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-