Hacker News Reader

Comment by jalino23 | Hacker News Reader

I as a frontend web dev. just awed in how do you even begin to program an airplane

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.

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

Much like you program any other computer. At my shop we use C, C++ and Ada. Some problems suit themselves well to modeling, so something like Simulink can be used (which translates to C++). What throws people off is usually the fact that these are hard real-time systems (requires a different mindset) and that some functions are distributed across multiple computers.

Hey there I teach people to code some of them I teach web.

I think the easiest way to go about this, is to learn how to fly a plane. Then once you've learnt that you can kinda learn it piece by piece. IE: it's easier to teach someone how to drive a car first before teaching them how to mod it and write a self-driving program for it.

But, then again, some mechanical engineers learn how to build planes, before knowing how to fly a plane.

It really helps if you can reach out to someone in that industry and they can show you the ropes

My first day on the job at Boeing, in the 757 flight controls group, as a newly minted mechanical engineer, my lead engineer told me to "size the jackscrew". The jackscew is what drives the leading edge of the stabilizer up and down. If it fails, the airplane becomes uncontrollable.

I went back to my desk, stewed for a while, and panicked.

So I go back to Erwin, shamefaced, and said I had no idea how to size the jackscrew. He chuckled, and said "did they teach you column buckling in school?" I said sure. He said it's a column buckling problem. You know how to do it.

And sure enough, I did.

Nothing to be ashamed of there. You hadn't had enough domain specific exposure to cut through the jargon from the sounds of it. First exercise I do with my hires/juniors is work to connect what we're doing with something they already know.

That's communication 101.

201 is divesting yourself of the assumption you always know exactly what everyone else is talking about, and remembering that it never hurts to play the fool and learn something, as in the process of being taught, sometimes new knowledge will become apparent.

People who master both pieces tend to be the most amazingly competent people I've ever had the privilege to work with.

OOh, ooh, ooh, me too!

A couple months into my first job, the chief engineer, who was an ME in an EE company, told me to figure out how a certain filter worked. I sat down at my desk with the diagram for hours struggling with it. Then I got up to go to the bathroom or something and came back in through a different door and saw the schematic upside down and that from that perspective it looked totally different. It was just a 2-port network; I know all about 2-port networks!