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:

Your first stop is section 2.2, where you determine the software level. The software level, which (section 2.2.2) is either A, B, C, D, or E, is based on an assessment of the consequences of a failure of the software (section 2.2.1) as "catastrophic", "hazardous/severe-major", "major", "minor", or "no effect". (See the notes on the System Safety Assessment, above.) The software level chosen determines how many deliverable documents you have to produce, and how much stuff has to be in those documents, along with a miscellaneous assortment of non-documentation-related activities you may have to perform. At level A, the amount of work will be enormous; at level E, it will be practically nil. In a theoretical sense, you have the option to choose almost any software level you like. The problem is that if you choose a level too low, nobody will be able to use your product for its intended purpose because an SSA will not justify it. In other words, if the user determines that he needs a certain gadget at level C, and you provide one but only at level D, he won't be able to use it. Therefore, your device will have the widest applicability if you use level A, and the least amount of work on your part if you use level E. Your task is to figure out the happy medium. Know, though, that the FAA generically assumes that Level A is required, and that any reduction must be justified.
Your second stop is section 11, which defines all of the standard DO-178B documents, and other types of deliverables, and what's in them. These items are invariably known by their acronyms. For example, PSAC is the Plan for Software Aspects of Certification. Efficient certification is largely a matter of making sure that everything mentioned in section 11 is covered in the relevant document, in a manner calculated to allow a reviewer to verify this. Here's a list of all the potential deliverables mentioned in section 11:

Acronym	Title	Type
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

Your third stop is Annex A. Though section 11 defines all of the documents and their contents, not every document is needed at every software level, and not every item mentioned in section 11 needs to be in those documents at every software level. For example, at level E, you really need only the PSAC document, and only the section in the PSAC that mentions that the software level is E. At level A, on the other hand, you need every document, and every item of every document. Annex A defines all this.
The other important use of Annex A is that the items in it can be used essentially without change to create checklists for transitions between various phases (or "processes" in DO-178B terminology) of the software-development effort. For example, it very often happens that there is a "Planning process", followed by a "Requirements process", followed by a "Design process", and so on, and Table A-3, "Verification of Outputs of Software Requirements Process" can be used as-is as a checklist for a review that authorizes transitioning from the Requirements process to the Design process. The checklist so created is almost useless in practical terms because it is so general, but the FAA loves it.
The remainder of DO-178B consists basically of explanations that help you to understand what the things mentioned in section 2.2, section 11, and Annex A mean. Unfortunately, not everything is explained. Understanding some items requires knowledge of project management or of software engineering.

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.