Utility SCADA

Status
Not open for further replies.

bwat

EE
Location
NC
Occupation
EE
Doing some info gathering... what platform do utilities use for their SCADA system?

I'm aware of a few, but want to see what's out there. Wondering whether a lot of them use a platform by well-known third party (and who those companies are) or if they are fully built in house from scratch. Answers from big utilities all the way down to small RECs and anywhere in between are welcome. Even answers toward quasi-utilities like large institutions that have a sizeable grid that they own are welcome.
 
It’s all over the place. It can be an HMI system or DCS. Or it can be purely built into the relays using GOOSE as a distributed system, which is becoming more popular.

Look at SEL as one example. Or GE Mark VI. Those are more utility specific. Honeywell tried to sell their DCS as well as Delta V which are the two dinosaurs. Then we get into various flavors of Wonderware, Ignition, GE Profitcy/intellution, ABs system.

They are all mostly inter compatible with each other except the DCS systems.
 
They are all mostly inter compatible with each other except the DCS systems.
What makes you think that different DCS systems are not compatible with each other? Most of them can be made to easily talk to each other in fairly straightforward ways. They are certainly different from each other but no more different in most respects than the relays are from each other. It's just about having the people that understand how to make it work, just like it is having people who know how to make the relays work. Admittedly the scada software is multiple orders of magnitude more complex than a relay.
 
Doing some info gathering... what platform do utilities use for their SCADA system?
Three of my ex customers (ex because I'm retired) use PI from osisoft.com. They were utility scale, but not utilities; pulp/paper and steel mills.
 
The trend is towards TCP/IP (ethernet). Some large SCADA providers, like Siemens don't use ethernet (yet), but those odd protocols like ModBus, DeviceNet are going away. I worked on 4 generations of SCADA equipment for Water and Wastewater, ending up with TCP/IP. So my end equipment could talk over twisted pair, licensed radio, fiber optic and cellular radios.
 
The trend is towards TCP/IP (ethernet). Some large SCADA providers, like Siemens don't use ethernet (yet), but those odd protocols like ModBus, DeviceNet are going away. I worked on 4 generations of SCADA equipment for Water and Wastewater, ending up with TCP/IP. So my end equipment could talk over twisted pair, licensed radio, fiber optic and cellular radios.
Siemens has done ethernet for at least a decade. They want you to use their flavor called profinet but it can coexist with any other TCP/IP based ethernet.

Modbus is not going away. It is cheap and simple to implement so is popular with cheapskates. And it works really well.

Devicenet should have been killed off a long time ago as a favor to the users.
 
OSI SCADA platform.
DNP between SCADA server and RTAC in the field.
Relays to RTAC in the same station use SEL protocol over fiber.
Some line devices are SEL over cellular to RTAC in office then DNP to SCADA server.
Most now get from RTAC at the station back to SCADA server over cellular signal. A few stations have land fiber because there is no cell signal there.
Telnet first some, ssh for others
 
Siemens has done ethernet for at least a decade. They want you to use their flavor called profinet but it can coexist with any other TCP/IP based ethernet.

Modbus is not going away. It is cheap and simple to implement so is popular with cheapskates. And it works really well.

Devicenet should have been killed off a long time ago as a favor to the users.

Profinet is NOT Ethernet. If you want to claim that then Ethercat is “Ethernet”. Profinet and Ethercat use the same cabling and the same protocol as Ethernet but it stops right there. The switches are not standard Ethernet switches and the protocol is effectively token ring style (scheduled) with some portion of the traffic reserved for standard Ethernet. Siemens overcharges for the switches, the special Ethernet cards, etc., etc. In comparison Modbus/TCP is the serial Modbus protocol embedded in TCP packets. Due to some issues with how this works ODVA came up with the horrible name Ethernet/IP where they embed Devicenet/Controlnet packets into TCP or UDP. The TCP version is very similar to Modbus/TCP. But in UDP it can simply broadcast data without the request/response polling overhead which is very nice and duplicates what the Arcnet protocol (aka Controlnet) does big in true normal Ethernet without special switches.

Unfortunately the biggest vendor is Allen Bradley. The standard includes standardized packet formats for IO cards, instruments, and even VFDs. So it should be almost plug-and-play as far as compatibility. But AB refuses to do anything following the standard. Every one of their devices implements some screwy proprietary nonstandard formatted packet.

As far as Modbus and Devicenet going away, not a chance. Modbus works over miles using two twisted pairs and no fiber or repeaters. No other modern protocol comes close. And every single PLC brand and most more advanced devices support it. It is the universal protocol. Ethernet is far less prominent and far more fragile, and everybody has their own flavor. Second Devicenet does one thing well. When you have low density IO like on conveyor systems where you have only say an E-Stop or some simple digital input or output say every 100 feet, Devicenet or Modbus is very practical. On high IO densities and shorter distances Ethernet works out much nicer.
 
Profinet, Modbus/TCP, and Ethernet/IP can all coexist together with a normal Ethernet network. They all can use the same hardware, switches, routers, etc. There are some special things made mostly for industrial use but that is for environmental or packaging reasons and those things are usable in a normal plant network. The protocols are different, but they all can use standard ethernet hardware and cabling.

Devicenet seems to be slowly dying off. Ethernet is taking over. I fully expect POE devices to become the I/O of choice for the kind of applications you describe.
 
OSI SCADA platform.
DNP between SCADA server and RTAC in the field.
Relays to RTAC in the same station use SEL protocol over fiber.
Some line devices are SEL over cellular to RTAC in office then DNP to SCADA server.
Most now get from RTAC at the station back to SCADA server over cellular signal. A few stations have land fiber because there is no cell signal there.
Telnet first some, ssh for others
Never from the relays directly into SCADA? Always through RTAC? Curious to why. I understand the RTAC for use of automation tasks, but didn't think it was necessary if there were no automatic functions required.

Thank you everyone for the answers.
 
Never from the relays directly into SCADA? Always through RTAC? Curious to why. I understand the RTAC for use of automation tasks, but didn't think it was necessary if there were no automatic functions required.

Thank you everyone for the answers.
OSI doesn’t allow SEL protocol.
Only DNP, series 5, and 2179.
We don’t use Cooper
 
... didn't think it was necessary if there were no automatic functions required.

We often use RTACs as data concentrators and as network 'isolators'. We definitely liked to keep our protection separate from SCADA and the 'rest of the world'.
 
We often use RTACs as data concentrators and as network 'isolators'. We definitely liked to keep our protection separate from SCADA and the 'rest of the world'.
This is very true.
Our SCADA server is totally separate from our network. I can’t log in unless I’m off the company network when I remote in. Either that or work at one of two dedicated workstations.
then password protections through four different layers, including two RSA tokens generated through their token generator app on my phone.
So... no phone, can’t get into my computer.
 
Status
Not open for further replies.
Top