Tool Support

It is apparent that the process of Figure 3.1 is inefficient and error prone. But it leaves plenty of room for automation and the experiment described in section 2.2 would not have possibly succeeded without the reusable architecture and the process being in place.

First, the process suggests a natural specification language: MatLab. While the MatLab source contains all necessary equations and formulas as well as test code to produce various plots, it does not contain information about the kind of telemetry to send, the commands and their parameters that are to be received, and how to respond to a particular command. Thus the specification language was defined as an extension to MatLab that includes the following additions:

• Optional type information can be added to determine precision of data and to select specific Ada types (e.g. the support infrastructure contains a 4-element float vector type as well as a quaternion type which are structurally equal but have different associated operations).
• Telemetry is specified by listing those variables whose values are to be included in the telemetry stream.
• Commands are defined by a name and possible parameters.
• A hierarchical finite state machine (essentially a textual version of state charts [6]) specifies the actions to be taken in response to a clock tick or a command.
• Special comments were added that can be included in generated Ada code and documentation.

In addition, it was necessary to mark certain inputs (e.g., test code that generates plots) so that it can be excluded from processing by FCG. All extensions were added to MatLab using special comment characters such that a source file of the extended language can still be processed by MatLab. The resulting language is ugly by any measure. But that problem was far outweighed by the benefits of having a single representation of the design. Engineers found surprising ways to make their specifications readable.

FCG is a batch tool written in Common Lisp that takes specifications written in the extended MatLab language and generates the following outputs (controlled by command line options)

1.

Database records that describe telemetry and command information necessary for building ground software.

2.

An Ada package that conforms to interfaces and conventions of the reusable architecture. While the code is commented and human readable it is ready for system integration and does not require human modifications.

3.

A test environment that allows interactive or scripted unit testing of the generated Ada code. The test environment contains an interpreter that allows inspection and modification of all variables, calls to defined procedure, and the simulation of clock ticks and the arrival of commands. It also allows the generation of plots that can be compared with those generated by MatLab.

4.

Documentation of both the design and implementation of the module. This information is based on the specifications, embedded comments, and decisions made by the Ada code generator

  

Figure 3: FCG fits into the existing development process and eliminated virtually all manual handling of the Ada code for functional components.

The new tool substantially simplifies the development process with only minimal additional work (see Figure 3.2). The aerospace engineer has to provide additional specifications in the MatLab source and is now performing unit tests of the generated Ada code. Any necessary code change is made in the MatLab source. Even with this additional work, the AE's job is simplified since the documentation requirements are reduced and the communication with the software engineer is eliminated.