Hacker News Reader

Comment by na85 | Hacker News Reader

You don't program "an airplane". Each box has its own spec to which it must conform, so for example the little controller that regulates fuel flow into the combustion chamber is first modeled as a system in e.g. MATLAB. For throttle position X, at altitude Y, with air temperature Z and Mach number W, the fuel flow must be ABC pounds per hour so set the servo valve position to DEF.

So on and so forth (it gets a lot more complicated than that but you get the idea).

Then, you ask the mechanical guys what the operating environment will be (vibration, temperature, pH, etc.) and you source a chip from an approved manufacturer that can handle your system dynamics and the environment. Then you hit the autocode button in MATLAB, flash the generated code to the chip, and run the programmed chip through bench tests.

View on HN

> For throttle position X, at altitude Y, with air temperature Z and Mach number W, the fuel flow must be ABC pounds per hour so set the servo valve position to DEF.

This is fascinating. So underneath it it's a big decision tree with a few defaults thrown in. Is that an accurate description?

I don't know how it's done for planes, but I've heard that many automotive ECUs are programmed graphically, as a block diagram. The engineers basically pretend it's an insanely complicated analog system with amplifiers, filters, switches, and what have you. Then the whole thing gets compiled into a real time binary that simulates the system one timestep at a time.

That is correct for a lot of aircraft systems as well, especially in the design/requirements phase the actual implementation might vary of course. I've personally used Simulink a lot for control systems.

I.e. hydraulics, fuel transfers, ECS etc.

Yeah, when trying to diagnose issue with my car I found ECU documentation that contained suspiciously complicated block diagrams (with all parameters labeled with abbreviated German), which I'm not sure if they are just documentation or program source itself: https://i.imgur.com/BcW1ho6.png

Not sure about aviation computers, but for car engines it’s typically a set of tables with something like air pressure on the y axis and engine rpm on the x axis where each cell has a fuel value. Then you have other tables for other variables such as spark ignition advance, or anything else that can be changed electronically on the specific engine. Tables are typically used because they make the software quite simple/fast. And the values in the table can be tweaked (either from simulation or by experiments on the real engine) that separates the configuration from the code.

  > for car engines it’s typically a set of tables with something like air pressure
  > on the y axis and engine rpm on the x axis where each cell has a fuel value

You can see those values being edited here while tuning a Viper:

https://www.youtube.com/watch?v=93cOSZkKAvo

Think of it more like a piecewise continuous model with a decision tree that chooses which model to use.

>So underneath it it's a big decision tree with a few defaults thrown in.

Not in the sense that it's yes/no decisions all the way down. Most of the inputs are continuous functions, and your output will be a function that combines the inputs in some particular way specific to the application.

You might do something like:

   if (mach > 0.5 && mach <= 0.85) {
      ...
   }

And so on and so forth

  > if (mach > 0.5 && mach <= 0.85)

But surely there's some else clause at the end with a default value, no? Or at the minimum log.error("No matching flight conditions configured", pressureAir, pressureFuel, airspeedMach, engineRPM) or such?

Yes of course there is fault handling! That's one of the hard things about safety critical sw is that you actually have to deal with everything.. Lettings things "fail" or be "undefined" isn't really an option.

E.g. Mach is derived from multiple sensors so you have a first layer of redundancy there, then if all fails (and you can detect it ofc..) you'd probably start some kind of dead-reckoning and issue WARNINGS accordingly to the pilot and/or connected systems that change its behavior to a more conservative one.

There is almost always some kind of "safe state" that wouldn't depend on the input signals at all. It would obviously negatively affect the performance of the aircraft and most likely reduce its operational envelope.

Pilot action would be required, i.e. reduce altitude, reduce AoA, reduce air speed etc. LAND ASAP etc. :)

Terrific, thank you!

Reply on news.ycombinator.com