Sikkert kender mange af jer eller har endda set, hvordan store automatiserede anlæg styres, for eksempel et atomkraftværk eller en fabrik med mange produktionslinjer: det primære ophold finder ofte sted i et stort rum med masser af skærme, lamper og kontrolpaneler. Denne kontrolkompleks kaldes normalt GShU - hovedkontrolskærm til overvågning af produktionsanlægget.
Sikkert har du været nysgerrig på, hvordan det hele fungerer fra både hardware- og softwareperspektiv, og hvordan disse systemer adskiller sig fra almindelige personlige computere. I denne artikel vil vi undersøge, hvordan forskellige data kommer ind i GShU, hvordan der gives kommandoer til udstyret, og hvad der overhovedet kræves for at styre en kompressorstation, en propanproduktionsenhed, en samlebånd eller endda en spildevandspumpeanlæg.
Niveauet nederst eller feltbussen - det, hvor alt begynder
Denne uklare samling af ord bruges, når man skal beskrive kommunikationsmidlerne mellem mikrocontrollere og det tilsluttede udstyr, for eksempel input-output-moduler eller måleinstrumenter. Normalt kaldes denne kommunikationskanal 'feltbuss', fordi den er ansvarlig for at overføre data fra 'feltet' til controlleren.
«Feltet» er et dybt professionelt begreb, der angiver, at noget udstyr (for eksempel sensorer eller aktuatorer), som controlleren interagerer med, befinder sig langt, langt væk, udenfor, på markerne, under nattens mørke. Og det betyder ikke noget, at sensoren kan være placeret en halv meter fra controlleren og måle for eksempel temperaturen i automatikskabet; det anses stadig for at være 'i feltet'. Oftest skal signalerne fra sensorerne, der kommer ind i input-output-modulerne, stadig dække afstande fra titusind til hundrede meter (og nogle gange mere), hvilket indsamler information fra fjerntliggende steder eller udstyr. Det er derfor, busserne, hvor controlleren modtager værdier fra disse sensorer, normalt kaldes feltbusser eller sjældnere underliggende busser eller industrielle busser.
Overordnet skema for automatisering af industrielt anlæg
Så, det elektriske signal fra sensoren rejser en vis afstand gennem kabellinjer (ofte gennem almindelige kobberkabler med et vist antal ledninger), som flere sensorer tilsluttes. Derefter når signalet behandlingsmodulet (input-output modul), hvor det omdannes til et sprog, som kontrolsystemet kan forstå. Herefter sendes dette signal direkte til controlleren gennem feltbussen, hvor det endeligt behandles. Logikken i mikrokontrollerens funktion bygger på sådanne signaler.
Øverste niveau: fra lyskæde til en hel arbejdsstation
Øverste niveau refererer til alt, hvad en almindelig operatør, der styrer den teknologiske proces, kan røre ved. I den simpleste form består det øverste niveau af et sæt lamper og knapper. Lamperne signalerer til operatøren om bestemte begivenheder i systemet, mens knapperne bruges til at afgive kommandoer til controlleren. Et sådant system kaldes ofte en "lyskæde" eller "juletræ", fordi det ser meget lignende ud (som man kan se på billedet i begyndelsen af artiklen).
Hvis operatøren er heldigere, får han en operatørpanel — en form for fladskærmscomputer, der på en eller anden måde modtager data til visning fra controlleren og viser dem på skærmen. Dette panel monteres typisk på selve automationsskabet, så man som regel står op for at interagere med det, hvilket kan være besværligt. Desuden efterlader billedkvaliteten og størrelsen på de kompakte paneler meget tilbage at ønske.
Og endelig, en stor generøsitet — en arbejdsstation (eller måske flere duplikerende), som er en almindelig personlig computer.
Udstyret på det øverste niveau skal på en eller anden måde interagere med mikrokontrolleren (ellers hvorfor skulle det være nødvendigt?). Til denne interaktion bruges protokoller på det øverste niveau og et transmissionsmedium, f.eks. Ethernet eller UART. I tilfælde af "juletræet" er sådanne indviklinger selvfølgelig ikke nødvendige; lamperne tændes ved hjælp af almindelige fysiske ledninger, der er ingen komplicerede grænseflader og protokoller.
Overordnet set er dette overniveau mindre interessant end feltbus, da dette overniveau slet ikke nødvendigvis findes (af typen, at operatøren ikke har noget at se på, kontroleren klarer selv, hvad der skal gøres).
"Gamle" datatransmissionsprotokoller: Modbus og HART
Mange ved det ikke, men på den syvende dag af verdens skabelse hvilede Gud ikke, men skabte Modbus. Sammen med HART-protokollen er Modbus måske den ældste industrielle datatransmissionsprotokol, og den blev introduceret helt tilbage i 1979.
Oprindeligt blev en sekventiel grænseflade brugt til transmission, og senere blev Modbus implementeret over TCP/IP. Det er en synkron protokol baseret på en "master-slave" (hoved-underordnet) model, hvor principperne "anmodning-svar" anvendes. Protokollen er temmelig tung og langsom, og hastigheden på udvekslingen afhænger af modtagerens og senderens egenskaber, men normalt måles det næsten i hundrede millisekunder, især i implementeringen gennem den sekventielle grænseflade.
Desuden er Modbus datastrukturen 16-bit, hvilket straks begrænser transmissionen af real- og double-typer. De overføres enten i bidder eller med tab af præcision. Selvom Modbus stadig anvendes bredt i tilfælde, hvor høj udvekslingshastighed ikke er nødvendig, og tab af transmitte data ikke er kritisk. Mange producenter af forskellige enheder kan lide at udvide Modbus-protokollen på deres egen unikke og meget originale måde ved at tilføje ikke-standardfunktioner. Derfor har denne protokol mange mutationer og afvigelser fra normen, men lever stadig godt i den moderne verden.
HART-protokollen har også eksisteret siden 1980'erne; det er en industriel kommunikationsprotokol over en to-leder strømloop, hvori 4-20 mA sensorer og andre HART-understøttede instrumenter tilsluttes direkte.
Der anvendes specielle enheder til at forbinde HART-linjer, såkaldte HART-modemer. Der findes også convertere, der leverer brugeren et output, eksempelvis i Modbus-protokol.
HART er bemærkelsesværdig, ikke mindst fordi den udover analoge signalsystemer 4-20 mA også overfører et digitalt signal fra selve protokollen, hvilket gør det muligt at kombinere digitale og analoge dele i én kabelstrækning. Moderne HART-modemer kan tilsluttes USB-porten på kontrolleren, forbinde via Bluetooth, eller på den gammeldags måde gennem en seriestorport. For ti år siden kom der en trådløs standard, WirelessHART, inspireret af Wi-Fi, som opererer i ISM-båndet.
Det andet generation af protokoller eller ikke helt industrielle busser som ISA, PCI(e) og VME
På bekostning af Modbus- og HART-protokoller er der dukket ikke helt industrielle busser op, såsom ISA (MicroPC, PC/104) eller PCI/PCIe (CompactPCI, CompactPCI Serial, StacPC), samt VME.
Vi er nu i en æra med computere, der har adgang til en universel datatransmissionsbus, hvor man kan tilslutte forskellige kort (moduler) til behandling af et eller andet standardiseret signal. I sådanne tilfælde indsættes processormodulet (computeren) i den såkaldte ramme, som sikrer interaktion via bussen med andre enheder. Rammen, eller som de ægte automatiserere kalder det, "krate", suppleres med de nødvendige ind- og udgangskort: analoge, digitale, grænseflade osv., eller alt dette samles som en sandwich uden ramme — et kort ovenpå et andet. Herefter udveksler denne mangfoldighed på bussen (ISA, PCI, osv.) data med processormodulet, som således modtager information fra sensorerne og implementerer en eller anden logik.
Kontroller og ind- og udgangsmoduler i PXI-rammen på PCI-bussen. Kilde:
Alt i alt var disse busser ISA, PCI(e) og VME udmærkede for deres tid: både hastigheden for dataoverførsel var acceptabel, og komponenterne var samlet i én ramme, kompakt og bekvemt. Selv om der muligvis ikke er nogen mulighed for hot-swapping af ind- og udgangskort, er det heller ikke noget, man ønsker i høj grad endnu.
Men der er en skefuld tjære, og ikke kun en. Det er ret svært at opbygge et distribueret system i en sådan konfiguration, busserne er lokale, man skal tænke på noget til dataudveksling med andre underordnede eller ligestillede noder, som Modbus over TCP/IP eller en anden protokol, kort sagt er der ikke meget bekvemmelighed. En anden uheldig ting er, at indgangs- og udgangskort normalt forventer et eller andet standardiseret signal, og de har ikke galvanisk adskillelse fra feltudstyret, så man skal konstruere et komplekst sæt af forskellige konverteringsmoduler og intermediære kredsløb, hvilket gør det betydeligt mere kompliceret.
Intermediære signalkonverteringsmoduler med galvanisk adskillelse. Kilde:
"Men hvad med udvekslingsprotokollen på den industrielle bus?" — spørger du. Og intet. Den findes ikke i en sådan implementering. Via kabellinjerne overføres signalet fra sensorer til signalomformere, omformerne giver spænding til det diskrete eller analoge ind- og udgangskort, og dataene fra kortet læses via ind- og udgangsportene, ved hjælp af operativsystemet. Og ingen specialiserede protokoller.
Hvordan fungerer moderne industrielle busser og protokoller
Og hvad så nu? Til dags dato er den klassiske idé om opbygning af automatiserede systemer ændret en smule. Mange faktorer har spillet ind, fra at automatisering også skal være praktisk, til tendensen til distribuerede automatiserede systemer med fjerntliggende noder.
Man kan måske sige, at der i dag er to hovedkoncepter for opbygning af automatiseringssystemer: lokaliserede og distribuerede automatiserede systemer.
I tilfælde af lokaliserede systemer, hvor datainnsamling og styring er centraliseret på ét bestemt sted, er konceptet med et sæt af input-output moduler, der er forbundet med en fælles hurtig bus, efterspurgt. Dette inkluderer en controller med sin egen kommunikationsprotokol. Som regel indeholder input-output modulerne også en signalkonverter og galvanisk adskillelse (selvom det selvfølgelig ikke altid er tilfældet). Det vil sige, at den endelige forbruger kun skal forstå, hvilke typer sensorer og mekanismer der vil være til stede i det automatiserede system, tælle det nødvendige antal input-output moduler til forskellige typer signaler og forbinde dem i en samlet række med controlleren. I dette tilfælde bruger hver producent normalt sin foretrukne kommunikationsprotokol mellem input-output modulerne og controlleren, og der kan være mange muligheder.
I tilfælde af distribuerede systemer gælder alt, hvad der er sagt om lokaliserede systemer, dog er det vigtigt, at de enkelte komponenter, som f.eks. et sæt input-output moduler plus en enhed til indsamling og transmission af information — en ikke særlig intelligent mikrocontroller, der står et sted i felten nær ventilen, der lukker for olie — kan interagere med tilsvarende enheder og den centrale controller på en stor afstand med effektiv kommunikationshastighed.
Hvordan vælger udviklere protokollen til deres projekt? Alle moderne kommunikationsprotokoller sikrer ret høj ydelse, så valget af en bestemt producent er ofte ikke baseret på hastigheden af kommunikation over den industrielle bus. Implementeringen af selve protokollen er heller ikke så vigtig, fordi det fra systemudviklerens perspektiv vil være en sort boks, der sikrer en intern struktur for kommunikation og ikke er beregnet til ekstern indblanding. Ofte lægges der vægt på praktiske egenskaber: beregnerens ydeevne, anvendeligheden af producentens koncept til den stillede opgave, tilgængeligheden af de nødvendige typer input-output moduler, muligheden for hot-swap af moduler uden at bryde busforbindelsen osv.
Populære hardwareleverandører tilbyder deres egne implementeringer af industrielle protokoller: for eksempel udvikler det velkendte firma Siemens sin serie af protokoller Profinet og Profibus, B&R udvikler protokollen Powerlink, og Rockwell Automation står bag protokollen EtherNet/IP. Et indenlandsk løsning i denne liste af eksempler er versionen af protokol FBUS fra det russiske firma Fastwel.
Der er også mere universelle løsninger, der ikke er knyttet til en bestemt producent, såsom EtherCAT og CAN. Vi vil udforske disse protokoller grundigt i den fortsatte artikel og finde ud af, hvilke der er bedst egnet til specifikke anvendelser: bil- og rumfartsindustrien, produktion af elektronik, positionssystemer og robotteknologi. Hold dig opdateret!
Kilde: habr.com
