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.
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
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.
- Writing down the hardware requirements.
- Establishing that the hardware requirements are traceable to the
- 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.
This little explanation is intended for
hardware developers who
like to produce aviation hardware but who have no idea how to get
What you will learn is that you probably don't want to do it, if it
involves PLDs, FPGAs, or ASICs.
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?
is the Radio Technical Commission for Aeronautics, Inc. (
www.rtca.org). It plays an important role in defining
for various aviation practices. It is not a government agency,
many of the guidelines it produces are essentially accepted as
by the FAA. This is partially the case for document "DO-254",
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,
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,
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
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
upon personally to deal with it.
As a newcomer, part of the problem with DO-254 is the immense
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
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
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
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
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
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
is often to pervert the spirit of DO-254 by expediently reducing its
to a question of deliverables. The "deliverables" are mainly
and successful certification depends on these documents saying all the
right things. Inexpensive certification depends on the
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
- Your first stop is Table 2-1, where you determine the assurance
The assurance level, which is either A, B, C, D, or E,
based on an assessment of the consequences of a failure of the hardware
as "catastrophic", "hazardous/severe-major", "major",
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,
how much stuff has to be in those documents, along with a miscellaneous
assortment of non-documentation-related activities you may have to
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
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
at level C, and you provide one but only at level D, he won't be able
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
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
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.
certification is largely a matter of making sure that everything
in section 10 is covered in the relevant document, in a manner
to allow a reviewer to verify this. Here's a list of all the
deliverables mentioned in section 10. (The acronyms in
parenthesis I made up myself.)
||Plan for Hardware Aspects of Certification
||Hardware Development Plan
|Hardware Validation Plan
|Hardware Verification Plan
||Hardware Configuration Management Plan
||Hardware Process Assurance Plan
||Hardware Design Standards
||Validation and Verification Standards
|Hardware Archiving Standards
||Hardware Requirements Data
||Hardware Design Representation Description
|Detailed design data (CAD files, HDL source code, etc.)
|Implementation data (Gerber files, JEDEC files, etc.)
||Hardware Test Procedures
|Hardware Test Results and other stuff, collectively known as
the Validation and Verification Records
|Hardware Configuration Management Records
|Hardwaer Process Assurance Records
||Hardware Accomplishment Summary
- Your third stop is Appendix A. Though section 10 defines
documents and their contents, not every document is needed at every
level. For example, at level E, you
need only the PHAC document, and only the section in the PHAC
mentions that the assurance level is E. At level A, on the other
you need every document, and every item of every document.
A defines all this.
- The remainder of DO-254 consists basically of explanations that
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
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
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
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
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
Is That Everything You Need to Know About Certification?
You might want to read The
FAA and Industry Guide to Product Certification. This
is self-admittedly "focused on large and/or complex [development]
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
using Birds Project materials.
In other words, if you are ignorant enough to be seeking
from the Birds Project, you shouldn't be undertaking airborne projects
that are large enough or critical enough to interest certification
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
Also, you will
usually have to hire a DER (Designated Engineering
to examine your documentation. A DER is a specialist
by the FAA as having authority to sign off. The next time you
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
One reason is that the DER may insist on witnessing some things, such
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
the Birds Project.