Memodenkan HMI Bailey INFI 90 Symphony yang Berjalan pada OpenVMS Alpha

Memodenkan HMI Tanpa Menggantikan Keseluruhan Sistem INFI 90

Banyak sistem Bailey INFI 90 terus beroperasi dengan boleh dipercayai berdekad-dekad selepas pemasangan asalnya. Pengawal, modul komunikasi, unit penamatan dan I/O medan sistem tersebut mungkin masih melaksanakan fungsi kawalan yang diperlukan.

Masalah kitar hayat yang paling mendesak selalunya terletak di atas lapisan pengawal.

Stesen pengendali mungkin bergantung pada perkakasan AlphaStation yang semakin usang, penyesuai grafik yang tidak lagi disokong, peranti storan lapuk dan persekitaran perisian OpenVMS Alpha lama. Alat ganti semakin sukar diperoleh, manakala jurutera OpenVMS dan Bailey Symphony yang berpengalaman semakin berkurangan.

Contoh yang dipertimbangkan di sini merangkumi empat stesen kerja AlphaStation 255. Setiap stesen menjalankan OpenVMS Alpha dan mengehoskan fungsi antara muka pengendali Bailey Symphony untuk sistem kawalan teragih Bailey INFI 90.

Objektifnya tidak semestinya menggantikan keseluruhan DCS. Objektif yang lebih praktikal ialah menghapuskan kebergantungan pada perkakasan AlphaStation yang semakin usang sambil mengekalkan pengawal yang stabil, pendawaian medan, modul I/O, logik kawalan dan operasi proses.

Perbezaan itu mengubah strategi pemodenan.

Projek ini pada asasnya ialah migrasi antara muka pengendali dan platform pengkomputeran. Ia hanya menjadi migrasi DCS penuh apabila kitar hayat pengawal, keperluan keselamatan siber, objektif pengeluaran atau keadaan sokongan mewajarkan penggantian lapisan kawalan yang lebih rendah.

Terdapat beberapa laluan pemodenan yang mungkin. Walau bagaimanapun, laluan-laluan ini mengekalkan bahagian sistem sedia ada yang berbeza.

Emulator Alpha boleh mengekalkan hampir keseluruhan persekitaran perisian. Migrasi OpenVMS x86 mengekalkan keluarga sistem pengendalian tersebut tetapi memerlukan migrasi aplikasi. Penggantian HMI berasaskan OPC mengekalkan lapisan pengawal sambil membina semula antara muka pengendali. Strategi evolusi ABB boleh memodenkan seni bina Symphony yang lebih luas secara berperingkat.

Tiada laluan yang patut digambarkan sebagai penggantian PC yang mudah.

Rajah 1. Tiga laluan pemodenan utama boleh mengekalkan bahagian yang berbeza daripada pelaburan Bailey INFI 90 dan Symphony yang telah dipasang.

Mengapa Pengklonan Cakera AlphaStation Sahaja Tidak Mencukupi

Pengklonan cakera berguna untuk mengekalkan persekitaran OpenVMS Alpha yang telah dipasang. Ia boleh menangkap sistem pengendalian, fail aplikasi, konfigurasi peranti, akaun pengguna, perisian Bailey, pangkalan data, grafik dan tetapan khusus tapak.

Walau bagaimanapun, pengklonan cakera tidak menukar perisian Alpha menjadi perisian x86.

Sistem pengendalian yang diklon masih mengandungi arahan pemproses Alpha. Kernel, pemuat but, pustaka sistem, aplikasi dan pemacu perkakasannya dibina untuk seni bina Alpha.

PC moden standard menggunakan pemproses x86-64. Ia juga menyediakan pengawal storan, peranti rangkaian, struktur gangguan, perkakasan grafik, antara muka perisian tegar dan bas peranti persisian yang berbeza.

VMware, VirtualBox, Hyper-V dan hipervisor x86 konvensional memayakan perkakasan yang serasi dengan x86. Ia biasanya tidak menterjemah arahan pemproses Alpha kepada arahan x86.

Oleh itu, meletakkan imej cakera OpenVMS Alpha di dalam mesin maya x86 biasa tidak menjadikan imej tersebut boleh dibut.

Mesin maya mungkin menyediakan cakera maya, penyesuai rangkaian maya dan peranti grafik maya. OpenVMS Alpha masih menjangkakan pemproses Alpha dan peranti era Alpha yang disokong.

Sebab itulah dua konsep mesti kekal berasingan:

Pemayaan biasanya menyediakan perkakasan maya menggunakan seni bina pemproses yang sama seperti hos.

Emulasi merentas seni bina menghasilkan semula pemproses dan persekitaran perkakasan lain dalam perisian.

OpenVMS Alpha memerlukan pendekatan kedua apabila binari Alpha asal dan sistem pengendalian mesti kekal tidak berubah.

Oleh itu, pengklonan cakera boleh dilaksanakan dalam tiga situasi terhad.

Yang pertama ialah pemulihan ke model AlphaStation yang sama dengan storan dan peranti persisian yang serasi.

Yang kedua ialah pemulihan ke sistem Alpha lain yang disokong selepas melengkapkan perubahan peranti dan konfigurasi yang diperlukan.

Yang ketiga ialah pemulihan ke dalam emulator Alpha yang menghasilkan semula persekitaran AlphaServer atau AlphaStation yang serasi.

Pengklonan sahaja tidak menyelesaikan masalah seni bina. Persekitaran sasaran masih mesti memahami dan melaksanakan arahan mesin Alpha.

Emulasi Alpha Mengekalkan Sebahagian Terbesar Pelaburan Sedia Ada

Emulasi Alpha biasanya merupakan laluan yang paling kurang mengganggu apabila perisian Symphony sedia ada mesti terus beroperasi tanpa perubahan kod sumber.

Emulator Alpha berjalan pada perkakasan x86 moden tetapi menyajikan sistem Alpha maya kepada OpenVMS. Sistem pengendalian dan aplikasi asal terus melihat persekitaran perkakasan yang serasi dengan Alpha.

Produk seperti CHARON-AXP direka untuk tujuan ini. Emulator menggantikan pemproses Alpha fizikal, seni bina memori, pengawal storan, penyesuai Ethernet dan peranti lain yang disokong dengan setara yang ditakrifkan oleh perisian.

Pelayan x86 menjalankan Windows atau Linux sebagai persekitaran hos. Emulator Alpha berjalan di atas hos tersebut. OpenVMS Alpha kemudiannya berjalan di dalam sistem Alpha yang diemulasikan.

Pendekatan ini berbeza daripada memindahkan OpenVMS ke x86.

Pemasangan OpenVMS Alpha asal kekal sebagai pemasangan Alpha. Binari Bailey Symphony kekal sebagai binari Alpha. Emulator menterjemah atau menghasilkan semula tingkah laku perkakasan Alpha yang diperlukan.

Ini dapat mengekalkan:

• Sistem pengendalian OpenVMS Alpha yang dipasang.

• Aplikasi Bailey Symphony sedia ada.

• Grafik operator dan pangkalan data paparan.

• Konfigurasi penggera dan fail sejarah.

• Akaun pengguna dan prosedur arahan.

• Utiliti khusus tapak sedia ada.

• Antara muka aplikasi yang bergantung pada persekitaran Alpha.

• Aliran kerja operator yang sebaliknya memerlukan latihan semula.

Migrasi praktikal biasanya melibatkan penciptaan imej atau sandaran cakera Alpha asal yang telah disahkan. Data tersebut dipulihkan ke dalam bekas cakera maya yang digunakan oleh emulator.

Konfigurasi emulator mesti menghasilkan semula ciri CPU, memori, cakera, rangkaian dan peranti persisian yang sesuai. Pasukan ini mungkin juga perlu memetakan port bersiri atau antara muka rangkaian fizikal melalui sistem hos.

Emulasi Alpha boleh mengurangkan kebergantungan pada perkakasan fizikal usang dengan ketara. Emulasi ini juga boleh memudahkan sandaran kerana fail cakera maya boleh disalin menggunakan infrastruktur storan moden.

Walau bagaimanapun, istilah “tanpa perubahan” hendaklah digunakan dengan berhati-hati.

Kod aplikasi mungkin kekal tidak berubah, tetapi persekitaran masih memerlukan kejuruteraan. Pemetaan peranti mesti diperiksa. Antara muka rangkaian mesti dikonfigurasikan. Lesen OpenVMS dan lesen aplikasi mesti disemak.

Emulator juga mesti diuji dengan antara muka komunikasi Bailey yang digunakan di tapak tersebut.

Aplikasi OpenVMS generik mungkin beroperasi dengan betul, manakala antara muka DCS khusus gagal kerana bergantung pada penyesuai rangkaian, antara muka bas, peranti bersiri atau tingkah laku pemasaan tertentu.

Oleh itu, konfigurasi tepat AlphaStation 255 mesti diinventori sebelum memilih profil emulator.

Antara Muka Komunikasi Bailey ialah Ujian Emulasi Kritikal

Persoalan emulasi yang paling penting bukanlah sama ada OpenVMS berjaya mencapai gesaan log masuk.

Persoalan penting ialah sama ada stesen yang diemulasikan berkomunikasi dengan betul dengan sistem Bailey INFI 90 dalam keadaan operasi penuh.

Antara muka tersebut mungkin bergantung pada Ethernet, komunikasi bersiri, antara muka rangkaian Bailey atau perkakasan komunikasi khusus. Konfigurasi tapak boleh berbeza dengan ketara.

Sebelum membuat keputusan untuk menggunakan emulasi Alpha, jurutera hendaklah mendokumenkan:

• Antara muka rangkaian fizikal yang dipasang pada setiap AlphaStation.

• Protokol komunikasi yang digunakan antara Symphony dan INFI 90.

• Nama peranti yang ditetapkan dalam OpenVMS.

• Alamat rangkaian dan takrifan nod.

• Perkhidmatan DECnet, TCP/IP, LAT atau proprietari yang diperlukan.

• Tetapan port bersiri jika berkenaan.

• Sebarang kunci lesen luaran atau dongel perkakasan.

• Tingkah laku redundansi dan pengambilalihan kegagalan antara stesen operator.

• Keperluan penyegerakan masa.

• Fungsi grafik dan papan kekunci yang digunakan oleh operator.

Pembekal emulator mungkin menyokong peranti Ethernet Alpha dan storan yang biasa digunakan. Namun, hal itu tidak secara automatik mengesahkan sokongan untuk setiap antara muka Bailey proprietari.

Jika HMI sedia ada bergantung pada penyesuai fizikal khusus yang tidak boleh divirtualkan, laluan emulator mungkin memerlukan get laluan komunikasi alternatif.

Oleh itu, projek ini harus merangkumi ujian bangku menggunakan stesen yang diklon dan akses kepada rangkaian Bailey yang mewakili keadaan sebenar.

Ujian itu mesti merangkumi lebih daripada pembacaan tag statik. Pengendali harus mengesahkan nilai masa nyata, arahan, penggera, pengakuan, trend, navigasi paparan, pencetakan, pengendalian peristiwa dan pemulihan stesen.

Prestasi juga harus diuji semasa lonjakan penggera dan aktiviti kemas kini tag yang tinggi.

OpenVMS x86-64 Merupakan Laluan Migrasi yang Berbeza

OpenVMS moden tersedia untuk seni bina x86-64. Ia boleh beroperasi dalam persekitaran tervirtualisasi yang disokong pada pelayan moden.

Ini mewujudkan pilihan migrasi tambahan yang tidak tersedia semasa banyak perbincangan pemodenan INFI 90 terdahulu.

Walau bagaimanapun, OpenVMS x86-64 tidak menjalankan binari OpenVMS Alpha secara langsung seolah-olah binari tersebut ialah aplikasi x86 asli.

Persekitaran aplikasi mesti dimigrasikan.

Kod sumber mungkin perlu dipindahkan, disemak, dikompil, dipautkan dan diuji untuk x86-64. Pustaka pihak ketiga dan produk berlapis juga mesti tersedia untuk versi sasaran.

Persoalan utama ialah sama ada perisian Bailey Symphony yang dipasang mempunyai versi OpenVMS yang serasi dengan x86.

Jika vendor perisian tidak pernah mengeluarkan aplikasi tersebut untuk OpenVMS x86-64, pemindahan sistem pengendalian sahaja tidak mengekalkan HMI.

Program yang dibangunkan di tapak mungkin boleh dipindahkan apabila kod sumber dan persekitaran binaannya masih tersedia. Aplikasi komersial tertutup biasanya tidak boleh dibina semula tanpa sokongan vendor.

Laluan ini mungkin masih praktikal untuk pelayan data tersuai, sejarawan, utiliti, laporan dan aplikasi integrasi yang berjalan bersama HMI Symphony.

Ia kurang berkemungkinan mengekalkan persekitaran pengendali Symphony proprietari yang lama tanpa keluaran aplikasi yang disokong.

Penilaian migrasi OpenVMS x86 harus mengenal pasti:

• Setiap boleh laku yang dipasang dan produk berlapis.

• Kod sumber dan prosedur binaan yang tersedia.

• Kebergantungan pada pengkompil dan masa jalan.

• Produk pangkalan data dan format fail.

• Pustaka komunikasi proprietari.

• Kebergantungan pada grafik atau sistem tetingkap.

• Ketersediaan lesen untuk x86-64.

• Perubahan yang diperlukan akibat perbezaan seni bina.

• Andaian prestasi dan pemasaan.

Laluan ini mempunyai potensi jangka panjang yang lebih kukuh berbanding peralihan daripada Alpha kepada seni bina perkakasan lain yang telah dihentikan. Ia boleh menempatkan beban kerja OpenVMS yang serasi pada infrastruktur virtualisasi x86 yang disokong.

Namun begitu, ia harus dihuraikan sebagai projek migrasi aplikasi, bukan projek pengklonan cakera.

Mengapa Migrasi Itanium Biasanya Merupakan Pilihan Peralihan

OpenVMS juga dikeluarkan untuk pelayan HPE Integrity yang menggunakan seni bina Itanium.

Alat migrasi dan kaedah kejuruteraan tersedia untuk memindahkan sesetengah aplikasi Alpha ke OpenVMS Integrity. Ini pernah menyediakan laluan yang disokong untuk beralih daripada perkakasan Alpha yang semakin usang.

Walau bagaimanapun, hari ini perkakasan Itanium sendiri merupakan platform legasi.

Perpindahan daripada Alpha ke Integrity mungkin menghapuskan satu kebergantungan perkakasan usang sambil mewujudkan kebergantungan yang lain. Pelayan, alat ganti, antara muka storan dan kepakaran pakar yang sesuai akan terus menjadi semakin sukar diperoleh.

Itanium masih boleh relevan apabila tapak sudah memiliki infrastruktur Integrity yang disokong. Ia juga mungkin relevan apabila produk berlapis yang diperlukan tersedia untuk Integrity tetapi tidak untuk x86-64.

Bagi projek pemodenan baharu, laluan ini secara amnya perlu dinilai sebagai laluan keserasian perantaraan.

Kes perniagaan mesti menerangkan sebab perpindahan ke Integrity lebih baik berbanding emulasi Alpha, migrasi OpenVMS x86 atau penggunaan semula platform HMI.

Penggunaan Semula Platform OPC Mengekalkan Lapisan Kawalan

Penggunaan semula platform OPC menggantikan lapisan antara muka pengendali sambil mengekalkan pengawal INFI 90 dan I/O medan sedia ada.

Pelayan komunikasi menyambungkan sistem Bailey dan mendedahkan tag proses kepada platform HMI atau SCADA moden.

HMI baharu mengendalikan paparan, penggera, trend, keselamatan, arahan pengendali, laporan dan perkhidmatan stesen kerja.

Laluan ini menghapuskan kebergantungan pada aplikasi pengendali Symphony asal. Ia juga mengelakkan keperluan menjalankan OpenVMS Alpha pada stesen pengendali baharu.

Seni bina ini lazimnya merangkumi:

• Pengawal dan I/O Bailey INFI 90 sedia ada.

• Antara muka komunikasi Bailey yang serasi.

• Pelayan data OPC DA, OPC UA atau khusus vendor.

• Platform HMI atau SCADA moden.

• Stesen kerja pengendali dan kejuruteraan.

• Perkhidmatan sejarah data, pelaporan dan analisis penggera pilihan.

Contoh lapangan yang dirujuk dalam bahan sumber menggunakan pelayan OPC RoviSys dengan GE CIMPLICITY. Sistem yang dilaporkan beroperasi dengan jayanya, tetapi projek tersebut memerlukan pembinaan semula paparan pengendali dan logik animasi.

Contoh ini tidak harus ditafsirkan sebagai cadangan produk automatik untuk setiap pemasangan INFI 90.

Pelayan yang dipilih mesti menyokong rangkaian Bailey, modul komunikasi, generasi pengawal, bilangan tag, kadar kemas kini, keperluan redundansi dan fungsi arahan khusus di tapak.

Perkara yang sama terpakai pada platform HMI.

GE CIMPLICITY ialah salah satu platform HMI/SCADA perusahaan yang boleh digunakan. Sistem lain juga mungkin sesuai jika menyediakan kesalinghubungan OPC, grafik, penggera, penskripan, redundansi, keselamatan dan sokongan kitar hayat yang diperlukan.

Rajah 2. Migrasi berasaskan OPC mengekalkan lapisan kawalan INFI 90 sambil menggantikan persekitaran pengendali Symphony legasi.

Kesalinghubungan OPC Tidak Menukar Skrin Sedia Ada

Pelayan OPC menyediakan kesalinghubungan data. Ia biasanya tidak menukar paparan HMI lama kepada format HMI baharu.

Skrin Symphony asal mungkin mengandungi grafik statik, simbol dinamik, perubahan warna, nilai berangka, graf bar, penunjuk penggera, butang navigasi, kawalan arahan, trend dan templat fungsi tersuai.

Elemen ini mesti dihasilkan semula dalam HMI sasaran.

Paparan ringkas boleh dilukis semula secara langsung. Paparan kompleks mungkin mengandungi skrip atau ungkapan tersembunyi yang tidak kelihatan dengan serta-merta.

Jurutera mesti memahami cara setiap objek beranimasi memperoleh dan memproses datanya.

Simbol injap mungkin tidak hanya mengikut satu tag output. Warna dan kedudukannya mungkin bergantung pada maklum balas terbuka, maklum balas tertutup, keadaan arahan, status interlok, kualiti komunikasi dan mod peralatan.

Simbol motor mungkin menggunakan tag berasingan untuk arahan mula, maklum balas sedang berjalan, status berhenti, trip, kawalan setempat, keadaan penyelenggaraan, permisif dan penyekatan penggera.

Oleh itu, memindahkan hanya grafik yang kelihatan boleh menghasilkan HMI yang kelihatan betul tetapi berfungsi secara tidak betul.

Pasukan migrasi mesti mendokumenkan maksud fungsi di sebalik setiap elemen paparan.

Kerja ini merangkumi:

• Memetakan setiap objek dinamik kepada sumber datanya.

• Menghasilkan semula ungkapan animasi.

• Mengesahkan pengesahan arahan dan keselamatan.

• Membina semula navigasi dan hierarki paparan.

• Menghasilkan semula kelas dan keutamaan penggera.

• Mengesahkan unit kejuruteraan dan ketepatan perpuluhan.

• Membina semula trend sejarah dan masa nyata.

• Menguji keadaan komunikasi yang tidak sah, tidak pasti dan gagal.

• Menghasilkan semula mesej dan panduan operator.

• Menggantikan fon dan simbol yang tidak disokong.

Oleh itu, usaha yang diperlukan ditentukan oleh kerumitan paparan, bukan hanya bilangan paparan.

HMI Moden Tidak Sepatutnya Menyalin Setiap Paparan Legasi Secara Membuta Tuli

Pembinaan semula secara manual memberikan peluang untuk menambah baik antara muka operator.

Grafik HMI legasi sering menggunakan warna terang untuk peralatan normal, rajah proses yang padat, paip hiasan dan petunjuk penggera yang tidak konsisten.

Konvensyen ini mungkin munasabah ketika sistem asal dibangunkan. Namun, konvensyen tersebut tidak semestinya ideal untuk amalan bilik kawalan semasa.

Projek pemodenan sepatutnya menyemak:

• Hierarki paparan.

• Keterlihatan penggera.

• Konsistensi navigasi.

• Persembahan keadaan peralatan.

• Penggunaan warna.

• Kebolehcapaian trend.

• Keperluan tindak balas operator.

• Resolusi skrin dan susun atur stesen kerja.

• Kebolehcapaian dan kebolehbacaan.

Keadaan operasi normal sepatutnya kekal tenang secara visual. Warna yang terang harus mengenal pasti keadaan tidak normal yang memerlukan perhatian.

Operator sepatutnya dapat beralih daripada gambaran keseluruhan loji kepada unit yang terjejas, panel hadapan peralatan, trend, sejarah penggera dan paparan diagnostik tanpa navigasi yang berlebihan.

Namun begitu, reka bentuk semula yang berlebihan boleh mewujudkan risiko lain.

Operator mungkin telah menggunakan skrin asal selama bertahun-tahun. Mengubah setiap simbol, warna dan laluan navigasi dalam projek yang sama boleh meningkatkan keperluan latihan dan risiko pertukaran sistem.

Pendekatan seimbang mengekalkan hubungan proses yang biasa sambil menambah baik persembahan penggera dan navigasi.

Pengekstrakan Tag Mesti Dianggap sebagai Pakej Kerja Kejuruteraan

Bahan sumber menimbulkan kemungkinan mengeksport data tag Bailey ke CSV. Ia tidak menyediakan prosedur sejagat yang disahkan.

Oleh itu, tidak boleh diandaikan bahawa satu arahan eksport akan menghasilkan pangkalan data HMI yang lengkap dan bersih.

Sumber maklumat tag yang mungkin termasuk:

• Pangkalan data konfigurasi Symphony.

• Takrif paparan sedia ada.

• Rekod konfigurasi dan kejuruteraan pengawal.

• Pangkalan data pelayan komunikasi Bailey.

• Fungsi penyemakan imbas pelayan OPC.

• Fail konfigurasi penggera.

• Pangkalan data sejarah.

• Senarai tag bercetak atau diarkibkan.

• Hamparan kejuruteraan tapak.

Penyemakan imbas OPC boleh menyediakan titik permulaan yang praktikal selepas pelayan mewujudkan komunikasi dengan sistem Bailey.

Ia mungkin mendedahkan nama tag, pengecam item, perihalan, kualiti dan nilai semasa. Sesetengah pelayan juga menyokong pengeksportan ruang nama yang disemak imbas.

Walau bagaimanapun, ruang nama OPC mungkin tidak merangkumi setiap medan yang diperlukan oleh HMI baharu.

Keutamaan penggera, had kejuruteraan, pengumpulan paparan, nota operator, keselamatan arahan dan hubungan peralatan mungkin disimpan di tempat lain.

Sesetengah pelayan OPC mendedahkan tag menggunakan nama yang dijana dan berbeza daripada nama Symphony asal.

Projek harus membina induk tag terkawal yang mengandungi sekurang-kurangnya:

• Nama tag asal.

• Nama tag HMI baharu.

• Pengecam item OPC.

• Perihalan.

• Jenis data.

• Kebenaran baca atau tulis.

• Unit kejuruteraan.

• Maklumat penskalaan.

• Had dan keutamaan penggera.

• Kadar kemas kini.

• Paparan berkaitan.

• Status pengesahan.

• Keputusan ujian.

Induk ini menjadi rekod penyelarasan antara sistem lama dan sistem baharu.

Bilangan Tag Bukan Satu-satunya Keperluan Komunikasi

Ujian penyemakan imbas yang berjaya tidak membuktikan bahawa seni bina OPC boleh menyokong keseluruhan HMI.

Jurutera mesti menilai bilangan tag aktif, kadar kemas kini yang diminta, kekerapan perubahan, aktiviti penggera, trafik arahan dan redundansi pelayan.

Sistem mungkin mengandungi puluhan ribu tag yang dikonfigurasikan. Hanya sebahagiannya mungkin aktif pada paparan operator pada satu-satu masa.

Pelayan dan HMI harus diuji dalam keadaan yang realistik.

Pemeriksaan prestasi penting termasuk:

• Masa yang diperlukan untuk membuka paparan kompleks.

• Kelewatan antara perubahan medan dan animasi HMI.

• Penyampaian penggera semasa lonjakan peristiwa.

• Pengumpulan trend pada kadar pensampelan yang diperlukan.

• Masa pelaksanaan arahan dan maklum balas.

• Pemulihan selepas gangguan rangkaian.

• Pertukaran ganti antara pelayan berlebihan.

• Tingkah laku selepas pengawal dimulakan semula.

• Status kualiti semasa kegagalan komunikasi.

• Beban CPU, memori dan rangkaian.

Arahan memerlukan perhatian khusus.

Membaca nilai melalui OPC mungkin agak mudah. Menulis nilai dengan selamat memerlukan kawalan akses, pengesahan arahan, pengesahan maklum balas dan pengendalian kegagalan komunikasi yang betul.

Pasukan harus menguji setiap jenis arahan operator, bukan hanya satu tag perwakilan.

ABB Symphony Plus menyediakan laluan evolusi yang lebih luas

Penggantian OPC bukan satu-satunya laluan untuk sistem Bailey yang dipasang.

ABB terus meletakkan Symphony Plus sebagai platform evolusi untuk pemasangan Bailey, INFI 90, Harmony Rack dan Symphony yang lebih lama.

Pemodenan ABB secara berperingkat mungkin mengekalkan sebahagian seni bina kawalan dan I/O yang dipasang sambil memperkenalkan komponen operator, kejuruteraan, rangkaian, pengawal atau I/O yang lebih baharu.

Laluan ini boleh menarik apabila organisasi mahukan strategi kitar hayat yang disokong vendor dan bukannya penggantian HMI secara bebas.

Projek ini mungkin memodenkan persekitaran operator terlebih dahulu. Pengawal dan I/O boleh kekal digunakan sehingga kitar hayat atau nilai operasi masing-masing mewajarkan penggantian.

Fasa seterusnya boleh menangani komunikasi, pengawal, alat kejuruteraan dan antara muka medan.

Seni bina migrasi yang tepat bergantung pada generasi sistem yang dipasang.

Pemasangan Bailey INFI 90, INFI 90 OPEN, Network 90, Harmony, Symphony dan Symphony Plus tidak semuanya menggunakan antara muka yang sama.

Nama modul dan istilah rangkaian mesti disahkan melalui lukisan tapak dan inventori perkakasan.

Organisasi yang menyelenggara lapisan kawalan sedia ada juga boleh menyemak komponen ABB Bailey INFI 90 dan Network 90 yang tersedia ketika merancang liputan alat ganti, sokongan kitar hayat dan pemodenan berperingkat.

Pautan dalaman ini relevan kerana projek pemodenan sering memerlukan sistem lama kekal beroperasi semasa kejuruteraan, pengujian dan peralihan berperingkat.

Menyelenggara pengawal ganti, modul komunikasi, bekalan kuasa dan modul I/O yang sesuai boleh mengurangkan risiko semasa peralihan tersebut.

HMI Tersuai atau Sumber Terbuka Boleh Digunakan tetapi Memerlukan Pemilikan

HMI tersuai boleh dibangunkan menggunakan rangka kerja perisian sumber terbuka atau komersial.

Bahan sumber menyebut pelayan berasaskan VMS dengan klien moden berasaskan Qt. Seni bina jenis ini boleh mengasingkan sambungan data pada bahagian pelayan daripada klien operator.

Laluan ini boleh memberikan fleksibiliti dan mengelakkan kebergantungan pada satu vendor HMI.

Ia juga boleh menjadi komitmen pembangunan perisian jangka panjang.

Organisasi mesti memiliki atau menyelenggara:

• Pelayan komunikasi.

• Pangkalan data tag.

• Aplikasi klien.

• Rangka kerja grafik.

• Pemprosesan penggera.

• Penyepaduan historian.

• Pengesahan pengguna.

• Kemas kini keselamatan siber.

• Pelaksanaan dan kawalan versi.

• Dokumentasi dan latihan.

Qt, Python, C++, teknologi web atau rangka kerja lain boleh menghasilkan antara muka industri yang berkebolehan. Kesukarannya bukanlah melukis grafik proses.

Kesukarannya ialah mewujudkan sistem operator yang boleh dipercayai dan berfungsi dengan betul semasa kegagalan komunikasi, pelayan dimulakan semula, lambakan penggera, perubahan pengguna dan keadaan loji yang tidak normal.

Platform tersuai hanya patut dipilih apabila organisasi mempunyai pasukan kejuruteraan yang mampan atau penyepadu jangka panjang yang boleh dipercayai.

Pelesenan Boleh Menentukan Sama Ada Sesuatu Laluan Teknikal Itu Praktikal

Perisian industri legasi sering menggunakan mekanisme pelesenan yang terikat pada pengecam perkakasan, alamat Ethernet, pangkalan data lesen, dongel atau kunci kebenaran yang dikeluarkan vendor.

Sistem klon mungkin berjaya but tetapi enggan memulakan aplikasi Symphony kerana identiti perkakasan maya telah berubah.

Inventori migrasi hendaklah merangkumi:

• Lesen sistem pengendalian OpenVMS.

• Lesen aplikasi Bailey Symphony.

• Lesen pangkalan data.

• Lesen rangkaian dan komunikasi.

• Lesen emulator.

• Lesen kiraan titik HMI dan OPC.

• Lesen pengarkib sejarah.

• Pilihan lebihan.

• Lesen klien kejuruteraan.

• Lesen klien masa jalan.

Pengesahan bertulis hendaklah diperoleh sebelum platform akhir dipilih.

Keserasian teknikal tanpa ketersediaan lesen yang sah tidak menghasilkan penyelesaian yang boleh digunakan.

Keselamatan Siber Mesti Direka Bentuk Ke Dalam Penggantian

Sistem AlphaStation lama kerap dipasang sebelum amalan keselamatan siber industri moden menjadi standard.

Sistem tersebut mungkin beroperasi pada rangkaian terpencil dengan akses jauh yang terhad. Menggantikannya dengan pelayan Windows, klien SCADA moden, pelayan OPC dan infrastruktur Ethernet mengubah permukaan serangan.

Seni bina baharu hendaklah mentakrifkan zon rangkaian kawalan, pelayan, kejuruteraan dan perusahaan yang berasingan.

Tembok api hendaklah membenarkan laluan komunikasi yang diperlukan sahaja. Akses jauh hendaklah menggunakan pengesahan dan rakaman yang diuruskan.

Akaun pengendali hendaklah menggunakan kebenaran berasaskan peranan. Fungsi kejuruteraan tidak sepatutnya tersedia daripada setiap klien HMI.

Akses tulis OPC hendaklah dihadkan kepada tag dan stesen yang memerlukannya.

Reka bentuk itu juga hendaklah menangani:

• Penampalan sistem pengendalian.

• Antivirus atau kawalan aplikasi.

• Sandaran dan pemulihan.

• Penyegerakan masa.

• Pengelogan keselamatan.

• Kawalan media boleh tanggal.

• Sokongan jauh vendor.

• Pengurusan sijil untuk OPC UA.

• Pengurusan kitar hayat akaun.

Kawalan keselamatan siber tidak boleh menghalang pengendali daripada bertindak balas semasa kejadian di loji. Reka bentuk hendaklah mengimbangi perlindungan dengan ketersediaan dan operasi yang deterministik.

Migrasi Hendaklah Bermula Dengan Inventori Berasaskan Bukti

Sebelum memilih laluan, jurutera hendaklah mendokumentasikan sistem sedia ada secara terperinci.

Inventori hendaklah merangkumi keempat-empat AlphaStation dan mengenal pasti sama ada konfigurasinya benar-benar serupa.

Rekod:

• Model AlphaStation dan konfigurasi pemproses.

• Kapasiti memori.

• Jenis cakera dan volum logik.

• Versi dan tahap tampalan OpenVMS.

• Versi perisian Bailey yang dipasang.

• Produk berlapis dan pangkalan data.

• Perkakasan grafik dan resolusi paparan.

• Penyesuai rangkaian.

• Antara muka bersiri.

• Perkakasan komunikasi Bailey.

• Nama dan alamat nod.

• Prosedur arahan permulaan.

• Fail lesen.

• Prosedur sandaran.

• Lebihan stesen pengendali.

• Pencetak yang disambungkan dan peranti luaran.

• Pengekalan data sejarah dan penggera.

Pasukan juga harus mengumpulkan tangkapan skrin bagi setiap paparan. Keadaan dinamik harus dirakam apabila boleh.

Rekodkan keadaan normal, berhenti, berjalan, berpenggera, disekat, setempat, manual, automatik dan kegagalan komunikasi.

Bukti ini penting apabila skrin baharu diuji.

Sistem Bangku Adalah Wajib

Tiada laluan pemodenan harus diuji buat kali pertama pada sistem pengeluaran langsung.

Persekitaran bangku harus meniru seni bina terpasang secukupnya untuk mengesahkan komunikasi dan fungsi pengendali.

Bagi projek emulator, bangku ujian harus mengandungi persekitaran OpenVMS Alpha yang diklon dan konfigurasi emulator yang dicadangkan.

Bagi projek OPC, ia harus merangkumi pelayan komunikasi yang dipilih, perisian HMI, grafik perwakilan dan akses kepada nod ujian Bailey yang selamat atau sumber data simulasi.

Ujian bangku harus mengesahkan:

• But sistem dan permulaan aplikasi.

• Komunikasi dengan sistem Bailey.

• Jumlah tag yang boleh diakses.

• Operasi baca dan tulis.

• Penskalaan tag dan unit kejuruteraan.

• Penjanaan dan pengakuan penggera.

• Pengumpulan trend.

• Animasi paparan.

• Keselamatan arahan.

• Fungsi pencetak dan laporan.

• Tingkah laku semasa pelayan dimulakan semula.

• Tingkah laku semasa kegagalan rangkaian.

• Lebihan dan failover.

• Pemulihan sandaran.

• Masa tindak balas pengendali.

Keputusan ujian harus disaksikan oleh wakil operasi, kejuruteraan kawalan, penyelenggaraan dan keselamatan siber.

Operasi Selari Mengurangkan Risiko Pertukaran

AlphaStation asal harus kekal tersedia semasa pelaksanaan awal sistem pengganti.

HMI baharu boleh beroperasi secara selari sementara jurutera membandingkan nilai, penggera, trend dan arahan.

Operasi selari membolehkan ketidakpadanan dikenal pasti sebelum stesen legasi dialih keluar.

Pasukan perlu menyelaraskan:

• Nilai proses yang dipaparkan.

• Petunjuk status.

• Keutamaan penggera.

• Cap masa penggera.

• Hasil arahan.

• Nilai trend.

• Mod peralatan.

• Kualiti komunikasi.

• Keizinan keselamatan.

Tidak semua perbezaan menunjukkan ralat. Sistem baharu mungkin menggunakan penskalaan atau persembahan penggera yang dipertingkatkan.

Setiap perbezaan masih perlu dijelaskan dan diluluskan.

Stesen legasi harus kekal boleh dipulihkan sehingga HMI baharu lulus ujian penerimaan tapak yang disaksikan dan tempoh operasi yang dipersetujui.

Memilih Laluan Migrasi yang Betul

Pilih emulasi Alpha apabila:

Aplikasi Symphony sedia ada mesti kekal tanpa perubahan. Kod sumber tidak tersedia. Grafik pengendali adalah kompleks. Latihan semula perlu diminimumkan. Antara muka komunikasi Bailey boleh disokong oleh seni bina emulator.

Pilih migrasi OpenVMS x86 apabila:

Aplikasi yang diperlukan tersedia untuk x86-64 atau boleh dibina semula. Kod sumber dan pengetahuan kejuruteraan masih tersedia. Organisasi mahu mengekalkan OpenVMS sambil beralih kepada persekitaran x86 yang disokong.

Pilih penggunaan semula platform OPC apabila:

Pengawal INFI 90 dan lapisan I/O masih boleh dipercayai. Organisasi mahukan platform HMI moden. Sumber kejuruteraan tersedia untuk membina semula dan mengesahkan paparan, penggera, tag serta logik arahan.

Pilih laluan evolusi ABB apabila:

Organisasi mahukan program pemodenan yang lebih luas dan disokong vendor. Fasa seterusnya mungkin merangkumi sistem pengendali, alat kejuruteraan, antara muka rangkaian, pengawal dan I/O.

Pilih HMI tersuai apabila:

Organisasi mempunyai keperluan khusus dan boleh menyokong pembangunan perisian, ujian, keselamatan siber dan penyelenggaraan kitar hayat untuk jangka panjang.

Kekalkan sistem sedia ada buat sementara apabila:

Antara muka migrasi masih tidak jelas. Sandaran tidak lengkap. Pelesenan belum diselesaikan. Pangkalan data tag tidak tersedia. Ujian di bangku uji masih belum dapat menghasilkan semula laluan komunikasi Bailey.

Pelan Pemodenan Berfasa yang Praktikal

Fasa 1: Kekalkan persekitaran sedia ada.

Cipta sandaran imej yang disahkan bagi setiap AlphaStation. Rekodkan butiran perkakasan, perisian, rangkaian, pelesenan dan permulaan. Uji pemulihan jika boleh.

Fasa 2: Kenal pasti seni bina komunikasi.

Dokumentasikan dengan tepat cara setiap stesen Symphony berkomunikasi dengan INFI 90. Sahkan sama ada antara muka itu boleh diemulasikan atau digantikan oleh pelayan yang disokong.

Fasa 3: Bina bukti konsep.

Uji satu stesen yang diklon pada emulator Alpha atau sambungkan satu pelayan OPC kepada nod Bailey yang mewakili sistem.

Fasa 4: Cipta induk tag.

Selaraskan tag pengawal, pengecam item OPC, unit kejuruteraan, arahan, penggera dan penggunaan paparan.

Fasa 5: Bina semula paparan yang mewakili sistem.

Pilih beberapa skrin yang mengandungi keperluan animasi, penggera, arahan dan trend yang berbeza.

Fasa 6: Lengkapkan penerimaan di bangku uji.

Uji pemuatan tag penuh, kegagalan komunikasi, mula semula pelayan, lonjakan penggera, tingkah laku arahan dan pemulihan sandaran.

Fasa 7: Gunakan secara selari.

Kendalikan HMI baharu dan lama secara serentak. Bandingkan nilai dan tindak balas pengendali.

Fasa 8: Laksanakan peralihan dengan pemerhatian.

Gunakan prosedur ujian yang diluluskan. Pastikan AlphaStation tersedia sebagai sandaran.

Fasa 9: Hentikan penggunaan perkakasan legasi secara beransur-ansur.

Jangan musnahkan imej asal, rekod konfigurasi, lesen atau perkakasan sehingga penerimaan jangka panjang selesai.

Soalan Lazim

Bolehkah cakera OpenVMS AlphaStation diklon terus ke PC moden?

Tidak. Imej tersebut mengandungi kod mesin Alpha dan memerlukan perkakasan yang serasi dengan Alpha. PC x86 moden tidak boleh but terus daripadanya. Imej tersebut mesti dipulihkan pada perkakasan Alpha yang serasi atau emulator Alpha.

Bolehkah VMware atau VirtualBox menjalankan OpenVMS?

Paparan tersebut boleh menjalankan keluaran OpenVMS x86-64 yang disokong. Paparan tersebut tidak menukar pemasangan OpenVMS Alpha lama kepada aplikasi x86. OpenVMS Alpha memerlukan emulasi Alpha.

Bolehkah paparan Symphony asal dikekalkan?

Ia biasanya boleh dikekalkan apabila keseluruhan persekitaran Alpha dijalankan di bawah emulator yang serasi. Ia biasanya memerlukan penciptaan semula secara manual apabila berpindah ke platform HMI lain.

Adakah pelayan OPC mengeksport setiap tag Bailey secara automatik?

Tidak semestinya. Penyemakan imbas OPC mungkin menyediakan ruang nama yang berguna, tetapi konfigurasi penggera, hubungan paparan, arahan, penerangan, dan metadata kejuruteraan mungkin memerlukan pengekstrakan serta penyelarasan tambahan.

Adakah GE CIMPLICITY satu-satunya HMI pengganti?

Tidak. Ia ialah salah satu platform yang mungkin dan muncul dalam contoh lapangan yang disediakan bersama sumber. Pemilihan muktamad hendaklah bergantung pada sokongan komunikasi, redundansi, pelesenan, keselamatan siber, sumber kejuruteraan, dan keperluan operator.

Adakah migrasi daripada Alpha ke Itanium masih berbaloi?

Ia mungkin wajar apabila perisian yang diperlukan hanya tersedia untuk sistem Integrity atau apabila infrastruktur Integrity sedia ada sudah disokong. Secara amnya, ini ialah laluan peralihan dan bukannya strategi pemodenan jangka panjang yang paling kukuh.

Bolehkah pengawal dan I/O INFI 90 kekal dipasang?

Ya, apabila ia kekal boleh dipercayai dan seni bina komunikasi yang dipilih menyokongnya. Pemodenan HMI boleh diselesaikan secara berasingan daripada penggantian pengawal dan I/O.

Patutkah AlphaStation lama dialih keluar sejurus selepas peralihan?

Tidak. Ia hendaklah kekal tersedia sebagai sandaran yang telah diuji sehingga persekitaran operator baharu melepasi penerimaan fungsi, prestasi, dan operasi.

Penyelesaian yang Tepat Bergantung pada Perkara yang Mesti Dikekalkan

Kesilapan teknikal utama dalam banyak rancangan HMI legasi ialah menganggap stesen operator sebagai PC biasa.

AlphaStation yang menjalankan OpenVMS Alpha dan Bailey Symphony ialah persekitaran perkakasan dan perisian yang lengkap. Seni bina pemproses, sistem pengendalian, antara muka komunikasi, binari aplikasi, lesen, grafik, dan sambungan sistem kawalan saling bergantung.

Klon cakera mengekalkan data. Ia tidak menterjemahkan persekitaran tersebut kepada seni bina lain.

Emulasi Alpha menyediakan laluan paling langsung apabila keseluruhan pemasangan Symphony mesti dikekalkan tanpa perubahan.

OpenVMS x86-64 menyediakan laluan sistem pengendalian moden apabila aplikasi boleh dimigrasikan atau dibina semula.

Penyusunan semula platform OPC menyediakan laluan praktikal apabila lapisan kawalan INFI 90 masih bernilai tetapi lapisan operator perlu digantikan.

Evolusi ABB Symphony Plus dapat menyediakan strategi berperingkat yang lebih menyeluruh apabila organisasi mahu memodenkan sistem melangkaui HMI.

Keputusan muktamad hendaklah dibuat berdasarkan inventori yang disahkan, kajian antara muka komunikasi, semakan pelesenan, bukti konsep, ujian bangku, dan penerimaan operasi yang disaksikan.

Tiada pertukaran tanpa usaha. Walau bagaimanapun, terdapat beberapa laluan migrasi terkawal yang dapat melindungi pelaburan sedia ada dalam kawalan proses sambil menghapuskan kebergantungan pada perkakasan AlphaStation yang semakin usang.