مدرن‌سازی رابط‌های کاربری انسان‌ـ‌ماشین Bailey INFI 90 Symphony اجراشده روی OpenVMS Alpha

نوسازی HMI بدون جایگزینی کل سیستم INFI 90

بسیاری از سیستم‌های Bailey INFI 90 دهه‌ها پس از نصب اولیه همچنان با اطمینان کار می‌کنند. کنترلرها، ماژول‌های ارتباطی، واحدهای ترمینیشن و I/O میدانی آن‌ها ممکن است هنوز وظایف کنترلی موردنیاز را انجام دهند.

فوری‌ترین مشکل چرخه عمر، اغلب در لایه بالاتر از کنترلر قرار دارد.

ایستگاه‌های اپراتور ممکن است به سخت‌افزار قدیمی AlphaStation، آداپتورهای گرافیکی پشتیبانی‌نشده، تجهیزات ذخیره‌سازی منسوخ و محیط‌های نرم‌افزاری قدیمی OpenVMS Alpha وابسته باشند. تهیه قطعات جایگزین دشوار می‌شود و مهندسان باتجربه OpenVMS و Bailey Symphony نیز کمتر در دسترس هستند.

مثال بررسی‌شده در اینجا شامل چهار ایستگاه کاری AlphaStation 255 است. هر ایستگاه OpenVMS Alpha را اجرا می‌کند و میزبان عملکردهای رابط اپراتور Bailey Symphony برای یک سیستم کنترل توزیع‌شده Bailey INFI 90 است.

هدف لزوماً جایگزینی کل DCS نیست. هدف عملی‌تر می‌تواند حذف وابستگی به سخت‌افزار قدیمی AlphaStation و درعین‌حال حفظ کنترلرهای پایدار، سیم‌کشی میدانی، ماژول‌های I/O، منطق کنترل و عملیات فرایند باشد.

این تمایز، راهبرد نوسازی را تغییر می‌دهد.

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

چندین مسیر برای نوسازی وجود دارد. بااین‌حال، هرکدام بخش‌های متفاوتی از سیستم موجود را حفظ می‌کنند.

شبیه‌ساز Alpha می‌تواند تقریباً کل محیط نرم‌افزاری را حفظ کند. مهاجرت OpenVMS به x86 خانواده سیستم‌عامل را حفظ می‌کند، اما به مهاجرت برنامه‌های کاربردی نیاز دارد. جایگزینی HMI مبتنی بر OPC، لایه کنترلر را حفظ می‌کند و درعین‌حال رابط اپراتور را از نو می‌سازد. راهبرد تکامل ABB می‌تواند معماری گسترده‌تر Symphony را به‌صورت مرحله‌ای نوسازی کند.

هیچ مسیری نباید به‌عنوان جایگزینی ساده برای رایانه شخصی توصیف شود.

شکل ۱. سه مسیر اصلی نوسازی می‌توانند بخش‌های متفاوتی از سرمایه‌گذاری نصب‌شده روی Bailey INFI 90 و Symphony را حفظ کنند.

چرا کلون‌سازی دیسک AlphaStation کافی نیست

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

بااین‌حال، کلون‌سازی دیسک، نرم‌افزار Alpha را به نرم‌افزار x86 تبدیل نمی‌کند.

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

یک رایانه شخصی مدرن استاندارد از پردازنده x86-64 استفاده می‌کند. این رایانه همچنین کنترلرهای ذخیره‌سازی، دستگاه‌های شبکه، ساختارهای وقفه، سخت‌افزار گرافیکی، رابط‌های سفت‌افزار و گذرگاه‌های تجهیزات جانبی متفاوتی ارائه می‌دهد.

VMware، VirtualBox، Hyper-V و هایپروایزرهای متعارف x86، سخت‌افزار سازگار با x86 را مجازی‌سازی می‌کنند. آن‌ها معمولاً دستورهای پردازنده Alpha را به دستورهای x86 ترجمه نمی‌کنند.

بنابراین، قرار دادن یک تصویر دیسک OpenVMS Alpha درون یک ماشین مجازی معمولی x86، آن تصویر را قابل بوت نمی‌کند.

ماشین مجازی ممکن است دیسک مجازی، آداپتور شبکه مجازی و دستگاه گرافیکی مجازی ارائه دهد. OpenVMS Alpha همچنان انتظار یک پردازنده Alpha و دستگاه‌های پشتیبانی‌شده مربوط به دوران Alpha را دارد.

به همین دلیل، این دو مفهوم باید از هم جدا بمانند:

مجازی‌سازی معمولاً سخت‌افزار مجازی را با استفاده از همان معماری پردازنده میزبان ارائه می‌دهد.

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

وقتی فایل‌های دودویی Alpha و سیستم‌عامل اصلی باید بدون تغییر باقی بمانند، OpenVMS Alpha به رویکرد دوم نیاز دارد.

بنابراین، کلون‌سازی دیسک فقط در سه وضعیت محدود عملی است.

راه اول، بازیابی روی همان مدل AlphaStation، با فضای ذخیره‌سازی و تجهیزات جانبی سازگار است.

راه دوم، بازیابی روی یک سیستم Alpha پشتیبانی‌شده دیگر، پس از تکمیل تغییرات لازم در دستگاه‌ها و پیکربندی است.

راه سوم، بازیابی در یک شبیه‌ساز Alpha است که محیطی سازگار با AlphaServer یا AlphaStation را بازتولید می‌کند.

شبیه‌سازی صرف به‌تنهایی مشکل معماری را حل نمی‌کند. محیط مقصد همچنان باید بتواند دستورهای ماشین Alpha را درک و اجرا کند.

شبیه‌سازی Alpha بیشترین بخش سرمایه‌گذاری موجود را حفظ می‌کند

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

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

محصولاتی مانند CHARON-AXP برای همین منظور طراحی شده‌اند. شبیه‌ساز، پردازنده فیزیکی Alpha، معماری حافظه، کنترلرهای ذخیره‌سازی، آداپتورهای اترنت و سایر دستگاه‌های پشتیبانی‌شده را با معادل‌های تعریف‌شده توسط نرم‌افزار جایگزین می‌کند.

سرور x86، ویندوز یا لینوکس را به‌عنوان محیط میزبان اجرا می‌کند. شبیه‌ساز Alpha روی آن میزبان اجرا می‌شود. سپس OpenVMS Alpha داخل سیستم Alpha شبیه‌سازی‌شده اجرا می‌شود.

این رویکرد با انتقال OpenVMS به x86 متفاوت است.

نصب اصلی OpenVMS Alpha همچنان یک نصب Alpha باقی می‌ماند. فایل‌های دودویی Bailey Symphony همچنان فایل‌های دودویی Alpha خواهند بود. شبیه‌ساز، رفتار سخت‌افزاری موردنیاز Alpha را ترجمه یا بازتولید می‌کند.

این موارد را می‌توان حفظ کرد:

• سیستم‌عامل OpenVMS Alpha نصب‌شده.

• برنامه‌های موجود Bailey Symphony.

• گرافیک‌های اپراتور و پایگاه‌های داده نمایشگر.

• پیکربندی‌های هشدار و فایل‌های تاریخی.

• حساب‌های کاربری و رویه‌های فرمان.

• ابزارهای کاربردی موجود و ویژه سایت.

• رابط‌های برنامه که به محیط Alpha وابسته‌اند.

• گردش‌کارهای اپراتوری که در غیر این صورت به آموزش مجدد نیاز داشتند.

مهاجرت عملی معمولاً شامل ایجاد یک تصویر تأییدشده یا پشتیبان از دیسک‌های Alpha اصلی است. این داده‌ها در محفظه‌های دیسک مجازی مورد استفاده شبیه‌ساز بازیابی می‌شوند.

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

شبیه‌سازی Alpha می‌تواند وابستگی به سخت‌افزار فیزیکی منسوخ را به میزان چشمگیری کاهش دهد. همچنین می‌تواند پشتیبان‌گیری را ساده‌تر کند، زیرا فایل‌های دیسک مجازی را می‌توان با استفاده از زیرساخت‌های نوین ذخیره‌سازی کپی کرد.

بااین‌حال، باید از عبارت «بدون تغییر» با احتیاط استفاده کرد.

کد برنامه ممکن است بدون تغییر باقی بماند، اما محیط همچنان به مهندسی نیاز دارد. نگاشت دستگاه‌ها باید بررسی شود. رابط‌های شبکه باید پیکربندی شوند. مجوزهای OpenVMS و مجوزهای برنامه باید بازبینی شوند.

شبیه‌ساز همچنین باید با رابط ارتباطی Bailey مورد استفاده در سایت آزمایش شود.

ممکن است یک برنامه عمومی OpenVMS به‌درستی کار کند، اما یک رابط تخصصی DCS به دلیل وابستگی به آداپتور شبکه، رابط گذرگاه، دستگاه سریال یا رفتار زمانی خاصی از کار بیفتد.

بنابراین، پیکربندی دقیق AlphaStation 255 باید پیش از انتخاب نمایه شبیه‌ساز ثبت و بررسی شود.

رابط ارتباطی Bailey، آزمون حیاتی شبیه‌سازی است

مهم‌ترین پرسش درباره شبیه‌سازی این نیست که آیا OpenVMS به اعلان ورود می‌رسد یا خیر.

پرسش مهم این است که آیا ایستگاه شبیه‌سازی‌شده در شرایط کامل بهره‌برداری، به‌درستی با سیستم Bailey INFI 90 ارتباط برقرار می‌کند یا خیر.

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

پیش از تصمیم‌گیری برای استفاده از شبیه‌سازی Alpha، مهندسان باید موارد زیر را مستندسازی کنند:

• رابط فیزیکی شبکه نصب‌شده در هر AlphaStation.

• پروتکل ارتباطی مورد استفاده بین Symphony و INFI 90.

• نام دستگاه‌های اختصاص‌یافته در OpenVMS.

• نشانی‌های شبکه و تعریف گره‌ها.

• سرویس‌های موردنیاز DECnet، TCP/IP، LAT یا سرویس‌های اختصاصی.

• تنظیمات درگاه سریال، در صورت کاربرد.

• هرگونه کلید مجوز خارجی یا دانگل سخت‌افزاری.

• رفتار افزونگی و جابه‌جایی در حالت خرابی بین ایستگاه‌های اپراتوری.

• الزامات همگام‌سازی زمانی.

• قابلیت‌های گرافیکی و صفحه‌کلید مورد استفاده اپراتورها.

ممکن است تأمین‌کننده شبیه‌ساز از دستگاه‌های رایج اترنت و ذخیره‌سازی Alpha پشتیبانی کند. اما این موضوع به‌طور خودکار پشتیبانی از همه رابط‌های اختصاصی Bailey را تأیید نمی‌کند.

اگر HMI موجود به یک آداپتور فیزیکی تخصصی وابسته باشد که امکان مجازی‌سازی آن وجود ندارد، مسیر استفاده از شبیه‌ساز ممکن است به یک درگاه ارتباطی جایگزین نیاز داشته باشد.

بنابراین پروژه باید شامل یک آزمایش روی میز با استفاده از یک ایستگاه کلون‌شده و دسترسی به شبکه‌ای نماینده از Bailey باشد.

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

عملکرد باید هنگام جهش‌های هشدار و فعالیت زیاد در به‌روزرسانی تگ‌ها نیز آزمایش شود.

OpenVMS x86-64 مسیر مهاجرت متفاوتی است

OpenVMS مدرن برای معماری x86-64 در دسترس است. این سیستم می‌تواند در محیط‌های مجازی‌سازی‌شده پشتیبانی‌شده روی سرورهای مدرن فعالیت کند.

این موضوع یک گزینه مهاجرت اضافی ایجاد می‌کند که در بسیاری از بحث‌های قبلی درباره نوسازی INFI 90 در دسترس نبود.

بااین‌حال، OpenVMS x86-64 باینری‌های OpenVMS Alpha را مستقیماً، گویی برنامه‌های بومی x86 هستند، اجرا نمی‌کند.

محیط برنامه کاربردی باید مهاجرت داده شود.

ممکن است لازم باشد کد منبع برای x86-64 منتقل، بررسی، دوباره کامپایل، پیوند و آزمایش شود. کتابخانه‌های شخص ثالث و محصولات لایه‌ای نیز باید برای نسخه مقصد در دسترس باشند.

پرسش اصلی این است که آیا نرم‌افزار نصب‌شده Bailey Symphony نسخه‌ای سازگار با x86 برای OpenVMS دارد یا خیر.

اگر فروشنده نرم‌افزار هرگز آن برنامه را برای OpenVMS x86-64 عرضه نکرده باشد، انتقال صرفِ سیستم‌عامل، HMI را حفظ نمی‌کند.

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

این مسیر ممکن است همچنان برای سرورهای داده سفارشی، تاریخچه‌نگارها، ابزارهای کاربردی، گزارش‌ها و برنامه‌های یکپارچه‌سازی که در کنار HMI سامفونی اجرا می‌شوند، عملی باشد.

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

ارزیابی مهاجرت OpenVMS به x86 باید موارد زیر را شناسایی کند:

• هر فایل اجرایی نصب‌شده و هر محصول لایه‌ای.

• کد منبع و رویه‌های ساخت موجود.

• وابستگی‌های کامپایلر و زمان اجرا.

• محصولات پایگاه داده و قالب‌های فایل.

• کتابخانه‌های ارتباطی اختصاصی.

• وابستگی‌های گرافیکی یا وابستگی به سیستم پنجره‌ای.

• در دسترس بودن مجوز برای x86-64.

• تغییرات لازم ناشی از تفاوت‌های معماری.

• فرضیات مربوط به عملکرد و زمان‌بندی.

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

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

چرا مهاجرت به ایتانیوم معمولاً گزینه‌ای موقت است

OpenVMS همچنین برای سرورهای HPE Integrity با استفاده از معماری ایتانیوم عرضه شد.

ابزارهای مهاجرت و روش‌های مهندسی برای انتقال برخی برنامه‌های آلفا به OpenVMS Integrity وجود دارد. این مسیر زمانی راهی پشتیبانی‌شده برای فاصله گرفتن از سخت‌افزارهای قدیمی آلفا فراهم می‌کرد.

بااین‌حال، امروزه سخت‌افزار ایتانیوم خود یک پلتفرم قدیمی است.

مهاجرت از Alpha به Integrity ممکن است یک وابستگی سخت‌افزاری منسوخ را حذف کند و وابستگی دیگری ایجاد نماید. سرورهای مناسب، قطعات، رابط‌های ذخیره‌سازی و تخصص کارشناسی همچنان کمتر در دسترس خواهند بود.

Itanium همچنان می‌تواند زمانی مرتبط باشد که سایت از پیش زیرساخت Integrity پشتیبانی‌شده داشته باشد. همچنین ممکن است زمانی مرتبط باشد که یک محصول لایه‌ای موردنیاز برای Integrity وجود داشته باشد، اما برای x86-64 موجود نباشد.

برای یک پروژه نوسازی جدید، این گزینه معمولاً باید به‌عنوان مسیری میانی برای سازگاری ارزیابی شود.

طرح توجیهی باید توضیح دهد چرا مهاجرت به Integrity نسبت به شبیه‌سازی Alpha، مهاجرت OpenVMS به x86 یا بازسکوپ‌بندی HMI گزینه بهتری است.

بازسکوپ‌بندی مبتنی بر OPC، لایه کنترل را حفظ می‌کند

بازسکوپ‌بندی مبتنی بر OPC، لایه رابط اپراتوری را جایگزین می‌کند و در عین حال کنترلرهای موجود INFI 90 و ورودی/خروجی میدانی را حفظ می‌کند.

یک سرور ارتباطی به سیستم Bailey متصل می‌شود و تگ‌های فرایندی را در اختیار یک پلتفرم مدرن HMI یا SCADA قرار می‌دهد.

HMI جدید نمایشگرها، هشدارها، روندها، امنیت، فرمان‌های اپراتور، گزارش‌ها و سرویس‌های ایستگاه کاری را مدیریت می‌کند.

این مسیر وابستگی به برنامه اصلی اپراتوری Symphony را حذف می‌کند. همچنین نیاز به اجرای OpenVMS Alpha روی ایستگاه‌های کاری جدید اپراتورها را از بین می‌برد.

این معماری معمولاً شامل موارد زیر است:

• کنترلرها و ورودی/خروجی موجود Bailey INFI 90.

• یک رابط ارتباطی سازگار با Bailey.

• یک سرور داده OPC DA، OPC UA یا اختصاصی فروشنده.

• یک پلتفرم مدرن HMI یا SCADA.

• ایستگاه‌های کاری اپراتوری و مهندسی.

• سرویس‌های اختیاری تاریخچه‌نگاری، گزارش‌دهی و تحلیل هشدار.

در یک نمونه میدانی که در منابع اصلی به آن اشاره شده، از سرور OPC شرکت RoviSys همراه با GE CIMPLICITY استفاده شده بود. سیستم گزارش‌شده با موفقیت کار کرد، اما پروژه به بازسازی نمایشگرهای اپراتوری و منطق پویانمایی نیاز داشت.

نباید این مثال را توصیه خودکار یک محصول برای هر نصب INFI 90 تفسیر کرد.

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

این موضوع درباره پلتفرم HMI نیز صدق می‌کند.

GE CIMPLICITY یکی از پلتفرم‌های ممکن HMI/SCADA سازمانی است. سیستم‌های دیگر نیز ممکن است مناسب باشند، مشروط بر اینکه اتصال موردنیاز OPC، گرافیک‌ها، هشدارها، اسکریپت‌نویسی، افزونگی، امنیت و پشتیبانی چرخه عمر را فراهم کنند.

شکل ۲. مهاجرت مبتنی بر OPC، لایه کنترل INFI 90 را حفظ می‌کند و هم‌زمان محیط اپراتوری قدیمی Symphony را جایگزین می‌سازد.

اتصال OPC نمایشگرهای موجود را تبدیل نمی‌کند

یک سرور OPC اتصال داده را فراهم می‌کند. این سرور معمولاً نمایشگرهای قدیمی HMI را به قالب جدید HMI تبدیل نمی‌کند.

صفحه‌های اصلی Symphony ممکن است شامل گرافیک‌های ثابت، نمادهای پویا، تغییرات رنگ، مقادیر عددی، نمودارهای میله‌ای، نشانگرهای هشدار، دکمه‌های پیمایش، کنترل‌های فرمان، روندها و قالب‌های توابع سفارشی باشند.

این عناصر باید در HMI مقصد بازآفرینی شوند.

صفحات ساده را می‌توان مستقیماً بازترسیم کرد. صفحات پیچیده ممکن است شامل اسکریپت‌ها یا عبارت‌های پنهانی باشند که بلافاصله قابل‌مشاهده نیستند.

مهندسان باید درک کنند که هر شیء متحرک چگونه داده‌های خود را دریافت و پردازش می‌کند.

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

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

بنابراین، انتقال صرفِ گرافیک‌های قابل‌مشاهده می‌تواند HMIای ایجاد کند که درست به نظر برسد اما نادرست عمل کند.

تیم مهاجرت باید معنای عملکردی پشت هر عنصر صفحه را مستندسازی کند.

این کار شامل موارد زیر است:

• نگاشت هر شیء پویا به منبع داده آن.

• بازآفرینی عبارت‌های انیمیشن.

• راستی‌آزمایی تأیید فرمان و امنیت.

• بازسازی پیمایش و سلسله‌مراتب صفحات.

• بازآفرینی دسته‌ها و اولویت‌های آلارم.

• تأیید واحدهای مهندسی و دقت اعشار.

• بازسازی روندهای تاریخی و بلادرنگ.

• آزمودن حالت‌های نامعتبر، نامطمئن و ارتباط ناموفق.

• بازتولید پیام‌ها و راهنمایی‌های اپراتور.

• جایگزینی فونت‌ها و نمادهای پشتیبانی‌نشده.

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

یک HMI مدرن نباید هر صفحه قدیمی را کورکورانه کپی کند

بازآفرینی دستی فرصتی برای بهبود رابط اپراتور ایجاد می‌کند.

گرافیک‌های HMI قدیمی اغلب برای تجهیزات عادی از رنگ‌های روشن، نمودارهای متراکم فرایندی، لوله‌کشی تزئینی و نشانه‌گذاری‌های ناهماهنگ آلارم استفاده می‌کنند.

این قراردادها ممکن است هنگام توسعه سیستم اصلی منطقی بوده باشند، اما همیشه برای رویه‌های کنونی اتاق کنترل ایدئال نیستند.

یک پروژه نوسازی باید موارد زیر را بررسی کند:

• سلسله‌مراتب نمایش.

• قابل‌مشاهده‌بودن آلارم‌ها.

• یکپارچگی پیمایش.

• نمایش وضعیت تجهیزات.

• استفاده از رنگ.

• دسترس‌پذیری روندها.

• الزامات واکنش اپراتور.

• وضوح صفحه‌نمایش و چیدمان ایستگاه کاری.

• دسترس‌پذیری و خوانایی.

شرایط عادی بهره‌برداری باید از نظر بصری خلوت باقی بمانند. رنگ‌های پرقدرت باید حالت‌های غیرعادیِ نیازمند توجه را مشخص کنند.

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

بااین‌حال، بازطراحی بیش‌ازحد می‌تواند خطر دیگری ایجاد کند.

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

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

استخراج تگ باید به‌عنوان یک بسته کاری مهندسی در نظر گرفته شود

متن منبع احتمال صادر کردن داده‌های تگ Bailey به CSV را مطرح می‌کند، اما رویه‌ای جهانی و تأییدشده ارائه نمی‌دهد.

بنابراین نباید فرض کرد که یک فرمان صادر کردن، پایگاه داده کامل و پاکیزه‌ای برای HMI تولید می‌کند.

منابع احتمالی اطلاعات تگ عبارت‌اند از:

• پایگاه‌های داده پیکربندی Symphony.

• تعریف‌های نمایشگرهای موجود.

• سوابق پیکربندی و مهندسی کنترلر.

• پایگاه‌های داده سرور ارتباطی Bailey.

• توابع مرور سرور OPC.

• فایل‌های پیکربندی هشدار.

• پایگاه‌های داده تاریخی.

• فهرست‌های چاپی یا بایگانی‌شده تگ‌ها.

• صفحات گسترده مهندسی سایت.

مرور OPC پس از برقراری ارتباط سرور با سیستم Bailey می‌تواند نقطه شروعی عملی فراهم کند.

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

بااین‌حال، فضای نام OPC ممکن است همه فیلدهای موردنیاز HMI جدید را شامل نشود.

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

برخی سرورهای OPC تگ‌ها را با نام‌های تولیدشده‌ای ارائه می‌کنند که با نام‌های اصلی Symphony تفاوت دارند.

پروژه باید یک فایل اصلی کنترل‌شده از تگ‌ها ایجاد کند که دست‌کم شامل موارد زیر باشد:

• نام تگ اصلی.

• نام تگ HMI جدید.

• شناسه آیتم OPC.

• توضیحات.

• نوع داده.

• مجوز خواندن یا نوشتن.

• واحدهای مهندسی.

• اطلاعات مقیاس‌بندی.

• حدود و اولویت هشدار.

• نرخ به‌روزرسانی.

• نمایشگر مرتبط.

• وضعیت اعتبارسنجی.

• نتیجه آزمون.

این فایل اصلی به رکورد تطبیق میان سیستم قدیمی و سیستم جدید تبدیل می‌شود.

تعداد تگ تنها نیازمندی ارتباطی نیست

موفقیت در آزمون مرور، ثابت نمی‌کند که معماری OPC می‌تواند از HMI کامل پشتیبانی کند.

مهندسان باید تعداد تگ‌های فعال، نرخ به‌روزرسانی درخواستی، دفعات تغییر، فعالیت هشدارها، ترافیک فرمان‌ها و افزونگی سرور را ارزیابی کنند.

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

سرور و HMI باید در شرایط واقع‌گرایانه آزمایش شوند.

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

• زمان لازم برای باز کردن یک نمایشگر پیچیده.

• تأخیر بین تغییر در میدان و پویانمایی HMI.

• ارسال هشدارها هنگام جهش‌های رویدادی.

• گردآوری روند با نرخ نمونه‌برداری موردنیاز.

• زمان اجرای فرمان و دریافت بازخورد.

• بازیابی پس از وقفه شبکه.

• جابه‌جایی بین سرورهای افزونه.

• رفتار پس از راه‌اندازی مجدد کنترلر.

• وضعیت کیفیت هنگام قطع ارتباط.

• بار پردازنده، حافظه و شبکه.

فرمان‌ها به توجه ویژه‌ای نیاز دارند.

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

تیم باید همه انواع فرمان‌های اپراتور را آزمایش کند، نه فقط یک تگ نماینده را.

ABB Symphony Plus مسیر تکامل گسترده‌تری ارائه می‌دهد

جایگزینی OPC تنها مسیر برای یک سیستم Bailey نصب‌شده نیست.

ABB همچنان Symphony Plus را به‌عنوان یک پلتفرم تکاملی برای نصب‌های قدیمی Bailey، INFI 90، Harmony Rack و Symphony معرفی می‌کند.

نوسازی مرحله‌ای ABB می‌تواند بخش‌هایی از معماری نصب‌شده کنترل و I/O را حفظ کند و هم‌زمان اجزای جدید اپراتوری، مهندسی، شبکه، کنترلر یا I/O را وارد کند.

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

پروژه ممکن است ابتدا محیط اپراتوری را نوسازی کند. کنترلرها و I/O می‌توانند تا زمانی که چرخه عمر یا ارزش عملیاتی آن‌ها جایگزینی را توجیه کند، به کار خود ادامه دهند.

فازهای بعدی می‌توانند ارتباطات، کنترلرها، ابزارهای مهندسی و رابط‌های میدانی را پوشش دهند.

معماری دقیق مهاجرت به نسل سیستم نصب‌شده بستگی دارد.

نصب‌های Bailey INFI 90، INFI 90 OPEN، Network 90، Harmony، Symphony و Symphony Plus همگی از رابط‌های یکسان استفاده نمی‌کنند.

نام ماژول‌ها و اصطلاحات شبکه باید از روی نقشه‌های سایت و فهرست‌های سخت‌افزاری تأیید شوند.

سازمان‌هایی که لایه کنترلی موجود را نگهداری می‌کنند، هنگام برنامه‌ریزی پوشش قطعات یدکی، پشتیبانی چرخه عمر و نوسازی مرحله‌ای، می‌توانند قطعات ABB Bailey INFI 90 و Network 90 موجود را نیز بررسی کنند.

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

نگهداری کنترلرهای یدکی، ماژول‌های ارتباطی، منابع تغذیه و ماژول‌های I/O مناسب می‌تواند ریسک را در طول این گذار کاهش دهد.

HMI سفارشی یا متن‌باز امکان‌پذیر است، اما به مالکیت نیاز دارد

یک HMI سفارشی را می‌توان با استفاده از چارچوب‌های نرم‌افزاری متن‌باز یا تجاری توسعه داد.

در مطالب منبع به سروری مقیم VMS با یک کلاینت مدرن مبتنی بر Qt اشاره شده است. معماری‌های این نوع می‌توانند اتصال داده در سمت سرور را از کلاینت اپراتور جدا کنند.

این مسیر می‌تواند انعطاف‌پذیری ایجاد کرده و از وابستگی به یک فروشنده HMI جلوگیری کند.

این مسیر همچنین می‌تواند به تعهدی بلندمدت برای توسعه نرم‌افزار تبدیل شود.

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

• سرور ارتباطات.

• پایگاه داده تگ‌ها.

• برنامه کاربردی کلاینت.

• چارچوب گرافیکی.

• پردازش آلارم.

• یکپارچه‌سازی با هیستوریَن.

• احراز هویت کاربر.

• به‌روزرسانی‌های امنیت سایبری.

• استقرار و کنترل نسخه.

• مستندسازی و آموزش.

Qt، پایتون، ++C، فناوری‌های وب یا سایر چارچوب‌ها می‌توانند رابط‌های صنعتی توانمندی ایجاد کنند. دشواری، ترسیم گرافیک فرایند نیست.

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

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

مجوزدهی می‌تواند تعیین کند که آیا یک مسیر فنی عملی است یا خیر

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

یک سیستم کلون‌شده ممکن است به‌درستی راه‌اندازی شود، اما به‌دلیل تغییر هویت سخت‌افزار مجازی از اجرای برنامه Symphony خودداری کند.

موجودی مهاجرت باید شامل موارد زیر باشد:

• مجوزهای سیستم‌عامل OpenVMS.

• مجوزهای برنامه Bailey Symphony.

• مجوزهای پایگاه داده.

• مجوزهای شبکه و ارتباطات.

• مجوزهای شبیه‌ساز.

• مجوزهای تعداد نقاط HMI و OPC.

• مجوزهای تاریخچه‌نگار.

• گزینه‌های افزونگی.

• مجوزهای کلاینت مهندسی.

• مجوزهای کلاینت زمان اجرا.

پیش از انتخاب پلتفرم نهایی باید تأییدیه کتبی دریافت شود.

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

امنیت سایبری باید در طراحی جایگزین گنجانده شود

سیستم‌های قدیمی AlphaStation اغلب پیش از رایج‌شدن شیوه‌های نوین امنیت سایبری صنعتی نصب شده بودند.

آن‌ها ممکن است روی شبکه‌های ایزوله با دسترسی محدود از راه دور کار کنند. جایگزین‌کردن آن‌ها با سرورهای ویندوز، کلاینت‌های مدرن SCADA، سرورهای OPC و زیرساخت اترنت، سطح حمله را تغییر می‌دهد.

معماری جدید باید نواحی جداگانه‌ای برای شبکه‌های کنترل، سرور، مهندسی و سازمانی تعریف کند.

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

حساب‌های اپراتورها باید از مجوزهای مبتنی بر نقش پیروی کنند. عملکردهای مهندسی نباید از هر کلاینت HMI در دسترس باشند.

دسترسی نوشتن OPC باید به تگ‌ها و ایستگاه‌هایی محدود شود که به آن نیاز دارند.

طراحی باید موارد زیر را نیز پوشش دهد:

• وصله‌گذاری سیستم‌عامل.

• ضدویروس یا کنترل برنامه‌ها.

• پشتیبان‌گیری و بازیابی.

• همگام‌سازی زمان.

• ثبت رویدادهای امنیتی.

• کنترل رسانه‌های قابل‌حمل.

• پشتیبانی از راه دور فروشنده.

• مدیریت گواهی‌ها برای OPC UA.

• مدیریت چرخه عمر حساب‌ها.

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

مهاجرت باید با موجودی مبتنی بر شواهد آغاز شود

مهندسان باید پیش از انتخاب مسیر، سیستم موجود را با جزئیات مستند کنند.

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

ثبت:

• مدل AlphaStation و پیکربندی پردازنده.

• ظرفیت حافظه.

• نوع دیسک و حجم‌های منطقی.

• نسخه و سطح وصله OpenVMS.

• نسخه‌های نصب‌شده نرم‌افزار Bailey.

• محصولات لایه‌ای و پایگاه‌های داده.

• سخت‌افزار گرافیکی و وضوح نمایشگر.

• آداپتورهای شبکه.

• رابط‌های سریال.

• سخت‌افزار ارتباطی Bailey.

• نام‌ها و نشانی‌های گره‌ها.

• رویه‌های فرمان راه‌اندازی.

• فایل‌های مجوز.

• رویه‌های پشتیبان‌گیری.

• افزونگی ایستگاه اپراتور.

• چاپگرهای متصل و دستگاه‌های خارجی.

• نگهداری داده‌های تاریخی و هشدارها.

تیم همچنین باید از هر نمایشگر عکس صفحه تهیه کند. در صورت امکان، وضعیت‌های پویا نیز باید ثبت شوند.

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

این شواهد هنگام آزمون صفحه‌های جدید ضروری است.

وجود سیستم آزمون روی میز الزامی است

هیچ مسیر نوسازی نباید برای نخستین بار روی سیستم زنده تولیدی آزموده شود.

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

برای یک پروژه شبیه‌ساز، محیط آزمون باید شامل یک محیط OpenVMS Alpha شبیه‌سازی‌شده و پیکربندی پیشنهادی شبیه‌ساز باشد.

برای یک پروژه OPC، این محیط باید شامل سرور ارتباطی انتخاب‌شده، نرم‌افزار HMI، گرافیک‌های نماینده و دسترسی به یک گره آزمایشی امن Bailey یا منبع داده شبیه‌سازی‌شده باشد.

آزمون روی میز باید موارد زیر را بررسی کند:

• راه‌اندازی سیستم و اجرای اولیه برنامه.

• ارتباط با سیستم Bailey.

• تعداد کل تگ‌های قابل دسترسی.

• عملیات خواندن و نوشتن.

• مقیاس‌بندی تگ‌ها و واحدهای مهندسی.

• تولید و تأیید هشدارها.

• جمع‌آوری روندها.

• پویانمایی نمایشگر.

• امنیت فرمان‌ها.

• عملکرد چاپگر و گزارش‌ها.

• رفتار هنگام راه‌اندازی مجدد سرور.

• رفتار هنگام خرابی شبکه.

• افزونگی و جابه‌جایی پس از خرابی.

• بازیابی نسخه پشتیبان.

• زمان پاسخ اپراتور.

نتایج آزمون باید توسط نمایندگان بهره‌برداری، مهندسی کنترل، نگهداری و امنیت سایبری مشاهده و تأیید شود.

عملیات موازی خطر انتقال نهایی را کاهش می‌دهد

AlphaStationهای اصلی باید در زمان استقرار اولیه سیستم جایگزین همچنان در دسترس باشند.

HMI جدید می‌تواند به‌صورت موازی کار کند و مهندسان مقادیر، هشدارها، روندها و فرمان‌ها را با یکدیگر مقایسه کنند.

عملیات موازی امکان شناسایی ناهماهنگی‌ها را پیش از حذف ایستگاه قدیمی فراهم می‌کند.

تیم باید موارد زیر را تطبیق دهد:

• مقادیر نمایش‌داده‌شده فرایند.

• نمایش وضعیت‌ها.

• اولویت‌های هشدار.

• مُهرهای زمانی هشدارها.

• نتایج فرمان‌ها.

• مقادیر روند.

• حالت تجهیزات.

• کیفیت ارتباطات.

• مجوزهای امنیتی.

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

بااین‌حال، هر تفاوتی باید توضیح داده و تأیید شود.

ایستگاه‌های قدیمی باید تا زمانی که HMI جدید آزمون پذیرش سایتِ شاهددار را با موفقیت پشت سر بگذارد و یک دوره عملیاتی مورد توافق طی شود، همچنان قابل بازیابی باشند.

انتخاب مسیر صحیح مهاجرت

در شرایط زیر، شبیه‌سازی Alpha را انتخاب کنید:

برنامه کاربردی موجود Symphony باید بدون تغییر باقی بماند. کد منبع در دسترس نیست. گرافیک‌های اپراتوری پیچیده هستند. آموزش مجدد باید به حداقل برسد. رابط ارتباطی Bailey را می‌توان با معماری شبیه‌ساز پشتیبانی کرد.

در شرایط زیر، مهاجرت OpenVMS x86 را انتخاب کنید:

برنامه‌های کاربردی موردنیاز برای x86-64 در دسترس هستند یا می‌توان آن‌ها را بازسازی کرد. کد منبع و دانش مهندسی همچنان در دسترس است. سازمان می‌خواهد OpenVMS را حفظ کند و هم‌زمان به یک محیط x86 پشتیبانی‌شده منتقل شود.

وقتی بازپلتفرم‌سازی OPC را انتخاب کنید:

وقتی کنترلر و لایه‌های I/O سیستم INFI 90 همچنان قابل اتکا هستند. سازمان یک پلتفرم مدرن HMI می‌خواهد. منابع مهندسی برای بازسازی و اعتبارسنجی نمایشگرها، هشدارها، تگ‌ها و منطق فرمان در دسترس است.

وقتی مسیر تکاملی ABB را انتخاب کنید:

وقتی سازمان خواهان برنامه نوسازی گسترده‌تری با پشتیبانی فروشنده است. فازهای آینده ممکن است شامل سیستم‌های اپراتوری، ابزارهای مهندسی، رابط‌های شبکه، کنترلرها و I/O باشند.

وقتی یک HMI سفارشی را انتخاب کنید:

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

سیستم موجود را موقتاً حفظ کنید وقتی:

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

برنامه عملی نوسازی مرحله‌ای

فاز ۱: محیط موجود را حفظ کنید.

از هر AlphaStation نسخه پشتیبان ایمیجِ تأییدشده تهیه کنید. جزئیات سخت‌افزار، نرم‌افزار، شبکه، مجوزها و راه‌اندازی را ثبت کنید. در صورت امکان، بازیابی را آزمایش کنید.

فاز ۲: معماری ارتباطی را شناسایی کنید.

دقیقاً مستند کنید که هر ایستگاه Symphony چگونه با INFI 90 ارتباط برقرار می‌کند. تأیید کنید که آیا این رابط را می‌توان شبیه‌سازی یا با یک سرور پشتیبانی‌شده جایگزین کرد.

فاز ۳: نمونه اثبات مفهوم را بسازید.

یک ایستگاه کلون‌شده را روی شبیه‌ساز Alpha آزمایش کنید یا یک سرور OPC را به یک گره نماینده Bailey متصل کنید.

فاز ۴: مرجع اصلی تگ‌ها را ایجاد کنید.

تگ‌های کنترلر، شناسه‌های آیتم OPC، واحدهای مهندسی، فرمان‌ها، هشدارها و کاربرد نمایشگرها را تطبیق دهید.

فاز ۵: نمایشگرهای نماینده را بازسازی کنید.

چند صفحه را انتخاب کنید که الزامات متفاوتی برای پویانمایی، هشدار، فرمان و روندنما دارند.

فاز ۶: پذیرش کامل روی میز آزمون را انجام دهید.

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

فاز ۷: به‌صورت موازی استقرار دهید.

HMIهای جدید و قدیمی را هم‌زمان راه‌اندازی کنید. مقادیر و پاسخ‌های اپراتورها را مقایسه کنید.

فاز ۸: انتقال نهایی را با حضور شاهد انجام دهید.

از یک رویه آزمون تأییدشده استفاده کنید. AlphaStationها را به‌عنوان راهکار پشتیبان در دسترس نگه دارید.

فاز ۹: سخت‌افزار قدیمی را به‌تدریج از رده خارج کنید.

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

پرسش‌های متداول

آیا می‌توان دیسک یک AlphaStation دارای OpenVMS را مستقیماً روی یک رایانه مدرن کلون کرد؟

خیر. این ایمیج حاوی کد ماشین Alpha است و به سخت‌افزار سازگار با Alpha نیاز دارد. یک رایانه مدرن x86 نمی‌تواند مستقیماً آن را راه‌اندازی کند. ایمیج باید روی سخت‌افزار سازگار Alpha یا یک شبیه‌ساز Alpha بازیابی شود.

آیا VMware یا VirtualBox می‌توانند OpenVMS را اجرا کنند؟

آن‌ها می‌توانند نسخه‌های پشتیبانی‌شده OpenVMS x86-64 را اجرا کنند. آن‌ها یک نصب قدیمی OpenVMS Alpha را به یک برنامه x86 تبدیل نمی‌کنند. OpenVMS Alpha به شبیه‌سازی Alpha نیاز دارد.

آیا می‌توان نمایشگرهای اصلی Symphony را حفظ کرد؟

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

آیا سرور OPC به‌طور خودکار همه تگ‌های Bailey را صادر می‌کند؟

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

آیا GE CIMPLICITY تنها HMI جایگزین است؟

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

آیا مهاجرت از Alpha به Itanium هنوز ارزشمند است؟

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

آیا کنترلرها و I/O مربوط به INFI 90 می‌توانند در محل نصب باقی بمانند؟

بله، اگر همچنان قابل‌اعتماد باشند و معماری ارتباطی انتخاب‌شده از آن‌ها پشتیبانی کند. نوسازی HMI را می‌توان جدا از جایگزینی کنترلر و I/O تکمیل کرد.

آیا باید AlphaStationهای قدیمی بلافاصله پس از انتقال حذف شوند؟

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

راهکار درست به مواردی بستگی دارد که باید حفظ شوند

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

یک AlphaStation که OpenVMS Alpha و Bailey Symphony را اجرا می‌کند، محیطی کامل از سخت‌افزار و نرم‌افزار است. معماری پردازنده، سیستم‌عامل، رابط‌های ارتباطی، فایل‌های اجرایی برنامه، مجوزها، گرافیک و اتصالات سیستم کنترل آن به یکدیگر وابسته‌اند.

کلون دیسک داده‌ها را حفظ می‌کند؛ اما آن محیط را به معماری دیگری ترجمه نمی‌کند.

شبیه‌سازی Alpha مستقیم‌ترین مسیر را فراهم می‌کند، زمانی که لازم باشد کل نصب Symphony بدون تغییر حفظ شود.

OpenVMS x86-64 زمانی که برنامه‌ها قابل مهاجرت یا بازسازی باشند، مسیری مدرن برای سیستم‌عامل فراهم می‌کند.

بازسازی بستر OPC زمانی مسیری عملی فراهم می‌کند که لایه کنترلی INFI 90 همچنان ارزشمند باشد، اما لایه اپراتوری باید جایگزین شود.

تکامل ABB Symphony Plus می‌تواند راهبرد مرحله‌ای گسترده‌تری فراهم کند، زمانی که سازمان بخواهد فراتر از HMI به نوسازی بپردازد.

تصمیم نهایی باید بر اساس موجودیِ تأییدشده، بررسی رابط‌های ارتباطی، بازبینی مجوزها، نمونه‌اثبات، آزمون روی میز و پذیرش عملیاتیِ مشاهده‌شده اتخاذ شود.

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