How Is Critical Life or Death Software Tested? • Hacker News Board

Re: How Is Critical Life or Death Software Tested?

#41

Post by omouse » Mon, Jun 01, 2015, 9:27 PM UTC

outworlder wrote: post #15

acomjean wrote: post #8

I wrote software for Radars. Kind of important (not like plane software). We used Ada alot, which in my estimation helped. Software was reviewed. Tests were reviewed. Reliability was favored over other things (for example recursion was discouraged). We used Ada's constrained types (this value is between 1 and 99, if it goes out of range, throw an exception). For external hardware inputs, we had software simulating th…

> Actually testing was built into the software. When it came up it would talk to the physical parts to make sure everything was communicating ok before it could start running. I've been wondering about this for a while. We tend to run unit tests, integration tests, whatever tests, while the software is in development. However, once it is in "production" (for whatever definition of production), usually no tests are pe…

That would be called reliability testing and it's why Netflix has chaos monkey to throw a wrench into things.

Re: How Is Critical Life or Death Software Tested?

#42

Post by yellowapple » Mon, Jun 01, 2015, 9:28 PM UTC

z3t4 wrote: post #21

acomjean wrote: post #8

I wrote software for Radars. Kind of important (not like plane software). We used Ada alot, which in my estimation helped. Software was reviewed. Tests were reviewed. Reliability was favored over other things (for example recursion was discouraged). We used Ada's constrained types (this value is between 1 and 99, if it goes out of range, throw an exception). For external hardware inputs, we had software simulating th…

A lot of ppl get this backwards, that a stable program should never "crash". While it's actually the opposite, it should throw errors at every opportunity to do so. The errors should then be logged and the program should be restarted by a watcher process. Here's an example on how you can both log errors and e-mail them if a process crash, using a startup script (Linux, Ubuntu): exec sudo -u user /bin_location /progra…

This is how Erlang (for example) gets its reputation of being "nine-nines" capable (i.e. capable of 99.9999999% uptime, or downtime on the order of milliseconds per year). Erlang (and Elixir and LFE) software following the OTP framework is usually ordered into "supervision trees" - layer upon layer of Erlang processes managing other Erlang processes in turn managing other Erlang processes, all potentially distributed across multiple Erlang VM (nowadays BEAM) instances.

Re: How Is Critical Life or Death Software Tested?

#43

Post by manarth » Mon, Jun 01, 2015, 9:31 PM UTC

Aleman360 wrote: post #37

Worked on anesthesia machines for a few years. Since both hardware and software is involved, the testing was quite extensive. * Lots of manual testing. While we did unit testing and some automated integration testing, most defects were found using exhaustive manual testing by trained engineers. * Randomized UI testing. Used UI automation to exercise the UI with various physical configurations of the system. Would oft…

You just have to look at Therac 25 for the risks of relying on software interlocks alone. One of the prevailing pieces of feedback was the lack of hardware interlocks - whether that's possible on anesthesia machines I don't know…but the prevailing wisdom is to use/include hardware interlocks wherever that's feasible, for any critical life-supporting equipment.

Re: How Is Critical Life or Death Software Tested?

#44

Post by click170 » Mon, Jun 01, 2015, 9:32 PM UTC

Aleman360 wrote: post #37

Worked on anesthesia machines for a few years. Since both hardware and software is involved, the testing was quite extensive. * Lots of manual testing. While we did unit testing and some automated integration testing, most defects were found using exhaustive manual testing by trained engineers. * Randomized UI testing. Used UI automation to exercise the UI with various physical configurations of the system. Would oft…

How does an anesthesia machine fail safe?

What I mean is, does it continue applying anesthetic in the event of a power failure or does that stop entirely?

Re: How Is Critical Life or Death Software Tested?

#45

Post by Aleman360 » Mon, Jun 01, 2015, 9:33 PM UTC

manarth wrote: post #43

Aleman360 wrote: post #37

Worked on anesthesia machines for a few years. Since both hardware and software is involved, the testing was quite extensive. * Lots of manual testing. While we did unit testing and some automated integration testing, most defects were found using exhaustive manual testing by trained engineers. * Randomized UI testing. Used UI automation to exercise the UI with various physical configurations of the system. Would oft…

You just have to look at Therac 25 for the risks of relying on software interlocks alone. One of the prevailing pieces of feedback was the lack of hardware interlocks - whether that's possible on anesthesia machines I don't know…but the prevailing wisdom is to use/include hardware interlocks wherever that's feasible, for any critical life-supporting equipment.

Not sure what you mean by "interlocks", but the hardware was quite distributed. Each critical component had its own board and industrial microcontroller. And we had various levels of watchdogs keeping track of system health at all times.

Re: How Is Critical Life or Death Software Tested?

#46

Post by acomjean » Mon, Jun 01, 2015, 9:34 PM UTC

cesarbs wrote: post #17

> As for the code itself, its perfection came as the result of basically the opposite of every trope normally assigned to "coder." Creativity in the shuttle group was discouraged; shifts were nine-to-five; code hotshots and superstars were not tolerated; over half of the team consisted of women; debugging barely existed because mistakes were the rarest of occurrences. Programming was the product not of coders and eng…

Large corporations with government contracts have this kind of work. Probably financial institutions too.

The coding proces is slower than most people are used too and can become frustrating.

Re: How Is Critical Life or Death Software Tested?

#47

Post by Aleman360 » Mon, Jun 01, 2015, 9:35 PM UTC

click170 wrote: post #44

Aleman360 wrote: post #37

Worked on anesthesia machines for a few years. Since both hardware and software is involved, the testing was quite extensive. * Lots of manual testing. While we did unit testing and some automated integration testing, most defects were found using exhaustive manual testing by trained engineers. * Randomized UI testing. Used UI automation to exercise the UI with various physical configurations of the system. Would oft…

How does an anesthesia machine fail safe? What I mean is, does it continue applying anesthetic in the event of a power failure or does that stop entirely?

It can operate completely mechanically. There is an integrated UPS in case mains fails. If the battery also fails, a pneumatic whistle goes off to alert the user. If for some reason something goes really bad, they switch to using an ambu bag, typically hung on the back of the machine.

Re: How Is Critical Life or Death Software Tested?

#48

Post by DannoHung » Mon, Jun 01, 2015, 9:42 PM UTC

acomjean wrote: post #46

cesarbs wrote: post #17

> As for the code itself, its perfection came as the result of basically the opposite of every trope normally assigned to "coder." Creativity in the shuttle group was discouraged; shifts were nine-to-five; code hotshots and superstars were not tolerated; over half of the team consisted of women; debugging barely existed because mistakes were the rarest of occurrences. Programming was the product not of coders and eng…

Large corporations with government contracts have this kind of work. Probably financial institutions too. The coding proces is slower than most people are used too and can become frustrating.

Financial institutions do not necessarily do things this way. Some parts might, but I don't have any experience with them. The parts I do have experience with it is utterly a miracle that anything works.

Re: How Is Critical Life or Death Software Tested?

#49

Post by neurotech1 » Mon, Jun 01, 2015, 9:42 PM UTC

tormeh wrote: post #36

jokoon wrote: post #11

It's true that writing software requires only computers, and that's it would be too expensive to test it in real situations, when the stakes are high maybe it's also important to do live testing ?

Hardware in the loop (HIL) is a sort of middle ground, where all the expensive stuff that breaks are replaced by ordinary computers, but the actual control hardware is not. Corporate video by people who do this, explaining it: https://www.youtube.com/watch?t=116&v=YpxPAuHNpdM

The mission systems avionics on a F/A-18F costs around $1-2m per aircraft. This includes Displays, PowerPC based AMC boards, power supplies etc. Hardware in the Loop testing quite practical and was ran as an engineering flight simulator. Missions were flown in the simulator, and problems located without costing $20k/hr per aircraft for an actual flight test.

SpaceX do HIL tests with the Falcon 9 & Dragon spacecraft. http://www.spaceflightnow.com/falcon9/003/120424date/

Re: How Is Critical Life or Death Software Tested?

#50

Post by alkonaut » Mon, Jun 01, 2015, 9:42 PM UTC

I think in the "normal" software industry we have a skewed picture of quality, simply because it's not the primary focus. For everyday software, it's fine if it works to 95%. Even bugs you have identified must be weighed against new features, and features often win. For the customer it's better to have a piece of software that has all the features they need, but calculates a bad result every 1/1000 times, or crashes a couple of times per day, than a program that doesn't have all the features. It's also the "release early release often" thing where the cheapest testers are your end users. That is far from the "release once patch never" of rockets. So feature bloat and suffering quality isn't really due to bad practices, it's an active choice.