(Of: “Je moet er wel iets aan hebben….”)
Kent u het begrip Edge computing? Ik volg dit al een tijdje maar heb er tot nu toe nog niet zoveel mee te maken gehad. Tot ik me realiseerde dat ik hier een aantal jaren geleden in een project al mee begonnen ben. We gebruikten toen een Raspberry Pi om verschillende sensoren uit te lezen en deze data te combineren en interpreteren voordat we deze naar onze ‘Cloud’ sturen.
Klinkt goed zult u zeggen, door een grote hoeveelheid ruwe sensor data eerst samen te voegen en te bewerken hoef je niet zoveel meer te versturen. En dat klopt ook. Op deze manier maak je, als je het goed doet, van een heleboel ruwe sensor data informatie en dit is makkelijker te begrijpen en te hanteren.
We zien dit veel toegepast bij het voorspellen van onderhoud aan machines. De voorlopers hiervan zijn bijvoorbeeld trilling metingen aan elektromotoren in de procesindustrie. In de meer vooruitstrevende industrieën is dat al 10-tallen jaren gemeengoed.
De historie hiervan is eigenlijk heel verrassend. Alhoewel de eerste trilling opnemers in 1938 mondjesmaat door de Amerikaanse firma Brush aangeboden werden zijn de eerste commerciële vibratie meters in 1943 tijdens de 2de wereldoorlog door het Deense Brüel & Kjear vanuit Zweden naar de markt gebracht.
We moeten ons van die metingen nog niet veel voorstellen. Alhoewel nauwkeurig, was alles handwerk, inclusief de interpretatie vanaf een vacuümbuis voltmeter of een pen-recorder.
Pas in 1965 werden de eerste FFT berekeningen op deze trilling waarnemingen uitgevoerd waardoor er ook frequentie informatie over de trillingen beschikbaar kwam.
De eerste standaard (ISO 2372) voor de evaluatie van deze trillingen kwam in 1974 beschikbaar waarmee er meer eenduidigheid bij de analyses ontstond.
Hoe relateert dit nu aan Edge computing? Verrassend eenvoudig. Door de ontwikkeling van deze eerste machine-trillingenstandaard werd de domeinkennis (wat betekenen de gemeten trillingen voor de mechanische conditie van de motoren) voor een groter publiek beschikbaar.
Niet dat het hiermee ineens voor iedereen toegankelijk werd, maar engineers die snapten wat een elektromotor was konden ineens een waardeoordeel uitspreken over de kwaliteit, of ‘gezondheidstoestand’, van een elektromotor, hoe beperkt misschien ook.
Ook nu nog is het proces van het opnemen van de gezondheidstoestand vaak nog erg manueel. Een onderhoudsengineer loopt langs de draaiende motoren en plaatst daar een trilling opnemer op die verbonden is met een handheld device. Dit registreert de trillingen, analyseert deze en slaat ze op. De engineer kan op het schermpje de status uitlezen en ziet de ‘gezondheidstoestand’ van de motor. De ruwe meetdata is hierbij omgezet in informatie. Zeg maar een ‘mobiele’ Edge computing.
Als we nu kijken naar samengestelde apparaten, zeg maar een motor, een overbrenging naar één of meerdere assen en wat hydraulica dan zijn al deze onderdelen tegenwoordig eenvoudig (en best goedkoop) te monitoren. De volgende vraag is dan: “Stuurt elke sensor zijn ‘ruwe’ data op naar de Cloud of verzamel ik deze en voeg ik de data samen en bewerk ik deze en stuur ze dan als informatie naar de Cloud”?
Als ik de brochures van de fabrikanten van ‘Edge’ devices lees is dit dé weg om te gaan. Wat ik dan weer jammer vind is dat geen van deze leveranciers aangeeft hoe ik die ruwe data moet combineren om er voor mijn toepassing bruikbare informatie van de maken.
Wat mist in al deze verhalen is de cruciale stap om de kennis van de werking en ‘gezondheid’ van de machine om te zetten in de berekeningen die door het Edge device uitgevoerd moeten worden. Het is met name dit essentiële aspect dat in de AI driven Edge computing hype ontbreekt.
Vergelijk het maar met een politicus met een megafoon na een geflopt kabinet: Veel lawaai, maar je hebt er niets aan……
