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

ممکن است یک درایو موتور شروع به کشیدن جریان نامنظم کند. یک ماژول توان ممکن است شروع به کارکردن با دمایی بالاتر از حد معمول کند. خطاهای ارتباطی ممکن است به‌طور متناوب میان دستگاه‌های کنترل ظاهر شوند.

در یک سیستم متعارف، این وضعیت‌ها اغلب تنها پس از وقوع هشدار، تریپ یا خاموشی به مشکلات تعمیر و نگهداری تبدیل می‌شوند.

معماری‌های کنترلی هوشمندتر می‌توانند زودتر واکنش نشان دهند.

آن‌ها می‌توانند وضعیت‌های غیرعادی را شناسایی کنند، خطاهای منتخب را ایزوله کنند، عملکردها را به تجهیزات افزونه منتقل کنند و اطلاعات عیب‌یابی دقیق را در اختیار کارکنان تعمیر و نگهداری قرار دهند.

این مفهوم گاهی به‌صورت تابلوی کنترل خودترمیم‌شونده توصیف می‌شود.

این اصطلاح نباید به‌صورت تحت‌اللفظی تفسیر شود. یک تابلوی کنترل نمی‌تواند کنتاکتور آسیب‌دیده، ترمینال سوخته یا درایو خراب را به‌تنهایی تعمیر کند.

کاری که می‌تواند انجام دهد، شناسایی برخی خرابی‌ها و استفاده از راهبردهای ازپیش‌تعریف‌شده بازیابی برای محدود کردن اثر آن‌ها بر تولید است.

شکل ۱. تابلوهای کنترل صنعتی ماژولار، پایه‌ای برای عیب‌یابی، ایزوله‌سازی و تعویض ساختاریافته قطعات فراهم می‌کنند.

نقطه‌ضعف اغلب خودِ ماشین نیست

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

PLCها، منابع تغذیه، رله‌ها، درایوها، ماژول‌های ارتباطی و دستگاه‌های ورودی/خروجی با یکدیگر کار می‌کنند تا توالی عملیاتی قابل‌پیش‌بینی حفظ شود.

بنابراین خرابی یک قطعه کوچک می‌تواند بر فرایندی بسیار بزرگ‌تر تأثیر بگذارد.

یک رله آسیب‌دیده ممکن است مانع راه‌اندازی موتور شود. خرابی منبع تغذیه می‌تواند چندین مدار کنترلی را به‌طور هم‌زمان از کار بیندازد. مشکل ارتباطی ممکن است تجهیزات سالم را برای کنترلر غیرقابل‌دسترس کند.

راهبردهای سنتی نگهداری و تعمیرات بازرسی، قطعات یدکی، تعویض پیشگیرانه و مداخله اپراتور را برای مقابله با این خطرات به کار می‌گیرند.

این اقدامات همچنان ضروری هستند.

محدودیت، زمان واکنش است.

وقتی تشخیص خطا عمدتاً به توقف دستگاه یا مشاهده هشدار توسط اپراتور وابسته باشد، فرایند پیشاپیش وارد وضعیت عملیاتی غیرعادی شده است.

طراحی مدرن سیستم‌های کنترل، بیش‌ازپیش می‌کوشد پیش از رسیدن به آن مرحله، افت عملکرد را شناسایی کند.

خودترمیمی واقعاً به چه معناست

از دیدگاه مهندسی، خودترمیمی بهتر است ترکیبی از تشخیص خطا، ایزوله‌سازی خطا و بازیابی خودکار درک شود.

یک معماری عملی می‌تواند چندین عملکرد را انجام دهد.

اول، سیستم یک سیگنال غیرعادی یا وضعیت عملیاتی غیرعادی را شناسایی می‌کند.

دوم، منطق عیب‌یابی تعیین می‌کند کدام دستگاه، مدار یا ناحیه فرایند تحت‌تأثیر قرار گرفته است.

سوم، سیستم کنترل، در صورت امکان معماری، عملکرد تحت‌تأثیر را ایزوله می‌کند.

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

اپراتور همچنان هشدارها، گزارش‌ها و اطلاعات عیب‌یابی را دریافت می‌کند.

هدف، حذف خرابی‌ها نیست؛ بلکه جلوگیری از آن است که هر خرابی منفرد به‌طور خودکار به توقفی در سراسر کارخانه تبدیل شود.

معماری ماژولار، جداسازی خطا را عملی می‌کند

رفتار تحمل‌پذیر در برابر خطا با طراحی فیزیکی آغاز می‌شود.

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

یک معماری ماژولار مرزهای عملکردی روشن‌تری ایجاد می‌کند.

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

این موضوع چندین مزیت عملیاتی دارد.

اغلب می‌توان یک خطا را به ناحیه عملکردی کوچک‌تری نسبت داد. کارکنان تعمیر و نگهداری می‌توانند سخت‌افزار آسیب‌دیده را سریع‌تر شناسایی کنند و تعویض ساختارمندتر می‌شود.

ماژولار بودن همچنین از راهبردهای استاندارد قطعات یدکی پشتیبانی می‌کند.

به‌جای عیب‌یابی تک‌تک اجزا تا سطح برد، تکنسین‌ها می‌توانند ماژول‌های مشخص را تعویض کنند و طبق یک رویه نگهداری تثبیت‌شده، سرویس را بازیابی کنند.

سخت‌افزار قابل‌تعویض در حالت روشن می‌تواند این رویکرد را بهبود دهد، مشروط بر اینکه پلتفرم کنترلی و کاربرد مشخص از تعویض در حالت برق‌دار پشتیبانی کنند.

بااین‌حال، صرفاً به این دلیل که یک سامانه ماژولار است، هرگز نباید قابلیت تعویض در حالت روشن را بدیهی فرض کرد.

کنترلر، پلتفرم ورودی/خروجی، طراحی الکتریکی و رویه ایمنی باید صراحتاً از آن پشتیبانی کنند.

برای سامانه‌هایی که بر سخت‌افزار کنترلی قابل‌تعویض ساخته شده‌اند، ماژول‌های ورودی/خروجی با دسته‌بندی روشن نیز می‌توانند نگهداری چرخه عمر و برنامه‌ریزی قطعات یدکی را ساده‌تر کنند.

پایش پیشگویانه پیش از خرابی به دنبال تغییرات است

یک راهبرد کنترلی خودمدیریت‌شونده به اطلاعاتی درباره وضعیت تجهیزات نیاز دارد.

در اینجا حسگری IIoT و نگهداری پیشگویانه اهمیت پیدا می‌کنند.

سامانه‌های پایش مدرن می‌توانند بار الکتریکی، دما، لرزش، کیفیت ارتباط و دیگر متغیرهای عملیاتی را مشاهده کنند.

یک اندازه‌گیری منفرد ممکن است نشان‌دهنده مشکل نباشد.

روند اغلب مفیدتر است.

افزایش تدریجی دمای یک اتصال ترمینال ممکن است نشان‌دهنده وضعیتی الکتریکی باشد که به بازرسی نیاز دارد.

موتوری که روند افزایشی لرزش را نشان می‌دهد، ممکن است پیش از آنکه این وضعیت به خاموشی برنامه‌ریزی‌نشده منجر شود، به بررسی مکانیکی نیاز داشته باشد.

عدم‌تعادل تکرارشونده جریان نیز، اگر در زمینه صحیح الکتریکی و مکانیکی ارزیابی شود، می‌تواند شواهد تشخیصی مفیدی ارائه دهد.

رایانش لبه‌ای امکان می‌دهد بخشی از این تحلیل در نزدیکی ماشین انجام شود.

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

این کار می‌تواند تأخیر در پاسخ‌گویی و ترافیک غیرضروری داده را کاهش دهد.

عیب‌یابی باید بیش از «خطا» را توضیح دهد

یک نشانگر خطای کلی، زمانی که تولید از قبل متوقف شده است، ارزش محدودی دارد.

عیب‌یابی مؤثر باید محل وقوع مشکل را مشخص کند و زمینه کافی برای بررسی آن توسط کارکنان تعمیر و نگهداری فراهم آورد.

کنترلرهای مدرن و دستگاه‌های هوشمند می‌توانند اطلاعات تشخیصی در سطح مؤلفه را از طریق شبکه کنترل ارائه کنند.

سپس لایه HMI یا SCADA می‌تواند اطلاعات دقیق‌تری درباره هشدار ارائه دهد.

سیستم به‌جای گزارش تنها یک خطای عمومی درایو، ممکن است مشخص کند کدام درایو هشدار را ایجاد کرده و مقادیر عملیاتی مرتبط را ثبت کند.

رویدادهای ثبت‌شده در تاریخچه نیز به مهندسان کمک می‌کنند مشخص کنند بلافاصله پیش از تریپ چه رخ داده است.

این موضوع به‌ویژه زمانی اهمیت دارد که یک خطای اولیه چندین هشدار ثانویه ایجاد کند.

اولین هشداری که روی صفحه دیده می‌شود ممکن است علت اصلی نباشد.

توالی رویدادهایی که به‌درستی زمان‌گذاری شده‌اند، به مهندسان کمک می‌کنند آنچه را رخ داده است بازسازی کنند.

ایزولاسیون خطا از گسترش یک مشکل جلوگیری می‌کند

تشخیص به‌تنهایی تحمل خطا ایجاد نمی‌کند.

معماری باید همچنین مشخص کند پس از شناسایی خرابی چه اتفاقی می‌افتد.

در برخی کاربردها، ماژول تحت‌تأثیر را می‌توان به‌صورت منطقی از توالی عملیاتی حذف کرد.

در برخی موارد دیگر، فرایند ممکن است به تجهیزات افزونه منتقل شود.

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

افزونگی به‌طور خودکار سودمند نیست.

یک سیستم افزونه با طراحی ضعیف می‌تواند حالت‌های خرابی بیشتری ایجاد کند و عیب‌یابی را دشوارتر سازد.

بنابراین، راهبرد بازیابی باید هم‌زمان با راهبرد تشخیص خطا مهندسی شود.

شکل ۲. یک توالی مقاوم در برابر خطا، وضعیت غیرعادی را شناسایی می‌کند، عملکرد تحت‌تأثیر را ایزوله می‌کند و هرجا افزونگی وجود داشته باشد، عملیات را منتقل می‌کند.

نشان دادن نحوه عملکرد مفهوم با خرابی درایو

یک خط بطری‌گذاری را در نظر بگیرید که برای تنظیم سرعت نوار نقاله از درایوهای فرکانس متغیر استفاده می‌کند.

یکی از درایوها شروع به نشان دادن رفتار نامنظم جریان و افزایش دما می‌کند.

در یک معماری متداول، درایو ممکن است تا زمانی که عملکردهای حفاظتی آن تریپ ایجاد کنند، به کار خود ادامه دهد.

نوار نقاله متوقف می‌شود.

سپس واحد نگهداری عیب‌یابی بخش ازکارافتاده را آغاز می‌کند، در حالی که تولید همچنان متوقف است.

یک معماری مقاوم‌تر در برابر خطا می‌توانست واکنش متفاوتی نشان دهد.

پایش وضعیت ابتدا الگوی غیرعادی الکتریکی و حرارتی را شناسایی می‌کند.

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

اگر کاربرد شامل یک درایو آماده‌به‌کار مهندسی‌شده یا مسیر مکانیکی redundant باشد، عملکرد تحت‌تأثیر قرارگرفته می‌تواند طبق منطق ازپیش‌تعریف‌شده به آن منتقل شود.

درایو اصلی ایزوله می‌شود و واحد نگهداری اطلاعات دقیق خطا را دریافت می‌کند.

بسته به طراحی فرایند، تولید ممکن است با ظرفیت کامل یا کاهش‌یافته ادامه پیدا کند.

این مثال یک محدودیت مهم را نشان می‌دهد.

سیستم کنترل نمی‌تواند افزونگی‌ای را ایجاد کند که از ابتدا در طراحی ماشین پیش‌بینی نشده است.

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

در مواردی که کنترل سرعت متغیر مطرح است، معماری‌های VFD و درایو AC مناسب می‌توانند بخشی از یک راهبرد گسترده‌تر نگهداری و افزونگی باشند.

ارتباطات بخشی از معماری بازیابی است

تشخیص‌های مدرن تا حد زیادی به شبکه‌های ارتباطی صنعتی وابسته‌اند.

کنترلرها به اطلاعات وضعیت از درایوها، I/Oهای راه‌دور، تجهیزات حفاظتی و دیگر مؤلفه‌های هوشمند نیاز دارند.

EtherNet/IP، PROFINET و دیگر پروتکل‌های صنعتی، در صورت پشتیبانی تجهیزات، می‌توانند این قابلیت مشاهده تشخیصی را فراهم کنند.

بااین‌حال، استفاده از یک پروتکل اترنت صنعتی به‌طور خودکار شبکه را تحمل‌پذیر در برابر خطا نمی‌کند.

تاب‌آوری به معماری شبکه وابسته است.

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

بنابراین، مهندسان باید این دو پرسش را از یکدیگر جدا کنند.

آیا دستگاه می‌تواند خطا را گزارش کند؟

آیا شبکه می‌تواند پس از وقوع خطا به کار خود ادامه دهد؟

این دو قابلیت مرتبط‌اند، اما از نظر فنی متفاوت هستند.

ایمنی و بازیابی خودکار به مرزهای مشخص نیاز دارند

بازیابی خودکار هرگز نباید عملکرد ایمنی یک ماشین یا فرایند را نادیده بگیرد.

برخی خرابی‌ها باید به خاموش‌سازی کنترل‌شده منجر شوند، نه ادامه خودکار کار.

توقف اضطراری، اینترلاک ایمنی یا وضعیت الکتریکی خطرناک را نمی‌توان صرفاً به این دلیل که حفظ تولید مطلوب است، دور زد.

منطق بازیابی باید بین خطاهایی که امکان ادامه کار را می‌دهند و خطاهایی که لازم است تجهیزات به وضعیت ایمن وارد شوند، تمایز قائل شود.

این موضوع زمانی که مسیرهای کنترل افزونه درگیر هستند، اهمیت ویژه‌ای دارد.

مهندسان باید بدانند کدام سیگنال‌ها به اتوماسیون استاندارد و کدام‌یک به معماری مرتبط با ایمنی تعلق دارند.

بنابراین، مفهوم خودترمیمی زمانی بهترین عملکرد را دارد که مهار خطا بر اساس نواحی عملکردی و ایمنیِ تعریف‌شده طراحی شود.

دوقلوهای دیجیتال یک لایه آزمون اضافه می‌کنند

دوقلوهای دیجیتال می‌توانند طراحی تحمل‌پذیر در برابر خطا را فراتر از تابلو فیزیکی گسترش دهند.

نمایش مجازی سیستم کنترل به مهندسان اجازه می‌دهد توالی‌های عملیاتی را پیش از اجرای تغییرات روی تجهیزات در حال کار مطالعه کنند.

شرایط خطا را می‌توان در مدل ایجاد کرد تا نحوه پاسخ‌گویی منطق کنترل بررسی شود.

مهندسان می‌توانند بررسی کنند که آیا هشدارهای درست نمایش داده می‌شوند، آیا انتقال افزونه به‌درستی انجام می‌شود و آیا برهم‌کنش‌های ناخواسته در فرایند رخ می‌دهد یا خیر.

این موضوع به‌ویژه زمانی مفید است که منطق بازیابی پیچیده می‌شود.

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

محیط شبیه‌سازی راه دیگری برای اعتبارسنجی عملکرد پیش از استقرار فراهم می‌کند.

شکل ۳. شبیه‌سازی دیجیتال می‌تواند به مهندسان کمک کند توالی‌های خطا و منطق بازیابی را پیش از اعمال تغییرات روی تجهیزات در حال کار ارزیابی کنند.

هوشمندی لبه‌ای، تصمیم‌گیری محلی را گسترش می‌دهد

پیشرفت دیگری، افزایش میزان پردازشی است که مستقیماً در خود ماشین در دسترس است.

معماری‌های کنترل سنتی اغلب وظایف تحلیلی سطح بالاتر را به سرورهای متمرکز ارسال می‌کنند.

پلتفرم‌های اج امکان می‌دهند برخی تشخیص‌ها به‌صورت محلی باقی بمانند.

این قابلیت برای کاربردهایی مفید است که در آن‌ها تصمیم‌گیری درباره خطا باید به‌سرعت انجام شود یا نمی‌توان اتصال مداوم به ابر را تضمین کرد.

تحلیل‌های محلی می‌توانند الگوهای غیرعادی را شناسایی کنند و فقط رویدادهای مرتبط را به سیستم‌های نظارتی یا سازمانی ارسال کنند.

PLC همچنان کنترل قطعی را انجام می‌دهد.

لایه تحلیلی اطلاعات بیشتری فراهم می‌کند که می‌تواند بر تصمیم‌های نگهداری یا منطق بازیابی ازپیش‌تعریف‌شده اثر بگذارد.

جدا نگه داشتن شفاف این عملکردها اهمیت دارد.

کنترل ماشین نباید به یک مدل تحلیلی مبهم وابسته شود که رفتار آن قابل اعتبارسنجی نیست.

پرسش‌هایی که مهندسان باید هنگام طراحی تابلو مطرح کنند

یک تابلوی مقاوم در برابر خطا، با پرسش‌های طراحی آغاز می‌شود، نه با یک قابلیت نرم‌افزاری.

مهندسان باید تعیین کنند که آیا نواحی مجزای خطا در معماری الکتریکی به‌وضوح تعریف شده‌اند یا خیر.

آن‌ها باید مشخص کنند کدام خرابی‌ها را می‌توان بدون خاموش کردن کامل ماشین ایزوله کرد.

دستگاه‌ها باید بازخورد تشخیصی کافی برای راهبرد نگهداری ارائه دهند.

عملکردهای حیاتی باید بررسی شوند تا مشخص شود آیا افزونگی از نظر فنی و اقتصادی توجیه دارد یا خیر.

تیم طراحی باید همچنین مشخص کند کدام متغیرهای وضعیت، فراتر از ساعات ساده کارکرد، به پایش مداوم نیاز دارند.

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

منطق بازیابی نیز باید در برابر سناریوهای واقع‌گرایانه خرابی، نه فقط توالی‌های عادی بهره‌برداری، آزمایش شود.

هدف، کاهش عملکرد کنترل‌شده است، نه تابلویی شکست‌ناپذیر

تجهیزات صنعتی همچنان دچار خرابی خواهند شد.

قطعات فرسوده می‌شوند. اتصالات افت می‌کنند. شبکه‌ها ارتباط خود را از دست می‌دهند. درایوها تریپ می‌کنند. منابع تغذیه به پایان عمر کاری خود می‌رسند.

بنابراین، هدف مهندسی ساخت تابلوی کنترلی غیرممکنی نیست که هرگز خراب نشود.

هدف بهتر، کاهش عملکرد کنترل‌شده است.

سیستم باید در صورت امکان، فرسودگی را زود تشخیص دهد.

هنگام وقوع خرابی، اثر آن باید هر زمان که معماری سیستم اجازه می‌دهد، محدود بماند.

اپراتورها باید به‌جای هشدارهای عمومی، اطلاعات تشخیصی مفیدی دریافت کنند.

فرایندهای حیاتی باید در صورت لزوم به عملکردهای پشتیبان مهندسی‌شده منتقل شوند.

پرسنل نگهداری باید اطلاعات کافی برای تعمیر سخت‌افزار آسیب‌دیده را بدون بررسی‌های غیرضروری در اختیار داشته باشند.

این، معنای عملی یک تابلو کنترل خودترمیم‌شونده است.

این سیستم خودش را تعمیر نمی‌کند.

این سیستم طوری طراحی شده است که وضعیت خود را بهتر درک کند، به خرابی‌های قابل پیش‌بینی واکنش هوشمندانه نشان دهد و تا زمان تکمیل تعمیر فیزیکی توسط افراد، بیشترین میزان عملکرد ایمن ممکن را حفظ کند.