|
Thread: Comments for: "Software for dependable systems"
|
|
|
|
Replies:
4
-
Pages:
1
-
Last Post:
Nov 10, 2009 11:18 AM
Last Post By: Lundin
|
|
|
Posts:
102
Registered:
10/03/07
|
|
|
|
Comments for: "Software for dependable systems"
Posted:
Nov 2, 2009 12:53 PM
|
|
|
|
|
|
Posts:
102
Registered:
10/03/07
|
|
|
|
Re: Comments for: "Software for dependable systems"
Posted:
Nov 2, 2009 12:53 PM
in response to: krwada
|
|
|
99.9% ???? That is way to high a figure! According to the Boeing Corporation, There were approximately 18 million flights in the year 2000. Of these, only 20 resulted in fatal accidents. Of the 20, I am most certain only a very few were due to controller failure.
Therefore, I would think something on the order of parts-per-million or parts-per-billions is a better metric. It is way way better to have folks not ever know what we do than otherwise ... in general, any publicity, in the general media, about embedded controllers is because of a failure.
You can see the statistics ... provided by Boeing ... here
... or course The Boeing company will have a particular bias on the safety of flying. |
|
|
Posts:
10
Registered:
05/01/08
|
|
|
|
Re: Comments for: "Software for dependable systems"
Posted:
Nov 5, 2009 2:08 PM
in response to: krwada
|
|
|
krwada,
You're talking about the number of times a particular product (aircraft) has been used (flights). The 99.9% in the article is referring to the code in a given item (a particular model of aircraft, etc.). These numbers may be worlds apart (apples and oranges).  |
|
|
Posts:
19
Registered:
11/20/07
|
|
|
|
Re: Comments for: "Software for dependable systems"
Posted:
Nov 5, 2009 6:10 PM
in response to: krwada
|
|
|
|
To set the record straight on DO-178B:
Aviation incidents caused by software systems are thankfully rare, even given the exponential growth of software density in aircraft systems – perhaps this is a consequence of prescriptive standards (guidelines) such as DO-178B, and their enforcement by certification authorities (e.g. FAA Designated Engineering Representatives). A major criticism here of the book ‘Software for Dependable Systems’ is it is not prescriptive enough!
DO-178B is far from perfect, but it has known strengths, such as its bias toward Requirements and their satisfaction. The guideline contains more than 60 objectives. Many people concentrate on a select number of Code based objectives (e.g. MC/DC coverage) – but this is a gross misinterpretation and misrepresentation of DO-178B.
DO-178B is limited in scope, and it fails to address the holistic System aspects of safety. Still, this article falls into a similar trap, with too much emphasis latterly on coding languages (e.g. Ada and SPARK). Note: systems containing perfectly functioning Code have contributed to fatal accidents (e.g. Cali, Colombia).
In terms of safety, gazing at the Code is analogous to organizing the deckchairs on the Titanic as you steam toward the ‘Requirements Iceberg’ – at least it keeps you occupied.
The most pertinent statement in the article is, “Finally, expertise is demanded.” Competence and professionalism should not be implicit or assumed when the systems are high-dependability. Interestingly, standard IEC 61508 provides guidance on competence assessment.
For interested readers, there is a DO-178B group on LinkedIn
|
|
|
Posts:
13
Registered:
03/03/09
|
|
|
|
Re: Comments for: "Software for dependable systems"
Posted:
Nov 10, 2009 11:18 AM
in response to: krwada
|
|
|
|
Halfways through this book, I don't find it particulary thought-provoking or revolutionary. If you are like me, namely a software engineer with a bit of experience in designing safety-critical systems, you will find a lot of preaching to the choir. At least the book satisfies my ego...
The things preached such as modular design to avoid "tight coupling", simplicity etc are taught for any decent computer engineering degree, even if you don't specialize in safety-critical systems. That most of the accidents happen because of poor specifications is well-known as well. Or so I thought...
I like that they emphasis to regard the user of the software as a system component, there are plenty of standard bureaucrats preaching the opposite: ie if you leave supervising of the system to a human, it ain't your problem any longer.
As comment to this article, note that the book explicitly advises against C as whole, but it also explicitly recommends the subset MISRA-C. So if you have a C application, there is no need to rush off and learn SPARK. Instead, introduce MISRA-C, if you aren't already following it. It is very much possible to test MISRA-C with a static analyzer: in fact MISRA-C enforces the use of a static analyzer.
---
While I have never worked with DO-178B and can't comment it, I am very sceptical against vauge "functional saftety" standards such as IEC 61508. I have seen several cases where a manufacturer claim SIL 3 level of their system, with notified body approval and everything. And then we tried to short-circuit one of the emergency stop relays, and the whole emergency stop function was disabled. Apparently this utterly fundamental error was unnoticed by the "SIL 3" system itself, the pile of papers produced by 61508, and by the notified body.
The spectacular is that I've seen the same on two different SIL 3 systems by different manufacturers, certified by two different notified bodies. One notified body was a particulary famous 3-letter german test house, so I don't think less serious test houses is the cause. Apparently there was no real evidence as preached by the book, but only false evidence in the form of the pile with irrelevant papers required by 61508.
But at least 61508 keeps a lot of standard-writers, bureaucrats and "non-technical engineers" busy, while steaming towards the very same iceberg that was already mentioned.
|
|
|
|
|
|
|
