Live data from Hacker News

Software Engineering Lessons from Aviation

riceo.me

31–40 of 56 posts

Re: Software Engineering Lessons from Aviation

#31

Though 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.…

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.

Re: Software Engineering Lessons from Aviation

#32
post #24

Earlier quoted context omitted.

There is no other useful meaning of "correct code" apart from "matches specification/design". There is no notion of correctness for design. The design may not be consistent with safety requirements for example.

Of course there is correctness for design! When reviewing a design, the first thing to verify is if it can satisfy its input requirements. In your example, a design that has to satisfy a safety requirement but doesn't is not correct and must be rejected.

The safety requirements are one of the design decisions that have to be made, not a separate thing that exists outside design space.

Re: Software Engineering Lessons from Aviation

#33
post #11

Earlier quoted context omitted.

There are a handful of highly respected books that everyone knows software engineers should read, like "The Mythical Man-Month" and "Peopleware". Yet whenever I read one of these, I found I learned very little. Everything in them was obvious -- to those who are 'in the trenches'. What we need is a way to get managers to read these, and take them to heart. Even when my manager had a copy of the book sitting on their d…

I know few of us want to become managers, but when you find a harmful one, it's time to take on that responsibility.

What responsibility?

Re: Software Engineering Lessons from Aviation

#34
post #8

I think there's a lot to learn from the aviation industry. I did a talk at my companies internal conference on this (turned into words at https://medium.com/ingeniouslysimple/why-dont-planes-crash-1... ). For me it's the mindset that differs. Too often as software engineers we find a bug and just fix it. Aviation goes a step deeper and finds the environment that created the bug and stops that. Unfortunately, the rece…

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

Yes, everyone wants to blame the pilots or the engineers at Boeing.

This was not an engineering problem, it was a greed-created management intentional decision. It was management designed for failure because management changed the goal to put money over life in distinct ways.

Re: Software Engineering Lessons from Aviation

#35

Not killing yourself and a checklist (like we learned in driver's ed but apply informally at best) also apply to driving a car.

Uh, no. In a car, if things go badly you pull off the road and work on a solution. If things to really badly, you have seatbelts, airbags, crumple zones, and a thick frame to help you out.

In an airplane, if things to badly, you keep flying until you land. If things go really badly, remember that everything is built to be light weight, and unless the crash is well controlled, everything will be destroyed and everyone will die. If your engine quits, your cabin ruptures, your instrumentation fails, you keep flying. And you need instruments; in poor visibility, your own sensory inputs are in fact faulty, and won't help you figure out which way is down.

Unlike in a car, where it's pretty obvious where the ground is, for example.

Re: Software Engineering Lessons from Aviation

#36
post #8

I think there's a lot to learn from the aviation industry. I did a talk at my companies internal conference on this (turned into words at https://medium.com/ingeniouslysimple/why-dont-planes-crash-1... ). For me it's the mindset that differs. Too often as software engineers we find a bug and just fix it. Aviation goes a step deeper and finds the environment that created the bug and stops that. Unfortunately, the rece…

>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, or less then minor system or environmental damage.

Now, face it, most webcrap and phone apps are at level IV. Few people in computing outside aerospace regularly work on Level I systems. (Except the self-driving car people, who are working at Level I and need to act like it.)

MCAS started as just an automatic trim system. Those have been around for decades, and they're usually level III systems. They usually have limited control authority, and they usually act rather slowly, on purpose. So auto trim systems don't have the heavy redundancy required of level I and II systems. Then the trim system got additional functionality, control authority, and speed to provide the MCAS capability. Now it could cause real trouble.

At that point, the auto trim system had become a level I system. A level I system requires redundancy in sensors, actuators, electronics, power, and data paths. Plus much more failure analysis. A full fly-by-wire system or a full authority engine control system will have all that.

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. Boeing did neither. Parts of the company seem to have thought the system didn't have as much authority as it did. ("Authority", in this context, means "how much can you change the setting".)

Management failure.

Re: Software Engineering Lessons from Aviation

#38

Earlier quoted context omitted.

Of course there is correctness for design! When reviewing a design, the first thing to verify is if it can satisfy its input requirements. In your example, a design that has to satisfy a safety requirement but doesn't is not correct and must be rejected.

The safety requirements are one of the design decisions that have to be made, not a separate thing that exists outside design space.

No!

Requirements are product features that must be present. A Design is one of many potential ways to satisfy that set of Requirements.

For example, a requirement might be "the user shall not be exposed to hazardous voltages (defined elsewhere) when servicing the equipment."

A possible Design solution might be "provide cover interlock switches so when the covers are opened, all voltage supplies are disconnected." or "software monitors a cover switch, and when that particular cover is opened, a command is sent to the power controller to disconnect power to anything that is reachable from that opening."

Which of the two (or other) design options is chosen, is a Design Decision, but they are means to an end, that end being Satisfying The Requirement.

Re: Software Engineering Lessons from Aviation

#39
post #10
post #4

Earlier quoted context omitted.

The blog post was good but it was just another variation highlighting the age old conundrum... fast, good and cheap, pick two. Those that value quality are going to be swimming up stream in most organization that develop software because the bean counters always go straight to fast and cheap.

I work in regulated industry and you really don’t want the level of scrutiny regulated processes have in other industries. Innovation would slow down to a crawl or pretty much stop. In a lot of industries you can make trade offs quality vs speed or innovation and be better off by not having perfect quality.

I strongly agree. However to my experience companies decide on quality vs speed based on other factors rather than business needs. For example, in my previous job, CTO called “ overengineering” whenever something went against his will, while “innovation/we are not a Corp” was his tail wind. So much office politics for such a small company :/

Re: Software Engineering Lessons from Aviation

#40

Earlier 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.

Well, nobody's perfect ;-)
Post reply on HN