Modbus

Den aktuelle version af siden er endnu ikke blevet gennemgået af erfarne bidragydere og kan afvige væsentligt fra den version , der blev gennemgået den 17. marts 2020; checks kræver 44 redigeringer .

Modbus  er en åben kommunikationsprotokol baseret på master-slave-arkitekturen ( engelsk master -  slave ; begreberne klient-server bruges i Modbus-standarden ). Det er meget brugt i industrien til at organisere kommunikation mellem elektroniske enheder . Kan bruges til datatransmission via serielle kommunikationslinjer RS-485 , RS-422 , RS-232 og TCP/IP (Modbus TCP) netværk. Der er også ikke-standard implementeringer, der bruger UDP [1] [2] .

Forveksle ikke "Modbus" og "Modbus Plus". Modbus Plus er en proprietær protokol ejet af Schneider Electric . Det fysiske lag af Modbus Plus er unikt, svarende til Ethernet 10BASE-T , halv dupleks over et parsnoet , hastighed 2 Mbps. Modbus Plus-transportprotokollen er HDLC , over hvilken en udvidelse til Modbus PDU-transmission er specificeret.

JBUS er en delmængde af Modbus RTU-protokollen med små forskelle i adresseringsmetoden [3] .

Historie

Modbus blev udviklet af Modicon (nu ejet af Schneider Electric ) til brug i deres programmerbare logiske controllere . Protokolspecifikationen blev først offentliggjort i 1979 [4] . Det var en åben standard, der beskrev formatet af beskeder, og hvordan de blev transmitteret over et netværk af forskellige elektroniske enheder.

Til at begynde med brugte MODICON-controllere det serielle RS-232 [4] -interface . Senere begyndte RS-485-grænsefladen at blive brugt, da den giver højere pålidelighed, giver dig mulighed for at bruge længere kommunikationslinjer og forbinde flere enheder til en linje.

Mange producenter af elektronisk udstyr har understøttet standarden, hundredvis af produkter, der bruger den, er dukket op på markedet.

Modbus standard

Modbus udvikles i øjeblikket af non-profit organisationen Modbus-IDA [5] .

Specifik terminologi

Modbus specificerer 4 typer data:

Sammensætning af standarden

Modbus-standarderne består af 3 dele:

Fordele ved standarden

De vigtigste fordele ved standarden er åbenhed og massekarakter. Industrien producerer nu (2014) en masse typer og modeller af sensorer, aktuatorer, signalbehandlings- og normaliseringsmoduler osv. Næsten alle industrielle overvågnings- og kontrolsystemer har softwaredrivere til at arbejde med Modbus-netværk.

Ulemper ved standarden

Standarden blev dybest set udviklet i 1979 under hensyntagen til datidens behov og computeregenskaber, og mange problemstillinger, der er relevante for moderne industrielle netværk, blev ikke taget i betragtning [6] . Fraværet af disse funktioner er en konsekvens af protokollens enkelhed, som letter dens undersøgelse og fremskynder implementeringen.

Introduktion

Controllere på Modbus-bussen kommunikerer ved hjælp af en master-slave- model baseret på transaktioner bestående af en anmodning og et svar.

Normalt er der kun én master ( eng.  client , ifølge den gamle terminology master ) enhed i netværket, og flere slaves ( eng.  server , ifølge den gamle terminology slave ) enheder. Masteren igangsætter transaktioner (transmitterer anmodninger). Masteren kan adressere anmodningen individuelt til enhver slave eller starte en broadcast-meddelelse til alle slaver. Slaveanordningen, der har genkendt sin adresse, reagerer på en anmodning, der er rettet specifikt til den. Når en udsendelsesanmodning modtages, genereres der ikke et svar af slaveenheder.

Modbus-specifikationen beskriver strukturen af ​​anmodninger og svar. Deres grundlag er en elementær protokolpakke, den såkaldte PDU ( Protocol Data Unit ). Strukturen af ​​PDU'en er uafhængig af linktypen og inkluderer en funktionskode og et datafelt. Funktionskoden er kodet som et én-byte felt og kan tage værdier i området 1…127. Værdiområdet 128…255 er reserveret til fejlkoder. Datafeltet kan være af variabel længde. PDU-pakkestørrelsen er begrænset til 253 bytes.

Modbus PDU
funktionskode data
1 byte N ≤ 252 (byte)

For at sende en pakke over fysiske kommunikationslinjer placeres PDU'en i en anden pakke, der indeholder yderligere felter. Denne pakke kaldes ADU ( Application Data Unit ). ADU-formatet afhænger af linktypen. Der er tre varianter af ADU, to til datatransmission over en asynkron grænseflade og en over TCP/IP-netværk:

Den generelle struktur for en ADU er som følger (afhængigt af implementeringen kan nogle af felterne mangle):

adresse på slave (slave) enhed funktionskode data fejldetekteringsblok

hvor

Den maksimale ADU-størrelse for RS232/RS485 serielle netværk er 256 bytes, for TCP-netværk er den 260 bytes.

For Modbus TCP ADU ser sådan ud:

Transaktions ID Protokol ID pakke længde slave adresse funktionskode data

hvor

Det skal bemærkes, at der ikke er noget fejlkontrolfelt i Modbus TCP, da dataintegriteten sikres af TCP/IP-stakken.

Kategorier af funktionskoder

Den aktuelle protokolspecifikation definerer tre kategorier af funktionskoder:

Standard kommandoer Deres beskrivelse skal offentliggøres og godkendes af Modbus-IDA. Denne kategori omfatter både allerede definerede og aktuelt ubrugte koder. Brugerdefinerede kommandoer To rækker af koder (65 til 72 og 100 til 110), som brugeren kan tildele en vilkårlig funktion. Det er dog ikke garanteret, at en anden enhed ikke vil bruge den samme kode til at udføre en anden funktion. reserveret Denne kategori omfatter funktionskoder, der ikke er standard, men som allerede bruges i enheder fremstillet af forskellige virksomheder. Det er koderne 9, 10, 13, 14, 41, 42, 90, 91, 125, 126 og 127.

Datamodel

En af de typiske anvendelser af protokollen er at læse og skrive data til controller-registre. Protokolspecifikationen definerer fire datatabeller:

Bord Varetype Adgangstype
Flagregistre ( Coils ) en smule Læs og skriv
Diskrete indgange _ en smule kun læsning
Input registre _ 16 bit ord kun læsning
Beholdningsregistre _ _ 16 bit ord Læs og skriv

Elementerne i hver tabel tilgås ved hjælp af en 16-bit adresse, den første celle er adresse 0. Hver tabel kan således indeholde op til 65536 elementer. Specifikationen definerer ikke, hvad tabelelementerne fysisk skal være, og på hvilke interne enhedsadresser de skal være tilgængelige. For eksempel er det acceptabelt at organisere overlappende tabeller. I dette tilfælde vil instruktioner, der arbejder med diskrete data og med 16-bit registre, faktisk få adgang til de samme data.

Der er en vis forvirring forbundet med den måde, data behandles på. Modbus blev oprindeligt udviklet til Modicon controllere. I disse controllere blev der brugt en speciel nummerering for hver af tabellerne. For eksempel var det første indgangsregister lokationsnummer 30001, og det første holderegister var 40001. Holderegisteradresse 107 i Modbus-kommandoen var således registernummer 40108 på controlleren. Selvom en sådan adressematchning ikke længere er en del af standarden, kan nogle softwarepakker automatisk "rette" adresser indtastet af brugeren, for eksempel ved at trække 40001 fra lagerregisteradressen. Referencemanual fra 1996 https://modbus.org/docs/PI_MBUS_300.pdf , hvor lignende adressering implicit blev vedtaget, markeret som forældet ("forældet" og "KUN FOR LEGACY APPLICATIONS"), nuværende protokolspecifikation https:// modbus. org/docs/Modbus_Application_Protocol_V1_1b3.pdf bruger kun absolut adressering - 01 (0x01) Læs spoler 0x0000 til 0xFFFF, 03 (0x03) Læs holdregistre 0x0000 til 0xFFFF.

Standard Modbus protokol funktioner

Dataadgang

Læser data

For at læse værdier fra datatabellerne ovenfor, brug funktionskoder 1-4 ( hexadecimale værdier 0x01-0x04):

  • 1 (0x01)  - aflæsning af værdier fra flere flagregistre (Read Coil Status) .
  • 2 (0x02)  - aflæsning af værdier fra flere diskrete indgange (Læs diskrete indgange) .
  • 3 (0x03)  - Aflæsning af værdier fra flere holding registre (Read Holding Registers) .
  • 4 (0x04)  - Læsning af værdier fra flere inputregistre (Read Input Registers) .

Forespørgslen består af adressen på det første element i tabellen, hvis værdi skal læses, og antallet af elementer, der skal læses. Adressen og mængden af ​​data er angivet som 16-bit tal, den mest signifikante byte af hver sendes først.

De ønskede data sendes i svaret. Antallet af databytes afhænger af antallet af anmodede elementer. Før dataene transmitteres en byte, hvis værdi er lig med antallet af bytes data.

Værdierne af lagerregistrene og inputregistrene overføres fra den angivne adresse, to bytes pr. register, den høje byte af hvert register overføres først:

byte 1 byte 2 byte 3 byte 4 … byte N-1 byte N
RA ,1 RA ,0 RA +1,1 RA +1,0 … RA +Q-1.1 RA +Q-1,0

Værdierne af flag og digitale input transmitteres i pakket form: en bit pr. flag. Én betyder tændt, nul betyder slukket. Værdierne af de anmodede flag fylder først den første byte, startende med den mindst signifikante bit, derefter de næste bytes, også fra den mindst signifikante bit til de mest signifikante. Den mindst signifikante bit af den første databyte indeholder værdien af ​​flaget angivet i "adresse"-feltet. Hvis det anmodede antal flag ikke er et multiplum af otte, er værdierne af de ekstra bits fyldt med nuller:

byte 1 … byte N
F A+7 F A+6 F A+5 F A+4 F A+3 F A+2 F A+1 F A … 0 … 0 F A+Q-1 F A+Q-2 …
Optagelse af en enkelt værdi
  • 5 (0x05)  - skriv værdien af ​​et flag (Force Single Coil) .
  • 6 (0x06)  - skriv værdi til et lagerregister (forudindstillet enkelt register) .

Kommandoen består af elementadressen (2 bytes) og den indstillede værdi (2 bytes).

For et holderegister er værdien blot et 16-bit ord.

For flag betyder værdien 0xFF00 tændt, 0x0000 betyder slukket, andre værdier er ugyldige.

Hvis kommandoen lykkes, returnerer slaven en kopi af anmodningen.

Optagelse af flere værdier
  • 15 (0x0F)  - Skriv værdier til flere flagregistre (Force Multiple Coils)
  • 16 (0x10)  - skriv værdier til flere lagerregistre (forudindstillede flere registre)

Kommandoen består af adressen på elementet, antallet af elementer, der skal ændres, antallet af bytes af indstillede værdier, der skal transmitteres, og de indstillede værdier selv. Dataene pakkes på samme måde som i datalæsekommandoer.

Svaret består af startadressen og antallet af ændrede elementer.

Ændring af registre
  • 22 (0x16) - skrivning til ét lagerregister ved hjælp af "AND"-masken og "ELLER"-masken (Mask Write Register) .

Kommandoen består af adressen på et register og to 16-bit numre, der bruges som masker, der kan bruges til individuelt at nulstille eller indstille individuelle bits i registeret. Det endelige resultat bestemmes af formlen:

Resultat = ( Current_value AND Mask_AND ) OR ( Mask_OR AND (IKKE Mask_AND ))

Læsning med skrivning
  • 23 (0x17)  - læs/skriv flere registre ( Læs/skriv flere registre )

Denne funktionskode udfører en kombination af én læseoperation og én skriveoperation i én Modbus-transaktion.

Datakøer
  • 24 (0x18) - læsning af data fra køen (Læs FIFO-kø)

Funktionen er designet til at modtage 16-bit ord fra en først-ind-først-ud- kø ( FIFO ).

Filadgang
  • 20 (0x14) - læsning fra en fil (Read File Record)
  • 21 (0x15) - skriv til en fil (Skriv filpost)

Disse funktioner bruges til at få adgang til 16-bit registre organiseret i filer af vilkårlig længde. Kommandoen angiver filnummer, postnummer og postlængde i 16-bit ord. Med en enkelt kommando kan du skrive eller læse flere poster, ikke nødvendigvis tilstødende.

Derudover indeholder kommandoen en en-byte kode til at angive typen af ​​datareference. Den aktuelle version af standarden definerer kun én type (beskrevet ovenfor) med kode 0x06.

Diagnostik

Funktionerne nedenfor er til enheder på serielle linjer (Modbus RTU og Modbus ASCII).

  • 7 (0x07) - læs statussignaler (læs undtagelsesstatus)

Funktionen er beregnet til at få information om statusindikatorer på en ekstern enhed. Funktionen returnerer en byte, hvoraf hver bit svarer til tilstanden af ​​en indikator.

  • 8 (0x08) - diagnostik (diagnostik)
  • 11 (0x0B) - læsning af hændelsestælleren (Get Com Event Counter)
  • 12 (0x0C) - læsning af hændelsesloggen (Get Com Event Log)

Disse funktioner er designet til at teste funktionaliteten af ​​det serielle link.

  • 17 (0x11) - læs enhedsoplysninger (Rapport Server ID)

Funktionen er beregnet til at indhente information om enhedstypen og dens tilstand. Formatet på svaret afhænger af enheden.

Andre

  • 43 (0x2B) - Indkapslet grænsefladetransport

Funktionen er designet til at overføre data i vilkårlige formater (defineret af andre standarder) fra master (klient) til slave (server) og omvendt.

Typen af ​​transmitterede data bestemmes af en ekstra kode (MEI - Modbus Encapsulated Interface), der transmitteres efter funktionsnummeret. Standarden definerer MEI 13 (0x0D), beregnet til at indkapsle CANopen -protokollen . MEI 14 (0x0E) bruges til at få enhedsoplysninger, og MEI'er i intervallerne 0-12 og 15-255 er reserveret.

Fejlhåndtering

Der kan opstå to typer fejl under kommunikation:

  • fejl forbundet med forvrængning i datatransmission;
  • logiske fejl (anmodning accepteret uden forvrængning, men kan ikke udføres)

Ved transmission over asynkrone kommunikationslinjer detekteres fejl af den første type ved at kontrollere, om den modtagne anmodning er i overensstemmelse med det etablerede ADU-format og beregne kontrolsummen. Derudover kan en paritetsbit bruges til at kontrollere hvert tegn . Hvis slaven registrerer datakorruption, ignoreres den modtagne anmodning, og der genereres ingen svarmeddelelse. Værten kan registrere en fejl uden svar.

Modbus TCP giver ikke yderligere dataintegritetstjek. Forvrængningsfri datatransmission leveres af TCP/IP-protokoller.

Ved fejl af den anden type sender slaveenheden en fejlmeddelelse (hvis anmodningen er adresseret til denne enhed; der sendes intet svar på udsendelsesanmodninger). En indikation af, at svaret indeholder en fejlmeddelelse, er den indstillede høje bit af funktionsnummeret. Funktionsnummeret efterfølges af fejlkoden og om nødvendigt yderligere fejldata i stedet for de sædvanlige data.

Standard fejlkoder

  • 01 - Modtaget funktionskode kunne ikke behandles.
  • 02 - Den dataadresse, der er angivet i anmodningen, er ikke tilgængelig.
  • 03 - Værdien i anmodningsdatafeltet er en ugyldig værdi.
  • 04 - Der opstod en uoprettelig fejl, mens slaven forsøgte at udføre den anmodede handling.
  • 05 - Slaveenheden har modtaget anmodningen og behandler den, men det tager lang tid. Dette svar forhindrer masteren i at generere en timeout-fejl.
  • 06 - Slaveenheden er i gang med at behandle kommandoen. Masteren bør gentage beskeden senere, når slaven er fri.
  • 07 - Slavenheden kan ikke udføre den programfunktion, der er angivet i anmodningen. Denne kode returneres for en mislykket programanmodning ved hjælp af funktionsnumrene 13 eller 14. Masteren skal anmode om diagnosticering eller fejlinformation fra slaven.
  • 08 - Slavenheden stødte på en paritetsfejl under læsning af udvidet hukommelse. Skibsføreren kan gentage anmodningen senere, men normalt kræves reparation af udstyr i sådanne tilfælde.

Eksempler

Nedenfor er et eksempel på en masterkommando og slavesvar (til Modbus RTU).

Anmodning
Overførselsretning slave enheds adresse funktionsnummer Adresse Antal flag Antal databytes Data CRC
høj byte lav byte høj byte lav byte høj byte lav byte lav byte høj byte
Klient→Server 0x01 0x0F 0x00 0x13 0x00 0x0A 0x02 0xCD 0x01 0x72 0xCB
Svar
Overførselsretning slave enheds adresse funktionsnummer Adresse Antal flag CRC
høj byte lav byte høj byte lav byte lav byte høj byte
Server→ Klient 0x01 0x0F 0x00 0x13 0x00 0x0A 0x24 0x09
Fejl besked
Overførselsretning slave enheds adresse funktionsnummer Fejlkode CRC
lav byte høj byte
Server→ Klient 0x01 0x8F 0x02 0xC5 0xF1

Noter

  1. ↑ Modbus-protokollen i dybden. Arkiveret 29. juni 2017 på Wayback Machine National Instruments
  2. ↑ Modbus UDP-specifikation. Arkiveret 7. juli 2017 på Wayback Machine Java Modbus Library
  3. ↑ PROMOTIC - Kommunikation via Modbus-protokol . Hentet 7. juli 2015. Arkiveret fra originalen 8. juli 2015.
  4. ↑ 1 2 Modbus interface tutorial . Hentet 23. marts 2009. Arkiveret fra originalen 3. marts 2011.
  5. ↑ Om Modbus-IDA . Hentet 23. marts 2009. Arkiveret fra originalen 3. marts 2016.
  6. ↑ Charles Palmer, Sujeet Shenoi (red) Critical Infrastructure Protection III: Third IFIP WG 11. 10 International Conference, Hanover, New Hampshire, USA, 23.-25. marts 2009, Revised Selected Papers Springer, 2009 ISBN 3-6742-0479 1 , side 87
  7. ↑ 1 2 3 4 Applikationsudvikling med Modbus . Hentet 7. juli 2015. Arkiveret fra originalen 8. juli 2015.

Litteratur

Links

 UART
Fysiske lag
punkt til punkt
Netværk
Særlig
Protokoller
punkt til punkt
Netværk
Anvendelsesområder
Implementeringer
Controllere
ChaufførerMAX232