Aerospace (DO-178B) Software

Systems and Hardware Standards

This information might be trivial for most of you, but I thought it is worth putting them together somewhere.

Even if it is just for my reference.

But first a small preamble:

DO-178B records that “At the time of publication of this document [meaning DO-178B], guidelines for the system life cycle processes were under development by an international committee.”

So the natural question is if the document for guidelines for system life cycle processes is now available; after all, DO-178B was published almost 17 years ago.

The next natural question should be what about certification of airborne hardware.

So here is the list of the standards that apply to airborne firmware - all under one roof:

ARP 4754: Certification Considerations for Highly-Integrated or Complex Aircraft Systems.

DO-254: Design Assurance Guidance for Airborne Electronic Hardware

DO-178B: Software Considerations in Airborne Systems and Equipment Certification

Now for a piece of good news:

ARP4754 is available for free down load here.

Similarly DO-254 is available for a free download here

I have no way of knowing if these are legal downloads. Or if the information contained in these downloaded documents are correct or not. I assume these are.

Estimating Verification Effort

Continuing on estimation techniques ...

Have you estimated the time and effort it will require to complete verification for your project? Sure? 

Now go ahead and double the effort. Most of the DO-178B projects fail as the effort of verification and its impact is almost always underestimated. 

All of us know that no software development is a classic waterfall method but we estimate as if it is. As a result, we fail to take into account the feedback loops that verification generates. That's where the problem lies.

As a rule of thumb I recommend you immediately double your allocated time budget for verification effort. You can start refining from there.

A Perfect Estimation Technique

This is an extract from a wonderful book, Think Twice, written by Michael J. Mauboussin. I would like to believe that finally we have a perfect technique for estimating projects.

The extract ...

People find it hard to estimate how long a job will take and how much it will cost. When they are wrong they usually underestimate the time and expense. Psychologists call it the planning fallacy. ...

[But here is] an interesting twist. While people are notoriously poor at guessing when they'll finish their own projects, they're pretty good at guessing about other people. In fact, the planning fallacy embodies a broader principle. When people are forced to look at similar situations and see the frequency of success, they tend to predict more accurately. If you want to know how something is going to turn out for you, look at how it turn out for others in the same situation. Daniel Gilbert, a psychologist at Harvard University, ponders why people don't rely more on the outside view. ... The reason is most people think of themselves as different, and better, than those around them.

So, there you are. The best method of estimating any project would be:

a) Shed your ego.

b) Rely on historical data available in your company

c) Or if historical data is not available, simply ask others how much time they think you will take to complete a task.

  

Expanding domain of DO-178B

Now it is news like this that makes me real happy.

No I am not referring to the product that is being discussed in the article. My person preference is that of a scheduler rather than a RTOS but in order to harness the power of the modern micro-processors/controllers and the consequent growing demands being placed on the system requirements will make the use of RTOS inevitable, bar the most simple airborne system. Why do I prefer a scheduler to an RTOS? Now that is the subject matter of another post.I promise.

Right now, I am referring to a specific extract in the article, "The FAA requires that all operational software in an aircraft that flies in US airspace be developed and certified in conformance with DO-178B, a safety-critical software standard used widely in other industries as well."

Two things:

1) I am assuming "an aircraft that flies in US airspace" includes general aviation; not just large commercial aircrafts ... though I would hope that included military aircrafts too.

2) I have not heard that DO-178B is widely used in other industries as well. I would really love to know which?

Any one?

Validation is not a software process

"Doing things right" versus "Are we doing the right thing"; Verification versus Validation ... easy to get lost, right?

DO-178B makes life easy.

How? Check out section 6.0 of DO-178B. What does it say? Verification Processes. Not Verification and Validation Processes.

So, whatever you do to satisfy Section 6.0 is verification. Reviews, Analysis, Low-Level testing, High-Level Testing, Hardware-Software Integration, etc. are all verification processes. Within the domain of DO-178B, you never ever validate the software.

Validation belongs to the Systems Domain.