Smart Control en HMI-softwareontwerpen helpen ingenieurs bij het bouwen van nieuwe netwerken voor het IIoT

Marissa Tucker van Parker Hannifin praat met hoofdredacteur Patrick Waurzyniak

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

Ik zou een stap verder willen gaan dan de bewegingscontroller en zeggen dat de programmeerbare automatiseringscontroller [PAC] de grootste rol speelt in het IIoT. Dat komt omdat PAC's niet alleen de machinelogica hebben, maar ook motion control als onderdeel van hun routines en vaak ook een ingebouwde mens-machine-interface [HMI]. Het mooie van deze aanpak is dat het programma geen tags tussen apparaten hoeft te delen, omdat componenten zich op hetzelfde apparaat bevinden en dezelfde logica gebruiken. Deze kortere programmeertijd verkort niet alleen de IIoT-mogelijkheden.

Hier is een voorbeeld:Positiefout, die vroeger heel specifiek was voor de bewegingscontroller, is automatisch toegankelijk via de ingebouwde HMI. Als die ingebouwde HMI webservermogelijkheden heeft, wat velen van hen hebben, kan de HMI onmiddellijk een waarschuwing sturen naar de lokale operator en ook naar een fabrieksmanager via e-mail of sms [short message service]. Dit is veel beter dan de traditionele benadering waarbij de motion controller de fout naar de PLC [programmeerbare logische controller] stuurt, waarbij de PLC de gegevens dan alleen hoeft te verwerken om deze naar de HMI te sturen - die al dan niet een web Server. Deze complexe gegevensoverdracht tussen apparaten wordt geëlimineerd, omdat de logica is geschreven op één programmeersoftware die is gedownload op één hardwareapparaat. Het is zo nauw geïntegreerd dat u overal gemakkelijk informatie kunt krijgen.

Het is van cruciaal belang dat de ontwikkelaar die de ingesloten HMI maakt, verschillende gebruikersgroepen en referenties kan maken. Hierdoor kan de programmeur een aangepast exemplaar van de HMI maken, afhankelijk van de gebruiker.

Het gemak van de informatiestroom binnen de machine is belangrijk, maar dat geldt ook voor de gemakkelijke informatiestroom tussen machines. De programmeerstandaard IEC 61131-3 zorgt ervoor dat een machine die door de ene fabrikant is ontwikkeld, dezelfde taal spreekt als de andere. Dit komt integrators enorm ten goede omdat ze gemakkelijker twee verschillende machinesystemen met elkaar kunnen laten praten, een noodzakelijke stap in de richting van IIoT. Organisaties zoals OMAC [Organization for Machine Automation and Control], dat de PackML-standaard promoot, brengen IEC 61131-3 naar een hoger niveau door niet alleen aan te bevelen hoe een systeem moet worden geprogrammeerd, maar ook door een standaardset tags te ontwikkelen die machines beschikbaar moeten maken voor andere machines in het netwerk.

Hoe zit het met apparaten op laag niveau, zoals pneumatische kleppen en positiesensoren? Moet niet alles deel uitmaken van het IoT?

De uitdaging ligt in het nemen van gegevens van low-level apparaten en het omzetten ervan in bruikbare informatie. Een benadering is om de verwerking op het niveau van deze apparaten uit te voeren en de resultaten vervolgens via een krachtige controlebus of rechtstreeks naar de cloud te verzenden. Dit is een erg dure aanpak en helpt niet bij het verzamelen of centraliseren van de gegevens. Als alternatief zien we een enorme groei in de populariteit van IO-Link, een serieel-gebaseerd protocol dat basisgegevens kan verzamelen van temperatuursensoren, elektromagneten, pneumatische klepverdeelstukken, enz., zonder dure overheadkosten.

Door de bus eenvoudig te laten, kunnen deze gegevens worden verzameld en bruikbaar gemaakt door verwerking op de PAC of PLC die in elk machinesysteem moet bestaan. Door gebruik te maken van een PAC, die ook een ingebouwde HMI heeft voor webpublicatie, kunnen gebruikers die informatie vervolgens meenemen en op het netwerk plaatsen, waar het ook heen moet. Stel je een pneumatisch systeem voor met een sensor die het geluid continu in decibel bewaakt. De enige data die naar een PAC IO-Link gestuurd hoeft te worden, is de huidige dB. De PAC kan aangepaste IEC 61131-3-functieblokken hebben die door de fabrikant zijn ontwikkeld en die op meerdere controllers kunnen werken. Deze functieblokken kunnen controleren of er een vreemd patroon in het geluid is, om te zeggen:"Ah, er is mogelijk een lek." De programmeur kan die waarschuwing aannemen en een bericht sturen naar een onderhoudsniveaugebruiker van de HMI voordat de pneumatiek uitvalt .

Hoe komt de informatie van de machine naar de cloud en hoe zit het met de software die erbij betrokken is?

Er is nog steeds een grote scheiding tussen de werkvloer en IT. Zeker voor productiebedrijven met meerdere vestigingen in verschillende staten of landen is het opslaan van data op een externe server of de cloud ideaal. Wat de software betreft, moeten fabrikanten van componenten helpen om het leven van machinebouwers zo gemakkelijk mogelijk te maken wanneer ze met IT werken.

De meeste machinebouwers zijn comfortabel met het programmeren van een PLC of PAC in IEC of vergelijkbare talen, dus bedrijven moeten op zoek gaan naar fabrikanten die een geïntegreerde benadering van machinebesturing hanteren om de informatiestroom gemakkelijk te maken maar die het ook gemakkelijk maken om die informatie te delen met IT-servers. Een andere standaard die uit Europa wordt verdreven, is OPC-UA [OPC Unified Architecture]. Dit client-serverprotocol is aanzienlijk uitgebreid, waardoor een universele manier mogelijk is om gegevens van machine naar machine, machine naar SCADA of machine naar server over te dragen. Door zijn flexibiliteit is OPC-UA hard op weg om de IoT-standaard te worden. Zoek naar leveranciers die softwaretools hebben ingebouwd om eenvoudig een OPC-UA-verbinding te maken met slechts een paar klikken en waarmee ontwikkelaars gegevens kunnen delen door simpelweg een paar tags te delen binnen een IEC 61131-3-programma. Zodra het toegankelijk is op een server, laat IT de rest doen.

Is de informatie nuttig in de cloud? Hoe komen de kritieke gegevens in de handen van de operator, op de fabrieksvloer?

Het hangt af van het gebruik. Iedereen die aan IIoT denkt, of het nu een machinebediener, OEM-machinebouwer of fabriekseigenaar is, moet eerst een use case ontwikkelen. Een manager op de fabrieksvloer wil bijvoorbeeld informatie over de algehele effectiviteit van apparatuur [OEE]. Dit soort informatie is meestal niet iets dat gedeeld moet worden met een bredere publieke sfeer, dus het is het beste om een ​​interne server te gebruiken. Managers op de fabrieksvloer zijn echter vaak ver van de machine verwijderd, of niet aan hun bureau, maar moeten toch naar OEE kijken. De use case stuurt de oplossing:als de machine een ingebouwde HMI met een webserver heeft, kan een gebruiker er verbinding mee maken vanaf een iOS- of een Android-platform, zijn of haar inloggegevens invoeren en de OEE van de machine bekijken, geen externe cloud nodig . Dit fabrieksnetwerk wordt vaak 'fog' computing genoemd.

Een ander voorbeeld is een inkoper die de opbrengstgegevens voor meerdere fabriekslijnen op meerdere locaties moet controleren. Een externe server is het enige antwoord. Om het risico op het vrijgeven van gevoelige bedrijfsinformatie te minimaliseren, kan het programma alleen de totale output publiceren in plaats van de opbrengsten. Hoewel deze oplossing het gebruik van een cloudserver vereist, illustreert het de noodzaak om terughoudendheid te betrachten bij het verzenden van gegevens naar een externe server om twee redenen:over het algemeen is het minder veilig dan het op een intern of 'fog' netwerk te houden, en de meeste plannen bedrijven in rekening brengen voor het verzenden en opslaan van gegevens naar een externe cloud.

Marketeers hebben goed werk geleverd door Industrie 4.0 te promoten, maar elke gebruiker moet een stapje terug doen en vragen:'Hoe kan ik de informatie gebruiken?' De cloud is misschien niet zo noodzakelijk zoals je zou denken.

Drijft al deze connectiviteit niet de kosten op?

Het kan, maar het hoeft niet. Waar het duur wordt, is drie of vier jaar in de toekomst, wanneer uw bedrijf klaar is voor IoT, maar u apparaten hebt gespecificeerd die het moeilijk of onmogelijk maken om te communiceren via webserver of OPC-UA, of u koos voor traditioneel, gefragmenteerd ontwerp in plaats van PAC's voor één machine die de gegevensstroom aanzienlijk eenvoudiger maken. Om deze fout te verkleinen, kunt u ongelooflijk dure sensoren kopen die van temperatuurregeling rechtstreeks naar een externe cloud gaan, waarbij alle andere apparaten op de machine worden omzeild. Van daaruit moet je een hele aangepaste laag of website programmeren met de software van iemand anders om de gegevens bruikbaar te maken. Je wilt deze man niet zijn.

In plaats daarvan implementeert u IIoT slim:maak het vanaf dag één onderdeel van het machineontwerp. Als u een nieuwe applicatie bouwt, bevindt u zich in de perfecte positie om over te stappen, ook al overweegt uw organisatie dit nu niet. De keuzes die u vandaag maakt, kunnen later honderdduizenden dollars besparen.

Selecteer ook low-level apparaten die bussen ondersteunen, zoals IO-Link, zodat je er voordelig data uit kunt halen. Gebruik standaardprotocollen die kosteneffectief zijn en waarmee u gegevens uit vele bronnen kunt gebruiken. Gebruik een enkele programmeersoftware op een enkele controller om het programmeren te vereenvoudigen. Zorg ervoor dat de machinecontroller de mogelijkheid heeft voor een client-server-relatie zonder dat er per se een extra gateway nodig is. Op die manier kunt u, als u informatie naar verschillende locaties moet routeren, dit rechtstreeks in uw op IEC gebaseerde programma doen. Vergeet mistcomputing niet. Als uw PLC een ingebouwde HMI heeft die geschikt is voor webservers, kunt u mogelijk aan al uw IIoT-gebruiksscenario's voldoen zonder het gebruik van een cloud. En als het toch nodig is, zorg er dan voor dat de controller die je kiest software heeft die het gemakkelijk maakt om te delen met een OPC-UA-server, zodat IT kan doen waar IT goed in is.

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