پروتکل MQTT در اینترنت اشیا صنعتی: معماری، QoS و امنیت

انتشار و اشتراک: MQTT چگونه کار می‌کند

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

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

• ناشر (Publisher) پیام را روی یک تاپیک منتشر می‌کند، مثلاً دمای یک موتور.
• مشترک (Subscriber) علاقه خود را به یک یا چند تاپیک اعلام می‌کند.
• بروکر پیام‌ها را دریافت می‌کند و به همه مشترکان مرتبط تحویل می‌دهد.

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

طراحی سلسله‌مراتب تاپیک‌ها

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

site/area/line/asset/telemetry/temperature

مشترکان می‌توانند از دو wildcard استفاده کنند: + برای یک سطح و # برای همه سطوح بعدی. برای مثال site/area/+/+/alarms/# همه هشدارهای همه خطوط یک ناحیه را دریافت می‌کند.

توصیه‌های عملی

• از حروف کوچک، بدون فاصله و بدون کاراکترهای خاص استفاده کنید و تاپیک را با / شروع نکنید.
• داده‌های تله‌متری، وضعیت، هشدار و فرمان را در شاخه‌های جدا نگه دارید تا سطح دسترسی و QoS برای هر کدام جداگانه قابل تنظیم باشد.
• شناسه یکتای دستگاه را در تاپیک بیاورید تا قواعد کنترل دسترسی (ACL) بر اساس آن نوشته شود.
• قالب payload را مستند کنید؛ JSON برای خوانایی و قالب‌های دودویی مانند Protobuf برای لینک‌های محدود مناسب‌ترند.

تضمین تحویل و وضعیت نشست

سطوح QoS

MQTT سه سطح کیفیت سرویس دارد. نکته مهم این است که QoS در هر «پرش» جداگانه اعمال می‌شود: یک بار میان ناشر و بروکر و یک بار میان بروکر و هر مشترک.

سطح	تضمین	سازوکار	کاربرد رایج
QoS 0	حداکثر یک بار	ارسال بدون تأیید	تله‌متری پرتکرار که از دست رفتن یک نمونه مشکلی ایجاد نمی‌کند
QoS 1	حداقل یک بار	PUBLISH و PUBACK؛ امکان پیام تکراری	رویدادها، هشدارها و فرمان‌ها با پردازش idempotent
QoS 2	دقیقاً یک بار	دست‌دهی چهارمرحله‌ای	مواردی که تکرار پیام هزینه دارد و سربار بیشتر پذیرفتنی است

پیام‌های ماندگار (Retained)

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

Last Will and Testament

کلاینت هنگام اتصال می‌تواند یک «وصیت‌نامه» تعریف کند. اگر اتصال به‌صورت غیرعادی قطع شود و keep-alive منقضی شود، بروکر این پیام را منتشر می‌کند. ترکیب LWT با یک پیام ماندگار وضعیت، روشی ساده برای پایش در دسترس بودن دستگاه‌ها و گیت‌وی‌هاست.

نشست‌های پایدار

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

امکانات MQTT 5 و امنیت

آنچه MQTT 5 اضافه کرده است

• کدهای دلیل (Reason Codes) برای تشخیص دقیق‌تر خطاها.
• User Properties برای افزودن فراداده مانند نسخه schema یا واحد اندازه‌گیری بدون تغییر payload.
• اشتراک مشترک (Shared Subscriptions) برای توزیع بار پیام‌ها میان چند نمونه از یک سرویس پردازشی.
• Session Expiry و Message Expiry برای کنترل عمر نشست‌ها و پیام‌ها.
• Response Topic و Correlation Data برای الگوی درخواست و پاسخ، مثلاً در فرمان‌دهی.
• Topic Alias و Receive Maximum برای کاهش ترافیک و کنترل جریان.

TLS و احراز هویت

MQTT به‌طور پیش‌فرض رمزنگاری ندارد. در محیط صنعتی حداقل‌های زیر توصیه می‌شود:

• استفاده از TLS (معمولاً پورت 8883) و غیرفعال کردن پورت بدون رمزنگاری 1883 در شبکه‌های غیرقابل‌اعتماد.
• احراز هویت دستگاه با گواهی کلاینت (mTLS) یا توکن‌های یکتا برای هر دستگاه، نه یک رمز مشترک.
• قواعد ACL تا هر دستگاه فقط روی تاپیک‌های خودش بنویسد و فقط فرمان‌های خودش را بخواند.
• جداسازی شبکه OT و IT و قرار دادن بروکر در یک ناحیه کنترل‌شده (DMZ صنعتی) طبق رویکرد IEC 62443.

Sparkplug B و مقایسه با OPC UA و HTTP

MQTT فقط نحوه انتقال را تعریف می‌کند و درباره ساختار تاپیک یا payload چیزی نمی‌گوید. مشخصه Sparkplug B که در بنیاد Eclipse نگهداری می‌شود، این خلأ را برای کاربردهای صنعتی پر می‌کند: فضای نام تاپیک ثابت با پیشوند spBv1.0، payload مبتنی بر Protobuf و پیام‌های تولد و مرگ (NBIRTH، NDEATH، DBIRTH، DDEATH) که وضعیت دستگاه‌ها و فهرست متریک‌های آن‌ها را برای سامانه میزبان مشخص می‌کنند. Sparkplug وقتی ارزشمند است که چند سامانه SCADA یا پلتفرم باید بدون توافق‌های اختصاصی، داده یکدیگر را بفهمند.

معیار	MQTT	OPC UA	HTTP/REST
الگوی ارتباط	انتشار و اشتراک از طریق بروکر	کلاینت/سرور و همچنین PubSub	درخواست و پاسخ
مدل داده	آزاد؛ با Sparkplug ساخت‌یافته	مدل اطلاعاتی غنی و استاندارد	آزاد، معمولاً JSON
سربار	کم	متوسط تا زیاد	بیشتر به ازای هر پیام
داده بلادرنگ	بله، رانش داده (push)	بله، با اشتراک و پایش	نیازمند polling یا webhook
جایگاه معمول	لبه تا پلتفرم و ابر	سطح ماشین و کنترلر	یکپارچه‌سازی با سامانه‌های IT

در عمل، الگوی رایج این است که گیت‌وی لبه داده را از PLCها با OPC UA یا Modbus بخواند و با MQTT به پلتفرم بفرستد؛ HTTP هم برای یکپارچه‌سازی با ERP یا سامانه‌های تجاری استفاده می‌شود.

انتخاب و بهره‌برداری از بروکر

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

• Eclipse Mosquitto: بروکر متن‌باز و سبک، مناسب برای لبه، آزمایشگاه و استقرارهای کوچک تا متوسط.
• EMQX: بروکر توزیع‌شده با امکان خوشه‌بندی، موتور قواعد و یکپارچه‌سازی با پایگاه‌های داده.
• HiveMQ: بروکر با تمرکز بر محیط‌های سازمانی، همراه با نسخه‌های تجاری و افزونه‌ها.
• ThingsBoard: لایه انتقال MQTT داخلی برای اتصال مستقیم دستگاه‌ها به پلتفرم با API تاپیک خودش (مثلاً v1/devices/me/telemetry)؛ بروکر عمومی برای تبادل دلخواه میان سامانه‌ها نیست.

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

جمع‌بندی و گام‌های عملی

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