Embedding Cloud Connectivity in Edge Nodes

Bringing intelligence and connectivity to the edge of the network requires OEMs to change their point of view when it comes to product design, writes Witekio’s CEO, Yannick Chammings If the typewriter shaped the modern office, the PC reshaped it. Similarly, the embedded industry is being redefined by the IoT; it is no longer enough to create a device that provides functionality without connectivity. And increasingly that includes connecting to cloud-based services that can extend functionality, provide remote access and feed into the Big Data paradigm. Adding connectivity to a device isn’t difficult, semiconductor device manufacturers have almost made it ‘Plug & Play’ by offering a wide range of single-chip or modular solutions covering almost all wired or wireless protocols. More recently this level of connectivity is already fully integrated into the microcontroller at the heart of an embedded system. What is perhaps more challenging is developing a product that seamlessly integrates into the infrastructure; a task that is becoming increasingly defined by the requirements and technologies more commonly found in the IT world. Marrying IT-centric technologies with the resource constraints of embedded devices isn’t without pain but it is necessary in order to maximise the data available from the billions of IoT nodes expected to be deployed over the next five years or so. And it will be in these nodes where Little Data becomes Big Data. From the wider IoT point of view, Little Data is anything that can be measured on a local level, while Big Data is the conglomeration of individual data points into a common set for deeper analysis. It is this Big Data that many are keen to exploit and while Little Data isn’t exactly a by-product, it is arguably of less global value. However, without Little Data there would be no IoT. Connected devices must therefore be developed from a data-centric viewpoint; they will need to consider how the data will be collected, what form it takes, how it will be securely and reliably passed to the Cloud, and how it will be managed (stored, shared, accessed) in the Cloud. Far from being an IT problem, it is OEMs in the embedded domain that will need to build these features into smart devices. Let’s get connected Connectivity in the IoT will be less about USB and CAN, and more about Ethernet. In short, it will be based on Internet Protocols and technologies developed to support the web, but not as we know it. OEMs may be comfortable with connectivity at a local level, but networking introduces new considerations, such as which protocols to employ. In the IT world, where resources are less constrained, such choices are less relevant but in the IoT it will be dictated by several aspects. Firstly, what kind of protocol is most appropriate for the data or application in question. There are a growing number of protocols being developed (or ported from the IT world) to support the IoT and these come with features that may not have previously been important in the embedded domain. This is illustrated by mDNS (multicast Domain Name System), which effectively allows small systems to resolve IP addresses where no DNS server is present. As such it can provide an important building block for networks comprising small nodes that need to be discoverable and addressable by a more conventional element, such as a router. It is also likely that the node will need to be accessible directly over the IP-based network connection, and so will need to support a protocol such as IPv6, UDP or TCP/IP. However, these protocols can be considered ‘heavy’ for small (microcontroller-based) devices, so new lighter versions are now emerging. This includes NanoIP (a version of TCP/IP with lower overhead) and lwIP (Lightweight IP), an open source TCP/IP stack developed for embedded systems, adopted and supported by a range of semiconductor vendors offering microcontrollers capable of running an RTOS (a prerequisite for lwIP). There are also protocols being developed specifically to meet the needs of the IoT, such as TSMP (Time Synchronised Mesh Protocol) for self-organising WSNs (Wireless Sensor Networks) and MQTT-SN (Message Queueing Telemetry Transport - Sensor Networks). The latter is an optimised version of the lightweight messaging protocol, MQTT (which runs over TCP/IP) for sensor network systems that don’t use TCP/IP. CoAP (Constrained Application Protocol) can be supported by most devices able to run UDPOne of the main protocols that helped build the Internet is HTTP but this can also be considered too ‘heavy’ for an embedded system. HTTP is based on the REST model (Representational State Transfer), which has significant synergy with the needs of the IoT, so to preserve this without adding the overhead of HTTP, the Internet Engineering Task Force Constrained RESTful Environments Working Group has driven the development of CoAP (Constrained Application Protocol), which can be supported by most devices able to run UDP. Stay secure It is undeniable that taking connectivity to the next level in order to support a cloud-based infrastructure requires adoption of new and often optimised protocols, but it should not be assumed that they also provide the necessary level of security ‘out of the box’. Including security is no longer an option for embedded device developers, but how and where it is applied needs careful consideration. This is apparent by the fact that the MQTT protocol is perfectly happy transmitting usernames and passwords in plain text; the organisation behind MQTT recommends using Secure Socket Layer (SSL) technology, but acknowledges that SSL isn’t ‘lightweight’ enough for many resource-constrained devices. Similarly, the Lightweight Local Automation Protocol (LLAP) is a simple text-based protocol. It would be extremely ill-advised to exchange messages between cloud-based services and an edge node without using some form of encryption. In terms of cloud communication and accessing data located in cloud-based servers, the technology many are turning to is JSON (JavaScript Object Notation). This is described as being agnostic towards database schemas and so can provide a common platform for the disparate devices that will comprise the IoT. Its main strength is that JSON messages from different devices needn’t be formatted in the same way, making interoperability and extensibility much simpler. However, it too uses a plain text, unencrypted message format and so it would still be necessary to employ encryption at some other level. The security of IoT wireless protocols like Thread should be carefully evaluated at the design stage   Wireless communication protocols based on standards including ZigBee and more recently Thread, Sigfox and Neul, offer varying levels of ‘baked in’ security, which should also be evaluated at the design stage. Often the security level is configurable, with defaults sometimes being no security at all. Conclusion The IoT isn’t just about making devices ‘smarter’, it is about bringing cloud-based services out to the edge of the network. The edge used to be the PC sitting on a desk, but now it could just as easily be the lamp sitting next to the monitor, the lock on the door or even the coat hook. Putting intelligence into everyday objects is all about collecting information; data that can be used locally and globally. Big Data is the process of finding meaning in chaos, while Little Data is already being used in home automation and managing our personal environment. But all of the data, and the real intelligence behind it, sits in the cloud. OEMs should embrace this opportunity to become part of the future, by adopting a cloud-centric approach to device development. Bridging the gap between the embedded domain and the IT infrastructure is really where the cloud begins. Its potential, however, is unlimited.