Historically, the selection of a programming language for an Aerospace & Defense project has been fairly clear-cut. In the U.S., Ada was mandated for use on DoD projects until 1997, when the required use of Ada was relaxed in favor of “an engineering approach to selection of the language to be used” (OSAD Memorandum, 29th April 1997).

Despite the change, many high-integrity and safety-related projects in the U.S. continue to choose Ada for their development language, and the use of Ada is actively encouraged on safety-related projects in a number of other countries. Only recently, though, has there been a marked increase in multiple language device software development. The most frequent pairing is Ada with C. Several factors may contribute to this situation.

First, existing safety-critical systems implemented in Ada are being enhanced with additional functionality that requires the use of an RTOS, which is usually written in C.

Second, distributed applications are becoming more prevalent through the adoption of TCP/IP and related networking technologies, which are often implemented in C. This adoption is being driven in NATO defence systems by strategies such as Network Centric Warfare (NCW) and Network Enabled Connectivity (NEC), and also in the US through the DoD Memorandum (“Internet Protocol Version 6 (IPv6)”, 9 June 2003) in relation to the use of IPv6.

Third, the advances in display systems are now open to exploitation by safety-critical and safety-related device software implemented in Ada, which needs to interface with OpenGL and other graphical libraries implemented in C. Finally, code reuse is a growing trend in software development, one that increases the likelihood of a system that mixes Ada and C.

In aerospace systems, all of these factors can occur together. A case in point is Integrated Modular Avionics (IMA) systems, where Ada and C device software can operate side by side on the same processor, driving graphical displays, and communicate over an Ethernet or AFDX network.

In order to efficiently develop and optimize mixed language device software, developers need to be able to perform the following:

• Call Ada procedures from C functions and vice versa

• Perform mixed language source-level debugging

• Understand the memory utilization of the mixed language application

• Understand the system-level behavior of the mixed language application

Mixed Language Interaction

Many programming languages provide limited support for interfacing to other programming languages. As a result, language compilers and debuggers have provided limited support as well. Because of this, developers have had to implement their own bindings between languages in assembler, an error-prone activity that can result in non-portable code. However, the Ada95 programming language provides a well-defined interface to the C language, enabling developers to easily and safely call C functions from Ada procedures and vice versa.

For example, a command and control system implemented in Ada historically may have performed I/O over a bus or via serial devices directly from Ada routines. In order to upgrade this system to support IPv6 networking connectivity, though, it is likely that the application will need to interface with an IPv6 stack implemented in C.

For reasons of future maintainability, we may prefer not to embed IPv6-specifc code within the Ada command and control application, but rather to use an abstraction layer to hide or minimize the interface with the network stack. This could be done by using the inter-process communication (IPC) capabilities provided by the underlying real-time operating system (RTOS). In the case of a VxWorks-based implementation, VxWorks message queues could be used for IPC, and a GNAT Ada procedure would call the msgQReceive()API, which is implemented in C as shown in Code Block 1.

This enables calls from GNAT Ada to C in a straightforward manner, provided that the appropriate Ada data types are selected to interface to the data types used in the parameters to the C function. A blocking msgQReceive() call from the Ada application is shown in code Block 2.

Mixed Language Debugging

Once developers have used the ability to call C functions from Ada procedures, and vice versa, they will also want to perform source-level debugging of the mixed-language application code. This presents its own challenges, particularly since compilers and debuggers have tended to use a variety of object module formats (OMF). Developers who have tried to bind C++ applications created by different compilers know this problem all too well.