HAL in the navy

[time]

http://www.news.com.au/story/0,10117,12204297-26618,00.html

Wonder if they run Windows?

 

[ddrueding]

Good to know humans can still make errors :roll:

I'd blame this squarely on the captain. The computer did nothing until the captain attemped an impossible manuver (running 2 props in 2 directions with 1 engine).

 

[Bung]

Last year there was some fuss about the British navy basing a new destroyer control system on Windows.

 

[Jake the Dog]

Good to know humans can still make errors :roll:

I'd blame this squarely on the captain. The computer did nothing until the captain attemped an impossible manuver (running 2 props in 2 directions with 1 engine).

the failure here came way before the captain's incompetance forced it to appear.

fail-safe computer operation under any circumstance should been a critical and mandatory requirement met before that boat was out to sea. I'd say more likely the blame should be placed on the selection committee for not ensuring the software developers had covered all such conceivable scenarios in their design and testing.

 

[sechs]

Reminds me of the problems that Airbus had in implementing fly-by-wire. Sometimes the computer would disagree with the pilot....

 

[LiamC]

As Jake and Sechs have alluded to, if people provide "fail-safes" to override the captain or pilot, all that's going to happen is that TV shows like Black Box or Air Crash Investigation are going to show episodes where the conclusion is software error rather than pilot error.

I write software for a living, lately java. The evangelists in the org I currently work for are big on junit testing--you write test cases for each class and method you write. The trouble I see with this is that I can write simple test cases for each piece of code, but it isn't the simple (blindingly obvious) that bugs my code. It's the weird corner cases where module A talks to module B via Module C and interacts with another application (Z) entirely which validates when where and what data I can get from application Y which allows my program to talk to module D, except when the planets are in alighment, and somebody forgot to fill out their birth date correctly with four digit years in application X. Then the whole lot crashes. It's when the unexpected happens. A good pilot may recover. An average pilot probably won't. Software can't think, so it will be no better than an average pilot.

There was a particularly useful air-crash show I saw a few months back about a Peruvian (Chilean??) aircraft that crashed. 'Twas a foggy night, and the aircraft had just taken off. The pilot started to receive an overspeed warning. So he slowed the plane (and started to descend). Then he received a stall warning! He tried to get confirmation from ATC. On top of that, he then got a ground proximity warning! So he was flying too fast, too slow and too close to the ground. Crash, bang 70 dead. The cause. Some ground crew had taped over a (pitot?) tube when washing the plane, and forgotten to take the tape off. Three people (including the Captain) missed it. How would software react in such conflicting circumstances?

 

[ddrueding]

Three people (including the Captain) missed it. How would software react in such conflicting circumstances?

Expecting it to is too much. This too was blatant human error. Expecting a computer to protect against even smaller degrees of human error is too much. In this case, what if there wasn't a computer running this sensor, what if it was a human? They'd still recieve conflicting information from the faulted sensor and the plane would have still crashed if the Pilot had again failed to identify the error in the few seconds he had.

 

[time]

The evangelists in the org I currently work for are big on junit testing--you write test cases for each class and method you write. The trouble I see with this is that I can write simple test cases for each piece of code, but it isn't the simple (blindingly obvious) that bugs my code. It's the weird corner cases where module A talks to module B via Module C and interacts with another application (Z) entirely which validates when where and what data I can get from application Y which allows my program to talk to module D, except when the planets are in alighment, and somebody forgot to fill out their birth date correctly with four digit years in application X. Then the whole lot crashes. It's when the unexpected happens.

Yeah, it's like checking every nail when building a house and calling that quality. The fact that structural supports may be missing, the roof leaks or the electrician wired the mains to the plumbing, is neither here nor there. Welcome to the world of "software engineering".

I'll never get over the fact that lots of these places claim they produce "zero defect software". :rofl: I bet UML gets quite a workout in your workplace, Bill.

I actually believe that current OOP has become an obsession that excludes development of methodologies better able to simulate reality and the interaction of real objects. I think I'm going to insert an object into the next ivory tower dweller that pretends the real world can be reduced to inheritance-based classes. :evil:

I agree with the point you were trying to make about pilots. Computers don't think, they just follow instructions. Whereas a human can rely on life experience to identify the incongruity of the plane being both too fast and too slow, this exact situation has to be anticipated by a software developer and successfully coded, for a computer to even understand that a paradox exists.

 

[iGary]

Good to know humans can still make errors... I'd blame this squarely on the captain...

Being that the ship was the HMAS Ballarat, the captain was likely an escaped simian.