برنامه‌ریزی ظرفیت CompactLogix L35E برای EtherNet/IP

CompactLogix 1769-L35E همچنان در ماشین‌آلاتی رایج است که از برنامه‌ریزی اولیه شبکه‌شان بیشتر عمر کرده‌اند. مشکلات توسعه معمولاً زمانی شروع می‌شوند که فهرست دستگاه‌ها به‌عنوان تعداد اتصال‌ها در نظر گرفته شود. ظرفیت EtherNet/IP به نوع ترافیکی که هر دستگاه ایجاد می‌کند، دفعات تبادل داده و منابع کنترلی‌ای که برنامه از قبل استفاده می‌کند بستگی دارد. بنابراین، یک بررسی ایمن باید با پروژه و عیب‌یابی واقعی آغاز شود، نه با یک قاعده عمومی برای تعداد دستگاه به‌ازای هر پورت.

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

با حد مجاز مستندشده کنترلر شروع کنید

راهنمای کاربر کنترلرهای 1769 CompactLogix شرکت Rockwell Automation اعلام می‌کند که L35E از 100 اتصال CIP پشتیبانی می‌کند. این یک محدودیت منابع است، نه مجوزی برای اتصال 100 دستگاه. یک دستگاه ممکن است به بیش از یک اتصال نیاز داشته باشد، در حالی که برخی ارتباطات می‌توانند از یک اتصال بهینه‌سازی‌شده به‌صورت مشترک استفاده کنند. ویرایش فریم‌ور، پیکربندی ماژول، تگ‌های تولیدشده و مصرف‌شده، پیام‌های ذخیره‌شده و کلاینت‌های HMI یا نظارتی همگی بر مجموع نهایی اثر می‌گذارند.

این کنترلر همچنین محصولی متوقف‌شده است. Rockwell، مدل 1769-L35E را از 20 دسامبر 2020 متوقف‌شده اعلام کرده است. این موضوع یک سیستم در حال کار را غیرقابل‌استفاده نمی‌کند، اما تصمیم مهندسی را تغییر می‌دهد: مشکل ظرفیت باید همراه با موجودی قطعات یدکی، پشتیبانی فریم‌ور، میزان آسیب‌پذیری امنیت سایبری و هزینه خرابی پیش‌بینی‌نشده ارزیابی شود.

موجودی اتصال‌ها را از روی پروژه تهیه کنید

پروژه آفلاینی را که با کنترلر در حال اجرا مطابقت دارد باز کنید و همه آداپتورهای I/O پیکربندی‌شده، درایوها، تگ‌های تولیدشده یا مصرف‌شده، مسیرهای پیام، سرورهای داده HMI، تاریخچه‌نگارها، درگاه‌ها و اتصال‌های برنامه‌نویسی را فهرست کنید. مشخص کنید هر تبادل از نوع I/O چرخه‌ای، داده تولیدشده، پیام صریح یا نظرسنجی کلاینت است. فقط بر اساس نام فروشنده، یک میزان ثابت برای اتصال در نظر نگیرید. پیکربندی واقعی مرجع اصلی است.

برای I/O توزیع‌شده، بررسی کنید قالب ارتباطی انتخاب‌شده اتصال‌های مستقیم ماژول یا اتصال بهینه‌شده رک ایجاد می‌کند. برای دستورالعمل‌های MSG، مشخص کنید کدام اتصال‌ها ذخیره می‌شوند و آیا چند پیام می‌توانند هم‌زمان فعال باشند. برای سیستم‌های نظارتی، مسیرهای ارتباطی مستقل را بشمارید و راهبرد نظرسنجی آن‌ها را بررسی کنید. یک صفحه‌گسترده باید هر اتصال فرض‌شده را به یک شیء پروژه یا پیکربندی آزمایش‌شده کلاینت مرتبط کند.

تعداد اتصال را از بار بسته‌ها جدا کنید

یک کنترلر ممکن است پایین‌تر از سقف اتصال خود باقی بماند، اما همچنان عملکرد ضعیفی در شبکه داشته باشد. فواصل درخواست بسته، بسامد پیام، اندازه بسته، رفتار چندپخشی، پیکربندی سوئیچ و جهش‌های ترافیکی ناشی از چند کلاینت بر بار بسته‌ها اثر می‌گذارند. RPIهای بسیار سریع باید با فرایند مکانیکی و پاسخ کنترلی موردنیاز توجیه شوند؛ سریع‌تر کردن همه دستگاه‌ها لزوماً ماشین را بهتر نمی‌کند.

هنگامی که ماشین به‌طور عادی در حال تولید است، یک خط مبنا ایجاد کنید. میزان استفاده از اتصال، شمارنده‌های خطای اترنت، پیام‌های ازدست‌رفته یا دارای زمان‌تمام‌شدن، وضعیت I/O، پاسخ‌گویی HMI و رفتار اسکن کنترلر را ثبت کنید. ثبت داده را هنگام راه‌اندازی، دانلود دستور ساخت، جهش‌های هشدار، دسترسی تعمیر و نگهداری و دیگر اوج‌های محتمل نیز تکرار کنید. میانگین‌ها می‌توانند بازه کوتاهی را که باعث خطای متناوب می‌شود پنهان کنند.

سوئیچینگ مدیریتی، توپولوژی مستندشده و اندازه‌گیری‌های تکرارپذیر، تشخیص خطاهای متناوب ظرفیت را ممکن می‌کنند.

از 1769-AENTR به‌عنوان پورت دوم L35E استفاده نکنید

1769-AENTR یک آداپتور EtherNet/IP برای بانک راه‌دور Compact I/O است که از طریق شبکه کنترل می‌شود. این تجهیز یک رابط اترنت توسعه‌ای برای افزایش ظرفیت ارتباطی کنترلر L35E نیست و نمی‌توان آن را به‌عنوان پورت دوم کنترلر متصل کرد تا ترافیک HMI یا پیام‌ها از رابط داخلی دور شود. طراحی بر پایه این فرض، توپولوژی‌ای ایجاد می‌کند که نمی‌تواند عملکرد ادعاشده را ارائه دهد.

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

بار قابل‌اجتناب را بدون پنهان‌کردن مشکل کاهش دهید

بهینه‌سازی باید الزامات فرایند را حفظ کند. مسیرهای رهاشده و کلاینت‌های بلااستفاده را حذف کنید. در صورت پشتیبانی پلتفرم و انواع ماژول‌ها، اتصال‌های I/O را تجمیع کنید. فقط اتصال‌های MSG را که به اجرای سریع و تکرارشونده نیاز دارند ذخیره کنید و پیام‌های غیرضروری را زمان‌بندی کنید تا همه هم‌زمان باز نشوند. فاصله RPI یا نظرسنجی را فقط پس از تأیید قابل‌قبول‌بودن زمان تشخیص، اینترلاک‌ها، هشدارها و کیفیت کنترل افزایش دهید.

از سوئیچ‌های صنعتی مدیریتی استفاده کنید و در صورت کاربرد، تنظیمات VLAN، چندپخشی و IGMP را مستند کنید. سوئیچ می‌تواند سیلاب غیرضروری ترافیک را کنترل و مشاهده‌پذیری را بهتر کند، اما نمی‌تواند منابع اتصال کنترلر ایجاد کند. به همین ترتیب، افزودن یک سوئیچ غیرمدیریتی تعداد پورت‌ها را تغییر می‌دهد، نه ظرفیت کنترلر را.

خطای مشکوک ظرفیت را به‌صورت روشمند تشخیص دهید

ابتدا پروژه در حال اجرا، شماره کاتالوگ کنترلر، ویرایش فریم‌ور و توپولوژی شبکه را تأیید کنید. سپس اتصال‌های پیکربندی‌شده را با عیب‌یابی زنده مقایسه کنید. به‌دنبال ماژول‌های I/O باشید که بین حالت اجرا و خطا جابه‌جا می‌شوند، دستورالعمل‌های MSG که در بار اوج زمانشان تمام می‌شود یا مقادیر HMI کهنه می‌شوند، در حالی که منطق کنترلر همچنان اجرا می‌شود.

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

توسعه‌ها را با آزمون‌های خرابی راه‌اندازی کنید

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

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