Memodernisasi HMI Bailey INFI 90 Symphony yang Berjalan di OpenVMS Alpha

Memodernisasi HMI Tanpa Mengganti Seluruh Sistem INFI 90

Banyak sistem Bailey INFI 90 terus beroperasi dengan andal puluhan tahun setelah pemasangan awal. Pengendali, modul komunikasi, unit terminasi, dan I/O lapangan mungkin masih menjalankan fungsi kendali yang diperlukan.

Masalah siklus hidup yang paling mendesak sering kali berada di atas lapisan pengendali.

Stasiun operator mungkin bergantung pada perangkat keras AlphaStation yang sudah menua, adaptor grafis yang tidak lagi didukung, perangkat penyimpanan usang, dan lingkungan perangkat lunak OpenVMS Alpha lama. Suku cadang pengganti semakin sulit diperoleh, sementara teknisi OpenVMS dan Bailey Symphony yang berpengalaman semakin jarang tersedia.

Contoh yang dibahas di sini mencakup empat stasiun kerja AlphaStation 255. Setiap stasiun menjalankan OpenVMS Alpha dan menjadi tempat fungsi antarmuka operator Bailey Symphony untuk sistem kendali terdistribusi Bailey INFI 90.

Tujuannya tidak selalu harus mengganti seluruh DCS. Tujuan yang lebih praktis adalah menghilangkan ketergantungan pada perangkat keras AlphaStation yang sudah menua, sambil mempertahankan pengendali yang stabil, pengabelan lapangan, modul I/O, logika kendali, dan operasi proses.

Pembedaan tersebut mengubah strategi modernisasi.

Proyek ini terutama merupakan migrasi antarmuka operator dan platform komputasi. Proyek ini baru menjadi migrasi DCS menyeluruh ketika siklus hidup pengendali, persyaratan keamanan siber, sasaran produksi, atau kondisi dukungan membenarkan penggantian lapisan kendali yang lebih rendah.

Ada beberapa jalur modernisasi yang mungkin. Namun, jalur-jalur tersebut mempertahankan bagian yang berbeda dari sistem yang ada.

Emulator Alpha dapat mempertahankan hampir seluruh lingkungan perangkat lunak. Migrasi OpenVMS x86 mempertahankan keluarga sistem operasi, tetapi memerlukan migrasi aplikasi. Penggantian HMI berbasis OPC mempertahankan lapisan pengendali sekaligus membangun ulang antarmuka operator. Strategi evolusi ABB dapat memodernisasi arsitektur Symphony yang lebih luas secara bertahap.

Tidak ada jalur yang seharusnya digambarkan sebagai penggantian PC sederhana.

Gambar 1. Tiga jalur utama modernisasi dapat mempertahankan bagian yang berbeda dari investasi Bailey INFI 90 dan Symphony yang telah terpasang.

Mengapa Mengkloning Disk AlphaStation Saja Tidak Cukup

Kloning disk berguna untuk mempertahankan lingkungan OpenVMS Alpha yang telah terpasang. Proses ini dapat menangkap sistem operasi, berkas aplikasi, konfigurasi perangkat, akun pengguna, perangkat lunak Bailey, basis data, grafik, dan pengaturan khusus lokasi.

Namun, kloning disk tidak mengonversi perangkat lunak Alpha menjadi perangkat lunak x86.

Sistem operasi hasil kloning masih berisi instruksi prosesor Alpha. Kernel, boot loader, pustaka sistem, aplikasi, dan driver perangkat kerasnya dibuat untuk arsitektur Alpha.

PC modern standar menggunakan prosesor x86-64. PC tersebut juga menyajikan pengontrol penyimpanan, perangkat jaringan, struktur interupsi, perangkat keras grafis, antarmuka firmware, dan bus periferal yang berbeda.

VMware, VirtualBox, Hyper-V, dan hipervisor x86 konvensional memvirtualisasikan perangkat keras yang kompatibel dengan x86. Biasanya, semua itu tidak menerjemahkan instruksi prosesor Alpha menjadi instruksi x86.

Oleh karena itu, menempatkan citra disk OpenVMS Alpha di dalam mesin virtual x86 biasa tidak membuat citra tersebut dapat di-boot.

Mesin virtual dapat menyediakan disk virtual, adaptor jaringan virtual, dan perangkat grafis virtual. OpenVMS Alpha tetap mengharapkan prosesor Alpha dan perangkat yang didukung dari era Alpha.

Inilah sebabnya dua konsep harus tetap dibedakan:

Virtualisasi biasanya menyajikan perangkat keras virtual menggunakan arsitektur prosesor yang sama dengan host.

Emulasi lintas arsitektur mereproduksi prosesor dan lingkungan perangkat keras lain dalam perangkat lunak.

OpenVMS Alpha memerlukan pendekatan kedua ketika biner Alpha asli dan sistem operasi harus tetap tidak berubah.

Oleh karena itu, kloning disk dapat dilakukan dalam tiga situasi terbatas.

Yang pertama adalah pemulihan ke model AlphaStation yang sama dengan penyimpanan dan periferal yang kompatibel.

Yang kedua adalah pemulihan ke sistem Alpha lain yang didukung setelah menyelesaikan perubahan perangkat dan konfigurasi yang diperlukan.

Yang ketiga adalah pemulihan ke dalam emulator Alpha yang mereproduksi lingkungan AlphaServer atau AlphaStation yang kompatibel.

Kloning saja tidak menyelesaikan masalah arsitektur. Lingkungan target tetap harus memahami dan menjalankan instruksi mesin Alpha.

Emulasi Alpha Mempertahankan Sebagian Besar Investasi yang Ada

Emulasi Alpha biasanya merupakan jalur dengan gangguan paling kecil ketika perangkat lunak Symphony yang ada harus tetap beroperasi tanpa perubahan kode sumber.

Emulator Alpha berjalan pada perangkat keras x86 modern, tetapi menyajikan sistem Alpha virtual kepada OpenVMS. Sistem operasi dan aplikasi asli tetap melihat lingkungan perangkat keras yang kompatibel dengan Alpha.

Produk seperti CHARON-AXP dirancang untuk tujuan ini. Emulator menggantikan prosesor Alpha fisik, arsitektur memori, pengontrol penyimpanan, adaptor Ethernet, dan perangkat lain yang didukung dengan padanan yang ditentukan perangkat lunak.

Server x86 menjalankan Windows atau Linux sebagai lingkungan host. Emulator Alpha berjalan di atas host tersebut. OpenVMS Alpha kemudian berjalan di dalam sistem Alpha yang diemulasikan.

Pendekatan ini berbeda dari mem-port OpenVMS ke x86.

Instalasi OpenVMS Alpha asli tetap menjadi instalasi Alpha. Biner Bailey Symphony tetap menjadi biner Alpha. Emulator menerjemahkan atau mereproduksi perilaku perangkat keras Alpha yang diperlukan.

Hal ini dapat mempertahankan:

• Sistem operasi OpenVMS Alpha yang terpasang.

• Aplikasi Bailey Symphony yang ada.

• Grafis operator dan basis data tampilan.

• Konfigurasi alarm dan berkas historis.

• Akun pengguna dan prosedur perintah.

• Utilitas khusus lokasi yang sudah ada.

• Antarmuka aplikasi yang bergantung pada lingkungan Alpha.

• Alur kerja operator yang jika tidak demikian akan memerlukan pelatihan ulang.

Migrasi praktis biasanya melibatkan pembuatan citra atau cadangan terverifikasi dari disk Alpha asli. Data tersebut dipulihkan ke kontainer disk virtual yang digunakan emulator.

Konfigurasi emulator harus mereproduksi karakteristik CPU, memori, disk, jaringan, dan periferal yang sesuai. Tim mungkin juga perlu memetakan port serial fisik atau antarmuka jaringan melalui sistem host.

Emulasi Alpha dapat secara signifikan mengurangi ketergantungan pada perangkat keras fisik yang usang. Emulasi ini juga dapat menyederhanakan pencadangan karena berkas disk virtual dapat disalin menggunakan infrastruktur penyimpanan modern.

Namun, istilah “tanpa perubahan” harus digunakan dengan hati-hati.

Kode aplikasi mungkin tetap tidak berubah, tetapi lingkungannya tetap memerlukan rekayasa. Pemetaan perangkat harus diperiksa. Antarmuka jaringan harus dikonfigurasi. Lisensi OpenVMS dan lisensi aplikasi harus ditinjau.

Emulator juga harus diuji dengan antarmuka komunikasi Bailey yang digunakan di lokasi tersebut.

Aplikasi OpenVMS generik mungkin dapat beroperasi dengan benar, sementara antarmuka DCS khusus gagal karena bergantung pada adaptor jaringan, antarmuka bus, perangkat serial, atau perilaku pewaktuan tertentu.

Oleh karena itu, konfigurasi AlphaStation 255 yang tepat harus diinventarisasi sebelum memilih profil emulator.

Antarmuka Komunikasi Bailey Adalah Pengujian Emulasi yang Kritis

Pertanyaan emulasi yang paling penting bukanlah apakah OpenVMS dapat mencapai prompt login.

Pertanyaan pentingnya adalah apakah stasiun yang diemulasikan dapat berkomunikasi dengan benar dengan sistem Bailey INFI 90 dalam kondisi operasi penuh.

Antarmuka tersebut mungkin bergantung pada Ethernet, komunikasi serial, antarmuka jaringan Bailey, atau perangkat keras komunikasi khusus. Konfigurasi di setiap lokasi dapat sangat bervariasi.

Sebelum berkomitmen pada emulasi Alpha, teknisi harus mendokumentasikan:

• Antarmuka jaringan fisik yang terpasang di setiap AlphaStation.

• Protokol komunikasi yang digunakan antara Symphony dan INFI 90.

• Nama perangkat yang ditetapkan dalam OpenVMS.

• Alamat jaringan dan definisi node.

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

• Pengaturan port serial jika berlaku.

• Kunci lisensi eksternal atau dongle perangkat keras apa pun.

• Perilaku redundansi dan failover antarstasiun operator.

• Persyaratan sinkronisasi waktu.

• Fungsi grafis dan keyboard yang digunakan operator.

Pemasok emulator mungkin mendukung perangkat Ethernet dan penyimpanan Alpha yang umum. Namun, hal itu tidak otomatis mengonfirmasi dukungan untuk setiap antarmuka Bailey proprietari.

Jika HMI yang ada bergantung pada adaptor fisik khusus yang tidak dapat divirtualisasi, pendekatan emulator mungkin memerlukan gateway komunikasi alternatif.

Oleh karena itu, proyek harus mencakup pengujian di bangku menggunakan stasiun kloning dan akses ke jaringan Bailey yang representatif.

Pengujian harus mencakup lebih dari sekadar pembacaan tag statis. Operator harus memverifikasi nilai waktu nyata, perintah, alarm, pengakuan, tren, navigasi tampilan, pencetakan, penanganan peristiwa, dan pemulihan stasiun.

Kinerja juga harus diuji selama lonjakan alarm dan aktivitas pembaruan tag yang tinggi.

OpenVMS x86-64 Merupakan Jalur Migrasi yang Berbeda

OpenVMS modern tersedia untuk arsitektur x86-64. Sistem ini dapat beroperasi dalam lingkungan tervirtualisasi yang didukung pada server modern.

Hal ini menciptakan opsi migrasi tambahan yang belum tersedia selama banyak pembahasan modernisasi INFI 90 sebelumnya.

Namun, OpenVMS x86-64 tidak dapat menjalankan biner OpenVMS Alpha secara langsung seolah-olah biner tersebut merupakan aplikasi x86 asli.

Lingkungan aplikasi harus dimigrasikan.

Kode sumber mungkin perlu dipindahkan, ditinjau, dikompilasi ulang, ditautkan, dan diuji untuk x86-64. Pustaka pihak ketiga dan produk berlapis juga harus tersedia untuk versi target.

Pertanyaan utamanya adalah apakah perangkat lunak Bailey Symphony yang terpasang memiliki versi OpenVMS yang kompatibel dengan x86.

Jika vendor perangkat lunak tidak pernah merilis aplikasi tersebut untuk OpenVMS x86-64, memindahkan sistem operasi saja tidak akan mempertahankan HMI.

Program yang dikembangkan di lokasi mungkin dapat dipindahkan jika kode sumber dan lingkungan build-nya masih tersedia. Aplikasi komersial tertutup biasanya tidak dapat dibangun ulang tanpa dukungan vendor.

Jalur ini mungkin masih praktis untuk server data kustom, historian, utilitas, laporan, dan aplikasi integrasi yang berjalan berdampingan dengan HMI Symphony.

Kemungkinan lebih kecil untuk mempertahankan lingkungan operator Symphony proprietari lama tanpa rilis aplikasi yang didukung.

Penilaian migrasi OpenVMS x86 harus mengidentifikasi:

• Setiap executable dan produk berlapis yang terpasang.

• Ketersediaan kode sumber dan prosedur build.

• Ketergantungan pada kompiler dan runtime.

• Produk basis data dan format berkas.

• Pustaka komunikasi proprietari.

• Ketergantungan pada grafis atau sistem windowing.

• Ketersediaan lisensi untuk x86-64.

• Perubahan yang diperlukan akibat perbedaan arsitektur.

• Asumsi kinerja dan waktu.

Jalur ini memiliki potensi jangka panjang yang lebih kuat daripada berpindah dari Alpha ke arsitektur perangkat keras lain yang telah dihentikan. Jalur ini dapat menempatkan beban kerja OpenVMS yang kompatibel pada infrastruktur virtualisasi x86 yang didukung.

Namun demikian, hal ini harus dijelaskan sebagai proyek migrasi aplikasi, bukan proyek kloning disk.

Mengapa Migrasi Itanium Biasanya Merupakan Opsi Transisi

OpenVMS juga dirilis untuk server HPE Integrity yang menggunakan arsitektur Itanium.

Tersedia alat migrasi dan metode rekayasa untuk memindahkan beberapa aplikasi Alpha ke OpenVMS Integrity. Dahulu, ini menyediakan jalur yang didukung untuk beralih dari perangkat keras Alpha yang menua.

Namun, saat ini perangkat keras Itanium sendiri merupakan platform warisan.

Migrasi dari Alpha ke Integrity dapat menghilangkan satu ketergantungan perangkat keras usang sekaligus menciptakan ketergantungan lainnya. Ketersediaan server, suku cadang, antarmuka penyimpanan, dan keahlian khusus yang sesuai akan terus menurun.

Itanium masih dapat relevan jika suatu lokasi sudah memiliki infrastruktur Integrity yang didukung. Itanium juga dapat relevan jika terdapat produk berlapis yang diperlukan untuk Integrity tetapi tidak tersedia untuk x86-64.

Untuk proyek modernisasi baru, opsi ini umumnya harus dievaluasi sebagai jalur kompatibilitas perantara.

Kasus bisnis harus menjelaskan mengapa migrasi ke Integrity lebih baik daripada emulasi Alpha, migrasi OpenVMS x86, atau replatforming HMI.

Replatforming OPC Mempertahankan Lapisan Kontrol

Replatforming OPC mengganti lapisan antarmuka operator sekaligus mempertahankan pengontrol INFI 90 dan I/O lapangan yang ada.

Server komunikasi terhubung ke sistem Bailey dan mengekspos tag proses ke platform HMI atau SCADA modern.

HMI baru menangani tampilan, alarm, tren, keamanan, perintah operator, laporan, dan layanan stasiun kerja.

Rute ini menghilangkan ketergantungan pada aplikasi operator Symphony asli. Rute ini juga menghindari kebutuhan menjalankan OpenVMS Alpha pada stasiun operator baru.

Arsitektur ini umumnya mencakup:

• Pengontrol dan I/O Bailey INFI 90 yang ada.

• Antarmuka komunikasi Bailey yang kompatibel.

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

• Platform HMI atau SCADA modern.

• Stasiun kerja operator dan teknisi.

• Layanan historian, pelaporan, dan analisis alarm opsional.

Contoh lapangan yang dirujuk dalam materi sumber menggunakan server OPC RoviSys dengan GE CIMPLICITY. Sistem yang dilaporkan berhasil beroperasi, tetapi proyek tersebut memerlukan rekonstruksi tampilan operator dan logika animasi.

Contoh ini tidak boleh ditafsirkan sebagai rekomendasi produk otomatis untuk setiap instalasi INFI 90.

Server yang dipilih harus mendukung jaringan Bailey tertentu, modul komunikasi, generasi pengontrol, jumlah tag, laju pembaruan, persyaratan redundansi, dan fungsi perintah di lokasi tersebut.

Hal yang sama berlaku untuk platform HMI.

GE CIMPLICITY adalah salah satu kemungkinan platform HMI/SCADA tingkat perusahaan. Sistem lain juga dapat digunakan jika menyediakan konektivitas OPC, grafik, alarm, skrip, redundansi, keamanan, dan dukungan sepanjang siklus hidup yang diperlukan.

Gambar 2. Migrasi berbasis OPC mempertahankan lapisan kontrol INFI 90 sekaligus mengganti lingkungan operator Symphony lama.

Konektivitas OPC Tidak Mengonversi Layar yang Ada

Server OPC menyediakan konektivitas data. Server ini biasanya tidak mengonversi tampilan HMI lama ke format HMI baru.

Layar Symphony asli dapat berisi grafik statis, simbol dinamis, perubahan warna, nilai numerik, grafik batang, indikator alarm, tombol navigasi, kontrol perintah, tren, dan templat fungsi khusus.

Elemen-elemen ini harus dibuat ulang dalam HMI target.

Tampilan sederhana dapat digambar ulang secara langsung. Tampilan kompleks mungkin berisi skrip atau ekspresi tersembunyi yang tidak langsung terlihat.

Insinyur harus memahami cara setiap objek beranimasi memperoleh dan memproses datanya.

Simbol katup mungkin tidak hanya mengikuti satu tag keluaran. Warna dan posisinya dapat bergantung pada umpan balik terbuka, umpan balik tertutup, status perintah, status interlock, kualitas komunikasi, dan mode peralatan.

Simbol motor mungkin menggunakan tag terpisah untuk perintah mulai, umpan balik berjalan, status berhenti, trip, kontrol lokal, status pemeliharaan, permissive, dan inhibisi alarm.

Dengan demikian, hanya memindahkan grafik yang terlihat dapat menghasilkan HMI yang tampak benar tetapi berperilaku salah.

Tim migrasi harus mendokumentasikan makna fungsional di balik setiap elemen tampilan.

Pekerjaan ini mencakup:

• Memetakan setiap objek dinamis ke sumber datanya.

• Membuat ulang ekspresi animasi.

• Memverifikasi konfirmasi perintah dan keamanan.

• Membangun ulang navigasi dan hierarki tampilan.

• Membuat ulang kelas dan prioritas alarm.

• Mengonfirmasi satuan teknik dan presisi desimal.

• Membangun ulang tren historis dan waktu nyata.

• Menguji status komunikasi yang tidak valid, tidak pasti, dan gagal.

• Mereproduksi pesan dan panduan operator.

• Mengganti font dan simbol yang tidak didukung.

Oleh karena itu, upaya yang diperlukan ditentukan oleh kompleksitas tampilan, bukan hanya jumlah tampilan.

HMI Modern Tidak Boleh Menyalin Setiap Tampilan Lama Secara Membabi Buta

Pembuatan ulang secara manual memberikan peluang untuk meningkatkan antarmuka operator.

Grafik HMI lama sering menggunakan warna cerah untuk peralatan normal, diagram proses yang padat, perpipaan dekoratif, dan indikasi alarm yang tidak konsisten.

Konvensi ini mungkin wajar ketika sistem asli dikembangkan. Namun, konvensi tersebut tidak selalu ideal untuk praktik ruang kontrol saat ini.

Proyek modernisasi harus meninjau:

• Hierarki tampilan.

• Visibilitas alarm.

• Konsistensi navigasi.

• Penyajian status peralatan.

• Penggunaan warna.

• Aksesibilitas tren.

• Persyaratan respons operator.

• Resolusi layar dan tata letak workstation.

• Aksesibilitas dan keterbacaan.

Kondisi operasi normal harus tetap tenang secara visual. Warna yang kuat harus mengidentifikasi kondisi abnormal yang memerlukan perhatian.

Operator harus dapat berpindah dari ikhtisar pabrik ke unit yang terdampak, faceplate peralatan, tren, riwayat alarm, dan tampilan diagnostik tanpa navigasi yang berlebihan.

Namun, desain ulang yang berlebihan dapat menimbulkan risiko lain.

Operator mungkin telah menggunakan layar asli selama bertahun-tahun. Mengubah setiap simbol, warna, dan jalur navigasi dalam proyek yang sama dapat meningkatkan kebutuhan pelatihan dan risiko saat peralihan.

Pendekatan yang seimbang mempertahankan hubungan proses yang sudah dikenal sekaligus meningkatkan penyajian alarm dan navigasi.

Ekstraksi Tag Harus Diperlakukan sebagai Paket Kerja Rekayasa

Materi sumber menyebutkan kemungkinan mengekspor data tag Bailey ke CSV. Materi tersebut tidak memberikan prosedur universal yang telah dikonfirmasi.

Oleh karena itu, tidak boleh diasumsikan bahwa satu perintah ekspor akan menghasilkan basis data HMI yang lengkap dan bersih.

Sumber informasi tag yang mungkin meliputi:

• Basis data konfigurasi Symphony.

• Definisi tampilan yang ada.

• Konfigurasi pengendali dan catatan teknik.

• Basis data server komunikasi Bailey.

• Fungsi penelusuran server OPC.

• Berkas konfigurasi alarm.

• Basis data historis.

• Daftar tag yang dicetak atau diarsipkan.

• Lembar kerja teknik di lokasi.

Penelusuran OPC dapat menjadi titik awal yang praktis setelah server berhasil menjalin komunikasi dengan sistem Bailey.

Namespace tersebut dapat menampilkan nama tag, pengidentifikasi item, deskripsi, kualitas, dan nilai saat ini. Beberapa server juga mendukung ekspor namespace yang ditelusuri.

Namun, namespace OPC mungkin tidak mencakup setiap bidang yang diperlukan oleh HMI baru.

Prioritas alarm, batas teknik, pengelompokan tampilan, catatan operator, keamanan perintah, dan hubungan peralatan mungkin disimpan di tempat lain.

Beberapa server OPC menampilkan tag menggunakan nama yang dibuat secara otomatis dan berbeda dari nama Symphony asli.

Proyek harus membuat master tag terkontrol yang setidaknya berisi:

• Nama tag asli.

• Nama tag HMI baru.

• Pengidentifikasi item OPC.

• Deskripsi.

• Jenis data.

• Izin baca atau tulis.

• Satuan teknik.

• Informasi penskalaan.

• Batas dan prioritas alarm.

• Laju pembaruan.

• Tampilan terkait.

• Status validasi.

• Hasil pengujian.

Master ini menjadi catatan rekonsiliasi antara sistem lama dan sistem baru.

Jumlah Tag Bukan Satu-satunya Persyaratan Komunikasi

Uji penelusuran yang berhasil tidak membuktikan bahwa arsitektur OPC dapat mendukung HMI secara keseluruhan.

Insinyur harus mengevaluasi jumlah tag aktif, laju pembaruan yang diminta, frekuensi perubahan, aktivitas alarm, lalu lintas perintah, dan redundansi server.

Sebuah sistem dapat berisi puluhan ribu tag yang dikonfigurasi. Hanya sebagian yang mungkin aktif pada tampilan operator pada satu waktu.

Server dan HMI harus diuji dalam kondisi yang realistis.

Pemeriksaan kinerja penting meliputi:

• Waktu yang diperlukan untuk membuka tampilan kompleks.

• Jeda antara perubahan di lapangan dan animasi HMI.

• Pengiriman alarm selama lonjakan kejadian.

• Pengumpulan tren pada laju pengambilan sampel yang diperlukan.

• Waktu eksekusi perintah dan penerimaan umpan balik.

• Pemulihan setelah gangguan jaringan.

• Failover antara server redundan.

• Perilaku setelah pengendali dimulai ulang.

• Status kualitas selama kegagalan komunikasi.

• Beban CPU, memori, dan jaringan.

Perintah memerlukan perhatian khusus.

Membaca nilai melalui OPC mungkin relatif sederhana. Menulis nilai dengan aman memerlukan kontrol akses, validasi perintah, konfirmasi umpan balik, dan penanganan kegagalan komunikasi yang tepat.

Tim harus menguji setiap jenis perintah operator, bukan hanya satu tag yang mewakili.

ABB Symphony Plus Menyediakan Jalur Evolusi yang Lebih Luas

Penggantian OPC bukan satu-satunya rute untuk sistem Bailey yang terpasang.

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

Modernisasi ABB secara bertahap dapat mempertahankan sebagian arsitektur kontrol dan I/O yang terpasang sekaligus memperkenalkan komponen operator, engineering, jaringan, controller, atau I/O yang lebih baru.

Rute ini dapat menarik ketika organisasi menginginkan strategi siklus hidup yang didukung vendor, bukan penggantian HMI secara independen.

Proyek ini dapat memodernisasi lingkungan operator terlebih dahulu. Controller dan I/O dapat tetap digunakan hingga siklus hidup atau nilai operasionalnya membenarkan penggantian.

Tahap-tahap selanjutnya dapat mencakup komunikasi, controller, alat engineering, dan antarmuka lapangan.

Arsitektur migrasi yang tepat bergantung pada generasi sistem yang terpasang.

Instalasi Bailey INFI 90, INFI 90 OPEN, Network 90, Harmony, Symphony, dan Symphony Plus tidak semuanya menggunakan antarmuka yang sama.

Nama modul dan terminologi jaringan harus diverifikasi dari gambar instalasi dan inventaris perangkat keras di lokasi.

Organisasi yang memelihara lapisan kontrol yang ada juga dapat meninjau komponen ABB Bailey INFI 90 dan Network 90 yang tersedia saat merencanakan cakupan suku cadang, dukungan siklus hidup, dan modernisasi bertahap.

Tautan internal ini relevan karena proyek modernisasi sering mengharuskan sistem lama tetap beroperasi selama engineering, pengujian, dan peralihan bertahap.

Memelihara controller cadangan, modul komunikasi, catu daya, dan modul I/O yang sesuai dapat mengurangi risiko selama masa transisi tersebut.

HMI Kustom atau Sumber Terbuka Memungkinkan, tetapi Memerlukan Kepemilikan

HMI kustom dapat dikembangkan menggunakan framework perangkat lunak sumber terbuka atau komersial.

Materi sumber menyebutkan server yang berada di VMS dengan klien modern berbasis Qt. Arsitektur semacam ini dapat memisahkan koneksi data sisi server dari klien operator.

Rute ini dapat memberikan fleksibilitas dan menghindari ketergantungan pada satu vendor HMI.

Hal ini juga dapat menjadi komitmen pengembangan perangkat lunak jangka panjang.

Organisasi harus memiliki atau memelihara:

• Server komunikasi.

• Basis data tag.

• Aplikasi klien.

• Framework grafis.

• Pemrosesan alarm.

• Integrasi historian.

• Autentikasi pengguna.

• Pembaruan keamanan siber.

• Deployment dan kontrol versi.

• Dokumentasi dan pelatihan.

Qt, Python, C++, teknologi web, atau framework lainnya dapat menghasilkan antarmuka industri yang mumpuni. Kesulitannya bukan menggambar grafik proses.

Kesulitannya adalah menciptakan sistem operator yang dapat diandalkan dan berfungsi dengan benar saat terjadi kegagalan komunikasi, server dimulai ulang, lonjakan alarm, perubahan pengguna, dan kondisi pabrik yang tidak normal.

Platform kustom hanya boleh dipilih jika organisasi memiliki tim engineering yang berkelanjutan atau integrator jangka panjang yang andal.

Lisensi Dapat Menentukan Apakah Suatu Rute Teknis Praktis

Perangkat lunak industri lama sering menggunakan mekanisme lisensi yang terkait dengan pengidentifikasi perangkat keras, alamat Ethernet, basis data lisensi, dongle, atau kunci otorisasi yang diterbitkan vendor.

Sistem hasil kloning mungkin dapat melakukan boot dengan benar, tetapi menolak memulai aplikasi Symphony karena identitas perangkat keras virtualnya berubah.

Inventaris migrasi harus mencakup:

• Lisensi sistem operasi OpenVMS.

• Lisensi aplikasi Bailey Symphony.

• Lisensi basis data.

• Lisensi jaringan dan komunikasi.

• Lisensi emulator.

• Lisensi jumlah titik HMI dan OPC.

• Lisensi historian.

• Opsi redundansi.

• Lisensi klien rekayasa.

• Lisensi klien runtime.

Konfirmasi tertulis harus diperoleh sebelum memilih platform akhir.

Kompatibilitas teknis tanpa ketersediaan lisensi yang sah tidak menghasilkan solusi yang dapat diterapkan.

Keamanan Siber Harus Dirancang Ke Dalam Sistem Pengganti

Sistem AlphaStation lama sering dipasang sebelum praktik keamanan siber industri modern menjadi standar.

Sistem tersebut mungkin beroperasi pada jaringan terisolasi dengan akses jarak jauh terbatas. Menggantinya dengan server Windows, klien SCADA modern, server OPC, dan infrastruktur Ethernet akan mengubah permukaan serangan.

Arsitektur baru harus menetapkan zona jaringan kontrol, server, rekayasa, dan perusahaan yang terpisah.

Firewall hanya boleh mengizinkan jalur komunikasi yang diperlukan. Akses jarak jauh harus menggunakan autentikasi terkelola dan perekaman.

Akun operator harus mengikuti izin berbasis peran. Fungsi rekayasa tidak boleh tersedia dari setiap klien HMI.

Akses tulis OPC harus dibatasi pada tag dan stasiun yang memerlukannya.

Desain juga harus menangani:

• Patching sistem operasi.

• Antivirus atau kontrol aplikasi.

• Pencadangan dan pemulihan.

• Sinkronisasi waktu.

• Pencatatan log keamanan.

• Kontrol media lepasan.

• Dukungan jarak jauh dari vendor.

• Manajemen sertifikat untuk OPC UA.

• Manajemen siklus hidup akun.

Kontrol keamanan siber tidak boleh menghalangi operator untuk merespons saat terjadi insiden di pabrik. Desain harus menyeimbangkan perlindungan dengan ketersediaan dan pengoperasian deterministik.

Migrasi Harus Dimulai Dengan Inventaris Berbasis Bukti

Sebelum memilih rute, para insinyur harus mendokumentasikan sistem yang ada secara terperinci.

Inventaris harus mencakup keempat AlphaStation dan mengidentifikasi apakah konfigurasinya benar-benar identik.

Catat:

• Model AlphaStation dan konfigurasi prosesor.

• Kapasitas memori.

• Jenis disk dan volume logis.

• Versi OpenVMS dan tingkat patch.

• Versi perangkat lunak Bailey yang terpasang.

• Produk dan basis data berlapis.

• Perangkat keras grafis dan resolusi tampilan.

• Adaptor jaringan.

• Antarmuka serial.

• Perangkat keras komunikasi Bailey.

• Nama dan alamat node.

• Prosedur perintah startup.

• Berkas lisensi.

• Prosedur pencadangan.

• Redundansi stasiun operator.

• Printer yang terhubung dan perangkat eksternal.

• Retensi data historis dan data alarm.

Tim juga harus mengumpulkan tangkapan layar dari setiap tampilan. Status dinamis harus diambil jika memungkinkan.

Catat status normal, berhenti, berjalan, beralarm, diinhibisi, lokal, manual, otomatis, dan kegagalan komunikasi.

Bukti ini sangat penting saat layar baru diuji.

Sistem Uji Wajib Disediakan

Tidak ada rute modernisasi yang boleh diuji untuk pertama kalinya pada sistem produksi aktif.

Lingkungan uji harus mereproduksi bagian arsitektur terpasang yang memadai untuk memvalidasi komunikasi dan fungsi operator.

Untuk proyek emulator, lingkungan uji harus berisi lingkungan OpenVMS Alpha hasil kloning dan konfigurasi emulator yang diusulkan.

Untuk proyek OPC, lingkungan tersebut harus mencakup server komunikasi yang dipilih, perangkat lunak HMI, grafik yang representatif, serta akses ke node uji Bailey yang aman atau sumber data simulasi.

Pengujian di lingkungan uji harus memverifikasi:

• Boot sistem dan pengaktifan aplikasi.

• Komunikasi dengan sistem Bailey.

• Jumlah total tag yang dapat diakses.

• Operasi baca dan tulis.

• Penskalaan tag dan satuan teknik.

• Pembentukan dan pengakuan alarm.

• Pengumpulan tren.

• Animasi tampilan.

• Keamanan perintah.

• Fungsi printer dan laporan.

• Perilaku saat server dimulai ulang.

• Perilaku saat jaringan gagal.

• Redundansi dan failover.

• Pemulihan cadangan.

• Waktu respons operator.

Hasil pengujian harus disaksikan oleh perwakilan operasional, rekayasa kontrol, pemeliharaan, dan keamanan siber.

Operasi Paralel Mengurangi Risiko Peralihan

AlphaStation asli harus tetap tersedia selama penerapan awal sistem pengganti.

HMI baru dapat beroperasi secara paralel sementara teknisi membandingkan nilai, alarm, tren, dan perintah.

Operasi paralel memungkinkan ketidaksesuaian diidentifikasi sebelum stasiun lama dihapus.

Tim harus merekonsiliasi:

• Nilai proses yang ditampilkan.

• Indikasi status.

• Prioritas alarm.

• Stempel waktu alarm.

• Hasil perintah.

• Nilai tren.

• Mode peralatan.

• Kualitas komunikasi.

• Izin keamanan.

Tidak setiap perbedaan menunjukkan kesalahan. Sistem baru mungkin menggunakan penskalaan atau penyajian alarm yang lebih baik.

Setiap perbedaan tetap harus dijelaskan dan disetujui.

Stasiun lama harus tetap dapat dipulihkan hingga HMI baru lulus uji penerimaan lokasi yang disaksikan dan periode operasional yang disepakati.

Memilih Jalur Migrasi yang Tepat

Pilih emulasi Alpha jika:

Aplikasi Symphony yang ada harus tetap tidak berubah. Kode sumber tidak tersedia. Grafik operator rumit. Pelatihan ulang harus diminimalkan. Antarmuka komunikasi Bailey dapat didukung oleh arsitektur emulator.

Pilih migrasi OpenVMS x86 jika:

Aplikasi yang diperlukan tersedia untuk x86-64 atau dapat dibangun ulang. Kode sumber dan pengetahuan rekayasa masih tersedia. Organisasi ingin mempertahankan OpenVMS sambil beralih ke lingkungan x86 yang didukung.

Pilih penggunaan ulang platform OPC apabila:

Pengontrol dan lapisan I/O INFI 90 tetap andal. Organisasi menginginkan platform HMI modern. Sumber daya rekayasa tersedia untuk membangun ulang dan memvalidasi tampilan, alarm, tag, serta logika perintah.

Pilih jalur evolusi ABB apabila:

Organisasi menginginkan program modernisasi yang lebih luas dan didukung vendor. Fase mendatang dapat mencakup sistem operator, alat rekayasa, antarmuka jaringan, pengontrol, dan I/O.

Pilih HMI khusus apabila:

Organisasi memiliki persyaratan khusus dan dapat mendukung pengembangan perangkat lunak, pengujian, keamanan siber, serta pemeliharaan siklus hidup jangka panjang.

Pertahankan sistem yang ada untuk sementara apabila:

Antarmuka migrasi masih belum jelas. Cadangan belum lengkap. Status lisensi belum terselesaikan. Basis data tag tidak tersedia. Pengujian di bangku uji belum dapat mereproduksi jalur komunikasi Bailey.

Rencana Modernisasi Bertahap yang Praktis

Fase 1: Pertahankan lingkungan yang ada.

Buat cadangan citra terverifikasi untuk setiap AlphaStation. Catat detail perangkat keras, perangkat lunak, jaringan, lisensi, dan proses startup. Uji pemulihan jika memungkinkan.

Fase 2: Identifikasi arsitektur komunikasi.

Dokumentasikan secara tepat cara setiap stasiun Symphony berkomunikasi dengan INFI 90. Pastikan apakah antarmuka tersebut dapat diemulasikan atau digantikan oleh server yang didukung.

Fase 3: Bangun bukti konsep.

Uji satu stasiun hasil kloning pada emulator Alpha atau hubungkan satu server OPC ke node Bailey yang representatif.

Fase 4: Buat master tag.

Cocokkan tag pengontrol, pengidentifikasi item OPC, satuan teknik, perintah, alarm, dan penggunaan tampilan.

Fase 5: Bangun ulang tampilan yang representatif.

Pilih beberapa layar yang memuat persyaratan animasi, alarm, perintah, dan tren yang berbeda.

Fase 6: Selesaikan penerimaan di bangku uji.

Uji pemuatan tag secara menyeluruh, kegagalan komunikasi, mulai ulang server, lonjakan alarm, perilaku perintah, dan pemulihan cadangan.

Fase 7: Terapkan secara paralel.

Operasikan HMI baru dan lama secara bersamaan. Bandingkan nilai dan respons operator.

Fase 8: Lakukan peralihan dengan disaksikan.

Gunakan prosedur pengujian yang disetujui. Sediakan AlphaStation sebagai cadangan.

Fase 9: Pensiunkan perangkat keras lama secara bertahap.

Jangan memusnahkan citra asli, catatan konfigurasi, lisensi, atau perangkat keras hingga penerimaan jangka panjang selesai.

Pertanyaan yang Sering Diajukan

Apakah disk OpenVMS AlphaStation dapat langsung dikloning ke PC modern?

Tidak. Citra tersebut berisi kode mesin Alpha dan memerlukan perangkat keras yang kompatibel dengan Alpha. PC x86 modern tidak dapat melakukan booting langsung dari citra tersebut. Citra harus dipulihkan ke perangkat keras Alpha yang kompatibel atau emulator Alpha.

Apakah VMware atau VirtualBox dapat menjalankan OpenVMS?

Tampilan tersebut dapat menjalankan rilis OpenVMS x86-64 yang didukung. Tampilan tersebut tidak mengonversi instalasi OpenVMS Alpha lama menjadi aplikasi x86. OpenVMS Alpha memerlukan emulasi Alpha.

Apakah tampilan Symphony asli dapat dipertahankan?

Tag tersebut biasanya dapat dipertahankan ketika seluruh lingkungan Alpha dijalankan di bawah emulator yang kompatibel. Tag tersebut biasanya harus dibuat ulang secara manual ketika berpindah ke platform HMI lain.

Apakah server OPC secara otomatis mengekspor setiap tag Bailey?

Belum tentu. Penelusuran OPC dapat menyediakan namespace yang berguna, tetapi konfigurasi alarm, hubungan tampilan, perintah, deskripsi, dan metadata teknik mungkin memerlukan ekstraksi serta rekonsiliasi tambahan.

Apakah GE CIMPLICITY satu-satunya HMI pengganti?

Tidak. Itanium adalah salah satu platform yang mungkin digunakan dan muncul dalam contoh lapangan yang diberikan oleh sumber. Pemilihan akhir harus bergantung pada dukungan komunikasi, redundansi, lisensi, keamanan siber, sumber daya teknik, dan kebutuhan operator.

Apakah migrasi dari Alpha ke Itanium masih layak?

Hal ini dapat dibenarkan jika perangkat lunak yang diperlukan hanya tersedia untuk sistem Integrity atau jika infrastruktur Integrity yang ada sudah didukung. Secara umum, ini merupakan jalur transisi, bukan strategi modernisasi jangka panjang yang paling kuat.

Apakah pengendali dan I/O INFI 90 dapat tetap terpasang?

Ya, jika perangkat tersebut tetap andal dan arsitektur komunikasi yang dipilih mendukungnya. Modernisasi HMI dapat diselesaikan secara terpisah dari penggantian pengendali dan I/O.

Haruskah AlphaStation lama segera disingkirkan setelah peralihan?

Tidak. Perangkat tersebut harus tetap tersedia sebagai cadangan teruji sampai lingkungan operator baru lulus penerimaan fungsional, kinerja, dan operasional.

Solusi yang Tepat Bergantung pada Hal yang Harus Dipertahankan

Kesalahan teknis utama dalam banyak rencana HMI lama adalah memperlakukan stasiun operator sebagai PC biasa.

AlphaStation yang menjalankan OpenVMS Alpha dan Bailey Symphony merupakan lingkungan perangkat keras dan perangkat lunak yang lengkap. Arsitektur prosesor, sistem operasi, antarmuka komunikasi, biner aplikasi, lisensi, grafis, dan koneksi sistem kendalinya saling bergantung.

Kloning disk mempertahankan data. Tindakan ini tidak menerjemahkan lingkungan tersebut ke arsitektur lain.

Emulasi Alpha menyediakan jalur paling langsung ketika seluruh instalasi Symphony harus tetap berjalan tanpa perubahan.

OpenVMS x86-64 menyediakan jalur sistem operasi modern ketika aplikasi dapat dimigrasikan atau dibangun ulang.

Penerapan ulang platform OPC menyediakan jalur praktis ketika lapisan kendali INFI 90 masih bernilai, tetapi lapisan operator perlu diganti.

Evolusi ABB Symphony Plus dapat menyediakan strategi bertahap yang lebih luas ketika organisasi ingin melakukan modernisasi melampaui HMI.

Keputusan akhir harus didasarkan pada inventaris terverifikasi, studi antarmuka komunikasi, tinjauan lisensi, bukti konsep, pengujian di bangku, dan penerimaan operasional yang disaksikan.

Tidak ada penggantian tanpa upaya sama sekali. Namun, ada beberapa jalur migrasi terkendali yang dapat melindungi investasi pengendalian proses yang ada sekaligus menghilangkan ketergantungan pada perangkat keras AlphaStation yang sudah menua.