• Ada Stands Ready for the 21st Century
• The ANDF Consortium
• Tech Talk: User defined tools in the SCORE GUI
• Subscribe to DDC-I Online News and receive monthly updates automatically

The following article, courtesy of the RTC Group, was published in the May 2001 issue of the COTS Journal, and on their website at http://www.rtcgroup.com/cotsjournal/may2001/.

Ada Stands Ready for the 21st Century

Invented for, but no longer required by, the military, Ada is a clear winner in the era of COTS because of its inherent safety-critical reliability, modularity and excellent lifecycle underpinnings. It's finding its way into numerous nonmilitary applications.

Joyce Tokar, VP Technology DDC-I

The concept of safety-critical embedded systems where system failure is measured in human lives as well as dollars originated in the defense industry. In 1976, concern about the proliferation of programming languages used to create the software driving crucial military systems led the DoD to develop the first international software development language standard. In 1983, seven years later, the final result was unveiled: the Ada programming language. 

Mandated as the official DoD language in 1986, Ada successfully completed its early mission. According to the federally funded Institute for Defense Analysis, Ada was able to facilitate decreasing the number of high-order programming languages and dialects from over 450 in 1983 to just 37 by 1996 (Figure 1 and table 1).

The success was based on the principles guiding its creation, which stated that the language must be developed with sound software engineering principles in mind; be able to handle large, complex projects; be both standardized and validated; and at the same time provide both reliability and maintainability. 

Standardization Leads to Portability and Reliability 
For instance, the hugely popular C++ language isn't yet an international standard (though C is a standard), whereas Ada has achieved standardization via ISO/IEC 8652. The advantage of following a standard is that there's no ambiguity in implementing code, and new programmers can crack open a manual and become knowledgeable on structures and syntax. 

Even more important is the fact that - in true COTS fashion - standardized languages like Ada allow the use of multiple vendors' compilers, and they eschew proprietary tweaks and tunings. The Ada Resource Association (ARA) lists myriad information on its Web site, including vendors whose products have passed validation, modifications to existing validation test suites and a variety of other conformance and validation data (see [www.adaic.com]). Finally, the IEC standard and its insistence on validation to ensure compliance allows Ada to be moved from one application to another, which aids in portability and leads to software reuse (Table 2).

From a reliability standpoint, Ada also outshines C. One measure of reliability is the size of the program, represented empirically as the amount of code it takes to accomplish a given task Shown in Figure 2 is an exception handling routine coded in both Ada and in C++. Note the size difference in the each of the routines: Ada requires less than 30% fewer lines of code than C++ in this example. Also, in the Ada example, it's clear where the exception is to be handled, whereas the C++ code requires more checking to determine if the string exception is the expected exception. 

In another example of reliability, according to a study conducted by Ada vendor Rational Software, Ada compiled into fewer thousands of source lines of code (KSLOC) and required fewer fixes per thousand lines (Figure 3). In Rational's example, C required 1,509 KSLOCs for a given application, while a similar implementation in Ada required only 1,273 KSLOCs, a reduction of nearly 16%. Ada also provided a factor of 2 improvement in the number of fixes required per KSLOC, from 9.21 for C down to 4.59 for Ada. 

The Institute for Defense Analysis (IDA) reports that the number of programming languages decreased dramatically from1983 to 1996. Ada precipitated this change and helped focus the military's software around a common language. (Courtesy: IDA.)

Figure 1

Of the 37 high-order languages in use in the DoD in 1994, the IDA provided a subset list of the languages considered to be used only in weapon systems. The list is ranked by Source Lines of Code (SLOC) for Third-Generation languages (3GL). (Courtesy: IDA.) Table 1	Ada 95 Conformity Assessment Process mandates numerous basic steps. Table 2

Mission and Safety Critical
The Ada programming language and embedded systems technology have long been regarded as the stuff of fighter planes and Space Shuttles. But at present, embedded systems play a critical part in the business and consumer technology markets and Ada is playing an increasing role.

Today commercial applications are demanding the same level of safety-critical performance that earned Ada the DoD mandate. With embedded systems residing in applications ranging from satellite and telecommunications systems to networking routers and passenger aircraft, an increasing number of lives and dollars now depend wholly on the reliability of embedded systems software.

For example, at the 2000 Association for Computing Machinery SIGAda Conference, held at the Johns Hopkins University Applied Physics Lab in Laurel, Maryland, there was considerable discussion about where Ada is going, and some surprises emerged. For instance, Canal+ Technologies uses satellites to deliver interactive TV programming, and company representatives gave a presentation about the Ada-based ground system that pushes their signals. While everybody keeps saying, "Ada is a military language," Canal's application couldn't be any less military.

That's because since the lifting of the DoD mandate in 1996 to develop military embedded systems using Ada, the language is asserting its influence in many nonmilitary applications where dependability is paramount. The term safety critical is often used to describe embedded applications where Ada is used, but two distinct measures of the term are emerging. While safety has always been measured in human lives in the military and aerospace world, in a networked world, safety is simply a synonym for "uptime," and when a critical network system is down, money burns.

Moreover, Ada's not just used in networking applications. It has moved from being used exclusively for military and space applications into realms like high-speed rail, commercial air transportation and even process control. This has been partially assisted by efforts that help commercialize the language and make it applicable for nonmilitary safety-critical applications. One such effort has been the definition and standardization of the Ravenscar Profile, a tasking subset of Ada 95 suitable for use in safety-critical, high-integrity real-time systems.

In parallel with these efforts, the embedded-systems market is becoming more and more enamored with high-level programming languages, of which Ada is one. For assembly language programmers, just moving to C is a big step. Meanwhile, the C++ programmers are working hard to figure out, How can we do this on an embedded chip? Ada offers everything available in C++, and it's also been tailored for embedded chips, the traditional realm of the COTS RTOS companies.

As a direct result, a number of RTOS vendors are announcing safety-critical versions of their products because of increasing interest in expanding the development of real-time, safety-critical applications beyond assembly language. Meanwhile, Ada has been providing facilities for safety-critical, real-time high-level application development for many years, but the embedded systems community is only just now beginning to catch on.

Ada Is COTS
Despite predictions of its demise after the DoD lifted the Ada development mandate for defense contracts, Ada usage is actually increasing. Independent software vendors (ISVs), like DDC-I, view Ada as highly desirable for use in nonmilitary markets. To help further this vision, industry groups like the Ada Resource Association board helps to guide future development of the Ada language (see Sidebar "Ada Resource Association").

Stigmatized for years as a "DoD-only" software language, the steady upswing in Ada development is clear evidence that programmers are recognizing Ada's long-standing advantages over other languages. There's a growing market demand and an increasing recognition of Ada's advantages in code reliability, reusability, readability and portability among embedded systems developers.

Hard numbers back these assertions about Ada. In studies conducted during the '80s, Ada consistently outperformed established programming languages like Pascal, Fortran and C. In the '90s, Ada continues to surpass C++ in performance evaluations measuring capability, efficiency, maintenance, risk and lifecycle cost (Tables 3 and 4).

Ada example
begin
 P1;
exception
 when P1_Exception => Handle_It;
 when others => raise;
end;

C++ example
try
{
 p1();
}
 catch (const char* string_exception)
{
 if (!strcmp(string_exception,Ap1_exception@))
 {
 handle_it();
 } else
 {
 throw;
 }
}
catch (...)
{
 throw;
}

An exception handling routine coded in Ada vs. C++. Not only is the Ada code more clear on where the exception is to be handled, but there are fewer lines of code overall. Both of these factors contribute toward Ada's overall inherent high reliability in embedded systems.

Figure 2

The reliability advantages of Ada include fewer lines of code and fewer fixes required for a given application, according to tests conducted by Steve Zeigler at Rational Software. (Courtesy: Rational Software.)

Figure 3

Boeing's choice of Ada for high-profile commercial projects like the Boeing 777 as well as military programs like the Comanche helicopter underscore the military and commercial success of Ada. While the cost savings made possible by implementing Ada are most apparent in the maintenance of large, complex software development programs like the 777 project, smaller commercial applications are primarily turning to Ada for its proven stability and error-checking capabilities.

Penetrating markets long dominated by C++, Ada is surfacing outside the traditional realm of aviation and aerospace, in applications as diverse as meteorological imaging and yachting security. One current project, a Level 7 router being developed by Top Layer, brought home "Best Of Show" in the infrastructure category at the most recent Networking & Interop show in Las Vegas.

In a 1985 study conducted by IBM, Ada outperformed other languages in most criteria. The numbers represent weighted scores, where a higher number is better. (Courtesy: IBM and the Center for Operational Support, Joint Interoperability & Engineering Organization, DISA.)

Table 3:

Top Layer's choice of Ada as the programming language for their new router hinged on several key items; the most important being early identification of programming errors typically detected much later with other languages. Since Ada catches the majority of coding glitches at compile time, before system integration and deployment, errors are less expensive to repair.

Viewed from a business perspective, Ada's primary advantage is in its support of open systems and interoperability, while a list of other "ilities" also contribute to higher programmer productivity and lower lifecycle cost:

• Portability: Correctly designed Ada source code is readily portable across numerous architectures. This saves time and money when hardware changes and upgrades, management shifts, or support problems make it necessary to move a system. Because of language standardization, programmers trained in Ada can also move swiftly from project to project without extensive or expensive retraining.
• Availability/Reliability: Ada is reliable because its compilers apply rigorous checks to the code at compile time, enabling the programmer to locate and remove defects. At runtime, Ada effectively compartmentalizes code. This prevents unpredictable interactions between modules.
• Reusability: Ada allows the compartmentalization of information within packages and tasks and also allows the use of generic procedures and data abstractions to achieve a modularized structure. The result is an increased capacity for the creation of reusable software components and the potential for dramatic cost reductions.
• Readability: Ada code is very readable, which makes errors easier to locate and correct before compile time. Code maintenance and change is made easier because earlier work can be clearly understood, helping developers avoid incorrect and unintentional code alteration.
• Verifiability: Ada doesn't specifically provide verification features, because software verification isn't an end in itself, but a means of achieving reliability. Ada provides reliability directly and makes the additional abstraction of a verification process unnecessary. In addition, all Ada compilation systems are verified against the Ada standard using the Ada Conformance Assessment Test Suite (ACATS formerly known as the ACVC tests).

Despite the steady increase in Ada use, a number of inaccurate perceptions about Ada still linger, with a number of programmers still convinced that Ada will eventually fade away without the DoD mandate. The truth is that Ada won't go away in the foreseeable future. The DoD has an enormous investment in Ada, and major systems written in Ada will be in service for at least the next 20 years.

In addition, some developers view Ada as a radical departure from what they already know, as a language with a steep learning curve. In reality, the Ada learning curve is no different than that of any other high-order programming language, and educational resources are increasing alongside Ada's continuing growth in both the military and the commercial sector.

One early criticism leveled at Ada involved first-generation Ada compilers, which produced large executables. The development of optimizing compilers eliminated this problem, and today's Ada compilers produce the tightest embedded system code available.

Contentions that Ada is an immature, unsupported language and that the compilers and tools are expensive and unavailable are wholly incorrect. In fact, mature Ada compilers are available for different platforms and environments, with free Ada 95 compilers available. Vendor pricing geared toward DoD contracts in the '80s has also shifted to reflect the competitive commercial market.

In a 1991 follow-on study conducted by SEI, Ada was compared with C++ in six weighted categories. The categories are the same and have the same maximum scores as those used by IBM in their study. (Courtesy: SEI and DISA.)

Table 4: 

Lifecycle Benefits
One of the most significant benefits Ada offers often isn't even considered when the choice between development languages is made. When looking at computer systems from the total lifecycle perspective, research has determined that between 60% and 80% of costs occur after development and implementation. In other words, the maintenance phase accounts for the lion's share of the costs in traditional projects.

Since procurement decisions are typically driven by development costs and maintenance is typically handled as a separate contract on most projects, this creates an artificial division in the lifecycle that makes it far too easy to overlook maintenance. Basically, a decision based exclusively on the first-phase costs is only considering 20% to 40% of the total possible project expenses.

Another harsh reality is that COTS software isn't always the correct choice, since maintaining COTS solutions is often difficult, if not impossible; source code isn't always readily available; and vendor support doesn't always continue. Evidence of this is easy to find in the PC market, the quintessential COTS market. For example, Microsoft has recently announced that it's ending broad support for its once popular Windows95 operating system (though the company continues to support its products under individual customer arrangements).

It's in the best interest of the customer making a fiscally responsible decision to get a true picture of the costs of a software system, and this can only be accomplished when the total lifecycle is taken into consideration - not just the development phase. That's because Ada was developed with good software engineering practice as a founding principle and remains the only internationally standardized programming language specifically designed to address large, complex applications. For real-time, safety-critical applications, Ada is still the undisputed leader.

The ANDF Consortium

by Poul Munch, Sales, DDC-I

A couple of years ago a number of companies and organizations established the ANDF Consortium. The participants have all been involved in the establishment of ANDF (Architectural Neutral Distribution Format) technology or actually used the technology in development projects.

The ANDF Consortium has established a homepage http://www.andf.org/. Maintained by the University of Karlsruhe, Germany, this home page contains information about the ANDF standard, free software downloads (cross & native compilers and numerous back-ends), success stories, articles, experiences with the technology, yellow pages of key people who are references, links and useful information about active companies and organizations working with ANDF.

The ANDF technology is the basis for DDC-I's SCORE (Safety Critical, Object-oriented, Real-time Embedded), an integrated software development environment designed to address the need for combining reusable software components, written in different languages, targeting different microprocessors and developed on different development platforms.

The ANDF website also offers literature about commercial ANDF based products such as SCORE from DDC-I as well as a news section, where the latest developments are listed.

Tech Talk

User Defined Tools in the SCORE GUI

by Lisa Jett, Software Engineer, DDC-I

Using the SCORE GUI, users can easily integrate their own tools. The SCORE GUI allows user defined tools to exist at three levels. Tools can be defined (1) as available to all users of all projects, (2) as available to all users of a particular project only, or (3) as available for a single user on a single project.

Defining a tool available to all users of all projects

Suppose your company has a tool for handling the configuration management of source code files (eg. rcs). One of the features of most CM tools is the ability to display the history of information about the changes that have been made to a particular file (eg. rlog <filename>). To use this tool, we would like to be able to have a file open in the editor and the tool display the history information for the file. To define this tool, select Preferences | Tools. When the Tools dialog appears, press the "New" button. The New Tool dialog is then displayed which requires the following information:

When finished entering your choices for the New Tool dialog, click OK to implement your changes and exit the dialog. Now a tool called "File History" appears in the Tools menu available that will display the history information for the currently selected file open in the editor.

Defining a tool for all users of a particular project

Some tools may only be needed for a particular project, but all users of the project need to be able to use the tool. The project administrator can define a tool at the project level which will be available for all users of the project. To do this the project administrator opens the particular project and selects Project | Project Mode. Then select Project | Edit to display the Edit Project dialog. Select the Tools tab on the Edit Project dialog and the New Tools dialog is displayed. Here the tool can be defined exactly as stated above and will be listed in the Tools menu. However, this tool will only be available when the particular project it was defined for is opened by a user.

Defining a tool for one user of a particular project 

Users often need to be able to define tools that make getting their work done easier. A user can define a tool for a project that is only available for them. By default a project is in user mode. To define a tool for a project, the user would select Project | Edit to display the Edit Project dialog. Select the Tools tab on the Edit Project dialog and the New Tools dialog is displayed. Here the tool is defined exactly as stated in the first section above and will be listed in the Tools menu. However, this tool will only be available for this user when the project is opened.