Internet of Things/Watson

Inleiding: aan sensordata naar betekenis

In de eerdere hoofdstuken hebben we vooral aandacht besteed aan de sensordata: hoe verwerf je deze sensordata, hoe stuur je die door naar de NodeRed server, via MQTT? In dit hoofdstuk gaan we in op de betekenis van die sensordata: wat doe je ermee? Welke beslissingen en acties zijn hieraan gekoppeld? Hoe maak je die koppeling?

Het uiteindelijke doel is bijna altijd beslissing, gevolg door een actie: bij deze beslissing vormen die sensordata een belangrijke input. Vaak zijn er bij een beslissing nog data van andere bronnen betrokken. Aan een dergelijke beslissing is meestal een actie gekoppeld, geautomatiseerd of uit te voeren door mensen.

Van sensordata naar betekenis: de data-actie keten

De betekenis van sensordata heeft meerdere niveaus of lagen, bijvoorbeeld:

• op het onderste niveau hebben we de ruwe sensordata en een eenvoudige identificatie van de sensor: sensor3: 173;
• op een volgend niveau geven we de fysische grootheid aan voor deze waarde (temperatuur), met de eenheid (graden Celcius) en de bijbehorende precisie (+/-0,5 'C);
• vervolgens koppelen we de sensor aan het "ding": temperatuur van de woonkamer (op 1,5 meter hoogte).
• een volgend niveau is de interpretatie van deze data in de context van de temperatuurregeling van de kamer (een toepassing): "2,7'C te koud". Op dit niveau gebruiken we meestal events, zoals we verderop bespreken.
• een event koppelen we aan een actie: schakel de verwarming voor deze kamer in.

We kunnen dit weergeven als abstractielagen, hier van hoog abstractieniveau naar laag:

		voorbeeld
actie	toepassing: actie	schakel de verwarming in
beslissing/conclusie (toepassing)	toepassing: beslissing	2,7'C te koud
koppelen aan "ding"	commissioning	temperatuur van de woonkamer: 17,3' C
grootheid/eenheid/precisie	schema	temperatuur: 17,3'C (+/- 0,5'C)
ruwe sensordata, fysieke adressen	fysisch niveau	sensor3: 173

We kunnen de overgang naar een volgend niveau op verschillende posities in de IoT-keten uitvoeren. Dit is vaak een afweging tussen verschillende aspecten:

• we willen de software voor de sensornodes eenvoudig en generiek houden; we gebruiken daar liever "sensor0" dan "woonkamer-temperatuur";
• als we veel data van de vorm "sensor-x: waarde-y" krijgen, weten we al snel niet meer wat de betekenis daarvan is;
• we kunnen in NodeRed gemakkelijker complexe berekeningen uitvoeren dan in een sensornode;
• we kunnen in NodeRed gemakkelijker data uit verschillende bronnen combineren, bijvoorbeeld van verschillende sensoren in een ruimte;
• de sensordata van een "ding" kunnen we voor meerdere toepassingen gebruiken;
• voor een toepassing kunnen we sensordata uit verschillende bronnen gebruiken (meerdere sensoren per "ding", data van meerdere "dingen").

N.B. de terminologie die we hier gebruiken: fysisch niveau, schema, commissioning, toepassing, is niet gebruikelijk. Ik gebruik deze hier om enige ordening aan te geven. Voor zover mij bekend is er geen gangbare terminologie.

Schema: grootheden, eenheden en precisie

De stap van de ruwe sensordata naar data met grootheden (temperatuur), eenheden (graden Celcius) en precisie noemen we het schema van de sensordata.

De terminologie hierbij is (nog) niet gestandaardiseerd: deze is, net als een database-schema, in eerste instantie gericht op de menselijke gebruiker/programmeur. Er zijn verschillende pogingen, onder andere van W3C (Semantic Sensor Network, Open/Linked Data), om tot een dergelijke standaardisatie te komen. Zie bijvoorbeeld: https://www.w3.org/2005/Incubator/ssn/ssnx/ssn

Commissioning: sensordata koppelen aan "ding"

We willen niet alleen weten wat de grootheid van een sensor is ("temperatuur"), we willen ook weten waarop dit betrekking heeft. Wat is het "ding" waarvan dit de temperatuur is? Het kan bijvoorbeeld gaan om de temperatuur van een onderdeel van een machine, of om de temperatuur in een kamer.

Op een laag abstractieniveau identificeren we de sensoren en de sensornodes met een "fysiek adres". Op een hoger niveau koppelen we dit aan een eigenschap van het "ding". Bij het installeren van sensoren en sensornodes moet je op de een of andere manier deze koppeling tot stand brengen. Dit proces heet "commissioning". Je legt dan bijvoorbeeld vast dat "button-0" op sensornode "ac1e" de "licht-aanknop" is in "kamer 314". Het resultaat van deze commissioning moet je ergens vastleggen, bijvoorbeeld in een tabel, die je raadpleegt als je van de fysieke adressering naar betekenisvolle namen overgaat, of andersom.

Dit kun je vergelijken met het gebruik van DNS (domain name system): dit beschrijft de relatie tussen IP-adressen en domeinnamen. We kunnen dan over "infvo.nl" spreken in plaats van over "123.210.99.101".

Voor het Internet of Things is er (nog) geen gestandaardiseerde manier om een dergelijke koppeling tot stand te brengen: we moeten dat voor elke toepassing/domein opnieuw bedenken.

Toepassingen en sensoren

In de toepassing geven we verder betekenis aan de sensordata. De toepassing kan bijvoorbeeld de klimaatregeling van een ruimte zijn (woonkamer). In dat geval hebben we te maken met een ingestelde wenselijke temperatuur en met de actuele, waargenomen temperatuur. Door middel van een of andere regeling proberen we met behulp van "actuatoren" zoals verwarming of koeling de gewenste temperatuur te realiseren.

In het Internet of Things is er niet altijd een 1-op-1 relatie tussen sensoren en toepassingen:

• voor sommige toepassingen hebben we meerdere sensoren nodig; denk bijvoorbeeld aan een brandalarm: dit kunnen we betrouwbaarder maken door rook- en warmtesensoren te combineren.
• sommige sensoren kunnen we voor meerdere toepassingen gebruiken. Denk bijvoorbeeld aan de temperatuursensoren in een kamer: deze kunnen we gebruiken voor het regelen van de verwarming, maar ook voor het detecteren van brand.

Voor een toepassing hebben we meestal sensor-data nodig waarvan (i) de grootheid/eenheid/precisie bekend is; (ii) de relatie tot het "ding" bekend is.

Hoe vaak meten we met een sensor? (Wat is de bemonsteringsfrequentie?). Hoe precies meten we? Hier kunnen we op twee manieren mee omgaan:

• we gebruiken onze kennis over het fysische proces waaraan we meten. Als de temperatuur in een vriescel, door de isolatie en dergelijke, niet sneller verandert dan 0.1 graad per 10 minuten, dan hoeven we met een sensor met deze nauwkeurigheid niet vaker te meten dan eens per ca. 10 minuten.
  • anders gezegd: we gebruiken onze kennis over de bron van de data;
• we gebruiken onze kennis over de beslissingen verderop in de keten. Een voorbeeld hiervan is MP3: op basis van onze kennis van het menselijk gehoor weten we wat de maximale bemonsteringsfrequentie is; bovendien kunnen we zachte geluiden die gemaskeerd worden door harde geluiden weglaten.
  • in dit geval gebruiken we onze kennis over het doel van de data.

Events, toestanden en signalen

Op het hoogste niveau, dat van de beslissingen en acties, gebruiken we events. Een event (in deze context) is "instantaan": een event vindt plaats op een bepaald tijdstip, en heeft geen duur.

Voorbeelden van dergelijke events zijn:

• het indrukken van een knop (op een sensornode);
• een val (van een persoon);
• het binnenkomen van een persoon in een ruimte;

Een vergelijkbaar gebruik van events vinden we bij grafische user interface-systemen, zoals in een operating system GUI of in een browser.

Toestanden en toestandsovergangen

Naast het begrip event onderscheiden we het begrip toestand: een toestand heeft wel een duur. De overgang naar een andere toestand kunnen we als een event beschouwen.

Voorbeeld: bij een drukknop hebben we twee toestanden: open (niet ingedrukt) en gesloten (ingedrukt). De overgang van open naar gesloten is een event ("het indrukken van de drukknop"), net als de overgang van gesloten naar open ("het loslaten van de drukknop").

Opmerking: een dergelijke overgang heeft in fysische zin ook altijd een bepaalde duur, maar op het abstractieniveau van onze toepassing is die niet relevant, en beschouwen we deze overgang als instantaan.

We koppelen een actie aan een event, niet aan een toestand. Bij een dergelijke actie speelt de tijdsduur ook geen essentiële rol.

Van signaal naar event

Een sensor geeft een signaal: een waarde die in de loop van de tijd verandert. We kunnen in een dergelijk sensorsignaal events detecteren. Soms kan dit aan de hand van een eenvoudige overgang in het signaal (bijvoorbeeld van 0 naar 1). In andere gevallen hebben we een complexere patroonherkenning nodig, waarbij soms ook meerdere sensoren betrokken zijn.

Voorbeeld: in het signaal van een hartsensor (ECG) willen we de hartslag detecteren, met de periode tussen de opeenvolgende hartslagen (voor de "heart rate variability"). Een hartslag is dan een event, met een bepaald tijdstip.

Voorbeeld: in het signaal van een versnellingsmeter (accellerometer) willen we de stappen detecteren, met een indicatie van de "impact". Een stap is dan een event.

Voorbeeld: we willen weten of een plant voldoende water heeft; als dat niet het geval is, willen we een mail ontvangen. We moeten dan uit het signaal dat de bodemvochtigheid weergeeft, een event detecteren. We willen niet voor elke seconde dat de bodem te droog is, een mailtje ontvangen. We kunnen dit op verschillende manieren oplossen:

• alleen bij de overgang van "voldoende vochtig" naar "te droog" sturen we een mail;
• we sturen een mail als de bodem te droog is, en de vorige mail langer dan 4 uur geleden verstuurd is.
• (andere alternatieven).

Signaalverwerking; sensor fusion

Voor het detecteren van complexe events in een signaal moeten we soms veel rekenen (signaalverwerking). In bepaalde gevallen kan het handig zijn om de signalen van meerdere sensoren te combineren (sensor fusion).

Wat is de beste plek voor het uitvoeren van deze signaalverwerking?

• als we dit dicht bij de "bron" doen, dan kunnen we flink besparen op de hoeveelheid data die overgestuurd wordt. Een hartslag-event kunnen we veel compacter weergeven dan een volledig ECG.
  • het rekenwerk van signaal naar event (in een sensornode) kost soms minder energie dan het oversturen van de sensordata.
• door deze signaalverwerking wordt de data specifieker (voor bepaalde toepassingen): we kunnen onregelmatigheden in het ECG niet meer detecteren in een hartslag-event.

NodeRed: events en messages

Een NodeRed flow bestaat uit een reeks verbonden nodes. Een node krijgt een bericht (message) binnen, verwerkt deze, en stuurt het resultaat-bericht naar de volgende node(s). Dit model sluit direct aan op het gebruik van events: een bericht stelt dan een event voor met de bijbehorende data.

Complexe beslissingen, Data Science en Cognitive Computing

De voorbeelden die we hiervoor gegeven hebben zijn erg eenvoudig. In een meer realistische situatie hebben we te maken met een veelheid aan data uit verschillende bronnen, en met beslissingen waarbij we allerlei effecten tegen elkaar moeten afwegen. In een dergelijk geval kun je gebruik maken van de verworvenheden van Data Science en Cognitive Computing (kunstmatige intelligentie).

Data Science

Data Science biedt middelen op verschillende niveaus:

• een eerste stap is data-visualisatie, op verschillende manieren. In deze visualisaties kun je "op het oog" mogelijke patronen en verbanden ontdekken.
• een volgende stap is het gebruik van statistiek. Hiermee kun je verbanden kwantificeren. Vaak gebruik je dit voor lineaire verbanden tussen grootheden.
• voor complexere situaties gebruik je modellen van het systeem waaraan je meet. Op basis van deze modellen en van de actuele data kun je beslissingen nemen.

Voorbeeld: een plant heeft in verschillende stadia van ontwikkeling, en in verschillende sitaties, verschillende soorten licht, lucht, water en voedingsstoffen nodig. Aan de hand van een plantmodel (groeimodel) in combinatie met een waarneming van de actuele situatie (sensordata) kun je bepalen welke actie nodig is.

De modellen die je hierbij gebruikt kunnen op verschillende manieren tot stand komen:

• het kan een expliciet model zijn, bijvoorbeeld ontwikkeld op basis de fysische processen die een rol spelen;
• het kan een impliciet model zijn, geconstrueerd door zelflerende algoritmen (Cognitive Computing) uit een groot aantal waarnemingen.
• het kan een combinatie van deze twee zijn.

Cognitive computing

We kunnen de verworvenheden van Cognitive computing (kunstmatige intelligentie) op verschillende manieren inzetten:

• we kunnen met behulp van lerende systemen impliciete modellen maken, voor het nemen van beslissingen;
• we kunnen allerlei technieken voor patroonherkenning en classificatie gebruiken;
• we kunnen de brug slaan tussen "kennis" (zoals bijvoorbeeld beschikbaar in wetenschappelijke publicaties of andere documenten) en (sensor)data;
• we kunnen interfaces maken die gebruik maken van natuurlijke taal, al dan niet gesproken.

User interfaces: spraak, dialogen (conversations)

Voor IoT-toepassingen zijn gebruikersinterfaces gebaseerd op spraak interessant, omdat we vaak niet de beschikking hebben over een traditioneel computer-interface (scherm/toetsenbord) in de buurt van de "dingen". Een luidspreker/microfoon "in de buurt" is vaak wel mogelijk. Voorbeelden van dergelijke interfaces zijn:

• Siri (Apple);
• Alexa (Amazon);
• Google Speech;
• ...

Ook in Watson/Bluemix zijn voorzieningen (in NodeRed) voor het werken met spraak.

Voor een fatsoenlijk gebruikersinterface moet je niet alleen spraak kunnen genereren en herkennen, maar je moet ook dialogen (conversations) kunnen beschrijven, gericht op bepaalde taken of toepassingen. Ook hiervoor heeft Watson/Bluemix voorzieningen (in NodeRed).

Acties

Zoals gezegd willen we een actie koppelen aan een event. Voorbeelden hiervan zijn:

• indrukken van knop AAN -> inschakelen van de lamp
• indrukken van knop UIT -> uitschakelen van de lamp
• bodem wordt te droog -> versturen van een e-mail
• detecteren van een val -> versturen van een alarm

Er zijn allerlei systemen om via het internet events en acties te koppelen. Voorbeelden van dergelijke systemen zijn:

• IFTTT (if this then that) - https://ifttt.com/
• Zapier - https://zapier.com/
• (andere voorbeelden?)

Ook met behulp van NodeRed kunnen we acties koppelen aan events. NodeRed geeft meer mogelijkheden dan bijvoorbeeld IFTTT en Zapier, maar we moeten daarvoor wel meer zelf doen (configureren/programmeren).