From OpenSCADAWiki
Jump to: navigation, search
This page is a translated version of the page Modules/Serial and the translation is 100% complete.

Other languages:
English • ‎российский • ‎українська
Модуль Имя Версия Лицензия Источник Языки Платформы Тип Автор Описание
Serial Последовательные интерфейсы 2.3 GPL2 tr_Serial.so en,uk,ru,de x86,x86_64,ARM Транспорт Роман Савоченко
  Максим Кочетков (2016)
Предоставляет транспорт основанный на последовательных интерфейсах. Используется для обмена данными через последовательные интерфейсы типа RS232, RS485, GSM и похожие.

Модуль предоставляет в программу поддержку транспортов, основанных на последовательных интерфейсах типа RS232, RS485, GSM и похожие. Поддерживаются входные и выходные транспорты. Добавить новые входные и выходные интерфейсы можно посредством конфигурации транспортной подсистемы в любом конфигураторе OpenSCADA.

Модулем, в режиме модема, поддерживается смешанный режим работы, который предусматривает наличие входящего транспорта, ожидающего внешних подключений, а также исходящего транспорта на том-же устройстве. Т.е. входящий транспорт будет игнорировать все запросы при наличии установленного исходящим транспортом соединения, в тоже время исходящий транспорт не будет осуществлять попыток установить соединение при наличии подключения к входящему транспорту или соединения другого исходящего транспорта, например, с другим номером телефона.

At.png В обычном режиме последовательного интерфейса не допускается многократное использование одного и того-же порта во входящих и исходящих транспортах. Глобальное блокирование последовательного устройства не осуществляется в виду неоднозначности этого процесса на системном уровне, а многократное использование может привести к непредсказуемым и сложно-уловимым проблемам. При необходимости организации локального последовательного канала с парой связанных портов рекомендуется использование команды "$ socat -d -d pty,raw,echo=0,perm=0666 pty,raw,echo=0,perm=0666".

1 Входящие транспорты

Сконфигурированный и запущенный входящий транспорт открывает порт последовательного интерфейса для ожидания запросов клиентов. Каждый входящий интерфейс обязательно связывается с одним из доступных транспортных протоколов, к которому передаются входящие сообщения.

Диалог конфигурации входящего последовательного интерфейса изображён на рисунок 1.

Рис.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, в миллисекундах.
  • Приоритет задачи входящего потока.

Транспорт поддерживает возможность работы в режиме модема. Данный режим включается пятым параметром адреса и подразумевает ожидания звонка от удалённого модема (запрос "RING"), ответа на звонок (команда "ATA") и последующей передачи запросов от удалённой станции протоколу транспорта. Отключение сеанса связи осуществляется инициатором соединения и приводит к переподключению модема приёмника на ожидание новых звонков.

Для настройки модема входного транспорта предусмотрена специальная вкладка "Модем" (рис.2).

Рис.2. Вкладка "Модем" конфигурации модема входящего последовательного интерфейса.

С помощью этого диалога можно установить следующие свойства работы с модемом:

  • Время ожидания (таймаут) модема на запросы, в секундах.
  • Выдержка времени перед инициализацией модема, в секундах.
  • Выдержка времени после инициализации модема, в секундах.
  • Первая строка инициализации (обычно содержит команду сброса настроек модема "ATZ").
  • Вторая строка инициализации.
  • Строка результата инициализации модема (обычно "OK"), которой отвечает модем на инициализацию и которую нужно ожидать.
  • Запрос звонка (обычно "RING"), который шлёт модем в случае поступления исходящего вызова.
  • Ответ на звонок (обычно "ATA"), который отправляется модему для ответа на звонок.
  • Строка результата на ответ на звонок (обычно "CONNECT"), которой отвечает модем на команду ответа и которую нужно ожидать.

2 Исходящие транспорты

Сконфигурированный и исполняющийся исходящий транспорт открывает порт последовательного интерфейса для отправки запросов через него.

Главная вкладка страницы конфигурации исходящего последовательного интерфейса изображёна на рисунке 3.

Рис.3. Главная вкладка страницы конфигурации исходящего последовательного интерфейса.

С помощью этого диалога можно установить:

  • Состояние транспорта, а именно: "Статус", "Исполняется" и имя БД, содержащей конфигурацию.
  • Идентификатор, имя и описание транспорта.
  • Адрес интерфейса в формате строки: "{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, в миллисекундах.
  • Не останавливать при обработке. Иногда закрытие открытого устройства может быть разрушительным, например, на ПЛК LP от ICP-DAS, и Вы можете предотвратить это данной опцией.

Транспорт поддерживает возможность работы в режиме модема. Данный режим включается наличием пятого параметра адреса и подразумевает осуществление звонка по телефону, указанному этим параметром, в момент запуска транспорта. После установки связи с удалённым модемом все запросы передачи направляются станции за удалённым модемом. Отключение сеанса связи, с остановкой транспорта, осуществляется по таймауту активности.

Для настройки модема исходящего транспорта предусмотрена специальная вкладка "Модем" (рис.4).

Рис.4. Вкладка "Модем" конфигурации модема исходящего последовательного интерфейса.

С помощью этого диалога можно установить следующие свойства работы с модемом:

  • Время ожидания (таймаут) модема на запросы, в секундах.
  • Время жизни соединения, в секундах. Если в течении этого времени будет отсутствовать передача данных через транспорт, то соединение будет разорвано.
  • Выдержка времени перед инициализацией модема, в секундах.
  • Выдержка времени после инициализации модема, в секундах.
  • Первая строка инициализации (обычно содержит команду сброса настроек модема "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, может возникнуть проблема высокой латентности, связанная с особенностью аппаратной реализации или его драйвера. Решать эту проблему нужно путём изучения настроек этого оборудования или установкой большого времени ожидания- символа!

Похожим образом определяется и оптимальное время подключения, а именно: установить время подключения в значение по умолчанию для данной скорости (ставится при смене скорости в адресе), снять "Ожидать таймаут", отослать запрос. Если ответ пришёл то берём измеренное время отклика устройства, удваиваем и устанавливаем полученное значение, как время подключения. Необоснованное превышение времени подключения приведёт к большим ожиданиям в случае отсутствия устройства, а также срабатывания защитных таймаутов внутренних процедур!

At.png На рынке встречаются 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-порт удалённого устройства.

At.png В работе через драйвер 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-порту.