By Arun Ananthampalayam, Sr. Product Marketing Manager for OPC UA, Honeywell Process Solutions
Growing adoption of the Industrial Internet of Things (IIoT) and Industry 4.0 is driving requirements for open and secure connectivity between devices (e.g., machine-to-machine) and edge-to-cloud solutions. Those who deploy the OPC Foundation’s (OPC) Unified Architecture (UA) will be able to better leverage plant floor to enterprise communications as a vehicle to participate in IIoT applications. The goal for OPC is to be a standard for interoperability for moving information vertically through the enterprise of multi-vendor systems as well as providing interoperability between devices on different industrial networks from different vendors.
Today’s Industrial Revolution
Technological advances have been the impetus for dramatic increases in industrial productivity since the dawn of the Industrial Revolution. The first step was the mechanization of production using water and steam power. The second phase then introduced mass production with the help of assembly lines and electric power, followed by the third advancement with the use of electronics and information systems to further automate production.
Today, the fourth industrial revolution encompasses the technologies and concepts of the value chain organization. Known as Industry 4.0, the current phase of innovation relates to the previous three industrial revolutions, each of which heralded a turning point in production and manufacturing strategies. Industry 4.0 employs the concept of cyber-physical systems designed to link real objects with information-processing, and virtual objects and processes, via information networks – including the Internet.
Fig. 1. In a highly competitive global marketplace, industrial organizations are dealing with the evolution of their businesses and operations, where the virtual world of information systems, the physical world of machines and the Internet have become one.
Need for Improved Connectivity
Now, more than ever, manufacturing firms need to make sense of vast quantities of data having a critical impact on their performance. To support the variety of applications necessary within an industrial facility, information must be delivered with context so it can be understood and used in various ways by a variety of people.
The latest wave of technological change is bringing unprecedented opportunities to manufacturing businesses. Companies, and whole industries, must react quickly to capitalize on the new capabilities and avoid obsolescence. The first challenge is connecting devices and intelligent systems. Communication standards form the backbone of the IIoT in that they enable the secure integration and interoperability of the many devices and software applications that participate in this “system of systems.”
Fig. 2. The IIoT is being enabled by technologies that help manufacturing facilities access and capture real-time information.
Growth of OPC UA Technology
International standards are needed for Industry 4.0 and the IIoT, to accelerate growth in industrial and manufacturing environments. Having international standards in place means that data coming from Industrial Internet machines will be consistently identified, and mapped in the same way, whether that’s data about usage, or when the machine needs maintenance.
First issued in 1996, the OPC’s data connectivity standard (OPC UA) is increasingly being used by automation suppliers and original equipment manufacturers (OEMs) to enable IIoT connectivity in their products. The OPC standard allows for secure and reliable exchange of data across manufacturing and other enterprises. The OPC UA is a platform-independent, service-oriented architecture that integrates all the functionality of the original OPC specifications into a single, flexible framework.
The standard is built on an information model that provides structure and context to information at its source, which is critical to have responsive systems.
Importance of Developer Tools
The choice of tools to be used in the software development process can literally make or break a project. Once the target environment and programming language(s) is chosen, and the requirements and end goals are understood, the next task is to select the tools that will be used throughout the process.
A well-functioning software development kit (SDK) delivers a quality user experience for both the end-user and the engineers who integrate it. Selecting an SDK represents a substantial commitment in terms of initial adoption, implementation, and ultimately maintenance. If the most appropriate toolkit is not chosen, the result likely means significant additional work, rework, or worse – serious system limitations.
In the automation market, suppliers require an effective SDK solution for deploying IIoT connectivity across their product lines. Vendor development teams seek a fully scalable SDK that allows them to easily interconnect industrial software systems, regardless of the platform, operating system or size.
Choosing the Right SDK
Whether you are a tool builder or an application developer – if your software needs to access automation data, you may want to implement OPC UA connectivity to ensure your system can access data via the world’s most popular, standards-based, open connectivity solution. The question is: How to best do this?
Discrete and process industry manufacturers, commercial customers, and automation OEMs choosing an OPC UA SDK should be mindful of the following key considerations:
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 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 account.
Fig. 3. Automation suppliers need an OPC UA SDK that is scalable across every class of device or application, enabling products to be engineered for either minimum unit cost or maximum performance.
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
Irrespective of 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.
Fig. 4. Developers seek a software toolkit with superior performance characteristics allowing them to target low-cost microcontrollers or use less CPU resources on embedded processors.
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.
Fig. 5: With the right OPC UA SDK, vendors can confidently focus their development efforts and resources on core business competencies, knowing their products deliver proven interoperability and security, as well as reliable data connectivity.
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.
About the Author
Arun Ananthampalayam is the Sr. Product Marketing Manager for OPC UA connectivity solutions within Honeywell Process Solutions. As a member of the Honeywell Connected Plant IIoT team, Arun is responsible for leading the connectivity aspects of Industrial Internet of Things (IIoT) which will directly impact Honeywell’s growth. Arun has 10+ years of experience working for Information Technology and Industrial Internet of Things businesses. He was responsible for managing >$120m product portfolio. Played a critical role in developing and marketing IIoT technologies such as asset performance management systems, predictive analytics, and diagnostics solution for Data center, O&G, and other verticals. Arun has an MBA and MS in Electrical and Computer Engineering from Portland State University. For over 20 years, Matrikon has been a leading data connectivity supplier providing solutions for control system application. With successful classic OPC and OPC UA installations and live-support around the world, Matrikon solutions are recognized for enabling universal access and seamless connectivity across the enterprise –independent of the devices, applications or manufacturer selection.
Source:Automation.com
