IoT en Beton
Meten is weten, en in deze tijd van slimme apparaten hebben we duizend-en-één verschillende manieren om data uit onze omgeving te onttrekken. Temperatuursensors, bewegingssensors, lichtsensors, gps, etcetera. Denk enkel al aan je mobiel. De gemiddelde smartphone weet waar je bent. Hoe snel je gaat. Hoe warm het is. Welke muziek je draait. Hoeveel stappen per uur je zet. Hoe je gezicht eruitziet en ga zo maar door.
Veel van deze data en kennis wordt verwerkt in allerlei applicaties. De apparaten die deze data leveren zijn IoT-Devices. IoT, of Internet of Things, is een populaire technologie-toepassing die de kennis van een slim apparaat ontvangt, verwerkt en toepast.
Een prima technologie dus om te gebruiken voor beton. Voor een opdrachtgever hebben wij een applicatie ontwikkeld voor het meten en monitoren van beton. Op basis hiervan wordt geadviseerd over alle beton gerelateerde zaken.
Voor het gebruik van deze applicatie plaatst men apparatuur met sensoren in het vers gegoten beton. Deze apparatuur zal voor een langere tijd onder andere temperatuur uitlezen. Door de data van deze sensoren en de eigenschappen van het beton te combineren, kunnen er op elk moment zeer precieze resultaten (en voorspellingen) getoond worden over de hardheid van je beton. Zo kan een bouwopzichter in Dubai zien dat hij niet tien dagen hoeft te wachten voordat hij verder kan bouwen, maar misschien maar zeven dagen. In een wereld waar tijd geld is, is drie dagen een aanzienlijke winst.
De apparaten en sensoren die hierbij gebruikt worden vallen onder de eerdergenoemde term: een IoT-Device.
Het postkantoor
Veel data betekent veel management. Hierbij komt ook de term Big Data om de hoek kijken. Maar de uitdaging hier is niet hoe we deze vele data opslaan, maar hoe we het verwerken.
Voor slimme apparaten is het de uitdaging om zo veel mogelijk data op een zo efficiënt mogelijke manier naar een verzamelpunt te sturen… Een hub zou je kunnen zeggen… Of nog mooier: Een IoT-hub.
Een IoT-hub is vergelijkbaar met een postkantoor. Apparaten gekoppeld aan een hub kunnen verzamelde data als een brief hier naartoe sturen via verschillende protocollen.
Deze apparaten zijn geen grote computers. Integendeel, ze zijn compact in formaat en beperkt in capaciteit. De vele data die ze meten moeten dus op een efficiënte manier naar de hub verstuurd worden.
Bytes
Bij het versturen van data komen voornamelijk twee eigenschappen terug: grootte en type. Een vriendelijk leesbaar type van data is bijvoorbeeld JSON, een standaard en leesbaar tekst-gebaseerd formaat. Een ander type (en veel efficiënter dan dit kom je niet) is het versturen van ruwe bytes. De meest elementaire vorm van data.
Een voorbeeld van JSON met bijvoorbeeld een gemeten temperatuur zou er zo uit kunnen zien:
{
"Temperature": "18.90"
}
Bovenstaande bericht heeft een grootte van 29 bytes.
Het voordeel hiervan is dat de ontvangende applicatie die de data dient te verwerken direct weet wat de gegevens inhouden. Het is een temperatuur van 18,90 graden met twee getallen achter de komma.
Een voorbeeld van ruwe bytes van datzelfde temperatuurbericht zou zijn:
0x0762
Hiervan is de grootte slechts twee bytes… Meer dan 14 keer zo efficiënt als JSON!
De uitdaging hierbij is dat de ontvangende applicatie moet weten dat dit om een temperatuur gaat, dat er geen komma in voor komt en dat er twee getallen achter de komma zouden moeten staan. Er zijn dus veel bytes bespaard, maar dat moet worden gecompenseerd met de interne logica (of afspraak) van de applicaties die de data verwerken.
Een leuke uitdaging dus om deze data naar bruikbare data te zetten. Dit proces noemen we de-serialisatie. Deze uitdaging wordt nog groter als je bedenkt dat een gemiddeld slim apparaat meer dan één soort data kan versturen. En elk met een eigen de-serialisatie afspraak.
Bytes uit het beton
De IoT-hub ontvangt alle berichten, van alle apparaten. Als primaire taak moet elk berichttype aangekomen in de hub geïdentificeerd worden. Vergelijkbaar met de sorteerders in het postkantoor. Met zijn nieuwe gevonden identiteit wordt het bericht doorgestuurd naar een sub-queue.
Voor elk berichttype is er zo’n queue; een wachtrij die vergelijkbaar is met de rij voor een achtbaan. Ga je eerder in de rij dan de volgende persoon, dan mag je ook eerder in de attractie. Voor elke queue is er een verwerkend proces, ook wel een micro-service.
Een micro-service heeft de taak om de berichten volgens afspraak te de-serialiseren tot iets leesbaars. Onze bouwopzichter in Dubai zou dus na dit proces de leesbare temperatuur van het beton kunnen inzien.
Bytes naar het beton
De hub werkt als een uitstekend verzamelpunt voor slimme apparaten om berichten naar toe te sturen. Deze zelfde hub kan (opnieuw vergelijkbaar met het postkantoor) natuurlijk ook gebruikt worden om berichten naar het device terug te sturen.
Een slim apparaat kan instellingen hebben die een gebruiker moet kunnen bewerken, of een set commando’s die uitgevoerd kunnen worden. Het schrijven van deze data gebeurd in dezelfde vorm als het ontvangen: Bytes.
Naast het de-serialiseren van data vindt er dus ook data serialisatie plaats.
Het eindproduct
Het eindproduct is een combinatie van technieken: een hub, meerdere queue’s, meerdere microservices, verschillende databases en tabellen. En natuurlijk een gebruikersvriendelijke applicatie om data te kunnen raadplegen en om data naar toe te kunnen schrijven.
Het is een assemblagelijn geworden die rekening houdt met verschillende soorten berichten, foutmeldingen en zelfs probeert zelf-herstellende acties te ondernemen bij foutieve berichten.
Het opbouwen van deze structuur, rekening houdend met zulke ruwe data en efficiënte afhandeling was een uitdaging waar de meeste programmeurs jaloers op zouden zijn.