Programming languages, like living organisms in a Darwinian jungle, need to adapt if they are to survive in a changing technological landscape that can bring challenges, surprises and occasional major climatic disruptions. Ada has been around for more than 25 years and has undergone one major revision, in the mid-1990s. Its most recent update, known as Ada 2005, was published as an ISO standard earlier this year. This version of the language brings improvements in several areas, including new facilities for Object-Oriented Programming and some additional libraries. But what may have even greater impact are a number of relatively small enhancements that increase Ada’s support for high-integrity real-time systems.

High Integrity Means What?

A high-integrity application is one where safety, security, or both are essential requirements. In the safety-critical arena each application domain tends to have its own specific requirements standard that a system must satisfy in order to be certified, for example, RTCA DO-178B for commercial avionics. In the security area the situation is somewhat less fragmented, with the Common Criteria and Common Evaluation Methodology generally accepted as certification requirements standards in a domain-independent fashion. Tables 1 and 2 summarize the various criticality levels of the two standards. Generally systems at DO-178B Level A or B would be considered safety-critical, and systems at EALs 5 through 7 would be considered high security.

Although safety and security standards evolved independently, their common goal is to offer assurance that the delivered system is free from vulnerabilities that could lead to safety hazards or security breaches. Not surprisingly, they make basically the same demands on the programming language—or languages—used for development: the language must support reliable, predictable and analyzable code, yet be expressive enough to capture the processing and data structures characteristic of the application domain.

Ironically, some of the features that in general help developers produce robust and maintainable software—such as Object-Oriented Programming, generic templates and exceptions—complicate analyzability, especially for systems that need to comply with the highest levels of DO-178B or the Common Criteria. The key for the developer is to choose an appropriate language and then to restrict feature usage to a subset based on the kinds of analyses that are to be performed.

Ada Does the Job

Ada is an experienced player in the field of high-integrity software, and Ada 95—indeed Ada 83—already provides a sound language foundation. For example, Ada’s lexical and syntactic rules avoid the confusion found in C-based languages and also in Java for things like octal literals (the leading 0 might better be called the misleading 0) and “if” statements (dangling else). Ada’s parameter passing modes, which reflect the data flow direction (in, out, or in out) make it easier for tools to analyze information flow: dependencies between the inputs to and the outputs from a subprogram.

One of the most notable milestones during Ada’s history was the production of an ISO Technical Report (Table 3) on feature usage for high-integrity systems. That report is basically a matrix that identifies, for each type of analysis that might be desired—such as control flow, data flow, formal proofs of correctness—whether or not a given language feature is permitted.

In short, that report showed that there is no such thing as “the high-integrity” subset of Ada, or for any other language, and indeed what is needed is a language mechanism that allows the programmer to identify which features are to be excluded. Among other things, this means that there will be no run-time libraries for the excluded features, thus simplifying the job of certification against standards such as DO-178B. Ada is unique in supplying a feature called Pragma Restrictions that allows the programmer to specify those features that the program is not using.

High Integrity Systems Annex

The High Integrity Systems Annex of the Ada standard specifically addresses the needs of safety-critical and high-security systems. Among other things, this section of the reference manual, originally called the Safety and Security Annex, identifies a number of features that can be specified with Pragma Restrictions. These include restrictions prohibiting dynamic allocation, exceptions and nested tasks.