IIC Journal of Innovation 5th Edition | Page 81

A Practical Guide to Using the Industrial Internet Connectivity Framework
3 . Teams of programmers must control interfaces between modules . The databus specifies a full data model . All connectivity frameworks do this to some extent , but the databus specification is more expressive . It includes not only type information , but also QoS such as deadlines , sensor availability and flow rates . So , the interfaces are defined and then enforced at runtime . The databus can also manage the evolution of those interfaces , allowing modules , for instance , that use newer and older versions of an interface to interoperate . That is important for a practical , large IIoT system that must be incrementally deployed and updated .
4 . A databus controls flow between many complex applications . It handles a mix of fast and slow components . Its filtering can make the overall flow manageable . Peer discovery delivers data between multiple field-based components . And QoS control guarantees the flows . There are simpler solutions for one-way , onedestination flows such as capturing sensor information to send it to the cloud for analysis .
5 . Finally , using a databus requires a completely new architecture . Most DDS designs are building something new rather than optimizing something old . The databus can integrate legacy subsystems via gateways and adapters , but it should not be considered an incremental design change .
Most databus systems do not have all five of these properties . Three of the five indicate that a databus design will be compelling .
OPC UA
OPC UA is a standard managed by the OPC Foundation , also documented as IEC 62541 .
OPC UA targets device interoperability . Rather than accessing devices directly through proprietary application program interfaces ( APIs ), OPC UA defines standard APIs that allow changing device types or vendors . This also lets higher-level applications such as human-machine interfaces ( HMI ) find , connect to and control the various devices in factories .
OPC UA divides system software into clients and servers . The servers usually reside on a device or higher-level Programmable Logic Controller ( PLC ). They provide a way to access the device through a standard “ device model .” There are standard device models for dozens of types of devices from sensors to feedback controllers . Each manufacturer is responsible for providing the server that maps the generic device model to its particular device . The servers expose a standardized object-oriented , remotelycallable API that implements the device model .
Clients can connect to a device and call functions using the generic device model . Thus , client software is independent of the actual device internals and factory integrators are free to switch manufacturers or models as needed . So , OPC UA can build and maintain a system from interchangeable parts , much like standardized printer drivers allow PC system integration . Note that the device model also provides a level of “ semantic ” interoperability , because the device model defines the generic object APIs in known units and specified reference points .
IIC Journal of Innovation - 79 -