Kritik Sistemlerde Donanım Tasarım Güvencesi: DO-254 ve ARP4754A Pratikleri
Üniversite laboratuvarlarında veya Ar-Ge prototiplerinde bir FPGA'in veya gömülü sistemin "çalışıyor olması", projenin bittiği anlamına gelebilir. Ancak havacılık ve savunma elektroniği dünyasında "çalışıyor olmak" işin sadece başlangıcıdır. FADEC (Tam Yetkili Dijital Motor Kontrolü) veya uçuş kontrol bilgisayarları gibi sistemlerde temel soru şudur: "Bu donanımın her türlü beklenmedik koşulda, radyasyon altında veya sensör hatalarında öngörülebilir ve güvenli bir şekilde çalışmaya devam edeceğini nasıl kanıtlarsınız?"
Bu kanıtı sağlayan endüstri standartları olan ARP4754A ve DO-254 süreçlerinin, salt dokümantasyon yükü olmaktan çıkıp donanım mimarisini nasıl şekillendirdiğine yakından bakalım.
1. Sistem Mühendisliği ve Güvenlik Analizi: ARP4754A
Bir hava platformunun tasarımı sistem mühendisliği (V-Model) ile başlar. ARP4754A, uçak seviyesindeki gereksinimleri sistem, donanım ve yazılım seviyelerine indirger. Bu sürecin kalbinde Güvenlik Değerlendirmesi (Safety Assessment) yatar.
- FHA (Functional Hazard Assessment): Sistem fonksiyonlarının kaybı ne tür tehlikelere yol açar?
- PSSA (Preliminary System Safety Assessment): Önerilen mimari, hedeflenen güvenlik gereksinimlerini karşılayabilir mi? (Fault Tree Analysis - FTA burada devreye girer).
Bu analizler sonucunda donanıma bir DAL (Design Assurance Level) atanır. DAL A (Felaket) seviyesindeki bir donanım ile DAL D seviyesindeki bir donanımın Quartus Prime veya Vivado üzerindeki tasarım ve doğrulama süreçleri tamamen farklıdır.
2. DO-254: Karmaşık Donanım Tasarım Döngüsü
DO-254 (RTCA/DO-254), FPGA, ASIC ve PLD gibi karmaşık donanımlar (CEH - Complex Electronic Hardware) için bir tasarım güvence rehberidir. Bu standart bize "nasıl kod yazacağımızı" söylemez, ancak sürecin izlenebilir (traceable) ve doğrulanabilir (verifiable) olmasını zorunlu kılar.
Planlama Fazı ve PHAC
Her şey PHAC (Plan for Hardware Aspects of Certification) dokümanı ile başlar. Hangi FPGA'i kullanacaksınız? Hangi sentez aracını (örneğin Quartus) hangi sürümde kullanacaksınız? Doğrulama stratejiniz nedir? Otorite (EASA/FAA veya savunma tedarik makamı) bu dokümanı onaylamadan Verilog/VHDL yazmaya başlayamazsınız.
Tasarım ve İzlenebilirlik (Traceability Matrix)
DO-254'ün en kritik konseptlerinden biri izlenebilirliktir. Donanım Gereksinim Dokümanındaki (HRD) her bir madde, yazdığınız HDL kodundaki bir bloğa ve aynı zamanda yazdığınız bir testbench (doğrulama) adımına bağlanmalıdır.
| Sistem Gereksinimi | Donanım Gereksinimi (HRD) | HDL Implementasyonu | Test / Doğrulama Yöntemi |
|---|---|---|---|
| SYS-REQ-012: Motor aşırı sıcaklık durumunda güvenli kapanma sağlanmalıdır. | HW-REQ-045: Sıcaklık sensörü ADC verisi 0x3FF değerini aşarsa, shut_down_n sinyali 1 clock cycle içinde LOW'a çekilmelidir. | temp_monitor.v (Line 45-52) | TB_temp_monitor.sv -> Test_Case_04 (Timing Simulation) |
3. DAL A/B Tasarımlarında Pratik Kodlama Standartları
Sertifikasyona tabi bir donanım tasarlarken, standart dijital tasarım alışkanlıklarımızın dışına çıkmamız gerekir. Olası Single Event Upset (SEU - radyasyon kaynaklı bit değişimleri) veya sinyal bütünlüğü sorunlarına karşı mimari seviyede önlemler alınmalıdır.
DO-254 Uyumlu State Machine (FSM) Tasarımı
Örneğin bir FPGA içinde Durum Makinesi (State Machine) tasarlıyorsunuz. Tanımlamadığınız bir state'e (default/others) geçiş donanımsal bir hata sonucu oluşursa ne olacak? DO-254, bu durumlar için "Safe State" (Güvenli Durum) geçişlerini açıkça kodlamanızı ve sentez aracının bu kodları optimize edip silmesini (safe state machine encoding) engellemenizi ister.
4. Doğrulama ve Kapsama Analizi (Code Coverage)
Tasarımı bitirdiniz ve testbench yazdınız. Testler "Passed" verdi. DO-254 için bu yeterli değildir. "Acaba test etmediğimiz bir kod bloğu kaldı mı?" sorusunun cevabı Kapsama Analizi (Coverage Analysis) ile verilir. DAL A ve B sistemleri için genellikle şu kapsama oranları %100 olmalıdır:
- Statement Coverage: Yazılan her bir satır kod en az bir kere çalıştırıldı mı?
- Branch Coverage: Tüm if-else ve case durumlarının hem TRUE hem FALSE şartları test edildi mi?
- MC/DC (Modified Condition/Decision Coverage): Bir if şartının içindeki çoklu lojik operatörlerin (örn:
if (A && B || C)) her birinin, sonucun değişmesine bağımsız olarak etki ettiği kanıtlandı mı?
Ölü Kod (Dead Code) Sendromu
Eğer bir donanım gereksinimine dayanmayan, "ileride lazım olur" diye fazladan yazdığınız bir kod bloğu varsa, kapsama analizi sırasında bu bloğu test eden bir gereksinim bulamayacaksınız. DO-254 süreçlerinde "Dead Code" veya "Deactivated Code" bulunması sertifikasyon denetimlerinde Majör bulgu sebebidir. Ya kodu silmeniz ya da kodun sisteme zarar veremeyeceğini çok ağır analizlerle kanıtlamanız gerekir.
Sonuç
Havacılık ve savunma elektroniğinde donanım geliştirmek, laboratuvarda lehim yapmaktan veya FPGA programlamaktan çok daha öte, devasa bir veri yönetim ve kanıtlama mühendisliğidir. ARP4754A ve DO-254, donanımı bir sanat eseri gibi değil, matematiksel olarak doğrulanmış, deterministik bir mühendislik ürünü olarak ele almamızı sağlar. Kariyerini bu yönde şekillendirmek isteyen dijital tasarımcıların, HDL kodlamanın yanı sıra bu kalite ve doğrulama vizyonuna sahip olması, onları sektörde gerçek birer uzman yapacaktır.