Требования

1. Функциональные требования (черновик)

• Полевые устройства IOOT PRO должны работать без Linux и состоять из AT32 (real-time + CANopen) и ESP32 (MQTT transport).

• AT32 должен выполнять технологический процесс в реальном времени и обмен PDO/SDO по CANopen.

• ESP32 должен быть связан с AT32 по UART.

• ESP32 должен передавать данные в MQTT-брокер локального Linux-контроллера ПО «Зеленый робот».

• Данные PDO из CAN-сегмента должны транслироваться в MQTT-топики.

• Команды из MQTT должны преобразовываться в SDO-команды для AT32 и других CANopen-устройств.

• Один локальный контроллер должен обслуживать один конкретный объект.

• Локальный контроллер ПО «Зеленый робот» должен иметь CAN-интерфейс и возможность direct SDO/PDO работы с CANopen сетью.

• Локальный контроллер ПО «Зеленый робот» с 10» экраном и аккумулятором должен поддерживать RFID MIFARE считыватель карт для идентификации пользователя.

• Локальный контроллер ПО «Зеленый робот» должен применять ролевые права доступа к операциям на основании идентификации по RFID MIFARE.

• Локальный контроллер ПО «Зеленый робот» должен содержать локальный MQTT-брокер для приема данных от ESP32 transport-уровня.

• Локальный контроллер ПО «Зеленый робот» должен выполнять супервизорное управление технологическими сценариями и бизнес-процессами объекта.

• Локальный контроллер ПО «Зеленый робот» должен формировать и вносить уставки по технологической цепочке через SDO в CANopen.

• Локальный Linux-контроллер не должен брать на себя критичные hard real-time контуры, закрепленные за AT32.

• Обработка и регулирование технологических параметров должны выполняться на runtime AT32 устройствах.

• Контроллер ПО «Зеленый робот» должен контролировать, сравнивать и мониторить процесс по данным PDO (CAN) и MQTT pub.

• Робот должен передавать телеметрию в backend в реальном времени.

• Оператор должен иметь возможность отправлять управляющие команды.

• Система должна хранить историю телеметрии.

• Платформа должна поддерживать удаленное обновление ПО устройства.

• Должна быть базовая диагностика состояния узлов.

• REST API должен быть описан и публиковаться через Swagger/OpenAPI.

• OpenAPI должен быть source-of-truth для API-контракта с синхронизацией runtime и документации.

• Глобальный UI-контракт данных: GET /api/v1/<resource>/list + GET /api/v1/<resource>/scheme для таблиц, карточек и форм.

• UI-навигация должна строиться backend-driven через API-каталоги модулей/папок/меню.

• Backend-каталог модулей должен поддерживать параметры отображения display_module, show_filters, module_view и расширяться без слома базового каркаса.

• Frontend reference runtime должен реализовываться на Vue 3 + Vite (TypeScript допускается как релизный профиль).

• UI должен быть mobile-oriented (mobile-first, адаптивный интерфейс для телефона/планшета/десктопа).

• Модули должны отображаться в основном окне приложения в виде карточек.

• Карточка модуля должна поддерживать 3 состояния:

  • свёрнутое (минимальный виджет),

  • развернутое (нормальный виджет),

  • полноэкранное (режим работы в карточке).

• По выбранному объекту карточки открывается popup Infobar и содержит инструменты операций с объектом.

• Справочник, настройки и дополнительные элементы должны находиться в burger-меню.

• Кнопка выхода должна оставаться в topbar вне burger-меню, чтобы сценарий logout не зависел от прав на доступ к самому меню.

• Отдельные fullscreen представления (карты, пульт) должны вызываться кнопками быстрого доступа в правом верхнем углу интерфейса.

• Табличный режим должен поддерживать smart-функции (drag-and-drop колонок, сортировка, глобальный поиск, smart-фильтры).

• Табличный режим должен поддерживать двунаправленную lazy-пагинацию с оконной выгрузкой.

• Табличный режим должен поддерживать серверные и пользовательские пресеты фильтров.

• Frontend должен передавать route-context заголовки X-Route-Path, X-Route-Module, X-Route-Filter.

• Frontend должен передавать build-context заголовки X-Client-Version, X-Client-Build-Time.

• UI runtime должен использовать config-driven bootstrap с обогащением модулей из backend-каталога.

• Shell runtime должен поддерживать versioned export/import/rollback profile для theme, dashboard layout, quick modules, ui-access с изоляцией по tenant/site/industry.

• Для pilot-контуров должны поддерживаться готовые shell presets как минимум для cloud-multi и edge-single.

• Pilot handover должен поддерживать evidence bundle с app/context, ready, modules, site-policy, shell-profile, security-log.

• Pilot release-gate должен включать автоматизированный rollback/restore drill с возвратом baseline runtime без расхождения modules_state/site-policy/shell-profile.

• Следующий эксплуатационный этап должен обеспечить retention pilot-артефактов и observability по /ready, tenant-master-sync lag, status heartbeat, Postgres/NanoMQ.

• Для pilot-контура должен поддерживаться единый sign-off bundle (inspect/apply/smoke/evidence/rollback/archive) и архив площадки.

• Для multi-site эксплуатации должен вестись rollout registry по площадкам и production waves с привязкой к последнему sign-off и promotion-check.

• Operational incident должен передаваться как единый handover package с pilot-summary, ready, sign-off reference и rollback decision.

• Production rollout должен ссылаться только на immutable versioned artifacts (bootstrap_ref, signoff_ref, promotion_ref, build_commit, content_hash) без mutable aliases latest/current/tmp.

• i18n-политика: русский как source-locale, синхронизация ключей на поддерживаемые языки.

• PWA-подход должен поддерживаться как базовая опция (service worker, auto-update, offline-ready), с возможностью отключения по политике релиза.

• Платформа должна поддерживать MQTT broker/client для телеметрии и событий.

• Контроллер должен поддерживать CANopen для связи с датчиками и блоками управления.

• Контроллер должен поддерживать RS485 Modbus RTU для интеграции сторонних счетчиков и устройств.

• Базовые промышленные интеграции текущего контура: CANopen и RS485 Modbus RTU.

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

• В cloud-контуре должен поддерживаться multi-industry режим, в site/cabinet edge-контуре — single-industry режим.

• Для отрасли melioration учет воды должен поддерживать mm как primary и m3 как derived значение.

• Для осадков в melioration локальная метеостанция должна быть primary-источником, внешний weather service — fallback и контур контроля аномалий.

• Режим управления поливом в MVP должен использовать B (semi-auto) по умолчанию с поддержкой переключения в A и C по policy.

• Протоколы ISOBUS/J1939/BACnet не включаются в текущий контур и переносятся на этап после MVP.

• Платформа должна поддерживать два контура подготовки продуктовых пакетов: ПО «Зеленый робот» и ПАК «IOOT PRO».

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

• Для ПАК должны вестись версии embedded-прошивок и Linux-embedded сборок контроллера/камеры.

• Облачный контур клиента должен синхронизироваться одновременно с множеством локальных контроллеров.

• Для каждого клиента (хозяйства) должен развертываться отдельный cloud-контейнер с tenant-контроллером.

• Каждый tenant-контейнер должен иметь собственный MQTT-брокер для обмена с локальными контроллерами.

• Tenant-контейнеры должны обмениваться с master-контроллером только ограниченным набором служебных данных.

• Master-контроллер должен использовать MQTT-брокер NanoMQ.

• Master-контроллер должен управлять подписками клиентов.

• Master-контроллер должен предоставлять сервисы аналитики и данных по режимам/методикам.

• Локальный и облачный контуры должны использовать единое приложение ПО «Зеленый робот» в разных режимах развертывания (edge/cloud).

2. Нефункциональные требования (черновик)

• Надежность канала связи при кратковременных сбоях.

• Расширяемость для новых типов сенсоров/приводов.

• Безопасность: аутентификация устройств и пользователей.

• Наблюдаемость: логи, метрики, алерты.

• Документируемость API и протоколов.

• Требования к MQTT: устойчивое переподключение и delivery-гарантии (QoS по профилю нагрузки).

• Требования к промышленным интерфейсам: обработка ошибок шины CANopen/RS485 и таймаутов опроса.

• Требования к мосту AT32 <-> ESP32: гарантированная и проверяемая трансляция PDO -> MQTT и MQTT -> SDO.

• Требования к direct CAN контуру: гарантированная доставка SDO уставок, контроль подтверждений и повтор при отказе.

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

• После восстановления связи должна выполняться консистентная синхронизация состояния с облаком.

• Tenant-контейнеры должны быть логически изолированы друг от друга (данные и каналы управления).

• Обмен tenant-контейнеров с master-контроллером должен быть ограничен утвержденным набором метрик/событий и обновлений.

• Масштабирование master-контроллера и NanoMQ должно поддерживать рост числа tenant-контейнеров без деградации SLA.

• Документация проекта должна поддерживаться в актуальном состоянии и быть трассируемой до требований/релизов.

• Комплект документов должен покрывать требования подготовки продуктовых пакетов и аудита изменений.

• Перед релизом UI обязателен quality-gate: i18n checks, тесты, сборка и smoke основных endpoint-ов.

• Перед pilot rollout обязателен acceptance smoke для shell permissions, quick modules, fullscreen flow и shell-profile portability.

3. Открытые вопросы

• Какие условия эксплуатации (улица/помещение/производство)?

• Какой допустимый уровень задержки команд?

• Какие требования по автономности питания?

• Какие ограничения по стоимости BOM для MVP?

• Нужен ли офлайн-режим при потере сети?

• Какой точный whitelist данных разрешен для обмена Tenant -> Master?

• Какие данные запрещено передавать в master-контур по политике клиента?

• Какой SLA синхронизации и доставки обновлений между master, tenant и local слоями?

• Как финально фиксируется совместимость CRUD-контракта (/api/v1/<resource> и /{id}) относительно приоритетного list/scheme?

• Какой целевой профиль модульного Pinia-store принимается для ПО «Зеленый робот» (границы store-срезов, ответственность, правила взаимодействия)?

• Какой минимальный обязательный состав backend-каркаса Go фиксируем как стандарт (env/validation/middleware/shutdown)?

• В каком релизе и с каким контрактом вводятся endpoint-ы /healthz, /readyz, /version, учитывая что фактический baseline сейчас использует GET /health?