Модули/Serial

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

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

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

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

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

Fig.1. The generic configuration dialogues of the input serial interface.

Using the main dialog you can set:

• State of transport, that is: status, "Connect" and name of the database, containing the configuration.
• Identifier, name and description of the transport.
• Address of the transport in the format "{dev}:{spd}:{format}[:{opts}[:{mdm}]]", where:
  • dev — address of the serial device (/dev/ttyS0);
  • spd — speed of the serial devices from a number: 300, 600, 1200, 2400, 4800, 9600, 19200, 38400, 57600, 115200, 230400, 460800, 500000, 576000 or 921600;
  • format — asynchronous data format "{size}{parity}{stop}" (8N1, 7E1, 5O2, ...);
  • opts — different options, mostly for flow control, separated by ',':
    • "[-]h" — hardware (CRTSCTS);
    • "[-]s" — software (IXON|IXOFF);
    • "rts" — using of the RTS signal for transferring(false) and checking for echo, for raw RS-485;
    • "rts1" — using of the RTS signal for transferring(true) and checking for echo, for raw RS-485;
    • "rtsne" — using of the RTS signal for transferring(false) and without checking for echo, for raw RS-485;
    • "rts1ne" — using of the RTS signal for transferring(true) and without checking for echo, for raw RS-485;
    • "[-]RS485" — using RS-485 mode, through TIOCSRS485.
  • mdm — modem mode, listen for "RING".
• Choice of transport protocols.
• The state "Connect", in which the transport must be translated at boot.

Using the additional dialog you can set:

• Time intervals of the interface in the format of string "{symbol}:{frm}[::{rtsDelay1}:{rtsDelay2}]", where:
  • symbol — character time in milliseconds, used to control of the frame end;
  • frm — maximum time of the frame in milliseconds, used to limit the package maximum size of the request — the frame;
  • rtsDelay1 — delay between the transmitter activation with RTS signal and start up of the transmission, in milliseconds;
  • rtsDelay2 — delay between the transmitting and disconnecting the transmitter with RTS signal, in milliseconds.
• Priority of the input stream task.
• [MODEM] Modem parameters. This mode is activated by the fifth parameter of the address and includes call waiting from the remote modem (the request "RING"), answering the call (the command "ATA") and the subsequent transfer of requests from the remote station to the transport protocol. The disconnection of the communication session is performed by the connection initiator and leads to the reconnection of the receiver modem to wait for new calls.
  • Requests timeout of the modem, in seconds.
  • Time delay before initializing the modem, in seconds.
  • Time delay after initializing the modem, in seconds.
  • First initialization string (typically contains the reset command of the modem "ATZ").
  • Second initialization string.
  • Result string of the modem's initialization (usually "OK"), with which the modem answers for initializing and which must be expected.
  • Call's request (usually "RING"), which is sent by the modem in the case of an output call.
  • Answer to the call (usually "ATA"), which is sent to the modem to answer the call.
  • Result line for the answer to the call (usually "CONNECT"), with which the modem answers to the answer command, and that is to be expected.
• Protocols' specific custom parameters.
• Reset all the additional parameters to default values and cleanup the protocols' specific custom parameters.

2 Выходные транспорты

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

Fig.2. The generic configuration dialogues of the output serial interface.

Using the main dialog you can set:

• The state of transport, that is: status, "Connect" and name of the database, containing the configuration.
• Identifier, name and description of the transport.
• Address of the transport in the format "{dev}:{spd}:{format}[:{opts}[:{modTel}]]", where:
  • dev — address of the serial device (/dev/ttyS0);
  • spd — speed of the serial devices from a number: 300, 600, 1200, 2400, 4800, 9600, 19200, 38400, 57600, 115200, 230400, 460800, 500000, 576000 or 921600;
  • format — asynchronous data format "{size}{parity}{stop}" (8N1, 7E1, 5O2, ...);
  • opts — different options, mostly for flow control, separated by ',':
    • "[-]h" — hardware (CRTSCTS);
    • "[-]s" — software (IXON|IXOFF);
    • "rts" — using of the RTS signal for transferring(false) and checking for echo, for raw RS-485;
    • "rts1" — using of the RTS signal for transferring(true) and checking for echo, for raw RS-485;
    • "rtsne" — using of the RTS signal for transferring(false) and without checking for echo, for raw RS-485;
    • "rts1ne" — using of the RTS signal for transferring(true) and without checking for echo, for raw RS-485;
    • "[-]RS485" — using RS-485 mode, through TIOCSRS485.
  • modTel — modem phone, presence of this field switches transport to work in the modem mode.

Using the additional dialog you can set:

• Time intervals of the interface in format of the string "{conn}:{symbol}[-{NextReqMult}][:{KeepAliveTm}[:{rtsDelay1}:{rtsDelay2}]]", where:
  • conn — maximum time of waiting the connecting response, in milliseconds;
  • symbol — maximum time of one symbol, used for the frame end detection, in milliseconds;
  • NextReqMult — next request's multiplicator to the symbol time, 4 by default;
  • KeepAliveTm — keep alive timeout to restart the transport, in seconds; use the value < 0 for stopping the transport after missing response at each request;
  • rtsDelay1 — delay between the transmitter activation with RTS signal and start up of the transmission, in milliseconds;
  • rtsDelay2 — delay between the transmitting and disconnecting the transmitter with RTS signal, in milliseconds.

Can be prioritatile specified into the address field as the second global argument, as such "/dev/rfcomm0:9600||1000:40-20".

• Do not disconnect at processing. Sometimes the closing of an open device can be destructive, for example, on an ICP-DAS LP PLC, and you can prevent it with this option.
• [MODEM] Modem parameters. This mode is enabled by the fifth parameter presence of the address and it involves making a call on the phone specified by this parameter at the start time of the transport. After establishing a connection to the remote modem, all transmission requests are sent to the remote modem station. Disconnection of a communication session, with the transport stopping, is carried out according to the activity timeout.
  • Requests timeout of the modem, in seconds.
  • Lifetime of the connection, in seconds. If during this time there will be no data transmission over the transport the connection will be aborted.
  • Delay time before initializing the modem, in seconds.
  • Delay time after initializing the modem, in seconds.
  • First initialization string (typically contains the reset command "ATZ" of the modem).
  • Second initialization string.
  • Result string of the modem's initialization (usually "OK"), with which the modem answers for initializing and which must be expected.
  • Dialling string to the remote modem (usually "ATDT"). When dialing, the phone number is added to this prefix.
  • Result string of the successful connection (usually "CONNECT").
  • Result string of the busy line (usually is "BUSY").
  • Result string of the absence of the carrier in line (usually "NO CARRIER").
  • Result string of the dial tone lack in the line (usually "NO DIALTONE").
  • Exit string from the data mode (usually "+++") and the "Delay time before initializing the modem" is used, after it.
  • Hang up command (usually "+++ATH"). This command is called whenever there is need to break the connection.
  • Result string of the hanging up command (usually "OK"), with which the modem answers to the command and which must be expected.
• Protocols' specific custom parameters.
• Reset all the additional parameters to default values and cleanup the protocols' specific custom parameters.

Транспорт может работать с аппаратной шиной 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 проверена:

• ICP DAS: tDS-7xx — настраивается через WEB-интерфейс и работает по прямому подключение к TCP-порту;
• Tibbo: DS100 — настраивается только через программу для MS Windows®, предоставляет собственный драйвер для формирования виртуальных последовательных интерфейсов на Linux, работает по прямому подключение к TCP-порту.