DO-178C Nedir? Havacılık Yazılım Sertifikasyonu Rehberi
Bir uçağın otopilot sistemi, motor kontrol ünitesi veya uçuş gösterge ekranı çalışıyor. Bu sistemlerin arkasında milyonlarca satır yazılım kodu var. Bir yazılım hatası ne sonuç doğurabilir?
Havacılık yazılımında hata toleransı yoktur. DO-178C, havacılık yazılımının güvenli ve güvenilir olduğunu kanıtlamak için uygulanan temel standarttır.
DO-178C Ne Demek?
DO-178C, "Software Considerations in Airborne Systems and Equipment Certification" başlıklı standarttır. RTCA (Radio Technical Commission for Aeronautics) tarafından yayınlanmış olup, havacılık yazılımlarının sertifikasyonu için dünya çapında kabul görmüş kılavuzdur.
Tam adı: RTCA DO-178C / EUROCAE ED-12C
Yayın tarihi: Aralık 2011 (DO-178B'nin yerini aldı)
Standart Kapsamı
DO-178C şunları kapsar:
- Sivil havacılık uçak yazılımları
- Aviyonik sistemler
- Uçuş kontrol yazılımları
- Motor kontrol sistemleri
- Gösterge ve ekran sistemleri
- İletişim/navigasyon yazılımları
Neden Önemli?
DO-178C uyumu olmadan:
- FAA (ABD) tip sertifikası alınamaz
- EASA (Avrupa) onayı verilemez
- Sivil havacılık pazarına girilemez
DO-178C ve DO-178B Farkı
| Özellik | DO-178B (1992) | DO-178C (2011) |
|---|---|---|
| Model tabanlı geliştirme | Yok | DO-331 eki ile desteklenir |
| Nesne yönelimli teknoloji | Yok | DO-332 eki ile desteklenir |
| Formal metotlar | Yok | DO-333 eki ile desteklenir |
| Araç kalifikasyonu | Sınırlı | DO-330 ile detaylı |
| Parametre veri | Belirsiz | Netleştirilmiş |
DO-178C, temel prensipleri koruyarak modern yazılım geliştirme tekniklerini kapsayacak şekilde güncellendi.
DAL Seviyeleri (Design Assurance Level)
Yazılımın kritiklik seviyesi, DAL (Design Assurance Level) ile belirlenir. DAL, yazılım hatasının uçuş güvenliğine etkisine göre tanımlanır.
DAL A - Felaket (Catastrophic)
Tanım: Yazılım hatası uçağın veya birden fazla kişinin kaybına yol açar.
Örnekler:
- Birincil uçuş kontrol yazılımı (fly-by-wire)
- Motor tam otorite kontrolü (FADEC)
- Kritik navigasyon sistemleri
Gereksinimler:
- En sıkı doğrulama
- %100 MC/DC yapısal kapsam
- Bağımsız doğrulama ekibi
DAL B - Tehlikeli (Hazardous)
Tanım: Yazılım hatası ciddi yaralanma veya büyük hasar, uçuş mürettebatının aşırı iş yükü.
Örnekler:
- İkincil uçuş kontrol sistemleri
- Uyarı sistemleri
- Otopilot (bazı fonksiyonlar)
Gereksinimler:
- Yüksek doğrulama seviyesi
- %100 DC + MC/DC (gerekiyorsa)
- Bağımsız gözden geçirme
DAL C - Majör (Major)
Tanım: Yazılım hatası güvenlik marjını önemli ölçüde azaltır, mürettebat iş yükünü artırır.
Örnekler:
- Gösterge sistemleri
- İletişim sistemleri
- Yardımcı sistemler
Gereksinimler:
- Orta seviye doğrulama
- %100 karar kapsamı (DC)
- Gözden geçirmeler
DAL D - Minör (Minor)
Tanım: Yazılım hatası küçük operasyonel etki, güvenlik marjında hafif azalma.
Örnekler:
- Kabin eğlence sistemleri
- Yardımcı göstergeler
- Bakım fonksiyonları
Gereksinimler:
- Temel doğrulama
- %100 deyim kapsamı (SC)
- Temel gözden geçirme
DAL E - Etki Yok (No Effect)
Tanım: Yazılım hatası uçuş güvenliğini etkilemez.
Örnekler:
- Bakım kayıt yazılımı
- Yer destek sistemleri
Gereksinimler:
- DO-178C doğrulama gereksinimleri uygulanmaz
- Temel yazılım mühendisliği yeterli
Yazılım Yaşam Döngüsü Süreçleri
DO-178C, yazılım geliştirme için integral süreçler ve yazılım yaşam döngüsü süreçleri tanımlar.
Planlama Süreci
Çıktılar:
- PSAC (Plan for Software Aspects of Certification)
- SDP (Software Development Plan)
- SVP (Software Verification Plan)
- SCMP (Software Configuration Management Plan)
- SQAP (Software Quality Assurance Plan)
Aktiviteler:
- Yazılım seviyesi belirleme
- Yaşam döngüsü tanımlama
- Geliştirme ortamı seçimi
- Standartlar belirleme
Gereksinim Süreci
Yüksek seviye gereksinimler (HLR):
- Sistem gereksinimlerinden türetilir
- Fonksiyonel ve performans gereksinimleri
- Güvenlik gereksinimleri
- Arayüz gereksinimleri
Düşük seviye gereksinimler (LLR):
- HLR'den türetilir
- Tasarıma yakın detay
- Yazılım mimarisi kararları
Tasarım Süreci
Yazılım mimarisi:
- Bileşen tanımları
- Veri ve kontrol akışı
- Kaynak kullanımı (bellek, CPU)
- Partitioning (izolasyon)
Kodlama Süreci
Kodlama standartları:
- Kodlama kuralları (MISRA C gibi)
- Karmaşıklık limitleri
- İsimlendirme kuralları
- Yorum gereksinimleri
Entegrasyon Süreci
Aktiviteler:
- Yazılım-yazılım entegrasyonu
- Donanım-yazılım entegrasyonu
- Sistem entegrasyonu
Doğrulama (Verification)
DO-178C'nin en kritik bölümü doğrulama sürecidir.
Gözden Geçirme (Reviews)
Türleri:
- Gereksinim gözden geçirme
- Tasarım gözden geçirme
- Kod gözden geçirme
- Test sonuç gözden geçirme
Bağımsızlık gereksinimleri (DAL'a göre):
| DAL | Gereksinim | Kod | Test |
|---|---|---|---|
| A | Bağımsız | Bağımsız | Bağımsız |
| B | Bağımsız | Bağımsız | Gözden geçirme |
| C | Gözden geçirme | Gözden geçirme | Gözden geçirme |
| D | - | - | - |
Analiz
Türleri:
- İzlenebilirlik analizi
- Veri ve kontrol akışı analizi
- En kötü durum çalışma zamanı analizi (WCET)
- Stack kullanım analizi
- Güvenlik analizi
Test
Test seviyeleri:
- Birim testi (Unit test)
- Entegrasyon testi
- Yazılım/donanım entegrasyon testi
- Sistem testi
Yapısal kapsam analizi (DAL'a göre):
| DAL | Gerekli Kapsam |
|---|---|
| A | MC/DC (Modified Condition/Decision Coverage) |
| B | DC (Decision Coverage) + MC/DC (bazı durumlarda) |
| C | DC (Decision Coverage) |
| D | SC (Statement Coverage) |
MC/DC Nedir?
Modified Condition/Decision Coverage en sıkı yapısal kapsam kriteridir.
Gereksinimler:
- Her karar (decision) en az bir kez true ve false değeri almış
- Her koşul (condition) en az bir kez true ve false değeri almış
- Her koşulun, kararı bağımsız olarak etkilediği gösterilmiş
Örnek:
if (A && B) then...
MC/DC için minimum test durumları:
| Test | A | B | Sonuç |
|---|---|---|---|
| 1 | T | T | T |
| 2 | T | F | F |
| 3 | F | T | F |
Yazılım Yapılandırma Yönetimi
Konfigürasyon Tanımlama
- Konfigürasyon öğelerinin belirlenmesi
- Baseline tanımları
- Sürüm numaralandırma
Değişiklik Kontrolü
- Problem raporlama
- Değişiklik istekleri
- Etki analizi
- Onay süreci
Durum Muhasebesi
- Konfigürasyon durumu raporlama
- Geçmiş kayıtları
Denetim
- Fiziksel konfigürasyon denetimi
- Fonksiyonel konfigürasyon denetimi
Kalite Güvence
Süreç Güvencesi
- Planların uygulanması
- Standartlara uyum
- Sapmaların raporlanması
Ürün Güvencesi
- Uyumluluk gözden geçirmeleri
- Problem raporlarının takibi
Geçiş Kriterleri
- Süreç geçiş kontrolleri
- Milestone denetimleri
Sektörel Uzmanlık için Profesyonel Eğitimler
AS9100, DO-178C, DO-254, NADCAP, AMS 2750 ve daha fazlası için sektör deneyimli uzman eğitmenlerden sertifikalı eğitim programları.
Eğitimleri KeşfetSertifikalı Eğitimler
Uluslararası geçerlilikte sertifikalar
Uzman Eğitmenler
Sektör deneyimli profesyoneller
Uygulamalı İçerik
Gerçek vaka çalışmaları
Esnek Programlar
Online ve yüz yüze seçenekler
DO-178C Ekleri (Supplements)
DO-330: Yazılım Araç Kalifikasyonu
Amaç: Geliştirme ve doğrulama araçlarının kalifikasyonu.
Araç Kalifikasyon Seviyeleri (TQL):
| TQL | Açıklama |
|---|---|
| TQL-1 | Doğrulama çıktısı üreten (DAL A) |
| TQL-2 | Doğrulama çıktısı üreten (DAL B) |
| TQL-3 | Doğrulama çıktısı üreten (DAL C/D) |
| TQL-4 | Hata önleme/tespit edilemez (DAL A/B) |
| TQL-5 | Hata önleme/tespit edilemez (DAL C/D) |
Kalifikasyon gerektiren araçlar:
- Test araçları (test çerçeveleri)
- Kapsam analiz araçları
- Statik analiz araçları
- Kod üreticileri
- Derleyiciler (bazı durumlarda)
DO-331: Model Tabanlı Geliştirme
Kapsam:
- Model tabanlı tasarım (Simulink, SCADE gibi)
- Otomatik kod üretimi
- Model doğrulama
Ek gereksinimler:
- Model standartları
- Model gözden geçirme
- Model test
- Model kapsam analizi
DO-332: Nesne Yönelimli Teknoloji
Kapsam:
- OOT (Object-Oriented Technology) kullanımı
- C++, Ada 2012 gibi diller
Ele alınan sorunlar:
- Kalıtım (inheritance)
- Polimorfizm
- Dinamik bellek
- İstisna yönetimi
DO-333: Formal Metotlar
Kapsam:
- Formal spesifikasyon
- Formal doğrulama
- Model checking
- Teorem ispatlama
Kullanım:
- Test yerine/tamamlayıcı olarak
- Yüksek DAL seviyelerinde avantaj
Sertifikasyon Süreci
Sertifikasyon Otoriteleri
| Otorite | Bölge |
|---|---|
| FAA | ABD |
| EASA | Avrupa |
| TCCA | Kanada |
| ANAC | Brezilya |
| SHGM | Türkiye |
Sertifikasyon Koordinasyon Toplantıları
Tipik SOI (Stages of Involvement):
- SOI #1: Planlama gözden geçirme
- SOI #2: Geliştirme süreçleri gözden geçirme
- SOI #3: Doğrulama süreçleri gözden geçirme
- SOI #4: Nihai sertifikasyon gözden geçirme
Sertifikasyon Çıktıları
SCI (Software Conformity Index):
- Yazılım yaşam döngüsü verilerinin özetiFull_project
- Konfigürasyon indeksi
- Açık problem raporları durumu
SAS (Software Accomplishment Summary):
- Yazılım geliştirme özeti
- Uyum beyanı
- Özellikler ve sınırlamalar
Problem Raporlama
Problem Raporu Kategorileri
DO-178C'de problem raporları (PR) kritik öneme sahiptir:
Kategori 1: Yazılım düzeltmesi gerektirir Kategori 2: Düzeltme gerekmez ama değerlendirilmeli
Açık PR Yönetimi
- Sertifikasyon öncesi tüm Kategori 1 PR'lar kapatılmalı
- Açık PR'ların güvenlik etkisi değerlendirilmeli
Havacılık Yazılım Geliştirme Araçları
Yaygın Kullanılan Araçlar
| Kategori | Araçlar |
|---|---|
| Modelleme | SCADE, Simulink, Rhapsody |
| Gereksinim | DOORS, Polarion, Jama |
| Test | VectorCAST, LDRA, Cantata |
| Kapsam | CTC++, BullseyeCoverage |
| Statik Analiz | Polyspace, CodeSonar, Coverity |
| Konfigürasyon | ClearCase, Git (sınırlı), Synergy |
Araç Zinciri Değerlendirmesi
Araç seçiminde değerlendirilecekler:
- TQL gereksinimleri
- Araç operasyonel gereksinimleri
- Sertifikasyon deneyimi
- Destek ve bakım
Yaygın Zorluklar
Zorluk 1: Gereksinim İzlenebilirliği
Sorun: Çift yönlü izlenebilirliğin sağlanması zor.
Çözüm:
- Gereksinim yönetim aracı kullan
- İzlenebilirlik matrislerini erken oluştur
- Otomatik izlenebilirlik araçları
Zorluk 2: MC/DC Kapsamı
Sorun: Bazı kod yapıları %100 MC/DC'ye ulaşmayı zorlaştırır.
Çözüm:
- Savunma kodu (dead code) analizi
- Kod tasarım kuralları
- Deaktivasyon haklılaştırması
Zorluk 3: Araç Kalifikasyonu
Sorun: Araç kalifikasyonu zaman alıcı ve maliyetli.
Çözüm:
- Önceden kalifiye araçlar tercih et
- Araç kalifikasyon kitlerini kullan
- Kalifikasyon kapsamını optimize et
Zorluk 4: Eski Kod (Legacy Code)
Sorun: Mevcut kodun DO-178C'ye uyumlandırılması.
Çözüm:
- Reverse engineering
- Ek doğrulama aktiviteleri
- Değişiklik etkisi analizi
Sıkça Sorulan Sorular
DO-178C sertifikası var mı?
Hayır, DO-178C bir kılavuzdur, sertifikasyon standardı değildir. Ürünler FAA/EASA tarafından sertifikalandırılır, DO-178C bu sürecin "nasıl" yapılacağını tanımlar.
DO-178C ve ISO 26262 farkı nedir?
DO-178C havacılık yazılımı içindir, ISO 26262 otomotiv yazılımı içindir. Prensipleri benzer (DAL vs ASIL), ancak detay gereksinimleri farklıdır.
DAL seviyesini kim belirler?
DAL, sistem güvenlik değerlendirmesi (ARP 4761) ve sistem geliştirme süreci (ARP 4754A) sonucunda belirlenir. Nihai onay sertifikasyon otoritesindedir.
Agile geliştirme DO-178C ile uyumlu mu?
Sınırlı olarak. DO-178C'nin dokümantasyon ve planlama gereksinimleri Agile'ın esnekliğiyle çelişebilir. Hybrid yaklaşımlar uygulanabilir.
DO-178C projesi ne kadar sürer?
Karmaşıklığa ve DAL seviyesine bağlı. Basit DAL D yazılımı aylar, karmaşık DAL A sistemi yıllar sürebilir.
DO-178C, havacılık yazılımının güvenliğini sağlamak için küresel standarttır. DAL seviyesine uygun geliştirme ve doğrulama süreçleri, güvenli uçuş yazılımlarının temelidir.
