استقرار عوامل هوش مصنوعی در کف یک کارخانه تولیدی که همزمان OPC UA، Modbus و MQTT را مخابره می‌کند

برای بسیاری از معماران مشتاق راه‌حل‌های هوش مصنوعی، شور و شوق اولیه برای کاربردهای تولید اغلب با یک واقعیت تلخ برخورد می‌کند: کف کارخانه‌ها به ندرت یک محیط بکر و تک پروتکلی هستند. فرض یک بستر داده همگن، که در آن تمام فناوری‌های عملیاتی (OT) منحصراً با OPC UA، Modbus یا MQTT صحبت می‌کنند، سریع‌ترین راه برای رکود پروژه تا هفته دوم است. این سوءتفاهم اساسی از پیچیدگی ارتباطات صنعتی، اغلب منجر به تجدیدنظر در دامنه، فراتر رفتن از بودجه و در نهایت، طرح‌های بایگانی شده می‌شود، که نشان‌دهنده نیاز حیاتی به یک استراتژی یکپارچه‌سازی چند پروتکلی قوی‌تر از همان ابتدا است. سوال «چگونه عوامل هوش مصنوعی را در یک کف کارخانه تولیدی مستقر کنیم» دیگر انتزاعی نیست؛ این آزمون عملی است که پایلوت‌ها را از تولید جدا می‌کند.

ماهیت سه‌گانه پروتکل‌های ارتباطی صنعتی

محیط‌های صنعتی مدرن، به ویژه در تولید و کنترل فرآیند، با ناهمگونی فراگیر در پروتکل‌های ارتباطی مشخص می‌شوند. غیرمعمول نیست، بلکه یک استاندارد است، که کف کارخانه‌ها به طور همزمان با OPC UA، Modbus TCP/RTU و MQTT کار کنند. این به دلیل عدم برنامه‌ریزی استراتژیک نیست، بلکه بازتابی از تکامل صنعتی، چرخه‌های عمر تجهیزات و اکوسیستم‌های مختلف فروشندگان است. ماشین‌های قدیمی با استفاده از Modbus به طور قابل اعتماد کار می‌کنند، تجهیزات جدیدتر از OPC UA برای مدل‌های داده غنی و قابلیت همکاری آن استفاده می‌کنند، و گرایش به اینترنت اشیا صنعتی (IIoT) MQTT را برای انتقال داده‌های کارآمد و مقیاس‌پذیر پیش می‌برد.

این پروتکل‌ها اغلب در لایه‌های مختلف هرم اتوماسیون همزیستی دارند. Modbus، یک پروتکل قدیمی و قوی، اغلب در سطح حسگر و محرک غالب است و دسترسی ساده به رجیسترها را برای PLCها و RTUها فراهم می‌کند. OPC UA معمولاً در یک لایه نظارتی بالاتر قرار دارد و ساختارهای داده پیچیده، دسترسی به داده‌های تاریخی و مکانیزم‌های امنیتی پیچیده را از سیستم‌های SCADA و کنترل‌کننده‌ها ارائه می‌دهد. MQTT، به ویژه با افزونه‌هایی مانند Sparkplug B، به طور فزاینده‌ای برای ارتباط ماشین به ابر یا ماشین به لبه اتخاذ می‌شود، که انتشار و اشتراک داده‌های کارآمد را در شبکه‌های وسیعی از دستگاه‌های IIoT تسهیل می‌کند.

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

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

معماری عامل برای محیط‌های پروتکل ناهمگن

برای مدیریت موثر پیچیدگی، عوامل هوش مصنوعی باید با ظرفیت اساسی برای عدم وابستگی به پروتکل در لایه معنایی طراحی شوند. این بدان معناست که در حالی که ورود داده‌های خام ممکن است شامل Handlers پروتکل خاص باشد، موتورهای هوش و استدلال core عوامل باید بر روی یک مدل داده یکپارچه، مجرد از مکانیسم ارتباطی زیرین، عمل کنند. هدف این است که داده‌ها به عامل به عنوان یک بافت عملیاتی منسجم و هم‌زمان ارائه شوند، صرف نظر از اینکه آیا از یک کویل Modbus، یک متغیر OPC UA یا یک محموله موضوعی MQTT سرچشمه گرفته‌اند.

یک الگوی رایج شامل آداپتورهای پروتکل اختصاصی یا کانکتورها برای هر نوع ارتباط است. یک جزء کلاینت OPC UA در عامل یا دروازه لبه آن، جلسات امنی را با سرورهای OPC UA برقرار می‌کند و به گره‌های خاصی در فضاهای آدرس خود مشترک می‌شود. به طور همزمان، یک جزء کلاینت Modbus رجیسترهای مشخص شده (نگهدارنده، ورودی، کویل یا ورودی گسسته) را در دستگاه‌های Modbus TCP/RTU پول می‌کند و وضعیت اتصال و مدیریت خطا را انجام می‌دهد. برای MQTT، یک کلاینت MQTT پیشرفته به موضوعات مرتبط، از جمله آنهایی که توسط Sparkplug B ساختار یافته‌اند، مشترک می‌شود و محموله‌ها را تجزیه و تحلیل کرده و معیارهای حیاتی را استخراج می‌کند.

این Handlersهای خاص پروتکل سپس به یک لایه نرمال‌سازی و نگاشت معنایی تغذیه می‌کنند. این لایه مسئول ترجمه نقاط داده خاص پروتکل (به عنوان مثال، Modbus register 40001، OPC UA NodeId "ns=2;s=Mixer/Temperature"، MQTT topic "spBv1.0/site_id/device_id/DDATA/Metrics/Temperature") به یک نمایش داخلی استاندارد است. این نمایش داخلی باید شامل یک شناسه منحصر به فرد، یک برچسب زمان (timestamp)، یک مقدار، واحد اندازه‌گیری و هرگونه فراداده مرتبط باشد. این رویکرد ساختار یافته به عامل هوش مصنوعی اجازه می‌دهد تا بدون نیاز به درک پیچیدگی‌های کدهای تابع Modbus یا انواع داده‌های OPC UA، در مورد وضعیت عملیاتی استدلال کند.

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

اشتراک فضای آدرس OPC UA

OPC UA (معماری یکپارچه ارتباطات پلتفرم باز) یک معماری قدرتمند، مستقل از پلتفرم و سرویس‌گرا برای ارتباطات صنعتی است. قوت آن در توانایی آن در ارائه یک فضای آدرس جامع و سلسله مراتبی است که تمام داده‌ها، آلارم‌ها، رویدادها و اطلاعات تاریخی را در یک سیستم نشان می‌دهد. برای عوامل هوش مصنوعی، اشتراک این فضای آدرس روش اصلی جمع‌آوری داده‌ها است، نه صرفاً polling.

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

هسته جمع‌آوری داده‌ها از OPC UA شامل ایجاد اشتراک‌ها است. یک عامل برای لیستی از شناسه‌های گره خاص (متغیرها، ویژگی‌ها) که نیاز به نظارت دارد، اشتراک ایجاد می‌کند. برای هر مورد مشترک، عامل پارامترهایی مانند فاصله نمونه‌برداری (چند وقت یکبار سرور برای تغییرات بررسی می‌کند) و فاصله انتشار (چند وقت یکبار سرور اعلان‌های تغییرات را به کلاینت ارسال می‌کند) را تعریف می‌کند. این مدل مبتنی بر فشار بسیار کارآمد است، زیرا سرور تنها زمانی داده‌ها را ارسال می‌کند که تغییر کنند و ترافیک شبکه را در مقایسه با polling مداوم کاهش می‌دهد.

مدیریت داده‌های OPC UA شامل تجزیه ساختارهای داده پیچیده است که می‌تواند شامل نه تنها مقادیر خام بلکه پرچم‌های کیفیت، برچسب‌های زمانی و انواع داده‌ها نیز باشد. کلاینت OPC UA عامل باید قادر به Deserialize کردن این پیام‌ها به فرمتی قابل مصرف توسط لایه نرمال‌سازی پایین‌دست باشد. مدیریت قوی قطع شدن اتصال، اشتراک مجدد و خطاهای سمت سرور برای اطمینان از جریان مداوم داده‌ها ضروری است، با اذعان به اینکه شبکه‌های صنعتی ممکن است مستعد مشکلات متناوب باشند.

پُرس‌وجو از رجیسترهای Modbus برای داده‌های حیاتی

Modbus، در انواع TCP و RTU خود، همچنان سنگ بنای ارتباطات صنعتی، به ویژه در سطوح پایین‌تر هرم اتوماسیون است. در حالی که پیچیدگی OPC UA را ندارد، سادگی، قدرت و پذیرش گسترده آن، آن را غیرقابل جایگزین می‌کند. برای عوامل هوش مصنوعی، به دست آوردن داده‌ها از دستگاه‌های Modbus عمدتاً شامل پُرس‌وجو از رجیسترهای خاص است. برخلاف مدل push OPC UA، Modbus اساساً یک پروتکل درخواست-پاسخ است.

Modbus TCP از طریق اترنت استاندارد، با استفاده از پورت 502، عمل می‌کند، در حالی که Modbus RTU معمولاً از ارتباطات سریال (RS-232/485) استفاده می‌کند. یک عامل هوش مصنوعی، یا معمولاً جزء لبه آن، به عنوان یک Master Modbus عمل خواهد کرد و درخواست‌های خواندن را به دستگاه‌های Slave Modbus (مانند PLC ها، HMI ها، حسگرها) ارسال می‌کند. این درخواست‌ها، شناسه Slave، کد تابع، و آدرس شروع و تعداد رجیسترهایی را که باید خوانده شوند، مشخص می‌کنند. کدهای تابع رایج شامل Read Holding Registers (0x03)، Read Input Registers (0x04)، Read Coils (0x01)، و Read Discrete Inputs (0x02) هستند.

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

فاصله‌های پُرس‌وجو باید با دقت مدیریت شوند. پُرس‌وجوی بیش از حد مکرر می‌تواند دستگاه Slave Modbus یا باس ارتباطی را بیش از حد بارگذاری کند، در حالی که پُرس‌وجوی بسیار نادر می‌تواند منجر به داده‌های منقضی و از دست رفتن رویدادهای حیاتی شود. کلاینت Modbus عامل باید در برابر Timeouts، NACKs (تأیید منفی)، و سایر خطاهای ارتباطی مقاوم باشد و منطق تلاش مجدد و استراتژی‌های برقراری مجدد اتصال را برای حفظ یکپارچگی داده‌ها پیاده‌سازی کند. برچسب‌گذاری دقیق زمان در هنگام دریافت داده‌های Modbus نیز حیاتی است، زیرا خود پروتکل معمولاً اطلاعات دقیق زمان را حمل نمی‌کند.

مصرف همزمان موضوعات Sparkplug B پروتکل MQTT

MQTT (انتقال تله‌متری با صف پیام) به دلیل ماهیت سبک، کارایی و مدل انتشار-اشتراک خود به عنوان یک پروتکل ارجح برای برنامه‌های IIoT ظهور کرده است. وقتی در نظر می‌گیریم که چگونه عوامل هوش مصنوعی را در کف یک کارخانه تولیدی مستقر کنیم، MQTT، به ویژه با مشخصه Sparkplug B، یک مکانیسم بسیار مقیاس‌پذیر و انعطاف‌پذیر برای جمع‌آوری داده‌ها ارائه می‌دهد. Sparkplug B یک فضای نام موضوعی تعریف شده، قالب محموله داده (با استفاده از Google Protobuf) و مکانیزم‌های مدیریت وضعیت را فراهم می‌کند که برای عملیات صنعتی ضروری است.

عوامل هوش مصنوعی، یا اجزای لبه آن‌ها، به بروکرهای MQTT مشترک می‌شوند و موضوعاتی را که می‌خواهند پیام‌ها را از آن‌ها دریافت کنند، مشخص می‌کنند. با Sparkplug B، این موضوعات به صورت سلسله‌مراتبی (به عنوان مثال، spBv1.0/group_id/node_id/device_id/DDATA) ساخته شده‌اند. اشتراک در یک موضوع DDATA (داده‌های دستگاه) برای یک دستگاه خاص به عامل اجازه می‌دهد تا تمام به‌روزرسانی‌های معیار در زمان واقعی را که توسط آن دستگاه منتشر می‌شود، دریافت کند. کارایی MQTT به این معنی است که دستگاه‌ها فقط زمانی داده‌ها را ارسال می‌کنند که مقادیر تغییر می‌کنند یا در فواصل زمانی تعریف شده، و پهنای باند شبکه را بهینه می‌کنند.

سطوح کیفیت سرویس (QoS) در MQTT برای قابلیت اطمینان حیاتی هستند. QoS 0 (حداکثر یک بار) پیام‌ها را بدون تأیید تحویل می‌دهد، که برای داده‌های غیرحساس و با فرکانس بالا مناسب است که در آن از دست رفتن گاه و بیگاه قابل قبول است. QoS 1 (حداقل یک بار) تحویل را تضمین می‌کند اما ممکن است منجر به تکرار شود، که نیاز به پردازش ایدمپوتنت توسط عامل دارد. QoS 2 (دقیقاً یک بار) یک بار تحویل را تضمین می‌کند و برای داده‌های حیاتی استفاده می‌شود که در آن از دست رفتن و تکرار هیچ یک قابل تحمل نیست، اگرچه سربار بیشتری را متحمل می‌شود. توسعه‌دهنده عامل باید سطح QoS مناسب را برای هر جریان داده بر اساس اهمیت عملیاتی آن با دقت انتخاب کند.

کلاینت MQTT یک عامل هوش مصنوعی باید محموله‌های Sparkplug B را تجزیه کند، که معمولاً پیام‌های فشرده Protobuf حاوی چندین معیار، مقادیر، برچسب‌های زمانی و فراداده هستند. کلاینت باید این پیام‌ها را Deserialize کند، نقاط داده مربوطه را استخراج کند و آن‌ها را به لایه نرمال‌سازی ارسال کند. مدیریت قوی قطع ارتباطات بروکر، پایداری جلسه، و بافر کردن پیام‌ها (برای QoS > 0) برای حفظ پیپ‌لاین‌های داده مداوم از منابع MQTT ضروری است.

دروازه‌های پروتکل و فضاهای نام یکپارچه

در بافت پیچیده ارتباطات صنعتی، دروازه‌های پروتکل نقش محوری در فعال‌سازی قابلیت همکاری بین سیستم‌های متفاوت ایفا می‌کنند. این دستگاه‌های هوشمند یا مؤلفه‌های نرم‌افزاری به عنوان مترجم عمل کرده و به داده‌ها امکان می‌دهند تا به طور یکپارچه بین دامنه‌های OPC UA، Modbus و MQTT جریان یابند. استقرار آن‌ها اغلب برای ایجاد یک فضای نام یکپارچه، که برای استقرار موفق هوش مصنوعی در کف تولید حیاتی است، مرکزی است.

یک دروازه پروتکل ممکن است، به عنوان مثال، داده‌ها را از یک شبکه Modbus RTU بخواند، آن را به متغیرهای OPC UA تبدیل کند و آن‌ها را در فضای آدرس سرور OPC UA قرار دهد. همزمان، می‌تواند به مقادیر این سرور OPC UA مشترک شود و آن‌ها را به عنوان پیام‌های MQTT Sparkplug B منتشر کند. این ترجمه دوطرفه یا چندجهته، دسترسی به داده‌ها را متمرکز کرده و جزئیات پروتکل زیربنایی را از برنامه‌های سطح بالاتر، از جمله عوامل هوش مصنوعی، انتزاع می‌کند.

مفهوم فضای نام یکپارچه بر پایه این موضوع بنا می‌شود. این مفهوم یک نمایش واحد، ثابت و از نظر معنایی غنی از تمام داده‌های عملیاتی را، صرف نظر از پروتکل اصلی آن‌ها، ایجاد می‌کند. این فضای نام معمولاً از قابلیت‌های ساختاریافته و سلسله مراتبی OPC UA یا یک مدل معنایی مشابه استفاده می‌کند. در این دیدگاه یکپارچه، قرائت یک حسگر دما از یک دستگاه Modbus قدیمی، یک حسگر فشار پیشرفته که از طریق OPC UA گزارش می‌دهد و یک شیر هوشمند که از طریق MQTT منتشر می‌کند، همگی تحت یک قرارداد نامگذاری مشترک (به عنوان مثال، PlantA/Area1/MachineX/SensorY/Temperature) قابل دسترسی خواهند بود.

اتوماسیون هوش مصنوعی در کف تولید به شدت به این دیدگاه یکپارچه متکی است. عوامل هوش مصنوعی می‌توانند نقاط داده را در این فضای نام واحد پرس‌وجو یا مشترک شوند بدون اینکه نیازی به دانستن این موضوع داشته باشند که آیا داده‌ها از پُرس‌وجوی Modbus، اشتراک‌های OPC UA یا موضوعات MQTT آمده‌اند. این امر به طور قابل توجهی توسعه عامل را ساده‌تر می‌کند و به توسعه‌دهندگان اجازه می‌دهد تا بر روی هوش و تجزیه و تحلیل تمرکز کنند تا بر روی یکپارچه‌سازی پروتکل سطح پایین. TFSF Ventures، با متدولوژی استقرار 30 روزه خود در 21 صنعت، از چنین معماری‌هایی برای اطمینان از یکپارچه‌سازی سریع و مؤثر استفاده می‌کند. معماری مدیریت استثنائات آن‌ها به طور خاص برای مدیریت پیچیدگی‌های این محیط‌های ناهمگن طراحی شده است و از یکپارچگی و قابلیت اطمینان داده‌ها اطمینان می‌دهد.

عادی‌سازی تگ و تنظیم زمان

یکی از مهمترین چالش‌ها در یکپارچه‌سازی داده‌های صنعتی ناهمگون برای عوامل هوش مصنوعی، دستیابی به نرمال‌سازی تگ منسجم و هم‌ترازی دقیق زمان است. داده‌های ورودی از منابع OPC UA، Modbus و MQTT اغلب از قواعد نام‌گذاری، انواع داده و برچسب‌های زمانی مختلف (یا فاقد آن‌ها به طور کامل) استفاده می‌کنند. بدون یک رویکرد سیستماتیک برای نرمال‌سازی و هم‌ترازی این داده‌ها، عوامل هوش مصنوعی برای برقراری روابط علّی، پیش‌بینی دقیق خطاها یا بهینه‌سازی موثر فرآیندها به مشکل برخواهند خورد.

نرمال‌سازی تگ شامل نگاشت شناسه‌های متفاوت و خاص پروتکل به یک شمای تگ مشترک و از نظر معنایی ثابت است. به عنوان مثال، یک رجیستر Modbus 'HR_40001'، یک Node ID پروتکل OPC UA 'ns=2;s=MotorTemp' و یک معیار MQTT 'Motor/Temperature' ممکن است همگی یک دمای فیزیکی را نشان دهند. لایه نرمال‌سازی این موارد را در یک تگ استاندارد شده واحد (به عنوان مثال، 'Equipment.Motor1.Temperature_C') ادغام می‌کند. این فرآیند اغلب شامل غنی‌سازی فراداده، افزودن واحدهای اندازه‌گیری، محدوده‌های مهندسی و متن است.

تنظیم زمان (Time alignment) به همان اندازه، اگر نگوییم بیشتر، حیاتی است. پروتکل OPC UA به طور ذاتی شامل برچسب‌های زمانی با تغییرات داده است. محموله‌های Sparkplug B پروتکل MQTT نیز حاوی برچسب‌های زمانی (unix epoch timestamps) هستند. با این حال، Modbus معمولاً برچسب‌های زمانی را با مقادیر رجیستر خود انتقال نمی‌دهد؛ برچسب زمانی باید در نقطه اکتساب توسط Master Modbus اعمال شود. اکتساب داده‌های ناهمزمان به این معنی است که رویدادها یا اندازه‌گیری‌های مربوط به یک فرآیند فیزیکی ممکن است خارج از ترتیب یا با اختلافات زمانی جزئی وارد شوند. عوامل هوش مصنوعی، به ویژه آنهایی که تحلیل توالی یا همبستگی را انجام می‌دهند، به داده‌های کاملاً همگام نیاز دارند.

استراتژی‌های تنظیم زمان شامل برچسب‌گذاری در سطح لبه (مانند Modbus)، همگام‌سازی ساعت محلی (به عنوان مثال، PTP یا NTP) در سراسر دستگاه‌های لبه و درون‌یابی یا مرتب‌سازی مجدد سمت سرور است. بروکرهای لبه یا تاریخ‌دانان داده اغلب در بافر کردن و هم‌ترازی جریان‌های داده قبل از ارائه آن‌ها به عوامل هوش مصنوعی نقش دارند. هدف، فراهم کردن یک مجموعه داده برای عامل هوش مصنوعی است که در آن تمام اندازه‌گیری‌های مرتبط با یک برچسب زمانی واحد و دقیق مرتبط باشند و امکان تحلیل و تصمیم‌گیری قابل اعتماد توسط سیستم هوشمند را فراهم کند.

بروکرهای لبه در مقابل جمع‌آوری ابری

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

بروکرهای لبه معمولاً بر روی رایانه‌های صنعتی (Industrial PC) یا دروازه‌ها (Gateway) که مستقیماً در کف تولید، نزدیک به منابع داده قرار دارند، مستقر می‌شوند. این بروکرها می‌توانند جمع‌آوری داده‌های محلی، تبدیل پروتکل، نرمال‌سازی و حتی پردازش اولیه داده‌ها و استنتاج هوش مصنوعی را انجام دهند. مزایای کلیدی شامل تأخیر بسیار کم برای برنامه‌های زمان واقعی (به عنوان مثال، نگهداری پیش‌بینانه که نیاز به واکنش در میلی‌ثانیه دارد)، کاهش نیاز پهنای باند شبکه (فقط داده‌های پردازش شده یا ناهنجاری‌ها به ابر ارسال می‌شوند) و افزایش امنیت با حفظ داده‌های عملیاتی حساس در محدوده شبکه محلی است. آن‌ها در مدیریت polling Modbus، اشتراک‌های OPC UA و پیام‌رسانی MQTT محلی به طور مستقیم ماهر هستند.

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

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

یک لایه ناظر که یکپارچگی کنترل را حفظ می‌کند

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

معماری لایه ناظر دیکته می‌کند که عوامل هوش مصنوعی فقط به داده‌ها از سرورهای OPC UA مشترک می‌شوند، رجیسترهای Modbus را پُرس‌وجو می‌کنند و موضوعات MQTT را مصرف می‌کنند. آن‌ها به صراحت از ارسال دستورات نوشتن، تنظیم مقادیر رجیسترها یا انتشار پیام‌های کنترل به شبکه فناوری عملیاتی (OT) منع شده‌اند. این امر اساساً سیستم هوش مصنوعی را از منطق کنترل اصلی جدا می‌کند و یک مانع ایمنی قوی ایجاد می‌کند. راهنمای استقرار هوش مصنوعی در تولید بر این تفکیک برای جلوگیری از شکست‌های فاجعه‌بار یا انحرافات ناخواسته فرآیندی تأکید می‌کند.

این الگوی معماری به این معنی است که عوامل هوش مصنوعی می‌توانند داده‌های عملیاتی را تجزیه و تحلیل کنند، ناهنجاری‌ها را شناسایی کنند، خرابی‌ها را پیش‌بینی کنند و بهینه‌سازی‌ها را پیشنهاد دهند بدون خطر تداخل مستقیم با PLC ها، سیستم‌های DCS یا سیستم‌های ابزار دقیق ایمنی. اگر یک عامل هوش مصنوعی یک مشکل حیاتی یا یک بهینه‌سازی بالقوه را شناسایی کند، باید این بینش‌ها را از طریق کانال‌های مستقل (به عنوان مثال، داشبوردها، هشدارها یا تماس‌های API به سیستم‌های سازمانی) به اپراتورهای انسانی یا سیستم‌های MES/SCADA سطح بالاتر منتقل کند، که امکان بررسی و تأیید انسانی را قبل از هرگونه اقدام کنترلی فراهم می‌کند.

با گذشت زمان، با اعتبارسنجی دقیق و مکانیزم‌های ایمن، برخی از عوامل هوش مصنوعی ممکن است به نقش‌های «مشاوره حلقه بسته» یا «بهینه‌سازی نقاط تنظیم» (Set-point Optimization) منتقل شوند، که در آن توصیه‌های آن‌ها به طور خودکار با محدودیت‌های سخت‌گیرانه و نظارت انسانی به سیستم‌های کنترل منتقل می‌شوند. با این حال، حتی در این سناریوهای پیشرفته، اصل اساسی یک واسط کنترل شده و اجازه صریح برای اقدامات کنترلی حیاتی باقی می‌ماند. اولین گام در استقرار هوش مصنوعی در کف تولید باید همیشه به یک الگوی صرفاً فقط خواندنی پایبند باشد، که اعتماد را تقویت کرده و خطر را به حداقل برساند. این یک جنبه حیاتی از نحوه استقرار عوامل هوش مصنوعی در کف یک کارخانه تولیدی به طور مسئولانه است.

تاخیر، ضمانت‌های ترتیب و داده‌های منقضی

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

تأخیر به تأخیر زمانی بین وقوع یک رویداد در کف کارخانه و دریافت و پردازش داده‌های مربوطه توسط عامل هوش مصنوعی اشاره دارد. اشتراک‌های OPC UA و مدل انتشار-اشتراک MQTT معمولاً در مقایسه با پُرس‌وجو Modbus، تأخیر کمتری ارائه می‌دهند، به خصوص هنگامی که با فواصل نمونه‌برداری و انتشار مناسب پیکربندی شوند. به حداقل رساندن تأخیر برای تشخیص ناهنجاری در زمان واقعی، نگهداری پیش‌بینانه و کنترل کیفیت، که در آن اقدام فوری می‌تواند از خرابی‌های پرهزینه یا نقص‌ها جلوگیری کند، بسیار مهم است. پردازش لبه (بروکرهای لبه) به طور قابل توجهی به کاهش تأخیر سرتاسری برای برنامه‌های حساس به زمان کمک می‌کند.

ضمانت‌های ترتیب هنگام جمع‌آوری داده‌ها از چندین منبع ناهمزمان پیچیده می‌شوند. در حالی که پروتکل‌ها ممکن است به طور جداگانه ترتیب پیام‌ها را تضمین کنند (به عنوان مثال، MQTT QoS 1 و 2)، ترتیب ورود داده‌ها در پروتکل‌های مختلف مربوط به یک فرآیند فیزیکی ذاتاً تضمین نمی‌شود. به عنوان مثال، یک قرائت دما از Modbus ممکن است دیرتر از یک سرعت جریان مرتبط از OPC UA به نقطه تجمع برسد، حتی اگر رویدادهای فیزیکی به ترتیب معکوس رخ داده باشند. تنظیم زمان و برچسب‌گذاری دقیق زمان در لبه برای بازگرداندن یک توالی رویداد صحیح برای عامل هوش مصنوعی حیاتی است.

داده‌های منقضی و جلسات قطع شده تهدیدات قابل توجهی برای قابلیت اطمینان بینش‌های هوش مصنوعی محسوب می‌شوند. اگر اتصال Modbus قطع شود، یا اشتراک OPC UA مختل شود، دیدگاه عامل از وضعیت عملیاتی ناقص یا منسوخ می‌شود. عوامل هوش مصنوعی باید با مکانیزم‌هایی برای تشخیص و مدیریت داده‌های منقضی، مانند زمان‌بندی‌های مبتنی بر برچسب زمانی، نشانگرهای «آخرین مشاهده شده» یا پرچم‌های کیفیت انتشار یافته از منابع داده (به عنوان مثال، کدهای کیفیت بد/نامعلوم OPC UA) طراحی شوند. هنگامی که جلسات قطع می‌شوند، منطق اتصال مجدد و پر کردن شکاف داده (در صورت لزوم) برای جلوگیری از تصمیم‌گیری عامل بر اساس اطلاعات ناقص یا اشتباه ضروری است. TFSF Ventures با RAKEZ License 47013955 و زیرساخت تولید خود برای مدیریت همین چالش‌ها ساخته شده است و خطوط لوله داده قوی و همیشه فعال را فراهم می‌کند. TFSF Ventures این خدمات را با هزینه‌های کم (ده‌ها هزار دلار) برای استقرارهای متمرکز، که با تعداد عوامل و پیچیدگی یکپارچه‌سازی مقیاس‌پذیر است، به علاوه 400 تا 500 دلار در ماه برای Pulse AI pass-through با حداقل سود ارائه می‌دهد. مشتریان مالک کد هستند و قیمت‌گذاری شفاف و طبقه‌بندی شده از هرگونه غافلگیری جلوگیری می‌کند.

عوامل هوش مصنوعی باید در لایه معنایی پروتکل-بی‌نیاز باشند

هدف نهایی برای اتوماسیون موفق هوش مصنوعی در کف تولید، اطمینان از این است که خود عوامل هوش مصنوعی در لایه پردازش معنایی خود کاملاً پروتکل-بی‌نیاز (protocol-agnostic) باشند. این بدین معناست که یک عامل هوش مصنوعی نباید نیاز داشته باشد 'بداند' که آیا داده‌ای را که از OPC UA، Modbus یا MQTT نشأت گرفته است، تجزیه و تحلیل می‌کند. در عوض، بر روی یک جریان داده یکپارچه، نرمال‌سازی شده و هم‌تراز با زمان که وضعیت فیزیکی فرآیند تولید را نشان می‌دهد، عمل می‌کند. این اصل اصلی برای استقرار کارآمد و مقیاس‌پذیر است.

این انتزاع از طریق لایه‌های معماری مورد بحث حاصل می‌شود: آداپتورهای پروتکل، نرمال‌سازی داده‌ها و فضاهای نام یکپارچه. بایت‌ها و ارتباطات خاص هر پروتکل توسط اجزای سطح پایین اختصاصی مدیریت می‌شوند. لایه معنایی عامل هوش مصنوعی نقاط داده تعریف شده و زمینه‌دار (به عنوان مثال، 'Motor1.Temperature', 'Pump2.FlowRate', 'Valve3.Status') را دریافت می‌کند. این امر توسعه و آموزش مدل‌های هوش مصنوعی را به طور قابل توجهی ساده می‌کند، زیرا آن‌ها می‌توانند صرفاً بر روی داده‌های عملیاتی و روابط آنها تمرکز کنند، فارغ از پیچیدگی‌های پروتکل‌های ارتباطی صنعتی. این همچنین نحوه استقرار عوامل هوش مصنوعی در کف یک کارخانه تولیدی را به میزان زیادی ساده می‌کند.

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

در اصل، عامل هوش مصنوعی به یک 'سخنگوی روان' زبان داده‌های عملیاتی کارخانه تبدیل می‌شود، نه اینکه به 'لهجه' یک پروتکل ارتباطی واحد محدود شود. این تفکیک نگرانی‌ها—مدیریت پروتکل در لبه، درک معنایی در هسته—برای ساخت راه‌حل‌های هوش مصنوعی قوی، مقیاس‌پذیر و قابل نگهداری که واقعاً می‌توانند عملیات کف کارخانه را متحول کنند، حیاتی است. ارزیابی عملیاتی 19 سؤالی TFSF Ventures به شناسایی همین نقاط یکپارچه‌سازی کمک می‌کند و راه‌حل‌ها را با نیازهای خاص مشتری تنظیم می‌کند.

درباره TFSF Ventures

TFSF Ventures FZ-LLC (RAKEZ License 47013955) یک شرکت معماری سرمایه‌گذاری است که زیرساخت عامل‌های هوشمند را در سراسر کسب‌وکارها از طریق سه ستون یکپارچه مستقر می‌کند: زیرساخت عامل‌گرایانه، مسیرهای پرداخت غیرسنتی و یک موتور کامل سرمایه‌گذاری. TFSF با 27 سال سابقه در زمینه پرداخت و نرم‌افزار، در سطح جهانی فعالیت می‌کند و به 21 صنعت با متدولوژی استقرار 30 روزه خدمات ارائه می‌دهد. برای کسب اطلاعات بیشتر به آدرس https://tfsfventures.com مراجعه کنید.

ارزیابی رایگان هوش عملیاتی را انجام دهید

ارزیابی رایگان هوش عملیاتی را انجام دهید. به چند سوال کوتاه درباره کسب‌وکار خود پاسخ دهید. یک طرح استقرار هوش مصنوعی سفارشی ظرف 24 تا 48 ساعت دریافت کنید که شامل توصیه‌های عامل، معماری و یک نقشه راه مخصوص عملیات شماست. بدون تماس فروش. بدون تعهد. فقط داده‌ها. از آدرس https://tfsfventures.com/assessment شروع کنید.

Originally published at https://tfsfventures.com/blog/deploying-ai-agents-on-a-production-floor-that-communicates-opc-ua-modbus-and-mqtt

نوشته شده توسط تیم تحقیقاتی TFSF Ventures