OPC UA مدل‌های اطلاعات صنعتی و خدمات ارتباطی فراهم می‌کند؛ MQTT انتقال پیام به روش انتشار و اشتراک را انجام می‌دهد. این دو می‌توانند با هم کار کنند، از جمله OPC UA PubSub روی MQTT. معماری مستند را بر اساس معنای داده، نیاز تحویل و پیاده‌سازی‌های پشتیبانی‌شده انتخاب کنید، نه مقایسه اجباری یکی در برابر دیگری. هویت تجهیز، واحد، زمان منبع، کیفیت و شناسه رویداد باید در کل مسیر حفظ شوند. رسیدن پیام بهتنهایی ثابت نمی‌کند مقدار تازه، معتبر یا مناسب تصمیم تولید است.
ببینید چرا OPC UA و MQTT می‌توانند کنار هم باشند.
حداقل قرارداد داده مفید برای تولید را مشخص کنید.
پیش از اعتماد به شاخص‌ها، داده تکراری، قدیمی و نامعتبر را آزمایش کنید.
معنای داده را از انتقال پیام جدا کنید
دمای ۷۵ به مشخصات ماشین، حسگر، واحد، زمان و کیفیت نیاز دارد. بدون آنها، گیرنده نمی‌تواند با اطمینان درجه سلسیوس را از فارنهایت یا خوانش فعلی را از خوانش ذخیره‌شده تشخیص دهد.
OPC UA اطلاعات صنعتی را مدل می‌کند و چند الگوی ارتباطی دارد. MQTT پیام را با موضوع‌ها و واسط پیام توزیع می‌کند. OPC Foundation صریحاً ادغام این دو را پشتیبانی می‌کند؛ طرح Cloud Initiative آن شامل معماری مرجع ۲۰۲۶ و گروه کاری OPC UA روی MQTT است.
راهنمای اینترنت اشیای صنعتی تصویر گسترده‌تر سیستم را توضیح می‌دهد. این مقاله روی حفظ قرارداد داده از جمع‌آوری تا تحلیل تمرکز دارد.
الگوی پشتیبانی‌شده انتخاب کنید، نه شعار
یک کلاینت OPC UA میتواند داده سرور را بخواند یا مشترک تغییرات آن شود و از برنامه لبه عبور دهد. راه دیگر، پیاده‌سازی پشتیبانی‌شده OPC UA PubSub است که مجموعه داده تعریف‌شده را با MQTT منتشر می‌کند. اینها طراحی‌های متفاوتی‌اند؛ مشخص کنید تجهیز و نرم‌افزار شما واقعاً کدام را پشتیبانی می‌کنند.
JSON بودن محتوای پیام، به MQTT مدل اطلاعات صنعتی نمی‌دهد. قرارداد JSON سفارشی میتواند مفید باشد، اما خودبه‌خود OPC UA PubSub مطابق استاندارد نیست. IIoT StarterKit از OPC Foundation یک نمونه مشخص ناشر مطابق استاندارد دارد.
پیش از انتخاب پیاده‌سازی، رمزگذاری، قرارداد موضوع‌ها، نسخه فراداده و سازگاری مصرف‌کننده را بررسی کنید. علامت پشتیبانی از یک پروتکل در دو محصول، سازگاری عملی آنها را ثابت نمی‌کند.
گیرنده باید چه چیزهایی بداند؟
قرارداد فرضی برای تحلیل شمارنده قطعات: ماشین P-07 مقدار تجمعی ۴۱۲ واحد پذیرفته‌شده را با زمان منبع 10:15:00 UTC گزارش می‌کند. سابقه لبه پنج ثانیه بعد می‌رسد. زمان رسیدن نباید بی‌توضیح جای زمان منبع بنشیند.
فیلدهای زیر قرارداد آموزشی‌اند، نه قالب انتقال اجباری OPC UA. پیاده‌سازی تولید باید وضعیت واقعی منبع، نسخه و هویت مدل مستندشده را حفظ کند.
| فیلد | مقدار فرضی | چرا لازم است؟ |
|---|---|---|
| تجهیز و سنجه | P-07 / accepted-count | مشخص می‌کند چه چیزی شمرده شده |
| مقدار و واحد | ۴۱۲ واحد، تجمعی | عدد تجمعی را با افزایش جدید اشتباه نمیگیرد |
| زمان منبع و رسیدن | 10:15:00 / 10:15:05 UTC | زمان رویداد را از تأخیر جدا می‌کند |
| کیفیت و نسخه | Good / schema 1 | داده نامعتبر و تغییر قرارداد را آشکار می‌کند |
| شناسه رویداد | نشست منبع S8، شماره توالی 92 | به حذف تکرار و بررسی راه‌اندازی مجدد کمک می‌کند |
اتصال مجدد، تکرار و داده قدیمی را آزمایش کنید
استاندارد MQTT از OASIS سطح‌های کیفیت تحویل را تعریف می‌کند. تحویل «حداقل یک بار» ممکن است پیام تکراری بسازد. حتی تحویل «دقیقاً یک بار» در پروتکل تضمین نمی‌کند پایگاه داده و محاسبه کسب‌وکار شما هر رویداد واقعی را در کل مسیر دقیقاً یک بار پردازش کند.
مقدار نگهداشتهشده ممکن است مدت‌ها پس از اندازهگیری به مشترک جدید برسد. زمان منبع را حفظ و تازگی را تعریف کنید؛ در صورت نیاز از سازوکار انقضای پشتیبانی‌شده استفاده کنید. نبود داده باید نبود داده بماند، نه صفر شبیه توقف خط.
مقدار OPC UA که تغییر نکرده ممکن است زمان منبع قدیمی داشته باشد، در حالی که منبع سالم است. وضعیت دریافت، زمان سرور یا نشانه ضربان مناسب را هم بررسی کنید. زمان قدیمی آخرین تغییر، بهتنهایی قطعی را ثابت نمی‌کند.
صفرشدن شمارنده تجمعی، جابه‌جایی ترتیب رویدادها، قطع اتصال و کیفیت نامعتبر را آزمایش کنید. شکست‌های متفاوت قواعد برخورد متفاوت می‌خواهند.
- یک کاربرد تحلیلی تعریف کنید
با یک سنجه فقط‌خواندنی شروع کنید و تأخیر مجاز، اعتبار و مرز گزارش را مشخص کنید.
- قرارداد را مستند کنید
شناسه تجهیز، نوع داده، واحد، معنای زمان، کیفیت، ساختار و شناسه رویداد را بنویسید.
- تحویل غیرعادی را آزمایش کنید
قطع اتصال، بازپخش، تکرار، مقدار نگهداشتهشده قدیمی، صفرشدن شمارنده و وضعیت نامعتبر منبع را شبیه‌سازی کنید.
- با سابقه قابل اتکا تطبیق دهید
پیش از گسترش، تغییر شمارش پذیرفته‌شده و بازه‌های زمانی را با سابقه تولیدی که مستقل بررسی شده مقایسه کنید.
کنترل و ایمنی را خارج از آزمایش نگه دارید
مسیر تحلیل نباید راهی برای فرمان‌های بررسی‌نشده به ماشین شود. دسترسی، گواهی، مجوز، جداسازی شبکه و تنظیمات امنیتی پشتیبانی‌شده، مسئول مشخص در محل و بررسی افراد صلاحیت‌دار می‌خواهند.
این مثال طراحی کنترل با زمان‌بندی قطعی نیست. تأخیر تحویل و دسترس‌پذیری داشبورد ابری شاید برای تحلیل روند قابل قبول، اما برای کنترل یا ایمنی نامناسب باشد. این مرز را صریح بنویسید.
مسیر را با شواهد قابل استفاده بسنجید
تازگی، وضعیت کیفیت، بازه‌های مفقود، تکرارهای ردشده و ناسازگاری ساختار را دنبال کنید. اگر همان مقدار قدیمی بارها برسد، تعداد خام پیام معیار خوبی برای موفقیت نیست.
وقتی سابقه قابل اتکا شد، تحلیل داده تولید و پایش تولید می‌توانند سؤال عملیاتی را پاسخ دهند. از یک ماشین و یک سنجه تطبیق‌داده‌شده شروع کنید و قرارداد را آگاهانه گسترش دهید.
چک‌لیست عملی
- الگوی پشتیبانی‌شده OPC UA و MQTT را تأیید کنید.
- JSON سفارشی را از PubSub مطابق استاندارد جدا کنید.
- هویت تجهیز و واحد را حفظ کنید.
- زمان منبع را جدا از زمان رسیدن نگه دارید.
- کیفیت منبع و نسخه ساختار را منتقل کنید.
- رویداد تکراری و صفرشدن شمارنده را مدیریت کنید.
- مقدار قدیمی نگهداشتهشده و بازه مفقود را آزمایش کنید.
- دسترسی تحلیل را از کنترل و ایمنی تأییدشده جدا نگه دارید.
پرسش‌های متداول
پرسش‌های متداول
منابع و مطالعهٔ بیشتر
منابع معتبر استفاده‌شده برای پژوهش و بررسی این راهنما.