Boeing problems...

[itsmydamnation]

Please don't hold back. Give us your thoughts too!

So the easiest thing to say is in Aviation Safety everything is signed off, Every Signature is accepting liability both civil and criminal*. Are you willing to put your signature on an AI interfering with the flight controls of an aircraft?

* its not as bad as it sounds once you understand how systems engineering processes , safety and V&V work together.

 

[pmv]

So, it's better to have unhinged pilots crashing planes than software that's designed and tested to be fail safe, but could conceivably fail?

I dunno, though, that sounds disconcertingly close to what happened with the MCAS fiasco, no?

 

[igor_kavinski]

They used to have an engineer on every flight. Then they decided to save money by automating the systems. So yeah.

 

[Paratus]

So, it's better to have unhinged pilots crashing planes than software that's designed and tested to be fail safe, but could conceivably fail?

I personally wrote a lot of code for a mission critical application for the company of my employ over 2+ years. I alone wrote the code changes, surveyed and tested each release and there were many. IIRC, I never had an embarrassing or serious failure that I couldn't remedy easily and quickly. In fact, I don't remember failures at all. You don't release code that can fail, was my mantra. You test it to your satisfaction. When hundreds of lives and many millions of dollars and a major corporation's reputation are at stake, you are that much more careful and testing methodologies take center stage.

One. My issue is with the suggestion to use “AI”. Which is basically black box software in what amounts to a catastrophic hazard control. The level of software verification you’d need to do to verify it’s not going to make things worse would be extraordinary. This a generic problem with all non-deterministic software controlling hazards.

Two. We haven’t seen 787’s falling out of the sky due to whatever this is. Whatever comes out of this failure investigation, the fix should not make things worse.

Fuel cutoffs activated during takeoff is bad except when it isn’t. Someone with pilot experience could confirm but based on their central location, easily accessible by either pilot I’m sure they are part of fire response. Do you want the “AI” saying “I’m
Sorry Dave I can’t do that” when the pilot is trying to cutoff fuel to an engine that’s on fire?

Three I’m not saying a software interlock is a necessarily a bad idea if the software is deterministic and can be verified.

It’s great you write good code. In my experience almost no company does. I’ve seen several dumb software bugs that slipped through testing and could have had catastrophic consequences.

That’s why I want to see a robust software validation and verification program and an Independent Verification and a Validation software program to make sure any code changes are bullet proof.

 

[sdifox]

One. My issue is with the suggestion to use “AI”. Which is basically black box software in what amounts to a catastrophic hazard control. The level of software verification you’d need to do to verify it’s not going to make things worse would be extraordinary. This a generic problem with all non-deterministic software controlling hazards.

Two. We haven’t seen 787’s falling out of the sky due to whatever this is. Whatever comes out of this failure investigation, the fix should not make things worse.

Fuel cutoffs activated during takeoff is bad except when it isn’t. Someone with pilot experience could confirm but based on their central location, easily accessible by either pilot I’m sure they are part of fire response. Do you want the “AI” saying “I’m
Sorry Dave I can’t do that” when the pilot is trying to cutoff fuel to an engine that’s on fire?

Three I’m not saying a software interlock is a necessarily a bad idea if the software is deterministic and can be verified.

It’s great you write good code. In my experience almost no company does. I’ve seen several dumb software bugs that slipped through testing and could have had catastrophic consequences.

That’s why I want to see a robust software validation and verification program and an Independent Verification and a Validation software program to make sure any code changes are bullet proof.

Igor travels by camel. He doesn't understand planes.

 

[Paratus]

Igor travels by camel. He doesn't understand planes.

Igor? Little confused. I was replying to Muse.

 

[sdifox]

Igor? Little confused. I was replying to Muse.

I was the one confused. I read your response and Igor has the preceding post xd.

 

[[DHT]Osiris]

Igor travels by camel. He doesn't understand planes.

I don't blame him, I'd rather travel by camel right now too.

 

[Muse]

I dunno, though, that sounds disconcertingly close to what happened with the MCAS fiasco, no?

My imagining of AI usage in this thread was quite narrow and only concerns thwarting pilot initiated fuel shut off to both engines when the plane could not fail to crash if fuel is shut off to both engines, i.e. at quite low altitude and velocity. MCAS is entirely different.

 

[hal2kilo]

One. My issue is with the suggestion to use “AI”. Which is basically black box software in what amounts to a catastrophic hazard control. The level of software verification you’d need to do to verify it’s not going to make things worse would be extraordinary. This a generic problem with all non-deterministic software controlling hazards.

Two. We haven’t seen 787’s falling out of the sky due to whatever this is. Whatever comes out of this failure investigation, the fix should not make things worse.

Fuel cutoffs activated during takeoff is bad except when it isn’t. Someone with pilot experience could confirm but based on their central location, easily accessible by either pilot I’m sure they are part of fire response. Do you want the “AI” saying “I’m
Sorry Dave I can’t do that” when the pilot is trying to cutoff fuel to an engine that’s on fire?

Three I’m not saying a software interlock is a necessarily a bad idea if the software is deterministic and can be verified.

It’s great you write good code. In my experience almost no company does. I’ve seen several dumb software bugs that slipped through testing and could have had catastrophic consequences.

That’s why I want to see a robust software validation and verification program and an Independent Verification and a Validation software program to make sure any code changes are bullet proof.

In my experience in the process of fixing a software problem, another problem is created sometimes. Validation and extensive testing of new versions is always required.
The last system generation change I was involved with, had new requirements by the government to send our processors to some outfit that spent a lot of time looking for embedded spyware/malware. It took forever to get out gear back to meet our schedule.