Модуль <Serial> підсистеми "Транспорти"
| Модуль: | Serial |
| Ім'я: | Послідовний інтерфейс |
| Тип: | Транспорт |
| Джерело: | tr_Serial.so |
| Версія: | 1.6.0 |
| Автор: | Роман Савоченко, Максим Кочетков |
| Опис: | Надає послідовний інтерфейс. Використовується для обміну даними через послідовні інтерфейси типу RS232, RS485, GSM та інші. |
| Ліцензія: | GPL |
Вступ
Модуль транспорту Serial надає в систему підтримку транспортів, основаних на послідовних інтерфейсах типу RS232, RS485, GSM та інше. Підтримуються вхідні та вихідні транспорти. Додати нові вхідні та вихідні інтерфейси можна за посередництвом конфігурації транспортної підсистеми у будь якому конфігураторі системи OpenSCADA.
У режимі модему модулем підтримується змішаний режим роботи. Змішаний режим має на увазі наявність вхідного транспорту, який очікує зовнішніх підключень, а також вихідного транспорту на тому-ж пристрої. Тобто вхідний транспорт буде ігнорувати всі запити при наявності встановленого вихідним транспортом підключення, в той-же час вихідний транспорт не буде здійснювати спроб встановлення підключення при наявності підключення до вхідного транспорту або підключення іншого вихідного транспорту, наприклад, з іншим номером телефону.
У звичайному режимі послідовного інтерфейсу не допускається багаторазове використання одного й того-ж порту у вхідних та вихідних транспортах. Глобального блокування послідовного пристрою не здійснюється у зв'язку із неоднозначністю цього процесу на системному рівні, а багаторазове використання може привести до непередбачуваних проблем. При потребі у організації локального послідовного каналу з парою пов'язаних портів рекомендується використовувати команду "$ socat -d -d pty,raw,echo=0,perm=0666 pty,raw,echo=0,perm=0666".
1. Вхідні транспорти
Сконфігурований та запущений вхідний транспорт відкриває порт послідовного інтерфейсу для очікування запитів клієнтів. Кожний вхідний інтерфейс обов'язково пов'язується з одним із доступних транспортних протоколів, до якого передаються вхідні повідомлення.
Діалог конфігурації вхідного послідовного інтерфейсу зображено на рис.1.
Рис.1. Діалог конфігурації вхідного послідовного інтерфейсу.
За допомогою цього діалогу можна встановити:
- Стан транспорту, а саме: "Статус", "Виконується" та ім'я БД, яка містить конфігурацію.
- Ідентифікатор, ім'я та опис транспорту.
- Адреса інтерфейсу у форматі рядка: "dev:spd:format[:fc[:mdm]]". Де:
- dev — адреса послідовного пристрою (/dev/ttyS0);
- spd — швидкість послідовного пристрою із ряду: 300, 600, 1200, 2400, 4800, 9600, 19200, 38400, 57600, 115200, 230400, 460800, 500000, 576000 або 921600;
- format — формат асинхронних даних "{розмір}{парність}{стоп}" (8N1, 7E1, 5O2, ...);
- fc — управління потоком:
- "h" — апаратне (CRTSCTS);
- "s" — програмне (IXON|IXOFF);
- "rts" — використання RTS сигналу для передачі(false) та перевірки на луну, для сирого RS-485;
- "rts1" — використання RTS сигналу для передачі(true) та перевірки на луну, для сирого RS-485;
- "rtsne" — використання RTS сигналу для передачі(false) без перевірки на луну, для сирого RS-485;
- "rts1ne" — використання RTS сигналу для передачі(true) без перевірки на луну, для сирого RS-485;
- "RS485" — використовувати RS-485 режим, за посередництвом TIOCSRS485.
- mdm — режим модему, очікування 'RING'.
- Вибір транспортного протоколу.
- Стан, в який переводити транспорт при завантажені: "Запущено".
- Інтервали часу інтерфейсу в форматі рядка: "symbol:frm[::rtsDelay1:rtsDelay2]". Де:
- symbol — час символу у мілісекундах. Використовується для контролю факту закінчення фрейму;
- frm — максимальний час фрейму у мілісекундах. Використовується для обмеження максимального розміру пакету запиту (фрейму);
- rtsDelay1 — затримка, у мілісекундах, між включенням передавача сигналом RTS та початком передачі;
- rtsDelay2 — затримка, у мілісекундах, між закінченням передачі та відключенням передавача сигналом RTS.
- Пріоритет задачі вхідного потоку.
Транспорт підтримує можливість роботи у режимі модему. Цей режим включається п'ятим параметром адреси та передбачає очікування дзвінка від віддаленого модему (запит "RING"), відповіді на дзвінок (команда "ATA") та наступної передачі запитів від віддаленої станції протоколу транспорту. Відключення сеансу зв'язку здійснюється ініціатором з'єднання та призводить до перепідключення модему приймача на очікування нових дзвінків.
Для налаштування модему вхідного транспорту передбачено спеціальну вкладку "Модем" (рис.2).
Рис.2. Вкладка "Модем" конфігурації модему вхідного послідовного інтерфейсу.
За допомогою цього діалогу можна встановити наступні властивості роботи з модемом:
- Час очікування, таймауту, модему на запит, у секундах.
- Витримка часу перед ініціалізацією модему, в секундах.
- Витримка часу після ініціалізації модема, в секундах.
- Перший рядок ініціалізації, зазвичай містить команду скидання налаштувань модему "ATZ".
- Другий рядок ініціалізації.
- Рядок результату ініціалізації модему, зазвичай "OK", яким відповідає модем на ініціалізацію та якого треба очікувати.
- Запит дзвінка, зазвичай "RING", який надсилає модем у випадку надходження вихідного виклику.
- Відповідь на дзвоник, зазвичай "ATA", який надсилається модему для відповіді на дзвінок.
- Рядок результату на відповідь на дзвінок, зазвичай "CONNECT", яким відповідає модем на команду відповіді та яку треба очікувати.
2. Вихідні транспорти
Сконфігурований та запущений вихідний транспорт відкриває порт послідовного інтерфейсу для відправки запитів через нього.
Головна вкладка сторінки конфігурації вихідного послідовного інтерфейсу зображена на рис.3.
Рис.3. Головна вкладка сторінки конфігурації вихідного послідовного інтерфейсі.
За допомогою цього діалогу можна встановити:
- Стан транспорту, а саме: "Статус", "Запущено" та ім'я БД, яка містить конфігурацію.
- Ідентифікатор, ім'я та опис транспорту.
- Адреса інтерфейсу у форматі рядка: "dev:spd:format[:fc[:modTel]]". Де:
- dev — адреса послідовного пристрою (/dev/ttyS0);
- spd — швидкість послідовного пристрою із ряду: 300, 600, 1200, 2400, 4800, 9600, 19200, 38400, 57600, 115200, 230400, 460800, 500000, 576000 або 921600;
- format — формат асинхронних даних "{розмір}{парність}{стоп}" (8N1, 7E1, 5O2, ...);
- fc — управління потоком:
- "h" — апаратне (CRTSCTS);
- "s" — програмне (IXON|IXOFF);
- "rts" — використання RTS сигналу для передачі(false) та перевірки на луну, для сирого RS-485;
- "rts1" — використання RTS сигналу для передачі(true) та перевірки на луну, для сирого RS-485;
- "rtsne" — використання RTS сигналу для передачі(false) без перевірки на луну, для сирого RS-485;
- "rts1ne" — використання RTS сигналу для передачі(true) без перевірки на луну, для сирого RS-485;
- "RS485" — використовувати RS-485 режим, за посередництвом TIOCSRS485.
- modTel — телефон модему, присутність цього поля перемикає транспорт на роботу у режимі модему.
- Стан, в який переводити транспорт при завантажені: "Запущено".
- Інтервали часу інтерфейсу у форматі рядка: "conn:symbol[-NextReqMult][:KeepAliveTm[:rtsDelay1:rtsDelay2]]". Де:
- conn — час очікування з'єднання тобто відповіді від віддаленого пристрою;
- symbol — час символу у мілісекундах. Використовується для контролю факту закінчення фрейму та таймауту наступного запиту;
- NextReqMult — множник часу наступного запиту до часу символу symbol, 4 по замовченню;
- KeepAliveTm — таймаут життя в секундах для перезавантаження транспорту;
- rtsDelay1 — затримка, у мілісекундах, між включенням передавача сигналом RTS та початком передачі;
- rtsDelay2 — затримка, у мілісекундах, між закінченням передачі та відключенням передавача сигналом RTS.
- Не зупиняти при обробці. Інколи закриття відкритого пристрою може бути руйнівним, наприклад, на ПЛК LP від ICP-DAS, та Ви можете попередити це цією опцією.
Транспорт підтримує можливість роботи у режимі модему. Цей режим включається наявністю п'ятого параметру адреси та передбачає здійснення дзвінка за телефоном, вказаним п'ятим параметром, в момент запуску транспорту. Після встановлення зв'язку з віддаленим модемом всі запити передачі спрямовуються станції за віддаленим модемом. Відключення сеансу зв'язку, із зупинкою транспорту, здійснюється за таймаутом активності.
Транспорт може працювати з апаратною шиною I2С якщо у якості пристрою обрати "/dev/i2c-{N}" та шина дозволить встановити адресу підлеглого пристрою командою I2C_SLAVE, із першого байту запиту. Швидкість та формат не відіграють ролі в цьому режимі. Із таймаутів тут фактично працює тільки час символу і переважно для розрахунку очікування повтору запиту.
Для налаштування модему вихідного транспорту передбачено спеціальну вкладку "Модем" (рис.4).
Рис.4. Вкладка "Модем" конфігурації модему вихідного послідовного інтерфейсу.
За допомогою цього діалогу можна встановити наступні властивості роботи з модемом:
- Час очікування, таймаут, модема на запити, в секундах.
- Час життя підключення, в секундах. Якщо протягом цього часу буде відсутня передача даних через транспорт то підключення буде розірвано.
- Витримка часу перед ініціалізацією модема, в секундах.
- Витримка часу після ініціалізації модему, в секундах.
- Перший рядок ініціалізації, зазвичай містить команду скидання налаштувань модему "ATZ".
- Другий рядок ініціалізації.
- Рядок результату ініціалізації модему, зазвичай "OK", яким відповідає модем на ініціалізацію та якого треба очікувати.
- Рядок додзвону до віддаленого модему, зазвичай "ATDT". При додзвоні номер телефону додається до даного префіксу.
- Рядок результату вдалого підключення, зазвичай "CONNECT".
- Рядок результату зайнятості лінії, зазвичай "BUSY".
- Рядок результату відсутності несущої в лінії, зазвичай "NO CARRIER".
- Рядок результату відсутності гудка лінії, зазвичай "NO DIALTONE".
- Рядок виходу з режиму даних, зазвичай "+++" та "Час перед ініціалізацією модему" після неї використовується.
- Команда повісити трубку, зазвичай "+++ATH". Ця команда викликається завжди, коли потрібно розірвати підключення.
- Рядок результату команди повісити трубку, зазвичай "OK", яким відповідає модем на команду та який треба очікувати.
3. API користувацького програмування
Об'єкт "Вихідний транспорт" (SYS.Transport.Serial.out_{OutTransport})
- bool TS( bool rts = EVAL ) — Керування відправкою за посередництвом встановлення запиту rts та повернення стану дозволу CTS.
- bool DR( bool dtr = EVAL ) — Керування готовністю пристрою за посередництвом встановлення готовності терміналу dtr та повернення стану готовності DSR.
- bool DCD() — Повернення стану виявлення несущої даних.
- bool RI() — Повернення індикатору дзвінка.
- int sendbreak( int duration = 0 ) — Надіслати в потік переривання нулями протягом duration (0 — деякий інтервал по замовченню).
4. Зауваження
Комунікації через послідовні інтерфейси мають низку особливостей. Найбільш важливою особливістю є критерій закінчення повідомлення та час очікування цього критерію. У одних протоколах таким критерієм виступає ознака закінчення або вказаний розмір повідомлення. В інших протоколах таким критерієм є відсутність даних у вхідному потоці протягом вказаного часу, час символу. У обох випадках час очікування критерію або символу є ключовим та сильно впливає на загальний час обміну. Відповідно, чим менше цей час тим краще. Тут і виникає проблема латентності обладнання та його драйверів.
Перевірити латентність каналу обміну та тим самим оптимально налаштувати час доочікування, символу можна за допомогою інтерфейсу вкладки "Запит" вихідного транспорту. Для цього потрібно вказати зразковий запит відповідного протоколу, вказати "Очікувати таймаут", надіслати запит та проконтролювати його цілісність. Для отримання більш репрезентативного результату треба запит повторити декілька разів. Якщо спостерігається отримання неповних відповідей, то час символу треба збільшити, інакше можна зменшити.
На будованому обладнані послідовних інтерфейсів RS232/422/485 можна добитися низького рівня латентності, впритул до одиниць мілісекунд. Однак, на високо-навантажених системах з безліччю задач у пріоритеті реального часу латентність може стати недетермінованою у зв'язку з виконанням потоку обслуговування подій ядра Linux у низькому пріоритеті. Для вирішення цієї проблеми треба встановити високий пріоритет цим потокам, що можна здійснити за допомогою скрипта, помістивши його, наприклад, у "/etc/rc.local":
Цей скрипт не має сенсу для ядер Linux реального часу, з патчем PREEMPT_RT, скільки всі потоки переривань та повідомлень там вже запускаються у пріоритеті реального часу.
На зовнішньому обладнані послідовних інтерфейсів, наприклад, у перетворювачах USB->RS232/422/485, може виникнути проблема високої латентності, пов'язана з особливістю апаратної реалізації або його драйверу. Вирішувати цю проблему треба шляхом вивчення налаштувань цього обладнання або встановленням більшого часу очікування, символу!
Схожим чином визначається й оптимальний час підключення, а саме: встановити час підключення у значення по замовченню для даної швидкості (ставиться при зміні швидкості у адресі), зняти "Очікувати таймаут", відіслати запит. Якщо відповідь прийшла то беремо виміряний час відгуку пристрою, подвоюємо та встановлюємо отримане значення як час підключення. Необґрунтоване перевищення часу підключення призведе до великих очікувань у випадку відсутності пристрою, а також спрацьовуванню захисних таймаутів внутрішніх процедур!
Віртуальні/локальні послідовні інтерфейси
Часто для локальної перевірки, без фізичного обладнання, потрібна пара портів підключених у одну мережу. Створення таких портів та виконання багатьох інших операцій над послідовним потоком дозволяє виконувати утиліта socat. Наприклад, для створення двох пов'язаних портів треба виконати команду, яка створить їх та повідомить адреси:
Переклад
Проброс последовательного интерфейса через сеть Ethernet
В некоторых случаях бывает полезным пробросить порт последовательного интерфейса удалённой машины на локальный порт, например, для опроса устройств подключенных к последовательному интерфейсу удалённой машины. Конечно, если установить на удалённую машину OpenSCADA в конфигурации PLC, то можно будет сразу выполнять обработку этих данных, предварительное буферирование-архивирование и т.д., но иногда оборудование может быть сложным для запуска OpenSCADA, где и спасает возможность проброса последовательного потока через сеть. Для решения этой задачи можно воспользоваться той-же утилитой socat или remserial, ser2net, какую удастся собрать и запустить на удалённой машине. Примеры проброса последовательного порта:
В случае с "socat", а возможно и других утилит, можно на клиентской стороне опустить запуск драйвера EthernetTCP->Serial и подключаться из OpenSCADA прямо на TCP-порт удалённого устройства.
В работе через драйвер EthernetTCP->Serial есть особенность, которая связанна с наличием двух таймаутов подключения, один в драйвере, другой в Transport.Sockets. Важно чтобы значение этого таймаута в Transport.Sockets был больше чем в драйвере иначе возможно смещение и получение на запрос запоздалый ответ от предыдущего запроса.
Многие производители промышленного коммуникационного оборудования выпускают готовые конвертеры из Ethernet в RS-232/422/485, которые могут использоваться с OpenSCADA таким-же образом. Комментарии и перечень конвертеров с которыми работа OpenSCADA проверена:
-
ICP DAS: tDS-7xx — настраивается через WEB-интерфейс и работает по прямому подключение к TCP-порту;
- Tibbo: DS100 — настраивается только через программу для MS Windows®, предоставляет собственный драйвер для формирования виртуальных последовательных интерфейсов на Linux, работает по прямому подключение к TCP-порту.
Ссылки