A Horizontal Taxonomy for the Industrial IoT
then adapt to deliver to each endpoint in the schema that the endpoint expects1. These systems
thus decouple application interface dependencies, allowing large projects to evolve interfaces
and make parallel progress on multiple fronts.
Figure 7: IIoT Applications Built by Large Teams
Hundreds of different types of hospital medical devices, from heart monitors to ventilators, must combine to
better monitor and care for patients. Similarly, ship systems integrate dozens of complex functions coordinate
functions like navigation, power control, communications. When a complex “system of systems” integrates
many complex interfaces, the system architecture itself must help to manage system integration and evolution.
3.5
Runtime Integration
Metric: More than 20 “devices”, each with many parameters and data sources or sinks, that
cannot be configured at development time
Architectural Impact: Must provide a discoverable integration model.
Some IIoT systems can (or even must) be configured and understood before runtime. This does
not mean that every data source and sink is known, but rather only that this configuration is
relatively static. Others, despite a potentially large size, have applications that implement specific
functions that depend on knowing what data will be available. These systems can or must
implement an “end point” discovery model that finds all the data in the system directly.
However, other systems cannot easily know what devices or data will be available until runtime.
For instance, when IIoT systems integrate racks of field-replaceable machines or devices, they
must often be configured and understood during operation. For instance, a plant controller HMI
may need to discover the device characteristics of an installed device or rack so a user can choose
data to monitor.
1
http://www.omg.org/spec/DDS-XTypes/
- 36 -
December 2015