Зеленый робот

Программная документация

Справочник программных компонентов

Модульное интегрированное ПО «Зеленый робот»

Проектная редакция · GR-FP-1.0

D03 · АСУП.466459.100-01 13 03
Редакция 2.0 · 13.09.2026

Справочник программных компонентов ​

Документ

D03 · АСУП.466459.100-01 13 03

Редакция

2.0 · Проектная редакция

Применимость

Функциональный профиль GR-FP-1.0

Продукт

Модульное интегрированное ПО «Зеленый робот»

Обозначения и сокращения раскрыты в словаре этой книги.

1. Как пользоваться справочником ​

Справочник раскрывает компоненты M01–M22 функционального профиля GR-FP-1.0. Для каждого указаны назначение, артефакты, входы, параметры, состояния, работа и восстановление. Точные версии выбираются по D13. Имена параметров в кодовом начертании относятся к названному интерфейсу или конфигурационному формату; строки с обычными названиями задают поля профиля установки.

Изменение параметров выполняется через проверяемую редакцию: исходное значение → подготовка → проверка → применение → readback. Пользователь выбирает объект и роль до начала операции. Общие процедуры находятся в D04–D09; раздел компонента уточняет его условия и результат.

Рисунок D03.1 — Группы компонентов и общий путь интеграции. Программный профиль выбирает необходимые артефакты из каталога.

2. M01 — Прикладная логика контроллера ​

D03-M01. M01 — вход, обработка, результат и состояния.

2.1. Назначение и артефакт ​

M01 выполняет прикладной цикл технологического объекта: считывает входы, оценивает условия, рассчитывает выходы и формирует события. Артефакт содержит PLC-программу для совместимой среды M02, сведения об ABI и профиль сигналов. При совмещённой поставке образа ведомость сохраняет версии среды и прикладной программы отдельно.

Входы — измерения, дискретные сигналы, уставки и разрешённые команды. Выходы — требуемое состояние исполнительных сигналов, результат команды, блокировки и диагностика. Локальная логика обеспечивает согласованный приоритет защит в каждом цикле.

2.2. Параметры и состояния ​

Цикл различает инициализацию, готовность, технологические режимы, активную блокировку и восстановление. Набор предметных режимов задаётся алгоритмом. Каждый переход имеет условие, действие и наблюдаемое подтверждение.

2.3. Установка и работа ​

Наладчик сопоставляет алгоритм, ABI среды, карту сигналов и профиль объекта. В M17 выбирает артефакт и исходное состояние, проверяет план загрузки, применяет программу и читает её идентичность. Затем выполняет наблюдение входов и разрешённый контрольный цикл по D05. Оператор задаёт режим и уставки через профильное приложение; локальная логика проверяет допуск каждого воздействия.

При блокировке пользователь читает код, входное условие и время. После устранения причины выполняет предусмотренный профилем сброс и проверяет состояние выходов. Восстановление программы использует совместимый предыдущий артефакт и соответствующую редакцию параметров. Испытания E03/E04 воспроизводят цикл и отказы источников; физический профиль проверяет соответствующие свойства входов, выходов и времени.

3. M02 — Среда CANopen и загрузка L0 ​

D03-M02. M02 — вход, обработка, результат и состояния.

3.1. Функции и состав ​

M02 предоставляет среду исполнения L0, CANopen, словарь объектов, загрузку прикладной программы и восстановление образа. Поставка различает загрузчик, ядро и PLC payload, связывает их с конкретной MCU-целью, картой памяти и ABI. Профиль AT32F415 является именованной целью; каждый иной part требует собственной записи совместимости.

Сервисные обращения используют SDO; циклические данные передаются PDO; управление состоянием узла использует NMT; аварийное событие — EMCY; наблюдение присутствия — heartbeat. Индексы и типы объектов берутся из словаря выбранной редакции.

3.2. Настройка обмена ​

NMT-состояния отображаются как initialization, pre-operational, operational и stopped. Пользователь проверяет состояние перед сервисной операцией. Статус загрузки имеет отдельные шаги подготовки, передачи, проверки, активации и readback.

3.3. Загрузка и восстановление ​

В карточке устройства выберите AT32-цель и способ загрузки из паспорта. Проверьте идентичность, размер, digest и совместимость областей. Подготовьте исходное состояние процесса, примените план M17 и дождитесь версии выполняемой программы. Сохраните результат проверки heartbeat и контрольного чтения объектов.

При SDO-ошибке сопоставьте abort code, index/subindex, тип и длину запроса. При потере heartbeat проверьте питание программного узла в выбранной среде, канал и NMT-состояние. Прерванную загрузку продолжайте по сохранённому состоянию bootguard; предыдущий образ активируется штатным способом профиля. D16 проверяет допустимые и ошибочные объекты, порядок состояний, загрузку и восстановление.

4. M03 — Среда исполнения Runtime ​

D03-M03. M03 — вход, обработка, результат и состояния.

4.1. Службы и артефакты ​

Runtime предоставляет Linux L1 локальный HTTP API, конфигурацию, журнал, CAN/MQTT-службы и размещение приложений. Поставка включает исполняемый файл ioot-l1-runtime, конфигурационные схемы и совместимые манифесты. Приложения устанавливаются как отдельные frontend artifacts с регистрацией.

Композиция ioot.l1-app-composition/1.0 ссылается на манифесты и каталоги артефактов. ioot.l1-app-manifest/1.0 задаёт ID, SemVer, источник, digest, маршруты, регистрацию, health и требования совместимости. При проверке учитываются абсолютные пути и расположение манифеста отдельно от дерева артефакта; состав ограничен 32 приложениями.

4.2. Основные параметры ​

Именованные переменные и пути относятся к Linux-профилю Runtime. Установочный профиль может задавать другие адреса и каталоги, сохраняя их в плане. Права файлов выдаются сервисной учётной записи; решения авторизации записываются в предусмотренный журнал.

4.3. Проверка и эксплуатация ​

Перед запуском выполните ioot-l1-runtime --check-config либо одноимённую проверку плана M17. Она проверяет конфигурацию, манифесты, регистрацию и совместимость. После запуска откройте /livez, /readyz, затем / или /kiosk. Перечень приложений доступен через GET /api/v1/platform/apps; выбранное приложение — по /apps/<appId>/.

При изменении композиции Runtime проверяет полный кандидат и атомарно переключает active/previous. Пользователь сверяет список, версии, health и маршруты. Если приложение возвращает ошибку, сохраните его ID и диагностику; проверьте собственный API и совместимость регистрации. Восстановление возвращает согласованную предыдущую композицию через предусмотренный rollback. E01 проверяет фактический Runtime, два приложения, смену состава, разрыв транспорта и перезапуск.

5. M04 — Коммуникационное ПО ESP32 ​

D03-M04. M04 — вход, обработка, результат и состояния.

5.1. Назначение и данные ​

M04 связывает программный узел с CAN и защищённым MQTT-контуром, хранит эффективную конфигурацию и выполняет программное обслуживание. Артефакт привязан к конкретному SoC, SDK, board profile и карте flash. В составе платы ESP32 и AT32 сохраняют отдельные выполняемые версии, состояние присутствия и доступность чтения.

Конфигурация объекта поступает от её владельца с редакцией и digest. Устройство применяет snapshot и возвращает квитанцию. Последовательность изменения: validate → stage → apply → readback → commit. Поле base_revision связывает предложение с исходным состоянием.

5.2. Параметры профиля ​

Строгий YAML-профиль устройства использует mappings, строки UTF-8, целые числа и boolean; размер — до 8192 байт, отступ — два пробела. Состав полей задаётся схемой целевого профиля. Материалы доступа передаются отдельным защищённым каналом по ссылкам на секреты.

5.3. Присоединение и обслуживание ​

Наладчик присоединяет устройство к площадке, проверяет время и доверие, получает конфигурацию объекта и подтверждает readback. Для замены устройства выбирается тот же объект и допустимая новая идентичность; эффективная конфигурация восстанавливается из закреплённой редакции.

При конфликте базы прочитайте фактическую редакцию и подготовьте новый план. При отказе TLS проверьте время, цепочку доверия и область площадки. После применения сети или транспортных параметров управляемый перезапуск загружает единый snapshot. Восстановление использует предыдущую конфигурацию и ограниченный rollback. E02 фиксирует точный исполняемый образ или portable artifact и применённые модели TWAI, NVS, USB и сети.

6. M05 — ПО панели iO-5122 ​

D03-M05. M05 — вход, обработка, результат и состояния.

6.1. Исполнение и экранные функции ​

ПО панели предназначено для локального представления объекта и разрешённых экранных действий. Профиль iO-5122 использует ESP32-S3, дисплей 480×480, сенсорный ввод, LVGL v9 и совместимый ESP-IDF 6.x. Паспорт выпуска конкретизирует SDK, BSP, память и программные версии.

Панель показывает режим, измерения, качество связи, паспорт, события и результаты действия. Программный проект связывает страницы, элементы, источники данных и операции с определённым объектом. Журнал использует ограниченное окно и переход к текущим событиям. Для Pivot панель участвует в вычислении по согласованному расчётному профилю.

6.2. Настраиваемые данные ​

6.3. Использование и восстановление ​

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

При stale-сигнале проверяется источник и время; при ошибке проекта — его схема и совместимость Runtime панели. После восстановления носителя или переустановки проекта выполняются чтение идентичности, проверка связи и контрольный экранный сценарий. Виртуальная проверка указывает фактически моделируемые display/touch и периферию; аппаратная стадия подтверждает свойства реальной панели.

7. M06 — Приложение Pivot ​

D03-M06. M06 — вход, обработка, результат и состояния.

7.1. Функции и артефакты ​

Pivot использует паспорт машины, рассчитывает параметры орошения и представляет оперативный сценарий. Frontend app-pivot размещается общим хостом. Расчётный профиль ioot.irrigation-calculation-profile.v1 поставляется с входной схемой, контрольными векторами и совместимыми вычислителями. Паспорт, расчётный профиль и оперативный сценарий имеют отдельные редакции.

7.2. Расчётные параметры ​

Первые семь полей относятся к паспорту; остальные — к сценарию. Значения — JSON-safe integers. Расчёт использует проверяемые промежуточные значения и установленное округление публичного результата. Диапазоны и геометрические условия задаёт точная схема профиля.

7.3. Работа с расчётом ​

Откройте Pivot и прочитайте паспорт объекта. Создайте сценарий, задайте сектор, норму и время, затем выполните расчёт. Проверьте площадь, расход, время прохода, требуемый таймер и достижимую глубину. Сохраните редакцию сценария перед действием.

Результат содержит passportHash, profileRevision, profileHash, vectorSetHash, scenarioRevision и resultHash. Расчётно-зависимое действие использует согласованные digest всех установленных участников: Dispatcher, панель ESP32-S3 и Linux HMI при её наличии в составе. При ошибке геометрии или диапазона исправьте указанное поле; при расхождении hash восстановите согласованный паспорт/профиль и повторите расчёт. Контрольные примеры и модель полива приведены в D15/D16.

8. M07 — Приложение Visio ​

D03-M07. M07 — вход, обработка, результат и состояния.

8.1. Назначение и интерфейс ​

app-visio показывает наблюдаемый результат производственного машинного зрения и текстовой аналитики. Один frontend artifact работает через same-origin API хоста. UI располагается по /apps/app-visio, API — /api/v1/apps/app-visio; snapshot имеет схему ioot.l1.app-visio.snapshot.v2, поток SSE — /api/v1/apps/app-visio/events.

Приложение принимает снимок и обновления, проверяет их схему и представляет результат. Идентичность объекта определяется серверным контекстом. Версия frontend, регистрация 2.0 и совместимость Runtime указываются в манифесте поставки.

8.2. Состояния и данные ​

Режим IMAGE_SURVEY содержит изображение, поля обследования и подтверждение исполнения модели. TEXT_RESPONSE содержит текстовый результат с обозначением предварительного потока или завершённого ответа. Профиль входа задаёт допустимые форматы, размер, срок ожидания и критерии качества обработки.

8.3. Работа и восстановление ​

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

При повреждённом входе проверяется формат и исходный digest; при тайм-ауте — состояние задания обработки у его владельца. Повтор обработки выполняется предусмотренным интерфейсом задания с новым связанным ID. E04 использует именованный набор производственных изображений; D16 проверяет состояния, происхождение, ошибки декодирования и восстановление потока.

9. M08 — Оболочка операторских приложений ​

D03-M08. M08 — вход, обработка, результат и состояния.

9.1. Назначение и регистрация ​

Оболочка формирует общий операторский интерфейс: список приложений, страницы, контекст объекта, настройки и события. Артефакт хоста и его версия связываются с поддерживаемой схемой регистрации. Приложение поставляет декларацию ioot.hmi-app-registration/2.0; хост проверяет её до включения приложения в композицию.

9.2. Контекст и работа ​

Хост получает объект, права и доступные приложения от серверного владельца. При выборе приложения пользователь видит тот же объект и применимую конфигурацию. Локальный экран и L2 popup используют один frontend с соответствующим host adapter. Переходы сохраняют выбранный объект, страницу и состояние навигации в границах сеанса.

Наладчик устанавливает host и приложения через композицию Runtime. После проверки регистрации открывает каждую страницу, действие и настройку в разрешённой роли. При коллизии маршрута или несовместимой схеме исправляется кандидат композиции. При ошибке отдельного приложения оболочка сохраняет доступ к общей навигации и диагностике; восстановление приложения выполняется по его версии и health.

Для документации хост предоставляет воспроизводимые сценарии нормального состояния, ожидания, ограничения прав, ошибки и восстановления. Каждому снимку сопоставляются маршрут, объект, фикстура и версия. Длительная история проверяется с ограничением DOM и сохранением позиции читателя.

10. M09 — Библиотека элементов HMI ​

D03-M09. M09 — вход, обработка, результат и состояния.

10.1. Программная форма ​

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

10.2. Правила применения ​

Потребляющий интерфейс передаёт элементу данные и обработчик действия. Серверный владелец определяет полномочия и состояние операции; элемент показывает их и отправляет предусмотренный запрос. Цвет дополняется текстом, формой или маркером. Число отображается с единицей и подходящей точностью; обновление сохраняет читаемую компоновку.

При обновлении библиотеки разработчик проверяет используемые API компонентов и визуальные состояния потребителя. Контрольные сцены включают длинные подписи, крайние значения, локализованные даты, ограниченные права, ошибку и восстановление. Для журнала проверяются 24–72 часа логической истории, конечное окно, изменение ширины и непрерывный поток.

Восстановление выполняется возвратом совместимого frontend artifact целиком. Оператор получает версию приложения; версия библиотеки доступна в его программной ведомости. Снимки отдельных библиотечных сцен иллюстрируют свойства элемента; рабочие процедуры книги используют соответствующий контекст приложения.

11. M10 — Сервис обмена Brocker ​

D03-M10. M10 — вход, обработка, результат и состояния.

11.1. Назначение и связи ​

Brocker предоставляет защищённый MQTT 5 транспорт площадки, присоединение endpoint и диагностические квитанции. Он связывает идентичности, доверие, права публикации/подписки и сетевые ограничения. Предметные команды обрабатываются их прикладными владельцами.

Поставка содержит сервис, строгую JSON-конфигурацию и совместимый профиль брокера. Конфигурационный файл задаётся через BROCKER_CONFIG; группы http, mqtt, transport обязательны. --check-config проверяет структуру и лимиты до запуска сетевого обмена.

11.2. Параметры площадки ​

Численные лимиты закрепляются для всего канала. Базовый профиль Mosquitto задаёт пакет 256 КиБ, inflight 64, очередь 2048 сообщений и 64 МиБ; профиль Runtime и клиента согласуется с этими границами. При выборе другого профиля паспорт указывает новые значения и результаты нагрузочного метода.

11.3. Установка и диагностика ​

В M17 выберите пакет брокера, площадку, listener, ссылки на доверенные материалы и лимиты. Выполните проверку плана. После установки проверьте подключение служебных участников и разрешённого endpoint, затем обмен контрольным сообщением. Присоединение использует отдельный процесс выдачи эксплуатационной идентичности.

При TLS-ошибке проверьте время, цепочку, имя и отзыв; при отказе операции — principal, область topic и правило доступа; при перегрузке — размер, очередь и скорость. Восстановление конфигурации применяет предыдущую редакцию с проверкой клиентского reconnect. D16 проверяет допустимого участника, чужую площадку, отзыв, превышение лимита и восстановление канала.

12. M11 — Dispatcher ​

D03-M11. M11 — вход, обработка, результат и состояния.

12.1. Функции и состояние ​

Dispatcher предоставляет операторский интерфейс площадки и устойчивое прикладное состояние L2. Он хранит объекты, конфигурационные редакции, команды, результаты и оперативную историю. Карта, список и карточка объекта открывают отраслевое приложение в выбранном контексте. Интеграционные профили задают входы от различных L1-исполнений.

Данные устройств включают идентичность, связь, качество, время и выполняемые версии. В карточке платы ESP32 и AT32 представлены отдельными строками; источник версии указывает package metadata или фактический readback. Программный состав сопоставляется с паспортом объекта.

12.2. Параметры и операции ​

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

12.3. Ввод и восстановление ​

При первоначальном вводе создайте объект и свяжите endpoint, конфигурацию и приложение. Выполните импорт или редактирование YAML через проверку схемы и исходной редакции. После применения сопоставьте квитанцию и readback. Задание обслуживания M17 связывается по ID, а оперативная команда сохраняется у Dispatcher.

При конфликте редакций прочитайте текущую базу и подготовьте новое изменение. При разрыве потока интерфейс восстанавливает снимок и курсор. При повторной доставке команды используется её устойчивый идентификатор. Для восстановления базы остановите согласованные записи, примените совместимую копию и проверьте объекты, команды и поток. D16 охватывает прерывание на каждом этапе и разграничение прав.

13. M12 — Auth ​

D03-M12. M12 — вход, обработка, результат и состояния.

13.1. Функции и данные ​

Auth обеспечивает идентичность пользователей, факторы входа, сессии и решения по доступу. Идентичность, полномочия, challenge и сессия имеют собственные записи и сроки. Первоначальная установка связывает единственную system root identity с защищённым bootstrap-материалом. Последующие административные операции используют устойчивое состояние Auth.

13.2. Параметры и диагностика ​

Старт применяет миграции транзакционно и проверяет их контрольные суммы. Базовый runtime ограничивает пул восемью соединениями, ожидание соединения — 200 мс, busy timeout — 500 мс. Профиль нагрузки учитывает эти значения и ограничения входа.

13.3. Работа администратора ​

При первом запуске подготовьте защищённый материал исходной идентичности, выполните начальный вход и проверьте полномочия. Создайте пользователей и области, выдайте минимальный набор действий по должностной роли. Для обслуживания отдельно задайте права планирования, применения, обновления, восстановления и запуска испытаний.

Ответ 401 требует проверки сессии, 409 — актуальной редакции записи, 503 — состояния сервиса и БД. При отзыве сессии пользователь проходит новый вход по действующему правилу. Восстановление доступа использует штатную копию идентичностей, политик и миграционного состояния. Журнал содержит статус, длительность и фиксированную причину; экспорт использует идентификаторы решений. D16 проверяет первоначальный и повторный ввод, конфликт root binding, отказ прав, отзыв и восстановление.

14. M13 — Notify ​

D03-M13. M13 — вход, обработка, результат и состояния.

14.1. Назначение и цикл доставки ​

Notify принимает уведомление производственного или сервисного профиля, выбирает маршрут и доставляет сообщение получателю. Исходное событие, запрос доставки и квитанция канала связаны идентификаторами. Политика определяет приоритет, срок, повтор, канал и адресата.

14.2. Настройка и использование ​

Администратор задаёт каналы, доверенные материалы, маршруты событий и получателей. Затем отправляет контрольное сообщение и проверяет квитанцию. В эксплуатации оператор открывает уведомление, видит объект и время, переходит к исходной карточке и проверяет технологическое состояние.

Доставка различает ожидание, передачу, подтверждение, повторяемый отказ, окончательный отказ и истечение срока. При временном отказе применяется политика повторов; при постоянном — проверяются адресат, канал и причина. Повтор исходного события обрабатывается по ID. Устойчивый журнал доставки позволяет восстановить незавершённые операции после restart.

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

15. M14 — Производственная аналитика ​

D03-M14. M14 — вход, обработка, результат и состояния.

15.1. Профиль обработки ​

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

Программная форма включает runtime обработки, декларативный профиль и закреплённые артефакты исполнителей. Профиль ioot.bot-application-profile/1.0 и задание ioot.bot-workflow-job/1.0 используются в выбранной области производственной аналитики. Регистрация компонента в поставке задаёт конкретный разрешённый аналитический сценарий.

15.2. Параметры задания ​

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

15.3. Использование и восстановление ​

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

При нарушении входной схемы исправьте указанный набор. При исчерпании ресурса выберите меньший период либо профиль с утверждёнными лимитами. При расхождении digest восстановите согласованный набор артефактов. Устойчивое состояние связывает повтор с исходным job ID. Испытание использует фиксированные производственные данные, ожидаемую структуру вывода, правила происхождения и сценарии отказа исполнителя.

16. M15 — Производственные данные L3 ​

D03-M15. M15 — вход, обработка, результат и состояния.

16.1. Назначение и происхождение ​

M15 формирует производные представления технологических данных: поиск, временную историю, сводки и ссылки на артефакты. Источник оперативного факта сохраняется у соответствующего владельца L0–L2. Производная запись содержит исходный ID, время, digest и версию преобразования, что позволяет проверить и перестроить представление.

Программная поставка включает сервер, хранилище метаданных, индекс и предусмотренные профилем файловые коллекции. Доступ ограничивается субъектом и областью производственных данных. Интерфейс оборудования показывает связанные asset ID, версии и состояние; графические действия обслуживания передаются основному API M17.

16.2. Настраиваемые свойства ​

16.3. Работа и восстановление ​

Администратор подключает разрешённый источник и проверяет начальную синхронизацию. Пользователь выбирает объект, период и тип записи, применяет фильтр, открывает результат и переходит к источнику. При просмотре файла сервер проверяет размер, digest и право доступа. Экспорт включает редакцию выборки и происхождение данных.

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

Испытание D16 проверяет повтор события, разрыв потока, ограничение доступа, целостность артефакта и восстановление индекса. Отчёт фиксирует диапазон исходных данных и версию преобразования.

17. M16 — Agent ​

D03-M16. M16 — вход, обработка, результат и состояния.

17.1. Функции и полномочия ​

Agent выполняет ограниченное обслуживание программного узла и синхронизацию артефактов. Роль server или client задаётся профилем размещения. Операции получают идентификатор, тип, срок и область разрешения. Основные типы — status, sync, tunnel.open, tunnel.close, contracts.audit, network.apply, network.confirm, network.rollback.

Артефакт включает исполняемый сервис и валидируемую конфигурацию. Команды проходят состояния received → accepted → executing → completed | failed; отклонённый запрос завершается rejected. Результат содержит фиксированный код, время и связь с исходной операцией.

17.2. Параметры обслуживания ​

17.3. Эксплуатация и восстановление ​

Администратор выбирает узел, читает health и фактический состав, затем запускает разрешённую операцию через M17 или общий командный интерфейс. Для артефакта проверяются размер и SHA-256; результат синхронизации указывает объект хранения и исходный digest. При ошибке исходный файл сохраняется по политике.

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

При restart исполнитель сопоставляет устойчивое задание и фактические данные. Повтор командного ID обрабатывается идемпотентно. D16 проверяет истечение TTL, повреждённый артефакт, повтор, прерывание staging и восстановление сети. Журналы показывают безопасные метаданные операции и ссылки на секреты.

18. M17 — Развёртывание и обновление ​

D03-M17. M17 — вход, обработка, результат и состояния.

18.1. Назначение ​

M17 управляет программным составом из установленного L3. Пользователь выбирает профиль, задаёт параметры и запускает проверяемое задание установки, настройки, обновления или восстановления. Модуль хранит план и состояние его исполнения. Адаптеры компонентов выполняют типизированные шаги и возвращают квитанции.

Поставка включает координатор заданий, каталог профилей, схемы X13 и адаптеры. Графическое представление показывает основные операции, параметры, ход, отклонения и итог. Командный интерфейс обращается к тому же контракту задания.

18.2. Данные плана и задания ​

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

18.3. Операторский маршрут ​

Для подготовленного профиля после входа выполните четыре подтверждения:

1. Выберите карточку профиля.
2. Нажмите Проверить план и изучите результат.
3. Нажмите Развернуть; наблюдайте автоматические шаги.
4. После успешных проверок нажмите Завершить ввод.

Первичная подготовка включает параметры площадки, доверие, идентичности и каталог пакетов. D04 раскрывает её отдельно и показывает установку брокера, Runtime, приложений, ESP32/AT32 и служб. Задание переходит через подготовку, проверку, ожидание подтверждения, выполнение и конечное состояние. Возможные итоги — успех, ошибка, отмена или восстановленный предыдущий состав; определение итогов закреплено в X13.

18.4. Возобновление и проверка ​

После обновления страницы или возвращения узла откройте исходный job ID. Координатор проверяет выполненные шаги по фактическому readback, затем предлагает допустимое продолжение. Отмена завершает работу в определённой точке; действие, уже применённое компонентом, получает явный результат. Восстановление использует подготовленный предыдущий состав и совместимую копию данных.

Методы D16 проверяют четыре подтверждения готового профиля, первоначальный ввод, неверное поле, отказ доступа, устаревшую базу, обрыв на каждом шаге, повтор и откат. Измерение короткого маршрута включает все обязательные подтверждения после выбора подготовленного профиля.

19. M18 — Виртуальные испытания ​

D03-M18. M18 — вход, обработка, результат и состояния.

19.1. Испытательный состав ​

M18 запускает программные участники, подменяет оборудование согласованными моделями и формирует воспроизводимый протокол. Состав содержит E01 Runtime, E02 ESP32, E03 AT32/PLC, E04 технологические модели и E05 координатор. Профиль определяет, какой артефакт исполняется у каждого участника и какие свойства подтверждаются.

19.2. Параметры и артефакты ​

Для ESP32 выбирается точный SoC и SDK. Для AT32 указываются part, CPU/ABI, память, загрузка, flash, таймеры и CAN. Исполнение переносимой логики имеет собственный артефакт и HAL-профиль. Модель процесса содержит инерцию, сигналы, диапазоны и задаваемые отказы.

19.3. Запуск и повтор ​

Наладчик выбирает P-VIRTUAL, устанавливает пакеты через M17, открывает Испытания, выбирает профиль и методы. Координатор проверяет готовность участников, восстанавливает исходное состояние, запускает сценарий и собирает результат каждого шага. Во время прогона интерфейс показывает виртуальную среду, run ID, текущее действие и источники наблюдения.

Результат метода — PASS, FAIL или NOT_RUN с причиной. Протокол сохраняет ожидаемое и фактическое значение, допуск, время и ссылки на доказательства. Повтор использует тот же manifest и начальное состояние. При сбое среды сохраняется техническая причина; повтор запускается после восстановления участников.

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

20. M19 — Приложение и контроллер весовой ​

D03-M19. M19 — вход, обработка, результат и состояния.

20.1. Состав и цикл ​

M19 включает Go L1 controller, киоск водителя /weight/, локальную service surface /weight/dispatcher/, хранилище записей и профиль обмена с L2. Controller владеет состоянием процесса; браузер получает снимок и события, затем отправляет действия с ожидаемой последовательностью.

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

20.2. Настройка и данные ​

Программный интерфейс процесса: GET /weight/api/v1/runtime/state, события /weight/api/v1/runtime/events?after_seq=N, действия POST /weight/api/v1/runtime/actions. Снимок содержит seq, state, stage, panel_id, updated_at, quality, domainPayload; действие использует expected_seq.

20.3. Установка и работа ​

Установочный профиль связывает controller, frontend, конфигурацию и хранилище. Пакет проверяется по manifest и SHA-256, размещается в staging и активируется атомарно через current. После установки наладчик проверяет источник веса, последовательность стадий, запись контрольной провески и передачу в L2.

Водитель следует указаниям киоска. Оператор проверяет номер и груз, устойчивую массу и результат записи. История показывает исходные данные, кадры и признаки уточнения идентичности. При двухэтапном профиле брутто/тара результат нетто вычисляется по связанным записям и их единице.

20.4. Восстановление и испытание ​

При stale-весе проверьте источник и канал; при конфликте последовательности перечитайте снимок; при разрыве L2 сохраните локальные записи и проверьте последующую синхронизацию по weighing_key. Исправление идентификационных данных сохраняет источник и историю изменения. Восстановление БД выполняется по совместимой копии с проверкой уникальности записей.

Виртуальный профиль подменяет весы, оптику, QR/RFID и поток идентификации. D16 проверяет стабильность, повтор записи, изменение стадии, потерю L2 и restart. Метрологические свойства реальных весов закрепляются аппаратной стадией профиля.

21. M20 — ScaleProxy ​

D03-M20. M20 — вход, обработка, результат и состояния.

21.1. Назначение и режимы ​

ScaleProxy предоставляет HTTP API весов и управляет использованием последовательного порта в Windows-профиле. Исполняемый артефакт scale_proxy.exe имеет SemVer, конфигурацию и диагностические интерфейсы. Единица внешнего API — тонна (unit=t).

Режим foreign_com_exclusive передаёт работу с весами стороннему COM-клиенту по правилам профиля. Режим api_default_foreign_preempt использует API-опрос по умолчанию и приоритет стороннего COM при его активности. Состояние показывает текущего владельца api или foreign_com.

21.2. Параметры и интерфейсы ​

Свежий ответ /api/weight содержит ok=true, weight_fresh=true, weight_t, unit=t, age_ms, timestamp и источник. При превышении возраста сервис возвращает 503 с причиной. API-потребитель проверяет свежесть и единицу перед переводом массы в свой формат.

21.3. Установка и восстановление ​

После установки выполните scale_proxy.exe list, выберите порты и режим, затем выполните check. В графическом профиле M17 этим действиям соответствуют выбор порта и проверка плана. После запуска проверьте /ready, /api/state и /api/weight; /ready=200 подтверждает автономную готовность по профилю.

При занятом порте прочитайте активного владельца и конфигурацию. При тайм-ауте проверьте физический канал, формат и срок; при protocol error сопоставьте исходный ответ со схемой. После освобождения порта или восстановления связи проверьте свежую массу и счётчики. Виртуальный serial adapter воспроизводит пакет, задержку, обрыв и переключение владельца. Обновление сохраняет конфигурацию и проверенный предыдущий исполняемый файл.

22. M21 — Приложение «Освещение» ​

D03-M21. M21 — вход, обработка, результат и состояния.

22.1. Предметный профиль ​

Приложение app-lighting управляет отраслевым представлением световых групп объекта. Оно использует общий Runtime/App Host, контекст объекта и программные интерфейсы платформы. Предметный профиль определяет зоны, группы, источники освещённости, режимы, расписания и разрешённые воздействия.

Артефакт включает frontend, регистрацию и предметные схемы. Локальное приложение и окно объекта L2 используют один frontend. Технологическая логика и локальные защиты располагаются согласно карте функций профиля.

22.2. Параметры и состояния ​

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

22.3. Работа и восстановление ​

Наладчик создаёт зоны, сопоставляет каналы, загружает расписание и проверяет часовой пояс. Затем выполняет контрольный запрос каждой группы и сопоставляет readback. Оператор выбирает группу, проверяет режим и качество, задаёт разрешённое действие и наблюдает результат. Ручной режим имеет установленный срок или условие возврата.

При потере датчика применяется правило качества профиля; при тайм-ауте подтверждения проверяются канал и локальная блокировка. После restart восстанавливаются согласованная конфигурация и определённый режим. E04 моделирует освещённость и отказы; D16 проверяет смену суток, конфликт режима, потерю источника и возврат по расписанию.

23. M22 — Приложение «Вентиляция» ​

D03-M22. M22 — вход, обработка, результат и состояния.

23.1. Предметный профиль ​

app-ventilation представляет зоны воздухообмена, датчики, агрегаты, режимы и последовательность технологических действий. Приложение использует общий Runtime/App Host и объектный контекст L2. Профиль распределяет алгоритм, местные блокировки и наблюдение между L0/L1 и верхним уровнем.

Поставка включает frontend artifact, регистрацию, предметные схемы и совместимый алгоритмический профиль. Карта сигналов определяет назначение каждого датчика и исполнительного канала, единицы и реакцию на качество.

23.2. Настраиваемые данные ​

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

23.3. Ввод, работа и восстановление ​

Наладчик сопоставляет зоны и сигналы, задаёт допустимые уставки, проверяет направление измерений и последовательность подтверждений. Контрольный пуск выполняется по разрешённому методу D05/D16. Оператор выбирает зону, проверяет режим и условия, задаёт уставку либо действие и наблюдает ход последовательности.

При тайм-ауте шага откройте условие подтверждения, проверьте источник и местную блокировку. При ухудшении качества датчика применяется определённая реакция профиля. После устранения причины выполните установленную последовательность возврата и проверьте рабочий режим. E04 задаёт динамику, инерцию и отказы; метод D16 проверяет достижение уставки, задержку, блокировку, потерю связи и restart.

24. Связь компонентного и системного испытания ​

Компонентная проверка подтверждает свой интерфейс и состояние. Системный метод связывает участников по профилю D13: артефакты, конфигурация, права, сценарий и наблюдаемый результат. Для замены компонента повторяются методы, затронутые его интерфейсами, миграцией или способом исполнения. Порядок изменения и восстановления приведён в D10; единая форма протокола — в D16.