UAV Implementation of Software Reuse.pptVIP

UAV Implementation of Software Reuse Martin L. Gomez mgomez@aurora.aero Overview Why software reuse? How we did it What it cost us How we benefit 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 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 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 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 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