Hacker News Reader

Comment by raxxorrax | Hacker News Reader

Anyone working in engineering knows that any form of resistance would have been futile. I bet the engineers of MCAS didn't even have a view on the overall system and their solution probably fits the risk- and requirements analysis. You should be able check that, that is why we focus on documentation in security relevant branches.

Responsibility is for the stupid, certainly not for management.

View on HN

>> Anyone working in engineering knows that any form of resistance would have been futile.

That's a management failure right there. But fine, if managers want to take a "shut up and do as I say" attitude, then they need to be responsible for the results of what they said to do.

Also, the thing they were least transparent about was probably hiding the differences between the Max and the regular 737. They hid those differences so that they could be certified as the same type and not require additional pilot training. That's not a lack of transparency, it's deception.

> then they need to be responsible for the results of what they said to do.

"You clearly misunderstood what I said. I never said to design MCAS. I wanted you to build MCAAS. The extra A implies the redundancy the system requires. Sheeesh." Phew, now I'm no longer responsible for this mess.

That's not true. In industries like medical and aerospace engineers have more power than they think. I've been there and done that. Safety is relevant still so you can't throw you hands up and do nothing. They don't have the same mentality as FANG companies, safety, redundancy, and being vigilant is part of the job. However, things will happen if everyone isn't vigilent. There are lots of companies out there doing it the right way, don't throw them all under the bus with Boeing.

Not intending to throw Boeing under the bus at all and I do think engineers take security seriously.

But generally there is a R&D lead that makes the decision to implement it. There may be responsibility there, but the decision to design the plane this way was an economic one.

Some reported internal pressure to develop quickly. By now, that is probably standard in the industry where any software is involved. So apart from an engineering position that could nearly crash or delay such a project...

If the system reactivated wrongly, it is certainly a bug and I think they have already fixed that problem. But an error that is hard to identify and the system was basically just designed to conform to regulations defining flight characteristics to evade renewed certification and training.

Of course there are still valid design criticisms possible if you take security real serious.

If there are "the engineers of MCAS", with a narrow mandate to build the MCAS, there must also be other engineers who don't delve into MCAS details but understand the overall system and therefore understand that the MCAS is dangerous. If not, how was that thing allowed to fly?

There are. It's an entire engineering discipline and a required one on aviation/military projects: https://en.wikipedia.org/wiki/Systems_engineering

There absolutely would have been systems engineers in charge of the various budgets and margins baked into the design. Safety is always a top one in aviation. In fact, Id be surprised to find there wasn't a team of systems safety engineering on the max. We need to see their analysis to understand whether this was a fault of engineering or management. If the engineers had done a thorough systems safety analysis and quantified the risk, then the responsibility definitely does not fall on engineering.

Competent systems engineers are in charge of high level decisions in theory. In practice, they might be less in charge than they should be (so that, more or less criminally, managers prioritize business objectives over safety and quality) or less able to do their job and less competent than they should be (probably because better processes and higher standards would mean spending money to cause "problems").

It's never any engineer's job to make decisions/define constraints. That's on the business side whether it be management, marketing, analytics teams, etc... I seriously doubt any engineer decided this. The decision to go with a single non-redundant system and use software to improve safety margins seems like a cost cutting measure which definitely seems more like something that would have been mandated as one of the design goals. Maybe engineering presented various options or something like that, but I find it very hard to believe the risk decision laid anywhere else other than very senior management.

> I bet the engineers of MCAS didn't even have a view on the overall system

By system so your mean the MCAS, the airplane, it Boeing. I don't think you're correct if your mean the MCAS or how it integrated with the airplane. You don't think they had any sort of integration tests established? Also, one one the failings was that the system only relied on input from a single sensor, so that failing should have been extremely obvious.

Unless by system you mean Boeing as a whole. I'm sure that as a part of the requirements process they were told that the system can be deactivated (which it could be), and I'm sure they were probably unaware that pilots were not being trained in disabling the MCAS. That makes those technical failures still obvious, but nonetheless understandable and maybe even acceptable in that context.

No, with system I meant the aircraft as a whole.

I meant to say that few things are that obvious if they aren't specified. There should be a point in the risk analysis that handles sensory errors, possible consequences and risk mitigation and if it wasn't specified there, it would have been an error. Go up the chain from there.

I doubt that software engineers necessarily know much about the reliability of sensors. You mostly learn that from experience. That is why you should include as much experience in the analysis process as possible. A pilot or the air techs would probably have mentioned the tendency of sensors freezing or having some form of malfunction.

Only then can the softies develop a fault tolerant system. After a failure it is always obvious to everyone, but as you said, perhaps they just thought the pilots would notice the error and override the system. Also an obvious assumption that should be documented as mitigation to reduce risk.

No risk analysis is perfect, but after the accidents we can expect some diligence and discipline in my opinion and hopefully this accident leads to a review on these processes instead of finding some fall guys.

A thorough integration test would probably also have detected the issue at some point and maybe here are faults as well.

One of the main selling points of the plane was the lack of need to retrain pilots. So, Boeing was acutely aware of the lack of training regarding MCAS.

The need for training was there. The selling point was certification saying there was a lack of need. In part that's also a fault of each purchasing airline that didn't give extra training.

Regardless of whether Boeing were willing to certify the system as not being training, those responsible for pilot competence at the purchasing commands should still have ensured pilots were trained before using the system.

If a garage sells you a roadworthiness/MOT certificate when a vehicle isn't roadworthy, and you know it isn't, then we're both at fault.

Depends how the engineering teams are partitioned really. MCAS could be built as a closed system with a set of interface specs that the avionics teams would then have to integrate and test. That said, someone definitely should be doing integration tests.

Reply on news.ycombinator.com