A Practical Guide to Using the Industrial Internet Connectivity Framework
standard” per the IICF guidelines, because it has no standard type system. Without a type system, it cannot offer a standard ability to interoperate at the“ syntactic” datastructure level, leaving all data interpretation to the application.
Nonetheless, MQTT enjoys significant awareness. Because of its simplicity, simple questions about your system will help determine if it is appropriate:
1. Do you think of your application as data collection?
2. Is there little device-to-device communications? 3. Is interoperability not a consideration? 4. Do you have many small devices? 5. Is software a minor challenge?
Again, if you answer three or more of these“ yes,” you should look at MQTT. The reasons:
1. The first“ T” in MQTT stands for“ Telemetry,” or data collection at a distance. This is its main use case.
2. MQTT is designed as a hub-and-spoke design that requires a broker. It does not support direct inter-device communications. Choosing MQTT for device-to-device communications is awkward.
3. Without a type system, MQTT applications are tightly coupled – they must all be aware of the data format. The only way to build interoperability is to implement a way to share types in user code. As a result, most of all MQTT applications are standalone systems. MQTT also does not help with system evolution; version compatibility between components must be provided by the applications.
4. MQTT is by far the simplest technology considered here. If you have many small devices that are simply connected, simple software can handle your challenge.
5. MQTT offers little to ease software development. There is only one QoS setting( reliability). There are no defined services. It offers no data or device modeling. You are therefore going to have to write all of the software from scratch; that is only practical if you have a simple software challenge.
Comparisons and Overlaps
Comparing these technologies highlights the stark differences and non-overlapping nature of connectivity approaches.
For instance, OPC UA is object oriented( OO), while DDS is data centric. Those are diametric opposites. The OO mantra is“ encapsulate data, expose methods.” Data centricity is all about exposing data and there are no user-defined methods. The only methods are defined by the standard.
OO systems work like a sequential programming language. You“ call a method” on a remote server, it returns. Then you call the next. It is simple and intuitive for getting and setting values. However, it is difficult to call many methods in parallel. The new OPC UA“ pub / sub” functionality retains this flavor. Applications fundamentally interact with active remote peers. The paradigm is sequential reading and writing device values or streams, organized as a larger“ address space.”
IIC Journal of Innovation- 83-