OpenSCADAWiki: Home Page Uk/Doc/ Serial
 
English (1 Kb) English
Russian (1 Kb) Российский

 (2 Kb) Сторінку заморожено, актуальна тут.

Модуль <Serial> підсистеми "Транспорти"

Модуль: Serial
Ім'я: Послідовний інтерфейс
Тип: Транспорт
Джерело: tr_Serial.so
Версія: 1.6
Автор: Роман Савоченко, Максим Кочетков
Опис: Надає послідовний інтерфейс. Використовується для обміну даними через послідовні інтерфейси типу RS232, RS485, GSM та інші.
Ліцензія: GPL

Contents

Вступ

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

У режимі модему модулем підтримується змішаний режим роботи. Змішаний режим має на увазі наявність вхідного транспорту, який очікує зовнішніх підключень, а також вихідного транспорту на тому-ж пристрої. Тобто вхідний транспорт буде ігнорувати всі запити при наявності встановленого вихідним транспортом підключення, в той-же час вихідний транспорт не буде здійснювати спроб встановлення підключення при наявності підключення до вхідного транспорту або підключення іншого вихідного транспорту, наприклад, з іншим номером телефону.

 (2 Kb) У звичайному режимі послідовного інтерфейсу не допускається багаторазове використання одного й того-ж порту у вхідних та вихідних транспортах. Глобального блокування послідовного пристрою не здійснюється у зв'язку із неоднозначністю цього процесу на системному рівні, а багаторазове використання може привести до непередбачуваних проблем. При потребі у організації локального послідовного каналу з парою пов'язаних портів рекомендується використовувати команду "$ socat -d -d pty,raw,echo=0,perm=0666 pty,raw,echo=0,perm=0666".

1. Вхідні транспорти

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

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

Діалог конфігурації вхідного послідовного інтерфейсу. (82 Kb)
Рис.1. Діалог конфігурації вхідного послідовного інтерфейсу.


За допомогою цього діалогу можна встановити:

Транспорт підтримує можливість роботи у режимі модему. Цей режим включається п'ятим параметром адреси та передбачає очікування дзвінка від віддаленого модему (запит "RING"), відповіді на дзвінок (команда "ATA") та наступної передачі запитів від віддаленої станції протоколу транспорту. Відключення сеансу зв'язку здійснюється ініціатором з'єднання та призводить до перепідключення модему приймача на очікування нових дзвінків.

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

Вкладка "Модем" конфігурації модему вхідного послідовного інтерфейсу. (78 Kb)
Рис.2. Вкладка "Модем" конфігурації модему вхідного послідовного інтерфейсу.


За допомогою цього діалогу можна встановити наступні властивості роботи з модемом:

2. Вихідні транспорти

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

Головна вкладка сторінки конфігурації вихідного послідовного інтерфейсу зображена на рис.3.

Головна вкладка сторінки конфігурації вихідного послідовного інтерфейсі. (85 Kb)
Рис.3. Головна вкладка сторінки конфігурації вихідного послідовного інтерфейсі.


За допомогою цього діалогу можна встановити:

Транспорт підтримує можливість роботи у режимі модему. Цей режим включається наявністю п'ятого параметру адреси та передбачає здійснення дзвінка за телефоном, вказаним п'ятим параметром, в момент запуску транспорту. Після встановлення зв'язку з віддаленим модемом всі запити передачі спрямовуються станції за віддаленим модемом. Відключення сеансу зв'язку, із зупинкою транспорту, здійснюється за таймаутом активності.

Транспорт може працювати з апаратною шиною I2С якщо у якості пристрою обрати "/dev/i2c-{N}" та шина дозволить встановити адресу підлеглого пристрою командою I2C_SLAVE, із першого байту запиту. Швидкість та формат не відіграють ролі в цьому режимі. Із таймаутів тут фактично працює тільки час символу і переважно для розрахунку очікування повтору запиту.

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

Вкладка "Модем" конфігурації модему вихідного послідовного інтерфейсу. (94 Kb)
Рис.4. Вкладка "Модем" конфігурації модему вихідного послідовного інтерфейсу.


За допомогою цього діалогу можна встановити наступні властивості роботи з модемом:

3. API користувацького програмування

Об'єкт "Вихідний транспорт" (SYS.Transport.Serial.out_{OutTransport})

4. Зауваження

Комунікації через послідовні інтерфейси мають низку особливостей. Найбільш важливою особливістю є критерій закінчення повідомлення та час очікування цього критерію. У одних протоколах таким критерієм виступає ознака закінчення або вказаний розмір повідомлення. В інших протоколах таким критерієм є відсутність даних у вхідному потоці протягом вказаного часу, час символу. У обох випадках час очікування критерію або символу є ключовим та сильно впливає на загальний час обміну. Відповідно, чим менше цей час тим краще. Тут і виникає проблема латентності обладнання та його драйверів.

Перевірити латентність каналу обміну та тим самим оптимально налаштувати час доочікування, символу можна за допомогою інтерфейсу вкладки "Запит" вихідного транспорту. Для цього потрібно вказати зразковий запит відповідного протоколу, вказати "Очікувати таймаут", надіслати запит та проконтролювати його цілісність. Для отримання більш репрезентативного результату треба запит повторити декілька разів. Якщо спостерігається отримання неповних відповідей, то час символу треба збільшити, інакше можна зменшити.

На будованому обладнані послідовних інтерфейсів RS232/422/485 можна добитися низького рівня латентності, впритул до одиниць мілісекунд. Однак, на високо-навантажених системах з безліччю задач у пріоритеті реального часу латентність може стати недетермінованою у зв'язку з виконанням потоку обслуговування подій ядра Linux у низькому пріоритеті. Для вирішення цієї проблеми треба встановити високий пріоритет цим потокам, що можна здійснити за допомогою скрипта, помістивши його, наприклад, у "/etc/rc.local":


Цей скрипт не має сенсу для ядер Linux реального часу, з патчем PREEMPT_RT, скільки всі потоки переривань та повідомлень там вже запускаються у пріоритеті реального часу.

На зовнішньому обладнані послідовних інтерфейсів, наприклад, у перетворювачах USB->RS232/422/485, може виникнути проблема високої латентності, пов'язана з особливістю апаратної реалізації або його драйверу. Вирішувати цю проблему треба шляхом вивчення налаштувань цього обладнання або встановленням більшого часу очікування, символу!

Схожим чином визначається й оптимальний час підключення, а саме: встановити час підключення у значення по замовченню для даної швидкості (ставиться при зміні швидкості у адресі), зняти "Очікувати таймаут", відіслати запит. Якщо відповідь прийшла то беремо виміряний час відгуку пристрою, подвоюємо та встановлюємо отримане значення як час підключення. Необґрунтоване перевищення часу підключення призведе до великих очікувань у випадку відсутності пристрою, а також спрацьовуванню захисних таймаутів внутрішніх процедур!

 (2 Kb) На ринку зустрічаються USB->Serial перетворювачі, які працюють тільки з терміналами, тобто вони можуть передавати та опрацьовувати виключно ASCII символи та не можуть бути переключені у бінарний режим. Відомі екземпляри таких перетворювачів: PL2303TA (Y-105).

Віртуальні/локальні послідовні інтерфейси

Часто для локальної перевірки, без фізичного обладнання, потрібна пара портів підключених у одну мережу. Створення таких портів та виконання багатьох інших операцій над послідовним потоком дозволяє виконувати утиліта socat. Наприклад, для створення двох пов'язаних портів треба виконати команду, яка створить їх та повідомить адреси:

Перекидання послідовного інтерфейсу через мережу Ethernet

У деяких випадках буває корисним перекинути порт послідовного інтерфейсу віддаленої машини на локальний порт, наприклад, для опитування пристроїв, підключених до послідовного інтерфейсу віддаленої машини. Звісно, якщо встановити на віддалену машину OpenSCADA у конфігурації ПЛК, то можна буде одразу виконувати обробку цих даних, попереднє буферування/архівування та інше, але інколи обладнання може бути складним для запуску OpenSCADA, де й рятує можливість перекидання послідовного потоку через мережу. Для вирішення цього завдання можна скористатися тією-ж утилітою socat або remserial, ser2net, яку вдасться зібрати та запустити на віддаленій машині. Приклади перекидання послідовного порту:


У випадку з "socat", а можливо й інших утиліт, можна на клієнтському боці опустити запуск драйверу EthernetTCP->Serial та підключатися із OpenSCADA прямо на TCP-порт віддаленого пристрою.

 (2 Kb) У роботі через драйвер EthernetTCP->Serial є особливість, яка пов'язана із наявністю двох таймаутів підключення, один у драйвері, інший у Transport.Sockets. Важливо щоб значення цього таймауту у Transport.Sockets було більше ніж у драйвері інакше можливий зсув та отримання на запит запізнілої відповіді від попереднього запиту.

Багато виробників промислового комунікаційного обладнання випускають готові конвертери із Ethernet у RS-232/422/485, які можуть використовуватися з OpenSCADA таким-же чином. Коментарі та перелік перетворювачів з якими роботу OpenSCADA перевірено:

Посилання

Referring pages: HomePageUk/Doc
HomePageUk/Doc/DCON
HomePageUk/Function
HomePageUk/Using/PLC/firmware
HomePageUk/Using/PLC/firmwareARM