Operational Health Matrix (OHM)

Operational Health Matrix (OHM) ماژول عملیاتی مرکزی پلتفرم IIoT است. این ماژول جریان تله‌متری، نتایج تحلیل و رویدادهای بهره‌برداری را به یک چرخهٔ کاری مدیریت‌شده تبدیل می‌کند: از تشخیص خودکار مشکل تا رفع تأییدشده با داده.

OHM موارد زیر را در یک سامانهٔ واحد گرد می‌آورد:

• تشخیص مشکلات فنی، اندازه‌شناختی و یکپارچه‌سازی؛
• همبسته‌سازی نشانه‌ها و تعیین علت ریشه‌ای (Root Cause) محتمل؛
• ایجاد و مدیریت اشیای Operational Issue؛
• تعیین تیم‌های مسئول و مجریان؛
• مدیریت مهلت‌ها، اولویت‌ها و SLA؛
• پیگیری Tasks، کامنت‌ها، Evidence و تاریخچهٔ اقدامات؛
• راستی‌آزمایی خودکار نتیجه بر پایهٔ داده‌های جدید؛
• مدیریت رخدادهای گسترده (Massive Incident)؛
• ارزیابی وضعیت تجهیزات و ناوگان؛
• محاسبهٔ KPI عملیاتی و تیمی؛
• انباشت راهکارهای تأییدشده در پایگاه دانش (Knowledge Base)؛
• پشتیبانی AI از تحلیل، بدون واگذاری اختیار تصمیم‌های حیاتی به هوش مصنوعی.

flowchart TD
  A["تله‌متری"] --> B["Detectorها"]
  B --> C["Evidence"]
  C --> D["همبسته‌سازی و Root Cause"]
  D --> E["Operational Issue"]
  E --> F["تخصیص و اجرا"]
  F --> G["راستی‌آزمایی بر پایهٔ داده"]
  G --> H["بستن پرونده و Knowledge Base"]
  H --> I["KPI و بهبود مستمر"]

هدف ماژول

سامانه‌های سنتی تله‌متری به‌خوبی به این پرسش پاسخ می‌دهند:

برای دستگاه یا داده چه اتفاقی افتاده است؟

اما برای مدیریت یک ناوگان بزرگ این اندازه کافی نیست. پس از تشخیص یک رویداد، سازمان باید مشخص کند:

• آیا این سیگنال یک مشکل واقعی است؛
• آیا تنها یک دستگاه را در بر می‌گیرد یا یک رخداد در سطح کل سامانه است؛
• کدام نشانه‌های دیگر به همان علت ریشه‌ای مربوط‌اند؛
• مسئولیت رفع آن با کیست؛
• کار تا چه زمانی باید انجام شود؛
• پیش‌تر چه اقداماتی انجام شده است؛
• آیا رفع مشکل با داده‌های عینی تأیید شده است؛
• آیا مشکل تکرارشونده است؛
• فرایند عملیاتی تا چه اندازه اثربخش کار می‌کند.

OHM تمام این چرخه را می‌بندد.

خروجی اصلی این ماژول نه یک اعلان است و نه یک سطر گزارش، بلکه یک شیء عملیاتی مدیریت‌شده است که موارد زیر را دارد:

• شناسه؛
• نوع مشکل؛
• Assetهای متأثر؛
• Evidence؛
• شدت (Severity)؛
• سطح اطمینان؛
• علت ریشه‌ای محتمل و تأییدشده؛
• مالک؛
• مجری؛
• مهلت؛
• Tasks؛
• تاریخچه؛
• وضعیت راستی‌آزمایی؛
• نتیجهٔ رفع مشکل؛
• پیوند با Knowledge Base؛
• اثر بر 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 می‌سازد.

بهره‌برداری مبتنی بر شواهد

هر نتیجه‌گیری خودکار باید قابل توضیح باشد.

هر Issue شامل این موارد است:

• مقادیر اولیه؛
• برچسب‌های زمانی؛
• شناسهٔ Detector؛
• نسخهٔ الگوریتم؛
• آستانه‌های اعمال‌شده؛
• پیوند به گزارش تخصصی مرتبط؛
• تاریخچهٔ تکرارها؛
• سیگنال‌های مرتبط؛
• نتیجهٔ همبسته‌سازی.

کاربر همیشه می‌تواند مسیر را از تله‌متری خام تا Issue ایجادشده دنبال کند.

نخست علت ریشه‌ای (Root Cause)

OHM میان این مفاهیم تمایز می‌گذارد:

• نشانه — انحراف مشاهده‌شده؛
• علت — عامل فنی یا سازمانی که انحراف را پدید آورده است؛
• علت ریشه‌ای — عامل اولیه‌ای که رفع آن از تکرار گروهی از نشانه‌ها جلوگیری می‌کند.

مثال:

flowchart LR
  S1["نشانهٔ 1: آرشیو ساعتی موجود نیست"] --> RC["Root Cause محتمل: افت کارکرد منبع تغذیه"]
  S2["نشانهٔ 2: آخرین نشست ارتباطی 9 روز پیش بوده است"] --> RC
  S3["نشانهٔ 3: ولتاژ باتری رو به کاهش بوده است"] --> RC
  S4["نشانهٔ 4: مدت‌زمان نشست‌ها رو به افزایش بوده است"] --> RC

بستن پرونده با تأیید داده

مجری اعلام می‌کند که کار انجام شده است، اما وضعیت نهایی resolved تنها پس از راستی‌آزمایی نتیجه ثبت می‌شود.

flowchart TD
  V1["کار انجام شد"] --> V2["awaiting_verification"]
  V2 --> V3["داده‌های جدید عادی‌شدن وضعیت را تأیید می‌کنند"]
  V3 --> V4["resolved"]

برای مشکلاتی که با تله‌متری قابل راستی‌آزمایی نیستند، راستی‌آزمایی دستی و کنترل‌شده به کار می‌رود که در آن درج کامنت و ارائهٔ شواهد الزامی است.

Asset در مرکز مدل

همهٔ رویدادها، Issues، کارها و شاخص‌ها به Assetها پیوند می‌خورند:

• نقطهٔ اندازه‌گیری؛
• تصحیح‌کننده؛
• کنتور؛
• حسگر؛
• مودم؛
• گیت‌وی؛
• سیم‌کارت؛
• مؤلفهٔ سروری؛
• کانال یکپارچه‌سازی؛
• نسخهٔ نرم‌افزار.

کارت Asset سلامت جاری، تاریخچهٔ افت وضعیت، Issues فعال، کارهای انجام‌شده و تکرارشوندگی مشکلات را نشان می‌دهد.

مسئولیت با انسان، AI در نقش دستیار

AI کمک می‌کند تا:

• Evidence خلاصه شود؛
• فرضیه‌ها رتبه‌بندی شوند؛
• موارد مشابه یافت شوند؛
• راهکارهای شناخته‌شده پیشنهاد شوند؛
• خوشه‌های تازه شناسایی شوند؛
• ریسک خرابی پیش‌بینی شود.

AI به‌تنهایی نمی‌تواند:

• اولویت را تغییر دهد؛
• مسئولیت را تعیین کند؛
• Issue را ببندد؛
• Root Cause را به‌عنوان واقعیت اثبات‌شده تأیید کند؛
• SLA را تغییر دهد؛
• اقدام‌های حیاتی روی تجهیزات انجام دهد.

تکرارپذیری در طراحی

همهٔ محاسبات مهم تکرارپذیرند. پلتفرم برای هر نتیجه این موارد را نگه می‌دارد:

• نسخهٔ Detector؛
• نسخهٔ Canon؛
• نسخهٔ مدل همبسته‌سازی؛
• مجموعه‌دادهٔ استفاده‌شده؛
• زمان محاسبه؛
• آستانه‌ها؛
• پیکربندی؛
• منشأ تغییر.

جایگاه OHM در معماری پلتفرم IIoT

OHM میان لایهٔ تحلیل و مدیریت بهره‌برداری قرار دارد.

flowchart TD
  PHY["Assetهای فیزیکی"] --> DATA["لایهٔ داده و یکپارچه‌سازی IIoT"]
  DATA -->|"داده‌های نرمال‌شده"| ANL["تحلیل و تشخیص"]
  ANL -->|"Evidence و یافته‌های تحلیل"| OHM["Operational Health Matrix"]
  OHM -->|"API، رویدادها، یکپارچه‌سازی"| ENT["سامانه‌های سازمانی"]

ترکیب لایه‌ها:

منابع داده

OHM از این منابع استفاده می‌کند:

• تله‌متری جاری؛
• آرشیوهای ساعتی، روزانه و رویدادی؛
• لاگ نشست‌های ارتباطی؛
• داده‌های شناسنامه و Registry؛
• وضعیت دستگاه‌ها؛
• داده‌های باتری؛
• فشار، دما، دبی و حجم؛
• رویدادهای دستکاری؛
• نسخه‌های Firmware؛
• پارامترهای ارتباطی؛
• نتایج گزارش‌های تخصصی؛
• مشاهده‌های دستی کاربران؛
• رویدادهای سامانه‌های بیرونی.

تأمین‌کنندگان Evidence

هر ماژول تحلیلی پلتفرم می‌تواند نقش منبع شواهد را ایفا کند.

نمونه‌ها:

ماژول را کاوش کنید