Magistrala obiektowa to protokół komunikacyjny używany w sieciach przemysłowych do łączenia urządzeń obiektowych ze sterownikami przemysłowymi. Magistrala obiektowa zmniejsza ilość okablowania potrzebnego między sterownikami a urządzeniami, ponieważ wiele urządzeń może być podłączonych do tej samej pary przewodów.

Istnieje wiele popularnych technologii magistral obiektowych, w tym Modbus, Profibus, Foundation Fieldbus, ControlNet, DeviceNet i wiele innych.

W 1979 roku firma Modicon wprowadziła nowy protokół wykorzystujący warstwę aplikacji modelu OSI, przeznaczony specjalnie do użytku ze sterownikami PLC tej firmy. Protokół ten nazwano Modbus i stał się on pierwszą powszechnie stosowaną magistralą obiektową w historii automatyki.

 

Rysunek 1. Sterownik PLC podłączony do urządzeń obiektowych 

 

Wprowadzenie do protokołu Modbus

Modbus zaprojektowano do łączenia urządzeń obiektowych ze sterownikami przemysłowymi. W momencie jego wynalezienia większość urządzeń wykorzystywała reprezentacje napięcia lub prądu do komunikowania swojego stanu. Modbus może skutecznie obsługiwać zarówno dyskretne bity odzwierciedlające stany wysokie/niskie czujników i elementów wykonawczych, jak i rejestry przechowujące wartości całkowite odpowiadające analogowym wartościom procesowym.

Powolne przechodzenie na technologie magistrali obiektowej sprawiło, że Modbus stał się jednym z najprostszych protokołów, a na przestrzeni lat dodawano jego nowe wersje.

Pierwotnie Modbus był implementowany za pośrednictwem szeregowego łącza komunikacyjnego, tj. RS-232/RS-485. Te warianty są nadal powszechnie używane pod nazwami Modbus RTU i ASCII. Z czasem protokół dostosowano do pracy za pośrednictwem TCP/IP i Ethernetu. Jest to powszechnie określane jako Modbus TCP i stanowi najczęściej stosowaną implementację protokołu Modbus we współczesnych instalacjach.

 

Model komunikacji

Modbus wykorzystuje model master/slave do komunikacji (klient/serwer w Modbus TCP). Master Modbus wysyła żądanie do urządzenia slave Modbus, które wykonuje działania i odpowiada masterowi. W tym modelu masterem jest często sterownik PLC, a urządzenia obiektowe pełnią funkcję urządzeń slave. 

Ramka komunikatu w protokole Modbus składa się z jednostki danych aplikacji (ADU) i jednostki danych protokołu (PDU). Jednostka ADU różni się w zależności od używanego typu protokołu Modbus, natomiast jednostka PDU jest niezależna od metody komunikacji.

Jednostka PDU zwykle składa się z kodu funkcji i pewnych danych. W jednostce ADU jest ona uzupełniana o adres i kod kontroli błędów. Modbus TCP wykorzystuje w jednostce ADU nagłówek MBAP (Modbus Application Protocol).

 

Rysunek 2. Jednostka ADU i PDU protokołu Modbus ASCII/RTU (u góry) oraz Modbus TCP (u dołu). Ilustracja zaadaptowana z Modbus.org

 

Aby PDU pozostała niezależna od bazowej warstwy komunikacyjnej, musi mieścić się w ograniczeniach rozmiaru określonych w pierwotnej specyfikacji szeregowej. Rozmiar ten wynosił 256 bajtów dla ADU przez RS-485. Musimy zatem uwzględnić ADU — 1 bajt adresu i 2 bajty kontroli błędów — co oznacza, że PDU jest ograniczona do łącznej wielkości 253 bajtów. Należy zauważyć, że adres w ADU jest w rzeczywistości identyfikatorem urządzenia podrzędnego w sieci Modbus.

Część danych PDU będzie zawierać pola specyficzne dla kodu funkcji wraz z faktycznie przesyłanymi danymi. Pola te zostaną szczegółowo omówione w dalszej części artykułu.

 

Reprezentacja danych

Klasyczny Modbus ma dwa tryby transmisji: ASCII i RTU.

W trybie ASCII dane są przesyłane jako znaki ASCII 0–9 i A–F, natomiast w trybie RTU dane są reprezentowane w postaci binarnej 8-bitowej. Dane i adresy są kodowane w kolejności big-endian, co oznacza, że najpierw przesyłany jest najbardziej znaczący bajt.

Dane Modbus występują w czterech podstawowych typach:

• Wejścia dyskretne
• Cewki (wyjścia)
• Rejestry wejściowe
• Rejestry przechowujące

Wejścia dyskretne reprezentują pojedynczy bit danych i są tylko do odczytu. Cewki również reprezentują pojedynczy bit, ale można je zarówno odczytywać, jak i zapisywać. Rejestry wejściowe reprezentują 16-bitowe dane tylko do odczytu, natomiast rejestry przechowujące zawierają 16-bitowe dane do odczytu i zapisu.

 

Rysunek 3. Na podstawie specyfikacji protokołu Modbus

 

Dla każdego typu w pamięci urządzenia może znajdować się maksymalnie 2^16 (65536) elementów danych. Dostęp do poszczególnych typów danych uzyskuje się za pomocą określonych kodów funkcji, a każdy typ często ma własny dedykowany blok pamięci.

Aby zaadresować element danych, urządzenie nadrzędne korzysta po prostu z zakresu od 0 do 65535. Element danych 1 znajduje się pod adresem 0x0000. Element danych 2 znajduje się pod adresem 0x0001. Element danych 65536 znajduje się pod adresem 0xFFFF. Należy pamiętać, że urządzenia nie muszą mieć wszystkich 65536 elementów danych; w rzeczywistości większość zdalnych terminali wejść/wyjść korzystających z Modbus ma ich znacznie mniej niż wynosi ten limit.

 

Transakcje Modbus

Znając sposób reprezentacji danych w Modbus, możemy teraz szczegółowo przeanalizować transakcje. Zrobimy to z perspektywy PDU, ponieważ PDU jest niezależna od warstwy komunikacyjnej.

Transakcje Modbus wykorzystują instrukcje zapisane znakami szesnastkowymi, w których pojedynczy 8-bitowy bajt ma format 0x00, a zakres dla każdego znaku wynosi od 0 do F. Rejestr 16-bitowy składa się zatem z dwóch bajtów, reprezentowanych w formacie 0x0000. 

Specyfikacja Modbus definiuje trzy typy PDU:

• Żądanie Modbus
• Odpowiedź Modbus
• Odpowiedź wyjątkowa Modbus

Urządzenie nadrzędne inicjuje żądanie za pomocą kodu funkcji, natomiast urządzenie podrzędne wysyła odpowiedź na to żądanie. Pomyślna odpowiedź powtarza kod funkcji wysłany przez urządzenie nadrzędne. Odpowiedź wyjątku zawiera ten sam kod funkcji, ale z ustawionym bitem MSB (najbardziej znaczącym), co wskazuje, że wystąpił problem. 

Specyfikacja Modbus definiuje szereg kodów funkcji. Kod funkcji 0x01 to funkcja odczytu cewek.

Rysunek 4 przedstawia przykład tego, jak może wyglądać żądanie i odpowiedź odczytu cewek. Urządzenie nadrzędne Modbus wysyła żądanie z kodem funkcji 0x01 (odczyt cewek), rozpoczynając od pierwszego elementu danych (adres 0x0000) i odczytując tylko jedną cewkę. Funkcji odczytu cewek można użyć do jednoczesnego odczytu maksymalnie 2000 (0x7D0) cewek. 

 

Rysunek 4. Transakcja odczytu cewek

 

Jeśli operacja zakończy się pomyślnie, urządzenie podrzędne odpowiada tym samym kodem funkcji oraz liczbą cewek, których stan zwraca. Stan cewek będzie zajmował n bajtów, przy czym każdy bit będzie wskazywał, czy dana cewka jest w stanie ON (1), czy OFF (0).

W tym przypadku cewka pod adresem 0x0000 jest w stanie ON. Gdyby żądanie nie powiodło się, odpowiedź wyjątku zawierałaby kod funkcji z ustawionym bitem MSB (0x81) oraz kod wyjątku wyjaśniający, co poszło nie tak. Kod wyjątku 0x02 oznacza użycie nieprawidłowego adresu danych, czyli brak cewki pod adresem 0x0000 w pamięci tego urządzenia podrzędnego. 

Kolejny przykład przedstawia transakcję zapisu pojedynczego rejestru (kod funkcji 0x06). W tym przypadku urządzenie nadrzędne żąda zapisania danych 0xA0A0 pod adresem 0x00FF. Odpowiedź urządzenia podrzędnego jest po prostu echem żądania.

Przykładowa odpowiedź wyjątku przedstawiona tutaj zawiera kod funkcji z ustawionym bitem MSB oraz kod wyjątku 0x04. Kod ten oznacza, że podczas próby wykonania żądania przez urządzenie podrzędne wystąpił błąd nieodwracalny. 

 

Rysunek 5. Transakcja zapisu pojedynczego rejestru 

 

Wszystkie kody funkcji Modbus mają podobny schemat do dwóch przykładów przedstawionych powyżej.

Rysunek 6 przedstawia listę typowych kodów funkcji wraz z kodami wyjątków używanymi w odpowiedziach wyjątków. Więcej informacji można znaleźć w specyfikacji Modbus. 

 

Rysunek 6. Kody funkcji i kody wyjątków

 

Podsumowanie

Modbus umożliwia sterownikom PLC komunikację z różnego rodzaju jednostkami zdalnymi, w tym bankami wejść/wyjść, jednostkami terminalowymi i innymi sterownikami, wykorzystując standardową metodę odczytu i zapisu zarówno informacji dyskretnych, jak i całkowitych, obejmującą niemal każdy scenariusz związany z przesyłaniem danych cyfrowych.

Modbus jest obecnie standardem branżowym i jak dotąd stanowi najpowszechniejszy przemysłowy protokół wolny od opłat licencyjnych, mimo że powstał przed większością nowoczesnych systemów sterowania. Można go znaleźć w zakładach i fabrykach na całym świecie, a pomimo długiego stażu z pewnością pozostanie istotnym protokołem przemysłowym przez wiele kolejnych lat.

 

Oryginalny artykuł opublikowany w 2019 roku