Certain kinds of applications leave no margin for error. Software that flies an aircraft or that controls a nuclear reactor must work correctly, or the results could be catastrophic; such software is said to be safety-critical. Regulatory agencies in safety-critical domains typically have stringent certification requirements that must be met by software providers, beyond what would be standard practice for most military embedded systems. The goal is to provide assurance that the delivered system is reliable (it does what it is supposed to do) and is also safe (it does not do what it is not supposed to do).

For the development of safety-critical software, the choice of programming language makes a significant difference in meeting the requirements of exacting safety standards and, ultimately, high-reliability applications. Ada, for example, has a long history of success in the safety-critical domain. In a recent example, Ada was used in software for the mission control system (MCS) aboard Boeing’s advanced aerial refueling tanker, the KC-767 (Figure 1).

The Italian Air Force was Boeing’s first KC-767 customer, ordering four of the world’s newest and most advanced tankers, the first of which had its maiden flight this past May. The KC-767 MCS is the first avionics application in flight to use the Software Common Operating Environment (SCOE), which consists of a safety-critical-certified ARINC653 operating system from Wind River, the GNAT Pro for VxWorks 653 Ada compilation system from AdaCore, and infrastructure software developed by Smiths Aerospace.

Well-Seasoned Language

Ada was designed from the start to promote sound software engineering, with features such as strong typing that help detect errors early. Ada’s semantics are well defined and, unlike Java, the language has gone through a rigorous international standardization process that guarantees a thorough and detailed review. Ada also lacks the “traps and pitfalls” that cause run-time surprises in other languages, such as C and C++.

The Ada language was first introduced in 1983—the date of the first ANSI standardization. From the start there was a fundamental commitment to safety and reliability. Fitting that commitment, a formal process and an extensive test suite were introduced for testing an implementation’s conformance with the language standard. This process has been known informally as “validating” an implementation. Today that validation process is defined in an ISO (International Organization for Standardization) standard. Ada is the only language for which such a standardized set of conformance procedures exists.

In 1995, as a result of a significant effort sponsored by the U.S. DoD, a major revision of the language standard was published, popularly called Ada 95. Ada 95 brought a number of enhancements, including support for object-oriented programming, and became the first internationally standardized object oriented language. In accordance with Ada’s fundamental design principles, key objectives were safety and reliability, and Ada 95’s object-oriented features preserve this goal, while providing important capabilities such as inheritance with type extension.

No DoD Funding This Time Around

ISO procedures call for revising standardized languages every ten years. Although the DoD no longer requires specific languages, and thus did not fund the new revision, major work was again invested, this time provided by the Ada vendor and user community, with some sponsorship by the Ada Resource Association (an industry trade group). The new proposed standard, which is referred to as Ada 2005, incorporates another decade of experience in using Ada to build large safety-critical systems, for example the onboard avionics control of the Boeing 777, and also a decade of research in language design.

The new language is not yet officially standardized, but the technical work is complete, and formal standardization is expected sometime next year. Meanwhile, Ada vendors are proceeding with its implementation, and Ada 2005-based products are available and in use today. There are important contributions that the use of Ada 2005 can make in ensuring safety and security of large critical software applications.

It is interesting to note that the phrase “safety-critical” specifically applies to applications where human lives depend on correct operation—for example, commercial avionics. However, in a society increasingly dependent on sophisticated computer software, there are more and more applications where correctness is essential, even if they are not formally considered safety-critical. For example, the commercial banking structure relies on complex computer controls. Even a minor failure can cause waves that can have huge economic consequences. There are several decades of experience in building safety-critical systems, and the success has been remarkable—no fatalities can be attributed to failure of certified safety-critical software. It is both practical and essential to extend these techniques to improve the reliability of our entire computer infrastructure.

Ada 2005: A Family of Languages

For purposes of developing safety-critical systems, Ada 2005 may be regarded not as a single language but rather a family of languages. In practice in writing high-reliability software, one does not want to use the full facilities of a complex language, since excessive complexity is an enemy of reliability. Instead a reliable subset is chosen.

All general-purpose languages use this subset approach, but two aspects make Ada unique. First, the notion of such subsets is built into the language standard, rather than being external to it (the latter is exemplified by the attempt to define a “safe C” subset such as MISRA C). Second, the specific features in the subset can be chosen by the application developer, thus providing a high degree of flexibility. Indeed, such flexibility is essential in practice, since the exact set of features in the subset depends on the analysis techniques that are expected to be used during the development process, which in turn depends on the level of criticality.

The concept of language-defined subset was introduced in Ada 95 in the form of a specific compiler directive, pragma Restrictions, and formalized and extended in Ada 2005. For example, in many kinds of safety-critical applications it is inappropriate to use dynamic memory allocation, because of the possible resulting unpredictability of memory usage. By specifying pragma Restrictions (No_Dynamic_Allocation), the programmer has effectively specified a language subset. Any attempt to use dynamic allocation will be flagged as a compile-time error. And importantly, the implementation can exclude from the executable any run-time support for dynamic allocation, thus simplifying the certification process.

Ravenscar Profile

As another example, the use of the full Ada concurrency model has long been regarded as inappropriate for safety-critical applications. A 1997 international workshop on real-time Ada issues defined a set of tasking features, named the Ravenscar profile, simple enough to be efficiently implementable and amenable to certification, yet powerful enough for the needs of realistic applications. The Ravenscar profile is defined by a set of restrictions such as no locally declared tasks, no dynamic allocation of tasks and no asynchronous transfer of control.

A program conforming to the Ravenscar profile comprises a fixed number of tasks where each task body is an infinite loop with a single “invocation event” at each iteration (Figure 2a and 2b). The invocation event may be either a timeout or the execution of a construct that corresponds to accessing an object with a state-based mutual exclusion protocol (in Ada terms, a protected entry call). Intertask communication is through shared objects, either under software or hardware mutual exclusion control. Through the Ravenscar profile, Ada is unique in allowing the construction of portable, predictable, certifiable, concurrent programs.

Ada 2005 offers a number of improvements to the Ada language. Among the key enhancements are in the areas of object-oriented programming (OOP) interfaces, program packaging and an extensive containers library. See the sidebar “Ada 2005 Improves on Ada’s Strengths” on p.42 in this article.

Playing Nice with the Competition

Although Ada, and in particular Ada 2005, has substantial advantages over competing languages such as C++, Fortran and Java, in practice most large applications involve a mixture of languages. This makes good sense. Few large applications are actually programmed from scratch. Instead, developers try to make maximum use of existing reusable components, which may be written in a variety of languages. It makes no sense to rewrite these verified components in some other language. One of the less useful results of the misinterpretation of the DoD’s 1980s directives requiring Ada usage, was to encourage such rewriting (into Ada), when it made little sense, just as it makes no sense today to rewrite verified reliable Ada components in some other language.

But mixing languages can be problematic because most languages are designed with the conceptual notion that the entire program is in that language. Ada uniquely takes a more realistic view, and specifically provides for interfacing to other languages in a well-defined way. At the time of the Ada 95 design, this larger view included C, Fortran and COBOL but not C++, since C++ had not yet been standardized. Now C++ has caught up in this respect, and Ada 2005 allows easy interfacing to C++ and also to Java (even though Java is not itself a standard).

Interestingly, in some respects a program comprising a mixture of Ada and C can be more reliable than one written just in C. For example, in some environments a callback to a user-supplied function requires that the function be compiled with a special calling convention. Failure to specify the needed calling convention, in a program written in C, can lead to a run-time crash. If the function is supplied in Ada and then passed to a foreign routine in C, the Ada compiler will detect the mismatch in calling convention and reject the program at compile time. This is much preferable to tracking down a run-time failure.

Ada 2005 Is Available Today

As noted earlier, Ada 2005 is not yet formally standardized. The ISO procedures, like those of any official organization, can take some time to complete. However, the important part of these procedures, namely the technical design, is complete today, and it is generally agreed that the final standard will be essentially identical to the proposal that exists today.

This means that there is no need to wait for formal approval to steam ahead. For example, AdaCore has made a major commitment to Ada 2005, and its products today incorporate the most important features of the proposed language. Complete implementations are expected during the first quarter of 2006. Combined with AdaCore’s High Integrity Edition (HIE) version of Ada, which provides for flexible tailoring of subset capabilities, along with corresponding certification materials, this means that Ada 2005 is here today for use in the next generation of highly reliable software.

AdaCore
New York, NY.
(212) 620-7300.
[www.adacore.com].