Direct-to-device connectivity in the Internet of Things
Although the term is often applied loosely, “Internet of Things” (IoT), strictly defined, refers to embedded devices that communicate over or are accessible over a network via the Internet.Protocol. In this article IoT ‘solutions’ and IoT ‘architectures’ refer to networking infrastructure, topologies, or technologies that enable embedded devices to connect to the Internet of Things.
As with all embedded designs, adding IoT connectivity should be chosen to meet specific application requirements. Not all applications pose the same challenges, so different architectures have been proposed, created, and deployed. In this article I will briefly describe then discuss three contrasting IoT architectures in which FreeRTOS has been used by developers. The three architectures are a traditional ‘web server device’, a ‘virtual cloud device’, and a “peer to peer” direct-to-device configuration. These are just three architectures of many that could have been chosen (including some that are hybrids of these three).
For those more familiar with the traditional approaches to IoT connectivity using web and cloud devices, the term peer to peer (P2P) is used here to describe an architecture that creates a two way command and data connection directly with the deployed IoT device, hence the term ‘Direct to Device’. Nabto is an example of a peer to peer architecture. Nabto uses FreeRTOS to provide a common run time environment across all embedded platforms to take advantage of its low power, tickless operation.)
Very broadly speaking, there are three base IoT use case categories:
Data monitoring and acquisition. Examples of this type of use would include a haulage firm monitoring the positions of its trucks as the trucks move around the country, a production company monitoring the number of parts made, a vehicle insurance company logging the driving habits of its customers, or a maintenance company monitoring performance attributes of deployed equipment in order to predict potential failures before they occur.
The provision of a control interface. Examples of this type of use would include the ability to remotely open or close animal feed troughs on a farm, remotely vary the speed of a pump in a drainage system, remotely switch the part being produced by a production line, or simply to open or close a window. Control interfaces can be driven programmatically by a centralized supervisory and control computer system, or manually by users.
The provision of a graphical user interface (GUI). A GUI provides an interface for users using an IoT device for use case 1 or 2 above. Often a GUI is required to display different screens to different categories of user. For example, remote maintenance technicians (or even accountants) might have access to screens and data that are inaccessible to local operators.
Different use cases bring with them different challenges, and are therefore best serviced by differing IoT architectures. A use case may need to ensure that nodes on the IoT can:
- Be uniquely identified and located, potentially named, and allocated an IP address
- Be accessed when deployed behind a customer’s network firewall
- Operate in the absence of the Internet, particularly during equipment commissioning
- Be used from different geographic regions, which may require language, currency, or measurement unit conversions (internationalization)
- Only be accessed by authenticated users, or only send their data to authenticated servers
- Ensure data passing across the Internet is securely encrypted
- Ensure data stores and databases are secure and private (who owns the data?)
- Ensure the integrity of all exchanged data and commands
- Dynamically change the data that is being acquired, the rate at which the data is being acquired, or where acquired data is being sent
- Dynamically change the number of connections or data flows
- Be integrated easily, and used easily
- Be cost effective
Architecture 1: Web devices
In this article the term web device refers to a traditional embedded TCP/IP web server, as shown in Figure 1.
This approach has been used for years, and for good reasons. The Web Device approach was especially in focus at the time when IoT was envisioned to be a home-automation-gateway that coordinated a lot of smaller devices inside the home. Its major advantages include:
- It uses familiar technologies
- It is completely self-contained, with no reliance on a cloud service
- CGI (and other server side) scripts can provide a very powerful control interface
The inclusion of a simple FTP or TFTP server will allow the web pages and scripts to be updated after deployment (but note that each deployed device must be connected to then updated individually). However, despite these points in its favor, a quick re-read of the IoT challenges stated above shows the traditional web device is only suited to a small subset of potential use cases. It would take too long to go through each point in turn, but the following points are worth highlighting:
- The embedded firmware has a lot of interface layers and is therefore complex. Examples of the layers that must be provided include TCP/IP, HTTP parser, CGI script execution, template generation, and file systems.
- Even quite simple web interfaces require a lot of HTML logic, and hence computing time, memory resources, and high bandwidth.
- Deploying a web device on a standard network that includes a DHCP server (dynamic assignment of IP addresses) and a firewall can require specific rules to be set up in the end user’s router in order to make the web device accessible.
- Reaching the web device from outside of a firewall requires a VPN, port-forwarding, dynamic DNS, or a combination of such technologies. These are complex technologies for everyday users.
Currently no items