Skip to content
قطعات اتوماسیون، تامین جهانی
Stop PLC Brand Silos: Edge Integration That Works

پایان انحصار برند PLC: یکپارچه‌سازی لبه که کار می‌کند

محیط‌های PLC چندبرندی واقعیت اکثر کارخانه‌ها هستند، اما روش‌های سنتی یکپارچه‌سازی مانند سرورهای OPC باعث تأخیر، نقاط شکست منفرد و هزینه‌های بالای مجوز می‌شوند. این مقاله جایگزین‌های آزمایش‌شده توسط مهندسین را با استفاده از محاسبات لبه، کتابخانه‌های پروتکل متن‌باز مانند Snap7 و libplctag، و تکنیک‌های بافرینگ ناهمزمان ارائه می‌دهد. این مقاله شامل فیلتر کردن عملی داده‌ها، مدیریت چرخه عمر بر اساس پروفایل‌های ریسک، و یک مثال واقعی از پل زدن بین Siemens S7-1500 و Rockwell CompactLogix است.

اتصال چند برند PLC: رویکردهای فنی و بهترین شیوه‌های مهندسی

واقعیت صنعتی محیط‌های ترکیبی PLC

کارخانه‌های تولیدی اغلب چندین برند PLC را در خطوط تولید مختلف به‌کار می‌گیرند. تجهیزات زیمنس، راکول اتوماسیون، امرون، میتسوبیشی و اشنایدر الکتریک اغلب در یک کارخانه هم‌زمان وجود دارند. این تنوع ناشی از ارتقاء سیستم‌های قدیمی، ادغام‌ها و استراتژی‌های خرید بهترین‌ها است. بر اساس ممیزی بیش از ۵۰ واحد صنعتی، تنها ۱۲٪ از یک برند PLC استفاده می‌کنند. ۸۸٪ باقی‌مانده روزانه بین دو تا پنج برند کنترل‌کننده مختلف را مدیریت می‌کنند.

موانع سطح پروتکل بین برندهای کنترل‌کننده

هر برند PLC پروتکل‌های ارتباطی اختصاصی خود را پیاده‌سازی می‌کند. زیمنس از ارتباط S7 بر بستر ISO-on-TCP برای سری‌های S7-1200 و S7-1500 استفاده می‌کند. راکول اتوماسیون از EtherNet/IP با پیام‌رسانی CIP (پروتکل صنعتی مشترک) بهره می‌برد. امرون از پروتکل FINS یا پشته ارتباطی سری NY استفاده می‌کند. میتسوبیشی به پروتکل MC بر بستر TCP/IP متکی است. داده‌های یک برند کنترل‌کننده نمی‌توانند بدون لایه ترجمه مستقیماً به برند دیگر منتقل شوند. این محدودیت اپراتورها را مجبور می‌کند داده‌های تولید را به‌صورت دستی بین صفحه‌نمایش‌های HMI جداگانه منتقل کنند یا داشبوردها را از چندین منبع داده بازسازی نمایند. مدیریت دستی داده‌ها حدود سه ساعت در هفته برای هر خط تولید زمان می‌برد و خطاهای رونویسی ایجاد می‌کند که می‌تواند فرآیندهای تولید را مختل کند.

محدودیت‌های روش‌های سنتی یکپارچه‌سازی

سرورهای OPC Classic و OPC UA رایج‌ترین روش برای یکپارچه‌سازی چند برند PLC هستند. این سرورها محدودیت‌های عملیاتی متعددی ایجاد می‌کنند. آن‌ها به‌عنوان نقاط شکست واحد در شبکه کنترل عمل می‌کنند. نیازمند مدیریت مداوم مجوز و به‌روزرسانی‌های منظم سیستم‌عامل ویندوز هستند. در حفظ عملکرد با داده‌های کنترل حرکت با سرعت بالا که نیازمند زمان اسکن کمتر از ۵ میلی‌ثانیه هستند، مشکل دارند. در یک نصب مستند شده در یک کارخانه خودروسازی، یک پل OPC در طول یک شیفت تولید دوازده بار به دلیل به‌روزرسانی‌های خودکار ویندوز دچار خرابی شد. مبدل‌های پروتکل مانند دروازه‌های Profinet به EtherNet/IP تا ۱۰ تا ۳۰ میلی‌ثانیه تأخیر اضافه می‌کنند و نمی‌توانند به‌درستی دسترسی پارامترهای آ سیکلیک یا تشخیص‌های گسترده دستگاه را مدیریت کنند.

معماری یکپارچه‌سازی مبتنی بر ارکستراسیون

یک معماری مؤثرتر هر برند PLC را به عنوان یک مؤلفه تخصصی در یک سیستم اتوماسیون بزرگ‌تر در نظر می‌گیرد. کنترل‌کننده‌های زیمنس در کنترل فرآیندهای پیچیده با تنظیم پیشرفته PID و بلوک‌های عملکرد کنترل دما برتری دارند. کنترل‌کننده‌های راکول کنترل حرکت با سرعت بالا را از طریق معماری محور یکپارچه و سیستم‌های درایو Kinetix ارائه می‌دهند. کنترل‌کننده‌های اومرون برنامه‌ریزی وظایف مبتنی بر رویداد را که برای توالی‌های بسته‌بندی ایده‌آل است، فراهم می‌کنند. به جای جایگزینی یا برنامه‌نویسی مجدد کنترل‌کننده‌های موجود، مهندسان باید کد بومی را حفظ کرده و یک لایه میان‌افزار ارتباطی اضافه کنند. این رویکرد هزینه و ریسک بازنویسی بلوک‌های عملکرد SCL زیمنس به متن ساختاری راکول یا بالعکس را کاهش می‌دهد.

محاسبات لبه برای نرمال‌سازی داده چند برند

ادغام مبتنی بر پرس‌وجوی سنتی هر ۱۰۰ تا ۱۰۰۰ میلی‌ثانیه درخواست داده‌های مکرر از سرور مرکزی ارسال می‌کند. این روش ترافیک شبکه را افزایش داده و پاسخ‌های بلادرنگ را به تأخیر می‌اندازد. محاسبات لبه گره‌های پردازشی کوچکی را در کنار هر PLC یا گروهی از PLCها مستقر می‌کند. این گره‌ها کتابخانه‌های درایور بومی هر برند را اجرا می‌کنند. برای کنترل‌کننده‌های زیمنس، گره از کتابخانه‌های libnodave یا Snap7 برای خواندن بلوک‌های داده S7-1200 و S7-1500 استفاده می‌کند. برای راکول، از CIP روی اترنت با پیام‌رسانی صریح برای خواندن آرایه‌های تگ استفاده می‌کند. برای میتسوبیشی، از پروتکل MC روی TCP/IP بهره می‌برد. سپس گره لبه داده‌های جمع‌آوری شده را به یک طرح مشترک نرمال‌سازی کرده، قوانین فیلترینگ را اعمال می‌کند و داده‌های باقی‌مانده را با استفاده از پروتکل‌های MQTT یا Sparkplug B برای سیستم‌های مرکزی بسته‌بندی می‌کند.

یک کارخانه تولید پلاستیک که این معماری لبه را پیاده‌سازی کرده بود، کاهش ۷۳٪ در بار پردازش سرور مرکزی را به دست آورد. تأخیر داده از ۸۰۰ میلی‌ثانیه به کمتر از ۵۰ میلی‌ثانیه کاهش یافت. گره لبه مقادیر ثابت مانند نام دستگاه‌ها و عوامل مقیاس‌بندی را به صورت محلی کش کرد و تنها متغیرهای فرآیند پویا را ارسال کرد. فیلتر کردن Deadband از ارسال نوسانات بی‌اهمیت مقدار جلوگیری کرد. خوانش دما که بین ۱۰۰.۰ و ۱۰۰.۱ درجه نوسان داشت، هیچ انتقال شبکه‌ای ایجاد نکرد. فقط زمانی که مقدار از آستانه ۱۰۱.۰ درجه عبور کرد، گره به‌روزرسانی ارسال کرد. این کار ترافیک شبکه را برای فرآیندهای تولید پایدار تا ۴۰ برابر کاهش داد.

سلسله مراتب فیلتر داده برای کاربردهای صنعتی

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

  • فیلتر کردن سطح یک: حذف تمام مقادیر باقی‌مانده در محدوده‌های عملکرد عادی.
  • فیلتر سطح دو: فقط زمان‌سنج‌ها را زمانی ذخیره کنید که مقادیر از آستانه‌های تعریف شده عبور کنند.
  • فیلتر سطح سه: برای پارامترهای ایمنی حیاتی، داده خام کامل را به مدت ۳۰ روز ذخیره کنید. برای پارامترهای غیر حیاتی، فقط مقادیر تجمیع شده روزانه را ذخیره کنید.

بافر غیرهمزمان برای پل زدن پروتکل‌ها

پل زدن بین پروتکل‌های مختلف PLC نیازمند درک تفاوت‌های رفتار زمانی است. پروفینت IRT زمان‌های چرخه‌ای تا ۳۱.۲۵ میکروثانیه را فراهم می‌کند اما به سخت‌افزار شبکه همگام نیاز دارد. پیام‌رسانی ضمنی EtherNet/IP در مقادیر معمول RPI (فاصله بسته درخواستی) بین ۲ تا ۱۰۰ میلی‌ثانیه عمل می‌کند. پل زدن مستقیم یک دستگاه پروفینت با سرعت بالا به شبکه EtherNet/IP کندتر باعث ایجاد فشار برگشتی می‌شود که عملکرد را کاهش می‌دهد. بافر غیرهمزمان این مشکل را حل می‌کند. دستگاه پل داده‌ها را از شبکه سریع‌تر به یک بافر حافظه دوپورت می‌خواند. شبکه کندتر با سرعت خود از این بافر می‌خواند. این دو زمان چرخه را از هم جدا می‌کند. بافر باید عمق کافی برای مدیریت تفاوت‌های اوج انفجار داشته باشد. برای دستگاه پروفینتی که ۱۰۰۰ مقدار در هر میلی‌ثانیه به دستگاه EtherNet/IP می‌فرستد که هر ۱۰ میلی‌ثانیه می‌خواند، بافر باید حداقل ۱۰٬۰۰۰ مقدار را نگه دارد. بافرهای کوچک‌تر در اوج تولید سرریز می‌کنند و باعث شکست یکپارچه‌سازی می‌شوند.

نوع داده زیمنس نوع داده راکول نیاز تبدیل
REAL (عدد اعشاری شناور ۳۲ بیتی) REAL (عدد اعشاری شناور ۳۲ بیتی) هیچ‌کدام، اما ترتیب بایت (اندینس) را بررسی کنید
LREAL (عدد اعشاری شناور ۶۴ بیتی) LINT (عدد صحیح ۶۴ بیتی) / معادل مستقیم ندارد تبدیل به REAL یا پیاده‌سازی تبدیل آرایه سفارشی
DINT (عدد صحیح ۳۲ بیتی با علامت) DINT (عدد صحیح ۳۲ بیتی با علامت) نگاشت مستقیم
UDINT (عدد صحیح ۳۲ بیتی بدون علامت) نوع بدون علامت بومی وجود ندارد استفاده از DINT با بررسی محدوده

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

مدیریت چرخه عمر PLC مبتنی بر ریسک

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

  • پروفایل ریسک حرارتی (دمای محیط بالای ۵۰ درجه سانتی‌گراد): خازن‌های الکترولیتی را هر ۴۰,۰۰۰ ساعت کاری تعویض کنید. پیر شدن خازن طبق مدل آرنیوس است. هر افزایش ۱۰ درجه سانتی‌گراد عمر سرویس خازن را ۵۰٪ کاهش می‌دهد.
  • پروفایل ریسک مکانیکی (ارتعاش بالای ۰.۵g): هر شش ماه کانکتورها و ترمینال‌های پشت‌صفحه را بررسی کنید. ارتعاش باعث شل شدن ترمینال‌های پیچ می‌شود که منجر به خرابی‌های اتصال متناوب و دشوار در تشخیص می‌گردد.
  • پروفایل ریسک الکتریکی (محیط‌های برق ناپایدار): سیستم‌های UPS آنلاین نصب کنید و ریپل باس DC را نظارت کنید. ریپل بیش از ۱۰٪ نشان‌دهنده خرابی قریب‌الوقوع فیلتر منبع تغذیه است.

چارچوب تصمیم‌گیری خرید PLC

تصمیمات خرید که فقط بر اساس قیمت واحد گرفته می‌شوند اغلب هزینه کل مالکیت را نادیده می‌گیرند. کنترلری با هزینه کمتر ممکن است پشتیبانی پروتکل بومی برای سیستم‌های موجود کارخانه نداشته باشد و هزینه‌های یکپارچه‌سازی می‌تواند هر صرفه‌جویی اولیه را از بین ببرد. گاهی PLCهای دارای گواهی ایمنی برای کاربردهای غیر ایمنی به دلیل تخفیف‌های فروشنده خریداری می‌شوند. این کار باعث هدررفت بودجه و منحرف شدن موجودی دارای گواهی ایمنی از کاربردهایی می‌شود که واقعاً به آن نیاز دارند. ماتریس تصمیم‌گیری مبتنی بر سطح یکپارچگی ایمنی (SIL) مورد نیاز، نتایج خرید را بهبود می‌بخشد.

  • نیاز به SIL 2 یا بالاتر: PLC دارای گواهی ایمنی با بلوک‌های عملکردی تأییدشده انتخاب کنید.
  • بدون نیاز ایمنی: PLC استاندارد با پیکربندی I/O بهینه‌شده از نظر هزینه انتخاب کنید.

PLCهای دارای گواهی ایمنی در هر چرخه اسکن تست‌های تشخیصی اجرا می‌کنند که زمان اسکن را افزایش می‌دهد. استفاده از PLC ایمنی برای کاربردهای بسته‌بندی با سرعت بالا باعث کاهش توان عملیاتی می‌شود. در یک نصب مستند، کنترلر Siemens ET 200SP Failsafe روی یک بخش ساده نقاله به کار گرفته شد. زمان اسکن ۱۵۰ میلی‌ثانیه‌ای CPU ایمنی باعث ایجاد پشتیبان‌گیری در منطقه تجمع به مدت ۱.۵ ثانیه شد. جایگزینی آن با ET 200SP استاندارد زمان اسکن را به ۸ میلی‌ثانیه کاهش داد و گلوگاه را برطرف کرد.

نگهداری پیش‌بینانه عملی با استفاده از داده‌های موجود PLC

داشبوردهای نگهداری پیش‌بینانه با شاخص‌های بصری متعدد اغلب داده‌های بیشتری نسبت به آنچه اپراتورها می‌توانند به‌طور مؤثر نظارت کنند ارائه می‌دهند. هشدارهای ساده آستانه‌ای برای پارامترهای حیاتی بیشتر حالت‌های خرابی را شناسایی می‌کنند. خرابی بلبرینگ باعث افزایش قابل تشخیص ارتعاش و دما چند ساعت قبل از خرابی کامل می‌شود. افزایش دما به میزان ۴۰ درجه سانتی‌گراد نیازی به الگوریتم یادگیری ماشین برای شناسایی ندارد. بودجه‌های اتوماسیون باید ابتدا بر نظارت آستانه‌ای پایه اولویت دهند. یادگیری ماشین باید فقط برای الگوهای خرابی پیچیده که اپراتورهای انسانی به‌راحتی نمی‌توانند تشخیص دهند اضافه شود. سه منبع داده اصلی از نگهداری پیش‌بینانه مبتنی بر PLC پشتیبانی می‌کنند.

  1. رجیسترهای تشخیصی درون خود PLC. زیمنس بافرهای تشخیصی گسترده‌ای ارائه می‌دهد که از طریق SFB 52 (RDREC) قابل دسترسی هستند. راکول دستورالعمل‌های GSV (دریافت مقدار سیستم) را برای بازیابی وضعیت ماژول فراهم می‌کند.
  2. داده‌های کانال ورودی/خروجی شامل روندهای ورودی آنالوگ.
  3. آمار ارتباطی مانند تعداد تلاش‌های مجدد و خطاهای CRC (بررسی افزونگی چرخه‌ای). افزایش نرخ خطای CRC در یک بخش Profibus نشان‌دهنده تخریب لایه فیزیکی قبل از خرابی کامل است.

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

مثال فنی: پل زیمنس S7-1500 به راکول CompactLogix

یک اسکیید مخلوط‌کن کنترل‌شده توسط زیمنس S7-1500 محصول را به خط بسته‌بندی کنترل‌شده توسط راکول CompactLogix تغذیه می‌کند. اسکیید مخلوط‌کن باید وضعیت اتمام بچ، دمای نهایی محصول و مقدار ویسکوزیته را به خط بسته‌بندی ارسال کند. خط بسته‌بندی باید سیگنال آماده بودن و شمارش رد را به اسکیید مخلوط‌کن بازگرداند. اتصال OPC UA یک رایانه ویندوزی را به عنوان نقطه احتمالی خرابی اضافه می‌کند. یک گیت‌وی لبه با درایورهای بومی S7 و CIP راه‌حلی مقاوم‌تر ارائه می‌دهد.

گیت‌وی هر ۱۰۰ میلی‌ثانیه مقادیر DB100.DBD0 (وضعیت بچ به صورت DINT) و DB100.DBD4 (دما به صورت REAL) را از کنترلر زیمنس می‌خواند. این مقادیر را به تگ‌های راکول با نام‌های Mixer_Batch_Status و Mixer_Temperature می‌نویسد. در جهت معکوس، گیت‌وی هر ۵۰۰ میلی‌ثانیه تگ‌های راکول Pack_Ready (BOOL) و Pack_Reject_Count (DINT) را می‌خواند و آن‌ها را به DB200.DBX0.0 و DB200.DBD2 زیمنس می‌نویسد. گیت‌وی تبدیل نوع داده را به‌صورت خودکار انجام می‌دهد. نظارت بر ضربان قلب به این صورت پیاده‌سازی شده است: اگر گیت‌وی سه چرخه خواندن متوالی از هر یک از PLCها را از دست بدهد، هشدار سیستمی صادر کرده و خروجی‌ها را به حالت‌های ایمن می‌برد.

این پیکربندی به‌طور قابل اطمینانی روی یک رزبری پای صنعتی با کرنل زمان واقعی و هزینه سخت‌افزاری تقریباً ۴۰۰ دلار اجرا می‌شود. هزینه کل یکپارچه‌سازی شامل برنامه‌نویسی ۳۲۰۰ دلار بود. جایگزینی کامل PLC برای یکپارچه‌سازی برندها هزینه‌ای معادل ۸۵۰۰۰ دلار به‌علاوه سه هفته توقف تولید داشت.

مطالعه موردی: یکپارچه‌سازی چندبرندی در یک کارخانه تولید سیمان

یک تولیدکننده سیمان در جنوب شرق آسیا پنج برند مختلف PLC را در بخش‌های خردایش، کوره و بسته‌بندی به کار می‌برد. کارکنان مهندسی هر ماه دو روز کامل را صرف هماهنگ‌سازی گزارش‌های تولید از سیستم‌های مختلف می‌کردند. گره‌های لبه با استفاده از Node-RED که روی کامپیوترهای صنعتی اجرا می‌شدند به عنوان راه‌حل یکپارچه‌سازی مستقر شدند. هر گره کانتینرهای داکر جداگانه‌ای برای هر پشته ارتباطی برند PLC اجرا می‌کرد. کانتینر زیمنس از بسته node-red-contrib-s7 استفاده می‌کرد. کانتینر راکول از بسته node-red-contrib-cip-ethernet-ip بهره می‌برد. یک کانتینر Modbus دستگاه‌های اشنایدر الکتریک و سایر دستگاه‌های ثالث را مدیریت می‌کرد.

گره‌های لبه داده‌ها را به صورت محلی تجمیع کرده و بارهای JSON نرمال‌شده را به یک بروکر MQTT ارسال کردند. داشبورد مرکزی Node-RED به موضوعات MQTT مشترک شد و معیارهای یکپارچه را در تمام برندها نمایش داد. کل هزینه سخت‌افزار و نرم‌افزار کمتر از ۱۵۰۰۰ دلار بود. زمان توقف‌های غیر برنامه‌ریزی شده در عرض چهار ماه پس از استقرار ۲۷٪ کاهش یافت. برق‌کاران دیگر نیازی به حمل سه لپ‌تاپ برنامه‌نویسی مختلف نداشتند. آن‌ها اکنون از طریق رابط ترمینال مبتنی بر وب گره لبه به هر PLC متصل می‌شوند.

نقشه راه پیاده‌سازی برای کارخانه‌های چندبرندی

با مستندسازی هر PLC در کارخانه شروع کنید، شامل برند، مدل، نسخه فریمور و پروتکل‌های پشتیبانی شده. یک صفحه گسترده با ستون‌هایی برای آدرس IP، نوع پروتکل (S7، EtherNet/IP، Modbus TCP، FINS، پروتکل MC)، زمان اسکن مورد نیاز و سطح اهمیت ایجاد کنید. سه جریان داده با ارزش‌ترین که در حال حاضر از مرزهای برند عبور می‌کنند را شناسایی کنید. یک سلول تولید غیر بحرانی را به عنوان منطقه آزمایشی انتخاب کنید. فقط برای آن سلول، یک دروازه پروتکل متن‌باز یا گره لبه مستقر کنید. صرفه‌جویی در زمان اپراتور و کاهش خطا را اندازه‌گیری کنید. پس از تأیید بهبودهای قابل اندازه‌گیری، به سلول‌های دیگر گسترش دهید.

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

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

نوشته شده توسط گو جینهونگ، مهندس اتوماسیون صنعتی متخصص در راه‌حل‌های PLC و DCS برای صنایع نفت، گاز و شیمیایی.

Back To Blog