libuniset2 — библиотека для создания АСУ. Лучше один раз увидеть…Часть 6 (Заключительная)

В предыдущих частях (часть 1 ^[1], часть 2 ^[2], часть 3 ^[3], часть 4 ^[4], часть 5 ^[5]) были рассмотрены принципы и механизмы libuniset2, на примере сферической задачки по управлению. Осталось показать, что не вошло в поле нашего зрения… Тех, кто ещё не устал, прошу…

Итог

Целью предыдущих частей, было показать как просто и быстро можно написать (или даже развернуть) систему управления с использованием libuniset2. Если обобщить, то всё сводится к нескольким простым шагам:

• Заложить проект и наполнить его датчиками, входящими в систему (заполнение configure.xml). Кстати этот процесс можно и автоматизировать, генерируя список датчиков (или настроек) из каких-нибудь других более удобных форматов (источников)
• Реализовать свои алгоритмы управления, предварительно описав каждый в специальном xml-файле, рассматривая свой процесс как чёрный ящик со входами и выходами
• Отладить локально, при этом воспользовавшись различными утилитами, входящими в состав libuniset2-utils
• Написать тесты, используя тестовый фрэймворк — uniset2-testsuite ^[6]

И всё…
Но многие компоненты входящие в состав libuniset2 так и не были рассмотрены, поэтому я просто кратко опишу что, ещё входит в libuniset2 (может наберусь сил когда-нибудь и их описать с примерами использования)

Компоненты, не вошедшие в обзор

• SharedMemory ^[7] — Основной элемент системы, через который осуществляется вся работа. На самом деле, помимо собственно хранения текущих значений, SM умеет:
  • Формирование уведомлений об изменении заказанных датчиков
  • Формирование пороговых датчиков (по аналоговым)
  • Реализует механизм зависимости между датчиками
  • Реализует механизм отслеживания «сердцебиения» для процессов
  • Формирование аварийного следа, по событию (сохранение по срабатыванию датчика («детонатора»), значений указанной группы датчиков за последние N точек)
  • Восстановление данных из резервных SM
• DBServer — Ведение БД. Сохранение истории изменения по каждому датчику. Работа с MySQL, PostgreeSQL, SQLite, RRD
• Modbus TCP/RTU (Master ^[8],Slave ^[9]) — Реализация готовых процессов обмена по протоколу Modbus TCP/RTU в режимах Master и Slave. Опрос по нескольким каналам, переключение каналов в случае недоступности slave-узлов и т.п.
• IOControl ^[10] — Работа с картами ввода/вывода. Работа реализована на основе использования libcomedi ^[11]. В рамках этого были разработаны драйвера для поддержки карт ввода/вывода Российского производителя фирмы Fastwel ^[12]
• Механизмы обработки входных датчиков — задержка на срабатывание и отпускание, работа по переднему и заднему фронтам сигнала, антидребезг, простые цифровые фильтры для аналоговых сигналов, калибровка (линейная и по калибровочным диаграммам) и другие преобразования
• UNET ^[13] — протокол собственной разработки, на основе broadcast UDP. Обеспечивает синхронизацию состояния датчиков между узлами распределённой системы. Готовый компонент, только настроить и запустить. В самой первой статье ^[14] была представлена структурная схема системы с использованием UNET.
• LogicProcessor ^[15] — Реализация простого движка для поддержки «простых» логических схем. Создаётся описание логической схемы в виде xml-файла. Для использования доступны элементы «AND», «OR», «Delay», «NOT»
• MQTTPublisher — Возможность публиковать данные с датчиков в системе по протоколу MQTT ^[16]. Реализация основана на использовании проекта mosquitto ^[17].
• uniset-timemachine — Это отдельный, очень интересный, проект (на python). Суть его заключается в проигрывании исторических, данных сохранённых в БД. Данные вынимаются из БД и сохраняются в SM в реальном времени. Например, если подключить при этом графический интерфейс или имитаторы панелей управления, то можно визуально наблюдать, какие кнопки нажимал оператор в тот или иной момент, какие лампочки при этом зажигались, что было на экране графического интерфейса и т.п. Т.е. действительно «машина времени» (Правда этот проект ещё ждёт своего часа, там требуется оптимизация при больших объёмах БД, и пока поддерживается только MySQL. Но это всё дело времени…)

В целом вот тут ^[18] есть, какая-никакая, но документация.

Немного о реальном применении

Конечно, как известно, любая программа содержит ошибки. Думаю и в libuniset2 не всё идеально, но всё-таки она работает. Работает в реальных проектах. На сегодняшний день, самая «большая система» (просто пока не было проектов побольше) это система управления, где:

• Около двенадцати тысяч датчиков
• Около восьмидесяти опрашиваемых ModbusSlave устройств
• При этом сама система состоит всего из 5 контроллеров и 2 графических панелей
• Синхронизация состояния всех датчиков между узлами — 150 мсек (UNET)

Были проекты с примерно тремя тысячами датчиков, но зато контроллеров (узлов) было около 18-ти. Эти цифры не призваны «впечатлить», просто хочется показать, что это работает. И переваривает большие объёмы, без специальной оптимизации, хотя механизмы для этого в libuniset2 тоже есть (опрос не на каждом цикле для низко приоритетных или редко меняющихся датчиков и т.п.). В целом уже около тридцати или сорока проектов.

Так что попробуйте libuniset2, это легко :)

Ссылки на проект:

• Проект libuniset2 на github ^[19]
• Исходники примера ^[20]
• Багзилла проекта ^[21]

Автор: PavelVainerman

Источник ^[22]