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

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

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

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

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

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

۱۰-۱. کنترل محلی

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

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

۱۰-۲. نقش MQTT در کنترل

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

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

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

۱۰-۳. رفتار هنگام قطع ارتباط

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

این رفتار برای همه تجهیزات یکسان نیست.

برای مثال، یک فن تهویه ممکن است طبق تنظیمات محلی به کار خود ادامه دهد.

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

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

۱۰-۴. استقلال سیستم ایمنی

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

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

۱۰-۵. تفاوت مانیتورینگ با کنترل بلادرنگ

ممکن است تأخیر چندثانیه‌ای در نمایش یک دمای محیط قابل‌قبول باشد.

اما همین تأخیر برای یک حلقه کنترل سریع یا یک وظیفه ایمنی غیرقابل‌قبول است.

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

۱۰-۶. معماری مناسب پروژه نمونه

در پروژه ما، پی‌ال‌سی کنترل محلی موتور و فن را اجرا می‌کند.

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

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

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

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

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

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

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

۱۱-۱. احراز هویت

احراز هویت مشخص می‌کند طرف ارتباط چه هویتی دارد.

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

اما نام کاربری به‌تنهایی تضمین نمی‌کند که ارتباط امن است.

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

۱۱-۲. مجوز دسترسی

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

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

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

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

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

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

در MQTT روی TCP معمولاً از TLS برای ایجاد ارتباط امن استفاده می‌شود.

نام متداول این روش:

MQTT over TLS

۱۱-۴. تفاوت رمز عبور با TLS

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

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

بنابراین باید میان احراز هویت و حفاظت از کانال ارتباط تفاوت قائل شویم.

۱۱-۵. نقش گواهی دیجیتال

در ارتباط TLS، کلاینت باید اعتبار گواهی سرور را بررسی کند.

هدف این است که کلاینت به سرور موردنظر متصل شود و صرفاً به هر دستگاهی که در آدرس تعیین‌شده پاسخ می‌دهد اعتماد نکند.

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

همچنین زمان سیستم اهمیت دارد؛ زیرا گواهی‌ها معمولاً دارای دوره اعتبار هستند.

۱۱-۶. محافظت از اطلاعات ورود

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

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

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

۱۱-۷. به‌روزرسانی و نگهداری امنیت

امنیت تنها به راه‌اندازی اولیه محدود نمی‌شود.

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

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

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

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

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

۱۲-۱. اصل حداقل دسترسی

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

برای مثال، کنترلر خط اول نباید بتواند فرمان خط دوم را منتشر کند.

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

۱۲-۲. مجوز دروازه خط اول

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

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

نمونه الگوی انتشار:

factory/line1/+/telemetry/#

factory/line1/+/status/#

factory/line1/+/alarm/#

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

factory/line1/motor01/cmd/#

factory/line1/panel01/cmd/#

این الگوها صرفاً نمونه سیاست دسترسی هستند. نحوه نوشتن قواعد در بروکرهای مختلف یکسان نیست.

۱۲-۳. مجوز اپراتور اچ‌ام‌آی

اچ‌ام‌آی باید بتواند اطلاعات موردنیاز را دریافت کند.

برای مثال:

factory/line1/+/status/#

factory/line1/+/telemetry/#

factory/line1/+/alarm/#

اما مجوز انتشار آن بهتر است فقط به فرمان‌های مشخص محدود شود.

factory/line1/motor01/cmd/run

factory/line1/panel01/cmd/setpoint

۱۲-۴. مجوز ثبت‌کننده داده

نرم‌افزار ثبت اطلاعات معمولاً به دریافت اندازه‌گیری‌ها و رخدادها نیاز دارد.

برای مثال:

factory/+/+/telemetry/#

factory/+/+/alarm/#

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

۱۲-۵. مجوز سامانه مانیتورینگ مرکزی

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

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

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

۱۲-۶. جدول پیشنهادی

۱۲-۷. نکته درباره فیلترهای اشتراک

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

برای مثال، مجوز اشتراک در تمام موضوع‌های زیر:

factory/#

ممکن است بسیار گسترده‌تر از نیاز یک نمایشگر محلی باشد.

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

۱۲-۸. امنیت در سطح برنامه

محدودیت بروکر لازم است، اما کافی نیست.

کنترلر باید همچنان اعتبار درخواست و شرایط محلی اجرای آن را بررسی کند.

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

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

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

۱۳-۱. تفکیک شبکه صنعتی

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

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

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

۱۳-۲. محل نصب بروکر

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

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

هر انتخاب مزایا و محدودیت‌های خود را دارد.

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

اما برای دسترسی از بیرون، باید مسیر امنی طراحی شود.

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

۱۳-۳. جلوگیری از انتشار مستقیم تجهیزات

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

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

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

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

۱۳-۴. استفاده از فایروال

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

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

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

۱۳-۵. دسترسی راه‌دور

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

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

اما اتصال VPN نیز به معنی دسترسی نامحدود نیست.

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

۱۳-۶. ساعت سیستم

در پروژه صنعتی، ساعت صحیح برای چند موضوع اهمیت دارد.

نخست، ثبت زمان اندازه‌گیری‌ها و رخدادها است.

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

سوم، اعتبارسنجی گواهی‌های امنیتی است.

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

۱۳-۷. رفتار هنگام قطع اینترنت

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

در پروژه باید مشخص شود داده‌ها در این مدت کجا نگهداری می‌شوند و کنترل محلی چگونه ادامه پیدا می‌کند.

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

۱۳-۸. ثبت مسیرهای ارتباطی

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

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

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

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

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

۱۴-۱. آماده‌سازی محیط آزمایش

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

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

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

۱۴-۲. آزمایش اتصال

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

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

۱۴-۳. آزمایش انتشار و اشتراک

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

factory/test/panel01/temperature

محتوا:

{"value":25.5,"unit":"C"}

یک کلاینت پیام را منتشر می‌کند.

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

۱۴-۴. آزمایش فیلترهای اشتراک

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

factory/test/panel01/temperature

factory/test/panel02/temperature

factory/test/panel03/temperature

سپس فیلتر زیر را ثبت کرد:

factory/test/+/temperature

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

۱۴-۵. آزمایش ساختار جیسون

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

نمونه معتبر:

{"value":25.5}

نمونه نامعتبر:

{value:25.5}

برنامه دریافت‌کننده باید پیام نامعتبر را تشخیص دهد.

۱۴-۶. آزمایش نوع داده

فرض کنیم برنامه انتظار مقدار عددی دارد.

پیام زیر باید مطابق قرارداد پذیرفته شود:

{"value":25.5}

اما نمونه زیر از نوع متن است:

{"value":"25.5"}

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

۱۴-۷. آزمایش فرمان بدون تجهیز واقعی

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

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

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

{

"accepted": false,

  "reason": "overload"

}

۱۴-۸. آزمایش بازخورد

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

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

۱۴-۹. انتقال به محیط واقعی

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

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

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

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

فرض کنید پس از راه‌اندازی، نمایشگر هیچ داده‌ای دریافت نمی‌کند.

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

۱۵-۱. بررسی تغذیه و وضعیت دستگاه

ابتدا باید مطمئن شویم تجهیزات روشن هستند و برنامه اصلی آن‌ها اجرا می‌شود.

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

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

۱۵-۲. بررسی ارتباط شبکه

در مرحله بعد، وضعیت کابل، سوییچ، آدرس شبکه و مسیر ارتباط بررسی می‌شود.

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

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

۱۵-۳. بررسی آدرس و پورت بروکر

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

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

۱۵-۴. بررسی TLS

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

بعضی خطاهای گواهی ممکن است در ظاهر شبیه قطع ارتباط یا ناتوانی در اتصال دیده شوند.

۱۵-۵. بررسی احراز هویت

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

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

۱۵-۶. بررسی شناسه کلاینت

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

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

۱۵-۷. بررسی اشتراک

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

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

۱۵-۸. بررسی نام تاپیک

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

برای مثال:

factory/line1/temperature

با نمونه زیر یکسان نیست:

factory/Line1/temperature

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

۱۵-۹. بررسی مجوزهای دسترسی

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

بنابراین باید سیاست دسترسی بررسی شود.

۱۵-۱۰. بررسی محتوای پیام

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

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

۱۵-۱۱. بررسی منطق برنامه

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

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

۱۵-۱۲. بررسی بازخورد واقعی

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

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

همچنین ممکن است موتور روشن شده باشد اما وضعیت آن منتشر نشده باشد.

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

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

خطای اول: اتصال برقرار است ولی داده دریافت نمی‌شود

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

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

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

خطای دوم: قطع و وصل متناوب کلاینت

ممکن است وضعیت ارتباط هر چند ثانیه تغییر کند.

یکی از علت‌های مهم، شناسه کلاینت تکراری است.

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

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

خطای سوم: نمایش مقدار قدیمی

فرض کنید نمایشگر دمای ۳۸٫۵ درجه را نشان می‌دهد، اما کنترلر چند ساعت است خاموش شده است.

ممکن است این مقدار، آخرین پیام ریتین‌شده باشد.

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

خطای چهارم: دریافت پیام تکراری

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

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

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

خطای پنجم: اختلاف واحد

فرض کنید کنترلر مقدار خام ۳۸۵ را ارسال می‌کند، ولی نمایشگر آن را ۳۸۵ درجه نمایش می‌دهد.

علت آن است که ضریب تبدیل یک‌دهم اعمال نشده است.

ممکن است حالت عکس نیز رخ دهد؛ یعنی تبدیل هم در دروازه و هم در نمایشگر انجام شود.

در هر دو حالت باید محل مسئول تبدیل و قرارداد واحد مشخص شود.

خطای ششم: اجرای نشدن فرمان

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

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

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

خطای هفتم: پیام نامعتبر

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

برای مثال:

{"temperature":"invalid"}

اگر برنامه انتظار عدد داشته باشد، باید این پیام را نامعتبر تشخیص دهد.

خطای هشتم: اشتباه در شماره رجیستر

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

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

خطای نهم: تفسیر اشتباه عدد اعشاری

در بعضی تجهیزات، مقدار اعشاری در دو رجیستر ذخیره می‌شود.

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

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

خطای دهم: رفتار نامناسب پس از اتصال مجدد

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

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

جدول عیب‌یابی سریع

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

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

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

۱۷-۱. آزمایش عملکرد عادی

ابتدا باید مطمئن شویم تمام متغیرهای تعریف‌شده به‌درستی منتشر می‌شوند.

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

همچنین باید بررسی شود واحدها، مقیاس‌ها و نوع داده‌ها درست هستند.

۱۷-۲. آزمایش قطع کابل شبکه

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

باید بررسی شود:

آیا کنترل محلی پی‌ال‌سی ادامه دارد؟

آیا نمایشگر قطع ارتباط را تشخیص می‌دهد؟

آیا مقدارهای قدیمی با وضعیت مناسب نشان داده می‌شوند؟

آیا پس از بازگشت شبکه، ارتباط دوباره برقرار می‌شود؟

۱۷-۳. آزمایش قطع ارتباط مدباس

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

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

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

۱۷-۴. آزمایش راه‌اندازی مجدد دروازه

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

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

۱۷-۵. آزمایش توقف بروکر

در محیط آزمایشی، سرویس بروکر متوقف می‌شود.

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

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

۱۷-۶. آزمایش پیام نامعتبر

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

برای مثال:

{"value":

برنامه دریافت‌کننده باید پیام را رد کند و نباید خروجی کنترلی تغییر کند.

۱۷-۷. آزمایش فرمان خارج از محدوده

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

اگر محدوده ۲۰ تا ۵۰ درجه است، درخواست مقدار ۸۰ درجه باید رد شود.

۱۷-۸. آزمایش فرمان تکراری

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

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

۱۷-۹. آزمایش فرمان منقضی‌شده

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

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

۱۷-۱۰. آزمایش مجوز دسترسی

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

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

۱۷-۱۱. آزمایش اینترلاک

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

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

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

۱۷-۱۲. آزمایش بازخورد واقعی

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

اچ‌ام‌آی نباید فقط به دلیل پذیرش فرمان، وضعیت موتور را روشن نمایش دهد.

۱۷-۱۳. جدول ثبت آزمون

۱۷-۱۴. ثبت نتایج

برای هر آزمون باید تاریخ، نام مسئول، نسخه برنامه، شرایط آزمون، نتیجه واقعی و وضعیت قبولی ثبت شود.

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

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

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

پس از راه‌اندازی و تحویل پروژه، نگهداری آن آغاز می‌شود.

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

۱۸-۱. مستند معماری

ابتدا باید نمودار معماری ارتباط تهیه شود.

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

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

۱۸-۲. جدول تجهیزات

برای هر تجهیز بهتر است مشخصات زیر ثبت شود:

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

۱۸-۳. جدول تاپیک‌ها

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

برای مثال:

۱۸-۴. جدول رجیسترها

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

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

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

۱۸-۵. مستند قرارداد پیام

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

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

همچنین باید درباره رفتار برنامه هنگام دریافت فیلد ناشناخته یا حذف فیلد ضروری تصمیم گرفته شود.

۱۸-۶. ثبت تنظیمات ارتباط

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

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

۱۸-۷. نسخه‌بندی نرم‌افزارها

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

بنابراین بهتر است نسخه نرم‌افزارها و تاریخ تغییرات ثبت شوند.

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

۱۸-۸. پشتیبان‌گیری

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

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

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

۱۸-۹. ثبت خطاها

برای هر رخداد مهم بهتر است زمان، تجهیز، نوع خطا، وضعیت ارتباط و اطلاعات مرتبط ثبت شود.

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

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

۱۸-۱۰. توسعه پروژه

فرض کنید در آینده یک خط تولید جدید به کارخانه اضافه شود.

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

برای مثال:

factory/line2/panel01/telemetry/temperature

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

۱۸-۱۱. محدودیت توسعه بدون قرارداد مشخص

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

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

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

۱۸-۱۲. معرفی استاندارد اسپارک‌پلاگ

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

یکی از مشخصات مطرح در این زمینه عبارت است از:

Sparkplug

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

۱۸-۱۳. تفاوت MQTT با اسپارک‌پلاگ

MQTT روش انتقال و توزیع پیام را مشخص می‌کند.

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

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

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

۱۸-۱۴. ساختار کلی موضوع‌ها

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

الگوی کلی:

spBv1.0/group_id/message_type/edge_node_id/device_id

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

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

۱۸-۱۵. زمان مناسب استفاده از اسپارک‌پلاگ

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

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

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

۱۸-۱۶. برنامه نگهداری دوره‌ای

پس از تحویل پروژه بهتر است برنامه‌ای برای بازبینی وضعیت سامانه تعریف شود.

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

همچنین پس از هر تغییر مهم، آزمون‌های مرتبط با آن تغییر باید دوباره انجام شوند.

جمع‌بندی فصل چهارم

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

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

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

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

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

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

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

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

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

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

جمع‌بندی نهایی مجموعه چهار فصل

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

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

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

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

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

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

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

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

پایان فصل چهارم و مجموعه آموزشی «آموزش کاربردی پروتکل MQTT در اتوماسیون صنعتی»

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