В предыдущих частях (часть 1, часть 2, часть 3, часть 4, часть 5) были рассмотрены принципы и механизмы libuniset2, на примере сферической задачки по управлению. Осталось показать, что не вошло в поле нашего зрения… Тех, кто ещё не устал, прошу…
Целью предыдущих частей, было показать как просто и быстро можно написать (или даже развернуть) систему управления с использованием libuniset2. Если обобщить, то всё сводится к нескольким простым шагам:
И всё…
Но многие компоненты входящие в состав libuniset2 так и не были рассмотрены, поэтому я просто кратко опишу что, ещё входит в libuniset2 (может наберусь сил когда-нибудь и их описать с примерами использования)
В целом вот тут есть, какая-никакая, но документация.
Конечно, как известно, любая программа содержит ошибки. Думаю и в libuniset2 не всё идеально, но всё-таки она работает. Работает в реальных проектах. На сегодняшний день, самая «большая система» (просто пока не было проектов побольше) это система управления, где:
Были проекты с примерно тремя тысячами датчиков, но зато контроллеров (узлов) было около 18-ти. Эти цифры не призваны «впечатлить», просто хочется показать, что это работает. И переваривает большие объёмы, без специальной оптимизации, хотя механизмы для этого в libuniset2 тоже есть (опрос не на каждом цикле для низко приоритетных или редко меняющихся датчиков и т.п.). В целом уже около тридцати или сорока проектов.
Так что попробуйте 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, это легко :)
Ссылки на весь цикл
Ссылки на проект:
v2v
Разъясните пожалуйста: 'о реальном':
PavelVainerman
Нет, в данном случае, "около 12000" — имеется ввиду, все датчики используемые в проекте. Т.е. это число включает в себя, не только то, что получается от ModbusSlave устройств, но и от других систем с которыми ведётся взаимодействие, а также, датчики которые необходимы для внутреннего функционирования алгоритмов. Поэтому ModbusSlave устройства в данном случае — вполне обычные, с разным количеством регистров (от 20 до 80).
В давней статье были приведены "типичные структуры системы на базе uniset". Смысл в том, что на каждом контроллере запускается своя "SharedMemory" в которой "зарегистрированы" ВСЕ датчики (со всех узлов в сети). Т.е. алгоритмы запущенные на том или ином контроллере всегда имеют доступ ко всем датчикам в системе, независимо от того, где эти датчики находятся. Поэтому стоит задача синхронизировать состояние всех SM между собой. Этим занимаются процессы сетевого обмена (могут быть разные протоколы), запускаемые на каждом узле. Их задача, посылать в сеть информацию которая формируется на данном узле (взять из SM послать в сеть) и принимать информацию от других узлов (процессов обмена), сохраняя её в SM. В результате, с задержкой на сетевой обмен, на каждом узле SM содержит всю актуальную информацию по всей системе. Это и называется в данном случае "синхронизация состояния всех датчиков". Т.е. обеспечение того, чтобы на всех узлах SM содержала одинаковое, актуальное текущее состояние датчиков. При этом по сути уже не важно где запускать алгоритм управления (в целом они даже могу динамически мигрировать с узла на узел если надо), потому-что на любом узле "всё есть".