TUSAŞ AVİYONİK YAZILIM SERTİFİKASYON DENEYİMLERİ TUSAŞ-TÜRK HAVACILIK VE UZAY SANAYİİ A.Ş. TUSAŞ AVİYONİK YAZILIM SERTİFİKASYON DENEYİMLERİ

Emniyet Kritik Yazılım Geliştirme Gündem Emniyet Kritik Yazılım Geliştirme Sertifikasyon Faaliyetlerinde Yazılım TUSAŞ Deneyimleri C-130 Aviyonik Modernizasyon Projesi Aviyonik Yazılım Geliştirme ve Ulusal Sertifikasyon Hürkuş Projesi Aviyonik Yazılımları ve EASA Sertifikasyonu Alınan Dersler & Öneriler

Sistemlerin Yazılım İçeriği Her 10 Yılda Katlanıyor 3

Platformların Yazılım Bağımlılığı Artıyor Yıl Yazılım ile gerçeklenen fonksiyonlar - % F-35 DoD Defense Science Board Task Force on Defense Software, November 2000 4

Yazılım ve Modernizasyon 5

Yazılım ve Emniyet 6

Üretkenlik Karşılaştırması 7

Yazılım Geliştirme Olgunlukları 8

Süreçler ve DO-178B Santayana: Yazılımlarımızın ortak özellikleri: Büyük ve karmaşık olmaları (SISOS – Software Intensive System of Systems) Hata durumunda büyük mal veya can kaybına sebebiyet verme riski Santayana: “Geçmişlerini hatırlayamayanlar yaşadıklarını tekrar etmeye mahkumdur.” Aerospace recommended practice Başarısızlıklarını hatırlamıyor musun? Tekrar edeceksin. Başarılarını hatırlamıyor musun? Tekrar edemeyeceksin. 9

Genel Yaklaşımımız Yazılım Emniyet Kritik Gerçek Zamanlı 178B ve ECSS uyumlu Tabanlı Model Odaklı Süreç Kullanım Tekrar Yüksek

Kabiliyetlerimiz Faaliyet Alanları HAREKAT UÇUŞ YAZILIMLARI UÇUŞ KONTROL YAZILIMLARI VERİ KOTARMA SİSTEMİ YAZILIMLARI YER KONTROL İSTASYONU YAZILIMLARI SİMÜLASYON YAZILIMLARI DOĞRULAMA

Sertifikasyon Faaliyetlerinde Yazılım Organizasyon Sertifikasyonları kapsamında faaliyetler Tasarım Organizasyon Onayı (TOO) Ürün Sertifikasyonları kapsamında faaliyetler Tip Sertifikasyonu, Tamamlayıcı Tip Sertifikasyonu, Diğer Ürün Onayları Hürkuş : Tip C130 : Tamamlayıcı Tip

Sertifikasyon Faaliyetlerinde Yazılım TOO (Tasarım Organizasyon Onayı) Tasarım Organizasyonunun geçerli uçuşa elverişlilik ve çevresel sertifikasyon gereksinimlerine göre Tasarım yapma Bu gereksinimlere uyumu gösterme Uyumun bağımsız doğrulanması Uyumun Otorite’ye gösterilmesi kapsamında kabiliyeti olduğunun otorite tarafından tanınmasıdır.

Sertifikasyon Faaliyetlerinde Yazılım TOO (Tasarım Organizasyon Onayı) Organizasyon Sorumluluklar Prosedürler Kaynaklar Uyum Gösterimi Uyum Gösterim Doğrulaması Tasarım Tasarım Teminat Sistemi Uyumun Otoriteye Gösterimi Bağımsız İzleme

Sertifikasyon Faaliyetlerinde Yazılım TOO (Tasarım Organizasyon Onayı) ONAYLANMIŞ TUSAŞ PROJE YAZILIM ALT YAPISI EASA Part 21, Subpart J DOCA ERCİYES İMTİYAZLAR EASA DOA Hürkuş Level C ve altı delegasyon HÜRKUŞ

Sertifikasyon Faaliyetlerinde Yazılım Ürün Sertifikasyonları yazılım gereksinimleri, aşağıdaki Uçuşa Elverişlilik gereksinimlerinden gelmektedir: CS/FAR23/25. 1309 RTCA/DO-178B Yazılım konusunda otorite ile ilişkiler RTCA/DO-178B para 9, “Certification Liaison Process”de tanımlanmıştır. 23 : Hürkuş 25 : Erciyes CS # : Max. Take off weight & yolcu sayısı

Sertifikasyon Faaliyetlerinde Yazılım Sertifikasyon faaliyetleri kapsamında yazılım faaliyetlerinin takibi için Otorite tarafından Yazılım Paneli oluşturulmuştur. EASA ve FAA dahili prosedürlerinden çıkmakta.

C-130 Aviyonik Modernizasyon Hv.K.K.’ya ait 13 adet C-130 B/E uçağının aviyonik modernizasyonu TUSAŞ tarafından geliştirilen Harekat Uçuş Yazılımı (HUY); Türkiye’de Sertifikasyona tabi ilk DO-178B (Seviye A) uygulaması Milyon satır mertebesinde HUY Özgün tasarlanmış Uçuş Yönetim Sistemi (FMS) Entegre Yazılım Geliştirme süreç ve araç altyapısı Tekrar kullanılabilir bir mimari&altyapı ve somut uyarlama deneyimi 50 saatlik uçuş testleri

Yazılım Geliştirme ve Doğrulama Süreci ve Yaklaşımı Proje yönetimi yaklaşımı: Planla, işlet, takip et, düzelt

Yazılım Geliştirme-Doğrulama Süreci

Yazılım Gereksinimleri Yazılım gereksinim standardına uyumlu ve bağımsız bir ekip tarafından test edilen 13,625 yazılım gereksinimi Her rolün (geliştirici, doğrulamacı) aynı şekilde yorumlayabileceği gereksinimler Türetilmiş gereksinimler için emniyet analizi

Yazılım Mimarisi - Bölüntü Yaklaşımı Bölüntülendirme : Bağımsız geliştirme ve doğrulama Entegrasyon İMA yapısına geçiş

Kalifikasyon (DO-178B geliştirme ve doğrulama araçları) Entegrasyon Yazılım Altyapısı Araçlar, Kütüphaneler, 3. parti yazılımları, Alt Yüklenici yazılımları, RAHAT Yazılımlar Kalifikasyon (DO-178B geliştirme ve doğrulama araçları) Entegrasyon Bakım

Olgunluk seviyesi yüksek ürün Bakım safhasında çok daha az hata Gözden Geçirmeler ~ 500 gözden geçirme (Plan, gereksinim, tasarım, kod, test, kontrol listeleri) İşgücü ~ 200 adam ay Etkileri : Olgunluk seviyesi yüksek ürün Bakım safhasında çok daha az hata Geliştirme safhasında takvim gecikmeleri

Sistem gereksinimi – yazılım gereksinimleri İzlenebilirlik Sistem gereksinimi – yazılım gereksinimleri Yazılım gereksinimleri – kaynak kod–obje kodu Yazılım gereksinimleri – tasarım – kaynak kod Yazılım gereksinimleri – yazılım testleri İzlenebilirlikte Granülite SW verification cases & procedures

Yazılım testlerinin otomatik koşması (%95) Test Otomasyonu Yazılım testlerinin otomatik koşması (%95) Regresyon testlerinin hızlı yapılabilmesi Kod değişikliklerine testler hızlı cevap verdiği için yapılan hataların hızlı bulunabilmesi MVC

Yazılım Yapısal Kapsama Analizi (SCA) Gereksinimlerin, kodun ve testlerin bütünlüğü ve doğruluğunun teminat altına alınması Yüksek “coverage” = Yeterli test + yeterli gereksinim + gerektiği kadar kod Testlerde ortalama %95 “statement coverage”, %90 “branch coverage” Gecelik otomatik koşan testlerle birlikte %100 otomatik SCA raporu Defensive code ve analizler DO-178B %100 analiz bekliyor MC/DC’de alıyoruz modified condition decision coverage

120 bin satır test otomasyon ve araç yazılımı Yazılım Doğrulama 647 Test prosedürü 55,000 test senaryosu 880,000 test adımı 1,2 milyon satır test kodu 120 bin satır test otomasyon ve araç yazılımı Doğrulama eforu / toplam geliştirme eforu : %45 (Sertifikasyon olmayan bir projede doğrulama eforu%15-20)

Sertifikasyon Faaliyetleri Sertifikasyon otoritesi ile birlikte yürütülen ortak faaliyetler Faaliyet Sayı Panel Toplantısı 17 SİM (CRI) 5 SOI 10 Alt Yüklenici SOI 8 SOI: Stage of involvement 15 SOI review i yapılması planlanıyor Panel, SOI ve CRI’ler gerçekleşen CRI : EASA Issue Paper : FAA CRI : DO-178 B de detayı tam olarak içerilmeyen, sertifikasyon ile ilgili konuların ele alındığı spesifik dokümanlar

Yazılım Kalite Yaklaşımı Onaylı Yazılım Plan ve Standartlarına uyum Süreç Denetim Eş Gözden Geçirme YKKK Planlama ve Takip 13 8 419 Gereksinim 137 Tasarım 2 30 Kodlama 62 Doğrulama 9 180 YKKK Yazılım Konfigürasyon Kontrol Kurulu Yazılım Kalite Teminat Sürecinin hedefi (RTCA/DO-178B para .8), bütün yazılım seviyelerinde bağımsızlık sağlayarak aşağıdakilerin teminat altına alınmasıdır; Onaylı Yazılım Plan ve Standartlarına uyum. Tanımlı süreç geçiş kriterlerinin karşılanması. Uygunluk Gözden Geçirmelerinin yapılması.

HÜRKUŞ Servis İrtifası ............ 30,000ft Seyir Hızı ................. >250 kts G Limitleri ................ +7g / -3.5g Tırmanma ................ 15000 ft’e 5 dk. Rüzgarda Kalkış-İniş. 25kts Oturma Düzeni ......... Kademeli Tandem Motor ........................ Tek Turboprop Basınçlandırma ........ Var Anti-G Sistemi .......... Var OBOGS .................... Var 0/0 Fırlatma Koltuğu Var İlk Uçuş 2013 HÜRKUŞ, gece ve gündüz görev yapabilme kabiliyetine sahip olacak ve Avrupa Havacılık Otoritesi (EASA) tarafından CS 23’e göre sertifiye edilecektir. CS 23

Hürkuş Yazılım Faaliyetleri Yazılımlar Altyükleniciler tarafından geliştirilmektedir. Bu geliştirme süreci ve ürünlerin DO-178B’ye uygunluğu sertifikasyon otoritesi ile birlikte TUSAŞ tarafından teminat altına alınmaktadır. Bu aktiviteler Yazılım Altyüklenici Teknik Yönetimi, Yazılım Kalite Güvence, Yazılım Konfigürasyon Yönetimi, Uyum Doğrulama Mühendisliği fonksiyonları tarafından yürütülmektedir.

Yazılımın Sertifikasyon Uyumu Durum Yöntem ETSO/TSO onayı var Mevcut dokümantasyon CRI ve gerekirse DO-178B’ye uyum açısından gözden geçirilir. Örnek: ATA 34-57, SSR (Secondary Surveillance Radar) Transponder Yeni yazılım geliştirme/modifikasyon Alt yüklenici tarafından tamamlanan Yazılım Yaşam döngüsü verileri TAI tarafından yapılan denetimler ile kontrol edilir. Örnek: ATA 28, Yakıt Kontrol Ünitesi ED12B/DO178B uyumlu Önceden Geliştirilmiş Yazılım Alt yüklenici ve Otorite ile koordine edilerek, ED12B/DO-178B 12.1 (Use of PDS) bölümündeki aktiviteler uygulanır. Örnek: ATA 73-20, İtki Sistemi Güç Kontrol Ünitesi ED12B/DO178B uyumluluğu olmayan Önceden Geliştirilmiş Yazılım Firmanın mevcut dokümantasyonu incelenir. Otorite ile koordine edilerek DO-178B ye uyum konusunda yapılması gereken aktiviteler belirlenir. Örnek: ATA 95-10 Pilot Kurtarma Sistemi DO-178A ile uyumlu önceden geliştirilmiş yazılım DO-178A ve DO-178B yazılım denklik tablosu kullanılır. Denklik sağlanamadığı durumda DO-178B 12.1.4 (Upgrading a Development Baseline) bölümü uygulanır. Örnek: ATA 24-30, Elektrik Güç Sistemi PDS Previously Developed SW Sw Approval Guide 8110.49 (FAA) ETSO : European Technical Standard Order TSO : Technical Standard Order

Sertifikasyon Faaliyetleri Sertifikasyon otoritesi ile birlikte yürütülen ortak faaliyetler Faaliyet Sayı Panel Toplantısı - SİM (CRI) 6 SOI Alt Yüklenici SOI 3 Gerçekleşen değerler

Alınan Dersler & Öneriler

Alınan Dersler & Öneriler Sertifikasyon pratiklerinin projeden projeye değişebilmesi Ulusal emniyet kritik yazılım geliştirme (DO-178B) rehber dokümanı oluşturulması Plan ve standartların ortak hale getirilmesi (Kurumsal) Sertifikasyon maliyet ölçütleri Projelerde sertifikasyon&emniyet isterlerinin/standartlarının net olmaması Sözleşmelerde sertifikasyon&emniyet standartlarının (ARP 4761, 4754 vb. gibi) belirtilmesi

Alınan Dersler & Öneriler Tasarım Organizasyon Onayından yeterince yararlanamama TOO kapsamında imtiyazların projelerin daha erken aşamalarında alınması ve otoritenin yazılım kapsamındaki görevlerinin bir kısmının delege edilmesi Sözleşmelerde yer alan ancak DO-178B uyumlu olmayan yazılımlar içeren ekipmanların sertifikasyonunda sorun yaşanması Milli yaklaşım/kurallar rehber dokümanı oluşturulması ve risk paylaşımı

Alınan Dersler & Öneriler Sistem gereksinimlerindeki eksikliklerin yazılım gereksinimleri ile tamamlanabileceğinin düşünülmesi Sistem seviyesi aktivitelerin yazılıma olan etkisinin yeterince düşünülmemesi Sistem Mühendisi, Sistem Emniyet Sorumlusu ve Yazılım Geliştiricinin aynı dili konuşamaması Sistem ve yazılım ara yüzlerinin iyi tanımlanmaması İlgili seviyede bütün gereksinimlerin tanımlanması ve detay seviyesi için standartlar ve checklistler oluşturulması IPT takımları kurularak teklif aşamasından itibaren yazılım ile sistem süreçlerinin entegre düşünülmesi

Alınan Dersler & Öneriler Uygulanan standartların rasyonelleriyle bilinmemesi Eğitim, araştırma ve danışmanlıklar aracılığıyla bilgi sahibi olunması, daha verimli iş yapılması Altyüklenicilerin yazılım sertifikasyon konusunda yetkin olmaması Altyüklenici sözleşmelerinde yazılım ve sertifikasyon isterlerinin öngörülmesi, altyüklenici seçim kriterleri arasında yazılım sertifikasyon yetkinliği Emniyet sürecinde atanan seviyelerin daha aşağı seviyelere kırılamaması Emniyet sürecinden atanan seviyelerin sistem ve yazılıma doğru kırılması

Alınan Dersler & Öneriler Yazılım aktivitelerine (gözden geçirme, doğrulama vb. gibi) takvimde yeterince zaman ayrılmaması Hata düzeltme ve geri dönüşler için zaman planlanmaması Zaman kısıtları yüzünden bazı aktivitelerin paralel yapılabileceğinin ya da hiç yapılmayabileceğinin düşünülmesi Test ve analizlerin zamanında yapılmaması Planlamaya ve planlamada bu faaliyetlere yeterince zaman ayrılması (rework dahil) Geçmiş performans ve metriklerden yararlanılması

Alınan Dersler & Öneriler Personel yetkinliklerinin yetersiz olması DO-178B sürecinde yer alan tüm paydaşların yetkinliklerinin geliştirilmesi Dahili ve harici eğitim ve danışmanlık alınması Proje dokümantasyonunun (SVİL) belli formatlarda üretilmesi zorluğu Özellikle teknik dokümantasyonun kendi orijinal formatında teslim edilmesi ve incelenmesi Sertifikasyon sürecinde otomasyon fırsatlarından yeterince yararlanılamaması Otomasyona açık/elverişli RAHAT/özgün geliştirilmiş Yazılım Araçları kullanılması

42