?

Log in

No account? Create an account

Контроллер, описание модели опроса устройств

Механизм опроса достаточно сложен, порой я сам забываю как он работает в деталях.

Я думаю, этот пост будет важен не только мне, но и интеграторам при создании сложного проекта.

И так, как я уже сегодня писал, контроллер формирует заявки на опрос устройства с периодичностью указанной либо в локации, либо непосредственно в устройстве. Опрос может выполняться чаще(раз в минуту) если предыдущий опрос(с тремя попытками) был не успешным. Также заявка на опрос подается при получении команды для устройства или формировании ее сценариями. Ну и клиент тоже может сформировать такую заявку.

Заявки поступают опрашивателю(interrogator). Опрашиватель создается для каждого используемого физического интерфейса контроллера. Таким образом есть возможность вести параллельный опрос различных устройств подключив их к разным шинам, например используя несколько USB->RS485 шлюзов.
При получении заявки опрашиватель добавляет ее в свою очередь(FIFO), также проверяет принадлежность данного устройства к типу устройств поддерживающих функционал ExtraScan.

Если устройство поддерживает ExtraScan, а шлюз непосредственно подключенный к устройству не поддерживает, то опрашиватель берет эту задачу на себя, выполняя частый, постоянный опрос таких устройств.
Идея ExtraScan проста, она дает возможность быстро реагировать на события от устройств, которые не могут передавать события, например устройства реализованные на базе RS485 Modbus.

Далее, каждый опрашиватель постоянно выполняет обработку очереди заявок, выдерживая паузу между итерациями как минимум в 300 миллисекунд (иначе будет высокая нагрузка на ЦП).

Первым выполняется функционал ExtraScan для всех поддерживающих устройств, при обнаружении необходимости считать данные заявка на опрос устройства будет помещена в начало очереди.
При выдержке паузы в 300мс учитывается время потраченное на ExtraScan.

Далее идет непосредственно обработка очереди заявок. Устанавливается соединение с устройством. Создается пустой снимок показаний. Проверяется наличие других заявок для устройства(например чтение/запись конфигурации) и выполняются все команды управления устройством. Затем выполняется опрос в котором библиотека устройства выполняет все необходимые действия и наполняет снимок показаниями.
Есть поддержка асинхронных устройств, устройство может ответить, что заявка принята и данные будут позже, в этом случае опрашиватель оставляет снимок показаний пустым, считая, что опрос пройден успешно(механизм получения данных будет рассмотрен отдельно).
Сразу после этого еще раз выполняются новые команды управления устройством(да, могли появиться после опроса, если сейчас не выполнить, то будет пауза(некоторые устройства выдерживают паузы при подключении, отключении и между передачей пакетов данных, паузы могут быть значительные)). Закрываем соединение и проверяем результат всех действий, если где-то что-то пошло не так, то повторяем еще раз(максимум 3 попытки) добавляя нашу заявку заново в конец очереди.
И еще раз проверяем на наличие новых команд, если есть то добавляем также в конец очереди. Последним этапом, в случае успешного опроса или при исчерпании всех попыток, форсируется работа коммуникатора(он отвечает за взаимодействие с сервером в облаке) заставляя его передать полученные данные с минимальными задержками.

В случае, если заявок у опрашивателья нет, то он выполняет ExtraScan функционал и спит по 300мс каждую итерацию.
Первая же добавленная заявка моментально выведет его из сна.


*Пост будет редактироваться по мере внесения изменений в функционал.

Comments

Это все покрыто множеством автоматических юнит-тестов?
Нет, я такой хуетой не страдаю, с этим пожалуйста к фанатикам си плюс плюс.
Функциональное тестирвоание выполняю, остальное работа тестировщиков.
Грубовато как-то вышло.

Автоматическое тестирование на мой взгляд, по крайней мере в моих проектах, отнимает слишком много ресурсов, которых нет.

Аналогично как и разработка детального ТЗ, вещь стоящая но на грани фантастики.

Сложный проект сам, при разработке, учит логике функционирования, т.е. всплывают детали о которых никто не догадывался, и эти детали порой серьезно отражаются на интерфейсе или базовом функционале. Зачастую в этом случае содается костыль.

Если бы я распланировал ресурсы так как нас учат 'серьезные дяди' со стандартными процессами и т.п., то мой проект был бы на уровне проектов ардуино. Ну а ресурсов на серьезную команду у меня нет.

Начнет официальный проект приносить прибыль - обязательно кинем множество ресурсов на тестирование.


Edited at 2019-09-05 11:20 am (UTC)
Эта "хуета" реально бережет нервы.
Чуть выше отписался
И еще, здесь конечно можно долго говорить.
Но юнит тесты подразумевают наличие точных требований к данным на входе и на выходе. Эти данные берут свое начало от детального ТЗ. В данном проекте я не вижу разумного способа создания детального ТЗ в рамках мизерных ресурсов(человекочасов)
ТЗ - это уже для тестировщиков, а юнит тесты для внутренней кухни разработчика, чтобы быть увереным что модуль или сложная функция не сломалась при модификации, что функция корректно отрабатывает разные хитрые комбинации входных параметров и т.д.

Это конечно не актуально для скетчей ардуины, те простыни не поддаются никакому тестированию. Я даже не знаю, как они все это отлаживают, кроме как помигать светодиодиком.

Edited at 2019-09-05 03:13 pm (UTC)