Aurora Flight Sciences Proprietary

UAV Implementation of Software Reuse Martin L. Gomez

mgomez@aurora.aero Aurora Flight Sciences Corporation

9950 Wakeman Drive

Manassas, VA

(703) 369-3633

2Aurora Flight Sciences Proprietary

Program Name

Overview

Why software reuse?

How we did it

What it cost us

How we benefit

3Aurora Flight Sciences Proprietary

Program Name

Why Reuse?

The traditional answer: lower the DOLLAR cost of software development

Other reasons: More test opportunities means less risk of a crash Lower the opportunity costs…nobody has enough

software engineers Faster turnaround time

4Aurora Flight Sciences Proprietary

Program Name

Why Reuse (2)

Aurora never had more than 6 or so software engineers at a time

The first time we had to develop two UAVs at the same time, we looked for ways to do it more efficiently

Over the years, this infrastructure was used to control Theseus, a 140’, 7000 lbs twin-engine HALE AU-009, a 8’, 140 lbs jet UCAV prototype Perseus B, a 70’, 2000 lbs single-engine HALE Chiron, a Cessna 337 converted to a UAV testbed A hardware-in-the-loop simulator A ground control station

5Aurora Flight Sciences Proprietary

Program Name

How We Did It

All UAVs have some common core of functionality Uplink: turn buttons in GCS into actions on the A/V Downlink: turn numbers in A/V into displays in GCS Lost uplink handling Autonavigation: follow a route through space Autopilot: wiggle the control surfaces in response to

sensors Turn things on or off in response to commands or

automatically

6Aurora Flight Sciences Proprietary

Program Name

How We Did It (2)

With our traditional approach, achieving that functionality took ~10 staff-months per UAV

It consisted largely of software “wiring”, e.g. Read airspeed (say, an A/D reading): $3EA Convert binary to floating point engineering value: 23.2

m/s Send it to the downlink (again turned into an integer) Send it to the autopilot (as floating point) Convert back to FP Send it to displays Archive it

7Aurora Flight Sciences Proprietary

Program Name

How We Did It (3)

The functionality was abstracted into a few primitives (common to all UAVs): Interprocess Communication and Synchronization Reading and writing I/O devices Parsing and generating telemetry frames Autonavigation

A few higher-level functions, slightly different for each UAV: Mapping autopilot outputs to control surfaces Lost uplink handling Autopilot control law infrastructure

…and the rest is UAV-specific

8Aurora Flight Sciences Proprietary

Program Name

How We Did It (4)

Hardware

A/D Reader

Device Driver

D/A Writer

Device Driver

Downlinkprocess

Device Driver

Uplink process

Device Driver

Autopilot

Sensor MgmtControl Mixing

Autonavigation

Lost Uplink

9Aurora Flight Sciences Proprietary

Program Name

How We Did It (5)

The key was open-ended IPC

We chose a RAM database to share signals between processes

Generic processes, like the A/D and D/A handlers, or the uplink/downlink processes, are personalized at startup

A big ROM’d file called “The Very Big List” (VBL) tells each processes what do to on this airplane

Each process scans the VBL when it boots

10Aurora Flight Sciences Proprietary

Program Name

Contents of VBL

Logical name of process

Signal name (“OilPressure”, “PitchRate”, etc.)

Voltage-to-physical units calibration

Does it get downlinked? In which frame? Field size, position, etc.

Thus, each process “knows” what it has to do in this specific instantiation

There may be many instantatiation of a process

11Aurora Flight Sciences Proprietary

Program Name

Autopilot and Control Mixing

Autopilots are pretty generic It’s the gains that vary dramatically from airplane to

airplane The structure is pretty simple:

Surface deflection = gaini * (valuei - commandi)

The gains are physically separate from the structure

The output of an autopilot is a “virtual control surface”

Mapping the virtual control surface to a real one is a UAV-specific job

12Aurora Flight Sciences Proprietary

Program Name

What It Cost Us

The cost to “genericize” our existing software was this: Two staff-months to design the architecture and plan the

project One consultant writing tools and database code for ~3

months One in-house software engineer for ~3 months adapting

existing code

Total of eight staff-months

13Aurora Flight Sciences Proprietary

Program Name

How We Benefit

Being able to get basic functionality up and running in a few days

Spending the time we save concentrating on the unique features of the UAV

Being able to do this in 4 months with two s/w engineers: