Birds Project Introduction to DO-254
(or DO-178B)

Bird Man, a painting by artist Lynn Rothan

Disclaimer

I've not actually been through a DO-254 project myself. However, in examining RTCA DO-254, I've found enough similarity to RTCA DO-178B to justify adapting my DO-178B documentation tool (Do178Builder) to handle DO-254 projects. So naturally, I just had to write some background material. If you don't like what you read here, perhaps what I've written is wrong! Let me know if you think so.

Introduction

This is a brief introduction to qualification of aviation hardware, at least in so far as engineering is concerned. By "engineering", I refer to the basic principles such as:

Writing down the hardware requirements.
Establishing that the hardware requirements are traceable to the system requirements.
Developing the hardware requirements into a design.
Implementing the design.
Developing a set of test cases that are traceable to the requirements, and then actually performing the tests.
Configuration management.

Environmental testing such as that envisaged by RTCA DO-160D is not covered here. DO-160D represents a subset of the requirements and tests that would be needed for fully-engineered hardware. You need to be familiar with DO-160D, but compliance with DO-160D is straightforward and easy to understand, if not necessarily easy to accomplish, and will not be mentioned again here.

This little explanation is intended for hardware developers who would like to produce aviation hardware but who have no idea how to get started. What you will learn is that you probably don't want to do it, if it involves PLDs, FPGAs, or ASICs. Experienced aviation developers will learn nothing new, but I'd welcome hearing if anything I'm saying is wrong.

As it happens, the FAA does not require (as far as I can tell) that your hardware be "engineered" in general. If you want to simply perform your hardware development in a "shoot-from-the-hip" fashion without any creation of hardware-requirements data, hardware testing, configuration management, or process assurance, the FAA will apparently let you do so. As long as your hardware passes the appropriate environmental testing (DO-160D), all will be well. Software, on the other hand, must be engineered by conforming to something called RTCA DO-178B. This situation is hard to understand: Why must software be engineered, while hardware can be developed completely informally, as if in somebody's basement? This is a rhetorical question, as I'll probably never know the answer.

... But there is one exception, and that exception is complex programmable logic, such as PLDs, FPGAs, or ASICs. Apparently, the configuration of such devices is sufficiently similar to "software" that using them triggers the latent fear of software. And, to be fair, I suspect that many projects fearing the complexity of DO-178B have in the past buried functionality that logically should have been implemented in software into PLDs, simply to avoid DO-178B. But never fear! Those dastards will be stopped in the future from side-stepping this issue. Enter RTCA DO-254, the hardware equivalent of DO-178B! [And yes, "dastard" is a real word. Among other things, it means "one who shrinks from danger".]

What is RTCA DO-254? "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 partially the case for document "DO-254", which defines the guidelines for development of aviation hardware. FAA Advisory Circular AC20-152 establishes DO-254 as the accepted means of quallifying all new "complex custom micro-coded components" at assurance levels A, B, or C, and says that you "may choose" to use it for level D, but that the FAA won't bother to review your level D data. ("Assurance levels" are discussed below.) AC20-152 admits that there may be other means of establishing the appropriateness of the design for its intended function, but doesn't mention what these other means might be. Oddly, DO-254 does not limit itself merely to "complex custom micro-coded components", but actually covers the complete hardware development effort. However, the FAA has wimped out (at least for the present), and has limited the expected scope of application of DO-254 in the following words from AC20-152: "We don’t intend that you apply RTCA/DO-254 to every type of electronic hardware."

If you want to develop PLDs, FPGAs, or ASICs for airborne use at assurance levels A-C, you'll really have to have a copy of DO-254 and read it closely. It's not free. The only way to get one legally is to buy one from the RTCA.

I personally would also add the following: If you accept the notion that software must be engineered, and that something like DO-178B is useful or necessary for software development, then you should probably bite the bullet and admit that hardware needs to be engineered as well. You should accept that DO-254 needs to be applied to all of your airborne hardware development, and not simply to micro-coded devices. On the other hand, Emerson has told us that "a foolish consistency is the hobgoblin of little minds". Or to paraphrase Voltaire, "I agree that you have the right to use DO-254, but would fight to the death to avoid using it myself!"

Barrier to Entry (or, The Bar is High)

If you are personally primarily interested in designing electronics, and you purchase DO-254 and attempt to read it, you won't enjoy yourself.

Why not? What DO-254 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 hardware, and much to do with project management and with engineering in the sense of the preceding section. 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-254 is the immense amount of detail involved in it. Besides, DO-254 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 Hardware Sense)

Actually, there are a few non-DO-254 things you need to know before beginning hardware 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 hardware used in your project, of course, but to your project as a whole. Some other aspects to be considered are environmental qualification (DO-160D) and software qualification (DO-178B).

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 hardware 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)

Hardware assurance 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 assurance 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-254

DO-254 has almost nothing to do with electrical engineering. DO-254 is primarily about development processes and their objectives, and probably provides very useful guidance in a large corporation having an SQA department and other specialists to deal with issues related to DO-254.

For small organizations, though, the hardware developers themselves often must implement DO-254. In this case, I suspect that the practical consequence is often to pervert the spirit of DO-254 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-254 to see what your deliverables should look like:

Your first stop is Table 2-1, where you determine the assurance level. The assurance level, which is either A, B, C, D, or E, is based on an assessment of the consequences of a failure of the hardware as "catastrophic", "hazardous/severe-major", "major", "minor", or "no effect". (See the notes on the System Safety Assessment, above.) The assurance 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 assurance 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. I believe that the FAA generically assumes that Level A is required, and that any reduction must be justified.
Your second stop is section 10, which defines all of the standard DO-254 documents, and other types of deliverables, and what's in them. Many of these items are invariably known by their acronyms. For example, PHAC is the Plan for Hardware Aspects of Certification. Efficient certification is largely a matter of making sure that everything mentioned in section 10 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 10. (The acronyms in parenthesis I made up myself.)

Acronym	Title	Type
PHAC	Plan for Hardware Aspects of Certification	Document
HDP	Hardware Development Plan	Document
(HVVP)	Hardware Validation Plan	Document
(HVVP)	Hardware Verification Plan	Document
HCMP	Hardware Configuration Management Plan	Document
(HPAP)	Hardware Process Assurance Plan	Document
(RS)	Requirements Standards	Document
(HDS)	Hardware Design Standards	Document
(VVS)	Validation and Verification Standards	Document
(HARS)	Hardware Archiving Standards	Document
HRD	Hardware Requirements Data	Document
(HDRD)	Hardware Design Representation Description	Document
-	Detailed design data (CAD files, HDL source code, etc.)	Files
-	Implementation data (Gerber files, JEDEC files, etc.)	Files
(HTPR)	Hardware Test Procedures	Document
(VVD)	Hardware Test Results and other stuff, collectively known as the Validation and Verification Records	Records
-	Problem Reports	Records
-	Hardware Configuration Management Records	Records
-	Hardwaer Process Assurance Records	Records
HAS	Hardware Accomplishment Summary	Document

Your third stop is Appendix A. Though section 10 defines all of the documents and their contents, not every document is needed at every assurance level. For example, at level E, you really need only the PHAC document, and only the section in the PHAC that mentions that the assurance level is E. At level A, on the other hand, you need every document, and every item of every document. Appendix A defines all this.
The remainder of DO-254 consists basically of explanations that help you to understand what the things mentioned in Table 2-1, section 10, and Appendix A mean, and particularly what the objectives of each development process are. Unfortunately, not everything is explained. Understanding some items requires knowledge of project management or other fields.

Installability, Manufacturability, Service

So, if you create all of the DO-254 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-254 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?

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 DER (Designated Engineering Representative) to examine your documentation. A DER is a specialist designated by the FAA as having authority to sign off. 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 hardware 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.