Industrial Automation: 5 Factors To Consider When Choosing And Implementing OPC UA SDK

Patrick

December 9, 2022

General
Industrial Automation: 5 Factors To Consider When Choosing And Implementing OPC UA SDK

Open Platform Communications United Architecture (OPC UA) is an IEC62541 international standard cross-platform, open-source, for industrial communication between sensors to cloud applications.

This machine-to-machine communication integrates and interoperates data between different devices and vendors. As a successor to the OPC Classic specification, OPC UA has posed as a crucial and vital solution as it proves to be one of the easiest and fastest channels of information transfer (with the right tools.)

pasted image 0 (5).png 105.83 KB

However, because the devices on IIoT are controlled by a software application, it’s necessary to ensure that both end-use and software engineers have a quality user experience. 

There are 5 factors in total that you need to consider before choosing and implementing your OPC UA. 

  1. SDK (Software Development Kit)

The only way to have and implement an effective OPC UA is if you have a suitable SDK vendor with both technical and human resources. It must meet the requirement and allow you to enable security, API, and other basic functions that allow you to scale the SDK. Scalability is inevitable in all new and existing systems. 

Ensure scalability with 3 criterias. 

  1. The SDK must accommodate any type of hardware
  2. Be vendor independent
  3. Be platform-agnostic and OS

This will allow your OPC UA toolkit to be platform-independent and efficiently interoperable with small or large enterprise applications.

2. User-friendly and Customer Support

For the SDK to help you save time, energy, and cost, ease of use is important. Smaller scale manufacturers will save up plenty of time and effort from learning the ins and outs of the OPC UA application if it can deploy with a simple application with fast intergration using APIs. In addition, choose an SDK vendor that is willing and ready to provide thorough and step-by-step support on the OPC UA implementation so you don’t have to hire any additional experts in house. 

3. CPU and Memory

The SDK platform layer usually consists of several modules that encapsulate the general operating functions(often these modules work across multiple platforms e.g. like OpenSSL crypto and PKI backends.)

pasted image 0 (6).png 37.11 KB

Choose the modules that work on your platform and only port modules to write new backends  when configuring the SDK. This will allow easier existing code reuse with no requirement to maintain multiple parallel implementations for the various platforms. (E.g. OPC foundation stack) 

If written with an embedded system, the OPC UA SDK will require less CPU (Central Processing Unit) utility. When multi-threads aren’t available, this enables the application to accomplish significant work in a single thread, resulting in lower overall costs. 

Secondly, a good OPC UA implementation should have a minimum footprint with a lighter RAM. Memory leaks can take the entire system down when accumulated over time. No memory leaks are allowed in the OP UA SDK. 

4. Security, compatibility, and third-party libraries

First off, various security modes must be supported with compatibility with many other applications and security requirements. In fact, standard OPC UA must support all security modes. 

With third-party libraries, software application processes will be easier and more accessible. Most companies have their preferred libraries, which makes it a must for SDK vendors to have at least standard crypto libraries use-case examples, manuals, and API references to use wrappers like NanoSSL, Lib2XML, mBed TLS, and TinyXML2.

5. Language Support and Future Updates

It’s true that C++ is the most common language for SDK codes. Others such as Java, C, .NET, etc. are also quite common. The only challenge is when you have to make accumulative improvements to the products. Choose a broad language and tool interoperability options to allow you to develop an OPC in a wide range of languages.

Secondly, remember to ensure that SDK vendors are equipped and agile in performance to implement protocols and ongoing developments around SDKs and other OPC techs like AMQP Pub/Sub, UDP, and TSN.

Ti2 partners with Softing Industrial to provide competent OPC UA technology, products, and services for secure and reliable data integration. 

With more than 20 years of experience in OPC technology and a close working relationship with the OPC Foundation, Softing is the ideal partner for all OPC topics. Softing develops and markets a broad range of development tools and consumer products, including gateways for innovative and secure IoT architectures. This makes it possible to realise state-of-the-art solutions for OPC-based data exchange, optimally tailored to individual requirements, both in brownfield applications and new systems. All Softing products support the state-of-the-art OPC UA technology. Thus, the implemented applications benefit directly from its advantages. The product range is supplemented by appropriate training and development services. 

Softing’s dataFEED OPC SDKs enable the fast integration of OPC UA or OPC Classic connectivity capabilities in automation applications. The SDKs are built by a comprehensive set of libraries featuring a simple and well-documented programming interface. Relevant example applications as well as test and simulation tools allow for a short time-to-market of OPC-enabled products. 

To learn more about what we do and how we can help your OPC UA requirements, please click projects, products & services.

Ti2 is currently very focused on working with its global partners to secure stock and avoid long delay times in delivering products to their customers. Together with our trusted partners, we are here to provide solutions.

Please click here to email us your inquiry, we would like to hear from you.

Article inspired by ETEC, Forbes, Rockwell, SME, Elsevier, and Ti2.