Bussar och protokoll inom industriell automation: hur det hela fungerar

Bussar och protokoll inom industriell automation: hur det hela fungerar

Säkert många av er vet eller har till och med sett hur stora automatiserade objekt styrs, till exempel ett kärnkraftverk eller en fabrik med många tekniska linjer: huvudhandlingen utspelar sig ofta i ett stort rum, med en massa skärmar, glödlampor och fjärrkontroller. Detta kontrollkomplex kallas vanligtvis huvudkontrollrummet - huvudkontrollpanelen för styrning av produktionsanläggningen.

Du undrade säkert hur det hela fungerar i form av hårdvara och mjukvara, hur dessa system skiljer sig från de vanliga persondatorerna. I den här artikeln kommer vi att titta på hur olika data kommer till huvudkontrollrummet, hur kommandon ges till utrustningen och vad som i allmänhet behövs för att styra en kompressorstation, en propanproduktionsenhet, en bilmonteringslinje eller till och med en avloppspumpaggregat.

Bottenskiktet eller fältbussen är där allt börjar

Denna uppsättning ord, otydlig för den oinitierade, används när det är nödvändigt att beskriva kommunikationsmedel för mikrokontroller med underordnad utrustning, till exempel I / O-moduler eller mätanordningar. Vanligtvis kallas denna kommunikationskanal "fältbussen", eftersom den ansvarar för att överföra data till styrenheten som kommer från "fältet".

"Fält" är en djup professionell term som hänvisar till det faktum att viss utrustning (till exempel sensorer eller ställdon) som styrenheten interagerar med är någonstans långt, långt borta, på gatan, på fälten, i skydd av natten. Och det spelar ingen roll att sensorn kan placeras en halv meter från regulatorn och mäta till exempel temperaturen i automationsskåpet, den anses fortfarande vara "i fältet". Oftast övervinner signalerna från sensorerna som kommer till I/O-modulerna fortfarande avstånd från tiotals till hundratals meter (och ibland mer), och samlar in information från avlägsna platser eller utrustning. I själva verket kallas därför växelbussen, genom vilken styrenheten tar emot värden från samma sensorer, vanligtvis en fältbuss eller, mer sällan, en lägre nivåbuss eller en industribuss.

Bussar och protokoll inom industriell automation: hur det hela fungerar
Allmänt system för automatisering av en industriell anläggning

Så den elektriska signalen från sensorn färdas ett visst avstånd längs kabellinjer (vanligtvis längs en konventionell kopparkabel med ett visst antal kärnor), till vilken flera sensorer är anslutna. Sedan går signalen in i bearbetningsmodulen (input-output-modulen), där den omvandlas till ett digitalt språk som är förståeligt för styrenheten. Vidare går denna signal direkt till styrenheten via fältbussen, där den slutligen bearbetas. Baserat på sådana signaler byggs själva mikrokontrollerns logik.

Toppnivå: från en krans till en hel arbetsstation

Den översta nivån är allt som kan röras av en vanlig dödlig operatör som kontrollerar processen. I det enklaste fallet är den översta nivån en uppsättning glödlampor och knappar. Glödlampor signalerar till operatören om några pågående händelser i systemet, knappar tjänar till att ge kommandon till kontrollenheten. Ett sådant system kallas ofta en "girland" eller "julgran" eftersom det ser väldigt likt ut (som du kan se på bilden i början av artikeln).

Om operatören är mer lyckligt lottad kommer han som toppnivå att få operatörspanelen - en sorts platt dator som på något sätt tar emot data för visning från styrenheten och visar den på skärmen. En sådan panel är vanligtvis monterad på själva automationsskåpet, så du måste vanligtvis interagera med den stående, vilket orsakar besvär, plus att kvaliteten och storleken på bilden på paneler i småformat lämnar mycket övrigt att önska.

Bussar och protokoll inom industriell automation: hur det hela fungerar

Och slutligen en attraktion av oöverträffad generositet - en arbetsstation (eller till och med flera dubbletter), som är en vanlig persondator.

Utrustningen på toppnivå måste interagera på något sätt med mikrokontrollern (annars varför behövs den?). För sådan interaktion används överordnade protokoll och ett visst överföringsmedium, till exempel Ethernet eller UART. När det gäller julgranen behövs naturligtvis inte sådana finesser, glödlamporna tänds med vanliga fysiska linjer, det finns inga sofistikerade gränssnitt och protokoll där.

I allmänhet är denna toppnivå mindre intressant än fältbussen, eftersom denna toppnivå kanske inte existerar alls (operatören har inget att titta på från serien, styrenheten kommer att ta reda på vad den ska göra och hur).

"Gamla" dataöverföringsprotokoll: Modbus och HART

Få människor vet, men på den sjunde dagen av världens skapelse vilade Gud inte, utan skapade Modbus. Tillsammans med HART-protokollet är Modbus kanske det äldsta industriella kommunikationsprotokollet, det dök upp redan 1979.

Det seriella gränssnittet användes initialt som ett överföringsmedium, sedan implementerades Modbus över TCP/IP. Detta är ett synkront master-slave (master-slave) protokoll som använder principen för begäran-svar. Protokollet är ganska tungt och långsamt, växelkursen beror på egenskaperna hos mottagaren och sändaren, men vanligtvis är poängen nästan hundratals millisekunder, speciellt när den implementeras via ett seriellt gränssnitt.

Dessutom är Modbus dataöverföringsregistret 16-bitars, vilket omedelbart sätter begränsningar på överföringen av verkliga och dubbla typer. De överförs antingen i delar eller med förlust av noggrannhet. Även om Modbus fortfarande används flitigt i de fall där en hög växelkurs inte behövs och förlusten av överförd data inte är kritisk. Många tillverkare av olika enheter gillar att utöka Modbus-protokollet på sitt eget unika och mycket originella sätt, och lägger till icke-standardiserade funktioner. Därför har detta protokoll många mutationer och avvikelser från normen, men lever fortfarande framgångsrikt i den moderna världen.
HART-protokollet har också funnits sedan 4-talet, det är ett industriellt kommunikationsprotokoll över en tvåtrådsströmslinga som direkt kopplar samman 20-XNUMX mA-sändare och andra HART-aktiverade enheter.

För att byta HART-linjer används speciella enheter, så kallade HART-modem. Det finns också omvandlare som vid utgången förser användaren med, säg, Modbus-protokollet.

HART är kanske anmärkningsvärt eftersom, förutom de analoga signalerna från 4-20 mA-sensorerna, den digitala signalen från själva protokollet också överförs i kretsen, vilket gör att du kan ansluta de digitala och analoga delarna i en kabel linje. Moderna HART-modem kan kopplas till styrenhetens USB-port, kopplas via Bluetooth, eller på gammalt sätt via en seriell port. För ett decennium sedan, analogt med Wi-Fi, dök WirelessHART trådlös standard upp, som fungerade i ISM-bandet.

Den andra generationens protokoll eller inte riktigt industriella bussar ISA, PCI (e) och VME

Modbus- och HART-protokollen har ersatts av icke-industriella bussar som ISA (MicroPC, PC/104) eller PCI/PCIe (CompactPCI, CompactPCI Serial, StacPC), samt VME.

Kalkylatorernas era har kommit, med en universell dataöverföringsbuss till sitt förfogande, där du kan ansluta olika kort (moduler) för att bearbeta en viss enhetlig signal. Som regel, i detta fall, sätts processormodulen (datorn) in i den så kallade ramen, som ger bussinteraktion med andra enheter. Ramen, eller, som riktiga automatörer vill kalla den, "lådan", kompletteras med nödvändiga I/O-kort: analog, diskret, gränssnitt, etc., eller allt detta limmas ihop i form av en smörgås utan en ram - en bräda ovanför den andra. Därefter kommunicerar denna variant på bussen (ISA, PCI, etc.) med processormodulen, som alltså tar emot information från sensorer och implementerar någon form av logik.

Bussar och protokoll inom industriell automation: hur det hela fungerar
Styrenhet och I/O-moduler i en PXI-ram på en PCI-buss. Källa: National Instruments Corporation

Allt skulle vara bra med dessa ISA-, PCI (e)- och VME-bussar, speciellt för dessa tider: växelkursen stör inte, och systemkomponenterna är placerade i en enda ram, kompakt och bekväm, det kanske inte finns hot swapping av I/O-kort, men vill ändå inte riktigt.

Men det finns en fluga i glädjebägaren, och inte en. Det är ganska svårt att bygga ett distribuerat system i en sådan konfiguration, utbytesbussen är lokal, du måste komma på något för att utbyta data med andra slav- eller peer-noder, samma Modbus över TCP / IP eller något annat protokoll, i generellt sett finns det inte tillräckligt med bekvämligheter. Tja, den andra saken är inte särskilt trevlig: I / O-kort väntar vanligtvis på en enhetlig signal för ingång, och de har inte galvanisk isolering med fältutrustning, så du måste inhägna en trädgård med olika konverteringsmoduler och mellankretsar, vilket komplicerar elementbasen avsevärt.

Bussar och protokoll inom industriell automation: hur det hela fungerar
Mellansignalomvandlingsmoduler med galvanisk isolering. Källa: Data Forth Corporation

"Hur är det med fältbusskommunikationsprotokollet?" - du frågar. Men inget. Det finns inte i denna implementering. Via kabellinjer går signalen från sensorerna till signalomvandlarna, omvandlarnas utspänning till ett diskret eller analogt I/O-kort, och data från kortet läses redan genom I/O-portarna, med hjälp av OS . Och inga specialiserade protokoll.

Hur moderna industribussar och protokoll fungerar

Och nu då? Hittills har den klassiska ideologin att bygga automatiserade system förändrats lite. Många faktorer spelade in, från att det också ska vara bekvämt att automatisera och slutar med trenden mot distribuerade automatiserade system med noder på avstånd från varandra.

Kanske kan vi säga att det idag finns två huvudkoncept för byggnadsautomationssystem: lokaliserade och distribuerade automatiserade system.

När det gäller lokaliserade system, där datainsamling och styrning är centraliserad på en specifik plats, efterfrågas konceptet med en viss uppsättning I/O-moduler som är sammankopplade med en gemensam snabbbuss, inklusive en styrenhet med sitt eget utbytesprotokoll. I det här fallet inkluderar I/O-moduler som regel både en signalomvandlare och galvanisk isolering (även om det naturligtvis inte alltid är). Det vill säga, det räcker för slutanvändaren att förstå vilka typer av sensorer och mekanismer som kommer att finnas i det automatiserade systemet, räkna antalet nödvändiga I/O-moduler för olika typer av signaler och ansluta dem till en gemensam linje med styrenheten . I det här fallet använder som regel varje tillverkare sitt favoritutbytesprotokoll mellan I/O-moduler och styrenheten, och det kan finnas många alternativ.

När det gäller distribuerade system är allt som har sagts om lokaliserade system sant, förutom detta är det viktigt att enskilda komponenter, till exempel en uppsättning I/O-moduler plus en informationsinsamlings- och överföringsenhet - en inte särskilt mycket smart mikrokontroller som står någonstans i en monter på fältet, bredvid kranen som stänger av oljan, skulle kunna interagera med samma noder och med huvudkontrollern på stort avstånd med en effektiv växelkurs.

Hur väljer utvecklare ett protokoll för sitt projekt? Alla moderna utbytesprotokoll ger en ganska hög hastighet, så ofta bestäms inte valet av en viss tillverkare av växelkursen på samma industribuss. Implementeringen av själva protokollet är inte så viktigt, eftersom det, ur systemutvecklarens synvinkel, fortfarande kommer att vara en svart låda som ger en viss intern struktur för utbytet och inte är designad för extern störning. Oftast ägnas uppmärksamhet åt praktiska egenskaper: räknarens prestanda, bekvämligheten med att tillämpa tillverkarens koncept på uppgiften, tillgängligheten av de erforderliga typerna av ingångs-utgångsmoduler, möjligheten att hot-swapping-moduler utan att bryta bussen , etc.

Populära utrustningsleverantörer erbjuder sina egna implementeringar av industriella protokoll: till exempel utvecklar det välkända företaget Siemens sin serie Profinet- och Profibus-protokoll, B&R utvecklar Powerlink-protokollet, Rockwell Automation utvecklar EtherNet/IP-protokollet. Den inhemska lösningen i denna lista med exempel: versionen av FBUS-protokollet från det ryska företaget Fastwel.

Det finns också mer universella lösningar som inte är knutna till en specifik tillverkare, som EtherCAT och CAN. Vi kommer att utforska dessa protokoll i detalj senare i den här artikeln och se vilka som är bäst lämpade för specifika applikationer: fordon, flyg, elektronik, positioneringssystem och robotik. Hålla kontakten!

Källa: will.com

Lägg en kommentar