IoT project case study #1

This article is the first one of a series about project management in the field of Internet of Things. Every article, using a real-life project as an example, will exhibit a salient feedback from experience in managing such types of projects.

A first distinctive feature of IoT projects is that they require integration of technical blocks originating from three different domains: electronics, communications and software. And inside these three domains, various different subdomains are usually involved: analog and digital electronics, wireless communication modules, protocol stacks, embedded software, user interfaces, database management, analytics, geospatial data, etc.

There are many other fields where integration is far more complex. Just think about how difficult it can be to build a nuclear power plant! But with IoT, we usually talk about small projects (let's say with a workload less than 20 person-years[1]).

A second distinctive feature is the large number of totally different use cases. IoT encompasses smart cities (and what exactly is a smart city? ), energy management, environmental monitoring, building automation, home automation, fleet management, tracking systems, etc.

Many different use cases and several different technologies: no wonder that managing an IoT project can be a difficult task!

In this context, our first example illustrates the following point: beware of the black box syndrome.

Use case : uploading sensor data using a cellular network

In this example, a sensing equipment had to periodically upload a set of sensed data to a central system, using a GSM network in GPRS mode. The equipment was powered by a photovoltaic module and associated battery. Consequently, it was important for power consumption to be as low as possible.

The hardware design relied on a so-called "low power" cellular module, and a low-power microcontroller.

At a software point of view, the design team decided to store sensed data in CSV files, and to upload every file using FTP. Size of every file was around 10 KB.

Let's look at this in a detailed way.

CSV file

Firstly, a CSV file contains human-readable characters. Associated data uses more room than if it was stored in binary form. That's not such a big deal, for values that are usually coded on 2 bytes. For instance, 65000 uses 5 + 1 bytes (0x36 0x35 0x30 0x30 0x30 and the CSV separator, e.g. a semicolon), while 17 uses 2 + 1 bytes. But that's far more inefficient for fields like timestamps. Usually, a binary-coded timestamp requires only 4 bytes. In our example, it had been decided to use following ASCII format for timestamps:

dd/mm/yyyy hh:mm:ss+hh:mm

which is 25 + 1 byte long (more than 6 times the size of the binary version).

The planned overall CSV file line format was:

"00:1B:16:2D:4C:67";"11/02/2014 08:01:16+02:00";"112";"26023";"702";"2800";"3045";"21905";"1223";"64"

I don't know the domain of definition of every transmitted integer value. But let's consider that they are 2-byte (unsigned) integers. Consequently, storing the above line in binary format requires 6 + 4 + 8 x 2 = 26 bytes. Storing the line in ASCII format requires 101 bytes, plus an additional 1 or 2 character(s) (carriage return and / or linefeed). So, more than three times the number of binary format bytes!

Now, let's look at data semantics. Every line contains the address of the equipment, a timestamp, and sensed data. Compliance with usual CSV format requires that equipment address is present on every line. Using another (binary) format would allow to write it only once into the file. This would additionally decrease transfer size of (number of lines - 1) x 6.

Additionally, a simple compression scheme could be used for sensed data. For instance, differential values could be transmitted, after a first absolute value.

Why reducing data volume? Because the less you transmit data, the less you consume power. With GPRS, data throughput can be as low as 1000 bytes / s. For a 10 KB file, this means a minimum duration of 10 s (actually, additional time is required: see below).

FTP

Now, let's look at FTP. In usual conditions, FTP uses two TCP connections: one to control the FTP session, the other one to transmit data. A whole session looks like:

• open control connection
• wait for server acknowledge
• send username, wait for server acknowledge
• send password, wait for server acknowledge
• set transfer type, wait for server acknowledge
• open data connection
• send file
• terminate connections

As it can be seen, FTP protocol requires to wait for at least four acknowledges from remote side. For TCP, additional acknowledges are necessary, their exact number depending on parameter negociation and on file size. For GPRS, latency time can be around 1 s (almost the worst case). In our example, this means around 5 s just waiting for acknowledges.

Consequently, total communication time (data transmission and acknowledges) can be around 15 s.

If a binary protocol (even a very simple one) had been chosen, in order to reduce data volume and to minimize the number of downlink messages, communication time could have been reduced to around 3 or 4 s. And power consumption would have been reduced accordingly.

Conclusion

The design team was not bad at designing hardware. But they were naive beginners in the field of communication protocols. They had decided to use the FTP stack delivered with the communication module as a black box, without trying to understand the inner workings of the black box. And using it prevented them from thinking about how data was coded.

IoT project case study #2 - IoT project case study #3

Note

[1] This figure is not a strict one. I know of large companies where 20 person-years are not enough to build and deliver an IoT platform, while I know very small companies able to build and deliver a full tracking and monitoring system for urban bus fleets with around 5 person-years.