What features a supervision / SCADA system should contain

There are many ideas on how to make a good supervisor system and this make also a lot of confusion to engineers.
Actually HMI panels are so powerful that they can be compared to SCADA, and when i visit some clients and i see their systems, 80% of times i can't understand why they choosed an expensive SCADA package instead of a simple panel.
HMI panels are better than scada for human machine interface, as they require less time to be programmed, they can just get replaced if they get broken and they require less downtime; they doesn't require an updated Operative System and they doesn't require an OPC Server.
And most of all, they are cheaper!
With this post i don't want to make a comparison with SCADA and HMI panels, but just to point out what a supervisor system should contain, it is up to you to understand if you need a simple Panel or a complex SCADA.
So a SCADA program needs:
  1. Communication driver: can be OPC , Modbus or what else, the communication is the most important thing of those systems. It must refresh values on read at least once every second.
  2. Graphical User Interface: should contain plant schemes, motors, valves, leds, pipes, sensors' state, everything connected with the plant. It should represent all the plant status and its peculiarity, and also it should be as much dynamic as possible. This means that if you represent a motor (grey), when it runs you should represent it Green, and when it is in alarm state make it blinking grey-red.
  3. Set Points entry and Present Values visualization: to permit the configuration and troubleshooting of the plant. A good way to create set point entry is to set the value on PLC, and when you receive the refresh events from communication driver you visualize just what the PLC contains in the memory.This can be not instantaneous, but you can always see if communication is up and running.
  4. Alarm management: usually made with databases, your supervisor should contain at least an alarm banner, an alarm log and a page with active alarms.
  5. Recipes management (if needed): it's made with a database too, that contains various set points that should be transmitted once the operator select the recipe. An interface CRUD is needed for this database.
  6. Plant Control (if needed): when there are heavy algorithms to be described with PLC language, for example when recipes are complex and the supervisor controls many PLCs, you can use the PLC to control drives and motors based on high level inputs (like "go to position", "set speed") coming from SCADA. 
  7. Data logging: based on database too, with a SCADA you should log all the critical process variables (pressures - temperatures - speeds and so on) and visualize them in charts like (x -> time ; y -> Set Point and Present Value and Max Threshold  + Min Threshold).
  8. Production tracking: while a product is being made, it should be associated with all the process variables' values during it's making time. This will create a database containing all the statistics needed to analyze the production and improve quality and times.
  9. Reporting: if you give data about production, you should also give to clients a way to use those data. You can show them with reports and you can also analyze them with special recipes to check for production flaws automatically.
  10. Multilanguage support: if you are going to sell the software worldwide you need to support all messages and labels with a language database (in this case an Access file is the best choice, because EVERYONE know how to compile Access tables).
Scada are systems very powerful and expensive (in working hours or in money spent to buy all packages),but it's good to see them running once you made them :)


Robin said...

Nice blog! Thank you for sharing information about this. I work for a company that uses Saia PCD. So now im playing around with Saia .net suite.
Im thinking about developing a small configurable system based on C# with saia .net suite and Mysql for database storage. By that i mean something like intouch but much smaller and easier to use.
Any thoughts about that?

Keep up the good work!

Michele Cattafesta said...

Hi, thanks for posting.
The answer to your question is wide and depends on points of view, so i try to give mine.
The biggest problem to write your own scada vs buying a commercial one is that you need to build your own framework, and with framework i mean all the functions, classes, objects, controls, graphics etc to make your program complete. This requires A LOT of time (and the point of this blog is to give a starting point).
So usually when a client ask for a program that should be more powerful than an HMI, i just write what it needs, and nothing more (of course reusing all the knowledge made with previous programs).
With this approach i could build a decent framework without wasting too much time on research and development.
One of the problem of commercial scadas is the biggest size and heaviness of their libraries (dlls), that they are nothing more than another layer on .Net.
So it's important to don't fall on that web; if you keep your programs light and clear without too many libraries, you will not fail.
About mysql i never used it (always sql express if i need it shared, of sqlite if i need a file, like for translations ) but i think it's ok mysql too.