طبقة جمع البيانات

بنية طبقة جمع البيانات في منصة IIoT، وخدماتها الخفية (daemons)، ومبادئ تبادل البيانات، وتفاعلها مع طبقة الإدارة.

بنية طبقة جمع البيانات وتكوينها

طبقة جمع البيانات هي مكوّن أساسي من منصة IIoT يوفّر التكامل مع الأجهزة. وهي تتضمّن مجموعة من التطبيقات المتخصّصة، صُمّم كلّ منها للتفاعل مع نوع محدّد من أجهزة إنترنت الأشياء (العدّادات، والمستشعرات، وما إلى ذلك). تعمل هذه التطبيقات كخدمات شبكية، تتولّى الاتصالات الواردة عبر منافذ مخصّصة وتدير نقل البيانات بين الأجهزة والمنصّة. تضمن هذه البنية قابلية التوسّع والمرونة عند العمل مع معدّات غير متجانسة.

فيما يلي ملخّص لبنية تطبيقات طبقة جمع البيانات وتكوينها:

flowchart TD
    A(Household energy meters) <-->|Data transfer| B("Data collection daemon (Type-J)")
    C(Industrial energy meters) <-->|Data transfer| D("Data collection daemon (Type-T)")
    E(Smart sensors) <-->|Data transfer| F("Data collection daemon (DDT)")
    subgraph " "
    B("Data collection daemon (Type-J)") <--> I{"Balancer (Pgbouncer)"}
    D("Data collection daemon (Type-T)") <--> I{"Balancer (Pgbouncer)"}
    F("Data collection daemon (DDT)") <--> I{"Balancer (Pgbouncer)"}
    X@{ shape: braces, label: "Data Polling Subsystem" }
    end
    I{"Balancer (Pgbouncer)"} <--> J[(DBMS PostgreSQL)]

تُجرى عمليات التبادل مع الأجهزة الطرفية عبر اتصال TCP، حيث تطبّق كلّ خدمة جمع خفيّة بروتوكول التبادل التطبيقي الخاصّ بها لخدمة نوع معيّن من أجهزة إنترنت الأشياء.

تشترك هذه الخدمات الخفية في عدّة سمات معمارية مشتركة، موضّحة أدناه.

السمات المعمارية

  • تتضمّن كلّ حاوية تطبيقًا متخصّصًا في بروتوكول معيّن.
  • تُستخدم صور أساس خفيفة (alpine في التكوين الأساسي) لتقليل الحِمل الإضافي. ومع ذلك، من الممكن بناء صور لنظام تشغيل العميل.
  • لإدارة التبعيّات بين الخدمات (مثل الوصول إلى قاعدة البيانات)، تُحدَّد أقسام depends_on وhealth-check في Docker Compose.
  • تعمل خدمات compose الخفية بنسخ متعدّدة (replicas) لتوزيع الحِمل. وفي هذه الحالة، يمكن لكلّ خدمة جمع خفيّة أن تخدم عشرات الآلاف من الاتصالات في آنٍ واحد.
  • يوجّه موازِن (HAProxy، Nginx Stream) حركة المرور إلى الخدمات الخفية المتاحة باستخدام خوارزميتي Round Robin أو Least Connections.
  • في البيئات السحابية، يمكنك إضافة توسّع تلقائي استنادًا إلى المقاييس (وحدة المعالجة المركزية، عدد الاتصالات).
  • تُسجَّل جميع الاتصالات مع الأجهزة بالتفصيل في ملفّات، بحيث يمكن تحليلها عند اكتشاف المشكلات والأعطال.

مبادئ تبادل البيانات

فيما يلي مخطّط لجلسة اتصال بين جهاز إنترنت الأشياء وخدمة الجمع الخفية:

sequenceDiagram
    autonumber
    participant D as IoT device
    participant I as Data collection <br/>daemon
    Note over I,D: Stages of interaction
    D->>I: Session start, authentication
    I-->>D: Sending request parameters
    D->>I: Data acquisition
    I-->>D: Sending the next session time

مبادئ تنظيم تبادل البيانات:

  • بدء جلسة الاتصال.
    تبدأ جلسة الاتصال دائمًا بمبادرة من جهاز إنترنت الأشياء. وبعد إنشاء الاتصال بخدمة جمع البيانات الخفية، يرسل الجهاز حزمة هوية.

  • إجراء المصادقة
    تتولّى خدمة جمع البيانات الخفية مصادقة الجهاز. وإذا نجحت المصادقة، فإنها تؤدّي:

    • استرجاع تكوين الجهاز المحفوظ من قاعدة البيانات.
    • إرسال إعدادات الواجهة الحالية إلى الجهاز.
  • نقل البيانات
    استنادًا إلى الطلب المستلَم، ينقل الجهاز إلى خادم الجمع:

    • القراءات الحالية للجهاز.
    • السجلّات المؤرشفة (إن وُجدت).
  • جدولة الجلسة التالية
    بعد اكتمال استقبال البيانات، تقوم خدمة الجمع الخفية بما يلي:

    • توليد الطابع الزمني للجلسة التالية.
    • إرسال الطابع الزمني للجلسة التالية إلى الجهاز.
    • بدء إنهاء الاتصال.
  • معالجة البيانات وتخزينها
    تكون المعلومات المستلَمة:

    • مجمّعة في كائنات JSON منظَّمة.
    • مخزّنة في قاعدة بيانات PostgreSQL وسيطة.
    • منسَّقة وفقًا لمواصفات بروتوكول خدمة خفية معيّنة.
  • التكامل مع نظام التحكّم
    تصبح البيانات متاحة للمستوى الأعلى من النظام (نظام الإدارة الفرعي) من أجل:

    • مزيد من المعالجة التحليلية.
    • العرض المرئي في واجهات الإدارة.
    • توليد التقارير الآلية.

التفاعل مع طبقة الإدارة في المنصّة

بنية الترابط بين الأنظمة الفرعية

تتكامل خدمات جمع البيانات الخفية مع نظام المستوى الأعلى (طبقة الإدارة) عبر قاعدة بيانات وسيطة. ولتمكين هذا التفاعل، تُستخدم حاوية Docker تتضمّن نظام إدارة قواعد بيانات PostgreSQL مُنشَرًا.

تُحفَظ نتائج التفاعل الناجح مع الأجهزة تلقائيًا بواسطة الخدمات الخفية في جدول متخصّص داخل القاعدة نفسها، مما يوفّر شفافية في نقل البيانات بين مستوى التحكّم والأجهزة.

يوضَّح مخطّط التفاعل بين الأنظمة الفرعية أدناه:

flowchart LR
A@{ shape: procs, label: "Data Polling Subsystem"} -->|Readings data| B[(DBMS PostgreSQL)]
B[(DBMS PostgreSQL)] -->|Configuration| A@{ shape: procs, label: "Data Polling Subsystem"}
B[(DBMS PostgreSQL)] -->|Readings data| C@{ shape: procs, label: "Control Subsystem"}
C@{ shape: procs, label: "Control Subsystem"} -->|Configuration| B[(DBMS PostgreSQL)]

تكوين الجهاز

يتضمّن تكوين الجهاز المعلومات التالية:

  • تواريخ آخر القراءات حسب الأرشيف: ساعية، ويومية، وشهرية. تشير هذه المعاملات إلى التاريخ الذي ينبغي قراءة بيانات الأرشيف المقابل ابتداءً منه.
  • رمز جهاز القياس (لأجهزة إنترنت الأشياء التي تستخدم بروتوكول Type-T). هذا المعامل مطلوب فقط لخدمات الجمع الخفية التي تخدم بروتوكول Type-T، وهو يُعلِم خادم الجمع بالخوارزمية التي ينبغي استخدامها للعمل مع الجهاز.
  • سرعة المنفذ التسلسلي (لأجهزة إنترنت الأشياء التي تعمل ببروتوكول Type-T). يُعلِم هذا المعامل جهاز إنترنت الأشياء بمدى السرعة التي ينبغي أن يتواصل بها مع العدّاد. وترسله خدمة الجمع الخفية في بداية جلسة التبادل.
  • جدول الاتصال. يحفظ نظام الإدارة الفرعي جميع الجداول في قاعدة بيانات وسيطة، وتحسب خدمة الجمع الخفية أقرب تاريخ من الجداول المستلَمة وترسله إلى الجهاز.
  • أوامر التحكّم بالجهاز. تبعًا لنوع جهاز إنترنت الأشياء وإمكاناته، تشمل أوامر الإدارة:
    • أمر لتحديث برنامج جزء القياس عن بُعد (telemetry) من جهاز إنترنت الأشياء. عند استلام هذا الأمر، يقوم الجهاز بتنزيل البرنامج الثابت الجديد من الخادم وإجراء التحديث.
    • أمر لإعادة قراءة تكوين جهاز القياس.
    • أمر لإغلاق الصمّام أو فتحه (إذا كان الصمّام موجودًا ومدعومًا من برنامج جهاز إنترنت الأشياء).
    • أمر لضبط معاملات تشغيل جهاز القياس (يعتمد على الطراز).
    • أمر لإعادة تشغيل جهاز إنترنت الأشياء.

يُخزَّن الجزء الرئيسي من تكوين الجهاز في قاعدة بيانات وسيطة بتنسيق JSON.

فيما يلي مثال على التكوين:

json
{
  "settings": "1",
  "day_event": 1706140800,
  "hour_event": 1706140800,
  "month_event": 1673857740,
  "net_address": 58
}

هنا day_event وhour_event وmonth_event هي طوابع زمنية بتنسيق unixtime لأحدث السجلّات المحفوظة من الأرشيفات اليومية والساعية والشهرية على التوالي.

تُخزَّن الجداول بشكل منفصل، أيضًا بتنسيق JSON. وتُكوَّن سلسلة الجدول نفسها وتُعالَج بتنسيق CRON. يوفّر هذا النهج مرونة في إعداد أيّ جداول ومعالجتها.

فيما يلي مثال على تخزين عدّة جداول لجهاز:

json
[
  { "crontab": "10 * * * *", "schedule_id": 6 },
  { "crontab": "40 * * * *", "schedule_id": 7 }
]

وفقًا لهذه الجداول، ينبغي أن يتّصل الجهاز عند الدقيقة 10 والدقيقة 40 من كلّ ساعة. وتحدّد الخدمة الخفية نفسها الجدول الأنسب لحظة الاتصال بالجهاز وتنقل أقربها.

مواضيع ذات صلة

آخر تحديث في

هل كانت هذه الصفحة مفيدة؟