Emniyet Kritik Sistemlerde Model Tabanlı Doğrulama ve Gereksinim Gözden Geçirme Alper KENDİ Yazılım Müdürlüğü, STM A.Ş., Ankara e-posta: akendi@stm.com.tr Özetçe Bu makalenin amacı, güvenlik kritik yazılım geliştirme çevriminde karşılaşılan gereksinim kaynaklı hataların erken tespit edilmesine yardımcı bir yöntem anlatmaktır. Bu yöntem ile gereksinim tabanlı modelleme ve model üzerinden doğrulama yaklaşımı kullanılarak, yüksek verimli gereksinim gözden geçirilmesine ve beraberinde az hatalı, tutarlı ve test edilebilir gereksinim oluşturulmasına imkân verilmektedir. 1. Giriş 1980 li yıllardan başlayarak büyüyerek yayılan ve yaşamın her noktasında kendilerini gösteren yazılımlara, konusu insan yaşamı olan uygulamalarda ihtiyaç duyulmaya başlandı. İnsan yaşamının emanet edildiği bu tür yazılımların geliştirilmesine yazılımın üstlendiği sorumluluktan ötürü elverişlilik, güvenilirlik ve benzeri gibi ölçütler, uyulması zorunlu standartlar ile denetimler getirildi. Günümüzde halen mühendisler, insanoğlunun doğası gereği hata yapma alışkanlığı karşısında, insan üretimi fakat hata yapmayan yazılım geliştirilmesi zorunluluğu ile kıyasıya mücadele vermektedir. Bu mücadele güvenlik kritik yazılım geliştirme çevriminde, hata bulmaya ve önlemeye yönelik yeni yöntemlerin ortaya çıkartılması ve uygulanması ile insan-hata denkleminde mühendislerce kazanılması zaruri bir mücadele halini almıştır. Model güdümlü doğrulama, model güdümlü geliştirme yönteminin gereksinimlerin gözden geçirilmesine yönelik bir uyarlamasıdır. Binlerce satırlık gereksinim kümeleri içerisinde kaybolmadan, anlaşılır ve çalıştırılabilir modeller üzerinden gözden geçirmelerin gerçekleştirilerek, projenin ilerleyen aşamalarında ortaya çıkması muhtemel hataların henüz sisteme girmeden tespit edilmesine olanak sağlar. Bu bildiride öncellikle model güdümlü geliştirmenin genel bir tanımı verilerek, model güdümlü doğrulamanın DO-178B gibi standartlar kılavuzluğunda geliştirilen güvenlik kritik yazılımlarda hata bulma üzerine etkileri ve sağladığı faydalar yazarın deneyimlerine dayandırılarak anlatılacaktır. santrallere kadar farklı yapı ve davranışlardaki sistemlerin modellenebilmesi için elverişlidir. UML/SysML gösterimi grafiksel ve kolay anlaşılır dört temel tipten oluşmaktadır [3]. 2.1. Yapısal Gösterim Yapısal gösterim sistem elemanlarının niteliklerinin, sağlanan servislerin ifade edildiği, yazılım sisteminde sınıf, nesne gibi yapılara karşılık gelen ve bu gibi yapıların modellenmesi için araçlar içeren gösterim şeklidir. Yapısal gösterim yazılım geliştirme süreci bakımından daha çok yazılım tasarım aşamasında önemini gösteren ve daha sık kullanılan bir yapı olsa da gereksinimlerden oluşturduğumuz modellerin tasarım içermemesi, başka bir ifade ile tasarımı tarif etmesinin sakıncalarından ötürü gereksinim doğrulama bakımından önem arz etmemektedir. Şekil 1 dost düşman tanıma sisteminin basit bir yapısal gösterimidir. Şekil 1 Yapısal Gösterim Örneği 2. Model Güdümlü Yaklaşım Birleşik Modelleme Dili (UML) günümüzde karmaşık sistemlerin yapı ve ilişkilerinin başarılı bir şekilde ifade edilebildiği, sistemin uygulama sahası, geliştirme süreci, kullanılan teknoloji gibi unsurlardan bağımsız olarak modellenebildiği ve Object Management Group (OMG) isimli kuruluş tarafından standart haline getirilen bir dildir. SysML varyasyonu ile birlikte UML, yazılım sistemlerinden nükleer 2.2. Fonksiyonel Gösterim Fonksiyonel gösterim, sistem fonksiyonları ve kabiliyetleri üzerinde duran, UML/SysML gösteriminde use-case diyagramlarının sıklıkla kullanıldığı, sistemin tam olarak ne yaptığı sorusunun yanıtını verirken, nasıl sorusuna cevap vermekten kaçınılması gereken gösterim biçimidir. Sistem fonksiyonlarının modellenmesi oldukça kolay gibi görünse de sistem tasarımında üzerinde en çok durulması ve 258
ekip olarak fikir alışverişinde bulunularak ilerlenmesi gereken bir süreçtir. Aksi takdirde sistem bir sonraki aşamada hiç kullanılmayacak yüzlerce kullanım senaryosu (use-case) modeli içerisinde kaybolacaktır. Orta büyüklükte bir aviyonik projede önerilen, use-case modeli sayısının 6-10 arasında tutulmasıdır [2]. Anlaşılabilirlik açısından faydalar sunan fonksiyonel modelleme, doğrulama ekiplerinin sistem bütününü daha rahat anlamasına ve doğrulama adımlarının tatbikinin sağlıklı yapılmasına imkân vermektedir. Şekil 2 de gösterilen elektronik harp sistemi hedefi etkisiz hale getirmek için dost düşman tanıma sisteminden faydalanmaktadır. 2.4. Etkileşimsel Gösterim Etkileşimsel gösterimler, tanımlı bir senaryo üzerinden mesaj tabanlı davranışların ifade edilmesi için uygundur. Etkileşimsel gösterimi yapılmış bir sistemin parçaları arasındaki iletişimi ve senaryo akışı görülebilir. Şekil 4 te görüleceği üzere etkileşimsel gösterimde sıklıkla kullanılan sıralama (sequence) diyagramları, sundukları yaşam çizgisi ile zamana dayalı mesajların gösteriminde de başarılıdır. EHMS sistemi, pilota tehdit raporlandıktan sonra 2 saniye içerisinde komut almaya hazır duruma gelebilmelidir. Şekil 2 Fonksiyonel Gösterim Örneği 2.3. Davranışsal Gösterim Davranışsal gösterim UML/SysML dilinde çoğunlukla durum (state machine) ve aktivite (activity) diyagram tipleri ile gösterimi yapılan sistem durumlarının, bir durumdan başka bir duruma geçilmesi için gerekli şartların ve tetik mekanizmalarının ifade edildiği, model güdümlü doğrulama yaklaşımında önem arz eden bir gösterim şeklidir. Davranışsal gösterimi yapılan sistemlerde, gereksinim aşamasında sıklıkla karşılaşılan ve gözden geçiriciler için yakalanması zor olan kontrol akışı aykırılıkları, davranışsal gösterimi yapılan sistem modellerinde kolaylıkla görülebilmektedir. (bkz.şekil 3) Şekil 3 Davranışsal Gösterim Örneği Şekil 4 Etkileşimsel Gösterim Örneği 3. Model Tabanlı Doğrulama Gözden geçirme, yazılım endüstrisinde yazılım geliştirme yaşam döngüsü ürünlerindeki hataları ortaya çıkartmaya yönelik, maliyeti düşük doğrulama tekniklerinden biri halini almıştır. Gözden geçirmelerin birincil amacı olan hata yakalama, sistem ile ifade edilen yapıdaki olağan dışı tüm sapmaları kapsamaktadır. Konusunda uzman gözden geçiriciler ön tanımlı bir süreç çerçevesinde gereksinim, kaynak kod vb. çıktıların hatalarını bulmaya yönelik çalışmalar yapmaktadır. Bu çalışmalarda kullanılan Active Design Review, Two-Person Review, N-Fold Review vb. gözden geçirme teknikleri gözden geçirmelerin kalitesini yükseltmeye yönelik adımlar, yöntemler içermektedir [5]. Günümüz şartlarında gözden geçirilecek ürünlerin büyüklüklerinin getirmiş olduğu karmaşıklığın çözümü için mevcut metotlar, gözden geçirilecek ürünlerin mantıksal bölümlere ayrılıp, yönetilmesi üzerine farklı yöntemler sunar. Tüm bu tekniklerin temelinde yatan ve gözden geçirmenin anlaşılabilirliğini artırmaya yönelik adımlar Model Güdümlü yaklaşım ile bir üst noktaya taşınmaktadır. Model üzerinden doğrulama yapmanın anlaşılabilirliği, pek çok gereksinimin tek bir model elemanı ile ifade edilebilmesinin ve mevcut modellerin çalıştırılabilmesinin gözden geçiriciye sağladığı kolaylık, yakalanan kritik olarak adlandırılabilecek hata sayısını artırmakta, bu durum projenin ilerleyen safhalarında ortaya çıkması olası hataların önüne geçilerek maliyetleri azaltmaktadır. 259
Şekil 5 Sistem Açılış Durumları Gereksinimler ile örtüşen fakat tasarım tarif etmeyen model elemanlarının oluşturulması, oldukça dikkat ve tecrübe isteyen bir uğraş olsa bile sistem tasarımına girdi teşkil etmek maksadı ile oluşturulan bu modellerin, doğrulama amaçlı kullanımı gereksinim kaynaklı özellikle kontrol akışına (control flow) yönelik hataların bulunmasında etkin bir yöntem olarak karşımıza çıkmaktadır. Test yoğun faaliyetler olan güvenlik kritik uygulama geliştirme süreçlerinde testler, geliştirme eforunun %35 gibi bir kısmını oluşturabilir [4]. Süreç dâhilindeki test faaliyetlerinde, DO-178B gibi kılavuzlarda karşımıza çıkan yapısal kapsam analizi (SCA) gibi metotlar kullanılarak hata yakalama oranları yükseltilebilmektedir. Sisteme girmiş hataların testler esnasında bulunacağı düşünülerek ilerlemek ise proje maliyetleri açısından dezavantajlıdır. Zira hatanın sisteme girmesi ile hatanın sistemde tespit edildiği safha ters orantılı olarak maliyetleri artırmaktadır. Sürecin başında (gereksinim aşaması) sisteme giren hatalar ve sürecin sonunda (kullanım aşaması) ortaya çıkarılan hatalar firmalara yüksek maliyetli zararlar veren hatalardır. Testler esnasında ortaya çıkan gereksinim kaynaklı bir hata, yazılım kaynak kodunun değişmesine, değişen yazılım kaynak kodu yazılım tasarımının değişmesine, tasarımın değişmesi, yazılım gereksinimlerinin değişmesine kadar gidebilecek bir döngüyü tetikleyerek, zaman ve para kayıplarına yol açabilmektedir. Hata yapması durumunda can kaybına yol açması muhtemel (DO-178B kılavuzundaki muadili ile seviye A) 10K satırlık güvenlik kritik bir yazılımda, kullanım aşamasında bulunan hatanın üreticiye maliyeti 500K-1M $ arasında değişmektedir. Bu noktada hataların tespit edilmesi kadar hataların geliştirme sürecinin hangi safhasında tespit edilebildiği de önem kazanmaktadır [1-4]. Metin tabanlı gereksinimlerin gözden geçirilmesi günümüz sistemleri düşünüldüğünde bir insanın bütünüyle hâkim olamayacağı karmaşıklıkta olabilmektedir. DO-178B ve benzeri standartların gözden geçirme kalitesini artırmaya yönelik bağımsız gözden geçirici zorunluluğu, gereksinimleri yazanlar ile gözden geçirenlerin farklı kişiler olmasını gerektirmektedir. Bu durum, gereksinimi yazan saha uzmanlarının diğer insanların da ilgili konuda uzman olduğunu varsayarak gereksinim oluşturmaları gerçeği ile birleştiğinde, gereksinimin gözden geçirici tarafından anlaşılıp, hata bulmaya yönelik kaliteli bir gözden geçirme faaliyetinin icra edilmesi zorlaşmaktadır. Yukarıdaki şekilde (bkz. Şekil 5) modeli verilen örnek, bir hava aracının seyrüsefer sisteminin cihaz içi testlerini gerçekleştirecek yazılımın, metin tabanlı gereksinimlerinden oluşturulmuştur. Cihaz içi testler aviyonik cihazların açılışında, kullanım esnasında otomatik olarak veya pilot/bakım elemanı tarafından başlatılmak suretiyle çalışan, aviyonik sistemdeki ön tanımlı durumları kontrol eden, kısaca aviyonik donanım ve yazılımın düzgün çalıştığını doğrulamaya yönelik testlerdir. Şekil 5 te gösterilen PBIT (power up built-in test) durumu sistemin donanım sınama testlerinin çalıştığı açılış cihaz içi test durumudur. Örneğimizdeki 29 adet ön tanımlı donanım sınama testi, sisteme güç verilmesinin ardından, PBIT durumunda otomatik olarak çalıştırılıp, ilgili testlerden çıkan sonuçlara göre sistemin açılış şekli tespit edilmektedir. Sistemin test sonuçlarına göre 3 farklı açılış durumu mevcuttur. Birinci durum tüm test sonuçlarının Geçti olduğu model üzerinde isallsuccess() metoduyla kontrol edilen ve sistemde ön tanımlı hiçbir hatanın bulunmadığı normal (Normal Mode) durumudur. İkinci durum ön tanımlı hatalardan bir kısmının olduğu, yine de sistemin açılışının kısıtlanmış kabiliyetler ile gerçekleştirilebileceği indirgenmiş durum (Degrade Mode) ve son olarak sistemde fonksiyonel olarak sağlıklı bir açılışa imkân vermeyecek düzeyde kritik hataların bulunduğu hata (Fail Mode) durumudur. Sisteme güç verilmesinin ardından 29 adet ön tanımlı donanım sınama testi sırasıyla çalıştırılacak, tüm test sonuçlarının geçmesi durumunda sistem normal (Normal Mode) durumuna, indirgenmiş işlevsellik ile açılış yapılması gerekiyorsa indirgenmiş (Degrade Mode) durumuna, eğer sistemde kritik hatalar bulunduysa sistem hata (Fail Mode) durumuna geçecektir (bkz. Şekil 5). Metin tabanlı gereksinimler incelendiğinde kontrol akışında bir problem görülmemektedir fakat kontrol akışımızda metin tabanlı gözden geçirilme ile tespit edilmesi zor 2 adet önemli hata bulunmaktadır. Sistem açılışında, tüm testlerin geçmesi durumunda sistem normal (Normal Mode) durumunda başlatılacaktır. şeklinde bir gereksinim maddesinde gözden geçirici için dikkat edilen noktalar çoğunlukla giriş koşulları olmaktadır. Çıkış koşulları ve çıkış koşullarına bağlı diğer durum giriş şartları yani resmin tamamı metin tabanlı bir gözden geçirmede kolaylıkla hakim olunabilen bir durum değildir. Tüm testler geçtiği takdirde sistem normal durumuna geçecek; eğer testler aracılığı ile bir hata tespit edilirse hatanın cinsine göre sistem indirgenmiş veya hatalı mod 260
durumlardan birisine geçecektir. 2 adet önemli eksiklikten biri sistemin indirgenmiş ve hata durumlarına geçmesinden sonra kendini göstermektedir. Gereksinimler içerisinde sistemin indirgenmiş ve hata durumlarından hangi koşulda veya koşullarda çıkacağı belirtilmemiştir. Hata veya indirgenmiş durumuna geçen sistemin yeniden başlatılması, bir süre sonra kendiliğinden kapanması veya sistemin ikinci bir tetiklenmeye kadar mevcut durumunu koruması şeklinde çıkış koşullarının gereksinimlere eklenmesi gerekmektedir. Aksi takdirde yukarıda bahsi geçen gereksinim setine göre geliştirilmiş aviyonik yazılım Şekil-6 da görüldüğü üzere 1 hata veya indirgenmiş durumlarına girdiğinde, sistem gücü kapatılıp açılıncaya kadar bu durumda bekleyecektir. Şekil 7 Zaman Aşımı Hatası Şekil 6 Kontrol Akışı Hatası Gereksinimlerde geçtiği şekli ile sistem 29 adet donanım sınama testinin çalıştırılıp, testlerin sonuçlarına göre ön tanımlı durumlardan birine geçmektedir. Metin tabanlı gereksinimlerin gözden geçirilmesi esnasında fark edilmeyen diğer bir akış sıralı halde çalışan 29 adet testten bir tanesinden yanıt alınamaması koşulunda sistemin düşeceği kararsız durumdur. Aviyonik donanımlar, özellikle askeri uygulamalarda oldukça zorlu çevre koşullarında çalışmak zorundadır. Arızalanmış bir sensörden veri okumaya çalışan 29 adet ön tanımlı testten bir tanesi hiçbir zaman geçti/kaldı şeklinde bir neticeyle sırasını devretmeyebilir. Sistemde tanımlı bir sonraki testin çalıştırılması mümkün olmayabilir veya sistem donanım sınama testlerinin dahi çalıştırılamayacağı bir arızaya sahip olabilir. Bu durumda Şekil-7 de görüldüğü üzere 2 sistem, testlerin koşturulduğu PBIT durumunda çıkmaza girecektir. İlgili gereksinimler içerisine eklenecek bir madde ile 29 adet ön tanımlı testin tamamlanması için bir zaman aşımı tanımlanıp, bu süre içerisinde testlerin tamamlanamaması durumunda, sistemde ciddi bir hatanın olduğu kabul edilerek sistem hata (Fail Mode) durumuna geçirilmelidir. 1 Şekil-6 ve Şekil-7 oluşturulan modellerin yardımcı araçlar kullanılarak çalıştırılması ile elde edilmiş ekran görüntüleridir. Pembe çerçeveli alanlar o an aktif olan durumları(state), sarı çerçeve, aktif olan duruma geçilmeden bir önceki aktif durumu belirtmektedir. Şekildeki FailMode durumundan çıkış koşulu olan evrestart olayı(event) gereksinim setine ve modele hatanın tespitinin ardından eklenmiştir. 2 Şekil 7 te görülen tm(18000) zaman aşımı, hatanın gereksinimdeki eksikliğinin tespit edilmesinin ardından gereksinimlere ve modele eklenmiştir. 4. Sonuçlar DO-178B kılavuzluğunda ilerlenen projelerde sistem gereksinimlerinden oluşturulan yazılım yüksek seviye gereksinimleri (High Level Requirements) yazılım sisteminin tam olarak ne yapacağını tüm detayları ile ifade etmektedir. Bu detayda yazılan gereksinim setlerinin metin tabanlı olarak gözden geçirilmeleri, hataların gözden kaçırılmasına zemin hazırlamaktadır. Yukarıda bir bölümünden örnek verilen Cihaz İçi Test bileşeninin gereksinimleri içerisinde, bileşenin hata durumundan hangi olay/koşul ile çıkacağı ve zaman aşımı oluşması halinde bileşenin nasıl davranacağı gibi gereksinimler ifade edilmemiştir. Model tabanlı doğrulama, ön gözden geçirme çalışmalarımızda metin tabanlı gereksinimlerin resmi gözden geçirilmeleri sırasında gözden kaçması muhtemel bu iki eksikliğin ortaya çıkartılmasında görev almıştır. Yirmi dört adet metin tabanlı gereksinimin, model üzerinden yapılan ön gözden geçirmeleri sırasında ortaya çıkartılan iki adet eksiklik, Şekil 5 te görülen hata durumunun (Fail Mode) çıkış şartı olarak eklenmiş yeniden başlat (evrestart) tetiği ve açılış cihaz içi test (PBIT) durumuna eklenmiş tm(18000) zaman aşımı mekanizması ile çözümlenmiştir. Model tabanlı doğrulama yöntemi, günümüz teknolojisinde Şekil 6-7 de görülen çalıştırılabilir modeller sayesinde henüz tasarım ve kaynak kodun oluşturulmadığı proje safhalarında, akış kontrollerindeki aksayış ve eksikliklerin tespit edilmesine imkân vermektedir. Bu sayede projenin ilerleyen aşamalarında ortaya çıkabilecek ve firmaya iş ve zaman kaybına yol açabilecek hataların henüz gereksinim gözden geçirmeleri esnasında çözümlenmesine olanak sağlanmıştır. 5. Teşekkür Çalışmalarım sırasında desteklerini esirgemeyen ve değerli görüşleri ile deneyimlerin bir bildiri haline gelmesine yön veren Sayın Serkan Çak ve mesai arkadaşım M.Umut Pişken e teşekkür ederim. 6. Kaynakça [1] ``RTCA/DO-178B Software Considerations In Airborne Systems And Equipment Certification, RTCA, Inc. 1992. [2] Bruce Powel Douglass, Real-Time UML Workshop for Embedded Systems, Elsevier, Oxford, 2007 [3] OMG Systems Modeling Language (OMG SysML), Document Number formal/2008-11-01, 2008 261
[4] Hilderman, Vance, DO-178B Costs Versus Benefits, www.highrely.com/ whitepapers.php, 2006 [5] Yuk Kuen Wog, Modern software review: Techniques and Technologies, IRM Press, 2006 262