Ada programming language

Ada is a structured, compiled, statically typed programming language, designed by Jean Ichbiah of Cii Honeywell Bull in the 1970s. It is positioned to address much the same tasks as C or C++. Ada was named after Lady Ada Lovelace, the first computer programmer.

Table of contents

1 Language Features 2 History 3 "Hello, World!" in Ada 4 The Ariane 5 Failure

Language Features

Ada was originally targeted at embedded and real-time systems, and is still commonly used for those purposes. The Ada 95 revision (designed by Tucker Taft of Intermetrics between 1992 and 1995) improved support for systems, numerical, and financial programming.

Notable features of Ada include Strong typing, run-time checking, parallel processing, exception handling, and genericss. Ada 95 added support for object-oriented programming, including dynamic dispatch.

Ada implementations do not typically use garbage collection for storage management. Ada supports a limited form of region-based storage management which allows some cases of access to unallocated memory to be detected at compile time.

Ada supports run-time checks in order to protect against access to unallocated memory, buffer overflow errors, off by one errors, and other avoidable bugs. These checks can be disabled in the interest of efficiency. It also includes facilities to help program verification. For these reasons, it is very widely used in critical systems like avionics, weapons and spacecraft.

The Ada language definition is unusual among International Organization for Standardization standards in that it is Free content. One effect of this is that the standard document (known as the Reference Manual or RM) is the usual reference resorted to by Ada programmers for technical details, much as many other languages have a standard textbook.

History

In the 1970s, the US Department of Defense was concerned by the number of different programming languages being used for its projects, some of which were proprietary and/or obsolete. In 1975 the Higher Order Language Working Group (HOLWG) was formed with the intent of reducing this number by finding or creating a programming language generally suitable for the department's requirements; the result was Ada. The total number of high-level programming languages in use for such projects fell from over 450 in 1983 to 37 by 1996.

The working group created a series of language requirements documents - the Strawman, Tinman, and Ironman (and later Steelman) documents. Many existing languages were formally reviewed, but the team concluded in 1977 that no existing language met the specifications.

Requests for proposals for a new programming language were issued and four contractors were hired to develop their proposals under the names of Red, Green, Blue, and Yellow. In May of 1979, the Green proposal, designed by Jean Ichbiah at Cii Honeywell Bull, was chosen and given the name Ada. The reference manual was approved on December 10, 1980 (Ada Lovelace's birthday)

The US Department of Defense required the use Ada (the Ada mandate) for every software project where new code was more than 30% of result, though exceptions to this rule were often granted. This requirement was effectively removed in 1997. Similar requirements existed in other North Atlantic Treaty Organization countries.

The language became an ANSI standard in 1983 (ANSI/MIL-STD 1815), and an ISO standard in 1987 (ISO-8652:1987). This version of the language is commonly known as Ada 83, from the date of its adoption by ANSI.

Ada 95, the joint ISO/ANSI standard (ISO-8652:1995) is the latest standard for Ada. It was accepted in February 1995 (making Ada 95 the first ISO standard object-oriented programming language). To help with the standard revision and future acceptance the US Air Force funded the development of the GNAT Compiler.

"Hello, World!" in Ada

A common example of a language's syntax is the Hello world program.

with Ada.Text_Io; use Ada.Text_Io;
procedure Hello is
begin
  Put_Line("Hello World!");
end Hello;

The Ariane 5 Failure

A commonly encountered myth blames the loss of a European Space Agency Ariane 5 rocket on a bug in an Ada program or on disabling Ada's runtime checks. Though range checks and appropriate exception handlers on all type conversions (see e and f below) might have trapped the problem, the problem itself was a design decision to reuse a part and its software from the Ariane 4 rocket without adequate analysis of its suitability (see m and n below) or tests on Ariane 5 data (see r and t below), as described in the Report by the Inquiry Board -

3. CONCLUSIONS

3.1 FINDINGS

The Board reached the following findings:

...

e) At 36.7 seconds after H0 (approx. 30 seconds after lift-off) the computer within the back-up inertial reference system, which was working on stand-by for guidance and attitude control, became inoperative. This was caused by an internal variable related to the horizontal velocity of the launcher exceeding a limit which existed in the software of this computer.

f) Approx. 0.05 seconds later the active inertial reference system, identical to the back-up system in hardware and software, failed for the same reason. Since the back-up inertial system was already inoperative, correct guidance and attitude information could no longer be obtained and loss of the mission was inevitable.

g) As a result of its failure, the active inertial reference system transmitted essentially diagnostic information to the launcher's main computer, where it was interpreted as flight data and used for flight control calculations.

h) On the basis of those calculations the main computer commanded the booster nozzles, and somewhat later the main engine nozzle also, to make a large correction for an attitude deviation that had not occurred.

i) A rapid change of attitude occurred which caused the launcher to disintegrate at 39 seconds after H0 due to aerodynamic forces.

...

m) The inertial reference system of Ariane 5 is essentially common to a system which is presently flying on Ariane 4. The part of the software which caused the interruption in the inertial system computers is used before launch to align the inertial reference system and, in Ariane 4, also to enable a rapid realignment of the system in case of a late hold in the countdown. This realignment function, which does not serve any purpose on Ariane 5, was nevertheless retained for commonality reasons and allowed, as in Ariane 4, to operate for approx. 40 seconds after lift-off.

n) During design of the software of the inertial reference system used for Ariane 4 and Ariane 5, a decision was taken that it was not necessary to protect the inertial system computer from being made inoperative by an excessive value of the variable related to the horizontal velocity, a protection which was provided for several other variables of the alignment software. When taking this design decision, it was not analysed or fully understood which values this particular variable might assume when the alignment software was allowed to operate after lift-off.

o) In Ariane 4 flights using the same type of inertial reference system there has been no such failure because the trajectory during the first 40 seconds of flight is such that the particular variable related to horizontal velocity cannot reach, with an adequate operational margin, a value beyond the limit present in the software.

p) Ariane 5 has a high initial acceleration and a trajectory which leads to a build-up of horizontal velocity which is five times more rapid than for Ariane 4. The higher horizontal velocity of Ariane 5 generated, within the 40-second timeframe, the excessive value which caused the inertial system computers to cease operation.

q) The purpose of the review process, which involves all major partners in the Ariane 5 programme, is to validate design decisions and to obtain flight qualification. In this process, the limitations of the alignment software were not fully analysed and the possible implications of allowing it to continue to function during flight were not realised.

r) The specification of the inertial reference system and the tests performed at equipment level did not specifically include the Ariane 5 trajectory data. Consequently the realignment function was not tested under simulated Ariane 5 flight conditions, and the design error was not discovered.

...

t) Post-flight simulations have been carried out on a computer with software of the inertial reference system and with a simulated environment, including the actual trajectory data from the Ariane 501 flight. These simulations have faithfully reproduced the chain of events leading to the failure of the inertial reference systems.

3.2 CAUSE OF THE FAILURE

The failure of the Ariane 501 was caused by the complete loss of guidance and attitude information 37 seconds after start of the main engine ignition sequence (30 seconds after lift- off). This loss of information was due to specification and design errors in the software of the inertial reference system.

The extensive reviews and tests carried out during the Ariane 5 Development Programme did not include adequate analysis and testing of the inertial reference system or of the complete flight control system, which could have detected the potential failure.