The last 2 articles discussed the trends and information of OPC UA and Industrial IoT, and Industry 4.0. The first five points have been introduced, and this article will introduce the other five key points.
6. Tool chain compatibility and security
It is critical to choose an OPC UA SDK that supports a wide range of platforms and toolchains. Preferably, the SDK runs on both 32 and 64-bit architectures with distributed obfuscated source code, allowing the vendor to use any hardware platform required depending on the platform for which the SDK is to be compiled. This is different from binary SDK distribution, which only provides compiled versions of the SDK for specific platforms. A platform- and OS-independent SDK can be compiled for all CPUs and microprocessor units (MPUs), and the SDK can also run in any CPU and microprocessor unit to meet system requirements.
In addition, developers should also consider whether the kit supports common communication transport protocols, encodings and security models when purchasing the OPC UA SDK. This includes whether opc.tcp transport and binary encoding are supported, as well as signatures and encryption based on the latest standards. In addition, they should ensure that their devices are enabled for Ethernet TCP.
7. Language support
Developing OPC UA SDKs in different languages while maintaining scalability and excellent quality is not easy. For SDKs that support different languages, vendors that have released multiple SKUs have found that the task of incrementally improving their products based on the release of new specifications such as MQTT/AMQP Pub/Sub and UDP is becoming increasingly difficult. Experience has shown that C++ is the most appropriate language to use for SDK development. In contrast, techniques for packaging native code using C, Java, NET or Python have been validated and tested and are not technically difficult. If a customer needs to develop an SDK in any language other than native C++, the SDK vendor can provide appropriate packager services or other assistance.
8. Third-party libraries
Third-party libraries are another important factor for developers to consider when implementing OPC UA. Most companies already have preferred library versions for their products and applications, so they usually want to stick with the libraries they are familiar with. Therefore, leading technology providers often provide packaged programs for standard cryptographic libraries. In addition, they will provide sample application scenarios, manuals and API calls to use other packagers such as OpenSSL, NanoSSL, mBedTLS, TinyXML2 and LibXML2 that are provided.
9. Future Plans
This may seem obvious, but when selecting an OPC UA SDK vendor one needs to be aware of their financial stability and the professional experience needed to support customer needs over the long term. Since development around the SDK is ongoing and the OPC Foundation is constantly releasing new specifications (e.g. AMQP Pub/Sub, UDP, and in the near future TSN), it is critical to choose a partner that can keep pace with new features and enhancements. Vendors should build technology plans that are responsive to market developments and are committed to providing SDK solutions that cover all new features.
10. Vendor help
In addition to cost, performance and reliability issues, it is important to choose an OPC UA SDK vendor that is committed to building a close customer relationship to better meet the business and technical needs of its customers. The right vendor not only has proven industry experience and methodology, but can also provide local help and support on a global scale.
Working with Matrikon
For nearly 20 years, Matrikon has been the world’s leading data connectivity provider, offering solutions for a wide range of critical control systems and applications on the market. With successful installations of Classic OPC and OPC UA facilities and industry-leading real-time support services around the world, Matrikon solutions enable universal access and seamless connectivity across the enterprise – independent of the device, application or manufacturer chosen.
Figure 5: With the right OPC UA SDK, suppliers can confidently focus their development efforts and resources on improving the competitiveness of their core business, with the confidence that their products will deliver proven interoperability, security and reliable data connectivity.
Figure 6 For more than 20 years, Matrikon has been the world’s leading supplier of data connectivity to the automation industry.
Leading automation system and equipment suppliers have chosen the Matrikon Flex OPC UA SDK to easily and seamlessly embed OPC UA into their products. This versatile toolkit not only meets the requirement of a small memory footprint, but also provides excellent performance. It enables developers to use the same API for any size processor and operating system.
The Flex SDK is ideal for companies that are not proficient in OPC UA, but want to offer this functionality in their products. With the popularity of IIoT, the use of this standard in products is becoming more common. The toolkit allows for quick and easy implementation of OPC UA applications of any size. The toolkit is targeted at developers who need to implement native data connectivity in a way that is
– Open standards based on security
– Preserves rich data scenarios
– Hardware platform independent
– Operating system (OS)-independent
– Scalable for embedded environments and personal computer (PC) environments
– Very flexible to help accelerate communication between devices and applications in the workplace, office building and/or enterprise cloud
Unlike other OPC UA SDKs that require developers to use separate toolkits when implementing products on different platforms, the Flex SDK allows developers to use, maintain and update all of their products with just one solution. This solution allows for efficient and affordable deployment of IIoT connectivity within a portfolio, ultimately reducing the time required to bring products to market.
