OpenVMS Alpha üzerinde çalışan Bailey INFI 90 Symphony HMI’lerini modernleştirme

Tüm INFI 90 Sistemini Değiştirmeden HMI'yi Modernleştirme

Birçok Bailey INFI 90 sistemi, ilk kurulumlarından onlarca yıl sonra da güvenilir şekilde çalışmaya devam eder. Denetleyicileri, iletişim modülleri, sonlandırma birimleri ve saha G/Ç birimleri gerekli kontrol işlevlerini hâlâ yerine getirebilir.

En acil yaşam döngüsü sorunu genellikle denetleyici katmanının üzerinde bulunur.

Operatör istasyonları eskiyen AlphaStation donanımına, desteklenmeyen grafik bağdaştırıcılarına, kullanım dışı depolama aygıtlarına ve eski OpenVMS Alpha yazılım ortamlarına bağlı olabilir. Değiştirme parçalarını temin etmek zorlaşırken deneyimli OpenVMS ve Bailey Symphony mühendislerinin sayısı da azalmaktadır.

Burada ele alınan örnekte dört AlphaStation 255 iş istasyonu bulunur. Her istasyon OpenVMS Alpha çalıştırır ve Bailey INFI 90 dağıtılmış kontrol sistemi için Bailey Symphony operatör arayüzü işlevlerini barındırır.

Amaç mutlaka tüm DCS'yi değiştirmek değildir. Daha pratik bir amaç, kararlı denetleyicileri, saha kablolarını, G/Ç modüllerini, kontrol mantığını ve proses işlemlerini korurken eskiyen AlphaStation donanımına bağımlılığı ortadan kaldırmaktır.

Bu ayrım, modernizasyon stratejisini değiştirir.

Proje öncelikle operatör arayüzü ve bilgi işlem platformu geçişidir. Denetleyici yaşam döngüsü, siber güvenlik gereksinimleri, üretim hedefleri veya destek koşulları alt kontrol katmanlarının değiştirilmesini haklı çıkardığında ancak tam bir DCS geçişine dönüşür.

Birden fazla olası modernizasyon yolu vardır. Ancak bunlar mevcut sistemin farklı bölümlerini korur.

Bir Alpha emülatörü, yazılım ortamının neredeyse tamamını koruyabilir. OpenVMS x86 geçişi, işletim sistemi ailesini korur ancak uygulamaların taşınmasını gerektirir. OPC tabanlı bir HMI değişimi, denetleyici katmanını korurken operatör arayüzünü yeniden oluşturur. ABB evrim stratejisi, daha geniş Symphony mimarisini aşamalı olarak modernleştirebilir.

Hiçbir yol basit bir PC değişimi olarak tanımlanmamalıdır.

Şekil 1. Üç temel modernizasyon yolu, kurulu Bailey INFI 90 ve Symphony yatırımının farklı bölümlerini koruyabilir.

AlphaStation Diskini Klonlamanın Neden Yeterli Olmadığı

Disk klonlama, kurulu bir OpenVMS Alpha ortamını korumak için kullanışlıdır. İşletim sistemini, uygulama dosyalarını, cihaz yapılandırmasını, kullanıcı hesaplarını, Bailey yazılımını, veritabanlarını, grafikleri ve tesise özgü ayarları yakalayabilir.

Ancak disk klonlama, Alpha yazılımını x86 yazılımına dönüştürmez.

Klonlanan işletim sistemi hâlâ Alpha işlemci talimatlarını içerir. Çekirdeği, önyükleyicisi, sistem kitaplıkları, uygulamaları ve donanım sürücüleri Alpha mimarisi için oluşturulmuştur.

Standart bir modern bilgisayar x86-64 işlemci kullanır. Ayrıca farklı depolama denetleyicileri, ağ aygıtları, kesme yapıları, grafik donanımı, ürün yazılımı arabirimleri ve çevre birimi veri yolları sunar.

VMware, VirtualBox, Hyper-V ve geleneksel x86 hipervizörleri x86 uyumlu donanımı sanallaştırır. Normalde Alpha işlemci talimatlarını x86 talimatlarına çevirmezler.

Bu nedenle, bir OpenVMS Alpha disk imajını sıradan bir x86 sanal makinesine yerleştirmek, bu imajı önyüklenebilir hâle getirmez.

Sanal makine; sanal disk, sanal ağ bağdaştırıcısı ve sanal grafik aygıtı sağlayabilir. OpenVMS Alpha ise hâlâ bir Alpha işlemcisi ve desteklenen Alpha dönemi aygıtlarını bekler.

İki kavramın ayrı tutulması bu nedenledir:

Sanallaştırma genellikle ana makineyle aynı işlemci mimarisini kullanan sanal donanım sunar.

Mimari-karşıtı emülasyon, başka bir işlemciyi ve donanım ortamını yazılım içinde yeniden üretir.

Özgün Alpha ikili dosyalarının ve işletim sisteminin değiştirilmeden kalması gerektiğinde OpenVMS Alpha ikinci yaklaşımı gerektirir.

Bu nedenle disk klonlama üç sınırlı durumda uygulanabilir.

Birinci seçenek, uyumlu depolama birimleri ve çevre birimleriyle aynı AlphaStation modeline kurtarmadır.

İkinci seçenek, gerekli aygıt ve yapılandırma değişiklikleri tamamlandıktan sonra başka bir desteklenen Alpha sistemine kurtarmadır.

Üçüncü seçenek, uyumlu bir AlphaServer veya AlphaStation ortamını yeniden üreten bir Alpha emülatörüne geri yüklemedir.

Tek başına klonlama mimari sorununu çözmez. Hedef ortamın yine de Alpha makine talimatlarını anlaması ve yürütmesi gerekir.

Alpha Emülasyonu Mevcut Yatırımın En Büyük Bölümünü Korur

Mevcut Symphony yazılımının kaynak kodu değişikliği olmadan çalışır durumda kalması gerektiğinde, Alpha emülasyonu genellikle en az kesinti yaratacak yoldur.

Bir Alpha emülatörü modern x86 donanımı üzerinde çalışır, ancak OpenVMS'e sanal bir Alpha sistemi sunar. Özgün işletim sistemi ve uygulamalar, Alpha uyumlu bir donanım ortamı görmeye devam eder.

CHARON-AXP gibi ürünler bu amaçla tasarlanmıştır. Emülatör; fiziksel Alpha işlemcisini, bellek mimarisini, depolama denetleyicilerini, Ethernet bağdaştırıcılarını ve desteklenen diğer aygıtları yazılım tanımlı eşdeğerleriyle değiştirir.

x86 sunucu, ana makine ortamı olarak Windows veya Linux çalıştırır. Alpha emülatörü bu ana makinenin üzerinde çalışır. OpenVMS Alpha daha sonra emüle edilen Alpha sistemi içinde çalışır.

Bu yaklaşım, OpenVMS'i x86'ya taşımaktan farklıdır.

Orijinal OpenVMS Alpha kurulumu bir Alpha kurulumu olarak kalır. Bailey Symphony ikili dosyaları Alpha ikili dosyaları olarak kalır. Emülatör, gerekli Alpha donanım davranışını çevirir veya yeniden üretir.

Bu şunları koruyabilir:

• Yüklü OpenVMS Alpha işletim sistemi.

• Mevcut Bailey Symphony uygulamaları.

• Operatör grafikleri ve ekran veritabanları.

• Alarm yapılandırmaları ve geçmiş dosyaları.

• Kullanıcı hesapları ve komut yordamları.

• Mevcut sahaya özgü yardımcı programlar.

• Alpha ortamına bağlı uygulama arayüzleri.

• Aksi durumda yeniden eğitim gerektirecek operatör iş akışları.

Pratik geçiş genellikle özgün Alpha disklerinin doğrulanmış bir imajının veya yedeğinin oluşturulmasını içerir. Bu veriler, emülatör tarafından kullanılan sanal disk kapsayıcılarına geri yüklenir.

Emülatör yapılandırması uygun CPU, bellek, disk, ağ ve çevre birimi özelliklerini yeniden oluşturmalıdır. Ekibin fiziksel seri bağlantı noktalarını veya ağ arayüzlerini ana sistem üzerinden eşlemesi de gerekebilir.

Alpha emülasyonu, kullanım dışı kalmış fiziksel donanıma bağımlılığı önemli ölçüde azaltabilir. Ayrıca sanal disk dosyaları modern depolama altyapısı kullanılarak kopyalanabildiğinden yedeklemeyi kolaylaştırabilir.

Ancak “sıfır değişiklik” terimi dikkatle kullanılmalıdır.

Uygulama kodu değişmeden kalabilir, ancak ortam yine de mühendislik çalışması gerektirir. Aygıt eşlemeleri kontrol edilmelidir. Ağ arayüzleri yapılandırılmalıdır. OpenVMS lisansları ve uygulama lisansları gözden geçirilmelidir.

Emülatör, sahada kullanılan Bailey iletişim arayüzüyle de test edilmelidir.

Genel bir OpenVMS uygulaması doğru çalışabilirken özel bir DCS arayüzü belirli bir ağ adaptörüne, veri yolu arayüzüne, seri aygıta veya zamanlama davranışına bağlı olduğu için çalışmayabilir.

Bu nedenle, bir emülatör profili seçilmeden önce AlphaStation 255'in tam yapılandırması envantere alınmalıdır.

Bailey İletişim Arayüzü, Kritik Emülasyon Testidir

En önemli emülasyon sorusu, OpenVMS'in oturum açma istemine ulaşıp ulaşmadığı değildir.

Önemli olan, emüle edilen istasyonun tam çalışma koşulları altında Bailey INFI 90 sistemiyle doğru iletişim kurup kurmadığıdır.

Arayüz Ethernet'e, seri iletişime, bir Bailey ağ arayüzüne veya özel iletişim donanımına bağlı olabilir. Saha yapılandırmaları önemli ölçüde farklılık gösterebilir.

Alpha emülasyonunu uygulamaya almadan önce mühendisler şunları belgelemelidir:

• Her AlphaStation'a takılı fiziksel ağ arayüzü.

• Symphony ile INFI 90 arasında kullanılan iletişim protokolü.

• OpenVMS içinde atanan aygıt adları.

• Ağ adresleri ve düğüm tanımları.

• Gerekli DECnet, TCP/IP, LAT veya özel hizmetler.

• Uygun olduğu durumlarda seri bağlantı noktası ayarları.

• Harici lisans anahtarları veya donanım dongle'ları.

• Operatör istasyonları arasındaki yedeklilik ve devre dışı kalma durumunda geçiş davranışı.

• Zaman senkronizasyonu gereksinimleri.

• Operatörler tarafından kullanılan grafik ve klavye işlevleri.

Bir emülatör tedarikçisi yaygın Alpha Ethernet ve depolama aygıtlarını destekleyebilir. Bu durum, her özel Bailey arayüzünün desteklendiğini otomatik olarak doğrulamaz.

Mevcut HMI, sanallaştırılamayan özel bir fiziksel adaptöre bağlıysa emülatör yaklaşımı alternatif bir iletişim ağ geçidi gerektirebilir.

Bu nedenle proje, klonlanmış bir istasyon kullanılarak ve temsili bir Bailey ağına erişim sağlanarak gerçekleştirilecek bir tezgâh testini içermelidir.

Test, statik etiket okumasından fazlasını içermelidir. Operatörler gerçek zamanlı değerleri, komutları, alarmları, onaylamayı, trendleri, ekranlar arasında gezinmeyi, yazdırmayı, olay işlemeyi ve istasyon kurtarmayı doğrulamalıdır.

Performans, alarm yoğunlukları ve yüksek etiket güncelleme etkinliği sırasında da test edilmelidir.

OpenVMS x86-64 Farklı Bir Geçiş Yoludur

Modern OpenVMS, x86-64 mimarisi için kullanılabilir. Modern sunucularda desteklenen sanallaştırılmış ortamlarda çalışabilir.

Bu durum, önceki INFI 90 modernizasyon görüşmelerinin çoğunda mevcut olmayan ek bir geçiş seçeneği oluşturur.

Ancak OpenVMS x86-64, OpenVMS Alpha ikili dosyalarını yerel x86 uygulamalarıymış gibi doğrudan çalıştırmaz.

Uygulama ortamı taşınmalıdır.

Kaynak kodunun x86-64 için aktarılması, incelenmesi, yeniden derlenmesi, bağlanması ve test edilmesi gerekebilir. Üçüncü taraf kitaplıkları ve katmanlı ürünler de hedef sürüm için kullanılabilir olmalıdır.

Temel soru, yüklü Bailey Symphony yazılımının x86 uyumlu bir OpenVMS sürümünün olup olmadığıdır.

Yazılım satıcısı bu uygulamayı hiçbir zaman OpenVMS x86-64 için yayımlamadıysa, yalnızca işletim sistemini taşımak HMI'yi korumaz.

Saha tarafından geliştirilen programlar, kaynak kodları ve derleme ortamları kullanılabilir durumda kaldığında taşınabilir olabilir. Kapalı ticari uygulamalar, satıcı desteği olmadan normalde yeniden derlenemez.

Bu yol, Symphony HMI'nin yanında çalışan özel veri sunucuları, tarihçe sistemleri, yardımcı programlar, raporlar ve entegrasyon uygulamaları için yine de uygulanabilir olabilir.

Desteklenen bir uygulama sürümü olmadan eski, özel mülkiyetli bir Symphony operatör ortamını koruma olasılığı daha düşüktür.

Bir OpenVMS x86 geçiş değerlendirmesi şunları belirlemelidir:

• Yüklü her yürütülebilir dosya ve katmanlı ürün.

• Kullanılabilir kaynak kodu ve derleme prosedürleri.

• Derleyici ve çalışma zamanı bağımlılıkları.

• Veritabanı ürünleri ve dosya biçimleri.

• Özel iletişim kitaplıkları.

• Grafik veya pencere sistemi bağımlılıkları.

• x86-64 için lisans kullanılabilirliği.

• Mimari farklılıkların neden olduğu gerekli değişiklikler.

• Performans ve zamanlama varsayımları.

Bu yol, Alpha'dan artık üretilmeyen başka bir donanım mimarisine geçişe kıyasla uzun vadede daha büyük potansiyele sahiptir. Uyumlu OpenVMS iş yüklerini desteklenen x86 sanallaştırma altyapısına taşıyabilir.

Bununla birlikte, bu işlem disk klonlama projesi olarak değil, uygulama geçişi projesi olarak tanımlanmalıdır.

Itanium Geçişi Neden Genellikle Geçiş Aşamasına Yönelik Bir Seçenektir

OpenVMS, Itanium mimarisini kullanan HPE Integrity sunucuları için de yayımlandı.

Bazı Alpha uygulamalarını OpenVMS Integrity'ye taşımak için geçiş araçları ve mühendislik yöntemleri mevcuttur. Bu, bir zamanlar kullanım ömrünün sonuna yaklaşan Alpha donanımından uzaklaşmak için desteklenen bir yol sunuyordu.

Ancak bugün Itanium donanımının kendisi eski bir platformdur.

Alpha'dan Integrity'ye geçiş, eski bir donanım bağımlılığını ortadan kaldırırken başka bir bağımlılık yaratabilir. Uygun sunucular, yedek parçalar, depolama arabirimleri ve uzmanlık bilgisi giderek daha az bulunabilir olacaktır.

Bir tesis hâlihazırda desteklenen Integrity altyapısına sahipse Itanium hâlâ geçerli olabilir. Gerekli bir katmanlı ürün Integrity için mevcut olup x86-64 için mevcut değilse de geçerli olabilir.

Yeni bir modernizasyon projesi için bu yaklaşım genellikle ara bir uyumluluk seçeneği olarak değerlendirilmelidir.

İş gerekçesi, Integrity'ye geçişin Alpha emülasyonuna, OpenVMS x86 geçişine veya HMI platform yenilemesine neden tercih edildiğini açıklamalıdır.

OPC Platform Yenilemesi Kontrol Katmanını Korur

OPC platform yenilemesi, mevcut INFI 90 denetleyicilerini ve saha G/Ç birimlerini korurken operatör arayüzü katmanını değiştirir.

Bir iletişim sunucusu Bailey sistemine bağlanır ve proses etiketlerini modern bir HMI veya SCADA platformuna sunar.

Yeni HMI; ekranları, alarmları, trendleri, güvenliği, operatör komutlarını, raporları ve iş istasyonu hizmetlerini yönetir.

Bu yaklaşım, orijinal Symphony operatör uygulamasına olan bağımlılığı ortadan kaldırır. Ayrıca yeni operatör istasyonlarında OpenVMS Alpha çalıştırma gereksinimini de ortadan kaldırır.

Mimari genellikle şunları içerir:

• Mevcut Bailey INFI 90 denetleyicileri ve G/Ç birimleri.

• Uyumlu bir Bailey iletişim arayüzü.

• Bir OPC DA, OPC UA veya tedarikçiye özgü veri sunucusu.

• Modern bir HMI veya SCADA platformu.

• Operatör ve mühendislik iş istasyonları.

• İsteğe bağlı geçmiş veri kaydı, raporlama ve alarm analizi hizmetleri.

Kaynak materyalde atıfta bulunulan bir saha örneğinde RoviSys OPC sunucusu ile GE CIMPLICITY kullanılmıştır. Bildirilen sistem başarıyla çalışmıştır, ancak proje operatör ekranlarının ve animasyon mantığının yeniden oluşturulmasını gerektirmiştir.

Bu örnek, her INFI 90 kurulumu için otomatik bir ürün önerisi olarak yorumlanmamalıdır.

Seçilen sunucu, tesisteki belirli Bailey ağını, iletişim modüllerini, denetleyici neslini, etiket sayısını, güncelleme hızını, yedeklilik gereksinimlerini ve komut işlevlerini desteklemelidir.

Aynı durum HMI platformu için de geçerlidir.

GE CIMPLICITY, olası bir kurumsal HMI/SCADA platformudur. Gerekli OPC bağlantısını, grafikleri, alarmları, komut dosyası desteğini, yedekliliği, güvenliği ve yaşam döngüsü desteğini sağladıkları sürece diğer sistemler de uygun olabilir.

Şekil 2. OPC tabanlı bir geçiş, eski Symphony operatör ortamını değiştirirken INFI 90 kontrol katmanını korur.

OPC Bağlantısı Mevcut Ekranları Dönüştürmez

Bir OPC sunucusu veri bağlantısı sağlar. Genellikle eski HMI ekranlarını yeni bir HMI biçimine dönüştürmez.

Orijinal Symphony ekranları statik grafikler, dinamik semboller, renk değişiklikleri, sayısal değerler, çubuk grafikler, alarm göstergeleri, gezinme düğmeleri, komut kontrolleri, trendler ve özel işlev şablonları içerebilir.

Bu öğeler hedef HMI'da yeniden oluşturulmalıdır.

Basit ekranlar doğrudan yeniden çizilebilir. Karmaşık ekranlar, hemen görünür olmayan gizli betikler veya ifadeler içerebilir.

Mühendisler, her animasyonlu nesnenin verilerini nasıl elde ettiğini ve işlediğini anlamalıdır.

Bir vana sembolü yalnızca tek bir çıkış etiketini izlemeyebilir. Rengi ve konumu; açık geri bildirimi, kapalı geri bildirimi, komut durumunu, kilitleme durumunu, iletişim kalitesini ve ekipman modunu temel alabilir.

Bir motor sembolü; çalıştırma komutu, çalışma geri bildirimi, durma durumu, açma, yerel kontrol, bakım durumu, izin koşulları ve alarm engellemesi için ayrı etiketler kullanabilir.

Bu nedenle yalnızca görünen grafikleri taşımak, doğru görünen ancak yanlış davranan bir HMI oluşturabilir.

Göç ekibi, her ekran öğesinin arkasındaki işlevsel anlamı belgelendirmelidir.

Bu çalışma şunları içerir:

• Her dinamik nesneyi veri kaynağıyla eşlemek.

• Animasyon ifadelerini yeniden oluşturmak.

• Komut onayını ve güvenliği doğrulamak.

• Gezinmeyi ve ekran hiyerarşilerini yeniden oluşturmak.

• Alarm sınıflarını ve önceliklerini yeniden oluşturmak.

• Mühendislik birimlerini ve ondalık hassasiyetini doğrulamak.

• Geçmiş ve gerçek zamanlı trendleri yeniden oluşturmak.

• Geçersiz, belirsiz ve başarısız iletişim durumlarını test etmek.

• Operatör mesajlarını ve yönlendirmelerini yeniden oluşturmak.

• Desteklenmeyen yazı tiplerini ve sembolleri değiştirmek.

Bu nedenle çalışma, yalnızca ekran sayısına göre değil, ekranların karmaşıklığına göre belirlenir.

Modern Bir HMI Her Eski Ekranı Körü Körüne Kopyalamamalıdır

Elle yeniden oluşturma, operatör arayüzünü iyileştirme fırsatı sunar.

Eski HMI grafikleri genellikle normal ekipmanları parlak renklerle gösterir, yoğun proses diyagramları ve dekoratif borulama kullanır ve alarm göstergelerinde tutarsızlık barındırır.

Özgün sistem geliştirildiğinde bu kurallar makul olmuş olabilir. Ancak güncel kontrol odası uygulamaları için her zaman ideal değildir.

Bir modernizasyon projesi şunları gözden geçirmelidir:

• Ekran hiyerarşisi.

• Alarm görünürlüğü.

• Gezinme tutarlılığı.

• Ekipman durumunun sunumu.

• Renk kullanımı.

• Trendlere erişilebilirlik.

• Operatör yanıt gereksinimleri.

• Ekran çözünürlüğü ve iş istasyonu düzeni.

• Erişilebilirlik ve okunabilirlik.

Normal işletim koşulları görsel açıdan sakin kalmalıdır. Dikkat gerektiren anormal durumları belirlemek için güçlü renkler kullanılmalıdır.

Operatörler, aşırı gezinme gerektirmeden tesis genel görünümünden etkilenen üniteye, ekipman yüz plakasına, trende, alarm geçmişine ve tanılama ekranına geçebilmelidir.

Ancak aşırı yeniden tasarım başka bir risk oluşturabilir.

Operatörler özgün ekranları uzun yıllar kullanmış olabilir. Aynı proje sırasında her sembolü, rengi ve gezinme yolunu değiştirmek eğitim gereksinimlerini ve devreye alma riskini artırabilir.

Dengeli bir yaklaşım, alarm sunumunu ve gezinmeyi iyileştirirken bilinen süreç ilişkilerini korur.

Etiket Çıkarma Bir Mühendislik İş Paketi Olarak Ele Alınmalıdır

Kaynak materyal, Bailey etiket verilerinin CSV'ye aktarılabileceği olasılığını ortaya koymaktadır. Ancak doğrulanmış, evrensel bir prosedür sunmamaktadır.

Bu nedenle, tek bir dışa aktarma komutunun eksiksiz ve temiz bir HMI veritabanı oluşturacağı varsayılmamalıdır.

Etiket bilgilerinin olası kaynakları şunları içerir:

• Symphony yapılandırma veritabanları.

• Mevcut ekran tanımları.

• Kontrolör yapılandırması ve mühendislik kayıtları.

• Bailey iletişim sunucusu veritabanları.

• OPC sunucusu tarama işlevleri.

• Alarm yapılandırma dosyaları.

• Geçmiş veritabanları.

• Basılı veya arşivlenmiş etiket listeleri.

• Tesis mühendisliği elektronik tabloları.

OPC taraması, sunucu Bailey sistemiyle iletişim kurduktan sonra pratik bir başlangıç noktası sağlayabilir.

Etiket adlarını, öğe tanımlayıcılarını, açıklamaları, kaliteyi ve mevcut değerleri sunabilir. Bazı sunucular, taranan ad alanının dışa aktarılmasını da destekler.

Bununla birlikte, bir OPC ad alanı yeni HMI için gereken her alanı içermeyebilir.

Alarm öncelikleri, mühendislik sınırları, ekran gruplandırmaları, operatör notları, komut güvenliği ve ekipman ilişkileri başka yerlerde saklanabilir.

Bazı OPC sunucuları, etiketleri orijinal Symphony adlarından farklı oluşturulmuş adlarla sunar.

Proje, en azından aşağıdakileri içeren kontrollü bir etiket ana kaydı oluşturmalıdır:

• Orijinal etiket adı.

• Yeni HMI etiketi adı.

• OPC öğe tanımlayıcısı.

• Açıklama.

• Veri türü.

• Okuma veya yazma izni.

• Mühendislik birimleri.

• Ölçeklendirme bilgileri.

• Alarm sınırları ve önceliği.

• Güncelleme hızı.

• İlişkili ekran.

• Doğrulama durumu.

• Test sonucu.

Bu ana kayıt, eski ve yeni sistemler arasındaki mutabakat kaydı olur.

Etiket Sayısı Tek İletişim Gereksinimi Değildir

Başarılı bir tarama testi, OPC mimarisinin eksiksiz HMI'ı destekleyebileceğini kanıtlamaz.

Mühendisler; etkin etiket sayısını, istenen güncelleme hızını, değişiklik sıklığını, alarm etkinliğini, komut trafiğini ve sunucu yedekliliğini değerlendirmelidir.

Bir sistem on binlerce yapılandırılmış etiket içerebilir. Bunların yalnızca bir bölümü aynı anda operatör ekranlarında etkin olabilir.

Sunucu ve HMI, gerçekçi koşullar altında test edilmelidir.

Önemli performans kontrolleri şunları içerir:

• Karmaşık bir ekranı açmak için gereken süre.

• Sahadaki bir değişiklik ile HMI animasyonu arasındaki gecikme.

• Olay yoğunluğu sırasında alarm iletimi.

• Gerekli örnekleme hızında trend toplama.

• Komut yürütme ve geri bildirim süresi.

• Ağ kesintisi sonrasında kurtarma.

• Yedekli sunucular arasında yük devretme.

• Kontrolör yeniden başlatıldıktan sonraki davranış.

• İletişim arızası sırasında kalite durumu.

• CPU, bellek ve ağ yükü.

Komutlar özel dikkat gerektirir.

OPC üzerinden değerleri okumak nispeten kolay olabilir. Değerleri güvenli biçimde yazmak; erişim denetimi, komut doğrulama, geri bildirim onayı ve iletişim arızalarının doğru şekilde ele alınmasını gerektirir.

Ekip, yalnızca temsili bir etiketi değil, her operatör komutu türünü test etmelidir.

ABB Symphony Plus Daha Geniş Bir Gelişim Yolu Sunuyor

Kurulu bir Bailey sistemi için OPC değişimi tek seçenek değildir.

ABB, Symphony Plus'ı eski Bailey, INFI 90, Harmony Rack ve Symphony kurulumları için bir gelişim platformu olarak konumlandırmaya devam etmektedir.

Aşamalı bir ABB modernizasyonu, daha yeni operatör, mühendislik, ağ, kontrolör veya G/Ç bileşenlerini devreye alırken kurulu kontrol ve G/Ç mimarisinin bazı bölümlerini koruyabilir.

Bu yaklaşım, bağımsız bir HMI değişimi yerine üretici destekli bir yaşam döngüsü stratejisi isteyen kuruluşlar için cazip olabilir.

Proje, önce operatör ortamını modernleştirebilir. Kontrolörler ve G/Ç birimleri, yaşam döngüleri veya operasyonel değerleri değiştirilmelerini haklı çıkarana kadar hizmette kalabilir.

İlerleyen aşamalarda iletişim, kontrolörler, mühendislik araçları ve saha arayüzleri ele alınabilir.

Kesin geçiş mimarisi, kurulu sistemin nesline bağlıdır.

Bailey INFI 90, INFI 90 OPEN, Network 90, Harmony, Symphony ve Symphony Plus kurulumlarının tümü aynı arayüzleri kullanmaz.

Modül adları ve ağ terminolojisi, saha çizimleri ve donanım envanterlerinden doğrulanmalıdır.

Mevcut kontrol katmanını sürdüren kuruluşlar, yedek kapsamını, yaşam döngüsü desteğini ve aşamalı modernizasyonu planlarken mevcut ABB Bailey INFI 90 ve Network 90 bileşenlerini de inceleyebilir.

Bu dahili bağlantı, modernizasyon projelerinin mühendislik, test ve aşamalı devreye alma sırasında eski sistemin genellikle çalışır durumda kalmasını gerektirmesi nedeniyle önemlidir.

Uygun yedek kontrolörlerin, iletişim modüllerinin, güç kaynaklarının ve G/Ç modüllerinin bulundurulması, bu geçiş sırasında riski azaltabilir.

Özel veya Açık Kaynaklı Bir HMI Mümkündür, Ancak Sorumluluk Gerektirir

Özel bir HMI, açık kaynaklı veya ticari yazılım çerçeveleri kullanılarak geliştirilebilir.

Kaynak materyal, VMS üzerinde çalışan ve Qt tabanlı modern bir istemciye sahip bir sunucudan bahsetmektedir. Bu tür mimariler, sunucu tarafındaki veri bağlantısını operatör istemcisinden ayırabilir.

Bu yaklaşım esneklik sağlayabilir ve tek bir HMI üreticisine bağımlılığı önleyebilir.

Bu seçenek, uzun vadeli bir yazılım geliştirme taahhüdüne de dönüşebilir.

Kuruluş şunların sahibi olmalı veya bakımını üstlenmelidir:

• İletişim sunucusu.

• Etiket veritabanı.

• İstemci uygulaması.

• Grafik çerçevesi.

• Alarm işleme.

• Tarihçe sistemi entegrasyonu.

• Kullanıcı kimlik doğrulaması.

• Siber güvenlik güncellemeleri.

• Dağıtım ve sürüm kontrolü.

• Dokümantasyon ve eğitim.

Qt, Python, C++, web teknolojileri veya diğer çerçeveler, yetkin endüstriyel arayüzler oluşturabilir. Zorluk, bir proses grafiği çizmek değildir.

Zorluk; iletişim kesintileri, sunucu yeniden başlatmaları, alarm yoğunlukları, kullanıcı değişiklikleri ve anormal tesis koşulları sırasında doğru şekilde davranan güvenilir bir operatör sistemi oluşturmaktır.

Özel bir platform, yalnızca kuruluşun sürdürülebilir bir mühendislik ekibine veya güvenilir, uzun vadeli bir entegratöre sahip olduğu durumlarda seçilmelidir.

Lisanslama, Teknik Bir Güzergâhın Uygulanabilir Olup Olmadığını Belirleyebilir

Eski endüstriyel yazılımlar genellikle donanım tanımlayıcılarına, Ethernet adreslerine, lisans veritabanlarına, donanım kilitlerine veya tedarikçi tarafından sağlanan yetkilendirme anahtarlarına bağlı lisanslama mekanizmaları kullanır.

Klonlanmış bir sistem doğru şekilde açılabilir, ancak sanal donanım kimliği değiştiği için Symphony uygulamasını başlatmayı reddedebilir.

Geçiş envanteri şunları içermelidir:

• OpenVMS işletim sistemi lisansları.

• Bailey Symphony uygulama lisansları.

• Veritabanı lisansları.

• Ağ ve iletişim lisansları.

• Emülatör lisansları.

• HMI ve OPC nokta sayısı lisansları.

• Tarihçe verisi lisansları.

• Yedeklilik seçenekleri.

• Mühendislik istemcisi lisansları.

• Çalışma zamanı istemcisi lisansları.

Nihai platform seçilmeden önce yazılı onay alınmalıdır.

Yasal lisansların mevcut olmaması durumunda teknik uyumluluk, devreye alınabilir bir çözüm oluşturmaz.

Siber Güvenlik, Değiştirme Tasarımına En Baştan Dâhil Edilmelidir

Eski AlphaStation sistemleri, modern endüstriyel siber güvenlik uygulamalarının standart hâle gelmesinden önce sıklıkla kurulmuştur.

Yalıtılmış ağlarda, sınırlı uzaktan erişimle çalışabilirler. Bunların Windows sunucuları, modern SCADA istemcileri, OPC sunucuları ve Ethernet altyapısıyla değiştirilmesi saldırı yüzeyini değiştirir.

Yeni mimari; kontrol, sunucu, mühendislik ve kurumsal ağ bölgelerini ayrı olarak tanımlamalıdır.

Güvenlik duvarları yalnızca gerekli iletişim yollarına izin vermelidir. Uzaktan erişim, yönetilen kimlik doğrulama ve kayıt kullanmalıdır.

Operatör hesapları rol tabanlı izinleri izlemelidir. Mühendislik işlevleri her HMI istemcisinden kullanılabilir olmamalıdır.

OPC yazma erişimi, yalnızca buna ihtiyaç duyan etiketler ve istasyonlarla sınırlandırılmalıdır.

Tasarım ayrıca şunları ele almalıdır:

• İşletim sistemi yamalama.

• Antivirüs veya uygulama kontrolü.

• Yedekleme ve kurtarma.

• Zaman senkronizasyonu.

• Güvenlik günlük kaydı.

• Çıkarılabilir medya kontrolleri.

• Tedarikçinin uzaktan desteği.

• OPC UA için sertifika yönetimi.

• Hesap yaşam döngüsü yönetimi.

Siber güvenlik kontrolleri, tesis olayları sırasında operatörlerin müdahale etmesini engellememelidir. Tasarım, koruma ile kullanılabilirlik ve deterministik işletim arasında denge kurmalıdır.

Geçiş, Kanıta Dayalı Bir Envanterle Başlamalıdır

Bir güzergâh seçmeden önce mühendisler mevcut sistemi ayrıntılı olarak belgelemelidir.

Envanter, dört AlphaStation'ın tümünü içermeli ve yapılandırmalarının gerçekten aynı olup olmadığını belirtmelidir.

Kayıt:

• AlphaStation modeli ve işlemci yapılandırması.

• Bellek kapasitesi.

• Disk türü ve mantıksal birimler.

• OpenVMS sürümü ve yama düzeyi.

• Yüklü Bailey yazılımı sürümleri.

• Katmanlı ürünler ve veritabanları.

• Grafik donanımı ve ekran çözünürlüğü.

• Ağ bağdaştırıcıları.

• Seri arabirimler.

• Bailey iletişim donanımı.

• Düğüm adları ve adresleri.

• Başlatma komutu prosedürleri.

• Lisans dosyaları.

• Yedekleme prosedürleri.

• Operatör istasyonu yedekliliği.

• Bağlı yazıcılar ve harici cihazlar.

• Geçmiş ve alarm verilerinin saklanması.

Ekip ayrıca her ekranın ekran görüntüsünü toplamalıdır. Dinamik durumlar mümkün olduğunda yakalanmalıdır.

Normal, durmuş, çalışan, alarmda, engellenmiş, yerel, manuel, otomatik ve iletişim arızalı durumları kaydedin.

Yeni ekranlar test edilirken bu kanıt gereklidir.

Tezgâh Sistemi Zorunludur

Hiçbir modernizasyon yolu ilk kez canlı üretim sistemi üzerinde test edilmemelidir.

Bir tezgâh ortamı, iletişimi ve operatör işlevlerini doğrulamak için kurulu mimarinin yeterli bir bölümünü yeniden oluşturmalıdır.

Bir emülatör projesi için tezgâh ortamında klonlanmış bir OpenVMS Alpha ortamı ve önerilen emülatör yapılandırması bulunmalıdır.

Bir OPC projesi için seçilen iletişim sunucusu, HMI yazılımı, temsili grafikler ve güvenli bir Bailey test düğümüne veya benzetilmiş veri kaynağına erişim bulunmalıdır.

Tezgâh testi şunları doğrulamalıdır:

• Sistem önyüklemesi ve uygulama başlangıcı.

• Bailey sistemiyle iletişim.

• Erişilebilir toplam etiket sayısı.

• Okuma ve yazma işlemleri.

• Etiket ölçeklendirme ve mühendislik birimleri.

• Alarm oluşturma ve onaylama.

• Trend toplama.

• Ekran animasyonu.

• Komut güvenliği.

• Yazıcı ve rapor işlevleri.

• Sunucu yeniden başlatma davranışı.

• Ağ arızası davranışı.

• Yedeklilik ve yük devretme.

• Yedekten geri yükleme.

• Operatör tepki süresi.

Test sonuçları; işletme, kontrol mühendisliği, bakım ve siber güvenlik temsilcileri tarafından gözlemlenmelidir.

Paralel İşletim Geçiş Riskini Azaltır

İlk yedek sistem dağıtımı sırasında orijinal AlphaStation'lar kullanılabilir durumda tutulmalıdır.

Mühendisler değerleri, alarmları, trendleri ve komutları karşılaştırırken yeni HMI paralel çalışabilir.

Paralel işletim, eski istasyon kaldırılmadan önce uyumsuzlukların belirlenmesini sağlar.

Ekip şu unsurları karşılaştırıp uyumlu hâle getirmelidir:

• Görüntülenen proses değerleri.

• Durum göstergeleri.

• Alarm öncelikleri.

• Alarm zaman damgaları.

• Komut sonuçları.

• Trend değerleri.

• Ekipman modu.

• İletişim kalitesi.

• Güvenlik izinleri.

Her farklılık bir hatayı temsil etmez. Yeni sistem, iyileştirilmiş ölçeklendirme veya alarm sunumu kullanabilir.

Yine de her farklılık açıklanmalı ve onaylanmalıdır.

Yeni HMI, gözlemlenen bir saha kabul testini ve üzerinde anlaşılmış bir işletim dönemini başarıyla tamamlayana kadar eski istasyonlar kurtarılabilir durumda tutulmalıdır.

Doğru Geçiş Yolunu Seçme

Şu durumlarda Alpha emülasyonunu seçin:

Mevcut Symphony uygulaması değişmeden kalmalıdır. Kaynak kodu mevcut değildir. Operatör grafikleri karmaşıktır. Yeniden eğitim en aza indirilmelidir. Bailey iletişim arayüzü emülatör mimarisi tarafından desteklenebilir.

Şu durumlarda OpenVMS x86 geçişini seçin:

Gerekli uygulamalar x86-64 için mevcuttur veya yeniden derlenebilir. Kaynak kodu ve mühendislik bilgisi hâlâ erişilebilirdir. Kuruluş, desteklenen bir x86 ortamına geçerken OpenVMS'i korumak istemektedir.

OPC yeniden platformlandırmasını şu durumlarda seçin:

INFI 90 kontrolörü ve G/Ç katmanları güvenilirliğini koruyorsa. Kuruluş modern bir HMI platformu istiyorsa. Ekranları, alarmları, etiketleri ve komut mantığını yeniden oluşturup doğrulamak için mühendislik kaynakları mevcutsa.

ABB evolution rotasını şu durumlarda seçin:

Kuruluş daha kapsamlı ve tedarikçi destekli bir modernizasyon programı istiyorsa. Gelecek aşamalar operatör sistemlerini, mühendislik araçlarını, ağ arayüzlerini, kontrolörleri ve G/Ç'yi içerebilir.

Özel bir HMI'ı şu durumlarda seçin:

Kuruluşun özel gereksinimleri varsa ve uzun vadeli yazılım geliştirme, test, siber güvenlik ve yaşam döngüsü bakımı desteği sağlayabiliyorsa.

Mevcut sistemi şu durumlarda geçici olarak koruyun:

Geçiş arayüzleri hâlâ belirsiz. Yedekler eksik. Lisanslama çözüme kavuşmamış. Etiket veritabanları kullanılamıyor. Tezgâh testleri henüz Bailey iletişim yolunu yeniden oluşturamıyor.

Uygulanabilir Aşamalı Modernizasyon Planı

Aşama 1: Mevcut ortamı koruyun.

Her AlphaStation'ın doğrulanmış imaj yedeklerini oluşturun. Donanım, yazılım, ağ, lisanslama ve başlangıç ayrıntılarını kaydedin. Mümkün olan her yerde geri yüklemeyi test edin.

Aşama 2: İletişim mimarisini belirleyin.

Her Symphony istasyonunun INFI 90 ile tam olarak nasıl iletişim kurduğunu belgeleyin. Arayüzün emüle edilip edilemeyeceğini veya desteklenen bir sunucuyla değiştirilip değiştirilemeyeceğini doğrulayın.

Aşama 3: Kavram kanıtı oluşturun.

Klonlanmış bir istasyonu bir Alpha emülatöründe test edin veya bir OPC sunucusunu temsili bir Bailey düğümüne bağlayın.

Aşama 4: Etiket ana listesini oluşturun.

Kontrolör etiketlerini, OPC öğe tanımlayıcılarını, mühendislik birimlerini, komutları, alarmları ve ekran kullanımını mutabakatla doğrulayın.

Aşama 5: Temsili ekranları yeniden oluşturun.

Farklı animasyon, alarm, komut ve trend gereksinimleri içeren birkaç ekran seçin.

Aşama 6: Tezgâh kabulünü tamamlayın.

Tüm etiketlerin yüklenmesini, iletişim arızasını, sunucunun yeniden başlatılmasını, alarm yoğunluklarını, komut davranışını ve yedekten geri yüklemeyi test edin.

Aşama 7: Paralel olarak devreye alın.

Yeni ve eski HMI'ları birlikte çalıştırın. Değerleri ve operatör tepkilerini karşılaştırın.

Aşama 8: Tanıklar eşliğinde geçiş yapın.

Onaylanmış bir test prosedürü kullanın. AlphaStation'ları geri dönüş seçeneği olarak hazır bulundurun.

Aşama 9: Eski donanımı kademeli olarak devreden çıkarın.

Uzun vadeli kabul süreci tamamlanana kadar orijinal imajları, yapılandırma kayıtlarını, lisansları veya donanımı imha etmeyin.

Sıkça Sorulan Sorular

Bir OpenVMS AlphaStation diski doğrudan modern bir bilgisayara klonlanabilir mi?

Hayır. İmaj, Alpha makine kodu içerir ve Alpha uyumlu donanım bekler. Modern bir x86 bilgisayar bunu doğrudan başlatamaz. İmaj, uyumlu Alpha donanımına veya bir Alpha emülatörüne geri yüklenmelidir.

VMware veya VirtualBox OpenVMS'i çalıştırabilir mi?

Desteklenen OpenVMS x86-64 sürümlerini çalıştırabilirler. Eski bir OpenVMS Alpha kurulumunu x86 uygulamasına dönüştürmezler. OpenVMS Alpha, Alpha emülasyonu gerektirir.

Orijinal Symphony ekranları korunabilir mi?

Eksiksiz Alpha ortamı uyumlu bir emülatör altında çalıştırıldığında bunlar genellikle korunabilir. Başka bir HMI platformuna geçilirken ise normalde elle yeniden oluşturulmaları gerekir.

Bir OPC sunucusu her Bailey etiketini otomatik olarak dışa aktarır mı?

Şart değil. OPC taraması yararlı bir ad alanı sağlayabilir; ancak alarm yapılandırması, ekran ilişkileri, komutlar, açıklamalar ve mühendislik meta verileri için ek çıkarma ve uzlaştırma gerekebilir.

GE CIMPLICITY tek yedek HMI mıdır?

Hayır. Bu, olası platformlardan biridir ve kaynakla birlikte sunulan saha örneğinde yer almaktadır. Nihai seçim; iletişim desteğine, yedekliliğe, lisanslamaya, siber güvenliğe, mühendislik kaynaklarına ve operatör gereksinimlerine bağlı olmalıdır.

Alpha'dan Itanium'a geçiş hâlâ değerli mi?

Gerekli yazılım yalnızca Integrity sistemleri için mevcut olduğunda veya mevcut Integrity altyapısı hâlihazırda desteklendiğinde bu seçenek haklı görülebilir. Genellikle en güçlü uzun vadeli modernizasyon stratejisinden ziyade geçiş çözümüdür.

INFI 90 kontrolörleri ve G/Ç kurulu kalabilir mi?

Evet, güvenilir kalmaları ve seçilen iletişim mimarisinin bunları desteklemesi durumunda. HMI modernizasyonu, kontrolör ve G/Ç değişiminden ayrı olarak tamamlanabilir.

Eski AlphaStation'lar geçişten hemen sonra kaldırılmalı mı?

Hayır. Yeni operatör ortamı işlevsel, performans ve operasyonel kabul testlerinden geçene kadar test edilmiş bir geri dönüş seçeneği olarak kullanılabilir durumda tutulmalıdır.

Doğru Çözüm Neyin Korunması Gerektiğine Bağlıdır

Eski HMI planlarındaki başlıca teknik hata, operatör istasyonunu sıradan bir bilgisayar olarak ele almaktır.

OpenVMS Alpha ve Bailey Symphony çalıştıran bir AlphaStation, eksiksiz bir donanım ve yazılım ortamıdır. İşlemci mimarisi, işletim sistemi, iletişim arayüzleri, uygulama ikili dosyaları, lisanslar, grafikler ve kontrol sistemi bağlantıları birbirine bağımlıdır.

Disk klonlama verileri korur. Ancak bu ortamı başka bir mimariye çevirmez.

Tüm Symphony kurulumunun hiçbir değişiklik yapılmadan korunması gerektiğinde Alpha emülasyonu en doğrudan yolu sunar.

Uygulamalar taşınabildiğinde veya yeniden oluşturulabildiğinde OpenVMS x86-64, modern bir işletim sistemi yolu sağlar.

INFI 90 kontrol katmanı değerini korurken operatör katmanının değiştirilmesi gerektiğinde OPC'yi yeni bir platforma taşımak pratik bir yol sunar.

Kuruluş HMI'ın ötesinde modernleşmek istediğinde ABB Symphony Plus evrimi, daha kapsamlı ve aşamalı bir strateji sağlayabilir.

Nihai karar; doğrulanmış envanter, iletişim arayüzü incelemesi, lisans değerlendirmesi, kavram kanıtı, tezgâh testi ve gözlemci eşliğinde operasyonel kabul süreçlerinin ardından verilmelidir.

Sıfır çabayla gerçekleştirilebilecek bir geçiş yoktur. Ancak, eskiyen AlphaStation donanımına bağımlılığı ortadan kaldırırken mevcut proses kontrolü yatırımını koruyabilecek birkaç kontrollü geçiş yolu vardır.