تصور کنید یک مهندس اتوماسیون که ساعت‌ها وقت خود را صرف نوشتن بلوک‌های تکراری کد و پیکربندی سخت‌افزار می‌کند، حالا بتواند تمام این مسیر را به یک عامل هوشمند بسپارد. این دیگر یک رویای دور نیست؛ یک عامل تخصصی به نام WorkBuddy توانست چرخه کامل مهندسی صنعتی را برای یک سیستم تفکیک کالا در PLC زیمنس S7-1500 (مدل CPU 1511-1 PN) اجرا کند.
به نقل از مستندات پروژه، این عامل تنها به تولید تکه‌های کد محدود نشد، بلکه تمام مراحل از افزودن CPU و کامپایل گرفته تا اجرای شبیه‌ساز و تایید رفتار سیستم در S7-PLCSIM را مدیریت کرد. اتوماسیون صنعتی به دلیل هزینه بالای خطا، همواره دژی نفوذناپذیر برای مهندسی دستی بوده است. در حالی که مدل‌های زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — می‌توانند کدهای ساده بنویسند، فاصله بین یک «قطعه کد» و یک پروژه کامل PLC بسیار زیاد است. این چالش دقیقاً همان جایی است که شکاف میان صحت پیاده‌سازی کد و صحت کلی سیستم در عامل‌های کدنویس نمایان می‌شود و نیاز به اعتبارسنجی‌های سخت‌گیرانه را دوچندان می‌کند.
همان‌طور که در تحلیل‌های قبلی ما درباره‌ی ابزارهای کدنویسی هوشمند اشاره کردیم، کلید موفقیت در این پروژه استفاده از TiaLink بود؛ یک سرور پروتکل زمینهٔ مدل (MCP) — شبیه به یک مترجم که درخواست‌های هوش مصنوعی را به زبان قابل‌فهم برای نرم‌افزارهای صنعتی تبدیل می‌کند — که عملیات TIA Portal V19 را از طریق Openness API در دسترس قرار می‌دهد.
معماری زنجیره ابزار
این سامانه برای تبدیل یک دستور متنی به یک PLC در حال اجرا، از یک معماری سه‌لایه استفاده می‌کند:
- عامل (WorkBuddy): یک عامل مبتنی بر LLM که مشخصات مهندسی را می‌خواند، مراحل اجرا را برنامه‌ریزی می‌کند، کد SCL می‌نویسد و مجموعه تست‌ها را طراحی می‌کند.
- پل ارتباطی (TiaLink): سرور MCP که درخواست‌های عامل را به عملیات TIA Portal ترجمه می‌کند. این بخش وظیفه افزودن تجهیزات، ایجاد بلوک‌ها، نوشتن SCL، کامپایل، دانلود و خواندن داده‌ها را بر عهده دارد.
- هدف: نرم‌افزار TIA Portal V19 به همراه Openness و S7-PLCSIM برای اعتبارسنجی. پل ارتباطی روی یک PC صنعتی در همان ماشینی که TIA Portal نصب شده اجرا می‌شود، در حالی که عامل می‌تواند از راه دور عمل کند.
پرامپت مهندسی و الزامات
طبق گزارش توسعه‌دهندگان، به عامل دستور داده شد تا یک بلوک تابع (FB) بازاستفاده‌پذیر در زبان SCL (Structured Control Language) بنویسد. الزامات سخت‌گیرانه‌ای برای این کد تعریف شده بود:
- منطق ماشین حالت: شماره حالت‌ها باید دقیقاً مطابق مشخصات باشد تا در HMI، سیستم‌های هشدار و عیب‌یابی میدانی، همگی به یک شماره‌گذاری واحد ارجاع دهند.
- طراحی ماژولار: منطق باید در قالب یک FB بازاستفاده‌پذیر با DB نمونه (Instance DB) اختصاصی باشد تا از خطاهای کپی-پیست در خطوط تولید دوم جلوگیری شود.
- تفکیک متغیرها: تمایز واضح بین ورودی‌ها (
i_)، خروجی‌ها (q_) و متغیرهای داخلی (stat_). - استانداردهای زمان‌بندی: استفاده از تایمرهای استاندارد IEC (
TON_TIME) به جای شمارش‌های دستی چرخه اسکن. - الزامات عملکردی: پیاده‌سازی حذف تکرار در ورودی (Entry De-duplication)، لچ کردن نتیجه کیفیت، اینترلاک‌های دو-سیلندری، لچ کردن خطاها، ریست دستی و توقف عادی.
- قطعیت (Determinism): هر خروجی باید در هر چرخه اسکن یک مقدار قطعی داشته باشد تا وابستگی به باقی‌مانده‌های چرخه قبلی حذف شود.
- مرزهای ایمنی: توقف اضطراری (Emergency Stop) باید فقط به عنوان یک ورودی وضعیت مدار ایمنی خوانده شود؛ کد PLC نباید به عنوان یک تابع ایمنی عمل کند.
- خروجی‌های مورد نیاز: سورس SCL بلوک FB، انواع تعریف‌شده توسط کاربر (UDTs)، سند انتقال حالت، حداقل ۱۰ مورد تست خودکار و تحلیل مرزی/مسابقه (Race Analysis).
یک آزمون کلیدی برای عامل این بود که ابتدا دستور «افزودن CPU و بررسی عملکرد شبیه‌ساز» را اجرا کند تا اطمینان حاصل شود محیط اعتبارسنجی پیش از نوشتن منطق کد، آماده است.
توالی استقرار و اجرا
یکی از مهم‌ترین یافته‌ها، منطق برنامه‌ریزی WorkBuddy بود. این عامل به جای پریدن مستقیم به سراغ کدنویسی، یک توالی سخت‌گیرانه «اول اعتبارسنجی» را دنبال کرد:
۱. بررسی محیط: ابتدا بررسی کرد که آیا CPU از قبل وجود دارد یا خیر؛ سپس PLC_1 (مدل CPU 1511-1 PN) را افزود.
۲. تست اتصال: S7-PLCSIM را کامپایل و اجرا کرد تا از صحت حلقه دانلود/اجرا پیش از نوشتن هرگونه منطقی مطمئن شود.
۳. ایجاد اشیاء: بلوک FB_ConveyorSort و انواع تعریف‌شده توسط کاربر (UDTs) لازم را ساخت.
۴. یکپارچه‌سازی: بلوک را در OB1 با یک DB نمونه اختصاصی (DB_ConveyorSort_1) فراخوانی کرد.
۵. اعتبارسنجی: پس از کامپایل و دانلود نهایی (برای تایید نبود خطا)، جدول انتقال حالت و ۱۴ مورد تست خودکار را تحویل داد.
پیاده‌سازی فنی و ماشین حالت
کد SCL تولید شده، یک ماشین حالت پیچیده را پیاده کرد. برای تضمین قطعیت، عامل تمام خروجی‌ها را در ابتدای چرخه (بخش ۰) به مقدار پیش‌فرض (مثلاً q_xConveyor := FALSE) تغییر داد و دوباره در نگاشت نهایی خروجی‌ها (بخش ۷) مقداردهی کرد.
منطق حالت‌ها به این ترتیب بود:
- ۰ (INIT): اولین اسکن؛ پاک‌سازی لچ‌ها، کدهای خطا و دستورات؛ انتقال بدون شرط به حالت ۱۰.
- ۱۰ (READY): حالت روشن شدن/ریست. انتظار برای سیگنال استارت جهت انتقال به حالت ۲۰.
- ۲۰ (FEED): اجرای نوار نقاله. مدیریت حذف تکرار ورودی و لچ کردن کیفیت. انتقال به حالت ۳۰ (در موقعیت تفکیک)، ۹۰ (تایم‌اوت) یا ۱۰۰ (توقف).
- ۳۰ (CHECK): توقف نوار و تصمیم‌گیری بر اساس نتیجه کیفیت لچ شده: OK به حالت ۵۰ و NG به حالت ۶۰.
- ۵۰ (PUSH_A): فعال‌سازی جک A برای قطعات OK. انتقال به حالت ۷۰ پس از زمان نگهداشت.
- ۶۰ (PUSH_B): فعال‌سازی جک B برای قطعات NG. انتقال به حالت ۷۰ پس از زمان نگهداشت.
- ۷۰ (RETRACT): تایید بازگشت جک‌ها. انتقال به حالت ۸۰ در صورت موفقیت یا ۹۰ در صورت تایم‌اوت.
- ۸۰ (DISCHARGE): انتظار برای خروج قطعه از سنسور نوری تفکیک قبل از بازگشت به حالت ۲۰.
- ۹۰ (FAULT): خاموش کردن تمام خروجی‌ها. نیاز به ریست و برطرف شدن شرایط خطا برای بازگشت به حالت ۱۰.
- ۱۰۰ (STOPPED): توقف عادی. خروجی‌ها خاموش، اما با سیگنال استارت قابل بازگشت به حالت ۲۰.
ساختار داده‌ها (UDTs)
برای اطمینان از بازاستفاده‌پذیری FB در چندین خط تولید، عامل دو UDT خاص ایجاد کرد:
- UDT_SortParams: شامل
SortTimeout(T#5S)،PushHold(T#800MS) وRetractTO(T#3S). - UDT_SortStatus: برای HMI و تشخیص عیب، شامل
State(حالت)،FaultCode(کد خطا)،FaultLatched(لچ خطا)،QualityNG(کیفیت نامناسب)،PartSeen(قطعه دیده شد) وInTransit(در حال انتقال).
اعتبارسنجی و موارد تست
عامل ۱۴ مورد تست خودکار را برای تایید منطق ارسال کرد. نمونه‌های کلیدی عبارتند از:
- TC-01 (Power-on init): تایید حالت ۱۰ در اولین اسکن، خروجی‌های صفر و نبود خطا.
- TC-02 (Normal start): تایید انتقال از حالت ۱۰ به ۲۰ و فعال شدن نوار نقاله.
- TC-03 (Good part sort): تایید توالی ۲۰$ \rightarrow $۳۰$ \rightarrow $۵۰$ \rightarrow $۷۰$ \rightarrow $۸۰$ \rightarrow $۲۰ با فعال شدن جک A.
- TC-04 (Bad part sort): تایید توالی ۲۰$ \rightarrow $۳۰$ \rightarrow $۶۰$ \rightarrow $۷۰$ \rightarrow $۸۰$ \rightarrow $۲۰ با فعال شدن جک B.
- TC-05 (Entry de-dup): قطعه برای ۱۰۰ اسکن در ورودی می‌ماند؛ تایید اینکه
PartSeenفقط یک‌بار لچ می‌شود. - TC-06 (Sort timeout): قطعه در ۵ ثانیه به موقعیت تفکیک نمی‌رسد؛ تایید حالت ۹۰ و خطای
16#0020. - TC-07 (Fault latch + reset): تایید نادیده گرفته شدن استارت در حالت ۹۰؛ نیاز به ریست و رفع خطا برای بازگشت به حالت ۱۰.
- TC-08 (Reset refused): تایید بی‌اثر بودن ریست در صورتی که مدار ایمنی باز باشد.
- TC-09 (Normal stop + resume): تایید توقف $ \rightarrow $ حالت ۱۰۰ (خروجی‌های ایمن) $ \rightarrow $ استارت $ \rightarrow $ حالت ۲۰.
- TC-10 (Dual-cylinder interlock): اجبار هر دو درخواست فعال‌سازی جک به ۱؛ تایید خطای
16#0010و عدم فعال شدن هیچ‌کدام. - TC-11 (Contradictory sensors): فعال کردن هم‌زمان سنسورهای باز و بسته جک A؛ تایید خطای
16#0002و حالت ۹۰. - TC-12 (Safety circuit open): تنظیم
i_xSafetyOK = 0در حالت ۲۰؛ تایید قطع فوری خروجی‌ها و لچ شدن حالت ۹۰. - TC-13 (Retract timeout): عدم بازگشت جک در ۳ ثانیه؛ تایید خطای
16#0030و حالت ۹۰. - TC-14 (Output determinism): اجرای تک‌گام برای اطمینان از عدم وجود باقی‌مانده در خروجی‌ها بین اسکن‌ها.
شناسایی شرایط مسابقه صنعتی
ارزشمندترین خروجی این پروژه، کد نبود، بلکه تحلیل عامل از حالت‌های شکست بود. WorkBuddy چندین شرایط مسابقه (Race Condition) را شناسایی کرد:
- حذف تکرار ورودی: اشاره کرد که لچ کردن تا خروج قطعه از سنسور، از تحریک مضاعف جلوگیری می‌کند، اما تنها در صورتی که فاصله قطعات تضمین شده باشد؛ در غیر این صورت، قطعات بعدی نادیده گرفته می‌شوند.
- لچ کیفیت: عامل تصمیم گرفت نتایج کیفیت را در نقطه ورود لچ کند تا از رقابت با سیگنال موقعیت جلوگیری شود و پیشنهاد داد در صورت کند بودن تشخیص، از یک صف/دست‌دادن (Handshake) استفاده شود.
- رسیدن در برابر تایم‌اوت: صراحتاً بررسی رسیدن قطعه را پیش از بررسی تایم‌اوت قرار داد تا در یک اسکن واحد، «رسیدن» برنده شود، زیرا تایمرهای IEC TON در همان اسکنی که به PT می‌رسند، Q را TRUE می‌کنند.
- حالت تخلیه: حالت ۸۰ را پیاده کرد تا منتظر خروج قطعه از سنسور نوری بماند و از تفکیک مجدد یک قطعه پس از ضربه جلوگیری کند.
- لایه اینترلاک: هشدار داد که اینترلاک‌های نرم‌افزاری فقط «درخواست‌های منطقاً هم‌زمان» را متوقف می‌کنند و جایگزین اینترلاک‌های سخت‌افزاری پنوماتیک/الکتریکی نمی‌شوند.
- اولویت دکمه‌ها: یک سلسله‌مراتب اولویت تعریف کرد: خطا/ایمنی $>$ توقف $>$ ریست $>$ استارت.
- مرز PT = 0: اشاره کرد که اگر زمان پیش‌فرض تایمر (PT) از طریق HMI صفر شود، TON فوراً فعال شده و باعث خطاهای تضمینی می‌شود.
- رفتار ریست: از لبه‌زن (Edge-triggering) برای دکمه ریست استفاده کرد تا فشار طولانی دکمه، خطاهای تکرار شونده را نپوشاند.
- مقداردهی اولیه: حالت ۰ را برای Init حفظ کرد تا قابل مشاهده و تست باشد، هرچند اشاره کرد که در پروژه‌های تولیدی از OB100 نیز استفاده می‌شود.
- مدیریت نمونه‌ها: هشدار داد که تایمرها و حافظه‌های لبه در متغیرهای stat بلوک FB هستند، بنابراین یک DB نمونه هرگز نباید بین چندین خط به اشتراک گذاشته شود.
خط قرمزهای ایمنی
مهم‌ترین بخش این آزمایش، مواردی بود که هوش مصنوعی از انجام آن‌ها امتناع کرد. عامل صراحتاً از پیاده‌سازی سه تابع حیاتی خودداری کرد و آن‌ها را به مهندس انسان بازگرداند:
۱. توقف اضطراری: تاکید کرد که E-stops باید توسط یک مدار ایمنی سخت‌افزاری (رله ایمنی یا PLC ایمنی) اجرا شوند. برنامه فقط i_xSafetyOK را می‌خواند.
۲. اینترلاک‌های سخت: هشدار داد که اینترلاک سخت دو-سیلندری باید پنوماتیک یا الکتریکی باشد؛ نسخه نرم‌افزاری صرفاً مکمل است.
۳. تنظیمات میدانی: هشدار داد که موفقیت در شبیه‌ساز به معنای آمادگی برای محیط واقعی نیست، زیرا S7-PLCSIM نمی‌تواند تأخیرهای پنوماتیکی، لرزش سنسورها (Chatter) یا زمان پاسخ مدار ایمنی را مدل کند.
این مرزبندی نشان می‌دهد که قابل‌اعتمادترین عامل‌ها، آن‌هایی هستند که می‌دانند توانایی اعتبارسنجی آن‌ها کجا تمام می‌شود و ریسک فیزیکی کجا آغاز می‌گردد. این رویکرد یادآور تجربه‌ای است که در تحلیل ما درباره چگونه یک عامل هوش مصنوعی یک خطای زیرساختی بحرانی را پیش از وقوع شناسایی کرد بررسی شد، جایی که تشخیص محدودیت‌های مدل، مانع از یک فاجعه شد. برای مهندسان، این یعنی AI می‌تواند کارهای تکراری ماشین حالت و ایجاد UDT را انجام دهد، اما تایید نهایی ایمنی یک الزام انسانی باقی می‌ماند. توانایی یک عامل در گفتن «من نمی‌توانم این را تایید کنم» ارزشمندتر از مدلی است که با اعتمادبه‌نفس یک حلقه ایمنی خطرناک تولید می‌کند.
ملاحظات نهایی
باید توجه داشت که پاس شدن در شبیه‌ساز به معنای آماده بودن سیستم برای محیط صنعتی نیست. اعتبارسنجی انجام شده تنها تایید کرد که کد کامپایل و دانلود می‌شود و با موارد تست منطقی مطابقت دارد؛ هیچ تست روی سخت‌افزار واقعی انجام نشد. علاوه بر این، گزارش‌های خود-ارزیابی مدل در لاگ مراحل باید با شکاکیت استاندارد بررسی شوند.
برای مشاهده این فرآیند در عمل، می‌توانید سورس کامل کد و لاگ گام‌به‌گام عامل را در مستندات اصلی پروژه در پلتفرم 汇智网 (WorkBuddy) بررسی کنید.
گام بعدی شما
- اگر از TIA Portal استفاده می‌کنید، پروتکل MCP را برای اتصال مدل‌های زبانی به محیط مهندسی بررسی کنید.
- در طراحی سیستم‌های عامل‌محور، برای توابع ایمنی (Safety) هرگز به کد تولید شده توسط AI تکیه نکنید و لایه سخت‌افزاری را حفظ کنید.
- برای کاهش خطاهای منطقی، از متد «تست‌های خودکار» (Automated Test Cases) که توسط عامل طراحی شده، برای اعتبارسنجی کدها استفاده کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو