OT’de Değişiklik Penceresi Mühendisliği: Test, Geri Dönüş ve Onay

“Beş dakikalık bir firmware işi” diye başlanan değişiklik, üretim ağında pazartesi sabahına kadar süren bir duruşa dönüşebilir. IT’de kötü giden bir değişiklik bir hizmeti bir süre erişilemez bırakır; OT’de hattı durdurur, yarım kalan partiyi hurdaya çıkarır ya da güvenlik fonksiyonunun beklenmedik davranmasına yol açar. Aşağıda, onayı alınmış bir yama, firmware güncellemesi veya ağ değişikliğinin sahada nasıl uygulanacağını adım adım anlatıyoruz: risk sınıfı, ön doğrulama, yedek, uygulama planı, go/no-go ve geri dönüş. Hangi yamanın uygulanacağı ayrı bir karardır; burada konu, kararı verilmiş işin mühendisliği.

OT’de değişikliği IT’den farklı kılan kısıtlar

OT değişikliğini zorlaştıran teknoloji değil, işletme koşullarıdır. Plan yazılmadan önce bunlar masaya konur:

• Kullanılabilirlik önceliği: Sistemin çalışmaya devam etmesi çoğu zaman gizlilikten de güncellikten de önce gelir. Basit bir yeniden başlatma bile planlı duruş ister.
• Üretici onayı: SCADA, HMI ve mühendislik yazılımı üreticileri genellikle hangi işletim sistemi yamalarıyla test ettiklerini listeler. Listede olmayan bir yama destek sözleşmesini etkileyebilir.
• Durum (state) taşıyan süreçler: Kesikli üretimde parti, sürekli proseste sıcaklık ve basınç dengesi vardır. Değişiklik, prosesin güvenle durdurulup yeniden başlatılabileceği ana denk getirilir.
• Bağımlılık zinciri: Tek bir switch’in yeniden başlaması ringde yeniden yakınsama, PROFINET cihazlarında bağlantı kopması ve HMI’da alarm seli demektir.
• Eski sistemler: Desteği bitmiş işletim sistemleri ve yeniden kurulumu hiç belgelenmemiş istasyonlar geri dönüşü zorlaştırır.

Bu yüzden ITIL akışını olduğu gibi OT’ye kopyalamak tutmaz. Onay mekanizması benzer kalabilir; fark, teknik hazırlığın derinliğinde ve sahadaki koordinasyondadır. Denetim kanıtı tarafı ayrı bir iştir; burada mühendislik tarafına bakıyoruz.

Değişiklik türleri ve risk sınıflandırması

Her değişikliğe aynı ağırlıkta süreç uygularsanız iki şeyden biri olur: ekip yorulur ya da süreç arka kapıdan delinir. Sahada işe yarayan yöntem, değişikliği iki eksende tartmaktır: üretime etkisi (etkisiz, bir hücre, bir hat, tesis geneli) ve geri alınabilirliği (anında, planlı, zor). Aşağıdaki tablo bir başlangıç şablonudur; tesisinize göre uyarlayın.

Değişiklik örneği	Etki alanı	Geri alma	Risk sınıfı
Switch’e syslog/SNMP hedefi ekleme	Etkisiz	Anında	Düşük
Hücre firewall’una yeni izin kuralı	Bir hücre	Anında	Orta
HMI istasyonuna işletim sistemi yaması	Bir hat	Planlı (imaj)	Orta
PLC programında mantık değişikliği	Bir hat	Planlı	Yüksek
PLC veya switch firmware güncellemesi	Hat veya tesis	Zor	Yüksek
Ring/VLAN yapısında değişiklik	Tesis geneli	Planlı	Yüksek

Düşük riskli işler önceden onaylanmış “standart değişiklik” olarak tanımlanabilir: prosedür sabittir, üretim sırasında yapılır, yalnız kaydı tutulur. Orta riskte ön test ve vardiya amirinin bilgisi yeterlidir. Yüksek riskte aşağıdaki adımların tamamı uygulanır. Acil değişiklik (aktif arıza veya istismar edilen bir zafiyet) süreci atlamaz, yalnız sırayı değiştirir: önce uygulanır, kayıt ve gözden geçirme hemen ardından tamamlanır. “Acil” etiketi sürecin kaçış kapısına dönüşmemeli.

Test ortamı ve ön doğrulama yöntemleri

İdeali, üretimin bir kopyası olan test ortamıdır. Çoğu tesiste yoktur. Yine de kademeli doğrulama yapılabilir:

1. Masa üstü doğrulama: Yedek parça stoğundaki aynı model PLC ve switch üzerinde firmware güncellemesi denenir. Güncelleme süresi, yeniden başlatma süresi ve yapılandırmanın korunup korunmadığı ölçülür. Pencerede kullanılacak süreler buradan gelir, tahminden değil.
2. Simülasyon: PLC mantık değişiklikleri üreticinin simülasyon aracında (örneğin Siemens ortamında PLCSIM) test edilir. Mantık hatasını yakalar; zamanlama ve I/O davranışını tam yansıtmaz.
3. Sanal kopya: HMI ve SCADA sunucuları sanallaştırılmışsa üretimden yalıtılmış bir ağda klonlanır, yama orada uygulanır. Klon ayrı bir sanal ağda çalışmalıdır; aynı IP ve isimle üretim ağına bağlanan bir klon, test etmek istediğiniz sistemden daha büyük sorun çıkarır.
4. Pilot: Benzer hatlar varsa değişiklik önce birinde uygulanır ve en az bir tam üretim döngüsü (vardiya, parti veya reçete değişimi) boyunca izlenir.

Ön doğrulamanın çıktısı yazılıdır: ne test edildi, hangi sürümlerle, sonuç ne, neyin test edilemediği. Son madde en değerlisidir. Test edilemeyen her kısım uygulama planına ek gözlem adımı olarak girer.

PLC projesi, firmware ve switch yapılandırma yedekleri

Geri dönüşün ön koşulu, değişiklikten hemen önce alınmış ve doğrulanmış yedektir. “Sunucuda bir yerde proje dosyası var” yedek değildir. Sahada en sık gördüğümüz durum şu: PLC’de çalışan program ile arşivdeki proje aynı değil, çünkü son devreye almada yapılan küçük düzeltme arşive hiç girmemiş.

• PLC: Mühendislik yazılımıyla cihazdan güncel proje yüklenir (upload), arşivdeki projeyle online/offline karşılaştırma yapılır. Fark çıkarsa önce o fark açıklanır; bilinmeyen bir farkın üzerine değişiklik yapılmaz. Firmware sürümü, donanım sipariş numarası ve varsa bellek kartının kopyası kaydedilir.
• HMI/SCADA istasyonları: Sistem imajı alınır ve imajın açılabildiği bir kez doğrulanır. Lisans dosyaları ve donanıma bağlı lisanslar ayrıca not edilir; geri yüklemede ilk takılan yer genellikle lisanstır.
• Switch, router ve firewall: Çalışan yapılandırma ve firmware sürümü kaydedilir; yapılandırmanın kalıcı belleğe yazılıp yazılmadığı kontrol edilir. Kaydedilmemiş running-config, ilk yeniden başlatmada kaybolur.

Cisco IOS tabanlı endüstriyel switch’lerde değişiklik öncesi asgari kayıt şöyle alınabilir:

show version | include Version|uptime
show running-config
show interfaces status
show spanning-tree summary
show rep topology            ! REP kullanılıyorsa
copy running-config scp://yedek@10.30.5.20/cfg/hucre3-sw1-oncesi.cfg

Aynı çıktılar değişiklikten sonra da alınır; iki çıktı arasındaki fark, sonrası doğrulamanın temelidir. Ring protokolü olarak MRP veya üreticiye özgü bir protokol kullanılıyorsa ilgili durum komutu listeye eklenir. Ringin “sağlam” durumunun adı protokole göre değişir (MRP’de ring yöneticisinde closed, Cisco REP’te segment complete); plan, kullanılan protokolün terimiyle yazılır. Sahada yanlış terim, yanlış karar demektir.

Uygulama planı ve duruş penceresi koordinasyonu

Uygulama planı, sahada okunarak takip edilecek kadar somut olur. Her adımın sahibi, beklenen süresi ve başarı ölçütü yazılır. Aşağıdaki şablon, yüksek riskli bir switch firmware güncellemesi içindir:

Değişiklik: Hat 3 hücre switch'leri firmware güncellemesi (4 cihaz)
Pencere   : Pazar 06:00-10:00, hat 3 planlı bakım duruşu
Sorumlu   : Pencere sorumlusu (bakım), uygulayıcı (OT ağ), gözlemci (proses)
Ön koşul  : Hat güvenli durumda, partiler tamamlanmış, yedekler doğrulanmış

T+00  Hat durum teyidi, HMI alarm listesi ekran görüntüsü     -> proses
T+10  Ön kayıt komutları, ring durumu kapalı/tam            -> OT ağ
T+20  SW-4 (ring ucu) güncelleme ve yeniden başlatma         -> OT ağ
T+35  SW-4 doğrulama: sürüm, portlar, ring tekrar kapalı     -> OT ağ
T+40  GO/NO-GO 1: SW-4 sorunsuz mu?                          -> pencere sorumlusu
T+45  SW-3, SW-2, SW-1 sırayla, her biri sonrası doğrulama
T+120 PROFINET cihaz durumları, I/O testi, HMI haberleşmesi  -> proses
T+150 GO/NO-GO 2: hattı üretime ver ya da geri dön
Son geri dönüş başlangıç zamanı: T+180

Planlarda en çok atlanan iki nokta var. Birincisi “son geri dönüş başlangıç zamanı”: geri dönüşün pencere içinde bitebilmesi için en geç ne zaman başlaması gerektiği. Bu satır yoksa ekip pencere bitene kadar ileriye doğru uğraşır, geri dönüş mesaiye taşar. İkincisi gözlemci rolü. Komutu yazan kişi aynı anda prosesin tepkisini izleyemez. Proses tarafından biri HMI’da alarmları ve kritik değerleri takip etmelidir.

Üretim planlama, vardiya amirleri, bakım ve gerekiyorsa makine üreticisi pencereden önce bilgilendirilir. Uzaktan destek verecek bir üretici varsa bağlantı pencereden önce test edilir ve süre sınırlı açılır. Pencere sabahında VPN istemcisinin çalışmadığını öğrenmek, sahada sık yaşanan bir zaman kaybıdır.

Geri dönüş kriterleri ve go/no-go kontrol listesi

Geri dönüş kriteri, sahada tartışma çıkarmayacak kadar ölçülebilir olmalıdır. “Sorun olursa geri döneriz” kriter değildir. Örnekler: ring 5 dakika içinde kapalı duruma dönmezse; herhangi bir PROFINET cihazı bağlantı hatasında kalırsa; HMI’da değişiklik öncesinde olmayan bir haberleşme alarmı 10 dakika boyunca sürerse; son geri dönüş başlangıç zamanına gelindiyse.

Pencere başlamadan önce kullanılacak go/no-go listesi:

• Değişiklik onayı ve risk sınıfı kayıtlı.
• Ön doğrulama sonucu yazılı; test edilemeyen noktalar biliniyor.
• PLC projeleri, imajlar ve switch yapılandırmaları alındı ve ikinci bir konumda duruyor.
• Firmware dosyalarının bütünlüğü üreticinin yayınladığı özet değerle (hash) doğrulandı.
• Geri dönüş yöntemi ve süresi biliniyor; düşük sürüme dönüş desteklenmiyorsa yedek cihaz hazır.
• Pencere sorumlusu, uygulayıcı ve gözlemci sahada; iletişim kanalı belli.
• Proses güvenli durumda; operatörler bilgilendirildi.
• Mühendislik istasyonu ile hedef cihazlar arasında gereken firewall kuralları süre sınırlı olarak açık.

Listede tek bir madde karşılanmıyorsa değişiklik ertelenir. Baskı altında bu kural esner; esnememesi için listenin pencereden önce yöneticilerle paylaşılmış olması gerekir. Ertelenen pencere, yarım kalan pencereden ucuzdur.

Değişiklik sonrası doğrulama

Cihazın açılmasıyla iş bitmez. Doğrulama üç katmanda yapılır. Ağ katmanında ön kayıt komutları tekrarlanır ve çıktılar karşılaştırılır; port hata sayaçları sıfırlanıp birkaç saat sonra tekrar okunur, çünkü bazı sorunlar ancak yük altında görünür. Kontrol katmanında PLC teşhis tamponu (diagnostic buffer) incelenir, online/offline karşılaştırma tekrarlanır, I/O ve güvenlik fonksiyonları test edilir. Proses katmanında ilk partinin veya ilk vardiyanın kalite ve hız değerlerinin normal aralıkta olup olmadığına, historian’daki veri akışında boşluk oluşup oluşmadığına bakılır.

Haberleşme sorunlarında hızlı teşhis için PROFINET arıza teşhisi adımları kullanılabilir. Değişiklik sırasında ağ cihazlarına güvenli erişim, üretim trafiğinden ayrılmış bir yönetim yolu ister; tasarımı OT yönetim ağı ve out-of-band erişim yazısında. Segmentasyon projelerinde her dalga aslında bir değişiklik penceresidir; düz OT ağını segmentlere ayırma planı buradaki yöntemi temel alır.

Son adım kaydı kapatmaktır: yeni sürümler, yeni yapılandırma yedeği, gözlenen sapmalar ve bir sonraki pencere için çıkan dersler. Hangi zafiyetin yamanacağı, hangisinin telafi edici önlemle yönetileceği ise OT zafiyet yönetimi ve yama kararı kapsamındadır. Yama yönetimi için IEC 62443-2-3 teknik raporu ve NIST SP 800-82 Rev. 3 çerçeve olarak kullanılabilir. Değişiklik sürecinizi ve OT varlık envanterinizi birlikte gözden geçirmek isterseniz Fabrika OT altyapı keşfi ve OT siber güvenlik ve segmentasyon hizmetlerimize bakabilirsiniz.

Sık sorulan sorular

Her OT değişikliği için duruş penceresi gerekir mi?

Gerekmez. Switch’e syslog hedefi eklemek ya da kullanılmayan bir portun açıklamasını değiştirmek gibi prosese dokunmayan işler üretim sırasında yapılabilir. Firmware güncellemesi, PLC’ye yükleme, ring veya VLAN yapısına dokunan değişiklikler ise kontrollü bir duruşta ya da hattın ilgili bölümü güvenli duruma alındıktan sonra yapılır. Kararı değişikliğin risk sınıfı verir, aciliyet hissi değil.

Test ortamı yoksa değişiklik nasıl doğrulanır?

Yedek parça stoğundaki aynı model PLC ve switch ile masa üstü deneme, PLC simülasyon yazılımında mantık testi ve önce tek bir hat ya da hücrede pilot uygulama yapılır. Pilot en az bir tam üretim döngüsü boyunca izlenmeden değişiklik diğer hatlara yayılmaz.

Geri dönüş kararını kim verir?

Planda adı yazılı ve o sırada sahada olan tek bir kişi; genellikle üretim veya bakım tarafındaki pencere sorumlusu. Kriterler önceden yazıldığı için karar tartışılmaz: ölçülen sonuç kriteri karşılamıyorsa ya da son geri dönüş başlangıç zamanı geldiyse geri dönülür.

PLC firmware’i güncellendikten sonra eski sürüme dönülebilir mi?

Üreticiye ve modele bağlıdır. Bazı modeller düşük sürüme dönüşe izin verir, bazıları vermez ya da proje dosyasının da eski sürüme göre yeniden derlenmesini ister. Geri dönüş planı yazılmadan önce sürüm notlarındaki düşürme (downgrade) koşulları okunur; dönüş desteklenmiyorsa geri dönüş yöntemi, hazırda bekleyen yedek CPU ile fiziksel değişimdir.