لایه جمعآوری داده
ساختار لایه جمعآوری داده در پلتفرم IIoT، سرویسهای پسزمینهٔ آن، اصول تبادل داده، و تعامل با لایهٔ مدیریت.
ساختار و ترکیب لایهٔ جمعآوری داده
لایهٔ جمعآوری داده یکی از مؤلفههای کلیدی پلتفرم IIoT است که یکپارچهسازی با دستگاهها را فراهم میکند. این لایه شامل مجموعهای از برنامههای تخصصی است که هر یک برای تعامل با نوع مشخصی از دستگاههای IoT (کنتورها، حسگرها و مانند آن) طراحی شدهاند. این برنامهها بهصورت سرویسهای شبکه عمل میکنند، اتصالهای ورودی را از طریق درگاههای اختصاصی مدیریت مینمایند و انتقال داده میان دستگاهها و پلتفرم را برعهده دارند. این معماری مقیاسپذیری و انعطافپذیری در کار با تجهیزات ناهمگن را تضمین میکند.
ساختار و ترکیب برنامههای لایهٔ جمعآوری داده در ادامه بهطور خلاصه نشان داده شده است:
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 انجام میشود و هر سرویس جمعآوری، پروتکل تبادل کاربردی خاص خود را برای پشتیبانی از نوع مشخصی از دستگاه IoT پیادهسازی میکند.
این سرویسها چند ویژگی معماری مشترک دارند که در ادامه شرح داده شدهاند.
ویژگیهای معماری
- هر کانتینر شامل برنامهای تخصصی برای یک پروتکل مشخص است.
- برای کاهش سربار، از تصاویر پایهٔ سبک استفاده میشود (
alpineدر پیکربندی پایه). با این حال، امکان ساخت تصاویر برای سیستمعامل مشتری نیز وجود دارد. - برای مدیریت وابستگیهای میان سرویسها (مانند دسترسی به پایگاه داده)، بخشهای
depends_onوhealth-checkدر Docker Compose مشخص میشوند. - سرویسهای پسزمینهٔ compose در چند نمونه (نسخههای همتا) اجرا میشوند تا بار توزیع شود. در این حالت، هر سرویس جمعآوری میتواند دهها هزار اتصال را بهطور همزمان پشتیبانی کند.
- یک متعادلکننده (HAProxy، Nginx Stream) ترافیک را با استفاده از الگوریتمهای Round Robin یا Least Connections به سرویسهای در دسترس هدایت میکند.
- در محیطهای ابری میتوان مقیاسبندی خودکار مبتنی بر سنجهها (CPU، تعداد اتصالها) را افزود.
- تمام ارتباطات با دستگاهها بهتفصیل در فایلها ثبت میشود تا در صورت شناسایی مشکلات و خرابیها، قابل تحلیل باشد.
اصول تبادل داده
نموداری از یک نشست ارتباطی میان دستگاه IoT و سرویس جمعآوری در ادامه آمده است:
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اصول سازماندهی تبادل داده:
-
آغاز نشست ارتباطی.
یک نشست ارتباطی همواره توسط دستگاه IoT آغاز میشود. پس از برقراری اتصال به سرویس جمعآوری داده، دستگاه یک بستهٔ شناسایی ارسال میکند. -
رویهٔ احراز هویت
سرویس جمعآوری داده، دستگاه را احراز هویت میکند. در صورت موفقیت احراز هویت، اقدامات زیر را انجام میدهد:- بازیابی پیکربندی ذخیرهشدهٔ دستگاه از پایگاه داده.
- ارسال تنظیمات جاری رابط به دستگاه.
-
انتقال داده
بر اساس درخواست دریافتشده، دستگاه موارد زیر را به سرور جمعآوری منتقل میکند:- قرائتهای جاری دستگاه.
- رکوردهای بایگانیشده (در صورت وجود).
-
زمانبندی نشست بعدی
پس از تکمیل دریافت داده، سرویس جمعآوری:- برچسب زمانی نشست بعدی را تولید میکند.
- برچسب زمانی نشست بعدی را به دستگاه ارسال میکند.
- قطع اتصال را آغاز مینماید.
-
پردازش و ذخیرهسازی داده
اطلاعات دریافتشده:- در قالب اشیای 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)]پیکربندی دستگاه
پیکربندی دستگاه شامل اطلاعات زیر است:
- تاریخهای آخرین قرائتها بهتفکیک بایگانی: ساعتی، روزانه، ماهانه. این پارامترها تاریخی را مشخص میکنند که دادههای بایگانی متناظر باید از آن تاریخ بهبعد خوانده شوند.
- کد دستگاه اندازهگیری (برای دستگاههای IoT که از پروتکل Type-T استفاده میکنند). این پارامتر تنها برای سرویسهای جمعآوری پشتیبان پروتکل Type-T لازم است و به سرور جمعآوری میگوید که برای کار با دستگاه از کدام الگوریتم استفاده کند.
- سرعت درگاه سریال (برای دستگاههای IoT که با پروتکل Type-T کار میکنند). این پارامتر به دستگاه IoT میگوید که با چه سرعتی باید با کنتور ارتباط برقرار کند. سرویس جمعآوری آن را در آغاز نشست تبادل ارسال میکند.
- زمانبندی ارتباط. زیرسیستم مدیریت تمام زمانبندیها را در یک پایگاه دادهٔ میانی ذخیره میکند و سرویس جمعآوری، نزدیکترین تاریخ را از میان زمانبندیهای دریافتشده محاسبه کرده و به دستگاه ارسال مینماید.
- فرمانهای کنترل دستگاه. بسته به نوع دستگاه IoT و قابلیتهای آن، فرمانهای مدیریت شامل موارد زیر است:
- فرمانی برای بهروزرسانی نرمافزار بخش تلهمتری دستگاه IoT. با دریافت این فرمان، دستگاه میانافزار جدید را از سرور دانلود کرده و بهروزرسانی را انجام میدهد.
- فرمانی برای بازخوانی پیکربندی دستگاه اندازهگیری.
- فرمانی برای بستن یا باز کردن شیر (در صورتی که شیری وجود داشته باشد و توسط نرمافزار دستگاه IoT پشتیبانی شود).
- فرمانی برای تنظیم پارامترهای عملکردی دستگاه اندازهگیری (وابسته به مدل).
- فرمانی برای راهاندازی مجدد دستگاه IoT.
بخش اصلی پیکربندی دستگاه در یک پایگاه دادهٔ میانی به قالب JSON ذخیره میشود.
نمونهای از پیکربندی در ادامه آمده است:
{
"settings": "1",
"day_event": 1706140800,
"hour_event": 1706140800,
"month_event": 1673857740,
"net_address": 58
}در اینجا day_event، hour_event و month_event بهترتیب برچسبهای زمانی به قالب unixtime مربوط به آخرین رکوردهای ذخیرهشدهٔ بایگانیهای روزانه، ساعتی و ماهانه هستند.
زمانبندیها بهطور جداگانه و باز هم به قالب JSON ذخیره میشوند. رشتهٔ زمانبندی به قالب CRON تشکیل و پردازش میشود. این رویکرد انعطافپذیری در تنظیم و پردازش هر نوع زمانبندی را فراهم میکند.
نمونهای از ذخیرهٔ چند زمانبندی برای یک دستگاه در ادامه آمده است:
[
{ "crontab": "10 * * * *", "schedule_id": 6 },
{ "crontab": "40 * * * *", "schedule_id": 7 }
]طبق این زمانبندیها، دستگاه باید در دقایق ۱۰ و ۴۰ هر ساعت متصل شود. خود سرویس مناسبترین زمانبندی را در لحظهٔ ارتباط با دستگاه تعیین کرده و نزدیکترین مورد را ارسال میکند.
موضوعات مرتبط
آیا این صفحه مفید بود؟
از بازخورد شما سپاسگزاریم!