Detectorها و مشکلات مرجع
چگونه Detectorها تلهمتری را به یافته تبدیل میکنند و Canonها یافتهها را به مشکلهای مدیریتشده بدل میکنند — کلاسهای Detector، گیتهای کیفیت داده، کاتالوگ Canonها و تحلیل کیفیت Detectorها.
معماری Detectorها
آشکارساز (Detector)
Detector الگوریتمی است که مجموعهٔ دادهای مشخصی را تحلیل میکند و یافتهای صورتبندیشده تولید میکند.
Detector اجرای کار را مدیریت نمیکند و متن آزاد تولید نمیکند. خروجی آن قالبی ساختارمند دارد.
detector_id: archive.tail_gap.v3
detector_version: '3.2.1'
run_id: 'run-20260723-0400'
asset_id: 'station-5690'
observed_at: '2026-07-23T04:00:00Z'
finding:
canon: no_hourly_archive
detected: true
severity: critical
confidence: 0.98
value: 73
unit: 'hours'
threshold: 24
baseline: 0
evidence:
last_valid_hour: '2026-07-20T03:00:00Z'
expected_end: '2026-07-23T04:00:00Z'
missing_hours: 73زنجیرهٔ Detector → Canon → Issue
flowchart TD
D["Detector"] -->|"طبقهبندی"| C["Canon"]
C -->|"مدیریت"| I["Operational Issue"]Detector— الگوریتمی مشخص؛Canon— گونهای پایدار از مشکل بهرهبرداری؛Operational Issue— نمونهای از آن مشکل در بستری مشخص.
چند Detector متفاوت میتوانند یک Canon واحد را تأیید کنند.
مثال:
flowchart TD
D1["archive.tail_gap.v3"] --> CANON["no_hourly_archive"]
D2["archive.coverage.v2"] --> CANON
D3["archive.delivery_queue.v1"] --> CANON
D4["session.freshness.v4"] --> CANON
CANON --> ISSUE["OHM-2026-001842"]کلاسهای Detector
| کلاس | کاربرد |
|---|---|
| Connectivity | ارتباط، نشستها، دسترسپذیری، سیگنال |
| Archive | کامل بودن و تحویل آرشیوها |
| Data Quality | اعتبار، شکافها، تناقضها |
| Metering | دبی، حجم، نسبتهای اندازهشناختی |
| Pressure | بازهها، جهشها، قرائتهای ثابتمانده |
| Temperature | بازهها، روندها، سازگاری فیزیکی |
| Power | باتری، تغذیه، افت کارایی |
| Registry | فهرست ثبت، رکوردهای تکراری، اشیای ghost |
| Passport | کامل و درست بودن شناسنامه |
| Integrity | نشانههای دستکاری و نقض یکپارچگی |
| Security | رویدادهای ناهنجار دسترسی و پیکربندی |
| Firmware | خطاها، ناسازگاری، پسرفتها |
| Topology | وابستگی میان دستگاهها، گیتویها و سرویسها |
| Operations | موارد از موعد گذشته، نبود مالک، تکرارشوندگی |
| Predictive | پیشبینی خرابی یا افت کارایی |
الزامات هر Detector
هر Detector عملیاتی این موارد را دارد:
- شناسهٔ یکتای
detector_id؛ - نسخهٔ معنایی؛
- کاربرد اعلامشده؛
- مالک؛
- شرح دادههای ورودی؛
- آستانههای کنترلشده؛
- قواعد استثنا؛
- الزامهای کمینهٔ حجم نمونه؛
- گیتهای DQ؛
- فرمول Severity؛
- فرمول سطح اطمینان؛
- Canon متناظر؛
- مجموعهٔ Evidence؛
- آزمونها؛
- نمونهٔ کنترلی؛
- برآورد هشدارهای کاذب (false positive)؛
- تاریخ راهاندازی؛
- گزارش تغییرات؛
- حالت غیرفعالسازی و بازگردانی (rollback).
گیتهای کیفیت داده (DQ)
اگر دادههای منبع ناقص یا متناقض باشند، Detector نباید سطح اطمینان بالایی تولید کند.
نمونههایی از گیتها:
| شرط | اثر بر Detector |
|---|---|
نبودِ asset_id معتبر | مسدود کردن اقدام خودکار |
| تاریخچهٔ ناکافی | کاهش سطح اطمینان |
| خطای برچسب زمانی | تازگی داده محاسبه نشود |
| نبودِ یکای اندازهگیری | با آستانهٔ فیزیکی مقایسه نشود |
| نمونهٔ بسیار کوچک | پیشبینی ساخته نشود |
| شیء ghost در فهرست ثبت | Issueهای مرتبط non-actionable شوند |
سلامت Detectorها (Detector Health)
OHM کیفیت خودِ Detectorها را پایش میکند.
شاخصهای کلیدی:
- شمار فعالشدنها؛
- سهم فعالشدنهای تأییدشده؛
- نرخ هشدارهای کاذب؛
- سهم لغوهای دستی؛
- سهم بازگشاییهای مجدد؛
- توزیع سطح اطمینان؛
- رانش (drift) دادههای ورودی؛
- تغییر ساختار نمونه؛
- میانگین زمان تا تأیید؛
- نسخهٔ الگوریتم؛
- شمار Issueهای فعال به تفکیک نسخه.
مشکلات مرجع (Canon)
Canon طبقهبندی پایدارِ یک مشکل در سطح کسبوکار است که به پیادهسازی مشخصی از Detector وابسته نیست.
چرا به Canon نیاز است
بدون Canon، یک سامانهٔ تحلیلی بهسرعت به مجموعهای از پیامهای ناهماهنگ تنزل میکند:
archive_missingno_archivearchive_gaphourly_data_absentdelivery_error
Canon همهٔ این سیگنالهای همارز را زیر یک شناسهٔ واحد گرد میآورد: canon: no_hourly_archive.
این کار موارد زیر را فراهم میکند:
- یک چرخهٔ کاری واحد؛
- یک SLA واحد؛
- تحلیلهای شفاف؛
- KPIهای پایدار؛
- پایگاه دانش مشترک (Knowledge Base)؛
- قابلیت مقایسه میان نسخهها؛
- ترجمهٔ رابط کاربری بدون تغییر منطق؛
- یکپارچهسازی با سامانههای بیرونی.
ساختار Canon
canon_id: no_hourly_archive
name: 'Hourly archive is missing'
domain: archive
default_owner_zone: backend_integration
default_priority: P1
actionable: true
verification_mode: data
sla_policy: archive_p1
suppression_group: communication_archive
knowledge_tags:
- archive
- delivery
- communicationمجموعهٔ پایهٔ Canonها
| Canon | معنا | حوزهٔ اصلی |
|---|---|---|
no_sessions_in_period | در بازهٔ تحلیلشده هیچ نشستی وجود ندارد | یکپارچهسازی / ارتباطات |
stale_communication | دستگاه مدتهاست ارتباط برقرار نکرده است | میدانی / ارتباطات |
no_hourly_archive | آرشیو ساعتی وجود ندارد | backend / یکپارچهسازی |
archive_delivery_failure | آرشیو ساخته شده اما تحویل نشده است | backend / یکپارچهسازی |
archive_incomplete | آرشیو ناقص است | سرویس اندازهگیری |
abnormal_session_length | مدت نشستها ناهنجار است | ارتباطات / یکپارچهسازی |
battery_low | ذخیرهٔ باتری بهطور بحرانی کم است | سرویس |
battery_unknown | وضعیت باتری نامعلوم است | سرویس / یکپارچهسازی |
passport_incomplete | دادههای شناسنامه ناقص است | اندازهشناسی |
registry_ghost | شیء از نظر منطقی وجود دارد اما از نظر فیزیکی تأیید نشده است | Registry |
registry_duplicate | تعارض یا تکرار شناسهها | Registry |
pressure_out_of_range | فشار بیرون از بازهٔ مجاز | بهرهبرداری |
pressure_sensor_stuck | حسگر فشار در شرایط دینامیک مورد انتظار تغییر نمیکند | اندازهشناسی / سرویس |
temperature_out_of_range | دما بیرون از بازهٔ مجاز | بهرهبرداری |
data_quality_degraded | کیفیت داده اجازهٔ تحلیل قابل اتکا نمیدهد | یکپارچهسازی |
firmware_regression | مشکلات به نسخهٔ Firmware مرتبطاند | Firmware / backend |
tampering_suspected | نشانههایی از دستکاری احتمالی یافت شد | امنیت / اندازهشناسی |
leak_suspected | نشانههای غیرمستقیم نشتی احتمالی یافت شد | بهرهبرداری |
topology_dependency_failure | نشانهها ناشی از خرابی یک مؤلفهٔ وابستهٔ مشترکاند | backend / زیرساخت |
نسخهبندی Canonها
تغییر متن یا ترجمه، مستلزم تغییر شناسه نیست.
نسخهٔ تازهٔ Canon زمانی لازم است که یکی از این موارد تغییر کند:
- معنای کسبوکاری؛
- قاعدهٔ تخصیص؛
- معیار actionability؛
- روش راستیآزمایی؛
- اصل SLA؛
- منطق ادغام با مشکلات دیگر.
تحلیل کیفیت Detectorها
Operational Health Matrix نهتنها تجهیزات، بلکه کیفیت الگوریتمهای تحلیلی خود را نیز ارزیابی میکند.
سامانه برای هر Detector این موارد را محاسبه میکند:
- Accuracy؛
- Precision؛
- Recall؛
- False Positive Rate؛
- False Negative Rate؛
- میانگین سطح اطمینان؛
- Drift؛
- Stability؛
- میانگین زمان راستیآزمایی؛
- نرخ پذیرش.
چنین رویکردی امکان میدهد مدل تحلیلی پلتفرم IIoT پیوسته بهبود یابد، بیآنکه تکرارپذیری نتایج آسیب ببیند.
خودِ سبد Detectorها بر پایهٔ نقشهٔ راهی مرحلهای تکامل مییابد: Detectorهای تازه در قالب موجها معرفی میشوند و گشایش هر موج به آمادگی APIهای زیرین پلتفرم گره خورده است.
موضوعات مرتبط
آیا این صفحه مفید بود؟
از بازخورد شما سپاسگزاریم!