Previous | Table of Contents | Next |
10.3.1.1. Ada in U.S. Defense Applications: The Ada Policy
Defense projects are, by their very nature, not discussed in much detail in the open literature. On the other hand, enough information has come to light to lead to a conclusion that Ada has been reasonably succ essful in the weapons-building community.
In 1996, DoD commissioned the National Research Council to convene a task force to recommend the future course of the DoD Ada policy. The final report of this study group (National Research Council, 1996) contains a chart showing 50 million lines of active Ada code (MLOC) in DoD weapons systems, with 33 MLOC of C, 5 MLOC C++, 20 MLOC Fortran, 19 MLOC CMS-2, and 14 MLOC Jovial. Considering the long life cycles of DoD systems, this is a good record for Ada. It is interesting to note that the first validated Ada 95 compiler, validated in mid-1995, was hosted on a Sun Sparc and targeted to a proprietary board used in the revised Patriot missile system.
Published reports have discussed a number of successful military management information systems written in Ada, including a recent one in Ada 95 with SQL integration. The AdaSAGE system, developed by Idaho National Engineering Laboratory and consisting of a relational database manager, interface builder, and other support for secure PC-based information systems, won a best product award at a non-Ada object-technology conference and is said to have many customers within DoD.
The NRC report recommended that DoD maintain its Ada requirement for warfighting software but eliminate the requirement for other applications, and DoD management (Paige, 1997) subsequently decided to eliminate the requirement altogether, opting to embed language choice into a Software Engineering Plan Review process for each project. It will be interesting to observe the degree to which Ada continues to be chosen for U.S. military applications in the absence of a firm requirement to choose it.
It is useful to comment on the Ada mandate. The term mandate has acquired a negative connotation in current U.S. political life, but its use to describe DoDs Ada policy is inappropriate. In its negative sense, mandate has meant the Federal Government compelling action from state or local governments, the business sector, or the general public, without providing a suitable level of Federal funding for these actions. On-the-job safety regulations, air and water quality standards, and requirements placed on educational institutions are sometimes assailed in the daily press as unfunded mandates.
Whatever ones opinion on Federal regulation in general, one must agree that the Ada requirement is simply not a mandate in this sense. DoD has never required anyone to use Ada except vendors developing software under DoD contract for DoD use. Whether DoD should impose such a requirementor whether such a requirement could be consistently enforcedhas been, of course, a hotly debated issue; the fact remains that the Ada requirement was a contractual requirement, nothing more.
10.3.1.2. Non-Defense Applications
I have been tracking non-defense Ada projects for a number of years and participate in a joint SIGAda-Ada IC effort to prepare and publish application briefs for projects whose sponsors are willing to see some publicity. Several dozen of these success stories are online and accessible from the Ada IC and SIGAda Educator Web sites.
It is often difficult to get authoritative information for attribution. Many companies are, understandably, uncomfortable seeing details of their projectsincluding languages and tools useddescribed in print. These details are often considered trade secrets and sometimes are deemed to be unwanted invitations to head hunters to approach key employees. On the other hand, the published stories, combined with inside tips from software developers, yield enough information for a useful summary of the state of Ada in the non-defense world.
I can say with confidence that software written in Ada can be found in
It goes without saying that these projects were under no U.S. DoD requirement to use Ada. Further, although many of the projects are government-sponsored (by air traffic control agencies, national railway administrations, and so on), the governments involved generally did not impose the use of Ada. It follows that Ada was chosen as the implementation language by the companies doing the implementing. Why did they choose to go with Ada?
In some casesavionics, for exampleit can be conjectured that a companys experience with Ada in the defense sector led them to choose it for similar commercial projects. There are other reasons as well. In the various published articles and success story briefs, a recurring theme is that Ada was chosen because of its technical characteristics. Among other attributes, strong typing and language-supported multitasking are often mentioned; also, the confidence engendered by compiler validation seems to be an important reason for choosing Ada. In Ada 95 projects, the ease with which new Ada code can interface with existing subsystems such as SQL, CORBA, and the like is starting to be an important factor.
Previous | Table of Contents | Next |