Архитектура#

1. Состав модулей#

Рекомендуемый baseline-модульный набор:

  • industry.weighbridge.session

  • industry.weighbridge.identity

  • industry.weighbridge.media

  • industry.weighbridge.alarms

Принцип D-002 сохраняется:

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

  • модуль может обогащать соседний модуль данными, но не забирает ownership;

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

2. Ключевые сущности#

  • weigh_session — карточка взвешивания и цикл рейса;

  • driver_identity — данные водителя и рейса, полученные по RFID/QR;

  • media_evidence — фото и видеокадры ANPR и верхней камеры;

  • weigh_alarm_event — ошибки цикла, антифрод и отказ оборудования.

2.1. Key entity по модулям#

  • industry.weighbridge.session -> weigh_session

  • industry.weighbridge.identity -> driver_identity

  • industry.weighbridge.media -> media_evidence

  • industry.weighbridge.alarms -> weigh_alarm_event

3. Базовая топология объекта#

  • весовая платформа двусторонняя;

  • с каждой стороны устанавливается по одной панели iT-2110-015700;

  • панели работают как единый HMI-контур с горизонтальной синхронизацией состояний сессии, очереди, светофорной логики и данных карточки;

  • ANPR-камеры подключаются по сети к панелям;

  • в прототипе primary ANPR допускается на iT-2110-015700, в промышленном исполнении primary ANPR переносится в iT-2210;

  • верхняя камера подключается по сети и дает фотофиксацию груза;

  • в шкафу дополнительно установлены QR-сканер и RFID MIFARE reader;

  • панели, камеры и исполнительные цепи КПП работают в общем edge-контуре iP-1510.

4. Базовый поток операции#

  1. ТС обнаруживается у шлагбаума или в зоне въезда на весы; iP-1510 получает lane/trigger по MQTT и определяет активную сторону въезда.

  2. Если в trigger пришли zone_role и cycle_stage_hint, они используются как advisory-сигнал для перевода автоматического цикла на следующий шаг.

  3. ANPR фиксирует номер, QR/RFID при необходимости дополняют данные рейса и водителя.

  4. Стабилизация на платформе подтверждается от весового индикатора.

  5. Создается или обновляется weigh_session со статусом tare_pending, gross_pending или completed.

  6. Верхняя камера формирует фотофиксацию груза.

  7. При повторном заезде того же рейса карточка может оставаться частичной и затем дополняется второй фазой (tare или gross) с расчетом net.

  8. При нарушениях цикла создается weigh_alarm_event и при необходимости bridge в status.

5. Интеграция с ядром#

  • API-дисциплина: /api/v1/<resource>/scheme|list плюс command endpoint-ы;

  • изоляция данных: tenant_id, industry_code=weighbridge, site_id, lane_id, direction;

  • auth, permissions и shell runtime используются общие;

  • lane/trigger из ioot-pro-anpr рассматривается как внешний вход для старта и продвижения zero-operator cycle;

  • cycle_stage_hint и zone-поля от ANPR остаются advisory и не переносят ownership state machine из weighbridge-модуля;

  • media и alarm evidence должны быть доступны для infobar и карточки взвешивания через единый UI-контур iP-1510;

  • критические ошибки цикла и отказ оборудования публикуются в status по модели D-004.

6. Особенности edge-single сценария#

  • для шкафного контура edge-single отрасль фиксирована как weighbridge;

  • primary workspace — полноэкранный operational dashboard весов;

  • приоритет отдается zero-operator cycle, а не ручной карточной обработке;

  • QR/RFID работают как enrichment-контуры и не должны блокировать автоматический цикл;

  • ручное вмешательство допускается только как exception flow.