Birds Project
Introduction to DO-178B
(or DO-254)
Bird Man, a painting by artist Lynn Rothan

A Simple Phrase

This is a brief introduction to certification of aviation software.  It is intended for software developers who would like to produce aviation software but who have no idea how to get started.  What you will learn is that you probably don't want to do it.  Experienced aviation developers will learn nothing new, but I'd welcome hearing if anything I'm saying is wrong.

The difference between creating aviation software and other software can be summarized in one simple phrase:  "RTCA DO-178B".  If you are interested instead in developing hardware, then you will be interested instead in RTCA DO-254.

What is RTCA DO-178B?   "RTCA" is the Radio Technical Commission for Aeronautics, Inc. ( www.rtca.org).  It plays an important role in defining guidelines for various aviation practices.  It is not a government agency, but many of the guidelines it produces are essentially accepted as standards by the FAA.  This is the case for document "DO-178B", which defines the guidelines for development of aviation software.  FAA Advisory Circular AC20-115B establishes DO-178B as the accepted means of certifying all new aviation software.  The same situation applies in Europe, apparently, where DO-178B is known as ED-12B.  (Refer to av-info.faa.gov for the text of AC20-115B and many other related items.)

If you want to develop aviation software, you'll have to have a copy of DO-178B.  It's not free.  The only way to get one legally is to buy one from the RTCA.

Barrier to Entry (or, The Bar is High)

If you are personally primarily interested in coding software, and you purchase DO-178B and attempt to read it, you won't enjoy yourself.

Why not?  What DO-178B attempts to do, and probably succeeds in doing, is to force you to consider and to precisely specify many things about your development effort that have little to do with coding, and much to do with project management and with software engineering.  This is a good thing in theory, and perhaps in practice, unless you are called upon personally to deal with it.

As a newcomer, part of the problem with DO-178B is the immense amount of detail involved in it.  Besides, DO-178B is not organized in a such a way as to allow you easily extract this detail.  You need to know how to read it.

Last and First Things (in a Software Sense)

Actually, there are a few non-DO-178B things you need to know before beginning software development. 

Last Things:  FAA Approval

At the end of the project you're going to want to achieve FAA approval.  Approval relates not just to the software used in your project, of course, but to your project as a whole.  I do not understand---and cannot give you advice on---the many other aspects of your project that this encompasses.  Some of these aspects are environmental qualification (DO-160D) and hardware qualification (DO-254).

First Things:  FAA Project

You won't be able to get FAA approval---or indeed, the time of day---unless an FAA project has been opened, and you are doing your work under the project number which has been assigned to you.  So getting an FAA project number is usually the first thing to be done in a project.

Working Without an FAA Project?

In the short term, you can work on your own, without having an open FAA project.  This involves basically doing all of your development work without any FAA interaction or advice, and to hope that your work conforms to FAA expectations.  Eventually, however, you will find it necessary to obtain that approval, because without approval you're going to have great difficulty installing your product in aircraft.  At that point, you may embarassingly find that your some or all of your work needs to be redone. 

But for a Level E project (see below), you're very likely to get away with this.  For a Level D project, you may be able to get away with it.  For Level C and above, you'd probably be foolish to try it.

Opening an FAA Project

Sadly, not just anyone can open an FAA project.  You can only open an FAA project if you are attempting to obtain a Type Certificate (TC), a Supplemental Type Certificate (STC), or are creating a device that falls under an existing Technical Service Order (TSO).  (I suppose it may be possible somehow to open a project for creating a new TSO, but if so I don't claim to know anything about it.)

A TC is something that applies to an entire aircraft.  For example, the Cessna CitationJet has a TC, and most of the equipment installed on that aircraft as delivered from the factory are included in that TC.  An STC is like an addendum to a TC.  For example, if you have designed a piece of equipment that you want to install on Cessna CitationJets, you would obtain an STC allowing you to do so.  To install the same equipment on another type of aircraft (or rather, supplementing a different TC), you need to obtain a second STC.  Finally, a TSO is like a general-purpose STC, allowing equipment falling under that TSO to be installed on a broad class of aircraft without obtaining STCs for each aircraft type.

As you may expect, the FAA project associated with a TC is opened by the manufacturer of the aircraft, and not by anyone who would benefit from reading my little web page. 

As far as an STC is concerned, the certification not only relates to a specific type of aircraft, but must actually be performed on a specific aircraft of that type.  In other words, before performing your software development as part of a project that involves getting an STC, you must have such an aircraft at your disposal.  This might involve negotiating a deal with a company that owns an aircraft of the necessary type and is eager to install your product on it.  Alternately, you may need to work with the aircraft manufacturer that holds the TC on that aircraft type, it thus it may be the aircraft manufacturer who opens the FAA project and receives the STC.

Seemingly, the simplest method of certifying the product is to do it under an existing TSO.  Of course, that is not possible if your product is highly innovative, because then it will be the first of its kind and there won't be any applicable TSO.  In the future, though, it appears as though some rather generic TSOs may come into existence, and that these would apply to broad classes of products that pose no safety hazards.

System Safety Assessment (SSA)

Software criticality Levels (see below) are typically determined by means of an analysis called a System Safety Assessment.  This assessment is really the responsibility of the installer of the product, since the criticality level can only be judged in the context of the overall system.  Of course, if the FAA project aims at getting an aircraft TC, the aircraft manufacturer would perform this analysis and simply inform you, the sub-system manufacturer, of the necessary software Level of your sub-system.  In the case of an STC, the STC holder probably prepares the analysis.  I admit to ignorance as to what happens in the case of a TSO:  perhaps the TSO itself specifies the Level.  In other cases, you're really forced to guess what Level will be found necessary by the eventual installer.

How to Read DO-178B

DO-178B has almost nothing to do with coding.  Its proponents state that DO-178B is primarily about development processes and their objectives.   In a large corporation having an SQA department and other specialists to deal with DO-178B issues, the proponents are probably correct.

For small organizations, though, the software developers themselves often must implement DO-178B.  In this case, the practical consequence is often to pervert the spirit of DO-178B by expediently reducing its implementation to a question of deliverables.  The "deliverables" are mainly documents, and successful certification depends on these documents saying all the right things. Inexpensive certification depends on the documents not only saying the right things, but saying them in the right way, in the right order.

Here's how to read DO-178B to see what your deliverables should look like:

PSAC Plan for Software Aspects of Certification Document
SDP Software Development Plan Document
SVP Software Verification Plan Document
SCMP Software Configuration Management Plan Document
SQAP Software Quality Assurance Plan Document
SRS Software Requirements Standards Document
SDS Software Design Standards Document
SCS Software Code Standards Document
SRD Software Requirements Data Document
SDD Software Design Description Document

Source Code

Executable Object Code
SVCP Software Verification Cases and Procedures Document
SVR Software Verification Results Records
SECI Software Life Cycle Environment Configuration Index Document
SCI Software Configuration Index Document

Problem Reports Records

Software Configuration Management Records Records

Software Quality Assurance Records Records
SAS Software Accomplishment Summary Document

Installability, Manufacturability, Service

So, if you create all of the DO-178B documents mentioned above and provide the paper trail they imply, will you be able to install your product in an aircraft?  Well, yes---if the end result was that the TC or STC was granted, or if your product was added to the TSO. 

Actually, your product may be installable even if this isn't so.  Products can be installed even if they don't come under a TC, STC, or TSO by means of a "field approval", Form 337.  For a Form 337 installation, an ad hoc system safety assessment and inspection of the DO-178B documents is (in theory) performed, and a one-time signoff is given for installation in a single aircraft.  However, I'm told that it is becoming much rarer to perform Form 337 installations, presumably because of the ease of abuse.

A somewhat trickier question is whether you will be able to manufacture your product.  The authority to manufacture the product comes in the form of a Part Manufacture Approval (PMA).  You are not actually able to obtain a PMA for your product until the product is installable---i.e., until it is under a TC, STC, or TSO with FAA approval.  But obtaining the PMA is not an automatic result of FAA approval for the TC, STC, or TSO, and must be done separately.  Products without PMA, I believe, can only be installed under Form 337, with the attendant difficulties mentioned above.

Finally, will you be allowed to service your product?  It turns out that just being the manufacturer of a product does not authorize you to repair it.  For that, you must become an FAA-authorized repair station, and you are only authorized to repair certain products rather than being given blanket approval to repair all of the products you manufacture.  In other words, for each new product you create, you must separately apply to the FAA to have it added to your repair station.

Is That Everything You Need to Know About Certification?

Well, if you're contemplating creating Reusable Software Components (RSC), you want to acquire and absorb FAA notice 8110.97.  (As I write this on 03/01/02, N8110.97 has just been made official -- yesterday, I think -- and so is not yet available on av-info.faa.gov.  Soon, though, I'm sure.)

You might want to read The FAA and Industry Guide to Product Certification.  This publication is self-admittedly "focused on large and/or complex [development] programs," and as far as I can see is unlikely to have much (or any) relevance to the relatively small development efforts likely to be undertaken by those using Birds Project materials.

In other words, if you are ignorant enough to be seeking illumination from the Birds Project, you shouldn't be undertaking airborne projects that are large enough or critical enough to interest certification authorities.  Sticking to levels C-E might be good advice.   Don't attempt to receive Type Certificates on the basis of the material you've read here.  :-)

Also, you will usually have to hire a Software DER (Designated Engineering Representative) to examine your documentation.  A DER is a specialist  designated by the FAA as having authority to sign off.  The signoff is via FAA form 8110.  Once the DER has signed off, the product really is essentially "certified" for the holder of that 8110 form.  The next time you update the software, you get to go through the same thing all over again.

Knowing that a DER may eventually examine your documentation, it may be a good idea to get a DER involved at an early stage in your development.  One reason is that the DER may insist on witnessing some things, such as portions of your software testing.  Another reason is that the DER may not like your documentation (or processes) and insist on changes to them before signoff.

This page was last modified by Ron Burkey on 2006-07-02. Contact the Birds Project.