Modbus

Den aktuella versionen av sidan har ännu inte granskats av erfarna bidragsgivare och kan skilja sig väsentligt från versionen som granskades den 17 mars 2020; kontroller kräver 44 redigeringar .

Modbus  är ett öppet kommunikationsprotokoll baserat på master-slave-arkitekturen ( engelska master  -slave ; termerna klient-server används i Modbus-standarden ). Det används ofta inom industrin för att organisera kommunikation mellan elektroniska enheter . Kan användas för dataöverföring via seriella kommunikationslinjer RS-485 , RS-422 , RS-232 och TCP/IP (Modbus TCP) nätverk. Det finns också icke-standardiserade implementeringar som använder UDP [1] [2] .

Blanda inte ihop "Modbus" och "Modbus Plus". Modbus Plus är ett proprietärt protokoll som ägs av Schneider Electric . Det fysiska lagret av Modbus Plus är unikt, liknande Ethernet 10BASE-T , halv duplex över ett tvinnat par , hastighet 2 Mbps. Modbus Plus-transportprotokollet är HDLC , över vilket en förlängning för Modbus PDU-överföring är specificerad.

JBUS är en delmängd av Modbus RTU-protokollet med små skillnader i adresseringsmetoden [3] .

Historik

Modbus utvecklades av Modicon (nu ägs av Schneider Electric ) för användning i deras programmerbara logiska styrenheter . Protokollspecifikationen publicerades första gången 1979 [4] . Det var en öppen standard som beskrev formatet på meddelanden och hur de överfördes över ett nätverk av olika elektroniska enheter.

Till en början använde MODICON-styrenheter det seriella gränssnittet RS-232 [4] . Senare började RS-485-gränssnittet användas, eftersom det ger högre tillförlitlighet, gör att du kan använda längre kommunikationslinjer och ansluta flera enheter till en linje.

Många tillverkare av elektronisk utrustning har stött standarden, hundratals produkter som använder den har dykt upp på marknaden.

Modbus standard

Modbus utvecklas för närvarande av den ideella organisationen Modbus-IDA [5] .

Specifik terminologi

Modbus specificerar 4 typer av data:

Sammansättning av standarden

Modbus-standarderna består av 3 delar:

Fördelar med standarden

De främsta fördelarna med standarden är öppenhet och masskaraktär. Industrin producerar nu (2014) en mängd olika typer och modeller av sensorer, ställdon, signalbehandlings- och normaliseringsmoduler etc. Nästan alla industriella övervaknings- och styrsystem har mjukvarudrivrutiner för att arbeta med Modbus-nätverk.

Nackdelar med standarden

Standarden utvecklades i grunden 1979, med hänsyn till dåtidens behov och beräkningskapacitet, och många frågor som är relevanta för moderna industriella nätverk togs inte i beaktande [6] . Frånvaron av dessa funktioner är en konsekvens av protokollets enkelhet, vilket underlättar dess studier och påskyndar implementeringen.

Introduktion

Styrenheter på Modbus-bussen kommunicerar med en master-slav- modell baserad på transaktioner som består av en begäran och ett svar.

Vanligtvis finns det bara en master ( eng.  client , enligt den gamla terminology master )-enheten i nätverket och flera slavenheter ( eng.  server , enligt den gamla terminology - slaven ). Mastern initierar transaktioner (sänder förfrågningar). Mastern kan adressera begäran individuellt till vilken slav som helst, eller initiera ett broadcastmeddelande till alla slavar. Slavanordningen, efter att ha känt igen sin adress, svarar på en begäran riktad specifikt till den. När en sändningsbegäran tas emot genereras inget svar av slavenheter.

Modbus-specifikationen beskriver strukturen för förfrågningar och svar. Deras grund är ett elementärt protokollpaket, den så kallade PDU ( Protocol Data Unit ). Strukturen hos PDU:n är oberoende av länktypen och inkluderar en funktionskod och ett datafält. Funktionskoden är kodad som ett enbyte-fält och kan ta värden inom intervallet 1...127. Värdeområdet 128…255 är reserverat för felkoder. Datafältet kan vara av variabel längd. PDU-paketstorleken är begränsad till 253 byte.

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

För att sända ett paket över fysiska kommunikationslinjer placeras PDU:n i ett annat paket som innehåller ytterligare fält. Detta paket kallas ADU ( Application Data Unit ). ADU-formatet beror på länktypen. Det finns tre varianter av ADU, två för dataöverföring över ett asynkront gränssnitt och en över TCP/IP-nätverk:

Den allmänna strukturen för en ADU är som följer (beroende på implementeringen kan några av fälten saknas):

adressen till slavenheten (slaven). funktionskod data feldetekteringsblock

var

Den maximala ADU-storleken för seriella RS232/RS485-nätverk är 256 byte, för TCP-nätverk är den 260 byte.

För Modbus TCP ADU ser ut så här:

Transaktions ID Protokoll-ID paketets längd slavadress funktionskod data

var

Det bör noteras att det inte finns något felkontrollfält i Modbus TCP, eftersom dataintegriteten säkerställs av TCP/IP-stacken.

Kategorier av funktionskoder

Den nuvarande protokollspecifikationen definierar tre kategorier av funktionskoder:

Standardkommandon Deras beskrivning måste publiceras och godkännas av Modbus-IDA. Denna kategori inkluderar både redan definierade och för närvarande oanvända koder. Anpassade kommandon Två koder (65 till 72 och 100 till 110) som användaren kan tilldela en godtycklig funktion. Det är dock inte garanterat att någon annan enhet inte kommer att använda samma kod för att utföra en annan funktion. reserverad Denna kategori innehåller funktionskoder som inte är standard, men som redan används i enheter tillverkade av olika företag. Dessa är koderna 9, 10, 13, 14, 41, 42, 90, 91, 125, 126 och 127.

Datamodell

En av de typiska användningsområdena för protokollet är att läsa och skriva data till styrenhetsregister. Protokollspecifikationen definierar fyra datatabeller:

Tabell Objekttyp Åtkomsttyp
Flaggregister ( Coils ) en bit Läsa och skriva
Diskreta ingångar _ en bit bara läsning
Inmatningsregister _ _ 16 bitars ord bara läsning
Innehavsregister _ _ 16 bitars ord Läsa och skriva

Elementen i varje tabell nås med hjälp av en 16-bitars adress, den första cellen är adress 0. Varje tabell kan alltså innehålla upp till 65536 element. Specifikationen definierar inte vad tabellelementen ska vara fysiskt och på vilka interna enhetsadresser de ska vara tillgängliga. Det är till exempel acceptabelt att organisera överlappande tabeller. I det här fallet kommer instruktioner som fungerar med diskreta data och med 16-bitars register faktiskt att komma åt samma data.

Viss förvirring är förknippad med hur data hanteras. Modbus utvecklades ursprungligen för Modicon-kontroller. I dessa kontroller användes en speciell numrering för var och en av tabellerna. Till exempel var det första ingångsregistret platsnummer 30001, och det första lagringsregistret var 40001. Således var lagringsregisteradress 107 i Modbus-kommandot registernummer 40108 för styrenheten. Även om sådan adressmatchning inte längre är en del av standarden, kan vissa mjukvarupaket automatiskt "korrigera" adresser som användaren matat in, till exempel genom att subtrahera 40001 från lagringsregisteradressen. Referensmanual från 1996 https://modbus.org/docs/PI_MBUS_300.pdf , där liknande adressering implicit antogs, markerad som föråldrad ("föråldrad" och "ENDAST FÖR LEGACY APPLICATIONS"), aktuell protokollspecifikation https:// modbus. org/docs/Modbus_Application_Protocol_V1_1b3.pdf använder endast absolut adressering - 01 (0x01) Lässpolar 0x0000 till 0xFFFF, 03 (0x03) Läs lagringsregister 0x0000 till 0xFFFF.

Standard Modbus-protokollfunktioner

Dataåtkomst

Läser data

För att läsa värden från datatabellerna ovan, använd funktionskoderna 1-4 ( hexadecimala värden 0x01-0x04):

  • 1 (0x01)  - avläsning av värden från flera flaggregister (Läs spolestatus) .
  • 2 (0x02)  - avläsning av värden från flera diskreta ingångar (läs diskreta ingångar) .
  • 3 (0x03)  - Läser värden från flera lagringsregister (Läs innehavsregister) .
  • 4 (0x04)  - Läser värden från flera ingångsregister (Read Input Register) .

Frågan består av adressen till det första elementet i tabellen vars värde ska läsas och antalet element som ska läsas. Adressen och mängden data anges som 16-bitars nummer, den mest signifikanta byten av varje sänds först.

De begärda uppgifterna skickas i svaret. Antalet byte med data beror på antalet begärda objekt. Innan datan sänds en byte, vars värde är lika med antalet byte med data.

Värdena för lagringsregistren och ingångsregistren överförs från den angivna adressen, två byte per register, den höga byten för varje register överförs först:

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

Värdena för flaggor och digitala ingångar sänds i packad form: en bit per flagga. En betyder på, noll betyder av. Värdena för de begärda flaggorna fyller först den första byten, börjar med den minst signifikanta biten, sedan nästa byte, också från den minst signifikanta biten till de mest signifikanta. Den minst signifikanta biten av den första databyten innehåller värdet på flaggan som anges i "adress"-fältet. Om det begärda antalet flaggor inte är en multipel av åtta, fylls värdena för de extra bitarna med nollor:

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 …
Spela in ett enskilt värde
  • 5 (0x05)  - skriv värdet på en flagga (Force Single Coil) .
  • 6 (0x06)  - skriv värde till ett lagringsregister (Preset Single Register) .

Kommandot består av elementadressen (2 byte) och det inställda värdet (2 byte).

För ett lagringsregister är värdet helt enkelt ett 16-bitars ord.

För flaggor betyder värdet 0xFF00 på, 0x0000 betyder av, andra värden är ogiltiga.

Om kommandot lyckas returnerar slaven en kopia av begäran.

Spela in flera värden
  • 15 (0x0F)  - Skriv värden till flera flaggregister (Force Multiple Coils)
  • 16 (0x10)  - skriv värden till flera lagringsregister (förinställda multipelregister)

Kommandot består av adressen till elementet, antalet element som ska ändras, antalet byte av inställda värden som ska överföras och själva inställda värden. Data packas på samma sätt som i dataläskommandon.

Svaret består av startadressen och antalet ändrade element.

Ändra register
  • 22 (0x16) - skriver till ett lagringsregister med användning av "OCH"-masken och "ELLER"-masken (Mask Write Register) .

Kommandot består av adressen till ett register och två 16-bitars nummer som används som masker som kan användas för att individuellt återställa eller ställa in enskilda bitar i registret. Det slutliga resultatet bestäms av formeln:

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

Läsa med att skriva
  • 23 (0x17)  - läs/skriv flera register ( Läs/skriv flera register )

Denna funktionskod utför en kombination av en läsoperation och en skrivoperation i en Modbus-transaktion.

Dataköer
  • 24 (0x18) - läser data från kön (läs FIFO-kö)

Funktionen är utformad för att ta emot 16-bitars ord från en först-in-först-ut-kö ( FIFO ).

Filåtkomst
  • 20 (0x14) - läsning från en fil (Read File Record)
  • 21 (0x15) - skriv till en fil (Write File Record)

Dessa funktioner används för att komma åt 16-bitars register organiserade i filer med godtycklig längd. Kommandot anger filnummer, postnummer och postlängd i 16-bitars ord. Med ett enda kommando kan du skriva eller läsa flera poster, inte nödvändigtvis intilliggande.

Dessutom innehåller kommandot en kod på en byte för att indikera typen av datareferens. Den nuvarande versionen av standarden definierar endast en typ (beskriven ovan) med koden 0x06.

Diagnostik

Funktionerna nedan är för enheter på seriella linjer (Modbus RTU och Modbus ASCII).

  • 7 (0x07) - läs statussignaler (läs undantagsstatus)

Funktionen är avsedd för att få information om statusindikatorer på en fjärrenhet. Funktionen returnerar en byte, vars bit motsvarar tillståndet för en indikator.

  • 8 (0x08) - diagnostik (diagnostik)
  • 11 (0x0B) - läser händelseräknaren (Get Com Event Counter)
  • 12 (0x0C) - läser händelseloggen (Get Com Event Log)

Dessa funktioner är utformade för att testa den seriella länkens funktionalitet.

  • 17 (0x11) - läs enhetsinformation (rapportserver-ID)

Funktionen är avsedd för att få information om enhetstyp och dess tillstånd. Formatet på svaret beror på enheten.

Andra

  • 43 (0x2B) - Inkapslad gränssnittstransport

Funktionen är utformad för att överföra data i godtyckliga format (definierade av andra standarder) från mastern (klienten) till slaven (servern) och vice versa.

Typen av data som överförs bestäms av en extra kod (MEI - Modbus Encapsulated Interface) som överförs efter funktionsnumret. Standarden definierar MEI 13 (0x0D), avsedd att kapsla in CANopen- protokollet . MEI 14 (0x0E) används för att få enhetsinformation och MEI i intervallen 0-12 och 15-255 är reserverade.

Felhantering

Två typer av fel kan uppstå under kommunikation:

  • fel associerade med förvrängningar i dataöverföring;
  • logiska fel (begäran accepteras utan förvrängning, men kan inte utföras)

Vid sändning över asynkrona kommunikationslinjer detekteras fel av den första typen genom att kontrollera överensstämmelsen av den mottagna begäran med det etablerade ADU-formatet och beräkna kontrollsumman. Dessutom kan en paritetsbit användas för att kontrollera varje tecken . Om slaven upptäcker datakorruption ignoreras den mottagna begäran och inget svarsmeddelande genereras. Värden kan upptäcka ett fel utan svar.

Modbus TCP tillhandahåller inga ytterligare kontroller av dataintegritet. Distorsionsfri dataöverföring tillhandahålls av TCP/IP-protokoll.

Vid fel av den andra typen skickar slavenheten ett felmeddelande (om begäran är adresserad till denna enhet; inget svar skickas på sändningsförfrågningar). En indikation på att svaret innehåller ett felmeddelande är den inställda höga biten för funktionsnumret. Funktionsnumret följs av felkoden och vid behov ytterligare feldata istället för de vanliga uppgifterna.

Standardfelkoder

  • 01 - Mottagen funktionskod kunde inte bearbetas.
  • 02 - Den dataadress som anges i begäran är inte tillgänglig.
  • 03 - Värdet i förfrågningsdatafältet är ett ogiltigt värde.
  • 04 - Ett oåterställbart fel inträffade när slaven försökte utföra den begärda åtgärden.
  • 05 - Slavenheten har tagit emot begäran och bearbetar den, men det tar lång tid. Detta svar förhindrar mastern från att generera ett timeout-fel.
  • 06 - Slavenheten är upptagen med att bearbeta kommandot. Mastern bör upprepa meddelandet senare när slaven är ledig.
  • 07 - Slavenheten kan inte utföra den programfunktion som anges i begäran. Denna kod returneras för en misslyckad programförfrågan med funktionsnummer 13 eller 14. Mastern måste begära diagnostik- eller felinformation från slaven.
  • 08 - Slavenheten stötte på ett paritetsfel vid läsning av utökat minne. Befälhavaren kan upprepa begäran senare, men vanligtvis krävs i sådana fall reparation av utrustning.

Exempel

Nedan finns ett exempel på ett masterkommando och slavsvar (för Modbus RTU).

Begäran
Överför riktning slavenhetsadress funktionsnummer Adress Antal flaggor Antal databyte Data CRC
hög byte låg byte hög byte låg byte hög byte låg byte låg byte hög byte
Klient→Server 0x01 0x0F 0x00 0x13 0x00 0x0A 0x02 0xCD 0x01 0x72 0xCB
Svar
Överför riktning slavenhetsadress funktionsnummer Adress Antal flaggor CRC
hög byte låg byte hög byte låg byte låg byte hög byte
Server→Klient 0x01 0x0F 0x00 0x13 0x00 0x0A 0x24 0x09
Felmeddelande
Överför riktning slavenhetsadress funktionsnummer felkod CRC
låg byte hög byte
Server→Klient 0x01 0x8F 0x02 0xC5 0xF1

Anteckningar

  1. ↑ Modbusprotokollet fördjupat. Arkiverad 29 juni 2017 på Wayback Machine National Instruments
  2. ↑ Modbus UDP-specifikation. Arkiverad 7 juli 2017 på Wayback Machine Java Modbus Library
  3. ↑ PROMOTIC - Kommunikation med Modbus-protokoll . Hämtad 7 juli 2015. Arkiverad från originalet 8 juli 2015.
  4. ↑ 1 2 Handledning för Modbus-gränssnitt . Hämtad 23 mars 2009. Arkiverad från originalet 3 mars 2011.
  5. ↑ Om Modbus-IDA . Hämtad 23 mars 2009. Arkiverad från originalet 3 mars 2016.
  6. ↑ Charles Palmer, Sujeet Shenoi (red) Critical Infrastructure Protection III: Third IFIP WG 11. 10 International Conference, Hanover, New Hampshire, USA, 23-25 ​​mars 2009, Revised Selected Papers Springer, 2009 ISBN 3-672-0479 1 , sid 87
  7. ↑ 1 2 3 4 Applikationsutveckling med Modbus . Hämtad 7 juli 2015. Arkiverad från originalet 8 juli 2015.

Litteratur

Länkar

 UART
Fysiska lager
punkt till punkt
Nätverk
Särskild
Protokoll
punkt till punkt
Nätverk
Användningsområden
Genomföranden
Styrenheter
FörareMAX232