آیا تابلوهای کنترل می‌توانند خودترمیم شوند؟ مهندسی سیستم‌های مقاوم‌تر در برابر خطا
تابلوهای کنترل خودترمیم‌شونده نمی‌توانند سخت‌افزارهای خراب را به‌صورت فیزیکی تعمیر کنند، اما عیب‌یابی مدرن، طراحی ماژولار، افزونگی و هوشمندی لبه می‌توانند بسیاری از خطاها را به‌طور خودکار شناسایی، ...
وقتی یک تابلوی کنترل صنعتی، پیش از آنکه اپراتور متوجه مشکلی قابل مشاهده شود، یک خطای در حال شکل‌گیری را تشخیص می‌دهد، چه اتفاقی می‌افتد؟
ممکن است درایو موتور شروع به کشیدن جریان نامنظم کند. یک ماژول توان ممکن است با دمایی بالاتر از حد معمول شروع به کار کند. خطاهای ارتباطی ممکن است به‌طور متناوب میان دستگاه‌های کنترل ظاهر شوند.
در یک سیستم متعارف، این وضعیت‌ها اغلب تنها پس از وقوع هشدار، تریپ یا خاموشی به مشکل تعمیراتی تبدیل می‌شوند.
معماری‌های کنترلی هوشمندتر می‌توانند زودتر واکنش نشان دهند.
آن‌ها می‌توانند وضعیت‌های غیرعادی را تشخیص دهند، خطاهای منتخب را ایزوله کنند، عملکردها را به تجهیزات افزونه منتقل کنند و اطلاعات تشخیصی دقیق در اختیار کارکنان تعمیرات قرار دهند.
این مفهوم گاهی «تابلوی کنترل خودترمیم‌شونده» نامیده می‌شود.
این اصطلاح نباید به‌صورت تحت‌اللفظی تفسیر شود. یک تابلوی کنترل نمی‌تواند به‌تنهایی کنتاکتور آسیب‌دیده، ترمینال سوخته یا درایو خراب را تعمیر کند.
کاری که می‌تواند انجام دهد، شناسایی برخی خرابی‌ها و استفاده از راهبردهای بازیابی ازپیش‌تعریف‌شده برای محدود کردن اثر آن‌ها بر تولید است.
شکل ۱. تابلوهای کنترل صنعتی ماژولار، زیربنای تشخیص، ایزوله‌سازی و تعویض ساختاریافته قطعات را فراهم می‌کنند.
نقطه ضعف اغلب خود ماشین نیست
تابلوهای کنترل بخش بزرگی از تجهیزات صنعتی مدرن را هماهنگ می‌کنند.
PLCها، منابع تغذیه، رله‌ها، درایوها، ماژول‌های ارتباطی و دستگاه‌های ورودی/خروجی برای حفظ یک توالی عملیاتی قابل پیش‌بینی با یکدیگر کار می‌کنند.
بنابراین خرابی یک قطعه کوچک می‌تواند فرایندی بسیار بزرگ‌تر را تحت تأثیر قرار دهد.
یک رله آسیب‌دیده ممکن است مانع راه‌اندازی موتور شود. خرابی منبع تغذیه می‌تواند چندین مدار کنترل را هم‌زمان از کار بیندازد. مشکل ارتباطی ممکن است تجهیزاتی را که در غیر این صورت سالم هستند، برای کنترلر غیرقابل‌دسترس کند.
راهبردهای سنتی تعمیرات از طریق بازرسی، قطعات یدکی، تعویض پیشگیرانه و مداخله اپراتور با این خطرات مقابله می‌کنند.
این اقدامات همچنان ضروری هستند.
محدودیت، زمان واکنش است.
وقتی تشخیص خطا عمدتاً به توقف دستگاه یا مشاهده هشدار توسط اپراتور وابسته باشد، فرایند از پیش وارد وضعیت عملیاتی غیرعادی شده است.
طراحی مدرن سیستم‌های کنترل، بیش‌ازپیش تلاش می‌کند پیش از رسیدن به آن مرحله، خرابی را تشخیص دهد.
خودترمیمی واقعاً به چه معناست
از نظر مهندسی، خودترمیمی را بهتر است ترکیبی از تشخیص خطا، ایزوله‌سازی خطا و بازیابی خودکار در نظر گرفت.
یک معماری عملی ممکن است چندین عملکرد را انجام دهد.
اول، سیستم یک سیگنال یا وضعیت عملیاتی غیرعادی را تشخیص می‌دهد.
دوم، منطق تشخیصی تعیین می‌کند کدام دستگاه، مدار یا ناحیه فرایند تحت تأثیر قرار گرفته است.
سوم، سیستم کنترل، در صورت امکان معماری، عملکرد آسیب‌دیده را ایزوله می‌کند.
در نهایت، سخت‌افزار افزونه یا یک مسیر کنترلی جایگزین ممکن است بخشی از فرایند را تا زمان مداخله تیم تعمیرات حفظ کند.
اپراتور همچنان هشدارها، گزارش‌ها و اطلاعات تشخیصی را دریافت می‌کند.
هدف، حذف خرابی‌ها نیست؛ بلکه جلوگیری از آن است که هر خرابی منفرد به‌طور خودکار به توقفی در سراسر کارخانه تبدیل شود.
معماری ماژولار، ایزوله‌سازی خطا را عملی می‌کند
رفتار تحمل‌پذیر در برابر خطا با طراحی فیزیکی آغاز می‌شود.
ایزوله کردن یک تابلو که به‌صورت یک مجموعه الکتریکی یکپارچه و به‌شدت به‌هم‌پیوسته ساخته شده است، هنگام خرابی یک قطعه دشوار است.
یک معماری ماژولار مرزهای عملکردی روشن‌تری ایجاد می‌کند.
توزیع توان، کنترل، ارتباطات، درایوها و I/O را می‌توان به بخش‌های قابل‌شناسایی با حفاظت مناسب و دسترسی تشخیصی تقسیم کرد.
این امر چندین مزیت عملیاتی به همراه دارد.
اغلب می‌توان یک خطا را به ناحیه عملکردی کوچک‌تری نسبت داد. کارکنان تعمیر و نگهداری می‌توانند سخت‌افزار آسیب‌دیده را سریع‌تر شناسایی کنند و تعویض ساختارمندتر می‌شود.
ماژولار بودن همچنین از راهبردهای استاندارد قطعات یدکی پشتیبانی می‌کند.
به‌جای عیب‌یابی تک‌تک اجزا تا سطح برد، تکنسین‌ها می‌توانند ماژول‌های مشخص را تعویض کنند و طبق یک رویه نگهداری تثبیت‌شده، سرویس را بازیابی کنند.
سخت‌افزار قابل‌تعویض در حالت روشن می‌تواند در مواردی که پلتفرم کنترلی و کاربرد مربوطه از تعویض هنگام برق‌دار بودن پشتیبانی می‌کنند، این رویکرد را بهبود دهد.
بااین‌حال، صرفاً به دلیل ماژولار بودن یک سیستم، هرگز نباید قابلیت تعویض در حالت روشن را مفروض دانست.
کنترلر، پلتفرم I/O، طراحی الکتریکی و رویه ایمنی باید به‌صراحت از آن پشتیبانی کنند.
برای سیستم‌هایی که بر سخت‌افزار کنترلی قابل‌تعویض بنا شده‌اند، ماژول‌های I/O با دسته‌بندی روشن نیز می‌توانند نگهداری چرخه عمر و برنامه‌ریزی قطعات یدکی را ساده‌تر کنند.
پایش پیش‌بینانه تغییرات را پیش از خرابی جست‌وجو می‌کند
یک راهبرد کنترلی خودمدیریت‌شونده به اطلاعاتی درباره وضعیت تجهیزات نیاز دارد.
در اینجاست که حسگری IIoT و نگهداری و تعمیرات پیش‌بینانه اهمیت پیدا می‌کنند.
سیستم‌های پایش مدرن می‌توانند بار الکتریکی، دما، ارتعاش، کیفیت ارتباطات و دیگر متغیرهای عملیاتی را مشاهده کنند.
یک اندازه‌گیری منفرد ممکن است نشان‌دهنده مشکل نباشد.
روند اغلب مفیدتر است.
افزایش تدریجی دمای یک اتصال ترمینال می‌تواند نشان‌دهنده یک وضعیت الکتریکی باشد که به بازرسی نیاز دارد.
موتوری که روند افزایشی ارتعاش در آن مشاهده می‌شود، ممکن است پیش از آنکه این وضعیت به توقف برنامه‌ریزی‌نشده منجر شود، به بررسی مکانیکی نیاز داشته باشد.
عدم‌تعادل تکرارشونده جریان نیز، در صورتی که در زمینه صحیح الکتریکی و مکانیکی ارزیابی شود، می‌تواند شواهد تشخیصی مفیدی ارائه دهد.
رایانش لبه‌ای امکان می‌دهد بخشی از این تحلیل در نزدیکی ماشین انجام شود.
به‌جای ارسال هر اندازه‌گیری خام به یک سرور راه دور، یک دستگاه لبه می‌تواند سیگنال‌های انتخاب‌شده را به‌صورت محلی ارزیابی کند و هنگام شناسایی شرایط تعریف‌شده، رویدادهایی ایجاد کند.
این کار می‌تواند تأخیر در پاسخ را کاهش دهد و ترافیک غیرضروری داده را محدود کند.
تشخیص باید چیزی فراتر از «خطا» را توضیح دهد
یک نشانگر خطای کلی، زمانی که تولید از قبل متوقف شده است، ارزش محدودی دارد.
تشخیص مؤثر باید مشخص کند مشکل در کجا رخ داده است و زمینه کافی را برای بررسی آن توسط کارکنان تعمیر و نگهداری فراهم کند.
کنترلرهای مدرن و دستگاه‌های هوشمند می‌توانند اطلاعات عیب‌یابی در سطح مؤلفه را از طریق شبکه کنترل در دسترس قرار دهند.
سپس لایه HMI یا SCADA می‌تواند اطلاعات هشدار دقیق‌تری ارائه دهد.
سیستم به‌جای گزارش صرفاً یک خطای عمومی درایو، ممکن است مشخص کند کدام درایو هشدار را ایجاد کرده و مقادیر عملیاتی مرتبط را ثبت کند.
رویدادهای تاریخی نیز به مهندسان کمک می‌کنند تعیین کنند بلافاصله پیش از تریپ چه اتفاقی افتاده است.
این موضوع به‌ویژه زمانی اهمیت پیدا می‌کند که یک خطای اولیه چندین هشدار ثانویه ایجاد کند.
نخستین هشداری که روی صفحه نمایش دیده می‌شود ممکن است علت اصلی نباشد.
توالی رویدادهایی که به‌درستی زمان‌گذاری شده‌اند، به مهندسان کمک می‌کنند آنچه را رخ داده است بازسازی کنند.
ایزوله‌سازی خطا از گسترش یک مشکل جلوگیری می‌کند
تشخیص به‌تنهایی تحمل خطا ایجاد نمی‌کند.
معماری باید همچنین مشخص کند پس از شناسایی خرابی چه اتفاقی می‌افتد.
در برخی کاربردها، می‌توان ماژول تحت‌تأثیر را به‌صورت منطقی از توالی عملیاتی حذف کرد.
در برخی موارد دیگر، فرایند ممکن است به تجهیزات افزونه منتقل شود.
منابع تغذیه، مسیرهای شبکه، کنترلرها، واسط‌های ارتباطی و تجهیزات فرایندی همگی می‌توانند در صورت توجیه پیچیدگی اضافی توسط کاربرد، از افزونگی استفاده کنند.
افزونگی به‌طور خودکار سودمند نیست.
یک سیستم افزونه با طراحی ضعیف می‌تواند حالت‌های خرابی بیشتری ایجاد کند و عیب‌یابی را دشوارتر سازد.
بنابراین راهبرد بازیابی باید همراه با راهبرد تشخیص خطا مهندسی شود.
شکل ۲. یک توالی مقاوم در برابر خطا، وضعیت غیرعادی را تشخیص می‌دهد، عملکرد تحت‌تأثیر را ایزوله می‌کند و هرجا افزونگی موجود باشد، عملیات را منتقل می‌کند.
ازکارافتادگی یک درایو نشان می‌دهد این مفهوم چگونه کار می‌کند
یک خط بطری‌گذاری را در نظر بگیرید که برای تنظیم سرعت نوار نقاله از درایوهای فرکانس متغیر استفاده می‌کند.
یکی از درایوها شروع به نشان دادن رفتار نامنظم جریان و افزایش دما می‌کند.
در یک معماری متعارف، درایو ممکن است تا زمانی که عملکردهای حفاظتی آن تریپ ایجاد کنند، به کار خود ادامه دهد.
نوار نقاله متوقف می‌شود.
سپس واحد تعمیر و نگهداری عیب‌یابی بخش ازکارافتاده را آغاز می‌کند، در حالی که تولید همچنان متوقف است.
یک معماری مقاوم‌تر در برابر خطا می‌توانست واکنش متفاوتی نشان دهد.
پایش وضعیت ابتدا الگوی غیرعادی الکتریکی و حرارتی را تشخیص می‌دهد.
سیستم کنترل پیش از آنکه فرایند به وضعیت تریپ برسد، هشدار تعمیر و نگهداری صادر می‌کند.
اگر کاربرد شامل یک درایو آماده‌به‌کار مهندسی‌شده یا مسیر مکانیکی افزونه باشد، آن‌گاه می‌توان عملکرد تحت‌تأثیر را طبق منطق ازپیش‌تعریف‌شده منتقل کرد.
درایو اصلی ایزوله می‌شود و واحد تعمیر و نگهداری اطلاعات دقیق خطا را دریافت می‌کند.
بسته به طراحی فرایند، تولید ممکن است با ظرفیت کامل یا کاهش‌یافته ادامه یابد.
این مثال یک محدودیت مهم را نشان می‌دهد.
سیستم کنترل نمی‌تواند افزونگی‌ای ایجاد کند که از ابتدا در طراحی ماشین پیش‌بینی نشده باشد.
بازیابی خودکار تنها زمانی امکان‌پذیر است که معماری الکتریکی، مکانیکی و نرم‌افزاری یک مسیر جایگزین فراهم کند.
هرجا کنترل سرعت متغیر مطرح باشد، معماری‌های VFD و درایوهای AC مناسب می‌توانند بخشی از یک راهبرد گسترده‌تر نگهداری و افزونگی باشند.
ارتباطات بخشی از معماری بازیابی است
تشخیص‌های مدرن تا حد زیادی به شبکه‌های ارتباطی صنعتی وابسته‌اند.
کنترلرها به اطلاعات وضعیت درایوها، I/Oهای راه دور، تجهیزات حفاظتی و دیگر اجزای هوشمند نیاز دارند.
EtherNet/IP، PROFINET و دیگر پروتکل‌های صنعتی، در صورت پشتیبانی تجهیزات، می‌توانند این قابلیت مشاهده تشخیصی را فراهم کنند.
بااین‌حال، استفاده از یک پروتکل اترنت صنعتی به‌طور خودکار شبکه را تحمل‌پذیر در برابر خطا نمی‌کند.
تاب‌آوری به معماری شبکه وابسته است.
سوئیچ‌های مدیریتی، مسیرهای افزونه، قابلیت‌های کنترلر، توپولوژی و سازوکارهای بازیابی همگی بر آنچه پس از خرابی ارتباطی رخ می‌دهد تأثیر می‌گذارند.
بنابراین، مهندسان باید این دو پرسش را از یکدیگر جدا کنند.
آیا دستگاه می‌تواند خطا را گزارش کند؟
آیا شبکه می‌تواند پس از وقوع خطا به کار خود ادامه دهد؟
این‌ها قابلیت‌هایی مرتبط اما از نظر فنی متفاوت هستند.
ایمنی و بازیابی خودکار به مرزهای مشخص نیاز دارند
بازیابی خودکار هرگز نباید عملکرد ایمنی یک ماشین یا فرایند را نادیده بگیرد.
برخی خرابی‌ها باید به خاموشی کنترل‌شده منجر شوند، نه ادامه خودکار کار.
توقف اضطراری، اینترلاک ایمنی یا وضعیت خطرناک الکتریکی را نمی‌توان صرفاً به این دلیل که حفظ تولید مطلوب است، دور زد.
منطق بازیابی باید میان خطاهایی که امکان ادامه کار را می‌دهند و خطاهایی که تجهیزات را ملزم به ورود به وضعیت ایمن می‌کنند، تمایز قائل شود.
این موضوع به‌ویژه هنگام استفاده از مسیرهای کنترل افزونه اهمیت دارد.
مهندسان باید بدانند کدام سیگنال‌ها به اتوماسیون استاندارد و کدام‌یک به معماری مرتبط با ایمنی تعلق دارند.
بنابراین، مفهوم خودترمیمی زمانی بهترین عملکرد را دارد که مهار خطا بر اساس نواحی عملکردی و ایمنی تعریف‌شده طراحی شود.
دوقلوهای دیجیتال یک لایه آزمایشی اضافه می‌کنند
دوقلوهای دیجیتال می‌توانند طراحی تحمل‌پذیر در برابر خطا را فراتر از تابلوی فیزیکی گسترش دهند.
نمایش مجازی سیستم کنترل به مهندسان اجازه می‌دهد توالی‌های عملیاتی را پیش از اجرای تغییرات روی تجهیزات عملیاتی مطالعه کنند.
شرایط خطا را می‌توان وارد مدل کرد تا نحوه واکنش منطق کنترل بررسی شود.
مهندسان می‌توانند ارزیابی کنند که آیا آلارم‌های درست نمایش داده می‌شوند، آیا افزونگی به‌درستی منتقل می‌شود و آیا تعاملات ناخواسته‌ای میان فرایندها رخ می‌دهد یا نه.
این موضوع به‌ویژه زمانی مفید است که منطق بازیابی پیچیده شود.
آزمایش هر خرابی احتمالی روی تجهیزات تولیدی در حال کار ممکن است غیرعملی یا ناایمن باشد.
محیط شبیه‌سازی راه دیگری برای اعتبارسنجی عملکرد پیش از استقرار فراهم می‌کند.
شکل ۳. شبیه‌سازی دیجیتال می‌تواند به مهندسان کمک کند توالی‌های خطا و منطق بازیابی را پیش از اعمال تغییرات روی تجهیزات عملیاتی ارزیابی کنند.
هوشمندی لبه‌ای در حال گسترش تصمیم‌گیری محلی است
پیشرفت دیگر، افزایش میزان پردازشی است که مستقیماً در خود ماشین در دسترس قرار دارد.
معماری‌های کنترلی سنتی اغلب وظایف تحلیلی سطح بالاتر را به سرورهای متمرکز ارسال می‌کنند.
سکوهای لبه‌ای امکان می‌دهند برخی تشخیص‌ها به‌صورت محلی باقی بمانند.
این قابلیت برای کاربردهایی مفید است که در آن‌ها تصمیم‌گیری درباره خطا باید به‌سرعت انجام شود یا نمی‌توان اتصال پیوسته به ابر را فرض کرد.
تحلیل‌های محلی می‌توانند الگوهای غیرعادی را شناسایی کنند و فقط رویدادهای مرتبط را به سیستم‌های نظارتی یا سازمانی ارسال کنند.
PLC همچنان کنترل قطعی و قابل پیش‌بینی را انجام می‌دهد.
لایه تحلیلی اطلاعات اضافی ارائه می‌دهد که می‌تواند بر تصمیم‌های تعمیر و نگهداری یا منطق بازیابی ازپیش‌تعریف‌شده اثر بگذارد.
جدا نگه داشتن شفاف این عملکردها اهمیت دارد.
کنترل ماشین نباید به یک مدل تحلیلی مبهم وابسته شود که رفتار آن قابل اعتبارسنجی نیست.
پرسش‌هایی که مهندسان باید هنگام طراحی تابلو مطرح کنند
یک تابلو مقاوم در برابر خطا، با پرسش‌های طراحی آغاز می‌شود، نه با یک قابلیت نرم‌افزاری.
مهندسان باید تعیین کنند که آیا نواحی مجزای خطا در معماری الکتریکی به‌وضوح تعریف شده‌اند یا نه.
آن‌ها باید مشخص کنند کدام خرابی‌ها را می‌توان بدون خاموش کردن کل ماشین ایزوله کرد.
دستگاه‌ها باید بازخورد تشخیصی کافی برای راهبرد تعمیر و نگهداری ارائه دهند.
عملکردهای حیاتی باید بررسی شوند تا مشخص شود آیا افزونگی از نظر فنی و اقتصادی توجیه دارد یا نه.
تیم طراحی همچنین باید تصمیم بگیرد کدام متغیرهای وضعیت، فراتر از صرفاً ساعات کارکرد، به پایش پیوسته نیاز دارند.
تشخیص عیب از راه دور می‌تواند مفید باشد، اما امنیت شبکه و اختیار عملیاتی باید از همان ابتدا در نظر گرفته شوند.
منطق بازیابی نیز باید در برابر سناریوهای واقع‌گرایانه خرابی آزمایش شود، نه فقط توالی‌های عادی کارکرد.
هدف، کاهش کنترل‌شده عملکرد است، نه تابلویی که هرگز خراب نمی‌شود
تجهیزات صنعتی همچنان خراب خواهند شد.
قطعات فرسوده می‌شوند. اتصالات افت می‌کنند. شبکه‌ها ارتباط خود را از دست می‌دهند. درایوها تریپ می‌کنند. منابع تغذیه به پایان عمر کاری خود می‌رسند.
بنابراین هدف مهندسی، ساختن تابلوی کنترلی غیرممکنی نیست که هرگز خراب نشود.
هدف بهتر، کاهش تدریجی و کنترل‌شده عملکرد است.
سیستم باید در صورت امکان، فرسودگی را زود تشخیص دهد.
هنگام وقوع خرابی، اثر آن باید هر زمان که معماری سیستم اجازه می‌دهد، محدود بماند.
اپراتورها باید به‌جای هشدارهای عمومی، اطلاعات تشخیصی مفیدی دریافت کنند.
فرایندهای حیاتی باید در صورت لزوم به عملکردهای پشتیبان مهندسی‌شده منتقل شوند.
پرسنل تعمیر و نگهداری باید سپس اطلاعات کافی برای تعمیر سخت‌افزار آسیب‌دیده، بدون بررسی‌های غیرضروری، در اختیار داشته باشند.
این معنای عملی یک تابلو کنترل خودترمیم‌شونده است.
خودش را تعمیر نمی‌کند.
این سامانه طوری طراحی شده است که درباره وضعیت خود اطلاعات بیشتری به دست آورد، به خرابی‌های قابل پیش‌بینی هوشمندانه واکنش نشان دهد و تا زمان انجام تعمیر فیزیکی توسط افراد، بیشترین میزان ممکن از عملکرد ایمن را حفظ کند.