3 ms·

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 com

by na85 5y ago

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.

vishnugupta 5y ago
> 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?
- marcan_42 5y ago
  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.
  - mrmlz 5y ago
    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.
  - garaetjjte 5y ago
    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 https://i.imgur.com/BcW1ho6.png
- MobiusHorizons 5y ago
  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.
  - dotancohen 5y ago
    > 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 https://www.youtube.com/watch?v=93cOSZkKAvo
- snovv_crash 5y ago
  Think of it more like a piecewise continuous model with a decision tree that chooses which model to use.
- na85 5y ago
  >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
  - dotancohen 5y ago
    > 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?
    - mrmlz 5y ago
      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. :)
      - dotancohen 5y ago
        Terrific, thank you!

by na85 5y ago

vishnugupta 5y ago

> 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?

marcan_42 5y ago
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.
- mrmlz 5y ago
  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.
- garaetjjte 5y ago
  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 https://i.imgur.com/BcW1ho6.png
MobiusHorizons 5y ago
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.
- dotancohen 5y ago
  > 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 https://www.youtube.com/watch?v=93cOSZkKAvo
snovv_crash 5y ago
Think of it more like a piecewise continuous model with a decision tree that chooses which model to use.
na85 5y ago
>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
- dotancohen 5y ago
  > 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?
  - mrmlz 5y ago
    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. :)
    - dotancohen 5y ago
      Terrific, thank you!