Opzetten van een IoT

 
Opzetten van een IoT
Het IoT groeit snel. Dat is voor een belangrijk deel te danken aan de toegankelijkheid van de techniek. Daarin schuilt echter ook een gevaar; er ontstaat makkelijk fröbelwerk. Het vergt kennis van zaken om een professioneel IoT te bouwen.
 
Rik Vereecken
 
Ontwikkelen van professionele toepassingen
Over het Internet of Things (IoT) wordt vooral in termen van toekomstige toepassingen gepraat. Dat het IoT al op een aantal plaatsen bestaat is minder bekend. Toch wordt het IoT steeds vaker gebruikt als basis voor nieuwe toepassingen, met name op het vlak van remote registratie.
Het bouwen van een IoT is niet per se ingewikkeld. Als je de vele tutorials op het internet mag geloven volstaat het om voor twee-à driehonderd euro een Raspberry- of een Arduino-kit te kopen, je in te schrijven op een cloudservice, en vervolgens een kleine app te bouwen.
Voor de groei van het IoT is deze toegankelijkheid van de techniek een groot voordeel. Maar het ontwikkelen van professionele toepassingen vraagt om meer dan een ‘developers-kit’ die voor een relatief laag bedrag kan worden aangeschaft. Wat is er nodig om een professioneel IoT op te zetten? Aan de hand van een case nemen we de verschillende onderdelen van het IoT onder de loep.
Voorbeeldcase
In een kantooromgeving, in dit geval een studiebureau, is behoefte aan een systeem voor het meten van temperatuur, vochtigheid en CO2. Het gaat om een tijdelijke voorziening van ongeveer een jaar, wat de aanleg van een permanente infrastructuur overbodig maakt. De oplossing zal daarom gezocht moeten worden in draadloze communicatie. Daarnaast moet het mogelijk zijn om bij afwijkingen boven of onder bepaalde waarden bij te sturen via het geïnstalleerde BAS (Building Automation System).
Vertrekpunt bij bovengenoemde case was niet om op voorhand een IoT-oplossing te bouwen. Het IoT is immers een middel en nooit een doel op zich. Voor deze case was het zaak de goedkoopste en meest efficiënte oplossing te realiseren. Dat dit een IoT-oplossing blijkt te zijn, onderstreept iets over het gemak waarmee deze techniek toepasbaar is (figuur 1) .
 
Figuur 1. Onderdelen van een meetinstallatie. De bovenste rij afbeeldingen geeft de verschillende onderdelen van het systeem aan. De onderste rij plaatjes verbeelden de gekozen oplossingen.
 
Footprint
De footprint is in veel gevallen een sensor. Het gaat immers om meten of registratie. In deze case is het een multisensor waarbij de gewenste waarnemingen binnen een device zijn geïntegreerd. Dit device is opgebouwd uit: moederbord met microcontroller; temperatuur/vochtigheidssensor; CO2-sensor; LoRaWAN-chip met antenne; accelerometer met positiebepaling; en drie 3,6V Lithium-batterijen van 2600 mAh.
Een belangrijk aandachtspunt bij elke IoT-toepassing is om het energiegebruik zo laag mogelijk te houden. Daarom wordt communicatie via bijvoor-beeld wifi vanwege het hoge energiegebruik zo veel mogelijk vermeden. In dit voorbeeld hebben we een device dat in ‘slaapstand’ 0,1 mA stroom verbruikt. In een actieve modus loopt dit op tot 10 mA. Bij zenden van data is het stroomverbruik 50 mA en bij ontvangen van data 25 mA.
Met het oog op een laag energieverbruik is het zaak te bepalen hoe vaak men informatie wil ontvangen. Minimaliseren van het aantal meetmomenten bespaart energie. Daarnaast is het zaak om voor het transport van de meetgegevens een zo ‘licht’ mogelijk protocol te kiezen. MQTT (Message Queue Telemetry Transport) is zo’n energiezuinig protocol dat in staat is een beperkte hoeveelheid informatie als actuele positie, temperatuur, vochtigheid, CO2 en resterende batterijcapaciteit, snel door te geven. Als ‘drager’ tussen de multisensor en ontvanger wordt gebruikgemaakt van LoRaWAN (Low Power Wide Area Network). Het sturen van een (versleutelde) MQTT-boodschap met bovengenoemde informatie duurt drie seconden. Wordt dit elk kwartier verzonden, dan betekent dit dat het device slechts twaalf seconden per uur actief is en de rest van de tijd ‘slaapt’. Met deze frequentie is de gemiddelde batterijdur drie jaar.
De koppeling met het BAS is eenvoudiger. Hier wordt gebruik gemaakt van een gateway/controller die de informatie van het gebouwenautomatisatiesysteem real-time omzet in MQTT-boodschappen. Het feit dat dit real-time gebeurt verschaft inzicht in de gedragingen van het BAS. Een typisch voorbeeld zijn real-time dashboards en patroonherkenning om onregelmatigheden te ontdekken.
Addressing & security
Het eerder genoemde MQTT is een typisch publish/subscribe-protocol dat ooit binnen IBM werd ontwikkeld voor M2M-communicatie. Kenmerk van MQTT is dat het zeer eenvoudig is, betrouwbaar, geringe bandbreedte vereist, en een vorm van ‘assurance of delivery’ omvat.
De werking is eenvoudig. Er zijn minimaal drie entiteiten: een client ‘publisher’ of zender, een client ‘subscriber’ of ontvanger, en daar tussenin een ‘broker’. Binnen de broker wisselen zender en ontvanger informatie uit. Vanzelfsprekend kan een broker meer dan één zender aan en kunnen meerdere ontvangers dezelfde informatie ophalen. Het kan ook zijn dat één ontvanger de informatie van meerdere ontvangers verzamelt en/of combineert. Voordeel van deze ‘zender-broker-ontvanger’-opzet is dat zender en ontvanger niet direct met elkaar communiceren en daardoor alleen gedefini eerde informatie uitwisselen.
MQTT is onafhankelijk van hardware en programmeertaal. Tevens kan per boodschap een ‘quality of service’ worden gedefinieerd.
Hoe dit in de praktijk werkt is weergegeven in figuur 2 : de publishers geven informatie door op een ‘topic’ (in onze case de temperatuur, luchtvochtigheid en CO2); subscribers abonneren zich op dit of op diverse topics.
 
Figuur 2. MQTT is een typisch publish/ subscribe-protocol

Voor de koppeling met het BAS is vanzelfsprekend een iets uitgebreidere structuur nodig. Indien dit het geval is, zoals in onze case, wordt ook de locatie meegegeven en vindt communicatie plaats met het BAS. Die communicatie loopt via een zogeheten KNX-systeem (doel- en bronadres), een standaard systeem voor aansturing van gebouwentechniek.
Een subscriber kan zich inschrijven bij de broker op één of meerdere topics. In ons voorbeeld is de subscriber een beveiligde cloudomgeving maar dit kan evengoed een app zijn op een mobiel toestel. Een unieke eigenschap van MQTT is de functie ‘Last Will Testament’ (LWT). Indien de verbinding tussen broker en client verbroken wordt, bijvoorbeeld door een lege batterij, zal de broker dit via de ‘LWT-boodschap’ kenbaar maken, zodat duide-lijk is dat de sensor offline is. Deze LWT is identiek aan de data die standaard wordt uitgewisseld en kan daardoor worden verspreid met dezelfde technieken (figuur 3) .
De belangrijkste aandachtspunten voor het opzetten van deze omgeving zijn:
• Voorzie in een robuuste oplossing die eenvoudig integreerbaar is in andere systemen. Het toevoegen van extra’s maakt dit integreren doorgaans alleen maar lastiger.
• Ga er om dezelfde reden van uit dat applicaties over weinig processorkracht beschikken.
• Zorg ervoor dat applicaties met een minimum aan inspanning gekoppeld kunnen worden.
• Wees bandbreedte-efficiënt door overhead te vermijden. Stuur enkel zinvolle data. Hoe minder informatie hoe kleiner de kans op fouten. Dat is niet alleen belangrijk voor de betrouwbaarheid van het systeem maar komt ook de levensduur van de batterij ten goede. • Ga steeds uit van een onbetrouwbaar netwerk met lage bandbreedte, vertraging et cetera. Gebruik daarom altijd LWT.
• Maak gebruikt van ‘quality of service’, ofwel voldoe aan de gevraagde functionaliteit maar probeer niet meer te bouwen dan nodig is. • Houd elke oplossing eenvoudig. Vermijd dat administratie rond een oplossing nodig is.
• Wees flexibel en data-agnostisch.
Figuur 3. Praktijkopstelling van een meetsysteem op basis van het IoT met gebruik van MQTT
 
Scale en cloud
Ook bij het opzetten van een IoT-oplossing geldt dat men zo veel mogelijk flexibiliteit wil, terwijl de kosten zo laag mogelijk blijven. In de genoemde voorbeeldcase gaat het om pakweg tien devices, maar breiden we dit uit naar het monitoren van een groot gebouwencomplex, dan neemt het aantal devices exponentieel toe. Zelfs meetinstallaties bestaande uit tien miljoen devices zijn mogelijk.
Het verwerken van de enorme hoeveelheid data uit een dergelijke installatie data vergt enorme processorcapaciteit waarvoor uiteindelijk maar één oplossing denkbaar is: cloudcomputing.
Alleen dat biedt de schaal en flexibiliteit om dergelijk grote installaties te bouwen. Een mogelijk opzet in een cloudomgeving kan eruitzien als in figuur 4 . Daarbij meteen een opmerking in de zijlijn. Wie kiest voor verwerking en opslag in een cloudomgeving is zelf verantwoordelijk voor de redundantie. Dus moet je in een systeem voorzien dat de functies die door die servers behandeld worden, bij uitval van de server naadloos overgaan op een andere server.
Bij de uitleg van dit schema staan de twee linkse onderdelen ‘Apps & Devices’ en ‘Bridge D25’ voor de waarneming van sensoren en voor de communicatie naar de broker. Onderstaande beschrijving begint bij het derde onderdeel de ‘Broker S25’.
 
Figuur 4. Mogelijke opzet in een cloudomgeving
 
Broker S25
Dit deel omvat primair de ‘Event Hub’ / ‘IoT Hub’.
• Via de Event Hub zijn we in staat om grote hoeveelheden data te verwerken. Een Microsoft Event Hub kan per maand bijvoorbeeld tot een miljoen publishers en 1 triljoen boodschappen van 1 Kb grootte verwerken. Vanzelfsprekend moet dan je meerdere Event Hubs koppelen.
• Device-registratie, identificatie en manage ment: Bij het in een cloudomgeving verwerken van IoT-waarnemingen kan het om miljoenen devices gaan, van verschillende eigenaren en/of installaties. Voor een veilig beheer van de ‘eigen’ devices is uiteraard een goede registratie vereist. Dat is cruciaal voor een veilige en stabiele omgeving. Bij het beheer van de eigen devices behoort ook het uitvoeren of laten uitvoeren van firmware-upgrades.
Transformation storage en presentatie
Dit onderdeel staat voor de verwerking van gegevens via streaming analytics waarbij informatie verwerkt wordt vóór de data al dan niet opgeslagen wordt. Daarbij kunnen ‘streams’ onderling gecorreleerd worden of worden vergeleken met reeds weggeschreven data. Vanzelfsprekend is niet alle binnenkomende data bedoeld voor opslag. Als een ruimte thermostaat een temperatuurwijziging van bijvoorbeeld 0,1 graad Celcius signaleert mag dat in de meeste gevallen genegeerd worden. Hierbij kunnen dashboards direct gekoppeld worden aan streaming (live) data.
Zien we de CO2-waarde in een ruimte toenemen, kunnen we een alarm genereren indien een bepaalde CO2-waarde overschreden wordt. In deze opstelling kan tot 1 GB per seconde worden verwerkt.
Een stap verder is dat op basis van de analyse en machineleren naar predictive analytics wordt toegewerkt. Bijvoorbeeld door live meetgegevens te vergelijken met historische data en met processen uit het verleden. Op basis van deze informatie zouden we een waargenomen stijging van de CO2-waarde verder kunnen voorspellen. Bijvoorbeeld dat de drempelwaarden binnen twintig minuten overschreden zal worden. In dat geval kunnen we het BAS aansturen om de ventilatie een niveau hoger te zetten.
Een andere toepassing is dat we meer inzicht krijgen in het energieverbruik van een gebouw. Dit kan door de dagelijkse temperatuur van de afgelopen jaren te relateren aan het gebruik in de overeenkomstige dagen. Het actuele energieverbruik in relatie tot de temperatuur zou relatief weinig afwijking mogen vertonen ten opzichte van de historische waarneming. Is dit wel het geval dan kan dit wijzen op mogelijke gebreken in ofwel de installaties of in het gebouw zelf. Denk aan niet goed sluitende deuren of ramen.
Een stapje verder is om gebouwen van elkaar te laten ‘leren’. Dit kan door een afwijkend patroon als ‘fout’ te bestempelen, en de oorzaak van dit foute patroon te achterhalen. Vertoont binnenkomende data overeenkomsten met het foute patroon dan wordt dit onmiddellijk gesignaleerd en kan waarschijnlijk ook de oorzaak al aangegeven worden. Dit leidt ertoe dat een technische dienst bij melding van een mankement meteen al een suggestie van de mogelijke oorzaak krijgt. Het vergelijken van actuele gegevens met historische informatie vergt beschikbaarheid van beide databestanden. Ook hiervoor biedt cloudcomputing, met name als het om grote bestanden gaat, een oplossingen door allerlei vormen van cloudstorage aan te bieden waarbij zowel voor actuele data als voor ‘slapende’ data de beste oplossing gekozen kan worden.
 
 
Figuur 5. Meetwaarden foutief afgestelde waterpomp (boven) en meetwaarden nadat de pomp door de fabrikant correct was afgesteld (onder)

Figuur 5 toont in het bovenste plaatje de meetwaarden van een foutief afgestelde waterpomp. In de afbeelding daaronder zien we de meetwaarden nadat de pomp door de fabrikant correct was afgesteld. Het resultaat van het opnieuw afregelen van de pomp was dat het energiegebruik 25 procent lager lag.
Ook eenvoudige afregelfouten kunnen middels patroonherkenning op een eenvoudige wijze gedetecteerd worden (figuur 6) .
 
Figuur 6. Schematische weergave van het ‘gedrag’ van een fout ingestelde hulpventilator
 
Visualisatie
Hoewel de meeste BI-platforms reeds jaren van innovatie achter de rug hebben, is er nog steeds geen duidelijke definitie van de betekenis van ‘visual analytics’. Mede daardoor zijn de klassieke BI-omgevingen minder geschikt voor toepassing binnen een IoT-oplossing. De belangrijkste ‘zwakte’ van de huidige BI-oplossingen is dat zij zich baseren op traditionele technologie die minder geschikt is voor het continu verwerken van grote hoeveelheden, steeds weer nieuwe, informatie. Inzet van traditionele BI voor het visualiseren van resultaten uit een grote IoT-implementatie vergt daarom veel extra menselijke interventie.
Daarom lijkt SaaS (Software as a Service) de meest aangewezen oplossing. Ook hier geldt weer dat de meest geavanceerde oplossingen, ook voor visualisatie van data, inmiddels vanuit de cloud worden aangeboden. Ook hier geldt uiteraard weer dat beveiliging van de data voorop moet staan, met de troika ‘identificatie, authenticatie, autorisatie’ als basis.
Overigens dient daarbij te worden opgemerkt dat men zich altijd de vraag moet stellen of visualiseren van meetgegevens gewenst is. Visualisering betekent immers vrijwel altijd menselijke interactie om de getoonde informatie te interpreteren. Veel van de via het IoT verzamelde informatie kan echter prima via software geanalyseerd worden.
Security
Veiligheid bij het IoT blijft een heikel punt. Onlangs nog kwam Nissan in het nieuws met de gehackte app van de Nissan Leaf. Jammer genoeg is dit incident bij Nissan geen uitzondering. Integendeel zelfs, te vrezen is dat we op het terrein van hacking en cybercriminaliteit nog slechts het topje van de ijsberg zien. Dat stelt extra eisen aan de beveiliging van het IoT. Temeer omdat veel fabrikanten erop gebrand zijn hun devices en software zo snel mogelijk op de markt te brengen. Dat gaat ten koste van het afdoende testen. Zonder overdrijven kan worden gesteld dat datasecurity bij veel leveranciers nog steeds geen hoge prioriteit heeft.
Bouwers van IoT-oplossingen moeten security daarom de hoogste prioriteit geven en weten dat vertrouwen op leveranciers van apparatuur misplaatst is. Zelfs als beveiligingscertificaten en security-key’s worden meegeleverd. Vaak blijkt dat meegeleverde ‘sleutels’ niet meer zijn dan een standaard-instelling die iedereen kent, vergelijkbaar met elektronische cijfersloten die standaard worden geleverd met de code 1234. In de praktijk blijkt dat die code in 15 procent van alle gevallen nooit meer gewijzigd wordt.
Hoopgevend is dat bij steeds meer fabrikanten een duidelijke evolutie naar intrinsiek beveiligde devices en apps waarneembaar is.
 
Rik Vereecken (rik.vereecken@bynubian.com) is smart building evangelist bij de firma byNUBIAN.
 

Tag

IoT

Onderwerp

IoT


Niet gevonden? Vraag het de redactie!

Heeft u het antwoord op uw vraag niet gevonden, of bent u op zoek naar specifieke informatie? Laat het ons weten! Dan zorgen we ervoor dat deze content zo snel mogelijk wordt toegevoegd, of persoonlijk aan u wordt geleverd!

Stel uw vraag