- PVSM.RU - https://www.pvsm.ru -
В данной статье речь пойдёт об открытой библиотеке для построения распределённых систем управления — libuniset, написанной на языке C++ под ОС Linux. Будет дан общий обзор основных понятий, элементов и концепций, используемых в библиотеке.
Основной целью библиотеки libuniset является предоставление готовых «кубиков» для построения распределённых автоматизированных систем управления (АСУ). В любой АСУ можно выделить такие основные направления как:
В libuniset сделана попытка создать готовые для использования, согласованные и взаимодействующие между собой компоненты для всех указанных направлений, и при этом создать достаточно универсальную и легко расширяемую библиотеку.
Типичным проектом с использованием данной библиотеки является проект, состоящий из порядка 20-25 узлов, реализующих управление и контроль состояния, а также операторских станций (обычно не меньше двух резервирующих друг друга) отображающих информацию и, помимо этого, реализующих журналирование всех событий, происходящих в системе (то есть заполняющих базу данных). В общем случае число узлов системы не ограничено.
Библиотека libuniset развивалась (и развивается сейчас) как и положено — постепенно. В ходе работы над различными проектами систем управления из них выделялись какие-то общие для всех систем свойства, механизмы или компоненты, и эти общие части вносились в библиотеку для дальнейшего повторного использования. На данный момент текущей версией является версия 1.6, которая представляет из себя уже достаточно зрелую библиотеку с установившимся API, которая позволяет легко (и быстро) создавать и разворачивать системы управления.
На данный момент библиотека и все её вспомогательные утилиты собираются под дистрибутив ALT Linux [1],
а так же дополнительно, при помощи системы Korinf [2], библиотека собирается под:
На рисунке сделана попытка графически представить, что из себя представляет libuniset.
В основу положена технология CORBA [7], на ней построено всё взаимодействие «компонентов» системы между собой. При этом следует заметить, что API библиотеки «маскирует» взаимодействие, основанное на CORBA [7] и при необходимости взаимодействие может быть переписано с использованием других механизмов, не затрагивая интерфейсы, предназначенные для использования в проектах. Можно видеть, что libuniset по возможности задействует сторонние библиотеки (стараясь избегать изобретения велосипедов). Методы использования библиотеки могут быть различны: начиная от написания необходимой функциональности путём наследования от классов библиотеки и заканчивая использованием уже готовых компонентов без какой-либо модификации, а лишь настраивая их под свои задачи.
Основной информационной единицей в библиотеке является датчик. По сути, датчик — это некая переменная, хранящая состояние. Практически любая информация (о событиях, о состоянии того или иного процесса, объекта, сообщение оператору и т.п.) передаётся через состояние «датчика». В библиотеке предусмотрено четыре типа датчиков:
Исходно данные типы используются непосредственно процессами ввода/вывода. «Выходы» (DO, AO) — это команды «от системы управления», «Входы» (DI, AI) — это информация от объекта «в систему управления». Помимо этого, датчики не обязательно должны быть «живыми» входами или выходами — при помощи этих четырёх типов можно кодировать любую информацию. Например, можно передавать сообщения оператору, заранее создавая для каждого сообщения свой «датчик» и в случае необходимости послать сообщение выставлять его в «1». Удобство и универсальность числовых датчиков позволяет использовать для передачи данных большое число различных протоколов, рассчитанных на передачу только цифровой информации. Например: CAN [8], ModbusRTU [9], ModbusTCP [9] и т.п.
Вторым важным понятием является объект. Под объектом подразумевается некая сущность, способная принимать сообщения. Объекты создаются, инициализируются и запускаются в работу специальным активатором.
Дополнительно можно ещё ввести понятие процесс. Под процессом подразумевается системный процесс (запущенная программа), выполняющий те или иные функции управления и обменивающийся для этого с другими процессами сообщениями или удалённо вызывающий функции других объектов. Чаще всего понятия процесс и объект совпадают. В некоторых случаях процесс может содержать несколько взаимодействующих объектов. Все процессы в системе — многопоточные, так как для взаимодействия с другими объектами (процессами) в обязательном порядке создаются потоки для CORBA [7], а также у каждого объекта создаётся свой поток обработки сообщений (если его специально не отключить).
В ходе развития проекта опытным путём сформировалась следующая схема взаимодействие процессов на узле:
Центральным элементом системы является SharedMemory (SM) — это процесс, осуществляющий хранение состояния всех датчиков. Всё взаимодействие между процессами осуществляется через него. При этом не следует путать это название с понятием «разделяемая память», относящимся к механизмам взаимодействия в UNIX-системах. В данном случае процесс SharedMemory просто выполняет функцию разделяемого хранилища и поэтому получил такое название. Помимо этого SharedMemory осуществляет рассылку уведомлений другим процессам об изменении состояния того или иного датчика.
Все процессы условно можно разделить на два типа: «активные» и «пассивные».
Пассивные процессы — это процессы, которые большую часть времени «спят», ожидая сообщений об изменении того или иного датчика. В основном к таким процессам относятся процессы управления.
Активные процессы — это процессы, которые постоянно выполняют какую-то работу. К таким процессам относятся:
Так как активные процессы тесно взаимодействуют с SharedMemory, то для оптимизации работы (исключения удалённых вызовов процедур через CORBA) все активные процессы запускаются в одном адресном пространстве с SharedMemory (каждый процесс в отдельном потоке), и работают с SM напрямую, через указатели. Этот «объединённый» процесс по историческим причинам называется SharedMemory2.
Отдельно можно выделить группу «вспомогательных» процессов. На данном рисунке к таким относится DBServer, обычно запускаемый на операторских станциях, где ведётся БД. Его задача — получать уведомления от SM по изменении любого датчика и сохранять эти события в БД. По умолчанию в libuniset реализована поддержка MySQL и SQLite, но при необходимости можно реализовать взаимодействие с любой СУБД, разработав соответствующий DBServer.
На рисунке представлена типичная схема сетевого взаимодействия на основе libuniset.
Для обеспечения «прозрачности сети» на каждом узле запускается своя копия SharedMemory(SM). «Прозрачность» при этом обеспечивают процессы обмена между узлами по соответствующему протоколу (на рисунке это CAN и UNET). Узлы постоянно обмениваются между собой датчиками обеспечивая «одинаковость» хранимой в SM информации. Каждый процесс обмена получает от других узлов информацию о находящихся у них датчиков, и в свою очередь посылает другим узлам информацию о датчиках находящихся у него на узле.
Так же через SM функционирует и процесс ввода/вывода (IOControl). Всё, что считывается с каналов ввода, сохраняется в SM, а состояние «выходов» читается из SM и выводится в каналы вывода.
Из рисунка можно видеть, что взаимодействие может быть построено практически на основе любого интерфейса (Ethernet, CAN, RS, MIL-STD и т. п.). Для этого достаточно написать процесс обмена, реализующий соответствующий интерфейс и взаимодействующий с SM. При этом вся остальная система не потребует модификации.
Готовые компоненты представляют из себя уже законченные программы (процессы), которые «умеют» взаимодействовать с SharedMemory и позволяют легко «развёртывать» распределённые системы. В библиотеке libuniset имеются следующие готовые компоненты:
По мере работы над проектами и развитием возможностей библиотеки, в неё стали включаться различные вспомогательные утилиты, позволяющие вести наладку проектов, созданных с её использованием. Вот список основных утилит с кратким описанием:
Программный интерфейс (API) библиотеки libuniset стабилизировался уже давно, и постепенно в дополнение к ней возникли различные вспомогательные программы. Поскольку целью данной статьи является общее знакомство именно с libuniset, ограничимся только перечислением таких дополнений:
Библиотека libuniset позволяет довольно быстро создавать «сложные» системы. В чём-то она похожа по идеологии на SCADA-системы, но следует иметь ввиду, что это только поверхностное сходство: пользователю в данном случае представлен полный контроль над работой системы, возможность программировать любые алгоритмы (на языке C++). Хотя следует заметить, что система, построенная на libuniset, может быть легко интегрирована в какую-либо существующую систему (на основе SCADA) — просто выступая, например, в качестве Modbus Slave узла. Или же наоборот, может взаимодействовать с любой сторонней SCADA-системой, просто используя процесс обмена Modbus Master (готовый компонент).
Имеется положительный опыт применения её в ответственных проектах, где она проявила себя как надёжно работающая система (24x7x365).
Автор: PavelVainerman
Источник [12]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/razrabotka/28716
Ссылки в тексте:
[1] под дистрибутив ALT Linux: http://ftp.etersoft.ru/pub/Etersoft/LINUX@Etersoft/Sisyphus/i586/RPMS.addon/
[2] Korinf: http://wiki.etersoft.ru/Korinf
[3] Debian: http://ftp.etersoft.ru/pub/Etersoft/Sisyphus/Debian/7.0/
[4] Fedora: http://ftp.etersoft.ru/pub/Etersoft/Sisyphus/Fedora/18/
[5] Ubuntu: http://ftp.etersoft.ru/pub/Etersoft/Sisyphus/x86_64/Ubuntu/12.10/
[6] CentOS: http://ftp.etersoft.ru/pub/Etersoft/Sisyphus/CentOS/6/
[7] CORBA: http://ru.wikipedia.org/wiki/CORBA
[8] CAN: http://ru.wikipedia.org/wiki/Controller_Area_Network
[9] ModbusRTU: http://ru.wikipedia.org/wiki/Modbus
[10] git.etersoft.ru/projects/asu/uniset.git: http://git.etersoft.ru/projects/asu/uniset.git
[11] wiki.etersoft.ru/UniSet: http://wiki.etersoft.ru/UniSet
[12] Источник: http://habrahabr.ru/post/171711/
Нажмите здесь для печати.