Модуль <Serial> підсистеми "Транспорти"
| Модуль: | Serial |
| Ім'я: | Послідовний інтерфейс |
| Тип: | Транспорт |
| Джерело: | tr_Serial.so |
| Версія: | 1.6 |
| Автор: | Роман Савоченко, Максим Кочетков |
| Опис: | Надає послідовний інтерфейс. Використовується для обміну даними через послідовні інтерфейси типу 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, може виникнути проблема високої латентності, пов'язана з особливістю апаратної реалізації або його драйверу. Вирішувати цю проблему треба шляхом вивчення налаштувань цього обладнання або встановленням більшого часу очікування, символу!
Схожим чином визначається й оптимальний час підключення, а саме: встановити час підключення у значення по замовченню для даної швидкості (ставиться при зміні швидкості у адресі), зняти "Очікувати таймаут", відіслати запит. Якщо відповідь прийшла то беремо виміряний час відгуку пристрою, подвоюємо та встановлюємо отримане значення як час підключення. Необґрунтоване перевищення часу підключення призведе до великих очікувань у випадку відсутності пристрою, а також спрацьовуванню захисних таймаутів внутрішніх процедур!
На ринку зустрічаються USB->Serial перетворювачі, які працюють тільки з терміналами, тобто вони можуть передавати та опрацьовувати виключно ASCII символи та не можуть бути переключені у бінарний режим. Відомі екземпляри таких перетворювачів: PL2303TA (Y-105).Віртуальні/локальні послідовні інтерфейси
Часто для локальної перевірки, без фізичного обладнання, потрібна пара портів підключених у одну мережу. Створення таких портів та виконання багатьох інших операцій над послідовним потоком дозволяє виконувати утиліта socat. Наприклад, для створення двох пов'язаних портів треба виконати команду, яка створить їх та повідомить адреси:Перекидання послідовного інтерфейсу через мережу Ethernet
У деяких випадках буває корисним перекинути порт послідовного інтерфейсу віддаленої машини на локальний порт, наприклад, для опитування пристроїв, підключених до послідовного інтерфейсу віддаленої машини. Звісно, якщо встановити на віддалену машину OpenSCADA у конфігурації ПЛК, то можна буде одразу виконувати обробку цих даних, попереднє буферування/архівування та інше, але інколи обладнання може бути складним для запуску 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-порту.