Savunma Sanayii Başkanlığının önderliğinde 2004 yılında başlatılan ARGE2004 projesiyle birlikte havacılık alanında milli donanım üzerinde çalışan %100 milli yazılım geliştirilmesi serüveni ülkemizde özellikle askeri havacılık alanında dışa bağımlılığı tamamen ortadan kaldırmıştır. Özellikle, pilot için kritik uçuş ekranlarını da üreten görev bilgisayarı ilk olarak ATAK Helikopteri ihalesiyle birlikte kurgulanmış, donanımı ve yazılımıyla tamamen milli olarak geliştirilmiş ve son dönemde de milli tasarım uçak ve helikopterlerimizde diğer özgün tasarım ASELSAN aviyonik sistemlerle birlikte başarıyla kullanılmaktadır.
Modern hava araçlarına herhangi bir cihazı, telsiz olsun, silah olsun, entegre edebilmek için tüm sistemleri kontrol eden görev bilgisayarı tasarımına hakim olmanız şarttır. Hava aracının hazır olarak temin edildiği durumda, üzerindeki tüm sistemlerle entegre çalışan bir platforma sahip olursunuz, ancak üzerine milli sistemlerinizi kullanabilmek için tasarımcı firmaya gitmeniz gerekir. Aviyonik ve askeri sistemler de ülkeler arası kontrollere tabii olduğu için çeşitli sıkıntılar yaşanabilmekte ve sizi tamamen dışarıya bağımlı kılabilmektedir.
İşte bu bağımlılığı kırmak için o yıllarda SSM önderliğinde başlatılan çalışmalar meyvesini vermiş ve T-129 ATAK Helikopteri başta olmak üzere, T-38 Eğitim uçağı, ANKA İnsansız Hava Aracı, HÜRKUŞ-B Eğitim Uçağı, F-16 Özgür Savaş Uçağı, T-70 Genel Maksat Helikopteri ve Gökbey Helikopterleri tamamen milli bir görev bilgisayarı ve milli aviyonik sistemlerle geliştirilmiştir.
Hava araçlarında yıllara sair önemi ve büyüklüğü katlanarak artan yazılımın özellikleri ve geliştirilmesine yönelik bilgileri bu yazımızda bulabilirsiniz.
NASIL BAŞLADI?
ATAK Helikopteri ihale süreci hazır alımla başlayıp kritik bir kararla milli bir görev bilgisayarı geliştirilerek tüm aviyonik ve silah sistemi entegrasyonunun milli imkanlarla entegre edilmesi kararlaştırıldı. Paralelde de ARGE2004 projesi başlatılarak ASELSAN önderliğinde TÜBİTAK ve TUSAŞ ile üçlü konsorsiyum kurularak çok iddialı bir takvim içerisinde görev bilgisayarı yazılım ve donanımların geliştirilmesi için start verildi.
Prototip platform olarak envanterde bulunan AH-1S Süper Kobra helikopteri tahsis edildi. Kara Kuvvetleriyle yakın çalışılarak eski tip kokpitten yola çıkılarak modern bir glass kokpit tasarlandı. Emniyet açısından sadece ön kokpit modernize edildi, arka kokpit aynen korundu. Tersine mühendislikle tüm helikopter ve motor sinyalleri sayısallaştırılarak görev bilgisayarı tarafından ana uçuş ekranları (PFD - Primary Flight Display) oluşturuldu. ATAK Helikopteri konfigürasyonunda yer alan sistemler prototipte yer aldı. İlk kez bir hava aracına mühimmat entegrasyonu gerçekleştirildi.
Sayısal Harita dahil telsizler, veri aktarımı, elektronik harp, görev yönetimi, termal kamera gibi modern hava araçlarında bulunan tüm özelliklere sahip bir modernizasyon gerçekleştirildi ve çalışmalar başarılı bir canlı füze atışıyla taçlandırıldı.
Bundan sonrası hızlı devam etti. Öncelikle Agusta-Westland ve TUSAŞ ile T-129 ATAK Helikopteri projesine başlandı, paralelde TUSAŞ ile T-38 Eğitim Uçakları modernize edildi, TUSAŞ tasarımı ANKA Orta İrtifa İnsansız Hava Araçları için Görev Bilgisayarı geliştirildi.
ATAK ve T-38’de yapılanları inceleyen Sikorsky firması yetkilileri Türkiye’nin Genel Maksat Helikopteri ihalesinde ASELSAN görev bilgisayarını kullanmayı teklif etti. Bu uluslararası bir başarıydı. Özellikle ATAK ihalesinden çekilen Amerika’nın kısa bir süre içerisinde Türk Yazılımını kabul ettiğinin bir kanıtı oldu ve Savunma Sanayii Başkanlığı tarafından da dile getirildi.
Sonrasında, aviyonik alanında işler, ÖZGÜR F-16 Blok 30 modernizasyonu, TUSAŞ’ın geliştirdiği HÜRKUŞ-B Eğitim Uçağı ve Gökbey Helikopteri projeleri başta olmak üzere artarak devam etti.
GÖREV BİLGİSAYARI NEDEN KRİTİK?
Hava araçlarında, özellikle askeri platformlarda, yolcu taşımacılığı dışında kritik olan görevdir. Helikopter, savaş uçağı, insansız hava aracının görevi icra etmesi, emniyetli uçması kadar kritiktir. Dolayısıyla, modern askeri platformlarda pilotların, uçmanın yanı sıra görevlerini de yerine getirebilmeleri için hem uçuş hem görev sistemlerini tek bilgisayarda entegre eden kritik yapı görev bilgisayarıdır. Görev Bilgisayarı, hem platformda yer alan uçuş kontrol bilgisayarı ile haberleşerek hava aracının kontrolünü sağlamakta, hem de göreve yönelik diğer tüm sistemlerin kontrollerini yerine getirerek pilotlara sayısal ekranlar (MFD - Multifunction Display) üzerinden gösterim sağlamaktadır. Ana uçuş ekranından sayısal haritaya, elektronik harp sisteminden silahların kontrolüne kadar tüm sistemler görev bilgisayarı üzerinden hava aracına entegre edilmektedir.
Ülkemiz açısından görev bilgisayarının kritikliği, hava aracına milli tasarım aviyoniklerin ve milli tasarım silah sistemlerin görev bilgisayarı tasarımına hakim olmadan entegre edilememesidir. Böyle bir durumda, platform üreticisi firmaya gitmeden kendi tasarladığınız telsizinizi bile hava aracına entegre edemiyorsunuz. Dolayısıyla, askeri havacılık alanındaki bu dışa bağımlılık milli görev bilgisayarının tasarlanmasıyla aşılabilmiştir.
Görev Bilgisayarı tasarımının diğer elektronik cihaz tasarımlarından ve yazılım geliştirmeden farkı, havacılık alanında emniyetli tasarım için uyulması zorunlu standartlara uygun geliştirilmesi ve uçuşa elverişlilik için sertifikasyon alınmasıdır. Bu süreçler de tecrübe kazanılarak elde edilebilen, herhangi bir firmadan veya eğitimle kazanılamayan ciddi bir bilgi birikimidir (know-how).
AVİYONİK YAZILIMIN DİĞER YAZILIMLARDAN FARKI NEDİR?
Günümüzde, hepimizin kullandığı elektronik cihazlarla birlikte piyasaya pek çok yazılım sürülmekte, her birinde de belli hatalar (bug) bulunmaktadır. Sonrasında gelen güncellemelerle bu hatalar giderilmeye çalışılmaktadır. Ancak, aviyonik alanında bunu yapmanınız söz konusu olamaz.
Bir yazılımı hava aracına yükleyebilmek için oluşturulan obje kodunun (Executable binary) her bir bit’inin hangi amaçla orada olduğunu ve amaca uygun olarak doğru çalıştığının bir testle doğrulandığını sertifikasyon otoritesine kanıtlamanız gerekmektedir. Yani, test edilmemiş veya amaca hizmet etmeyen bir bit bile yazılımın içerisinde yer alamaz. Bunun nasıl başarılacağına yönelik tek bir yöntem olmadığı gibi, olası yöntemlere ilişkin bir bilgiye ulaşmak da neredeyse imkansızdır. Buna yönelik uygun teknikleri kendiniz belirlemeniz ve sürecinizi ona göre kurgulamanız gerekir ki, işin sonunda yazılımınız sertifiye olabilsin. Kurguda bir hata varsa, işin mali boyutundan bağımsız olarak sertifikasyonu alamaz ve yazılımı uçağa yükleyemezsiniz.
Aviyonik Yazılımların geliştirilmesinde sertifikasyon otoritelerinin baz aldığı standart, RTCA/DO-178C’dir. Bu doküman aslında bir standart değil, bir rehber dokümandır. Bu dokümana uyumlu ilerlendiğinde yazılımın sertifiye olabilmesi olasılığı yüksektir ve otoriteler tarafından izlenmesi tavsiye edilmektedir. İşin muallaklığı ve zorluğu da buradadır: hiçbir şey net değildir. Duruma göre ele alınmalıdır.
DO-178C
“Aviation” ve “Electronics” kelimelerini birleşiminden oluşan “Avionics” kelimesi, uçak elektronik sistemlerini temsil etmekte, bu elektroniklerin içerisinde yer alan yazılımlara da kısaca “Aviyonik Yazılım” olarak adlandırılmaktadır. Gömülü yazılımın bir alt alanı olan aviyonik yazılım, sadece teknik açıdan değil, yazılım yaşam döngüsü boyunca uygulanan süreçleriyle de farklılık göstermektedir.
Sivil havacılıkta uyulması zorunlu olan DO-178C standardı, aviyonik sistemlerde oluşabilecek yazılım hatalarının insan hayatına zarar vermemesi için hem izlenen yazılım süreçleri açısından hem de geliştirilen yazılım açısından dikkat edilmesi gereken esasları ve süreçlerin izlendiğine dair oluşturulması gereken sertifikasyon kanıtlarını tanımlamaktadır. Yazılım geliştirmenin her safhasında, geliştirilen yazılımın kritiklik seviyesine uygun olarak analiz, tasarım, kodlama ve testlerin bağımsız olarak gözden geçirilmesi, emniyet ve hata analizlerinin yapılması ve bu sayede can ve uçuş güvenliğine (safety) etki edebilecek her türlü hatanın ayıklanması amaçlanmaktadır. Sivil havacılık alanının olmazsa olmazları arasında yer alan bu standart askeri alanda da kendini kabul ettirmiş ve tüm askeri havacılık projelerinde de ülkemizde uyulması zorunlu hale gelmiştir.
SAE ARP 4754A ve ARP 4761 aviyonik sistem ve emniyet süreçleri ile birlikte işletilen RTCA/DO-178C süreci, platform ve sistem seviyesinde belirlenen kritiklik seviyelerinin yazılımda güvence altına alınmasında yol gösterir. RTCA/DO-178C, yazılımları, neden olabilecekleri sonuçların etkisine göre A’dan E’ye kadar beş seviyeye ayırmaktadır. A seviyesi, yazılım hatası oluştuğunda insan hayatına mal olabilecek yazılımlar için, E seviyesi de, insan hayatına etkisi olmayan yazılımlar için tanımlanmıştır. Her seviye için kanıt oluşturulması gereken ilave adımlar eklenmektedir. Bu nedenle, A seviyesi bir yazılımın geliştirilip doğrulanması, yazılım sürecinde en fazla zaman ve kaynak gerektiren seviye olmaktadır.
Seviye A olarak belirlenen bir yazılımın, üzerinde koştuğu tüm hava araçlarının görev yaptıkları tüm ömür/servis döngüleri boyunca tek noktadan kaynaklanan bir hatadan dolayı ölümcül sonuçlar oluşmayacağını taahhüt etmek ve bununla ilgili tüm kanıtları oluşturmak gerekmektedir. Böyle bir taahhüt için ilave sistem seviyesi çözümler oluşturulmakta, aviyonik mimari buna uygun tasarlanmaktadır.
Artık ASELSAN iç süreçleri, aviyonik alanında yazılım geliştirildiğinde, projede DO-178C ve/veya sertifikasyon isteri olmasa da, DO-178C’ye uygun olarak geliştirilmektedir ve sertifikasyon süreci, iç denetimlerle otorite yerine yürütülmektedir.
YAZILIM SERTİFİKASYONU
Hava aracına çıkan tüm yazılımların uçuşa elverişlilik (airworthiness) açısından sertifikasyonlarının yapılması gerekmektedir. Sivil hava sahasında uçabilmesi için hava aracına Tip Sertifikasyonu (TS) alınması zorunludur. Bu sertifikasyonun yazılım için zorunlu kıldığı standart DO-178C’dir. Hava aracından bağımsız olarak bazı standart birimlere tek başına TSO/ETSO sertifikasyonu alınabilmektedir. Bu sertifikalandırmayı Avrupa’da EASA, Amerika’da ise FAA havacılık otoriteleri gerçekleştirmektedir. Ülkemizde de bu rolü sivil projelerde Sivil Havacılık Genel Müdürlüğü (SHGM) ve askeri projelerde Savunma Sanayii Başkanlığı (SSB) üstlenmektedir. Sertifikasyon otoritesi yazılım açısından öncelikle DO-178C planlarını onaylamakta, sonrasında kanıtların ve sürecin planlara uygunluğunu SOI (Stage of Involvement) adı verilen denetimlerle gerçekleştirilmekte ve süreç boyunca üretilen tüm DO-178C kanıtlarını onaylamaktadır.
ASELSAN Görev Bilgisayarı Yazılımları ATAK Helikopteri ile başlayan süreçte T-38 Eğitim Uçağı, ANKA İnsansız Hava Aracı, ÖZGÜR F-16 Blok 30 Modernizasyonu, HÜRKUŞ-B Yeni Nesil Temel Eğitim Uçağı projeleri kapsamında SSB tarafından bağımsız olarak DO-178 açısından denetlenmektedir. Sikorsky ile birlikte yürütülen Genel Maksat Helikopteri projesinde Sikorsky QAB (Quality Assurance Board) tarafından bu süreç yürütülmüştür. Gökbey Helikopteri projesinde de sivil konfigürasyon için SHGM bu rolü üstlenmiştir.
AVİYONİK YAZILIM GELİŞTİRME SÜRECİ
Aviyonik Yazılım geliştirme süreçleri DO-178C standardında tanımlanmıştır. Yazılımın kritiklik seviyesine göre gerçekleştirilmesi gereken aktiviteler ve oluşturulması gereken sertifikasyon kanıtları (artifacts) değişiklik göstermektedir. Emniyet seviyesi arttıkça beklenen kriterlerin (objectives) sayısı da artmaktadır.
Burada aynı zamanda bağımsız olarak yürütülmesi gereken faaliyetlerin sayısı da seviye arttıkça artmaktadır. Bu faaliyetler temelde gözden geçirme ve doğrulama faaliyetler olarak özetlenebilir. En basit anlatımla, bir çıktıyı (artifact) üreten kişi ile o çıktıyı doğrulayan kişin farklı olmasıdır. Benzer şekilde, kritiklik seviyesi düşük yazılımlarda konfigürasyon kontrolü altındaki kanıtların bir kısmı için sadece son sürümlerinin yer alması yeterli olabiliyorken, daha yüksek seviyelerde tüm versiyonların saklanması ve yeni sürümlerin sadece değişiklik yönetimi süreci ile oluşturulması zorunlu olmaktadır.
Süreç, sertifikasyon konularının nasıl ele alınacağını anlatan Yazılım Sertifikasyon Planı (PSAC – Plan for Software Aspects of Certification) ile başlar ve sürecin bu plana göre nasıl sonlandığını anlatan Yazılım Başarım Özeti (SAS – Software Accomplishment Summary) ile son bulur.
Planlama aşamasında PSAC’in yanı sıra yazılım geliştirme (SDP), doğrulama (SVP), konfigürasyon yönetimi (SCMP) ve kalite güvencesi (SQAP) için dört farklı plan ve gereksinim (SRS), tasarım (SDS) ve kodlama (SCS) için üç ayrı geliştirme standardı oluşturulmaktadır. Gereksinim aşamasında üst seviye gereksinimler, tasarım aşamasında da yazılım mimarisi ve alt seviye gereksinimler oluşturulup, kodlama ve entegrasyon aşamalarına geçilmektedir. Sistem gereksinimlerinden üst ve alt seviye gereksinimlere ve oradan kodlamaya kadar çift yönlü izlenebilirlik kurulmaktadır. Benzer şekilde tüm gereksinimlerle test prosedürleri arasında da izlenebilirlik sağlanmaktadır.
Doğrulama süreci geliştirme sürecine paralel gitmektedir. Her aşamada kontrol listeleri kullanılarak sırasıyla gereksinim, tasarım, kodlama, entegrasyon, doğrulama prosedürleri ve doğrulama sonuçları gözden geçirilmekte ve kayıtları konfigürasyon kontrolü altında saklanmaktadır. Doğrulama aşamasında gereksinim bazlı testlerle yazılımın tamamı doğrulanmakta ve kapsama analizleri ile testlerin yeterliliği değerlendirilmektedir.
Kalite tüm süreci yakından takip etmektedir. Ayrıca sertifikasyon otoritesi, tüm dokümantasyonu onayladığı gibi ayrıca planlama, geliştirme, doğrulama ve sertifikasyon aşamalarında dört adet denetim (SOI – Stage of Involvement) gerçekleştirmektedir.
GÖREV BILGISAYARI YAZILIMI
Pilota uçuş ile ilgili tüm gösterge ve kontrolleri sağlayan ve uçuş yönetim sistemi (FMS) yazılımını da içeren Görev Bilgisayarı, hava aracında yer alan güvenli haberleşme, silah, elektronik harp, kask, hedefleme ve silah sistemlerinin denetimlerini gerçekleştirmekte, aviyonik sistemlerin arıza ve yedekleme yönetimini sağlamaktadır.
Yazılım güvenliği (safety) ve engetre modüler aviyonik (IMA – Integrated Modular Avionics) kavramlarıyla beraber bölüntü (partition) kavramı oluşmuştur. Bölüntüleme, yazılım parçalarını hem hafıza kullanımı, hem de işlemci kullanımı açısından tamamen birbirinden bağımsız hale getirmektedir. Bu sayede yazılımlar, sanki farklı işlemcilerde çalışıyormuşçasına tek bir işlemci üzerinde birbirlerini etkilemeden çalışabilmektedirler. Bir bölüntüde oluşan hata diğerini kesinlikle etkilememekte; hata oluşan bölüntünün diğer yazılımları etkilemeden yeniden başlatılabilmesine imkan vermektedir. ARINC-653, bu bölüntülemeye uygun standart işletim sistemi arayüzü sunmaktadır. Bölüntülemenin yanı sıra bu standart arayüz sayesinde işletim sistemi bağımlılığı da ortadan kalkmakta, işletim sistemi değişiklikleri uygulama seviyesinde kolaylıkla gerçekleştirilebilmektedir.
ASELSAN Görev Bilgisayarı Yazılımı, bu bölüntüleme yapısı kullanılarak geliştirilmiş ve tüm yazılım, kritiklik ve fonksiyonellik açısından modüler parçalara ayrılmıştır. Bölüntüler arası iletişim için kullanılan standart arayüzler sayesinde hava aracı konfigürasyonu ve ihtiyaçlarına bağlı olarak bölüntüler, ya tek bir işlemci ya da birden çok işlemci üzerinde koşabilmektedir. Bir işlemci üzerinde koşan bir bölüntü, ileride doğabilecek genişleme ihtiyaçlarına bağlı olarak farklı bir işlemci üzerine kolaylıkla taşınabilmektedir.
Görev Bilgisayarı Yazılımı modüler, katmanlı, model-tabanlı bir yazılım mimarisi üzerine kurulmuş ve ARINC-653 uyumlu işletim sistemi ile donanıma bağımlılığı en aza indirgenmiştir.
Katmanlı yapının en altında, Gerçek Zamanlı İşletim Sistemi ile üzerinde koşulan donanımlara erişimi sağlayan Kart Destek Paketi (BSP – Board Support Package) ve Sürücü (device driver) yazılımları yer almaktadır. Bu yazılımlar, uygulamadan bağımsız tamamen donanıma özgü olarak geliştirilmektedir. Her tür donanım değişikliklerinde bu yazılımlar güncellenmektedir. Kart Destek Paketi ve Sürücü yazılımları, kullanılan işletim sistemine özgü geliştirilmektedir. Bu katmanın üzerinde, işletim sistemine standart bir arayüz üzerinden erişim sağlayan ARINC-653 uyumlu işletim sistemi katmanı yer almaktadır.
Bu iki katman, uygulamadan bağımsız, tamamen donanıma ve işletim sistemine özgü bir yapıda kurulmuştur. Donanım değişikliklerinden bu iki katman doğrudan etkilenmektedir. Ancak aynı donanımın kullanıldığı farklı uygulamalarda bu iki katman aynı kalmaktadır.
Bu iki katman üzerinde uygulama yazılımlarını donanımdan soyutlayan ve donanım ve dış arayüzlere ortak yazılım arayüzleri üzerinden erişimi sağlayan donanım soyutlama katmanı yer almaktadır. Bu katman, tüm görev bilgisayarları için ortak yazılım modülleri ile donanıma ve konfigürasyona özgü temel yazılımları içermektedir. Aynı zamanda uygulama yazılımları ile donanım arasında üst seviye bir arayüz sağlayarak donanımın tamamen uygulamadan soyutlanmasını sağlamaktadır. Bu katman sayesinde her türlü donanım ve ortam değişiklikleri uygulama katmanı değiştirilmeden kolaylıkla mümkün olabilmektedir.
En üst seviyede bulunan sistem yönetimi katmanı, tüm bu yazılımların ayağa kalkmasını, sağlıklarının izlenmesini, yedekleme yönetimini, işlemcilerin senkronizasyonu gibi yönetimleri gerçekleştirmektedir. Bir yazılımda problem olduğunun tespit edilmesi ve buna bağlı olarak sadece o yazılım yeniden çalıştırılmasını veya tüm yazılımın baştan çalışmasını yöneten de bu katmandır. İki görev bilgisayarı arası geçişi de bu yazılım sağlamaktadır.
Modern hava araçlarına herhangi bir cihazı, telsiz olsun, silah olsun, entegre edebilmek için tüm sistemleri kontrol eden görev bilgisayarı tasarımına hakim olmanız şarttır. Hava aracının hazır olarak temin edildiği durumda, üzerindeki tüm sistemlerle entegre çalışan bir platforma sahip olursunuz, ancak üzerine milli sistemlerinizi kullanabilmek için tasarımcı firmaya gitmeniz gerekir. Aviyonik ve askeri sistemler de ülkeler arası kontrollere tabii olduğu için çeşitli sıkıntılar yaşanabilmekte ve sizi tamamen dışarıya bağımlı kılabilmektedir.
İşte bu bağımlılığı kırmak için o yıllarda SSM önderliğinde başlatılan çalışmalar meyvesini vermiş ve T-129 ATAK Helikopteri başta olmak üzere, T-38 Eğitim uçağı, ANKA İnsansız Hava Aracı, HÜRKUŞ-B Eğitim Uçağı, F-16 Özgür Savaş Uçağı, T-70 Genel Maksat Helikopteri ve Gökbey Helikopterleri tamamen milli bir görev bilgisayarı ve milli aviyonik sistemlerle geliştirilmiştir.
Hava araçlarında yıllara sair önemi ve büyüklüğü katlanarak artan yazılımın özellikleri ve geliştirilmesine yönelik bilgileri bu yazımızda bulabilirsiniz.
NASIL BAŞLADI?
ATAK Helikopteri ihale süreci hazır alımla başlayıp kritik bir kararla milli bir görev bilgisayarı geliştirilerek tüm aviyonik ve silah sistemi entegrasyonunun milli imkanlarla entegre edilmesi kararlaştırıldı. Paralelde de ARGE2004 projesi başlatılarak ASELSAN önderliğinde TÜBİTAK ve TUSAŞ ile üçlü konsorsiyum kurularak çok iddialı bir takvim içerisinde görev bilgisayarı yazılım ve donanımların geliştirilmesi için start verildi.
Prototip platform olarak envanterde bulunan AH-1S Süper Kobra helikopteri tahsis edildi. Kara Kuvvetleriyle yakın çalışılarak eski tip kokpitten yola çıkılarak modern bir glass kokpit tasarlandı. Emniyet açısından sadece ön kokpit modernize edildi, arka kokpit aynen korundu. Tersine mühendislikle tüm helikopter ve motor sinyalleri sayısallaştırılarak görev bilgisayarı tarafından ana uçuş ekranları (PFD - Primary Flight Display) oluşturuldu. ATAK Helikopteri konfigürasyonunda yer alan sistemler prototipte yer aldı. İlk kez bir hava aracına mühimmat entegrasyonu gerçekleştirildi.
Sayısal Harita dahil telsizler, veri aktarımı, elektronik harp, görev yönetimi, termal kamera gibi modern hava araçlarında bulunan tüm özelliklere sahip bir modernizasyon gerçekleştirildi ve çalışmalar başarılı bir canlı füze atışıyla taçlandırıldı.
Bundan sonrası hızlı devam etti. Öncelikle Agusta-Westland ve TUSAŞ ile T-129 ATAK Helikopteri projesine başlandı, paralelde TUSAŞ ile T-38 Eğitim Uçakları modernize edildi, TUSAŞ tasarımı ANKA Orta İrtifa İnsansız Hava Araçları için Görev Bilgisayarı geliştirildi.
ATAK ve T-38’de yapılanları inceleyen Sikorsky firması yetkilileri Türkiye’nin Genel Maksat Helikopteri ihalesinde ASELSAN görev bilgisayarını kullanmayı teklif etti. Bu uluslararası bir başarıydı. Özellikle ATAK ihalesinden çekilen Amerika’nın kısa bir süre içerisinde Türk Yazılımını kabul ettiğinin bir kanıtı oldu ve Savunma Sanayii Başkanlığı tarafından da dile getirildi.
Sonrasında, aviyonik alanında işler, ÖZGÜR F-16 Blok 30 modernizasyonu, TUSAŞ’ın geliştirdiği HÜRKUŞ-B Eğitim Uçağı ve Gökbey Helikopteri projeleri başta olmak üzere artarak devam etti.
GÖREV BİLGİSAYARI NEDEN KRİTİK?
Hava araçlarında, özellikle askeri platformlarda, yolcu taşımacılığı dışında kritik olan görevdir. Helikopter, savaş uçağı, insansız hava aracının görevi icra etmesi, emniyetli uçması kadar kritiktir. Dolayısıyla, modern askeri platformlarda pilotların, uçmanın yanı sıra görevlerini de yerine getirebilmeleri için hem uçuş hem görev sistemlerini tek bilgisayarda entegre eden kritik yapı görev bilgisayarıdır. Görev Bilgisayarı, hem platformda yer alan uçuş kontrol bilgisayarı ile haberleşerek hava aracının kontrolünü sağlamakta, hem de göreve yönelik diğer tüm sistemlerin kontrollerini yerine getirerek pilotlara sayısal ekranlar (MFD - Multifunction Display) üzerinden gösterim sağlamaktadır. Ana uçuş ekranından sayısal haritaya, elektronik harp sisteminden silahların kontrolüne kadar tüm sistemler görev bilgisayarı üzerinden hava aracına entegre edilmektedir.
Ülkemiz açısından görev bilgisayarının kritikliği, hava aracına milli tasarım aviyoniklerin ve milli tasarım silah sistemlerin görev bilgisayarı tasarımına hakim olmadan entegre edilememesidir. Böyle bir durumda, platform üreticisi firmaya gitmeden kendi tasarladığınız telsizinizi bile hava aracına entegre edemiyorsunuz. Dolayısıyla, askeri havacılık alanındaki bu dışa bağımlılık milli görev bilgisayarının tasarlanmasıyla aşılabilmiştir.
Görev Bilgisayarı tasarımının diğer elektronik cihaz tasarımlarından ve yazılım geliştirmeden farkı, havacılık alanında emniyetli tasarım için uyulması zorunlu standartlara uygun geliştirilmesi ve uçuşa elverişlilik için sertifikasyon alınmasıdır. Bu süreçler de tecrübe kazanılarak elde edilebilen, herhangi bir firmadan veya eğitimle kazanılamayan ciddi bir bilgi birikimidir (know-how).
AVİYONİK YAZILIMIN DİĞER YAZILIMLARDAN FARKI NEDİR?
Günümüzde, hepimizin kullandığı elektronik cihazlarla birlikte piyasaya pek çok yazılım sürülmekte, her birinde de belli hatalar (bug) bulunmaktadır. Sonrasında gelen güncellemelerle bu hatalar giderilmeye çalışılmaktadır. Ancak, aviyonik alanında bunu yapmanınız söz konusu olamaz.
Bir yazılımı hava aracına yükleyebilmek için oluşturulan obje kodunun (Executable binary) her bir bit’inin hangi amaçla orada olduğunu ve amaca uygun olarak doğru çalıştığının bir testle doğrulandığını sertifikasyon otoritesine kanıtlamanız gerekmektedir. Yani, test edilmemiş veya amaca hizmet etmeyen bir bit bile yazılımın içerisinde yer alamaz. Bunun nasıl başarılacağına yönelik tek bir yöntem olmadığı gibi, olası yöntemlere ilişkin bir bilgiye ulaşmak da neredeyse imkansızdır. Buna yönelik uygun teknikleri kendiniz belirlemeniz ve sürecinizi ona göre kurgulamanız gerekir ki, işin sonunda yazılımınız sertifiye olabilsin. Kurguda bir hata varsa, işin mali boyutundan bağımsız olarak sertifikasyonu alamaz ve yazılımı uçağa yükleyemezsiniz.
Aviyonik Yazılımların geliştirilmesinde sertifikasyon otoritelerinin baz aldığı standart, RTCA/DO-178C’dir. Bu doküman aslında bir standart değil, bir rehber dokümandır. Bu dokümana uyumlu ilerlendiğinde yazılımın sertifiye olabilmesi olasılığı yüksektir ve otoriteler tarafından izlenmesi tavsiye edilmektedir. İşin muallaklığı ve zorluğu da buradadır: hiçbir şey net değildir. Duruma göre ele alınmalıdır.
DO-178C
“Aviation” ve “Electronics” kelimelerini birleşiminden oluşan “Avionics” kelimesi, uçak elektronik sistemlerini temsil etmekte, bu elektroniklerin içerisinde yer alan yazılımlara da kısaca “Aviyonik Yazılım” olarak adlandırılmaktadır. Gömülü yazılımın bir alt alanı olan aviyonik yazılım, sadece teknik açıdan değil, yazılım yaşam döngüsü boyunca uygulanan süreçleriyle de farklılık göstermektedir.
Sivil havacılıkta uyulması zorunlu olan DO-178C standardı, aviyonik sistemlerde oluşabilecek yazılım hatalarının insan hayatına zarar vermemesi için hem izlenen yazılım süreçleri açısından hem de geliştirilen yazılım açısından dikkat edilmesi gereken esasları ve süreçlerin izlendiğine dair oluşturulması gereken sertifikasyon kanıtlarını tanımlamaktadır. Yazılım geliştirmenin her safhasında, geliştirilen yazılımın kritiklik seviyesine uygun olarak analiz, tasarım, kodlama ve testlerin bağımsız olarak gözden geçirilmesi, emniyet ve hata analizlerinin yapılması ve bu sayede can ve uçuş güvenliğine (safety) etki edebilecek her türlü hatanın ayıklanması amaçlanmaktadır. Sivil havacılık alanının olmazsa olmazları arasında yer alan bu standart askeri alanda da kendini kabul ettirmiş ve tüm askeri havacılık projelerinde de ülkemizde uyulması zorunlu hale gelmiştir.
SAE ARP 4754A ve ARP 4761 aviyonik sistem ve emniyet süreçleri ile birlikte işletilen RTCA/DO-178C süreci, platform ve sistem seviyesinde belirlenen kritiklik seviyelerinin yazılımda güvence altına alınmasında yol gösterir. RTCA/DO-178C, yazılımları, neden olabilecekleri sonuçların etkisine göre A’dan E’ye kadar beş seviyeye ayırmaktadır. A seviyesi, yazılım hatası oluştuğunda insan hayatına mal olabilecek yazılımlar için, E seviyesi de, insan hayatına etkisi olmayan yazılımlar için tanımlanmıştır. Her seviye için kanıt oluşturulması gereken ilave adımlar eklenmektedir. Bu nedenle, A seviyesi bir yazılımın geliştirilip doğrulanması, yazılım sürecinde en fazla zaman ve kaynak gerektiren seviye olmaktadır.
Seviye A olarak belirlenen bir yazılımın, üzerinde koştuğu tüm hava araçlarının görev yaptıkları tüm ömür/servis döngüleri boyunca tek noktadan kaynaklanan bir hatadan dolayı ölümcül sonuçlar oluşmayacağını taahhüt etmek ve bununla ilgili tüm kanıtları oluşturmak gerekmektedir. Böyle bir taahhüt için ilave sistem seviyesi çözümler oluşturulmakta, aviyonik mimari buna uygun tasarlanmaktadır.
Artık ASELSAN iç süreçleri, aviyonik alanında yazılım geliştirildiğinde, projede DO-178C ve/veya sertifikasyon isteri olmasa da, DO-178C’ye uygun olarak geliştirilmektedir ve sertifikasyon süreci, iç denetimlerle otorite yerine yürütülmektedir.
YAZILIM SERTİFİKASYONU
Hava aracına çıkan tüm yazılımların uçuşa elverişlilik (airworthiness) açısından sertifikasyonlarının yapılması gerekmektedir. Sivil hava sahasında uçabilmesi için hava aracına Tip Sertifikasyonu (TS) alınması zorunludur. Bu sertifikasyonun yazılım için zorunlu kıldığı standart DO-178C’dir. Hava aracından bağımsız olarak bazı standart birimlere tek başına TSO/ETSO sertifikasyonu alınabilmektedir. Bu sertifikalandırmayı Avrupa’da EASA, Amerika’da ise FAA havacılık otoriteleri gerçekleştirmektedir. Ülkemizde de bu rolü sivil projelerde Sivil Havacılık Genel Müdürlüğü (SHGM) ve askeri projelerde Savunma Sanayii Başkanlığı (SSB) üstlenmektedir. Sertifikasyon otoritesi yazılım açısından öncelikle DO-178C planlarını onaylamakta, sonrasında kanıtların ve sürecin planlara uygunluğunu SOI (Stage of Involvement) adı verilen denetimlerle gerçekleştirilmekte ve süreç boyunca üretilen tüm DO-178C kanıtlarını onaylamaktadır.
ASELSAN Görev Bilgisayarı Yazılımları ATAK Helikopteri ile başlayan süreçte T-38 Eğitim Uçağı, ANKA İnsansız Hava Aracı, ÖZGÜR F-16 Blok 30 Modernizasyonu, HÜRKUŞ-B Yeni Nesil Temel Eğitim Uçağı projeleri kapsamında SSB tarafından bağımsız olarak DO-178 açısından denetlenmektedir. Sikorsky ile birlikte yürütülen Genel Maksat Helikopteri projesinde Sikorsky QAB (Quality Assurance Board) tarafından bu süreç yürütülmüştür. Gökbey Helikopteri projesinde de sivil konfigürasyon için SHGM bu rolü üstlenmiştir.
AVİYONİK YAZILIM GELİŞTİRME SÜRECİ
Aviyonik Yazılım geliştirme süreçleri DO-178C standardında tanımlanmıştır. Yazılımın kritiklik seviyesine göre gerçekleştirilmesi gereken aktiviteler ve oluşturulması gereken sertifikasyon kanıtları (artifacts) değişiklik göstermektedir. Emniyet seviyesi arttıkça beklenen kriterlerin (objectives) sayısı da artmaktadır.
Burada aynı zamanda bağımsız olarak yürütülmesi gereken faaliyetlerin sayısı da seviye arttıkça artmaktadır. Bu faaliyetler temelde gözden geçirme ve doğrulama faaliyetler olarak özetlenebilir. En basit anlatımla, bir çıktıyı (artifact) üreten kişi ile o çıktıyı doğrulayan kişin farklı olmasıdır. Benzer şekilde, kritiklik seviyesi düşük yazılımlarda konfigürasyon kontrolü altındaki kanıtların bir kısmı için sadece son sürümlerinin yer alması yeterli olabiliyorken, daha yüksek seviyelerde tüm versiyonların saklanması ve yeni sürümlerin sadece değişiklik yönetimi süreci ile oluşturulması zorunlu olmaktadır.
Süreç, sertifikasyon konularının nasıl ele alınacağını anlatan Yazılım Sertifikasyon Planı (PSAC – Plan for Software Aspects of Certification) ile başlar ve sürecin bu plana göre nasıl sonlandığını anlatan Yazılım Başarım Özeti (SAS – Software Accomplishment Summary) ile son bulur.
Planlama aşamasında PSAC’in yanı sıra yazılım geliştirme (SDP), doğrulama (SVP), konfigürasyon yönetimi (SCMP) ve kalite güvencesi (SQAP) için dört farklı plan ve gereksinim (SRS), tasarım (SDS) ve kodlama (SCS) için üç ayrı geliştirme standardı oluşturulmaktadır. Gereksinim aşamasında üst seviye gereksinimler, tasarım aşamasında da yazılım mimarisi ve alt seviye gereksinimler oluşturulup, kodlama ve entegrasyon aşamalarına geçilmektedir. Sistem gereksinimlerinden üst ve alt seviye gereksinimlere ve oradan kodlamaya kadar çift yönlü izlenebilirlik kurulmaktadır. Benzer şekilde tüm gereksinimlerle test prosedürleri arasında da izlenebilirlik sağlanmaktadır.
Doğrulama süreci geliştirme sürecine paralel gitmektedir. Her aşamada kontrol listeleri kullanılarak sırasıyla gereksinim, tasarım, kodlama, entegrasyon, doğrulama prosedürleri ve doğrulama sonuçları gözden geçirilmekte ve kayıtları konfigürasyon kontrolü altında saklanmaktadır. Doğrulama aşamasında gereksinim bazlı testlerle yazılımın tamamı doğrulanmakta ve kapsama analizleri ile testlerin yeterliliği değerlendirilmektedir.
Kalite tüm süreci yakından takip etmektedir. Ayrıca sertifikasyon otoritesi, tüm dokümantasyonu onayladığı gibi ayrıca planlama, geliştirme, doğrulama ve sertifikasyon aşamalarında dört adet denetim (SOI – Stage of Involvement) gerçekleştirmektedir.
GÖREV BILGISAYARI YAZILIMI
Pilota uçuş ile ilgili tüm gösterge ve kontrolleri sağlayan ve uçuş yönetim sistemi (FMS) yazılımını da içeren Görev Bilgisayarı, hava aracında yer alan güvenli haberleşme, silah, elektronik harp, kask, hedefleme ve silah sistemlerinin denetimlerini gerçekleştirmekte, aviyonik sistemlerin arıza ve yedekleme yönetimini sağlamaktadır.
Yazılım güvenliği (safety) ve engetre modüler aviyonik (IMA – Integrated Modular Avionics) kavramlarıyla beraber bölüntü (partition) kavramı oluşmuştur. Bölüntüleme, yazılım parçalarını hem hafıza kullanımı, hem de işlemci kullanımı açısından tamamen birbirinden bağımsız hale getirmektedir. Bu sayede yazılımlar, sanki farklı işlemcilerde çalışıyormuşçasına tek bir işlemci üzerinde birbirlerini etkilemeden çalışabilmektedirler. Bir bölüntüde oluşan hata diğerini kesinlikle etkilememekte; hata oluşan bölüntünün diğer yazılımları etkilemeden yeniden başlatılabilmesine imkan vermektedir. ARINC-653, bu bölüntülemeye uygun standart işletim sistemi arayüzü sunmaktadır. Bölüntülemenin yanı sıra bu standart arayüz sayesinde işletim sistemi bağımlılığı da ortadan kalkmakta, işletim sistemi değişiklikleri uygulama seviyesinde kolaylıkla gerçekleştirilebilmektedir.
ASELSAN Görev Bilgisayarı Yazılımı, bu bölüntüleme yapısı kullanılarak geliştirilmiş ve tüm yazılım, kritiklik ve fonksiyonellik açısından modüler parçalara ayrılmıştır. Bölüntüler arası iletişim için kullanılan standart arayüzler sayesinde hava aracı konfigürasyonu ve ihtiyaçlarına bağlı olarak bölüntüler, ya tek bir işlemci ya da birden çok işlemci üzerinde koşabilmektedir. Bir işlemci üzerinde koşan bir bölüntü, ileride doğabilecek genişleme ihtiyaçlarına bağlı olarak farklı bir işlemci üzerine kolaylıkla taşınabilmektedir.
Görev Bilgisayarı Yazılımı modüler, katmanlı, model-tabanlı bir yazılım mimarisi üzerine kurulmuş ve ARINC-653 uyumlu işletim sistemi ile donanıma bağımlılığı en aza indirgenmiştir.
Katmanlı yapının en altında, Gerçek Zamanlı İşletim Sistemi ile üzerinde koşulan donanımlara erişimi sağlayan Kart Destek Paketi (BSP – Board Support Package) ve Sürücü (device driver) yazılımları yer almaktadır. Bu yazılımlar, uygulamadan bağımsız tamamen donanıma özgü olarak geliştirilmektedir. Her tür donanım değişikliklerinde bu yazılımlar güncellenmektedir. Kart Destek Paketi ve Sürücü yazılımları, kullanılan işletim sistemine özgü geliştirilmektedir. Bu katmanın üzerinde, işletim sistemine standart bir arayüz üzerinden erişim sağlayan ARINC-653 uyumlu işletim sistemi katmanı yer almaktadır.
Bu iki katman, uygulamadan bağımsız, tamamen donanıma ve işletim sistemine özgü bir yapıda kurulmuştur. Donanım değişikliklerinden bu iki katman doğrudan etkilenmektedir. Ancak aynı donanımın kullanıldığı farklı uygulamalarda bu iki katman aynı kalmaktadır.
Bu iki katman üzerinde uygulama yazılımlarını donanımdan soyutlayan ve donanım ve dış arayüzlere ortak yazılım arayüzleri üzerinden erişimi sağlayan donanım soyutlama katmanı yer almaktadır. Bu katman, tüm görev bilgisayarları için ortak yazılım modülleri ile donanıma ve konfigürasyona özgü temel yazılımları içermektedir. Aynı zamanda uygulama yazılımları ile donanım arasında üst seviye bir arayüz sağlayarak donanımın tamamen uygulamadan soyutlanmasını sağlamaktadır. Bu katman sayesinde her türlü donanım ve ortam değişiklikleri uygulama katmanı değiştirilmeden kolaylıkla mümkün olabilmektedir.
En üst seviyede bulunan sistem yönetimi katmanı, tüm bu yazılımların ayağa kalkmasını, sağlıklarının izlenmesini, yedekleme yönetimini, işlemcilerin senkronizasyonu gibi yönetimleri gerçekleştirmektedir. Bir yazılımda problem olduğunun tespit edilmesi ve buna bağlı olarak sadece o yazılım yeniden çalıştırılmasını veya tüm yazılımın baştan çalışmasını yöneten de bu katmandır. İki görev bilgisayarı arası geçişi de bu yazılım sağlamaktadır.
