Операционная доменная модель

Операционная доменная модель

Operational Health Matrix строится на единой операционной доменной модели, которая определяет ключевые сущности, связи и зоны ответственности в масштабах всей IIoT Платформы.

Каждый процесс, детектор, API-эндпоинт и аналитический компонент работает с одной и той же доменной моделью, что обеспечивает согласованность во всей системе.

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

Основные сущности

Домен Operational Health Matrix состоит из следующих основных сущностей:

• Asset
• Detector
• Evidence
• Operational Issue
• Task
• Root Cause
• Health
• Knowledge Article
• Massive Incident
• SLA Policy
• Team
• User
• Notification
• Attachment
• Comment
• Audit Record

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

Asset (актив)

Asset — центральная сущность платформы.

Каждый наблюдаемый физический или логический объект представлен как Asset.

Типичные примеры:

• счётчик газа
• датчик давления
• корректор
• RTU
• шлюз
• контроллер клапана
• телеметрический блок
• устройство связи
• программный компонент

Каждый Asset содержит:

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

Detector (детектор)

Detector — аналитический компонент, отвечающий за преобразование телеметрии в операционные наблюдения.

Detector не создаёт бизнес-логику.

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

Атрибуты Detector включают:

• Identifier
• Version
• Canon
• Confidence
• Status
• Accuracy Metrics
• Health

Evidence (доказательство)

Evidence представляет собой неизменяемое доказательство, подтверждающее операционный вывод.

Источниками Evidence могут быть:

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

Evidence не может быть изменено после создания.

Если требуется исправление, создаётся новый объект Evidence, а предыдущая версия сохраняется.

Operational Issue (операционная проблема)

Operational Issue представляет подтверждённую эксплуатационную проблему, требующую расследования или устранения.

Каждый Operational Issue содержит:

• Canon;
• Severity;
• Priority;
• Status;
• Owner;
• Root Cause;
• SLA Policy;
• Verification State;
• Operational History.

Operational Issue — главный операционный объект платформы.

Task (задача)

Task представляет исполняемое действие, необходимое для устранения Operational Issue.

Задачи не могут существовать самостоятельно.

Каждый Task принадлежит ровно одному Operational Issue.

Один Operational Issue может содержать несколько задач.

Root Cause (первопричина)

Root Cause представляет подтверждённую первопричину одного или нескольких Operational Issues.

Несколько Operational Issues могут ссылаться на одну и ту же Root Cause.

Эта связь обеспечивает эксплуатационную аналитику в масштабах предприятия и выявление повторяющихся проблем.

Health (здоровье)

Health — вычисляемый операционный показатель.

Health существует для:

• актива;
• площадки;
• региона;
• организации;
• всей экосистемы.

Значения Health всегда рассчитываются автоматически.

Knowledge Article (статья базы знаний)

Knowledge Article хранит проверенный эксплуатационный опыт.

Каждая статья может ссылаться на:

• канонические проблемы;
• корневые причины;
• типы активов;
• версии прошивки;
• эксплуатационные процедуры;
• документацию производителя.

Massive Incident (массовый инцидент)

Massive Incident группирует несколько Operational Issues, возникших из общего эксплуатационного события.

Он предоставляет единый объект управления для масштабных инфраструктурных инцидентов.

Операционные принципы

Operational Health Matrix следует нескольким архитектурным принципам, которые определяют поведение каждой подсистемы.

Актив прежде всего (Asset First)

Каждое эксплуатационное событие связывается с Asset.

Активы остаются первичными объектами на протяжении всего жизненного цикла.

Управление через Issues

Эксплуатация управляется через Operational Issues, а не через отдельные тревоги или события телеметрии.

Решения на основе доказательств

Каждый операционный вывод должен быть подтверждён одним или несколькими объектами Evidence.

Неподтверждённые предположения никогда не рассматриваются как установленные факты.

Сначала первопричина, затем устранение

Корректирующие действия по возможности направлены на подтверждённые причины, а не на наблюдаемые симптомы.

Человек в контуре (Human-in-the-Loop)

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

Критические действия требуют явного подтверждения человеком.

Объяснимая аналитика

Аналитические выводы остаются прозрачными.

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

Неизменяемый аудит

Операционная история не может быть переписана.

Каждое изменение порождает новую запись аудита.

API-first подход

Каждая возможность платформы доступна через документированные API.

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

Событийно-ориентированная архитектура

Операционные изменения распространяются в виде событий.

Это делает возможными асинхронные интеграции и масштабируемые конвейеры обработки.

Операционная модель данных

Платформа следует единой операционной модели данных.

flowchart TD
    A["Asset"] --> DET["Detector"]
    A --> EV["Evidence"]
    A --> ISSUE["Operational Issue"]
    ISSUE --> TASK["Task"]
    ISSUE --> RC["Root Cause"]
    ISSUE --> SLA["SLA Policy"]
    ISSUE --> CMT["Comment"]
    ISSUE --> ATT["Attachment"]
    A --> HLT["Health"]
    A --> KB["Knowledge Articles"]

Владение

Каждая сущность имеет ровно одного владельца жизненного цикла.

Правила жизненного цикла

Доменная модель соблюдает несколько инвариантов:

• Активы никогда не удаляются, пока существуют исторические Operational Issues.
• Evidence неизменяемо.
• Задачи не могут существовать без Operational Issue.
• Root Causes могут быть общими для нескольких Issues.
• Значения Health вычисляются и не могут быть отредактированы вручную.
• Audit Records ведутся в режиме append-only.
• Knowledge Articles остаются версионируемыми на протяжении всего жизненного цикла.

Эти ограничения обеспечивают согласованность, прослеживаемость и воспроизводимость во всей платформе Operational Health Matrix.