Using IoT and digital canaries to improve health
The Internet of Things (IoT) is the idea that everyday objects are embedded with sensors, software, and wireless connectivity to collect data about themselves and their environment. In this blog post, we describe how we used IoT technology to enable a digital transformation for one of our customers in order to improve the health of people in workplaces.
Modern canary in the coal mine
Our customer IDEWE is an external service for prevention and protection at work. The organization is fully committed to improving the working climate for its clients. To help IDEWE in its goal, we’ve built them an application that helps with external exposure assessment. This application, based on IoT, gathers data from sensors at different locations to visualize long-term measurements and the effects of taken actions. A solution was needed that allowed non-intrusive placement of sensors over a period of time and could display measurements in a dashboard without much configuration.
With this application, IDEWE is able to go from discrete measurements to continuous monitoring and formulating recommendations to improve people's health in real-time. How exactly? IDEWE uses a device called Little Lilly in the shape of a yellow bird. Using sensors, the Little Lilly is able to gather CO₂, temperature, relative humidity and Volatile Toxic Organic Compounds (VTOC). The little bird also features an indicator light to indicate low (green) or high (red) CO₂ levels. The device's form factor is a nod to the canaries used in coal mines to warn miners of decreasing air quality.
Our application collects the data from Little Lillies and visualizes that data in a dashboard filtered by location, period or sensor. If any actions are taken, e.g. opening a window or turning on the A/C when a Little Lilly reports a high CO₂ concentration, they are displayed in the dashboard as well. That way, users can immediately see what effect those actions had on the measurements.
The remainder of the blog describes how to securely ingest the telemetry data from IoT devices (Little Lillies) into a data platform with the necessary analytics dashboards for IDEWE to use.
MQTT as a lightweight communication protocol
In some situations where (IoT) devices are used, the communication channels or networks are unreliable and reliable communication is still required. For example, a car with sensors could drive through a tunnel and temporarily lose connection. Typically, IoT devices are small and resource-constrained, which implies the need for a very lightweight communication protocol.
For these reasons, MQTT is used as communication protocol. It is an OASIS standard messaging protocol for IoT and is designed as a lightweight publish/subscribe messaging transport to enable small devices with low network bandwidth and resources. MQTT scales to millions of devices. With persistent sessions and quality of service levels, MQTT supports reliable message delivery for unreliable networks. The solution is a protocol on top of TCP and is independent of the type of network used (Wi-Fi, 4G/5G, LoRaWAN, ...).
The following picture illustrates how MQTT makes use of a broker to facilitate publish/subscribe communication. Note that this MQTT broker should not become the single point of failure and needs to be highly available and scalable. For our project at IDEWE, we used the Google IoT Core solution, which has a fully managed MQTT broker out-of-the-box to address these requirements. IoT Core runs on Google’s serverless infrastructure, which scales automatically in response to real-time changes.
Security is crucial
With more and more data being collected every day and more devices present in our daily lives, the topic of security is more important than ever when designing an IoT solution:
- IoT devices are spread in all sorts of uncontrolled environments in the field, which makes them vulnerable for attacks.
- IoT devices sense a wide range of telemetry in people's cars, homes, working environments or even the public space. Some of this data is not meant for public eyes and should be protected as sensitive data.
- Data leaks risk serious damage to the reputation of the affected companies.
Security is always a matter of introducing security measures at different levels to make it as difficult as possible for an attack to succeed. There are three levels on which an IoT solution can be secured:
- Network Level: One way to provide a secure and trustworthy connection is to use a physically secure network or VPN for all communication between clients and brokers. This solution is suitable for gateway applications where the gateway is connected to devices on one side and with the MQTT broker on the other side. However, in a more public setting, a physically secure network or VPN is not always an option. In that case, the other levels of security are crucial.
- Transport Level: When confidentiality is the primary goal, TLS/SSL is commonly used for transport encryption. This method is a secure and proven way to make sure data can't be read or tampered with during transmission. Moreover, it provides client-certificate authentication to verify the identity of both sides.
- Application Level: On the transport level, communication is encrypted and identities are authenticated. The MQTT protocol provides a client identifier and username/password credentials to authenticate devices on the application level as well. These properties are provided by the protocol itself. Authorization or control of what each device is allowed to do is defined by the specific broker implementation.
With the MQTT protocol, both the transport-level encryption, and the application level authentication using protocols such as OAuth can be applied. More specifically, when using the Google IoT Core MQTT broker, it is required to encrypt all communication using TLS, authenticate clients using mutual TLS certificates, and with every communication authenticate using a valid JWT token that is signed by the correct certificate. Furthermore, only devices known to IoT Core's device manager and bound to a gateway (if used) are allowed to publish their telemetry data.
This results in a highly secure IoT environment to get telemetry data from the edge into the cloud.
Standardize protocols and message formats to enjoy flexibility
Being able to try out multiple types of devices and communication network technologies is key when designing and evolving an IoT solution. Devices evolve constantly. Not being stuck with a specific kind allows you to keep up with the new possibilities or integrate existing legacy devices when needed. Some types of devices and/or network technologies might work perfectly in specific environments, but don’t work in other environments. For example: in office environments, there might be Wi-Fi connection or 4G/5G, but in remote areas this might not be the case. Network technologies geared towards longer ranges, such as LoRaWAN are then necessary. LoRaWAN allows a single device to communicate across 10-20 km (world record is even set to 700 km). In other cases, some devices might also not have enough power to use Wi-Fi or 4G/5G. In these cases, LoRaWAN networks can also help, as they require very low power consumption when communicating. For legacy devices using very old or proprietary communication technology, a combination of devices and a gateway that supports this technology might be needed. The gateway is then responsible to adapt to a more standard protocol like MQTT.
For the Little Lilly project at IDEWE, we only standardized the communication protocol and message format being ingested. We kept full flexibility regarding the device type and network technology, as long as MQTT is used and an agreed upon message structure. An example message format is given below:
{
"version": "2.0.0",
"deviceId": "Li074726",
"timestampEpoch": "1643100924.268599987",
"timestampUtc": "2022-01-25T08:55:24.268600Z",
"metrics": [
{
"name": "co2",
"value": 805,
"unit": "ppm"
},
{
"name": "temperature",
"value": 78,
"unit": "celsius"
},
{
"name": "humidity",
"value": 29,
"unit": "percent"
},
{
"name": "tvoc",
"value": 78,
"unit": "ppb"
}
]
}Note that this is a simple example. Depending on the use cases you want to support, a more advanced format might be advised. This example telemetry message contains the reported CO₂ value, the timestamp when it was measured, and an identifier to know where or on which Little Lilly device it was measured.
In addition to the actual message format, MQTT also requires a topic to publish messages to. The way topics are structured is called a topic namespace. This topic namespace also needs to be part of the agreed upon structure. For example, when using Google IoT Core, a device can publish its telemetry data to a topic with structure `/devices/Li074715/events` and its state data to a topic with structure `/devices/Li074715/state`. Google does not impose any message format structure itself.
Transform your business insights and services by combining IoT telemetry with other enterprise data
A pure IoT solution allows you to put IoT devices everywhere and sense for example the current CO₂ levels by subscribing with a mobile device to the MQTT broker. If we stop there, then we are not realizing the full potential of IoT. A next step is to get insights into the evolution over time of these measurements. For this, we need to persist and get access to the history of CO₂ measurements.
MQTT is lightweight and designed for high scalability. For that reason, it does not offer a durable persistence of the MQTT messages, but directly pushes the messages to subscribed consumers of this data. Only a limited buffer is supported to have reliable communication.
Google IoT Core solves this with an MQTT bridge, which automatically publishes all MQTT messages onto a more durable pub/sub solution, i.e. Google Pub/Sub. This is also a more general purpose pub/sub component, which allows it to more easily connect to other software systems you may use.
For IDEWE, the MQTT bridge allowed us to ingest the telemetry data into a data platform. That data is then visualized in a dashboard for analyzing the evolution of CO₂ levels in schools, offices, restaurants, and other work places.
We used a combination of Google Dataflow based on the Apache Beam programming model, Google BigQuery and Google Data Studio to construct this dashboard. By using these fully managed services from Google, setting up a future-proof IoT and Data architecture is fairly easy to do. It’s also not hard to set up extensions with additional measurements and sensors (temperature, humidity, light, sound, ...), or even actuator IoT devices.
Having this IoT data as part of an enterprise-grade data platform allows it to go to the next level and combine the IoT data with other datasets you may have available in your enterprise. Designing this data as a product or a group of products in a Data Mesh then becomes more important, but that is another topic for another blog series. ;)
Conclusion
With the above solution, ACA Group has enabled IDEWE to augment their existing services or even introduce completely new services to their customers. The end result is a digital transformation in which the well-being and health of employees in the workplace (and children in schools) are improved using new technology and possibilities. Ultimately, the use of IoT devices for health monitoring is still in its early stages, and many more devices will become available in the future. However, these devices provide an easy way for people to improve their health without constantly being present. So far, the data collected from these devices has shown that people can make changes to their daily routine based on the data collected and improve their health.
The Internet of Things is changing how we live, work and play. If you want to learn more about this fascinating concept, contact us today. We’ll gladly help you make the most informed decision possible for your IoT project needs.
