Операційна доменна модель

Операційна доменна модель

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.