Pull to refresh

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

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

Итог


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

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

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


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

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

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


Конечно, как известно, любая программа содержит ошибки. Думаю и в libuniset2 не всё идеально, но всё-таки она работает. Работает в реальных проектах. На сегодняшний день, самая «большая система» (просто пока не было проектов побольше) это система управления, где:
  • Около двенадцати тысяч датчиков
  • Около восьмидесяти опрашиваемых ModbusSlave устройств
  • При этом сама система состоит всего из 5 контроллеров и 2 графических панелей
  • Синхронизация состояния всех датчиков между узлами — 150 мсек (UNET)

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

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


Ссылки на проект:
Tags:
Hubs:
+6
Comments2

Articles

Change theme settings