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

1HAVA ARAÇ SERTİFİKASYONUNDA YAZILIM FAKTÖRLERİTREND ANALİZİ ŞUBAT 2018

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


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

İş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 veri-lerin/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.


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

1980’li yıllardan başlayarak yazılımlar yaşamın her ala-nında giderek artan bir rol oynamaya başladı. Günümüz-de konusu insan yaşamı olan uygulamalarda da yazılıma olan ihtiyaç giderek artıyor. Birçok durumda insan yaşa-mı 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ühendis-ler 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 çevrimin-de, 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 gereksi-nimler bütünüdür diyebiliriz. Uçuşa elverişlilik gereksi-nimleri içerisinde hava aracında kullanılan yazılımın hata yapması durumunda sistem emniyetinin nasıl etkilene-

ceğ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 ka-zanı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öntem-lerle 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.

1. YAZILIM EMNİYETİAlper KENDİ

Ş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]



Bu iki örnek hava araç yazılımlarının ciddiyetle ele alınması gerektiğini göstermekle birlikte farklı fonksiyon-lar üstlenen yazılımların farklı güvenlik seviyelerine sahip olması gerektiğini de anlatmaktadır. Uçağın eğlence sis-temi 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 Aeronauti-cs (RTCA) tarafından yayınlanan “Software Considera-tions 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şılan-masıyla ilgilidir. Bu gereksinimlerin nasıl karşılanacağı ise tamamen geliştiriciye bırakılmıştır.

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ştiril-meleri 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 (catast-rophic) 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şturma-yan 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 yete-rince özen gösterilmeden belirlendiği durumlarda, proje çevriminde sertifikasyon gereksinimlerinin karşılanma-sı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ı ge-reken 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ı gereken-den daha düşük seviyelendirilmiş bir yazılım ise hava aracı emniyeti için risk teşkil edecek, kontrolü yapılma-yan bir olasılık sebebiyle can ve mal kaybına neden ola-bilecektir.

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 kalkma-sı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ışma-masından değil yanlış çalışmasından ve diğer sistemle-rin yanlış çalışan bu sistemlere güvenmesinden kaynak-landığını gösteriyor. Örneğin, Türk Hava Yolları TK-1951 sefer sayılı Hollanda uçağı Schiphol havaalanına iniş ya-parken kaza geçirerek üç yerden kırıma uğramış, uçak-ta bulunan 127 yolcu ve 7 mürettebattan 9 kişi hayatını

Certification Basis

CS 25.1309 Equipment, systems and İnstallation

CS 25.1322 Warning, caution, and advisory lightsCS 25.1323 Airspeed indicating systemCS 25.1325 Static pressure systemsCS 25.1327 Direction Indicator

Şekil 2: DO-178C’nin Evrimi[2]



kaybetmişti. Kaza kırım raporunda uçağın radar altimet-resinin 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ığı belir-tiliyordu.

DO-178B hatasız yazılımı garanti etmez ancak izlen-mesini önerdiği metodolojilerle ortaya çıkabilecek hata-ları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 Integrati-

on Process) Test ve Doğrulama Süreci (Test and Verification Pro-

cess) 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 şart-larda diye ifade etmemizin sebebi, endüstri ortalama-sı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 pa-ralel 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 proje-lerde, 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, plan-larda ifade ettikleri tüm maddelerin tam olarak planlarda geçen şekliyle yapıldığına dair otorite karşısında savun-ma 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ı, kulla-nılacak teknoloji, geliştirme araçları vb. konular fazla detaya girilmeden açıklanır. PSAC içinde; proje tak-viminin 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 giril-memesi tavsiye edilir zira projenin başında ve sonun-da 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 orta-ya çı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 de-tayları verilmiş olan bir araçta projenin daha ikinci yılın-da 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.

Şekil 3: Örnek Hava Aracı Geliştirme Sistem Süreci[3]



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ım-da, yazılım fonksiyonları emniyet isterleri gözetilerek ifade edilir. Kaynak yönetimi, hata dayanım, zaman kısıtları vb.

Sertifikasyon Gerekleri (Certification Considerati-ons): 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): Uygula-nacak 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 sertifikas-yon otoritesiyle yapılacak gözden geçirmenin tarihleri planlanır.

Ek Düşünceler (Additional Consideration): Bu kısım-da projenin ilerleyişinde ve emniyet isterlerinin karşılan-ması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 gere-ken 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 ka-lite 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öneticisi-

ne, “Şunları şunları yapmamışsınız ve ben bunu onayla-mı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üreci-nin ş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ılma-sı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 so-rumluluğunda ve hangi işlemlere tabi olacağının belirtil-diğ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 kon-figürasyonların nasıl oluşturulup nasıl saklanacağı ve nu-maralandı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 edi-lerek geliştirilmektedir. Yazılım gereksinimlerinin analiz edilmesiyle başlayan bu süreç, yazılım tasarımının yapıl-ması, kaynak kod geliştirilmesi ve bileşenlerin entegras-yonundan oluşur.

Yazılım geliştirmenin dört temel süreci dahilinde izle-necek 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



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 bahsedile-bilir. DO-178C kılavuzluğunda gerçekleştirilen projelerde yazılım geliştirmesini etkileyebilecek yazılım yaşam dön-gü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 ra-porlarını sunmanız istenecektir.

3. SONUÇGünümüz karmaşık sistemlerinin en önemli bileşeni ko-numunda 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 sis-temlerine kadar birçok emniyet ve iş kritik yazılım üre-ticiler 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 ya-zılım uçuş kontrol, seyrüsefer, silah kontrol vb. görevleri yerine getirmektedir.

Havacılık sektöründe kullanılan yazılımların munta-zam test edilmesi, yazılımların düzgün çalışması ve ya-zılıma bağlı çalışan sistemlerin emniyetli ve fonksiyonel olarak görevlerini icra etmelerinin güvencesidir. Yazılı-

Şekil 4: DO-178B projelerinde süreç bazında harcanan ortalama çaba grafiği[4]

Şekil 5: NASA, Quora, Ohio University, Wired aracılığı ile derle-nen bilgiler ışığında farklı uygulamalarda kullanılan yazılımla-rın büyüklükleri (kaynak kod bazında)[5]



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 hava-

cı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.



http://thinktech.stm.com.tr

hava araÇ sertİfİkasyonunda yazilim faktÖrlerİ

Documents