The previous article discussed the trends and information of OPC UA and Industrial Internet of Things, with Industry 4.0. To develop OPC UA client or server devices, where it is critical to choose the right SDK.
Choosing the right SDK
Whether you are a tool builder or an application developer, if your software needs to access automation data, you need to implement OPC UA connectivity to ensure that the system can access data via the world’s most common standard open connectivity solution. The question is: How do I optimize this aspect of my operation?
Manufacturers, commercial customers and automation OEMs in the stand-alone component and process industries should be aware of the following key points when selecting an OPC UA SDK.
1. Total Cost of Ownership
Most customers choose to purchase OPC UA SDKs rather than develop them in-house because of the lack of in-house expertise, high development and maintenance costs, difficulty keeping up with the evolving pace of standards and specifications, and the need for customers to reduce the time required to implement OPCUA in their applications and drive products to market.
This is not the case for all SDKs available on the market. It is important to note that it is important to ensure that the SDK vendor has implemented the common functionality required to enable OPC UA in most user applications, providing basic functionality and functions, implementing security processing, providing application programming interface (API) packagers for highly abstracted languages, and providing examples of available application scenarios.
It goes without saying that simplicity and ease of use are important when choosing an SDK. Some technology providers choose to sell their available SDKs on the market at a low cost, but rely heavily on the consulting services they provide to their customers for revenue. Since these SDKs do not include the various common OPC UA features and easy-to-use APIs needed to integrate with existing applications, customers are forced to pay for the additional services mentioned above. When calculating the total cost of ownership, customers should take into account both the consulting service fees and the upfront purchase cost of the SDK.
2. Platform Extensibility
The scalability of the SDK should not be limited to being platform- and operating system (OS)-independent. Most vendors have developed products with multiple stock keeping units (SKUs) to meet specific application requirements. This point makes it impossible to use one scalable SDK to enable OPC UA on all new or existing products, whether they are standalone sensors and actuators, PLCs, remote terminal units (RTUs) and distributed control systems (DCS), or high-performance servers in data centers. Developers must learn multiple SDK codes in order to use different platforms. At the same time, SDK vendors face huge hurdles in keeping up with the maintenance and enhancement cadence of all the SKUs. Managing the product lifecycle also becomes problematic, and customers may not always get the support they need in a timely manner during the development process.
One solution to this problem is to choose an SDK that is truly scalable. the OPC UA toolkit should work equally well in both small embedded environments and large enterprise applications. For companies that want to enable OPC UA for multiple product lines in a variety of environments, from embedded to enterprise applications, this scalability can make the SDK their ? one-stop? solution. There are huge advantages to adopting a fully scalable toolkit that allows users to quickly and easily interconnect industrial software systems regardless of platform, operating system or size. Ideally, the SDK should be a robust and reliable design built with an embedded systems-first philosophy to ensure maximum product uptime.
3. Easy to use
By partnering with an experienced SDK provider, you don’t have to be an expert in OPC UA to take advantage of the standard’s power. the SDK should contain abstract methods that use simple objects so that in-depth knowledge of the OPC UA specification is not required. the SDK should arrange tasks logically and intuitively for software developers and simplify deployment across applications using consistent routines. In addition, the SDK should provide an easy integration method using APIs. This way, users can easily customize and access low-level OPC UA functionality. They can learn one code base and then apply it to all systems and devices without having to master the nuances of multiple development products.
The SDK’s plug-in “OPC UA server/client integration” design speeds up the startup of OPC UA-enabled products and minimizes changes. Prototype development can be reduced to days instead of weeks or months.
4. CPU usage
Whether implementing OPC UA technology in an initial or mature project, there is a need to focus on the cost of the bill of materials. Many designers prefer to reuse the BOM rather than upgrade to higher cost hardware (e.g., using an ARM Cortex-M4 instead of an ARM Cortex-M7). In addition, they want to target low-cost microcontrollers and use fewer central processing unit (CPU) resources in the embedded processor. Therefore, the OPCUA SDK should be written and optimized based on the embedded system-first philosophy so that the application can still perform a large amount of work in a single-threaded environment where multithreading is not possible. In enterprise-class systems, adhering to the same philosophy can lead to significant performance gains.
The customer should choose an SDK that can perform tasks in a bare-metal environment with some operating system or real-time operating system (RTOS) or microcontroller. this approach helps to monitor a large number of process variables through multiple parallel connected UA clients.
Figure 3 The OPC UA SDK required by automation vendors to be scalable with different types of devices or applications to enable product design that minimizes unit cost or improves performance.
Figure 4 Developers are looking for software toolkits that not only perform well, but also allow them to target low cost microcontrollers or use fewer CPU resources in embedded processors.
5. Memory Space
A truly scalable OPC UA SDK should support all profiles (nano, micro, embedded and standard), which is a fundamental requirement for implementing OPC UA, especially in resource-constrained applications. The advantage is that developers can use the same API for all sizes of processors and operating systems. the advantage of taking up less RAM and flash space allows users to target low cost microcontrollers or use less memory resources in embedded processors. In addition, using this memory model also eliminates the need to use the system heap, providing excellent reliability. The SDK can be optimized to minimize RAM and flash usage or be suitable for large data sets and multiple parallel client connections.
