Модуль <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-порту.
Ссылки