F
Hi!
I'm having some thoughts on how a open source scada system could be built. I just want to hear what you have to say about it. If you have any input i'd be glad to hear it.
I've been looking around and are really impressed with what visual and PuffinScada has accomplished but IMHO there are always some thing that makes it that i cannot consider using them as a professional scada integrator. You might ask why i don't join and help adding the missing features but i believe that starting over, using the recent technologies that are available the workload is reduced.
Here are a few things that i feel is a need for making a customer even consider a open source alternative.
- Windows client
It's a fact that windows is most common operating system.
A linux alternative is always welcome but optional.
- IO Support
The times where i as a scada engeneer is able to chose what PLCs are used is used. A customer is also very seldom willing to accept lack of device support.
- Redundancy
- Configuration Enviroment
Text or XML files are great but a system without graphical configuration possibilities will never be widely spread.
Here's what i had in mind:
A complete modular system where the modules are run as individual processes.
To make a basic scada system the following modules would be required.
DataCollection:
To read and write IO data from devices and make it available to other modules.
OPC Foundation has recently released the XML-DA Specification wich looks
promising. Implementing a client for this is as difficult as implementing a
WebService. I'm expecting this to be about as much work as implementing a single
PLC protocol.
XML-DA to traditional OPC gateways are already available and enables all possible
I/O support.
Alarm:
Input from DataCollection and client (acknowledge, blocking) and output to Logging and
client to display alarm lists.
Hopefully if this project comes to reality the OPC foundation will have released
its XML Alarm & Events specification before any actual work is being done on the
alarm server.
Logging:
Handle log requests from the whole system and returning logs to the client.
OPC is planning historian support with XML aswell.
Client:
Graphic display of data.
the w3 svg standard looks like the best option around.
A standard svg file with a xml transformation definition file to describe
transformation with IO data.
Using svg makes it possible to use a commercial editor until something better is created.
I know you're wondering, You and what army of programmers are going to do this?
Well... Time will show if i'm wrong but i'm planning right now and will soon begin creating a class library for XML-DA.
The big task will be to complete the XML-DA and XML-AE support. If this becomes stable creating a modules for alarms, logging
or a client will be one mans job and would have a resonable chance of being completed.
Right now i'm planning on going .net and c#. I'm confident that mono will provide support for the linux platform and
if so it'll be platform independant.
I'm having some thoughts on how a open source scada system could be built. I just want to hear what you have to say about it. If you have any input i'd be glad to hear it.
I've been looking around and are really impressed with what visual and PuffinScada has accomplished but IMHO there are always some thing that makes it that i cannot consider using them as a professional scada integrator. You might ask why i don't join and help adding the missing features but i believe that starting over, using the recent technologies that are available the workload is reduced.
Here are a few things that i feel is a need for making a customer even consider a open source alternative.
- Windows client
It's a fact that windows is most common operating system.
A linux alternative is always welcome but optional.
- IO Support
The times where i as a scada engeneer is able to chose what PLCs are used is used. A customer is also very seldom willing to accept lack of device support.
- Redundancy
- Configuration Enviroment
Text or XML files are great but a system without graphical configuration possibilities will never be widely spread.
Here's what i had in mind:
A complete modular system where the modules are run as individual processes.
To make a basic scada system the following modules would be required.
DataCollection:
To read and write IO data from devices and make it available to other modules.
OPC Foundation has recently released the XML-DA Specification wich looks
promising. Implementing a client for this is as difficult as implementing a
WebService. I'm expecting this to be about as much work as implementing a single
PLC protocol.
XML-DA to traditional OPC gateways are already available and enables all possible
I/O support.
Alarm:
Input from DataCollection and client (acknowledge, blocking) and output to Logging and
client to display alarm lists.
Hopefully if this project comes to reality the OPC foundation will have released
its XML Alarm & Events specification before any actual work is being done on the
alarm server.
Logging:
Handle log requests from the whole system and returning logs to the client.
OPC is planning historian support with XML aswell.
Client:
Graphic display of data.
the w3 svg standard looks like the best option around.
A standard svg file with a xml transformation definition file to describe
transformation with IO data.
Using svg makes it possible to use a commercial editor until something better is created.
I know you're wondering, You and what army of programmers are going to do this?
Well... Time will show if i'm wrong but i'm planning right now and will soon begin creating a class library for XML-DA.
The big task will be to complete the XML-DA and XML-AE support. If this becomes stable creating a modules for alarms, logging
or a client will be one mans job and would have a resonable chance of being completed.
Right now i'm planning on going .net and c#. I'm confident that mono will provide support for the linux platform and
if so it'll be platform independant.