Автоматическая генерация программного кода микроконтроллера на основе событийно-ориентированной модели

[vpuhoff]

Думаю это зависит от того на какие хабы вы подписаны, не уверен точно как осуществляется отбор, но он явно от этого зависит.

[dtestyk]

Были ли у вас случаи, когда для срабатывания триггера нужно не просто множество событий, а некоторая их частичная упорядоченность по времени? Как боролись: введением вспомогательных триггеров?

[vpuhoff]

Если я правильно понял имеется в виду случай, когда при срабатывании триггера должно произойти несколько действий, но не сразу а последовательно, в таких случаях возможно 2 варианта:

1. просто использовать delay или его аналог, подходит к случаям когда заранее известно, что ничего другого в это время не произойдет.
2. вспомогательные триггеры, тут несколько вариантов, наиболее простой в реализации это добавление счетчиков, значение которых обновляется в соответствии с прошедшим временем (по millis к примеру), в таком случае условием для триггера будет значение этого счетчика. Похожее у нас используется для событий по времени.

[dtestyk]

при срабатывании триггера должно произойти несколько действий

Не совсем это имел ввиду: «триггер» A должен сработать, когда сначала был открыт кран, а затем включен насос, а не просто когда кран открыт и мотор включен. Причем, насос может включаться вручную. Т.е сам по себе триггер на открытие крана не нужен. А ведь может быть еще и другой «триггер» В(аварийный), который срабатывает когда, сначала включается мотор, а потом открывается кран.

история вопроса

Предложил использовать событийный адрес, но не смог придумать убедительного примера. В комментарие к своей предыдущей статье автор Парадигма ситуационно-ориентированного программирования написал:

Понятие «событийный адрес» не нужно.

Мне кажется, случай с насосом как раз является таким примером. Хотя если и он не достаточно показателен(можно просто по событию включения проверять открытость крана), можно предствить цепочку из трех и более событий.
P.S. Чтобы лишний раз не путаться в терминах, можно назвать «триггеры» А и В, например, «метатриггеры».

[vpuhoff]

В таком случае тут достаточно просто добавить 2 глобальные переменные — время запуска мотора и время открытия крана, затем на триггере использовать в качестве условия сравнение этих переменных.
Заполнять их значения по действию с соответствующих триггеров.Ничего сложного вроде как нет.

[dtestyk]

Спасибо, думал в этом направлении. Также нужны триггеры на обратные действия. Ведь мотор может включаться и выключаться несколько раз, также как и кран может открываться и закрываться. Возникает разделение триггеров на ключевые(активные), приводящие к действиям и вспомогательные(информативные), работающие в паре(открытие/закрытие, включение/выключение) и запоминающие время и последнее состояние.

Другой вариант: для каждого событийного адреса на основании предыдущих состояний формировать ожидаемые(несколько, так как инициирующее(первое в цепочке) событие может произойти еще раз после начала отслеживания) состояния и сравнивать их с текущим. При совпадении по маске, продолжать отслеживать цепочку. При наступлении ключевого события сработает «метатриггер». Из плюсов этого варианта — большая скорость реагирования, поскольку не нужно смотреть историю — мы ожидали ключевое событие.

На самом деле, возможна произвольная комбиная отслеживания и проверки истории. Событие, при котором происходит и проверка истории и запуск отслеживания можно назвать базовым. Но можно пойти еще дальше и допустить несколько базовых событий(дерево точек отсчета как вперед так и назад во времени), сброс ожидания событий по таймеру…

Также нужно помнить, что каждый триггер, который должен срабатывать повторно, должен где-то сбрасываться.

[vpuhoff]

Все так, сразу видно человека, который «в теме») По сути информативный и ключевой ничем не отличаются, просто информативный «ничего не делает». Второй вариант выглядит довольно красивым, но уже достаточно сильно зависит от языка реализации, в текущей реализации программа пригодна для любых языков с похожим на Си синтаксисом, если затачивать под конкретную платформу можно построить любой алгоритм выбора триггера. В текущей реализации можно поступить похожим образом, используя только более правильную «сортировку» триггеров. Метатриггер это насколько я понял просто триггер который зависит от других триггеров, такой в текущей реализации уже есть. По поводу сброса тоже думал, можно было реализовать на уровне приложения, но тогда это ставит жесткие рамки, по сути для сброса достаточно скинуть bool значение на false чтобы активировать триггер, это можно сделать из любого действия или вынести на уровень шаблона кода. Похожее я использовал для удаленного управления, все свободное от работы время контроллер слушает сеть на наличие команд.

[StarHunter]

Уважаемый автор, а Вы не думали в сторону языков релейной логики?
Например, можно использовать вот это

[vpuhoff]

Это очень хорошее решение для задач с идеальным ТЗ, в которых не может быть отклонений от изначально поставленной задачи. К примеру пример из практики, изначально было N устройств и определенная схема взаимодействия, к концу разработки было уже N+6 устройств и совсем другая схема взаимодействия. В случае с релейной логикой пришлось бы для каждого случая с нуля паять всю логику (которая была бы очень не простой). В случае с моим решением достаточно поменять пару триггеров в интерфейсе, чтобы получить полностью готовое решение с учетом изменений.

[vpuhoff]

За эти годы появилось много новых интересных решений для управления устройствами. Если вы хотите автоматизировать умный дом или создать систему управления для бизнеса, вот несколько вариантов, которые я могу порекомендовать:

• Node-RED – это простая платформа с визуальным программированием. Она позволяет соединять различные устройства, датчики и сервисы в удобные потоки, что идеально подходит для быстрого прототипирования.

• Home Assistant и openHAB – отличные решения для создания умного дома. Они используют события для управления устройствами, что позволяет легко настроить даже сложные сценарии взаимодействия.

• Eclipse 4diac – если вам нужна система для промышленной автоматизации, эта платформа поможет объединить несколько устройств в одну сеть и обеспечить надежную работу.

• ThingsBoard – универсальная платформа для IoT, которая помогает собирать данные с датчиков, управлять устройствами и быстро реагировать на события в реальном времени.

Кроме того, если вам нужно масштабное решение, можно обратить внимание на облачные сервисы, такие как AWS IoT и Azure IoT. Они отлично подходят для работы с большим количеством данных и устройств.

Надеюсь, что эти советы помогут вам выбрать подходящее решение для ваших проектов. Удачи и успехов!