سکوی فناوری مشترک رتروفیت

AI و MLOps، دا‌ده صنعتی، مدل اطلاعاتی، Edge و OT

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

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

فلسفه زیرساختی: ترکیب به‌اندازه مسئله

اگر از سرمایه موجود شروع کنیم، مسیر فقط خواندنی را برای «مشاهده» بصورت پیش‌فرض بگیریم، درج اطلاعات به OT را فقط وقتی انجام دهیم که مسئله کنترل‌شده باشد، برای قطع ارتباطات راهکار طراحی کنیم، مدل را پس از آموزش رها نکنیم، و امنیت را به بستن شبکه بعد از استقرار واگذار نکنیم، در پارادایم رتروفیت هستیم!

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

On-premise و Offline در صنایع حساس، گزینه حاشیه‌ای نیستند. اگر معماری فقط با اتصال دائمی به مرکز یا Cloud معنا داشته باشد، عملیات سایت، نقطه شکست بیرونی پیدا کرده است. سکو باید این قید را از لایه فناوری پشتیبانی کند.

لایه اتصال به دارایی و OT

پایین‌ترین لایه می‌تواند دا‌ده موجود  DCS، PLC، SCADA، Historian  و سامانه‌های مختلف را بخواند یا در صورت نیاز به حسگر و لبه جدید وصل شود. اصل، استفاده از سرمایه‌ها و دارایی‌های موجود است.

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

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

لایه دا‌ده صنعتی و مدل اطلاعاتی

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

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

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

Compute، AI و آنچه لازم نیست

زیرساخت پردازش از CPU و لبه تا خوشه GPU امتداد دارد. بسیاری از مدل‌های صنعتی GPU نمی‌خواهند. بینایی ماشین، مدل‌های زایا و آموزش سنگین ممکن است بخواهند. آموزش و استنتاج نیز الزاماً روی یک سخت‌افزار اجرا نمی‌شوند. آموزش می‌تواند مرکزی و کنترل‌شده باشد؛ استنتاج روی سایت یا لبه بماند.

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

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

چرخه عمر مدل؛ جایی که پروژه به قابلیت تبدیل می‌شود

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

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

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

قابلیت اطمینان و امنیت

زیرساخت باید قطع ارتباط، قطع سرویس، قطع GPU یا قطع منبع دا‌ده را در طراحی لحاظ کند. طراحی  «افت نرم» لازم است: ورودی غیرحیاتی نباید کل سامانه را مختل کند؛ ورودی کلیدی که رفت، خروجی ظاهراً معتبر نباید تولید شود.

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

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

آنچه برای همه پروژه‌ها اجباری نیست

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

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

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

پیام برای تصمیم خرید زیرساخت

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

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