Boeing 737 MAX 8 Mürettebat ve Yolcuları
Yazılım Kurbanı mı?

Hava Aracı Yazılım Testleri

‘‘Uçuş emniyeti önceliğimizdir. Gelişmeleri sıkı şekilde takip ediyoruz’’ THY Genel Müdürü Bilal Ekşi

Yazar: Ben Sampson, Aerospace Testing International, 25 Eylül 2018

Çeviren: Ercan Caner, Sun Savunma Net, 12 Mart 2019

Modern bir hava aracının uçuşu esnasında yüz milyonlarca satır kod çalışmaktadır. Yazılım, mutfaktaki sıradan komponentler ve yüksek seviyede kritik olan uçuş kontrol sistemleri dâhil hava araçlarının neredeyse her yerinde kullanılmaktadır.

Her satır kod, hataların belirlenmesi için kontrol edilmek zorundadır. Her bir yazılım birimi, diğer birimlerle uyum içinde çalıştığının görülmesi için kontrol edilmeli ve sonra da daha üst sistem seviyelerinde test edilmelidir. Bu çok zahmetli bir süreçtir. Hava araçları maliyetlerinin artması ve geliştirilmesindeki gecikmeler, giderek artan bir oranda yazılım testleriyle ilişkilendirilmektedir. Fakat hava araçlarında hatasız yazılım kullanılması da çok önemlidir.

Yazılımın hata yapması durumunda, 2009 yılında Brezilya’dan Paris’e gitmekte olan 447 Sefer Sayılı Air France A330 yolcu uçağının Atlantik üzerinde suya çakıldığında olduğu gibi uçaktaki herkesin hayatını kaybettiği büyük bir felaketle sonuçlanan kaza-kırımlar meydana gelebilir. QA Systems yazılım firmasından uluslararası satış müdürü Dylan Llewellyn, bu kazanın bir donanım arızasından kaynaklandığını, fakat kazanın asıl nedeninin donanım arızasını zamanında tespit etmeyen ve bildirmeyen yazılım yetersizliği olduğunu ifade etmektedir.

Kritik Planlama

Hava araçlarında kullanılan yazılım miktarı giderek daha da artacaktır. Örneğin, hava aracı motorları geliştikçe daha fazla yazılıma bağımlı hale gelmiştir. FADEC (Full Authority Digital Engine Control – Tam Donanımlı Sayısal Motor Kontrol Ünitesi) sistemi olan motorlar tamamen yazılım tarafından kontrol edilmektedir. Ticari hava araçları arasında Airbus A380, çok fazla kod kullanılması ile bilinen bir uçaktır. Fakat yazılımının geliştirilmesinin akıllara durgunluk verecek derecedeki karmaşıklığı nedeniyle uzun gecikmelere maruz kalan F-35 savaş uçağında kullanılan kod miktarı hiç bir hava aracıyla karşılaştırılamaz.

447 Sefer Sayılı uçakta yaşanan felaketlerden kaçınmak ve maliyetleri düşürmek maksadıyla yazılım testleri mümkün olabildiğince geliştirme safhasının başlarında yapılmalıdır. Aviyonik yazılımları uzmanı ve Southeast Europe for Vector Software bölge yöneticisi olan Massimo Bambino, bir geliştirme programındaki yazılım testlerinin ilk günden itibaren planlanmasını ve küçük ve becerikli yazılım ekiplerinin oluşturulmasını tavsiye etmektedir. Bu yazılım ekipleri, beklenmedik kötü sürprizler ve kodlar hata yaptığında uygulanan son dakika regresyon testlerini en aza indirmek maksadıyla bütün yazılım ve entegrasyon testlerini en baştan itibaren planlamalıdır.

Bambino; regresyon testinin bir kâbus olduğunu ve bütün yazılım endüstrisi için büyük bir problem olduğunu ifade etmektedir. Regresyon testi; uygulama ortamındaki yapılan tüm değişiklikleri; uygulamaya yeni eklenen özellikler, daha önceki yaşanan hataların düzeltilmesinden sonra, mevcut problemlerin giderildiği ve yeni yapılan güncellemelerin, eklenen özelliklerin yeni bir hata üretip üretmediğini kontrol amaçlı olarak yapılan yazılım testidir. Regresyon testleri özellikle güvenlik açısından kritik olan havacılık yazılımlarında büyük bir problemdir. Her şey mükemmel olarak çalışabilir ve aşılması gereken son engele gelindiğinde ortaya yeni bir şey çıkar ve test başarısızlıkla sonuçlanır. Regresyon testleri, ileri teknoloji olmadığında, çözmesi oldukça ustalık ve dikkat isteyen ve zaman alan testlerdir.

Bambino, regresyon testlerini önlemenin iki yolu olduğuna inanmaktadır. Bunlardan birincisi; daha en başından itibaren testlerin dikkatli bir şekilde yapılmasıdır. Fakat eğer çok fazla problem varsa ve artık çok geç ise, değişim esaslı testlerin uygulanması daha iyidir. Vector Software Firması, kod değişiklikleri sonrasında alt testlerin yapılmasını ve böylelikle testlerin etkinliğinin geliştirilmesini sağlayan bir teknolojiye sahiptir.

Bağımsız Doğrulama

FAA (Federal Aviation Administration – Federal Havacılık İdaresi), EASA (European Aviation Safety Agency – Avrupa Havacılık Emniyet Ajansı) ve Kanada Ulaştırma Bakanlığının, bütün ticari yazılım esaslı uzay sistemlerinin onaylanmasında ana doküman olarak kabul ettiği DO-178C Sertifikasyonuna göre, yazılım bağımsız taraflarca test edilmelidir.  Birçok orijinal donanım üreticisi kendi bünyelerinde ayrı ekipler kullansalar da yazılım testleri DO-178C gereği çoğunlukla üçüncü taraflara yaptırılmaktadır. Bu bağımsız taraflar, kodlardaki bütün hataların giderilmesini sağlamak maksadıyla doğrulama ve onaylama testleri icra ederler.

Bilgisayar bilim insanı ve yazılım geliştirici AdaCore firması dil araştırma direktörü olan Tucker Taft, diğer bir problemin de test yapıcıların doğrulama ve onaylama safhalarında birçok hata bulması durumunda, yanlışların geriye orijinal yazılım geliştiricilere kadar izlenmesinin zor olabileceğini ifade etmektedir.

Taft’a göre; test aşamasına gelindiği değerlendirildiğinde, bütün yazılımı bir araya getirmeye dayanan eski moda yaklaşım, yüz milyonlarca satır kod söz konusu olduğunda işe yaramamaktadır. Taft, günümüzde akıllı firmaların entegrasyon testlerine kadar beklemediklerini ve test süreçlerinde tasarım aşamasında hataların bulunmasına başlangıçtan itibaren büyük önem verdiklerini vurgulamaktadır.

En modern ve zamana süratle ayak uyduran firmalar, geçilmesi gereken koşulları belirlemeden kod yazmaya başlamadıkları, test odaklı yazılım geliştirme yöntemini kullanmaktadır. Bu firmaların sırrı; testleri tamamen geliştirme sürecinin bir parçası haline getirmeleridir.

Tucker Taft, hataları tespit etmek için yazılımı test ettiğinde, bir test uzmanının kodları çalıştırmadan hataların ortaya çıkmasını matematiksel olarak belirlemeye çalıştığı bir statik analiz yöntemi uygulamaktadır. Edindiği tecrübeler ona, programcılar tarafından yazılan konvansiyonel testleri kullanarak bazı yazılım türlerini kontrol etmenin zor olduğunu ve statik analiz yöntemini kullanarak yazılım biriminin güvenilirliğinin resmi sonucunu elde etmenin daha kolay olabildiğini öğretmiştir. Bununla birlikte, diğer bazı tür yazılım birimlerinde de bunun tam tersi doğru olabilir.

Taft, sistemin bir kısmı için matematiksel kanıtlara odaklanıldığını ve diğer kısımlar için de daha dinamik bir test stratejisi kullanıldığını ifade etmektedir. Taft’a göre müşteriler, matematiksel kanıtlara da ulaştıklarından, genellikle birleşmiş bir strateji kullanılmasını tercih etmektedirler.

Sertifikasyon maksatlı yapılan daha resmi testlerde, Taft yazılım için başlangıç ve sonuç şartlarını tanımlamayı tercih etmektedir. Başlangıç şartları, yazılımın bir komponente veri gönderme öncesinde kodun belirli özelliklere sahip olması anlamına gelmektedir. Yazılım uygun durumda olmadığı sürece veri göndermesine izin verilmez. Test işlemi başlangıç şartlarının karşılandığını doğrulayabilir. Sonrasında ise test sonrası şartlar, test uzmanının yazılımdan önceden belirlenmiş hangi verileri geri alması gerektiğini belirler.

Tucker Taft, başlangıç ve sonuç şartları kullanıldığında, birçok resmi doğrulamanın yapılabildiğini ve yazılımın bir bütün olarak uygunluğunun belirlenebildiğini ifade etmektedir. Ayrıca, her bir alt yüklenici ayrı olarak yaptığından ve testlerini icra ettiğinden, sonunda yazılım bir araya getirildiğinde, kaçınılmaz olarak bazı şeylerin yanlış gittiği, daima büyük bir problem olan entegrasyon testleri de kolaylaşmaktadır.

Test Modelleri ve Fuzz Testi

Teknolojik gelişmeler, yazılım test iş yükünün azaltılmasına yardım etmektedir. Yazılım testlerinde otomatik testlerin yanı sıra matematiksel modellerin kullanılması son yıllarda süratle gelişmiştir. Test faaliyetleri günümüzde, yazılım yüklendiğinde bir hava aracının ne yapacağını büyük bir doğrulukla simüle edebilmektedir.

Boeing ve Airbus gibi büyük hava aracı üreticileri, yazılım testlerinde model tabanlı yaklaşımı benimsemiş ve ayrıntılı, hassas modeller oluşturmuşlardır. Bu modeller, donanımın bir simülasyon ortamında hava aracının yazılım sistemleriyle test edildiği donanım çevrimde (HITL – Hardware In The Loop) testlerini yapabilsinler diye alt yüklenicilerle paylaşılabilir. Taft, bu simülasyonların yapılmasının oldukça fazla iş yükü gerektirdiğini,  oluşturulmalarının gereksiz bir iş olmaktan ziyade ağırlığınca altın değerinde olduğunu ifade etmektedir.

Başka bir trend de yazılımın, çökertilmesi maksadıyla, ‘‘fuzz’’ olarak adlandırılan çok büyük miktarda rastgele veriyle doldurulduğu Fuzz Testidir.

Tucker Taft, Fuzz testini beyaz şapkalı bilgisayar korsanlarının büyük şirketlerin güvenlik sistemlerindeki yetersizlikleri ortaya çıkarmak maksadıyla yaptıklarına benzetmektedir. Fuzz testi, henüz pratik uygulama seviyesine ulaşmış durumda değildir, fakat akademik çevrelerde birçok araştırma yapılmaktadır ve Taft’a göre gelecekte Fuzz testi yazılım testlerinin icrasında çok büyük bir rol oynayacaktır. Bir donanım arızasının rastgele veri ürettiği veya bir bilgisayar korsanının müdahale ediyor olabileceği asla bilinmeyebilir.

Bütün bu teknik ilerlemelere rağmen birçok hava aracı üreticisi yazılım testlerini çok zahmetli ve külfetli bulmaktadır. QA Systems Firmasından Dylan Llewellyn, Boeing 777X modeli uçağın güç dağıtım sistem yazılım testlerini yapan ekipte yer almıştır. Kodlar, bloklar halinde yazılmış ve sisteme dâhil edilmeden önce, önceden yüklenen kodlara olumsuz bir etkisinin olup olmadığı açısından test edilmiştir. Llewellyn, mevcut kodlarda kötü bir kod olması durumunda bunun büyük bir karmaşaya neden olduğunu, bu nedenle de Boeing 777-300 model hava aracında kullanılan kodların hiç birisinin 777X modeli üzerinde kullanılmadığını ifade etmektedir.

Boeing 777X Yazılım Geliştirme Süreci

Prosedür aslında oldukça tipik bir şekilde yürütülmüş, hava aracı üzerinde kullanılacak olan test ve yazılımları geliştirmek maksadıyla her biri dört beş mühendisten oluşan ve birbirlerinden bağımsız olarak çalışan birçok ekip görev almıştır. Bu arada, 6o bağımsız uzman da doğrulama ve onaylama işlerini gerçekleştirmiştir.

Llewellyn, Boeing 777X modeli hava aracı için inanılmaz miktarda testler yapıldığını, bir blok kodun testini düzinelerce mühendisin 10 aylık bir sürede gerçekleştirdiğini ifade etmektedir.

Güç dağıtım yazılım testlerine uçmayacak bir model üzerinde başlanmış, çeşitli birim ve entegrasyon testleriyle sürdürülmüştür. Bütün sistemlerin testi tamamlandıktan sonra yazılımlar Iron Bird (Ana komponentlerin hava aracı üzerindeki ilgili yerlerine yerleştirildiği sistem)  üzerine yerleştirilmiş ve gereksiz yazılımların ve çoklu sistem arızalarının tespit edilmesi için yoğun testler uygulanmıştır. Bütün bu faaliyetler sonrasında da yazılım testte kullanılacak hava aracı üzerine yerleştirilmiştir.

Modern hava araçlarında yazılımın böylesine ayrılmaz bir rolü olduğundan, yazılım testlerinin genellikle problemlere neden olan bir çaba olması belki de hiç şaşırtıcı değildir. Fakat hava araçlarında kullanılan kodların miktarı ve karmaşıklığı arttıkça hava aracı üretici şirketleri, daha iyi teknoloji ve daha iyi yönetim kullanarak yazılım testlerinin üstesinden gelmeye zorlanacaktır.

Bu makale ilk olarak Aerospace Testing International dergisinin Eylül 2018 sayısında yayınlanmıştır.

Çevirenin Notları: Yazı aslına sadık kalınarak çevrilmiştir,  orijinal metne aşağıdaki link üzerinden erişebilirsiniz.

Bu yazıyı bana gönderen; GÖKBEY helikopterinin ilk uçuşunu gerçekleştiren TUSAŞ Deneysel Test Pilotu & Öğretmen Pilotu Gökhan Virlan’a teşekkür eder, GÖKBEY helikopterini tasarlayan Türk mühendisler ile arka planda büyük emek ve özveriyle çalışan bütün TUSAŞ personeline başarılar ve kazasız uçuşlar dilerim.

Bir büyük alkış da milyonlarca satır kod yazan yazılımcılara…

Getting to grips with software testing | Aerospace Testing International

During a modern airplane’s flight, hundreds of millions of lines of code will run. Software is present almost everywhere in the aircraft, from mundane components like galley equipment to highly critical ones such as flight control systems. Each line of code has to be checked for faults.