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.
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
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
know how to read it.
Actually, there are a few non-DO-178B things you need to know before
beginning software development.
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).
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.
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.
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
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|
|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|
|Software Configuration Management Records||Records|
|Software Quality Assurance Records||Records|
|SAS||Software Accomplishment Summary||Document|
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
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 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.