Avionics software

Avionics software is embedded system with legally-mandated safety and reliability concerns used in avionics.

Interestingly, some claim that the Software development process described below is only slightly slower and more costly (perhaps 15 percent) than the normal ad-hoc Processes used for commercial Computer software. Since most software fails because of mistakes, eliminating the mistakes at the earliest possible step is also a relatively inexpensive, reliable way to produce software. Others claim the process is many times slower and more expensive. Because mistakes in the specifications may not be detected until deployment, they can be very expensive to fix.

The basic idea is that each step of the design process has outputs. If these outputs are tested for correctness and fixed, then normal human mistakes can t 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. The rest of this article assumes familiarity with that information, and discusses differences from commercial embedded systems.

=Regulatory issues=

In the United States, avionic and other aircraft components have safety and reliability standards mandated by the Federal Aviation Regulations, Part 25. These standards are enforced by designated engineering representatives of the Federal Aviation Administration who are usually paid by a manufacturer and certified by the FAA.

In the European Union the International Electrotechnical Commission describes recommended (mandatory!) requirements for safety-critical systems, which are usually adopted without change by relevant 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.

The regulatory requirements are not complex or burdensome. First, a document must be produced called the Plan for Software Aspects of Certification. This describes why using software is a good idea, and ideally, how using software is safer than not using software, how much risk the software adds to an aircraft (its level), and how the software will be proven to work. The manufacturer must label each revision of the software unambiguously, and preserve a description of how it can be reproduced, and the data to do so. Finally, a comprehensive maintenance manual must be produced. The maintenance manual is comprehensive-enough almost to permit an air-line to rebuild the unit from bare metal.

=General Overview of Avionics Software Systems=

Importance of embedded software in the avionics systems in the aircraft is ever increasing. The software in the aircraft plays an ever more vital role. Modern commercial aircraft with auto-pilots using flight computers which can fly the aircraft without the pilot s active intervention. Also under development or in production are unmanned vehicles, missiles and drones which can take off, cruise and land without pilot intervention. Such a critical role played by embedded software in the airborne vehicles calls for full proof safety and reliability in these softwares. In many of these systems failure is simply no option as it can result in catastrophic situation. Compare software running in Nukes with your run of the mill Microsoft software running in your PC. In PC you have option to reboot and wait for 15 minutes before you go back to your software. Do you think it is an option available for aircraft auto-pilot software or missile navigation software Think about it when you want to guege the level of planning, resources, due diligance needed to get such software inducted into airborne systems. The reliability of the software running in the airborne vehicles (civil or military) can be attested by this simple fact that majority of air borne accidents have happend due to manual error rather than machine errors.

In order to ensure this kind of reliability FAA has mandated a software development standard to be followed before the software can be executed in the flying civilian aircraft. For military systems you have DOD 2167A standard. RTCA DO-178B standard specifies final levels of criticality for any airborne software... based on impact of software error. Level A software can crash airplanes. (Death is guaranteed) Level B may kill or maim people. (Death is certainly possible) Level C can cause severe hardship to the pilot. (No death but few anxious moments for the pilot) ) Level D Minor irritants. Level E has no effect on safety or costs. These systems are like any other non safety commercial systems

Examples of different levels Level A - Engine Control System, flight control system, primary navigation Level B - Secondary power distribution assembly, Doors Level C - Secondary navigation system or on board communication with tower Level D - In flight entertainment, public address system inside the aircraft, Gallays

The differences between the levels are how much documentation must be preserved about the quality assurance steps. Level A needs to satisfy 66 goals outlined in Do-178B document Level B needs to satisfy 65 goals outlined in Do-178B document Level C needs to satidfy 60 goals outlined in Do-178B document

The avionics software needs to be developed as per the guidelines and recommendations given by RTCA DO-178B standard. This software needs to be certified by FAA representatives calld DER (Designated engineering representative) for the criticality level determined by FAA for that system. The DO-178B standard document provides the complete roadmap for planning, developing, verifying and certifying the avionics software. This is perhaps the single most important document for any avionics software developer. The complete compliance with this standard is mandatory if you want to get your software certified by FAA. The detailed information on RTCA DO-178B avoinics software development standard is provided below...

=RTCA DO-178B avioinics software development standard =

==Overview of document==

Section 2 - System Aspects relating to software development Software Life Cycle Process Section 3 - Software LifeCycle Section 4 - Software Planning Process Section 5 - Software Development Processes Integral Processes Section 6 - Software verification Section 7 - Software Configuration Management Section 8 - Software Quality Assurance Section 9 - Certification Liasion Section 10 - Overview of aircraft and engine certification Section 11 - Software Life Cycle Data Section 12 - Additional Consideration

=Other Aspects of Avionics software development=

==Human Interfaces==

Projects with substantial human interfaces are usually prototyped or simulated. The video tape should be retained, but the prototype retired immediately after testing, because otherwise senior management and customers can believe the system is complete.

==Hazard Analysis==

The hazard analysis takes each block of a block diagram and considers the things that could go wrong with that block. Then the severity and probability of the hazards are estimated.

Projects involving military cryptographic security usually include a security analysis, using methods very like the hazard analysis.

==Engineering Specification==

The engineering specification is a document that describes what the software should do in foreseeable circumstances. The hazards feed into it to create more requirements. Usually it s reviewed for completeness, conformance to the marketing requirements, mitigation of hazards, practicality and testability. If the requirements can t be tested, then the software can t be proven to be done.

One of the major differences between avionics and commercial electronics is that everything on an aircraft can usually be semi-automatically tested in the time it takes to turn around the aircraft at an airport. This built-in test is a substantial effort that can literally make or break avionics in the commercial marketplace, by affecting its cost of ownership.

==Software Design Document==

As soon as the engineering specification is complete, the software design can start. The design tells what software modules exist, and what they do, and how they relate. Engineers review it for completeness, accuracy, safety, conformance to the engineering and marketing specification, and practicality.

==Software Test Plan==

As soon as the engineering specification is complete, the test plan can start. The test plan describes a practical method to test every feature, especially the safety-critical ones. Often, the expense of testing can be dramatically reduced by adding a small amount of software and electronics to help the testing. The most common aid is an interface to an external computer, used to simulate inputs and read outputs.

==Maintenance Manual==

As soon as the engineering specification is complete, writing the maintenance manual can start. There are several levels. A level D product such as an in-flight entertainment unit (a flying TV) may escape with a schematic and procedures for installation and adjustment. A navigation system, autopilot or engine may have thousands of pages of procedures, inspections and rigging instructions. Documents are now (2003) routinely delivered on CD-ROM, in standard formats that include text and pictures.

==Code production and review==

The code is written, then programmers exchange the code, and review someone else s code. Skilled organizations use a checklist of possible mistakes, and add to it when they find a new mistake. The code is also often examined by programs. The Compilers or special checking programs like lint check to see if types of data are compatible with the operations on them. Another set of programs measure software metrics, to look for parts of the code that are likely to have mistakes. All the problems are fixed, or at least understood and double-checked.

Some code, such as digital filters, graphical user interfaces and inertial navigation systems, are so well-understood that software tools have been developed to write the software. In these cases, specifications are developed, and boring but reliable software is produced automatically.

==Unit testing==

Unit test code is written that should exercise every instruction of the code at least once. A coverage tool should be used to verify that every instruction is executed. This test is among the most powerful. It forces detailed review of the program logic, and detects most coding, compiler and some design errors. Some organizations write the unit tests before writing the code, using the software design as a module specification. The unit test code is executed, and all the problems are fixed.

==Integration testing==

As pieces of code become available, they are added to a skeleton of code, and tested in place to make sure each interface works. This is called integration, and the testing is called integration testing. Usually the built-in-tests of the electronics should be finished first, to begin burn-in and radio emissions tests of the electronics. Next, the most valuable features of the software are integrated. It is very convenient for the integrators to have a way to run small selected pieces of code, perhaps from a simple menu system.

==Black box and acceptance testing==

Meanwhile, the test engineers have been assembling a test rig, and releasing preliminary tests for use by the software engineers. At some point, the tests cover all of the functions of the engineering specification. At this point, testing of the entire avionic unit begins.

==Certification==

Each step produces a deliverable, either a document, code, or a test report. When the software passes all of its tests (or enough to be sold safely), these are bound into a certification report, that can literally have thousands of pages. The designated engineering representative, who has been nagging the organization all along, then decides if the result is acceptable. If it is, he signs it, and the avionic software is certified.

At this point, the software is usually very good software.