Have you had your coffee today? Then you should be ready for a quick quiz …
Question: “What will Uber, Lyft, aircraft and helicopters soon all have in common? “
Answer: “Certified software testing for UAM (Urban Air Mobility) and eVTOL (Electric Vertical Take-Off & Landing).”

Ahhh, you got that question right? Congratulations on your good brain or good coffee. Had both? Then you’re ready for a more important question:

“Will automotive safety standards apply to these new vehicles or will aviation standards apply?”
Answer: “If it goes airborne horizontally affecting public safety, aviation standards apply.”

Unless you’ve been under 24-hour pandemic lockdown with no internet connection these past sixteen months, you’ve seen the hundreds (likely thousands) of glitzy articles on emerging eVTOL and Urban Air Mobility. If you’ve managed to get vaccinated, mask up, and travel to the key eVTOL makers as this author has for his company AFuzion, then you know eVTOL/UAM are not just the latest popular science fantasy of flying cars. They’re real, they’re flying today, and they’ll be carrying passengers and cargo via pilots in a few short years and autonomously (starting with cargo in less populated areas) a couple of years later.

EVTOL & UAM: Software testing for “flying cars” or aircraft?

If you’re into safety-critical engineering (and if you’re not, congratulations on finding this blog between your TikTok and Instagram sessions), then you know that automotive’s ISO-26262 standard followed and liberally copied aviation’s DO-178C for software and DO-254 for hardware. However, aviation also requires an ecosystem of ARP4754A and AP4761 for the aircraft, systems, and safety with experienced practitioners covering both aircraft and automotive agreeing that aviation’s standards are more rigorous; they’re also independently assessed and certified by major country’s certification authorities such as FAA and EASA.

Now, if it is an experimental aircraft, space tourism related, or vertically launched rockets, these civil aircraft standards do not formally apply. If you’re a really smart and wealthy almost-astronaut, you’ll make your avionics suppliers follow DO-178C even if the FAA won’t.  And this all means that this ecosystem of aviation standards  DO apply for eVTOL/UAM.

What are the implications for eVTOL and UAM software testing?

Under DO-178C, UAM software testing focuses upon the following four areas in priority and sequential order:

1. Functional software requirements-based testing of High-Level Requirements and Low-Level Requirements.
2. Normal range testing, which ensures your functional software requirements were complete enough to cover all normal range operating conditions.
3. Robustness testing including white-box (“Look at and consider the code/design”) testing including error/boundary values, performance/bandwidth, and Worst-Case Execution Time (WCET).
4. Structural coverage analysis assessing the degree to which #1, #2, and #3 above covered the software logic, with additional requirements, then tests of those requirements, added until logic coverage is complete (this is almost always performed via automated commercial tools; see below).

The following figure depicts the relationship between the above four areas of testing required by DO-178C:

UAM testing: Key software safety needs

For software suppliers well-versed in automotive but less so in aviation, eVTOL and UAM software testing will need to address the following gaps:

• Safety requirements derived via ARP4761 based safety impact and pilot workload/automation for each phase of flight
  (Hint:  Take-off and landing are the most risky phases for most onboard equipment).
• Mandatory fully-independent redundancy for critical systems including flight control, batteries/electrification, and thrust (motors and propeller control).
• Structural (logic) coverage based upon more detailed  software requirements; see preceding paragraph and use formally qualified tools such as VectorCAST.
• Software design data flow / control flow determinism with coupling analysis.
• Evidence-based software lifecycle phase entry/exit gates for audited transition criteria.
• More rigorous project-specific plans, standards, & checklists (Hint: simply Google “DO-178C Templates Checklists” for a list of suppliers selling such).