نموذج المجال التشغيلي

نموذج المجال التشغيلي

يقوم 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 على:

• مُعرِّف فريد؛
• نوع؛
• طراز؛
• شركة مصنّعة؛
• رقم تسلسلي؛
• مالك؛
• منطقة تشغيل؛
• تهيئة؛
• إصدار برنامج ثابت؛
• ملف تعريف اتصال؛
• حالة دورة الحياة.

أداة الكشف (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 أولًا

تُتاح كل إمكانية في المنصة عبر واجهات 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.
• يمكن أن تشترك عدّة Issues في Root Cause واحد.
• قيم Health محسوبة ولا يمكن تحريرها يدويًا.
• تُدوَّن Audit Records بأسلوب الإضافة فقط.
• تبقى Knowledge Articles خاضعة لإدارة الإصدارات طوال دورة حياتها.

تضمن هذه القيود الاتساق وقابلية التتبّع وقابلية إعادة الإنتاج في منصة Operational Health Matrix بأكملها.