از کنترل PLC-محور تا اتوماسیون تعریف‌شده با نرم‌افزار
اتوماسیون صنعتی در حال عبور از مدل سنتی PLCهای اختصاصی، میکروکنترلرها و ماشین‌های با عملکرد ثابت است. سامانه‌های مدرن به‌طور فزاینده‌ای کنترل مبتنی بر PLC را با MPUها و SoCهای با کارایی بالا ترکیب می‌کنند تا بارهای کاری HMI، بینایی ماشین، تحلیل لبه‌ای، اتصال‌پذیری، دوقلوهای دیجیتال و هوش مصنوعی را مدیریت کنند.
این تحول معماری‌های کنترلی سنتی را منسوخ نمی‌کند. در عوض، معماری‌ای لایه‌ای ایجاد می‌کند که در آن PLCها همچنان می‌توانند کنترل قطعیِ سطح میدان را انجام دهند، در حالی که سکوهای محاسباتی با کارایی بالاتر، وظایف نظارتی، تحلیلی، بصری‌سازی و هوش مصنوعی را اجرا می‌کنند.
از دیدگاه مهندسی، مسئلهٔ مهم صرفاً افزودن ظرفیت محاسباتی نیست. چالش واقعی این است که اطمینان حاصل شود این بارهای کاری اضافی نمی‌توانند زمان‌بندی، دسترس‌پذیری یا یکپارچگی عملکردهای کنترلی تثبیت‌شده را به خطر بیندازند.
هوش مصنوعی فیزیکی چالش جدیدی برای اتوماسیون ایجاد می‌کند
معرفی هوش مصنوعی فیزیکی، معماری سامانه را دشوارتر می‌کند، زیرا اطلاعات تولیدشده توسط هوش مصنوعی می‌تواند بر تجهیزات فیزیکی و تصمیم‌های عملیاتی تأثیر بگذارد.
یک مدل هوش مصنوعی ممکن است وضعیت غیرعادی ماشین را شناسایی کند، ناهنجاری بصری را تشخیص دهد، از بازرسی پیش‌بینانه پشتیبانی کند یا وضعیتی مرتبط با اپراتور را شناسایی کند. بااین‌حال، نتیجهٔ استنتاج هوش مصنوعی تنها یک بخش از زنجیرهٔ کامل اتوماسیون است.
سامانه همچنان باید اطلاعات حسگرها را دریافت کند، مدل هوش مصنوعی را اجرا کند، زمینهٔ عملیاتی را اعتبارسنجی کند، سیاست‌های کنترلی از پیش تعریف‌شده را اعمال کند و وضعیت حاصل را به برنامهٔ کاربردی یا اپراتور مناسب منتقل کند.
از دیدگاه من، بنابراین هوش مصنوعی صنعتی باید به‌عنوان یک بار کاری پشتیبان تصمیم‌گیری یا پاسخ کنترل‌شده، نه یک لایهٔ هوشمند مجزا در نظر گرفته شود. این سکوی اتوماسیون پیرامونی است که تعیین می‌کند آیا اطلاعات هوش مصنوعی می‌تواند در چارچوب‌های زمانی و ایمنی موردنیاز پردازش و بر اساس آن اقدام شود یا نه.
بارهای کاری با اهمیت حیاتی ترکیبی به جداسازی واقعی نیاز دارند
پردازنده‌های چندهستهای مدرن امکان یکپارچه‌سازی وظایفی را فراهم می‌کنند که پیش‌تر به سکوهای سخت‌افزاری جداگانه نیاز داشتند. اکنون یک سامانهٔ محاسباتی واحد می‌تواند میزبان کنترل بلادرنگ سخت، سرویس‌های HMI، شبکه‌سازی، عیب‌یابی، ثبت رویداد، بینایی ماشین، تحلیل داده و استنتاج هوش مصنوعی باشد.
این بارهای کاری الزامات یکسانی ندارند.
یک وظیفهٔ کنترل بلادرنگ سخت ممکن است مهلت اجرای بسیار دقیقی داشته باشد. یک HMI می‌تواند ویژگی‌های زمانی متفاوتی را تحمل کند، در حالی که یک فرایند استنتاج هوش مصنوعی ممکن است به منابع قابل‌توجهی از CPU نیاز داشته باشد. سرویس‌های شبکه نیز مسیرهای ارتباطی خارجی ایجاد می‌کنند که نباید دسترسی نامحدود به منابع حیاتی داشته باشند.
در نتیجه، صرفاً قرار دادن چند برنامه روی یک پردازنده چندهستهای، به‌طور خودکار معماری تاب‌آوری ایجاد نمی‌کند.
محیط اجرایی باید سازوکارهایی برای جداسازی زمانی، حفاظت از حافظه، کنترل منابع و مهار خطا فراهم کند.
یکپارچه‌سازی سخت‌افزار برابر با تاب‌آوری نیست
یکپارچه‌سازی سخت‌افزار می‌تواند تعداد سکوهای محاسباتی را کاهش دهد، سیم‌کشی را ساده کند و یکپارچگی را افزایش دهد. بااین‌حال، این کار یک نقطه بالقوه خرابی مشترک نیز ایجاد می‌کند.
اگر بارهای کاری نامرتبط از یک پردازنده و محیط اجرایی مشترک استفاده کنند، یک درایور معیوب، برنامه خارج از کنترل، خطای حافظه یا سرویس در معرض نفوذ می‌تواند بر عملکردهای دیگر تأثیر بگذارد؛ مگر اینکه معماری نرم‌افزار مرزهای مناسبی ایجاد کرده باشد.
این یکی از مهم‌ترین ملاحظات هنگام نوسازی اتوماسیون قدیمی است.
هدف نباید صرفاً انتقال عملکردهای بیشتر به پردازنده‌های کمتر باشد. هدف باید یکپارچه‌سازی بارهای کاری بدون ایجاد وابستگی‌های غیرقابل‌قبول میان آن‌ها باشد.
سیستم‌عامل به یک لایه اعمال سیاست تبدیل می‌شود
در یک معماری اتوماسیون نرم‌افزارمحور، سیستم‌عامل دیگر صرفاً بستری نیست که برنامه‌ها روی آن اجرا شوند.
این معماری تعیین می‌کند فرایندها چگونه زمان‌بندی شوند، حافظه چگونه محافظت شود، منابع سخت‌افزاری چگونه مورد دسترسی قرار گیرند و سرویس‌های منفرد چگونه با یکدیگر تعامل داشته باشند. این سازوکارها مستقیماً بر توانایی سیستم برای حفظ عملکرد هنگام ازکارافتادن یک مؤلفه منفرد تأثیر می‌گذارند.
بنابراین، یک معماری تاب‌آور باید بتواند سرویس ازکارافتاده را ایزوله کند و، در صورت امکان طبق طراحی سیستم، آن سرویس را بدون راه‌اندازی مجدد برنامه‌های نامرتبط بازیابی کند.
این رویکرد به‌ویژه برای سیستم‌های صنعتی مرتبط است؛ جایی که راه‌اندازی مجدد کامل سیستم می‌تواند عملیات کنترل، مصورسازی، ارتباطات یا تولید را مختل کند.
اهمیت معماری میکروکرنل
یک سیستم‌عامل یکپارچه متعارف معمولاً بسیاری از سرویس‌ها، درایورها، سیستم‌های فایل و مؤلفه‌های شبکه را در محیطی با سطح دسترسی بسیار بالا در کرنل قرار می‌دهد.
یک میکروکرنل رویکرد معماری متفاوتی دارد. این معماری مجموعه کوچک‌تری از عملکردهای بنیادی را در کرنل نگه می‌دارد و در عین حال اجازه می‌دهد بسیاری از درایورها، پشته‌های پروتکل، سیستم‌های فایل و سرویس‌های سیستم به‌صورت فرایندهای جداگانه در فضاهای آدرس محافظت‌شده اجرا شوند.
برای اتوماسیون صنعتی، این معماری می‌تواند چندین ویژگی مفید فراهم کند:
- مهار خطا: یک درایور یا سرویس معیوب را می‌توان از فرایندهای نامرتبط جدا کرد.
- بازیابی کنترل‌شده: ممکن است سرویس‌های منفرد بدون راه‌اندازی مجدد کل سیستم، مجدداً راه‌اندازی شوند.
- کاهش کد دارای سطح دسترسی ممتاز: مؤلفه‌های کمتری نیاز دارند با بالاترین سطح دسترسی‌های سیستم اجرا شوند.
- ایزوله‌سازی حافظه: فضاهای آدرس محافظت‌شده به جلوگیری از تداخل مستقیم یک برنامه با برنامه‌ای دیگر کمک می‌کنند.
- پشتیبانی از سطح بحرانی ترکیبی: وظایف کنترل بلادرنگ می‌توانند در کنار HMI، شبکه، تحلیل داده و بارهای کاری هوش مصنوعی اجرا شوند.
- نگهداری چرخه عمر: سرویس‌های ماژولار می‌توانند نگهداری و به‌روزرسانی در سطح مؤلفه را ساده‌تر کنند.
ریزکرنل نقص‌های نرم‌افزاری یا آسیب‌پذیری‌های امنیت سایبری را از بین نمی‌برد. ارزش آن در ایجاد مرزهای معماری نهفته است؛ مرزهایی که می‌توانند پیامدهای خرابی‌ها یا به‌خطر افتادن‌های منفرد را محدود کنند.
قطعیت بلادرنگ همچنان یک الزام بنیادی است
مدرن‌سازی صنعتی نباید اجازه دهد الزامات هوش مصنوعی و محاسبات با کارایی بالا، الزامات کنترل قطعی را تحت‌الشعاع قرار دهند.
در کاربردهای کنترلی، پرسش صرفاً این نیست که چه میزان توان پردازشی در دسترس است. سیستم همچنین باید برای عملکردهایی با الزامات زمانی مشخص، زمان‌بندی قابل‌پیش‌بینی و ویژگی‌های پاسخ محدود و معین ارائه دهد.
این موضوع به‌ویژه زمانی اهمیت دارد که بارهای کاری هوش مصنوعی یا تحلیل داده، منابع محاسباتی قابل‌توجهی مصرف می‌کنند.
از دیدگاه من، بنابراین معماری عملی نه «جایگزینی کنترل با هوش مصنوعی»، بلکه عملکرد کنترل قطعی در کنار هوشمندی سطح بالاتر، تحت مرزهای کنترل‌شده منابع است.
امنیت سایبری باید در سراسر چرخه عمر محصول گسترش یابد
ایزوله‌سازی فنی تنها یکی از بخش‌های تاب‌آوری سایبری است.
تولیدکنندگان صنعتی همچنین به فرایندهایی برای شناسایی مؤلفه‌های نرم‌افزاری، پایش آسیب‌پذیری‌ها، اعتبارسنجی به‌روزرسانی‌ها، کنترل ارائه نرم‌افزار و نگهداری محصولات در سراسر عمر عملیاتی آن‌ها نیاز دارند.
مجموعه استانداردهای ISA/IEC 62443 چارچوبی مبتنی بر چرخه عمر ارائه می‌دهد که به‌طور خاص برای سیستم‌های اتوماسیون و کنترل صنعتی مرتبط است. استانداردهای دیگری، از جمله ISO/SAE 21434، نشان می‌دهند که چگونه مدیریت ساختاریافته ریسک امنیت سایبری می‌تواند از مرحله توسعه تا بهره‌برداری، نگهداری و از رده خارج کردن ادامه یابد.
قانون تاب‌آوری سایبری اروپا نیز اهمیت مدیریت امنیت سایبری در چرخه عمر محصولاتی را که در دامنه آن قرار می‌گیرند افزایش می‌دهد.
برای تولیدکنندگان تجهیزات صنعتی، این بدان معناست که امنیت سایبری را نمی‌توان به‌طور منطقی صرفاً فعالیتی برای صدور گواهی در مرحله نهایی دانست. ترکیب نرم‌افزار، پاسخ‌گویی به آسیب‌پذیری‌ها، سازوکارهای به‌روزرسانی، مدیریت تأمین‌کنندگان و نگهداری محصول باید در طول توسعه سیستم مورد توجه قرار گیرند.
معماری امنیتی باید از بازیابی، نه فقط پیشگیری، پشتیبانی کند
بحث‌های سنتی امنیت سایبری اغلب بر جلوگیری از دسترسی غیرمجاز تمرکز دارند. تاب‌آوری صنعتی به دیدگاهی گسترده‌تر نیاز دارد.
ممکن است با وجود کنترل‌های پیشگیرانه، یک مؤلفه آسیب‌دیده یا معیوب همچنان رخ دهد. بنابراین معماری باید توانایی مؤلفه برای اثرگذاری بر کارکردهای حیاتی را محدود کند و مسیر مشخصی برای بازیابی فراهم آورد.
این امر سه هدف مهندسی مکمل ایجاد می‌کند:
- پیشگیری از رفتار غیرمجاز یا ناخواسته.
- مهار خرابی‌ها و مؤلفه‌های به‌خطر‌افتاده.
- بازیابی خدمات آسیب‌دیده، در حالی که عملیات آسیب‌ندیده ادامه دارند.
برای اتوماسیون صنعتی، این ترکیب از اتکا به پیشگیری به‌تنهایی عملی‌تر است.
QNX به‌عنوان یک پلتفرم بنیادی بلادرنگ
QNX معماری یک سیستم‌عامل مبتنی بر ریزهسته و بلادرنگ سخت را ارائه می‌دهد که برای سیستم‌هایی طراحی شده است که در آن‌ها اجرای قابل پیش‌بینی، ایزوله‌سازی فرایندها و دسترسی کنترل‌شده به منابع اهمیت دارد.
در یک معماری اتوماسیون صنعتی، QNX می‌تواند محیط اجرای بنیادی را برای برنامه‌های کاربردی، درایورها، پشته‌های پروتکل و سیستم‌های فایلِ فعال در فضاهای آدرس محافظت‌شده فراهم کند. زمان‌بندی مبتنی بر اولویت می‌تواند از بارهای کاری با نیازمندی‌های زمانی متفاوت پشتیبانی کند.
این معماری می‌تواند مکمل کنترل مبتنی بر PLC باشد، نه جایگزین آن.
یک سیستم عملی می‌تواند PLCها را برای کنترل تثبیت‌شده در سطح میدان حفظ کند و هم‌زمان از پلتفرم‌های محاسباتی مبتنی بر MPU یا SoC، مجهز به سیستم‌عامل بلادرنگ، برای HMI، بینایی ماشین، اتصال، تحلیل داده، کارکردهای نظارتی و بارهای کاری مرتبط با هوش مصنوعی استفاده کند.
یک معماری عملی برای نوسازی صنعتی
بنابراین می‌توان یک سیستم صنعتی مدرن را متشکل از چندین لایه همکار در نظر گرفت:
- لایه میدانی: حسگرها، عملگرها، درایوها و دیگر تجهیزات فیزیکی.
- لایه کنترل: PLCها و کنترلرهایی که اتوماسیون قطعی را اجرا می‌کنند.
- لایه محاسباتی: پلتفرم‌های MPU/SoC که ظرفیت پردازشی بیشتری فراهم می‌کنند.
- لایه هوشمندی: بینایی ماشین، تحلیل داده، استنتاج هوش مصنوعی و دیگر بارهای کاری محاسباتی.
- لایه نظارتی: رابط انسان و ماشین (HMI)، تشخیص عیب، مدیریت رویدادها و برنامه‌های کاربردی عملیاتی.
- لایه اتصال: شبکه‌های صنعتی و خدمات ارتباطی خارجی.
- لایه نرم‌افزار بنیادی: سیستم‌عامل بلادرنگ، ایزوله‌سازی، زمان‌بندی، مدیریت منابع و سازوکارهای بازیابی.
نیازمندی کلیدی مهندسی، تعریف مرزهای میان این لایه‌هاست، نه برخورد با کل محیط محاسباتی به‌عنوان یک فضای کاربردی یکپارچه و تفکیک‌نشده.
نوسازی باید از سرمایه‌گذاری‌های موجود در حوزه کنترل محافظت کند
تجهیزات صنعتی اغلب سال‌های زیادی عملیاتی باقی می‌مانند. جایگزین کردن کنترل مبتنی بر PLC تثبیت‌شده صرفاً به این دلیل که قابلیت‌های محاسباتی جدید در دسترس هستند، همیشه از نظر فنی یا اقتصادی توجیه‌پذیر نیست.
راهبرد عملی‌تر برای نوسازی این است که عملکردهای کنترلی آزموده‌شده حفظ شوند و منابع محاسباتی پیرامون آن‌ها افزوده شود.
پلتفرم‌های مبتنی بر MPU و SoC می‌توانند ظرفیت پردازشی موردنیاز برای HMI مدرن، هوش مصنوعی، تحلیل داده، بصری‌سازی و اتصال‌پذیری را فراهم کنند، در حالی که PLCهای موجود همچنان کنترل قطعی را انجام می‌دهند.
این رویکرد به تولیدکنندگان امکان می‌دهد قابلیت‌های جدید را بدون ایجاد اختلال غیرضروری در معماری‌های کنترلی تثبیت‌شده معرفی کنند.
دیدگاه مهندسی من: تاب‌آوری از معماری آغاز می‌شود
مهم‌ترین درس این گذار آن است که تاب‌آوری را نمی‌توان پس از یکپارچه‌سازی سامانه به آن افزود.
وقتی کنترل، شبکه، HMI، تحلیل داده و هوش مصنوعی منابع محاسباتی را به‌اشتراک می‌گذارند، سازوکارهای جداسازی و بازیابی باید بخشی از معماری اولیه باشند.
یک پردازنده قدرتمند به‌تنهایی سامانه اتوماسیونی تاب‌آور ایجاد نمی‌کند. همچنین، یک مدل هوش مصنوعی زمانی سامانه اتوماسیون را هوشمند نمی‌کند که پلتفرم پیرامونی نتواند داده‌ها را دریافت کند، مدل را اجرا کند، خروجی آن را اعتبارسنجی کند، سیاست‌های ازپیش‌تعریف‌شده را اعمال کند و در محدوده‌های عملیاتی موردنیاز پاسخ دهد.
بنابراین نسل بعدی اتوماسیون صنعتی نه‌تنها به توان محاسباتی بیشتر، بلکه به نحوه کنترل مؤثر تعامل میان بارهای کاری توسط معماری نرم‌افزار وابسته خواهد بود.
نتیجه‌گیری
اتوماسیون صنعتی در حال ورود به معماری‌ای است که در آن PLCها، پردازنده‌های پرقدرت، هوش مصنوعی، اتصال‌پذیری و قابلیت‌های تعریف‌شده با نرم‌افزار، بیش از پیش در کنار یکدیگر کار می‌کنند.
این امر فرصت‌های قابل‌توجهی برای نوسازی ایجاد می‌کند، اما هم‌زمان وابستگی‌ها و حالت‌های خرابی جدیدی نیز به همراه دارد.
یک معماری تاب‌آور باید اجرای قطعی، جداسازی فرایندها، حفاظت از حافظه، دسترسی کنترل‌شده به منابع، مهار خطا، مدیریت چرخه عمر امنیت سایبری و سازوکارهای مشخص بازیابی را با یکدیگر ترکیب کند.
سیستم‌عامل‌های بلادرنگ مبتنی بر ریزهسته، مانند QNX، یکی از رویکردهای معماری برای برآوردن این الزامات هستند. چنین پلتفرم‌هایی در کنار فناوری‌های موجود PLC و کنترلر، می‌توانند بنیان نرم‌افزاری لازم برای یکپارچه‌سازی بارهای کاری محاسباتی مدرن را فراهم کنند و در عین حال مرزهای مشخصی پیرامون عملکردهای حیاتی اتوماسیون حفظ کنند.
