safety critical
safety critical
Posted Jul 17, 2014 21:07 UTC (Thu) by marcH (subscriber, #57642)In reply to: safety critical by raven667
Parent article: The future of realtime Linux in doubt
> That's probably a bit hyperbolic,
A "risk" is anything with a non-zero probability; leaves plenty of room. It's all in the details.
Posted Jul 17, 2014 21:25 UTC (Thu)
by raven667 (subscriber, #5198)
[Link] (6 responses)
Non-zero doesn't mean significant, there is always risk, managing it is about assessing significance and making subjective value judgements.
8-)
Posted Jul 18, 2014 11:01 UTC (Fri)
by marcH (subscriber, #57642)
[Link] (5 responses)
By the way, when talking about safety security is never far away, example:
http://arstechnica.com/security/2013/07/disabling-a-cars-...
Approving a system after ONLY a successful, five years long demo is giving even less confidence about security than about safety. Most other QA tools and processes tackle both at the same time. If you don't use all known working QA options when working on a safety critical system, then you are not really considering it as safety critical. By the way: the MP3 player in the car is probably not safety critical. Unless it can hack into brakes or steering. Modularity and "less is more"; here we go again.
Note about the car example: unlike carnivore butterflies, cars have already killed and will continue to kill millions of people. But again the key question is: for any given specific crash, who can you blame and who can you sue?
Posted Jul 18, 2014 12:41 UTC (Fri)
by PaulMcKenney (✭ supporter ✭, #9624)
[Link] (4 responses)
Posted Jul 18, 2014 14:23 UTC (Fri)
by marcH (subscriber, #57642)
[Link] (3 responses)
Posted Jul 26, 2014 22:01 UTC (Sat)
by PaulMcKenney (✭ supporter ✭, #9624)
[Link] (2 responses)
If the plaintiff's attorney is better than the defense's attorney, the jury will believe that what was required was whatever you did, plus a lot more. There are always more tests that could have been run, and there are always more types of formal validation that you could have brought to bear. Even if you somehow managed to run all conceivable tests and carried out all conceivable formal validation techniques, more will have been conceived of after the fact.
Of course, this would mean that the only safe way to produce a safety-critical widget would be to invest an infinite amount of time and money into it, that is to say, to not produce it at all. And in some cases, the lack of that safety-critical widget will be costing lives, which clearly indicates a need for a balanced approach to this issue.
And this in turn is one reason that there are laws, rules, and regulations that specify what is required for various safety-critical classifications. And for some of those classifications, the powers that be have determined that a long testing period suffices. Other classifications also require formal validation. Which is in fact a reasonably balanced approach to this issue.
Posted Jul 27, 2014 9:53 UTC (Sun)
by marcH (subscriber, #57642)
[Link] (1 responses)
What I really meant (and was too lazy to write) is: the quality bar for safety-critical applications should at the very least be one big step up from non safety-critical applications. This means using at the very least all the QA tools and methods which are well-known and *routine* - and a bit more. I think no jury would like to hear that some basic code review process or some common and off the shelf static analyser was ignored. This obviously includes testing as well.
By the way: I would be surprised to hear about some place that does not bother mentioning anything beyond testing to qualify safety critical applications, taking all the rest for granted. Now I would be even more surprised to hear about a place that explicitly states that using other, common QA processes is NOT required!
> And in some cases, the lack of that safety-critical widget will be costing lives,
I'm not sure about this one: there is often the option of doing something simpler without using (too) complex software. Or worst case, not do something at all and wait until it can be done safely (and keep prototyping).
I was just reading http://www.dwheeler.com/essays/heartbleed.html again. Security and safety are close in the sense that the most Software Quality processes can be used for both. Quote from David:
Complexity is exactly why general purpose operating systems cannot DRIVE planes and trains. Cars are probably OK: it's much easier to lie and pretend the driver made a mistake ;-)
> what is required for various safety-critical classifications. And for some of those classifications, the powers that be have determined that a long testing period suffices. Other classifications also require formal validation.
I think this sentence shows that some overdue clarification of the meaning of safety-"critical" is needed. For instance I would not have called "safety-critical" a device that merely monitors and alerts. Because in not all but many situations its failure would not have any effect.
For instance Do-178B seems to use "critical" only for the highest level; even more limited meaning than I thought
http://en.wikipedia.org/wiki/DO-178B
safety critical
safety critical
safety critical
safety critical
safety critical
safety critical
"code should be refactored over time to make it simple and clear, not just constantly add new features. [...] The goal should be code that is obviously right, as opposed to code that is so complicated that I can’t see any problems."