OpenVMS Alpha’da ishlayotgan Bailey INFI 90 Symphony HMI tizimlarini modernizatsiya qilish

Butun INFI 90 tizimini almashtirmasdan HMI ni modernizatsiya qilish

Ko‘plab Bailey INFI 90 tizimlari dastlab o‘rnatilganidan o‘nlab yillar o‘tib ham ishonchli ishlashda davom etmoqda. Ularning kontrollerlari, aloqa modullari, terminal bloklari va dala I/O qurilmalari hanuz zarur boshqaruv funksiyalarini bajarayotgan bo‘lishi mumkin.

Hayotiy siklning eng dolzarb muammosi ko‘pincha kontroller qatlamidan yuqorida joylashadi.

Operator stansiyalari eskirgan AlphaStation qurilmalariga, qo‘llab-quvvatlanmaydigan grafik adapterlarga, eskirgan saqlash qurilmalariga va eski OpenVMS Alpha dasturiy muhitlariga bog‘liq bo‘lishi mumkin. Almashtirish qismlarini topish qiyinlashadi, OpenVMS va Bailey Symphony bo‘yicha tajribali muhandislar esa tobora kamayib bormoqda.

Bu yerda ko‘rib chiqilayotgan misol to‘rtta AlphaStation 255 ish stansiyasini o‘z ichiga oladi. Har bir stansiyada OpenVMS Alpha ishlaydi va Bailey INFI 90 taqsimlangan boshqaruv tizimi uchun Bailey Symphony operator interfeysi funksiyalarini taqdim etadi.

Maqsad butun DCSni almashtirish bo‘lishi shart emas. Amaliyroq maqsad — barqaror kontrollerlar, dala simlari, I/O modullari, boshqaruv mantiqi va texnologik jarayonlarni saqlab qolgan holda, eskirgan AlphaStation qurilmalariga bog‘liqlikni bartaraf etish.

Bu farq modernizatsiya strategiyasini o‘zgartiradi.

Loyiha, avvalo, operator interfeysi va hisoblash platformasini ko‘chirishdan iborat. U faqat kontrollerning xizmat muddati, kiberxavfsizlik talablari, ishlab chiqarish maqsadlari yoki qo‘llab-quvvatlash shartlari quyi boshqaruv qatlamlarini almashtirishni oqlaganidagina to‘liq DCS migratsiyasiga aylanadi.

Modernizatsiyaning bir nechta mumkin bo‘lgan yo‘nalishlari mavjud. Biroq ular mavjud tizimning turli qismlarini saqlab qoladi.

Alpha emulyatori deyarli butun dasturiy muhitni saqlab qolishi mumkin. OpenVMS x86 ga migratsiya operatsion tizimlar oilasini saqlab qoladi, ammo ilovalarni ko‘chirishni talab qiladi. OPC asosidagi HMI almashtiruvi kontroller qatlamini saqlab qoladi, operator interfeysini esa qayta yaratadi. ABB evolyutsiya strategiyasi kengroq Symphony arxitekturasini bosqichma-bosqich modernizatsiya qilishi mumkin.

Hech bir yo‘nalishni oddiy kompyuter almashtiruvi sifatida ta’riflab bo‘lmaydi.

1-rasm. Modernizatsiyaning uchta asosiy yo‘nalishi o‘rnatilgan Bailey INFI 90 va Symphony investitsiyasining turli qismlarini saqlab qolishi mumkin.

Nega AlphaStation diskini klonlashning o‘zi yetarli emas

Diskni klonlash o‘rnatilgan OpenVMS Alpha muhitini saqlab qolish uchun foydalidir. U operatsion tizimni, ilova fayllarini, qurilma konfiguratsiyasini, foydalanuvchi hisoblarini, Bailey dasturiy ta’minotini, ma’lumotlar bazalarini, grafikalarni va obyektga xos sozlamalarni qamrab olishi mumkin.

Biroq diskni klonlash Alpha dasturiy ta’minotini x86 dasturiy ta’minotiga aylantirmaydi.

Klonlangan operatsion tizimda hali ham Alpha protsessori buyruqlari mavjud. Uning yadrosi, yuklovchi dasturi, tizim kutubxonalari, ilovalari va apparat drayverlari Alpha arxitekturasi uchun yaratilgan.

Standart zamonaviy kompyuter x86-64 protsessoridan foydalanadi. Shuningdek, u turli xil saqlash kontrollerlari, tarmoq qurilmalari, uzilish tuzilmalari, grafik apparati, mikrodastur interfeyslari va periferik shinalarni taqdim etadi.

VMware, VirtualBox, Hyper-V va an’anaviy x86 gipervizorlari x86 bilan mos apparatni virtuallashtiradi. Ular odatda Alpha protsessori yo‘riqnomalarini x86 yo‘riqnomalariga tarjima qilmaydi.

Shuning uchun OpenVMS Alpha disk tasvirini oddiy x86 virtual mashinasiga joylashtirish bu tasvirni yuklanadigan qilib qo‘ymaydi.

Virtual mashina virtual disk, virtual tarmoq adapteri va virtual grafik qurilmani taqdim etishi mumkin. OpenVMS Alpha esa hali ham Alpha protsessori va Alpha davriga oid qo‘llab-quvvatlanadigan qurilmalarni kutadi.

Shu sababli bu ikki tushunchani alohida saqlash kerak:

Virtuallashtirish odatda xostdagi protsessor arxitekturasi bilan bir xil virtual apparatni taqdim etadi.

Platformalararo emulyatsiya boshqa protsessor va apparat muhitini dasturiy ta’minotda takrorlaydi.

Asl Alpha ikkilik fayllari va operatsion tizimi o‘zgartirilmasdan qolishi kerak bo‘lganda, OpenVMS Alpha ikkinchi yondashuvni talab qiladi.

Shu sababli diskni klonlash faqat uchta cheklangan holatda amalga oshirilishi mumkin.

Birinchisi — mos saqlash qurilmalari va periferik qurilmalarga ega ayni AlphaStation modeliga tiklash.

Ikkinchisi — zarur qurilma va konfiguratsiya o‘zgarishlarini bajargandan so‘ng, boshqa qo‘llab-quvvatlanadigan Alpha tizimiga tiklash.

Uchinchisi — mos AlphaServer yoki AlphaStation muhitini takrorlaydigan Alpha emulyatoriga tiklash.

Faqat klonlash arxitektura muammosini hal qilmaydi. Maqsadli muhit Alpha mashina yo‘riqnomalarini tushunishi va bajara olishi kerak.

Alpha emulyatsiyasi mavjud investitsiyalarning eng katta qismini saqlab qoladi

Mavjud Symphony dasturiy ta’minoti manba kodini o‘zgartirmasdan ishlashi kerak bo‘lganda, Alpha emulyatsiyasi odatda eng kam buzilish keltirib chiqaradigan yo‘ldir.

Alpha emulyatori zamonaviy x86 apparatida ishlaydi, biroq OpenVMS uchun virtual Alpha tizimini taqdim etadi. Asl operatsion tizim va ilovalar Alpha bilan mos apparat muhitini ko‘rishda davom etadi.

CHARON-AXP kabi mahsulotlar aynan shu maqsad uchun ishlab chiqilgan. Emulyator jismoniy Alpha protsessori, xotira arxitekturasi, saqlash kontrollerlari, Ethernet adapterlari va boshqa qo‘llab-quvvatlanadigan qurilmalarni dasturiy ta’minotda belgilangan muqobillar bilan almashtiradi.

x86 server xost muhiti sifatida Windows yoki Linux’da ishlaydi. Alpha emulyatori shu xost ustida ishlaydi. Keyin OpenVMS Alpha emulyatsiya qilingan Alpha tizimi ichida ishlaydi.

Bu yondashuv OpenVMS’ni x86 platformasiga ko‘chirishdan farq qiladi.

Asl OpenVMS Alpha o‘rnatilmasi Alpha o‘rnatilmasi bo‘lib qoladi. Bailey Symphony ikkilik fayllari Alpha ikkilik fayllari bo‘lib qoladi. Emulyator talab qilinadigan Alpha apparati xatti-harakatlarini tarjima qiladi yoki takrorlaydi.

Bu quyidagilarni saqlab qolishi mumkin:

• O‘rnatilgan OpenVMS Alpha operatsion tizimi.

• Mavjud Bailey Symphony ilovalari.

• Operator grafikasi va displey ma’lumotlar bazalari.

• Signalizatsiya konfiguratsiyalari va tarixiy fayllar.

• Foydalanuvchi hisoblari va buyruq protseduralari.

• Mavjud obyektga xos yordamchi dasturlar.

• Alpha muhitiga bog‘liq bo‘lgan ilova interfeyslari.

• Aks holda qayta tayyorgarlikni talab qiladigan operator ish jarayonlari.

Amaliy ko‘chirish odatda dastlabki Alpha disklari tasdiqlangan obrazi yoki zaxira nusxasini yaratishni o‘z ichiga oladi. Ushbu ma’lumotlar emulyator foydalanadigan virtual disk konteynerlariga tiklanadi.

Emulyator konfiguratsiyasi mos CPU, xotira, disk, tarmoq va periferik qurilma xususiyatlarini takrorlashi kerak. Jamoaga, shuningdek, jismoniy ketma-ket portlar yoki tarmoq interfeyslarini xost tizimi orqali moslashtirish kerak bo‘lishi mumkin.

Alpha emulyatsiyasi eskirgan jismoniy qurilmalarga bog‘liqlikni sezilarli darajada kamaytirishi mumkin. Shuningdek, virtual disk fayllarini zamonaviy saqlash infratuzilmasi yordamida nusxalash mumkinligi sababli zaxiralashni soddalashtirishi mumkin.

Biroq “nol o‘zgarish” atamasidan ehtiyotkorlik bilan foydalanish kerak.

Ilova kodi o‘zgarishsiz qolishi mumkin, ammo muhit baribir muhandislik ishlarini talab qiladi. Qurilma moslashuvlari tekshirilishi kerak. Tarmoq interfeyslari sozlanishi kerak. OpenVMS litsenziyalari va ilova litsenziyalari qayta ko‘rib chiqilishi kerak.

Emulyator, shuningdek, obyektда ishlatiladigan Bailey aloqa interfeysi bilan sinovdan o‘tkazilishi kerak.

Umumiy OpenVMS ilovasi to‘g‘ri ishlashi mumkin, ammo ixtisoslashtirilgan DCS interfeysi muayyan tarmoq adapteri, shina interfeysi, ketma-ket qurilma yoki vaqt xatti-harakatiga bog‘liq bo‘lgani uchun ishlamay qolishi mumkin.

Shu sababli emulyator profilini tanlashdan oldin aniq AlphaStation 255 konfiguratsiyasi inventarizatsiya qilinishi kerak.

Bailey aloqa interfeysi emulyatsiyaning hal qiluvchi sinovidir

Emulyatsiya bo‘yicha eng muhim savol OpenVMS kirish so‘rovigacha yetib boradimi yoki yo‘qmi, degani emas.

Muhim savol — emulyatsiya qilingan stansiya to‘liq ishlash sharoitida Bailey INFI 90 tizimi bilan to‘g‘ri aloqa qila oladimi.

Interfeys Ethernet, ketma-ket aloqa, Bailey tarmoq interfeysi yoki ixtisoslashtirilgan aloqa apparatiga bog‘liq bo‘lishi mumkin. Obyekt konfiguratsiyalari sezilarli darajada farq qilishi mumkin.

Alpha emulyatsiyasiga o‘tishdan oldin muhandislar quyidagilarni hujjatlashtirishlari kerak:

• Har bir AlphaStation’da o‘rnatilgan jismoniy tarmoq interfeysi.

• Symphony va INFI 90 o‘rtasida ishlatiladigan aloqa protokoli.

• OpenVMS ichida tayinlangan qurilma nomlari.

• Tarmoq manzillari va tugun ta’riflari.

• Talab qilinadigan DECnet, TCP/IP, LAT yoki xususiy xizmatlar.

• Zarur bo‘lganda, ketma-ket port sozlamalari.

• Har qanday tashqi litsenziya kalitlari yoki apparat dongllari.

• Operator stansiyalari o‘rtasidagi zaxiralash va nosozlikdan keyingi almashish xatti-harakati.

• Vaqtni sinxronlashtirish talablari.

• Operatorlar foydalanadigan grafik va klaviatura funksiyalari.

Emulyator yetkazib beruvchisi keng tarqalgan Alpha Ethernet va saqlash qurilmalarini qo‘llab-quvvatlashi mumkin. Bu har bir xususiy Bailey interfeysi qo‘llab-quvvatlanishini avtomatik ravishda tasdiqlamaydi.

Agar mavjud HMI virtualizatsiya qilib bo‘lmaydigan ixtisoslashtirilgan jismoniy adapterga bog‘liq bo‘lsa, emulyator yo‘li muqobil aloqa shlyuzini talab qilishi mumkin.

Shu sababli loyiha klonlangan stansiya va namunaviy Bailey tarmog‘iga kirish imkoniyati yordamida stend sinovini ham o‘z ichiga olishi kerak.

Sinov faqat statik teglarni o‘qish bilan cheklanmasligi kerak. Operatorlar real vaqt qiymatlari, buyruqlar, signallar, tasdiqlash, trendlar, ekranlar bo‘ylab navigatsiya, chop etish, hodisalarni qayta ishlash va stansiyani tiklashni tekshirishlari kerak.

Ishlash unumdorligi signalizatsiya to‘lqinlari va teglar tez-tez yangilanadigan paytda ham sinovdan o‘tkazilishi kerak.

OpenVMS x86-64 — boshqa migratsiya yo‘li

Zamonaviy OpenVMS x86-64 arxitekturasi uchun mavjud. U zamonaviy serverlardagi qo‘llab-quvvatlanadigan virtualizatsiya muhitlarida ishlashi mumkin.

Bu ko‘plab avvalgi INFI 90 modernizatsiyasi muhokamalarida mavjud bo‘lmagan qo‘shimcha migratsiya variantini yaratadi.

Biroq OpenVMS x86-64 OpenVMS Alpha binar fayllarini xuddi mahalliy x86 ilovalari kabi bevosita ishga tushirmaydi.

Ilova muhiti migratsiya qilinishi kerak.

Dastlabki kodni x86-64 uchun ko‘chirish, ko‘rib chiqish, qayta kompilyatsiya qilish, bog‘lash va sinovdan o‘tkazish talab etilishi mumkin. Uchinchi tomon kutubxonalari va qo‘shimcha mahsulotlar ham maqsadli versiya uchun mavjud bo‘lishi kerak.

Asosiy savol — o‘rnatilgan Bailey Symphony dasturiy ta’minotining x86 bilan mos OpenVMS versiyasi mavjudmi.

Agar dasturiy ta’minot ishlab chiqaruvchisi bu ilovani OpenVMS x86-64 uchun hech qachon chiqarmagan bo‘lsa, faqat operatsion tizimni ko‘chirish HMI’ni saqlab qolmaydi.

Dastlabki kodi va yig‘ish muhiti mavjud bo‘lib qolsa, obyekt tomonidan ishlab chiqilgan dasturlarni ko‘chirish mumkin. Tijoriy yopiq ilovalarni odatda ishlab chiqaruvchi yordamisiz qayta yig‘ib bo‘lmaydi.

Bu yo‘l Symphony HMI yonida ishlaydigan maxsus ma’lumotlar serverlari, tarixiy ma’lumotlar tizimlari, yordamchi dasturlar, hisobotlar va integratsiya ilovalari uchun baribir amaliy bo‘lishi mumkin.

Qo‘llab-quvvatlanadigan ilova versiyasi mavjud bo‘lmasa, eski xususiy Symphony operator muhitini saqlab qolish ehtimoli past.

OpenVMS x86 migratsiyasini baholash quyidagilarni aniqlashi kerak:

• O‘rnatilgan har bir bajariluvchi fayl va qo‘shimcha mahsulot.

• Mavjud dastlabki kod va yig‘ish protseduralari.

• Kompilyator va bajarilish muhiti bog‘liqliklari.

• Ma’lumotlar bazasi mahsulotlari va fayl formatlari.

• Xususiy aloqa kutubxonalari.

• Grafika yoki oynalar tizimiga bog‘liqliklar.

• x86-64 uchun litsenziyaning mavjudligi.

• Arxitektura farqlari sababli talab etiladigan o‘zgarishlar.

• Ishlash unumdorligi va vaqt bo‘yicha taxminlar.

Bu yo‘l Alpha’dan boshqa to‘xtatilgan apparat arxitekturasiga o‘tishga qaraganda uzoq muddatda ko‘proq imkoniyat beradi. U mos keluvchi OpenVMS ish yuklamalarini qo‘llab-quvvatlanadigan x86 virtualizatsiya infratuzilmasiga joylashtirish imkonini beradi.

Shunga qaramay, buni diskni klonlash loyihasi emas, balki ilovani migratsiya qilish loyihasi sifatida ta’riflash kerak.

Nima uchun Itanium migratsiyasi odatda o‘tish davri varianti hisoblanadi

OpenVMS Itanium arxitekturasidan foydalanadigan HPE Integrity serverlari uchun ham chiqarilgan.

Ayrim Alpha ilovalarini OpenVMS Integrity tizimiga ko‘chirish uchun migratsiya vositalari va muhandislik usullari mavjud. Bu avval eskirayotgan Alpha apparatidan chiqish uchun qo‘llab-quvvatlanadigan yo‘lni ta’minlagan.

Biroq bugungi kunda Itanium apparatining o‘zi ham eskirgan platforma hisoblanadi.

Alpha’dan Integrity’ga o‘tish eskirgan apparatga bo‘lgan bir bog‘liqlikni bartaraf etishi, shu bilan birga boshqasini yaratishi mumkin. Mos serverlar, ehtiyot qismlar, xotira interfeyslari va maxsus bilimga ega mutaxassislar tobora kamroq mavjud bo‘lib boradi.

Agar saytda allaqachon qo‘llab-quvvatlanadigan Integrity infratuzilmasi mavjud bo‘lsa, Itanium hanuz dolzarb bo‘lishi mumkin. Shuningdek, x86-64 uchun mavjud bo‘lmagan, Integrity uchun zarur qatlamli mahsulot mavjud bo‘lsa ham dolzarb bo‘lishi mumkin.

Yangi modernizatsiya loyihasi uchun bu yo‘nalish odatda oraliq moslik yo‘li sifatida baholanishi kerak.

Biznes asosida Integrity’ga o‘tish nima uchun Alpha emulyatsiyasi, OpenVMS x86 migratsiyasi yoki HMI’ni qayta platformalashdan afzal ekanini tushuntirish kerak.

OPC asosida qayta platformalash boshqaruv qatlamini saqlab qoladi

OPC asosida qayta platformalash operator interfeysi qatlamini almashtiradi, mavjud INFI 90 kontrollerlari va maydon kiritish-chiqarish tizimini esa saqlab qoladi.

Aloqa serveri Bailey tizimiga ulanadi va jarayon teglarini zamonaviy HMI yoki SCADA platformasiga taqdim etadi.

Yangi HMI ekranlar, alarmlar, trendlar, xavfsizlik, operator buyruqlari, hisobotlar va ish stansiyasi xizmatlarini boshqaradi.

Bu yo‘l original Symphony operator dasturiga bog‘liqlikni bartaraf etadi. Shuningdek, yangi operator stansiyalarida OpenVMS Alpha’ni ishga tushirish zaruratidan qochish imkonini beradi.

Arxitektura odatda quyidagilarni o‘z ichiga oladi:

• Mavjud Bailey INFI 90 kontrollerlari va kiritish-chiqarish tizimi.

• Mos Bailey aloqa interfeysi.

• OPC DA, OPC UA yoki ishlab chiqaruvchiga xos ma’lumotlar serveri.

• Zamonaviy HMI yoki SCADA platformasi.

• Operator va muhandislik ish stansiyalari.

• Ixtiyoriy tarixiy ma’lumotlar, hisobot va alarmlarni tahlil qilish xizmatlari.

Manba materialida keltirilgan amaliy misolda GE CIMPLICITY bilan RoviSys OPC serveridan foydalanilgan. Xabar qilingan tizim muvaffaqiyatli ishlagan, biroq loyiha operator ekranlari va animatsiya mantiqini qayta yaratishni talab qilgan.

Bu misolni har bir INFI 90 o‘rnatmasi uchun avtomatik mahsulot tavsiyasi sifatida talqin qilmaslik kerak.

Tanlangan server saytdagi muayyan Bailey tarmog‘ini, aloqa modullarini, kontroller avlodini, teglar sonini, yangilanish tezligini, zaxiralash talablarini va buyruq funksiyalarini qo‘llab-quvvatlashi kerak.

Xuddi shu narsa HMI platformasiga ham tegishli.

GE CIMPLICITY — korporativ HMI/SCADA platformalaridan biri. Kerakli OPC ulanishi, grafikalar, alarmlar, skriptlar, zaxiralash, xavfsizlik va foydalanish davri qo‘llab-quvvatlashini ta’minlaydigan boshqa tizimlar ham mos kelishi mumkin.

2-rasm. OPC asosidagi migratsiya INFI 90 boshqaruv qatlamini saqlab qoladi, shu bilan birga eskirgan Symphony operator muhitini almashtiradi.

OPC ulanishi mavjud ekranlarni o‘zgartirmaydi

OPC serveri ma’lumotlar ulanishini ta’minlaydi. U odatda eski HMI ekranlarini yangi HMI formatiga o‘zgartirmaydi.

Original Symphony ekranlarida statik grafikalar, dinamik belgilar, rang o‘zgarishlari, sonli qiymatlar, ustunli grafiklar, avariya indikatorlari, navigatsiya tugmalari, buyruq boshqaruvlari, trendlar va maxsus funksiya shablonlari bo‘lishi mumkin.

Bu elementlar maqsadli HMI tizimida qayta yaratilishi kerak.

Oddiy ekranlarni bevosita qayta chizish mumkin. Murakkab ekranlarda darhol ko‘rinmaydigan yashirin skriptlar yoki ifodalar bo‘lishi mumkin.

Muhandislar har bir animatsiyalangan obyekt o‘z ma’lumotlarini qanday olishi va qayta ishlashini tushunishlari kerak.

Klapan belgisi faqat bitta chiqish tegiga bog‘liq bo‘lmasligi mumkin. Uning rangi va holati ochiqlik qayta aloqasi, yopiqlik qayta aloqasi, buyruq holati, blokirovka holati, aloqa sifati va uskuna rejimiga bog‘liq bo‘lishi mumkin.

Dvigatel belgisi ishga tushirish buyrug‘i, ishlayotganlik qayta aloqasi, to‘xtaganlik holati, avariya o‘chishi, mahalliy boshqaruv, texnik xizmat holati, ishga tushirishga ruxsat beruvchi shartlar va signalni bloklash uchun alohida teglaridan foydalanishi mumkin.

Shuning uchun faqat ko‘rinadigan grafikalarni ko‘chirish to‘g‘ri ko‘rinadigan, ammo noto‘g‘ri ishlaydigan HMI yaratishi mumkin.

Migratsiya jamoasi har bir ekran elementining funksional ma’nosini hujjatlashtirishi kerak.

Bu ishlar quyidagilarni o‘z ichiga oladi:

• Har bir dinamik obyektni uning ma’lumotlar manbasi bilan bog‘lash.

• Animatsiya ifodalarini qayta yaratish.

• Buyruqni tasdiqlash va xavfsizlikni tekshirish.

• Navigatsiya va ekranlar ierarxiyasini qayta qurish.

• Signal sinflari va ustuvorliklarini qayta yaratish.

• Muhandislik birliklari va o‘nli kasr aniqligini tasdiqlash.

• Tarixiy va real vaqt rejimidagi trendlarni qayta yaratish.

• Noto‘g‘ri, noaniq va aloqa uzilgan holatlarni sinash.

• Operator xabarlari va ko‘rsatmalarini qayta yaratish.

• Qo‘llab-quvvatlanmaydigan shriftlar va belgilarni almashtirish.

Shu sababli ish hajmi faqat ekranlar soni bilan emas, balki ekranlarning murakkabligi bilan belgilanadi.

Zamonaviy HMI har bir eski ekranni ko‘r-ko‘rona nusxalamasligi kerak

Qo‘lda qayta yaratish operator interfeysini yaxshilash imkonini beradi.

Eski HMI grafikalarida ko‘pincha normal ishlayotgan uskunalar uchun yorqin ranglar, zich joylashtirilgan texnologik diagrammalar, bezak sifatidagi quvurlar va izchil bo‘lmagan signal ko‘rsatkichlari qo‘llanadi.

Asl tizim ishlab chiqilgan paytda bu qoidalar maqbul bo‘lgan bo‘lishi mumkin. Ammo ular hozirgi boshqaruv xonasi amaliyotlari uchun har doim ham ideal emas.

Modernizatsiya loyihasi quyidagilarni ko‘rib chiqishi kerak:

• Ekranlar ierarxiyasi.

• Signallarning ko‘rinuvchanligi.

• Navigatsiya izchilligi.

• Uskuna holatini ko‘rsatish.

• Ranglardan foydalanish.

• Trendlardan foydalanish imkoniyati.

• Operatorning javob berish talablari.

• Ekran aniqligi va ish stansiyasi joylashuvi.

• Foydalanish imkoniyati va o‘qilishi.

Normal ish sharoitlari ekranda sokin ko‘rinishda qolishi kerak. Kuchli ranglar e’tibor talab qiladigan noodatiy holatlarni ko‘rsatishi lozim.

Operatorlar zavod umumiy ko‘rinishidan ta’sirlangan qurilmaga, uskuna boshqaruv paneliga, trendga, signallar tarixiga va diagnostika ekraniga ortiqcha navigatsiyasiz o‘ta olishlari kerak.

Biroq, haddan tashqari qayta loyihalash yana bir xavfni yuzaga keltirishi mumkin.

Operatorlar asl ekranlardan ko‘p yillar foydalangan bo‘lishi mumkin. Bitta loyiha davomida har bir belgi, rang va navigatsiya yo‘lini o‘zgartirish o‘qitish talablarini oshirishi va ishga o‘tish xavfini kuchaytirishi mumkin.

Muvozanatli yondashuv tanish jarayonlar o‘rtasidagi aloqalarni saqlab qolish bilan birga, signallar taqdimoti va navigatsiyani yaxshilaydi.

Teglarni ajratib olish muhandislik ish paketi sifatida ko‘rib chiqilishi kerak

Manba materiallar Bailey teg ma’lumotlarini CSV formatiga eksport qilish imkoniyatini ko‘rsatadi. Biroq unda tasdiqlangan universal protsedura keltirilmagan.

Shu sababli bitta eksport buyrug‘i to‘liq va toza HMI ma’lumotlar bazasini yaratadi, deb taxmin qilmaslik kerak.

Teglar haqidagi ma’lumotlarning mumkin bo‘lgan manbalari:

• Symphony konfiguratsiya ma’lumotlar bazalari.

• Mavjud ekran ta’riflari.

• Kontroller konfiguratsiyasi va muhandislik yozuvlari.

• Bailey aloqa serveri ma’lumotlar bazalari.

• OPC serverining ko‘rib chiqish funksiyalari.

• Signallar konfiguratsiyasi fayllari.

• Tarixiy ma’lumotlar bazalari.

• Chop etilgan yoki arxivlangan teglar ro‘yxatlari.

• Obyekt muhandislik jadvallari.

OPC orqali ko‘rib chiqish server Bailey tizimi bilan aloqa o‘rnatgandan keyin amaliy boshlang‘ich nuqtani taqdim etishi mumkin.

U teg nomlari, element identifikatorlari, tavsiflar, sifat holati va joriy qiymatlarni taqdim etishi mumkin. Ayrim serverlar ko‘rib chiqilgan nomlar makonini eksport qilishni ham qo‘llab-quvvatlaydi.

Biroq OPC nomlar makoni yangi HMI uchun zarur bo‘lgan barcha maydonlarni o‘z ichiga olmasligi mumkin.

Signallar ustuvorligi, muhandislik cheklovlari, ekran guruhlanishi, operator izohlari, buyruqlar xavfsizligi va uskunalar o‘rtasidagi bog‘liqliklar boshqa joyda saqlanishi mumkin.

Ba’zi OPC serverlari teglarni original Symphony nomlaridan farq qiladigan, avtomatik yaratilgan nomlar bilan taqdim etadi.

Loyiha kamida quyidagilarni o‘z ichiga olgan nazorat qilinadigan teglar reyestrini yaratishi kerak:

• Asl teg nomi.

• Yangi HMI teg nomi.

• OPC elementi identifikatori.

• Tavsif.

• Ma’lumotlar turi.

• O‘qish yoki yozish ruxsati.

• Muhandislik birliklari.

• Masshtablash ma’lumotlari.

• Signal chegaralari va ustuvorligi.

• Yangilanish tezligi.

• Bog‘langan ekran.

• Tekshiruv holati.

• Sinov natijasi.

Ushbu asosiy reyestr eski va yangi tizimlar o‘rtasidagi muvofiqlashtirish yozuvi bo‘ladi.

Teglar soni aloqa uchun yagona talab emas

Muvaffaqiyatli ko‘rib chiqish testi OPC arxitekturasi to‘liq HMI’ni qo‘llab-quvvatlay olishini isbotlamaydi.

Muhandislar faol teglar soni, so‘ralgan yangilanish tezligi, o‘zgarish chastotasi, signallar faolligi, buyruqlar trafigi va serverlarning zaxiraligini baholashi kerak.

Tizimda o‘n minglab sozlangan teglar bo‘lishi mumkin. Ularning faqat bir qismi bir vaqtning o‘zida operator ekranlarida faol bo‘lishi mumkin.

Server va HMI real sharoitlarga mos ravishda sinovdan o‘tkazilishi kerak.

Muhim unumdorlik tekshiruvlari quyidagilarni o‘z ichiga oladi:

• Murakkab ekran ochilishi uchun zarur vaqt.

• Dala qiymati o‘zgarishi bilan HMI animatsiyasi o‘rtasidagi kechikish.

• Hodisalar ko‘payib ketganda signallarni yetkazish.

• Talab etilgan namuna olish tezligida trendlarni yig‘ish.

• Buyruqni bajarish va qayta aloqa vaqti.

• Tarmoq uzilishidan keyingi tiklanish.

• Zaxira serverlar o‘rtasida zaxiralashga o‘tish.

• Kontroller qayta ishga tushirilgandan keyingi xatti-harakat.

• Aloqa uzilgandagi sifat holati.

• CPU, xotira va tarmoq yuklamasi.

Buyruqlarga alohida e’tibor berish kerak.

OPC orqali qiymatlarni o‘qish nisbatan oson bo‘lishi mumkin. Qiymatlarni xavfsiz yozish uchun kirishni nazorat qilish, buyruqlarni tekshirish, qayta aloqa tasdig‘i va aloqa uzilishlarini to‘g‘ri boshqarish talab etiladi.

Jamoa faqat bitta namunaviy tegni emas, operator buyruqlarining barcha turlarini sinab ko‘rishi kerak.

ABB Symphony Plus yanada keng rivojlanish yo‘lini taqdim etadi

O‘rnatilgan Bailey tizimi uchun OPC’ni almashtirish yagona yo‘nalish emas.

ABB Symphony Plus’ni eski Bailey, INFI 90, Harmony Rack va Symphony o‘rnatmalari uchun rivojlanish platformasi sifatida taqdim etishda davom etmoqda.

Bosqichma-bosqich ABB modernizatsiyasi o‘rnatilgan boshqaruv va I/O arxitekturasining ayrim qismlarini saqlab qolishi, shu bilan birga yangi operator, muhandislik, tarmoq, kontroller yoki I/O komponentlarini joriy etishi mumkin.

Bu yo‘nalish tashkilot mustaqil HMI almashtirishdan ko‘ra ishlab chiqaruvchi tomonidan qo‘llab-quvvatlanadigan ekspluatatsiya davri strategiyasini istaganida jozibador bo‘lishi mumkin.

Loyiha avvalo operator muhitini modernizatsiya qilishi mumkin. Kontrollerlar va I/O vositalari ularning ekspluatatsiya davri yoki amaliy qiymati almashtirishni oqlamaguncha ishlashda qolishi mumkin.

Keyingi bosqichlarda aloqa, kontrollerlar, muhandislik vositalari va dala interfeyslarini ko‘rib chiqish mumkin.

Aniq migratsiya arxitekturasi o‘rnatilgan tizim avlodiga bog‘liq.

Bailey INFI 90, INFI 90 OPEN, Network 90, Harmony, Symphony va Symphony Plus o‘rnatmalari bir xil interfeyslardan foydalanmaydi.

Modul nomlari va tarmoq terminologiyasi obyekt chizmalari hamda apparat vositalari inventarizatsiyasi asosida tekshirilishi kerak.

Mavjud boshqaruv qatlamini qo‘llab-quvvatlayotgan tashkilotlar zaxira qamrovi, ekspluatatsiya davri qo‘llab-quvvatlovi va bosqichma-bosqich modernizatsiyani rejalashtirishda mavjud ABB Bailey INFI 90 va Network 90 komponentlarini ham ko‘rib chiqishi mumkin.

Ushbu ichki havola dolzarb, chunki modernizatsiya loyihalari ko‘pincha muhandislik, sinov va bosqichma-bosqich o‘tish vaqtida eski tizimning ishlashda davom etishini talab qiladi.

Ushbu o‘tish davrida mos zaxira kontrollerlar, aloqa modullari, quvvat manbalari va I/O modullarini saqlash xavfni kamaytirishi mumkin.

Maxsus yoki ochiq manbali HMI mumkin, ammo egalik qilishni talab etadi

Maxsus HMI ochiq manbali yoki tijoriy dasturiy ta’minot freymvorklari yordamida ishlab chiqilishi mumkin.

Manba materialida VMS muhitida ishlaydigan server hamda Qt asosidagi zamonaviy klient tilga olingan. Bunday arxitekturalar server tomonidagi ma’lumotlar ulanishini operator klientidan ajratishi mumkin.

Bu yo‘nalish moslashuvchanlikni ta’minlashi va bitta HMI ishlab chiqaruvchisiga qaramlikdan qochish imkonini berishi mumkin.

Bu, shuningdek, uzoq muddatli dasturiy ta’minot ishlab chiqish majburiyatiga aylanishi mumkin.

Tashkilot quyidagilarga egalik qilishi yoki ularni qo‘llab-quvvatlashi kerak:

• Aloqa serveri.

• Teglar ma’lumotlar bazasi.

• Klient ilovasi.

• Grafik freymvork.

• Signalizatsiyani qayta ishlash.

• Arxivator bilan integratsiya.

• Foydalanuvchini autentifikatsiya qilish.

• Kiberxavfsizlik yangilanishlari.

• Joriy etish va versiyalarni boshqarish.

• Hujjatlashtirish va o‘qitish.

Qt, Python, C++, veb-texnologiyalar yoki boshqa freymvorklar imkoniyatli sanoat interfeyslarini yaratishi mumkin. Qiyinchilik texnologik jarayon grafikasini chizishda emas.

Qiyinchilik — aloqa uzilishlari, server qayta ishga tushishi, signalizatsiya toshqinlari, foydalanuvchi o‘zgarishlari va zavoddagi noodatiy sharoitlarda to‘g‘ri ishlaydigan ishonchli operator tizimini yaratishdir.

Maxsus platforma faqat tashkilotda barqaror muhandislik jamoasi yoki uzoq muddatli ishonchli integrator mavjud bo‘lgandagina tanlanishi kerak.

Litsenziyalash texnik yo‘nalishning amaliy yoki amaliy emasligini belgilashi mumkin

Eski sanoat dasturiy ta’minoti ko‘pincha apparat identifikatorlari, Ethernet manzillari, litsenziya ma’lumotlar bazalari, elektron kalitlar yoki yetkazib beruvchi tomonidan berilgan avtorizatsiya kalitlariga bog‘langan litsenziyalash mexanizmlaridan foydalanadi.

Klonlangan tizim to‘g‘ri yuklanishi mumkin, ammo virtual apparat identifikatori o‘zgargani sababli Symphony ilovasini ishga tushirishdan bosh tortishi mumkin.

Migratsiya inventarizatsiyasi quyidagilarni o‘z ichiga olishi kerak:

• OpenVMS operatsion tizimi litsenziyalari.

• Bailey Symphony ilovasi litsenziyalari.

• Ma’lumotlar bazasi litsenziyalari.

• Tarmoq va aloqa litsenziyalari.

• Emulyator litsenziyalari.

• HMI va OPC nuqtalari soni uchun litsenziyalar.

• Tarixchi tizim litsenziyalari.

• Zaxiralash variantlari.

• Muhandislik mijozlari litsenziyalari.

• Ishlash muhiti mijozlari litsenziyalari.

Yakuniy platformani tanlashdan oldin yozma tasdiq olinishi kerak.

Huquqiy jihatdan litsenziya mavjud bo‘lmasa, texnik muvofiqlik ishga joriy etiladigan yechimni yaratmaydi.

Kiberxavfsizlik almashtirish dizayniga singdirilishi kerak

Eski AlphaStation tizimlari ko‘pincha zamonaviy sanoat kiberxavfsizligi amaliyotlari standartga aylanishidan oldin o‘rnatilgan.

Ular cheklangan masofaviy ulanishga ega izolyatsiyalangan tarmoqlarda ishlashi mumkin. Ularni Windows serverlari, zamonaviy SCADA mijozlari, OPC serverlari va Ethernet infratuzilmasi bilan almashtirish hujum yuzasini o‘zgartiradi.

Yangi arxitektura boshqaruv, server, muhandislik va korporativ tarmoq zonalarini alohida belgilashi kerak.

Fayervollar faqat zarur aloqa yo‘llariga ruxsat berishi kerak. Masofaviy ulanish boshqariladigan autentifikatsiya va qayd etishdan foydalanishi lozim.

Operator hisoblari rollarga asoslangan ruxsatlardan foydalanishi kerak. Muhandislik funksiyalari har bir HMI mijozidan foydalanish uchun mavjud bo‘lmasligi kerak.

OPC orqali yozish huquqi faqat bunga muhtoj teglar va stansiyalar bilan cheklanishi kerak.

Dizayn shuningdek quyidagilarni ham qamrab olishi kerak:

• Operatsion tizimni yangilash.

• Antivirus yoki ilovalarni nazorat qilish.

• Zaxiralash va tiklash.

• Vaqtni sinxronlashtirish.

• Xavfsizlik jurnallarini yuritish.

• Olinadigan tashuvchilarni nazorat qilish.

• Yetkazib beruvchining masofaviy ko‘magi.

• OPC UA uchun sertifikatlarni boshqarish.

• Hisoblar hayotiy siklini boshqarish.

Kiberxavfsizlik nazoratlari zavoddagi hodisalar vaqtida operatorlarning javob berishiga to‘sqinlik qilmasligi kerak. Dizayn himoya, mavjudlik va deterministik ishlash o‘rtasida muvozanatni ta’minlashi lozim.

Migratsiya dalillarga asoslangan inventarizatsiyadan boshlanishi kerak

Yo‘nalishni tanlashdan oldin muhandislar mavjud tizimni batafsil hujjatlashtirishlari kerak.

Inventarizatsiya barcha to‘rtta AlphaStation’ni o‘z ichiga olishi va ularning konfiguratsiyalari haqiqatan ham bir xil ekanini ko‘rsatishi kerak.

Qayd:

• AlphaStation modeli va protsessor konfiguratsiyasi.

• Xotira sig‘imi.

• Disk turi va mantiqiy jildlar.

• OpenVMS versiyasi va tuzatishlar darajasi.

• O‘rnatilgan Bailey dasturiy ta’minoti versiyalari.

• Qatlamli mahsulotlar va ma’lumotlar bazalari.

• Grafik qurilmalari va displey o‘lchamlari.

• Tarmoq adapterlari.

• Ketma-ket interfeyslar.

• Bailey aloqa qurilmalari.

• Tugun nomlari va manzillari.

• Ishga tushirish buyruqlari protseduralari.

• Litsenziya fayllari.

• Zaxira protseduralari.

• Operator stansiyasi zaxirasi.

• Ulangan printerlar va tashqi qurilmalar.

• Tarixiy ma’lumotlar va alarm ma’lumotlarini saqlash.

Jamoa har bir ekranning skrinshotlarini ham to‘plashi kerak. Dinamik holatlar imkon qadar suratga olinishi kerak.

Oddiy, to‘xtagan, ishlayotgan, alarmlangan, bloklangan, mahalliy, qo‘lda, avtomatik va aloqa uzilgan holatlarni qayd eting.

Yangi ekranlar sinovdan o‘tkazilganda bu dalillar juda muhim.

Stend tizimi majburiy

Hech bir modernizatsiya yo‘li birinchi marta amaldagi ishlab chiqarish tizimida sinovdan o‘tkazilmasligi kerak.

Stend muhiti aloqa va operator funksiyalarini tekshirish uchun o‘rnatilgan arxitekturaning yetarli qismini takrorlashi kerak.

Emulyator loyihasi uchun stendda klonlangan OpenVMS Alpha muhiti va taklif etilayotgan emulyator konfiguratsiyasi bo‘lishi kerak.

OPC loyihasi uchun u tanlangan aloqa serveri, HMI dasturi, namunaviy grafikalar hamda xavfsiz Bailey sinov tuguniga yoki simulyatsiya qilingan ma’lumotlar manbasiga kirishni o‘z ichiga olishi kerak.

Stend sinovi quyidagilarni tekshirishi kerak:

• Tizimni yuklash va ilovani ishga tushirish.

• Bailey tizimi bilan aloqa.

• Foydalanish mumkin bo‘lgan teglarning umumiy soni.

• O‘qish va yozish operatsiyalari.

• Teglarni masshtablash va muhandislik birliklari.

• Alarm hosil bo‘lishi va tasdiqlanishi.

• Trendlarni yig‘ish.

• Ekran animatsiyasi.

• Buyruqlar xavfsizligi.

• Printer va hisobot funksiyalari.

• Server qayta ishga tushirilgandagi xatti-harakat.

• Tarmoq ishlamay qolgandagi xatti-harakat.

• Zaxiralilik va nosozlikda zaxira tizimga o‘tish.

• Zaxiradan tiklash.

• Operatorning javob berish vaqti.

Sinov natijalari ekspluatatsiya, boshqaruv muhandisligi, texnik xizmat ko‘rsatish va kiberxavfsizlik vakillari tomonidan guvohlik bilan tasdiqlanishi kerak.

Parallel ishlash o‘tish xavfini kamaytiradi

Almashtirilayotgan tizim dastlab joriy etilayotgan davrda original AlphaStation qurilmalari mavjud bo‘lib turishi kerak.

Yangi HMI muhandislar qiymatlar, alarmlar, trendlar va buyruqlarni taqqoslayotgan paytda parallel ishlashi mumkin.

Parallel ishlash eski stansiya olib tashlanishidan oldin nomuvofiqliklarni aniqlash imkonini beradi.

Jamoa quyidagilarni solishtirib, muvofiqlashtirishi kerak:

• Ekranda ko‘rsatiladigan jarayon qiymatlari.

• Holat ko‘rsatkichlari.

• Alarm ustuvorliklari.

• Alarm vaqt tamg‘alari.

• Buyruq natijalari.

• Trend qiymatlari.

• Uskuna rejimi.

• Aloqa sifati.

• Xavfsizlik ruxsatlari.

Har bir farq ham xato degani emas. Yangi tizim masshtablash yoki alarmlarni taqdim etishning yaxshilangan usullaridan foydalanishi mumkin.

Har bir farq baribir tushuntirilishi va tasdiqlanishi kerak.

Eski stansiyalar yangi HMI guvohlar ishtirokidagi obyektni qabul qilish sinovidan va kelishilgan ekspluatatsiya davridan muvaffaqiyatli o‘tguniga qadar qayta tiklanadigan holatda qolishi kerak.

To‘g‘ri migratsiya yo‘lini tanlash

Quyidagi hollarda Alpha emulyatsiyasini tanlang:

Mavjud Symphony ilovasi o‘zgartirilmasdan qolishi kerak. Manba kodi mavjud emas. Operator grafikasi murakkab. Qayta tayyorlashni minimallashtirish kerak. Bailey aloqa interfeysi emulyator arxitekturasi tomonidan qo‘llab-quvvatlanishi mumkin.

Quyidagi hollarda OpenVMS x86 migratsiyasini tanlang:

Talab qilinadigan ilovalar x86-64 uchun mavjud yoki qayta kompilyatsiya qilinishi mumkin. Manba kodi va muhandislik bilimlari saqlanib qolgan. Tashkilot OpenVMS tizimini saqlab qolgan holda, qo‘llab-quvvatlanadigan x86 muhitiga o‘tishni xohlaydi.

Quyidagi holatlarda OPC’ni qayta platformalashni tanlang:

INFI 90 kontrolleri va I/O qatlamlari ishonchli bo‘lib qolmoqda. Tashkilot zamonaviy HMI platformasini istaydi. Displeylar, signallar, teglar va buyruq mantiqini qayta yaratish hamda tasdiqlash uchun muhandislik resurslari mavjud.

Quyidagi holatlarda ABB evolyutsiya yo‘lini tanlang:

Tashkilot kengroq, yetkazib beruvchi tomonidan qo‘llab-quvvatlanadigan modernizatsiya dasturini istaydi. Kelajakdagi bosqichlar operator tizimlari, muhandislik vositalari, tarmoq interfeyslari, kontrollerlar va I/O’ni o‘z ichiga olishi mumkin.

Quyidagi holatlarda maxsus HMI’ni tanlang:

Tashkilotning maxsus talablari mavjud bo‘lib, u uzoq muddatli dasturiy ta’minot ishlab chiqish, sinovdan o‘tkazish, kiberxavfsizlik va hayotiy sikl texnik xizmatini qo‘llab-quvvatlay oladi.

Quyidagi holatlarda mavjud tizimni vaqtincha saqlab turing:

Migratsiya interfeyslari hali ham noaniq. Zaxira nusxalari to‘liq emas. Litsenziyalash masalasi hal qilinmagan. Teglar ma’lumotlar bazalari mavjud emas. Stenddagi sinovlar hozircha Bailey bilan aloqa yo‘lini takrorlay olmaydi.

Bosqichma-bosqich modernizatsiya qilishning amaliy rejasi

1-bosqich: Mavjud muhitni saqlab qoling.

Har bir AlphaStation’ning tasdiqlangan disk tasviri zaxira nusxalarini yarating. Apparat ta’minoti, dasturiy ta’minot, tarmoq, litsenziyalash va ishga tushirish tafsilotlarini qayd eting. Imkon qadar tiklashni sinang.

2-bosqich: Aloqa arxitekturasini aniqlang.

Har bir Symphony stansiyasi INFI 90 bilan aynan qanday aloqa qilishini hujjatlashtiring. Interfeys emulyatsiya qilinishi yoki qo‘llab-quvvatlanadigan server bilan almashtirilishi mumkinligini tasdiqlang.

3-bosqich: Konsepsiyani isbotlovchi loyihani yarating.

Bitta klonlangan stansiyani Alpha emulyatorida sinang yoki bitta OPC serverini namunaviy Bailey tuguniga ulang.

4-bosqich: Teglar bosh ro‘yxatini yarating.

Kontroller teglari, OPC element identifikatorlari, o‘lchov birliklari, buyruqlar, signallar va displeydan foydalanish ma’lumotlarini muvofiqlashtiring.

5-bosqich: Namunaviy displeylarni qayta yarating.

Turli animatsiya, signal, buyruq va trend talablariga ega bo‘lgan bir nechta ekranlarni tanlang.

6-bosqich: Stenddagi qabul sinovlarini yakunlang.

Barcha teglarni yuklash, aloqa uzilishi, serverni qayta ishga tushirish, signal portlashlari, buyruqlar xatti-harakati va zaxiradan tiklashni sinang.

7-bosqich: Parallel ravishda joriy qiling.

Yangi va eski HMI’larni birgalikda ishlating. Qiymatlar va operatorlarning javoblarini taqqoslang.

8-bosqich: Guvohlar ishtirokidagi o‘tishni amalga oshiring.

Tasdiqlangan sinov tartibidan foydalaning. AlphaStation’larni zaxira variant sifatida mavjud holda saqlang.

9-bosqich: Eskirgan apparat ta’minotidan bosqichma-bosqich voz keching.

Uzoq muddatli qabul qilish jarayoni yakunlanmaguncha asl disk tasvirlari, konfiguratsiya yozuvlari, litsenziyalar yoki apparat ta’minotini yo‘q qilmang.

Ko‘p so‘raladigan savollar

OpenVMS AlphaStation diski bevosita zamonaviy kompyuterga klonlanishi mumkinmi?

Yo‘q. Disk tasvirida Alpha mashina kodi mavjud va Alpha bilan mos keluvchi apparat ta’minotini talab qiladi. Zamonaviy x86 kompyuter uni bevosita yuklay olmaydi. Disk tasviri mos keluvchi Alpha apparatiga yoki Alpha emulyatoriga tiklanishi kerak.

VMware yoki VirtualBox OpenVMS’ni ishga tushira oladimi?

Ular qo‘llab-quvvatlanadigan OpenVMS x86-64 versiyalarini ishga tushira oladi. Ular eski OpenVMS Alpha o‘rnatilmasini x86 ilovasiga aylantirmaydi. OpenVMS Alpha uchun Alpha emulyatsiyasi talab etiladi.

Asl Symphony displeylarini saqlab qolish mumkinmi?

To‘liq Alpha muhiti mos keluvchi emulyator ostida ishlasa, ularni odatda saqlab qolish mumkin. Boshqa HMI platformasiga o‘tilganda esa ularni odatda qo‘lda qayta yaratish talab etiladi.

OPC serveri har bir Bailey tegini avtomatik ravishda eksport qiladimi?

Shart emas. OPC brauzeri foydali nomlar maydonini taqdim etishi mumkin, biroq signalizatsiya konfiguratsiyasi, ekranlar o‘rtasidagi bog‘lanishlar, buyruqlar, tavsiflar va muhandislik metama’lumotlari qo‘shimcha ajratib olish hamda muvofiqlashtirishni talab qilishi mumkin.

GE CIMPLICITY yagona o‘rinbosar HMI hisoblanadimi?

Yo‘q. Bu mumkin bo‘lgan platformalardan biri bo‘lib, manbada keltirilgan amaliy misolda uchraydi. Yakuniy tanlov aloqa ko‘magiga, zaxiralashga, litsenziyalashga, kiberxavfsizlikka, muhandislik resurslariga va operator talablariga bog‘liq bo‘lishi kerak.

Alpha’dan Itanium’ga migratsiya qilish hali ham maqsadga muvofiqmi?

Bu zarur dasturiy ta’minot faqat Integrity tizimlari uchun mavjud bo‘lganda yoki mavjud Integrity infratuzilmasi allaqachon qo‘llab-quvvatlanayotganda o‘zini oqlashi mumkin. Odatda bu kuchli uzoq muddatli modernizatsiya strategiyasidan ko‘ra o‘tish yo‘li hisoblanadi.

INFI 90 kontrollerlari va I/O qurilmalari o‘rnatilganicha qolishi mumkinmi?

Ha, agar ular hali ham ishonchli bo‘lsa va tanlangan aloqa arxitekturasi ularni qo‘llab-quvvatlasa. HMI modernizatsiyasini kontrollerlar va I/O qurilmalarini almashtirishdan alohida yakunlash mumkin.

Eski AlphaStation qurilmalari qayta ishga tushirilgandan keyin darhol olib tashlanishi kerakmi?

Yo‘q. Yangi operator muhiti funksional, unumdorlik va amaliy foydalanish bo‘yicha qabul qilish sinovlaridan o‘tguniga qadar ular sinovdan o‘tkazilgan zaxira variant sifatida mavjud bo‘lishi kerak.

To‘g‘ri yechim nimani saqlab qolish kerakligiga bog‘liq

Ko‘plab eski HMI rejalaridagi asosiy texnik xato operator stansiyasiga oddiy kompyuter sifatida qarashdir.

OpenVMS Alpha va Bailey Symphony ishlayotgan AlphaStation to‘liq apparat va dasturiy ta’minot muhitidir. Uning protsessor arxitekturasi, operatsion tizimi, aloqa interfeyslari, ilova binar fayllari, litsenziyalari, grafikasi va boshqaruv tizimi ulanishlari o‘zaro chambarchas bog‘liq.

Disk kloni ma’lumotlarni saqlab qoladi. U muhitni boshqa arxitekturaga o‘girmaydi.

To‘liq Symphony o‘rnatmasi o‘zgarishsiz saqlanishi kerak bo‘lsa, Alpha emulyatsiyasi eng to‘g‘ridan-to‘g‘ri yo‘lni taqdim etadi.

Ilovalarni ko‘chirish yoki qayta yaratish mumkin bo‘lsa, OpenVMS x86-64 zamonaviy operatsion tizimiga o‘tish yo‘lini taqdim etadi.

INFI 90 boshqaruv qatlami qimmatli bo‘lib qolsa, biroq operator qatlami almashtirilishi kerak bo‘lsa, OPC platformasini qayta tashkil etish amaliy yo‘lni taqdim etadi.

Tashkilot HMI doirasidan tashqarida modernizatsiya qilishni istasa, ABB Symphony Plus evolyutsiyasi bosqichma-bosqich kengroq strategiyani ta’minlashi mumkin.

Yakuniy qaror tekshirilgan inventarizatsiya, aloqa interfeyslarini o‘rganish, litsenziyalarni ko‘rib chiqish, konsepsiyani amalda tekshirish, stend sinovi va amaliyotda kuzatiladigan qabul qilish jarayonidan so‘ng qabul qilinishi kerak.

Nolga teng kuch sarflab almashtirishning imkoni yo‘q. Biroq mavjud jarayonlarni boshqarish tizimiga kiritilgan investitsiyalarni himoya qilgan holda, eskirgan AlphaStation qurilmalariga qaramlikni bartaraf etish imkonini beradigan bir nechta nazorat qilinadigan migratsiya yo‘llari mavjud.