Thinking of aviation makes me remember the impact of doing things right.
Software Engineering Lessons from Aviation
51–56 of 56 posts
Re: Software Engineering Lessons from Aviation
#52Though article isn't about software development in the aviation industry, a few thoughts on that: The industry is really slow to change its practices and tools. Like the use of C for most software, I do feel a more safer language out to be preferred. Use of 1553 bus for inter device communication, the bus and protocol aren't general, it is very opinionated/rigid about the manner in which communication should happen.…
>The industry is really slow to change its practices and tools. Like the use of C for most software, I do feel a more safer language out to be preferred.
And what language would that be, where it has absolute determinism (which rules out anything with GC)?
They tried using Ada years ago for avionics. The problem here is that no one knows Ada any more, and no one really wants to make a career out of it since it isn't used anywhere else.
So, in practice, C and (a narrow subset of) C++ get used. Maybe Rust would be a good choice in the future.
Re: Software Engineering Lessons from Aviation
#53Earlier quoted context omitted.
it is very opinionated/rigid about the manner in which communication should happen This could be a strong factor in its popularity. If things must happen in a certain order, then the behavior of the system becomes easier to verify. Ease of verification should never be understated in safety-critical systems.
Yet the industry uses largely the C language, which isn't a model for safety or ease of verification.
It is, compared to other languages, because it's simple and deterministic. The #1 most important thing with avionics systems and software is determinism. That's why they even disable CPU caches on avionics systems.
Re: Software Engineering Lessons from Aviation
#54Earlier quoted context omitted.
After fixing a recent bug, I asked my client company what if any postmortem process they had. I informally noted about 8 factors that had driven the resolution time to ~8 hours from what probably could have been 1 or 2. Some of them were things we had no control over, but a good 4-5 were things in the application team's immediate control or within its orbit. These are issues that will definitely recur in troubleshoot…
For anybody into podcasts, I can recommend "Causality" https://engineered.network/causality/ John Chidgey digs into well known catastrophes, analyses what went wrong, and what was fixed afterwards. Not software related but promotes a safety mindset very well.
I love Chidgey's podcasts
Re: Software Engineering Lessons from Aviation
#55Earlier quoted context omitted.
For anybody into podcasts, I can recommend "Causality" https://engineered.network/causality/ John Chidgey digs into well known catastrophes, analyses what went wrong, and what was fixed afterwards. Not software related but promotes a safety mindset very well.
I love Chidgey's podcasts
:heart:
Re: Software Engineering Lessons from Aviation
#56Earlier quoted context omitted.
>as software engineers we find a bug and just fix it. [...] Unfortunately, the recent 737 MAX incidents seem to have changed this. I think there's some nuance about MCAS that's lost in all the media reports. As far as I understand, the MCAS software didn't have a "bug" in the sense we programmers typically think of. (E.g. Mars Climate Orbiter's software programmed with incorrect units-of-measure.[0]) Instead, the MCA…
That's a different issue. Aircraft systems are classified as to degree of risk. This is from MIL-STD-882C. - I Catastrophic - Death, and/or system loss, and/or severe environmental damage. - II Critical - Severe injury, severe occupational illness, major system and/or environmental damage. - III Marginal - Minor injury, and/or minor system damage, and/or environmental damage. - IV Negligible - Less then minor injury,…
> So either MCAS needed to have more limited authority over trim, so it couldn't cause trim runaway, or it needed the safety features of a Level I system.
There are two other dodgy things going on. One you can't disable MCAS without totally disabling the electric trim. And the mechanical advantage of the manual trim isn't sufficient to re-adjust trim once it's too far out. And hasn't been _forever_.