Earth Notes: IoT Launchpad Project Outcomes (2016)

The original IoT Launchpad high-level project summary was:

This project lowers the barrier to entry into the world of IoT for non-hardware specialists. Whether a Hoxton based software developer, London's transport operator or a DIY maker, by providing a cheap-as-chips, easy to use and open sensor platform, this project takes the hard work out of hardware. Commercially innovative in acknowledging the key role of commoditised hardware, OpenTRV will be the go-to supplier of expertise and integration services, plus solve the problem of security right from the start. It is technically innovative with modular sensors and plug in communications backhaul. The research will determine the optimum combination of sensors to detect footfall around bus stops in Tech City and beyond; similarly researching indoor sensors to reduce energy use and cut carbon emissions by finding the optimum combination for detecting presence inside buildings. This project bridges the gap between the Cambridge and London tech clusters, making IoT sensors usable by just about anyone, at low cost, and is an IoT market enabler.

A few of the principal results (as delivered hardware, software and other mechanics, plus public discussions posted on-line) are:

• findings at scales from home to city, in-building and out
• explored viable security schemes including key management from pairing, and sensor/actuator secure authenticated comms, to long-term blockchain non-repudiatability
• agreed and deployed to multiple environments a trivially extensible JSON data and archive/log format to allow robust rapid development and that is readily mechanically translatable (eg for Hypercat), archivable, unit-friendly, and partly self-documenting
• already supports various provisioning-friendly and comms-integrated elements such as globally-unique node IDs, data frame sequence numbers, and battery level
• prototyped automatic commissioning process with cloud data platforms
• shown adaptable to radio/comms channels with and without adequate security and short frames
• shown that it is possible to create single-file production-quality application (COHEAT) within simple and free Arduino IDE
• shown that it is possible to deploy securely beyond one-off lab conditions
• investigated multiple radio flavours in the field for pros and cons
• worked on interoperability (including a BCS-hosted workshop) with other players in this space such as Open Energy Monitor

This project was not to churn out a fully commercialised product, but to research and fill some of the key holes implied in the way there. As a particular example, the Sensor API should be tweaked and a few lines of boilerplate added for each sensor to allow run-time detection of which subset of supported devices is actually plugged in when the sensor unit powers up. But maybe more importantly the main JSON data format and implementation selected happily accepts a variable set of data in its payload and makes best use of the available comms, allowing runtime configuration at runtime, transparent to (as an important example) intermediate gateways.

Also, time did not allow exploration of such tech as SIMPL which would allow any residual run-time device configuration changes to avoid 'C' coding or recompilation, in the style of the old Sun Workstation FORTH Open Firmware boot system.

Some Specific Wins

Security (AES-GCM for MCU/IoT)

Security Code and Spec Release

Security seems to have been an afterthought or omitted altogether in many IoT efforts to date, maybe just seen as a 'cost' rather than a key feature. During this project OpenTRV developed and released a liberally-licensed open-source specification and microcontroller-friendly code base, and deployed it in the field in production.

In particular after much discussion AES-GCM seemed to be a good strong cipher that was designed to run on smaller microprocessors, and requiring minimal entropy once the secret keys were generated (entropy is often in short supply in low-power isolated devices). We were unable to find implementations suitable for an 8-bit microcontroller and with a licence that was open source and friendly for commercial and non-commercial uses. So we created the OTAESGCM library, initially with support for the Atmel ATMega AVR microcontroller, as found in the Arduino UNO (and OpenTRV V0p2 boards).

A secure frame format was devised taking advantage of the authentication and encryption features of AES-GCM, and able to to fit in the typical 64-byte frame buffer of common cheap radio modules from many manufacturers. The frame format also makes handling easier on common cross-module support for a leading length byte on transmitted frames. (Features such as CRCs and so on a much less standardised and inter-compatible.) The frame format only requires a few bytes of persistent counter data (typically 3--6 bytes) to provide high levels of security including replay resistance.

Liberally-licensed (Apache V2.0) secure comms spec and code:

1. IoT (AVR/MCU) friendly secure frame format specification V0.1.
2. OTAESGCM 1.0.0 AES-GCM crypto support.
3. OTRadioLink 1.0.0 radio and V0p2 board support.

Provisioning Small, Medium and Large Scale and Hypercat Support

Small Scale: Single Home

Our discussions noted that for the domestic or single-building scale, a system may be assembled ad-hoc over time with equipment from a number of retailers and manufacturers. There will not be any form of secure central provisioning.

Our conclusion is that pairing is likely to be the best method for devices that need to communicate and trust one another, being brought physically together and interactively building up a shared key (eg a symmetric secret key) using several channels (such as radio on its lowest power, light using device LEDs and phototransistors, and buttons, partially mediated by the human operator at least to initiate the process, to frustrate attempts by outside actors to interfere in or eavesdrop on key creation. Co-creating a 128-bit secret key for AES-GCM-based crypto can provide an almost uncrackable comms channel, though the nature of these retail/consumer devices means that physical access to or close to the device by determined actors may allow keys to be extracted; this is not meant to somehow be more secure than the house's front door, but should be one of the stronger links in the security chain to protect individuals' privacy and protect their systems from external tampering and spying, eg over radio.

See also: A comparative study of secure device pairing methods [kumar2009pairing].

Medium Scale: Campus / Estate

For (say) an office block or a cluster of homes on an estate, the organisation using the target IoT devices may not have the capability and sophistication (and financial clout) to run a fully centralised system. Management of keys (etc) may reduce to to a domestic-like pairing scheme, with some manual record keeping and management on top.

However, there is definitely scope to have (say) a base unit that can plug into all the units to be commissioned for (say) a single house, in turn or at once, with the unit synced with a central secure store on-site or off, to inject matching keys into the IoT devices and the data servers downstream. OpenTRV has developed such a scheme in-house, prototyped slightly inelegantly (but cheaply) on Raspberry Pis, to provision sets for trial, for example. In this case keys are generated off-device, and set in the device at run-time. Unique device IDs are self-generated from local entropy and can be changed though not set. (The option to set an ID was later added to allow easier replacement of devices in the field.)

Large Scale: City-wide or Larger

For the large scale, eg city-wide or larger with thousands upwards of sensors, provisioning (eg of firmware, security keys/credentials, deployment checklists to staff, etc) need to be fully automated and managed, and one element of that is the run-time management (and live upgrading) of equipment on the scale managed by, for example, cable TV companies and major ISPs (Internet Service Providers) of their devices such as routers.

We delivered a prototype for automatic provisioning of equipment driven by a data platform such as EnergyDeck and inspired by the TR-069 standard. As part of this work, we also delivered:

• A simple implementation of the SenML payload format in Python.
• A demonstration implementation of an IoT data platform using Flask and Python that supports the mandatory parts of the Hypercat protocol.

Preparing OpenTRV for Commercialisation

The project aim was to make putting together an IoT solution for software developers as easy as stacking a bunch of plastic bricks.

We did not get all the way there, but the sensor hardware is pluggable, many different radios are pluggable including GSM, LoRa and generic ISM, the drivers have consistent run-time (Sensor/Actuator) interfaces (though do not yet explicitly do boot-time detection of device attachment), and it is possible to build a commercial-strength third-party application on our infrastructure with relatively little baggage from OpenTRV's main smart valve target, as demonstrated with the COHEAT deployment.

Though it is often going to be cost-effective to integrate an entire IoT sensor into a single PCB, we demonstrated use of our I2CEXT connector(s) to build an example board stack for the Launchpad final workshop, and it really was simple to do.

In summary, the modularity is fairly close to that needed for commercialisation (sensor device detection at power-on would be a useful usability step), and we have already had multiple discussion with various sizes of potential partner for standalone projects based on this completely open hardware and software stack.

Radio Backhaul for Small, Medium and Large Scale

The project has shown that the proposed comms architecture can be delivered in a number of ways at scales from domestic to city, and not tied to any particular radio hardware or channel, and that the comms can be secured entirely in software on small IoT-appropriate microcontrollers. In other words, the pluggable radio element of our stack of bricks works.

Telemetry frames have been delivered over different carrier variants in the 868MHz ISM band (EU band 48), and over LoRa (also 868MHz), and over GSM (cellular).

In particular there is a library of radio modules with a common interface which can be used partially interchangeably, with run-time settable channels where appropriate, and a notion of a primary radio interface (eg for communications with local peers) and a secondary radio interface (eg for relaying across backhaul).

Small: Domestic

Some important lessons included that at the domestic scale, ISM does usually 'just work' and low-power (microwatts average) narrow-band battery-powered sensor/transmitters are not rocket science and with care can be made cheaply and easily, and inherent error rates can be astonishingly low (with a 7-bit CRC our OOK channel in a domestic setting has an undetected error rate of the magnitude of 1 per 100k frames or a few per year (~5/500k/y in one data set), in dense non-redundant binary frames).

A typical use is transmission of sensor measurements and stats from a smart radiator valve back to a boiler control and/or Internet gateway. These transmissions can be secured in software, ie without depending on specific radio support.

Medium: Campus

At the campus scale the fact that ISM transmissions even at powers far below the maximum permitted (~10mW) and with unsophisticated whip or PCB trace antennae, can reach 10s or 100s of metres means that channel saturation can become a serious issue effectively becoming an Aloha network (unslotted for our channel style) and multiple channels and/or TX power control and/or campus-wide management of the channel space may all be useful. Though only simple narrow-band schemes were deployed for our campus-level work, LoRa would certainly be a contender here.

In the end the COHEAT deployment was vastly improved (raising successful sensor readings per day nearly five-fold for example) by separating traffic into two channels (supported by the same radio), and with the new channel being much faster (~x10) and more robust (FSK vs OOK), as well as some clever adaptive transmission controls by COHEAT to make the new channel effectively 'slotted', prioritised, and adapting to best available radio performance between sensors and hubs. In short, without any hardware changes, more clever use of the radios given the particular environment was able to make a very significant difference.

Large: City-wide

At the city-scale, at least in London in central areas, boring old 2G GSM is pretty solid, though simple use is slow and power-hungry (watts vs microwatts), and tariffs can be mind-bogglingly silly (charging every packet as if a minimum of 1kByte is totally out of touch with IoT). Still, many urban sites have mains available (eg most London bus shelters) so power need not be a bar, and there are plenty of bandwidth providers to choose from below the big telcos, some of whom at least are helpful and in this century.

The interesting case is LoRa: so new that the firmware was broken on the early modules that we were shipped, and we brought up the first base stations in London (made available also through The Things Network). So we had to spend rather more time on assessing range and antenna style and workable maximum frame lengths than we'd have liked, and did not manage to get power consumption to the levels we achieve for the domestic/campus scale before the end of the project, though there is no reason to believe that all that is achievable with a bit more experience in the field. We found that the sensor/transmitter units could be placed into all sorts of street furniture voids (eg bus timetable, London Landmark eaves and seats) with similar performance even when some of then looked unpromisingly like Faraday cages.

LoRa: 'Free' not yet quite 'Free'

What seemed more important for LoRa was placement of the base-station antennae. The mast on top of the Digital Catapult on 101 Euston Road seemed to get a range of nearly a mile, eg just about to Angel, and did not require line of site to work, at least once we'd improved transmitter antennae and reduced frame size and increased 'spreading factor'. Astonishingly good for the roiling sea of radio noise that might be expected of urban 868MHz. However, putting a second base station antenna on a windowsill in an office on Great Eastern Street barely got us to the other end of the road. So LoRa is not magic and the need for good sites with overlapping ~1.5km reach may mean that the 'free' LoRa backhaul may for now cost too much in infrastructure management for, for example, a transport operator to manage itself, though outsourcing to a nimble small telco could work, especially if the end user has a large number of potential sites for base stations (eg on buildings and existing street furniture with power).

Secure and Small

As part of the project small (non-secure) frames ranging from a few bytes of payload, up to a strongly-secure authenticated and partly-encrypted securable frame format fitting into 64 bytes or less, were specified and implemented entirely in software in microcontrollers on the domestic and campus scales, and even gatewayed onto GSM backhaul. For LoRa we did not use our own encryption layer, partly because LoRa has end-to-end encryption built in if needed, but also because it became evident that longer encrypted frames would be difficult to transmit reliably, and some tweaks to reduce frame size would be helpful (being able to send 16-byte encrypted payloads rather than 32-byte) but were not implemented by the end of the project.

The securable frames have been deployed both with COHEAT and relayed over a GSM backhaul for a housing trial with full and partial implementations in C/C++, Java and Python.

Interoperability from Radio Agnostic to JSON and Beyond

A very important part of our design process is to avoid being tied to single-source parts or the specifics of one contingent item of hardware or software (though then do exploit the detail for optimisation once there).

By design, for example, OpenTRV over-the-air and logging data structures, integrity checking, and even authentication and encryption, avoid relying on features (especially proprietary) of particular CPUs and radios, as those are rarely interoperable and have all the dangers of single-sourcing.

Thus the default data format is JSON, with UCUM-style units where possible to enable rapid development, partial self-documentation, and the ability for all points between data source and final consumer to be agnostic as to detailed content. There is some departure from UCUM for brevity. Binary forms can be used in parallel for compactness, or where the decoding device is itself 'small', and the two can be combined in a single data frame; this combination has worked well in production systems.

The JSON subset used is compact and portable, ie ASCII 7-bit printable only with no excess whitespace over the air, with the usual form being a JSON object/map "{...}", ie name/value pairs. Those values are usually simple (small ~16-bit signed) integers, or strings, though small arrays are nominally in scope, eg for vectors of temperature measurements.

A sample of JSON in logging form; the final map in each line is the form sent by each sensor:

[ "2016-05-27T11:16:01Z", "", {"@":"3015","+":7,"v|%":0,"tT|C":6,"tS|C":0} ]
[ "2016-05-27T11:16:52Z", "", {"@":"2d1a","+":4,"L":168,"v|%":0,"tT|C":14} ]
[ "2016-05-27T11:17:13Z", "", {"@":"0d49","+":1,"v|%":0,"tT|C":6,"vC|%":646} ]
[ "2016-05-27T11:18:13Z", "", {"@":"0d49","+":2,"T|C16":311,"O":1,"vac|h":4} ]
[ "2016-05-27T11:18:18Z", "", {"@":"414a","+":1,"tT|C":12,"tS|C":4,"T|C16":307} ]
[ "2016-05-27T11:18:46Z", "", {"@":"b6d9","+":0,"vac|h":4,"B|cV":245,"L":176} ]
[ "2016-05-27T11:19:03Z", "", {"@":"819c","T|C16":296,"L":246,"B|cV":253} ]
[ "2016-05-27T11:19:13Z", "", {"@":"0d49","+":3,"B|cV":259,"L":236,"v|%":0,"tT|C":6} ]
[ "2016-05-27T11:19:55Z", "", {"@":"3015","+":0,"vC|%":1590,"T|C16":327,"H|%":50} ]
[ "2016-05-27T11:20:57Z", "", {"@":"2d1a","+":5,"T|C16":340,"O":1,"vac|h":1,"b":0} ]

A couple of simple features are used to greatly increase usability in an IoT environment:

• A device unique ID prefix (from a full 8-byte globally-unique ID), with a "@" label.
• A simple sequence numbering of transmitted data, eg sensor readings, to make it easy to detect data loss, eg from radio issues, with a "+" label.

For the radios we assume only that it is possible to send a frame of up to 64 bytes (preferably whitened in some way), which many cheap devices can, and take advantage of the very common feature of a leading length byte where the radio supports it directly.

In contrast, radio addressing, checksums and encryption features are not at all portable/interoperable, and OpenTRV infrastructure does not depend on those, providing checksums and crypto (with well-understood widely used algorithms) in software that even IoT-friendly small MCU (microcontrollers) can handle.

The aim is always to make the basics of communication and integrity agnostic to the underlying hardware at least, to provide ease of development and keep hardware, software and development costs down.

Final Workshop

In our final workshop, 2016-03-21, at the Digital Catapult in London and part sponsored by RS Components, we shared some of our LoRa experience and software and hardware environment:

OpenTRV and the Digital Catapult present the Internet of Things and The Things Network Workshop

Recently the Digital Catapult and OpenTRV placed London's first open gateway for The Things Network http://thethingsnetwork.org on the roof of the Digital Catapult Centre at 101 Euston Road. With this low power, wide area network now available temporarily to use within a radius of one to two kilometres, the centre is hosting a workshop on 21st March 2-5pm to help you get started.

There will be three streams:

1. Connect a node to The Things Network using an Arduino with a LoRa Arduino shield. Andrew Lindsay from Thing Innovations will take you through setting up the shield, programming the node and receiving your data back from The Things Network. Participants should bring their own laptop, Arduino and USB cable and have the Arduino IDE installed. Your Arduino shield will be yours to take home.
2. Connect a self-contained sensor to The Things Network with an OpenTRV battery powered sensor, led by Damon Hart-Davis from OpenTRV. You will configure your installation of the Arduino IDE to program the self-contained sensor, instruct it to connect the The Things Network and extract your data back out of The Things Network for display. Participants should bring their own laptop with the Arduino IDE and serial cable drivers pre installed where necessary (http://www.ftdichip.com/Drivers/VCP.htm). Your self-contained sensor will be yours to take home.
3. Participate in a co-design and coding session with the Digital Catapult and Camden Council facilitated by Peter Karney from the Digital Catapult Centre and Bruno Girin from EnergyDeck. Using data from sensors located in the Camden Council offices, you will take part in understanding the data available and developing visualisations and solutions to assist with problems identified in social housing, such as condensation build up and mould growth. You will take home an OpenTRV self-contained sensor, pre-configured to connect to The Things Network. (This also included user research with Camden on what problems could technologies like OpenTRV and EnergyDeck solve for them, in particular around tenant well-being. This is complemented by user research done with EnergyDeck customers and partners on health and well-being, both in commercial and social housing contexts.)

Carson Thompson, Team Manager, Quality Assurance from Camden Council will attend and ensure that the outcomes are focused on real world problems. The results will be evaluated by the council with a possibility to test in council run buildings later this year.

Code and Other Specification Release

V1.0.0 code release of the key components at the end of the project:

1. OTProtocolCC 1.0.0 COHEAT protocol support.
2. OTAESGCM 1.0.0 AES-GCM crypto support.
3. OTRadioLink 1.0.0 radio and V0p2 board support.
4. OpenTRV 1.0.0 release against underlying libraries.

Other key specification releases were:

• IoT (AVR/MCU) friendly secure frame format specification V0.1.
• I2CEXT connector original and larger versions.
• Internal: our release procedure and numbering scheme.

Thanks

Thanks are due to many organisations and people for helping with this project including: EnergyDeck, IBM, TfL, RS, Digital Catapult. Also OpenTRV open source contributors, such as but not only, Mike S, Gary G, Matthew W, Jeremy Poulter of BigJungle Ltd.