Global Sources
EE Times-India
Stay in touch with EE Times India
EE Times-India > Networks

Direct-to-device connectivity in the IoT

Posted: 23 Jan 2014     Print Version  Bookmark and Share

Keywords:Internet of Things  IoT  FreeRTOS  peer to peer  P2P 

The term "Internet of Things" (IoT) is often used loosely. However, when strictly defined, it 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.)

Use cases
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 (internationalisation)
 • 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 (figure 1).

Figure 1: Architecture of a web device.

1 • 2 • 3 Next Page Last Page

Comment on "Direct-to-device connectivity in the..."
*  You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.


Go to top             Connect on Facebook      Follow us on Twitter      Follow us on Orkut

Back to Top