هوش مصنوعی چگونه عملیات مرکز داده را هوشمندتر می‌کند؟ چهار کاربرد عملی

از داده‌های عملیاتی تا تصمیم‌های قابل رهگیری؛ با مرزبندی روشن میان پایش، توصیه و کنترل

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

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

در این مقاله می‌خوانید
پایه داده و یکپارچه‌سازی • چهار کاربرد عملی • مدل بلوغ Observe → Recommend → Controlled Automation • الزامات حاکمیت و ایمنی • مسیر انتخاب و اجرای پایلوت

هوش مصنوعی در عملیات مرکز داده دقیقاً چه کاری انجام می‌دهد؟

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

لایه داده

نمونه داده

نقش در تصمیم

DCIM و EPMSتوان، انرژی، ظرفیت رک و مسیر توزیعمحاسبه بار، ظرفیت رزرو و الگوی مصرف
BMS/BMCSدما، رطوبت، فشار، وضعیت شیر و فنتحلیل شرایط محیطی و عملکرد سرمایش
سوابق رخداد CMMSدستورکار، خرابی، تعویض قطعه و علت ریشه‌ایبرچسب‌گذاری نتیجه و بستن حلقه یادگیری
شبکه و امنیتتله‌متری، رخداد ورود و هشدارهای امنیتیهم‌بستگی رفتار ناهنجار فیزیکی و منطقی
مهم
داشبوردی که فقط داده را نمایش می‌دهد، الزاماً هوش مصنوعی نیست؛ مدلی که یک امتیاز ریسک تولید می‌کند نیز تا وقتی فرآیند واکنش، ثبت نتیجه و بازآموزی مشخص نباشد، یک قابلیت عملیاتی کامل محسوب نمی‌شود

 نگهداری پیش‌بینانه؛ از هشدارهای ثابت تا برآورد ریسک خرابی

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

دارایی

سیگنال‌های قابل بررسی

نمونه تصمیم عملیاتی

UPS و باتریولتاژ و جریان رشته/سلول، دما، امپدانس یا مقاومت داخلی، تعادل سلول‌ها، تاریخچه آزمون و دشارژاولویت‌بندی آزمون، بازرسی اتصال یا برنامه‌ریزی تعویض؛ نه تصمیم بر پایه یک متغیر منفرد
ژنراتورزمان استارت، ولتاژ باتری استارت، فشار روغن و سوخت، دمای سیال، لرزش، دود و پاسخ به پله باربررسی انحراف در راه‌اندازی یا عملکرد زیر بار پیش از آزمون بعدی
کمپرسور و چیلرفشار و دمای مکش/دهش، جریان موتور، لرزش، وضعیت شیرها، سیکل روشن/خاموش و شرایط محیطتشخیص افت تدریجی راندمان، کنترل سنسور یا برنامه‌ریزی بازدید
پمپ و فنلرزش، جریان، دور، اختلاف فشار، دمای یاتاقان و ساعات کارتفکیک احتمال گرفتگی، نابالانسی، خرابی یاتاقان یا خطای اندازه‌گیری
یک مطالعه منتشرشده در IFAC-PapersOnLine در سال ۲۰۲۰ روی ۲۹۲ باتری سرب‌اسیدی با شیر تنظیم‌شونده (VRLA) و حدود ۳۰ ماه داده عملیاتی، دقت ۹۸ درصد روی مجموعه آزمون و میانگین هشدار ۱۵ روزه را گزارش کرد [۱]. این نتیجه به یک ناوگان مشخص، مجموعه‌داده مشخص و تعریف مشخصی از خرابی مربوط است؛ بنابراین نمی‌توان آن را معیار تضمین‌شده‌ای برای باتری‌های هر مرکز داده دانست و عملکرد آن باید با داده‌های محلی اعتبارسنجی شود.

مک‌کنزی در یک مطالعه تحلیلی در حوزه تولید، کاهش معمول ۳۰ تا ۵۰ درصدی توقف ماشین‌آلات و افزایش ۲۰ تا ۴۰ درصدی عمر آن‌ها را برای نگهداری پیش‌بینانه گزارش کرده است [۲]. این ارقام مربوط به صنعت تولید و یک معیار بین‌صنعتی هستند و نباید به‌عنوان نتیجه مستقیم برای مراکز داده در نظر گرفته شوند. استفاده از آن‌ها برای برآورد اقتصادی یک پروژه مرکز داده، تنها پس از تعیین خط مبنای سایت و اجرای یک پایلوت محلی قابل اتکاست.

  1. کمبود نمونه‌های واقعی خرابی می‌تواند باعث شود مدل بیشتر الگوهای عادی را یاد بگیرد و در تشخیص موارد غیرعادی عملکرد ضعیف‌تری داشته باشد.
  2. هشدار کاذبِ زیاد به‌تدریج اعتماد اپراتور را کاهش می‌دهد؛ بنابراین هزینه هشدار کاذب و هزینه تشخیص‌ندادن رخداد باید به‌صورت جداگانه ارزیابی شود.
  3. تعویض تجهیز، تغییر نقاط تنظیم یا تغییر فصل می‌تواند الگوی داده را تغییر دهد و باعث افت عملکرد مدل شود. عملکرد مدل باید در طول زمان پایش شود و در صورت نیاز، مدل یا آستانه‌های آن بازتنظیم شوند.

 بهینه‌سازی انرژی و سرمایش؛ تصمیم‌گیری در محدوده ایمن

سامانه سرمایش یک مسئله چندمتغیره است. بار IT، دمای محیط، الگوی جریان هوا، وضعیت فن و پمپ، نقاط تنظیم، وضعیت افزونگی فعال و محدودیت‌های عملکردی تجهیزات، هم‌زمان بر عملکرد آن اثر می‌گذارند. مدل می‌تواند ارتباط میان این متغیرها را از داده‌های عملیاتی استخراج کند و برای نقاط تنظیم یا نحوه بهره‌برداری پیشنهاد ارائه دهد؛ اما اجرای این پیشنهاد باید در محدوده‌های مهندسی‌شده و با تأیید اپراتور، یا در قالب کنترل خودکارِ محدود و از پیش تعریف‌شده، انجام شود.
شاهد صنعتی با دامنه مشخص
Google DeepMind در سال ۲۰۱۶ گزارش کرد که کنترل مبتنی بر یادگیری ماشین در یکی از مراکز داده زنده گوگل، انرژی مصرفی سرمایش را تا ۴۰ درصد کاهش داد. همان منبع این اثر را معادل حدود ۱۵ درصد کاهش در سربار PUE توصیف می‌کند؛ نه «۱۵ درصد کاهش در خود PUE» [۳]. نتیجه به همان سایت، معماری و خط مبنا وابسته است و نباید به همه مراکز داده تعمیم داده شود.
DeepMind در سال ۲۰۱۸ از یک سامانه کنترل خودکار با چرخه‌های اقدام پنج‌دقیقه‌ای، دو لایه بررسی ایمنی، محدودیت‌های عملیاتی و امکان لغو توسط اپراتور گزارش داد. در رویکرد محافظه‌کارانه‌تر همان مرحله، میانگین صرفه‌جویی انرژی سرمایش حدود ۳۰ درصد بود [۴]. اهمیت این تجربه فقط به رقم صرفه‌جویی محدود نمی‌شود؛ در زیرساخت حیاتی‌ای مانند مرکز داده، اتوماسیون باید با محدودیت‌های کنترلی مستقل، سازوکار Fail-safe، امکان بازگشت به وضعیت قبل و ثبت کامل تصمیم‌ها همراه باشد.

در یک پژوهش پذیرفته‌شده در ICLR ۲۰۲۵، یک روش یادگیری تقویتی آفلاینِ آگاه از فیزیک در محیط واقعی مرکز داده و طی بیش از ۲٬۰۰۰ ساعت کنترل حلقه‌بسته آزموده شد. نویسندگان صرفه‌جویی ۱۴ تا ۲۱ درصدی در انرژی سرمایش را بدون نقض محدودیت‌های ایمنی و عملیاتی گزارش کردند [۵]. این نتیجه نیز مربوط به یک مطالعه موردی است، اما نشان می‌دهد ترکیب داده تاریخی، مدل فیزیکی و قیود صریح می‌تواند در مقایسه با آزمون‌وخطای مستقیم در محیط عملیاتی، مسیر کم‌ریسک‌تری ایجاد کند.

شاخص اثربخشی مصرف توان (PUE) از نسبت انرژی کل مصرف‌شده در مرکز داده به انرژی مصرف‌شده توسط تجهیزات IT به‌دست می‌آید. ویرایش جاری ISO/IEC 30134-2:2026، تعریف و روش محاسبه این شاخص را مشخص می‌کند [۶]. PUE برای پایش عملکرد داخلی و مقایسه مراکز داده در شرایط هم‌ارز مفید است، اما به‌تنهایی کیفیت سرویس، مصرف آب، انتشار کربن، تراکم یا کارایی بار IT را نشان نمی‌دهد. حتی تغییر بار IT می‌تواند بدون بهبود واقعی زیرساخت، مقدار PUE را تغییر دهد؛ بنابراین ارزیابی عملکرد باید با شاخص‌های مکمل و بر مبنای یک خط مبنای روشن انجام شود.

 برآورد و پیش‌بینی ظرفیت؛ تصمیم‌گیری پیش از رسیدن به مرز ظرفیت

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

پرسش تصمیم

خروجی تحلیلی

کنترل انسانی لازم

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

 تشخیص ناهنجاری و امنیت؛ هم‌بستگی، نه داوری خودکار

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

  1. سامانه هوش مصنوعی جایگزین SIEM، کنترل دسترسی، تفکیک شبکه یا رویه‌های پاسخ به رخداد نیست.
  2. حداقل‌سازی داده، کنترل دسترسی، رمزنگاری، نگهداری لاگ و جداسازی محیط آموزش از محیط تولید باید درباره خود سامانه هوش مصنوعی نیز رعایت شود.
  3. هر هشدار باید با شواهد قابل مشاهده، سطح اطمینان، دارایی مرتبط و مسیر مشخص برای ارجاع و تشدید رخداد (Escalation) همراه باشد. اقدام مسدودکننده خودکار نیز فقط در سناریوهایی مناسب است که از پیش تعریف، آزموده و تأیید شده باشند.

چارچوب مدیریت ریسک هوش مصنوعی NIST AI RMF 1.0، چارچوبی داوطلبانه برای مدیریت ریسک و تقویت اعتمادپذیری سامانه‌های هوش مصنوعی است [۷]. تا زمان بازبینی این مقاله، NIST برای «پروفایل هوش مصنوعی قابل‌اعتماد در زیرساخت حیاتی» فقط یک Concept Note منتشر کرده و این پروژه همچنان در حال توسعه است؛ بنابراین، این سند نباید به‌عنوان پروفایل نهایی معرفی شود [۸]. سازمان‌ها می‌توانند در شرایط فعلی از توابع Govern، Map، Measure و Manage در AI RMF برای تعیین مسئولیت‌ها، ارزیابی و کنترل ریسک استفاده کنند.

مدل بلوغ: از مشاهده تا اتوماسیون کنترل‌شده

مرحله

خروجی سامانه

نقش انسان

معیار عبور

Observe | مشاهدهنمایش الگو، ناهنجاری و کیفیت داده؛ بدون ارائه پیشنهاد عملیاتیتیم عملیات علت رخداد و صحت داده را بررسی و ثبت می‌کندکامل‌بودن داده‌ها، نرخ هشدار قابل‌قبول و خط مبنای معتبر
Recommend | توصیهارائه پیشنهاد عملیاتی همراه با دلیل، سطح اطمینان و اثر احتمالیاپراتور پیشنهاد را می‌پذیرد، رد می‌کند یا اصلاح می‌کند؛ نتیجه ثبت می‌شوداثر پایدار، خطای کنترل‌شده و اعتماد تیم عملیات
Controlled Automation | اتوماسیون کنترل‌شدهاجرای اقدام‌های محدود در بازه و دامنه از پیش تعریف‌شدهمحدودیت مستقل، تأیید دومرحله‌ای در موارد حساس، Override و Fail-safeآزمون سناریو، مشاهده‌پذیری، برنامه بازگشت و تأیید مدیریت تغییر

اصل حاکمیتی
هرچه پیامد اقدام برگشت‌ناپذیرتر یا دامنه تأثیر آن بزرگ‌تر باشد، نیاز به محدودیت مستقل از مدل، تأیید انسانی و امکان بازگشت بیشتر است. Human-in-the-Loop یک برچسب نیست؛ باید در گردش‌کار، سطح دسترسی و سناریوی خطا پیاده شود.

پیش‌نیازهای یک پروژه قابل‌اتکا

داده و زمینه عملیاتی

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

یکپارچه‌سازی و امنیت

رابط‌های ارتباطی با DCIM، BMS، EPMS و CMMS باید حداقل سطح دسترسی لازم، ثبت رویدادها، مدیریت نسخه و جداسازی مسیر کنترل از مسیر تحلیل را رعایت کنند. اتصال مستقیم یک مدل آزمایشی به کنترلر تجهیزات، بدون یک لایه تأیید مستقل، از نظر مهندسی قابل دفاع نیست.

حاکمیت مدل و فرآیند عملیات

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

ارزش اقتصادی قابل‌اندازه‌گیری

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

چگونه یک پایلوت مناسب انتخاب کنیم؟

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

  1. ابتدا مسئله و تصمیم موردنظر را دقیق تعریف کنید؛ برای مثال، هدف می‌تواند اولویت‌بندی بازرسی باتری باشد، نه «پیش‌بینی همه خرابی‌ها».
  2. خط مبنا، هزینه خطا و شاخص‌های موفقیت را پیش از مشاهده نتایج مدل ثبت کنید.
  3. کیفیت و کامل‌بودن داده‌ها را در یک بازه زمانی نماینده، شامل فصل‌های مختلف، شرایط بار و رخدادهای عملیاتی، ارزیابی کنید.
  4. مدل را ابتدا در حالت Shadow یا Observe اجرا کنید و نتایج آن را با تصمیم اپراتور مقایسه کنید.
  5. پس از بررسی امنیت و مدیریت تغییر، مرحله ارائه پیشنهاد را آغاز کنید؛ اپراتور باید بتواند پیشنهاد را رد یا اصلاح کند و دلیل این تصمیم نیز ثبت شود.
  6. فقط پس از اثبات ارزش و ایمنی، اتوماسیون را در محدوده‌ای کوچک، مشخص و قابل بازگشت آغاز کنید.

معیار انتخاب

نشانه مناسب

علامت توقف یا بازطراحی

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

دیدگاه تخصصی مهندس شیرزادی

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

مهندس شیرزادی

جمع‌بندی

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

سوالات متداول

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

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

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

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

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

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

منابع و مراجع 

۱. Tang و همکاران، IFAC-PapersOnLine (۲۰۲۰) — Data center battery anomaly detection and failure prediction؛ مطالعه ۲۹۲ باتری VRLA، DOI: 10.1016/j.ifacol.2020.12.854

۲. McKinsey & Company (۲۰۱۷) — Manufacturing: Analytics unleashes productivity and profitability؛ معیار بین‌صنعتی نگهداری پیش‌بینانه

۳. Google DeepMind (۲۰۱۶) — DeepMind AI reduces Google data centre cooling bill by 40%

۴. Google DeepMind (۲۰۱۸) — Safety-first AI for autonomous data centre cooling and industrial control

۵. Zhan و همکاران، ICLR ۲۰۲۵ — Data Center Cooling System Optimization Using Offline Reinforcement Learning؛ مقاله داوری‌شده در Proceedings

۶. ISO/IEC 30134-2:2026 — Data centres KPI — Part 2: Power usage effectiveness (PUE)، ویرایش دوم

۷. NIST AI Risk Management Framework — AI RMF 1.0 و وضعیت بازنگری چارچوب

۸. NIST (۲۰۲۶) — Concept Note: AI RMF Profile for Trustworthy AI in Critical Infrastructure؛ پروژه در حال توسعه

نویسنده: محمد شیرزادی