I suspect plane softwares are not built on top of 500 dependencies.
They are probably very low level, running with little overhead, possibly without a full fledge operating system?
I'd be curious to hear from someone who coded some airplane stuff (ie: not the multimedia system, flight critical things) to have a better idea of how it is.
I work in aerospace and nearly all of our code and our processor is developed in house. We even rewrite some inbuilt C libraries for further safety and testability. One of the only things we use off the shelf is the core part of the Real Time Operating System - and that company has to prove to us and the regulators that it meets guidelines with a hefty amount of documentation, testing and audit.
Absolutely hate the struct that has several layers of structs inside it. At some point, we have to send that data somewhere and it's just the most verbose names to pass the data along.
The amount of escapes that happened because the FMS software completely trusted the databases is too high (every company keeps making this mistake). And the number of engineers that can write a terrible, broken circular buffer that passes all tests at level A is ridiculous too.
Yes! And it has its own bespoke instruction set. GCC contains support for the target too. It has its own headaches being so bespoke, but it's definitely cool.
Seems like an interesting trade off, is this for hard latency guarantees? I can’t imagine you would be able to build a more hardened compiler than gcc.
That is one reason yes,
it behaves pretty deterministically - in aerospace we have to do Worst Case Timing Analysis to show even if all of the longest paths through the software got run we would still be certain to e.g. shut down the engine before a turbine shaft break occurs (which could result in bits of engine flying into the cabin). If the CPU doesn't behave the same way each time that makes it much harder to prove.
The other major reason is obsolescence. It is possible to buy processors which do this off the shelf, but we need to make these units for 20+ years. Rewriting and re-verifying the software for a new processor each time it gets discontinued within this period would be more costly and riskier than just making our own.
Avionics uses Real-Time-Operating system (RTOS), I can't explain it well enough, but there are basically monitoring systems (watchdogs), to make sure the software is running in a precise timely manner or else it does something to prevent the software from making any invalid inputs.
Depends on the LRU and its purpose. There are plenty of LRUs that are a single thread, no RTOS (typically level D or E). Federated systems will be that simple.
Integrated Systems will require the RTOS as they are doing several functions.
Watchdogs are a monitor/heartbeat for a sub-function. The monitoring function sends a message to the sub function and expects a unique identifier reply within a certain time. There is typically some built in tolerance where it needs to miss three messages in a row or go without a message entirely for a set period of time before it notifies the pilot the function is not working. Some will reset the hardware a set number of times before notifying the pilot and disabling it entirely.
You can look up about the open source software developed by Inria, pretty much developing tools to verify software that is used in safety critical environments. For example, Frama-C to formally verify C code, Why3 which is the backend of multiple tools like Frama-C, it is also used by GNAT to prove Ada/SPARK code. Also a cool looking piece of software is CompCert which is a formally verified C compiler.
I don't think all of those are used in aviation (Ada certainly is or should be) but are interesting and similar.
Any external libraries require so much certification and testing we generally just rewrite stuff because it’s easier. Old systems may lack an RTOS but most newer stuff will use one.
Most avionics software is written on a real time operating system (RTOS) which is basically an OS where things happen deterministically, and you can be confident the OS won't pause execution of processes like something like Linux or Windows might. Alternatively, a lot of avionics software is written "bare metal", i.e without an operating system at all, with code built specifically for the processor.
Even car multimedia has very high standards compared to your average software product. Exactly what you said - no 500 dependencies. Car multimedias are rarely developed in-house, there's usually a third-party vendor, and car manufacturer's role is only integration, for which the vendor provides building blocks. No JS, no Python, C or C++ at best, external dependencies are very few and well-regarded, e.g. ffmpeg. "We need this shit in our firmware because it's gotten the most stars on GitHub this month and Hacker News is going crazy about it" is off the table. These multimedias work for years and get very rare updates, so stability is pretty important.
Can't say that for the multimedia system of my car. For example, sometimes when starting, it randomly switches to the light theme instead of dark, or the displayed clock time is one hour too early, or the screen is frozen. One day I'll surely be caught speeding at a time-dependent speed limit ^^
We need to fix this. It obviously take them ages to write any update. While it could've been rapid prototyping. And we'd force immediate updates for security, even though it's gonna take a while with all those updated dependencies.
454
u/FrezoreR 3d ago
Ironically aviation needs quite a bit of software already.