Reduce Development and Testing Time on

Embedded Space Programs With Auto-

Generated Code

Software Engineer

Northrop Grumman Electronic Systems

Matthew Conte

2

Abstract

Embedded software for space systems is one of the most expensive types of software to produce, mainly because of the rigorous testing involved. However, developers on the Northrop Grumman Space Systems Software team have observed that infrastructure code such as class definitions for interface messages, configuration files, and telemetry points is often repetitive, with each class differing only in parameters and implementation of common functions. It became clear that rewriting this repetitive code for each program and, sometimes, within a single program was taking developers’ focus away from the true engineering problems.

To reduce time spent writing repetitive code, we have built up a suite of tools to parse human-readable documents such as Interface Control Documents (ICDs), configuration files, and telemetry definition spreadsheets and automatically generate C++ classes from these files. The use of these tools has improved code reuse and reduced the number of SLOCs that must be tested, resulting in cost and schedule benefits for our programs and freeing up developers’ time to concentrate on the unique technical challenges of each program. This presentation will explain how we designed our code generation tools and discuss the many benefits of these tools to our products.

3

Agenda

• Who We Are

• Why Auto-Generate Code?

• Auto-Generation Tool Suite

• Evaluation of Our Auto-Gen Efforts

• Lessons Learned

4

Who We Are

• Northrop Grumman Space Systems Software (SSSW) group

• Develop embedded FSW for space systems

• Maintain a test software (TSW) suite to control our integration lab equipment and exercise functions of the system

• Work with a variety of languages and tools– C++, Java, Tcl, Python

– VxWorks Workbench

5

Program Background

• Our system is highly configurable – Configuration files

– Telemetry definition files

– Calibration files

• Need C++ code to read in these files at startup and provide the data to the relevant software components

• Dozens of each type of file– Writing and maintaining C++ classes for each individual file would be a large effort

• Settings change constantly during the testing phase of the program– If FSW group is bogged down in supporting test engineers, no time to continue

development

6

FSW Development Cycle

Modify Config File

Update C++ classes to reflect config file changes

FSW

Make code changes to use new values/fields

Provide new build to tester

• Red boxes indicate steps in thecycle where FSW is directly involved

• FSW engineer required at every step

1.

2.

3.

4.

7

Why Auto-Generate Code?

• Engineers don’t want to do tedious work of maintaining dozens of configuration files

– Especially not during Integration and Test (I&T) phase

– Systems and test engineers update config files multiple times per day

– Being bogged down with small updates distracts from critical development work

• Program management wants a shorter schedule and lower cost– Test the auto-gen tool once instead of manually-edited code every time it changes

– Time spent writing tool up-front saves developers’ time later

– Tools can be repurposed for later programs, promoting reuse

8

Auto-Generation Tool Suite

• Developed a suite of Java tools to generate code for several types of configuration files

• Inputs:– Spreadsheets and text files created by Systems and Test Engineers

– C++ class templates

• Outputs:– C++ classes which are built into our flight code

• Hold the data from the input files

• Provide an interface for the rest of the system to access the data

Java Tools Core Library

ConfigParserCalibration

ParserEventAndTele

mParser

Common features such

as parsing text files and

populating code templates

9

Configuration Parser

ConfigParserTool

Test Engineer createsconfig.txt

Tool outputs C++ classes

Software engineer makes required software changesand provides build to tester

Engineer feeds config.txt into the Java tool

Manually coding changes to

program logic is unavoidable. But these are now the

only changes which involve FSW

engineer.

10

Configuration Parser

• Role of the software engineering team is minimized in the process of updating configuration files for testing

• New classes are automatically generated by the tool

• Tool is trusted so testing not required on updated classes

• Quick turnaround compared to manually modifying and testing C++ code

• Turn out build in minutes

• Speed essential because of tight I&T schedule

• Less burden placed on software group to support testing• More time to develop actual flight code

11

Event and Telemetry Parser

Telemetry ICD created in collaboration with customer

EventAndTelemParserTool

Feed spreadsheet intoEventAndTelemParser

Outputs C++ classes anddefinition files for TSWsuite

12

Event and Telemetry Parser

• System events and telemetry points are more complex than config files

• Definitions must be coordinated between FSW and TSW • TSW simulates sending/receiving telemetry from FSW

• Cannot test unless both are in-sync

TSW UUT

FSW

Telemetry

Tool generates the interface as well as the

message-building classes for both TSW and FSW

13

FSW Development Cycle (with tool suite)

Modify Config File

Update C++ classes to reflect config file changes

FSW

Make code changes to use new values/fields

Provide new build to tester

• Removes FSW engineers from steps1. and 2.

• Now only required for code changesin step 3.

1.

2.

3.

4.

14

How Has Auto-Generation Worked for Us?

• Software engineers enjoy the auto-generation approach– Less tedious work

– Reduced testing time for code changes

– More time to work on the true engineering challenges

• Still figuring out the development life-cycle for the tools– See Lessons Learned

• Has been a tougher sell to management– Need to be convinced to spend money on non-delivered code

15

Lessons Learned

• Rigorous testing of the tools should be performed well before I&T phase of the program

– Time fixing bugs in tool is time that could be spent fixing integration issues

– Sinking too much maintenance time into the tool defeats its purpose

• Develop early and reuse– This was the SSSW group’s first foray into auto-generating config code

– Developed tools from scratch side-by-side with FSW

• Keep tools up-to-date– Make change to tool as soon as new formats released

– Don’t let auto-gen files get “stale”; regenerate with new builds

• Maximize use of code templates – Easier to swap out than if the text of the CPP file is hard-coded in the tool

• Convince management of the value of investing time in auto-gen tools up-front