-
Sadrazamv4
ig:sadrazam_v4 tg: Sadrazam.spy
DO-178C: Havacılık Sistemleri ve Ekipmanlarında Yazılım Sertifikasyon Standardı (Özet)
DO-178C (Avrupa'daki adıyla EUROCAE ED-12C), sivil ve askeri uçaklarda kullanılan yazılımların geliştirilmesi, test edilmesi ve sertifikalandırılması için ABD Federal Havacılık İdaresi (FAA) ve Avrupa Havacılık Emniyeti Ajansı (EASA) tarafından kullanılan birincil endüstri standardıdır.
DO-254 donanım dünyası için ne anlam ifade ediyorsa, DO-178C de yazılım dünyası için aynı anlama gelir. Amacı, uçuş kritik sistemlerde çalışan kodun güvenli, hatasız ve öngörülebilir olduğunu kanıtlamaktır.
Yazılım Güvenlik Seviyeleri (DAL - Design Assurance Level)
DO-178C, yazılımda meydana gelebilecek bir hatanın uçağa ve yolculara vereceği potansiyel zarara göre sistemi beş seviyeye (Level A'dan E'ye) ayırır. Testlerin katılığı ve üretilecek dokümantasyon miktarı bu seviyelere göre belirlenir:
Level A (Felaket - Catastrophic): Yazılım hatası uçağın güvenli uçuşunu ve inişini engeller, genellikle uçak kaybı ve çoklu can kaybı ile sonuçlanır (Örn: Uçuş kontrol yazılımları).
Level B (Tehlikeli - Hazardous): Uçağın güvenlik marjlarında ciddi bir azalma, uçuş ekibinin iş yükünde büyük bir artış ve az sayıda can kaybı riski oluşturur.
Level C (Önemli - Major): Uçuş ekibinin iş yükünde belirgin artış ve yolcularda fiziksel yaralanmalara yol açabilir.
Level D (Küçük - Minor): Uçuş planında hafif değişikliklere ve yolcularda rahatsızlıklara neden olur.
Level E (Etkisiz - No Effect): Uçuş güvenliğine, ekibe veya yolculara hiçbir etkisi yoktur (Örn: Uçak içi eğlence sistemi yazılımları).
DO-178C Yazılım Geliştirme Süreçleri
Standart, yazılımın baştan sona nasıl inşa edileceğini belirleyen katı bir yaşam döngüsü tanımlar:
Planlama (Planning): Sertifikasyon sürecinin nasıl yürütüleceğini otoritelerle baştan anlaştığınız aşamadır. Kullanılacak diller, derleyiciler ve standartlar PSAC (Plan for Software Aspects of Certification) belgesinde toplanır.
Yazılım Gereksinim Süreci (Requirements): Sistem seviyesinden gelen gereksinimler, "Yüksek Seviye Gereksinimlere (HLR)" dönüştürülür. Yazılımın ne yapması gerektiği burada tanımlanır.
Tasarım Süreci (Design): Yüksek seviye gereksinimler detaylandırılarak yazılım mimarisine ve "Düşük Seviye Gereksinimlere (LLR)" dönüştürülür.
Kodlama Süreci (Coding): Düşük seviye gereksinimler baz alınarak kaynak kodun (C, C++, Ada vb.) yazılması aşamasıdır.
Entegrasyon (Integration): Yazılım bileşenlerinin birleştirilerek hedef donanım üzerinde (veya donanım emülatörlerinde) çalıştırılabilir bir bütün haline getirilmesidir.
Destekleyici (İntegral) Süreçler
Yazılımın kalitesini ve standartlara uygunluğunu sağlayan sürekli süreçlerdir:
Doğrulama (Verification): Standart, kodun çalıştığını söylemenizi yeterli bulmaz, kanıtlamanızı ister. İncelemeler (Reviews), analizler ve en önemlisi Testler bu aşamada yapılır. Özellikle DAL A yazılımlar için MC/DC (Modified Condition/Decision Coverage) adı verilen çok katı bir kod kapsamı analizi zorunludur; koddaki her mantıksal koşulun bağımsız olarak sonucu değiştirdiği kanıtlanmalıdır.
Konfigürasyon Yönetimi (Configuration Management): Kaynak kod, gereksinim dosyaları, test sonuçları ve derleyici versiyonlarının kesin bir kontrol altında tutulmasıdır. Hangi kodun hangi uçakta uçtuğunun %100 bilinmesini sağlar.
Kalite Güvencesi (Quality Assurance): Geliştirme ekibinden bağımsız bir ekibin, projede planlanan süreçlere tam olarak uyulup uyulmadığını denetlemesidir.
Sertifikasyon İletişimi (Certification Liaison): Süreç boyunca SOI (Stage of Involvement) denetimleri ile otoritelerin projeyi belirli dönüm noktalarında incelemesi ve onaylamasıdır.
DO-178C'nin Temel Kuralları
Tam İzlenebilirlik (Traceability): Tıpkı DO-254'teki gibi, sistem gereksinimlerinden \rightarrow yazılım yüksek seviye gereksinimlerine \rightarrow düşük seviye tasarım gereksinimlerine \rightarrow kaynak kod satırına \rightarrow ve son olarak test senaryolarına kadar kesintisiz ve çift yönlü bir bağlantı olmak zorundadır.
Ölü Kod (Dead Code) Yasaktır: Hiçbir gereksinime bağlanamayan, test edilemeyen veya çalışması için bir koşul bulunmayan bir kod bloğu (Ölü Kod), DAL A ve B sistemlerinde kesinlikle bulunamaz ve silinmelidir.
DO-178C'nin Modern Ek Dokümanları (Supplements)
Teknoloji geliştikçe standart güncellenmiş ve spesifik modern yazılım metodolojileri için ek rehberler (Supplements) yayınlanmıştır:
DO-330: Araç Kalifikasyonu (Kod üreticiler veya test araçlarının güvenilirliğinin kanıtlanması).
DO-331: Model Tabanlı Geliştirme ve Doğrulama (Matlab/Simulink gibi araçlarla model üzerinden kod üretimi).
DO-332: Nesne Yönelimli Teknoloji (C++ veya Java gibi dillerdeki polimorfizm ve dinamik bellek yönetimi gibi yapıların kısıtlanması/yönetilmesi).
DO-333: Formel Yöntemler (Yazılımın doğruluğunun matematiksel olarak ispatlanması).
DO-178C (Avrupa'daki adıyla EUROCAE ED-12C), sivil ve askeri uçaklarda kullanılan yazılımların geliştirilmesi, test edilmesi ve sertifikalandırılması için ABD Federal Havacılık İdaresi (FAA) ve Avrupa Havacılık Emniyeti Ajansı (EASA) tarafından kullanılan birincil endüstri standardıdır.
DO-254 donanım dünyası için ne anlam ifade ediyorsa, DO-178C de yazılım dünyası için aynı anlama gelir. Amacı, uçuş kritik sistemlerde çalışan kodun güvenli, hatasız ve öngörülebilir olduğunu kanıtlamaktır.
Yazılım Güvenlik Seviyeleri (DAL - Design Assurance Level)
DO-178C, yazılımda meydana gelebilecek bir hatanın uçağa ve yolculara vereceği potansiyel zarara göre sistemi beş seviyeye (Level A'dan E'ye) ayırır. Testlerin katılığı ve üretilecek dokümantasyon miktarı bu seviyelere göre belirlenir:
Level A (Felaket - Catastrophic): Yazılım hatası uçağın güvenli uçuşunu ve inişini engeller, genellikle uçak kaybı ve çoklu can kaybı ile sonuçlanır (Örn: Uçuş kontrol yazılımları).
Level B (Tehlikeli - Hazardous): Uçağın güvenlik marjlarında ciddi bir azalma, uçuş ekibinin iş yükünde büyük bir artış ve az sayıda can kaybı riski oluşturur.
Level C (Önemli - Major): Uçuş ekibinin iş yükünde belirgin artış ve yolcularda fiziksel yaralanmalara yol açabilir.
Level D (Küçük - Minor): Uçuş planında hafif değişikliklere ve yolcularda rahatsızlıklara neden olur.
Level E (Etkisiz - No Effect): Uçuş güvenliğine, ekibe veya yolculara hiçbir etkisi yoktur (Örn: Uçak içi eğlence sistemi yazılımları).
DO-178C Yazılım Geliştirme Süreçleri
Standart, yazılımın baştan sona nasıl inşa edileceğini belirleyen katı bir yaşam döngüsü tanımlar:
Planlama (Planning): Sertifikasyon sürecinin nasıl yürütüleceğini otoritelerle baştan anlaştığınız aşamadır. Kullanılacak diller, derleyiciler ve standartlar PSAC (Plan for Software Aspects of Certification) belgesinde toplanır.
Yazılım Gereksinim Süreci (Requirements): Sistem seviyesinden gelen gereksinimler, "Yüksek Seviye Gereksinimlere (HLR)" dönüştürülür. Yazılımın ne yapması gerektiği burada tanımlanır.
Tasarım Süreci (Design): Yüksek seviye gereksinimler detaylandırılarak yazılım mimarisine ve "Düşük Seviye Gereksinimlere (LLR)" dönüştürülür.
Kodlama Süreci (Coding): Düşük seviye gereksinimler baz alınarak kaynak kodun (C, C++, Ada vb.) yazılması aşamasıdır.
Entegrasyon (Integration): Yazılım bileşenlerinin birleştirilerek hedef donanım üzerinde (veya donanım emülatörlerinde) çalıştırılabilir bir bütün haline getirilmesidir.
Destekleyici (İntegral) Süreçler
Yazılımın kalitesini ve standartlara uygunluğunu sağlayan sürekli süreçlerdir:
Doğrulama (Verification): Standart, kodun çalıştığını söylemenizi yeterli bulmaz, kanıtlamanızı ister. İncelemeler (Reviews), analizler ve en önemlisi Testler bu aşamada yapılır. Özellikle DAL A yazılımlar için MC/DC (Modified Condition/Decision Coverage) adı verilen çok katı bir kod kapsamı analizi zorunludur; koddaki her mantıksal koşulun bağımsız olarak sonucu değiştirdiği kanıtlanmalıdır.
Konfigürasyon Yönetimi (Configuration Management): Kaynak kod, gereksinim dosyaları, test sonuçları ve derleyici versiyonlarının kesin bir kontrol altında tutulmasıdır. Hangi kodun hangi uçakta uçtuğunun %100 bilinmesini sağlar.
Kalite Güvencesi (Quality Assurance): Geliştirme ekibinden bağımsız bir ekibin, projede planlanan süreçlere tam olarak uyulup uyulmadığını denetlemesidir.
Sertifikasyon İletişimi (Certification Liaison): Süreç boyunca SOI (Stage of Involvement) denetimleri ile otoritelerin projeyi belirli dönüm noktalarında incelemesi ve onaylamasıdır.
DO-178C'nin Temel Kuralları
Tam İzlenebilirlik (Traceability): Tıpkı DO-254'teki gibi, sistem gereksinimlerinden \rightarrow yazılım yüksek seviye gereksinimlerine \rightarrow düşük seviye tasarım gereksinimlerine \rightarrow kaynak kod satırına \rightarrow ve son olarak test senaryolarına kadar kesintisiz ve çift yönlü bir bağlantı olmak zorundadır.
Ölü Kod (Dead Code) Yasaktır: Hiçbir gereksinime bağlanamayan, test edilemeyen veya çalışması için bir koşul bulunmayan bir kod bloğu (Ölü Kod), DAL A ve B sistemlerinde kesinlikle bulunamaz ve silinmelidir.
DO-178C'nin Modern Ek Dokümanları (Supplements)
Teknoloji geliştikçe standart güncellenmiş ve spesifik modern yazılım metodolojileri için ek rehberler (Supplements) yayınlanmıştır:
DO-330: Araç Kalifikasyonu (Kod üreticiler veya test araçlarının güvenilirliğinin kanıtlanması).
DO-331: Model Tabanlı Geliştirme ve Doğrulama (Matlab/Simulink gibi araçlarla model üzerinden kod üretimi).
DO-332: Nesne Yönelimli Teknoloji (C++ veya Java gibi dillerdeki polimorfizm ve dinamik bellek yönetimi gibi yapıların kısıtlanması/yönetilmesi).
DO-333: Formel Yöntemler (Yazılımın doğruluğunun matematiksel olarak ispatlanması).
