English
Российский

---

Сторінку заморожено, актуальна тут.

Модулі <ModBus> підсистем "Збір даних" та "Транспортні протоколи"

Вступ

ModBus — комунікаційний протокол, заснований на клієнт-серверній архітектурі. Розроблений фірмою Modicon для використання у контролерах з програмованою логікою (PLC). Став стандартом де-факто у промисловості та широко застосовується для організації зв'язку промислового електронного обладнання. Використовується для передачі даних через послідовні лінії зв'язку RS-485, RS-422, RS-232, а також мережі TCP/IP. На цей час підтримується некомерційною організацією ModBus-IDA.

Існує три режими протоколу: ModBus/RTU, ModBus/ASCII та ModBus/TCP. Перші два використовують послідовні лінії зв'язку (переважно RS-485, рідше RS-422/RS-232), останній використовує для передачі даних мережі TCP/IP.

Модуль збору даних надає можливість збирати інформацію з різних джерел за протоколом ModBus у всіх режимах. Також модулем реалізуються функції горизонтального резервування, а саме спільної роботи з віддаленою станцією цього-ж рівня. В той же час модуль протоколу дозволяє сформувати та видати дані за протоколом ModBus у різних режимах та через інтерфейси, які підтримуються модулями підсистеми "Транспорти".

1. Загальний опис протоколу ModBus

Протокол ModBus/RTU припускає один ведучий (запити) пристрій у лінії (master), який може передавати команди одному або декільком веденим пристроям (slave), звертаючись до них за унікальною у лінії адресою. Синтаксис команд протоколу дозволяє адресувати 247 пристроїв на одній лінії зв'язку стандарту RS-485 (рідше RS-422 або RS-232). У випадку з режимом TCP адресація виключена з протоколу, оскільки здійснюється на рівні TCP/IP стека.

Ініціатива здійснення обміну завжди виходить від ведучого пристрою. Ведені пристрої прослуховують лінію зв'язку. Майстер подає запит (посилка, послідовність байт) у лінію та переходить в стан прослуховування лінії зв'язку. Ведений пристрій відповідає на запит, який надійшов у його адресу.

Закінчення посилки відповіді визначається залежно від режиму. У режимі RTU закінчення посилки визначається за інтервалом часу між закінченням прийому попереднього байту та початком прийому наступного, час символу. Якщо цей інтервал перевищив час, потрібний для прийому півтори байти на визначеній швидкості передачі то прийом фрейму відповіді вважається завершеним. У режимі ASCII критерієм закінчення посилки є символ '\r', а у режимі TCP — очікуваний розмір посилки, інформація про який присутня у заголовку пакету.

1.1. Адресація

Всі операції з даними прив'язано до нуля, кожний вид даних (регістр, біт, регістр входу або біт входу) починається з адреси 0 та закінчується 65535.

1.2. Стандартні коди функцій

У протоколі ModBus можна відокремити декілька множин команд (Таблиця 1).

Таблиця 1: Підмножина команд протоколу ModBus

Модулем збору даних використовуються команди 0x03 та 0x06(0x10) для читання та запису регістрів, 0x01 та 0x05(0x0F) для читання та запису бітів, 0x02 та 0x04 для читання біту та регістру входу відповідно. Для реалізації інших-нетипових команд модулем передбачено функцію API користувацького програмування, яку можна викликати з процедури шаблону, надсилаючи довільні PDU пакети та обробляючи отримані у відповідь.

Модуль протоколу обробляє запити командами 0x03 та 0x06(0x10) для читання та запису регістрів, 0x01 та 0x05(0x0F) для читання та запису бітів.

2. Модуль реалізації протоколу

Модуль протоколу ModBus містить код реалізації протокольної частини ModBus, а саме особливості варіантів протоколів ModBus/TCP, ModBus/RTU та ModBus/ASCII. Модуль протоколу, спільно з обраним транспортом, активно використовується модулем збору даних для здійснення безпосередніх запитів. Оскільки модуль протоколу є автономним то, використовуючи його, можна створювати додаткові модулі збору даних за посередництвом нестандартних функцій розширення ModBus різного обладнання автоматизації.

2.1. API функції вихідних запитів

API функції вихідних запитів (messIO()? EN RU) оперують обміном блоками PDU, загорнутими у XML-пакети з відповідною структурою:

Результатний pdu замінює pdu запиту у XML-пакеті, а також встановлюється атрибут "err" з кодом та текстом помилки, якщо така мала місце.

2.2. Обслуговування запитів за протоколом ModBus

Вхідна частина обслуговування запитів до модуля протоколу здійснює перевірку та обробку запитів за посередництвом об'єктів вузлів, передбачених модулем (рис.1). Фактично реалізується механізм, який дозволяє виконувати системою OpenSCADA роль серверу ModBus/TCP або підлеглого пристрою ModBus/RTU та ModBus/ASCII. Таким чином система OpenSCADA отримує можливість використовуватися у ролі будь якого учасника мереж ModBus.

Рис.1. Вкладка переліку вузлів обслуговування вхідних запитів протоколу.

Вузол протоколу еквівалентний фізичному вузлу пристрою мережі ModBus. Вузол протоколу може працювати у трьох режимах:

• "Дані" — режим відображення даних системи OpenSCADA на масиви регістрів та бітів ModBus з передачею їх за запитом клієнтського вузла або майстра.
• "Шлюз вузла" — режим переспрямування (шлюзування) запитів до вузла у іншій мережі ModBus через цей вузол.
• "Шлюз мережі" — режим переспрямування запитів до будь якого вузла у іншу мережі ModBus, фактично виконуючи інтеграцію декількох мереж ModBus у одну.

Оскільки вузлів протоколу може бути створено багато то виходить, що на одному інтерфейсі, тобто у одній мережі, одна станція на основі OpenSCADA може прозоро надавати декілька вузлів мережі ModBus з різними даними.

Розглянемо особливості конфігурації вузла протоколу у різних режимах.

Режим вузла протоколу "Дані"

Режим використовується для відображення даних системи OpenSCADA на масиви регістрів та бітів ModBus. Загальна конфігурація вузла здійснюється у вкладці "Вузол" (рис.2) параметрами:

• Стан вузла, а саме: статус, "Включено" та ім'я БД, яка містить конфігурацію.
• Ідентифікатор, ім'я та опис вузла.
• Стан, у який переводити вузол при завантажені: "Включено".
• Адреса вузла мережі ModBus від 1 до 247.
• Вхідний транспорт, до мережі якого належить вузол. Обирається із переліку вхідних транспортів підсистеми "Транспорти" OpenSCADA. Вказання у якості транспорту символу "*" робить цей вузол учасником будь якої мережі ModBus з обробкою запитів від будь якого транспорту.
• Варіант протоколу ModBus, запити у якому має обробляти вузол із переліку: Всі, RTU, ASCII, TCP/IP.
• Вибір режиму, у даному випадку це режим "Дані".
• Період обчислення даних у секундах. Вказує періодичність обробки даних які формуються для запитів, а саме: таблиці даних ModBus, програми обчислення даних та обслуговування посилання на дані OpenSCADA.

Вузлом у цьому режимі обробляються наступні стандартні команди протоколу ModBus:

• 0x01 — читання групи бітів;
• 0x02 — читання групи бітів входів;
• 0x03 — читання групи регістрів;
• 0x04 — читання групи регістрів входів;
• 0x05 — встановлення одного біту;
• 0x06 — встановлення одного регістру;
• 0x0F — встановлення групи бітів;
• 0x10 — встановлення групи регістрів.

Рис.2. Вкладка "Вузол" сторінки конфігурації вузла протоколу у режимі "Дані".

Для формування таблиці відбиття даних мережі ModBus, а саме регістрів та бітів передбачається вкладка "Дані" (рис.3). Вкладка "Дані" містить таблицю параметрів та програму обробки параметрів з визначеною мовою програмування, доступною у системі OpenSCADA. Таблиця містить параметри з властивостями:

• Id — ідентифікатор параметра. є ключовим для формування таблиць регістрів та бітів ModBus. Регістри та біти ModBus визначаються наступним чином:
  R{N}[w], RI{N}[w] — специфічна форма регістру (та входу), може бути розширено суфіксами: "i"—Int32, "f"—Float, "d"—Double, "s"—Рядок (розмір по замовченню 10 та до 100 регістрів);
  R:{N}:[w], RI:{N}:[w] — класична форма регістру (та входу), може бути розширено суфіксами: "i4"—Int32, "i8"—Int64, "f"—Float, "d"—Double, "s"—Рядок;
  C{N}[w], CI{N}[w], C:{N}:[w], CI:{N}:[w] — біт (та вхід).
  

  Де:

  {N} — адреса даних ModBus пристрою (десяткова, шістнадцяткова, або вісімкова) [0...65535];
  w — необов'язковий символ для індикації можливості запису.
  

  Приклади:

  "R0x300" — доступ до регістру;
  "C100w" — доступ до біту, доступний для запису;
  "R_f200" — отримати реальне з регістрів 200 та 201;
  "R_i400,300" — отримати int32 з регістрів 400 та 300;
  "R_s15,20" — отримати рядок, блок регістрів, з регістру 15 та розміром 20;
  "R_i8:0x10:w" — отримати та встановити int64 у регістри [0x10-0x13];
  "R_d:0x20,0x30" — отримати реальне подвійної точності (8 байтів) з регістрів [0x20,0x30-0x32].

В таблиці, по замовченню, визначаються декілька параметрів спеціального призначення:

• f_frq — частота обчислення таблиці програмою;
• f_start — ознака першого виконання — запуску програми.
• f_stop — ознака останнього виконання — зупинки програми.

Оскільки у вказівнику розширених типів регістрів може використовуватися недозволений символ ',' то доступ до нього із процедури можна здійснити тільки альтернативним способом, через об'єкт "arguments":

arguments["R_s10,5w"] = "9876543210";

Рис.3. Вкладка "Дані", сторінки конфігурації вузла протоколу у режимі "Дані".

Для вказаних у якості зв'язків параметрів можна встановити зв'язки тільки для вимкненого вузла протоколу у вкладці "Зв'язки" (рис.4).

Рис.4. Вкладка "Зв'язки" сторінки конфігурації вузла протоколу у режимі "Дані".

Режим вузла протоколу "Шлюз вузла"

Режим використовується для прокидання запиту до окремого пристрою у іншій мережі ModBus із мережі ModBus, для якого сконфігуровано цей вузол. Загальна конфігурація вузла здійснюється у вкладці "Вузол" (рис.5) параметрами:

• Стан вузла, а саме: стан "Включено" та ім'я БД, яка містить конфігурацію.
• Ідентифікатор, ім'я та опис вузла.
• Стан, у який переводити вузол при завантажені: "Включений".
• Адрес вузла вихідної мережі ModBus від 1 до 247.
• Вхідний транспорт, до мережі якої має стосунок вузол. Обирається з переліку вхідних транспортів підсистеми "Транспорти" OpenSCADA. Вказання у якості транспорту символу "*" робить цей вузол учасником будь якої мережі ModBus з обробкою запитів від будь якого транспорту.
• Варіант протоколу ModBus запити у якому має оброблятися вузлом з переліку: Всі, RTU, ASCII, TCP/IP.
• Вибір режиму, в цьому випадку цей режим "Шлюз вузла".
• Транспорт, у який переспрямовують запит, з переліку вихідних транспортів підсистеми "Транспорти".
• Протокол у якому переспрямовувати запит.
• Адреса вузла мережі ModBus, від 1 до 247, у яку переспрямовується запит.

Рис.5. Вкладка "Вузол" сторінки конфігурації вузла протоколу у режимі "Шлюз вузла".

Режим вузла протоколу "Шлюз мережі"

Режим використовується для прокидання запитів мережі цілком у іншу мережу ModBus з мережі ModBus для якої сконфігуровано цей вузол протоколу. Тобто запит на пристрій з будь якою адресою буде спрямовуватися у іншу мережу, без переадресування. Загальна конфігурація вузла протоколу здійснюється у вкладці "Вузол" (рис.6) параметрами:

• Стан вузла, а саме: статус, "Включено" та ім'я БД, яка містить конфігурацію.
• Ідентифікатор, ім'я та опис вузла.
• Стан, у який переводити вузол при завантажені: "Включений".
• Вхідний транспорт мережі, з якого прокидаються запити. Обирається з переліку вхідних транспортів підсистеми "Транспорти" OpenSCADA.
• Варіант протоколу ModBus, запити у якому має обробляти вузол із переліку: Всі, RTU, ASCII, TCP/IP.
• Вибір режиму, у цьому випадку цей режим "Шлюз мережі".
• Транспорт мережі, у яку переспрямовувати запит, з переліку вихідних транспортів підсистеми "Транспорти".
• Протокол у якому переспрямовувати запит.

Рис.6. Вкладка "Вузол" сторінки конфігурації вузла протоколу у режимі "Шлюз мережі".

2.3 Звіт запитів ModBus

Для можливості контролю та діагностики за коректністю здійснення запитів різними компонентами модулем надається можливість включення звіту запитів, що проходять через модуль протоколу. Звіт включається вказанням ненульової кількості записів у вкладці "Звіт" сторінки модуля протоколу (рис.7).

Рис.7. Вкладка "Звіт" сторінки модуля протоколу.

3. Модуль збору даних

Модуль збору даних надає можливість опитування та запису регістрів та бітів пристроїв за посередництвом режиму протоколів TCP, RTU, ASCII та команд запиту 0x01 — 0x06, 0x0F, 0x10.

3.1. Контролер даних

Для додання джерела даних ModBus створюється та конфігурується контролер у системі OpenSCADA. Приклад вкладки конфігурації контролеру даного типу зображено на рис.8.

Рис.8. Вкладка конфігурації контролеру.

За допомогою цієї вкладки можна встановити:

• Стан контролеру, а саме: Статус, "Включено", Запущено" та ім'я БД, яка містить конфігурацію.
• Ідентифікатор, ім'я та опис контролеру.
• Стан, у який переводити контролер при завантажені: "Включено" та "Запущено".
• Ім'я таблиць для зберігання конфігурації параметрів контролеру стандартного та логічного типу.
• Політика планування та пріоритет задачі збору даних.
• ModBus протокол, який використовується для опитування фізичного пристрою (TCP/IP, RTU або ASCII).
• Адреса вихідного транспорту? EN RU з переліку сконфігурованих вихідних транспортів у підсистемі "Транспорти" OpenSCADA.
• ModBus вузол призначення. У випадку з протоколами RTU та ASCII це індивідуальна адреса фізичного пристрою, а при TCP/IP — ідентифікатор одиниці.
• Об'єднання фрагментів регістрів. Стандартні функції 01-04 дозволяють запитати одразу декілька суміжних регістрів або бітів. Така стратегія часто дозволяє оптимізувати трафік та час. Однак потрібні регістри не завжди розташовані суміжно один до одного та така опція дозволяє збирати їх у блоки до 100 регістрів або 1600 бітів.
  До встановлення цього параметру треба підходити з обережністю, оскільки не всі пристрої підтримують доступ до регістрів між фрагментами.
  
• Використовувати функції запису декількох елементів (0x0F,0x10). Замість функцій одно-елементного запису буде використано багато-елементні.
• Час очікування підключення у мілісекундах. Вказує проміжок час, на протязі якого очікувати відповіді. У випадку вказання нульового значення використовується час очікування по замовченню у транспорті. Дозволяє враховувати індивідуальні властивості контролеру у загальній мережі.
• Час відновлення підключення у секундах. Указує проміжок часу за вичерпанням якого здійснювати повторну спробу запиту до раніш недоступного пристрою.
• Спроб запиту для протоколів RTU та ASCII. Вказує на кількість спроб повтору запиту у випадку отримання неповної або пошкодженої відповіді.
• Максимальний розмір блоку запиту (байти). Встановлює максимальний розмір блоку групових запитів регістрів та бітів, у байтах. Корисний для контролерів зі схожим обмеженням.

3.2. Параметри

Модуль збору даних надає два типи параметру: "Стандартний"(std) та "Логічний"(logic). Додатковими конфігураційними полями параметрів цього модуля є:

• "Стандартний"(std):
  • Перелік атрибутів — містить структурований перелік конфігурації атрибутів ModBus.
• "Логічний"(logic):
  • Шаблон параметру — адреса шаблону параметру DAQ.

Стандартний тип параметру(std)

Головну сторінку конфігурації параметру стандартного типу представлено на рисунку 9.

Рис.9. Вкладка конфігурації параметру стандартного типу.

Структура атрибуту, у параметрі переліку атрибутів, записується наступним чином: "{dt}:{numb}:{rw}:{id}:{name}".
Де:

Приклади:

Рядок, який починається з символу '#', вважається коментарем та не обробляється.

Відповідно до визначених переліком атрибутів здійснюється опитування та створення атрибутів параметру (рис.10).

Рис.10. Вкладка атрибутів параметру стандартного типа.

Логічний тип параметру(logic)

Головну сторінку конфігурації параметру логічного типу представлено на рисунку 11.

Рис.11. Вкладка конфігурації параметру логічного типа.

При формуванні шаблону, для логічного типу параметру даного контролеру, не треба враховувати формат посилання шаблону, оскільки він не використовується та може бути опущений. Саме ж значення посилання, при конфігурації шаблону (рис.12), записується у форматі: "{dt}:{numb}:{rw}".
Де:

Приклади:

Рис.12. Вкладка "Конфігурація шаблону" параметра логічного типу.

Модулем передбачена особлива обробка низки атрибутів шаблону:

• f_frq — Частота обчислення процедури шаблону або час після останнього обчислення, негативне у секундах, для планування за CRON, тільки читання.
• f_start — Ознака першого виконання процедури шаблону, запуск, тільки читання.
• f_stop — Ознака останнього виконання процедури шаблону, зупинка, тільки читання.
• f_err — Помилка параметру, повний доступ. Значення цього атрибуту шаблону потрапляє до атрибуту помилки параметру "err".
• SHIFR — Значення шифру параметру, тільки читання.
• NAME — Значення ім'я параметру, тільки читання.
• DESCR — Значення опису параметру, тільки читання.
• this — Об'єкт даного параметру, дозволяє отримати доступ до атрибутів параметру, наприклад, для доступу до архівів.

Відповідно до шаблону, який лежить у основі параметру, ми отримаємо набір атрибутів параметру рис.13.

Рис.13. Вкладка атрибутів параметру логічного типу.

3.3. API користувацького програмування

У зв'язку із підтримкою модулем параметрів логічного типу має сенс надання низки функцій користувацького API для виклику із шаблону логічного параметру.

Об'єкт "Контролер" [this.cntr()]

• string messIO(string pdu) — відправка PDU pdu через транспорт об'єкту контролеру за посередництвом ModBus протоколу. PDU результату запиту розташовується замість запиту у pdu, а помилка повертається у результаті функції.

Об'єкт "Параметр" [this]

• bool attrAdd( string id, string name, string tp = "real", string selValsNms = "" ) [для включеного параметру логічного типу] — додати атрибут id з іменем name та для типу tp. Якщо атрибут вже присутній, то будуть застосовані властивості, які можливо змінити "на ходу": ім'я, режим вибору та параметри вибору.
  • id, name — ідентифікатор та ім'я нового атрибуту;
  • tp — тип атрибута [boolean | integer | real | string | text | object] + режим вибору [sel | seled] + тільки для читання [ro];
  • selValsNms — два рядки зі значеннями у першому та їх іменами у другому (поділені ";").
• bool attrDel( string id ) [для включеного параметру логічного типу] — видалити атрибут id.

Посилання