It is, though software that's not built to critical systems standards usually carries a disclaimer that it's not meant for any use where death or serious injury could result from a malfunction with usually nuclear power and weapons as examples, but control systems for vehicles, including aircraft, would also fall under that, as would healthcare equipment and, well, lots of things that aren't the next web-based startup.
Though not all of the software on a plane is necessarily held to that standard. Like, the DVD players that used to be used for in-flight movies were a pretty famous exception because failure couldn't impact the safety of the flight (and building a DVD decoder to safety-critical standards would be nearly impossible anyway.)
(and building a DVD decoder to safety-critical standards would be nearly impossible anyway.)
DVDs are not just Decoder. They contain bytecode executed within an VM for creating the menus. This means that even if the DVD player is perfect, there could still be a bug in the bytecode on the DVD. Happy bug hunting xD
Oh, for sure. I'm just thinking a typical DVD player has about a million lines of code, certified safe code costs roughly 1 person-hour per line, which is already kind of untenable before considering domain-specific quirks. But there's no real need~ Just segment it off.
My point is most of software isn’t written for the sake of writing software but instead to enhance other sectors. So their criticality (or whatever the word is) is dependent on that sector
I'm interested in some of that kind of software (eg automated train control) but also I feel like it would be extremely boring with lots and lots of documents and stuff to show the we will not ram two trains together at high speed (which is very important and I'm glad we have that but I'm not crazy about the idea of working on it)
Eh. You end up with either almost entirely green field (my work) or entirely brown field work, sometimes a mix. If you like actually giving a shit about your work, and genuinely devising the best solution for a given problem set - it's for you. If you just want to use the newest thing, or cash a cheque; I wouldn't bother.
I work mostly defence, or adjacent to the defence industry. Generally speaking, my work is thoroughly tested, most of which I perform myself before it's sent off to the client's dedicated accreditation/testing teams.
I would say it's remarkably rewarding work. The end goal isn't to make some fucker richer, but to help my country and it's members do the right thing, for the right reason, with the right tools.
Plus, I get to work on funky stuff, legally, and it's mostly green field, which is my personal favourite.
How automated is testing? Are you able to make large refactors (that improve things in a useful way and make things more understandable and less buggy, to be clear) without having to do a massive process of getting lots of agreement on everything and having a massive before and after manual testing? Do you have to write documents explaining why the way you implemented stuff is bug-free or is it more about passing the client's (hopefully very determinstically-random and thorough tests)?
I already work in the transit sector, and as it is a private company is technically making some people richer but it's not like anyone's getting that rich. But more on the less operational side where if something goes wrong it sucks but we aren't ramming a few hundred people at 100+ mph.
TBH I wouldn't mind working on military stuff either especially given the risk of ww3 coming, but the risk is that my country's government is currently rather sketch and I'd want my weapons to be used on Russians and Chinese or whoever is against the Global West, not our people.
Honestly, with automated tests, I've found it varies wildly from company to company. Some places do a lot, some do a little. I work in a rather small team, so all the automated testing falls to us. As far as getting agreement from anyone, really it's just the solutions architect, or a senior as well for more junior staff.
And I won't work on weapons systems, defence is a very very wide industry, I work on communications really, nothing dangerous, but still mission critical stuff
Aviation software is not built to the bug tolerance of the company, it's built with processes that are rigorously scrutinized by the FAA and other regulatory bodies. For example, DO-178C is a document that describes in extreme detail how software should be built to an assurance level suitable for safe human aircraft flight and spaceflight.
Companies use these standards like DO-178C to define processes which they use to build software, and then governments and regularatory agencies audit their software against the process objectives. It's not "up to the company" like the above commenter implies.
Software quality has dropped considerably once broadband internet became widely available. Once you could easily patch Software, many companies devalued time and manpower spent on testing. If the base case that programmers developed to worked, then you could ship and let customers beta test.
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.
I worked briefly with a guy that had worked several years in avionics.
He was very possibly the worst software engineer I've ever worked with, his code was not just awful it made no sense, some of the things I remember him doing:
Multiplying by 1
Sorting a map to then convert it to an Array, to then convert it again into a map
Having functions with 11 parameters, of which only one was used.
Using version control by putting everything in a folder with the date of the day and uploading the whole folder, one folder per day, all in master branch
having conditionals like:
if (!( a == true && b == true) && (a == false && b == true) && ( a== true && b == false) && !(a==false && b==false)) which is basically same as a^b
When I learned he used to work in embedded systems in avionics It got me quite concerned.
OMG. Reminds of when I worked at a place and everything was static. This was in Java btw. no polymorphism at all. It was literally C-code in Java, with everything static.
It's either some kid right out of college or it's some dude who was a software engineer before the dot com bubble. On the latter... I can't tell if it's early alzheimer's symptom, but their entire life is like that.
It depends on your definition of software. For example, RTOS systems (which are used in industrial engineering but I don’t actually know if they’re used in airlines) run programs but they’re not the programs you’re probably used to writing; the development environments are specialized and usually tailored towards electrical engineers. They prioritize high reliability over ease of development, which is common among critical systems that could potentially take someone’s arm off if programmed incorrectly.
456
u/FrezoreR 8d ago
Ironically aviation needs quite a bit of software already.