Lil’ Hoss Design Part 1 – requirements capture and a Formula 1 racer

As many visions do, it started while staring at the stars on an Arabian night. 

I had been deployed to Qatar for four months, most of which had been consumed by refereeing imbecilic squabbles amongst military spouses¹ and dragging my MBA across the finish line.  On this evening, cheap cigar smoke curling around my head as card-playing Airmen listened to distorted hip-hop on even cheaper speakers, I mused on the state of pylon racing. A high-speed contest where airplanes complete left-turning laps at over 400 mph, this uniquely American sport seemed to be rapidly slipping into memory. 

Though once synonymous with technological achievement and American daring, air racing seemed on its last leg.  A sport that in the 1930s had featured hundreds of local exhibition events a year, and whose Cleveland championships were broadcast nationwide on the radio, had effectively dwindled to a shadow of its former glory.  In these early days, the winning pilots received a towering trophy and recognition as a household name, including figures like Jimmy Doolittle, Roscoe Turner, or Jackie Cochran, who are still recognized by the general public nearly a century later.  Today, there’s effectively one race, and after the carnage of the Galloping Ghost crash, the future of that was in doubt.

Which seemed odd.  Not only was the excitement of flying several hundred miles per hour, 50 feet above the ground (and equally close to the competition) self-evident.  But with decent-quality Formula-1 racing aircraft available for about the price of a used pickup truck, the barriers to entry seemed low.  Participating in this oddly accessible excitement was a must.  Buying a plane would have been an obvious choice.  I already owned an airplane whose sale could have easily funded a decent-condition Cassutt-M3 and associated support paraphernalia.  But that would have deprived me of something much more satisfying. 

With too many hours of my long days spent getting dressed down by General Officers because their spouses didn’t like the color of the new lawn furniture in their quarter-million USD a year residence, I needed an anchor to reality.  With two half-completed engineering master’s in my rearview mirror and no opportunity to flex my technical muscles in the career windshield, I needed to design my own Formula-1 race plane.

The first step would be good requirements capture.

Requirements capture is an often overlooked and unloved field of systems engineering and project management.  Before we can build anything, we logically need to figure out what that thing is to be.  The rub is how tightly we care to define it.  In many ways, requirements capture is like holding a bird: hold too loosely and it escapes², squeeze too tightly and the bird loses important bird-features, such as breathing.  From my software days, the projects tended towards the former, with inarticulate end users effectively wishing for a manifestation of unspoken whims.  During my military construction days, the latter was the rule, with hardcopy facility requirements towering over the buildings they specified. 

In a linear world with well-understood processes and delivery, the architectural-design-esq big-requirements-up-front (BRUF)³ approach can make sense.  A building uses reinforced concrete and steel EMT conduit, polymer pipes and gypsum drywall.  The delivery of a final form composed of these elements is relatively predictable, to the point where competing project estimation software packages will often agree to within a few percent on cost and schedule. 

However, the word is rarely linear.  As an example, I once did a design review on an 80 ft+ wide antenna for satellite communications.  The several-thousand-page design was complete, with details down to the fire exit signs, paint colors, and what kind of adhesive to use to attach conduit brackets to the concrete walls.  I was troubled by a nagging gap, though.  This antenna, weighing roughly as much as a herd of African Elephants, would have to move quickly to acquire a new satellite.  In turn, to transmit the dynamic loads of this movement into the ground, a significant concrete pedestal was specified.  But there was no geological report of the ground into which these loads would be transmitted.  After days of careful review, I found a footnote to the effect of “Once the soil report is complete, run the calculations and make the pedestal long enough to support the load.”  This from a project that was about to “break ground”!

To meet the inherent limitations of BRUF, a cornucopia of alternate requirements capture methodologies have sprung up, almost all featuring a snarky name and leveraging some iterative scheme where an early minimum viable product is used to check “is this really what you wanted?” with the feedback informing rapid refinements to an end.  They work okay for software, not as great for satellites and buildings, and are worthy of posts unto themselves.  In all cases, these approaches leave an “out” that avoids premature optimization by pushing specification to future steps.  The biggest risk inherent to these approaches is the inevitable increase in cost and loss of malleability as a project progresses.

As seen above, a notional change in requirement or end goal becomes increasingly expensive the further one progresses into the project cycle.  Endeavors such as software or literature maintain some degree of malleability throughout the project’s lifespan.  To borrow an argument from proto-hacker Paul Graham, a peculiar thing about software is that there is no abstraction of medium: text (in the form of specification) turns into other less abstract text (source code) in an iterative cycle until the source code itself is a hyper-specific specification that is fed to a compiler.⁴  This is in stark contrast to, say, a diesel engine, where at some point, blueprinted components must be machined from steel or cast in aluminum.  In these textual mediums, the cost of poor requirements capture begins low (reflexively: at the labor cost of requirement generation) and proceeds in an increasing curve until it matches the program cost at the time of delivery.

For those efforts where delivery in some physical medium is necessary, such as our diesel engine, the cost of late-stage requirements change can easily exceed the original program cost.  Commitment to facilities, fabrication, and disposal can easily exceed the original cost of the program – and neither example incorporated the opportunity costs inherent in expended labor, market timing, or Nunn-McCurdy breaches.   Since this is a story about airplane design, the chart above recognizes the reality that late-stage “re-starts” driven by requirements creep or changes can easily exceed the original project cost.  Ask your favorite purveyor of fighter aircraft for some specific examples; they each have a few.

So, I needed a set of requirements that would deliver an airplane design that could be tested at my home field (a 6,000ft runway at an elevation 6,875ft MSL, with a summer density altitude of roughly 30,000 ft), could place well at the National Championship Air Race in Reno, and meet the aviation records body’s requirements for the Formula-1 class.  Too much and I’d be painted into a corner.  Too little, and I ran the risk of realizing halfway through welding and fiberglass layup that I had the wrong problem.

Which is where my Formula-1 specification began.

After about three cigars’ worth of thinking, the specification was to be a single paragraph. 

With the whimsical name “Lil Hoss” (don’t ask, I honestly can’t remember) to identify the project, a set of minimum requirements was born.  The figures were chosen based on the performance of the two most winning aircraft in the Formula-1 class, Jon Sharp’s Nemesis, since retired and on permanent display at the Smithsonian Air and Space Museum, and Mike Arnold’s Endeavor, still winning races at that time.  These aircraft both had an additional advantage – both were particularly well documented from a design and construction perspective.  Sharp, in marketing follow-on sport-plane kits (the aptly named Nemesis NXT), had publicly captured much of his thinking and design choices on Nemesis.  Arnold, seeking a way to monetize his designs without the litigation hazard of actually selling airplanes⁵, had produced a series of films documenting the design and construction of both Endeavor and his personal AR-5, which set the speed record for airplanes under 300kg. 

The first problem was the required cruise speed.  Even with a highly optimized Continental piston engine, there would only be so much brake horsepower that could be squeezed from a 200cuin, normally aspirated engine at race altitudes and temperatures.  Additionally, propellers become linearly less efficient with cruise speed – the faster I went, the less of that horsepower would be converted to pounds of thrust. Looking at Jon Sharp’s Nemesis, with its almost negligible tail volume, and noticeable reflex on the laminar wing, it begged the question: how much of a hindrance is the 66 sqft minimum wing area in Formula 1 pylon racing?   

Running the numbers, it turns out a lot.  Ideally, for my goal race speed, a much smaller wing would be ideal, with costs incurred in increased stall speed, takeoff and landing distance, and low airspeed handling.  However, aside from takeoff and landing distance, which were generous, these were not requirements.  Per the rules, I needed 66 sqft of wing, and would have to lose wetted area somewhere else.  Not in the rules (or my requirements) was the need to have a tail or an associated tail cone.

Further flensing of unneeded area and weight continued.  I built a spreadsheet.  It evolved into a 50+ tab spreadsheet, quantitatively capturing everything from the parametric shapes of airfoils and fuselage structures to airframe weights, electronics, and the anatomical placement of the crew (me).  An increasing sea of Python code translated changes in these labyrinthine tables into models that could feed computational fluid dynamics codes, CAD software, and later physics-based flight simulators.  This poor man’s digital twin allowed for rapid experimentation and concept development within the confines of the original requirements.  Rapid progression of these models quickly pared down predicted drag.  A tapered “Snoopy” shaped nose, smoothly blended surfaces, and an emerging manta-ray-like flying wing were surprising developments as rapid model – digitally test – model cycles continued.⁶

To quote the aviator’s saint, Antoine de Saint-Exupéry, “it is finished not when there is nothing left to add, but when there is nothing left to take away.”  Much as the original requirements were best when they completely described what the thing was to be, and no more, the design concepts themselves seemed on the right track when tending towards simplicity.  If I had to “spackle” a complex idea on, then I was probably off.  For example: to reduce the approach angle and landing speed, some flap or speed brake is needed.  But in a flying-wing conventional flaps produce too much pitching moment.  Wing-mounted speed brakes, a split flap, or fuselage mounted brake could be an option.  But each requires further complexity – wing speed brakes require mounts and actuators in a small space.   A ventral flap can disrupt engine cooling flow.  Conventional flaps coupled with a ventral brake, on a single actualtor… could work.  And so the design studies went.

Until I realized I was solving the wrong problem

My requirements were bad.

Six months, a wedding and a honeymoon later, the Air Force had another assignment waiting for me.  This time, in the wine country of Vandenberg Air Force Base.

On a weekend back in Colorado, during a break from my sleepless, thermogenic-fueled campaign of grout repair and furniture packing, I showed my wife Becky the previous month’s design thoughts and analysis. My new bride asked if I intended to build this plane, and on hearing my “affirmative,” she made a single statement of “I don’t get it.”  A little affronted, I launched into further insights on viscous flows and cooling drag, when she stopped me and (as always) made an insightful point: “No, what fun is an airplane with only one seat?” Since splashing MIGs was not in the single paragraph mission requirements, I knew immediately that she was right.

The original sin of requirements capture.

Specifically, the premature optimization that is the root of all evil.  And with that, my sketches of pneumatic ejection seats, dorsal speedbrakes , Meredith-effect-heated-cowl flaps and Peltier-effect-cooled-induction were retired for a second attempt at the airplane design I actually wanted.

In the next part, we’ll look at where this went wrong, how I should have emulated the Boeing 727 and ignored the DC-1, and where the next iteration of design would go.

Let me know your thoughts below, and click here to subscribe!

-Jerome

Want help with your requirements capture processes? Need a systems engineering review of your aerospace projects? Crate of Thunder Aerospace Consulting can help you!

1. To be fair to these individuals, the immigration rules of Qatar at the time precluded them from having a car or real employment.  Trapped together in small, walled neighborhoods in 120F+ heat, it was inevitable that intrapersonal drama would result.  ↩︎
2. In the case of the DoD usually taking several hundred million USD with it. ↩︎
3. Yes, literally pronounced “BRUF”, rhymes with the noise a dog makes. ↩︎
4. I use an almost identical, albeit more generalized, argument for why artificial intelligence will not be completely replacing engineers anytime soon. But that’s another post. ↩︎
5. A certain blogger may be pursuing a similar strategy. ↩︎
6. At one point, I let the machines take over, creating an (over)simplified genetic algorithm to parametrically feed the results of a previous test into a new model with randomly generated “tweaks.”  Sets of well-performing models were combined (“bred”, in algorithmic parlance), and the resulting “offspring” analyzed.  Some were strangely beautiful.  Others were just strange. ↩︎