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

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

مقدمه

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

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

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

۱. مراحل اتصال تا دریافت اولین پیام

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

هر کلاینت درخواست CONNECT را ارسال می‌کند که مشخصاتی مانند نسخه پروتکل و شناسه کلاینت دارد. بروکر با CONNACK نتیجه پذیرش یا رد اتصال را اعلام می‌کند. پذیرش اتصال به معنی آماده‌شدن کلاینت برای عملیات مجاز است، نه الزاماً رسیدن داده به برنامه.

نمایشگر با SUBSCRIBE دریافت پیام‌های دمای تابلو را درخواست می‌کند و بروکر با SUBACK نتیجه اشتراک را اعلام می‌کند. کنترلر بعداً داده را در بسته PUBLISH روی موضوع تعیین‌شده منتشر می‌کند و بروکر آن را برای اشتراک‌های منطبق توزیع می‌کند.

factory/line1/panel01/temperature

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

نمایشگر با تحلیل محتوای پیام، دمای ۳۸٫۵ درجه سلسیوس را نشان می‌دهد. لزومی ندارد فرستنده منتظر ثبت اشتراک گیرنده بماند. همچنین اتصال و ثبت اشتراک به معنی دریافت تمام پیام‌های گذشته نیست.

دیاگرام ۱ ـ توالی اتصال و دریافت اولین پیام

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

۲. تنظیمات پایه اتصال یک کلاینت

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

Broker: broker.emqx.io

Port: 1883

Protocol: MQTT 3.1.1

Client ID: factory1_line1_plc01

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

۳. اهمیت یکتابودن شناسه کلاینت

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

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

factory1_line1_plc01

factory1_line1_plc02

factory1_line1_hmi01

۴. آشنایی با پیام‌های کنترلی پروتکل

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

برای مثال، موضوع دمای تابلو و محتوای آن در یک بسته PUBLISH حمل می‌شوند. پروتکل از محتوای «۶٫۲» تشخیص نمی‌دهد که داده فشار است؛ معنا را قرارداد نام موضوع و قالب محتوا تعیین می‌کند. تفاوت تأیید تحویل و اجرای عمل در فصل بعد بررسی می‌شود.

۵. طراحی ساختار چندسطحی تاپیک

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

factory/line1/panel01/temperature

برای تابلوی دوم می‌توان از factory/line1/panel02/temperature استفاده کرد. ساختار تاپیک را طراح سیستم انتخاب می‌کند؛ خود MQTT درباره «خط یک» یا «تابلوی اول» شناختی ندارد. هر سطح بهتر است پایدار، معنی‌دار و قابل‌استفاده برای دسته‌بندی گروهی باشد.

دیاگرام ۲ ـ درخت تاپیک‌ها

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

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

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

factory/line1/temperature

factory/Line1/temperature

factory/line1/Temperature

این سه نمونه با یکدیگر برابر نیستند. علامت / تنها جداکننده استاندارد سطح‌هاست. عبارتی مانند factory.line1.panel01 یک تاپیک تک‌سطحی خواهد بود و مانند factory/line1/panel01 امکان فیلتر سطحی ندارد.

از نام‌های مبهم مانند data1 و value3 و از نام‌های وابسته به مقدار جاری پرهیز کنید. بهتر است وضعیت موتور در محتوای یک موضوع پایدار قرار گیرد، نه اینکه با روشن و خاموش‌شدن دستگاه، آدرس تغییر کند. علامت‌های + و # برای فیلتر اشتراک رزرو شده‌اند و نباید در نام موضوع PUBLISH باشند. نام‌هایی که سطح اول آن‌ها با $ آغاز می‌شود نیز کاربرد ویژه دارند.

factory/line1/motor01/status

{"running":true}

۷. تفاوت آدرس انتشار با فیلتر اشتراک

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

Publish topic: factory/line1/panel01/temperature

Subscribe filter: factory/line1/panel01/temperature

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

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

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

factory/line1/+/temperature

factory/line1/#

Invalid: factory/line1/panel+/temperature

Invalid: factory/line1/#/temperature

در دریافت گروهی، نام کامل موضوع دریافتی نیز باید تحلیل شود تا معلوم باشد مقدار به کدام دستگاه تعلق دارد. فیلترهایی که با + یا # آغاز می‌شوند با تاپیک‌های دارای پیشوند $ منطبق نمی‌شوند؛ در صورت نیاز باید اشتراک ویژه‌ای ثبت کرد.

دیاگرام ۳ ـ دریافت دمای چند تابلو با یک اشتراک

۹. جداسازی مسیر اندازه‌گیری، وضعیت، آلارم، فرمان و پاسخ

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

factory/line1/motor01/telemetry/current

factory/line1/motor01/status/running

factory/line1/motor01/alarm/overload

factory/line1/motor01/cmd/run

factory/line1/motor01/response/run

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

{"value":true}

{"accepted":false,"reason":"overload"}

{"running":false}

در فصل اول از factory/line1/panel01/temperature استفاده شد؛ اکنون برای قابلیت توسعه نمونه کامل‌تر factory/line1/panel01/telemetry/temperature را پیشنهاد می‌کنیم. در پروژه واقعی تغییر قرارداد نام‌ها باید همراه با به‌روزرسانی مصرف‌کنندگان باشد.

۱۰. انتخاب قالب مناسب برای محتوای پیام

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

38.5

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

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

۱۱. آشنایی ساده با ساختار داده‌های جیسون

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

{"temperature":38.5}

{"temperature":38.5,"pressure":6.2}

{"running":true,"mode":"automatic","value":null}

در JSON عدد 38.5 با رشته "38.5" متفاوت است. مقدار منطقی true یا false بدون نقل‌قول نوشته می‌شود. علامت اعشار، نقطه است و مقدارهای NaN و Infinity معتبر نیستند. برای مقدار غیرقابل‌دسترس می‌توان null را همراه کیفیت داده به کار برد.

{"value":null,"quality":"sensor_fault"}

{"temperatures":[38.5,39.1,37.8]}

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

{"motor":{"running":true,"speed":1450,"current":4.8}}

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

۱۲. تبدیل متغیرهای پی‌ال‌سی به پیام

متغیر منطقی مانند MotorRunning می‌تواند به مقدار true یا false تبدیل شود. متغیر صحیح مانند شمارنده تولید با مقدار ۱۲۵۴۰ به عدد JSON و یک رشته وضعیت مانند automatic به متن تبدیل می‌شود.

{"running":true}

{"count":12540}

{"mode":"automatic"}

{"value":6.2,"unit":"bar"}

در بسیاری از سامانه‌ها مقدار خام ورودی آنالوگ باید قبل از انتشار به واحد مهندسی تبدیل شود. فرض کنیم خروجی کالیبره‌شده کارت ورودی از صفر تا ۱۰۰۰۰ و محدوده سنسور فشار از صفر تا ۱۰ بار است. در این مثال آموزشی اگر مقدار خام ۶۲۰۰ باشد، فشار ۶٫۲ بار است.

P = (R / 10000) * 10

R = 6200  -->  P = 6.2 bar

فرمول عمومی تبدیل خطی میان دو بازه چنین است: Y = Ymin + ((X−Xmin)/(Xmax−Xmin)) × (Ymax−Ymin). در سنسورهای ۴ تا ۲۰ میلی‌آمپر، باید آفست و گستره واقعی سیگنال را در نظر گرفت. پس از تبدیل به واحد مهندسی در کنترلر یا دروازه ارتباطی، نمایشگر نباید همان تبدیل را دوباره اعمال کند.

۱۳. مقایسه ارسال جداگانه و تجمیعی متغیرها

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

factory/line1/panel01/telemetry/temperature  --> 38.5

factory/line1/air01/telemetry/pressure       --> 6.2

factory/line1/motor01/status/running         --> true

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

factory/line1/controller01/telemetry

{"temperature":38.5,"pressure":6.2,"motor_running":true}

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

۱۴. افزودن زمان، کیفیت داده و شناسه پیام

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

{

  "value": 38.5,

  "unit": "C",

  "quality": "good",

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

  "seq": 1254

}

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

{"value":null,"unit":"C","quality":"communication_error"}

{"value":38.5,"unit":"C","quality":"stale"}

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

دیاگرام ۴ ـ اجزای یک پیام صنعتی

۱۵. انتخاب زمان و شرط ارسال داده

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

Deadband = 0.5 °C

Publish if abs(current - last_published) >= Deadband

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

Deadband = 0.5 °C

Maximum interval = 30 s

فرض کنید ۱۰۰ کنترلر هرکدام ده متغیر دارند؛ انتشار هر متغیر در هر ثانیه ۱۰۰۰ پیام اولیه بر ثانیه می‌سازد. اگر فاصله انتشار پنج ثانیه شود، میانگین ۲۰۰ پیام در ثانیه خواهد بود. این فقط شمار انتشارهای منبع است؛ بار واقعی شبکه به اندازه Payload، سربار و تعداد گیرندگان نیز بستگی دارد.

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

۱۶. طراحی کامل ساختار داده یک خط تولید

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

factory/line/device/category/variable

پیشوند مشترک تمامی موضوع‌ها در این مثال factory/line1 است. در جدول زیر نام‌ها نسبت به همین پیشوند نوشته شده‌اند.

قرارداد قالب و زمان انتشار

factory/line1/air01/telemetry/pressure

{"value":6.2,"unit":"bar","quality":"good","timestamp":"2026-10-17T10:30:00Z"}

factory/line1/motor01/status/running

{"running":true}

اشتراک‌های نمایشگر

factory/line1/+/telemetry/temperature

factory/line1/air01/telemetry/pressure

factory/line1/motor01/status/running

factory/line1/+/alarm/+

فیلتر آخر فقط الگوی پنج‌سطحی متناظر با آلارم‌ها را می‌پوشاند و اگر در آینده تعداد سطح‌ها تغییر کند باید بازنگری شود. برای دریافت همه دماها در همه خطوط می‌توان از factory/+/+/telemetry/temperature استفاده کرد؛ اما ممکن است تجهیزات غیرتابلو را نیز پوشش دهد.

سناریوی بهره‌برداری

فرض کنید دمای تابلوی اول ۳۸٫۵ درجه، تابلوی دوم ۳۹٫۲ درجه، فشار ۶٫۲ بار، موتور روشن و شمارنده تولید ۱۲۵۴۰ بسته باشد. کنترلرها بر اساس قرارداد، پیام‌های خود را روی موضوع‌های مستقل منتشر می‌کنند؛ نمایشگر و ثبت‌کننده نیز فقط موضوع‌های موردنیاز را می‌گیرند.

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

factory/line1/panel01/alarm/high_temperature

{"active":true}

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

جمع‌بندی فصل دوم

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

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

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