طراحی شبکههای صنعتی که همچنان عیبیابیپذیر بمانند
راهنمایی عملی برای بخشبندی، مستندسازی و آزمایش شبکههای اترنت صنعتی، تا تیمهای کارخانه بتوانند خطاها را سریع جدا کنند، تغییرات را کنترل کنند و بدون ایجاد وابستگیهای شکننده توسعه دهند.
خرابیهای اترنت صنعتی بهندرت ناشی از یک خطای چشمگیر در طراحی هستند. اغلب، یک کارخانه بهمرور مجموعهای از مصالحههای کوچک را انباشته میکند: افزودن یک سوئیچ مدیریتنشده هنگام توقف تعمیراتی، ثبتنشدن آدرسدهیهای تکراری، حلقهای که پس از توسعه هرگز آزمایش نشده، یا اجازهدادن به ترافیک تولید برای اشتراک مسیر با جمعآوری دادههای حجیم. ممکن است شبکه سالها کار کند و سپس، با تغییر کابل، سوئیچ یا پیکربندی، عیبیابی آن دشوار شود.
بنابراین، شبکهای که نگهداریپذیر باشد صرفاً نموداری از اتصالات نیست. این شبکه یک مدل عملیاتی است که مسیرهای ترافیک، مسئولیتها، مرزهای خرابی و رویههای بازیابی را آشکار میکند. هدف، بیشترین پیچیدگی ممکن نیست؛ بلکه طراحیای است که به تکنسینها اجازه دهد سریع به سه پرسش پاسخ دهند: چه چیزی تغییر کرده است، چه بخشهایی تحت تأثیر قرار گرفتهاند و آزمایش را از کجا باید آغاز کرد؟
با پیامد کنترلی شروع کنید
پیش از انتخاب VLAN، مسیریابی یا پروتکلهای افزونگی، مشخص کنید از دسترفتن ارتباطات برای فرایند چه معنایی دارد. اگر HMI یک سلول بستهبندی ارتباط خود را از دست بدهد، ممکن است سلول بهصورت ایمن متوقف شود. در یک خط هماهنگ، اختلاف بین شمارش محصولات تولیدشده و مصرفشده میتواند به تولید محصول معیوب منجر شود. یک واحد فرایندی ممکن است همچنان بهصورت محلی کنترل شود، اما دید نظارتی خود را از دست بدهد. این پیامدها تعیین میکنند کدام اتصالات به افزونگی نیاز دارند، کدام هشدارها باید بهصورت محلی مدیریت شوند و کدام جریانهای داده میتوانند تأخیر را تحمل کنند.
تولیدکنندگان و مصرفکنندگان هر اتصال مهم را مستند کنید. ترافیک PLC به I/O، پیامرسانی کنترلرها، کنترل درایو، ارتباطات مرتبط با ایمنی، نظرسنجی HMI، جمعآوری داده توسط تاریخچهنگار، دسترسی مهندسی، همگامسازی زمان و پشتیبانی از راه دور را در نظر بگیرید. این فهرست موجودی، از نقشهای که فقط پورتهای سوئیچ را نشان میدهد، کاربردیتر خواهد بود.
بر اساس کارکرد و مرز خرابی بخشبندی کنید
بخشبندی باید هم دامنه انتشار برادکست و هم پیامد عملیاتی را کاهش دهد. یک نقطه شروع رایج، جداسازی سلولهای ماشین، نواحی فرایندی، سرویسهای زیرساختی و برنامههای سطح کارخانه است. این مرز باید با شیوه بهرهبرداری و نگهداری کارخانه همخوان باشد. اگر یک تیم نگهداری مسئول کل یک خط است، یک ناحیه در سطح خط ممکن است از دهها زیرشبکه دلخواه شفافتر باشد. اگر یک اسکید بهصورت مستقل تأمین و سرویس میشود، مرز آن نیز باید قابل تشخیص باقی بماند.
بخشبندی بهتنهایی امنیت ایجاد نمیکند. ترافیک بین نواحی همچنان به قوانین صریح، مسیرهای پایششده و مدیریت کنترلشده نیاز دارد. راهنمای فعلی NIST برای امنیت فناوری عملیاتی بر معماریهایی تأکید میکند که الزامات عملکرد، قابلیت اطمینان و ایمنی OT را رعایت میکنند. در عمل، یعنی کنترلهای امنیتی باید بر اساس فرایند طراحی شوند، نه اینکه کورکورانه از IT اداری کپی شوند.
بخشبندی مفید از مالکیت فرایند پیروی میکند و محدوده تحت تأثیر خرابی یا تغییر غیرمجاز را محدود نگه میدارد.
مسیرهای پیشبینیپذیر بین نواحی ایجاد کنید
کنترلرهای موجود در بخشهای جداگانه همچنان به دادههای مشخصی نیاز دارند. مسیریابی باید این مسیرها را عمدی و شفاف کند. از ایجاد چند دروازه ثبتنشده بین نواحی یکسان خودداری کنید. هر مسیر اضافی، تحلیل بستهها، کنترل دسترسی و تحلیل خرابی را دشوارتر میکند. از زیرساخت مدیریتشده با پشتیبانگیری از پیکربندی، نامگذاری یکپارچه و قاعدهای روشن برای محل انجام مسیریابی استفاده کنید.
سوئیچهای صنعتی باید متناسب با محیط و فعالیتهای عیبیابی مورد انتظار انتخاب شوند. شمارندههای پورت، کشف توپولوژی، کنتاکتهای هشدار، همگامسازی زمان، خروجی پیکربندی و ثبت رویدادها اغلب هنگام خرابی مهمتر از سرعت اسمی ارسال داده هستند. کاتالوگ ارتباطات و شبکهسازی PLC ProTech نمونههایی از ماژولها و سوئیچهای مدیریتشدهای ارائه میدهد که معمولاً برای ساخت این مسیرها استفاده میشوند.
افزونگی نیز به هدفی مشخص نیاز دارد. یک حلقه میتواند از خرابی یک کابل محافظت کند، اما اگر کسی وضعیت حلقه را پایش نکند، ممکن است لینکهای آسیبدیده را پنهان کند. دو لینک بالادستی میتوانند دسترسپذیری را بهبود دهند، اما فقط زمانی که رفتار سوئیچینگ و مسیریابی بهخوبی درک شده باشد. هر طراحی افزونه باید برای قطع کابل، از دسترفتن برق سوئیچ، راهاندازی مجدد کنترلر و بازگشت سرویس، رویه آزمایش داشته باشد.
آدرسدهی و پیکربندی را کنترل کنید
طرح آدرسدهی باید بهعنوان داده مهندسی کنترلشده تلقی شود. نام دستگاه، نشانی IP، زیرشبکه، دروازه، پورت سوئیچ، نسخه میانافزار، مالک و محل تابلو را ثبت کنید. بازههایی را برای زیرساخت، کنترلرها، درایوها، HMIها، I/O راه دور و دستگاههای موقت راهاندازی رزرو کنید. به حافظه یا صفحهگستردهای که فقط یک نفر به آن دسترسی دارد متکی نباشید.
آدرسهای تکراری اغلب پس از بارگذاری پیکربندی قدیمی روی دستگاه جایگزین ظاهر میشوند. برای جلوگیری از این مشکل، رکورد تأییدشده شبکه را به فرایند تغییر پیوست کنید. پس از تعویض، فقط پاسخ پینگ را بررسی نکنید؛ هویت دستگاه، اطلاعات همسایهها، اتصالات فعال و عیبیابی کنترلر را نیز بررسی کنید. موفقیت در پینگ درباره درستبودن مسیر برنامه کاربردی اطلاعات بسیار کمی ارائه میدهد.
عیبیابی را پیش از خرابی طراحی کنید
سریعترین عیبیابی پیش از متوقفشدن تولید آغاز میشود. برای خطاهای پورت سوئیچ، میزان استفاده، نرخ چندپخشی، وضعیت حلقه، تعداد اتصالات کنترلر و تأخیر شبکه، یک خط مبنای سالم ایجاد کنید. از پیکربندیها نسخه پشتیبان تهیه کنید و تاریخ آخرین بازیابی تأییدشده را ثبت کنید. در صورت امکان، یک نقطه دسترسی پایششده برای ضبط بستهها فراهم کنید تا مهندسان هنگام قطعی مجبور به قراردادن یک سوئیچ جدید نباشند.
یک ستون فقرات مستند، برای هر ناحیه کنترل مسیر مشخص و محل مشخصی برای مشاهده ترافیک فراهم میکند.
ترتیب منظم عیبیابی
با علامت فرایند و دستگاههای تحت تأثیر شروع کنید. برق، وضعیت لینک و تغییرات اخیر را تأیید کنید. توپولوژی و شمارندههای فعلی را با خط مبنا مقایسه کنید. پیش از آزمایش در سراسر روتر یا فایروال، بهصورت محلی آزمایش کنید. اگر چند دستگاه همزمان از کار افتادند، سوئیچ، منبع برق، لینک بالادستی یا وابستگی مسیریابی مشترک آنها را بررسی کنید. پیش از راهاندازی مجدد تجهیزات، شواهد را ثبت کنید، زیرا راهاندازی مجدد ممکن است مفیدترین گزارشها را پاک کند.
مسئولیتهای IT و OT را شفاف نگه دارید
IT و OT به معماری مشترک، اما به فرضیات عملیاتی متفاوت نیاز دارند. تیمهای IT مدیریت هویت، رسیدگی به آسیبپذیریها، مدیریت فایروال و پایش سازمانی را به همراه میآورند. تیمهای OT زمان اسکن، پیامدهای ایمنی، پنجرههای نگهداری، پشتیبانی فروشنده و محدودیتهای بازیابی را درک میکنند. مسئولیت سوئیچها، فایروالها، سرورهای زمان، پشتیبانگیریها، گواهیها و حسابهای دسترسی از راه دور باید مشخص باشد.
کنترل تغییر، نقطه اتصال این دو حوزه است. یک قانون فایروال، بهروزرسانی میانافزار یا تعویض سوئیچ میتواند بر تولید اثر بگذارد، حتی اگر تغییر در جای دیگری عادی باشد. وجود برنامه بازگشت و مرحله تأیید تولید را الزامی کنید. دسترسی اضطراری را ممکن نگه دارید، اما استفاده از آن را ثبت و بررسی کنید.
ظرفیت را بدون پیشبینی همهچیز برنامهریزی کنید
هیچ طراحیای نمیتواند همه ماشینهای آینده را پیشبینی کند، اما میتواند گزینهها را حفظ کند. ظرفیت آدرسدهی مستند، پورتهای مدیریتشده اضافی، رشتههای فیبر در محلهای مستعد توسعه و فضای تابلو برای زیرساخت جدید در نظر بگیرید. ترافیک کنترلی را از تحلیلهای دادهمحور جدا کنید تا تاریخچهنگارها، دوربینها و سامانههای لبهای بتوانند توسعه یابند، بدون اینکه همان بودجه خرابی I/O قطعی و قابلپیشبینی را مصرف کنند.
نتیجهگیری روشن است: شبکه صنعتی خوب، شبکهای نیست که بیشترین قابلیتها را داشته باشد. شبکه خوب، شبکهای است که پس از سالها توسعه همچنان رفتار آن قابل توضیح باقی بماند. مرزهای شفاف، پیکربندیهای قابل بازیابی، خطمبناهای اندازهگیریشده و مالکیت مشترک، اترنت را از یک وابستگی نامرئی به دارایی مهندسیشده کارخانه تبدیل میکنند.