Slimme besturing & HMI-software: Engineers in staat stellen next-gen IIoT-netwerken te bouwen

Parker Hannifin's Marissa Tucker in gesprek met Senior Editor Patrick Waurzyniak

Marissa, wat is de rol van de motion controller in het Industrial Internet of Things [IIoT], en welke software is betrokken?

Ik zou het een stap verder nemen dan de motion controller en zeggen dat de programmeerbare automatiseringscontroller [PAC] de grootste rol speelt in het IIoT. Dat is omdat, naast het hebben van de machinelogica, PACs de motion control als onderdeel van hun routines bevatten en vaak een embedded human-machine interface [HMI] hebben. De schoonheid van deze benadering is dat het programma geen tags hoeft te delen tussen apparaten omdat componenten op hetzelfde apparaat zitten met dezelfde logica. Niet alleen slaat dit programmeertijd op, het vergemakkelijkt ook IIoT-mogelijkheden.

Hier is een voorbeeld: Positiefout - die vroeger heel specifiek was voor de motion controller - is automatisch toegankelijk voor de embedded HMI. Als die embedded HMI webserver-mogelijkheden heeft, wat velen wel hebben, kan de HMI direct een waarschuwing sturen naar de lokale operator en ook naar een plantmanager via e-mail of SMS [short message service]. Dit is veel beter dan de traditionele benadering van de motion controller die de fout naar de PLC [programmable logic controller] stuurt, waar de PLC de data moet verwerken om het daarna naar de HMI te sturen - wat wel of geen webserver heeft. Deze complexe dataoverdracht tussen apparaten wordt geëlimineerd, omdat de logica op één programmeersoftware geschreven is en op één hardware-apparaat gedownload wordt. Het is zo strak geïntegreerd dat je gemakkelijk overal informatie kunt krijgen.

Het waarborgen dat de ontwikkelaar die de embedded HMI creëert, verschillende gebruikersgroepen en inloggegevens kan maken, is cruciaal. Dit stelt de programmeur in staat om een aangepaste instantie van de HMI te creëren, afhankelijk van de gebruiker.

De gemakkelijkheid van informatiestroom binnen de machine is belangrijk, maar ook de gemakkelijkheid van informatiestroom tussen machines. De IEC 61131-3 programmeerstandaard zorgt ervoor dat een machine ontwikkeld door één fabrikant dezelfde taal spreekt als een andere. Dit baat integrators enorm omdat ze twee verschillende machinesystemen veel makkelijker met elkaar kunnen laten praten, een noodzakelijke stap naar IIoT. Organisaties als OMAC [Organization for Machine Automation and Control], die de PackML-standaard promoten, brengen IEC 61131-3 naar het volgende niveau door niet alleen aan te bevelen hoe een systeem geprogrammeerd moet worden, maar ook door een standaardset tags te ontwikkelen die machines beschikbaar moeten stellen aan andere machines in het netwerk.

Wat is met low-level apparaten, zoals pneumatische kleppen en positionsensoren? Hoort alles niet deel te zijn van de IoT?

De uitdaging ligt in het nemen van data van low-level apparaten en het omzetten ervan in nuttige informatie. Een aanpak is om verwerking op het niveau van deze apparaten te doen en de resultaten dan te sturen via een high-performance control bus of direct naar de cloud. Dit is een zeer dure aanpak en helpt niet om data te verzamelen of te centraliseren. Alternatief zien we enorme groei in de populariteit van IO-Link, een serieel protocol dat basisdata kan verzamelen van temperatuursensoren, solenoidventielen, pneumatische klepmanifolds, etc., zonder dure overhead.

Door de bus simpel te houden, kan deze data verzameld en nuttig gemaakt worden door verwerking op de PAC of PLC die in elk machinesysteem moet bestaan. Door voor een PAC te kiezen, die ook een embedded HMI heeft voor webpublicatie, kunnen gebruikers die informatie dan op het netwerk zetten, waar het ook moet gaan. Stel je een pneumatisch systeem voor met een sensor die continu geluid in decibels monitort. De enige data die naar een PAC IO-Link hoeft te gaan is de huidige dB. De PAC kan custom IEC 61131-3 functieblokken hebben ontwikkeld door de fabrikant die op meerdere controllers kunnen werken. Deze functieblokken kunnen controleren of er een vreemd patroon in het geluid zit, om te zeggen: 'Ah, er kan een lekkage zijn.' De programmeur kan die waarschuwing nemen en een bericht sturen naar een onderhoudsgebruiker van de HMI voordat de pneumatica faalt.

Hoe komt de informatie van de machine naar de cloud, en wat is met de betrokken software?

Er is nog steeds een grote kloof tussen de shopvloer en IT. Vooral voor productiebedrijven met meerdere faciliteiten in verschillende staten of landen, is het opslaan van data op een externe server of de cloud ideaal. Van de softwarekant moeten componentfabrikanten helpen om het leven van machinebouwers zo makkelijk mogelijk te maken bij het werken met IT.

De meeste machinebouwers zijn comfortabel met het programmeren van een PLC of PAC in IEC of vergelijkbare talen, dus bedrijven moeten zoeken naar fabrikanten die een geïntegreerde benadering van machinebesturing hanteren om de informatiestroom makkelijk te maken, maar die ook makkelijk maken om die informatie te delen met IT-servers. Een andere standaard die uit Europa gedreven wordt is OPC-UA [OPC Unified Architecture]. Dit client-server-protocol is aanzienlijk uitgebreid, wat een universele manier toestaat om data te overdragen ofwel machine-naar-machine, machine-naar-SCADA, of machine-naar-server. Vanwege zijn flexibiliteit wordt OPC-UA snel de IoT-standaard. Zoek naar leveranciers die softwaretools ingebouwd hebben om in een paar klikken eenvoudig een OPC-UA-verbinding te maken en ontwikkelaars toe te staan data te delen door simpelweg een paar tags binnen een IEC 61131-3-programma te delen. Eenmaal toegankelijk op een server, laat IT de rest doen.

Is de informatie nuttig in de cloud? Hoe komt de kritieke data in de handen van de operator, op de shopvloer?

Het hangt af van de use case. Iedereen die nadenkt over IIoT, of het nu een machineoperator, OEM-machinebouwer of fabrikanteigenaar is, moet eerst een use case ontwikkelen. Een shopvloermanager wil bijvoorbeeld overall equipment effectiveness [OEE]-informatie. Dit type informatie is meestal niet iets wat gedeeld hoeft te worden met een bredere publiekssfeer, dus het is best om een interne server te gebruiken. Echter, shopvloermanagers kunnen vaak ver van de machine zijn, of niet achter hun bureau, maar toch nog moeten kijken naar OEE. De use case drijft de oplossing: Als de machine een embedded HMI met een webserver heeft, kan een gebruiker ervanuit verbinden vanaf een iOS- of Android-platform, zijn inloggegevens invoeren, en de machines' OEE bekijken, geen externe cloud nodig. Dit in-fabrieksnetwerk wordt vaak aangeduid als 'fog' computing.

Een ander voorbeeld is een inkoopagent die opbrengstdata moet monitoren voor meerdere fabriekslijnen op meerdere locaties. Een externe server is het enige antwoord. Om het risico van het blootleggen van gevoelige bedrijfsinformatie te minimaliseren, kan het programma alleen de totale output publiceren, in plaats van opbrengsten. Hoewel deze oplossing de gebruik van een cloud-server vereist, illustreert het de noodzaak om terughoudend te zijn bij het sturen van data naar een externe server om twee redenen: doorgaans is het minder veilig dan het houden op een interne of 'fog'-netwerk, en de meeste abonnementen rekenen bedrijven voor het sturen en opslaan van data naar een externe cloud.

Marketeers hebben een geweldige werk gedaan om Industry 4.0 te promoten, maar elke gebruiker moet een stap terugzetten en vragen: 'Hoe kan ik de informatie gebruiken?' De cloud is misschien niet zo noodzakelijk als je denkt.

Drijft al deze connectiviteit de kosten niet op?

Het kan, maar het hoeft niet. Waar het duur wordt is drie of vier jaar in de toekomst, wanneer jouw bedrijf klaar is voor IoT, maar je apparaten hebt gespecificeerd die het moeilijk of onmogelijk maken om te communiceren via webserver of OPC-UA, of je hebt gekozen voor traditioneel, gefragmenteerd ontwerp in plaats van single-machine PACs die dataflow aanzienlijk makkelijker maken. Om deze fout te verminderen, kun je ongelooflijk dure sensoren kopen die van temperatuurcontrole rechtstreeks naar een externe cloud gaan, alle andere apparaten op de machine omzeilend. Daar vanaf moet je een hele aangepaste laag of website programmeren met andermans software om de data nuttig te maken. Je wilt niet diegene zijn.

In plaats daarvan, implementeer IIoT slim: maak het onderdeel van het machineontwerp op dag één. Als je een nieuwe applicatie bouwt, ben je in de perfecte positie om over te stappen, zelfs als het niet iets is waar je organisatie nu over nadenkt. De keuzes die je vandaag maakt, kunnen later honderdduizenden dollars besparen.

Selecteer ook low-level apparaten die bussen zoals IO-Link ondersteunen, zodat je data er goedkoop uit kunt halen. Gebruik standaardprotocollen die kosteneffectief zijn en je toestaan data van veel bronnen te gebruiken. Gebruik één programmeersoftware op één controller om programmering te vereenvoudigen. Zorg dat de machinecontroller de mogelijkheid heeft voor een client-server-relatie zonder noodzakelijk een extra gateway te vereisen. Op die manier, als je wel informatie naar verschillende locaties moet routeren, kun je dat direct in je IEC-gebaseerde programma doen. Vergeet fog computing niet. Als je PLC een embedded HMI heeft die webserver-capabel is, kun je misschien al je IIoT use cases voldoen zonder een cloud te gebruiken. En als je dat wel moet, zorg dan dat de controller die je kiest software heeft die het makkelijk maakt om te delen met een OPC-UA-server, zodat IT kan doen wat IT het beste doet.

Slimme keuzes maken het converteren naar IIoT heel betaalbaar, maar de keuzes moeten nu gemaakt worden.