AdaIC form G89-1091a
file SUCCESS.HLP

Ada Information Clearinghouse, 1-800/AdaIC-11, 703/685-1477

                             10 Ada SUCCESSES

                               By John Keller

Reprinted from Military & Aerospace Electronics, August 1991, Copyright 1991, 
Sentry Publishing Co., Inc., Westborough, MA 01581

Two or three years ago, a search for 10 unqualified Ada success stories would 
have turned up a whole lot of nothing.  A litany of General Accounting Office 
reports told one Ada horror story after another, of Ada code that wouldn't 
run, qualified programmers who couldn't be found, and concurrent software 
engineering projects that became so entangled that project managers had to 
scrap them and start over from scratch.  Leery of cost overruns and delays, 
program managers willingly granted waivers to the Pentagon's Ada mandate to 
virtually everyone who asked for one.

Now the industry has matured.  At the dawning of a new decade, Ada has 
overcome its greatest setbacks.  Today, successful Ada implementations are 
relatively easy to find.  Quality compilers and debugging tools are finally 
readily available for virtually any host environment and target processor -- 
and from a range of competing vendors.  Congress has given the Defense 
Department's mandate the force of law, and DoD has responded with a no-waiver 
policy designed to stop the easy-waiver practices of years past.  More 
important still is an Air Force study that shows, for the first time, that Ada 
really is living up to its promise of offering better maintainability, 
reusability, and programmer productivity than competitive languages.

This month, Military & Aerospace Electronics showcases 10 projects that can 
make Ada experts proud, rather than cringe and send them searching for cover.  
Some are big efforts, some small.  Some for embedded and real-time 
applications, some for desktop information-management jobs.  But no matter 
what the application, all of these efforts share at least one common 
characteristic: the programming tools worked.  And that's something that 
wasn't always the case just a few years back.

      Project: FS 2000

      Sponsor: Finnish, Swedish, Danish, Australian, New Zealand Navies

      Integrator: Nobel TechSystems AB, Stockholm, Sweden

      Compiler Vendor: Rational, Santa Clara, Calif.

      Challenge: Enabling Related Ada Functions to Communicate

If ever there was a massive software challenge, this was it: a complicated 
package of more than 1 million lines of Ada code that would provide an 
integrated surveillance, communications, and fire-control system for small 
warships and patrol craft.  What's more, the system had to include independent 
software programs that could communicate and work together -- and designers 
were under pressure to reuse as much code as possible each time the software 
was adapted for different ships belonging to different nations.

Today, five years after engineers with Nobel TechSystems AB began writing the 
first lines of code, the resulting FS-2000 system is acknowledged by senior 
U.S. software experts as one of the most successful Ada projects to date.  
Along the way, Stockholm-based Nobel -- formerly Bofors Electronics AB -- had 
to define a proprietary operating system that added several layers of 
communications software to the existing OS-9 operating system and develop a 
new approach to business expressly for their target market -- naval vessels.

"We wanted to build the system as a set of cooperating problems," says Jaak 
Urmi, chief of base technologies for Nobel TechSystems, "Ada nicely defines 
how to interface Ada tasks, but there is not a word on how to communicate 
between Ada programs."  And while industry and academia were trying to address 
that problem at the time, Urmi recalls, "we couldn't wait."  Instead, Nobel 
turned to Rational, of Santa Clara, Calif., for development tools and 
assistance.

But the task was not that simple.  FS-2000 consists of many systems, ranging 
in scope from data base applications where speed isn't pressing to demanding 
real-time applications for tracking sea-skimming anti-ship missiles and 
directing onboard weapon systems to destroy them within seconds of detection.  
With the processing load distributed over 100 Motorola Inc.  68020 and 68040 
microprocessors, the system was among the most complex Ada projects ever 
attempted.

"The software is very highly distributed," says Bob Bond, Rational's executive 
vice president for international sales.  "It's very complex, with intense 
real-time requirements."

Two conflicting needs tugged FS-2000's designers in opposite directions.  On 
the one hand, they had to meet hard-real-time constraints; on the other, they 
had to write the software in such a way that it could be easily reused.  So 
while it was tempting to write the real-time portions of the program in 
Assembly language for maximum performance, it was just as important that Ada 
be used as much as possible to promote software portability, maintainability, 
and reuse.

Portability was essential because of the broad application of the system.  
Nobel's FS-2000 command-and-control system is now in use aboard Swedish KKV 
coastal corvettes, Danish Stanflex 300 corvettes, Swedish A-19 submarines, 
Finnish coastal patrol boats, and Danish inspection ships designed for 
fisheries enforcement near Greenland.  The system is also scheduled to be 
incorporated into a planned Australian/New Zealand frigate.

Adding further to the already complex equation, was the requirement that 
developers write custom software to link the multiple Ada programs -- without 
violating Ada's strict guidelines for acceptable use.  The answer, Urmi says, 
came after much study.  "We implemented an Ada remote rendezvous that makes it 
possible to structure a set of Ada programs so you don't go outside the 
language," he explains.  The rendezvous is folded into OS-2000, a custom 
operating system based on OS-9.  "It's basically OS-9 with a lot of layers of 
software to support Ada and this distributed system."

Now Urmi and his colleagues are facing a new challenge.  With Unix becoming an 
industry standard, they're hard at work trying to substitute Unix for OS-9 as 
much as possible.  Urmi predicts Nobel's future shipboard command and control 
systems will include a mixture of OS-9 and Unix, with OS-9 handling the 
demanding real-time tasks and Unix handling the more conventional chores.  The 
arrangement is similar to today's technique of using Assembly routines 
embedded in Ada programs to squeeze out every microsecond of performance.

      Project: MK 41 Vertical Launch System Upgrade

      Sponsor: U.S. Navy

      Integrator: Martin Marietta Corp. Aero and Naval Systems Group, 
      Baltimore

      Compiler Vendor: DDC-I Inc., Phoenix, Ariz.

      Challenge: Achieving The fastest Possible Interrupt Handling

When engineers from Martin Marietta Corp.'s Aero and Naval Systems group in 
Baltimore started designing the Navy's Vertical Launch System Baseline 4 
upgrade two years ago, the ability to handle software interrupts was foremost 
in their minds.  That's one of the reasons they chose Ada compilers from DDC-I 
Inc. of Phoenix, Ariz., to support their VLS computers.  The computers are 
based on Intel Corp.'s 80286, 80386, and 80186 microprocessors, says John 
Page, Martin's chief of embedded software on the VLS project.  DDC-I, Page 
says, offers two kinds of interrupt handling -- fast and normal.  Back in 
1989, the competition didn't, he says.

The Vertical Launch System arrays as many as 61 missiles and launchers 
side-by-side, like eggs in an egg carton, below the decks of the Navy's 
Arleigh Burke and Spruance-class destroyers and Ticonderoga-class cruisers.  
The system, which can fire both offensive and defensive weapons, is also used 
in surface vessels belonging to several foreign navies.  Martin's job was to 
replace the low-level sequencing computer that controls missile launch 
sequencing and interfaces with fire control computers.  Engineers tore out 
8-bit processors and replaced them with a system based on two 80386 processors 
and ten 80186 processors, all running Ada, and seven 8097 microcontrollers 
running code written in C.

Their biggest concern: real-time interrupt handling.  That's crucial because 
missiles have to respond to changing threats within seconds -- without waiting 
for the computer to complete tasks in progress.  A missed interrupt message 
can cause the VLS system to miss incoming missiles, lose target opportunities, 
waste missiles by inadvertently flooding launching tubes, or even cause 
accidental detonations of multiple warheads.

DDC-I's fast interrupt handler bypasses the runtime system scheduler, so 
messages go straight into the source code, Page explains.  That way "it's as 
fast as the microcontroller and the processor."  By contrast, the normal 
interrupt handler is an Ada task that the runtime system schedules as the 
interrupts come into the system.  All interrupts must be handled within a 1 to 
2 ms window, but some must be taken care of more quickly than others.  DDC-I's 
normal interrupt handler, which features a context switch time of 25 us for an 
Ada rendezvous on a 16-MHz 80386 machine, beats the requirement by as much as 
80 times; DDC-I's fast interrupt handler is another 10 times faster than that.

But Page says that designers shouldn't use the fast interrupt handler unless 
they're faced with potential data overruns, in which the computer receives 
data faster than it can handle.  That's because the fast interrupt handler 
gains its speed by blocking the flow of other messages.  "Unless you have a 
definite need to use the fast interrupt handler, it's better to use the normal 
handler because [the fast handler] precludes you from scheduling and passing 
data to other tasks."  The MK 41 VLS, which can fire the Tomahawk and Sea 
Sparrow missile, Antisubmarine Rocket, and Standard Missile II, is scheduled 
for Navy acceptance this month, with the first test firings this fall.

      Project: B-2 Stealth Bomber Air Crew Simulator

      Sponsor: U.S. Air Force

      Integrator: CAE Industries Link Flight Simulation Division, Binghamton, 
      N.Y.

      Compiler Vendor: Concurrent Computer Corp., Tinton Falls, N.J.

      Challenge: Building Real-Time Extensions To Speed Ada Execution

Few defense systems have real-time requirements as stringent as air crew 
flight simulation.  Any perceived delay in the device as it responds to 
control movements compromises the training's value and makes the air crew lose 
confidence in the machine.  Engineers at CAE Industries' Link Flight 
Simulation Division in Binghamton, N.Y., confronted this problem when the Air 
Force contracted them to devise a simulator, written in Ada, for the B-2 
stealth bomber.  Link turned to Concurrent Computer Corp., Tinton Falls, N.J., 
in 1986 to provide software and hardware fast enough for the job.

Although Ada is intended for real-time embedded applications, critics often 
fault the language for failing to handle hard-real-time tasking well.  Until 
recently, the accepted method for Ada programmers working time-critical tasks 
was simply to write them in Assembly or C.  That method is fast and efficient, 
but can be difficult to maintain or reuse.

But when they started work on the B-2 simulator, Concurrent's engineers 
decided to handle virtually all time-critical tasks in Ada by writing a series 
of real-time extensions with Ada's pragma facility, which sends special 
instructions to the compiler to attain maximum speed.

"Time-critical Ada needs real-time extensions," says Wendy Hudson, 
Concurrent's senior manager of compiler development.  "Ada is a robust 
language, but there are subtleties underneath, and most basic Ada doesn't 
handle real time well."

Concurrent's 19-processor parallel architecture for the B-2 simulator, which 
is based on the company's 3280 processor, draws heavily on a real-time 
extension designed to suppress an Ada task that routinely checks for stack 
memory overflow, "If a subroutine is being called, you have the option to put 
in this pragma that says don't do the stack checking," Hudson says.  "It saves 
overhead by saving a couple of instructions."

But to do this, Hudson and her colleagues wrote software tools around the 
pragma that guarantee the programmer from the start that he'll have enough 
stack space, which is area set aside in main memory for arithmetic 
calculations or for keeping track of internal machine operations.  Concurrent 
developed tools to calculate how much stack space a program needs at any given 
time in order to guard against overflow.  So by determining that need from the 
start -- and by structuring code to require the minimum amount of stack memory 
at any given time -- users can safely avoid stack overflow checking while 
running code.

The B-2 simulator, which consists of more than 2 million lines of code, is now 
in its final stages of development.

      Project: YF-22 Common Integrated Processor Avionics

      Sponsor: U.S. Air Force

      Integrator: Hughes Aircraft Co., Radar Systems Group, El Segundo, Calif.

      Compiler Vendor: Irvine Compiler Corp., Irvine, Calif.

      Challenge: Using Ada Multitasking To Its Full Advantage

One of the qualities that attracted the Defense Department to Ada in the first 
place was its ability to execute several tasks at once.  But software 
engineers working on advanced avionics couldn't take full advantage of that 
multitasking capability until there was hardware available to really support 
it.  That's now available in Intel Corp's i960, the standard 32-bit 
microprocessor for Lockheed Corp's F-22 Advanced Tactical Fighter.

"The i960 processor understands multitasking in the silicon," says Dan Eilers, 
president of Irvine Compiler Corp., Irvine, Calif.  "It actually has hardware 
instructions to schedule and deal with different processes" -- capabilities 
unavailable, he claims, on competing processors, such as MIPS Computer Systems 
Inc.'s R3000.  "This is one key reason why the ATF uses the i960, because you 
have direct hardware support for these concepts."

Without a multitasking language like Ada and a chip like the i960 that can use 
it to full advantage, "you have to do clumsy things outside the language and 
in the operating system" to handle interrupt tasks, Eilers says.  "If the 
language is sequential [like C] and your application is parallel, you have a 
mismatch between the abstractions available in your programming language, and 
those required by your application."

With Irvine's Ada compiler, F-22 software engineers were able to handle 
interrupts within the language -- a crucial quality for avionics.  Interrupts 
are crucial in avionics applications, since software tasks must routinely be 
stopped and set aside so the system can handle higher-priority jobs, such as 
threat warning and avoidance.

Hughes Radar Systems Division, El Segundo, Calif., which is developing the 
F-22's Common Integrated Processor avionics, chose Irvine in 1986 because the 
company was the first to offer an i960 compiler -- one year before its prime 
competitor, Tartan Inc.  of Monroeville, Pa., brought its compiler to market.  
Tartan, however, claims it's the first to have its i960 compiler pass DoD 
validation.  Lockheed's YF-22 beat out a rival from a team led by Northrop 
Corp. and McDonnell Douglas Corp. in April, and the program's 
demonstration/validation phase is wrapping up this summer.

      Project: Advanced Field Artillery Tactical Data System (AFATDS)

      Sponsor: U.S. Army Communications-Electronics Command (CECOM), Fort 
      Monmouth, N.J.

      Integrator: Magnavox Government/Industrial Electronics Co., Fort Wayne, 
      Ind.

      Compiler Vendor: TeleSoft, San Diego

      Challenge: Building a complex system with immature technology

The Defense Department's first standardized version of Ada was only a year old 
when the Army and Magnavox Government/Industrial Electronics Co., Fort Wayne, 
Ind., started work on the Advanced Field Artillery Tactical Data System in 
1984.  AFATDS was going to be one of DoD's first major Ada projects.

The trouble was, there were virtually no reliable Ada compilers on the market 
at the time, the AFATDS central processor -- Motorola Inc.'s 68020 -- was 
brand spanking new and didn't have a proven track record, and the project 
called for 1 million or more lines of code -- more than any prior program.  
Recalls Mark Overgaard, vice president for advanced development at San 
Diego-based TeleSoft, which provided Ada compiler support: "It was pushing 
technology on all fronts."

It seemed like a disaster.  Magnavox engineers had software problems from the 
start.  And, for the first three years running, the company was lambasted in 
reports prepared for Congress by the General Accounting Office, Capitol Hill's 
investigatory arm.  Critics called for the program's cancellation and sought 
to replace it with a competing system from Litton Industries Inc. called Light 
Tacfire.  "Compilers had a lot of problems," says Ron Lawson, AFATDS software 
engineering manager at Magnavox, in a classic understatement.  Perhaps just as 
troublesome, he adds, was the lack of an Ada debugger for the 68020 target 
hardware.

But Magnavox weathered the storm.  Today, John Solomond, director of DoD's Ada 
Joint Program Office, points to AFATDS as one of the most successful military 
Ada programs in the U.S. Magnavox started turning things around in 1987 and, 
two years later, the Army redefined AFATDS hardware requirements, mandating 
that the software run on Army Tactical Command and Control System common 
hardware, rather than the custom computers originally planned.  That change -- 
to Hewlett-Packard Co. computers adapted for military use by Miltope Corp., 
Melville, N.Y. -- effectively removed TeleSoft from the project, and handed 
compiler work over to Alsys Inc., Burlington, Mass.

Still, Magnavox officials credit TeleSoft for helping to get the program back 
on track when everyone in Washington seemed bent on letting it die.  Magnavox 
officials agree that an extremely close relationship between the two companies 
may have been the key to salvaging AFATDS.  Indeed, TeleSoft even delivered 
its own source code directly to Fort Wayne, where it was loaded onto 
Magnavox's host computer systems.  That meant TeleSoft "could make fixes right 
on their machines, and within 24 hours [Magnavox] could be back in business," 
Overgaard says.  "We had technicians on site.  That makes a big difference on 
these big projects using complex languages with a lot of subtleties."

In return, Magnavox provided TeleSoft with working copies of AFATDS code as it 
was developed, so the Ada vendor's analysts could use it to test changes to 
their compilers and ensure that revised compilers could efficiently handle 
such large programs.

A footnote: The Army's restructuring of the AFATDS program two years ago 
essentially forces Magnavox to start again from scratch with a new design, new 
software requirements analysis, and a move from the old menu-driven user 
interface to a graphical interface based on X-Windows, Motif, and the Unix 
operating system.  Code development has barely started.  Even so, Lawson says 
Magnavox has completed much of the shovel work, because his engineers will be 
able to reuse as much as 50 percent of the Ada code they developed with the 
first go around.  The project is still woefully behind its original schedule, 
which called for fielding in the late 1980s.  But with reusable Ada code, and 
with the introduction of well-tested off-the-shelf software for the user 
interface and data base construction, Lawson says AFATDS is on track for its 
scheduled March 1993 delivery to the Army.

      Project: Integrated Control & Avionics for Air Superiority (ICAAS)

      Sponsor: U.S. Air Force

      Integrator: Lear Astronics Corp., Santa Monica, Calif.

      Compiler Vendor: InterAct Inc., New York

      Challenge: Developing Software for Multiprocessing Architecture

Software engineers at Lear Astronics Corp., Santa Monica, Calif., had to break 
new ground in 1988 when they won a contract to develop the Integrated Control 
& Avionics for Air Superiority system, or ICAAS, a situation-awareness and 
flight-control computer designed to enhance the air-combat capability of the 
aging F-15.

Their challenge was to write software for a multiprocessor system based on 
MIPS Computer Systems Inc.'s R3000 RISC processor and the MultiBus II 
backplane/data bus.  No one had ever done that before.

Lear Astronics was a beta test site for InterAct Inc.'s Ada/MIPS Cross 
Compiler system, so it was the natural choice for the company's developers.  
But to optimize the resulting Ada code for ICAAS' multiprocessing 
architecture, "we needed to modify the runtime system to provide the hooks, 
communications, and device drivers to exercise the [MultiBus II] 
architecture," says Bernard Shen, the project's lead software engineer.

Shen and his colleagues devised a message-passing scheme, rather than the more 
conventional approach of using shared memory and semaphores, because it was 
more secure and was less susceptible to data corruption, he says.  But message 
passing, with its extra layer of communications software, consumes twice as 
much throughput capacity as shared memory systems.  That factored heavily in 
Lear's decision to stick with the InterAct compiler, he adds, since its fast 
and efficient code put less demand on the hardware.

"The InterAct code is almost as fast as my hand-coded Assembly," Shen says.  
Now InterAct is introducing Version 2.0 of its R3000 compiler, which Shen says 
produces code that's twice as fast as the previous version.  And Lear is 
wasting no time upgrading ICASS with the new compiler.  "[Its] performance 
makes such a big difference, that you really don't have to care [in terms of 
speed] whether you have shared memory or message passing," Shen says.  His 
advice for other projects: "If you choose the right compiler, you'll be O.K."  
Lear delivered its portion of ICASS to the Air Force in October 1990.  Flight 
tests on the F-15 are to begin next month.

      Project: Advanced Navy Submarine Communications Buffer

      Sponsor: U.S. Navy

      Integrator: Naval Ocean systems Center, San Diego

      Compiler Vendor: Alsys Inc., Burlington, Mass.

      Challenge: Code Reuse Across Multiple Platforms

The software the Navy was using in the mid-1980s to automate its strategic 
submarine communications systems was a technical success.  Users didn't 
complain and system failures were rare.  But maintaining those programs was a 
logistical nightmare -- the systems were a mish-mash of hardware and software 
written primarily in poorly documented Assembly language.

By 1987, the systems needed to be modernized.  But given their software 
architectures, upgrading them was nearly impossible.  So program managers at 
the Naval Ocean Systems Center in San Diego decided to start from scratch, 
reprogramming NISBS, the NATO Interoperable Submarine Broadcast System, in 
Ada.  Now they're using that program as a foundation for two other submarine 
communications systems -- the Submarine Message Buffer and the Advanced 
Message Processing System.

The two spin-off projects are expected to multiply into an entire family of 
submarine communications systems, all of which will be made up of 
predominantly common software components.  The goal: only about 10 percent of 
each new program will be fresh Ada; the rest will all be taken from NISBS.

The savings are phenomenal.  NOSC's Submarine Message Buffer program might 
have cost $2.6 million and taken 235 man months to develop if it had to be 
developed from scratch, says program manager Ben Barlin.  Instead, it's 
costing $550,000 and taking just 48 man months.  Although it's a relatively 
small program -- about 20,000 lines of code -- Barlin says he can get the same 
time and cost savings on projects of 1 million lines or more.

Key to that process is compelling the sponsoring system program office -- in 
this case the Space and Naval Warfare Systems command -- to specify 
requirements, rather than narrow instructions for development.  As a result, 
the customer gets new systems into the field faster, Another bonus: functional 
prototypes early in the design cycle, so users can provide feedback on design 
and performance virtually from the beginning.  "Don't let the sponsors dictate 
how to do it," Barlin advises.  "Let them dictate what they want.  You 
[should] be responsible for the implementation."

Barlin's group does all the work on site at NOSC labs, using Intel Corp. 
80386-based personal computers as both the development environment and the 
target processor.  The project began with 80286-based machines in 1987 and was 
converted to 386 platforms two years later.  Alsys Inc., Burlington, Mass, 
supplies the compiler, but Barlin says the tools are not the most important 
thing here -- it's the reuse process, he says, that makes the difference.

      Project: Marine Corps Command Management Information System

      Sponsor: U.S. Marine Corps

      Integrator: Marine Corps Resources Management Directorate, Albany Marine 
      Corps Logistics Base, Ga.

      Compiler Vendor: Aetech Inc., Solana Beach, Calif.

      Challenge: Mapping Off-The-Shelf PC Graphics Into Ada

The Marine Corps' project to upgrade its Command Management Information System 
(CMIS) with Ada software was proceeding on course and on schedule last year.  
Then disaster struck: software engineers discovered the Alsys Inc. compiler 
they were using couldn't map DOS-based graphics programs into Ada or support 
the use of a mouse.

Without the ability to use such programs as PC Paintbrush and Harvard 
Graphics, or permit the use of a mouse on their Intel Corp. 80286 and 
80386-based personal computers, the Marine engineers were in a quandary.  They 
needed those capabilities and they needed Ada.  But no one could give them 
both.  Then, after looking into dozens of compiler products, they contacted 
Aetech Inc. in Solana Beach, Calif.

Aetech provided just what the doctor ordered.  "We needed the Aetech compiler 
and tools to display the graphical information, and for the graphic user 
interface and mouse driver," says 1st Lt. Lloyd Biggs, assistant officer in 
charge of Ada programming for the Information Resources Management Directorate 
at Albany Marine Corps Logistics Base, Ga.  "Aetech had a mouse driver 
package, which Alsys did not provide, and they can display the graphical 
images of several formats."

The Marines' CMIS program is an executive information system designed to pass 
logistics information up the chain of command, and it makes heavy use of bar 
graphs and pie charts so commanders can efficiently interpret data and pass it 
on to their high-ups, Biggs says.

The Marines moved CMIS to Ada because the older version, written in a language 
called Ready Master, didn't allow them to service all CMIS users with one 
program.  "We used to have to develop separate programs for each user, and it 
became cumbersome to maintain," says Capt. J.A. Hernandez, the directorate's 
officer in charge of Ada programming.  "The only drawback to Ada was the [lack 
of available] packages to handle these low-level capabilities that we needed.  
Other than Aetech, there wasn't anybody out there who supplied them."

      Project: Wide Area Mine (WAM)

      Sponsor: Army Armament Research and Development Command, Picatinny 
      Arsenal, N.J.

      Integrator: Textron Inc.'s Defense Systems, Wilmington, Mass.

      Compiler Vendor: Tartan Inc., Monroeville, Pa.

      Challenge: Optimizing Code For Different Memory Types

Modern military systems often integrate multiple types of solid state memory, 
including fast random-access memory chips and nonvolatile programmable 
read-only memories.  But the incompatible speeds and wait states of the memory 
chips can be a show stopper for weapons designers.

Program code must be written in such a way that real-time performance isn't 
sacrificed just because memory wait states aren't the same.  This was an 
important concern when engineers designing WAM, the Army's Wide Area Mine, 
began looking for an Ada compiler in 1989.  Their system was going to include 
static RAMs, erasable PROMs, and electrically erasable PROMs.  They turned to 
Tartan Inc., of Monroeville, Pa., to develop and provide an Ada compiler.

"These different memories have different wait states, and our product allows 
the user to specify the wait states that will be employed in the memory," says 
John Staire, DSP product manager at Tartan.  "It allows us to optimize the 
code generated for the machine."

With an architecture based on Texas Instruments Inc.'s 320C30 digital signal 
processor, WAM uses seismic and acoustic sensors to detect enemy tanks.  The 
unit then lobs a munition into the air where it conducts a localized search 
before attacking the tank from above, where its armor is thinnest and most 
vulnerable.  To succeed, the mine has to process information fast -- 
time-critical subroutines must execute in less than 500 ms -- with as little 
processing and memory hardware as possible.

Gary Viviani, principal engineer for Textron, adds that Tartan takes full 
advantage of the C30 architecture, which takes four cycles to branch, or move 
to different sections of the program, by filling each cycle with logic tasks 
that otherwise would have to be done after branching.  "Tartan isn't letting 
any of those cycles go to waste while it waits for the processor to be ready," 
Viviani says.  WAM is now in full-scale development.

      Project: Ada-To-Motif Bindings (Developed for the EUCOM Command and 
      Control System)

      Sponsor: Army Communications-Electronics Command, Fort Monmouth, N.J.

      Integrator: NASA Jet Propulsion Laboratory, Pasadena, Calif.

      Compiler Vendor: Meridian Software Systems Inc., Irvine, Calif.

      Challenge: Making Ada Compatible With the Motif Graphical User Interface

It's no secret that the Defense Department requires all weapons-system 
software to be written in Ada.  Less known -- though no less important -- is 
that DoD is also standardizing on the Open Software Foundation's Motif 
graphical user interface for all computer information systems.  But despite 
DoD's requirements, binding together popular "point-and-click" interface was 
next to impossible.

Until now.  The National Aeronautics and Space Administration's Jet Propulsion 
Laboratory broke through the barrier in May when it delivered a Motif and 
Ada-based command, control, and communications system to the U.S. European 
Command in Stuttgart, Germany.

With help from Ada compiler vendor Meridian Software Systems Inc., Irvine, 
Calif., JPL wrote the first-ever Ada bindings to Motif.  And now JPL is making 
the bindings available, free of charge, as government-furnished equipment to 
companies and government agencies that need them.  JPL wrote the bindings 
while under contract to the Army Information Systems Management Activity's 
Office for Command Center Upgrades and Special Projects, located at Fort 
Monmouth, N.J.

Assembling the bindings wasn't as easy as it might sound, says Andrew 
Magruder, a JPL systems programmer who's been closely involved with the 
project to build a decision support system for the Army Headquarters European 
Command's Command and Control System upgrade.  The problem was that Motif is 
written in C, a loosely controlled language that doesn't mesh well with Ada's 
notoriously tight controls.  "We tried lots of compilers and platforms, and 
they didn't work," Magruder says.

Then they tried Meridian's -- and it worked.  Unlike most compilers, the 
Meridian product doesn't translate Ada code directly to Assembly before 
generating machine language.  Instead, it incorporates an intermediate step, 
translating the Ada into C before boiling it down into machine language for 
specific target hardware -- in the case of the EUCOM C2 system, MIPS Computer 
Systems Inc.'s R3000 processor, the RISC engine within Digital Equipment 
Corp.'s DECStation 3100.

Meridian makes the extra step through C to make the compiler more portable 
from one host computer to the next, Magruder says.  The fact that the 
intermediate step was the key to binding Ada to Motif -- and conceivably other 
C-based products and standards -- was a bonus.  But it was a major step 
forward for DoD software compliance.  Indeed, since JPL's breakthrough, 
Magruder says, he can barely keep up with demand.  "We get calls every single 
day."

                            **********************

                 Ada Information Clearinghouse (AdaIC)
                               P.O. Box 46593
                        Washington, DC 20050-6593
             703/685-1477, 800/AdaIC-11, FAX 703/685-7019
           adainfo@ajpo.sei.cmu.edu; CompuServe 70312,3303

The AdaIC is sponsored by the Ada Joint Program Office and operated by IIT 
Research Institute.



