The nation`s most advanced self-propelled artillery systems represent some of the most innovative vehicle electronics designs, and eventually may offer solutions to a variety of applications beyond vetronics
By John Keller
The words "combat vehicles," for most people, conjure up a variety of descriptions. Hulking, powerful, and explosive are some, yet cutting-edge technology is rarely one of them. Nevertheless, today`s U.S. combat vehicle electronics - better known as vetronics - represent some of the most advanced concepts in open- systems design, innovative ruggedized component packaging, and perhaps most importantly, software engineering and implementation.
The electronics of the latest versions of U.S. self- propelled artillery systems, main battle tanks, and armored personnel carriers - as well as a variety of support vehicles such as mobile assault bridges and mine-hunting vehicles - are evolving toward architectures that depend heavily on commercial off-the-shelf (COTS) components.
The reasons for designing with open systems and COTS - keeping system costs down, using the latest technology, and enabling quick and easy systems upgrades - are particularly important to vetronics integrators. Combat vehicles are subject to even greater cost scrutiny and constraints than are aircraft and ships, so COTS is the obvious road to buying the most tech-nological capability on the tightest budgets.
Leading the way in vetronics systems design is the U.S. Army United Defense L.P. Crusader advanced field artillery system. Crusader, which is to be rolled out in 2006, will feature a vetronics architecture based on ruggedized PowerPC VME single-board computers from DY 4 Systems Inc. of Kanata, Ontario, and on the Lynx OS real-time operating system from Lynx Real Time Systems Inc. of San Jose, Calif.
Software engineers will write Crusader`s application code in the Ada 95 programming language, using the Apex software engineering environment and Ada compiler from Rational Software Corp. in Cupertino, Calif. The high-speed data bus for Crusader will be the 100-megabit-per-second Copper Data Distributed Interface - better known as CDDI. Virtually the only supplier of CDDI interface boards rugged enough for vetronics applications is Vista Controls Corp. of Santa Clarita, Calif.
Writing Crusader application code are software engineers at Honeywell Defense Avionics Systems in Albuquerque, N.M., the Raytheon Systems Co. Communication Systems Division in Fort Wayne, Ind., and the Litton Guidance and Control Systems Division in Northridge, Calif., says Larry Yung, chief of system engineering/system integration for software at the U.S. Army Crusader program office at Picatinny Arsenal, N.J. In charge of Crusader software for engine and mobile control are experts at the General Dynamics Land Systems Division in Sterling Heights, Mich.
Crusader also is notable for its innovative vetronics design approach that compartmentalizes computing hardware, application software, and software operating systems, with an eye toward easy future system upgrades with a minimum of software rewrite. "We want to put all the right things in Crusader, so we are pushing big time for open systems," Yung explains.
Crusader, from the United Defense L.P. Armament Systems Division in Minneapolis, consists of a 155 mm self-propelled howitzer and an armored resupply vehicle. It uses computer automation to enable both vehicles to operate with three crewmen each. Crusader will shoot, move, and communicate with fast armored vehicles such as the Army General Dynamics M1A2 main battle tank. Crusader is to contain embedded training to include individual and crew drills as well as combat training center interfaces.
Embedded technology will also include technical manuals, sensor suite, and decision aids such as route planning, firing point selection, and survivability moves. Crusader also is to be one of the first artillery pieces in the world to contain a radar and associated signal-processing subsystem that will track the flight of artillery shells as the gun fires them to help the crew fine-tune the aiming of following shots. Essentially this subsystem will be an automated forward observer. Handing the radar digital signal processing on Crusader are experts at Delphi Engineering Group Inc. of Costa Mesa, Calif.
Modular software
Key to the Crusader`s vetronics architecture is a software layer that resides between the application code and operating system that Crusader designers call Real-Time Common Operating Environment, better known as RTCOE. This software layer, which engineers at United Defense are creating, is to enable engineers to upgrade either the Crusader`s computer hardware or operating system without the necessity of recompiling or altering the artillery system`s application code. To adapt Crusader to future hardware or operating system upgrades, designers need only make alterations to the RTCOE software layer, Yung says.
"We need a loose coupling between the hardware and software, because your hardware will be obsolete before you complete your software development cycle-and our hardware at production is not even at the drawing board yet," Yung explains. "We want to prevent freezing of electronics designs at day one." Potential hardware upgrades could include not only new microprocessors, but also multiprocessor architectures, Yung says.
With the RTCOE, not only will Crusader easily be able to accept upgrades involving substantially different hardware and operating system software, but also application code written in different languages. It will not be tied to its Ada 95 programming language, Yung says. Instead, the RTCOE will enable software applications written in different languages to operate on one processor.
"The RTCOE makes the application software operating-system-independent," Yung says. "It isolates the application code from changes in hardware. In the future, we could go to Windows NT, VX Works, or whatever else is coming down the pike."
Without software "middleware" such as the RTCOE, system upgrades require engineers to reach into each application software task and alter it to render it compatible with the hardware or operating system changes, Yung says. This process is expensive, time consuming, and provides broad opportunities for inadvertent software code glitches or conflicts, he points out.
Ease of upgrades
By the same token, Crusader designers in the future could easily swap out the system`s PowerPC central processor for whatever new hardware is available when Army leaders need to improve the system.
Shielding the application code from necessary changes brought about by hardware or operating system changes may not sound like a big deal, but Yung says it represents profound cost savings.
Yung points to an example involving seven vetronics software application tasks such as command and control, navigation, mapping, fire control, system diagnostics, power, and communications. Without RTCOE, software engineers might need to recode 10 percent of the application software to accommodate new hardware or operating system changes. His example assumes the need to alter 130,000 lines of code at a cost of $26 million per weapon system, which includes only code changes, not the actual system upgrade.
Yet with RTCOE, the same kind of upgrade would require a change to 10 percent of only the RTCOE software. "It is a very thin layer of software than you need to modify," Yung says. This, approach, he says, would involve recoding 2,500 lines of code at a cost of $500,000 per weapon system. "We want to protect our investment in software," Yung says.
The RTCOE approach inevitably will increase software overhead on computer processors within the Crusader vetronics, Yung points out. Yet he says he has been assured that steadily increasing hardware performance will more than compensate for increased software overhead, and shield the system from software-induced performance degradation.
The cost savings that RTCOE represents extend beyond system upgrades. It also may ease the reuse of software in similar weapon systems and in training simulators, Yung says. "The Army is standing on a gold mine," he says. "Once you have that middleware, you have reuse on a grand scale." If systems integrators on other programs wanted to reuse all or part of the Crusader vetronics software, for example, they could do so and use whatever computer hardware and operating system software they chose. They would not be locked into the Crusader`s PowerPC/Lynx OS approach. At the same time, the RTCOE could enable systems designer to run the same application code on the Crusader gun system itself, and also on Crusader training simulators.
Although Yung says Crusader is the only program he knows of that is implementing software middleware to the extent that RTCOE offers, he says he would like to see systems designers apply the RTCOE approach to all U.S. Army indirect fire-support systems, which would include towed artillery with fire-control computers, as well as a host of tactical missiles such as the Multiple Launch Rocket System.
U.S. vetronics development is evolving toward standard architectures based primarily on COTS components that can be applied to a wide variety of combat vehicles, such as mobile assault bridges, mine hunters, and main battle tanks.
Paladin howitzer vetronics designers are making broad use of commercial-grade PCI/ISA printed circuit cards and packaging them in a ruggedized box that isolates them from shock and vibration.
How the Paladin computer evolved with its COTS roots
The fire-control computer in the U.S. Army M109A6 Paladin artillery vehicle featured commercially developed components even before COTS became fashionable as the Defense Department`s preferred way of designing weapons and related subsystems.
Paladin, the latest version of the venerable United Defense L.P. M109 155-mm self-propelled howitzer, began on the drawing board in the early 1980s as the Howitzer Improvement Program, or "HIP." Its three-box vetronics design consisted of mil-spec components, proprietary operating system, and a computer based on mil-spec versions of the 16-bit 8 MHz Intel 8086 and 80186 microprocessors.
Engineers at the vetronics designer, Alliant Tech- systems of Minneapolis, crafted Paladin`s real-time operating system software in-house, explains Arthur Lopez, Paladin team leader at the Software Engineering Center of the U.S. Army Picatinny Arsenal, N.J.
Paladin`s application code was in the Ada 83 programming language using the old government/industry Ada Language System compiler, better known as ALS. As a footnote, the ALS gave way to the ever-more-reliable Ada compilers and related software development tools that became available from the fledgling Ada software industry as in the mid-to-late 1980s.
On the face of it, the Alliant Techsystems unique operating system presented an advantage to the Army because Alliant software engineers tailored the code specifically to Paladin requirements. Still, there were problems, Lopez explains.
That custom operating system raised competitive and procurement issues as its integration into the M109A6 artillery locked Alliant into future systems upgrades. Perhaps more important, its use reduced the number of upgrade options available to the Army and to United Defense systems integrators at just the time when the commercial computer industry starting making a rich variety of new technology available to weapons designers.
At the same time, using the commercially developed yet mil-spec Intel 8086 and 80186 gave Paladin vetronics designers an early look at the dark underside of commercial off-the-shelf components, or COTS - rapid parts-obsolescence, explains Rene Kiebler, associate product manager of production and engineering on the Paladin program at Picatinny Arsenal.
To deal with the Paladin`s obsolescent microprocessor architecture, Army officials at Picatinny began work in the early 1990s on the first upgrade of the original M109A6 vetronics.
Working together with experts at Alliant Techsystems and United Defense, Army officials specified a hardware upgrade that switched out the Intel 8086 and 80186 microprocessors and substituted the then-more-powerful 32-bit 25 MHz Intel 80960 MX RISC processor. This microprocessor also had been the original choice of avionics designers of the U.S. Air Force Lockheed Martin F-22 advanced tactical fighter, and of the U.S. Army Boeing-Sikorsky RAH-66 Comanche scout-attack helicopter.
The switch to the 80960 processor involved far more than simply swapping out chips. It required systems designers to recompile and upgrade the Paladin application code, while still using the Alliant Techsystems proprietary real-time operating system kernel, Lopez explains. This upgrade also involved a switch from the old ALS Ada compiler to one then available from Tartan Inc. of Monroeville, Pa. Tartan since has become part of Texas Instruments.
Still, the 80960 upgrade still did not resolve issues of parts obsolescence as commercial industry rapidly introduced new processor technology.
By the mid 1990s, Army Paladin program leaders at Picatinny realized they needed to make a fundamental change in the program. They did this not only to ease the burden of ever-escalating system upgrades, but also to shield themselves from uncontrolled pricing from Alliant Techsystems, whose officials with their custom operating system were in a position to dictate terms.
Their solution was to make United Defense responsible for the hardware portion of the Paladin vetronics, and to take responsibility themselves for the Paladin software. Today, all the M109A6 software is written and maintained at Picatinny Arsenal, Lopez says.
"We went to Alliant Techsystems, and took all software responsibility into the government," Lopez explains. "We have complete configuration control at the software laboratory we established here in 1993 and 1994."
The result is a plan for an all-new Paladin vetronics upgrade scheduled for fielding beginning in August 1999. The vetronics is to be based on commercial-grade versions of the 133 MHz Intel Pentium microprocessor. The operating system, given Paladin`s legacy, represented a bit of a surprise - Windows NT. Picatinny officials also are moving to the Ada 95 programming language.
"There is a wide market for applications and development tools for Windows NT," Lopez explains. "We headed down the Unix path for a little while, but the support and applications were not available. The Win 32 API is also an emerging industry standard, while Posix, we believe, is becoming dated. As we migrate to more situational awareness in the vetronics and weapons, we are more graphic user interface oriented, and we want the Windows technology to implement those tasks."
The hardware in what is now called the Paladin Advanced Fire-Control System - better known as AFCS - reduced the old three-box fire-control computer system to one box. This subsystem shields commercial-grade components packaged on industrial-grade PCI/ISA printed circuit boards from the 100-G shock of the Paladin`s 155 mm gun firing with three single-stage shock mounts that reduce shock and vibration to only 10 Gs at the card level, Picatinny officials say.
The old three-box vetronics system cost about $80,000, while the new higher-capability one-box system costs about $20,000, Kiebler explains. It also reduces manning levels in each artillery system from five crewmembers to four.
Building the Paladin`s new PCI/ISA-based fire-control hardware are experts at Sechan Electronics Inc. of Lititz, Pa. The system integrates a tactical computer interface module card from Litton Guidance & Control Systems in Woodland Hills, Calif., a MIL-STD 1553 1-megabit-per-second data bus interface card from ILC Data Device Corp. in Bohemia, N.Y., and a Pentium single-board computer from Teknor Industrial Computers Inc. in Montreal.
The AFCS computer uses mil-spec connectors for use under battle conditions, and also commercial connectors for field or depot-level testing. The system makes use of existing Paladin cables.
For the future, Paladin designers plan to move from the existing amber monochrome display system to a color flat plane display by September 2000 to accommodate the Army`s first all-digitized battalion, Kiebler says. This will give the howitzer moving-map capability and enhance its situational awareness.
As an added benefit, Army officials plan to port the entire Paladin AFCS system to the future LightWeight Towed 155-mm howitzer system, for which leaders of the U.S. Marine Corps and the Canadian armed forces have expressed interest, Lopez says. - J.K.
The new upgrade to the Paladin howitzer fire-control computer uses COTS PCI cards throughout the subsystem. Shock isolators between the box and the howitzer hull help cut shock and vibration at the card level by 90 percent.
Wearable computers aid vehicle maintenance electronically
By John Rhea
FAIRFAX, Va. - Wearable computers are muscling into military maintenance applications such as vetronics and avionics that in the past had been the province of laptop computers.
Officials of the U.S. Army are pushing this technology with the malfunction diagnosis, repair, and maintenance program on the AH-64A Apache helicopter.
The program began at the Army`s Aviation Applied Technology Directorate at Fort Eustis, Va., using the Mobile Assistant wearables from Xybernaut Corp. in Fairfax, Va. Dave Stall, the Army`s project leader for the Intelligent Fault Locator software development effort, lists three reasons for using computer techniques for troubleshooting at the line replaceable unit level:
(1) the need to interface with electronic technical manuals;
(2) the need to incorporate maintenance expertise in expert systems; and
(3) the need to interface to the Apache`s MIL-STD-1553 data bus.
Maintenance technicians can do this with laptops in some environments, but Xybernaut officials say wearables have the edge where maintenance people work in cramped service areas or in highly mobile situations, such as an aircraft carrier flight deck or in the field. Also, by using voice interfaces, the maintenance personnel do not have to depend on mouse or keyboard entry when they need hands-free operation.
Army leaders are moving toward electronic technical manuals for many of their systems, Stall says, because the paper-based manuals originally developed for Apache, for example, required too much space to transport and use. Another trend involves capturing the expertise of experienced maintenance personnel to complement the electronic manuals.
"We went out and collected expertise among soldiers, engineers, manufacturers, consultants, or anyone else who had this knowledge," Stall says. "This was integrated into an expert system shell in such a manner that it could be retrieved quickly and easily [and it] now augments the electronic technical manuals."
The 1553 data bus is reshaping the way technicians collect maintenance data, Stall says, by enabling technicians to plug into the bus and receive data from onboard sensors, such as temperature and pressure.
U.S. Navy officials are evaluating a similar Xybernaut system on the Ticonderoga-class guided missile cruiser USS Princeton (CG-59). The wearable computers are for the Navy`s Smartlink program to combine asynchronous transfer mode and satellite communications to provide real-time ship-to-shore communications. As in the Army application, Navy shipboard maintenance personnel are accessing interactive electronic training manuals via the speech-activated mobile computer.
Xybernaut has been upgrading the basic wearable to a new version, designated the Mobile Assistant IV, which uses the Intel Pentium 233 MHz microprocessor. The basic design involves a 2-pound computer worn around the waist and a VGA head-mounted display with headphone and microphone for hands-free operation. The 1-pound display creates a monochrome image equivalent to a 15-inch VGA monitor at the distance of about two feet. The computer runs software applications on all the Windows and Unix operating systems.
Officials of the U.S. Customs Service, meanwhile, are employing the same technology at a border crossing in Arizona to help detect stolen cars, drugs, and other criminal activity. The service tested three of the earlier model Xybernaut Mobile Assistant wearables at Douglas, Ariz., as a possible replacement for radios previously used by guards to relay car serial numbers and license numbers.
Wearable computers from Xybernaut Corp., pictured above, are being used in the Army`s Apache helicopter for troubleshooting at the LRU level, and are under consideration for vetronics programs.
New software helps vetronics computers to share data
U.S. Army leaders are working with TRW software engineers to create a code package that will enable tanks, trucks, mobile artillery, helicopters, and other combat vehicles to share important battlefield information in real time.
The Embedded Battle Command (EBC) software, in development at TRW Tactical Systems in Carson, Calif., will help vehicles share data over secure radio links in much the same way as commercial phone lines and local area networks enable citizens to share information over the Internet.
The first formal test of the EBC software will be in late 1999 on platforms with several different microprocessors, says Neil Siegel, vice president and general manager of TRW Tactical Systems. Preliminary EBC software fielding could begin as early as 2000.
"Out goal is to put information technology into every platform - wheeled vehicles, tracked vehicles, and helicopters," Siegel says. "Information technology will help them maneuver, support, and fight better."
The EBC software will use graphic overlays to convey a common picture of the battlefield to all tactical vehicles in the area. This common picture, for example, will broadcast the locations of friend forces, enemy forces, minefields, destroyed bridges, chemical strikes, and other important information, Siegel says.
The EBC software, part of the so-called Force 21 Battle Command Brigade and Below "Applique" program, will embed either in existing vehicle computers, or will come in its own computer subsystem in vehicles that today do not have computers of their own. The special EBC computers most likely will be ruggedized CompactPCI systems, Siegel says.
One particular challenge for EBC software developers is enabling the code to run on several different microprocessors, Siegel explains.
For example, the EBC software must run on the PowerPC-based computers in the M1A2 System Enhancement Package (SEP) main battle tank vetronics, in the latest upgrade to the M2A3 Bradley Fighting Vehicle, and in the future Crusader self-propelled howitzer. The software also must run on the Pentium-based systems in the M109A6 Paladin self-propelled howitzer and on the EBC computer system. Not only that, but EBC software also must run on the Sun Sparc-based notebook computers of the Army Common Hardware-Software 2 system.
"We have a strategy that allows us to build the software for all those computers," Siegel says. "On some, there needs to be a special library of alterations to run on the specific microprocessor, and for other there simply needs to be a re-compilation."
The EBC is also helping provide focus to several different vetronics programs. "The focus of our efforts from now until next year is the development and integration of the EBC software," says Rick Wyrembelski, manager of horizontal technology integration and Abrams vetronics programs at M1A2 designer General Dynamics Land Systems Division in Sterling Heights, Mich.
"You are dovetailing several programs together, such as the SEP, the M2A3, and Crusader," Wyrembelski says. "As we share more and more technologies, we have a greater burden on the program executive elements." - J.K.
International opportunities for vetronics components
International combat vehicle programs are proving to be a promising market for several U.S. vetronics suppliers.
One example involves Vista Controls Corp. of Santa Clarita, Calif., which is providing control panels, central processor, and I/O for the fire control system on the Saudi Light Armored Vehicle (LAV) 120 mm mortar system.
Vista, which has extensive experience in vetronics components and subsystems, is providing a VME-based system with a mil-spec Advanced Micro Devices 29050 32-bit RISC processor, as well as keypad/electronic display system for the Saudi LAV howitzer system.
Meanwhile, engineers at Interstate Electronics Corp. in Anaheim, Calif., are providing a ruggedized 10.4-inch-diagonal color active-matrix liquid crystal display for the night-vision subsystem in the Canadian LAV.
"We did some very special design that has to do with strategically locating heaters in various areas of the display," says Zeev Kalansky, Interstate`s director of business development.
Liquid crystal displays can freeze in extremely low temperatures. "We included some interesting algorithms and sensors that control those heaters and reroute power accordingly. We don`t want to melt the plastic pieces inside. We need to take care of the electronics, liquid crystal, and backlights," Kalansky says.
The display, which Interstate leaders call WarriorVision, operates in temperatures as cold as -40 degrees Celsius, Kalansky says. - J.K.
