Zeker weten veel van jullie weten of zelfs hebben gezien hoe grote geautomatiseerde objecten worden beheerd, zoals een kerncentrale of een fabriek met veel productielijnen: de belangrijkste acties vinden vaak plaats in een grote ruimte, vol met schermen, lampen en bedieningspanelen. Dit beheersysteem wordt doorgaans aangeduid als GSchU — het hoofdbeheerscherm voor de controle van het productieobject.
Zeker hebben jullie je afgevraagd hoe dit alles werkt vanuit zowel hardware- als softwareperspectief, en wat deze systemen onderscheidt van reguliere persoonlijke computers. In dit artikel gaan we onderzoeken hoe verschillende gegevens op de GSchU komen, hoe opdrachten naar de apparatuur worden verzonden en wat je eigenlijk nodig hebt om een compressorstations, een propaanproductie-installatie, een autolijn of zelfs een rioolpomppunt te beheren.
De onderste laag of veldbus — dat is waar alles begint.
Deze onduidelijke termen voor leken worden gebruikt om de communicatiemiddelen tussen microcontrollers en de aangesloten apparatuur, zoals in- en uitgangen of meetapparatuur, te beschrijven. Gewoonlijk wordt deze communicatiekanaal een 'veldbus' genoemd, omdat het verantwoordelijk is voor het verzenden van gegevens naar de controller die vanuit het 'veld' komen.
'Veld' is een diepgaand professioneel begrip dat het feit aanduidt dat bepaalde apparatuur (zoals sensoren of actuatoren) waarmee de controller interactie heeft, zich ergens ver weg bevindt, buiten, op het veld, onder de nachtelijke hemel. En het maakt niet uit dat de sensor zich op een halve meter van de controller bevindt en bijvoorbeeld de temperatuur in een automatiek kast meet; het wordt nog steeds beschouwd als 'in het veld'. Meestal overbruggen de signalen van sensoren die naar in- en uitgangen komen afstanden van tientallen tot honderden meters (of soms zelfs meer), terwijl ze informatie verzamelen van verre locaties of apparatuur. Daarom wordt de bus waarmee de controller waarden ontvangt van deze sensoren doorgaans de veldbus genoemd, of minder vaak de onderste laag of industriële bus.
Algemeen schema van automatisering van een industrieel object
Dus, het elektrische signaal van de sensor reist een bepaalde afstand langs kabelverbindingen (meestal door een gewone koperen kabel met een aantal aderen), waarop meerdere sensoren zijn aangesloten. Vervolgens komt het signaal in de verwerkingsmodule (in- en uitvoermodule), waar het wordt omgezet in een begrijpelijke digitale taal voor de controller. Daarna bereikt dit signaal via de veldbus de controller, waar het definitief wordt verwerkt. De logica van de microcontroller is gebaseerd op deze signalen.
Bovenste niveau: van een lichtsnoer tot een volledige werkstation
Het bovenste niveau verwijst naar alles wat een gewone operator kan aanraken, die het technologische proces beheert. In de eenvoudigste vorm vertegenwoordigt het bovenste niveau een set lampjes en knoppen. De lampjes signaleren de operator over bepaalde gebeurtenissen in het systeem, en de knoppen zijn bedoeld om opdrachten naar de controller te sturen. Dit systeem wordt vaak een 'lichtsnoer' of 'kerstboom' genoemd, omdat het er zeer vergelijkbaar uitziet (zoals te zien op de foto aan het begin van het artikel).
Als de operator geluk heeft, krijgt hij een bedieningspaneel als bovenste niveau — een soort platte computer die op de een of andere manier gegevens van de controller ontvangt en deze op het scherm weergeeft. Dit paneel is meestal gemonteerd op de automatiseringskast, waardoor interactie meestal staand moet gebeuren, wat ongemak veroorzaakt, en de kwaliteit en grootte van het beeld op kleinere panelen vaak te wensen overlaat.
En tenslotte, de attractie van ongekende vrijgevigheid — een werkstation (of zelfs meerdere duplicaten), dat een gewone persoonlijke computer is.
De apparatuur van het bovenste niveau moet op een of andere manier interactie hebben met de microcontroller (anders zou het niet nodig zijn?). Voor deze interactie worden protocollen van het bovenste niveau en een transmissiemedium, bijvoorbeeld Ethernet of UART, gebruikt. In het geval van de 'kerstboom' zijn zulke ingewikkeldheden uiteraard niet nodig; de lampjes worden aangestoken met gewone fysieke lijnen, zonder ingewikkelde interfaces en protocollen.
Over het algemeen is dit hogere niveau minder interessant dan de veldbus, aangezien dit hogere niveau geheel afwezig kan zijn (in de zin dat de operator daar niets te zien heeft, de controller zal zelf begrijpen wat er gedaan moet worden).
"Oude" datatransmissieprotocollen: Modbus en HART
Weinig mensen weten het, maar op de zevende dag van de schepping rustte God niet uit, maar creëerde Hij Modbus. Net als het HART-protocol is Modbus wellicht het oudste industriële datatransmissieprotocol, het werd al in 1979 geïntroduceerd.
In het begin werd een seriële interface gebruikt voor de transmissie, later werd Modbus geïmplementeerd bovenop TCP/IP. Dit is een synchronisch protocol volgens het ‘master-slave’ (hoofd-ondergeschikte) principe, waarbij het principe van ‘verzoek-antwoord’ wordt gebruikt. Het protocol is vrij zwaar en traag, de communicatiesnelheid is afhankelijk van de kenmerken van de ontvanger en de zender, maar over het algemeen gaat het om honderden milliseconden, vooral bij de implementatie via de seriële interface.
Bovendien is het Modbus-datatransmissieregister 16-bits, wat meteen beperkingen oplegt aan de overdracht van real- en double-typen. Ze worden gedeeltelijk of met verlies van precisie verzonden. Hoewel Modbus nog steeds veel gebruikt wordt in situaties waar geen hoge communicatiesnelheid vereist is en waar het verlies van verzonden gegevens niet kritiek is. Veel fabrikanten van verschillende apparaten houden ervan om het Modbus-protocol op hun eigen unieke en zeer originele manier uit te breiden door niet-standaardfuncties toe te voegen. Daarom heeft dit protocol veel mutaties en afwijkingen van de norm, maar het leeft nog steeds succesvol in de moderne wereld.
Het HART-protocol bestaat ook al sinds de jaren tachtig, dit is een industrieel protocol voor communicatie via een tweedraads- stroomlus, waarin 4-20 mA sensoren en andere apparaten met HART-ondersteuning rechtstreeks zijn aangesloten.
Voor het schakelen van HART-lijnen worden speciale apparaten gebruikt, de zogenaamde HART-modems. Er zijn ook converters die de gebruiker aan de output bijvoorbeeld het Modbus-protocol bieden.
De HART is opmerkelijk, omdat naast de analoge signalen van de 4-20 mA sensoren ook een digitaal signaal van het protocol wordt verzonden, waardoor de digitale en analoge componenten in één kabel kunnen worden verbonden. Moderne HART-modems kunnen worden aangesloten op de USB-poort van de controller, verbinding maken via Bluetooth, of op de traditionele manier via de seriële poort. Tien jaar geleden, naar analogie met Wi-Fi, verscheen ook de draadloze standaard WirelessHART, die werkt binnen het ISM-bereik.
De tweede generatie protocollen of niet-helemaal industriële bussen zoals ISA, PCI(e) en VME
In plaats van de Modbus- en HART-protocollen kwamen niet-helemaal industriële bussen zoals ISA (MicroPC, PC/104) of PCI/PCIe (CompactPCI, CompactPCI Serial, StacPC), evenals VME.
Er is een tijdperk aangebroken van rekeneenheden die beschikken over een universele databus waarop verschillende kaarten (modules) kunnen worden aangesloten voor de verwerking van een bepaalde uniforme signaal. In dit geval wordt de processor module (rekeneenheid) in een zogenaamde behuizing geplaatst, die de interactie via de bus met andere apparaten mogelijk maakt. De behuizing, of zoals echte automatiseerders het graag noemen, "crate", wordt aangevuld met de noodzakelijke in- en uitvoermodules: analoge, digitale, interface, enzovoort, of dit alles wordt samengevoegd in de vorm van een sandwich zonder behuizing — één kaart bovenop de andere. Vervolgens wisselen deze diversiteit op de bus (ISA, PCI, enz.) gegevens uit met de processor module, die op deze manier informatie van sensoren ontvangt en een bepaalde logica uitvoert.
Controller en in- en uitvoermodules in de PXI-behuizing op de PCI-bus. Bron:
Er is niet veel mis met deze ISA, PCI(e) en VME bussen, vooral niet voor die tijd: de snelheid van gegevensuitwisseling is niet teleurstellend, en de systeemcomponenten zijn compact en handig in één behuizing geplaatst, terwijl onmiddellijke vervanging van in- en uitvoerkaarten misschien niet beschikbaar is, maar het is ook nog niet echt noodzakelijk.
Maar er is een lepel teer, en niet één. Het is behoorlijk moeilijk om een gedistribueerd systeem op te bouwen in deze configuratie; de bus voor gegevensuitwisseling is lokaal, je moet iets bedenken voor de gegevensuitwisseling met andere ondergeschikte of gelijkwaardige knooppunten, zoals Modbus over TCP/IP of een ander protocol. Kortom, er zijn niet veel gemakken. En nog een niet zo prettige zaak: input-outputkaarten verwachten doorgaans een gestandaardiseerd signaal op hun ingangen, en ze hebben geen galvanische isolatie met het veldapparatuur, dus je moet een ingewikkeld systeem van verschillende conversiemodules en tussenliggende schakelingen bouwen, wat de componentenbasis enorm complicates.
Tussentijdse conversiemodules met galvanische isolatie. Bron:
‘Wat is er met het communicatieprotocol over de industriële bus?’ zult u vragen. En niets. Het is er niet in deze uitvoering. Via kabelverbindingen komt het signaal van de sensoren bij de signaalconverters, die een spanning op de discrete of analoge input-outputkaart genereren, en de gegevens van de kaart worden gelezen via de in-/uitgangspoorten, met de middelen van het besturingssysteem. En geen gespecialiseerde protocollen.
Hoe moderne industriële bussen en protocollen werken
En wat nu? Tegenwoordig is de klassieke ideologie voor het bouwen van geautomatiseerde systemen een beetje veranderd. Veel factoren hebben een rol gespeeld, van de noodzaak dat automatisering ook gebruiksvriendelijk moet zijn, tot de trend naar gedistribueerde geautomatiseerde systemen met van elkaar verwijderde knooppunten.
Het kan gerust gezegd worden dat er tegenwoordig twee hoofdconcepten zijn voor het bouwen van automatiseringssystemen: gelokaliseerde en gedistribueerde geautomatiseerde systemen.
In het geval van gelokaliseerde systemen, waar gegevensverzameling en beheer gecentraliseerd zijn op een specifieke plaats, is er behoefte aan een concept van een bepaalde set invoer-/uitvoermodules die met elkaar zijn verbonden via een gemeenschappelijke snelle bus, inclusief een controller met zijn eigen communicatieprotocol. Dit betekent doorgaans dat de invoer-/uitvoermodules ook een signaalomzetter en galvanische isolatie omvatten (hoewel dat natuurlijk niet altijd het geval is). De eindgebruiker hoeft in principe alleen maar te begrijpen welke soorten sensoren en mechanismen aanwezig zullen zijn in het geautomatiseerde systeem, het aantal benodigde invoer-/uitvoermodules voor verschillende types signalen te tellen en ze in één gezamenlijke lijn met de controller te verbinden. In dit geval gebruikt elke fabrikant doorgaans zijn favoriete communicatieprotocol tussen de invoer-/uitvoermodules en de controller, en hier kunnen talloze varianten van zijn.
In het geval van gedistribueerde systemen geldt alles wat gezegd is over gelokaliseerde systemen, met de aanvulling dat het belangrijk is dat afzonderlijke componenten, zoals een set invoer-/uitvoermodules plus een apparaat voor gegevensverzameling en -overdracht — een niet al te slimme microcontroller die ergens in een hut op het veld staat, naast een kraan die olie afsluit — in staat zijn om te communiceren met soortgelijke knooppunten en met de hoofdcontroller op grote afstand met een efficiënte snelheid van gegevensoverdracht.
Hoe kiezen ontwikkelaars een protocol voor hun project? Alle moderne communicatieprotocollen bieden vrij hoge prestaties, daarom wordt de keuze voor een bepaalde fabrikant vaak niet bepaald door de snelheid van gegevensoverdracht via deze industriële bus. Evenmin is de implementatie van het protocol zelf van groot belang, omdat het voor de systeemontwikkelaar toch een zwarte doos zal zijn die een bepaalde interne structuur van gegevensoverdracht biedt en niet is bedoeld voor externe interventie. Vaak wordt er meer aandacht besteed aan praktische kenmerken: de prestaties van de rekeneenheid, het gebruiksgemak van de fabrikant-concepten voor de gestelde taak, de beschikbaarheid van de benodigde types invoer-/uitvoermodules, de mogelijkheid van hot-swapping van modules zonder de bus te onderbreken, enzovoort.
Populaire leveranciers van apparatuur bieden hun eigen implementaties van industriële protocollen aan: bijvoorbeeld, het bekende bedrijf Siemens ontwikkelt zijn eigen serie protocollen Profinet en Profibus, het bedrijf B&R - het Powerlink protocol, Rockwell Automation - het EtherNet/IP protocol. Een binnenlandse oplossing in deze lijst van voorbeelden is de versie van het FBUS protocol van het Russische bedrijf Fastwel.
Er zijn ook meer universele oplossingen die niet aan een specifieke fabrikant zijn gebonden, zoals EtherCAT en CAN. We zullen deze protocollen grondig bespreken in de vervolgartikelen en bekijken welke het beste geschikt zijn voor specifieke toepassingen: de auto- en luchtvaartindustrie, de productie van elektronica, positioneringssystemen en robotica. Blijf op de hoogte!
Bron: habr.com
