Mange af jer kender eller har endda set, hvordan store automatiserede objekter styres, for eksempel et atomkraftværk eller en fabrik med mange produktionslinjer: Hovedhandlingen foregår ofte i et stort rum, med en masse skærme, elpærer og fjernbetjeninger. Dette kontrolkompleks kaldes normalt hovedkontrolrummet - hovedkontrolpanelet til overvågning af produktionsanlægget.
Du undrede dig sikkert over, hvordan det hele fungerer med hensyn til hardware og software, hvordan disse systemer adskiller sig fra konventionelle personlige computere. I denne artikel vil vi se på, hvordan forskellige data kommer til hovedkontrolrummet, hvordan kommandoer sendes til udstyret, og hvad der generelt er nødvendigt for at styre en kompressorstation, et propanproduktionsanlæg, et bilsamlebånd eller endda en kloakpumpeanlæg.
Det laveste niveau eller fieldbus er der, hvor det hele starter
Dette sæt ord, der er uklart for den uindviede, bruges, når det er nødvendigt at beskrive kommunikationsmidlerne mellem mikrocontrollere og underordnet udstyr, for eksempel I/O-moduler eller måleapparater. Typisk kaldes denne kommunikationskanal en "feltbus", fordi den er ansvarlig for at overføre data, der kommer fra "feltet" til controlleren.
"Felt" er et dybt professionelt udtryk, der refererer til det faktum, at noget udstyr (for eksempel sensorer eller aktuatorer), som controlleren interagerer med, er placeret et sted langt, langt væk, på gaden, på markerne, i ly af natten . Og det gør ikke noget, at sensoren kan placeres en halv meter fra controlleren og måle for eksempel temperaturen i et automatiseringsskab, det anses stadig for at være "i marken." Oftest rejser signaler fra sensorer, der ankommer til I/O-moduler, stadig afstande fra ti til hundreder af meter (og nogle gange mere) og indsamler information fra fjerntliggende steder eller udstyr. Faktisk er det derfor, ombytningsbussen, gennem hvilken controlleren modtager værdier fra de samme sensorer, normalt kaldes en feltbus eller, mindre almindeligt, en bus på lavere niveau eller en industribus.
Generel ordning for automatisering af en industriel facilitet
Så det elektriske signal fra sensoren rejser en vis afstand langs kabellinjer (normalt langs et almindeligt kobberkabel med et vist antal kerner), hvortil flere sensorer er forbundet. Signalet kommer derefter ind i behandlingsmodulet (input/output-modul), hvor det konverteres til et digitalt sprog, der er forståeligt for controlleren. Dernæst går dette signal via feltbussen direkte til controlleren, hvor det til sidst behandles. Baseret på sådanne signaler er selve mikrocontrollerens driftslogik bygget.
Øverste niveau: fra en guirlande til en hel arbejdsstation
Det øverste niveau kaldes alt, hvad der kan røres af en almindelig dødelig operatør, der styrer den teknologiske proces. I det enkleste tilfælde er det øverste niveau et sæt lys og knapper. Pærer signalerer operatøren om visse hændelser, der opstår i systemet, knapper bruges til at udstede kommandoer til controlleren. Dette system kaldes ofte en "guirlande" eller "juletræ", fordi det ligner meget (som du kan se på billedet i begyndelsen af artiklen).
Hvis operatøren er mere heldig, så får han som øverste niveau et operatørpanel - en slags fladskærmscomputer, der på den ene eller anden måde modtager data til visning fra controlleren og viser dem på skærmen. Sådan et panel er normalt monteret på selve automationsskabet, så du skal normalt interagere med det stående, hvilket medfører besvær, plus at kvaliteten og størrelsen af billedet på paneler i lille format lader meget tilbage at ønske.
Og endelig en attraktion af hidtil uset generøsitet - en arbejdsstation (eller endda flere dubletter), som er en almindelig personlig computer.
Udstyr på øverste niveau skal på en eller anden måde interagere med mikrocontrolleren (hvorfor er det ellers nødvendigt?). Til sådan interaktion bruges protokoller på øverste niveau og et bestemt transmissionsmedium, for eksempel Ethernet eller UART. I tilfældet med "juletræet" er sådanne sofistikationer selvfølgelig ikke nødvendige; pærerne tændes ved hjælp af almindelige fysiske linjer, der er ingen sofistikerede grænseflader eller protokoller der.
Generelt er dette øverste niveau mindre interessant end feltbussen, da dette øverste niveau måske slet ikke eksisterer (der er intet for operatøren at se på fra serien; controlleren vil selv finde ud af, hvad der skal gøres, og hvordan ).
"Gamle" dataoverførselsprotokoller: Modbus og HART
De færreste ved det, 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 dataoverførselsprotokol; den dukkede op tilbage i 1979.
Det serielle interface blev oprindeligt brugt som et transmissionsmedium, derefter blev Modbus implementeret over TCP/IP. Dette er en synkron master-slave (master-slave) protokol, der bruger anmodning-svar princippet. Protokollen er ret besværlig og langsom, udvekslingshastigheden afhænger af modtagerens og senderens karakteristika, men normalt er tællingen næsten hundreder af millisekunder, især når den implementeres via en seriel grænseflade.
Desuden er Modbus dataoverførselsregisteret 16-bit, hvilket øjeblikkeligt pålægger begrænsninger for overførsel af reelle og dobbelte typer. De transmitteres enten i dele eller med tab af nøjagtighed. Selvom Modbus stadig er meget brugt i tilfælde, hvor høje kommunikationshastigheder ikke er nødvendige, og tabet af transmitterede data ikke er kritisk. Mange producenter af forskellige enheder kan godt lide at udvide Modbus-protokollen på deres egen eksklusive og meget originale måde og tilføje ikke-standardfunktioner. Derfor har denne protokol mange mutationer og afvigelser fra normen, men lever stadig med succes i den moderne verden.
HART-protokollen har også eksisteret siden firserne, det er en industriel kommunikationsprotokol over en to-leder strømsløjfe, der direkte forbinder 4-20 mA sensorer og andre HART-aktiverede enheder.
For at skifte HART-linjer bruges specielle enheder, såkaldte HART-modemmer. Der er også konvertere, der forsyner brugeren med f.eks. Modbus-protokollen ved udgangen.
HART er måske bemærkelsesværdig for det faktum, at udover de analoge signaler fra 4-20 mA sensorer, transmitteres det digitale signal fra selve protokollen også i kredsløbet, dette giver dig mulighed for at forbinde de digitale og analoge dele i en kabellinje. Moderne HART-modemmer kan forbindes til controllerens USB-port, tilsluttes via Bluetooth, eller på den gammeldags måde via en seriel port. For en halv snes år siden, analogt med Wi-Fi, dukkede WirelessHART trådløs standard op, der opererer i ISM-området.
Anden generation af protokoller eller ikke helt industrielle busser ISA, PCI(e) og VME
Modbus- og HART-protokollerne er blevet erstattet af ikke helt industrielle busser, såsom ISA (MicroPC, PC/104) eller PCI/PCIe (CompactPCI, CompactPCI Serial, StacPC), samt VME.
Der er kommet en æra med computere, der råder over en universel databus, hvor forskellige kort (moduler) kan forbindes for at behandle et bestemt samlet signal. Som regel er processormodulet (computeren) i dette tilfælde indsat i den såkaldte frame, som sikrer interaktion via bussen med andre enheder. Rammen, eller som ægte automationseksperter ynder at kalde det "kassen", er suppleret med de nødvendige input-output boards: analog, diskret, interface osv., eller alt dette er sat sammen i form af en sandwich uden en ramme - det ene bræt oven på det andet. Herefter udveksler denne variant på bussen (ISA, PCI osv.) data med processormodulet, som dermed modtager information fra sensorerne og implementerer noget logik.
Controller og I/O-moduler i en PXI-ramme på en PCI-bus. Kilde:
Alt ville være fint med disse ISA-, PCI(e)- og VME-busser, især til disse tidspunkter: udvekslingshastigheden er ikke skuffende, og systemkomponenterne er placeret i en enkelt ramme, kompakt og praktisk, der er muligvis ikke hot-swappable I/O-kort, men det vil jeg egentlig ikke endnu.
Men der er en flue i salven, og mere end én. Det er ret vanskeligt at bygge et distribueret system i en sådan konfiguration, udvekslingsbussen er lokal, du skal finde på noget for at udveksle data med andre slave- eller peer noder, den samme Modbus over TCP/IP eller en anden protokol, i generelt er der ikke nok bekvemmeligheder. Nå, den anden ikke særlig behagelige ting: I/O-kort forventer normalt en form for samlet signal som input, og de har ikke galvanisk isolation fra feltudstyr, så du skal lave et hegn ud af forskellige konverteringsmoduler og mellemliggende kredsløb, hvilket i høj grad komplicerer grundstofbasen.
Mellemsignalkonverteringsmoduler med galvanisk isolering. Kilde:
"Hvad med industribusprotokollen?" - du spørger. Ikke noget. Det findes ikke i denne implementering. Via kabellinjer går signalet fra sensorer til signalomformere, konverterne leverer spænding til et diskret eller analogt I/O-kort, og dataene fra kortet læses allerede gennem I/O-portene ved hjælp af OS. Og ingen specialiserede protokoller.
Hvordan moderne industribusser og protokoller fungerer
Hvad nu? Til dato har den klassiske ideologi om at bygge automatiserede systemer ændret sig lidt. Mange faktorer spillede en rolle, startende med, at automatisering også skulle være praktisk, og sluttede med tendensen til distribuerede automatiserede systemer med noder fjernt fra hinanden.
Måske kan vi sige, at der er to hovedkoncepter for bygningsautomatiseringssystemer i dag: lokaliserede og distribuerede automatiserede systemer.
I tilfælde af lokaliserede systemer, hvor dataindsamling og kontrol er centraliseret på et bestemt sted, er konceptet med et bestemt sæt input/output-moduler forbundet med en fælles hurtig bus, herunder en controller med sin egen udvekslingsprotokol, efterspurgt. I dette tilfælde inkluderer I/O-moduler som regel både en signalomformer og galvanisk isolering (selv om det selvfølgelig ikke altid er). Det vil sige, at det er nok for slutbrugeren at forstå, hvilke typer sensorer og mekanismer der vil være til stede i det automatiserede system, tælle antallet af nødvendige input/output moduler til forskellige typer signaler og forbinde dem til en fælles linje med controlleren . I dette tilfælde bruger hver producent som regel sin foretrukne udvekslingsprotokol mellem I/O-moduler og controlleren, og der kan være mange muligheder her.
Ved distribuerede systemer er alt hvad der siges i forhold til lokaliserede systemer sandt, derudover er det vigtigt at enkelte komponenter, f.eks. et sæt input-output moduler plus en enhed til indsamling og transmission af information - en ikke meget smart mikrocontroller, der står et sted i en bås i marken, ved siden af ventilen, der lukker for olien - kunne interagere med de samme noder og med hovedcontrolleren på stor afstand med en effektiv vekselkurs.
Hvordan vælger udviklere en protokol til deres projekt? Alle moderne udvekslingsprotokoller giver ret høj ydeevne, så valget af den ene eller anden producent er ofte ikke bestemt af valutakursen på denne meget industrielle bus. Implementeringen af selve protokollen er ikke så vigtig, fordi det fra systemudviklerens synspunkt stadig vil være en sort boks, der giver en vis intern udvekslingsstruktur og ikke er designet til ekstern interferens. Oftest lægges der vægt på praktiske egenskaber: computerens ydeevne, letheden ved at anvende producentens koncept på den aktuelle opgave, tilgængeligheden af de nødvendige typer I/O-moduler, muligheden for hot-swappable moduler uden at gå i stykker bussen osv.
Populære udstyrsleverandører tilbyder deres egne implementeringer af industrielle protokoller: for eksempel udvikler det velkendte firma Siemens sin serie af Profinet- og Profibus-protokoller, B&R udvikler Powerlink-protokollen, Rockwell Automation udvikler EtherNet/IP-protokollen. En indenlandsk løsning på denne liste over eksempler: en version af FBUS-protokollen fra det russiske firma Fastwel.
Der findes også mere universelle løsninger, som ikke er bundet til en bestemt producent, såsom EtherCAT og CAN. Vi vil analysere disse protokoller i detaljer i fortsættelsen af artiklen og finde ud af, hvilke af dem der er bedre egnede til specifikke applikationer: bil- og rumfartsindustrien, elektronikfremstilling, positioneringssystemer og robotteknologi. Holde kontakt!
Kilde: www.habr.com