This article is within the scope of the Aviation WikiProject. If you would like to participate, please visit the project page, where you can join the project and see lists of open tasks and task forces. To use this banner, please see the full instructions.AviationWikipedia:WikiProject AviationTemplate:WikiProject Aviationaviation articles

This article has been checked against the following criteria for B-class status:
Referencing and citation: criterion not met Coverage and accuracy: criterion not met Structure: criterion met Grammar and style: criterion not met Supporting materials: criterion not met

This article is supported by the aircraft project.

Rewrite needed[edit]

Here are some reasons for the need of a major rewrite/cleanup:

Severely mixed topics (could divide into smaller topics such as DO-178B, FAA, FAR 25.1309, AC 25.1309, DER, SAE ARP4761).
Little information/links about/to the European stuff (EASA/JAA/CAA/AMJ/...).
Inappropriate tone some places.
Some (a lot?) of spelling issues.
Should use same wording as the standards where applicable.

Petter Nordby 13:19, 25 November 2005 (UTC)[reply]

Better?[edit]

Almost nothing left here now. The new DO-178B page is not derived from old stuff which was here, but should cover most of the relevant topics. Petter Nordby 01:14, 2 December 2005 (UTC)[reply]

Most common programming languages & applicable restrictions[edit]

IMHO, it would make sense to provide more in-depth information regarding the ADA/SPARK programming language/s (wikipedia), given that these are the most commonly used languages for all sorts of aviation software in the majority of avionics, regardless of manufacturer. —Preceding unsigned comment added by 82.83.119.24 (talk) 00:46, 7 January 2008 (UTC)[reply]

Suggestion for new text[edit]

Much of the removed text was not from a NPOV (my opinion). I suggest to add hard facts about real life stuff to give the reader an insight into how reliable safety critical avionics software is:

Calculate "Failure rate" based on historical data from safety critical software "in the air" and number of accidents (could be some information regarding this available somewhere)
Show that this number is in the 10E-9 area (less?).
Compare this to failure rate from hardware and human factors.
Compare to "all other software"

Petter Nordby 22:19, 2 December 2005 (UTC)[reply]

Added back some stuff[edit]

The description of developmental stages in older versions was accurate, NPOV, of genuine interest to an uninformed reader, and unrelated to DO-178B. I am a domain expert, having actually developed avionic software that is currently certified and flying. I restored that text, edited for style and spelling. Ray Van De Walker 20:55, 20 March 2006 (UTC)[reply]

Comment on some of the added stuff[edit]

I have also written certified software which is up there, but would not call myself an domain expert. Great work you have done on the restored text. Your contributions are appreciated! Newertheless, here is my ignorant opinion on some of the statements:

The regulatory requirements are not complex or burdensome may be incorrect (DO-178B level A and B?).

For the most part, the regulatory requirements are simply to follow a described quality assurance process that will produce quality that natches the needs of the software. This can't be burdensome, because nobody wants to produce software that's dangerous. It can be more expensive than other forms of software- I'll certainly note that.

I can agree on the requirements not beeing complex. Burdensome however might be a point-of-view-thing. Depending on burdensome for the customer (no in my opinion) or the software developer (yes in my opinion).

Referring only to FAA some places can be not NPOV (I'm thinking of CAA).

Ok- "nation regulatory agency"? I'll change it.

Great!

The code is written, then programmers exchange the code, and review someone else's code can be incorrect, if e.g. there is only one person which writes software (but on the other hand: persons with programming experience will typically need to review the code).

I can't even imagine that a DER would sign-off an unreviewed engineering design, or a review by an unqualified person. I think I'll stick by the text, which describes how most organizations seem to actually do reviews.

I wrote typically due to no review need on lowest level. We had a level B project where I wrote code and another (qualified) person performed review.

Meanwhile, the test engineers have been assembling a test rig, and releasing preliminary tests for use by the software engineers has to me a slightly inappropriate tone for an encyclopedia. I'm unsure about why, but it might have to do with how this statement seems to inform of one single method, which must be used.

This is a very normal method, because it parallelizes test development. I'm willing to qualify the whole description of the process. "Most organizations attempt to perform actions in parallel to reduce a program's calendar time, and therefore use a sequence similar to..."

I'm not sure if I follow you on this one, but the outcome from your edit is better from my (attempted objective) point of view.

Typically is a word which could have been used several places (e.g. section with alternative methods in DO-178B).

? Feel free to change it. Overqualification can interfere with readability. A qualification at the front will be less instrusive, as well as more precise.

I tried (in the front of the chapter I was thinking about).

There seems to be something missing about the good verification done by the relationship between requirements, traceability, tests and coverage (leading to: no code implements an undocumented function and all code is verified to behave as required).

Agreed. I'll add some such text.

Your additions on this were great. There could possibly be a bit of "glue" (a section/summary) which describes this relationship.

Would it be better if avionics software contained an overview, and all the details about documents and stuff was in DO-178B, MIL-STD-2167, ARP4761, etc?

I agree. I tried to put back an overview of the development process, which is really the distinctive difference between avionic software and other embedded systems. Compare the links to specific process specs, like DO-178B. I edited-out particulars of terminology, reports, schedule milestones, authorizing authorities (etc. ad nauseam) linking to them, and restored the text that described a general process. Ray Van De Walker 19:05, 23 March 2006 (UTC)[reply]

That really did the trick! Great work! --Nordby73 21:50, 23 March 2006 (UTC)[reply]

--Nordby73 09:42, 21 March 2006 (UTC)[reply]

Airbus: Design by Diversity[edit]

There are several products and aircraft manufacturers that employed the principle of "Design by Diversity" trying to ensure a higher degree of reliability and implementation independence, might be worth to add a corresponding section. —Preceding unsigned comment added by Parallelized (talk • contribs) 10:50, 28 January 2008 (UTC)[reply]

Main programming languages[edit]

SPARK
Ada —Preceding unsigned comment added by Parallelized (talk • contribs) 11:02, 28 January 2008 (UTC)[reply]

Info

Added new corresponding category: http://en.wikipedia.org/wiki/Category:Avionics_Programming_Language —Preceding unsigned comment added by Parallelized (talk • contribs) 22:50, 1 February 2008 (UTC)[reply]

Safety-critical avionics software[edit]

Given the current opening sentence "Avionics software is embedded software with legally-mandated safety and reliability concerns used in avionics", this page might be better titled as "Safety-Critical Avionics Software" since there is avionics software where human safety is not an issue. For example, the avionics software on the Mars rovers is not subject to the kinds of legally-mandated safety and reliability concerns as avionics software for commercial aviation. SpaceExploration (talk) 17:14, 26 March 2008 (UTC)[reply]