Avionics software is embedded software with legally mandated safety and reliability concerns used in avionics. The main difference between avionic software and conventional embedded software is that the development process is required by law and is optimized for safety. It is claimed that the process described below is only slightly slower and more costly (perhaps 15 percent) than the normal ad hoc processes used for commercial software. Since most software fails because of mistakes, eliminating the mistakes at the earliest possible step is also a relatively inexpensive and reliable way to produce software. In some projects however, mistakes in the specifications may not be detected until deployment. At that point, they can be very expensive to fix.
The basic idea of any software development model is that each step of the design process has outputs called "deliverables." If the deliverables are tested for correctness and fixed, then normal human mistakes can not easily grow into dangerous or expensive problems. Most manufacturers follow the waterfall model to coordinate the design product, but almost all explicitly permit earlier work to be revised. The result is more often closer to a spiral model.
For an overview of embedded software see embedded system and software development models. The rest of this article assumes familiarity with that information, and discusses differences between commercial embedded systems and commercial development models.
General overview
Since most avionics manufacturers see software as a way to add value without adding weight, the importance of embedded software in avionic systems is increasing.
Most modern commercial aircraft with auto-pilots use flight computers and so called flight management systems (FMS) that can fly the aircraft without the pilot's active intervention during certain phases of flight. Also under development or in production are unmanned vehicles: missiles and drones which can take off, cruise and land without airborne pilot intervention.
In many of these systems, failure is unacceptable. The reliability of the software running in airborne vehicles (civil or military) is shown by the fact that most airborne accidents occur due to manual errors. Unfortunately reliable software is not necessarily easy to use or intuitive, poor user interface design has been a contributing cause of many aerospace accidents and deaths.
Regulatory issues
Due to safety requirements, most nations regulate avionics, or at least adopt standards in use by a group of allies or a customs union. The three regulatory organizations that most affect international aviation development are the U.S, the E.U. and Russia.
In the U.S., avionic and other aircraft components have safety and reliability standards mandated by the Federal Aviation Regulations, Part 25 for Transport Airplanes, Part 23 for Small Airplanes, and Parts 27 and 29 for Rotorcraft. These standards are enforced by "designated engineering representatives" of the FAA who are usually paid by a manufacturer and certified by the FAA.
In the European Union the IEC describes "recommended" requirements for safety-critical systems, which are usually adopted without change by governments. A safe, reliable piece of avionics has a "CE Mark." The regulatory arrangement is remarkably similar to fire safety in the U.S. and Canada. The government certifies testing laboratories, and the laboratories certify both manufactured items and organizations. Essentially, the oversight of the engineering is outsourced from the government and manufacturer to the testing laboratory.
To assure safety and reliability, national regulatory authorities (e.g. the FAA, CAA, or DOD) require software development standards. Some representative standards include MIL-STD-2167 for military systems, or RTCA DO-178B and its successor DO-178C for civil aircraft.
The regulatory requirements for this software can be expensive compared to other software, but they are usually the minimum that is required to produce the necessary safety.
Development process
The main difference between avionics software and other embedded systems is that the actual standards are often far more detailed and rigorous than commercial standards, usually described by documents with hundreds of pages. It is usually run on a real time operating system.
Since the process is legally required, most processes have documents or software to trace requirements from numbered paragraphs in the specifications and designs to exact pieces of code, with exact tests for each, and a box on the final certification checklist. This is specifically to prove conformance to the legally mandated standard.