اسنایدر فاکسبورو SDA سیستم کنترل توزیعشده را بهسوی نرمافزار سوق میدهد
اشنایدر الکتریک در ۲ سپتامبر ۲۰۲۶ از اتوماسیون نرمافزارمحور فاکسبورو رونمایی کرد. این بررسی مهندسی، بازبودن، جایگذاری بارهای کاری، امنیت سایبری، دسترسپذیری و مهاجرت در سایتهای موجود را بررسی می...
اشنایدر الکتریک در ۲ سپتامبر ۲۰۲۶، در همایش رهبری صنعتی ARC در اورلاندو، EcoStruxure Foxboro Software Defined Automation را معرفی کرد. این شرکت آن را یک سیستم کنترل توزیعشده باز و نرمافزارمحور برای صنایع فرایندی و هیبریدی توصیف کرد. این اعلامیه جدید است، اما اهمیت مهندسی آن کمتر به این عنوان و بیشتر به نحوه پیادهسازی کارکردهای کنترلی، سختافزار، دسترسپذیری، امنیت سایبری و مسئولیتهای چرخه عمر بستگی دارد.
آنچه Schneider Electric اعلام کرد
Foxboro Software Defined Automation یا Foxboro SDA بهعنوان تکامل سبد محصولات Foxboro DCS معرفی شده است. اشنایدر میگوید این معماری، نرمافزار اتوماسیون را از سختافزار اختصاصی جدا میکند تا کارکردهای کنترلی با انعطافپذیری بیشتری استقرار یافته و نگهداری شوند. این پلتفرم با EcoStruxure Automation Expert کار میکند و هدف آن حفظ تداوم عملیاتی مورد انتظار از یک DCS، همزمان با کاهش وابستگی به یک نسل ثابت از کنترلرهاست.
اعلامیه شرکت بر بازبودن، امنیت سایبری تعبیهشده، هوشمندی بلادرنگ و نوسازی مرحلهای تأکید داشت. اشنایدر همچنین این عرضه را به پژوهشی که با Omdia انجام شده مرتبط کرد؛ پژوهشی که برآورد کرده است معماریهای کنترلی بسته میتوانند از طریق توقف تولید، ناکارآمدی و اصلاحات مربوط به انطباق، هزینههای قابلتوجهی ایجاد کنند. این برآوردهای کسبوکار به اعتبارسنجی اختصاصی در هر سایت نیاز دارند، اما مسئله مهندسی زیربنایی آشناست: منسوخشدن سختافزار، ارتقاهای بهشدت بههمپیوسته و رابطهای اختصاصی میتوانند ایجاد تغییر را پرهزینه کنند.
نرمافزارمحور بودن به معنای مستقل بودن از سختافزار نیست
یک برنامه کنترلی همیشه روی منابع فیزیکی محاسباتی، شبکه، توان، ورودی/خروجی و زمانبندی اجرا میشود. معماری نرمافزارمحور نحوه بستهبندی، تخصیص و مدیریت کارکردها را تغییر میدهد؛ اما این محدودیتها را از بین نمیبرد. مهندسان همچنان به اجرای قطعی، رفتار مشخص اسکن، همگامسازی زمانی، افزونگی، احراز صلاحیت محیطی و مهار خطا نیاز دارند.
پرسش طراحی این است که کدام مسئولیتها به نرمافزار منتقل میشوند و کدام همچنان به یک دستگاه وابسته میمانند. یک سرویس نظارتی مجازیسازیشده معمولاً میتواند زمانهای بازیابی متفاوتی نسبت به یک وظیفه کنترل حلقهبسته تحمل کند. یک کارکرد ایمنی، الزامات متفاوتی در زمینه گواهیپذیری، استقلال و کنترل تغییر نسبت به یک اتصالدهنده تاریخچهنگار دارد. کارخانهها باید پیش از تصمیمگیری درباره محل اجرای بارهای کاری، آنها را دستهبندی کنند.
برای تجهیزات نصبشده، این تمایز اهمیت دارد. مجموعه Foxboro سایت شامل خانوادههای سختافزاری است که کارخانههای موجود ممکن است در جریان گذار مرحلهای به پشتیبانی از آنها نیاز داشته باشند. یک برنامه نوسازی باید همه ماژولهای ورودی/خروجی، رابطهای فیلدباس، وابستگیهای کنترلر، بستههای کاربردی و جریانهای کاری نگهداری را مشخص کند و نباید خودکار فرض کند که قابلحمل بودن نرمافزار، محدودیتهای قدیمی را برطرف میکند.
ارزش بالقوه برای نوسازی کارخانههای موجود
ارتقاهای سنتی DCS اغلب چندین ریسک را همزمان دربرمیگیرند: تعویض کنترلر، تغییر سیستمعامل، تبدیل برنامه، مهاجرت شبکه، بازطراحی گرافیکها و آموزش مجدد اپراتورها. جداسازی کارکردها میتواند امکان گامهای مهاجرت کوچکتر را فراهم کند، اما فقط زمانی که رابطها و قواعد همزیستی بهطور شفاف تعریف شده باشند.
یک برنامه قدرتمند برای کارخانههای موجود باید مشخص کند کدام داراییها میتوانند حفظ شوند، کدام به درگاه نیاز دارند و کدام باید تعویض شوند. این برنامه باید نقاط بازگشت، معماریهای موقت، مالکیت داده و رفتار آزمودهشده هنگام از دست رفتن یک سرویس نرمافزاری جدید را تعریف کند. مزیت فقط به تعویق انداختن خرید سختافزار نیست؛ بلکه کاهش تعداد متغیرهایی است که در هر توقف تولید تغییر میکنند.
بازبودن به رابطهای قابلاندازهگیری نیاز دارد
معماری باز زمانی معنادار است که مهندسان بتوانند پروتکلهای پشتیبانیشده، مدلهای داده، APIها، مرزهای قابلحمل بودن و الزامات انطباق را شناسایی کنند. انتشار یک رابط تضمین نمیکند که دو تأمینکننده، هشدارها، وضعیت کیفیت، مُهرهای زمانی، افزونگی یا مالکیت پیکربندی را به یک شکل تفسیر کنند.
تیمهای خرید باید بپرسند کدام رابطها بهصورت بومی ارائه میشوند، کدام به اجزای اختیاری نیاز دارند و کدام فقط برای پایش در نظر گرفته شدهاند. همچنین باید مشخص کنند که آیا برنامههای شخص ثالث میتوانند در کنترل مشارکت کنند، به دادههای متنی و زمینهمند دسترسی داشته باشند یا فقط مقادیر انتخابشده را مصرف کنند. محدودیتهای عملکرد، سیاستهای بهروزرسانی، مجوزها و مسئولیتهای پشتیبانی باید در مشخصات فنی گنجانده شوند.
مجموعه سیستمهای DCS و کنترل زمینه لازم را برای پلتفرمهای نصبشدهای فراهم میکند که کارخانههای فرایندی با یکدیگر مقایسه میکنند. صرفنظر از معماری انتخابشده، اپراتورها به رفتار پایدار هنگام سوئیچکردن کنترلر، خطاهای شبکه، نگهداری سرور و از دست رفتن بخشی از زیرساخت نیاز دارند.
امنیت سایبری وارد چرخه عمر میشود
اشنایدر امنیت سایبری را بهعنوان بخشی تعبیهشده در معماری Foxboro SDA توصیف میکند. راهنمای امنیت سایبری ژوئیه ۲۰۲۶ و راهنمای فنی راهکار آن، به دلیل پرداختن به برنامهریزی و پیکربندی، نقطه شروع مفیدتری نسبت به زبان کلی اعلامیه عرضه فراهم میکنند. اسناد رسمی به معماری سیستم اشاره دارند؛ اما پیادهسازی در سایت است که وضعیت نهایی امنیتی را تعیین میکند.
سیستمهای نرمافزارمحور اهمیت هویت، مدیریت گواهی، نرمافزار امضاشده، تفکیک نقشها، ارزیابی وصلهها، ثبت رویداد، پشتیبانگیری و بازیابی را افزایش میدهند. آنها همچنین ممکن است در مقایسه با چرخه عمر سنتی کنترلر، تغییرات نرمافزاری مکررتری ایجاد کنند. کارخانهها به فرایندی کنترلشده برای آزمودن بهروزرسانیها در برابر برنامههای کنترلی، درایورها، گرافیکها، سرویسهای زمانی و افزونگی، پیش از استقرار در تولید، نیاز دارند.
زونبندی شبکه همچنان ضروری است. ترافیک مدیریتی، دسترسی مهندسی، ارتباطات کنترلی و تبادل داده سازمانی باید مسیرها و مجوزهای مشخصی داشته باشند. مدیریت از راه دور نباید به یک مسیر میانبُر ثبتنشده برای دور زدن فرایند دسترسی OT سایت تبدیل شود. پایش امنیتی باید فعالیتهای مورد انتظار هماهنگسازی را از تغییرات پیکربندی غیرمجاز متمایز کند.
دسترسپذیری باید در سطح کارکرد اثبات شود
ادعای دسترسپذیری یک DCS باید به سناریوهای خرابی تفکیک شود. هنگام از کار افتادن یک گره محاسباتی، قطع شدن مسیر شبکه، در دسترس نبودن سرویس هماهنگسازی یا ناقص ماندن استقرار نرمافزار چه رخ میدهد؟ کدام حلقههای کنترلی ادامه کار میدهند، کدام نماهای اپراتوری دچار افت میشوند و بازیابی چقدر طول میکشد؟
مهندسان باید برای زمان انتقال، همگامسازی وضعیت، انتقال بدون جهش، تداوم هشدارها، بافرگذاری تاریخچهنگار و بازیابی پس از خطاهای همزمان، شواهد مطالبه کنند. پشتیبانگیری با دسترسپذیری بالا یکسان نیست و افزونگی نیز تا زمانی که خطاهای با علت مشترک در نظر گرفته نشده باشند، مفید نخواهد بود. آزمون پذیرش کارخانه باید حالتهای تنزلیافته را نیز شامل شود، نه فقط عملکرد عادی را.
چگونه کارخانهها میتوانند Foxboro SDA را ارزیابی کنند
یک پایلوت محدود تعریف کنید
یک واحد غیرحیاتی یا سامانه آزمایشی نماینده را انتخاب کنید که دارای ورودی/خروجی واقعی، هشدارها، توالیها، ارتباطات و گرافیکهای اپراتوری باشد. عملکرد فعلی را مستند کنید تا معماری جدید با یک خط مبنا مقایسه شود.
همه وابستگیها را مشخص کنید
کنترلرها، ورودی/خروجی، سرورها، سوئیچها، منابع زمانی، سرویسهای دامنه، مجوزها، ابزارهای مهندسی و بستههای شخص ثالث را ثبت کنید. مشخص کنید مالک هر وابستگی چه کسی است و چگونه بازیابی میشود.
تغییر و بازیابی را آزمایش کنید
یک بهروزرسانی نرمافزاری اعمال کنید، آن را بازگردانید، یک گره خراب را تعویض کنید، مسیرهای شبکه را قطع کنید و از نسخه پشتیبان بازیابی کنید. تأیید کنید که رویهها با مهارتها و ابزارهای موجود در کارخانه قابل اجرا هستند.
ادعاها را از معیارهای پذیرش جدا کنید
بازبودن، انعطافپذیری و امنیت سایبری را به الزامات قابلاندازهگیری تبدیل کنید. نمونهها شامل نسخههای پروتکل پشتیبانیشده، حداکثر زمان بازیابی، سیستمعاملهای اعتبارسنجیشده، مدت نگهداری گزارشها، مجوزهای نقشها و محدودیتهای اجرای کنترلر هستند.
دیدگاه مهندسی
Foxboro SDA تلاشی جدی برای تغییر نحوه استقرار و نوسازی قابلیتهای DCS است. اعلامیه رسمی اشنایدر الکتریک درباره عرضه در ۲ سپتامبر جهتگیری محصول را مشخص میکند، در حالی که راهنمای فنی راهکار Foxboro SDA زمینه اجرای آن را ارائه میدهد.
فرصت اصلی، انعطافپذیری بیشتر هنگام نوسازی است. خطر، تلقی کردن انتزاع بهعنوان مدرکی برای ناپدید شدن مشکلات زمانبندی، امنیت، دسترسپذیری و پشتیبانی است. کارخانههایی که از دستهبندی بارهای کاری، مهاجرت مرحلهای، رابطهای شفاف و آزمون پذیرش مبتنی بر خطا استفاده میکنند، موقعیت بهتری برای ارزیابی محل ایجاد ارزش این معماری خواهند داشت.