# Требования

## 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`?