Beginning

DO-178B Beginning

Everything was a dust and gas cloud.. Okey, not that long ago, lets skip appearing of DO-178A in 1985 and talk about B version that appeared with improving A. “Software Considerations in Airborne Systems and Equipment Certification” titled document published by DO-178B RTCA. As the title suggests, pursuit is that softwares fulfill the requirements of convenience to flight.  How to fulfill these requirements is completely depend on developer. – We shouldn’t feel that relax because fulfilling DO-178B requirements will require substantially sensibility ($).

The requirements of convenience to flight are about how system safety is affected in case of  failure in software running in aircraft. For people who ask how much it can be affected , it runs without any software (it happened to me in a seminar); we can explain with a few examples.

Example 1:  Failure in video player’s software in entertainment system of airplane.

Possible Consequence: Passengers who are unhappy, maybe angry but still can breathe.

Example 2:  Failure in software controlling the airplane during instrumented landing in case of 0 visibility ( fog, etc.).

Possible Consequence: Burned passengers who stuck in the debris or fly out of plane without knowing anything.

These two examples I gave are proof that this job is serious and various softwares have responsible for different jobs. Safety of system is affected differently in case of  failure in entertainment and automatically landing systems’ software in plane. For this reason, two different software systems should be developed and tested according to two different safety levels.

In order to explain these different safety critical situations, DO-178B defined software systems in 5 levels.

Level A: Softwares causing fatal (Catastrophic) outcomes in case of failure.

Level B: Softwares causing dangerous/risky (Hazardous) outcomes in case of  failure .

Level C: Softwares causing critical (Major) outcomes in case of failure

Level D: Sofwares causing less risky (Minor) outcomes in case of  failure .

Level E: Software not causing any risky outcomes in case of  failure .

When system safety assessments and impact analyzes are completed, levels i mentioned above can be defined into software. We will explain how to make system safety assessment and impact analyzes in another writing. What should be paid attention is that this period is a critical period when serious analyzes and assessments are made and levels are defined into software. Unfortunately,  in case of especially contractor-subcontractor situations, there are examples where breakdowns and levels are stated without caring, and this cause safety languor in aircrafts in addition to loss of money, labor, and time.

If we consider that objective number is 66 in Level A software, 65 in Level B software, and 57 in Level C software, improving team of a software wantonly stated high level will have to complete more targets, and each target that must be completed costs thousands of dollars. If they don’t do so, a software leveled less than normal will cause risky situations, and it may cause loss of life and property  because of not controlled possibility.

Does improving software with guidance of DO-178B make softwares that we improved safe? Maybe.. It is certain that DO-178B set serious targets to prevent errors, but it doesn’t guarantee to annihilate them. Interesting aspect of this , researches show that most of plane accidents is caused from that systems run in a wrong way, and the other systems depend on them, not they don’t run. For example, Turkish Airlines TK-1951 flight numbered plane to Netherlands crashed while landing , and 135 individual lost their lives. When accident report is examined, it can be seen that radar altimeter of plane measured height of plane wrongly, automatic pilot broke speed and engine power by depending on this data, and plane crashed.

DO-178B does not guarantee safe software but it enable to establish possible breakdowns with methodologies that it recommends. How? Control.. Control again.. And control again.. And control again and again..

Pre-defined targets lead to developers in order not to fall into traps in nature of improving. Processes below that are targets form the backbone of DO-178B.

- Planning Process

- Development Process

-Requirement Process

-Design Process

-Codding  Integration Process

-Test and Verification Process

-Configuration Process

-Quality Assurance Process

These processes that are known by many developers are adressed with some differences in D0-178B. For CMMI Level 3 firm, carrying out DO-178B processes cost normally extra 35-40 %. Reason of that I said “normally” is a fact that this number is between 75% and 150%,which is much more than average of industry. In another writing, in the scope of DO-178B , i will try to explain how to adress each processes, how are they adressed generally, and semtinizing mistakes and consequences step by step.