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 -