Emniyet-Kritik Sistemlerin Süreci Software Verification Process in Safety-Critical Systems Mehmet Özbek mehmet.ozbek@bte.mam.gov.tr Ayşegül Kurt aysegul.kurt@bte.mam.gov.tr Ali Gürbüz ali.gurbuz@bte.mam.gov.tr Özet Günlük hayatın her alanında karşılaşılan yazılım, her geçen gün daha da yaygın bir şekilde kullanılmaktadır. Emniyet-kritik sistemler yazılımın önemli kullanım alanlarından biridir. Günümüzde kimyasal madde üretimi yapan fabrikalardan, nükleer santrallere, nükleer tıpta kullanılan biyomedikal cihazlardan, uçak, helikopter ve hızlı tren gibi ulaşım araçlarına, oradan silah sistemleri ve uzay araçlarına kadar birçok emniyet-kritik sistemin kontrolü emniyet-kritik yazılımlarla gerçekleştirilmektedir. Bu sistemlerin kullanımları sırasında meydana gelebilecek en küçük bir hata bile önemli can ve mal kayıplarına neden olabilir. Oluşabilecek muhtemel kazalar can ve mal kaybının yanında, çevre için de önemli zararlara neden olabilirler. Bu nedenle bu tür sistemlerin kontrolünde kullanılan emniyet-kritik yazılımların doğrulama sürecinin başarılı bir şekilde gerçekleştirilmesi ayrı bir önem arz etmektedir. Bu çalışma kapsamında emniyetkritik sistemlerdeki yazılımların doğrulama süreci anlatılmıştır. Donanım doğrulama süreci bu çalışma kapsamında ele alınmamıştır. Abstract In daily life software is everywhere in most fields and becoming much more popular day by day. Nowadays safety-critical software is used to control many types of systems from factories producing chemicals to nuclear power plants, from biomedical equipments used in nuclear medicine to transport systems like aircrafts, planes, helicopters, weapon systems and rapid trains. During the use of these systems any simple defect may cause serious accidents leading life or equipment (system) loss and ecological disasters. Thus the success of verification process of safety-critical software used in such kinds of systems is much more important. In this study the verification process of safety-critical software is explained. Hardware verification process is out of the scope of this study. 1. Giriş Emniyet-kritik sistem, herhangi bir hataya bağlı kaza olması durumunda: Can kaybı veya ciddi yaralanma, Ekipmanın kaybı veya ciddi bir şekilde hasar görmesi, Çevrenin büyük zarar görmesi gibi sonuçlara neden olabilecek sistemlere denir. Emniyet-kritik yazılımlar ise bu sistemlerde kullanılan yazılımlara denir. Emniyet-kritik yazılımların kullanımı her geçen gün yaygınlaşmaktadır. Bu tür yazılımlar nükleer reaktörlerin kontrolünde, zararlı kimyasalların üretildiği ve kullanıldığı endüstriyel merkezlerin kontrol sistemlerinde, radyasyon kullanan tıp cihazlarında önemli bir kullanım alanı bulmaktadır. Emniyet-kritik yazılımlar ayrıca kara/hava/deniz platformlarında kullanılan silah sistemlerinde, uzay araçlarında, uçak, helikopter, hızlı tren gibi ulaşım araçlarında da kullanılmaktadır. Bu yazılımlar günümüzde otomotiv sektöründe de kullanılmaya başlanmıştır. Tüm bu sistemlerde meydana gelebilecek en küçük bir hata olumsuz sonuçlar doğurabilir. Emniyet-kritik sistemlerde oluşabilecek hatalar yazılım kaynaklı, donanım kaynaklı veya insan faktörüne bağlı olabilir. Bu sistemlerin donanımları genellikle yedekli olarak tasarlanır ve arıza durumunda kesintiye uğramadan çalışmaya devam edebilmeleri Bu sistemlerin yazılımlarının da özel bir şekilde geliştirilmesi, kullanıma sunulmadan önce olası tüm hatalardan arındırılması gereklidir [1]. Bu nedenle bu tür sistemlerin otomasyonunda kullanılan emniyet-kritik yazılımların geliştirilmesi ve doğrulanması ayrı bir önem taşımaktadır. da bulunan bir hatayı tespit etmek genelde donanım hatasını tespit etmekten daha zordur. Bu durum hatanın giderilmesi için de söz konusudur. Emniyet-kritik yazılımların içerdikleri olası hatalar,
yazılımın üzerinde çalıştığı donanımı da (dolayısı ile tüm sistemi) devre dışı bırakıp tehlikeli sonuçlara yol açabileceğinden bu tür yazılımlar kullanılmadan önce sistematik bir doğrulama sürecinden geçirilmelidir. Böylelikle yazılımdan kaynaklanacak tehlikelerinin önceden belirlenmesi ve bunlar için önlem alınması Bu çalışma kapsamında emniyet-kritik yazılımlar geliştirilirken kullanılan doğrulama süreci anlatılacaktır. 2. Süreci süreci, geliştirilen sistemin, tam olarak istenen sistem olduğunu, kendisinden beklenen davranışları gerçekleştirdiğini ve sistemde istenmeyen özelliklerin bulunmadığını, istenmeyen davranışlar göstermediğini ortaya koyan süreçtir. geliştirmede, geliştirilen sistemin müşteri gereksinimlerini tam olarak karşıladığı ve yazılım geliştirmenin her evresindeki çıktıların doğru olduğuna karar verilmesi gerekir. Bu kararı verme süreci, yazılım doğrulama sürecidir. süreci, bu gibi nedenlerle yazılım geliştirmede en önemli süreçlerden birisidir. Böylelikle yazılımın kusursuz olarak çalışması doğrulama sürecinin temel amacı, geliştirilen yazılımda bulunan olası hataları ortaya çıkarmak ve bunların sonunda gerekli düzeltici eylemleri gerçekleştirmektir. Bu sürecin planlanması ve uygulanması, yazılım geliştirme sürecinin mümkün olduğunca erken evrelerinde başlatılmalıdır [2]. projelerinde gerçekleştirilen yazılım doğrulama süreci iki aşamada gerçekleştirilir. Bunlar gözden geçirmeler ve yazılım testleridir. Statik Belirtimleri Ön Tasarım Detay Tasarım Gerçekleme Şekil 1: doğrulama yöntemleri Dinamik geçirmeler statik doğrulama, yazılım testleri ise dinamik doğrulama yöntemidir [3,4]. geçirmeler (statik doğrulama), bir yazılım ürününün hedeflenen kullanıma uygunluğunu incelemek, kendi belirtimlerinden ve standartlardan sapmalarını tespit etmek amacıyla gerçekleştirilen sistematik değerlendirmelerdir [5]. Testleri (dinamik doğrulama), kaynak kodun çalıştırılarak bir yazılım ürününün kendisinden beklenen işlevsel davranışları gösterdiğini, kusurlar içermediğini ortaya koymak için hazırlanan test durumlarının koşturulmasıyla gerçekleştirilen eylemler dizisidir. Şekil-1, yazılım doğrulama sürecini şematik olarak göstermektedir. Statik doğrulama, yazılım yaşam döngüsünde her evre ile ilgilenirken, dinamik doğrulama sadece geliştirilen yazılım ile ilgilenir. Statik doğrulama; yönetimsel gözden geçirme, teknik gözden geçirme, üzerinden geçme (walkthrough), inceleme (inspection), denetleme (audit) gibi çeşitli gözden geçirme teknikleri ile gerçekleştirilirken, dinamik doğrulama ise işlevsel, yineleme (regression), performans, yükleme, stres, güvenlik, vb. testlerle gerçekleştirilir. geçirmelerin amaçlarından bazıları: yaşam döngüsünün her evresinde üretilen bütün dokümanların amaçlarına uygun olarak üretildiğini, n tam, tutarlı, test edilebilir vb. özellikleri karşıladığını, Tasarımın belirlenen gereksinimlere uygun, tutarlı ve gerçekleştirilebilir olduğunu, Üretilen kaynak kodun tasarımı tam olarak gerçeklediğini, ortaya koymaktır [6]. n gözden geçirilmemesi durumunda gereksinimdeki eksiklikler veya çelişkilerin ya farkına varılamayacak ya da yazılım yaşam döngüsünün ancak ilerlemiş evrelerinde tespit edilecektir. İleriki evrelerde tespit edilen hataların düzeltilmesi daha uzun düzeltici faaliyetlere neden olacağından, proje takviminin uzaması ve maliyetin artması riski ile karşılaşılacaktır. gözden geçirmenin amaçlarından biri de gereksinimin tasarım, gerçekleme ve testleri yapmak için yeterli detayı içerip içermediğinin tespit edilmesidir. gözden geçirmeler üzerinden geçme (walkthrough) şeklinde gerçekleştirilir. Bu teknikte amaç, kod içerisindeki mantıksal hataları, geliştirilen kodun kodlama standartlarına uymadığı durumları ve koddaki hatalı durumları (ilklendirilmemiş değişkenler, tanımlanmış ve hiç kullanılmamış değişkenler vb.) tespit etmektir. Statik doğrulama hata önleme ve tespitinde önemli bir
role sahip olup yazılım geliştirmenin erken evrelerinde bu gibi tespitlerin yapılmasını sağladığı için, proje maliyetinin artmasına ve proje takviminin uzamasına engel olarak projenin başarı ile tamamlanmasını sağlar [6]. Dinamik doğrulama yazılımın geliştirilmesi tamamlandıktan sonra, test eylemleriyle gerçekleştirilir. projelerinde gerçekleştirilen yazılım testlerinin amacı hataların varlığının ortaya konulmasıdır. Testler ile yazılımda hataların varlığı ortaya çıkarılır, yokluğu gösterilmez [7]. Başarılı bir test bir veya birden fazla hatanın bulunmasını sağlayan testtir. Statik ve dinamik doğrulama birbirini bütünleyen iki tekniktir. Birbirine karşı olan iki doğrulama tekniği değildir. doğrulama sürecinde her ikisi birlikte kullanılmalıdır. geçirmeler yazılımın belirtimlere ve standartlara uygunluğunun kontrol edilmesi olduğundan bu doğrulama yöntemi ile işlevsel ve performans, güvenlik gibi işlevsel olmayan özellikler kontrol edilemez. Statik doğrulama tek başına, geliştirilen yazılımın müşterinin gerçek gereksinimlerine uygun olduğunu garanti edemez. Bu amaçla gözden geçirmelere yani statik doğrulamaya bütünleyici olarak yazılım testleri yani dinamik doğrulama gerçekleştirilir. 3. Emniyet-Kritik Süreci Emniyet-kritik yazılımlarının doğrulama sürecinin temel amacı, yazılımın kusursuz olarak çalışmasının yanında güvenilir (safe) olarak geliştirilmesini sağlamaktır. Emniyet-kritik yazılımlar için doğrulama süreci, emniyet-kritik olmayan yazılımlardaki doğrulama sürecinde olduğu gibi statik ve dinamik doğrulama kapsamında gerçekleştirilir. Ancak bu tür yazılımların doğrulanmasında mevcut gözden geçirmelere ek olarak izlenebilirlik, ek gözden geçirmeler ve kapsama (coverage) analizleri gerçekleştirilir. Ayrıca geliştirilen emniyet-kritik sistem için de sistem emniyet analizleri yapılır. Şekil 2 de emniyet-kritik yazılımların statik doğrulama yöntemleri gösterilmiştir. Statik Şekil 2: Emniyet-kritik yazılımlarda statik doğrulama yöntemleri Emniyet-kritik yazılımlarda, emniyet-kritik olmayan yazılımların statik doğrulamasına ek olarak izlenebilirlik, gereksinim kapsama (requirement coverage) analizi ve test durumları gözden geçirmeleri gerçekleştirilmelidir. Dinamik doğrulamada ise testlere ek olarak yapısal kapsama (structural coverage) analizi ve test durumları ile kaynak kod arasındaki izlenebilirlik gerçekleştirilmelidir. İzlenebilirliklerin kurulması emniyet-kritik yazılımların geliştirilmesinde ayrı bir öneme sahiptir. Tüm müşteri gereksinimlerinin yeterli bir şekilde detaylandırılarak sistem gereksinimlerinin oluşturulduğu, sistem gereksinimlerinin detaylandırılarak bunlardan yazılım gereksinimlerinin oluşturulduğu ancak izlenebilirlik ile sistematik olarak doğrulanabilir. İzlenebilirlik gereksinim kapsaması için gereklidir. Bununla birlikte tüm gereksinimlerin test edildiğinin gösterilebilmesi için de test durumları ile gereksinimler arası izlenebilirliğin kurulması gereklidir. Test durumları ile kaynak kod arası kurulan izlenebilirlik dinamik doğrulamada gerçekleştirilen yapısal kapsama için gereklidir. Yapısal kapsama analizleri ile emniyet-kritik yazılımın sınır değerlerinin aşılması, uyarı-dikkat-ikaz bölgelerine girilmesi gibi olası bütün çalışma durumlarına karşı test edilmesi lerden kaynak koda doğru giden izlenebilirliğe ileri yönde izlenebilirlik; kaynak koddan gereksinimlere doğru olan izlenebilirliğe geri yönde izlenebilirlik denir. Şekil 3 de izlenebilirlik yapısı, görülmektedir. Müşteri İzlenebilirlik Sistem Test Durumları Test Durumları Kaynak İleri Yönde İzlenebilirlik
Şekil 3: Emniyet-kritik yazılımlarda izlenebilirlikler Emniyet-kritik yazılımların doğrulanma sürecinde diğer bir önemli konu da kapsama analizleridir. Bu tür yazılımlarda iki tür kapsamaya bakılması gereklidir. kapsaması statik doğrulamada, yapısal kapsama ise dinamik doğrulamada gerçekleştirilir. Şekil 4 de izlenebilirlik ve kapsama ilişkisi gösterilmiştir. Şekilde görüldüğü gibi, her bir sistem ve yazılım gereksinimini doğrulayacak en az bir test durumunun yazıldığının analizinin yapılmasına gereksinim kapsama denir. Böylelikle dinamik doğrulamada testler gerçekleştirilirken tüm gereksinimleri doğrulayacak olan test durumlarının mevcut olduğu gösterilir. Yapısal kapsamada ise koşturulan test durumları ile kodun ne kadarının çalıştırıldığı ve çalıştırılmayan kod parçasının olmadığı doğrulanır. Yapısal kapsama analizleri ile kod içerisindeki tüm satırların çalıştırılarak test edilmesi Sistem Test Durumları Yapısal Kaynak Şekil 4: İzlenebilirlik- kapsama ilişkisi Statik ve dinamik doğrulamanın otomatikleştirilmesi ve yazılım test araçlarının etkin bir şekilde kullanılması büyük önem taşır. Bu araçlar, özellikle DO178B gibi rehberler ve standartların öngördüğü doğrulama faaliyetlerinin gerçekleştirilmesinde önemli kolaylıklar sağlar. Emniyet kritik yazılımların doğrulama sürecinde ek olarak gerçekleştirilen bir diğer işlem ise test durumlarının gözden geçirilmesidir. Test durumlarını gözden geçirmedeki amaç doğrulanacak olan gereksinimlerin üretilen test durumu veya durumları ile gerçekten doğrulanıp doğrulanmadığının anlaşılmasıdır. Böylece her gereksinimin yeter sayıda ve doğru yapıda test durumu ile doğrulanabileceği garanti altına alınmaya çalışılır. Emniyet-kritik yazılımların doğrulama sürecine getirilen bu ek denetimler ile geliştirilen kritik yazılımın hedeflenen tüm işlevleri doğru bir şekilde yerine getirdiği, hedeflenenin dışında yazılımın içerisinde fazladan kod parçacıklarının olmadığı ve hedeflenen işlevlerin uygun bir yapıda test edildiği doğrulanarak kayıt altına alınmış olur. Ayrıca emniyet-kritik sistemler geliştirilirken yukarıda değinilen yazılım doğrulama faaliyetlerinin yanında sistem emniyeti çalışmaları yapılır. 3.1 Sistem Emniyeti Çalışmaları Emniyet kritik sistemler geliştirilirken sistem emniyeti ile ilgili çalışmalar projenin tasarım aşamasından itibaren başlar ve projenin tüm hayat döngüsü boyunca emniyet çalışmaları diğer süreçlere paralel olarak devam eder. Emniyet-kritik sistem geliştirilirken yapılan olası hatalar sistemde kusurlar oluşmasına neden olur, bu kusurlar sistemin başarısızlığa uğramasına neden olabilir. Beklenmedik davranışlara neden olan bu başarısızlıklar tehlikeli durumlara neden olur. Sonuçta tehlikeli durumlar da kazalara yol açabilir. Bu nedenle emniyet-kritik sistemler geliştirilirken doğrulama ve geçerleme faaliyetlerine ek olarak fonksiyonel tehlike analizi, hata modları ve etkileri analizi, hata ağacı analizi, olay ağacı analizi, neden-sonuç analizi gibi çeşitli analiz teknikleri de kullanılır. Sistem emniyeti, geliştirilen sistemde hiçbir hatanın olmaması veya olası hataların etkilerinin en aza indirilerek insan, mal kaybı ve çevresel zararlara neden olmayacak şekilde sistemin geliştirilmesini sağlamaktır. Sistemin müşteriye tesliminden önce gerekli emniyeti sağlamak için gerçekleştirilecek bazı etkinlikler şunlardır: Fonksiyonel Tehlike Analizi Hata Modları ve Etkileri Analizi (FMEA) Hata Modları ve Etkileri Kritiklik Analizi (FMECA) Hata Ağacı Analizi Sistem Emniyet Değerlendirmesi
Emniyet çalışmaları kapsamında öncelikle sistem fonksiyonları belirlenir. Bu fonksiyonlara ilişkin potansiyel tehlikeler ve bunlara neden olabilecek olası hatalar ve bunların etkileri fonksiyonel tehlike analizi ve FMEA ile tespit edilip, hatalar türlerine göre sınıflandırılır. Hatalar ayrıca emniyet seviyelerine göre de sınıflandırılır. Bu hataların olma olasılıkları hata ağacı analizleri ile hesaplanarak ilgili tablolara kaydedilir. Bu hatalardan Tablo-1 veya Tablo-2 de örnek olarak gösterilen emniyet sınıfı tablolarında belirtilen emniyet hedeflerini sağlayamayanları tespit edilerek tehlike analizi tablolarına eklenir. Bu analizler sonunda, sistem emniyeti değerlendirme raporu hazırlanır. Raporda yer alan emniyet hedefini sağlayamayan hataların önlenmesi için gerekli düzeltici eylemlerin gerçekleştirilmesi Düzeltici eylemler yapılırken gerektiğinde tasarım evresine geri dönülerek tasarım değişikliğiyle, istenen emniyet hedefi Böylece emniyet kritik yazılımların kullanımı sırasında olası tehlikelerin ortaya çıkma olasılığı sıfırlanamasa bile kabul edilebilir düzeye indirilmesi amaçlanır. Bununla beraber emniyet hedefinin sağlanamadığı durumlarda, mutlaka önceden tanımlanmış prosedürler, ikaz ışıkları ve sinyaller gibi uyarıcılar kullanılarak gerekli önlemler alınır. Geliştirilen emniyet-kritik sisteme göre analizler sırasında kullanılacak emniyet seviyeleri farklılık gösterir. Örnek olarak DO178B ye göre havacılık alanındaki emniyet-kritik yazılımlar için kullanılan emniyet seviyeleri şu şekildedir[8]: Tablo-1 Emniyet Seviyeleri (örnek) Seviye Emniyet Sınıfı Emniyet Hedefi Seviye A Ölümcül <10-9 (Catastrophic) Seviye B Kritik (Hazardous) <10-7 Seviye C Önemli (Major) <10-5 Seviye D Az Önemli (Minor) >10-5 Seviye E Etkisiz (No effect) - Nükleer enerji alanında kullanılan emniyet seviyeleri ise IEC 61226 standardına göre şu şekildedir: Tablo-2 Emniyet Seviyeleri (örnek) Seviye Açıklama Emniyet Hedefi Seviye A Can ve mal kaybı ile <10-8 çevresel hasara yol açabilecek nükleer kaza Seviye B A seviyesi kazaya <10-7 neden olabilecek kaza Seviye C Nükleer kaza olmayıp, <10-5 yardımcı sistemlerde meydana gelebilecek kaza 4. Sonuç Sonuç olarak, günümüzün gelişen Türkiye sinin yazılım sektörü şu an olmasa da yakın gelecekte yoğun bir şekilde kara/hava/deniz platformlarında kullanılan silah sistemlerinde, ulaşım araçları ve otomotiv sektöründeki sistem kontrol ve yönetiminde, kimyasal fabrika otomasyonlarında, biyomedikal cihazlarda, hatta nükleer santral kontrol ve yönetiminde ve uzay araçlarında emniyet-kritik yazılımlar geliştirmeye, artan bir hızla devam edecektir. Bu yazılımlar doğası gereği yüksek risk taşımaktadırlar. Bu nedenle emniyet-kritik yazılımların doğrulanma süreci diğer yazılımların doğrulanma sürecinden farklılık göstermelidir. Bu çalışma kapsamında insan, ekipman ve çevre açısından büyük önem taşıyan emniyet-kritik yazılımların doğrulama sürecinde üzerinde önemle durulması gereken noktalara ve sistem emniyeti çalışmalarına değinilmiştir 5. Kaynaklar [1] Sarıdoğan, M., E., Mühendisliği, Papatya yay., 2008 [2] Anderson, C., Exploring the software Verification and Validation Process with Focus on Efficient Fault Detection, Licentiate Thesis.Lund Institute of Technology, 2003 [3] Amey, P., Chapman,R., Static Verification and Extreme Programming, ACM SIGAda, 2003 [4] Bormann,J.,Fedeli,A.,Frank,R.Winkelmann,K., Combined Static and Dynamic Verification, Research Report, FP6-IST-507219, Version 2- Public Version, 31 March 2005 [5] IEEE Standard 1028, Software Engineering Standard Committee of The IEEE Computer Society, IEEE Standard 1028. IEEE Standard for Software review, Institute of Electrical and Electronics Engineers Inc., New York, 1998 [6] Richard, L.K., Testing Requirements, http://www.projectmangler.com/content/regular/art 20050516.htm, 2005 [7] Widera, M., Why Testing Matters in Functional Programming, 7th Symposium on Trends in Functional Programming, University of Nottingham, TFP 2006 [8] RTCA DO-178B Software Considerations in Airbone Systems and Equipment Certification, RTCA, 1992