eVTOL is the buzz in the aerospace community. With recent advances and FAA initiatives, this technology finally seems ready to take off.  (groan)

People sometimes talk about eVTOL technology as if the old guard who developed the critical software for aircraft in the past has become obsolete. Speaking as one of the old guard, I do not think that is quite right.

A firmware engineer who spent years on certified systems for conventional aircraft would recognize much of the work immediately. Requirements still matter. Determinism still matters. Traceability still matters. Fault handling still matters. The uneasy awareness that "probably good enough" is not a valid phrase in aerospace still matters.

That part did not go away.

What does seem to be changing is something a little more subtle, and also more consequential. The old craft is still there, but the walls around it are thinner than they used to be. In some corners, they are gone entirely, which is exciting if you enjoy systems thinking, and less exciting if you were hoping your subsystem boundary might continue to protect your evenings.

In many traditional fixed-wing contexts, a firmware engineer could do extremely valuable work inside a reasonably well-bounded box. That box might be difficult, safety-critical, timing-sensitive, certification-heavy, and full of failure modes with unpleasant implications. But it was still a box. You could understand its responsibilities, understand its interfaces, and make a fairly disciplined argument that if this thing behaved correctly, it was making a legible contribution to aircraft-level safety.

That was never simple. It was just containable.

eVTOL seems to weaken that containment. These aircraft tend to combine distributed electric propulsion, digital flight control, extensive monitoring, and fault-tolerant architectures that depend on coordinated behavior across motors, inverters, batteries, sensors, and control functions. At that point, "my piece is working" is still necessary, but it begins to sound less like a conclusion and more like the opening statement in a longer conversation.

It is hard not to see some of the drone world in this. The family resemblance is real, even though the certifiable, passenger-carrying version is a far more serious affair. Software-coordinated distributed propulsion did not arrive in aerospace as a complete surprise.

That longer conversation is the real story.

The old instincts were not wrong

Whenever a field gets a new label, there is a brief social window in which people become tempted to speak as though all prior knowledge has turned to dust. That is usually nonsense, and it appears to be nonsense here as well.

For the engineer who learned to worry about stale data, race conditions, edge cases, watchdog behavior, startup sequencing, abnormal inputs, and whether the evidence will survive hostile review, those lessons learned are not obsolete. They still matter in a big way. The familiar standards culture is still underneath the work, even as special conditions and powered-lift guidance have been added to deal with the parts that do not fit neatly inside the older rulebooks.

If anything, the newness of eVTOL makes the old discipline more valuable. Novelty is not a substitute for rigor. It is mostly a way of increasing the number of places where rigor can go missing.

The system boundary moved

This, to me, is the heart of it.

In a more traditional fixed-wing setting, firmware could often be developed with a strong focus on local correctness. Not exclusively, of course. Nobody serious ever believed the subsystem lived in moral isolation from the rest of the aircraft. But the architecture often allowed a sane engineer to reason primarily from local behavior outward.

That becomes harder in eVTOL. The firmware engineer is more likely to find that the job is drifting toward flight software in the larger sense, where the meaning of local behavior depends on what several other parts of the aircraft are doing at the same time. A motor-control function carries more than motor control. A monitoring function carries more than status reporting. A power-management function is doing more than counting beans in a very expensive bucket. Each of these may be part of a broader argument about control authority, energy margin, degraded operation, or continued safe flight after faults.

That changes the engineer’s mental model. It is no longer enough to ask whether a unit behaves correctly in isolation, or even whether it satisfies its local requirements under the tested conditions. The harder question is whether that local correctness continues to mean anything useful once the rest of the aircraft begins doing what real systems do, namely disappointing everyone in slightly different ways at the same time.

That is simply a different job.

Monitoring grew up

Monitoring is one of the clearest places to see the change, because monitoring tends to reveal what the system designers actually fear.

In many conventional contexts, monitoring is concerned with health, validity, and status. Is the unit alive? Is the value in range? Did the interface time out? Did the processor fault? Did the sensor go implausible in some recognizable way? None of that is trivial. It is just familiar.

In eVTOL, monitoring appears to carry more of the burden of answering a more interesting question. Whether a component is healthy is only part of it. The larger question is whether the aircraft is still safe enough, controllable enough, balanced enough, and powered enough to remain inside the intended envelope after something has gone wrong.

Firmware engineers feel that difference pretty quickly. A status monitor reports health. A monitor that participates in the safety argument carries a heavier burden and reaches much closer to operational judgment, whether or not anybody wants to use that phrase out loud. At that point, the work begins to look a lot like flight software, even if much of it is still written with firmware habits and firmware constraints.

And once a monitor starts participating in the safety argument, the standard engineering nuisance of "just add another status channel" loses some of its charm.

Control became more social

That may be an odd way to put it, but I think it is accurate.

Traditional aircraft certainly have sophisticated control systems, and it would be silly to pretend otherwise. But eVTOL architectures often put software in the middle of a much more distributed control problem. Distributed propulsion means the achieved aircraft behavior may depend on coordinated action across many propulsive elements rather than one or two obvious thrust sources behaving in mostly familiar ways.

That draws firmware engineers into questions that once felt slightly more distant from the embedded layer. It also means that some of this work is more naturally described as flight software, even though the implementation still lives close to hardware, timing, and interface reality. What happens if one inverter responds late? What happens if one motor fails cleanly and another degrades messily? What happens if the command path is correct, the telemetry looks plausible, and the physical result is still asymmetric in a way the control law did not have in mind? Those are awkward questions, which is one reason they are worth asking.

They are also system questions in the most practical sense. Somebody still has to implement the behavior, detect the problem, report the right thing, avoid reporting the wrong thing, and do all of it under timing and evidence constraints that do not care how interdisciplinary the conversation has become.

Redundancy got more intimate

Redundancy has always been part of aerospace. The difference now seems to be that redundancy is less of a protective shell around the primary function and more of an active participant in the primary function itself.

The system is continuously deciding what remains trustworthy, what remains available, and how much of the original plan must now be abandoned with dignity. That is a much more intimate relationship between redundancy and behavior than many engineers grew up with.

It also has an annoying habit of making edge cases turn out to be the main event.

Certification also changed tone

There is another difference here that engineers sometimes underestimate at first, perhaps because it sounds administrative until it starts affecting design decisions.

Traditional fixed-wing certification sits on mature rule sets with long institutional memory behind them. eVTOL certification has relied much more on special conditions, means of compliance, and powered-lift guidance because the inherited categories did not fit cleanly.

For engineers, that changes the tone of the conversation. On mature platforms, there is often a long-established sense of what the road looks like and what staying on it requires. In eVTOL, there is more pressure to show why the road itself is sound, why the chosen guardrails belong where they are, and why the evidence actually supports the safety claim being made. The rigor is still familiar. The burden of explanation can be less so.

That is not necessarily a bad thing. It has the healthy effect of forcing a clearer relationship between what the software does, what the architecture assumes, and what the certification argument is really claiming. It just means nobody gets to hide behind precedent quite as comfortably.

What the firmware engineer needs to become

If I had to compress the difference into one sentence, I would say this: the firmware engineer now has to carry more of the aircraft around in his or her head.

The low-level work still matters. Timing still matters. Memory behavior still matters. Initialization still matters. Interfaces still matter. Fault containment still matters. None of the old pain has been reduced. The profession did not become more abstract. If anything, it became more concrete and more entangled at the same time, which is a neat trick when you think about it.

But low-level skill by itself closes less of the loop than it once did. The modern engineer has to understand how those familiar mechanics connect to energy management, control allocation, degraded modes, fault accommodation, and the certifiable safety case built around all of it. That is a broader intellectual job, even if the code still eventually comes down to bits, timing, and somebody asking why that variable can possibly be trusted.

One could make a parallel argument about methods. The more tightly coupled and safety-driven these systems become, the less room there seems to be for the casual neglect of requirements, architecture, and design that has become fashionable in some corners of software.

Some people will love that expansion. Some will hate it. Most will probably do both, depending on the week.

The deepest similarity

For all the change, the deepest similarity may be this: good firmware work in aerospace still begins with skepticism.

What assumptions are being made? Which ones are actually guaranteed? What happens when data is late, stale, contradictory, frozen, noisy, or simply wrong in a way nobody budgeted time for? What happens when the hardware does not fail decisively enough to be convenient? What happens when the local requirement is technically satisfied, but the aircraft-level behavior is still unsafe? Those questions were worth asking before. They remain worth asking now.

That continuity is reassuring. To me, it suggests that eVTOL did not rewrite the whole profession. It expanded it.

And that may be the most useful way to think about the change. It is a world in which the firmware engineer’s habits of mind have to reach farther than they used to, and they must do so without losing their old precision.

 

Further reading