safety critical
safety critical
Posted Jul 8, 2014 23:48 UTC (Tue) by marcH (subscriber, #57642)In reply to: The future of realtime Linux in doubt by SEJeff
Parent article: The future of realtime Linux in doubt
No offence but software for safety critical systems is developed on a completely different planet than Linux - and rightly so. It's not that much about hard versus soft real-time or open versus closed source... the differences that matter are here about formal development, review and verification processes. All very costly BTW. See for instance: http://en.wikipedia.org/wiki/DO-178C
I suspect Linux has simply grown too big to ever stand a chance to be retro-certified and used in that space. Use the right tool for the job!
Posted Jul 13, 2014 14:18 UTC (Sun)
by PaulMcKenney (✭ supporter ✭, #9624)
[Link] (16 responses)
That said, formal proof is but one road to safety-critical certifications. For some applications in some jurisdictions, practical demonstration is permitted. For example, if a given system does the right thing for five years, then it will be considered to be suitable for that particular safety-critical application.
Of course, given that each application needs to a separate long-term safety test, and that any failure means that you start over, the practical-demonstration approach could take even more time and be even more costly than formal proof. The advantage that the practical-demonstration approach has is that the formal-proof approach simply cannot handle anything but the smallest of systems. And rumor has it that Linux actually is used today in some carefully chosen safety-critical applications.
Nicholas McGuire has done some excellent work in this area: http://www.slideshare.net/DTQ4/gnu-linux-for-safety-relat...
Posted Jul 15, 2014 22:29 UTC (Tue)
by marcH (subscriber, #57642)
[Link] (15 responses)
Like you mentioned, Linux has grown too big and general purpose to qualify. I think it's OK; it's good at pretty much everything else.
"Practical demonstration" should definitely be a requirement for safety-critical certifications - but not just! Far from it. I mean, testing should never be an excuse not to use other, common quality processes, especially not for safety-critical code.
> And rumor has it that Linux actually is used today in some carefully chosen safety-critical applications.
Meanwhile, people are kept in fear of terrorists...
Posted Jul 16, 2014 19:06 UTC (Wed)
by PaulMcKenney (✭ supporter ✭, #9624)
[Link] (14 responses)
Posted Jul 16, 2014 21:06 UTC (Wed)
by marcH (subscriber, #57642)
[Link] (13 responses)
Of course I have, who would not? Which software engineer with more than a tiny bit of experience would believe something as lame as "it worked for five years, so it will work forever even in new situations; no need to look at how it works". Would you? This type of subpar software QA is not even considered acceptable by regular, non-critical software!
What next? "It compiles without any warning, so it's good for production"?
> I suggest you take that up with the authorities in the jurisdictions where this is the case.
Names? Interesting to know in which places lives are put at risk.
Posted Jul 17, 2014 14:24 UTC (Thu)
by mathstuf (subscriber, #69389)
[Link] (2 responses)
Posted Jul 18, 2014 4:05 UTC (Fri)
by ssokolow (guest, #94568)
[Link] (1 responses)
Posted Jul 18, 2014 10:42 UTC (Fri)
by marcH (subscriber, #57642)
[Link]
Posted Jul 17, 2014 14:35 UTC (Thu)
by raven667 (subscriber, #5198)
[Link] (8 responses)
That's probably a bit hyperbolic, I mean clearly you can look outside and see that it is not the apocalypse yet.
Posted Jul 17, 2014 21:07 UTC (Thu)
by marcH (subscriber, #57642)
[Link] (7 responses)
> 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
Posted Jul 18, 2014 12:34 UTC (Fri)
by PaulMcKenney (✭ supporter ✭, #9624)
[Link]
As to places in which lives are put at risk, that would be pretty much anywhere that grants drivers licenses, and especially those that grant drivers licenses to teenagers on the one hand and to the elderly and infirm on the other, now wouldn't it? ;-)
safety critical
safety critical
safety critical
safety critical
safety critical
Linux. Debian 6, specifically.
safety critical
safety critical
safety critical
safety critical
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."
safety critical