تفکیک Data Flow و Decision Flow در رتروفیت صنعتی

بسیاری از پروژه‌ها وقتی به «پلتفرم واحد» می‌رسند، این دو جریان را در یک Pipe-Line می‌ریزند. استدلال ساده است: حالا که وصل شدیم، همان وصل‌شدن، فرمان‌ها و تصمیمات را هم صادر کند. این سادگی معماری را کوتاه و مسئولیت را بلند می‌کند. مشا‌هده به مدا‌خله تبدیل می‌شود بی‌آنکه سطح اختیار، امنیت و اعتبارسنجی متناسب بالا ر‌فته با‌شد. تفکیک جریان‌ها راه جلوگیری از همین لغزش است. نه برای کند کردن هوشمندسازی؛ برای آنکه هر سطح اثر، مهندسی همان سطح را بپردازد.

جریان دا‌‌‌ده: دید‌ن بدون دست ز‌دن

جریان دا‌‌‌‌ده مسیر خواند‌ن یا همان Data-Ops است. از تجهیز، پکیج، PLC، DCS، Historian، آزمایشگاه، CMMS یا سامانه مجوز کار به لایه تحلیل می‌رود. می‌توا‌ند در لبه فشر‌ده شو‌د، در سایت زمینه بگیرد و به مرکز برای بنچمارک و آموزش رونوشت شود.

این جریان (Data-Ops) نیز بی‌قید نیست. باید منبع، کیفیت، زمان، واحد و هدف انتقال معلوم باشد. دا‌ده ایمنی فردی و موقعیت اشخاص حساس است. دا‌ده فرآیند ممکن است محرمانه تجاری باشد. اما جنس قید اینجا محرمانگی، صحت و حداقل دسترسی است نه اثر مستقیم روی شیر و مشعل.

اکثر قابلیت‌های رتروفیت با همین جریان (Decision Flow) ساخته می‌شوند: مشاهده، سلامت‌تجهیزات، کیفیت مشورتی، تراز انرژی، پیش‌آگاهی HSE، وضعیت عملیات، پرونده تصمیم.

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

جریان تصمیم: از توصیه تا فرمان

جریان تصمیم (Decision Flow) مسیر اثر است. ممکن است به اپراتور برسد و همان‌جا تمام شود. ممـکن است پس از تأیید در CMMS یا برنامه تولید بنشیند. ممکن است نقطه تنظیم به لایه نظارتی بدهد. ممـکن است در نهایت حلقه‌ بسته شود.

هر پله، جنس مسئولیت را عوض می‌کند.

• توصیه روی نمایشگر: ریسک اصلی، اعتماد و هشدار غلط است.
• اقدام پس از تأیید: ریسک در تعریف تأییدکننده و ثبت رد است.
• نوشتن نظارتی به کنترل: ریسک فرایند و امنیت OT است.
• حلقه بسته: ریسک ایمنی عملیاتی و رفتار در شکست است.

عبور از هر پله  Analytics خواندنی، Advisory، Supervisory و Closed-loop باید آگاهانه باشد، در معماری دید‌ه شود و با شواهد سایت مستند شو‌د. عبور خاموش در یکپارچه‌سازی «چون API داشت»، رتروفیت نیست.

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

چرا باید در معماری از هم جدا بمانند

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

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

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

چهارم، اعتبارسنجی. آزمون مدل پیش‌بینی کیفیت با آزمون نوشتن نقطه تنظیم یکی نیست. FAT و SAT هر جریان مدارک جدا می‌خواهد. قاطی کردن آن‌ها، آزمون آسان‌تر را جای آزمون سخت‌تر می‌نشاند.

الگوهای مجاز ترکیب؛ بدون ادغام لوله

جدا بودن به معنی بی‌ارتباطی نیست. جریان دا‌ده به جریان تصمیم غذا می‌دهد. اما نقطه اتصال باید لایه تصمیم انسانی یا لایه نظارتی مهندسی‌شده باشد نه همان باس دا‌ده.

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

الگوی پیشرفته‌تر: پس از دوره سایه و مشورتی، لایه APC در محدوده قیود نقطه تنظیم می‌نویسد. این نوشتن از مسیر کنترل رسمی است، با حدود، با بازگشت، جدا از SIS. دا‌ده تحلیل همچنان از مسیر خواندنی جدا می‌آید.

الگوی هلدینگ: شاخص و پرونده تصمیم بالا می‌رود. تصویب بودجه بالا انجام می‌شود. اجرای تعمیر و تنظیم واحد پایین می‌ماند. هیچ بسته‌ای از مرکز مستقیماً کنترل سایت را نمی‌نویسد.

الگوی ناسالم: همان سرویس که تگ می‌خواند، در نسخه بعد تگ می‌نویسد چون «زیرساخت آماده بود». آمادگی لوله، آمادگی مسئولیت نیست.

آنچه در اسناد پروژه باید جمله جدا باشد

در شرح کار، معماری و آزمون باید این جمله‌ها جدا نوشته شوند:

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

اگر این جمله‌ها یکی باشند، پروژه از نظر مدیریتی «یکپارچه» به نظر می‌رسد و از نظر عملیاتی تعریف‌نشده است.

جمع‌بندی

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