Çökme Lüksü Olmayan Sistemler: Emniyet Kritik Yazılımın Kırmızı Çizgileri ve Yasaklı Kodlama Kuralları

Emniyet kritik sistemlerde amaç hızlı çalışan kod değil; sınırları ve davranışı matematiksel olarak doğrulanabilir kod yazmaktır.

Telefonunuzdaki bir uygulama çöktüğünde en fazla canınız sıkılır ve uygulamayı kapatıp yeniden başlatırsınız. Ancak saatte 900 kilometre hızla seyreden bir yolcu uçağının uçuş kontrol bilgisayarında, raylı sistem sinyalizasyonunda veya bir nükleer reaktörün soğutma döngüsünde sistemin kesintiye uğraması veya kontrolsüz yeniden başlatılması kabul edilemez. Emniyet kritik sistemlerin mühendisliği, genel amaçlı yazılım geliştirme dünyasından taban tabana zıt bir disiplin üzerine kuruludur. Standart yazılımda geliştiricilere hız ve esneklik kazandıran en popüler araçlar bu alanda doğrudan saatli bomba muamelesi görür. Bu analiz; MISRA C ve ISO 26262 gibi standartların getirdiği katı yasakları, hız yerine determinizmi önceleyen mimari mantığı ve emniyet kritik yazılımın değişmez kurallarını ortaya koyuyor.

Hız Değil Kesinlik: Determinizm Neden Tek Önceliktir?

Genel amaçlı yazılım dünyasında rekabet genellikle ortalama çalışma hızı, özellik zenginliği ve geliştirme çevikliği üzerinden yürür. Oysa insan hayatının veya yüksek maliyetli endüstriyel tesislerin söz konusu olduğu emniyet kritik sistemlerde tek bir değişmez öncelik vardır: determinizm.

Determinizm; sistemin aynı başlangıç durumunda ve aynı girdi kümesiyle karşılaştığında her zaman tam olarak aynı çıktıyı üretmesi ve durum geçişlerini önceden bilinen sürelerde tamamlamasıdır. Bu sistemlerde ortalama çalışma süresinin kısa olması hiçbir anlam ifade etmez. Asıl belirleyici olan, en kötü durum çalışma süresinin matematiksel olarak sınırlandırılmış olmasıdır.

Aşağıdaki tablo, genel amaçlı yazılım yaklaşımı ile emniyet kritik sistem felsefesi arasındaki derin ayrımı özetlemektedir:

Kriter	Genel Amaçlı Yazılım (Web, Mobil, IT)	Emniyet Kritik Yazılım (Otomotiv, Raylı Sistemler, Havacılık)
Temel Hedef	Ortalama performans, esneklik, hızlı teslimat	Determinizm, en kötü durum garantisi, sıfır sürpriz
Hata Toleransı	Yeniden başlatma, çökme logları, istisna yakalama	Güvenli duruma geçiş, donanımsal yedeklilik, kesintisiz çalışma
Bellek Modeli	Dinamik tahsis, çöp toplayıcılar, esnek boyutlar	Katı statik tahsis, derleme anında sabitlenmiş sınırlar
Kontrol Akışı	Özyineleme, olay tabanlı asenkron akış, try-catch	Deterministik döngüler, açık durum makineleri, açık hata kodları
Tasarım Felsefesi	Sınırsız ölçeklenebilirlik	Kanıtlanabilir şekilde yeterli ve sınırlı sistem

Emniyet Kritik Yazılımın Yasaklı Bölgesi

MISRA C ve ISO 26262 gibi standartlar, genel yazılım dünyasında her gün kullanılan birçok popüler yapıyı kesin bir dille sınırlar veya tamamen yasaklar. Bu yasakların arkasındaki teknik gerekçeler ve güvenli alternatifler şunlardır:

Dinamik Bellek Yönetimi (malloc / free)

Neden Yasaktır? Çalışma anında yığın bellekten dinamik yer ayırmak iki büyük risk yaratır: bellek parçalanması ve belirsiz çalışma süresi. Günlerce veya aylarca kesintisiz çalışan bir kontrolörde dinamik tahsisler zamanla belleği parçalar; toplamda boş alan olsa dahi tek parça bitişik blok bulunamadığında sistem aniden kilitlenir. Ayrıca bir bellek ayırma fonksiyonunun kaç mikrosaniye süreceği çalışma anında garanti edilemez.
Güvenli Çözüm: Katı statik tahsis. İhtiyaç duyulan tüm tamponlar ve veri yapıları derleme anında tanımlanır ve bellekteki yerleri baştan rezerve edilir.

Özyineleme (Recursion)

Neden Yasaktır? Bir fonksiyonun kendini doğrudan veya dolaylı olarak çağırması, her adımda çağrı yığınına yeni bir veri çerçevesi ekler. Girdiye bağlı olarak özyineleme derinliğinin nerede sonlanacağı yüzde 100 garanti edilemez; bu da yığın taşması arızasına yol açar. Statik kod analiz araçları bu tür yapıların sınırlarını matematiksel olarak kanıtlayamaz.
Güvenli Çözüm: Üst sınırı derleme zamanında belli olan yinelemeli döngüler kullanmak.

İstisna Yönetimi (try-catch)

Neden Yasaktır? İstisna fırlatıldığında kontrol akışı yerel olmayan gizli bir adrese sıçrar ve çağrı yığını geri sarılır. Bu sıçrama, fonksiyonun ne kadar sürede sonlanacağını ve hangi ara durumlardan geçeceğini hesaplamayı imkansız hale getirir; statik analiz araçlarının kontrol akış grafiğini bozar.
Güvenli Çözüm: Açık durum ve hata kodları. Fonksiyonların dönüş değerleri açıkça hata durumunu belirtmeli ve çağıran kod bu değeri kontrol etmek zorunda bırakılmalıdır.

Dinamik İş Parçacıkları ve Görevler

Neden Yasaktır? Çalışma anında rasgele iş parçacığı veya proses oluşturmak, çekirdekler arası veri yarışlarına, kilitlenmelere ve öncelik terslenmesine zemin hazırlar.
Güvenli Çözüm: Statik görev mimarisi. Sistemin ihtiyaç duyduğu tüm periyodik ve kesme görevleri sistem önyüklemesi sırasında bir kez oluşturulur; öncelikleri ve zaman dilimleri baştan sabitlenir.

Kontrolsüz İşaretçi Aritmetiği

Neden Yasaktır? Bellek adresleri üzerinde toplama ve çıkarma yapmak, işaretçinin amaçlanan sınırların dışına çıkmasına ve komşu kritik sistem değişkenlerinin üzerine yazılmasına neden olabilir. Bu durum hem kestirilemeyen arızalara hem de güvenlik açıklarına yol açar.
Güvenli Çözüm: Dizi indeksleme kullanımı ve MISRA işaretçi kurallarına tavizsiz uyum.

Sıkıcı Kod Güvenli Koddur

Yazılımcılar için akıllıca yazılmış, tek satırda karmaşık işler başaran veya en yeni dil özelliklerini kullanan kodlar cazip gelebilir. Ancak emniyet kritik dünyada zeka gösterileri değil, sıkıcı ve öngörülebilir sadelik değer görür.

Kod, yalnızca derleyici veya işlemci için değil, aynı zamanda statik analiz araçları ve güvenlik denetçileri için yazılır. Eğer bir kod bloğunun en kötü durum davranışı matematiksel olarak kanıtlanamıyorsa, o kod emniyetli değildir.

Bu kurallar mühendislerin elini kolunu bağlamak veya yaratıcılığı yok etmek için değil; kritik anlarda sistemin hata yapmasını önlemek ve sahada insan hayatını korumak için vardır.

📚 Kaynaklar

MISRA C:2023 : Guidelines for the Use of the C Language in Critical Systems, MISRA Consortium.
ISO 26262 : Road Vehicles — Functional Safety, International Organization for Standardization.
IEC 61508-3 : Functional Safety of Electrical/Electronic/Programmable Electronic Safety-related Systems – Software Requirements, IEC.

📋 İlgili Bağlantılar

🔗 HSE Raporu ve Şartnamelerin Hayati Önemi: Kontrol Sistemi Arızaları Nerede Başlar?
🔗 Büyük Resim ve Sistem Mühendisliği: Puzzle Analojisi ile Proje Başarısızlıkları

Son güncelleme: Aralık 2025 | Versiyon: 1.0