1 / 13

UAV Implementation of Software Reuse

UAV Implementation of Software Reuse . Martin L. Gomez mgomez@aurora.aero. Aurora Flight Sciences Corporation 9950 Wakeman Drive Manassas, VA (703) 369-3633. Overview. Why software reuse? How we did it What it cost us How we benefit. Why Reuse?.

findlay
Download Presentation

UAV Implementation of Software Reuse

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. UAV Implementation of Software Reuse Martin L. Gomez mgomez@aurora.aero Aurora Flight Sciences Corporation 9950 Wakeman Drive Manassas, VA (703) 369-3633

  2. Overview • Why software reuse? • How we did it • What it cost us • How we benefit

  3. 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

  4. 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

  5. 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

  6. 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

  7. 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

  8. How We Did It (4) Lost Uplink Autonavigation Autopilot Control Mixing Sensor Mgmt D/A Writer A/D Reader Downlink process Uplink process Device Driver Device Driver Device Driver Device Driver Hardware

  9. 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

  10. 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

  11. 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 = S 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

  12. 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

  13. 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:

More Related