Need to Speed Up OPC UA Development? Use a Framework

By Bob McIlvride, Director of Communications, Skkynet Cloud Systems

One of the convenient features of OPC UA is scalability.  Unlike OPC Classic that runs only in Windows, you can put OPC UA on an embedded OS and connect to applications right at the device level.  That functionality comes with a challenge, though―development.  To get OPC UA into your system, you need to build it.

Thankfully, you don't have to start from scratch.  There are software development kits (SDKs) on the market to help developers build OPC UA applications.  These SDKs tend to be collections of reference implementations, wrappers, helper classes, and sample applications aimed at giving you a head-start for building your UA app.  Developers with experience in OPC UA find these tools indispensable.  The problem is, in the end, they still need to build it.

Beyond the SDK - A Framework

As useful as an SDK may be, there is another level beyond build-it-yourself.  We call that a "framework".  You can think of a UA framework as a pre-installed OPC UA server that a developer can easily integrate into a project.  It comes with the necessary code to bridge between the application logic and the OPC UA protocol.  Using a framework, a developer can focus on their specific application, and simply make connections to the OPC UA server as needed. 

An OPC UA framework is a pre-installed OPC UA server.

Here are three ways an OPC UA framework speeds development time:

1. Resolves OPC blocking - OPC UA is a synchronized protocol, which means that every OPC message between a UA server and a UA client needs a response before the process can continue.  While it is waiting, the server cannot take messages from the application, such as notifications that the source data has changed.  And if it is connected to multiple OPC clients, the UA server will block one client while waiting for a response from another.  The way around this problem is multithreading, the ability to handle multiple data connections simultaneously.  A good SDK might offer multithreading for the OPC UA data streams, but a developer still needs to handle the threading for communicating with devices and sensors.  An OPC UA framework, on the other hand, provides multithreading for all connections in the application, including connections to devices and sensors.  With multithreading built in, the framework saves a developer a lot of time.

2. Converts protocols - Embedded OPC UA is typically used in one of two scenarios: device interfaces or IIoT gateways.  Each of these has its own data protocol, which the OPC UA server is responsible for converting.  For example, a UA server in a gateway might convert OPC UA to MQTT or DHTP, while a UA server in a device might convert Modbus or DeviceNet to OPC UA.  This conversion is not trivial, as the server needs to maintain the connection logic, data hierarchy, and other characteristics unique to the protocol.  A framework will typically come with one or more of these protocols pre-installed, reducing the task of protocol conversion to simple configuration rather than complex development.

3. No need to learn OPC UA - How many programming languages and protocols do you or your developers know already?  How much time do you want your team to spend learning a new one?  OPC UA is not simple.  This is a far more sophisticated protocol than OPC DA, and implementing it is more complex.  According to our own experience, and the highly qualified OPC developers we've talked to, it can take 12 to 18 months to develop a decent OPC UA server, even when using an SDK.  Since it is an industrial protocol, you can't cut corners or rush something through half-tested.  Using a framework, the OPC UA server is already built, abstracted away, and accessible.  Instead of spending time learning OPC UA, the developer simply interacts with the higher level functions offered by the framework. 

We are a software company, and our developers know how tempting it is, how fun it can be, to roll up your sleeves and dig into a new and exciting protocol.  They relish the chance to say, "And we did it all by ourselves" every now and then.  But they also keep an eye on the clock and the bottom line, and are always looking for more effective tools.  The best tools take care of the routine work, and let them focus on the fun stuff, the important stuff, the creative stuff.  For embedded OPC UA development, whenever possible, they use a framework.

About the Author

Bob McIlvride is Director of Communications at Skkynet Cloud Systems, Inc., a global leader in real-time data information systems. He has been working as a professional technical writer in the industrial process control sector for over 15 years, and can be reached at [email protected]

Did you Enjoy this Article?

Check out our free e-newsletters
to read more great articles.

Subscribe Now