3 ms·

Certification already exists - called Functional Safety Engineer, issued by people like Exida and TUV. I hold this Certification. It is painfully slow to use p

Certification already exists - called Functional Safety Engineer, issued by people like Exida and TUV. I hold this Certification. It is painfully slow to use performance based standards to extract users risks and needs and then produce software designed and tested to standards like IEC 61511 and IEC 61508. They are basically Q/A standards, encourage use of the V-model, defined life cycle activities etc etc in an attempt to produce critical software to an estimated known quality. When you do the calcs the equipment is usually the easier part, it is almost always the humans that end up causing the problems. It is amazing how creative they can be to do a task, or to not do a task.

BeetleB 7y ago
Kind of sad that out of 83 comments, only 1 mentions "functional safety". If you want to write SW for, say, cars, ISO safety standards exist, and you generally get your work and development audited by a 3rd party agency who will confirm whether you've conformed to the safety standards. Conforming to those standards is not fun. And obviously, conforming to them doesn't mean your SW is actually "safe". If most engineers, managers, and auditors follow the spirit of the standards, it probably is safe. You really don't want such rigorous standards for your average SW product.
- airbreather 7y ago
  Yeah ISO 26262 is a derived standard from the parent 61508, as is 61511 for process sector. It is all about risk management, probabilistic outcomes and not spending all your money on a highly visible/emotive risk and ignoring an equivalent risk that is pervasive but lower consequences. A day to day example of how humans can be poor at intuitively allocating risk and avoidance is the immense fear some people have of the shark attack or plane crash, when they are statistically at way more risk driving to the beach or the airport, but think nothing of it. (Cars can be mighty convenient though). In my case risk decisions are usually driven by the company risk matrix as to tolerable risk, the companies way of conveying the enterprise wide appetite for risk. The risk matrix is also known as "the death quota" because it actually says how much is the maximum they are prepared to spend to avoid a fatality, or multiple fatalities, but you are never popular with the client when you frame their risk aversion guidance in that manner, not at all. Usual guidance is that the company wants no real increase of risk of harm to employees as they experience in general public day to day life, around 1x10-5 chance of death per year in western countries. Not thinking this sort of risk is part of the day to day thinking of most SV software engineers, because the consequences of your Uber going to the right street in the wrong suburb are undoubtedly significant to someone at the time, hardly likely to be life ending.

BeetleB 7y ago

Kind of sad that out of 83 comments, only 1 mentions "functional safety". If you want to write SW for, say, cars, ISO safety standards exist, and you generally get your work and development audited by a 3rd party agency who will confirm whether you've conformed to the safety standards. Conforming to those standards is not fun. And obviously, conforming to them doesn't mean your SW is actually "safe". If most engineers, managers, and auditors follow the spirit of the standards, it probably is safe. You really don't want such rigorous standards for your average SW product.

airbreather 7y ago
Yeah ISO 26262 is a derived standard from the parent 61508, as is 61511 for process sector. It is all about risk management, probabilistic outcomes and not spending all your money on a highly visible/emotive risk and ignoring an equivalent risk that is pervasive but lower consequences. A day to day example of how humans can be poor at intuitively allocating risk and avoidance is the immense fear some people have of the shark attack or plane crash, when they are statistically at way more risk driving to the beach or the airport, but think nothing of it. (Cars can be mighty convenient though). In my case risk decisions are usually driven by the company risk matrix as to tolerable risk, the companies way of conveying the enterprise wide appetite for risk. The risk matrix is also known as "the death quota" because it actually says how much is the maximum they are prepared to spend to avoid a fatality, or multiple fatalities, but you are never popular with the client when you frame their risk aversion guidance in that manner, not at all. Usual guidance is that the company wants no real increase of risk of harm to employees as they experience in general public day to day life, around 1x10-5 chance of death per year in western countries. Not thinking this sort of risk is part of the day to day thinking of most SV software engineers, because the consequences of your Uber going to the right street in the wrong suburb are undoubtedly significant to someone at the time, hardly likely to be life ending.