فصل چهارم/ بخش اول : اجرای پروژه، امنیت و عیب‌یابی ارتباط صنعتی

آموزش کاربردی پروتکل MQTT در اتوماسیون صنعتی

هدف فصل

هدف این فصل، به‌کارگیری عملی مفاهیم سه فصل گذشته در طراحی، راه‌اندازی و نگهداری یک سامانه ارتباط صنعتی است.

در این فصل، یک پروژه نمونه را از مرحله انتخاب تجهیزات و تعیین روش ارتباط تا برنامه‌نویسی، آزمایش، امنیت، عیب‌یابی و تحویل نهایی دنبال می‌کنیم.

مقدمه

در فصل اول با مفاهیم پایه پروتکل MQTT، نقش بروکر، کلاینت‌ها و مدل انتشار و اشتراک آشنا شدیم. در فصل دوم، روش نام‌گذاری تاپیک‌ها، طراحی محتوای پیام‌ها و تبدیل داده‌های صنعتی به قالب‌های قابل‌استفاده را بررسی کردیم. در فصل سوم نیز آموختیم چگونه کیفیت تحویل پیام، قطع ارتباط، نگهداری نشست و اجرای قابل‌پیگیری فرمان‌ها را مدیریت کنیم.

اکنون می‌خواهیم این مفاهیم را در یک پروژه صنعتی واقعی‌نما به کار بگیریم.

فرض کنید در یک کارخانه بسته‌بندی، چند تجهیز وظیفه اندازه‌گیری دما، فشار، وضعیت موتور و شمارنده تولید را بر عهده دارند. اطلاعات این تجهیزات باید در اتاق کنترل نمایش داده شوند و هم‌زمان در یک پایگاه داده ثبت شوند. همچنین اپراتور باید بتواند از طریق نمایشگر، درخواست روشن یا خاموش‌شدن موتور و تغییر بعضی مقدارهای تنظیمی را ارسال کند.

در چنین پروژه‌ای، صرف انتخاب یک بروکر و متصل‌کردن چند کلاینت به آن کافی نیست.

ابتدا باید مشخص کنیم اطلاعات از چه تجهیزی تولید می‌شوند، با چه پروتکلی به کنترلر می‌رسند و در چه نقطه‌ای به پیام MQTT تبدیل می‌شوند. سپس باید ساختار تاپیک‌ها، نوع داده‌ها، مجوزهای ارتباط، شرایط ارسال فرمان و روش بررسی نتیجه را تعیین کنیم.

پس از راه‌اندازی اولیه، موضوع امنیت مطرح می‌شود. هر تجهیز یا کاربر نباید بتواند به همه اطلاعات کارخانه دسترسی داشته باشد یا به هر دستگاهی فرمان ارسال کند. همچنین داده‌ها و اطلاعات ورود باید در برابر دسترسی غیرمجاز محافظت شوند.

در نهایت، باید بتوانیم مشکلات ارتباطی را شناسایی کنیم. ممکن است اتصال شبکه برقرار باشد اما هیچ داده‌ای به نمایشگر نرسد. ممکن است دما نمایش داده شود، ولی مقدار آن اشتباه باشد. همچنین ممکن است فرمان به کنترلر برسد اما موتور روشن نشود.

عیب‌یابی این وضعیت‌ها زمانی آسان است که از ابتدا ساختار مناسبی برای پروژه در نظر گرفته باشیم.

در این فصل یک پروژه نمونه مشترک را در تمام مراحل دنبال خواهیم کرد تا ارتباط میان طراحی، پیاده‌سازی، امنیت و عیب‌یابی روشن شود.

۱. تعریف پروژه نمونه و نیازهای آن

۱-۱. معرفی پروژه

یک خط تولید بسته‌بندی را در نظر بگیرید که دارای تجهیزات زیر است:

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

سامانه MQTT برای انتقال اطلاعات به نمایشگرها و دریافت درخواست‌های مجاز مورد استفاده قرار می‌گیرد.

۱-۲. نیازهای اندازه‌گیری

اطلاعاتی که باید در سامانه مانیتورینگ نمایش داده شوند، عبارت‌اند از دمای تابلو، دمای محیط، فشار هوای فشرده، وضعیت واقعی موتور، جریان مصرفی موتور، شمارنده تولید و انرژی مصرفی.

برای هر کمیت باید واحد اندازه‌گیری، محدوده معتبر و فاصله مناسب به‌روزرسانی تعیین شود.

برای مثال، دمای تابلو برحسب درجه سلسیوس و فشار هوای فشرده برحسب بار نمایش داده می‌شوند.

۱-۳. نیازهای وضعیت و آلارم

اپراتور باید بتواند وضعیت موتور را مشاهده کند و میان روشن‌بودن واقعی موتور و درخواست روشن‌شدن آن تفاوت قائل شود.

همچنین لازم است هشدارهایی مانند افزایش غیرمجاز دمای تابلو، افت فشار هوای فشرده، خطای درایو و قطع ارتباط با تجهیزات اندازه‌گیری اعلام شوند.

برای هر آلارم باید شرایط فعال‌شدن، شرایط برطرف‌شدن و مسئول تشخیص آن مشخص باشد.

برای مثال، آلارم افت فشار می‌تواند هنگامی فعال شود که فشار برای مدت تعیین‌شده‌ای پایین‌تر از حد مجاز قرار گیرد. استفاده از تأخیر مناسب و هیسترزیس می‌تواند از تغییر مکرر وضعیت آلارم بر اثر نوسان فشار جلوگیری کند.

۱-۴. نیازهای کنترلی

در این پروژه، اچ‌ام‌آی باید امکان ارسال دو نوع درخواست را داشته باشد.

نوع اول، درخواست روشن یا خاموش‌شدن موتور نوار نقاله است.

نوع دوم، تغییر مقدار تنظیمی دمای تابلو برای فعال‌کردن فن تهویه است.

این درخواست‌ها باید تنها در شرایط مجاز پذیرفته شوند.

برای مثال، اگر موتور در حالت کنترل محلی قرار داشته باشد، درخواست راه‌اندازی از راه دور نباید جایگزین فرمان اپراتور محلی شود.

همچنین اگر حفاظت اضافه‌بار فعال باشد، درخواست روشن‌شدن باید رد شود.

۱-۵. نیازهای ثبت داده

سامانه ثبت اطلاعات باید بتواند مقادیر اندازه‌گیری‌شده را همراه زمان ثبت یا اندازه‌گیری ذخیره کند.

اطلاعات تولید، تغییر وضعیت موتور و رخدادهای آلارم نیز باید برای گزارش‌گیری قابل‌بازیابی باشند.

برای داده‌های مهم، باید مشخص شود اگر ارتباط شبکه برای مدتی قطع شد، آیا ازدست‌رفتن نمونه‌ها قابل‌قبول است یا ذخیره محلی ضروری خواهد بود.

۱-۶. جدول نیازمندی‌های پروژه

اعداد این جدول برای پروژه آموزشی انتخاب شده‌اند. در یک کارخانه واقعی باید براساس سرعت فرایند، دقت تجهیزات، ظرفیت ارتباط و الزامات بهره‌برداری تعیین شوند.

۲. انتخاب روش اتصال تجهیزات پروژه

پس از تعیین نیازها باید درباره معماری ارتباط تصمیم بگیریم.

دو روش اصلی وجود دارد: اتصال مستقیم تجهیزات به بروکر و اتصال از طریق یک تجهیز واسط.

۲-۱. اتصال مستقیم پی‌ال‌سی به بروکر

برخی پی‌ال‌سی‌ها دارای قابلیت ارتباط MQTT هستند. این قابلیت ممکن است به‌صورت داخلی یا از طریق یک ماژول ارتباطی و کتابخانه نرم‌افزاری فراهم شده باشد.

در این روش، پی‌ال‌سی مستقیماً نقش کلاینت MQTT را بر عهده می‌گیرد.

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

همچنین می‌تواند مشترک تاپیک‌های فرمان شود و پیام‌های دریافتی را پس از اعتبارسنجی در برنامه کنترل خود پردازش کند.

مزیت اصلی این روش کاهش تعداد تجهیزات واسط است.

اما پی‌ال‌سی باید امکانات لازم برای ساخت پیام، مدیریت ارتباط، اتصال مجدد، رمزنگاری و کنترل خطا را داشته باشد.

همچنین نباید پردازش پیام‌ها باعث اختلال در زمان‌بندی اجرای منطق کنترلی شود.

۲-۲. اتصال از طریق دروازه ارتباطی

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

ممکن است ارتباط آن‌ها از نوع مدباس سریال یا مدباس TCP باشد.

در چنین شرایطی، یک دروازه ارتباطی می‌تواند داده‌های تجهیزات را دریافت کرده و آن‌ها را به پیام MQTT تبدیل کند.

برای مثال، دروازه از طریق مدباس مقدار دمای تابلو را می‌خواند و پیام زیر را منتشر می‌کند:

factory/line1/panel01/telemetry/temperature

{

"value": 38.5,

"unit": "C",

"quality": "good"

}

در مسیر برگشت نیز دروازه می‌تواند درخواست مجاز را از بروکر دریافت کند و پس از بررسی اولیه، آن را از طریق رابط مناسب به کنترلر انتقال دهد.

دروازه ارتباطی ممکن است یک دستگاه صنعتی مستقل، یک رایانه صنعتی یا یک سامانه تعبیه‌شده دارای میکروکنترلر باشد.

۲-۳. استفاده از کامپیوتر صنعتی

کامپیوتر صنعتی می‌تواند علاوه بر تبدیل پروتکل، وظایف دیگری مانند ثبت محلی داده، اجرای نرم‌افزار واسط، نگهداری موقت پیام‌ها و ثبت خطا را انجام دهد.

در پروژه‌های کوچک ممکن است استفاده از یک رایانه صنعتی برای چند وظیفه اقتصادی باشد.

اما باید به پایداری سیستم‌عامل، راه‌اندازی خودکار برنامه‌ها پس از قطع برق، ظرفیت ذخیره‌سازی و شرایط محیط صنعتی توجه شود.

کامپیوتر صنعتی لزوماً جایگزین پی‌ال‌سی برای اجرای منطق کنترلی زمان‌حساس نیست.

۲-۴. معماری انتخاب‌شده برای پروژه

در پروژه نمونه این فصل، پی‌ال‌سی کنترل محلی را انجام می‌دهد و دروازه ارتباطی وظیفه تبادل داده با بروکر را بر عهده دارد.

سنسورهای آنالوگ و ورودی‌های دیجیتال به پی‌ال‌سی متصل هستند. کنتور انرژی نیز از طریق مدباس سریال به پورت مستر پی‌ال‌سی وصل شده است.

دروازه ارتباطی، اطلاعات آماده‌شده در حافظه پی‌ال‌سی را از طریق مدباس TCP می‌خواند.

بنابراین دو مسیر جداگانه داریم:

در این معماری، پی‌ال‌سی نقش مستر باس سریال تجهیزات میدانی را دارد و دروازه به‌عنوان کلاینت مدباس TCP به پی‌ال‌سی دسترسی پیدا می‌کند.

این انتخاب از ایجاد چند مستر مستقل روی یک باس مدباس RTU جلوگیری می‌کند.

اما اگر گیت وی یا دروازه ارتباطی موجود  ارتباط ModBus RTU  به MQTT  را پشتیبانی می کند می توان از یک مسیر ارتباطی به شکل زیر استفاده کرد:

۲-۵. نقش بروکر

بروکر در مسیر تبادل پیام قرار می‌گیرد، اما مسئول اجرای منطق کنترل موتور نیست.

وظیفه بروکر، مدیریت اتصال کلاینت‌ها، ثبت اشتراک‌ها و توزیع پیام‌ها طبق قواعد پروتکل و سیاست‌های دسترسی است.

نمایشگر اچ‌ام‌آی می‌تواند مستقل از برنامه ثبت داده به بروکر متصل شود.

بنابراین اضافه‌کردن یک نرم‌افزار مانیتورینگ جدید الزاماً نیازی به تغییر ارتباط پی‌ال‌سی با تجهیزات میدانی ندارد.

۲-۶. انتخاب روش ارتباط

برای انتخاب میان اتصال مستقیم و دروازه ارتباطی باید مشخص شود چه تجهیزاتی از قبل وجود دارند، کدام پروتکل‌ها در دسترس‌اند، آیا نیاز به ثبت داده در زمان قطعی داریم و چه مقدار پردازش برای تبدیل داده لازم است.

در پروژه‌ای که پی‌ال‌سی از MQTT و قابلیت‌های امنیتی موردنیاز پشتیبانی می‌کند، اتصال مستقیم می‌تواند ساده‌تر باشد.

اما در کارخانه‌ای دارای تعداد زیادی تجهیز قدیمی، دروازه ارتباطی می‌تواند راهکار مناسب‌تری برای توسعه شبکه باشد.

۳. بررسی سازگاری و امکانات پیش از اجرا

پیش از خرید تجهیزات یا شروع برنامه‌نویسی باید مشخصات ارتباطی تمام اجزای پروژه بررسی شوند.

اگر این مرحله انجام نشود، ممکن است پس از نصب تجهیزات متوجه شویم که بعضی قابلیت‌های موردنیاز در دسترس نیستند.

۳-۱. نسخه پروتکل MQTT

ابتدا باید مشخص شود هر کلاینت از چه نسخه‌ای پشتیبانی می‌کند.

برای مثال:

MQTT 3.1.1

MQTT 5.0

در پروژه نمونه ممکن است دروازه از نسخه ۳٫۱٫۱ و نرم‌افزار مانیتورینگ از نسخه پنج استفاده کند.

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

با این حال، قابلیت‌های مخصوص نسخه پنج برای کلاینتی که از نسخه ۳٫۱٫۱ استفاده می‌کند به‌طور خودکار در دسترس نخواهند بود.

۳-۲. کیفیت سرویس

باید بررسی شود که دستگاه چه سطوحی از کیفیت سرویس را پشتیبانی می‌کند.

ممکن است یک کلاینت سبک فقط از سطوح صفر و یک استفاده کند.

همچنین باید اندازه صف پیام‌ها، تعداد پیام‌های در حال تأیید و رفتار کتابخانه هنگام قطع ارتباط بررسی شود.

۳-۳. قابلیت نگهداری پیام و نشست

پشتیبانی از ریتین، پیام وصیت و نشست ماندگار باید بررسی شود.

در کنار این قابلیت‌ها، لازم است محدودیت حافظه و ظرفیت نگهداری پیام‌ها مشخص شود.

برای مثال، اگر یک دستگاه در زمان قطع شبکه تنها اطلاعات محدودی در حافظه موقت خود نگهداری کند، نمی‌توان انتظار داشت تمام اندازه‌گیری‌های چند ساعت را پس از اتصال مجدد ارسال کند.

۳-۴. رمزنگاری

دروازه ارتباطی باید در صورت نیاز بتواند اتصال امن برقرار کند.

برای ارتباط MQTT روی TLS معمولاً از پورت زیر استفاده می‌شود:

8883

اما شماره پورت به‌تنهایی امنیت ایجاد نمی‌کند.

باید بررسی شود که کتابخانه ارتباطی از نسخه مناسب TLS، اعتبارسنجی گواهی سرور و الگوریتم‌های رمزنگاری قابل‌قبول پشتیبانی می‌کند.

در تجهیزات تعبیه‌شده، حافظه و توان پردازشی لازم برای TLS نیز اهمیت دارد.

۳-۵. اندازه پیام

اندازه بیشینه پیام قابل‌ارسال یا قابل‌دریافت باید مشخص شود.

فرض کنید برنامه دروازه، اطلاعات بیست متغیر را در یک پیام جیسون قرار می‌دهد.

اگر اندازه بافر برنامه برای نگهداری این پیام کافی نباشد، ممکن است پیام ناقص ساخته شود یا عملیات ارسال با خطا مواجه شود.

باید طول موضوع، طول محتوا و سربار پردازشی را در طراحی لحاظ کرد.

۳-۶. تعداد اتصال و اشتراک

برخی تجهیزات دارای محدودیت در تعداد اتصال‌های هم‌زمان، تعداد اشتراک‌ها یا اندازه فیلترهای اشتراک هستند.

اگر یک کنترلر قرار است صدها تاپیک را دریافت کند، لازم است این ظرفیت پیش از اجرا آزمایش شود.

۳-۷. بررسی امکانات مدباس

در سمت تجهیزات صنعتی نیز باید مواردی مانند سرعت ارتباط سریال، نوع پاریتی، شناسه اسلیو، فانکشن‌کد، محدوده آدرس رجیسترها و ترتیب بایت‌ها بررسی شود.

یک دروازه ارتباطی مناسب باید بتواند نوع داده را به شکل موردنیاز پروژه تفسیر کند.

۳-۸. جدول سازگاری

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

مهم آن است که در هر مسیر ارتباطی، امکانات دو طرف با یکدیگر سازگار باشند.

۴. تبدیل داده مدباس و تجهیزات سریال به پیام

در بسیاری از پروژه‌های صنعتی، داده‌ها ابتدا در قالب رجیسترهای مدباس در دسترس هستند.

برای استفاده از آن‌ها در MQTT، باید مقدار خام، نوع داده، واحد و اعتبار اندازه‌گیری به‌درستی تفسیر شود.

۴-۱. معرفی رجیسترهای پروژه

فرض کنیم پی‌ال‌سی، اطلاعات فرایند را در رجیسترهای زیر در اختیار دروازه قرار می‌دهد.

این جدول فرضی است و باید با نقشه واقعی رجیسترهای پی‌ال‌سی جایگزین شود.

۴-۲. تفاوت آدرس نمایشی و آدرس پروتکل

در بسیاری از مستندات مدباس، رجیسترهای نگهدارنده با شماره‌هایی مانند 40001 معرفی می‌شوند.

اما در درخواست واقعی مدباس، آدرس اغلب از صفر آغاز می‌شود.

برای مثال، ممکن است رجیستر نمایشی 40001 با آدرس صفر در درخواست پروتکل خوانده شود.

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

بنابراین پیش از اجرا باید مشخص شود نرم‌افزار از شماره مرجع رجیستر استفاده می‌کند یا آفست صفرمبنا.

۴-۳. خواندن رجیسترها

برای خواندن رجیسترهای نگهدارنده، یکی از فانکشن‌کدهای رایج عبارت است از:

Function Code = 03

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

Start Address = 0

Quantity = 8

اگر پی‌ال‌سی داده‌ها را مطابق نقشه فرضی بالا ارائه کند، دروازه می‌تواند مقادیر موردنیاز را دریافت کند.

۴-۴. تبدیل مقدار خام

مقدار دما در رجیستر اول برابر ۳۸۵ است.

طبق قرارداد پروژه، ضریب تبدیل برابر یک‌دهم است:

[
T=\frac{385}{10}=38.5
]

بنابراین دمای مهندسی برابر ۳۸٫۵ درجه سلسیوس خواهد بود.

برای فشار نیز داریم:

[
P=\frac{62}{10}=6.2
]

دروازه پس از تبدیل، پیام مناسب را می‌سازد.

{

  "value": 6.2,

  "unit": "bar",

  "quality": "good"

}

۴-۵. تبدیل سیگنال آنالوگ

اگر مقدار فشار مستقیماً از ورودی جریان ۴ تا ۲۰ میلی‌آمپر به دست آید، تبدیل باید محدوده واقعی سنسور را در نظر بگیرد.

فرض کنیم سنسور دارای محدوده صفر تا ده بار است.

فرمول تبدیل چنین است:

[
P=\frac{I-4}{16}\times10
]

اگر جریان اندازه‌گیری‌شده برابر ۱۳٫۹۲ میلی‌آمپر باشد:

[
P=\frac{13.92-4}{16}\times10=6.2
]

این فرمول زمانی معتبر است که ورودی برحسب میلی‌آمپر اندازه‌گیری شود. اگر کارت آنالوگ مقدار خام دیجیتال تولید کند، ابتدا باید رابطه تبدیل کارت اعمال شود.

۴-۶. تبدیل متغیرهای منطقی

فرض کنیم بیت صفر رجیستر وضعیت موتور نشان‌دهنده روشن‌بودن واقعی موتور باشد.

اگر مقدار رجیستر برابر یک باشد، نتیجه منطقی چنین خواهد بود:

{"running":true}

اگر مقدار بیت صفر صفر باشد:

{"running":false}

اگر رجیستر چند بیت وضعیت داشته باشد، نباید کل مقدار آن را مستقیماً به‌عنوان یک متغیر منطقی تفسیر کرد.

برای مثال، اگر مقدار رجیستر برابر پنج باشد، بیت صفر و بیت دوم فعال هستند.

برنامه باید بیت موردنظر را با عملیات مناسب استخراج کند.

۴-۷. تبدیل متغیرهای چندرجیستری

بعضی متغیرها مانند شمارنده‌های ۳۲ بیتی یا اعداد اعشاری شناور در دو رجیستر ۱۶ بیتی ذخیره می‌شوند.

در این حالت ترتیب رجیسترها و ترتیب بایت‌ها اهمیت دارد.

در نمونه جدول، فرض کردیم رجیستر اول بخش بالای شمارنده و رجیستر دوم بخش پایین آن است.

اگر مقدارها چنین باشند:

High Word = 0

Low Word  = 12540

مقدار نهایی برابر ۱۲۵۴۰ خواهد بود.

اما برای یک تجهیز دیگر، ممکن است ترتیب دو رجیستر معکوس باشد.

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

۴-۸. تشخیص خطای مدباس

فرض کنید دروازه در زمان خواندن رجیسترهای پی‌ال‌سی پاسخی دریافت نکند.

در این شرایط نباید آخرین مقدار دما را به‌عنوان یک اندازه‌گیری تازه منتشر کند.

می‌توان کیفیت داده را به شکل زیر اعلام کرد:

{

  "value": null,

  "unit": "C",

  "quality": "communication_error"

}

اگر آخرین مقدار معتبر نیز نمایش داده می‌شود، باید مشخص باشد که آن مقدار قدیمی است.

۴-۹. تمایز سلامت دروازه با سلامت تجهیزات

دروازه ممکن است به بروکر متصل باشد، اما ارتباط آن با پی‌ال‌سی قطع شده باشد.

بنابراین بهتر است دو وضعیت جداگانه داشته باشیم.

factory/line1/gateway01/connection

factory/line1/plc01/communication

در نتیجه نمایشگر می‌تواند تشخیص دهد که مسیر MQTT فعال است، ولی داده‌های پی‌ال‌سی معتبر نیستند.

۵. آشنایی با نقش ابزارهای واسط

در بسیاری از پروژه‌های صنعتی، پیش از توسعه یک برنامه اختصاصی، می‌توان از ابزارهای نرم‌افزاری برای آزمایش مسیر داده و ساخت نمونه اولیه استفاده کرد.

یکی از ابزارهای شناخته‌شده در این زمینه نرم‌افزار زیر است:

Node-RED

این نرم‌افزار امکان طراحی جریان‌های پردازش پیام را با اتصال اجزای نرم‌افزاری به یکدیگر فراهم می‌کند.

۵-۱. مفهوم جریان پردازش

در محیط نودرد، اطلاعات از یک گره دریافت می‌شود، از گره‌های پردازشی عبور می‌کند و در نهایت به مقصد موردنظر ارسال می‌شود.

برای مثال:

Modbus Read

|

v

Function

|

v

MQTT Out

در این جریان، گره اول داده را دریافت می‌کند.

گره دوم مقدار را تبدیل و محتوای پیام را آماده می‌کند.

گره سوم پیام را به بروکر منتشر می‌کند.

گره‌های ارتباط مدباس ممکن است از طریق بسته‌های تکمیلی نصب شوند و الزاماً جزو گره‌های اصلی نرم‌افزار نیستند.

۵-۲. مثال تبدیل دمای تابلو

فرض کنیم یک گره خواندن مدباس، مقدار خام ۳۸۵ را دریافت کرده و آن را در ویژگی زیر قرار می‌دهد:

msg.payload

در گره پردازش می‌توان مقدار را تبدیل کرد.

const raw = Number(msg.payload);

if (!Number.isInteger(raw)) {

node.error("Invalid Modbus value", msg);

return null;

}

const temperature = raw / 10;

msg.topic =

"factory/line1/panel01/telemetry/temperature";

msg.payload = {

value: temperature,

unit: "C",

quality: "good"

};

msg.qos = 1;

msg.retain = false;

return msg;

این کد فرض می‌کند گره قبلی، مقدار خام یک رجیستر را استخراج کرده است. اگر خروجی گره مدباس به‌صورت آرایه یا شیء باشد، باید ابتدا رجیستر موردنظر انتخاب شود.

۵-۳. انتشار پیام

گره خروجی MQTT با استفاده از موضوع و محتوای پیام، داده را به بروکر ارسال می‌کند.

اگر محتوای پیام یک شیء باشد، گره خروجی می‌تواند آن را به قالب جیسون تبدیل کند.

در نتیجه دریافت‌کننده پیامی مانند نمونه زیر خواهد داشت:

{

"value": 38.5,

"unit": "C",

"quality": "good"

}

۵-۴. دریافت و تبدیل پیام

نودرد می‌تواند نقش مشترک MQTT را نیز بر عهده بگیرد.

برای مثال، می‌توان پیام‌های دمای تابلو را دریافت کرد و در یک نمودار یا پایگاه داده ذخیره کرد.

MQTT In

|

v

JSON

|

v

Validate

|

v

Database

در این مسیر، داده ابتدا دریافت و سپس از نظر قالب و اعتبار بررسی می‌شود.

تنها پس از معتبر شناخته‌شدن پیام، مقدار برای ذخیره یا نمایش استفاده می‌شود.

۵-۵. استفاده در نمونه اولیه و بهره‌برداری

نودرد برای آموزش، آزمایش، تبدیل پیام و ساخت سریع نمونه اولیه مناسب است.

اما برای استفاده در پروژه عملیاتی باید مدیریت خطا، امنیت دسترسی به محیط ویرایش، راه‌اندازی خودکار، نگهداری تنظیمات و بازیابی پس از خرابی نیز در نظر گرفته شود.

همچنین نباید منطق ایمنی یا کنترل زمان‌حساس ماشین را بدون ارزیابی مناسب به یک جریان نرم‌افزاری وابسته کرد.

۶. طراحی منطق ارسال داده در پی‌ال‌سی

در یک پروژه صنعتی، ارسال داده به شبکه نباید عملکرد اصلی کنترلر را مختل کند.

پی‌ال‌سی باید بتواند وظایف کنترلی خود را طبق چرخه زمانی موردنیاز اجرا کند، حتی اگر بروکر در دسترس نباشد.

۶-۱. جداسازی داده فرایند از ارتباط

بهتر است برنامه کنترلر دارای دو بخش منطقی باشد.

بخش اول، ورودی‌ها را خوانده و منطق کنترل محلی را اجرا می‌کند.

بخش دوم، اطلاعات آماده‌شده را در اختیار سامانه ارتباطی قرار می‌دهد.

در معماری پروژه نمونه، دروازه اطلاعات را از حافظه پی‌ال‌سی می‌خواند؛ بنابراین خود پی‌ال‌سی نیازی به ساخت مستقیم پیام MQTT ندارد.

۶-۲. آماده‌سازی داده‌ها

پی‌ال‌سی پس از خواندن سنسورها، مقدارهای مهندسی و وضعیت‌های منطقی را آماده می‌کند.

برای نمونه، دمای تابلو، فشار هوا، وضعیت موتور و آلارم‌ها در ناحیه مشخصی از حافظه قرار می‌گیرند.

اگر مقدارها در چند رجیستر ذخیره می‌شوند، باید اطمینان حاصل شود که دروازه مجموعه‌ای سازگار از داده‌ها را می‌خواند.

در صورت نیاز می‌توان از ناحیه داده تصویری یا سازوکار ثبت هم‌زمان نمونه‌ها استفاده کرد.

۶-۳. زمان‌بندی انتشار

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

اما لازم نیست هر بار تمام اطلاعات را منتشر کند.

برای مثال، اگر دمای تابلو از آخرین مقدار منتشرشده کمتر از نیم درجه تغییر کرده باشد، می‌توان انتشار را تا رسیدن به حد تغییر یا پایان فاصله زمانی مجاز به تعویق انداخت.

شرط نمونه:

abs(current - last_published) >= 0.5

یا:

elapsed_time >= 30 seconds

در این روش، دو شرط به‌صورت جایگزین عمل می‌کنند.

۶-۴. بررسی کیفیت اندازه‌گیری

پیش از انتشار، دروازه باید کیفیت داده را بررسی کند.

اگر خواندن مدباس ناموفق باشد، وضعیت ارتباط نامعتبر است.

اگر سنسور خطای داخلی اعلام کند، ممکن است ارتباط مدباس سالم باشد ولی خود اندازه‌گیری نامعتبر باشد.

این دو وضعیت بهتر است با کیفیت‌های متفاوت گزارش شوند.

۶-۵. ساخت پیام

فرض کنیم دمای تابلو معتبر و برابر ۳۸٫۵ درجه است.

پیام می‌تواند چنین باشد:

{

  "value": 38.5,

  "unit": "C",

  "quality": "good",

"timestamp": "2026-10-17T10:30:00Z",

  "seq": 1254

}

زمان باید براساس ساعت معتبر دستگاه تعیین شود و شماره ترتیب مطابق قرارداد پروژه افزایش یابد.

۶-۶. بررسی نتیجه انتشار

در سطح کیفیت سرویس یک، دریافت تأیید MQTT می‌تواند تکمیل مرحله ارسال به بروکر را نشان دهد.

اما این تأیید به معنی ذخیره‌شدن در پایگاه داده یا نمایش موفق روی اچ‌ام‌آی نیست.

اگر ثبت قطعی اطلاعات اهمیت دارد، سامانه ثبت داده باید سازوکار تأیید کاربردی مستقل داشته باشد.

۶-۷. رفتار هنگام قطع ارتباط

اگر ارتباط با بروکر قطع شود، دروازه نباید تلاش اتصال مجدد را به‌صورت نامحدود و بدون فاصله انجام دهد.

همچنین لازم است سیاست ذخیره داده مشخص باشد.

برای مثال، می‌توان آخرین مقدار جاری را برای مانیتورینگ حفظ کرد و داده‌های تاریخی مهم را در حافظه غیر‌فرار ثبت کرد.

پس از بازیابی ارتباط، اطلاعات جاری باید تازه شوند و ارسال تاریخچه نیز طبق یک برنامه کنترل‌شده انجام شود.

۶-۸. نمونه توالی برنامه

Read PLC registers

|

v

Validate Modbus response

|

v

Convert raw values

|

v

Update data quality

|

v

Check change / timer

|

v

Build MQTT payload

|

v

Publish message

|

v

Track delivery result

این مراحل بهتر است به‌صورت غیرمسدودکننده طراحی شوند تا خرابی شبکه باعث توقف اجرای برنامه اصلی کنترل نشود.

۷. طراحی منطق دریافت پیام و فرمان

مسیر دریافت فرمان حساس‌تر از مسیر انتشار داده‌های اندازه‌گیری است.

در انتشار دما، دریافت یک مقدار نامعتبر ممکن است به نمایش اشتباه منجر شود؛ اما در مسیر فرمان، پردازش نادرست می‌تواند باعث تغییر وضعیت تجهیزات شود.

بنابراین هر پیام دریافتی باید پیش از اجرا بررسی شود.

۷-۱. دریافت پیام

فرض کنیم نمایشگر پیام زیر را منتشر می‌کند:

factory/line1/motor01/cmd/run

محتوا:

{

"command_id": "CMD-12540",

  "value": true,

"timestamp": "2026-10-17T10:30:00Z",

"valid_for_ms": 5000

}

دروازه ارتباطی مشترک این موضوع است و درخواست را دریافت می‌کند.

۷-۲. بررسی قالب

ابتدا باید مشخص شود محتوا ساختار معتبر جیسون دارد.

اگر پیام ناقص باشد یا فیلد ضروری وجود نداشته باشد، نباید به مرحله اجرا وارد شود.

برای مثال، پیام زیر ناقص است:

{"command_id":"CMD-12540"}

در این نمونه، مقدار فرمان مشخص نشده است.

۷-۳. بررسی نوع داده

اگر فیلد فرمان باید منطقی باشد، دریافت رشته متنی به‌جای مقدار منطقی باید طبق قرارداد بررسی شود.

نمونه صحیح:

{"value":true}

نمونه متفاوت:

{"value":"true"}

در نمونه دوم مقدار از نوع رشته است.

برنامه نباید بدون قرارداد روشن، تمام رشته‌های متنی را به فرمان منطقی تبدیل کند.

۷-۴. بررسی محدوده

برای فرمان تغییر مقدار تنظیمی، باید مقدار در محدوده مجاز باشد.

فرض کنیم مقدار تنظیمی دما می‌تواند بین ۲۰ تا ۵۰ درجه باشد.

Minimum Setpoint = 20

Maximum Setpoint = 50

اگر پیام زیر دریافت شود:

{"value":80}

برنامه باید آن را رد کند.

۷-۵. بررسی اعتبار زمانی

فرمان باید در محدوده زمانی مجاز دریافت و پردازش شود.

اگر درخواست برای پنج ثانیه معتبر است، دستگاه نباید پس از چند دقیقه قطعی شبکه، آن را بدون بررسی اجرا کند.

در این روش، صحت ساعت دستگاه و روش محاسبه اعتبار اهمیت دارد.

۷-۶. جلوگیری از اجرای دوباره

هر فرمان می‌تواند شناسه مستقل داشته باشد.

اگر همان شناسه دوباره دریافت شود، برنامه باید بررسی کند که آیا درخواست قبلاً پردازش شده است یا خیر.

در صورت وجود نتیجه قبلی، می‌توان همان نتیجه را گزارش کرد؛ بدون اینکه فرمان دوباره اجرا شود.

برای فرمان‌های مهم، این اطلاعات باید متناسب با نیاز پروژه در حافظه ماندگار یا در منطق کنترلر قابل‌بازیابی باشند.

۷-۷. بررسی مجوز

اینکه یک پیام از طریق بروکر به دروازه رسیده است، به‌تنهایی مجازبودن اجرای آن را تضمین نمی‌کند.

بروکر باید مجوز انتشار تاپیک را بررسی کند و سامانه اجرایی نیز باید شرایط کاربردی را کنترل کند.

۷-۸. بررسی اینترلاک‌ها

پی‌ال‌سی باید مستقل از دروازه بررسی کند که موتور در وضعیت مجاز قرار دارد.

برای مثال، اگر حفاظت اضافه‌بار فعال باشد، فرمان روشن‌شدن رد می‌شود.

حتی اگر دروازه درخواست را معتبر تشخیص داده باشد، کنترلر نباید بررسی‌های محلی را حذف کند.

۷-۹. پاسخ به درخواست

اگر درخواست معتبر باشد:

{

"command_id": "CMD-12540",

"accepted": true,

  "status": "accepted"

}

اگر درخواست رد شود:

{

"command_id": "CMD-12540",

"accepted": false,

  "status": "rejected",

  "reason": "interlock_active"

}

این پاسخ‌ها نتیجه بررسی درخواست را اعلام می‌کنند و با بازخورد واقعی موتور تفاوت دارند.

۸. نمایش صحیح وضعیت فرایند در اچ‌ام‌آی

اچ‌ام‌آی رابط میان اپراتور و تجهیزات صنعتی است.

اگر وضعیت‌ها در نمایشگر به‌درستی تفکیک نشوند، اپراتور ممکن است تصور نادرستی از شرایط واقعی ماشین داشته باشد.

۸-۱. تفاوت فرمان با وضعیت واقعی

فرض کنید اپراتور دکمه روشن‌شدن موتور را فشار می‌دهد.

در این لحظه، وضعیت درخواست چنین است:

Requested Run = true

اما وضعیت واقعی موتور ممکن است همچنان خاموش باشد:

Actual Running = false

بنابراین نمایشگر نباید فقط به دلیل فشرده‌شدن دکمه استارت، رنگ موتور را به وضعیت روشن تغییر دهد.

۸-۲. مراحل نمایش فرمان

می‌توان وضعیت درخواست را در سه مرحله نشان داد:

درخواست ارسال شده است: نمایشگر منتظر نتیجه بررسی فرمان است.

فرمان پذیرفته شده است: کنترلر اعلام کرده شرایط اولیه اجرای فرمان برقرار است.

موتور واقعاً روشن شده است: بازخورد معتبر، انجام عمل را تأیید کرده است.

اگر نتیجه سوم دریافت نشود، نمایشگر باید وضعیت نامشخص یا خطا را نشان دهد.

۸-۳. نمایش کیفیت داده

فرض کنید آخرین دمای معتبر تابلو ۳۸٫۵ درجه بوده است.

اگر ارتباط با سنسور قطع شود، نمایشگر می‌تواند همان عدد را نگهداری کند، اما باید مشخص کند مقدار تازه نیست.

برای مثال:

Temperature: 38.5 °C

Quality: STALE

یا در صورت نداشتن مقدار قابل‌اعتماد:

Temperature: ---

Quality: COMMUNICATION ERROR

هدف این است که اپراتور مقدار قدیمی را با اندازه‌گیری فعلی اشتباه نگیرد.

۸-۴. نمایش وضعیت ارتباط

بهتر است وضعیت‌های زیر از یکدیگر تفکیک شوند:

برای مثال، اگر اچ‌ام‌آی به بروکر متصل باشد ولی دروازه خاموش شده باشد، نمایشگر باید بتواند همین تفاوت را نشان دهد.

۸-۵. رفتار هنگام دریافت داده قدیمی

در طراحی نمایشگر می‌توان برای هر داده، یک زمان اعتبار تعیین کرد.

فرض کنیم قرار است دمای تابلو حداکثر هر سی ثانیه منتشر شود.

می‌توان قراردادی تعریف کرد که اگر در مدت مشخصی داده تازه و معتبر دریافت نشد، وضعیت نمایش به داده قدیمی تغییر کند.

این فاصله باید با زمان انتشار، تأخیر شبکه و شرایط قطعی هماهنگ باشد.

نباید صرف دریافت آخرین پیام ریتین‌شده را به‌عنوان تأیید تازگی اندازه‌گیری در نظر گرفت.

۹. اجرای نمونه فرمان موتور و تغییر مقدار تنظیمی

در این بخش دو عملیات کاربردی را روی پروژه نمونه اجرا می‌کنیم.

عملیات اول، روشن‌کردن موتور نوار نقاله است.

عملیات دوم، تغییر مقدار تنظیمی دمای تابلو است.

۹-۱. فرمان روشن‌شدن موتور

اپراتور در اچ‌ام‌آی دکمه استارت موتور را فشار می‌دهد.

موضوع فرمان:

factory/line1/motor01/cmd/run

محتوا:

{

"command_id": "CMD-12540",

  "value": true,

"timestamp": "2026-10-17T10:30:00Z",

"valid_for_ms": 5000

}

دروازه پیام را دریافت می‌کند.

پس از بررسی اولیه، درخواست را از طریق مسیر ارتباطی کنترل‌شده به پی‌ال‌سی منتقل می‌کند.

در این پروژه، دروازه می‌تواند برای انتقال درخواست از یک ناحیه اختصاصی تبادل فرمان در حافظه پی‌ال‌سی استفاده کند.

بهتر است این ناحیه شامل شناسه درخواست، نوع فرمان، مقدار و وضعیت تأیید باشد.

جزئیات رجیسترهای این ناحیه باید در نقشه حافظه پی‌ال‌سی تعریف شوند.

۹-۲. بررسی شرایط محلی

پی‌ال‌سی پیش از اجرا باید موارد زیر را بررسی کند:

بررسی توقف اضطراری و وظایف ایمنی باید در معماری ایمنی مستقل و مناسب ماشین انجام شود. MQTT نباید مسیر اصلی اجرای وظیفه ایمنی باشد.

۹-۳. اجرای فرمان

اگر شرایط مجاز باشند، پی‌ال‌سی فرمان راه‌اندازی را به درایو ارسال می‌کند.

اما نتیجه واقعی باید با بازخورد مشخص شود.

برای مثال، وضعیت کار درایو یا بازخورد معتبر دیگری می‌تواند نشان دهد موتور وارد حالت کار شده است.

موضوع وضعیت:

factory/line1/motor01/status/running

محتوا:

{"running":true}

۹-۴. اعلام نتیجه

در صورت موفقیت:

{

"command_id": "CMD-12540",

  "status": "completed",

  "running": true

}

در صورت خطا:

{

"command_id": "CMD-12540",

  "status": "failed",

  "reason": "drive_fault"

}

۹-۵. تغییر مقدار تنظیمی دما

اکنون فرض کنیم اپراتور می‌خواهد مقدار تنظیمی راه‌اندازی فن تابلو را از ۴۵ درجه به ۴۲٫۵ درجه کاهش دهد.

موضوع:

factory/line1/panel01/cmd/setpoint

محتوا:

{

"command_id": "CMD-12541",

"parameter": "fan_start_temperature",

  "value": 42.5,

  "unit": "C",

"timestamp": "2026-10-17T10:32:00Z",

"valid_for_ms": 5000

}

دروازه و پی‌ال‌سی باید نام پارامتر، نوع مقدار، محدوده مجاز و سطح دسترسی را بررسی کنند.

اگر مقدار پذیرفته شود، کنترلر باید آن را مطابق روش ذخیره‌سازی تعیین‌شده در برنامه اعمال کند.

در صورت نیاز به ماندگاری تنظیم پس از قطع برق، روش نوشتن در حافظه غیر‌فرار باید به‌صورت جداگانه طراحی شود.

۹-۶. تأیید مقدار جدید

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

{

"command_id": "CMD-12541",

"accepted": true

}

اما برای تأیید اعمال واقعی مقدار، بهتر است پی‌ال‌سی مقدار جاری تنظیمی را دوباره گزارش کند.

factory/line1/panel01/status/fan_setpoint

{

  "value": 42.5,

  "unit": "C"

}

نمایشگر پس از دریافت این مقدار می‌تواند نتیجه را نشان دهد.

۹-۷. تفاوت فرمان مقدار مطلق با فرمان افزایشی

فرمان زیر مقدار تنظیمی را روی یک عدد مشخص قرار می‌دهد:

{"value":42.5}

اما فرمانی مانند «مقدار تنظیمی را دو درجه افزایش بده» به وضعیت فعلی وابسته است.

اگر چنین فرمانی دوبار اجرا شود، نتیجه نهایی ممکن است چهار درجه افزایش باشد.

بنابراین فرمان‌های مقداری مطلق، در موارد مناسب، مدیریت اجرای تکراری را ساده‌تر می‌کنند.

البته برای هر دو نوع فرمان باید مجوز، اعتبار زمانی و نتیجه واقعی بررسی شود.

دربخش دوم فصل چهار موارد زیر بررسی می شود

۱۰. تعیین حدود استفاده در کنترل صنعتی

جایگاه منطق کنترل محلی، رفتار دستگاه هنگام قطع شبکه و استقلال وظایف ایمنی.

۱۱. شناخت امنیت ارتباط به زبان ساده

تفاوت احراز هویت، اجازه دسترسی و رمزنگاری؛ نقش نام کاربری، رمز عبور، ارتباط TLS و گواهی.

۱۲. محدودکردن دسترسی کاربران و تجهیزات به تاپیک‌ها

مثال تجهیزی با اجازه انتشار وضعیت و اپراتوری با اجازه ارسال فرمان‌های مشخص.

۱۳. طراحی شبکه و دسترسی از راه دور

تفکیک شبکه صنعتی، فایروال، ارتباط VPN، نگهداری اطلاعات ورود و اهمیت زمان صحیح سیستم.

۱۴. آزمایش ارتباط پیش از اتصال به فرایند واقعی

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

۱۵. عیب‌یابی مرحله‌به‌مرحله ارتباط

بررسی شبکه، آدرس و پورت، رمزنگاری، ورود، شناسه کلاینت، اشتراک، تاپیک، پیام و منطق برنامه.

۱۶. شناخت خطاهای پرتکرار و نشانه‌های آن‌ها

اتصال بدون دریافت داده، قطع و وصل متناوب، مقدار قدیمی، پیام تکراری، اختلاف واحد و اجرا‌نشدن فرمان.

۱۷. انجام آزمون‌های تحویل پروژه

قطع کابل، راه‌اندازی مجدد تجهیزات، توقف بروکر، ارسال پیام نامعتبر و بررسی بازیابی سیستم.

۱۸. مستندسازی، نگهداری و توسعه آینده

تهیه جدول تاپیک‌ها و متغیرها، ثبت تنظیمات و نسخه‌ها، ثبت خطاها و نسخه پشتیبان؛ معرفی کوتاه Sparkplug برای استانداردسازی داده صنعتی.