Is IT/OT-convergentie echt alleen een buzzword? De ware waarde ontrafeld

Dus, is "IT/OT-convergentie" gewoon nog een gimmick buzz-term?

U kunt argumenteren dat het zo is. Telkens als iemand een nieuw idee pikt, is er een poging om het memorabel te maken en te laten klinken als "het beste nieuwe ding sinds gesneden brood." Natuurlijk zal iemand een vinnige zin bedenken die verandering moet inspireren en die ze voor marketing kunnen gebruiken.

Het ding is echter, deze "convergentie" van IT en OT is eigenlijk gewoon de volgende uitbreiding van data bruikbaar maken.

Wat is IT/OT-convergentie?

Enkele tijd geleden zagen we de start van automatisering in productie. Geautomatiseerde apparatuur was ontworpen om een specifieke functie uit te voeren die op een snelheid of vermogensniveau moest worden uitgevoerd dat mensen niet konden bereiken. Maar toen de geautomatiseerde apparatuur faalde, moest de controle-ingenieur in het systeem duiken om te bepalen wat er mis was. Dit vereiste in de registers van de PLC-systemen te kijken naar aanwijzingen van de fout. Dit was de start van operationele technologie (OT) data-gebruik.

Het hebben van wat data leidend tot het moment van storing was goed voor diagnostiek – om te zien wat er vooraf ging. Als resultaat begonnen PLC-systemen historians te gebruiken om langere stromen data van sensoren, verwarmers, en automatiseringsactuatoren op te slaan – met grote hoeveelheden OT-data.

Door de OT-data van historians te monitoren, konden SCADA-functies operators inzicht geven in hoe de apparatuur werkte. Wanneer een storing dreigde, gaven SCADA-functies operators (of supervisors) een kans om actie te ondernemen voordat de storing plaatsvond. Dit vereiste dat het SCADA-systeem toegang had tot de data van historians, en gebruikte proprietaire communicatie zoals MODBUS of PROFIBUS om die data beschikbaar te maken voor operators via human-machine interfaces (HMI's). Maar de monitoring was exclusief voor de prestaties van de apparatuur, wat het gebruik van OT-data verder uitbreidde.

Door observatie van deze datastromen (meters, operatorschermen, enz.) en door meer te begrijpen over de drift van data, kon men herkennen – via de SCADA-systemen – niet alleen wanneer storing van apparatuur dreigde, maar dat de data ook gebruikt kon worden om fouten in productkwaliteit bij test en inspectie te analyseren – operaties die misschien verschillende stappen later in het proces waren.

Dit creëerde de noodzaak om OT-data te koppelen aan IT-data. Het resulteerde in de creatie van complexe interfaces van PLC's en SCADA naar informatietechnologie (IT) systemen zoals MES, waardoor relationele data van productfouten gekoppeld kon worden aan operationele data van de apparatuur die het product maakte. Sommigen probeerden het direct naar ERP (en proberen nog steeds), maar ERP-systemen zijn niet uitgerust om die data snel genoeg en in voldoende detail te verwerken en presenteren in relatie tot andere gebeurtenissen tijdens het productieproces.

Het probleem met de interfaces naar MES is dat ze hoog gecustomiseerd en duur zijn, soms tot 40-50% van de implementatiekosten voor een project toevoegend. De volgende stap in verbetering van data-toegang zou zijn om PLC-data meer toegankelijk te maken voor MES en andere relationele databases. Toen deze noodzaak voor toegang gecombineerd werd met de dalende kosten van computing en computermemory en netwerkcommunicatie stabieler werd (kom 5G-netwerken), maakte het zin om PLC-sensoren en actuatoren direct aan IT-netwerken te koppelen (wat we IIoT noemen) en hun data beschikbaar te maken voor... wie het ook nodig had.

Al deze achtergrond is om te benadrukken dat het beschikbaarder maken van OT-data voor IT-systemen simpelweg de volgende stap in een langere proces is van de technologie-evolutie die ons naar Industrie 4.0 bracht.

Hoe kan IT/OT-convergentie gebruikt worden?

De interfacing van OT-data aan IT-systemen stuit nu op een nieuw probleem.

De PLC/SCADA-systemen die sensoren in historians monitoren, kunnen grote stromen data (tot megabytes grootte) binnen seconden creëren. Vanuit het perspectief van het begrijpen van de karakterisering van een gebeurtenis terug naar de IT-systemen, is deze stroom data – zelfs in kleine tijdframes – simpelweg te veel voor de relationele databases van IT-systemen zoals MES om te hanteren. Veel implementaties hebben geprobeerd een instantie van sensordata (genomen uit een stroom data) te registreren om een enkel data-element vast te leggen, om een representatie van OT-gebeurtenissen op IT-niveau te proberen. Velen ontdekten echter dat het koppelen van een instantie van OT-data aan een kwaliteitsgebeurtenis van een product tijdens productie niet erg effectief is voor het monitoren van de kwaliteit van een proces in het algemeen.

We moeten nu manieren bepalen om stromen data van OT-systemen te aggregeren op een manier die de belangrijke kenmerken van een productiegebeurtenis behoudt. Het rapporteren van OEE is een van deze pogingen tot aggregatie. Het is belangrijk te erkennen dat bij het gebruik van elke vorm van data-aggregatie, er enige verlies zal zijn van de belangrijke details van een kwaliteitsgebeurtenis. Daarom wordt OEE gebruikt als een monitoring-level data-object en niet als een analyse-level object. Echter, door de real-time waarde van OEE te monitoren, kan een IT-systeem de snelheid en omvang van de veranderingen herkennen en een alarm creëren om op een probleem te waarschuwen.

Om dat daadwerkelijke probleem te analyseren, moet u teruggaan naar de oorspronkelijke datastroom die gebruikt werd om de OEE-waarde te creëren. Tenminste met de OEE-waarde die in real-time wordt geleverd, krijgen productie- en controle-ingenieurs zichtbaarheid op een issue vroeg genoeg zodat ze terug kunnen gaan naar de historian voor analyse voordat de gebeurtenis begraven wordt door meer data uit de OT-datastroom.

Het vraagstuk is: hoe aggregeert u de data?

Het antwoord, zoals altijd, is... het hangt ervan af!

Hoe de data geaggregeerd moet worden, hangt af van welke data u aggregeert en wat u probeert te monitoren binnen het proces. Het hangt ook af van het kunnen interpreteren van veranderingen in het data-aggregatiemodel.

In deze sectie zal ik kijken naar één dergelijke aggregatiemethode en enkele manieren presenteren om veranderingen in deze dataset te interpreteren.

De "natuurlijke verdelingscurve" of histogram is een van de meest voorkomende grafische weergaven van data van apparaten zoals sensoren. De primaire premisse van de curve is dat, als er alleen normale willekeurige variatie in een proces is, de verdeling van de instanties van data in een patroon zal vallen dat lijkt op een natuurlijke verdelingscurve.

Figuur 1 toont hoe de verdeling van metingen van een ovensensor eruit zou kunnen zien met normale variatie wanneer geplot in een histogram.

Figuur 1: Verdelingscurve van oventemperatuur met gemiddelde, mediaan, en modus. Met dank aan de auteur.

De kernkenmerken van de curve zijn dat het gemiddelde (mean), mediaan (middelste waarde van de datastroom), en de modus (waarde met de meest voorkomende) allemaal ongeveer gelijk zijn. Dit kan als referentie gebruikt worden om te bepalen of het proces problemen ervaart. Zolang er een indicatie is dat het proces in controle is, is er waarde in het bepalen van de +/-3 sigma waarden en het vergelijken met de boven- en ondergrens en de productspecificatielimieten.

Een voorbeeldscenario

Om het proces van een productie-eenheid die door een verhardingsoven gaat te monitoren, zou het MES-systeem de tijd noteren dat de eenheid de oven binnenkwam en verliet. Tijdens deze tijd zou het PLC-systeem (met een slimme sensor) een constante stroom temperatuursensordata creëren die opgeslagen zou worden in een lokale historian-database in het sensortoestel. Toen de productie-eenheid de oven verliet, zou het MES een verzoek doen aan het toestel voor een aggregaat van de temperatuurdata gedurende die gedefinieerde periode. Zelfs met beperkte rekencapaciteit op toestelniveau, kon het toestel honderden (of zelfs duizenden) datapunten nemen en een set geaggregeerde data terugsturen naar het MES – in plaats van een enkele instantie van de sensordata te leveren, zoals typisch, of te proberen de gehele datastroom te verwerken.

Het volgende zou een set geaggregeerde datawaarden zijn voor deze productie-eenheid:

• Gemiddelde (Mean): 90.0
• Mediaan: zou heel dicht bij 90.0 liggen
• Modus: ongeveer 90.0 graden ook
• +/- 3 Sigma verdeling: 87.0, 93.0 (te verifiëren met UCL en LCL)

Door een snelle analyse van de verschillen tussen gemiddelde, mediaan en modus, kan het MES kijken naar acceptabele procescontrole monitoring alsook trending veranderingen van eerdere productie-eenheden die al door de oven zijn gegaan. Als de +/- 3 sigma waarden buiten acceptabele grenzen vallen, zou het MES de productie-eenheid automatisch als verdacht vlaggen, evenals als het gemiddelde, mediaan, of modus significant verschillen van elkaar of van eerdere producten.

Figuur 2 presenteert een voorbeeld van hoe deze zelfde waarden een proces zouden aanduiden dat niet in controle was. In dit geval is het nog steeds mogelijk dat de +/- 3 sigma waarden binnen grenzen liggen.

Figuur 2: Voorbeeld verschillen van gemiddelde, mediaan, en modus in een scheef proces. Met dank aan de auteur.

Nu, technisch gezien, als de verdeling scheef is zoals getoond, zouden de +/- 3 sigma waarden mogelijk niet geldig beschouwd worden als gevolg van de scheefheid van de dataset. Maar de directe analyse door het toestel kan nog steeds gebruikt worden om te bepalen of de controlegrenzen zijn geschonden.

Het kernpunt: als dit het soort dataset is dat wordt geleverd door een slimme sensor, is het een indicatie voor productietechniek dat de oven niet werkt met alleen willekeurige variantie – en dus onderzocht moet worden.

Andere verschillen in gemiddelde, mediaan, en modus (bijv. gemiddelde en mediaan zijn gelijk, maar modus is anders) kunnen ook condities aangeven zoals een bimodale verdeling die wijst op meerdere procesinvloeden. Opnieuw, productietechniek zou in het proces moeten kijken.

Wanneer de bovengenoemde datasets direct gekoppeld zijn aan de productie-eenheid op MES-niveau, kan deze data gebruikt worden – met test- en inspectieresultaten – om aan te geven of er een link is tussen variatie in oventemperatuur en de fout van de productie-eenheid.

Of het product nu faalde als gevolg van de procesproblemen of niet, het zien van datawaarden die driften tijdens een productieloop kan ook fundamentele procesmanagementproblemen aangeven die onderzocht moeten worden.

Samenvatting

De voorgaande voorbeelden van data-aggregatie reflecteren alleen een specifiek scenario, maar ze zijn bedoeld om een blik te geven op de redenen voor de convergentie van OT- en IT-data alsook de potentiële waarde van deze convergentie. In elk productiescenario moet de juiste methode van data-aggregatie geëvalueerd worden, en de programmering van slimme toestellen moet deze functionaliteit beschikbaar maken. Of, als alternatief, edge computing systemen zouden geprogrammeerd moeten worden om de functionaliteit te vervangen die beschreven is voor de slimme toestellen.

De kern is dat, hoewel de industrie "IT/OT-convergentie" zwaar gebruikt als een buzz-term om veranderende technologie te beschrijven, er een legitieme verandering in dataverwerking is die de technologie achter de buzz-term levert. Bedrijven die voordeel trekken uit de technologie van convergentie, en die leren om data van het OT-niveau correct te aggregeren en te interpreteren zodat systemen op IT-niveau ermee om kunnen gaan, kunnen praktische voordelen behalen in de effectiviteit van kwaliteits- en faciliteitsmanagementprogramma's. In de huidige competitieve wereldomgeving is het gebruik van elk voordeel goed voor de bottom line.

Dus het antwoord is nee. IT/OT-convergentie is niet alleen een buzz-term. Het is een waardevol instrument in de evolutie van data-acquisitie en management-technologie dat productiebedrijven enorm kan baaten. Leren hoe data van het OT-niveau te aggregeren zodat systemen op IT-niveau ermee om kunnen gaan, is een belangrijk deel van de convergentie.