Sikkert mange av dere vet eller har til og med sett hvordan store automatiserte objekter styres, for eksempel et atomkraftverk eller en fabrikk med mange produksjonslinjer: hovedhandlingen foregår ofte i et stort rom, med en haug med skjermer, lyspærer og fjernkontroller. Dette kontrollkomplekset kalles vanligvis hovedkontrollrommet - hovedkontrollpanelet for overvåking av produksjonsanlegget.
Du lurte sikkert på hvordan det hele fungerer når det gjelder maskinvare og programvare, hvordan disse systemene skiller seg fra konvensjonelle personlige datamaskiner. I denne artikkelen vil vi se på hvordan ulike data kommer til hovedkontrollrommet, hvordan kommandoer sendes til utstyret, og hva som generelt er nødvendig for å kontrollere en kompressorstasjon, et propanproduksjonsanlegg, en bilmonteringslinje, eller til og med en kloakkpumpeanlegg.
Det laveste nivået eller feltbussen er der det hele starter
Dette settet med ord, uklart for uinnvidde, brukes når det er nødvendig å beskrive kommunikasjonsmidlene mellom mikrokontrollere og underordnet utstyr, for eksempel I/O-moduler eller måleenheter. Vanligvis kalles denne kommunikasjonskanalen "feltbussen" fordi den er ansvarlig for å overføre data som kommer fra "feltet" til kontrolleren.
"Felt" er et dypt profesjonelt begrep som refererer til det faktum at noe utstyr (for eksempel sensorer eller aktuatorer) som kontrolleren samhandler med er plassert et sted langt, langt unna, på gaten, i markene, i ly av natten . Og det spiller ingen rolle at sensoren kan plasseres en halv meter fra kontrolleren og måle for eksempel temperaturen i et automatiseringsskap, det anses fortsatt at det er "i feltet." Oftest reiser signaler fra sensorer som ankommer I/O-moduler fortsatt avstander fra titalls til hundrevis av meter (og noen ganger mer), og samler informasjon fra eksterne steder eller utstyr. Det er faktisk derfor utvekslingsbussen, som kontrolleren mottar verdier fra de samme sensorene gjennom, vanligvis kalles en feltbuss eller, mindre vanlig, en buss på lavere nivå eller en industribuss.
Generell ordning for automatisering av et industrianlegg
Så det elektriske signalet fra sensoren reiser en viss avstand langs kabellinjer (vanligvis langs en vanlig kobberkabel med et visst antall kjerner), som flere sensorer er koblet til. Signalet går deretter inn i prosesseringsmodulen (inn-/utgangsmodul), hvor det konverteres til et digitalt språk som er forståelig for kontrolleren. Deretter går dette signalet via feltbussen direkte til kontrolleren, hvor det til slutt behandles. Basert på slike signaler bygges driftslogikken til selve mikrokontrolleren.
Toppnivå: fra en krans til en hel arbeidsstasjon
Det øvre nivået kalles alt som kan berøres av en vanlig dødelig operatør som kontrollerer den teknologiske prosessen. I det enkleste tilfellet er toppnivået et sett med lys og knapper. Lyspærer signaliserer operatøren om visse hendelser som skjer i systemet, knapper brukes til å gi kommandoer til kontrolleren. Dette systemet kalles ofte en "krans" eller "juletre" fordi det ser veldig likt ut (som du kan se fra bildet i begynnelsen av artikkelen).
Hvis operatøren er mer heldig, vil han som øverste nivå få et operatørpanel - en slags flat-panel datamaskin som på en eller annen måte mottar data for visning fra kontrolleren og viser dem på skjermen. Et slikt panel er vanligvis montert på selve automatiseringsskapet, så du må vanligvis samhandle med det mens du står, noe som forårsaker ulemper, pluss at kvaliteten og størrelsen på bildet på paneler i småformat lar mye å være ønsket.
Og til slutt, en attraksjon av enestående generøsitet - en arbeidsstasjon (eller til og med flere duplikater), som er en vanlig personlig datamaskin.
Utstyr på øvre nivå må samhandle på en eller annen måte med mikrokontrolleren (hvorfor er det ellers nødvendig?). For slik interaksjon brukes overordnede protokoller og et bestemt overføringsmedium, for eksempel Ethernet eller UART. Når det gjelder "juletreet", er slike raffinementer selvfølgelig ikke nødvendige; lyspærene tennes med vanlige fysiske linjer, det er ingen sofistikerte grensesnitt eller protokoller der.
Generelt er dette øvre nivået mindre interessant enn feltbussen, siden dette øvre nivået kanskje ikke eksisterer i det hele tatt (det er ingenting for operatøren å se på fra serien; kontrolleren vil selv finne ut hva som må gjøres og hvordan ).
"Gamle" dataoverføringsprotokoller: Modbus og HART
De færreste vet det, men på den syvende dagen av verdens skapelse hvilte ikke Gud, men skapte Modbus. Sammen med HART-protokollen er Modbus kanskje den eldste industrielle dataoverføringsprotokollen; den dukket opp tilbake i 1979.
Det serielle grensesnittet ble opprinnelig brukt som et overføringsmedium, deretter ble Modbus implementert over TCP/IP. Dette er en synkron master-slave (master-slave) protokoll som bruker forespørsel-svar-prinsippet. Protokollen er ganske tungvint og treg, utvekslingshastigheten avhenger av egenskapene til mottakeren og senderen, men vanligvis er tellingen nesten hundrevis av millisekunder, spesielt når den implementeres via et serielt grensesnitt.
Dessuten er Modbus-dataoverføringsregisteret 16-bit, noe som umiddelbart setter begrensninger på overføring av reelle og doble typer. De overføres enten i deler eller med tap av nøyaktighet. Selv om Modbus fortsatt er mye brukt i tilfeller der høye kommunikasjonshastigheter ikke er nødvendig og tap av overførte data ikke er kritisk. Mange produsenter av ulike enheter liker å utvide Modbus-protokollen på sin egen eksklusive og veldig originale måte, og legger til funksjoner som ikke er standard. Derfor har denne protokollen mange mutasjoner og avvik fra normen, men lever fortsatt vellykket i den moderne verden.
HART-protokollen har også eksistert siden åttitallet, det er en industriell kommunikasjonsprotokoll over en to-leder strømsløyfelinje som direkte kobler 4-20 mA sensorer og andre HART-aktiverte enheter.
For å bytte HART-linjer brukes spesielle enheter, såkalte HART-modemer. Det finnes også omformere som gir brukeren, for eksempel, Modbus-protokollen ved utgangen.
HART er kanskje kjent for det faktum at i tillegg til de analoge signalene til 4-20 mA sensorer, overføres også det digitale signalet til selve protokollen i kretsen, dette lar deg koble de digitale og analoge delene i en kabellinje. Moderne HART-modemer kan kobles til kontrollerens USB-port, kobles til via Bluetooth, eller på gammeldags måte via en seriell port. For et dusin år siden, analogt med Wi-Fi, dukket WirelessHART trådløs standard, som opererer i ISM-området, opp.
Andre generasjons protokoller eller ikke helt industribusser ISA, PCI(e) og VME
Modbus- og HART-protokollene er erstattet av ikke helt industrielle busser, som ISA (MicroPC, PC/104) eller PCI/PCIe (CompactPCI, CompactPCI Serial, StacPC), samt VME.
Tiden for datamaskiner har kommet som har til disposisjon en universell databuss, hvor ulike kort (moduler) kan kobles til for å behandle et visst enhetlig signal. Som regel, i dette tilfellet, er prosessormodulen (datamaskinen) satt inn i den såkalte rammen, som sikrer interaksjon via bussen med andre enheter. Rammen, eller, som ekte automatiseringseksperter liker å kalle det, "kasse", er supplert med de nødvendige input-output-kortene: analog, diskret, grensesnitt osv., eller alt dette settes sammen i form av en sandwich uten en ramme - ett bord oppå det andre. Etter det utveksler denne varianten på bussen (ISA, PCI, etc.) data med prosessormodulen, som dermed mottar informasjon fra sensorene og implementerer noe logikk.
Kontroller og I/O-moduler i en PXI-ramme på en PCI-buss. Kilde:
Alt ville være bra med disse ISA-, PCI(e)- og VME-bussene, spesielt for disse tider: utvekslingshastigheten er ikke skuffende, og systemkomponentene er plassert i en enkelt ramme, kompakt og praktisk, det kan hende at det ikke er hot-swappable I/O-kort, men jeg vil egentlig ikke det ennå.
Men det er en flue i salven, og mer enn én. Det er ganske vanskelig å bygge et distribuert system i en slik konfigurasjon, utvekslingsbussen er lokal, du må finne på noe for å utveksle data med andre slave- eller peer-noder, samme Modbus over TCP/IP eller en annen protokoll, i generelt er det ikke nok bekvemmeligheter. Vel, den andre ikke veldig hyggelige tingen: I/O-kort forventer vanligvis et slags enhetlig signal som inngang, og de har ikke galvanisk isolasjon fra feltutstyr, så du må lage et gjerde av forskjellige konverteringsmoduler og mellomkretser, som i stor grad kompliserer elementbasen.
Mellomsignalkonverteringsmoduler med galvanisk isolasjon. Kilde:
"Hva med industribussprotokollen?" - du spør. Ingenting. Det finnes ikke i denne implementeringen. Gjennom kabellinjer går signalet fra sensorer til signalomformere, omformerne leverer spenning til et diskret eller analogt I/O-kort, og dataene fra kortet er allerede lest gjennom I/O-portene ved hjelp av OS. Og ingen spesialiserte protokoller.
Hvordan moderne industribusser og protokoller fungerer
Hva nå? Til dags dato har den klassiske ideologien om å bygge automatiserte systemer endret seg litt. Mange faktorer spilte inn, fra og med at automatisering også skulle være praktisk, og slutter med trenden mot distribuerte automatiserte systemer med noder fjernt fra hverandre.
Kanskje kan vi si at det er to hovedkonsepter for bygningsautomasjonssystemer i dag: lokaliserte og distribuerte automatiserte systemer.
Når det gjelder lokaliserte systemer, hvor datainnsamling og kontroll er sentralisert på ett spesifikt sted, er konseptet med et visst sett med inngangs-/utgangsmoduler koblet sammen av en felles hurtigbuss, inkludert en kontroller med egen utvekslingsprotokoll, etterspurt. I dette tilfellet inkluderer I/O-moduler som regel både en signalomformer og galvanisk isolasjon (selv om det selvfølgelig ikke alltid er). Det vil si at det er nok for sluttbrukeren å forstå hvilke typer sensorer og mekanismer som vil være til stede i det automatiserte systemet, telle antall nødvendige inngangs-/utgangsmoduler for forskjellige typer signaler og koble dem til en felles linje med kontrolleren . I dette tilfellet bruker som regel hver produsent sin favorittutvekslingsprotokoll mellom I/O-moduler og kontrolleren, og det kan være mange alternativer her.
Når det gjelder distribuerte systemer er alt som sies i forhold til lokaliserte systemer sant, i tillegg er det viktig at individuelle komponenter, for eksempel et sett med input-output moduler pluss en enhet for innsamling og overføring av informasjon - en ikke veldig smart mikrokontroller som står et sted i en bås i felt, ved siden av ventilen som stenger oljen - kunne samhandle med de samme nodene og med hovedkontrolleren på stor avstand med en effektiv valutakurs.
Hvordan velger utviklere en protokoll for prosjektet sitt? Alle moderne utvekslingsprotokoller gir ganske høy ytelse, så valget av en eller annen produsent bestemmes ofte ikke av valutakursen på denne svært industrielle bussen. Implementeringen av selve protokollen er ikke så viktig, fordi fra systemutviklerens synspunkt vil det fortsatt være en svart boks som gir en viss intern utvekslingsstruktur og ikke er designet for forstyrrelser utenfor. Oftest rettes oppmerksomheten mot praktiske egenskaper: ytelsen til datamaskinen, hvor lett det er å bruke produsentens konsept på oppgaven, tilgjengeligheten av de nødvendige typene I/O-moduler, muligheten til å bytte ut moduler uten å gå i stykker. bussen osv.
Populære utstyrsleverandører tilbyr sine egne implementeringer av industrielle protokoller: for eksempel utvikler det velkjente selskapet Siemens sin serie med Profinet- og Profibus-protokoller, B&R utvikler Powerlink-protokollen, Rockwell Automation utvikler EtherNet/IP-protokollen. En innenlandsk løsning i denne listen over eksempler: en versjon av FBUS-protokollen fra det russiske selskapet Fastwel.
Det finnes også mer universelle løsninger som ikke er knyttet til en spesifikk produsent, som EtherCAT og CAN. Vi vil analysere disse protokollene i detalj i fortsettelsen av artikkelen og finne ut hvilke av dem som er bedre egnet for spesifikke bruksområder: bil- og romfartsindustri, elektronikkproduksjon, posisjoneringssystemer og robotikk. Holde kontakten!
Kilde: www.habr.com