DO-178C Standardı: Emniyet Kritik Havacılık Yazılım Süreçleri

Hızlı Özet (TL;DR)

DO-178C (“Software Considerations in Airborne Systems and Equipment Certification”), sivil ve askeri hava araçlarında (uçak, helikopter, İHA/SİHA ve aviyonik alt sistemler) çalışan tüm gömülü ve görev kritik yazılımların emniyet ve güvenilirlik gereksinimlerini belirleyen uluslararası havacılık standardıdır. RTCA ve EUROCAE (ED-12C) tarafından ortaklaşa geliştirilen ve FAA, EASA ile SHGM gibi sivil havacılık otoriteleri tarafından sertifikasyon temeli kabul edilen bu kılavuz, yazılımda meydana gelebilecek tek bir mantıksal hatanın veya bellek taşmasının ölümcül uçak kazalarına yol açmasını engellemeyi hedefler. Havacılık projelerinde yazılım, donanımdan bağımsız düşünülemez; bu nedenle sistem seviyesinde ARP4754A, emniyet analizlerinde ARP4761 ve karmaşık elektronik donanım (FPGA/ASIC) tarafında DO-254 standartlarıyla tam entegre bir mühendislik disiplini yürütülür.

Havacılık Ekosisteminde Sistem Emniyeti ve DO-178C Mimarisi

Ticari veya savunma amaçlı bir hava aracında çalışan yazılım, masaüstü veya kurumsal sunucu yazılımlarından tamamen farklı bir deterministik (öngörülebilir) çalışma rejimine tabidir. Uçuş esnasında bir aviyonik bilgisayarın “yeniden başlatılması”, bellek sızıntısı (memory leak) nedeniyle yanıt vermemesi veya beklenmedik bir istisna (exception) fırlatarak görevini durdurması kabul edilemez.

Havacılık sertifikasyon süreci doğrudan kod yazmakla başlamaz. Öncelikle SAE ARP4754A standardı çerçevesinde hava aracının sistem fonksiyonları tanımlanır ve SAE ARP4761 metodolojisi ile Fonksiyonel Tehlike Analizi (FHA - Functional Hazard Assessment), Ön Sistem Emniyet Değerlendirmesi (PSSA) ve Sistem Emniyet Değerlendirmesi (SSA) gerçekleştirilir. Bu emniyet analizleri sonucunda, bir sistemdeki yazılım hatasının hava aracına, mürettebata ve yolculara verebileceği potansiyel zarar derecelendirilir. İşte bu derecelendirme, yazılımın hangi Tasarım Güvence Seviyesinde (DAL - Design Assurance Level) geliştirileceğini ve doğrulanacağını belirler.

Yazılım Seviyeleri (Design Assurance Level - DAL) Karşılaştırma Matrisi

Standardın kalbinde, yazılımın anormal davranması veya çökmesi durumunda uçuş emniyetine getireceği risk derecesi yatar. DO-178C, en kritik seviye olan DAL A’dan emniyet etkisi bulunmayan DAL E’ye kadar beş kademeli bir matris tanımlar:

Seviye	Hata Durumunun Etkisi	Maksimum Hata Olasılığı (Uçuş Saati Başına)	Örnek Hava Aracı Sistemi	Gerekli Hedef Sayısı (DO-178C)	Yapısal Kod Kapsama Kriteri
DAL A	Katastrofik (Hava aracının kaybı, çoklu ölümcül kaza)	$< 10^{-9}$	Uçuş Kontrol Bilgisayarı (Fly-by-Wire), Motor Kontrol (FADEC)	71 Hedef (33’ü Bağımsız Doğrulama)	Statement + Decision + MC/DC
DAL B	Tehlikeli / Ağır (Ciddi yaralanma, kritik sistem kaybı)	$< 10^{-7}$	Frenleme Kontrolü, İniş Takımı Yönetimi, Birincil Uçuş Ekranı (PFD)	69 Hedef (21’i Bağımsız Doğrulama)	Statement + Decision (Branch)
DAL C	Büyük (Mürettebat iş yükünde aşırı artış, emniyet marjı düşüşü)	$< 10^{-5}$	İkincil Seyrüsefer Sistemleri, İletişim Radyoları, Yakıt Yönetimi	62 Hedef (8’i Bağımsız Doğrulama)	Statement Coverage (Satır Kapsama)
DAL D	Küçük (Operasyonel aksama, yolcu konforunda azalma)	$< 10^{-3}$	Kabin İklimlendirme, Uçuş Veri Kaydedici Yardımcı Birimleri	26 Hedef (2’si Bağımsız Doğrulama)	Yapısal Kod Kapsama Zorunlu Değil
DAL E	Emniyete Etkisi Yok	Sınır Yok	Uçak İçi Eğlence Sistemi (IFE), Yolcu Wi-Fi Ağı	0 Hedef (Sertifikasyon Dışı)	Yok

Tabloda görülen “Bağımsız Doğrulama (Independence)” kavramı, ilgili yazılım gereksinimini veya kaynak kodu yazan mühendis ile o çıktıyı doğrulayan, test senaryosunu koşan ve gözden geçiren (review) mühendisin farklı kişiler olmasını zorunlu kılar.

DO-178C Yazılım Yaşam Döngüsü ve 5 Temel Planlama Dokümanı

DO-178C bir “kodlama kılavuzu” olmaktan ziyade, baştan sona kanıtlanabilir bir süreç standardıdır. Bir projede ilk satır kod yazılmadan önce sertifikasyon otoritesine (DER / CVE denetçilerine) sunulmak üzere beş temel planlama dokümanı hazırlanır:

1. PSAC (Plan for Software Aspects of Certification): Sertifikasyon otoritesiyle yapılan ana sözleşmedir. Sistemin genel mimarisini, hedeflenen DAL seviyesini, kullanılacak ek teknoloji standartlarını ve sertifikasyon takvimini tanımlar.
2. SDP (Software Development Plan): Gereksinim yazımı, mimari tasarım ve kodlama aşamalarında hangi mühendislik yöntemlerinin, programlama dillerinin (C, C++, Ada) ve kodlama standartlarının (örneğin MISRA C) kullanılacağını belirler.
3. SVP (Software Verification Plan): Gözden geçirme (review), statik analiz, birim testi, entegrasyon testi ve donanım üzerinde test (HIL) süreçlerinin nasıl yürütüleceğini detaylandırır.
4. SCMP (Software Configuration Management Plan): Kaynak kodların, derleyici parametrelerinin, test betiklerinin ve dokümanların sürüm kontrolünü, temel hat (baseline) yönetimini ve değişiklik kontrol kurullarını (CCB) tanımlar.
5. SQAP (Software Quality Assurance Plan): Süreçlerin tanımlanan planlara uygun yürütüldüğünü denetleyen bağımsız kalite güvence mekanizmasını ortaya koyar.

Gereksinim Mühendisliği ve Çift Yönlü İzlenebilirlik (Bidirectional Traceability)

Standart kapsamında yazılım geliştirme süreci iki katmanlı gereksinim mimarisi üzerine inşa edilir: Yüksek Seviyeli Gereksinimler (HLR - High-Level Requirements) ve Düşük Seviyeli Gereksinimler (LLR - Low-Level Requirements). Sistem mühendisliğinden gelen sistem gereksinimleri HLR’ye dönüştürülür; HLR ise yazılım mimarisiyle birleşerek doğrudan kaynak kod fonksiyonlarına dönüşecek kadar detaylı LLR maddelerine ayrıştırılır.

Çift yönlü izlenebilirlik ilkesi gereği:

• Her bir Sistem Gereksinimi en az bir HLR’ye, her HLR ilgili LLR maddelerine, her LLR doğrudan Kaynak Kod satırlarına ve her gereksinim mutlaka onu doğrulayan Test Senaryolarına (Test Cases) bağlanmalıdır.
• Ters yönde bakıldığında ise kaynak koddaki her bir satırın ve koşulun neden var olduğu bir LLR’ye dayandırılmalıdır. Herhangi bir gereksinime dayanmayan “yetim kod” (orphan code) veya “ölü kod” (dead code) barındıran bir yazılım DO-178C denetiminden geçemez.

Savunma ve havacılık projelerinde gereksinim izlenebilirliğini ve mühendislik iş akışlarını dijitalleştiren çözümlerimiz için Özel Yazılım Geliştirme sayfamızı inceleyebilirsiniz.

Deterministik Kodlama Kuralları ve Yapısal Kapsama Analizi (MC/DC)

Emniyet kritik aviyonik yazılımlarda (özellikle DAL A ve DAL B seviyesinde) çalışma zamanı (runtime) belirsizliklerini sıfırlamak için çok katı kodlama kısıtlamaları uygulanır:

• Dinamik Bellek Tahsisi Yasağı: Çalışma esnasında malloc(), calloc(), free() veya new/delete gibi heap belleği dinamik olarak parçalayan (fragmentation) fonksiyonlar kullanılmaz. Tüm bellek blokları sistem başlatılırken statik olarak tahsis edilir.
• Özyineleme (Recursion) Yasağı: Kendi kendini çağıran fonksiyonlar yığın taşmasına (stack overflow) yol açabileceği ve En Kötü Durum Çalışma Süresi (WCET - Worst-Case Execution Time) hesabını imkansız kıldığı için yasaktır.
• Sınırlı Döngüler ve İşaretçi Güvenliği: Sonsuz döngü riski taşıyan yapılar sınırlandırılır; karmaşık işaretçi (pointer) aritmetiği ve tip dönüşümleri MISRA C:2012 veya CERT C kurallarıyla statik analiz araçları üzerinden denetlenir.

Gereksinim Tabanlı Test ve MC/DC Doğrulaması

DO-178C’de testler “kodu test etmek” için değil, gereksinimleri doğrulamak (Requirements-Based Testing) için yazılır. Normal şartlar testi (Normal Range) ve sağlamlık testi (Robustness / sınır değer ve hatalı girdi testleri) tamamlandıktan sonra, yazılan bu testlerin kaynak kodun ne kadarını çalıştırdığı Yapısal Kapsama Analizi (Structural Coverage Analysis) ile ölçülür:

• Statement Coverage (DAL C): Kaynak koddaki her çalıştırılabilir satırın testler sırasında en az bir kez işletildiğini kanıtlar.
• Decision / Branch Coverage (DAL B): Her if-else, switch-case veya döngü karar noktasının hem True hem de False dallarının test edildiğini doğrular.
• MC/DC - Modified Condition / Decision Coverage (DAL A): Karmaşık bir mantıksal kararda (örneğin if ((A || B) && C)) yer alan her bir tekil koşulun (A, B ve C), diğer koşullar sabit tutulduğunda nihai kararın sonucunu tek başına bağımsız olarak değiştirebildiğini kanıtlayan matematiksel test yöntemidir. $N$ adet koşul içeren bir karar ifadesi için $2^N$ kombinasyon yerine minimum $N+1$ test senaryosu ile %100 mantıksal doğrulama sağlar.

DO-178C Ek Kılavuzları (Supplements) ve DO-254 Donanım Entegrasyonu

2011 yılında yayınlanan DO-178C, önceki sürüm olan DO-178B’nin modern yazılım teknolojilerine uyarlanması amacıyla dört kritik ek standartla (Supplement) birlikte yürürlüğe girmiştir:

• DO-330 (Software Tool Qualification Considerations): Geliştirme veya doğrulama sürecinde kullanılan kod üreticilerin, statik analizörlerin ve test otomasyon araçlarının (TQL-1’den TQL-5’e kadar) kalifikasyon kriterlerini belirler.
• DO-331 (Model-Based Development and Verification): SCADE veya Simulink gibi model tabanlı tasarım araçlarıyla geliştirilen aviyonik yazılımların simülasyon ve model kapsama süreçlerini tanımlar.
• DO-332 (Object-Oriented Technology and Related Techniques): Nesne yönelimli programlamadaki kalıtım (inheritance), çok biçimlilik (polymorphism) ve dinamik bağlama (dynamic dispatch) mekanizmalarının deterministik sınırlarını çizer.
• DO-333 (Formal Methods Supplement): Yazılımın doğruluğunu matematiksel ispat yöntemleriyle (soyut yorumlama, teorem ispatlama) kanıtlayarak bazı test aşamalarının ikame edilmesini düzenler.

DO-254 ile Karmaşık Elektronik Donanım Güvencesi

Modern aviyonik kartlarda algoritmalar yalnızca mikroişlemci üzerindeki yazılımda değil, yüksek hızlı paralel işleme gerektiren FPGA (Field Programmable Gate Array), PLD ve ASIC yongaları üzerinde koşar. RTCA DO-254 standardı, VHDL veya Verilog ile kodlanan bu donanım tasarımlarının tıpkı yazılımda olduğu gibi DAL A–E seviyelerinde gereksinim izlenebilirliğine, fonksiyonel simülasyona, zamanlama analizine (Static Timing Analysis) ve hedef donanım testlerine tabi tutulmasını zorunlu kılar.

Savunma sanayii alt yüklenicilerinin ağ izolasyonu, veri güvenliği ve uyumluluk gereksinimleri için Savunma Sanayii Ağ ve Siber Güvenlik ile üretim izlenebilirliği odaklı Özel İmalat Çözümleri sayfalarımızı inceleyebilirsiniz.

Sıkça Sorulan Sorular

DO-178B ile DO-178C arasındaki temel fark nedir?

DO-178C, temel yaşam döngüsü felsefesini korumakla birlikte hedef sayılarını artırmış (örneğin DAL A için 66 hedeften 71 hedefe çıkılmıştır), parametre veri öğesi dosyalarının (Parameter Data Items) doğrulanmasını netleştirmiş ve en önemlisi DO-330 (Araç Kalifikasyonu), DO-331 (Model Tabanlı Geliştirme), DO-332 (Nesne Yönelimli Teknolojiler) ve DO-333 (Biçimsel Yöntemler) ek standartlarını resmi sertifikasyon çerçevesine dahil etmiştir.

Bir yazılım doğrudan “DO-178C sertifikalı” olarak satılabilir mi?

Hayır. Havacılık otoriteleri (FAA, EASA) tek başına bir yazılım kütüphanesine veya işletim sistemine bağımsız “DO-178C sertifikası” vermez. Yazılım her zaman entegre edildiği aviyonik ekipmanın (TSO - Technical Standard Order) veya hava aracının Tip Sertifikasının (Type Certificate / STC) bir parçası olarak onaylanır. Ancak ticari hazır yazılımlar (COTS / RTOS), entegrasyonu kolaylaştırmak adına tüm DO-178C yaşam döngüsü kanıt paketleriyle (Certification Evidence Package) birlikte “sertifikasyona hazır” olarak sunulur.

Yapısal kapsama analizinde %100 kapsanmayan kod çıkarsa ne yapılır?

Gereksinim tabanlı testler tamamlandığında kapsanmayan kod satırları veya koşullar tespit edilirse üç olasılık vardır: Birincisi, gereksinimler eksik yazılmıştır (yeni gereksinim ve test eklenir). İkincisi, test senaryoları yetersizdir (mevcut gereksinimi tam doğrulayacak yeni test senaryoları yazılır). Üçüncüsü ise kodda hiçbir gereksinime dayanmayan “ölü kod” (dead code) vardır ve bu kod kaynak dosyadan derhal silinmelidir. Farklı uçak konfigürasyonları için bırakılan “devre dışı kodlar” (deactivated code) içinse çalışma anında asla tetiklenemeyeceği matematiksel ve mimari olarak kanıtlanmalıdır.