ToolboxST نرم‌افزار اصلی ایستگاه کاری مهندسی در مجموعه GE Vernova ControlST است که برای سیستم کنترل توربین Mark VIe طراحی شده است. این نرم‌افزار مجموعه‌ای از وظایف را انجام می‌دهد، از جمله پیکربندی سیستم، عیب‌یابی، دانلود آنلاین و بازیابی داده‌ها. برای مهندسان کنترل، تسلط بر ToolboxST تفاوت میان صرفاً مشاهده یک آلارم و توانایی ردیابی سیستماتیک علت ریشه‌ای است—حرکت در توپولوژی IONet، ارزیابی وضعیت سلامت بسته‌های I/O و بررسی سوابق پیکربندی. بینش‌ها و تحلیل‌های ارائه‌شده در این مقاله تنها برای مرجع هستند. لطفاً توجه داشته باشید که این اطلاعات برای راهنمایی ارائه شده است؛ برای پشتیبانی فنی خاص، با یک مهندس حرفه‌ای واجد صلاحیت مشورت کنید.

جایگاه ToolboxST و مسیرهای اتصال

ToolboxST یک ابزار عیب‌یابی جدا نیست؛ بلکه به‌عنوان دروازه‌ای مهندسی عمل می‌کند که در همان زیست‌بوم نرم‌افزاری کنترل‌کننده‌های Mark VIe، بسته‌های I/O و سرور آلارم WorkstationST یکپارچه شده است. رابط کاربری آن حول دو سطح اصلی ساختار یافته است: System Editor و Component Editor. System Editor دستگاه‌ها و توپولوژی شبکه کل سیستم را مدیریت می‌کند، در حالی که دوبار کلیک روی یک کنترل‌کننده، Component Editor را باز می‌کند؛ در آنجا زبانه «Hardware» نمای درختی از بسته‌های I/O، بردهای ترمینال و پیکربندی‌های افزونگی ارائه می‌دهد. رابط کاربری بر سه مؤلفه کلیدی استوار است: Tree View (برای پیمایش سلسله‌مراتب مؤلفه‌ها)، Property Editor (برای ویرایش پارامترهای اشیای انتخاب‌شده) و Summary View (که نمایش گرافیکی اتصال شبکه را ارائه می‌دهد).

روش ترجیحی برای اتصال به سیستم Mark VIe از طریق Ethernet است. ایستگاه کاری باید روی زیرشبکه‌ای همسان با کنترل‌کننده پیکربندی شود. در ToolboxST، به مسیر Controller → Communication → Connect بروید، «Ethernet» را انتخاب کنید و آدرس IP و پورت مناسب را برای ایجاد اتصال آنلاین وارد کنید. اگر Ethernet در دسترس نباشد، اتصال سریال RS-232 می‌تواند به‌عنوان جایگزین استفاده شود، با تنظیمات زیر: 9600 baud، 8 data bits، بدون parity، 1 stop bit و بدون flow control. لازم به ذکر است که اتصال‌های سریال عموماً فقط برای پیکربندی اولیه IP یا دسترسی اضطراری در نظر گرفته شده‌اند؛ پس از ایجاد آدرس IP، همه وظایف پیکربندی و عیب‌یابی بعدی باید از طریق Ethernet انجام شوند. تفسیر لایه‌ای اطلاعات عیب‌یابی

خروجی عیب‌یابی در ToolboxST صرفاً یک فهرست تخت از آلارم‌ها نیست؛ بلکه یک سیستم اطلاعاتی ساختاریافته است که در سه سطح سازماندهی شده است: I/O Pack، Module و Component. «I/O Diagnostic Viewer» — قابل دسترسی از طریق زبانه «Summary» — نقطه ورود اصلی عیب‌یابی است. با کلیک راست روی یک بسته I/O یا برد ترمینال و انتخاب «Troubleshoot and Status»، کاربران می‌توانند گزارش‌های خطا، اطلاعات نسخه و داده‌های ارتباطی عیب‌یابی مربوط به آن واحد خاص را مشاهده کنند. نمادها در نمای درختی معانی مشخصی دارند: قرمز نشان‌دهنده یک ناهنجاری پیوند است، زرد به معنای آلارم فعال است، یک آیکون اطلاعاتی نشان‌دهنده آلارم غیرفعال است، و نبود هرگونه نشانگر از این نوع بیانگر وضعیت عادی است. نگه‌داشتن نشانگر روی یک مورد توضیحات تفصیلی را نمایش می‌دهد—ویژگی‌ای که به‌ویژه هنگام عیب‌یابی در محل بسیار مفید است.

گزارش‌های عیب‌یابی منبعی هستند که غالباً دست‌کم گرفته می‌شوند. ToolboxST می‌تواند چهار نوع گزارش تولید کند—I/O Module Fault Report، Revision Report، Communication Report و Hardware Report—که هر یک شامل جزئیات پیکربندی یا عیب‌یابی مختص ماژول‌های مربوطه است. هنگام تعویض ماژول‌ها یا مقایسه نسخه‌ها، گزارش‌های Revision و Hardware بسیار ارزشمندتر از بررسی دستی آلارم‌ها صفحه‌به‌صفحه هستند. علاوه بر این، عملکرد «Compare Parameters» به کاربران اجازه می‌دهد تا پیش از دانلود پارامترهای جدید، مقایسه‌ای سلسله‌مراتبی بین پیکربندی ذخیره‌شده کنونی در کنترل‌کننده و مقادیر تعریف‌شده در پروژه ToolboxST انجام دهند. این امر برای جلوگیری از «اثرات موجی» حیاتی است، جایی که تغییر یک پارامتر به‌طور ناخواسته طیف گسترده‌تری از منطق را تغییر می‌دهد.

یک تمایز مهم در عیب‌یابی که باید به آن توجه کرد این است که عیب‌یابی‌های مرتبط با ارتباط که خود ToolboxST تولید می‌کند (مانند «unhealthy link» یا «cannot retrieve diagnostics information») به WorkstationST Alarm Viewer گزارش داده نمی‌شوند. در نتیجه، اگر HMI اپراتور عادی به نظر برسد اما ToolboxST نشان دهد که یک بسته I/O قطع شده است، علت ریشه‌ای احتمالاً در لایه اتصال مهندسی قرار دارد—برای مثال، ممکن است بسته I/O راه‌اندازی خود را کامل نکرده باشد، یک فایل پیکربندی مفقود باشد، در پیکربندی دو شبکه‌ای تنها یک شبکه متصل باشد، بارکد برد ترمینال به اشتباه وارد شده باشد، یا پیکربندی هنوز به کنترل‌کننده دانلود نشده باشد. هنگام عیب‌یابی چنین مسائلی، ابتدا باید ارتباط بین ToolboxST و کنترل‌کننده را بررسی کرد و سپس به‌طور سیستماتیک تأیید کرد که پیکربندی سخت‌افزار با نصب فیزیکی واقعی مطابقت دارد.

تعویض ماژول: پیش‌نیازهای ایمنی ضروری در ToolboxST

اگرچه بسته‌های I/O مدل Mark VIe از «hot-swapping» پشتیبانی می‌کنند، این قابلیت به این معنا نیست که می‌توان آن‌ها را در هر زمان و بدون رعایت رویه‌های صحیح خارج یا وارد کرد. پیش از اقدام به یک ماژول فیزیکی، دو بررسی باید در ToolboxST انجام شود. نخست، سلامت شبکه حلقه‌ای IONet را با رفتن به مسیر Device → Component → IONet Status بررسی کنید. همه گره‌ها باید وضعیت سبز داشته باشند و هر دو پورت «Link Up» را نشان دهند، شمارنده خطای فریم باید کمتر از ۱۰۰ فریم در دقیقه باشد و همه کنترل‌کننده‌های UCVE باید «In Sync» باشند. وضعیت حلقه زرد نشان می‌دهد که افزونگی از دست رفته است؛ تعویض ماژول در این شرایط سیستم را در معرض خطر خرابی تک‌نقطه‌ای قرار می‌دهد. دوم، از عملکرد «Force I/O to last value» در ToolboxST برای ثابت نگه‌داشتن خروجی‌ها استفاده کنید تا از نوسانات سیگنال در طول جداسازی جلوگیری شود؛ نوساناتی که در غیر این صورت می‌توانند اقدامات حفاظتی را فعال کنند.

پس از برآورده شدن این پیش‌نیازها، فرایند تعویض نسبتاً ساده است: گره معیوب را خارج کنید، واحد جایگزین را وارد کنید، پیکربندی را دانلود کنید تا آدرس MAC جدید ثبت شود، و در نهایت بررسی کنید که قرائت‌های زمان واقعی در محدوده ±۱٪ از مقادیر واقعی فرایند باشند. اگرچه IONet ظرف حدود ۲۰۰ میلی‌ثانیه پس از حذف یک ماژول به‌طور خودکار مسیرها را تغییر می‌دهد، این موضوع ضرورت تأیید بازیابی شبکه حلقه‌ای را از بین نمی‌برد. پس از تعویض، باید دوباره IONet Status را بررسی کنید تا اطمینان یابید یکپارچگی شبکه حلقه‌ای بازیابی شده است؛ در غیر این صورت، سیستم همچنان بدون افزونگی کار خواهد کرد. برای کانال‌های مرتبط با ارتعاش، کانال‌های تحت تأثیر نیز باید پیش از تعویض از طریق رابط رک Bently Nevada 3500 در حالت «bypass» قرار گیرند و حفاظت تنها پس از تأیید سیگنال‌ها باید بازیابی شود.

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

در ToolboxST، «backup» صرفاً یک عملیات تک‌دکمه‌ای نیست؛ بلکه یک راهبرد حفظ داده است که شامل سه فرایند متمایز می‌شود: upload، download و controller replication. «upload» داده‌های پیکربندی را از کنترل‌کننده به ایستگاه کاری منتقل می‌کند، در حالی که «download» داده‌های پیکربندی اصلاح‌شده را در کنترل‌کننده می‌نویسد. هر دو عملیات به یک پیوند ارتباطی عملیاتی و سازگاری نسخه نیاز دارند. علاوه بر این، پیش از download، سیستم باید در وضعیت «IDLE» یا «CGG» باشد—هرگز در حالت «RUN» یا «SEQ» نباشد. از آنجا که download کل پیکربندی کنترل‌کننده را بازنویسی می‌کند و یک پیکربندی نادرست می‌تواند به پیامدهای شدیدی—مانند سرعت بیش از حد توربین—منجر شود، تأیید پشتیبان پیش از download اجباری است، نه اختیاری.

فایل «.m6b» به‌عنوان محفظه اصلی پیکربندی‌های مهندسی در ToolboxST عمل می‌کند. وقتی عدم تطابق نسخه بین چند ایستگاه کاری و یک کنترل‌کننده رخ می‌دهد، روش توصیه‌شده برای بازگرداندن سازگاری، استفاده از فایل «.m6b» یک ایستگاه کاری با وضعیت «Equal» به‌عنوان مرجع است. فایل‌های ناسازگار روی سایر ایستگاه‌های کاری را با این فایل مرجع جایگزین کنید، سپس دوباره متصل شوید و وضعیت را بررسی کنید. بازیابی پس از خرابی سخت‌افزار کنترل‌کننده شامل تعویض UCSB (Universal Controller System Base) و اجرای رویه backup/restore است: در صورت امکان، از NAND flash اصلی UCSB پشتیبان تهیه کنید، سخت‌افزار را تعویض کنید و از ToolboxST برای بازیابی پیکربندی کنترل‌شده استفاده کنید. ممکن است یک download متعاقب لازم باشد تا کنترل‌کننده به وضعیت کنترل فعال بازگردد. Controller Setup Wizard نیز می‌تواند فرایند بازیابی را راهنمایی کند؛ با این حال، آماده‌سازی رسانه بازیابی و تفسیر نشانگرهای وضعیت (چراغ سبز ثابت نشان‌دهنده بازیابی در حال انجام است، در حالی که چراغ سبز چشمک‌زن نشان‌دهنده خرابی است) باید به‌طور دقیق با مراحل تعویض سخت‌افزار هماهنگ شود.

س: اگر ToolboxST در اتصال به کنترل‌کننده Mark VIe ناموفق باشد، ابتدا چه چیزی باید بررسی شود؟

پیش از تلاش‌های مکرر برای اتصال از طریق نرم‌افزار، لایه فیزیکی و پارامترهای شبکه را بررسی کنید. بررسی کنید که آیا آدرس‌های IP ایستگاه کاری و کنترل‌کننده در یک زیرشبکه قرار دارند، اطمینان حاصل کنید که فایروال ترافیک روی پورت TCP 18245 را مجاز می‌کند، و تأیید کنید که کابل‌های Ethernet و پورت‌های سوئیچ به‌درستی کار می‌کنند—این سه بررسی اکثر سناریوهای شکست اتصال را پوشش می‌دهند. اگر دستگاه کاملاً از طریق Ethernet قابل دسترسی نباشد، می‌توانید پیکربندی اولیه IP را با استفاده از پورت سریال COM1 و یک آداپتور RJ45-to-DB9 انجام دهید، سپس دوباره به Ethernet برگردید. اگر هنوز پس از برقراری اتصال نمی‌توانید اطلاعات عیب‌یابی را دریافت کنید، بررسی کنید که Type، HW Form، Bar Code و مکان فیزیکی در پیکربندی بسته I/O با سخت‌افزار واقعی مطابقت داشته باشند؛ در صورت لزوم، یک «Build» انجام دهید و پارامترها را به بسته I/O دانلود کنید.

س: آیا می‌توان از ToolboxST برای عیب‌یابی بدون قرار داشتن در وضعیت «online» استفاده کرد؟

برخی وظایف را می‌توان به‌صورت offline انجام داد، اما عملکردهای اصلی عیب‌یابی نیازمند اتصال online هستند. برای نمونه، I/O Diagnostic Viewer به‌طور صریح برای نمایش داده‌های عیب‌یابی زمان واقعی به اتصال online نیاز دارد، در حالی که عملکردهای گزارش‌گیری انعطاف‌پذیرتر هستند. در وضعیت offline، ToolboxST عمدتاً برای مرور پیکربندی مفید است—مانند بررسی اینکه توپولوژی IONet، پارامترهای ماژول، تنظیمات افزونگی و پیکربندی‌های EGD با انتظارات هماهنگ هستند—یا برای استفاده از ویژگی «Compare Parameters» جهت مقایسه پیکربندی پروژه فعلی با یک پشتیبان شناخته‌شده و تأییدشده. با این حال، «عیب‌یابی واقعی خطا»—مانند ارزیابی سلامت پیوندهای بسته I/O، خواندن وضعیت آلارم فعلی ماژول‌ها، یا تأیید اینکه آیا کنترل‌کننده «In Sync» است—تنها پس از برقراری اتصال online قابل انجام است. بنابراین، رویه استاندارد برای عیب‌یابی میدانی باید ابتدا بازگرداندن ارتباط بین ToolboxST و کنترل‌کننده و سپس دسترسی به عملکردهای عیب‌یابی باشد، نه تلاش برای استنباط وضعیت سخت‌افزار هنگام کار در یک پروژه offline.