Установка и развертывание#

Метаданные#

  • Документ ID: REG-OPS-003

  • Версия: 0.1.1

  • Ответственный: ООО "Аросса"

  • Статус: Готово

1. Требования к окружению#

  • Аппаратные требования: локальный контроллер с Linux, CAN-интерфейсом, сетевым доступом и достаточными ресурсами для backend/UI/MQTT; для ПАК также требуется комплект полевых устройств AT32/ESP32 и Linux-камера.

  • Сетевые требования: доступность MQTT и REST между local/tenant/master уровнями, связность CANopen и RS485 в полевом контуре, поддержка автономной работы при временном отсутствии облачного канала.

  • Требования к ОС и зависимостям: Linux, PostgreSQL, Go 1.22 runtime, frontend на Vue 3.4.21/Vite 5.2.9, MQTT-брокер, dfu-util для AT32, ESP-IDF/idf.py для ESP32, ARM toolchain для AT32/ASR6601.

2. Порядок развертывания ПО «Зеленый робот» и ПАК#

  1. Подготовить backend/frontend стенд из ../ioot-pro-cabinet:

    • cd ../ioot-pro-cabinet

    • docker compose up -d --build

  2. Запустить frontend локально при необходимости стендовой проверки:

    • cd ../ioot-pro-cabinet/frontend-vue

    • ../scripts/node-env.sh npm install

    • ../scripts/node-env.sh npm run dev -- --host 127.0.0.1 --port 5173

  3. Проверить доступность runtime:

    • http://127.0.0.1:8080/swagger

    • GET /api/v1/app/context

    • GET /api/v1/modules/list

  4. Настроить MQTT/CANopen/RS485 и проверить локальный runtime на контроллере.

  5. Подключить embedded-компоненты из ../ioot-pro-embedded:

    • собрать/обновить прошивки AT32F415, ESP32-S3, ASR6601;

    • выполнить запись контроллеров по USB DFU или ST-Link.

  6. Выполнить smoke-проверку полного контура и оформить ввод в эксплуатацию.

3. Интеграция с ioot-pro-embedded#

  • Рабочий каталог:

    • cd ../ioot-pro-embedded

  • Сборка:

    • ./scripts/ioot_build_firmware.sh firmware-459-047-01

    • ./scripts/ioot_build_firmware.sh esp32

    • ./scripts/ioot_build_firmware.sh asr6601

  • Запись AT32 по USB DFU:

    • ./scripts/ioot_flash_at32_dfu.sh --build --profile firmware-459-047-01 --port /dev/cu.usbmodemXXXX

    • ./scripts/ioot_flash_at32_kernel_plc.sh --build --profile firmware-459-047-01 --plc-target wm_047 --port /dev/cu.usbmodemXXXX

  • Предварительные условия:

    • ARM_GCC_PATH должен указывать на каталог с arm-none-eabi-gcc;

    • idf.py должен быть доступен в shell для сборки ESP32-S3;

    • dfu-util должен быть установлен для сценариев AT32.

  • Проверка версии runtime:

    • app/context (scope runtime + policy.permissions/capabilities/guards),

    • modules/scheme (catalog_enrichment, runtime-конфигурация shell),

    • modules/list,

    • status/stream.

  • Для отладочного режима на стенде после обновления используется последовательный smoke-контур:

    • проверка CANopen/SDO,

    • проверка локального /api/v1/app/context,

    • проверка обработки команд,

    • проверка fallback поведения клиента: reconnect status/stream и резервный polling status/list.

4. Локальное и автономное развертывание#

  • Локальное развертывание допускается без постоянного облачного канала, если на объекте обеспечены Linux runtime, локальная БД, MQTT и связность с приборным контуром.

  • Для HMI-сценариев используется Linux-embedded сборка iP-11 на панели iT-21; такая поставка применяется как преднастроенный локальный контур оператора.

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

  • При обновлении объекта должны быть сохранены пользовательские настройки, список проектов и параметры запуска; перед заменой исполняемых файлов рекомендуется сформировать локальную резервную копию рабочего каталога.

  • После локального обновления обязательна проверка запуска продукта, открытия прикладного контура, получения телеметрии и исполнения базовых команд управления.

5. Откат и восстановление#

  • Порядок отката версии: остановить сервисы, восстановить предыдущий пакет релиза и совместимый дамп конфигурации/БД, выполнить smoke-проверку API и телеметрии.

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