Забути не можна використовувати

1. Пропонована «розстановка ком»
2. Передача даних між відомими
3. резервування майстра
4. Подієва передача даних
5. Перевірка теорії практикою

Цей протокол польовий шини володіє як деякими відомими недоліками, так і незаперечними перевагами. В активі MODBUS і гранична простота, і низька вартість реалізації, і відкриті специфікації. Перехід на інші, більш

«Наворочені»протоколи, нерідко відбувається «з важким подихом жалю» ...Давайте подивимося, чи реально виправити ситуацію?Може бути, потрібно просто «правильно розставити коми»?

В контексті семиуровневой моделі OSI специфікацією MODBUS визначається рівень інтерфейсу додатку (7 - Application), опис інших рівнів, крім рівня фізичного доступу до середовища передачі (1 - Physical), що визначається «класичним» EIA / TIA_485, при цьому не потрібно. Відповідно до специфікації на шині має зазначатися одне провідне (master) і одне або кілька ведених (slave) пристроїв. Передача даних здійснюється між ведучим і веденим в форматі «запит - твет». Передача даних від одного відомого до іншого не підтримується. Одиницею інформації є або регістр, або біт, адресовані за номерами. Визначено чотири простору номерів: два для бітів і два для регістрів (одне - доступні тільки для читання і одне - доступні для читання і запису).

1. Пряма взаємодія між відомими стандартом не підтримується, і для передачі даних від одного відомого до іншого необхідно програмно, в провідному пристрої, реалізувати послідовно читання з одного пристрою, буферизацію і запис на інший пристрій.

2. Наявність в системі «єдиної точки відмови». При відмові ведучого пристрою ніякі взаємодії з іне неможливі. Система переходить в повністю непрацездатний стан.

3. Протокол MODBUS - скануючий і, як наслідок, він досить неефективно використовує смугу пропускання каналу. Сучасні протоколи польових шин подієві (точніше, собитійно_сканірующіе).

Пропонована «розстановка ком»

А якщо взяти, що специфікацією MODBUS визначається не судимий (Application), а третій (Network) рівень моделі OSI, і «надбудувати» над ним, окремим рівнем, якого бракує функціонал? Тоді ми отримаємо польову шину, для якої вже є широкий вибір якісної, перевіреної часом, дешевої периферії, шлюзів і всякої «дріб'язку», відпрацьована методологія застосування і інша смакота ». І при цьому є можливість будувати мережі нового типу, позбавлені основних НЕ статків класичного »MODBUS!

Передача даних між відомими

А чому, власне кажучи, один ведений не може «підслуховувати» відповіді інших відомих і, таким чином, отримувати дані безпосередньо, без нав'язуваної «класичним» MODBUS подвійний пересилання і буферизації? Дані по шині передаються пакетами (в термінах протоколу це PDU - protocol data units). У режимі MODBUS RTU пакети розділені паузами в 3,5 ... 4 символу. У режимі ASCII пакети поділяються символами «:» (початок) і «Ctrl» (кінець). Завдяки цьому можна досить легко виділити в потоці даних, що передаються окремі PDU. Все PDU відповідають шаблону {Адреса веденого, Номер функції, CRC}. Це дозволяє при «підслуховування» провести первинну фільтрацію і відразу відкинути більшу частину «нецікавих» PDU. Далі необхідно відрізняти між собою PDU запиту і PDU відповіді (формати деяких PDU наведені на малюнку). Оскільки запит і відповідь в потоці завжди йдуть підряд, один за іншим, і в багатьох випадках обидва містять корисну інформацію, має сенс зберігати в буфері не менше двох останніх прийнятих PDU. Функції 3 і 4 (читати Input registers і читати Holding registers) Довжина запиту про цих функцій завжди вісім байт (тобто парна), а довжина відповіді із_за поля «Byte Count» завжди непарна. Функціям 1 і 2 (читати біти - Inputs і Coils) Довжина запиту також дорівнює восьми байтам, але тут не все так просто. При запиті одним пакетом від 17 до 24 біт (три байта даних) довжина відповіді також буде дорівнює восьми байтам і довжини запиту і відповіді співпадуть. У цьому випадку поле «Byte Count» PDU відповіді має дорівнювати трьом, а воно збігається з позиції зі старшим байтом номера початкового біта в PDU запиту. Таким чином, якщо в цьому байті пакета значення відмінно від трьох і довжина пакета дорівнює восьми, то це достовірно PDU запиту. Таким чином, проблема є тільки для «трехбайтних запитів» (запити на 17 ... 24 біт), що починаються з біта c номером в діапазоні 0х300 ... 0х3FF (номера старше 767). Звичайно, для проблемних PDU можна ще перевірити, чи є в позиції «Count High" не нуль і в позиції «Count Low» значення в межах дії 17 ... 24. Можна виконати ще деякі перевірки, але слід визнати, що гарантувати 100% розшифровку звернень до бітам в діапазоні 0x300 ... 0x3FF при «підслуховування», не можна. Що ж, навіть якщо обмежитися «input registers», «holding registers» і першими 768 бітами (0 ... 0x2FF), це немало!

резервування майстра

Якщо прийняти, що ведені обмінюються інформацією шляхом «підслуховування», який формується провідним условнонепреривного потоку «запит - відповідь», то в системі можна

передбачити резервування провідного пристрою і тим самим прибрати «єдину точку відмови». Один або кілька резервних провідних можуть «слухати потік», фіксувати його структуру і «тайміровать паузи». Якщо, наприклад, виявлена ​​пауза більше трьох секунд, це, швидше за все, означає відмову ведучого, і резервний ведучий може спробувати відновити обмін по шині, перехопивши контроль лінії і сформувавши потік з раніше зафіксованої структурою. Якщо через деякий час після цього на шині будуть виявлені колізії, можна спробувати повернути контроль лінії основного ведучому, сформувавши паузу, наприклад, дві з половиною секунди. Альтернативною реалізацією може бути не фіксація структури потоку, а якесь API, реалізоване поверх реєстрової моделі MODBUS, що дозволяє іншим пристроям «підписатися» на потрібні їм дані у резервного майстра, вже після перехоплення їм контролю лінії. Або, навпаки, структура потоку, при управлінні лінією від резервного майстра може бути в ньому запрограмована або налаштована через якийсь інтерфейс людиною (наладчиком) на етапі введення системи в експлуатацію.

Подієва передача даних

Цю фішку, на наш погляд, теж досить просто реалізувати «поверх» MODBUS. Правда, буде потрібна підтримка нової функціональності як провідним, так і веденим (але, зауважимо, необов'язково усіма відомими). Введемо, за аналогією з цифровими форматами зберігання відеоінформації, поняття P-фрейми (опорного) і I-фрейми (інкрементного або подієвого). P-фреймами в протоколі MOD BUS будуть стандартні пакети читання груп регістрів, які в новому режимі передачі даних можна буде запитувати значно рідше, ніж це було потрібно раніше. I-фрейми пропонується отримувати таким чином:

• Ведучий звертається до веденого на читання двох спеціальних регістрів (наприклад, з номерами 0xFFFE і 0xFFFF).
• Ведений повертає в цих регістрах номер регістра, який змінив своє значення з часу останнього звернення, і його нове значення.
• Якщо, на думку відомого, нічого не змінювалося, він відправляє ведучому просто номер і поточне значення одного з регістрів, на свій розсуд :).
• Ведучий обробляє отриманий номер регістра / значення і запитує наступний I-фрейм (або P-фрейм, якщо вважатиме за потрібне).
• Якщо ведучий отримав I-фрейм з помилкою, він може запросити Р-фрейм (стандартний пакет читання групи регістрів), що забезпечить швидке відновлення після помилок, що виникають в каналі.
• Для того щоб відправляти в I-фреймах не всі підряд, а тільки дані, «цікаві» ведучому, ведений може трактувати P-фрейми як запити на підписку отримання I-фреймів :).

Вообще_то можна було б вирішити цю задачу внесенням до протоколу для опитування I-фреймів окремої функції, але тоді потрібно буде відмовитися від використання в якості драйверів транспортного рівня вже існуючих OPC_серверов і вбудованих модулів SCADA_сістем. На нашу думку, воно того не варто.

Перевірка теорії практикою

Дана методика була нами застосована для розробки модуля місцевої індикації / сигналізації. Розроблений модуль підключається до існуючої MODBUS_сеть і без втручання в її налаштування виконує опитування (підслуховування) до 12 регістрів на будь-якому (до 12 :)) кількості ведених пристроїв, індикацію їх поточного стану та сигналізацію певних значень як аварійних. При «пропажі потоку» модуль перехоплює роль ведучого шини і самостійно опитує потрібні йому пристрої. На сьогоднішній день проведено лабораторні випробування, які показали як мінімум можливість використання такого модуля в мережі MODBUS спільно з контролерами «РАУТ_Автоматік» і «ОВЕН» (це те обладнання, яке опинилося під рукою, завдання протестувати модуль на сумісність з усім і вся ми поки собі не ставили). Також поки не тестувався режим декількох резервних провідних і режим подієвої передачі по шині. Роботи тривають. Можливо, про це - в наступному номері. :)