ACA Group Blog | Inzichten over Softwareontwikkeling, UX/UI, Data & Innovatie

IoT en digitale kanaries gebruiken om de gezondheid te verbeteren - ACA Group

Geschreven door Peter Hardeel | 22-jan-2022 0:00:00

Het Internet of Things (IoT) draait rond het idee dat alledaagse objecten voorzien worden van sensoren, software en een draadloze verbinding om data over zichzelf en hun omgeving. In deze blogpost vertellen we je hoe we IoT-technologie gebruikten om een digitale transformatie te verzorgen voor één van onze klanten en zo de gezondheid van mensen op werkplekken te verbeteren.

Een kanarietje uit de koolmijnen in een modern jasje

Onze klant IDEWE is een externe dienst voor preventie en bescherming op het werk. De organisatie zet zich volledig in om het werkklimaat voor haar klanten te verbeteren. Om IDEWE te helpen bij haar doel, hebben we een applicatie gebouwd die helpt bij de beoordeling van externe blootstelling. Deze applicatie, gebaseerd op IoT, verzamelt gegevens van sensoren op verschillende locaties om langetermijnmetingen en de effecten van ondernomen acties te visualiseren. Er was een oplossing nodig waarmee sensoren gedurende een bepaalde periode niet-intrusief konden worden geplaatst en waarmee de metingen zonder veel configuratie in een dashboard konden worden weergegeven.

Met deze toepassing is IDEWE in staat om van discrete metingen naar continue monitoring te gaan en aanbevelingen te formuleren om de gezondheid van mensen in real-time te verbeteren. Hoe precies? IDEWE gebruikt een apparaat genaamd Little Lilly in de vorm van een gele vogel. Met behulp van sensoren kan de Little Lilly CO₂, temperatuur, relatieve vochtigheid en vluchtige toxische organische stoffen (VTOC) verzamelen. Het vogeltje heeft ook een indicatielampje dat lage (groen) of hoge (rood) CO₂-niveaus aangeeft. De vorm van het apparaatje is een knipoog naar de kanaries die in kolenmijnen werden gebruikt om mijnwerkers te waarschuwen voor een afnemende luchtkwaliteit.

Onze applicatie verzamelt de gegevens van Little Lillies en visualiseert die gegevens in een dashboard gefilterd op locatie, periode of sensor. Als er acties worden ondernomen, zoals het openen van een raam of het aanzetten van de airco wanneer een Little Lilly een hoge CO₂-concentratie rapporteert, worden deze ook weergegeven op het dashboard. Op die manier kunnen gebruikers meteen zien welk effect die acties hadden op de metingen.

In de rest van deze blog wordt beschreven hoe de telemetriegegevens van IoT-apparaten (Little Lillies) veilig kunnen worden opgenomen in een dataplatform met de nodige analytische dashboards die IDEWE kan gebruiken.

MQTT als lichtgewicht communicatieprotocol

In sommige situaties waarin (IoT-)apparaten worden gebruikt, zijn de communicatiekanalen of netwerken onbetrouwbaar en is toch betrouwbare communicatie vereist. Een auto met sensoren kan bijvoorbeeld door een tunnel rijden en tijdelijk de verbinding verliezen. Typisch zijn IoT-apparaten klein en beperkt in het gebruik, wat de behoefte aan een zeer licht communicatieprotocol met zich meebrengt.

Om deze redenen wordt MQTT gebruikt als communicatieprotocol. Het is een OASIS standaard messaging protocol voor IoT en is ontworpen als een lichtgewicht publish/subscribe messaging transport om kleine apparaten met een lage netwerkbandbreedte en beperkte middelen mogelijk te maken. MQTT is schaalbaar tot miljoenen apparaten. Met persistente sessies en quality of service levels ondersteunt MQTT betrouwbare berichtaflevering voor onbetrouwbare netwerken. De oplossing is een protocol bovenop TCP en is onafhankelijk van het type netwerk dat gebruikt wordt (Wi-Fi, 4G/5G, LoRaWAN, ...).

De volgende afbeelding illustreert hoe MQTT gebruik maakt van een broker om publish/subscribe communicatie mogelijk te maken. Merk op dat deze MQTT-broker geen single point of failure mag worden en zeer beschikbaar en schaalbaar moet zijn. Voor ons project bij IDEWE gebruikten we de Google IoT Core-oplossing, die een volledig beheerde MQTT-broker out-of-the-box heeft om aan deze vereisten te voldoen. IoT Core draait op de serverloze infrastructuur van Google, die automatisch schaalt in reactie op real-time veranderingen.

Security is van het grootste belang

Nu er elke dag meer en meer gegevens worden verzameld en er meer apparaten aanwezig zijn in ons dagelijks leven, is het onderwerp beveiliging belangrijker dan ooit bij het ontwerpen van een IoT-oplossing:

  • IoT-apparaten zijn verspreid in allerlei ongecontroleerde omgevingen in het veld, wat ze kwetsbaar maakt voor aanvallen.
  • IoT-apparaten nemen een breed scala aan telemetrie waar in auto's, huizen, werkomgevingen of zelfs de openbare ruimte. Sommige van deze gegevens zijn niet bedoeld voor publieke ogen en moeten worden beschermd als gevoelige gegevens.
  • Datalekken kunnen ernstige schade toebrengen aan de reputatie van de getroffen bedrijven.

Beveiliging is altijd een kwestie van het introduceren van beveiligingsmaatregelen op verschillende niveaus om het zo moeilijk mogelijk te maken voor een aanval om te slagen. Er zijn drie niveaus waarop een IoT-oplossing kan worden beveiligd:

  1. Netwerkniveau: Eén manier om een veilige en betrouwbare verbinding te bieden is door een fysiek beveiligd netwerk of VPN te gebruiken voor alle communicatie tussen clients en brokers. Deze oplossing is geschikt voor gatewaytoepassingen waarbij de gateway aan de ene kant verbonden is met apparaten en aan de andere kant met de MQTT broker. In een meer publieke omgeving is een fysiek beveiligd netwerk of VPN echter niet altijd een optie. In dat geval zijn de andere beveiligingsniveaus cruciaal.
  2. Transportniveau: Als vertrouwelijkheid het primaire doel is, wordt TLS/SSL vaak gebruikt voor transportversleuteling. Deze methode is een veilige en bewezen manier om ervoor te zorgen dat gegevens niet kunnen worden gelezen of dat er niet mee kan worden geknoeid tijdens de overdracht. Bovendien biedt het authenticatie van client-certificaten om de identiteit van beide partijen te verifiëren.
  3. Toepassingsniveau: Op transportniveau wordt de communicatie versleuteld en worden identiteiten geverifieerd. Het MQTT protocol biedt een client identifier en gebruikersnaam/wachtwoord om apparaten ook op applicatieniveau te authenticeren. Deze eigenschappen worden geleverd door het protocol zelf. Autorisatie of controle van wat elk apparaat mag doen wordt gedefinieerd door de specifieke brokerimplementatie.

Met het MQTT protocol kunnen zowel de versleuteling op transportniveau als de authenticatie op applicatieniveau met behulp van protocollen zoals OAuth worden toegepast. Meer specifiek, wanneer de Google IoT Core MQTT broker wordt gebruikt, is het vereist om alle communicatie te versleutelen met behulp van TLS, clients te authenticeren met behulp van wederzijdse TLS-certificaten en bij elke communicatie te authenticeren met behulp van een geldig JWT token dat is ondertekend door het juiste certificaat. Verder mogen alleen apparaten die bekend zijn bij de apparaatbeheerder van IoT Core en die gebonden zijn aan een gateway (indien gebruikt) hun telemetriegegevens publiceren.

Dit resulteert in een zeer veilige IoT-omgeving om telemetriegegevens van de rand naar de cloud te krijgen.

Standaardiseer protocollen en berichtformaten voor meer flexibiliteit

De mogelijkheid om meerdere soorten apparaten en communicatienetwerktechnologieën uit te proberen is essentieel bij het ontwerpen en ontwikkelen van een IoT-oplossing. Apparaten evolueren voortdurend. Door niet vast te zitten aan een specifiek type kun je de nieuwe mogelijkheden bijhouden of bestaande apparaten integreren wanneer dat nodig is. Sommige soorten apparaten en/of netwerktechnologieën kunnen perfect werken in specifieke omgevingen, maar werken niet in andere omgevingen. Bijvoorbeeld: in kantooromgevingen is er misschien een Wi-Fi-verbinding of 4G/5G, maar in afgelegen gebieden is dit misschien niet het geval. Netwerktechnologieën die gericht zijn op een groter bereik, zoals LoRaWAN, zijn dan nodig. Met LoRaWAN kan één enkel apparaat over een afstand van 10-20 km communiceren(het wereldrecord staat zelfs op 700 km). In andere gevallen hebben sommige apparaten ook niet genoeg vermogen om Wi-Fi of 4G/5G te gebruiken. In deze gevallen kunnen LoRaWAN-netwerken ook helpen, omdat ze zeer weinig stroom verbruiken wanneer ze communiceren. Voor legacy-apparaten die gebruik maken van zeer oude of propriëtaire communicatietechnologie kan een combinatie van apparaten en een gateway die deze technologie ondersteunt nodig zijn. De gateway is dan verantwoordelijk voor het aanpassen aan een meer standaard protocol zoals MQTT.

Voor het Little Lilly-project bij IDEWE hebben we alleen het communicatieprotocol en het berichtformaat dat wordt opgenomen gestandaardiseerd. We behielden volledige flexibiliteit met betrekking tot het apparaattype en de netwerktechnologie, zolang MQTT werd gebruikt en een overeengekomen berichtenstructuur. Hieronder staat een voorbeeld van een berichtformaat:

{"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" } }

Merk op dat dit een eenvoudig voorbeeld is. Afhankelijk van de use cases die u wilt ondersteunen, kan een geavanceerder formaat worden geadviseerd. Dit voorbeeld telemetriebericht bevat de gerapporteerde CO₂-waarde, de tijdstempel wanneer het gemeten werd en een identificatie om te weten waar of op welk Little Lilly apparaat het gemeten werd.

Naast het eigenlijke berichtformaat heeft MQTT ook een topic nodig om berichten naar te publiceren. De manier waarop topics gestructureerd zijn, wordt een topic namespace genoemd. Deze topicnaamruimte moet ook deel uitmaken van de overeengekomen structuur. Wanneer je bijvoorbeeld Google IoT Core gebruikt, kan een apparaat zijn telemetriegegevens publiceren naar een topic met structuur `/devices/Li074715/events` en zijn toestandsgegevens naar een topic met structuur `/devices/Li074715/state`. Google legt zelf geen berichtenstructuur op.

Vernieuw je business inzichten en diensten door IoT-data en bedrijfsgegevens te combineren

Met een pure IoT-oplossing kun je overal IoT-apparaten plaatsen en bijvoorbeeld de huidige CO₂-niveaus meten door je met een mobiel apparaat aan te melden bij de MQTT broker. Als we het daarbij laten, realiseren we niet het volledige potentieel van IoT. Een volgende stap is om inzicht te krijgen in de evolutie in de tijd van deze metingen. Hiervoor moeten we de geschiedenis van CO₂-metingen bijhouden en er toegang toe krijgen.

MQTT is lichtgewicht en ontworpen voor hoge schaalbaarheid. Om die reden biedt het geen duurzame persistentie van de MQTT-berichten, maar pusht het de berichten rechtstreeks naar geabonneerde gebruikers van deze gegevens. Slechts een beperkte buffer wordt ondersteund voor betrouwbare communicatie.

Google IoT Core lost dit op met een MQTT bridge, die automatisch alle MQTT-berichten publiceert op een meer duurzame pub/sub-oplossing, namelijk Google Pub/Sub. Dit is ook een meer algemene pub/sub-component, waardoor het gemakkelijker verbinding kan maken met andere softwaresystemen die je mogelijk gebruikt.

Voor IDEWE konden we met de MQTT-bridge de telemetriegegevens opnemen in een dataplatform. Die gegevens worden vervolgens gevisualiseerd in een dashboard voor het analyseren van de evolutie van CO₂-niveaus in scholen, kantoren, restaurants en andere werkplekken.

We gebruikten een combinatie van Google Dataflow gebaseerd op het Apache Beam programmeermodel, Google BigQuery en Google Data Studio om dit dashboard te bouwen. Door gebruik te maken van deze volledig beheerde diensten van Google is het opzetten van een toekomstbestendige IoT- en Data-architectuur vrij eenvoudig. Het is ook niet moeilijk om uitbreidingen op te zetten met extra metingen en sensoren (temperatuur, vochtigheid, licht, geluid, ...), of zelfs actuatorische IoT-apparaten.

Als deze IoT-gegevens deel uitmaken van een enterprise-grade dataplatform, kan het naar het volgende niveau gaan en de IoT-gegevens combineren met andere datasets die mogelijk beschikbaar zijn in je bedrijf. Het ontwerpen van deze data als een product of een groep producten in een Data Mesh wordt dan belangrijker, maar dat is een ander onderwerp voor een andere blogserie. ;)

Conclusie

Met de bovenstaande oplossing heeft ACA Group IDEWE in staat gesteld om hun bestaande diensten uit te breiden of zelfs volledig nieuwe diensten te introduceren bij hun klanten. Het eindresultaat is een digitale transformatie waarbij het welzijn en de gezondheid van werknemers op de werkplek (en kinderen op scholen) worden verbeterd met behulp van nieuwe technologie en mogelijkheden. Uiteindelijk staat het gebruik van IoT-apparaten voor gezondheidsmonitoring nog in de kinderschoenen en zullen er in de toekomst nog veel meer apparaten beschikbaar komen. Deze apparaten bieden echter een gemakkelijke manier voor mensen om hun gezondheid te verbeteren zonder constant aanwezig te zijn. Tot nu toe hebben de verzamelde gegevens van deze apparaten aangetoond dat mensen hun dagelijkse routine kunnen aanpassen op basis van de verzamelde gegevens en zo hun gezondheid kunnen verbeteren.

Het internet der dingen verandert de manier waarop we leven, werken en spelen. Als je meer wilt weten over dit fascinerende concept, neem dan vandaag nog contact met ons op. We helpen je graag om de best mogelijke beslissing te nemen voor jouw IoT-project.