تحلیل و بازنویسی اختصاصی آران ویژن بر پایه وایتپیپر زیمنس «Evaluation of production data»، شماره سند DIFA-B90394-00-7600، منتشرشده در سال ۲۰۲۶.
داده زمانی ارزش دارد که به تصمیم عملیاتی برسد
ثبت انبوه تگها بهتنهایی بهرهوری را افزایش نمیدهد. اپراتور، سرپرست تولید و تیم نگهداری باید بتوانند داده برخط، تاریخچه فرایند، آلارم و وضعیت ماشین را در زمینه درست ببینند و از آن برای یافتن گلوگاه، کاهش توقف و کنترل کیفیت استفاده کنند. نقطه شروع، تعریف مسئله و تصمیم موردنیاز است؛ سپس باید مشخص شود کدام داده با چه دقت، تناوب و مدت نگهداری برای آن تصمیم لازم است.
پایگاه داده مشترک، جزیرههای HMI را به یک تصویر منسجم تبدیل میکند
در بسیاری از خطوط، هر ماشین یا ناحیه HMI و آرشیو جداگانه دارد. نتیجه، زمانبندیهای ناسازگار، فرمتهای متفاوت و دشواری ردیابی رخدادهاست. معماری SCADA میتواند داده و آلارم چند زیرسامانه را تجمیع و بهصورت مرکزی آرشیو کند؛ با این شرط که همگامسازی زمان، کیفیت تگ، نامگذاری، مالکیت داده و سیاست نگهداری از ابتدا استاندارد شوند. یک داشبورد زیبا روی داده نامعتبر فقط خطا را پنهان میکند.
تحلیل آلارم باید از شمارش پیامها فراتر برود
برای تحلیل آلارم میتوان فراوانی وقوع، مدت فعالبودن، زمان تأیید و توالی رخدادها را بررسی کرد. Hit list به شناسایی آلارمهای پرتکرار کمک میکند، اما آلارم پرتکرار الزاماً علت ریشهای نیست. تحلیل معتبر باید وضعیت فرایند، interlockها، تغییرات اپراتور و رخدادهای پیش از توقف را در خط زمانی مشترک قرار دهد. هدف نهایی، کاهش alarm flood و تعریف اقدام روشن برای پیامهای مهم است.
تحلیل در سطح کل سایت بدون تعویض همه سامانهها
وایتپیپر به PM-ANALYZE برای SIMATIC WinCC Unified و WinCC V8 اشاره میکند؛ ابزاری که میتواند پیامها و روندها را از منابع مختلف گردآوری، نگاشت و فیلتر کند و گزارشهای مستند تولید کند. مزیت این رویکرد آن است که برای ایجاد دید کلان الزاماً نباید همه تجهیزات موجود تعویض شوند. پیش از اجرا باید کیفیت رابط هر منبع، ترتیب زمانی رویدادها، ظرفیت آرشیو، سطح دسترسی و بار گزارشگیری ارزیابی شود.
OEE، MTBF و MTTR را با تعریف مشترک محاسبه کنید
شاخصهای عملکرد زمانی قابل مقایسهاند که مرز محاسبه آنها روشن باشد. برای OEE باید برنامه تولید، زمان توقف، سرعت مرجع و معیار محصول سالم تعریف شود. MTBF بدون توافق درباره مفهوم خرابی و MTTR بدون ثبت دقیق شروع و پایان تعمیر میتواند گمراهکننده باشد. بهتر است هر KPI از سطح ماشین تا خط و کارخانه قابلیت drill-down داشته باشد تا تغییر عدد به تگها، حالت ماشین، خطاها و عملیات کاربر متصل شود.
هوش مصنوعی باید روی داده ساختیافته و دسترسی کنترلشده قرار بگیرد
WinCC Unified و WinCC V8 میتوانند بستر دسترسی ساختیافته به مقدارهای برخط، تاریخچه، آلارم و زمینه پروژه را فراهم کنند. در سند، رابطهای باز و الگوهای یکپارچهسازی مبتنی بر MCP بهعنوان پایه دستیار اپراتور مطرح شدهاند؛ برای نمونه، جستوجوی زبان طبیعی در رخدادها، آمادهسازی گزارش یا راهنمایی عیبیابی. این قابلیت باید با نقشهای دسترسی، ثبت کامل درخواستها، محدودیت عملیات نوشتنی و تأیید انسانی پیاده شود؛ پاسخ مدل نباید جایگزین interlock یا تصمیم ایمنی شود.
دفتر شیفت الکترونیکی، حافظه عملیاتی کارخانه است
تحویل شفاهی شیفت معمولاً جزئیات مهم را از دست میدهد. دفتر شیفت الکترونیکی رخداد، اولویت، وضعیت، مسئول پیگیری و تاریخچه ویرایش را ثبت میکند و میتواند رخداد را به تجهیز یا ناحیه مشخصی در ساختار کارخانه متصل سازد. قابلیت جستوجو و دسترسی از SCADA یا مرورگر، عیبیابی رخدادهای تکرارشونده را سریعتر میکند؛ مشروط بر اینکه سطح دسترسی بر اساس نقش و مسئولیت تعریف شود.
ترکیب راهکارها؛ WinCC، افزونههای PM و رایانش صنعتی
این معماری میتواند از WinCC V8 یا WinCC Unified برای نمایش و عملیات، افزونههای PM برای تحلیل و مدیریت فرایند، و SIMATIC IPC برای اجرای صنعتی استفاده کند. سند به ارتباطاتی مانند OPC UA، REST API و MQTT نیز اشاره دارد. انتخاب میان این اجزا باید بر اساس تعداد تگ، نرخ ثبت، مدت آرشیو، افزونگی، تعداد کاربران، الزامات شبکه و نسخههای سازگار انجام شود؛ عنوان محصول بهتنهایی برای طراحی معماری کافی نیست.
مسیر اجرایی پیشنهادی؛ با یک مسئله محدود شروع کنید
یک خط یا تجهیز بحرانی را انتخاب کنید و هدفی قابلاندازهگیری مانند کاهش زمان تشخیص توقف تعیین کنید. فهرست تگ و آلارم، کیفیت داده، منبع زمان و مالک هر سیگنال را ثبت کنید؛ سپس یک خط زمانی مشترک، چند KPI محدود و یک گزارش شیفت آزمایشی بسازید. پس از تأیید دقت داده و استفاده واقعی کاربران، دامنه را گسترش دهید. معیار پذیرش باید شامل صحت محاسبه، تأخیر نمایش، بازیابی پس از قطع ارتباط، کنترل دسترسی و امکان ردیابی تغییرات باشد.
دامنه و محدودیت اطلاعات فنی
مطالب این مقاله برای طراحی مفهومی و ارزیابی اولیه است. قابلیت دقیق هر نسخه، لایسنس، افزونه و سختافزار باید در مستندات همان نسخه و قرارداد پروژه کنترل شود. همانطور که زیمنس در سند اصلی یادآوری میکند، توضیحات عمومی ممکن است با توسعه محصول تغییر کنند و ویژگی الزامآور باید صریحاً در قرارداد نهایی درج شود.