Application layer protocol options for M2M and IoT functionality
consumes more power … but messages can be two bytes – even smaller than those of CoAP. Due to its open nature, MQTT can also be particularly easy to implement. No wonder Amazon Web Services’ AWS IoT employs MQTT for message transport and (with caveats) supports MQTT based on the v3.1.1 specification . MQTT does have some limitations, which may be due to the fact that MQTT was initially intended as a telemetry protocol – in contrast to the IoT-specific Lightweight Machine to Machine (LwM2M) protocol to be covered shortly. Features such as objects, connectivity monitoring, and remote device actions aren’t included in the standard, so inclusion of these tends to be vendor specific which degrades the standardized protocol’s value somewhat. MQTT also offers no error-handling abilities. Finally, although MQTT can be made secure with a full TLS protocol, doing so increases its overhead. Primarily at the enterprise level: AMQP Advanced Message Queuing Protocol (AMQP) is another open standard with some similarities with MQTT. It offers advanced features such as message queuing. However, the overhead of AMQP is higher than that of MQTT, making it poorly suited to connecting very constrained devices. No wonder its
air-traffic control systems. In these settings, DDS supports the connection of embedded systems for distributed control that’s freed from overreliance on gateways. DDS also handles the routing and delivery of messages without requiring intervention from applications. Plus, the quality of DDS service parameters are configurable – so network operations can be optimized to the work within system constraints.
applications, it can also operate a strong DTLS security protocol without increasing overhead.
Conclusion: IIoT application layer protocols All protocols have strengths and weaknesses, but open-source options allowing rapid deployment and security (preferably with low overhead) are the most suitable for IoT applications. Embedded systems and system-on-chip (SoC) devices with ever-increasing computing capabilities continue to spur IIoT implementation – and further expand what’s possible at various protocols’ application layers.
Figure 4: Nordic’s SiP is a low-power MCU with an integrated LTE-M and narrowband (NB)-IoT modem, as well as GPS. A Software development kit allows setup of CoAP. Image source: Nordic Semiconductor
DDS for real-time distributed applications The data distribution service (DDS) is a little different – and is often classified as an M2M middleware rather than an application-layer protocol. It provides secure and high-performance connections in (among other things) autonomous vehicles, power generation, and
use in industrial IoT applications is less common than its use in performance enterprise messaging.
should find that connecting IoT devices with CoAP is very similar to connecting devices with Web API.
CoAP for connecting simple devices The constrained application protocol (CoAP) from the Internet Engineering Task Force (IETF) allows communication on low-power networks between devices with minimal memory and processing power. It can operate with very low overhead and requests and responses can be as small as four bytes. CoAP eschews the use of a complex transport stack for use of UDP instead. Refer to the DigiKey article on EtherNet/IP versus PROFINET for more on UDP. Like HTTP, CoAP also uses the REST model – with servers making resources available under a URL and clients accessing them via POST, GET, DELETE and PUT methods. What’s more, CoAP can be easily translated into HTTP for integration with other web functions … and integrates with XML and JSON. Engineers
Connecting battery- powered devices with LwM2M
Real-time innovations Connext Drive uses DDS Sample Autonomous Vehicle Architecture
An application-layer protocol from the Open Mobile Alliance is the LwM2M protocol built specifically for IoT applications. Employed in smart-city applications, shipping-container, and cargo tracking, automated off-highway routines, and utilities monitoring, LwM2M is based on CoAP, so shares many of its attributes. The standard encompasses a wide range of clearly defined and maintained standard objects as well as connectivity-monitoring and remote-device actions. Automatic firmware upgrades also simplify the management of LwM2M- connected devices. Although the inclusion of modules such as JSON increases its overhead, it also makes design work easier for developers. Because LwM2M has been designed specifically for IoT
Teleop
Fleet Mgmt
Connext Databus
ROS Component
?
ROS2 (DDS from Connext Drive)
Path Planning
Vehicle Control
Teleop
Connext Databus
AUTOSAR Component
Connext Databus
AUTOSAR Adaptive (DDS from Connext Drive)
CAN BUS
Test & Validation
Simulation
Adaptive Device
Adaptive Service
Figure 5: Connext Drive software for autonomous vehicles is built on data distribution service (DDS) middleware – which serves as part of the foundation for AUTomotive Open System ARchitecture (AUTOSAR) Adaptive and ROS2 software architectures. This is just one example of how DDS supports IoT software integration. Image source: Real-Time Innovations
we get technical
44
45
Powered by FlippingBook