Casestudie: Eerste stappen op weg naar IIoT in een mkb-omgeving

IIoT en Industry 4.0 zijn alomtegenwoordige onderwerpen in de industriebeurzen en blogposts van vandaag. Veel producten beloven u te helpen bij de verticale integratie van productiestroom en gegevens en bedrijfssoftware zoals ERP. Maar meestal zit er ook een addertje onder het gras: of u krijgt zeer complexe producten met een eveneens schokkend prijskaartje - of ondanks IIoT's belofte van volledige cross-vendor interoperabiliteit raakt u vendor-locked, vooral als u softwareoplossingen overweegt die door verkopers van productiemachines worden verkocht in combinatie met hun apparatuur.

Voor kleinere bedrijven met beperkte middelen en kleine of eenpersoons IT-afdelingen is dit een dilemma. Hoewel dergelijke bedrijven afhankelijk zijn van flexibiliteit om te kunnen concurreren met grotere ondernemingen en dus paradigma's zoals Industrie 4.0 moeten invoeren, gaat dit meestal gepaard met een enorme investering en een muur van schijnbaar onoverkomelijke technische complexiteit.

In deze casestudy zal ik ten eerste laten zien hoe een software-integratieplatform met kant-en-klare connectoren voor machinedatacommunicatie kan helpen om deze beperkingen te overwinnen. En ten tweede, wat de eerste praktische toepassingen kunnen zijn voor realtime machinegegevens in een kleine fabriek die zijn reis naar het Industriële Internet der Dingen begint.

Over de klant en zijn eisen

De klant is een kleine industriële leverancier van voornamelijk roestvrijstalen plaatwerkproducten met kleine batchgroottes en een complexe productportefeuille.

Om op dit gebied met andere fabrikanten te kunnen concurreren, heeft de fabriek technologische vooruitgang en een constante evolutie van het productieproces nodig. Daarom is de klant begonnen met de invoering van ultramodern gerobotiseerd laserlassen in het productieproces.

Afgezien van het proces zelf is de integratie van een dergelijke gerobotiseerde lasoplossing in de productieplanning, het verkrijgen van de nodige gegevens voor kostenberekening, kwaliteitscontrole enz. een andere uitdaging.

De IT-omgeving van de klant

Het IT-landschap van de klant is natuurlijk gegroeid en daarom inherent complex. De basis wordt gevormd door een verouderd ERP-systeem dat wordt uitgebreid met op maat gemaakte webgebaseerde PHP-toepassingen en interfaces met andere softwareproducten (bv. CAD, CAM zoals lasernestingsoftware, ...) en klantsystemen voor directe gegevensuitwisseling. Dit alles binnen een gemengde Windows/Linux-serveromgeving en een bijna uitsluitend op Windows gebaseerde clientpool in een Active Directory. Bestandsdiensten zijn voornamelijk gebaseerd op Windows shares en (in mindere mate) op Dropbox.

In het algemeen bestaat de strategie van de klant erin de complexiteit van zijn IT-infrastructuur te verminderen door te proberen het aantal verschillende gebruikte technologieën (LAMP-stacks, AD, Windows, O365, legacysystemen, enz.) te verminderen, en zo de beheersbaarheid te vergroten en de onderhoudskosten van het hele ecosysteem te verlagen.

De productieomgeving

Productiemachines hebben meestal een inherent lange gebruiksperiode. Daarom zijn niet alle machines uitgerust voor Industrie 4.0-toepassingen of bieden ze zeer beperkte functionaliteit op dit gebied. Daarom richt dit artikel zich uitsluitend op de toepassing van robotlassen en de integratiebehoeften daarvan.

Het lassysteem is een kant-en-klare oplossing van een bekende fabrikant bestaande uit een vaste-stoflaserbron, een robot met draai-kieptafel, een bewerkingskop met een camerasysteem, een beschermingscel die nodig is voor lasertoepassingen met een hoog vermogen, besturingssystemen en hulpsystemen (afzuiging, stofopvang, koeling).

De componenten van dit systeem communiceren via een verscheidenheid van standaard industriële interconnecties (digitale IO's, Profinet, EtherCat, standaard ethernet). Volgens de specificaties van de leverancier is slechts één standaard ethernetinterface toegankelijk voor de netwerkinfrastructuur van de klant. Deze interface is verbonden met het algemene PLC-systeem van de machineleverancier en biedt slechts zeer beperkte toegang tot de gegevens en het besturingssysteem van de machine. Het biedt een OPC UA-interface met minder dan 10 datapunten die alleen worden ingevuld als de fabriek de productieplanningssoftware van de machineleverancier gebruikt die op de PLC van de machine draait. Daarom bleek deze interface op dit moment niet al te nuttig voor mijn klant, maar de situatie kan veranderen.

De eerste stappen

Als eerste stap was het de bedoeling rechtstreeks gegevens te verkrijgen van de componenten van de machine.

De klant koos voor het OPC UA-communicatieprotocol, dat steeds gangbaarder wordt in de PLC's en machines van vandaag. Hoewel deze standaard kan worden gebruikt om real-time communicatie tot stand te brengen en derhalve functies kan vervangen die momenteel door industriële veldbussystemen worden geïmplementeerd, zijn real-time mogelijkheden in ons scenario niet noodzakelijk. Hoewel SDK's beschikbaar zijn voor directe integratie van de OPC UA-stack in de toepassing van mijn klant, zijn deze meestal ingewikkeld en dus in tegenspraak met het doel de complexiteit te verminderen.

Dus in plaats van codering op maat kiest de klant voor een integratieplatform met een vooraf gebouwde OPC UA-connector met een gebruiksvriendelijke interface en de mogelijkheid om verbinding te maken met back-officesystemen zoals ERP, CRM, verschillende documentbeheersystemen of databases - lokaal en in de cloud - en een redelijk prijskaartje.

Rechtstreekse besturing van deze systemen via het integratieplatform is geen doel, aangezien dit mogelijk in strijd zou kunnen zijn met het beginsel van één enkel controlepunt, dat noodzakelijk is voor de veiligheid van de machine.

Frequentie van gegevenspeiling

In deze fabriek doorloopt de nieuwe technologie het aanpassingsproces, zodat het robotlassysteem slechts in één ploegendienst werkt en de machine zelfs tijdens de werkuren niet constant draait. Daarom kunnen de op dit moment verkregen gegevens nuttig zijn, maar ook onbetrouwbaar blijken voor toekomstig gebruik of voor voorspellende doeleinden. Dit is gebaseerd op de ervaring van de klant met gegevens die zijn verzameld van andere productiemachines, bv. lasersnijmachines. Bepaalde factoren - of de machinebediener aanwezig was toen een productiecyclus eindigde, wanneer de gegevensverzameling in gang werd gezet - bewezen dat zelfs schijnbaar zeer nauwkeurige gegevens een verkeerd beeld kunnen schetsen, en dat fijnkorreligheid niet altijd noodzakelijk is om de efficiëntie van het productieproces te beoordelen.

Daarom wordt momenteel een vrij lage polling-frequentie van 30 seconden gebruikt voor het verzamelen van gegevens.

In deze eerste stap zou de klant gegevens van deze 3 hoofdcomponenten willen opvragen:

de laserbron,

de PLC van de robot,

het camerasysteem.

Op dit moment kan echter alleen de laserbron worden aangesloten. Andere componenten kunnen niet worden geïntegreerd: de PLC van de robot heeft alleen de OPC Classic interface, en de overgang naar de Unified Architecture is momenteel een uitdaging; en het camerasysteem is gekoppeld aan de PLC van de gehele machine en lijkt niet toegankelijk te zijn voor externe clients.

OPC UA voor de laserbron

Dan blijft de laserbron over. Gelukkig is dit systeem uitgerust met een ultramoderne controller die is voorzien van een geavanceerde OPC UA-interface met verschillende toegangsniveaus: anonieme toegang met beperkte leesmogelijkheden, read-only, read-and-write. Zoals eerder vermeld, was lees-en-schrijftoegang uit den boze om redenen van machineveiligheid. Daarom werd gekozen voor read-only toegang.

Deze interface biedt een overvloed aan gegevens:

Algemene toestand van het lasersysteem

Werkingsduur, gebruikte stroom, ...

Fout- en onderhoudsmeldingen

Met het integratieplatform ontwikkelde de klant een Windows service in C# om periodiek de gegevens op te vragen en deze te compileren in verschillende SQL-databasetabellen voor toekomstig gebruik. De tabellen kunnen informatie bevatten zoals algemene gegevens, gebruik van apparatuur, tabellen voor onderhoud/foutmeldingen die door de laserbron worden geproduceerd.

Een grote vraag: hoe deze machinegegevens te gebruiken

Het eerste waardevolle inzicht is de compilatie van machine log berichten. De ervaring van mijn klant in het verleden was dat niet alle machines hun logbestanden bijhouden tijdens herstarts. Ook melden machineoperators storingen en fouten niet altijd nauwkeurig aan hun supervisors. Dit kan resulteren in langer dan noodzakelijke machinestilstand wanneer zich een ernstige storing voordoet. Of de machine op die dag wel draaide - is een belangrijke vraag.

Voor gemakkelijke toegang door het technisch management van het bedrijf, worden dergelijke dagelijkse rapporten gegenereerd als PDF-bestanden en opgeslagen in een gedeelde Dropbox, voor het geval er een ondersteuningsgesprek met de leverancier van de machine moet worden geopend.

Natuurlijk is dit momenteel slechts een zeer beperkte toepassing van de immense mogelijkheden van de OPC UA connector. De volgende stappen die de klant aan het ontwikkelen is, zijn:

Verbinding met de PLC van de robot (via digitale IO's indien niet anders mogelijk) om nauwkeurige start/stop-timing van productiecycli te verkrijgen.

In combinatie met het timesheetsysteem van het bedrijf zal dit een beter inzicht geven in hoeveel tijd de machine daadwerkelijk in productie is en hoeveel tijd wordt gebruikt voor onderwijs (robotprogrammering) en/of laden/lossen/onderhoud;

Toegang tot het camerasysteem: aangezien laserlassen een ander lasproces is, moeten de klanten van mijn cliënt deze productiemethode certificeren voordat er echte producten worden geleverd. Dergelijke processen kunnen veel gemakkelijker worden verwezenlijkt als voortdurend en automatisch volledige documentatie van het lasproces kan worden geleverd.

Met de geplande vermindering van de complexiteit en de gebruikte diensten is bovendien een overstap van Dropbox-Shared naar OneDrive op handen, zodra dit bij alle betrokken klanten is uitgerold. De klant is ook geïnteresseerd in mogelijke gegevensanalyse voor voorspellend onderhoud.

Conclusie

Zoals hierboven geschreven, bevindt dit project zich in de opstartfase en is het nog lang geen volledig functionele IIoT-oplossing. Door te kiezen voor een integratieplatform met vooraf gebouwde connectoren in plaats van de hele integratie te programmeren, kon ik voorkomen dat ik me moest verdiepen in de details van weer een andere connectiestack (zoals OPC UA of de Dropbox API). En voor mijn klant bood het een gecentraliseerde communicatiestack voor toekomstige toepassingen.

Over Richard Majer

Richard Majer, oprichter van flupo Systemtechnik e.U., gespecialiseerd in industriële IT en automatiseringstechnologie voor het MKB. Voordat hij zijn eigen bedrijf startte, werkte Richard in een R&D-instituut voor high-power lasertoepassingen (waar hij ervaring opdeed in lasertechnologie, FEM-simulaties, industriële robotica, PLC-programmering, industriële veldbussystemen), en heeft hij meer dan 10 jaar ervaring in algemene IT met een focus op software-ontwikkeling in MKB-omgevingen (voornamelijk interfaces tussen verschillende softwareproducten en toepassingen voor productieplanning). Hij heeft een mastergraad in wiskunde van de Universiteit van Wenen.