Summary

in an Aircraft
In November of 2005, I joined with Marc Ausman and Jake Dostal to build a prototype of the VP-200. This system replaces circuit breakers, fuses, and switches with solid state electronics in the experimental aircraft (home-built) industry. And although the system could power devices simplistically, it uses the flight mode of the aircraft to automatically handle device power transitions. In addition to power control, the VP-200 levies the flight modes for a strong context-sensitive base to enhance engine gauges, provide smart alerts, and display checklists.
In July of 2006, our doors opened. Within 9 months, we had the production hardware in-house. Within 13 months, we launched the VP-200 and VP-100 at the EAA AirVenture 2007. To date, there are over 80k lines of code, 7 custom circuit boards, and 4 core products.
Accomplishments
Co-Founder/VP Engineering/Software Lead/Software Developer
- Developed the software for the first prototype which was instrumental in securing venture capital funding for the company.
- As a collaborative effort, defined over 700 system and software level requirements for the flagship product based on use-case scenarios, conceptual feature sets, and non-competing avionic capabilities.
- Within a deadline of one year, designed and developed the production software for our two initial products (VP-200 and VP-100) which were successfully launched with Best New Product 2007 at AirVenture, the premier aviation air show in the U.S.
- Performed unit, lab, and field tests resulting in the reduction of hundreds of defects, enhancement of the user-experience, and over 400 hours of issue-free flight hours.
- Based on existing code, created two new products (VP-50 and Climate Control) within a 3 month period, allowing for increased sales and revenue. Introduction of the Climate Control system landed Vertical Power an article in Flying, the leading certified aircraft magazine in the U.S.
Technical Highlights
Software speaking, there are two different development aspects of the VP-200: (a) a soft-real time system for controlling and monitoring the Electronic Circuit Breakers (ECB) on the Power Control Unit and (b) a user interface for the pilot (Display Unit).

The control and monitoring for the ECB system runs on an 8-bit microprocessor without an OS. The system powers standard avionics (lights, EFIS, GPS) and the mechanical systems (starter, flaps, and trim). There is a primary loop that cycles through the different aspects of power control. One such control was determining whether an ECB has a short or over-current condition. There were several iterations on the detection algorithms to ensure that there were not any false-positive notifications, as this proved to be tricky with respect to certain high current inrush and continual cycle (e.g. strobes) lights.

The user interface runs on an Xscale (ARM core) processor running embedded (small footprint) Linux. The core of the software is written in Java with some JNI/C and Linux driver code to access the hardware. I built an AWT-like widget package on top of SDL in order to reduce the overhead of the standard AWT/Swing packages which requires X-Windows. Since data and control arrives from multiple sources, I wrote a generic event handling system that passes data to the appropriate data listeners. The flight modes are implemented as a set of objects that handle transitions and in-state control. Adding new features results in one or two new objects (including adding/updating a user interface screen for setup), easily plugging into the standard data pathways.
Lessons Learned
- Requirements for a real product are iterative and continually changing. Capture desirements and vet out the requirements just-in-time.
- Track all bugs above unit level testing. Notes about previous issues are very instrumental for handling future bugs/feature changes.
- Long term maintenance and code branching needs a strong, written process.
- A wiki works great as a lab notebook. You can add whatever you want, and anybody can see what you're up to.
- Custom hardware must reflect the needs of the software; software must reflect the needs of the custom hardware.
Fun Facts
- It can be quite cold in a hanger during the middle of winter in Albuquerque. So we set up a small enclosure with a space heater to allow me to tweak software while we evaluated pre-production hardware on Marc's aircraft.
- The current inrush profile for a strobe light can wreak havoc on over-current detection algorithms.
- Due to significant code re-use, the VP-50 software took only a month to write, verify, and validate.
Skills
- Embedded Linux/Driver Modules
- Linux tools: Ant SVN Make
- C
- Java/JNI
- ARM
- Atmel ATMega
- Hardware Verification & Validation
- I2C SPI RS-232/-422
- Electronics Technician
- Field Test
- Requirements Tracking
- Bugzilla
Links
- Vertical Power
- EAA Airventure
- Requirements Management - This is a great system, built by software engineers for software engineers.
Notice: images used with permission from Vertical Power.