Today the “Internet of Things” is one of the hot topics in the industry. Every day, new IoT-enabled products are presented and IoT is now an acronym as popular as WWW was. Someone even joked about the fact that we may expect to see an “IoT-enabled resistor” coming out any time soon, and every week we read new studies that talk about billions (and even trillions) of connected devices that will exist in a few years from today.

But what is the IoT about?

Dissecting the Internet of Things
In my opinion, we need to understand the entities included in this definition. Let’s start with “Things.” For an embedded developer, it’s easy to identify them with embedded devices and I think it’s correct to do so. Included in this definition are small microcontroller-based devices as well as more complex devices running a full-featured operating system.

So is the “Internet of Things” just about connecting devices to the Internet?

I don’t think so. It would be like defining the Internet as PCs, tablets, and smartphones connected to a TCP/IP based network; we would be missing an important part of it.

We already have many connected devices. Multiple studies evaluate that, since 2008, there are more devices than people connected to the Internet, but the IoT is still far from being a reality in our daily routine.

The Internet has evolved in recent years, moving from the static “email and web page” model at the beginning of the World Wide Web revolution to the huge and sometimes useful mix of information and services (and cat videos) we have today.

In the same way, connected devices will need to evolve, to interoperate, and to share and access information before we can really live in the “Internet of Things” era.

The “Internet” side of IoT is about processing the huge amount of data that can be collected by devices and extract the useful bit of information that can improve the way we use many services and devices today. This may sound like finding a needle in a haystack, but the good news is that with cloud computing we have the processing power we need to filter many haystacks per second.

An “IoT device” can’t exist (it will be just a “thing”), but we can design a device that is part of an IoT solution. The device will no longer be “the product,” but will be part of a larger project involving services that add value to it.

We also have processing power on devices, and IoT doesn’t mean that all the processing must be done in the cloud, but, on the other side, having a full vision of the ensemble of devices can be very useful to make more informed and more efficient decisions.

The Internet of Things for automotive and traffic systems
Let’s think about traffic. A single vehicle can know the road network and get information about traffic jams, roadwork, etc., but it only knows its own destination. A management system that can collect information from multiple vehicles that know where they are and where they want to go can give optimized directions, allowing people to avoid existing traffic jams and to not create new ones in the process. In this case having a connected system can really improve the way people drive. Of course this is not currently possible; most of navigation systems aren’t connected and those that have connectivity use different protocols. But it’s already possible to do some specific implementations to optimize, for example, public transportation.

This process will have to overcome big challenges.

Implementation challenges
Interoperability is definitely one of them, but also legitimate concerns about security and privacy from people who may not like the idea of unauthorized access to information that can be even more personal than the information stored on PCs, phones, and tablets.

And there is also a major design challenge: changing the perspective from device to solution. A product will include hardware, local software, and services. Some requirements will not change – we will still need reliable hardware and productive development tools – but other requirements will be added to the mix.

As embedded developers we will face new challenges, having to think about our software as part of a more complex solution. We will need to have a vision of how the whole system operates, from bits collected from sensors to how this data is stored and processed in the cloud to the actions it generates on devices as feedback.

Pretending that designing an IoT system does not change the way we work, just focusing on embedded software, and considering connectivity only as one of the features will limit our impact on projects.

Designing with connectivity in mind

Devices (Things) will have to interact with a back-end (Internet) to perform different activities:

• Provide data (telemetry)
• Require data or actions from the backend (inquiries)
• Perform operations required from the backend (commands)
• Receive information from the backend or other devices (notifications)

Those patterns and the challenges of connecting a device to an Internet service are clearly described in an MSDN article from Clemens Vasters entitled “Service assisted communication for connected devices.”

As we have many different vendors for the hardware and software we use to build embedded devices, we also have different providers for the “Internet” side of IoT. Companies like Microsoft, Amazon, and Google are fighting to provide cloud-based services to a wide audience of companies and developers. Many of those services can be used to build an IoT system.

Those services can collect, store, and process the data acquired by devices and make good use of the information extracted from it. We can also use “traditional” in-house servers, but the requirements for scalability and reliability for many of those projects make the cloud-based approach a natural solution.

I’ll focus on Microsoft solutions, but most of the concepts will apply also to other vendors.

Microsoft provides a full range of products, ranging from operating systems targeted to embedded devices (.NET Microframework, the Windows Embedded Compact and Standard product lines and the new Windows Developer Program for IoT) to cloud-based services based on its Azure platform.

This will let developers use a consistent set of tools and programming languages on the different components of the IoT system. On the other side, Microsoft releases SDKs for different operating systems and languages, allowing the creation of a system composed by devices running different operating systems (or no OS at all).

Azure provides a messaging system called Service Bus. Using messages, instead of the request-response mechanism used by web APIs, allows services to process information in an asynchronous way. This leads to better scalability and improved reliability. Peaks in the number of requests can be processed without disrupting the service and, as soon as a message is delivered to the Service Bus, the device can even disconnect itself from the network, not having to wait for processing.

All the communication patterns we need for IoT can be implemented using messaging. Devices can connect directly to the Service Bus using Advanced Message Queuing Protocol (AMQP) or the HTTPS. The former protocol was designed for messaging, packs information in binary format, and usually leads to lower bandwidth usage. Other messaging protocols like MQTT (common on low-resources devices that can’t support the additional cryptography and security features required by AMQP and HTTPS) and CoAP can be integrated using a protocol adapter like the one Microsoft itself implemented for project Reykjavik (Azure Device Gateway).

Leveraging existing open source implementation of those protocols and the SDKs provided by Microsoft will simplify the development of the communication between devices and the back-end service and let developers focus on the parts of the implementation that add value to the whole solution.

IoT learning resources
There are many resources that can be useful for embedded developers who want to understand what IoT means outside of all the marketing noise.

I suggest starting with Clemens Vaster’s videos on Channel 9, which provide both a good architectural overview and some interesting samples. They focus on Azure, but many of the concepts are generic and can be applied to different platforms.

A few weeks ago, my friend Paolo Patierno and I had the chance to talk about IoT at a very popular Italian developer conference, Community Days. As an embedded developer, it is interesting to have a chance to exchange ideas with developers working on different kinds of projects, and the IoT will increase chances to mix different experiences ranging from low-level firmware development to Big Data processing using cloud services.

You can download slides and code samples from the event website if you want to see how some IoT-related features can be implemented on the Microsoft Windows Embedded Compact platform. The website is in Italian but slides and code comments are in English.

Our samples are a mix of native C code and managed C# code and use both MQTT (using the M2MQTT open source library) and AMQP (using AMQP.NET lite) to communicate with a cloud-based service.

Valter Minute is an Embedded Software Engineer at Toradex.