Modbus

Aktuální verze stránky ještě nebyla zkontrolována zkušenými přispěvateli a může se výrazně lišit od verze recenzované 17. března 2020; kontroly vyžadují 44 úprav .

Modbus  je otevřený komunikační protokol založený na architektuře master-slave ( anglicky master  -slave ; ve standardu Modbus se používá termín klient-server ). Je široce používán v průmyslu k organizaci komunikace mezi elektronickými zařízeními . Lze použít pro přenos dat přes sériové komunikační linky RS-485 , RS-422 , RS-232 a sítě TCP/IP (Modbus TCP). Existují i ​​nestandardní implementace využívající UDP [1] [2] .

Nezaměňujte „Modbus“ a „Modbus Plus“. Modbus Plus je proprietární protokol vlastněný společností Schneider Electric . Fyzická vrstva Modbus Plus je jedinečná, podobná Ethernetu 10BASE-T , poloviční duplex přes jednu kroucenou dvojlinku , rychlost 2 Mbps. Transportní protokol Modbus Plus je HDLC , přes který je specifikováno rozšíření pro přenos Modbus PDU.

JBUS je podmnožinou protokolu Modbus RTU s drobnými rozdíly ve způsobu adresování [3] .

Historie

Modbus byl vyvinut společností Modicon (nyní ve vlastnictví Schneider Electric ) pro použití v jejich programovatelných logických automatech . Specifikace protokolu byla poprvé publikována v roce 1979 [4] . Jednalo se o otevřený standard, který popisoval formát zpráv a způsob jejich přenosu přes síť různých elektronických zařízení.

Zpočátku kontroléry MODICON používaly sériové rozhraní RS-232 [4] . Později se začalo používat rozhraní RS-485, protože poskytuje vyšší spolehlivost, umožňuje používat delší komunikační linky a připojit více zařízení na jednu linku.

Řada výrobců elektronických zařízení tento standard podporuje, na trhu se objevily stovky produktů, které jej využívají.

Modbus standard

Modbus v současnosti vyvíjí nezisková organizace Modbus-IDA [5] .

Specifická terminologie

Modbus specifikuje 4 typy dat:

Složení normy

Standardy Modbus se skládají ze 3 částí:

Výhody standardu

Hlavní předností standardu je otevřenost a masový charakter. Průmysl nyní (2014) vyrábí velké množství typů a modelů senzorů, akčních členů, modulů pro zpracování signálu a normalizace atd. Téměř všechny průmyslové monitorovací a řídicí systémy mají softwarové ovladače pro práci se sítěmi Modbus.

Nevýhody standardu

Norma byla v zásadě vyvinuta v roce 1979 s přihlédnutím k tehdejším potřebám a výpočetním možnostem a mnoho otázek relevantních pro moderní průmyslové sítě nebylo zohledněno [6] . Absence těchto vlastností je důsledkem jednoduchosti protokolu, která usnadňuje jeho studium a urychluje implementaci.

Úvod

Regulátory na sběrnici Modbus komunikují pomocí modelu master-slave na základě transakcí skládajících se z požadavku a odpovědi.

Obvykle je v síti pouze jedno master ( angl.  client , podle staré terminologie master ) zařízení a několik slave ( angl.  server , podle staré terminologie slave ) zařízení. Master inicializuje transakce (vysílá požadavky). Master může adresovat požadavek jednotlivě kterémukoli podřízenému zařízení nebo iniciovat vysílanou zprávu všem podřízeným. Podřízené zařízení poté, co rozpoznalo svou adresu, odpoví na požadavek adresovaný konkrétně jemu. Když je přijat požadavek na vysílání, podřízená zařízení nevygenerují odpověď.

Specifikace Modbus popisuje strukturu požadavků a odpovědí. Jejich základem je základní protokolový balíček, tzv. PDU ( Protocol Data Unit ). Struktura PDU je nezávislá na typu linky a zahrnuje funkční kód a datové pole. Funkční kód je zakódován jako jednobajtové pole a může nabývat hodnot v rozsahu 1…127. Rozsah hodnot 128…255 je vyhrazen pro chybové kódy. Datové pole může mít proměnnou délku. Velikost paketu PDU je omezena na 253 bajtů.

Modbus PDU
funkční kód data
1 bajt N ≤ 252 (bajt)

Pro přenos paketu přes fyzické komunikační linky se PDU umístí do jiného paketu obsahujícího další pole. Tento balíček se nazývá ADU ( Application Data Unit ). Formát ADU závisí na typu odkazu. Existují tři varianty ADU, dvě pro přenos dat přes asynchronní rozhraní a jedna přes sítě TCP/IP:

Obecná struktura ADU je následující (v závislosti na implementaci mohou některá pole chybět):

adresa podřízeného (slave) zařízení funkční kód data blok detekce chyb

kde

Maximální velikost ADU pro sériové sítě RS232/RS485 je 256 bajtů, pro sítě TCP je to 260 bajtů.

Pro Modbus TCP ADU vypadá takto:

ID transakce ID protokolu délka balení adresa otroka funkční kód data

kde

Je třeba poznamenat, že v Modbus TCP není žádné pole kontroly chyb, protože integrita dat je zajištěna zásobníkem TCP / IP.

Kategorie kódů funkcí

Aktuální specifikace protokolu definuje tři kategorie funkčních kódů:

Standardní příkazy Jejich popis musí být zveřejněn a schválen Modbus-IDA. Tato kategorie zahrnuje jak již definované, tak aktuálně nepoužívané kódy. Vlastní příkazy Dva rozsahy kódů (65 až 72 a 100 až 110), kterým může uživatel přiřadit libovolnou funkci. Není však zaručeno, že některé jiné zařízení nebude používat stejný kód k provedení jiné funkce. Rezervováno Tato kategorie zahrnuje kódy funkcí, které nejsou standardní, ale jsou již používány v zařízeních vyráběných různými společnostmi. Jedná se o kódy 9, 10, 13, 14, 41, 42, 90, 91, 125, 126 a 127.

Datový model

Jedním z typických použití protokolu je čtení a zápis dat do registrů řadiče. Specifikace protokolu definuje čtyři datové tabulky:

Stůl Typ položky Typ přístupu
Vlajkové registry ( cívky ) jeden kousek číst a psát
Diskrétní vstupy _ jeden kousek pouze čtení
Vstupní registry _ 16bitové slovo pouze čtení
Vedení registrů _ 16bitové slovo číst a psát

K prvkům v každé tabulce se přistupuje pomocí 16bitové adresy, první buňka je adresa 0. Každá tabulka tedy může obsahovat až 65536 prvků. Specifikace nedefinuje, jaké prvky tabulky by měly být fyzicky a na jakých interních adresách zařízení by měly být dostupné. Například je přijatelné uspořádat překrývající se tabulky. V tomto případě budou instrukce, které pracují s diskrétními daty a s 16bitovými registry, ve skutečnosti přistupovat ke stejným datům.

Určitý zmatek je spojen se způsobem adresování dat. Modbus byl původně vyvinut pro regulátory Modicon. V těchto kontrolérech bylo použito speciální číslování pro každou z tabulek. Například první vstupní registr měl číslo pozice 30001 a první udržovací registr byl 40001. Adresa 107 udržovacího registru v příkazu Modbus byla tedy číslo registru 40108 řadiče. I když takové porovnávání adres již není součástí standardu, některé softwarové balíčky mohou automaticky „opravovat“ adresy zadané uživatelem, například odečtením 40001 od adresy registru úložiště. Referenční příručka z roku 1996 https://modbus.org/docs/PI_MBUS_300.pdf , kde bylo podobné adresování implicitně převzato, označeno jako zastaralé ("zastaralé" a "POUZE PRO STARŠÍ APLIKACE"), aktuální specifikace protokolu https:// modbus. org/docs/Modbus_Application_Protocol_V1_1b3.pdf používá pouze absolutní adresování - 01 (0x01) Read Coils 0x0000 až 0xFFFF, 03 (0x03) Read Holding Registers 0x0000 až 0xFFFF.

Standardní funkce protokolu Modbus

Přístup k datům

Čtení dat

Chcete-li číst hodnoty z datových tabulek uvedených výše, použijte kódy funkcí 1-4 ( hexadecimální hodnoty 0x01-0x04):

  • 1 (0x01)  - čtení hodnot z několika příznakových registrů (Read Coil Status) .
  • 2 (0x02)  - čtení hodnot z několika diskrétních vstupů (Read Discrete Inputs) .
  • 3 (0x03)  - Čtení hodnot z několika uchovávacích registrů (Read Holding Registers) .
  • 4 (0x04)  - Čtení hodnot z několika vstupních registrů (Read Input Registers) .

Dotaz se skládá z adresy prvního prvku tabulky, jehož hodnota má být načtena, a počtu prvků, které mají být načteny. Adresa a množství dat jsou uvedeny jako 16bitová čísla, přičemž nejvýznamnější byte každého z nich je přenášen jako první.

Požadovaná data jsou odeslána v odpovědi. Počet bajtů dat závisí na počtu požadovaných položek. Před daty se přenese jeden bajt, jehož hodnota se rovná počtu bajtů dat.

Hodnoty úložných registrů a vstupních registrů se přenášejí počínaje zadanou adresou, dva bajty na registr, nejprve se přenese horní bajt každého registru:

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

Hodnoty příznaků a digitálních vstupů jsou přenášeny v zabalené formě: jeden bit na příznak. Jedna znamená zapnuto, nula znamená vypnuto. Hodnoty požadovaných příznaků vyplňují nejprve první bajt, počínaje nejméně významným bitem, poté další bajty, rovněž od nejméně významného bitu k nejvýznamnějším. Nejméně významný bit prvního datového bytu obsahuje hodnotu příznaku zadaného v poli "adresa". Pokud požadovaný počet příznaků není násobkem osmi, pak jsou hodnoty extra bitů vyplněny nulami:

bajt 1 … bajt 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 …
Záznam jedné hodnoty
  • 5 (0x05)  - zapište hodnotu jednoho příznaku (Force Single Coil) .
  • 6 (0x06)  - zápis hodnoty do jednoho úložného registru (Preset Single Register) .

Příkaz se skládá z adresy prvku (2 bajty) a nastavené hodnoty (2 bajty).

U přídržného registru je hodnota jednoduše 16bitové slovo.

U příznaků hodnota 0xFF00 znamená zapnuto, 0x0000 znamená vypnuto, ostatní hodnoty jsou neplatné.

Pokud je příkaz úspěšný, slave vrátí kopii požadavku.

Záznam více hodnot
  • 15 (0x0F)  - Zápis hodnot do více příznakových registrů (Force Multiple Coils)
  • 16 (0x10)  - zápis hodnot do několika registrů úložiště (Preset Multiple Registers)

Příkaz se skládá z adresy prvku, počtu prvků, které se mají změnit, počtu bajtů nastavených hodnot, které mají být přeneseny, a samotných nastavených hodnot. Data jsou zabalena stejným způsobem jako v příkazech pro čtení dat.

Odpověď se skládá z počáteční adresy a počtu změněných prvků.

Změna registrů
  • 22 (0x16) - zápis do jednoho úložného registru pomocí masky "AND" a masky "OR" (Mask Write Register) .

Příkaz se skládá z adresy registru a dvou 16bitových čísel, která se používají jako masky, které lze použít k individuálnímu resetování nebo nastavení jednotlivých bitů v registru. Konečný výsledek je určen vzorcem:

Výsledek = ( Current_value AND Mask_AND ) OR ( Mask_OR AND (NOT Mask_AND ))

Čtení s psaním
  • 23 (0x17)  - čtení/zápis více registrů ( Čtení/zápis více registrů )

Tento funkční kód provádí kombinaci jedné operace čtení a jedné operace zápisu v jedné transakci Modbus.

Datové fronty
  • 24 (0x18) - čtení dat z fronty (Read FIFO Queue)

Funkce je navržena tak, aby přijímala 16bitová slova z fronty FIFO (first-in-first-out).

Přístup k souboru
  • 20 (0x14) - čtení ze souboru (Read File Record)
  • 21 (0x15) - zápis do souboru (Write File Record)

Tyto funkce se používají pro přístup k 16bitovým registrům organizovaným do souborů o libovolné délce záznamů. Příkaz specifikuje číslo souboru, číslo záznamu a délku záznamu v 16bitových slovech. Jediným příkazem můžete zapisovat nebo číst několik záznamů, ne nutně sousedních.

Příkaz navíc obsahuje jednobajtový kód označující typ datového odkazu. Aktuální verze standardu definuje pouze jeden typ (popsaný výše) s kódem 0x06.

Diagnostika

Níže uvedené funkce jsou pro zařízení na sériových linkách (Modbus RTU a Modbus ASCII).

  • 7 (0x07) - čtení stavových signálů (Read Exception Status)

Funkce je určena pro získávání informací o stavových indikátorech na vzdáleném zařízení. Funkce vrací jeden bajt, jehož každý bit odpovídá stavu jednoho indikátoru.

  • 8 (0x08) - diagnostika (Diagnostika)
  • 11 (0x0B) - čtení počítadla událostí (Get Com Event Counter)
  • 12 (0x0C) - čtení protokolu událostí (Get Com Event Log)

Tyto funkce jsou určeny k testování funkčnosti sériové linky.

  • 17 (0x11) - čtení informací o zařízení (ID serveru sestav)

Funkce je určena pro získání informací o typu zařízení a jeho stavu. Formát odpovědi závisí na zařízení.

Ostatní

  • 43 (0x2B) - Encapsulated Interface Transport

Funkce je navržena pro přenos dat v libovolných formátech (definovaných jinými standardy) z master (klienta) na slave (server) a naopak.

Typ přenášených dat je určen doplňkovým kódem (MEI - Modbus Encapsulated Interface) vysílaným za číslem funkce. Norma definuje MEI 13 (0x0D), která má zapouzdřit protokol CANopen . MEI 14 (0x0E) se používá k získání informací o zařízení a MEI v rozsahu 0-12 a 15-255 jsou vyhrazeny.

Zpracování chyb

Během komunikace mohou nastat dva typy chyb:

  • chyby spojené se zkreslením přenosu dat;
  • logické chyby (žádost přijata bez zkreslení, ale nelze ji provést)

Při přenosu po asynchronních komunikačních linkách jsou chyby prvního typu detekovány kontrolou souladu přijatého požadavku se zavedeným formátem ADU a výpočtem kontrolního součtu. Navíc lze ke kontrole každého znaku použít paritní bit . Pokud slave zařízení detekuje poškození dat, přijatý požadavek je ignorován a nevygeneruje se žádná zpráva s odpovědí. Hostitel může detekovat chybu bez odezvy.

Modbus TCP neposkytuje další kontroly integrity dat. Přenos dat bez zkreslení zajišťují protokoly TCP/IP.

Při chybách druhého typu podřízené zařízení odešle chybovou zprávu (pokud je požadavek adresován tomuto zařízení; na broadcastové požadavky není odeslána žádná odpověď). Indikace, že odpověď obsahuje chybovou zprávu, je nastavený horní bit čísla funkce. Za číslem funkce následuje kód chyby a případně další chybové údaje místo obvyklých údajů.

Standardní chybové kódy

  • 01 - Přijatý kód funkce nelze zpracovat.
  • 02 - Datová adresa uvedená v požadavku není dostupná.
  • 03 – Hodnota obsažená v datovém poli požadavku je neplatná.
  • 04 - Došlo k neopravitelné chybě, když se slave zařízení pokusilo provést požadovanou akci.
  • 05 - Podřízené zařízení přijalo požadavek a zpracovává jej, ale trvá to dlouho. Tato odpověď zabrání masteru ve generování chyby časového limitu.
  • 06 - Podřízené zařízení je zaneprázdněno zpracováním příkazu. Master by měl zprávu zopakovat později, až bude slave volný.
  • 07 - Podřízené zařízení nemůže vykonat funkci programu specifikovanou v požadavku. Tento kód je vrácen při neúspěšném požadavku programu pomocí funkčních čísel 13 nebo 14. Master si musí vyžádat diagnostické nebo chybové informace od slave.
  • 08 - Podřízené zařízení zjistilo chybu parity při čtení rozšířené paměti. Velitel může požadavek opakovat později, ale obvykle je v takových případech nutná oprava zařízení.

Příklady

Níže je uveden příklad odezvy hlavního povelu a podřízeného zařízení (pro Modbus RTU).

Žádost
Směr přenosu adresa podřízeného zařízení číslo funkce Adresa Počet příznaků Počet datových bytů Data CRC
vysoký bajt nízký bajt vysoký bajt nízký bajt vysoký bajt nízký bajt nízký bajt vysoký bajt
Klient→Server 0x01 0x0F 0x00 0x13 0x00 0x0A 0x02 0xCD 0x01 0x72 0xCB
Odpovědět
Směr přenosu adresa podřízeného zařízení číslo funkce Adresa Počet příznaků CRC
vysoký bajt nízký bajt vysoký bajt nízký bajt nízký bajt vysoký bajt
Server→Klient 0x01 0x0F 0x00 0x13 0x00 0x0A 0x24 0x09
Chybové hlášení
Směr přenosu adresa podřízeného zařízení číslo funkce chybový kód CRC
nízký bajt vysoký bajt
Server→Klient 0x01 0x8F 0x02 0xC5 0xF1

Poznámky

  1. ↑ Podrobný protokol Modbus. Archivováno 29. června 2017 ve Wayback Machine National Instruments
  2. ↑ Specifikace Modbus UDP. Archivováno 7. července 2017 v knihovně Wayback Machine Java Modbus Library
  3. ↑ PROMOTIC - Komunikace protokolem Modbus . Získáno 7. července 2015. Archivováno z originálu dne 8. července 2015.
  4. ↑ 1 2 Výukový program rozhraní Modbus . Získáno 23. března 2009. Archivováno z originálu 3. března 2011.
  5. ↑ O Modbus-IDA . Získáno 23. března 2009. Archivováno z originálu 3. března 2016.
  6. ↑ Charles Palmer, Sujeet Shenoi (ed.) Ochrana kritické infrastruktury III: Třetí IFIP WG 11. 10 International Conference, Hanover, New Hampshire, USA, 23.-25. března 2009, Revised Selected Papers Springer, 2009 ISBN 3-642-04797- 1 , strana 87
  7. ↑ 1 2 3 4 Vývoj aplikací pomocí Modbus . Získáno 7. července 2015. Archivováno z originálu dne 8. července 2015.

Literatura

Odkazy

 UART
Fyzické vrstvy
bod k bodu
Síť
Speciální
Protokoly
bod k bodu
Síť
Oblasti použití
Implementace
Ovladače
ŘidičiMAX232