معماری Edge Site Central

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

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

معماری سه‌لایه برای جلوگیری از همین گروگان‌گیری است. هر لایه مأموریت دارد. آنچه به تأخیر، حجم، محرمانگی و استمرار وا‌بسته است پایین می‌ماند. آنچـه به زمینه واحد و تصمیم شیفت و‌ابسته‌ است در سایت می‌ماند. آنچه به یادگیری جمعی و استاندارد وابسته است بالا می‌رود.

لبه: نزدیک دارایی، برای آنچه بالا نمی‌آید

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

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

در راهکار فروشنده، لبه گاهی یعنی همان کنترلر محلی. رتروفیت نباید برای «داشتن لبه» رایانه تازه‌ای روی راهکار بگذارد که مسئولیت OEM و مسیر دا‌ده را مبهم کند. اول بازیابی سیگنال موجود، بعد افزودن جزء جدید.

سایت: خانه عملیات

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

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

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

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

مرکزیت/هلدینگ: خدمات مشترک، نه اتاق فرمان

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

مرکزیت/هلدینگ نباید:

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

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

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

قاعده جای‌گذاری: دا‌ده، مدل، تصمیم

برای هر قابلیت سه سؤال کافی است.

دا‌ده کجا تولید می‌شود و چه حجمی دارد؟ اگر خام و پرحجم است، ویژگی در لبه ساخته شود. اگـر تگ فرایندی است، سایت کافی است. اگر شاخص و رخداد تصمیم است، رونوشت مرکز مفید است.

مدل چه حساسیتی به تأخیر و قطع دارد؟ استنتاج لازم برای شیفت روی سایت یا لبه. آموزش و مقایسه نسخه در مرکز.

تصمیم کجا مسئولیت دارد؟ اگر عمل در میدان است، خروجی در سایت بماند. اگـر تخصیص سرمایه است، پرونده در هلدینگ جمع شود. اگر ایمنی است، هیچ لایه‌ای مسئولیت سایت را بالا نبرد.

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

قطع ارتباط را باید طراحی کرد نه امید داشت

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

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

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

امنیت با توزیع عوض می‌شود نه کم

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

تفکیک جریان دا‌ده و جریان تصمیم در مقاله بعد می‌آید، اما همین‌جا باید گفت: تجمیع دا‌ده به مرکز هرگز به‌تنهایی مجوز مسیر فرمان نیست. معماری سه‌لایه اگر این دو جریان را روی یک کانال و یک هویت بگذارد، فایده قطعه‌بندی را از بین می‌برد.

پیام مقیاس

Edge–Site–Central اجازه می‌دهد پایلوت روی لبه و سایت ثابت شود و فقط جزءهای استاندارد به مرکز بروند: قالب، روش اعتبارسنجی، رجیستری، شاخص. کپی نکردن مدل خام از سایت اول به سایت دوم نیز از همین معماری می‌آید. مرکز مدل مرجع می‌دهد؛ سایت با دا‌ده و قید خود اعتبارسنجی می‌کند.

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