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

Общее описание

Можно изучить на странице Подробнее об архитектуре проекта

Сборка

Требуется ряд инструментов для сборки и тестирования:

CMake 3.28+
conan2
рекомендуется использовать clion или другой современный IDE с поддержкой CMake и conan2

Для работы с пакетами conan2 из нашего репозитория требуется добавить удалённый репозиторий:

conan remote add insitech https://nexus.insitechdev.ru/repository/conan-hosted --force

conan remote login insitech "comfort-embeded-deploy" -p vf6kXWp9c1NeU5eJRAEGKMc

После добавления репозитория, проект собирается с помощью cmake как обычно.

CMAKE флаги

флаги добавляются автоматически в ci/cd , но разработчик может по необходимости включать их в сборку. Например если нужно включить сборку для ARM на linux x86 машине.

CMAKE_BUILD_TYPE (Release/Debug)
PROJECT_SEMVER версия со стандартным форматом MAJOR.MINOR.PATCH. Используется только для cmake
SOFTWARE_VERSION версия для бинаря,( например x.x.x-postfix) передается из Conan или из cicd.
SOFTWARE_COVERAGE # опция покрытия, включай в CI только там, где нужно
BUILD_FOR_TARGET # если нужно собирать для другой платформы, например, для ARM на x86. Настраивается в нашем cicd

Это и многое другое описано в шаблонном проекте в ветке console_template

Именование сборок

В конец названия исполнительного файда добавляется суффикс, например

lacteApp : armv6 , целевая архитектура
lacteApp_arm64: arm64 архитектура

Это было нужно для исключения ошибок при компилировании под собственную среду. Возможно в будущем будет лишено смысла

Установка и запуск

Запуск

lacteApp [OPTIONS]

Опции:

--test <mode> — тестовый режим. По умолчанию ping.
- ping — отправляет стандартные запросы на плату и проверяет ответы.
--flash <path> — путь к файлу прошивки (поддержка сервиса обновления).
--dev <tty> — путь к UART-устройству (например, /dev/ttyUSB0). Если опция не указана, приложение попытается * *автоматически обнаружить** устройство по VID:PID 067b:23a3 и открыть его на скорости 115200.
--verbose — подробный вывод протокола (парсинг полей, длины, CRC).
--virtual — запуск в виртуальном режиме (без реального железа). Виртуальная плата полностью повторяет протокол обмена и ответы (для отладки и тестов), кроме перепрошивки: обновление прошивки в виртуальном режиме не выполняется.
-v --version — показать версию приложения.
-h --help — показать справку по опциям.
--no_gui - запустить без gui
--check-interval <ms> — интервал опроса платы в миллисекундах (по умолчанию 10000 мс).
--bin-path <path> - путь к файлам приложения (прошивка для обновления, кэш) (по умолчанию /mnt/nand_disk_ext/lacte).

Примеры:

# Виртуальный пинг с подробным логом
./lacteApp --verbose --test=ping --virtual
 
# Работа с реальной платой
./lacteApp --dev /dev/ttyUSB0 --verbose

Рабочая директория и хранение данных:

по умолчанию у всего есть собственные пути

база данных находится в директории запуска, то есть на целевой платформе это /root/
файл для хранения кэша board_cache.txt. Нужен для сохранения данных от перезагрузки к перезагрузке. Находится в /usr/local/daemon/lacte/board_cache.txt
файл лога будет находиться в /mnt/nand_disk_ext/lacte так как он может быть весьма объемный.
директория для поиска новых прошивок та же что и для логов /mnt/nand_disk_ext/lacte/

Коммуникационные пакеты

protocol page

Обновление прошивки

update page

База данных

database page

Тестирование

Для проверки корректности работы используются интеграционные и модульные тесты на базе GoogleTest и CTest. Современные среды разработки, вроде clion/vscode, поддерживают отладку и запуск gtest, подробнее ищите в документации или youtube канале своей среды. Запуск всех тестов из консоли осуществляется командой:

/usr/bin/ctest --extra-verbose

Пример вывода (сокращённо):

...
[==========] Running 1 test from 1 test suite.
[----------] 1 test from LacteAppTest
[ RUN      ] LacteAppTest.ResetDataKeepsSchemaAndAllowsInsert
[       OK ] LacteAppTest.ResetDataKeepsSchemaAndAllowsInsert (233 ms)
[----------] 1 test from LacteAppTest (233 ms total)
...
[==========] 1 test from 1 test suite ran. (233 ms total)
[  PASSED  ] 1 test.
 
100% tests passed, 0 tests failed out of 15
Total Test time (real) =   8.27 sec

Все 15 тестов успешно проходят, что подтверждает корректную работу сервисных и протокольных компонентов lacteApp, как на уровне интеграции, так и отдельных модулей.

Версионирование

conventional commit . Изучить можно самостоятельно.

Политика релизов

Процесс выкладывания артифактов сложен, он состоит из тестирования и последующей загрузки на nexus. А еще, чаще нам не нужно генерировать пререлизную версию автоматически, кроме как в ветке main/master. Это упрощает последующую работу с git.
Общий принцип такой, для генерации release candidate, нужно закоммитить в testing и потом руками запустить пуш релиза и генерацию версии через https://gitlab.insitechdev.ru/comfort/embedded/lacte/km_lacte/-/pipelines

При пуше в обычную вертку, релиз не формируется, и такой возможности не дается. Вы не можете сгенерировать релиз из feat/your_best_feat.
При пуше в develop, релиз не формируется, но можно запустить его вручную в pipeline проекта https://gitlab.insitechdev.ru/comfort/embedded/lacte/km_lacte/-/pipelines нажаа на "шестеренку возле этапа publish_nexus"
При коммите в testing, все аналогично коммиту в develop, релиз автоматически не убликуется
при мердже в main, релиз сгенерируется сам.

Бинари

Релизы приложения публикуются во внутреннем Nexus-репозитории: https://nexus.insitechdev.ru/#browse/browse:comfort-raw:km_lacte. В каждом релизе содержатся:

все артифакты сборки и тестирования.
два бинарных файла для разных систем.

Документация

Документация попадает в сервер документации https://docs.insilab.ru/km_lacte/

Планируемые улучшения

Метрики/health‑check endpoint.
Миграции схемы БД при обновлениях.