HAVA ARAÇ SERTİFİKASYONUNDA YAZILIM FAKTÖRLERİ

T R E N D A N A L İ Z İ Ş U B AT 2 0 1 8 HAVA ARAÇ SERTİFİKASYONUNDA YAZILIM FAKTÖRLERİ HAVA ARAÇ SERTİFİKASYONUNDA YAZILIM FAKTÖRLERİ TREND ANALİZİ ŞUBAT 2018 1

İşbu eserde/internet sitesinde yer alan veriler/bilgiler, yalnızca bilgi amaçlı olup, bu eser/internet sitesinde bulunan veriler/bilgiler tavsiye, reklam ya da iş geliştirme amacına yönelik değildir. STM Savunma Teknolojileri Mühendislik ve Ticaret A.Ş. işbu eserde/internet sitesinde sunulan verilerin/bilgilerin içeriği, güncelliği ya da doğruluğu konusunda herhangi bir taahhüde girmemekte, kullanıcı veya üçüncü kişilerin bu eserde/internet sitesinde yer alan verilere/bilgilere dayanarak gerçekleştirecekleri eylemlerden ötürü sorumluluk kabul etmemektedir. Bu eserde/internet sitesinde yer alan bilgilerin her türlü hakkı STM Savunma Teknolojileri Mühendislik ve Ticaret A.Ş ye aittir. Yazılı izin olmaksızın eserde/ internet sitesinde yer alan bilgi, yazı, ifadenin bir kısmı veya tamamı, herhangi bir ortamda hiçbir şekilde yayımlanamaz, çoğaltılamaz, işlenemez. 2 HAVA ARAÇ SERTİFİKASYONUNDA YAZILIM FAKTÖRLERİ

Alper KENDİ 1. YAZILIM EMNİYETİ 1980 li yıllardan başlayarak yazılımlar yaşamın her alanında giderek artan bir rol oynamaya başladı. Günümüzde konusu insan yaşamı olan uygulamalarda da yazılıma olan ihtiyaç giderek artıyor. Birçok durumda insan yaşamı ister istemez yazılıma emanet ediliyor. O nedenle bu gibi durumlarda yazılımların geliştirilmesine elverişlilik, güvenilirlik vb. ölçütler, uyulması zorunlu standartlar ve denetimler getirilmiş bulunuyor. İnsanoğlu doğası gereği hata yapar ancak yazılımlar da insanlar tarafından geliştirilmek zorundadır. Bu yüzden günümüzde mühendisler hata yapmayan yazılımlar geliştirmek gibi büyük bir meydan okumaya karşı kıyasıya mücadele vermektedir. Bu mücadelede hedef; kritik yazılım geliştirme çevriminde, hata bulmaya ve önlemeye yönelik yeni yöntemlerin ortaya çıkartılması ve uygulanmasıdır. Uçuşa elverişlilik gereksinimleri işte bu çevrimde ortaya çıkarılan ve günümüzde ekseriyetle uygulanan yöntemler ve gereksinimler bütünüdür diyebiliriz. Uçuşa elverişlilik gereksinimleri içerisinde hava aracında kullanılan yazılımın hata yapması durumunda sistem emniyetinin nasıl etkileneceği ile ilgili kısım; hava araç sertifikasyonunda yazılım faktörleri olarak değerlendirilir. Bu değerlendirme farklı fonksiyonları icra eden yazılımlar için ayrı ayrı ele alınır. Bir hava aracında kullanılan yazılımlar, gerçekleştirdikleri fonksiyonun emniyet kritiklik seviyesine göre önem kazanırlar. Yazılımın uçuş esnasında icra ettiği fonksiyon ne kadar emniyet kritik ise yazılım da o derece özel yöntemlerle geliştirilir. Örnek vermek gerekirse: Örnek 1: Uçağın eğlence sistemini oluşturan; film, müzik ve oyun hizmeti sunan yazılım. Olası Sonuç: Mutsuz, belki sinirli ama hâlâ nefes alıp verebilen yolcular. Örnek 2: Sıfır görüş durumunda (sis vb.) aletli otomatik iniş esnasında uçağı kontrol eden yazılımın hata yapması. Olası Sonuç: Ne olduğunu bile anlamadan yarı yanmış halde kimisi enkaza sıkışmış, kimi piste saçılmış yolcular. Şekil 1: Yolcu uçaklarında kullanılan yazılımların yıllara göre oranı (yıl/yazılım kaynak kod) [1] HAVA ARAÇ SERTİFİKASYONUNDA YAZILIM FAKTÖRLERİ 3

Bu iki örnek hava araç yazılımlarının ciddiyetle ele alınması gerektiğini göstermekle birlikte farklı fonksiyonlar üstlenen yazılımların farklı güvenlik seviyelerine sahip olması gerektiğini de anlatmaktadır. Uçağın eğlence sistemi yazılımı ile otomatik iniş sistemi yazılımının yaptığı hatalar, sistemin güvenliğini farklı şekillerde etkiler. Bu sebepten iki farklı yazılım, iki farklı emniyet seviyesine göre geliştirilmeli ve test edilmelidir. 2. DO-178C BAŞLANGIÇ DO-178B, Radio Technical Commission for Aeronautics (RTCA) tarafından yayınlanan Software Considerations in Airborne Systems and Equipment Certification başlıklı bir dokümandır. Başlıktan da anlaşılacağı üzere, yazılımların uçuşa elverişlilik gereksinimlerinin karşılanmasıyla ilgilidir. Bu gereksinimlerin nasıl karşılanacağı ise tamamen geliştiriciye bırakılmıştır. Certification Basis CS 25.1309 Equipment, systems and İnstallation CS 25.1322 Warning, caution, and advisory lights CS 25.1323 Airspeed indicating system CS 25.1325 Static pressure systems CS 25.1327 Direction Indicator FAA AC-23/25 dokümanı ile EASA CS- 23/25 dokümanında hava araç sertifikasyonunda DO-178C dokümanının takip edilmesi önerilir. Yazılımlar hava araçlarının en kritik bileşenlerindendir ve emniyetli şekilde geliştirilmeleri hava aracı güvenilirliğine doğrudan etki eder. DO- 178B bu farklı emniyet kritiklik durumlarıyla ilgili olarak yazılım sistemlerini beş seviyede tanımlar: Seviye A: Hata yapması durumunda ölümcül (catastrophic) sonuçlara yol açan yazılımlar. Seviye B: Hata yapması durumunda tehlikeli/riskli (hazardous) sonuçlara yol açan yazılımlar. Seviye C: Hata yapması durumunda ciddi olabilecek (major) sonuçlara yol açan yazılımlar. Seviye D: Hata yapması durumunda daha az risk oluşturabilecek (minör) sonuçlara yol açan yazılımlar. Seviye E: Hata yapması durumunda risk oluşturmayan yazılımlar. Sistem emniyet değerlendirmesi (safety assessment) ve etki analizleri tamamlandığında yazılıma yukarıda bahsedilen seviyeler tanımlanır. Bu kritik bir sonuçtur, o nedenle bu sürecin hassasiyetle işletilmesi gerekir. Yüklenici-alt yüklenici ilişkili üretim modellerinde bazen maliyet ve zaman kaygılarıyla emniyet seviyelerinin yeterince özen gösterilmeden belirlendiği durumlarda, proje çevriminde sertifikasyon gereksinimlerinin karşılanmasında güçlükler yaşanabilmekte, bu da zaman, işgücü ve para kaybının yanında hava araçlarında güvenlik zafiyeti oluşturmaktadır. Seviye A olan bir yazılımda DO-178B standardına (DO-178C den önceki versiyon) göre tamamlanması gereken hedef sayısı 66, B de 65 ve C seviyesinde 57 dir. Gereksiz yere yüksek seviyeye atanmış bir yazılım için geliştirme ekibi fazladan birtakım hedefler tamamlamak zorunda kalacak, tamamlanması gereken her hedef de firmaya fazladan maliyet yaratacaktır. Olması gerekenden daha düşük seviyelendirilmiş bir yazılım ise hava aracı emniyeti için risk teşkil edecek, kontrolü yapılmayan bir olasılık sebebiyle can ve mal kaybına neden olabilecektir. DO-178B Kılavuzluğunda Yazılım Geliştirmek, Geliştirdiğimiz Yazılımları Güvenli Yapar mı? DO-178B hataların önlenmesi konusunda ciddi hedefler getirmiştir, fakat bu hataların tamamen ortadan kalkmasını garanti etmez. Yapılan araştırmalar, meydana gelen uçak kazalarının büyük bir kısmının sistemlerin çalışmamasından değil yanlış çalışmasından ve diğer sistemlerin yanlış çalışan bu sistemlere güvenmesinden kaynaklandığını gösteriyor. Örneğin, Türk Hava Yolları TK-1951 sefer sayılı Hollanda uçağı Schiphol havaalanına iniş yaparken kaza geçirerek üç yerden kırıma uğramış, uçakta bulunan 127 yolcu ve 7 mürettebattan 9 kişi hayatını Şekil 2: DO-178C nin Evrimi [2] 4 HAVA ARAÇ SERTİFİKASYONUNDA YAZILIM FAKTÖRLERİ

Şekil 3: Örnek Hava Aracı Geliştirme Sistem Süreci [3] kaybetmişti. Kaza kırım raporunda uçağın radar altimetresinin uçağın yükseklik bilgisini yanlış ölçtüğü, otomatik pilotun bu yükseklik verisine güvenerek motor gücünü kestiği ve uçağın piste ulaşamadan yere çarptığı belirtiliyordu. DO-178B hatasız yazılımı garanti etmez ancak izlenmesini önerdiği metodolojilerle ortaya çıkabilecek hataların tespit edilmesine olanak sağlar. Nasıl mı? Kontrol Tekrar kontrol Ve tekrar kontrol Ve yine kontrol. Önceden tanımlanmış hedefler yazılım geliştirmenin doğasında olan tuzaklara düşülmemesi için ürün geliştiricilere yol gösterir. Her biri birer hedef olan aşağıdaki süreçler DO-178B nin omurgasını oluşturur: Planlama Süreci (Planning Process) Geliştirme Süreci (Development Process) Gereklilik Süreci (Requirement Process) Tasarım Süreci (Design Process) Kodlama ve Entegrasyon Süreci (Codding Integration Process) Test ve Doğrulama Süreci (Test and Verification Process) Konfigürasyon Süreci (Configuration Process) Kalite Güvence Süreci (Quality Assurance Process) Birçok geliştirici yukarıdaki süreçlere halihazırda aşina olsa da, bu süreçler DO-178B de birtakım farklılıklarla ele alınır. CMMI Seviye 3, bir firmanın DO-178B süreçlerini uygulamasının normal şartlar altında yüzde 35-40 ilave maliyet getireceği öngörülür. Normal şartlarda diye ifade etmemizin sebebi, endüstri ortalamasının bu rakamın çok üzerinde, yüzde 75 ila yüzde 150 arasında olmasıdır. Oranların böyle yüksek olmasının en büyük sebebi de havacılık yazılımlarıyla ilgili testlerin sektörün tahmininden daha uzun sürmesi ve buna paralel olarak tekrarlama ve başa dönme sayısının yüksek olmasıdır. Bu yüzden DO-178B kılavuzluğunda ilerlenen projelerde, planlama en kritik ve ekip olarak üzerinde en çok kafa yorulması gereken süreçtir. Planlama sürecinin kritik olmasının nedeni, DO-178B nin aksi ispatlanana kadar her şey suçludur prensibidir. Modern hukuk anlayışının aksi ispatlanana kadar herkes masumdur prensibi DO- 178B süreçlerinde tam tersidir diyebiliriz. Üreticiler, planlarda ifade ettikleri tüm maddelerin tam olarak planlarda geçen şekliyle yapıldığına dair otorite karşısında savunma yapmak ve delil sunmak zorundadır. DO-178B planlama süreci beş adet planı ve bunların standart dokümanlarını kapsar: 2.1. PSAC (Plan for Software Aspects of Certification) Projenin amacı, süreçleri, süreç geçiş şartları, kullanılacak teknoloji, geliştirme araçları vb. konular fazla detaya girilmeden açıklanır. PSAC içinde; proje takviminin nasıl olacağı personel görev tanımlarının nasıl yapılacağı, ne tür bir işletim sistemi kullanılacağı gibi soruların yanıtlarının verilmesi beklenir. Detaya girilmemesi tavsiye edilir zira projenin başında ve sonunda onaylanan PSAC in detaylı olarak kaleme alınması yazılım geliştirmenin değişken doğası (değişen müşteri talepleri, teknoloji vb.) düşünüldüğünde sıkıntılar ortaya çıkartabilir. Projede hangi araçların kullanılacağı bu dokümanda belirtilebilir, fakat bu araçların detayları ve diğer araçlarla entegrasyonu dokümanda anlatılırsa detayları verilmiş olan bir araçta projenin daha ikinci yılında olabilecek bir sürüm değişikliği firma için problem olabilir. 20-30 sayfalık bir PSAC dokümanının yeterli olacağı belirtilmektedir. HAVA ARAÇ SERTİFİKASYONUNDA YAZILIM FAKTÖRLERİ 5

Dokümanın genel yapısı aşağıdaki gibi özetlenebilir: Sisteme Genel Bakış (System Overview): Sistemin işlevselliği, yazılım/donanım dağılımı, arayüz tanımları vb. burada anlatılır. Yazılıma Genel Bakış (Software Overview): Bu kısımda, yazılım fonksiyonları emniyet isterleri gözetilerek ifade edilir. Kaynak yönetimi, hata dayanım, zaman kısıtları vb. Sertifikasyon Gerekleri (Certification Considerations): Atanmış DAL (design assurance level) değerine uygunluğun nasıl sağlanacağı anlatılır. Yazılım Yaşam Döngüsü (Software Lifecyle): Uygulanacak yazılım geliştirme süreci bu kısımda anlatılır. Her bir süreç aşamasının amacı ve bu amaca nasıl ulaşılacağı ifade edilir. Yazılım Yaşam Döngüsü Verisi (Software Lifecycle Data): Bir önceki adımda bahsedilen süreç adımlarının her biri için giriş/çıkış koşulları ve ürünler (data) anlatılır. Takvim (Schedule): Proje takvimi belirtilir ve sertifikasyon otoritesiyle yapılacak gözden geçirmenin tarihleri planlanır. Ek Düşünceler (Additional Consideration): Bu kısımda projenin ilerleyişinde ve emniyet isterlerinin karşılanmasında etkili olabilecek varsa araç kalifikasyonu, COTS ürünler vb. konulardan bahsedilir. 2.2. Kalite Güvence Planı (Quality Assurance Plan QA Planı) QA Planı tüm süreç boyunca kalite güvencenin nasıl sağlanacağını anlatan plandır. CMMI bir firma için bunun anlaşılması ve üretilmesi kolaydır, dikkat edilmesi gereken nokta, kalite planının yazılım geliştirme planıyla çelişmemesidir. DO-178B kılavuzluğunda ilerleyen projelerde bağımsız bir kaliteci şarttır. Bağımsız olmasının, yani kalite temsilcisinin proje yönetimi dışında bir merciye rapor vermesinin nedeni, işi yapan ile Olmamış, bunu yeniden yapın diyenin farklı kişilere rapor vermesinin herkes için daha yararlı olmasıdır. Zira bağlı olduğu proje yöneticisine, Şunları şunları yapmamışsınız ve ben bunu onaylamıyorum demek biraz sıkıntı oluşturabilir. QA planı, şirket plan ve standartlarının DO-178B ile uyumlu olduğunu ifade eder. Yazılım geliştirme sürecinin şirket planlarıyla uyumluluğunu garanti eden kanıtlar içerir, gözden geçirmelerin nasıl yapılacağını ve süreçler arası geçiş kriterlerinin neler olduğunu belirtir. Genel bir üslupla yazılması başka projeler kapsamında kullanılmasını kolaylaştıracaktır. 2.3. Konfigürasyon Planı (Configuration Plan) Konfigürasyon planı; yazılım konfigürasyon parçalarının neler olacağının ve bu konfigürasyonların kimlerin sorumluluğunda ve hangi işlemlere tabi olacağının belirtildiği önemli bir plandır. Tüm yazılım, yaşam döngüsünü kapsar. Konfigürasyon planlarında sürümler, değişiklik kontrolü, izleme, alınan baseline ve release gibi konfigürasyonların nasıl oluşturulup nasıl saklanacağı ve numaralandırılacağı gibi süreçler kapsamlı şekilde belirtilir ve bu planlar havacılık yazılımlarının yüklü olduğu hava araçlarının yaşamları boyunca üretici firmalar tarafından saklanır. 2.4. Geliştirme Planı (Development Plan) Emniyet kritik yazılımlar, doğaları gereği diğer yazılımlara kıyasla daha zorlu ve sınırları kesin süreçler takip edilerek geliştirilmektedir. Yazılım gereksinimlerinin analiz edilmesiyle başlayan bu süreç, yazılım tasarımının yapılması, kaynak kod geliştirilmesi ve bileşenlerin entegrasyonundan oluşur. Yazılım geliştirmenin dört temel süreci dahilinde izlenecek süreçlerin ifade edildiği geliştirme planı, DO-178C kapsamındaki tüm diğer planlarda olduğu gibi, projeye başlamadan önce yapılması ve proje süresince takip edilmesi gereken bir plandır. 2.5. Test Planı (Test Plan) Testler, emniyet kritik sistem geliştirilirken en çok efor sarf edilen süreçtir. Yazılımların doğası gereği MTBF (mean time between failure) hesaplaması yapılamaz. Bu sebeple yazılımların emniyetli olarak geliştirilebilmeleri için test yoğun bir geliştirme metodolojisi izlenmelidir. Test Planı çerçevesinde yazılım testlerinin nasıl yapılacağı henüz projenin başında ifade edilir. Hangi test 6 HAVA ARAÇ SERTİFİKASYONUNDA YAZILIM FAKTÖRLERİ

Şekil 4: DO-178B projelerinde süreç bazında harcanan ortalama çaba grafiği [4] araçlarının kullanılacağı, testlerin kabul, şartlı kabul ve ret koşulları belirtilir. Emniyet kritik olmayan sistemlere kıyasla burada araç kalifikasyonu farkından bahsedilebilir. DO-178C kılavuzluğunda gerçekleştirilen projelerde yazılım geliştirmesini etkileyebilecek yazılım yaşam döngüsü içerisinde kullanılan tüm yardımcı programlar da kalifikasyona tabidir. Örneğin derleyicinizin kalifikasyonu yoksa bu derleyiciyi emniyet kritik bir sistem geliştirmek için kullanmak istediğiniz doğrulama ve geçerli kılma raporlarını sunmanız istenecektir. Havacılık sektöründe kullanılan yazılımların muntazam test edilmesi, yazılımların düzgün çalışması ve yazılıma bağlı çalışan sistemlerin emniyetli ve fonksiyonel olarak görevlerini icra etmelerinin güvencesidir. Yazılı- 3. SONUÇ Günümüz karmaşık sistemlerinin en önemli bileşeni konumunda olan yazılımlar hava araçlarının da en önemli bileşenleri arasındadır ve gelecekte de olmaya devam edecektir. Havacılıktan otomotive, sağlıktan banka sistemlerine kadar birçok emniyet ve iş kritik yazılım üreticiler tarafından kamunun hizmetine sunulmaktadır. Özellikle Endüstri 4.0 ın gelmesiyle otonom sistemler, yapay zekâ uygulamaları, kendi kendine karar verebilen, verilen görevi operatör yardımı olmaksızın icra edebilen akıllı sistemler, akıllı arabalar, robot işçiler vb. şekillerde üretici ve kullanıcıların yardımına koşmaktadır. Boeing 737 den F-35 savaş uçaklarına kadar insanlı-insansız birçok hava aracında milyonlarca satır kaynak kodlu yazılım uçuş kontrol, seyrüsefer, silah kontrol vb. görevleri yerine getirmektedir. HAVA ARAÇ SERTİFİKASYONUNDA YAZILIM FAKTÖRLERİ Şekil 5: NASA, Quora, Ohio University, Wired aracılığı ile derlenen bilgiler ışığında farklı uygulamalarda kullanılan yazılımların büyüklükleri (kaynak kod bazında) [5] 7

mın güvenilir çalışması yazılımın doğası gereği malzeme teknolojilerinden farklı olarak garanti edilir. Bu sebeple özellikle emniyet kritik fonksiyon icra eden yazılımların belirli kriterlere göre geliştirilmeleri doğaldır. Son sürümü ile DO-178C bu özel kriterlerden biridir. Sivil amaçlarla geliştirilmiş olsa da günümüzde DO-178C askeri havacılık projelerinde de sıklıkla kullanılmaktadır. Hava araçlarında kullanılan yazılım faktörlerinin değerlendirilmesi, emniyetli şekilde geliştirilmeleri ve test edilmeleri için havacılık otoriteleri tarafından tavsiye edilen bir kılavuz dokümandır. KAYNAKÇA [1] http://www.businessinsider.com/how-many-lines-of-code-it-takes-to-run-different-software-2017-2. [2] Radio Technical Commission for Aeronautics, RTCA DO-178C Software Considerations in Airborne Systems and Equipment Certification. [3] SAE ARP 4754 Certification Considerations for Highly-Integrated or Complex Aircraft Systems. [4] STM Sertifikasyon Müdürlüğü DO-178C Eğitimi Notları. [5] http://www.techsite.io/p/391459. 8 HAVA ARAÇ SERTİFİKASYONUNDA YAZILIM FAKTÖRLERİ

T R E N D A N A L İ Z İ Ş U B AT 2 0 1 8 HAVA ARAÇ SERTİFİKASYONUNDA YAZILIM FAKTÖRLERİ 9

http://thinktech.stm.com.tr 10 HAVA ARAÇ SERTİFİKASYONUNDA YAZILIM FAKTÖRLERİ