The Nightstar Zoo

Nightstar IRC Network - irc.nightstar.net
It is currently Wed Nov 22, 2017 4:48 pm

All times are UTC - 6 hours [ DST ]




Post new topic Reply to topic  [ 6 posts ] 
Author Message
 Post subject: Software bugs that kill.
PostPosted: Wed Dec 07, 2005 6:15 am 
Offline
Intern
Intern
User avatar

Joined: Sun May 12, 2002 12:18 am
Posts: 1134
Location: Idaho
Bugs and implementation problems in the Therac-25 software led to several severe injuries and deaths.

The older Therac-20 suffered from several of the same bugs, but it had fuses, circuit breakers and other hardware protections that prevented harm to patients. The Therac-25 relied soley on its software for safety.

Any other deadly bugs?

_________________
Fandemonium!
August 1st, 2nd, 3rd, 2014

"I am a machine. I am a weapon of war. I am a destroyer of life in the service of life, the sword and shield of my human creators." Bolo Invincibilus, Mark XXIII, Model B (Experimental) 0075-NKE "Nike".


Top
 Profile  
 
 Post subject:
PostPosted: Thu Dec 08, 2005 12:10 am 
Not really deadly, but IIRC, a software bug caused the first launch of the Ariane 5 rocket to blow up. Like the Therac, Ariane 5 used software from an older version (in this case, Ariane 4), however, Ariane 4 didn't ever fly fast enough to trigger the bug.

Edit[0]: Found a link: Clickity!

Edit[1]: Forgot to mention that Ariane 5 is an unmanned launcher. Otherwise the bug would have acutally been deadly.


Top
  
 
 Post subject:
PostPosted: Thu Dec 08, 2005 4:16 am 
Offline
Intern
Intern
User avatar

Joined: Sun May 12, 2002 12:18 am
Posts: 1134
Location: Idaho
It wasn't that the 5 was faster, the problem was the inertial alignment reference system was allowed to operate for 40 seconds after liftoff.

The same system was used in the 4 and 5. The failure was caused by the quicker rotation onto the orbital insertion trajectory used by the 5. At 37 seconds after liftoff, the horizontal velocity value generated by the inertial reference overflowed and caused it to spit gibberish into the inputs of the guidance computers. Since the IR wasn't being used, the engineers assumed they could safely ignore it, and leave out any error trapping on the IR's data output.

The backup computer crashed first, then the primary. When the failover system attempted to switch to the backup, it was already gone.

With garbage data running rampant through the system, the engine nozzle actuators tried to do a u-turn. ;)

Had the primary guidance crashed first, there might have been a slim chance the rocket could've kept control through 40 seconds, when the inertial reference would've shut down and stopped sending garbage data.

The rationale for leaving the inertial reference running past liftoff was so the controllers could disable its shutdown in the event of a late pause in the launch sequence. If allowed to shut down, the reference would take some time to re-align.

A better way to have designed the system would be to have the inertial reference shutdown event triggered (by actual liftoff) rather than time triggered x time from countdown start.

IIRC, that was the fix for later launches.

Even better would've been to leave the inertial reference out completely, since it wasn't actually being used in the 5! A dummy box that did nothing but output a constant "safe" value, ignored by the rest of the system, would've been cheaper and also solved the issue of "designing out" the IR interface.

Quite annoying to have an expensive rocket and payload destroyed merely because someone assumed an unused bit of equipment could be ignored completely, without making absolutely certain that it would not have any effect. ;)

If the Ariane 5 was a car, it'd have an extra gear in the transmission, which at certain speeds and angles of turning the front wheels, would engage and make the car do a u-turn. :)

_________________
Fandemonium!
August 1st, 2nd, 3rd, 2014

"I am a machine. I am a weapon of war. I am a destroyer of life in the service of life, the sword and shield of my human creators." Bolo Invincibilus, Mark XXIII, Model B (Experimental) 0075-NKE "Nike".


Top
 Profile  
 
 Post subject:
PostPosted: Thu Dec 08, 2005 7:14 pm 
Eh, turns too fast, flys too fast, same difference. :lol:

Although, I have found another incident of an acutally lethal software bug. Once again, it was a computer-controlled radiation machine overdosing patients.

The Cobalt-60 radiotherapy machine allows doctors to place shields over parts of the patient's body to prevent those parts from being exposed. The machine needs to know the exact position of these shields to calculate the correct dose. Unfortunately, it would only accept a maximum of four shields, and the doctors wanted to use five. They discovered that they could use five by "drawing" them into the computer as a single shield with a hole in the middle. However, depending on which direction the hole was drawn, this technique might trigger a bug that would overdose patients.

Of particular note, this incident occured in Panama, where the law requires the doctors to double-check the computer's numbers by hand. Since they failed to do this, they are now being charged with second-degree murder.

Linkage.


Top
  
 
 Post subject:
PostPosted: Fri Dec 09, 2005 1:06 pm 
Leaking natural gas pipelines can result in fairly impressive fuel-air bombs.


Top
  
 
 Post subject:
PostPosted: Fri Dec 30, 2005 5:28 pm 
Offline
Nightstar Graveyard Daemon
User avatar

Joined: Mon Jun 03, 2002 8:30 pm
Posts: 1071
Location: Wouldn't you rather observe my Velocity?
A company I worked for a decade ago made vibration controllers for shaker tables. The idea was you had this gimongous electromagnetic thruster (picture a speaker coil designed to vibrate a 50-ton vehicle up and down instead of vibrating air to produce audio) and you bolted something to it you wanted to vibrate. Our software would vibrate the object, and using accelerometers placed around the object, would vibrate that object at a fairly constant amount of G-force across the spectrum. Everything from portable electronics to automobiles are tested this way, to see if there are any design flaws that will cause it to resonate mechanically and fall apart. In the auto industry this is called "squeak & rattle" testing.

We got a bug report from Toyota one day that started off with, "Fortunately, nobody was killed...."

The bug was this: our software tracked the past second of acceleration data, divided into 256ths. Each 256th of a second was called a "bin". At the beginning of each bin, we check the previous 10 bins and average out the energy put into the object on the table. If it's shaking too hard, we dampen our bin. If it's not shaking hard enough, we put more power into it.

Someone at a Toyota plant somewhere had a Camry frame on the shaker table, a 5-ton shaker driven by a 25kVA power supply. They were demonstrating the unit for some executives touring the plant. Partway through the demonstration, they paused the test to talk about the system.

The averaging software had a bug: although the test stopped, the averager did not pause its averaging. It began averaging bin after bin of 0 energy input into the system. When the operator hit resume, it went

BANG

as it tried to correct 10 bins of 0 energy in 1 bin.

It bent the Camry's frame. I'm not sure what the underwear cleaning bill was.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 6 posts ] 

All times are UTC - 6 hours [ DST ]


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group