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

IIoT en Industrie 4.0 zijn alomtegenwoordige onderwerpen op de huidige industriële beurzen en in blogposts. Veel producten beloven u te helpen bij het realiseren van verticale integratie van productiestromen en gegevens en bedrijfssoftware zoals ERP. Maar meestal zit er ook een addertje onder het gras: ofwel krijgt u zeer complexe producten met een even schokkend prijskaartje, ofwel raakt u, ondanks de belofte van IIoT van volledige interoperabiliteit tussen verschillende leveranciers, gebonden aan één leverancier, vooral als u softwareoplossingen overweegt die door leveranciers van productiemachines in combinatie met hun apparatuur worden verkocht.

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 op natuurlijke wijze gegroeid en daardoor inherent complex. Het is gebaseerd op een verouderd ERP-systeem dat is uitgebreid met op maat gemaakte PHP-webapplicaties en interfaces naar andere softwareproducten (bijv. 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 verschillende standaard industriële interconnecties (digitale IO's, Profinet, EtherCat, standaard ethernet). Volgens de specificaties van de leverancier wordt slechts één standaard ethernetinterface blootgesteld aan de netwerkinfrastructuur van de klant. Deze interface is aangesloten op het algemene PLC-systeem van de machinefabrikant 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 gevuld als de fabriek gebruikmaakt van de productieplanningssoftware van de machinefabrikant die op de PLC van de machine draait. Daarom bleek deze interface op dit moment niet erg nuttig voor mijn klant, maar de situatie kan veranderen.

De eerste stappen

Als eerste stap was het doel om gegevens rechtstreeks van de onderdelen van de machine te verkrijgen.

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

In plaats van maatwerkprogrammering kiest de klant dus voor een integratieplatform met een vooraf gebouwde OPC UA-connector, een gebruiksvriendelijke interface en de mogelijkheid om verbinding te maken met backoffice-systemen zoals ERP, CRM, diverse documentbeheersystemen of databases – zowel lokaal als in de cloud – en een redelijke prijs.

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 bevindt de nieuwe technologie zich nog in een aanpassingsproces, waardoor het robotlassysteem slechts in één ploegendienst werkt en de machine zelfs tijdens de werkuren niet continu draait. Daarom kunnen de gegevens die op dit moment worden verzameld weliswaar nuttig zijn, maar ook onbetrouwbaar blijken voor toekomstig gebruik of voorspellende doeleinden. Dit is gebaseerd op de ervaring van de klant met gegevens die zijn verzameld van andere productiemachines, bijvoorbeeld lasersnijmachines. Bepaalde factoren – bijvoorbeeld of de machineoperator aanwezig was toen een productiecyclus werd voltooid, toen de gegevensverzameling werd geactiveerd – hebben aangetoond dat zelfs schijnbaar zeer nauwkeurige gegevens een verkeerd beeld kunnen geven en dat een fijne granulariteit niet altijd nodig 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 op dit moment een uitdaging; bovendien is het camerasysteem gekoppeld aan de PLC van de hele machine en lijkt het niet toegankelijk te zijn voor externe klanten.

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

Werkingsperiodes, stroomverbruik, …

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 het verzamelen van logberichten van machines. Mijn klant had in het verleden de ervaring dat niet alle machines hun logbestanden bijhouden na een herstart. Bovendien melden machineoperators storingen en fouten niet altijd nauwkeurig aan hun leidinggevenden. Dit kan leiden tot onnodig lange stilstand van machines wanneer zich een ernstige storing voordoet. Of de machine op deze dag überhaupt heeft gedraaid, is een belangrijke vraag.

Om het technisch management van het bedrijf gemakkelijk toegang te geven, worden dergelijke dagelijkse rapporten gegenereerd als pdf-bestanden en opgeslagen in een gedeelde Dropbox, voor het geval er een ondersteuningsverzoek bij de leverancier van de machine moet worden ingediend.

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 I/O's indien niet anders mogelijk) om nauwkeurige start-/stoptijden van productiecycli te verkrijgen.

In combinatie met het urenregistratiesysteem van het bedrijf zal dit een beter inzicht geven in hoeveel tijd de machine daadwerkelijk in productie is en hoeveel tijd wordt besteed aan het aanleren (robotprogrammering) en/of laden/lossen/onderhoud.;

Toegang tot camerasysteem: aangezien laserlassen een ander lasproces is, moeten de klanten van mijn klant deze productiemethode certificeren voordat er daadwerkelijk producten worden geleverd. Dergelijke processen zullen veel gemakkelijker te realiseren zijn als er 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 hoogvermogenlasertoepassingen (waar hij ervaring opdeed in lasertechnologie, FEM-simulaties, industriële robotica, PLC-programmering en industriële veldbussystemen) en heeft hij meer dan 10 jaar ervaring in algemene IT met een focus op softwareontwikkeling in MKB-omgevingen (voornamelijk interfaces tussen verschillende softwareproducten en productieplanningsapplicaties). Hij heeft een masterdiploma in wiskunde van de Universiteit van Wenen.