MQTT، BACnet IP و Modbus TCP: ارتباط چندپروتکلی بر روی کامپکت Ethernet PLC

یک ماژول DIN-rail که با MQTT به ابر، با BACnet به ساختمان و با Modbus TCP به ماشین‌ها صحبت می‌کند. این جمله برای توصیف یک پنل پر از دروازه‌ها استفاده می‌شد. اکنون یک CPU کامپکت با قابلیت اترنت را توصیف می‌کند و داستان چندپروتکلی در پلتفرم xLogic یک اسلاید بازاریابی نیست - این در فریمور موجود است و در تمام نسخه‌های راهنما مستند شده است: MQTT از V1.04، BACnet از V1.57، Modbus از روز اول.

در اینجا نحوه استفاده از آن بدون ایجاد یک کابوس نگهداری آمده است.

نقشه پروتکل

هر پروتکل مخاطب طبیعی خود را دارد و ترفند این است که آن‌ها را جدا نگه داریم:

  • Modbus TCP— کف ماشین: VFDها، HMIها، SCADA، سایر PLCها. قطعی، مبتنی بر ثبت، دست دادن صنعتی جهانی
  • MQTT— ابر: ارسال تلمتری به یک کارگزار، داشبوردها مشترک می‌شوند. مبتنی بر رویداد، دوستانه با NAT، ساخته شده برای شبکه‌های غیرقابل اعتماد
  • BACnet— ساختمان: اتاق‌های کارخانه، AHUها، سرآغازهای BMS. زبان بومی صنعت املاک

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

ساختمان واقعی: اتاق گیاهی کوچک

یک اتاق گیاهی با AHU، دو گروه فن‌کویل و یک پمپ حرارتی: Modbus TCP به HMI محلی و VFDها، BACnet به BMS ساختمان برای زمان‌بندی و هشدارها، MQTT به یک سرویس ابری برای روندهای از راه دور. سه پروتکل، یک کنترل‌کننده، یک برنامه. مهندس BMS پرسید که دروازه‌بان کیست. پاسخ - "دروازه‌بان وجود ندارد" - سکوتی را به همراه داشت که پنج ثانیه کامل طول کشید.

این سکوت محصولی است که کار می‌کند.

چه چیزی را جدا نگه داریم

پروتکل‌ها می‌توانند CPU را به اشتراک بگذارند، اما نباید برنامه داده را به اشتراک بگذارند. نقاط را یک بار، به‌طور عمدی نقشه‌برداری کنید: کدام رجیسترها برای Modbus قابل مشاهده هستند، کدام اشیاء BACnet هستند، کدام موضوعات MQTT هستند. یک نقشه نقطه‌ای واحد، که در یک صفحه گسترده نگهداری می‌شود، از شکست کلاسیک جلوگیری می‌کند - یک شماره رجیستر تغییر کرده و سه سیستم به آرامی از کار می‌افتند.

و محدودیت‌های مدل را به یاد داشته باشید: BACnet/IP و MQTT به CPU‌های با قابلیت اترنت نیاز دارند. مدل‌های فقط سریال Modbus RTU و BACnet/MSTP را نگه می‌دارند. مدل را با نیاز قبل از وعده بررسی کنید، نه بعد از سفارش خرید.

زاویه پشتیبانی که هیچ‌کس قیمت‌گذاری نمی‌کند

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

انضباط نقشه نقطه

چندپروتکلی یک نعمت و یک دام است. نعمت: یک CPU که به سه سیستم خدمت می‌کند. دام: سه سیستم که نسخه‌های کمی متفاوتی از حقیقت را می‌خوانند. راه‌حل خسته‌کننده و غیرقابل مذاکره است - یک نقشه نقطه‌ای واحد که هر مقدار را یک بار، با رجیستر آن، شیء BACnet آن و موضوع MQTT آن در یک ردیف لیست می‌کند.

صفحه گسترده را از روز اول شروع کنید، قبل از اینکه اولین بلوک سیم‌کشی شود. ستون‌ها: نام مقدار، رجیستر Modbus، نوع و نمونه شیء BACnet، موضوع MQTT، نوع داده، مقیاس‌بندی، نرخ به‌روزرسانی و کدام سیستم برای نوشتن معتبر است. ستون آخر مهم‌تر از آن چیزی است که مردم فکر می‌کنند - وقتی BMS و داشبورد ابری هر دو می‌خواهند یک نقطه تنظیم را تغییر دهند، کسی باید برنده شود و نقشه می‌گوید کی. بدون آن، دو سیستم بر روی یک مقدار می‌جنگند و ماشین در ساعت 3 صبح به‌طور غیرقابل پیش‌بینی رفتار می‌کند.

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

و مسیرهای بین پروتکلی را به‌طور عمدی تست کنید: یک نقطه تنظیم از BMS بنویسید، تأیید کنید که ماشین پاسخ می‌دهد، تأیید کنید که داشبورد ابری تغییر را نشان می‌دهد. یک تست انتها به انتها برای هر نقطه، در زمان راه‌اندازی، خطاهای نقشه‌برداری را در حالی که اصلاح آن‌ها ارزان است، شناسایی می‌کند.

واقعیت فریمور و نسخه

ویژگی‌های پروتکل به صورت موجی وارد شدند و تاریخچه ویرایش دستی داستان را روایت می‌کند: MQTT در 4.2، سرور وب در 4.5، دستورالعمل‌های WiFi در 6.0، BACnet در 6.2، پشتیبانی SR-22 در 6.2.1. اگر در حال برنامه‌ریزی یک پروژه چندپروتکلی هستید، نسخه فریمور یک جزئیات نیست - این یک نیاز است. یک CPU که دو سال پیش ارسال شده ممکن است قبل از اینکه با BACnet صحبت کند به یک به‌روزرسانی نیاز داشته باشد و مسیر به‌روزرسانی به مدل بستگی دارد.

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

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

عادت مستندسازی پروتکل

یک کنترل‌کننده سه پروتکلی بدون نقشه پروتکل یک نمایشگاه موزه‌ای است. این انضباط یک ساعت در زمان راه‌اندازی هزینه دارد و هر بار که ساختمان تغییر می‌کند یک هفته صرفه‌جویی می‌کند: یک برگه که هر نقطه، رجیستر Modbus آن، شیء BACnet آن و موضوع MQTT آن را لیست می‌کند - با مجوز نوشتن مشخص شده است. این برگه با نقشه‌های پنل زندگی می‌کند و با برنامه نسخه‌بندی می‌شود. وقتی مهندس BMS می‌پرسد "دمای تأمین کدام مقدار است؟" پاسخ یک ردیف است، نه یک بعدازظهر باستان‌شناسی رجیستر.

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