از یک فروشنده PLC درباره MQTT بپرسید و یک نقشه راه دریافت می‌کنید: "سال آینده، شاید، روی مدل پریمیوم." سپس به جزئیات نگاه می‌کنید و یک دروازه، یک مبدل، یا یک اشتراک ابری را که پشت ویژگی پنهان شده است، پیدا می‌کنید. پشتیبانی MQTT در CPUهای اترنت xLogic هیچ‌کدام از این‌ها را ندارد - از نسخه 1.04 در فریمور بوده و مستقیماً از کنترلر منتشر می‌شود.
این تغییر می‌دهد که یک ماشین بودجه‌ای چه کاری می‌تواند انجام دهد و بیشتر یکپارچه‌سازها متوجه نشده‌اند.
چرا MQTT برای یکMicro PLC
MQTT دقیقاً برای این وضعیت ساخته شده است: یک دستگاه در یک شبکه غیرقابل اعتماد، انتشار پیام‌های کوچک به یک بروکر، با مشترکانی که می‌آیند و می‌روند. یک ماشین در یک کارخانه، یک ایستگاه پمپ در یک میدان، یک گلخانه دو ساعت دورتر از دفتر - هر کدام وضعیت خود را منتشر می‌کند؛ داشبورد ابری، اپلیکیشن تلفن و لپ‌تاپ مهندس همه به یک موضوع مشترک می‌شوند. هیچ نظارتی، هیچ پورت باز به داخل کارخانه، هیچ سرور SCADA که مراقب اتصال باشد.
بروکر هرج و مرج را مدیریت می‌کند. PLC فقط منتشر می‌کند.
آنچه واقعاً پیکربندی می‌کنید
بلوک‌های اتصال در برنامه زندگی می‌کنند: آدرس بروکر، موضوع، فاصله انتشار را تنظیم کنید و مشخص کنید کدام مقادیر در بار داده قرار می‌گیرند. CPU چرخه عمر اتصال را مدیریت می‌کند - دوباره متصل شدن بعد از قطع، دوباره منتشر کردن بعد از یک فاصله - که بخشی است که پیاده‌سازی‌های دستی را از بین می‌برد.
آن را با سرور وب و SMS هشدار جفت کنید و سه کانال مستقل از راه دور روی یک کنترلر خواهید داشت. داشبورد ابری برای دفتر، صفحه مرورگر برای اپراتور، SMS برای مهندس مسئول. کانال خود را بر اساس مخاطب انتخاب کنید.
مورد واقعی: نظارت بر گلخانه از راه دور
یک مهدکودک با چهار بخش می‌خواست دید ابری بدون بازسازی شبکه سایت. هر کنترلر بخش دما، رطوبت و وضعیت شیر را به یک بروکر در یک VPS اجاره‌ای منتشر کرد؛ یک داشبورد ساده مشترک شد و همه چهار بخش را در یک صفحه نمایش داد. وقتی اینترنت برای یک بعدازظهر قطع شد، کنترلرها به انتشار در یک صف محلی ادامه دادند و مقادیر هنگام دوباره متصل شدن به روز شدند.
خلاصه کشاورز، ترجمه شده از هیجان: "من در تعطیلات دما را از تلفن خود تماشا کردم. این بهتر از بودن در آنجا بود."
جایی که MQTT پاسخ اشتباهی است
در مورد محدودیت‌ها صادق باشید. MQTT به رویداد و تلمتری متمرکز است - این یک حلقه کنترل قطعی نیست. اگر به تحویل تضمینی و پاسخ میلی‌ثانیه‌ای نیاز دارید، از Modbus TCP به‌صورت محلی استفاده کنید. MQTT برای نظارت و گزارش‌گیری است، نه برای قفل ایمنی. آن را به این شکل طراحی کنید و سال‌ها برای شما کار خواهد کرد.
و اعتبارنامه‌های بروکر را درست نگه‌دارید. یک PLC که به یک موضوع عمومی منتشر می‌کند، یک PLC است که کسب‌وکار خود را پخش می‌کند. موضوعات خصوصی، یک بروکر محلی، یا حداقل TLS روی بروکر - هزینه راه‌اندازی چند دقیقه است و شرم‌ساری که از آن جلوگیری می‌شود واقعی است.
الگوی ارزش دزدیدن
طراحی موضوعی که مقیاس‌پذیر است
MQTT به اندازه ساختار موضوع شما تمیز است و ساختار موضوع جایی است که پروژه‌های کوچک به آرامی غیرقابل مدیریت می‌شوند. رویکرد ساده - یک موضوع برای هر دستگاه، یک بار داده با همه چیز در آن - برای یک ماشین کار می‌کند و در ده تا می‌افتد. هر مشترک هر بار داده را دوباره تجزیه می‌کند، هر تغییر در بار داده هر داشبورد را خراب می‌کند و اشکال‌زدایی به یک شکار موضوع به موضوع تبدیل می‌شود.
سلسله‌مراتب را قبل از اولین انتشار طراحی کنید. یک الگو که برای من خوب کار کرده است:سایت/دستگاه/دسته‌بندی/مقدار. بنابراینplant1/pump1/status/run, plant1/pump1/sensor/level, plant1/pump2/alarm/high-level. مشترک‌های wildcard - یک داشبورد برای plant1، یک صفحه برای pump1، یک شنونده هشدار برای همه چیز - هر کدام دقیقاً به برش مورد نیاز خود مشترک می‌شوند. دستگاه‌های جدید بدون دست زدن به موضوعات قدیمی وارد می‌شوند و بار داده‌ها کوچک و نوع‌دار باقی می‌مانند.
بار داده‌ها را ساده نگه‌دارید: یک مقدار و یک زمان‌سنج. هیچ بلوک JSON تو در تویی که یازده فیلد را نگه‌دارد مگر اینکه واقعاً به آن‌ها نیاز داشته باشید. بار داده‌های ساده قابل اشکال‌زدایی هستند - می‌توانید یکی را در کنسول بروکر بخوانید و بلافاصله بدانید که آیا درست است یا نه. و پرچم نگهداری را روی موضوعات وضعیت تنظیم کنید تا یک مشترک جدید بلافاصله آخرین وضعیت شناخته شده را ببیند به جای اینکه منتظر انتشار بعدی باشد. وضعیت نگهداری شده تفاوت بین یک داشبورد است که آماده باز می‌شود و یکی که برای دقایق به‌طور خیره‌کننده‌ای نگاه می‌کند.
آخرین قانون، قانونی است که مردم در برابر آن مقاومت می‌کنند: نسخه موضوع را زمانی که فرمت بار داده تغییر می‌کند.plant1/pump1/status/v2. این زشت است. این شما را از شکستن پنج مشترک در تولید با یک تغییر نجات می‌دهد. موضوعات زشت که کار می‌کنند بهتر از موضوعات تمیز هستند که منفجر می‌شوند.
داده‌هایی که ارزش انتشار دارند
انتشار همه چیز به اندازه انتشار هیچ چیز بد است - این بروکر را غرق می‌کند، لاگ را بزرگ می‌کند و مقادیر مهم را دفن می‌کند. از سوالی که مشترک خواهد پرسید شروع کنید، نه از لیست ثبت‌ها. یک اپراتور وضعیت، هشدارها و مجموع‌های جاری می‌خواهد. یک مهندس روندها را می‌خواهد: دما، فشار، ساعت‌های کار. یک مدیر زمان کار و شمارش‌ها را می‌خواهد. آن‌ها را منتشر کنید و فقط آن‌ها را.
نرخ‌ها نیز مهم هستند. انتقال‌های هشدار: بلافاصله منتشر کنید، همیشه. وضعیت: در تغییر به علاوه یک ضربان. مقادیر آنالوگ: در فاصله‌ای که واقعاً فرآیند را نشان می‌دهد - ده ثانیه برای دمای گلخانه‌ای کند، یک ثانیه برای ابزار ماشین. هر موضوع سریعی که به آن نیاز ندارید بار بروکر هدر رفته و داده‌های سیم کارت هدر رفته در مدل‌های بی‌سیم است.
و موارد مهم را به‌صورت محلی نیز ثبت کنید. ثبت‌نام داده‌های CPU به‌علاوه پیام‌های نگهداری شده بروکر به شما دو نسخه از تاریخچه حیاتی می‌دهد. وقتی بروکر یک روز بد دارد - همه آن‌ها دارند - لاگ سمت ماشین منبع حقیقت است و مکالمه بازیابی کوتاه است.
کنترل محلی روی CPU، دید ابری از طریق MQTT، و این دو هرگز تداخل نمی‌کنند. این جدایی معماری اتوماسیون کوچک مدرن است و روی ریل DIN جا می‌شود. نقشه راه فروشنده نیامد. فریمور قبلاً ارسال شده است.
