Key Considerations for OPC UA SDK Selection
1. Total Cost of Ownership
Most customers choose to buy an OPC UA SDK rather than develop it in-house due to a lack of internal expertise, high development and maintenance costs, the challenges of keeping up with constantly evolving standards and specifications, and the need to reduce OPC UA implementation time in their application and accelerate time-to-market.
Not all commercially available SDKs are the same. It is important to ensure that the SDK vendor has implemented the common functionality necessary to enable OPC UA in most user applications, offers base functionality and functions, implements security handling, provides application programming interface (API) wrappers for high abstraction languages, and makes available use case examples.
Ease of use is important when choosing an SDK. Some technology providers choose to sell their commercially available SDKs for very low cost, but rely heavily on consulting revenue when they engage with customers. Customers are forced to pay for these additional services since the SDK does not include all common OPC UA functionality and simple-to-use APIs to integrate with existing applications. When calculating the total cost of ownership, customers should take both the consulting services cost and SDK upfront procurement cost into consideration.
2. Platform Scalability
An SDK’s scalability should go beyond being hardware platform agnostic and operating system (OS) independent. Most vendors have developed multiple stock-keeping units (SKUs) of products to address specific applications. This makes it impossible to enable OPC UA in all new or existing products, from discrete sensors and actuators, PLCs, remote terminal units (RTUs) and distributed control systems (DCSs), all the way to high-performance servers in a data center, using one scalable SDK. Developers have to learn multiple SDK codes to work across different platforms. At the same time, SDK vendors will face an insurmountable challenge to keep up with maintenance and enhancements to all SKUs. Managing the product lifecycle becomes a problem and customers do not always get the timely support they need during development.
One way to address this problem is to choose a truly scalable SDK. OPC UA toolkits should work equally well in small, embedded environments and large, enterprise-based applications. There are significant benefits to a single, fully scalable toolkit that allows users to quickly and easily interconnect industrial software systems, regardless of the platform, operating system or size. Ideally, the SDK should employ a robust and reliable design built from embedded first principles to maximize product uptime.
3. Ease of Use
By partnering with a knowledgeable SDK provider, you don’t have to be an OPC UA expert to take advantage of the standard’s powerful functionality. The SDK should incorporate abstraction methods employing simple objects, thus eliminating the need for in-depth knowledge of the OPC UA specification. The SDK should logically organize tasks for software developers, and utilize a consistent approach to simplify deployment from application to application. The SDK should also provide integration using APIs. In this way, users can enjoy customization with access to low-level OPC UA functions.
SDKs implementing a drop-in “OPC UA server/client-in-a-box” design provide a way to launch OPC UA-enabled products faster and with the fewest changes. Prototype development is reduced to days – not weeks or months.
4. CPU Utilization
Aside from implementing OPC UA technology in a Greenfield or Brownfield project, the cost of bill of materials (BOM) is of major concern. Many designers would like to reuse the BOM without moving to higher cost hardware (e.g., using ARM Cortex-M4 instead of ARM Cortex-M7). They may also want to target low-cost microcontrollers and use less central processing unit (CPU) resources on their embedded processor. That is why an OPC UA SDK should be written and optimized from first principles for embedded systems so the application can still perform a significant amount of work in a single thread in the case where multi-thread is not available.
5. Memory Footprint
A truly scalable OPC UA SDK should support all profiles – nano, micro, embedded and standard – an essential requirement for OPC UA implementation, especially in resource-constrained applications. The benefit is that developers can use the same API across all processor sizes and operating systems. The use of a small RAM and Flash footprint makes it possible to target low-cost microcontrollers or use less memory resources on an embedded processor. This memory model also does away with the need for system heap – enabling superior robustness. The SDK can be optimized for minimum RAM and Flash utilization, or for large data sets and multiple concurrent client connections.
6. Toolchain Compatibility & Security
It is important to choose an OPC UA SDK that is designed to support a broad range of platforms and toolchains. Ideally, the SDK should run on 32-bit and 64-bit architectures, and employ distributed as obfuscated source code – freeing vendors to use any hardware platform they want since they will compile the SDK for that platform. An SDK without platform or OS dependencies can be compiled for and run on all CPUs and microprocessor units (MPUs) that meet the system requirements.
Developers purchasing an OPC UA SDK should also consider the toolkit’s support for commonly used communication transport protocols, encoding, and security modes. This includes support for opc.tcp transport and binary encoding, as well as sign and encrypt up to Basic256SHA256. Additionally, they should ensure that their device is Ethernet TCP-enabled.
7. Language Support
Developing an OPC UA SDK in different languages while maintaining scalability and quality is a difficult task. Vendors who have released multiple SKUs of their SDK supporting different languages are already finding it challenging to make incremental improvements to their products as new specifications like AMQP Pub/Sub and UDP are being released. Experience has shown that C++ is the optimal language for use in developing an SDK. Conversely, wrapping native code in C, Java, NET, or Python is a tried and tested technology and is not technically challenging.
8. Third-Party Libraries
Third-party libraries are another crucial consideration for developers undertaking OPC UA implementation. Most companies already have a preferred library version for their products and applications, so they usually like to stick to what they know. For this reason, leading technology providers typically offer wrappers for standard crypto libraries. They also offer use-case examples, manuals, and API reference for using other supplied wrappers such as NanoSSL, mBed TLS, TinyXML2, and Lib2XML.
9. Future Roadmap
It may seem obvious, but when choosing an OPC UA SDK vendor, it is important to know if they are financially stable and have the expertise necessary to support their customers’ needs over the long term. Since there are ongoing developments around SDKs, and the OPC Foundation is always releasing new specifications like AMQP Pub/Sub, UDP, and in the near future TSN, it is critical to choose a partner who can keep up with the new features and enhancements. The vendor should maintain a market-backed technology roadmap and be committed to delivering SDK solutions addressing all nano, micro, embedded and standard profiles, as well as other key facets such as data access, historical access, alarms and conditions, and programs.
10. Vendor Assistance
Aside from cost, performance and reliability issues, it is essential to work with an OPC UA SDK vendor who is dedicated to building close relationships with customers to best address their business and technical needs. The right vendor will have proven industry experience and know-how, and provide a local presence on a global scale.
