DO-178B

Not 1: Uçuşa Elverişlilik Açısından Yazılım Sertifikasyonu Konferansı başlıklı yazıyı okumakta fayda var.

Not 2: DO1-78B RTCA ve EUROCAE ile ortak geliştirilmesine rağmen, Amerika'da DO-178B, Avrupa'da ED-12B ismi kullanılıyor. Her iki kurum birbirlerinin verdikleri sertifikaları kabul ediyorlar.

Not 3: DO-178B yazılım geliştirmek için var. Donanım geliştirmek için DO-254 Design Assurance Guidance for Airborne Electronic Hardware kullanılıyor. Avrupa'da DO-254 yerine ED-80 ismi kullanılıyor.

Dolayısıyla bazı yazılarda DO-178C/ED-12C ve DO-254/ED80 şeklinde kullanımlar görülebilir.

DO-254 karmaşık (complex) olarak nitelenen donanımlarda kullanılır. Karmaşık tabiri ile ne kast edildiğini tam olarak bilmiyorum.

Not 4 : http://www.do178blog.com ve http://www.do178site.com faydalı siteler gibi görünüyorlar.

Not 5:  Demiryolları için CENELEC EN 50128 kullanılıyor. Bu standart DO - 178B gibi yazılımın nasıl geliştirileceğini anlatıyor. Tren'in nasıl çalışacağı ise European Rail Traffic Management System (ERTMS) standardında anlatılıyor.

DO-178C
Konuyu DO-178C başlıklı yazıya taşıdım.

DO-178B nedir ?
DO-178B sivil havacılık sektöründe hava araçlarında kullanılan emniyet kritik yazılımın geliştirilmesi esnasında kullanılan bir yazılım geliştirme sürecidir. Süreç kısaca DO-178B olarak bilinir uzun ismi ise "DO-178B Software Considerations in Airborne Systems and Equipment Certification"

Bu sürecin  uluslararası ortak hava sahasını kullanan sivil uçakların yazılım geliştirilmesinde kullanılması kanunen zorunlu. Askeri uçaklar ortak sivil hava sahasını kullanmadığı için yazılımları DO-178B ile geliştirilmek zorunda değil. Ancak bir çok askeri aviyonik yazılımı üreten firma benzer süreçleri takip ediyor.

Sovyetler Birliği sivil havacılıkta D0-178B'yi uygulamıyordu, şimdiki Rusya da uygulamıyor. Bu yüzden Rus uçakları sivil uluslararası havayollarına örneğin Avrupa hava sahasına özel izin ile girebiliyorlar. Fakat kendi ülkelerinde diledikleri gibi uçabiliyorlar.

Askeri Havacılık

Askeri havacılıkta ABD'de uçakların uçuşa elverişlilik (airworthiness) sertifikasyonunu FAA değil, Naval Air System Command for USN yapıyor. Avustralya'da ise ADF yapıyor ancak sertifikasyon için DO-178 kullanıyor.  Özetle askeri alanda işler sivil uluslararası havacılığa göre biraz daha karışık. FAA'in askeri uçaklarda hükmünün olmadığı şöyle ifade edilmiş.

No FAA issued Type Certificate or Airworthiness Certificate is required for aircraft owned and operated under military registration- FAA is not the A/W authority for these Aircraft.

Askeri uçaklar FAA sertifikasyonuna tabi olmasa da halen uçuşa elverişli olması gerekiyor. Air Force Policy Directive dokümanı şu cümle ile başlıyor.

The Air Force (AF) is responsible for assuring the airworthiness of the aircraft which it operates.

Bir başka açıklama şöyle

... the military isn't actually under the jurisdiction of the FAA. So, even if the FAA still required two pilots for all aircraft over a certain weight, that wouldn't apply to a military aircraft.

Bu yüzden FAA ve askeri uçuşa elverişlilik sertifikaları bazı noktalarda örtüşürler. Mesela FAA bazı tip uçaklarda karakutu olmasını ister. Bu kural askeri uçakları bağlamaz, ancak bir çok askeri uçakta da karakutu bulunur.

Bazı terimlerin anlamı şöyle:

Airworthiness— The verified and documented capability of an air system configuration to
safely attain, sustain, and terminate flight in accordance with approved usage and limits

Emniyet kritik yazılım geliştirilmesinde kullanılan tek standart DO-178 değil. Örneğin NASA NASA-STD-8739.8 ile kendi standardını uyguluyor. MIL-STD-498 artı MIL-STD-882D "Standard Practice for System Safety" ile yazılım da geliştiriliyor. Fakat bu ürünler sivil havacılıkta kullanılmıyor.

DO-178B'yi nereden okuyabilirim?
DO-178B belgesi açık kaynak değil. www.rtca.org sitesinden satın alınabilir.

Tarihçesi Nasıldır?
Belgeleri yayınlayan kurum RTCA (Radio Technical Commission for Aeronautics). 

RTCA Kimdir?

Belgenin başındaki açıklama şöyle. Yani RTCA resmi bir kuruluş değil.

RTCA, Incorporated is a not-for-profit organization formed to advance the art and science of aviation and aviation electronic systems for the benefit of the public. The organization functions as a Federal Advisory Committee and develops consensus-based recommendations on contemporary aviation issues..

...

Since the RTCA is not an official agency of the United States Government, its recommendations many not be regarded as statements of official government policy unless so enunciated by the U.S. government organization or agency having statutory jurisdiction over any matters to which recommendations relate.

Süreci denetleyen ve yürüten kurum ise 1958 yılında kurulan FAA. Belgenin ismindeki DO Document kelimesinden geliyor. 178 sayısı ise yayınlandığı zamanki verilen numara. RTCA kar amacı gütmeyen (non-profit) bir kurum. Uzlaşmaya dayalı (consensus based) belge ve öneriler yayınlıyor.

DO-178
1982 yılında yayınlandı. Bu yıllarda uçaklarda yazılım kullanılmaya başlandığı için bu belgede genel yazılım geliştirme döngüsü anlatılıyor.  Örneğin gereksinim yazılmalı, doğrulama yapılmalı vs. gibi. Belgenin bu ilk sürümünde MIL STD 498'de olduğu gibi doldurulması gereken dokümanların içeriği bile vardı. Bu fikirden hızla vazgeçildi.

DO-178A 
1985 yılında yayınlandı. Bu belge ile Konfigürasyon Yönetimi sürece dahil ediliyor. Bir yazılım sürecinin olması ürünün emniyetli olduğu güvencesini vermez. Bu belgede ilk defa havacılık yazılımında kritiklik seviyeleri 1,2,3,4,5 vs. olarak belirtilmiş ve süreç seviyeye göre düzenlenmiş. Daha sonra bu belirtimden vazgeçildi.

DO-178B 
1992 yılında yayınlandı. Bu belgede doğrulama ve analize yönelik eklemeler var. Bu belge ile yazılımın kritiklik seviyeleri A,B,C,D,E olarak belirlendi. Bu belge üretilirken endüstrinin bir çok dalından uzmanlar bir araya gelerek çalışmış ve uzlaşmaya dayalı (consensus based) bir yöntem izleyerek yazıya dökülmüş.

Belgede Guideline (yönerge) ve Guidance (rehber) kelimeleri bolca kullanılıyor. Gerekçe olarak ta yazılımı geliştiren ekibin Objective'leri yerine getirdiği müddetçe istediği yazılım modelini (waterfall, spiral vs.)  kullanabilmesi belirtilmiş.

Ben bu yazıda bu kelimeler yerine DO-178B için "standart" kelimesini kullanmayı tercih ettim.

DO-178C 
2011 yılında yayınlandı. Nesneye Yönelik geliştirme için eklemeler var. DO-178C belgesinde Guideline ve Guidance kelimeleri mümkün olduğunca az kullanılmış.

Seviyeler Nelerdir?
DO 178B/C Seviyeleri yazısına taşıdım

Maliyet Nasıl Etkilenir?
Emniyet seviyesi arttıkça maliyetler de artıyor. Aşağıdaki şekilde durum görülebilir.

Buradaki bir değerlendirmede, askeri havacılıkta emniyet seviyesinin sivil havacılığa göre daha önemsiz olduğuna dair bir şekle denk geldim. Ancak ister sivil ister askeri amaçlı olsun, DO-178B yazılım açısından hep aynı kuralları işletir. Kaza olasılığının değişmesi, yazılımdan çok sistem gereksinim ve tasarımından kaynaklanıyor olmalı diye düşünüyorum.

DER Nedir?
DER (Designated Engineering Representative) FAA adına DO-178B/C ile geliştirilen yazılımı denetleyen ve sertifiye eden kişidir. DER sertifikasyonda attığı imza ile kişisel sorumluluk (liability) alır. Bir kazada yazılım hatası bulunursa ve DER'ın işini yapmadığı ortaya çıkarsa DER cezalandırılır. Bu yüzden DER'lar son derece titizdirler her türlü süreç adımı için delil (evidence) talep ederler.

SOI nedir ?
Stage of Involvement (SOI) aşamasında DER denetlemede bulunur. SOI bir kaç sefer yapılabilir. Projenin aşamasına göre planlara, gereksinimlere, tasarıma, koda ve teste bakılır. Bu belgeler arasında izlenebilirlik olup olmadığı örnekleme yöntemiyle denetlenir. Eğer sistematik bir hata varsa, bulunmaya çalışılır. 4 aşamadan oluşur.

SOI'lerde kontrol listeleri (check list) kullanılır.

SOI-1 Planning Review
SOI 1 - Software Planning Review Checklist yazısına bakabilirsiniz. 

SOI-2 Development Review
SOI 2 - Development Review yazısına bakabilirsiniz. 

SOI-3 Verification Review
SOI-3 Verification Review yazısına bakabilirsiniz. 

SOI-4 Final Review
Amacı yaz

Seviye D projelerde SOI yapılmaz.

Üretilen Planlar
DO-178B ile 5 tane ana plan kullanılıyor.
PSAC : yazısına taşıdım
QA : Quality Assurance Plan
CM : Configuration Management Plan
SWDP : Software Development Plan
SWVP : Software Verification Plan

Diğer Belgeler
Bu planların yanında bir çok belge de üretiliyor. Bunlardan önemli olanları requirements, design ve coding standartları.

Software Requirements Standard:
Gereksinimin nasıl yazılacağını belirtir.

Software Requirements Checklist:
Gereksinimin gözden geçirme kontrol listesi.

Software Design Standard:
Alt Seviye Gereksinimler (Low Level Requirements) D0-178B sürecinde tasarım olarak kabul edilir. Dolayısıyla tasarım denilince ilk akla gelen UML diyagramları olmamalıdır.

Coding Standard :
Kapsama analizinde işi zorlaştıracak hususlar coding standard (yazılım kodlama standardı) ile kullanılmayacak şeklinde belirtilir. Ayrıca kullanılmayacak API'ler de belirtirlir. Açıklaması şöyle

While developing it is common to use a limited subset of assemblies (APIs) in order to prevent developers from preforming dangerous operations. This type of restriction can also ensure that developers utilize the APIs correctly, such as cleaning up objects as a requirement.

İlaveten static analizin nasıl yapılacağı belirtilir.

Code Review Checklist :
Kod gözden geçirmesi kontrol listesi. Kod gözden geçirmesi otomatik mi olacak belirtilir.

Software Environment Configuration Index :
Yazılımı geliştirirken kullanılan tüm araçların isim ve sürümlerinin olduğu liste. Yazılımı tekrar geliştirmek istersek bu listedeki araçları kurarak tekrar başlayabiliriz.

Software Accomplishments Summary :
Yapılan işlerin özeti. Eğer varsa, sapmaların izah edildiği yer.

DO178B Standardı Nasıl Okunur
Tablolarda bulunan boş yuvarlaklar independent review gerektirmez. Dolu olanlar gerektirir.
CC1 ile işaretlenenler için değişiklik talep kaydı gerekir. CC2 olanlar için belgenin son hali yeterlidir. Açıklaması şöyle

Configuration Management in DO-178C

Configuration items that you track through configuration management fall into two Control Categories, which determine the level of control that must be applied to items in that category.

DO-178C specifies which items must be treated as Control Category 1 or 2 items based on the project’s Design Assurance Level.

Items treated as Control Category 1 (CC1) must undergo full problem reporting processes, and formal change review and release processes.

Configuration items classified as Control Category 2 (CC2) items do not need to undergo these more formal processes, but items in this category must still comply with configuration identification and traceability needs, be protected against unauthorized changes, and meet applicable data retention requirements.

Kodlama Önerileri 
Konuyu DO-178B Object Oriented Technology in Aviation başlıklı yazıya taşıdım.

Sertifikasyon
Sertifikasyon tanım olarak kişi, organizasyon, ürün, parça ya da cihazların düzenlemelere  uygunluğunun tanınması / belgelendirilmesi durumudur.

Üretilen yazılımı sertifikasyona tabi tutulması ile ilgili olarak Uçuşa Elverişlilik Açısından Yazılım Sertifikasyonu Konferansı başlıklı yazı da okumaya değer bir yazı.

Grandfathering Yöntemi
FAA eskiden üretilmiş ve sertiye edilmiş bir hava aracının yeni bir varyasyonu üretilince sadece değişen kısımları sertifiye ediyor. Örneğin 1972 yılında üretilen bir uçağın yeni bir varyasyonunda sadece motoru değişmiş olsun. Bu durumda sadece motor sertifiye ediliyor. Aracın geri kalan kısmının halen emniyetli olduğu kabul ediliyor. Bu yönteme "grandfathering" deniliyor. Yöntemin yanlış olduğuna, emniyeti değil üreticiyi koruduğuna dair eleştiriler var.

Örnek
Hatta bir kazada 1978 yılında sertiye edilmiş bir helikopterin, yeni modelinin halen daha acrylic cam kullanması yüzünden ölümcül kaza yapması çok eleştirildi. 1996 yılında acrylic cam kullanımının FAA tarafından yasaklanmasına rağmen, yeni olan bu helikopter "grandfather rules" yüzünden ana tasarım değişmediği için eski tip cam ile sertifiye edilebilmiş.

Örnek
Boeing 737'de "trim wheel" artık legacy kabul edilse bile tüm modellerde var. Sebebi ise yine grandfathering. Açıklaması şöyle

When an aircraft is certified with particular equipment, changing that can be difficult and may require the filing of a MAJOR REPAIR AND ALTERATION form. Its likely cheaper for Boeing to keep the trim wheels the way they are. The common 737 type certificate notes that the airframe was certified against (and must be rigged in accordance with) a particular set of Boeing drawing.

Sertifikasyonda Kullanılan Bazı Kelimeler
Certified
Belli bir hava aracı için sertifikasyonu olan yazılım

Certifiable
Sertifikasyona hazır yazılım. Daha önce başka bir platformda sertifiye edilmiş ve kullanılan yazılım, yeni bir platform için certifiable'dır. Yeni platform için bir kere daha sertifiye edilmesi gerekir.

Qualified
Geliştirmede kullanılan ancak uçakta uçmayan bir yazılım geliştirme aracını belirtir. Örneğin yer bakım yazılımı.

Compliant
FAA haricindeki bir başka oluşum tarafından sertifikalandırılan yazılımı nitelendirir. Bu yazılım uluslararası sivil hava sahasında uçamaz ancak ülkeler kendi dahilinde bulunan ve ortak sivil hava sahasını kullanmayan diğer hava araçlarını bu şekilde sertifiye edebilirler

DO-178B ve Sistem Gereksinimleri
Aşağıda bazı örnek sistem gereksinimleri var:

* The avionics system shall provide maintenance access to the system LAN.
* The avionics system primary flight display shall consist of the following
      - Airspeed indicator
      - Altitude indicator
      - Vertical speed indicator
        ....

Süreç

Süreç temel olarak şu safhalardan oluşuyor

Planning Process

Design Process

Verification Process

DO-178B ve Yazılım Geliştirme Faaliyeti(Software Development Activities)

Bu süreçte iki seviye faaliyet var. High Level Requirements geliştirilmesi ve Low Level Requirements geliştirilmesi . Aşağıda bir açıklama mevcut.

The software development processes are composed of

1. The Software requirements process, which usually produces the high level requirements (HLR)

2. The Software design process, which usually produces the low level requirements (LLr) and the software architecture

Şekilde sistem gereksinimlerinin, HLR ve LLR haline nasıl geldiği gösterilmiş.

HLR yazılırken doğal dil kullanılıyor. Aşağıda bazı örnek HLR gereksinimleri var:

* For each X, the X shall be imported from Y database
* When a BIT failure is detected, the LRU shall log the failure toZ
* The A software shall verify the CPU bus interface to the graphics chip is  operational and is showing a status of good.

DO-178B Software Design Process yazısına bakabilirsiniz

DO-178B ve Yazılım Doğrulama Faaliyet (Verification Process) 
Yazılım doğrulama faaliyeti şu ana başlıklar altında yapılıyor. Burada şu cümle önemli.

Who does the testing in DO-178C?

Many DO-178C objectives that involve testing require independence in testing at some DALs.

When this is required, the person (or group) implementing a particular item and the person (or group) verifying that item must be different.

Independence requirements are identified within DO-178C’s objective tables.

Higher DAL developments require independence on a larger number of objectives than lower DAL developments.

Test edilecek sistemler şöyle olabilir

Doğrulama Süreci Es Geçilemez
Bazen mülakatlarda adaya şöyle bir soru soruluyor. Soru direkt olarak havacılık ile ilgili değil ancak benzerlik içeriyor.

Just imagine you are working on some important simulation system and a client call you at 8 pm. He's kind of upset because your simulation tool doesn't work at his place. If it does not work tomorrow at 8 am he'll give up on your company and it will lose hundreds of millions. What do you do?

Süreçler es geçilemez. Açıklaması şöyle.

- There's urgency in time and money. This is to cloud your judgment.

- You're being asked to circumvent normal procedures for pushing changes. Especially for big clients, and doubly so for something as tightly regulated as aeronautics, this is a no-go. Just look at what's happening to Boeing right now if you're curious what happens in this industry when things aren't taken seriously and regulations are skirted.

Tool Qualification
Amaç yazılım geliştirmede kullanılan araçları doğrulamaktır. 3. parti araçların yeterliliği test edilir, test sonuçları yazılır.  Eğer araç kendi geliştirdiğimiz bir yazılımsa SRS, test ve test sonuçları yazılır.

Kendi geliştirdiğimi araç bağımsız bir şekilde doğrulanmalıdır. Örneğin simülatör geliştiriyorsak, simülatörü doğrulamak için simülatörün besleyeceği yazılımı kullanamayız. Bu tür bağımlılıklar DER tarafından hemen yakalanır.

Software Review
Üretilen her şeyin gözden geçirilmesi

Software Testing
Bu faaliyeti gerçekleştirirken iki önemli madde yapılmalı. İlki 

- Requirements Based Test Case Selection, diğeri ise 

- Test Coverage Analysis.

Requirements Based Test Case Selection:
Süreçte gerçekleştirilen yazılım testi faaliyetini diğer süreçlerden ayıran en önemli konu, tüm testlerin gereksinimlere bakılarak yazılması. Aşağıdaki cümle daha iyi açıklıyor.

DO-178B imposes that all test cases are requirements-based. Blind testing based on code, without clear relationship with the requirements is not valid.

Bu faaliyet çevik metodlarda kullanılan Test Driven Development'a (TDD) benziyor. TDD'de amaç her Feature için test yazmak. Featue gereksinim olarak düşünülebilir. İki yöntemin ayrıldıkları nokta TDD'nin kodu yazmadan önce testin yazılmasını istemesi. DO-178B'de test'ten Test Coverage Analysis çıkarıldığı için ve bu işlem maliyetli olduğundan kodun bitmiş olması gerekir.

Test Coverage Analysis :
Testler geliştirildikten sonra, target ortamda koşturulurlar ve test çıktılarına bakılarak analiz yapılır. DO-178B Level C ve üstü seviyelerde iki temel analiz yapılmasını şart koşmaktadır.

> 1. Gereksinim Kapsama Analizi : İngilizcesi Requirements based coverage analysis. Analiz sonucunda her yazılım gereksinimi için bir test olduğunu doğrulanmalıdır. Ayrıca testlerin normal ve sağlamlık (robustness) kriterleri göz önüne alınar yazıldığı gösterilmelidir. Bu analiz sonucunda bazı gereksinimler için daha fazla test yazılması gerektiği kanaatine varıldıysa, yeni testler geliştirilir.

2. Yapısal Kapsama Analizi : İngilizcesi Structural Coverage Analysis. Analiz sonucunda koşturulan testlerin hedeflenen sertifikasyon seviyesine göre kodu kapsandığını doğrular. Bu analiz sonucunda. testlerde yetersizlik varsa, yeni testler geliştirilir veya mevcutlar iyileştirilir. Yazılım gereksiniminde yetersizlik varsa - örneğin tek bir gereksinim varken çok daha fazla kod yazılmışsa - gereksinim iyileştirilir. Ölü kodlar (dead code) silinir. Deactivated kod - test edilen kofigürasyonda çalışması gerekmeyen kod - varsa, bu kodlar işaretlenir ve geliştirme ortamının doğru konfigürasyonda olduğu gösterilir.
Kuralların en sıkı olduğu seviye A seviyesidir. Bu seviyede derleyici tarafından üretilen makine koduna kadar izlenebilirlik ve analiz uygulanır. Does “DO-178B level A” prohibits optimizing compilers? sorusuna verilen cevaplarda da görülebildiği gibi derleyicinin kod optimizasyon yetenekleri de mümkün olduğunca kapatılır.

Yazılım Kapsama Analizi yani Structural Coverage Analysis (SCA)
Konuyu Structural Coverage Analysis başlıklı yazıya taşıdım.

Programlama Dili
Programla dili genellike C veya C++. Ancak hava aracına girmeyecek kodlar örneğin yardımcı araçlarda diğer diller - Python gibi -  kullanılabilir.

İşletim Sistemi
Emniyet kritik sistemlerde genellikle Green Hills firmasının Integrity, Wind River firmasının VxWorks, LynxOS işletim sistemleri kullanılır.

DO-178B ve Gerekircilik (Determinizm)
DO-178B ve Determinizm yazısına taşıdım.

DO-178B, Cihazlar ve Built-in Test (BIT)
Bir çok cihaz Built-in Test (BIT) yapılmasını destekliyor. BIT ile cihazın durumunu ve varsa hatalarını görebilmek mümkün. DO-178B projelerinde BIT 3 çeşide ayrılıyor.

PBIT (Power up BIT) : Cihaz ilk elektrik aldığından yapılan oldukça kapsamlı BIT. Cihazın güvenilir olduğunu söyleyebilmek için vazgeçilmez bir adımdır. Register, memory, interrupt vs. gibi şeyler test edilir.

IBIT (Initiated BIT) : Genellikle bir hata alınması sonucunda elle çalıştırılan BIT. Hatayı tespit etmeye yöneliktir. Yazılımın zamanlamasını (scheduling) etkilediği için pek tercih edilmez.

CBIT (Continuous BIT) : Belli aralıklarla çalıştırılan BIT. Sürekli tekrar ettiğinden dolayı zamanlamada biraz yer ayrılarak rahatlıkla yapılabilir.

DO-178B ve Entegrasyon Lab Ortamı
Yazılım hava aracına yüklenmeden önce Sistem Entegrasyon Labında (SEL) denenir. Burada dikkat edilmesi gereken nokta, tüm ortamın , kablolama  dahil , hava aracındaki ortam ile birebir aynı olması. Amaç yazılımı ve cihazları havadaki ortamdaymış gibi, yerde test etmek olmalı.

Software Corruption
Bu konunu DO-178B ile direkt bağlantısı yok. Sadece not almak istedim. Bir kaza incelemesinde geçen cümle şöyle

A number of potential trigger types were investigated, including software bugs, software corruption, hardware faults, electromagnetic interference and the secondary high-energy particles generated by cosmic rays.

 Burada geçen software corruption yazılımın algoritmasında olan hata değil, yazılımın depolandığı ortamda olan bozulma anlamına geliyor. Yani yazılımın bitlerinin bir şekilde değişmesi/bozulması