EclipseSCADA/Plan/IEC 62541

IEC 62541 (OPC UA)

to cite from wikipedia (http://en.wikipedia.org/wiki/OPC_Unified_Architecture):

OPC Unified Architecture, OPC UA, is an industrial M2M communication protocol for interoperability developed by the OPC Foundation. It is the successor to OLE for process control (OPC). Although developed by the same organization, OPC UA differs significantly from its predecessor. The Foundation's goal for this project was to provide a path forward from the original OPC communications model (namely COM/DCOM) to a cross-platform service-oriented architecture (SOA) for process control, while enhancing security and providing an information model.

Various stacks for Java were being developed. Similar to .NET, there are principally three variants:

• Encapsulate the complete ANSI C stack via JNI, which complicates portability. Although the stack can be ported to different operating systems, it needs to get compiled for those individually. Also, the data needs to get copied to the JNI boundary, but benefits from the performance of C during de-serialization.
• Code directly on the network layer (similar to the current .Net implementation) and de-serialize in Java. This saves one data copy execution, but still depends on the C stack.
• Write a native Java OPC UA stack. This was observed to be the most portable, but estimated to take the most engineering effort to implement.

Alternatively, there is the simple variant to only support the WebService protocol. For that, a SOAP Toolkit that supports WS-Security is needed.

IEC 62541 is a standard for OPC Unified Architecture.

A cleanroom implementation

The Javastack of OPC UA itself is provided by the OPC foundation. This can not be used since it depends on the licensing restrictions set forth by the OPC foundation. Since OPC UA is also standardized as IEC 62541, it is possible to create a variant which uses completely different interfaces but implements the same protocols. This is what we would like to implement for Eclipse SCADA. The library itself would be usable completely standalone, just as it is possible right now with IEC 60870-5-104. It would have some other dependencies like Netty and SLF4J.

Why we?

With IEC 60870-5-104 we already demonstrated that we can create a high quality implemantation according to spec. Although OPC UA is still larger we already did a very small prototype to validate our approach. Additionally with the Utgard library, a OPC DA 2.0 client implementation (part of the openSCADA project) we already have a product (and the mindshare) which is used world wide.

Sponsors needed

The implementation effort is pretty substantial, so it would take quite some time to implement it. Our idea was to split the effort between several parties. One of the parties could be you! The more participants would take part in the effort, the cheaper the implementation would get.

A plan for the implementation

The first step would be to create a client implementation for DA (comparable to openSCADAs Utgard). The implementation effort for that would be probably around 3 developer months. After that we would prefer to create a server implementation (for DA) [we don't have an estimation for that at the moment]. After that we could progress according to customer feedback. The cost would be the price for the specs (can be bought relatively cheaply at some Eastern European countries, but still a few hundred Euros) and the cost to finance the development itself. We would split the development into milestones (first DA client, then server, then HD(?), then AE(?)); the actual roadmap would be created as soon as some sponsors would commit themselves to the development.

Whats in it for me?

You would get a freely available library which you could use as long as the constraints given by the EPL are met. And this for the cost of what a handful of commercial licenses would cost.

Crowdfunding

If enough companies are willing to chip in, and ready to commit for the development, then there is also the possibility to lower the cost further in creating a kickstarter, indigogo or whatever project, so additional funding could be acquired.

You want to be a Sponsor?

Please write an email to Juergen Rose <juergen.rose@ibh-systems.com>, we should then personally talk about it.