Решения

Решения#

D-001. Модель переключения отрасли#

  • Статус: РЕШЕНО (2026-03-05).

  • Принятое правило:

    • уровень облачного развертывания (master/tenant cloud) поддерживает несколько отраслей;

    • уровень площадки/шкафа (site/cabinet edge) использует только одну отрасль применения.

  • Техническая модель:

    • cloud: multi-industry registry и маршрутизация по industry_code;

    • edge: фиксированный industry_code на инсталляцию (без runtime-переключения).

  • Влияние: модель данных, права, UI-навигация, профиль деплоя.

D-002. Гранулярность отраслевых модулей#

  • Статус: РЕШЕНО (2026-03-05).

  • Принятое правило:

    • отрасль реализуется как набор модулей, а не монолит;

    • на конкретном хозяйстве/площадке включается только нужный поднабор;

    • каждый модуль имеет одну ключевую сущность (domain owner);

    • модуль может агрегировать/обогащать данные других модулей, но не забирает их ownership.

  • Пример (poultry):

    • industry.poultry.climate -> ключевая сущность climate_profile;

    • industry.poultry.flock -> ключевая сущность batch;

    • industry.poultry.feedwater -> ключевая сущность feedwater_snapshot;

    • industry.poultry.production -> ключевая сущность production_kpi.

D-003. Политика нормативов#

  • Статус: РЕШЕНО (2026-03-05).

  • Принятое правило:

    • нормативы хранятся в конфигурационных профилях (не в коде);

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

    • изменения профилей версионируются;

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

  • Обязательные функции:

    • export profile -> yaml;

    • import yaml -> validate -> draft;

    • publish version;

    • rollback to version.

  • Влияние: высокая скорость адаптации под генетику/регион/сезон, контролируемость изменений.

D-004. Контуры ответственности для тревог#

  • Статус: РЕШЕНО (2026-03-05).

  • Принятое правило: вариант B.

    • общий status остается единым системным контуром;

    • специализированные тревоги отрасли публикуются в отдельный industry alarm-bus.

  • Правило маршрутизации:

    • критические отраслевые тревоги дублируются в status как агрегированные события;

    • детальная диагностика и эскалация остаются в отраслевом контуре.

  • Влияние: сохраняется единая операторская видимость через status, при этом не теряется отраслевая детализация.

D-005. Приоритет отраслей после poultry#

  • Статус: РЕШЕНО (2026-03-05).

  • Принятое правило:

    • следующая отрасль после poultry — melioration (мелиорация).

  • Обязательный состав модулей melioration:

    • industry.melioration.field (ключевая сущность: field_water_balance);

    • industry.melioration.irrigation_machine (широкозахватные дождевальные машины);

    • industry.melioration.irrigation_drip (капельное/внутрипочвенное орошение);

    • industry.melioration.soil_moisture (мониторинг влажности почвы);

    • industry.melioration.weather (локальная метеостанция + внешние погодные интеграции).

  • Правило обогащения:

    • модуль field агрегирует данные об объеме и источнике воды:

      • от дождевальных машин;

      • от внутрипочвенного/капельного орошения;

      • от осадков (метеостанция и/или внешние сервисы).

D-006. Источник нормативов для poultry#

  • Статус: РЕШЕНО (2026-03-05).

  • Принятое правило:

    • источники из docs/industries/poultry/source-instructions.md считаются source-of-truth для MVP poultry;

    • обязательное baseline-ядро нормативов:

      • Ross-BroilerHandbook2018-RU.pdf;

      • ARBOR_Вентиляция.pdf;

      • xajseks-braun-rukovodstvo.pdf;

    • контроллерные документы (Climatepro, AC Touch, 99-94-0635) используются как source-of-truth по operational/alarm паттернам.

  • Влияние: KPI, алармы, алгоритмы климат-контроля и профили уставок.

D-007. Единица учета воды в melioration#

  • Статус: РЕШЕНО (2026-03-05).

  • Принятое правило:

    • использовать модель C: хранить обе единицы;

    • mm является primary-значением для агрономических расчетов и нормативов;

    • m3 хранится как derived/операционное значение (с привязкой к площади поля/зоны).

  • Влияние: совместимость отчетности, расчеты норм полива, сравнение источников.

D-008. Приоритет источника осадков в melioration#

  • Статус: РЕШЕНО (2026-03-05).

  • Принятое правило:

    • локальная метеостанция является primary-источником осадков;

    • внешний weather service используется как fallback при пропусках/недоступности локальной станции;

    • расхождения локального и внешнего источников используются для контроля аномалий.

  • Влияние: точность водного баланса и доверие операторов.

D-009. Режим управления поливом в MVP#

  • Статус: РЕШЕНО (2026-03-05).

  • Принятое правило:

    • базовый режим MVP: B (semi-auto, рекомендации + подтверждение оператором);

    • поддерживается переключение режима в A (advisory-only) и C (full-auto);

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

  • Ограничения безопасности:

    • режим C разрешается только при валидном профиле правил и исправных источниках телеметрии;

    • при потере критичных данных система должна автоматически деградировать из C в B или A по policy.

  • Влияние: безопасность внедрения, скорость реакции, ответственность эксплуатации.

D-010. Приоритет отрасли после melioration#

  • Статус: РЕШЕНО (2026-03-05).

  • Принятое правило:

    • следующая отрасль после melioration — swine (свиноводство).

  • Обоснование:

    • есть пересечение по климат-контролю и тревогам с уже покрытыми платформенными контрактами;

    • позволяет переиспользовать паттерны модульной декомпозиции (climate, feeding, water, production, biosecurity);

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

  • Влияние:

    • запускается пакет docs/industries/swine как следующий отраслевой контур;

    • задачи и критерии приемки по swine ведутся в отдельном отраслевом backlog.

D-011. Представление poultry-модулей во frontend#

  • Статус: РЕШЕНО (2026-03-06).

  • Принятое правило:

    • poultry во frontend представляется как единый workspace Птицеводство;

    • внутри workspace сохраняются изолированные submodule-экраны (climate, flock, feedwater, production, alarms);

    • cloud/tenant использует overview dashboard как primary-вход;

    • edge-single использует тот же poultry-dashboard как основной fullscreen cards-экран для 10» HMI;

    • отдельный canvas-режим не используется;

    • primary drill-down выполняется через карточки dashboard и переход в модульные детали.

  • Ограничения:

    • poultry-profiles/* не выводятся как основной пользовательский модуль;

    • состав submodule-ов остается управляемым через install state и site-policy.

  • Влияние:

    • frontend shell получает workspace-level навигацию;

    • edge-контур получает уплотненный fullscreen cards-layout без отдельной второй визуальной модели.

D-012. Пакет weighbridge в published industry layer#

  • Статус: РЕШЕНО (2026-03-12).

  • Принятое правило:

    • weighbridge фиксируется как отдельный отраслевой пакет published-слоя, а не остается только в docs/featurelists/* и docs/company/*;

    • пакет синхронизируется с reference runtime ../ioot-pro-cabinet, где уже заведены модули weighbridge-session, weighbridge-identity, weighbridge-media, weighbridge-alarms с industry_code=weighbridge;

    • edge ANPR/device контур для этого пакета ведется в отдельном engineering repo ../ioot-pro-anpr.

  • Обоснование:

    • работа по беспилотным весам уже идет как отдельный runtime-контур, поэтому отсутствие пакета в docs/industries/* искажает фактический срез платформы;

    • published-контур уже содержит прикладной смысл весов в featurelists и company, но ему не хватало явного отраслевого пакета.

  • Влияние:

    • в green-robot появляется отдельный пакет docs/industries/weighbridge;

    • отраслевой обзор, project map и registration-facing runtime registry должны учитывать weighbridge как активную часть платформы.

Содержание