مدل دامنهٔ عملیاتی

مدل دامنهٔ عملیاتی

‏Operational Health Matrix بر یک مدل دامنهٔ عملیاتی واحد بنا شده است که موجودیت‌های اصلی، روابط و حوزه‌های مسئولیت را در سراسر پلتفرم IIoT تعریف می‌کند.

هر فرایند، هر Detector، هر نقطهٔ پایانی 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 شامل این موارد است:

• شناسهٔ یکتا؛
• نوع؛
• مدل؛
• سازنده؛
• شمارهٔ سریال؛
• مالک؛
• منطقهٔ بهره‌برداری؛
• پیکربندی؛
• نسخهٔ Firmware؛
• پروفایل ارتباطی؛
• وضعیت چرخهٔ عمر.

‏Detector (آشکارساز)

‏Detector مؤلفه‌ای تحلیلی است که تبدیل تله‌متری به مشاهده‌های عملیاتی بر عهدهٔ آن است.

‏Detector منطق کسب‌وکار نمی‌سازد.

مسئولیت آن به شناسایی الگوهای قابل مشاهده و تولید Evidence محدود می‌شود.

ویژگی‌های 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ها نمی‌توانند مستقل وجود داشته باشند.

هر Task دقیقاً به یک Operational Issue تعلق دارد.

یک Operational Issue می‌تواند چند Task داشته باشد.

‏Root Cause (علت ریشه‌ای)

‏Root Cause نمایانگر عامل زیربنایی تأییدشدهٔ یک یا چند Operational Issue است.

چند Operational Issue می‌توانند به یک Root Cause واحد ارجاع دهند.

این رابطه، تحلیل عملیاتی در مقیاس کل سازمان و شناسایی مشکلات تکرارشونده را ممکن می‌کند.

‏Health (سلامت)

‏Health یک شاخص عملیاتی محاسبه‌شده است.

‏Health برای این سطوح وجود دارد:

• ‏Asset؛
• سایت؛
• منطقه؛
• سازمان؛
• کل اکوسیستم.

مقادیر Health همواره به‌صورت خودکار محاسبه می‌شوند.

‏Knowledge Article (مقالهٔ پایگاه دانش)

‏Knowledge Article تجربهٔ بهره‌برداری اعتبارسنجی‌شده را نگه می‌دارد.

هر مقاله می‌تواند به این موارد ارجاع دهد:

• مشکلات مرجع (Canon)؛
• علت‌های ریشه‌ای (Root Cause)؛
• انواع Asset؛
• نسخه‌های Firmware؛
• رویه‌های بهره‌برداری؛
• مستندات سازنده.

‏Massive Incident (رخداد گسترده)

‏Massive Incident چند Operational Issue را که از یک رویداد بهره‌برداری مشترک سرچشمه گرفته‌اند، در یک گروه گرد می‌آورد.

این موجودیت یک شیء مدیریتی واحد برای رخدادهای زیرساختی بزرگ‌مقیاس فراهم می‌کند.

اصول عملیاتی

‏Operational Health Matrix از چند اصل معماری پیروی می‌کند که رفتار هر زیرسامانه را تعیین می‌کنند.

اولویت با Asset (Asset First)

هر رویداد بهره‌برداری به یک Asset پیوند می‌خورد.

‏Assetها در سراسر چرخهٔ عمر، اشیای اصلی باقی می‌مانند.

بهره‌برداری Issue-محور

بهره‌برداری از راه Operational Issues مدیریت می‌شود، نه از راه هشدارهای منفرد یا رویدادهای تله‌متری.

تصمیم‌های مبتنی بر Evidence

هر نتیجه‌گیری عملیاتی باید با یک یا چند شیء 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"]

مالکیت

هر موجودیت دقیقاً یک مالک چرخهٔ عمر دارد.

قواعد چرخهٔ عمر

مدل دامنه چند ناوردا (invariant) را رعایت می‌کند:

• تا زمانی که Operational Issues تاریخی وجود دارند، Assetها هرگز حذف نمی‌شوند.
• ‏Evidence تغییرناپذیر است.
• ‏Taskها بدون یک Operational Issue نمی‌توانند وجود داشته باشند.
• یک Root Cause می‌تواند میان چند Issue مشترک باشد.
• مقادیر Health محاسبه می‌شوند و به‌صورت دستی قابل ویرایش نیستند.
• ‏Audit Records فقط افزودنی‌اند (append-only).
• ‏Knowledge Articles در سراسر چرخهٔ عمر خود نسخه‌بندی‌شده می‌مانند.

این محدودیت‌ها سازگاری، ردیابی‌پذیری و تکرارپذیری را در سراسر پلتفرم Operational Health Matrix تضمین می‌کنند.