| Модуль | Ім'я | Версія | Ліцензія | Джерело | Мови | Платформи | Тип | Автор | Опис |
|---|---|---|---|---|---|---|---|---|---|
| Serial | Послідовні інтерфейси | 2.7 | GPL2 | tr_Serial.so | en,uk,ru,de | x86,x86_64,ARM | Транспорт | Роман Савоченко Максим Кочетков (2016) |
Надає транспорт заснований на послідовних інтерфейсах. Використовується для обміну даними через послідовні інтерфейси типу RS232, RS485, GSM та схожі.
|
Модуль надає до програми підтримку транспортів, заснованих на послідовних інтерфейсах типу RS232, RS485, GSM та схожі. Підтримуються вхідні та вихідні транспорти. Додати нові вхідні та вихідні інтерфейси можна за посередництвом конфігурації транспортної підсистеми у будь якому конфігураторі OpenSCADA.
Модулем, у режимі модему, підтримується змішаний режим роботи, який передбачає наявність вхідного транспорту, що очікує зовнішніх підключень, а також вихідного транспорту на тому-ж пристрої. Тобто вхідний транспорт буде ігнорувати всі запити при наявності встановленого вихідним транспортом підключення, в той-же час вихідний транспорт не буде здійснювати спроб встановлення підключення при наявності підключення до вхідного транспорту або підключення іншого вихідного транспорту, наприклад, за іншим номером телефону.
У звичайному режимі послідовного інтерфейсу не допускається багаторазове використання одного й того-ж порту у вхідних та вихідних транспортах. Глобального блокування послідовного пристрою не здійснюється у зв'язку із неоднозначністю цього процесу на системному рівні, а багаторазове використання може призвести до непередбачуваних та складно-вловимих проблем. При потребі організації локального послідовного каналу з парою пов'язаних портів рекомендується використовувати команду socat -d -d pty,raw,echo=0,perm=0666 pty,raw,echo=0,perm=0666.
Contents
1 Вхідні транспорти
Сконфігурований та запущений вхідний транспорт відкриває порт послідовного інтерфейсу для очікування запитів клієнтів. Кожний вхідний інтерфейс обов'язково пов'язується з одним із доступних транспортних протоколів, до якого передаються вхідні повідомлення.
За допомогою основного діалогу можна встановити:
- Стан транспорту, а саме: статус, "Підключення" та ім'я БД, яка містить конфігурацію.
- Ідентифікатор, ім'я та опис транспорту.
- Адреса інтерфейсу у форматі рядка: "{dev}[:{spd}[:{format}[:{opts}[:{mdm}]]]]", де:
- dev — адреса послідовного пристрою (/dev/ttyS0);
- spd — швидкість послідовного пристрою із ряду: 300, 600, 1200, 2400, 4800, 9600, 19200, 38400, 57600, 115200, 230400, 460800, 500000, 576000 або 921600;
- format — формат асинхронних даних "{розмір}{парність}{стоп}" (8N1, 7E1, 5O2, ...);
- opts — різноманітні параметри, переважно для керування потоком, поділені символом ',':
- "[-]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, у мілісекундах.
- Пріоритет задачі вхідного потоку.
- [MODEM] Параметри модему. Цей режим включається п'ятим параметром адреси та передбачає очікування дзвінка від віддаленого модему (запит "RING"), відповіді на дзвінок (команда "ATA") та наступної передачі запитів від віддаленої станції до транспортного протоколу. Відключення сеансу зв'язку здійснюється ініціатором з'єднання та призводить до перепідключення модему приймача на очікування нових дзвінків.
- Час очікування (таймаут) модему на запит, у секундах.
- Витримка часу перед ініціалізацією модему, в секундах.
- Витримка часу після ініціалізації модема, в секундах.
- Перший рядок ініціалізації (зазвичай містить команду скидання налаштувань модему "ATZ").
- Другий рядок ініціалізації.
- Рядок результату ініціалізації модему (зазвичай "OK"), яким відповідає модем на ініціалізацію та якого треба очікувати.
- Запит дзвінка (зазвичай "RING"), який надсилає модем у випадку надходження вихідного виклику.
- Відповідь на дзвоник (зазвичай "ATA"), який надсилається модему для відповіді на дзвінок.
- Рядок результату на відповідь на дзвінок (зазвичай "CONNECT"), яким відповідає модем на команду відповіді та яку треба очікувати.
- Специфічні до протоколу користувацькі параметри.
- Скинути усі додаткові параметри до типових значень та очистити специфічні до протоколу користувацькі параметри.
2 Вихідні транспорти
Сконфігурований та виконуваний вихідний транспорт відкриває порт послідовного інтерфейсу для відправки запитів через нього.
За допомогою основного діалогу можна встановити:
- Стан транспорту, а саме: статус, "Підключення" та ім'я БД, яка містить конфігурацію.
- Ідентифікатор, ім'я та опис транспорту.
- Адреса інтерфейсу у форматі рядка: "{dev}[:{spd}[:{format}[:{opts}[:{modTel}]]]]", де:
- dev — адреса послідовного пристрою (/dev/ttyS0);
- spd — швидкість послідовного пристрою із ряду: 300, 600, 1200, 2400, 4800, 9600, 19200, 38400, 57600, 115200, 230400, 460800, 500000, 576000 або 921600;
- format — формат асинхронних даних "{розмір}{парність}{стоп}" (8N1, 7E1, 5O2, ...);
- opts — різноманітні параметри, переважно для керування потоком, поділені символом ',':
- "[-]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 — таймаут життя для перезавантаження транспорту, в секундах; використовуйте значення < 0 для зупинки транспорту після відсутності відповіді на будь-який запит;
- rtsDelay1 — затримка між включенням передавача сигналом RTS та початком передачі, у мілісекундах;
- rtsDelay2 — затримка між закінченням передачі та відключенням передавача сигналом RTS, у мілісекундах.
- Може бути пріоритетно визначено другим глобальним аргументом поля адреси, на кшталт "/dev/rfcomm0:9600||1000:40-20".
- Не відключати при обробці. Інколи закриття відкритого пристрою може бути руйнівним, наприклад, на ПЛК LP від ICP-DAS, та Ви можете попередити це цією опцією.
- [MODEM] Параметри модему. Цей режим включається наявністю п'ятого параметру адреси та передбачає здійснення дзвінка за телефоном, вказаним цим параметром, на момент запуску транспорту. Після встановлення зв'язку з віддаленим модемом всі запити передачі спрямовуються станції за віддаленим модемом. Відключення сеансу зв'язку, із зупинкою транспорту, здійснюється за таймаутом активності.
- Час очікування (таймаут) модема на запити, в секундах.
- Час життя підключення, в секундах. Якщо протягом цього часу буде відсутня передача даних через транспорт, то підключення буде розірвано.
- Витримка часу перед ініціалізацією модема, в секундах.
- Витримка часу після ініціалізації модему, в секундах.
- Перший рядок ініціалізації (зазвичай містить команду скидання налаштувань модему "ATZ").
- Другий рядок ініціалізації.
- Рядок результату ініціалізації модему (зазвичай "OK"), яким відповідає модем на ініціалізацію та якого треба очікувати.
- Рядок додзвону до віддаленого модему (зазвичай "ATDT"). При додзвоні номер телефону додається до даного префіксу.
- Рядок результату вдалого підключення (зазвичай "CONNECT").
- Рядок результату зайнятості лінії (зазвичай "BUSY").
- Рядок результату відсутності несущої в лінії (зазвичай "NO CARRIER").
- Рядок результату відсутності гудка лінії (зазвичай "NO DIALTONE").
- Рядок виходу з режиму даних (зазвичай "+++") та використовується "Час перед ініціалізацією модему", після неї.
- Команда повісити трубку (зазвичай "+++ATH"). Ця команда викликається завжди, коли потрібно розірвати підключення.
- Рядок результату команди повісити трубку (зазвичай "OK"), яким відповідає модем на команду та який треба очікувати.
- Специфічні до протоколу користувацькі параметри.
- Скинути усі додаткові параметри до типових значень та очистити специфічні до протоколу користувацькі параметри.
Транспорт може працювати з апаратною шиною I2С, якщо у якості пристрою обрати "/dev/i2c-{N}" та шина дозволить встановити адресу підлеглого пристрою командою I2C_SLAVE, із першого байту запиту. Швидкість та формат не відіграють ролі в цьому режимі. Із таймаутів тут фактично працює тільки час символу і переважно для розрахунку очікування повтору запиту.
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":
#!/bin/sh
# Setting the high priority for events kernel threads to rise the serial interfaces reaction
events=`ps -Ao pid,comm | sed -n '/[ ]*\([^ ]\)[ ]*events\/[0-9]/s//\1/p'`
for ie in $events; do
chrt -pr 21 $ie
done
Цей скрипт не має сенсу для ядер Linux реального часу, з патчем PREEMPT_RT, оскільки всі потоки переривань та повідомлень там вже запускаються у пріоритеті реального часу.
На зовнішньому обладнані послідовних інтерфейсів, наприклад, у перетворювачах USB->RS232/422/485, може виникнути проблема високої латентності, пов'язана з особливістю апаратної реалізації або його драйверу. Вирішувати цю проблему треба шляхом вивчення налаштувань цього обладнання або встановленням більшого часу очікування-символу!
Схожим чином визначається й оптимальний час підключення, а саме: встановити час підключення у значення по замовченню для даної швидкості (ставиться при зміні швидкості у адресі), зняти "Очікувати таймаут", надіслати запит. Якщо відповідь прийшла то беремо виміряний час відгуку пристрою, подвоюємо та встановлюємо отримане значення, як час підключення. Необґрунтоване перевищення часу підключення призведе до великих очікувань у випадку відсутності пристрою, а також спрацьовуванню захисних таймаутів внутрішніх процедур!
На ринку зустрічаються USB->Serial перетворювачі, які працюють тільки з терміналами, тобто вони можуть передавати та опрацьовувати виключно ASCII символи та не можуть бути переключені у бінарний режим. Відомі екземпляри таких перетворювачів: PL2303TA (Y-105).
4.1 Віртуальні/локальні послідовні інтерфейси
Часто для локальної перевірки, без фізичного обладнання, потрібна пара портів підключених у одну мережу. Створення таких портів та виконання багатьох інших операцій над послідовним потоком дозволяє виконувати утиліта socat. Наприклад, для створення двох пов'язаних портів треба виконати команду, яка створить їх та повідомить адреси:
socat -d -d pty,raw,echo=0,perm=0666 pty,raw,echo=0,perm=0666
#2013/07/02 16:37:29 socat[10402] N PTY is /dev/pts/6
#2013/07/02 16:37:30 socat[10402] N PTY is /dev/pts/7
#2013/07/02 16:37:30 socat[10402] N starting data transfer loop with FDs [3,3] and [5,5]
4.2 Перекидання послідовного інтерфейсу через мережу Ethernet
У деяких випадках буває корисним перекинути порт послідовного інтерфейсу віддаленої машини на локальний порт, наприклад, для опитування пристроїв, підключених до послідовного інтерфейсу віддаленої машини. Звісно, якщо встановити на віддалену машину OpenSCADA у конфігурації ПЛК, то можна буде одразу виконувати обробку цих даних, попереднє буферування/архівування та інше, але інколи обладнання може бути складним для запуску OpenSCADA, де й рятує можливість перекидання послідовного потоку через мережу. Для вирішення цього завдання можна скористатися тією-ж утилітою socat або remserial, ser2net, яку вдасться зібрати та запустити на віддаленій машині. Приклади перекидання послідовного порту:
# Створення сокету на порту 5555 віддаленої машини, для порту /dev/ttyS0
socat tcp-l:5555,reuseaddr,fork file:/dev/ttyS0,raw
# Підключення до сокету віддзеркаленого порту віддаленої машини та формування файлу віддзеркаленого локального інтерфейсу
socat -d -d pty,raw,echo=0,perm=0666 tcp:192.168.2.4:5555,mss=1400
#2013/07/04 10:09:09 socat[12947] N PTY is /dev/pts/4
#2013/07/04 10:09:09 socat[12947] N opening connection to AF=2 192.168.2.4:5555
#2013/07/04 10:09:09 socat[12947] N successfully connected from local address AF=2 192.168.2.61:33493
#2013/07/04 10:09:09 socat[12947] N starting data transfer loop with FDs [3,3] and [5,5]
У випадку з "socat", а можливо й інших утиліт, можна на клієнтському боці опустити запуск драйверу EthernetTCP->Serial та підключатися із OpenSCADA прямо на TCP-порт віддаленого пристрою.
У роботі через драйвер EthernetTCP->Serial є особливість, яка пов'язана із наявністю двох таймаутів підключення: один у драйвері та інший у Transport.Sockets. Важливо щоб значення цього таймауту у Transport.Sockets було більше ніж у драйвері інакше можливий зсув та отримання запізнілих відповідей від попередніх запитів.
Багато виробників промислового комунікаційного обладнання випускають готові конвертери із Ethernet у RS-232/422/485, які можуть використовуватися з OpenSCADA таким-же чином. Коментарі та перелік перетворювачів з якими роботу OpenSCADA перевірено: