.png)
In industrial automation and IIoT systems, OPC UA (Open Platform Communications Unified Architecture) has become a cornerstone for secure, reliable, and platform-independent communication. One of the essential features of OPC UA is its method call functionality, where clients can invoke methods on the server with specific input arguments. The server processes the request through an internal method handler and returns a StatusCode to indicate success or failure.
However, what happens when additional diagnostic information needs to be sent along with the response? This scenario was encountered in one of our customer projects, and it posed an interesting technical challenge.
The Problem
In the customer’s application, the OPC UA server was integrated with REST APIs. Each OPC UA method call triggered a corresponding REST API method within the server’s method handler. The REST API response was then analyzed to determine the appropriate OPC UA StatusCode to return. While functional, this approach had two significant drawbacks:
Maintenance Overhead: Mapping REST API responses to OPC UA StatusCodes required considerable effort, especially as the API grew in complexity. Each new scenario needed to be manually mapped, increasing the potential for errors.
Scalability Impact: The process of analyzing API responses and determining corresponding StatusCodes became a bottleneck, making the system less scalable.
Furthermore, returning the REST API response as an output argument of the OPC UA method was not an option. According to OPC UA specifications, the output argument must be null if the StatusCode is anything other than Good.
The Solution
To address these challenges, we devised a solution that leveraged the flexibility of OPC UA. Instead of overloading the method’s output arguments, we constructed a service result that included both the StatusCode and additional diagnostic information from the REST API.
The service result consisted of:
A StatusCode to indicate the success or failure of the method call.
A response message from the REST API, providing detailed diagnostic information.
This approach allowed the client application to access additional information for troubleshooting while adhering to OPC UA specifications. The diagnostic data proved invaluable for identifying issues and improving the overall system reliability.
Why This Matters
OPC UA’s extensibility and versatility make it a powerful choice for industrial applications. By leveraging features like custom service results, we can tailor solutions to meet specific requirements without compromising on maintainability or scalability. This approach not only resolved the immediate issue but also highlighted the adaptability of OPC UA for complex integration scenarios.
Conclusion
At Eclatron Technologies, we continuously encounter and solve unique technical challenges in the realm of industrial automation and IIoT. By sharing these experiences, we aim to contribute to the broader community and inspire innovative solutions.
Stay tuned for more insights, technical deep dives, and case studies from our work.