IN THIS ISSUE...
- Ada 95 IS FLYING HIGH!
- EARLY Ada 95 ADOPTION PARTNERSHIPS
- Overview of Ada 95 Successes in "Letter from the AJPO"
- JAST: Reuse, Compatibility, Security, and Fault Tolerance with Ada 95
- SWEDISH DEVELOPERS USING Ada 95 SINCE 1993
- COE: SCOUTING THE TERRITORY, HIGHLIGHTING Ada 95 FEATURES
- ADOPTING Ada 95 IN AN INCREMENTAL STRATEGY - THE S3 PROJECT
- AJPO receives recommendations for future bindings and tools efforts
- Ada 95 AS A WAY TO REDUCE RISK: SOME OPSERVATIONS FOR PROJECTS WHERE "SAFETY-CRITICAL" IS ESSENTIAL
- AJPO RECEIVES RECOMMENDATION FOR TOOL PLAN FOR Ada 95
- THE AdaIC ON-LINE
- AdaSAGE - MOVING OUT TO WINDOWS, MOVING UP TO Ada 95
- VENDORS' PROFITS RISING
- DoD's LANGUAGE STRATEGY PAYING OFF
- PROGRAMMING LANGUAGES IN USE BY DoD
- Ada 95 COMPILERS COMING TO MARKET!
This issue of the newsletter highlights the successes early adopters of the new Ada 95 standard have had as they developed software for a range of applications. The Ada 95 success stories in this issue begin with...
Looking only at technology, Airfields is a classic example of a modern information-systems re-engineering effort.
Airfields is an information system that provides commanders with access to many different kinds of information about different airfields and airports worldwide. The COBOL version of Airfields is part of the Worldwide Military Command and Control System (WWMMCS); reengineered into Ada, Airfields will be part of the Defense Information Systems Agency's (DISA's) Global Command and Control System (GCCS), a new, integrated command and control environment.
Airfields is also an example of putting Ada to work - delivering a product within an aggressive schedule, and doing so with limited resources. And it shows the importance of teamwork - with COBOL program-mers moving both the project and themselves to Ada 95.
Teamwork was also important outside the project, and its benefits and lessons learned are going to be available to a wider audience - because Airfields took part in the Early Ada 95 Adopter Partnership program sponsored by the Ada Joint Program Office (AJPO).
Velma D. Blue, Airfields Team Leader, highlighted the importance of both forms of teamwork in getting the job done:
"The success of the project was highly dependent upon a strong and supportive team. Team building is a key ingredient in producing a successful product for users. It must be stated that without the support of the mentors the success of the project would have been more difficult to bring to closure, especially using an Ada 95 compiler before it was matured."
Re-engineering called for a number of things:
To every scenario, a few complications must be added in order for it to be a true, "real world" test of the technology.
In the case of Airfields, the two biggest complicating factors have been: (a) the need to field an operational system under imposed deadlines (driven by the shutdown of WWMMCS); and (b) lack of a complete hardware suite suitable for building the project. The project had to field its first version in early June. (Additional enhancements will be provided throughout the summer.)
DISA initially assembled the Airfields team in October of 1994. There were eight COBOL developers, two managers, one configuration manager/quality assurance and documentation person, and one database expert on loan from another project.
The team was supported by two full-time mentors supplied by the AJPO and one part-time database expert from DISA's Center for Software. From October 1994 to January 1995, the team received training in Ada 83, Ada 95, Unix, and Oracle.
Ada training was provided in two steps: going from a COBOL background to Ada 83, and then going from Ada 83 to Ada 95. The reason for the two- step approach was simple: In the Fall of 1994, no vendor offered an Ada 95 course for non-Ada programmers. (Since then, several courses have been made available. If the team were to be trained today, a single Ada 95 course for non-Ada programmers would be preferred.)
During December 1994 and January 1995, the team assessed the upward compatibility of the Joint Automated Message Editing System (JAMES) Ada 83 software. (See the AdaIC News 1995, "Writing for 95 in 83 - It's been done without Trying!" )
This effort helped the team to understand the environment they were to use on the Airfields project - including the publicly available GNU Ada Translator (GNAT) Ada 95 compiler.
(The team is using the GNAT compiler for initial development and will eventually transition to an ObjectAda compiler from Thomson Software Products to meet DoD requirements to use validated compilers for fielded software.)
By February 1995, the team had gathered enough information about the legacy system to begin their formal requirements-analysis effort.
The legacy system provided a clear baseline of functionality that had to be implemented. So the analysis team focused on analyzing their enhanced, Motif-based, user interface - using the ScreenMachine GUI- builder tool from Objective Interface Systems (OIS). Besides acting as an analysis tool, an additional benefit of ScreenMachine has been the fact that it automatically produces most of the GUI code. This allowed the developers to be more productive and kept them isolated from the details of X-Windows.
The project's schedule and aggressive nature didn't allow the team to receive any formal training in object-oriented technology. But with the informal introduction they received in their Ada training and the support of the mentors, the team was able to approach the analysis and design of Airfields using an informal packaging-oriented approach to good Ada design. Initially, the team concentrated on understanding major Ada design issues such as packaging and private types.
On the advice of the mentors, the team made use of Ada 95 features only where they could be shown to simplify the design. This kept the group from diving into features simply because they were new and exciting. As the design progressed, it became clear that both tagged types and hierarchical library units would be useful in several places in the architecture. Additionally, the team used some of the new predefined units of Ada 95 (e.g., Ada.Strings.Unbounded).
Another benefit of using Ada 95 was the team's ability to use Ada 83 tools to build their software. For example, OIS was able to provide the Ada 83 version of the Screen Machine GUI Builder. The team used this tool and it generated code without modification - even after OIS provided versions that worked with the GNAT and Thomson ObjectAda compilers.
The GUI builder was modified to work with the new compilers, but neither the tool, nor the Ada to X-Windows software that it uses had any Ada 95 features. Similarly, the Oracle Pro*Ada software used only Ada 83 technology. The underlying bindings were ported to GNAT and ObjectAda, but no Ada 95 code was produced by the version of Pro*Ada used here.
A major issue arose as the team was finishing much of the Phase One design, and the tools were being tweaked to work together.
A compiler bug in GNAT temporarily halted the ScreenMachine port. The bug was eventually fixed by Ada Core Technologies, a company formed to support the GNAT compiler; however, in order to reduce project risk, a decision was made to support both the GNAT and Thomson's ObjectAda compilers. At that time, however, the available version of the ObjectAda compiler supported far fewer Ada 95 features than GNAT did.
Design, implementation, and testing proceeded throughout March, April, and May of 1995. Phase One of Airfields was delivered to GCCS for integration into the baseline on June 19. Five additional phases are planned through the summer of 1995. Each will add increasing functionality to Airfields by defining additional reports and queries.
Although Phase One does not implement Airfields' complete functionality, it does contain most of the software that the final version will have. Subsequent phases will add only small amounts of code to the existing framework. Therefore, even though the comparison is not totally accurate, it is reasonable to look at the size of the original Airfields software and contrast it with the new Ada 95 implementation.
The original software was approximately 60K source lines of code (SLOC) of COBOL (not including various optional pieces). This software included the flat-file access routines - which have been replaced by calls to the Oracle database in the Ada 95 version. After Phase One, the Ada 95 version of Airfields was 13K SLOC (";" count). About 6K was produced manually, the rest by reuse or automatic generation. It is estimated that this will grow by approximately 50% by the end of phase 6.
Looking at the project, Ms. Blue summed things up:
"The Ada language was a complex language to grasp initially, but the benefits paid off, and the results were obvious when the team was forced to maintain two parallel systems, Thomson and GNAT.... The team can easily say that Ada has earned its rightful place in their lives. The team would prefer to continue programming in Ada and would not choose to program in any other language."
Although the project is not yet complete, these early results are favorable. The development team and the mentors have encountered their share of challenges. In meeting these challenges, they have cited the strong support of the vendors. And now, an initial Airfields capability - written in Ada 95 - has been baselined as a part of DISA's GCCS program.
To sum it up, DISA has walked its talk by taking Airfields from COBOL on a mainframe to Ada 95 on a workstation running Unix.
The AJPO sponsors the Early Ada 95 Adopter Partnership program as a part of its Ada Dual-Use Initiative. Each project team supplies the personnel, hardware, and environment for the project and takes on the responsibility of producing the software. The AJPO supplies in-kind support in the form of both formal classroom training and hands-on mentoring.
In such a partnership, there are two complementary goals: The project team seeks to reduce the risk of adopting a new technology like Ada 95; the AJPO seeks to gain valuable lessons-learned about Ada 95. These lessons will help reduce the risk to follow-on projects and will help to mature Ada 95 technology by providing feedback on its usage under project conditions.
This issue of the newsletter highlights the successes early adopters of the new Ada 95 standard have had as they developed software for a range of applications. As reported, the news is upbeat and encouraging.
In the last issue of the newsletter, we reported on one test of how well Ada 83 can move to use under Ada 95. Developers took an existing Ada 83 application, the Joint Automated Message Editing System (JAMES), and found it to be 100% upward compatible. The software, which consisted of 48,000 lines of Ada code (counted as carriage returns), required no changes whatsoever to move to Ada 95.
In this issue, our cover story reports on Airfields - a project taking a much greater leap. Part of the Global Command and Control System (GCCS), this database application rides on top of the Common Operating Environment (COE), and identifies characteristics of airfields worldwide for DoD decision-makers. It was moved from a mainframe to a Sun client- server configuration during the past eight months by a government team of programmers at the Defense Information Systems Agency (DISA). The application was converted from COBOL to Ada 95. It was redone to run under Unix and a relational database manager. The team had no Ada experience when they started. Yet they were able to field an operational system quickly and smartly.
Several other early Ada 95 successes are also reported in this issue of the newsletter. The Army at Fort Monmouth is developing several GCCS tool building blocks for the COE . Progress on the Alert Block has been encouraging. (For more, see recommendations for future tools and bindings ) Based upon these successes, several other building-block applications are scheduled to be done in Ada 95 for Version 3 of the COE. In addition to these GCCS efforts, the Marines at Camp Pendleton - at the Marine Corps Tactical Systems Support Activity (MCTSSA) - have agreed to initiate an Ada 95 transition project with the AJPO's assistance.
In the world of weapons systems, the Joint Advanced Strike Technology (JAST ) aircraft program has demonstrated several Ada95 successes this year. They have built a testbed for evaluating the distributed-systems annex of the Ada 95 standard; they will be reusing code from the Navy's Seawolf BSY-2 program; and as part of their scale- up of technology for their on-board platforms, they are aggressively investigating the issues associated with using Ada 95 POSIX real-time bindings. Also, they have sponsored work investigating the use of the Software Engineering Institute's Simplex architecture in Ada 95. Their initial successes have fortified their resolve to use Ada 95 for developing avionics systems for this next-generation aircraft system.
The Air Force's F22 fighter has also made the commitment to move to Ada 95. They have a transition plan in place to move their avionics software from Ada 83. ( See one of the important reasons why such systems are moving to Ada 95. ) The Navy also plans to start transitioning the S-3 aircraft avionics software to Ada 95 later this year.
In the world of missile systems, the Swedish military has made the commitment to use Ada 95 on their BaMSe ground-based radar project . The Swedes join the U.S. Army - which made the decision to use Ada 95 on the Patriot missile system several years ago. The compiler for the Patriot's on-board system will be one of the first to undergo validation during the summer of this year.
A wide variety of other DoD projects are currently planning to use or move to Ada 95 for a variety of applications with the AJPO's help. The Army's WARSIM 2000 simulator requires Ada 95 in its Solicitation. The Navy is investigating a pilot business-system reengineering project in Ada 95 in Jacksonville. DISA plans to reengineer some of its nuclear applications to Ada 95. The Navy is also investigating migration of a test-equipment application to Ada 95. The Defense Mapping Agency is looking to use Ada 95 on its Interoperable Map Software Project. The Air Force's CARDS program at their Electronic Systems Center is developing a Object Request Broker (ORB) for use in interconnecting and operating the DoD's software reuse libraries in Ada 95.
In addition, several commercial ventures are adopting Ada 95. Several are developing products using it, while others are focusing on generating applications.
The messages that you should be getting from the reports in this newsletter are: (1) DoD is committed to Ada 95; (2) early-adopter results to date are promising; (3) DoD is already starting to use Ada 95 in a variety of information systems, weapons systems, and command and control applications; and (4) the risks associated with transition seem manageable. These messages seem just cause for me to continue to be upbeat about the potential of Ada 95. The bottom line is that people are using the language, not just talking about it.
The most frequent questions I get asked about Ada 95 seem to revolve around when production compilers, bindings, and tools will be available. As illustrated in Table 1 on page 10, the vendors are starting to release Ada 95 compilers, bindings, and tool products. A summary of public vendor plans and validation schedules for the compilers is available from the Ada Information Clearinghouse. Needless to say, most of these products will not provide full support for the Ada 95 standard. However, support for Ada 83 and the new features users seem to want most (support for object-oriented techniques, the revised tasking model, child libraries, and defined bindings to other languages) will be readily available.
Remember Ada is the only internationally standardized object-oriented programming language. It provides upward compatibility for Ada 83 software and full support for object-oriented techniques. Ada 95 is accepted as a standard by the International Standardization Organization (ISO/IEC 8652:1995), the American National Standards Institute (ANSI 8652:1995), and it's a Federal Information Processing Standard (FIPS 119-1). As such, it fully complies with direction from Secretary of Defense Perry to use only commercial standards.
Ada 95 also supports DoD's emphasis on the use of commercial-off-the- shelf (COTS) software. The bindings the AJPO is providing (see Tables 2 and Table 3.) through our existing investment strategy are aimed at enabling COTS users to interface their applications with their Ada code quickly, simply, and inexpensively. These bindings will enable our users to take advantage of the growing amount of COTS software that is available.
In summary, now's the time to join the early majority and use Ada 95. I believe that it is a technology ripe for the time. Those of you who were at the Software Technology Conference this April in Salt Lake City know that many others within the Defense community (including the Seniors) share my optimism. It is time for you to make the commitment to use Ada 95.
As many of you know, I am wearing many hats. In addition to running the AJPO, I manage the Software Reuse Initiative for the DoD, and act as the Technical Advisor to the Deputy Commander of DISA, who runs the Center for Software within DISA's Joint Interoperability and Engineering Organization (JIEO). The Center for Software is bringing Dr. Charles Engle on board to off-load some of my responsibilities and to run the AJPO to ensure Ada's continued success. Dr. Engle is a long-time Ada advocate. He is well known to the Ada community and will be able to help take Ada 95 the next steps. I will remain involved during the remainder of my assignment with DISA in an oversight capacity. It is great to be associated with a winner.
Donald J. Reifer, Chief
Ada Joint Program Office
By Capt Jules Bartow, USAF
The Joint Advanced Strike Technology (JAST) program is chartered to mature and demonstrate affordable technologies for the next-generation strike fighter for the Air Force, Navy, Marine Corps, and Allies. JAST systems are to replace the F-16 and the AV-8B, as well as provide a survivable first day of the war strike fighter for the Navy in the 2010 timeframe.
For JAST, one crucial element is the affordability equation - a function of meeting the warfighter's needs within costs. The key to unlocking that equation is open systems. However, you can't put "open systems" as a requirement in a contract - because you can't test it or validate it. You can go to the Technical Architecture Framework for Information Management (TAFIM) document for a list of commercial standards that are acceptable, but you won't find anything for integrated, secure, reliable, safety-critical hard real-time systems found in strike fighters.
JAST is changing that. They're getting hard data to make sure open systems support the four pillars of lethality, survivability, supportability, and affordability.
In April, at the Software Technology Conference (STC) in Salt Lake City, JAST reported on some of its progress. What kind of hard data did JAST demonstrate?
For starters, using features of Ada 95's Distributed Systems Annex, 16,000 lines of uniprocessor Ada 83 code for a trainer were ported and optimized across three processors. The total time from contract award to demonstration was less than two and a half months, including hardware procurement.
Pat Rogers, SBS Engineering, Inc.'s lead engineer for the Ada 95 evaluation, says, "It was easy to implement the Ada 95 features. That took less than 40 hours. The hard part was integrating the device drivers for the new target boards - even though the old board and the new boards both use the same [commercial off-the-shelf] COTS processor. That took an additional 80 hours".
"We had initially intended to do a very simple demo, but Capt Jules Bartow, Project Manager from the JAST program office, demanded that the demo be relevant to a strike fighter. One of our sister divisions makes trainers, so we asked them if they had any software that we could use. A couple of hours later, via the Internet, we had what we needed from an algorithm and environmental models standpoint."
Unfortunately, the display software could not be used because it was highly specialized for unique hardware. At this point, the project said they could provide some display software as government-furnished equipment (GFE) to keep the costs down. Some of the developers were less than enthusiastic at the prospect of throwing in an unknown quantity. (One viewed such help about like an Inspector General's (IG's) visit. "The IG is here to help you.")
As it turned out, the project was able to create new cockpit displays using an automatic code generator at the Air Force's Wright Laboratory (WL). In addition, WL provided the Ada out-the-window and heads-up display software. This software was modified and integrated into the strike fighter simulation. Ada's strength during integration phase was clearly evident
No human being writing code is perfect, and there is always the possibility that a bug might sneak through even the most exhaustive testing. The chance of introducing an error increases dramatically when a system is modified to meet new requirements that were not anticipated by the original design. JAST is a high stake game with a long life cycle. It has to be ready for such problems before it happens.
And in keeping with the need for using open systems to keep cost down, the Ada code is going to be working with Portable Operating System Interface (POSIX). To test this combination and to mature the technology for reliable system evolution, JAST went to the Software Engineering Institute (SEI).
As a test, an SEI team used real time extension of POSIX (POSIX.1b) for a software fault tolerance architecture demonstration that controls an inverted pendulum, an inherently unstable device. The demonstration allows members of the audience to upgrade the control software on the fly, while ensuring that the system will never lose the control in spite of arbitrary application errors.
Dr. Lui Sha, who heads the team, said, "We had originally coded this in C/C++, since C/C++ and POSIX.1b was a mature technology. It is also easier to insert all kinds of bugs as part of the software fault tolerance demonstrations. It is pretty clear to JAST that they're going to use Ada, so that JAST can leverage F-15, F- 16, F-18 and F-22 software investments. The question is, is the Ada 95 and POSIX.1b combination mature enough to support the performance and fault tolerance requirements needed for affordable tactical aircraft avionics?"
Since there was no Ada 95 compiler for POSIX.1b commercially available, the SEI started to port the Free Software Foundation's GNU Ada 95 Translator (GNAT) to a commercial POSIX.1b OS, the Lynx OS. This permited the system upgrade/fault tolerance demonstration to be ported to Ada 95. In fact, the software architecture allows the control software originally written in C/C++ to be replaced with Ada 95 software on the fly without shutting down the demonstration.
You don't get something for nothing. Part of GNAT's licensing agreement is that if you distribute any improvements you make to the compiler, they must be made available to the world at no charge. As a result of the SEI work, there is yet another POSIX.1b compliant OS and host machine (Intel x86) that an Ada 95 compiler is available for. That is a step towards portability and reuse of legacy software for JAST - a demonstrated capability to meet real time and fault tolerant requirements on a small scale.
Next, JAST needs to scale up the Ada/POSIX based demonstrations and put them in the context of real flying tactical hardware.
One of JAST's concerns is open-systems security. Minerva Rodriquez, an expert in operating-system security, compared POSIX real-time interfaces to the Hughes avionics operating system (AOS) used on the F-22 and F-18. There were both security and performance issues with POSIX's real-time interfaces: timers, signals, and semaphores.
For instance, POSIX uses two types of semaphores versus one. These semaphores can be shared between processes, which creates an unarbitrated data channel. This is not good from a security perspective.
In addition, arming a POSIX timer can take 5-10 times longer than the AOS. This is due to POSIX's time definition as a 64-bit word using nanoseconds, whereas the demo used the i960MX, a 32-bit processor with native resolution of microseconds.
JAST has to look at the rest of POSIX interfaces to see which ones are appropriate for tactical aircraft avionics. The program is working with Wright Laboratory, the Defense Information Systems Agency (DISA), the Next Generation Computer Resources (NGCR) effort, and the Portable Applications Standards Committee of the Institute of Electrical and Electronics Engineers (IEEE) to come up with a profile of the interfaces that will be needed prior to starting Engineering & Manufacturing Demonstration in the year 2000.
Not only is JAST looking at ways to handle coding errors, but they're building software that handles data errors as well. The Analytical Science Corporation's Data Fusion Integrity Process (DFIP) allows a software developer to choose Ada 95 procedures from a library of fault- tolerant techniques.
Using actual data captured off an F-16 MIL-STD-1553 data bus, you can explore the robustness of a bombing algorithm in conjunction with a DFIP. The simulation provided a "god's eye" view of the ingress into the target area and dropping of a MK-84 General Purpose Bomb.
Why would brown-shoes use tube-rat stuff? The answer, quite simply is, there are more planes in the sea than there are submarines in the air. However, JAST doesn't expect to add to that number when they reuse 9.6 thousand source lines of code of Ada Seawolf Submarine software.
The developer of the Seawolf BSY-2 Submarine Combat System tried to integrate a commercial off-the-shelf (COTS) database management into their design. Unfortunately, there wasn't any way to make it simple, fast, and deterministic enough for sonar tracking. They eventually did the job entirely in Ada. The same constraints apply to radar, target, and threat tracking in an aircraft. So, instead of re-inventing a real- time database manager, JAST is leveraging Wright Lab investments in the Reuse and upgrade of the SeaWolf Database Manager.
JAST is also leveraging the Advanced Research Project Agency's (ARPA's) work in domain-specific software architectures. Instead of writing software, the engineer can pick and choose components and the system automatically composes the system and optimizes it.
JAST brought together Loral's frontend Avionics Domain Application Generation Environment (ADAGE) with Honeywell's backend compilation and optimization program, MetaH. So far, there's been an order of magnitude improvement in how fast software can be put together.
What's the intermediate language? Ada 83. There's a proposal in to upgrade MetaH to Ada95.
Besides the JAST demonstrations at STC in April, there were also JAST demos June 13-15 at the Test Facilities Working Group Conference in Las Vegas.
Questions can be referred to Capt Bartow at 703/602-7390 x6624, or to Marc Pitarys at 513/255-6548. The SeaWolf Reuse contact is Mike Bohler at 513/255-4952.
By Torbj÷rn Andr_asson and Ingemar Carlsson
In Sweden, one project has been writing and compiling Ada 95 since November 1993 - well before this year's final publication of the International Standard.
In May 1993, Ericsson Microwave Systems (then called Ericsson Radar Electronics) entered into a contract with the Swedish Defence Materiel Administration (Forsvarets materielverk - FMV). The contract was for development of part of the BAMSE Air Defense system - the Swedish Army's new intermediate-range, ground-to-air missile system. Ericsson would develop the Combat Control Centre (CC Centre) of the UndE search radar and associated command-and-control system.
Using GNAT to get ahead of the pack with object orientation
The people at Ericsson Microwave wanted very badly to use object- oriented techniques - perhaps inspired by Ericsson Telecom's push into object orientation with C++. They initially bid the project in C++, but that was before they were presented with the Ada 9X Project schedule and the availability of a compiler - the GNU Ada 9X Translator (GNAT). After discussions of principles, etc., they decided to do the project in Ada 95.
From the beginning of the project, developers were convinced that they would benefit from mapping object-oriented models on an object-oriented language.
The size of CC Centre software in Ada 95 is substantial. Including automatically generated code, it will approach a million lines of code. Reuse is also an important factor. The CC Centre is an extension of Ericsson's successful Giraffe Radar Series, so there is reuse of old Eripascal code - primarily in the basic radar portions.
This was and is a full-scale development project, and at the same time FMV's first Ada 95 application. So both Ericsson and FMV were taking some risk here. With the enthusiasm of the key software people at Ericsson Surface Radar Division, however, and the progress they saw being made by Ada 9X, both FMV and Ericsson concluded it was a reasonable proposition.
It is still certainly not risk-free - especially, the most desired aspect, object-orientation, is not without challenges.
Nonetheless, a solid track record has been established. As noted, Ericsson has been using the GNAT compiler since November 1993; also, since May 1994, they have been using ObjectAda from Thomson (formerly Alsys); they expect they will deliver the first system compiled with a validated Ada 95 compiler.
GNAT is also being used by a team implementing the Client/Server Generator (CSGEN) - a tool for generating distributed Ada/C/C++ applications. (With CSGEN, developers do not need to rewrite existing functions when creating distributed client/server applications from stand-alone programs.) CSGEN will probably be used in the project until their compiler vendors provide an implementation of Ada 95's Distributed Systems Annex.
The Swedish BAMSE system will mainly be used for the protection of vital objects such as air bases, naval bases, headquarters, etc., and for protection of ground combat forces. The system will be highly mobile. It will have cross-country capability, and be transportable by air without any extensive preparation.
The CC Centre in the BAMSE system is an autonomous unit, mounted on a vehicle; it is a true 3-D search radar that must achieve short reaction times against all types of threatening targets. The operator's compartment includes two workstations that will be operated by a radar operator and a tactical-control operator. The work stations contain command, control, and communications (c3) computing facilities and the man-machine interface (MMI).
The project is being developed against projected threat far beyond the year 2000.
You can plan your next vacation with roadmaps, but it's a lot better if you can get first-hand reports from people who have tried out the hotels, sampled the food, and figured out the best way to get from the hotel to the airport. You probably want those reports from people who are just as demanding as you are.
Ideally, you might even want comparisons from different people.
The Common Operating Environment (COE) project is working on that for projects that are preparing to move to Ada 95.
The COE is a command-and-control environment that has grown out of the Army Common Hardware Software (CHS) Program and the Global Command and Control System (GCCS).
The COE Ada-95 effort is a series of shadow projects that will take individual COE components and transition them to Ada 95. Currently, those COE components use several programming languages - predominantly Ada 83, C, and C++. The first effort involving Ada 95 is the COE's Alert Block software, which provides a standard way for user applications to initiate and manage alerts to the system.
Since the COE Ada-95 effort is a shadow project, it will parallel the original development effort to complete the Alert Block software in Ada 83.
The COE Ada-95 effort is designed to provide a lot of real-world data for projects moving up to Ada 95. One area of interest is how easy it will be for projects to reuse their Ada-83 code in Ada 95 development efforts. Because project managers want as much data as possible, to highlight all the factors that are at work, one of the jobs of the COE Ada-95 effort is to assess Ada 95's compatibility with Ada 83.
The COE project will also assess Ada 95's new real-time features. Enhancements to the tasking model and the introduction of protected types for instance, provide opportunities for improved real-time performance. Data from the COE project will give other projects hard data on Ada 95's performance as compared to Ada 83. The effort is to measure both the run-time speed and code-size efficiency of selected Ada 95 features. (For instance, what code-size savings are related to child libraries? What's the overhead impact of using pragma Import?)
The COE effort is taking place in a demanding environment. Command and control software requires high performance both in terms of speed and in terms of features; it must do its job within real-time constraints; it must be adaptable to changing circumstances; it must conform to high quality standards.
Those are demands that led to Ada in the first place, and led to Ada's upgrade to the new features of Ada 95. The COE is putting Ada 95 to the test, and giving the rest of the Ada community a better picture of what to expect and how to make their trip more profitable.
In the Ada 95 Adoption Handbook - a Guide to Investigating Ada 95 Adoption, Version 1.1, 31 March 1995, the Ada Joint Program Office (AJPO) suggested that many projects may want to adopt an incremental strategy in adopting Ada 95. One project that is taking such an approach is the Navy's S-3B aircraft avionics effort as it considers moving from Ada 83 to Ada 95.
The project has opted for a "conservative" approach - where the use of new features would be restricted to those with the highest payoff for the S-3B.
Basically, for a new Ada 95 feature to be adopted, it will have to meet one of the following criteria: 1) It is necessary to meet the requirements of the S-3B program. 2) It will make a significant contribution to software-development productivity or reduce maintenance costs - and do so without any undue penalty in application performance. 3) It more naturally reflects the algorithm being coded - again, without undue application-performance penalty.
To start, the project will be ensuring that code written in Ada 83 will be compatible with Ada 95. The project will be using guidelines recommended in the Adoption Handbook, and covered in the Spring issue of this newsletter. (See "How Can I... Write Ada-95-Compatible Code Using Ada 83?")
For copies of the Adoption Handbook, its companion Ada 95 Transition Planning Guide, or a flyer on the compatibility guidelines, contact the Ada Information Clearinghouse (AdaIC) at 1-800/232-4211. These documents can also be downloaded from the the AdaIC's Internet host (sw-eng.falls-church.va.us).
One measure of Ada 95's rapid advance into the market is the number of bindings efforts that have been verified as already underway on the heels of Ada 95's acceptance as an international standard. (See Table 1.)
Bindings are critical in maintaining Ada's current growth, and increasing its success in new areas. Ada applications have to be able to access whatever resources an end user will wish to control. This frequently requires Ada bindings to other standards and protocols that control such resources.
The Ada Joint Program Office (AJPO) has been deeply involved in bindings efforts for Ada 83; looking ahead, it had the Institute for Defense Analyses (IDA) propose an Ada 95 Bindings Plan. (See the discussion of a similar plan for Ada 95 tools and libraries.) The Bindings Plan is intended to provide a rationale for current and future AJPO investments in bindings, and to encourage third-party development of bindings.
The Plan recommends creating two action plans: one aimed at the growth of a self-sustaining bindings marketplace; another to address each major area where the number of currently available bindings can be increased. Overall, the Bindings Plan is intended to identify the high-priority bindings that allow end-user Ada programmers to take advantage of existing software systems without constraints.
For the near term, the Plan points out the need to update, correct, or complete existing bindings that are not getting used (See Table 2). Also, new bindings need to be created in order to speed the adoption of Ada 95 in the marketplace (See Table 3). The Unix-workstation market and the PC market are the focus of the near-term plan, since they have the most rapidly growing market share.
The AJPO plans to encourage third parties to develop bindings by providing cost-sharing incentives. Under its Ada Technology Insertion Program (ATIP), the AJPO will work with DoD systems developers to fund and produce bindings for high-demand environments (such as distributed computing); also, the AJPO will fund public-domain bindings to high- demand commercial-off-the-shelf (COTS) products.
IDA's recommendations are the result of ongoing input from the Ada community. Perhaps the most notable input came at the Second Ada Dual- Use Workshop, held Feb. 6-8, 1995. (See "Dual-Use" in the previous issue.) The authors sought information from other sources, as well - including surveys, selected project interviews, historical files, and from informal input from working groups of the Association for Computing Machinery's Special Interest Group on Ada (ACM SIGAda).
Ada applications have to be able to access whatever resources an end user will wish to control - which frequently requires Ada bindings to other standards and protocols that control such resources. A "binding" is essentially conceptual - a definition of how Ada should interface with the other standard. A programmer still needs a product that implements the binding.
Tracking bindings and bindings products is the purpose of the Ada Information Clearinghouse's "Available Ada Bindings" report. For a copy of the 1994 edition of this report, contact the AdaIC.
|IEEE 488 GPIB||PC|
|IEEE 1003.1g (protocol independent communication - sockets)||Workstation/PC|
|IEEE 1003.1b-1993 and 1003.1c-1994 (real-time extension and threads)||Workstation|
|IEEE 1295.1 (Motif) draft||Workstation|
|Mail Application Programming Interface (MAPI)||PC|
|OS2 Presentation Manager||PC|
|MACH kernel API||Workstation|
|Persistent Object||Base Workstation|
|Xt, Xlib (X11R6)||Workstation|
|IEEE 1003.1g (sockets)||Protocol Independent Communications||1|
|IEEE 1003.b-1993 and 1003.1c-1994||Real-time extensions and threads - V||1|
|DCE||Distributed Computing Environment - S, I, V||1|
|Paradox||PC database - S, I||1|
|1533 Bus||Avionics bus - V||1|
|IEEE 1295.1 draft||OSF Motif - I, V||2|
|DIS||Distributed Interactive Simulation - V||2|
|IEEE 1003.1d (more POSIX real-time extensions)||V||1|
|Existing WWW product Standard||S, I, V||1|
|Sun/HP version of ODBC 2.0||I, V||1|
|IEEE 1003.1e (POSIX Security extensions)||1, V||1|
|IEEE 1003.1f (POSIX Network extensions)||S, I, V||1|
|Simple Mail Transfer Protocol (SMTP)||S, I, V||1|
|Portable Document Format (PDF) reader/writer||S, I, V||1|
|Lotus 123 File format reader/writer||S, I, V||1|
|D-base DBF reader/writer||S, I, V||1|
|Windows Meta File reader/writer||S, I, V||1|
|Netware APIs||S, I, V||1|
|Graphical Formats (GIF, TIFF, JPEG, etc.) reader/writer||S, I, V||1|
|Common Operating System Environment (COSE) Spec 1170||S, I, V||1|
|COSE Common Desktop Environment (CDE)||S, I, V||1|
|SVR4 APIs||S, I, V||1|
|VXI bus||S, I, V||2|
|1553B bus||S, I, V||2|
|ODBC 3.0||S, I, V||2|
|SQL 92 - three levels of conformity||S||2|
|CDIF reader/writer||S, I, V||2|
|Sytem Object Model (SOM)||S, I, V||2|
"Any change involves risk", we're often told. But sometimes, change is essential as a means to reduce risk.
That's exactly one of the elements facing developers of weapon-systems software - who have been using Ada 83 for some time now.
Ada 83 has always been a good choice for developing safety-critical software, due to its strong typing, information hiding, etc. However, Ada 95 has improvements specifically intended to give greater support to safety-critical applications. One improvement that is important to such projects is Ada 95's access-to-constant type.
In flight-control software, large tables of data are used to help determine the aircraft's response to system inputs. As a compromise between efficient use of memory and throughput, this table is usually stored using access values to connect the various parts of the table. Ada 83 expects such access values to be stored in the Ada "heap" - an area in writeable memory. With most weapon systems, there's only a relatively small amount of writeable memory as opposed to read-only memory. With the relatively large size of the table, therefore, developers have used Ada 83's unchecked_conversion function and other tricks to store the access values in read-only memory.
Whenever unchecked conversions are used, however, the burden is shifted from the compiler to the programmer to ensure that the conversions maintain the properties that are guaranteed by the language for objects of the target type. This weakens Ada's strong typing.
Ada 95 provided for just such a situation as faced by the weapon-systems developers: the data can now be efficiently and portably defined using the access-to-constant mechanism.
Obviously, Ada 95's improved reliability is just one factor in upgrading. But it does make clear that "risk" is relative to your situation. Sometimes, moving forward is the best way to reduce risk. If you have a safety-critical situation, maybe you should be doing what many others are - putting Ada 95 on the agenda.
The Plan points out the importance of using the strengths of Ada itself to improve a tool's capabilities and usefulness.
As Ada moves more and more into the commercial marketplace, it faces competition from aggressively marketed alternatives. Usually, those alternatives are not marketed on the basis of a language's inherent technical strengths - an area where Ada has a commanding advantage. Instead, the commercial competition is marketed on the tools, libraries, and features that surround a language - the programming environment.
For Ada 95 to compete aggressively with the competition, then, the development of tools and libraries is a major objective. Responding to this need, the Ada Joint Program Office (AJPO) had the Institute for Defense Analyses (IDA) propose an Ada 95 Tools and Libraries Plan.
In turn, IDA analyzed the most commonly available environments for C, C++, and BASIC - Visual BASIC and Visual C++ from Microsoft, and Centerline C. It also sought the views of Ada users, such as participants at the Second Ada Dual-Use Workshop.
In developing its recommendations, IDA focused on two of the most important developments in the market: the rise of "visual programming" products (e.g., Visual BASIC and Visual C++), and the need for support of distributed systems.
IDA's Tools Plan identifies the tools and techniques used by the most successful commercial environments. Doing so helped to identify a model to which developers can add Ada-specific capabilities - creating a product superior to the current commercial alternatives. The Plan's reference model for tools and libraries provides a single vision for their construction. (See Table 1.)
IDA's Plan lists a minimal tool suite - compiler and source-level debugger, visual workspace, embedded workspace, browser, inheritance manager, configuration manager, and metrics manager. But it does not enumerate a fixed list of tools with a fixed list of features that must be created. Those elements are the sphere of user demand and vendor resources.
Instead, the Plan's recommendations for development are phrased in terms of the general requirements any tool will have to meet, regardless of its particular features.
For instance, tools must be integrated into a single environment. To give users the widest possible choice and vendors the widest possible market, interfaces and methods of integration should be based on generally accepted standards. The Plan lists nine such standards. (See Table 2.)
The Plan's reference model for tools and libraries breaks down the environment into three layers: framework, domain-specific, and task- specific. The framework layer provides the parts necessary to construct tools easily. The domain-specific layer provides users with individual tools that perform particular actions. The task-specific layer provides a collection of tools bound together to accomplish a goal.
In some sense, IDA's recommended Plan can be said to be a preliminary manual for the creation of future tools - where many of the particular features are not even on the market yet.
The Plan points out the importance of using the strengths of Ada itself to improve a tool's capabilities and usefulness. In other words, Ada can take tools beyond what is currently on the market.
A good example of this is semantic-based test tools. Such tools will have much more information available at their disposal when processing Ada code as opposed to other languages such as C or C++. Such advantages (for instance, ranges on discrete types) should be exploited, and appropriate test cases developed. Each tool that is being considered can be improved by accessing Ada's extra semantic information, and increasing the overall quality of the tool.
|Layer:||Component and Interface Types:||Examples:|
|Framework [Basic Layer - composed of parts used to create tools]||Components - Foundation Classes||Libraries, Class Hierarchies Bindings|
|External Interfaces||Multimedia, Communications, Databases, Buses, Reuse Libraries|
|Domain Specific [Applications for tools particular for a domain]||Components - Stand-alone Tools||Program Management tools, Rate Monotonic Analysis Tools, Filters|
|Component Interfaces||OMG Cobra IDL, Microsoft OLE|
|Task Specific [Collection of applications to accomplish a particular goal]||Components - Connected Tools||Aggregates of domain-specific tools and components|
|Tool Interfaces||TCL, Pipes, Object Brokers|
The following standards support various types of tool interfaces, and methods of integration. They should be incorporated into any design of a programming environment.
|ANSI X3H6 Tool Integration Models Specification|
|OMG Common Object Request Broker Architecture (CORBA)|
|ECMA Portable Common Tool Environment (PCTE)|
|CASE Data Interchange Format (CDIF)|
|IEEE-1175 Semantic Transfer Language|
|IEEE-1420 2 RIG Basic Interoperability Data Model (Draft)|
|ISO Ada Static-Semantics Interface Specification (ASIS) (Draft)|
|Microsoft Object Linking and Embedding 2.0 (OLE) (Product Standard)|
|Microsoft Component Object Model (COM) (Product Standard)|
More than 6,000 files, covering virtually every aspect of Ada , are available 24-hours a day on the AdaIC's Internet host: sw-eng.falls-church.va.us
Computer users who don't have Internet access can obtain Ada information on the AdaIC Internet host via our dial-up line. Call the AdaIC at 1/800-AdaIC-11 (232-4211) or 703/681-2466 for help in getting connected!
Two advances are underway for the application-development system AdaSAGE.
First, it is moving to Microsoft Windows - it is currently in beta test under WIN 32 and WIN 32s. The emphasis on future enhancements (particularly those involving user interfaces) is set to be in the Windows development area.
Also, AdaSAGE is being upgraded to support developers working Ada 95's new object-oriented features.
AdaSAGE will be made available on several Ada 95 compilers: Work is already underway to port it to the Free Software Foundation's GNU Ada 95 Translator (GNAT) under Linux and under Windows NT; the port to a commercial Ada 95 compiler is still to be determined, depending on availability, etc.
AdaSAGE's Ada 95 applications framework will provide developers a means of accessing AdaSAGE facilities as objects and classes through the object-oriented paradigm. In the area of open architecture, the new application framework will allow third-party developers a viable means of integrating their products into AdaSAGE, whether they are objects, classes, components, or tools. AdaSAGE will have a dynamic-link library (DLL) interface, which will allow commercial and other reusable code to be integrated into AdaSAGE applications.
Also, the AdaSAGE environment will provide a dynamic object component registration tool for registering commercially developed components. Along with this capability, there will be a component development library, which will assist third-party developers with the integration of their products into AdaSAGE.
For further information on AdaSAGE or details on obtaining copies, etc., contact the Ada Information Clearinghouse at 1-800-232-4211.
These newsbits have been extracted from the AdaIC's "Newsflashes"- a regular news feature that is sent out electronically on a weekly basis. To be added to the distribution list, please send e-mail to: adanews@ sw-eng.falls-church.va.us
DDC-I, Inc.'s Ada Compiler System for the Intel i386 (DACS-80386 PM) has been selected for India's Light Combat Aircraft (LCA), reports the Spring issue of DDC-I's Real Time Journal. The LCA is under construction by the Aeronautical Development Agency in Bangalore, India, and is the world's smallest, light weight, multi-role combat aircraft. Real Time Journal reports that the LCA designed to meet the requirements of the Indian Air Force as its frontline multi-mission single seater tactical aircraft during the period 2000-2020.
The DDC-I Ada Compiler System is used to implement the Avionics System of the Mission Computer, which is based on a dual Intel i386 architecture.
["DDC-I on Indian Light Combat Aircraft", Real Time Journal, Spring 1995, DDC-I, Inc., 410 North 44th Street, Phoenix, AZ 85008]
The Best New Object Technology Development Product award went to Rational Software Corporation for version 2.7 of its Rational Rose family of tools at ComputerWorld's Second Annual Best New Object Technology Product Awards held recently at Object World Boston.
The Rational Rose family has long supported the Ada language and object- oriented application development. The new generation offers expanded support for Ada (and other object-oriented languages) in controlling iterative development. It also features expanded support for document generation, increased extensibility, and improved support for round-trip engineering.
[Rational Software Corporation, 2800 San Tomas Expressway, Santa Clara, CA 95051-0951; 408/496-3600 or 800/RAT-1212; fax: 408/496-3636; e-mail: product_info@ rational.com]
The May 1995 issue of Defense Electronics features an article by Joyce Tokar, titled, "Ada 95: Getting the Bugs Out."
Tokar discusses the revisions made to Ada 83 after the Ada community initiated the language revision process in 1988. She also reports, in detail, the enhancements made to the Ada 95 real-time model: the protected type, the requeue operation, the asynchronous transfer of control statement and the delay until statement.
["Ada 95: Getting the Bugs Out", Joyce L. Tokar, Ph.D, Defense Electronics, May 1995 (Vol. 27, No. 5); Argus, Inc., 6151 Powers Ferry Road, N.W., Atlanta, GA 30339-2941; 404/955-2500]
An article in the May issue of Object Magazine notes that the new Ada 95 standard is not merely object oriented, but it is the first and only internationally standardized object-oriented programming (OOP) language. The author, Richard Riehle, of AdaWorks Software Engineering, says that Ada 83 needed only a few syntactic and semantic changes to enable the three OOP features it lacked: inheritance, dynamic binding, and polymorphism.
Riehle continues with a discussion of the revision process - and further comments on programming by extension, child packages, inheritance, dynamic binding, and abstract classes.
["Ada 95: The New Object-Oriented Standard," Richard Riehle, Object Magazine, May 1995; Adaworks, 2555 Park Boulevard, Suite #27, Palo Alto, CA 94303; 415/328-1815]
The DDC-I Ada Compiler System (DACS) has recently been integrated with Rational Software Corporation's Rational Apex. DACS can now be used from within the Rational Apex development environment.
["Rational Apex Integration", Dan Troftgruben, Real Time Journal, Spring 1995; DDC-I, Inc., 410 North 44th Street, Phoenix, AZ 85008]
Under a value-added reseller (VAR) agreement with Atria Software, Inc., Thomson Software Products will integrate and distribute its Ada development environments with Atria's ClearCase and ClearCase MultiSite configuration-management products.
The integration of ClearCase products with Thomson's AdaWorld and ObjectAda provides a number of benefits to Ada-based development teams according to Jacques Brygier, director of Ada product marketing. The agreement, he said, will allow Thomson Software Products to "provide a highly-integrated, single-source solution to meet the increasing demands of mission-critical, business-critical, and safety-critical Ada applications developers."
[Thomson Software Products, 67 South Bedford Street, Burlington, MA 01803-5152; Karen Johnson, 619/457-2700]
Two of the largest compiler companies, Thomson Software Products and Rational Software Corporation, have announced record profits, which can be attributed in part to their Ada strategies.
[Source: Kara Myers, Rational Software Corporation, 2800 San Tomas Expressway, Santa Clara, CA 95051-0951; 408/496-3600 or 800/RAT-1212; Karen Johnson, Thomson Software Products, 67 South Bedford Street, Burlington, MA 01803-5152; 619/457-2700]
Military Departments and DoD Agencies have made great progress in reducing the number of programming languages in use. Since 1977, there has been more than a 90% reduction in the number of languages used in DoD systems, according to an Institute for Defense Analyses (IDA) study released in January 1995.
The frequently quoted 1977 study provided some of the early justification for the DoD to create one programming language that would meet the needs of all of its systems. The one programming language, Ada, is at the top of the usage lists for Weapon Systems and Automated Information Systems (AIS).
* Existing weapon systems written in third-generation languages contain more Ada source lines of code (SLOC) than any other language. There are 49.7 million Ada SLOC in today's weapon systems.
* AIS developers are choosing Ada more often than any other third- generation language, except for COBOL.
Call the AdaIC at 1-800/232-4211 or 703/681-2466 to order your copy of A Survey of Computer Programming Languages Currently Used in the DoD, January 1995.
The Ada Calendar is available for downloading from our Internet host, accessible via ftp, Gopher, and the World-Wide Web. You can also call the AdaIC for further information on the following Ada conferences, seminars, and workshops. Please let us know if your organization is sponsoring an Ada event!
*The AdaIC will have an exhibit. We sometimes have free passes to conference exhibit areas where the AdaIC will have an exhibit. Feel free to call and ask for available passes.
The Ada market's largest and most successful Ada 83 compiler vendors are gearing up their product line for Ada 95. The following vendors have already announced their plans to validate compilers for Ada 95:
These companies provide 68.8 percent of the currently
validated Ada 83 compilers!
|Vendor||Percentage of Available Ada 83 Compiler Market|
|Irvine Compiler Corp., Inc.||2.4%|
|OC Systems (IBM)||3.8%|
|Rational Software Corporation||3.3%|
|Meridian (now owned by Rational)||5.2%|
|Verdix (now owned by Rational)||20.9%|
|R.R. Software, Inc.||1.0%|
|Silicon Graphics, Inc.||0.7%|
|Sun Microsystems, Inc.||0.6%|
|Thomson Software Products (Alsys)||17.7%|
|TeleSoft (now owned by Thomson)||2.6%|
The Ada Information Clearinghouse (AdaIC) publishes information on the Ada community's events, working groups, research, publications, and concerns. The AdaIC provides its services free of charge to the governmental, academic, and commercial software communities.
This service is sponsored by the Ada Joint Program Office (AJPO), which facilitates the implementation of the DoD's Software Initiative (Ada) throughout the Services, and maintains the integrity of the language. IIT Research Institute operates the AdaIC out of the AJPO offices in Arlington, Virginia.
Ada Information Clearinghouse
P.O. Box 1866
Falls Church, VA 22041
Ada Joint Program Office Defense Information Systems Agency Code JEXC 5600 Columbia Pike Arlington, VA 22204-2199 Phone: 703/681-2463 DSN: 761-2463
The views, opinions, and findings contained in this report are those of the author(s) and should not be construed as an official Agency position, policy, or decision, unless so designated by other official documentation.
Copyright 1995. IIT Research Institute. All rights assigned to the U.S. Government (Ada Joint Program Office). Permission to reprint this newsletter, in whole or in part, is granted, provided the Ada Information Clearinghouse is acknowledged as the source. If this newsletter is reprinted as part of a published document, please send the AdaIC a courtesy copy of the publication. The AdaIC is sponsored by the Ada Joint Program Office.