Wat zou je willen weten als baas van een fabriek?

De afgelopen maand heb ik weer wat meters proberen te maken met mijn Smart Industry-project – dat inmiddels de naam Shinchoku (進捗, Japans voor ‘vooruitgang’ of ‘innovatie’) heeft. Zoals ik eerder schreef, is het heel interessant om data uit een fabriek te ‘trekken’ en deze vervolgens te gebruiken om te analyseren en uit te vinden waar er ruimte is voor procesverbeteringen. Dat is technisch interessant, maar het moet natuurlijk ook zakelijk interessant zijn.

Niemand zit te wachten op het gemiddelde toerental van de motor van een transportband, of het aantal keren dat een doseerklep onder een silo open- en dichtgaat. Tenminste, niet rechtstreeks. Het toerental op zich is niet interessant, maar wellicht wel het stroomverbruik dat bij dat toerental hoort. Stroom kost immers geld en kosten willen we graag minimaliseren. Ook interessant is het aantal uren per dag dat het toerental 0 is – dan staat de betreffende transportband stil. Nu is dat bij een transportband niet zo erg, maar bij veel andere machines betekent stilstand dat er niet wordt geproduceerd – en dus geen geld verdiend.

Kort gezegd: data uit de fabriek halen is mogelijk, maar we moeten er wel die data uithalen waar de fabriek zakelijk iets aan heeft. Dat lijkt een open deur, maar gesprekken in de afgelopen twee maanden laten iets anders zien. Zodra ik aan tafel zit met een directeur of productiemanager, is het duidelijk: processen optimaliseren betekent kosten besparen en opbrengsten verhogen, net als overal.

Een gesprek met een operator of it-manager geeft een heel ander beeld: zij zijn vooral geïnteresseerd in de operationele status van lopende opdrachten – welke stap is uitgevoerd, wanneer is die afgelopen, is de juiste hoeveelheid materiaal gebruikt? Dat is informatie die vaak al wordt verzameld en bijgehouden in bijvoorbeeld een mes-systeem.

Uiteindelijk willen ze natuurlijk allemaal hetzelfde. Wat we nodig hebben, is een koppeling tussen de operationele data over de productie en de machinedata die daaronder ligt.

Minder doorzichtig

Een voorbeeld uit mijn eigen recente ervaring. Een batch mengvoer produceren bestaat uit een aantal stappen: automatisch doseren van grondstoffen, handmatige bijstort toevoegen, product mengen en malen en daarna brokjes maken (extrusie). Voor elke stap kennen we de theoretische kengetallen van de operatie: de doseertijd per gewicht voor doseersystemen, de mengtijd van een mengsysteem, de kooktijd van een extrusiesysteem en de snelheden van transportsystemen (lopende banden, rollenbanen, agv’s, enzovoorts). Maar er is een reden dat dit theoretische kengetallen zijn: de praktijk is altijd net anders. Soms doseert een materiaal wat moeilijker of wat makkelijker, is er een verstopping in een extrusieleiding of hapert een transportsysteem even omdat er iemand langs een veiligheidssensor loopt. Of op een hoger niveau: het duurt even voordat uit een silo gedoseerd kan worden, stomweg omdat die nog gevuld moet worden.

Als ik nu die theoretische kengetallen heb en vanuit de realiteit de operationele data en de machinedata van de diverse systemen, kan ik gaan achterhalen waar zich problemen voordoen en waarom. Stel dat een gemiddelde productietijd voor een batch bekend is en we zien dat bij een bepaald product die tijd veel hoger is. Dan kan een onderzoek bijvoorbeeld laten zien dat de tijd van sommige doseringen veel hoger is dan van andere. De reden? Een plakkerig materiaal (beendermeel) of een materiaal dat snel inklinkt (kalk) en daardoor moeilijker doseert.

Als productietijd echt geld is, dan kunnen we op basis hiervan op zoek naar een oplossing. We kunnen gaan kijken naar de parameters van het doseersysteem onder de silo, de samenstelling van het materiaal en wellicht nog andere oplossingen. Allemaal op basis van productie- en machinedata.

Nu is dit een eenvoudig voorbeeld, dat een beetje ervaren operator ook zonder geautomatiseerd systeem wel doorziet. Er zijn echter ook scenario’s die veel minder doorzichtig zijn. Om die op te sporen, kan een geautomatiseerd systeem wel uitkomst brengen.

In eerste instantie door de data te verzamelen in een rapportagesysteem, waarmee de tegenwoordig erg hippe ‘dashboards’ gevuld kunnen worden. Daarna zouden we de data echter ook kunnen voeren aan een machine learning-algoritme, dat op basis van specifieke parameters op zoek gaat naar oplossingen voor gevonden bottlenecks en andere problemen.

Uitkomst

Of en hoe dat gaat werken, is een uitzoekwerkje voor de komende maanden, waar we inmiddels mee aan de slag zijn gegaan. Dat doen we naast het slimmer maken van de domme fabrieken waar ik vorige keer over schreef. Ook uit een machine die geen controller (plc) heeft, kunnen we data halen. Een elektromotor loopt als er stroom loopt door de spoelen. Die stroom kun je detecteren, en zelfs meten, om te bepalen of de motor loopt, hoe hard die loopt en zelfs welke kant hij op draait. Zo komen we van analoge data (de schrijfblok en de stroommeter) via digitale data (productie- en machinedata) tot automatische procesverbetering (machine learning).

Maar het levert pas echt iets op als we weten wat de productie drijft en wat dus voor de baas van de fabriek belangrijk is. Ik heb me hier even beperkt tot ‘tijd is geld’, maar er zijn ook fabrieken waarvoor geldt ‘kwaliteit is geld’. Daar zou de vraag bijvoorbeeld kunnen zijn: hoe komt het dat 5 tot 8 procent van de producten die uit mijn fabriek rolt niet door de kwaliteitscontrole komt? Ook daar kan machinedata als aanvulling op de kwaliteitsdata uitkomst bieden: we kunnen afwijkingen in het product proberen te koppelen aan deelbewerkingen die door verschillende machines worden gedaan om de oorzaak te vinden. Een andere soort data, een andere soort analyse, maar wel op basis van dezelfde principes: operationele data, machinedata en theoretische kengetallen koppelen.

We zijn weer een stap verder, Shinchoku!

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