• DACS Keeps JSOW Maintenance On Target at Raytheon
• On the Front Lines: Meet Erik Jensen, VP of Engineering & Director of DDC-I A/S
• 3rd Party Update: Ada Information Clearinghouse
• Tech Talk: Using Path Commands to Provide Flexibility in the Location of Source Code

Using software originally developed by Texas Instruments, engineers at Raytheon maintaining the Guidance Electronics Unit (GEU) of the Joint Stand-Off Weapon (JSOW) — one of the most valuable medium-range tactical weapons in the United States’ high-tech arsenal — have come to respect DDC-I’s DACS programming tools for safety-critical, real-time embedded systems.

An autonomous, air-launched glide weapon designed to attack a variety of ground targets from standoff range, the JSOW moniker actually represents a family of delivery vehicles sharing a common platform and variants with unique missions and payloads. A joint Navy and Air Force program, integration is ongoing for several aircraft, including the F/A-18, F-16, B-2, B-52, while also planned for a host of others in current and future inventories.

"The GEU is the operational core of the JSOW, responsible for guidance, navigation and control of the munition from launch to strike," explains Guy Yeager, a principal software engineer and the software team lead for the JSOW/GEU program at Raytheon. "Every system on the weapon in some way, shape or form communicates with the GEU."

According to Yeager, the GEU is literally the mind of the JSOW, taking inertial measurements from the IMU and performing a GPS correction to arrive at a "nav solution." This data is fed to guidance and control, where necessary adjustmentments are determined and the data converted into autopilot commands, which drive the control system and set trim on the flight surfaces.

The current Raytheon JSOW program emerged from the Advanced Interdiction Weapon System (AIWS), a Navy program initiated in the mid-eighties. From the beginning, affordability was a critical element, and as a direct result the JSOW program has been aggressively managed within a strict unit-cost threshold established early in the program.

Required mission capabilities for the JSOW also created significant challenges, particularly with respect to the aggressive cost goals, but a persistent focus has driven the adoption of progressive acquisition strategies involving a combination of competition and cooperation. Unlike some DoD programs that have used an "affordability" label to satisfy critics, the strict JSOW goals drove a number of key design and production decisions to produce components like the GEU at low cost.

"Where the main development of the GEU software was originally done at TI Systems, we’re in the maintenance phase now," continues Yeager. "What we’re doing is porting the old assembly code to Ada for a 486 processor using DDC-I’s DACS cross-compiler."

A strong advocate of Ada, especially for safety-critical applications, Yeager and his team know first-hand how features like robust exception handling, multi-tasking capability and built-in run-time contribute to cost-effective software programming for real-time embedded systems.

"Ada’s strong typing and other characteristics seem very limiting to programmers accustomed to languages like C++, but if it’s for a safety-critical system I don’t want creativity. Ada is much more self-regulating in that respect. Even if you know what you’re doing, it has intelligent checks integrated into the language that ultimately produce fewer mistakes in the code," he adds.

Hosted on a UNIX platform, only the DACS cross-compiler is currently in use. However, already in the process of upgrading to the latest version of DACS to eliminate the need to use a second assembler to work with the legacy code, he explains that DDC-I chose to upgrade their DACS toolset specifically to recognize the extensions familiar to their other assembler and make it easier — and less expensive — for his team to manipulate their legacy code. In addition, they look forward to gaining debug capabilities for their target processor.

Though he’s not in a position to endorse DDC-I as a Raytheon employee, Yeager concludes: "Their support has been phenomenal. They helped us get a handle on the upgrade process when we needed guidance. Their technical lead has been here more than once during the upgrade, and to me nothing demonstrates a vendors’ dedication and determination like their top technical guy coming in at eight in the morning and leaving at nine at night just to fix your problems."

Introducing Erik Jensen, VP of Engineering & Director of DDC-I A/S. As Director, Erik is responsible for business development, which includes establishing partnerships with other embedded systems software vendors, as well as sales management for Europe with distributors world-wide. In his role as VP of Engineering, Erik works very closely with US & Europe engineering managers on maintenance and future enhancements of all DDC-I products lines.

Prior to working at DDC-I, Erik spent two years as an Assistant Professor at Aalborg University teaching Computer Science. He then worked for 9 years with a large company developing a Network Management System (NMS) part of a large fault-tolerant computer network system called CRSN. Most of those 9 years were spent as Project Manager of the NMS software development team and later Marketing Manager and Manager of Consulting Services. Finally, Erik was employed as Product Manager, and later as Assistant Vice President of Olicom, now a very active player in the IT Venture market in Scandinavia.

Erik lives in Herlev, Copenhagen, commuting 400 kilometers most weekends to be with his wife-to-be Lisbeth in the green country side close to the largest forest in Denmark (Rold Skov), situated in North Jutland. He enjoys stamp collecting, specifically 1864-1870 Crown-Scepter Issue from Denmark; supplemented with standard issue collections from Austria, Canada, France, Germany, Nordic Countries, United Kingdom, USA and other countries. Erik also has a large comic book collection (classical Walt Disney and DC and Marvel Super Hero series) spanning more than 10.000 comic books from the 30's until present.

The Ada Information Clearinghouse has served a community of software engineers, managers, and programmers for over fifteen years. The Web site provides articles on Ada applications, databases of available compilers, current job offerings, and more. The AdaIC is managed by the Ada Resource Association (ARA), a group of software tool vendors that supports the use of Ada for excellence in software engineering. http://www.adaic.org

[ Back to Top ]

When debugging using the SCORE Multi-Language Debugger, all debug information is kept in special sections of the object file. The program library is not referenced during debugging. Information about the location(s) of source files used to build the application are kept within these sections. So, for example, when a breakpoint is encountered, the debug information is queried to find a source file, line number, and column number for the breakpoint. The file is then opened and the appropriate source is displayed.

Using the actual source file to display the source code provides flexibility in debugging in that a program library is not needed for referencing the source.

However, the debugger will not be able to directly find the source indicated in the debug information if it has been "moved". Consider the following scenerio on NT. An application with its sources in a directory structure below E:\big_project\source has been built, but the debugging is on a laboratory machine that does not have a drive E (and is not connected to the network for access) but has the sources copied into the same directory structure below C:\project_source. The Multi-Language Debugger's DEFINE PATH command can be used to let the debugger know how to properly reference the source files. In addition to providing a mapping for directory structures that have been "moved", the DEFINE PATH can also be used to notify the debugger how to find individual files that have been moved.

The general syntax of the DEFINE PATH command is

DEFINE PATH <compile_pathname> <user_pathname>

This command is used to notify the debugger that a file or directory has been moved from the location it was in when the file(s) was compiled. The presence of a '/' or '\' character at the end of a path indicates that the command refers to a directory.

The debugger keeps track of correspondence between the location of a file when it is compiled (as is stored in the debug information) and a user location where a file or directory may have been moved. Whenever a user refers to a file name, a check is made to see if a correspondence with that user name has been defined. If there is a correspondence, then the corresponding compile_pathname is used to access the debug information about the file. If not, then a check is made to see if there is a correspondence for the directory of the file. If there is, that is substituted and used to access the debug information about the file.

For the situation described above, one would give the command

DEFINE PATH E:\big_project\source C:\project_source

to nodify the debugger to replace all references to files in E:\big_project\source\<rest_of_file_path> with C:\project_source\<rest_of_file_path>

A customer has used this capability to enable NT debugging of PowerPC or executable created on a Solaris host.

If one or more DEFINE PATH commands can be known before the start of debugging, the commands can be placed in an "initialization file" that will be executed on debugger startup. Doing so can make the fact that the files have been moved transparent to the debugger user. ( Equivalently, a "paths file" can be used to provide the same capability.)

In addition to defining paths, path definitions can be deleted. The command for this is:

DELETE PATH [<user path name>]

This removes the specified path from the defined path substitution list. Instead of specifying a <user path name>, \ALL may be specified. This means that all paths are deleted.

The DELETE PATH command is not often used as paths are not likely to change during debugger execution. It is primarily used to correct any mistakes made in using the DEFINE PATH command.

The debugger provides the capability of showing the associateion of any user path with a compile path. This is done with the SHOW PATH command

SHOW PATH <user_pathname>

[ Back to Top ]