De mens als mechatronische schakel

Angelo Hulshout heeft een ambitieus plan om fabrieken efficiënter te maken met behulp van Smart Industry-technologieën als het internet of things, cloud en machine learning. In Mechatronica&Machinebouw rapporteert hij over de voortgang van zijn inspanningen.

Angelo Hulshout is onafhankelijke software-expert, lid van het Brainport High Tech Software Cluster.

19 maart 2021

Mechatronica is een samentrekking van mechanica en elektronica. Volgens sommigen zit er ergens ook software in verstopt; zij houden het op een samentrekking van mechanica, elektronica en informatica. Daar is wat voor te zeggen, want er zijn weinig mechatronische systemen waar geen software in zit, en nog minder die kunnen functioneren als die software het om een of andere reden niet doet.

Foto: Luke Chesser op Unsplash

Dat was ook waar we onlangs tegenaan liepen in een onderzoekje dat we voor Shinchoku mochten doen. De software functioneerde wel, zowel op het mes-systeem van de fabriek waar we waren, als op de aanwezige plc’s, maar om onduidelijke redenen vielen er gaten in de informatie die we uit ‘het systeem’ dachten te kunnen halen. Zo heeft het even geduurd voor we in de gaten hadden waarom we uit de data die het mes-pakket genereert niet konden achterhalen hoelang een bepaalde bewerking op een product duurt – en dan geen gemiddelde, maar per product. De theoretische tijd was bekend en met een stopwatch erbij konden we die ook wel bevestigen voor een tiental producten die langskwamen tijdens een productierun, maar de mes-resultaten varieerden van die gemeten tijd tot een veelvoud daarvan.

Na wat heen en weer discussiëren en hard nadenken besloten we nog een keer te gaan meten. Dat is er nooit van gekomen, omdat we op de werkvloer aangekomen ons realiseerden wat er aan de hand was. De producten voor een productierun (typisch 10 tot 50 stuks) worden in deze fabriek voorzien van een barcode. Die wordt voorafgaand aan de bewerking gescand en na afloop weer, door een operator met een handscanner – en daar lag de oorzaak van ons probleem. De bedoeling was ooit dat het proces voor de operator zou bestaan uit vier stappen: barcode scannen, product in de machine, product uit de machine, barcode scannen. Omdat er tussen stap 2 en 3 een wachttijd zit van zo’n 45 seconden waarin de bewerking wordt uitgevoerd, is het veel efficiënter om de barcodes van de andere producten alvast te scannen en aan het eind van de rit ze weer allemaal te scannen. Daardoor zagen wij de bewerkingstijd variëren van pakweg 45 seconden tot diezelfde tijd vermenigvuldigd met het aantal te bewerken producten.

Het systeem is mechanisch correct opgezet, elektrisch ook, en de meetfunctie in de software werkt ook. Helaas was de menselijke schakel hier vergeten.

Echt meten is weten

In heel veel mechatronische systemen en dus in heel veel fabrieken worden nog onverwacht veel handmatige acties verricht. Gevolg daarvan is dat productie niet altijd zo verloopt als gepland – mensen zijn nu eenmaal geen robotjes, en dat is maar goed ook. Een medewerker die niet snel genoeg is, kunnen we daarop bijsturen, evenals een die acties vergeet uit te voeren. Dat gaat jaren goed, en in een systeemontwerp kunnen we er rekening mee houden: instructies op een scherm zetten, waarschuwingssignalen geven, voorbereid zijn op vertraging op de ‘interfaces’ tussen mens en machine.

Tegelijkertijd zijn mensen ook heel goed in staat processen waarin ze werken te optimaliseren voor zichzelf – wat dan juist kan leiden tot versnellingen in plaats van vertragingen. Tot het moment dat we het totale systeem en de individuele stappen willen gaan meten. Dan blijkt dat die lokale optimalisaties wel effectief zijn, maar niet meetbaar in de context van het proces dat oorspronkelijk was ontworpen.

Bij het verzamelen en analyseren van data, met als doel processen te optimaliseren en fabrieken slimmer te maken, is dit een extra uitdaging. Meten is weten, maar dan moet wat je denkt te meten wel zijn wat je echt meet – en niet een onbekende afgeleide daarvan.

Omdat we nu kijken naar machine learning-oplossingen, waarbij algoritmes op basis van een model van een fabriek de data gaan analyseren en verbetervoorstellen doen, ontstaat een interessante vraag. In machine learning kunnen we algoritmes maken die deels met bekende data werken, dat wil zeggen: data waarvan ze de betekenis kennen, en data waarvoor dat niet geldt. De algoritmes kunnen patronen herkennen in die data (oorzaak en gevolg is een simpel voorbeeld), die in vervolgstappen toch gebruikt kunnen worden voor verbetervoorstellen. Zou het mogelijk zijn om foutieve ‘bekende data’ te identificeren door ze te koppelen met onbekende data, om zo de menselijke optimalisaties te identificeren en correct te interpreteren? Of moeten we eerst onze manier van data-acquisitie aanpassen, zodat de menselijke optimalisaties ofwel onzichtbaar worden, ofwel onderdeel worden van een aangepaste systeemdefinitie en bijbehorend model?

Zekere voor het onzekere

In het ‘batchscan’-voorbeeld wordt inmiddels gewerkt aan een aanpasing waarbij de barcode wordt gelezen op het moment dat het product in bewerking wordt genomen en direct daarna. Daarmee kan de operator blijven doen wat hij altijd deed, afgezien van het handmatig scannen. Richting machine learning nemen we nog even het zekere voor het onzekere en proberen we de bestaande systeemdefinitie te handhaven ondanks de invloed van de mens als mechatronische schakel.