Operational Health Matrix (OHM)

Operational Health Matrix (OHM) هي الوحدة التشغيلية المركزية في منصة IIoT. وهي تحوّل تدفّق القياس عن بُعد ونتائج التحليلات والأحداث التشغيلية إلى دورة عمل مُدارة: من الاكتشاف الآلي للمشكلة إلى معالجتها معالجةً مؤكَّدة بالبيانات.

تجمع OHM في نظام واحد:

• كشف المشكلات التقنية والمترولوجية ومشكلات التكامل؛
• ربط الأعراض وتحديد السبب الجذري المحتمل (Root Cause)؛
• إنشاء كائنات Operational Issue وإدارتها؛
• إسناد الفرق المسؤولة والمنفّذين؛
• إدارة المواعيد النهائية والأولويات وسياسات SLA؛
• تتبّع المهام والتعليقات والأدلّة وسجلّ الإجراءات؛
• التحقّق الآلي من النتائج استنادًا إلى البيانات الجديدة؛
• إدارة الحوادث الجماعية (Massive Incidents)؛
• تقييم حالة المعدّات والأسطول؛
• حساب مؤشّرات KPI التشغيلية ومؤشّرات الفرق؛
• تراكم الحلول المؤكَّدة في قاعدة المعرفة؛
• تحليل بمساعدة الـ AI دون تفويض صلاحية اتخاذ القرارات الحرجة إلى الذكاء الاصطناعي.

flowchart TD
  A["القياس عن بُعد"] --> B["أدوات الكشف"]
  B --> C["Evidence"]
  C --> D["الترابط و Root Cause"]
  D --> E["Operational Issue"]
  E --> F["الإسناد والتنفيذ"]
  F --> G["التحقّق بالبيانات"]
  G --> H["الإغلاق و Knowledge Base"]
  H --> I["مؤشّرات KPI والتحسين المستمر"]

الغرض من الوحدة

تجيب أنظمة القياس عن بُعد التقليدية إجابة جيدة عن السؤال:

ماذا حدث للجهاز أو للبيانات؟

لكنّ هذا لا يكفي لإدارة أسطول كبير. فبعد اكتشاف الحدث، على المؤسسة أن تحدّد:

• هل تمثّل الإشارة مشكلة حقيقية؛
• هل تخصّ جهازًا واحدًا أم تشكّل حادثة على مستوى النظام؛
• ما الأعراض الأخرى المرتبطة بالسبب الجذري نفسه؛
• من المسؤول عن المعالجة؛
• ما الموعد الذي يجب أن يكتمل فيه العمل؛
• ما الإجراءات التي اتُّخذت بالفعل؛
• هل تأكّدت المعالجة ببيانات موضوعية؛
• هل المشكلة متكرّرة؛
• ما مدى فعالية العملية التشغيلية.

تُغلق OHM هذه الدورة بأكملها.

والنتيجة الأساسية لعمل الوحدة ليست إشعارًا ولا سطرًا في تقرير، بل كائنًا تشغيليًا مُدارًا له:

• مُعرِّف؛
• نوع مشكلة؛
• أصول متأثّرة؛
• أدلّة؛
• درجة خطورة؛
• مستوى ثقة؛
• سبب جذري محتمل ومؤكَّد؛
• مالك؛
• منفِّذ؛
• موعد نهائي؛
• مهامّ؛
• سجلّ تاريخي؛
• حالة تحقّق؛
• نتيجة معالجة؛
• ارتباط بقاعدة المعرفة؛
• أثر في مؤشّرات KPI.

الميزة الأساسية

لا تكتفي المنصة بتسجيل الانحرافات. المنصة ترافق المشكلة حتى الوصول إلى نتيجة مؤكَّدة.

flowchart TD
  subgraph OPS["منصة IIoT و OHM"]
    direction TB
    O1["اكتشفت المشكلة"] --> O2["تحقّقت من الأدلّة"]
    O2 --> O3["وحّدت الإشارات المترابطة"]
    O3 --> O4["حدّدت الأولوية"]
    O4 --> O5["أسندت منطقة المسؤولية"]
    O5 --> O6["تراقب الموعد النهائي"]
    O6 --> O7["تحقّقت من النتيجة بالبيانات"]
    O7 --> O8["حفظت الحل المؤكَّد"]
  end
  subgraph MON["نظام المراقبة"]
    direction TB
    M1["اكتشف المشكلة"] --> M2["هنا ينتهي عمل النظام"]
  end

وبفضل ذلك تنقل OHM التشغيل من نمط ردّ الفعل إلى نموذج مُدار يكون فيه لكل انحراف جوهري مالك وموعد نهائي وأدلّة ونتيجة قابلة للقياس.

المبادئ الأساسية

Issues بدلًا من الإنذارات

الإنذار الواحد لا يعادل دائمًا مشكلة تشغيلية.

فالعطل المادي الواحد قد يولّد عشرات أو مئات الأحداث:

• لا توجد جلسة اتصال؛
• لا يوجد أرشيف؛
• بيانات متقادمة؛
• حالة البطارية غير معروفة؛
• لا يوجد ضغط حالي؛
• خطأ في التسليم.

لا تُنشئ OHM بند عمل منفصلًا لكل عرَض. فيربط النظام الإشارات وينشئ Operational Issue واحدًا عندما تعود هذه الإشارات إلى سبب مشترك.

عمليات قائمة على الأدلّة (Evidence)

يجب أن يكون كل استنتاج آلي قابلًا للتفسير.

يحتوي الـ Issue على:

• القيم المصدرية؛
• الطوابع الزمنية؛
• مُعرِّف أداة الكشف (Detector)؛
• إصدار الخوارزمية؛
• العتبات المطبَّقة؛
• رابط إلى التقرير المتخصّص ذي الصلة؛
• سجلّ التكرارات؛
• الإشارات المرتبطة؛
• نتيجة الترابط.

يستطيع المستخدمون دائمًا تتبّع المسار من بيانات القياس عن بُعد الخام حتى الـ Issue الذي أُنشئ.

الأولوية للسبب الجذري (Root Cause)

تميّز OHM بين:

• العرَض — انحراف مُلاحَظ؛
• السبب — العامل التقني أو التنظيمي الذي أنتج الانحراف؛
• السبب الجذري — العامل الأوّلي الذي يمنع القضاءُ عليه تكرارَ مجموعة من الأعراض.

مثال:

flowchart LR
  S1["العرَض 1: الأرشيف الساعي مفقود"] --> RC["السبب الجذري المحتمل: تدهور مصدر التغذية"]
  S2["العرَض 2: آخر جلسة كانت قبل 9 أيام"] --> RC
  S3["العرَض 3: جهد البطارية كان يتناقص"] --> RC
  S4["العرَض 4: مدة الجلسات كانت تتزايد"] --> RC

الإغلاق المؤكَّد بالبيانات

يُبلّغ المنفِّذ بأن العمل قد أُنجز، لكنّ الحالة النهائية resolved لا تُسجَّل إلا بعد التحقّق من النتيجة.

flowchart TD
  V1["اكتمل العمل"] --> V2["awaiting_verification"]
  V2 --> V3["بيانات جديدة تؤكّد عودة الوضع الطبيعي"]
  V3 --> V4["resolved"]

أما المشكلات التي يتعذّر التحقّق منها عبر القياس عن بُعد، فيُطبَّق عليها تحقّق يدوي مُراقَب، مع تعليق إلزامي ودليل داعم.

الأصل (Asset) في مركز النموذج

ترتبط جميع الأحداث والـ Issues وبنود العمل والمؤشّرات بالأصول:

• نقاط القياس؛
• المصحّحات؛
• العدّادات؛
• المستشعرات؛
• المودمات؛
• البوّابات؛
• بطاقات SIM؛
• مكوّنات الخوادم؛
• قنوات التكامل؛
• إصدارات البرمجيات.

تعرض بطاقة الأصل الصحة الحالية وسجلّ التدهور والـ Issues النشطة والأعمال المنجزة وتكرار المشكلات.

المسؤولية على الإنسان والـ AI مساعِد

يساعد الـ AI في:

• تلخيص Evidence؛
• ترتيب الفرضيات؛
• إيجاد الحالات المشابهة؛
• اقتراح الحلول المعروفة؛
• كشف العناقيد الجديدة؛
• التنبّؤ بخطر العطل.

ولا يستطيع الـ AI بمفرده:

• تغيير الأولوية؛
• إسناد المسؤولية؛
• إغلاق Issue؛
• تأكيد Root Cause بوصفه حقيقة ثابتة؛
• تعديل سياسات SLA؛
• تنفيذ إجراءات حرجة على المعدّات.

قابلية إعادة الإنتاج بحكم التصميم

جميع الحسابات المهمّة قابلة لإعادة الإنتاج. وتحفظ المنصة لكل نتيجة:

• إصدار أداة الكشف؛
• إصدار الـ Canon؛
• إصدار نموذج الترابط؛
• مجموعة البيانات المستخدمة؛
• زمن الحساب؛
• العتبات؛
• التهيئة؛
• مصدر التغيير.

موقع OHM في بنية منصة IIoT

تقع OHM بين طبقة التحليلات وإدارة التشغيل.

flowchart TD
  PHY["الأصول المادية"] --> DATA["طبقة بيانات IIoT والتكامل"]
  DATA -->|"بيانات مُطبَّعة"| ANL["التحليلات والكشف"]
  ANL -->|"Evidence ونتائج التحليل"| OHM["Operational Health Matrix"]
  OHM -->|"API والأحداث والتكامل"| ENT["الأنظمة المؤسسية"]

محتوى الطبقات:

مصادر البيانات

تستخدم OHM:

• بيانات القياس عن بُعد الحالية؛
• الأرشيفات الساعية واليومية وأرشيفات الأحداث؛
• سجلّات جلسات الاتصال؛
• بيانات الـ Passport والـ Registry؛
• حالات الأجهزة؛
• بيانات البطارية؛
• الضغط ودرجة الحرارة ومعدّل التدفّق والحجم؛
• أحداث التلاعب؛
• إصدارات الـ Firmware؛
• معاملات الاتصال؛
• نتائج التقارير المتخصّصة؛
• الملاحظات اليدوية للمستخدمين؛
• أحداث الأنظمة الخارجية.

مزوّدو Evidence

يمكن لأي وحدة تحليلية في المنصة أن تكون مصدرًا للأدلّة.

أمثلة:

استكشف الوحدة