Download Real world problem anyone

Real world problem anyone?
In case there is anyone out there like me who likes to create programs just for practise and a bit of
fun – and frustration lol.
I work for transpower. We are experiencing a rare problem in a particular type of RTU we have
where if the SOE buffer overflows, instead of wiping the first entry as new SOE’s come in the buffer
just locks up. No more SOE points are stored in memory and therefore no new SOE points are
reported. It’s an acknowledged bug in the firmware and Transpower wants a work around now to
save money having to send a technician to site to reboot the RTU to reset the buffer. Under normal
conditions the SOE buffer is cleared as they are reported every second. But under fault conditions,
ie. a chattering point from some device, multiple SOE’s full up the buffer in under a second. See
Terminology below.
RTU PLC Logic required:
1. Create a heartbeat generated within the RTU which sends out an SOE point (a DI - Digital
input point) every 10secs to its master, the SMS.
2. Build in a startup delay of 2mins before sending out the first SOE heartbeat point to allow
time for the RTU to boot up and for all its attached devices to come online.
SMS logic (not PLC) listens for the heartbeat and when it receives one it sends back to the RTU a DO
heartbeat pulse in return.
3. Convert the incoming heartbeat DO to a DI
4. If 30secs has passed before the next DO heartbeat is received back from the SMS then send
a DI alarm point to the SMS which flags that the SOE buffer has overflowed. This point will
not of course be time-stamped as SOE’s are no longer being sent out.
As part of my investigation I will also be creating logic for the SMS – one in which the SMS listens for
the heatbeat coming from the RTU. If it stops receiving heartbeats it will either send a DI alarm flag
to national SCADA to alert the operators to the problem or send a DO control for the RTU to reboot
to reset the SOE buffer. We’re not sure if that’s possible, others are investigating whether we can
reboot the RTU remotely.
The other is as described above, the SMS listens for the heartbeat and sends back a heartbeat, then
if it receives the alarm flag that the SOE buffer is overflowed it will carry out one of the above
actions.
If the RTU requires more than one reboot an alarm would be sent to national SCADA
Terminology – in simplistic terms:
DI and DO – Digital Input and Output – referenced from the Master’s perspective. Therefore a DI
point is an input from the Master device but an outgoing point from a Slave device, but in both cases
they are referred to as DI’s.
RTU – Remote Terminal Unit – gathers telemetry data from IEDs, circuit breakers, voltage
transformers, current transformers etc etc about the health or otherwise of the system and sends it
to our national SCADA system. Transpower is monitoring 24/7 - currents, voltages, generation
outputs, surges, spikes, gas levels, temperature readings, circuit breaker trippings etc etc etc.
SCADA – Supervisory Control and Data Acquisition – it’s basically a system that gathers telemetry
data from all the RTUs within the wider system and displays information for operators to see what is
happening out there in the national grid. It can also remotely control the system, the most notable
example would be opening or closing a circuit breaker remotely.
SOE - stands for Sequence of Event – basically it’s simply a time-tagged data packet, generated by
whichever device is hanging off the RTU reporting a problem. If a point that changed state happened
to be a time-stamped point the RTU will place that point in its SOE buffer and send the point to the
master as an SOE point. Under normal running conditions the SOE buffer gets cleared every time
the RTU responds to the master. SOE’s are used during fault investigations to determine the
sequence of events that actually occurred over a variety of alarms that have been generated (all SOE
points are also alarms), this should then pinpoint what actually caused the problem in the first place.
COS – Change of State – every second the master device (in this case a different type of RTU called
an SMS) polls the slave (the RTU) requesting it sends through any data that has changed state since
the last poll. The RTU responds appropriately. Ergo the SOE buffer in the RTU is cleared every
second.
SMS – Station Management System – a new fancy RTU that has far more features and allows for
remote interrogation and modification.