name of "law" general engineering priciple "single failure shouldn't be fatal"? - Page 1
Forum section: electronics / general

author: incf
author_rank: Frequent Contributor
timestamp: April 05, 2025, 09:02:00 pm
content: In certain engineering disciplines it is common to design systems, processes, and procedures so that the occurrence of a single failure does not result in catastrophic/fatal consequences.Does this principle/"law" have a name?An example of a similar but distinct "law" is Murphy's Law.Also would be interested in any lists that may exist of engineering related "laws" and truisms.

author: tom66
author_rank: Super Contributor
timestamp: April 05, 2025, 09:04:06 pm
content: Fault tolerance.

author: Sensorcat
author_rank: Regular Contributor
timestamp: April 05, 2025, 09:59:14 pm
content: A system that has this property is called fail-safe.

author: Analog Kid
author_rank: Super Contributor
timestamp: April 05, 2025, 10:03:03 pm
content: Redundant backup systems?

author: Bud
author_rank: Super Contributor
timestamp: April 05, 2025, 10:05:02 pm
content: Quote from: incf on April 05, 2025, 09:02:00 pm"If it is not broken, do not touch it" 😊

author: tom66
author_rank: Super Contributor
timestamp: April 05, 2025, 10:13:04 pm
content: Quote from: incf on April 05, 2025, 09:02:00 pmIf it's made by Boeing, I ain't going.

author: Nominal Animal
author_rank: Super Contributor
timestamp: April 05, 2025, 10:35:10 pm
content: Quote from: incf on April 05, 2025, 09:02:00 pmThe weakness is calledsingle point of failure, SPOF, or single-point failure.Quote from: incf on April 05, 2025, 09:02:00 pmNot a simple name, no; "fault tolerance" is the closest one I can think of personally.Avoidance of SPOF is crucial in redundant, high-availability, and high-reliability systems.

author: Gregg
author_rank: Super Contributor
timestamp: April 05, 2025, 11:42:13 pm
content: "The Stockton Rush Ego law"?

author: SteveThackery
author_rank: Super Contributor
timestamp: April 06, 2025, 10:43:39 am
content: Quote from: Sensorcat on April 05, 2025, 09:59:14 pmActually, back when I was a Reliability Engineer, "fail-safe" was a different thing. It meant the system would fail in a safe condition. Note that it would still fail. Nuclear reactors have lots of fail-safe systems, such as dropping the graphite rods under gravity if the control systems crash.

author: SteveThackery
author_rank: Super Contributor
timestamp: April 06, 2025, 10:45:14 am
content: To follow up: systems that would keep working under fault conditions were called "resilient" or "fault tolerant".Therefore the term the OP is looking for is probably "fault tolerance" or "resilience". The latter term was more widely used when I was doing the job.There was also the term "diversity", back when the modern meaning wasn't widely used. Diversity was the principle of avoiding common-mode failures by using two different technologies, or different products. For example, an optical fibre data link where resilience was required might use a point-to-point microwave radio link as it's standby system. The link is far less likely to be brought down by a digger than if the standby system comprised a second optical fibre cable. Running the standby fibre via a physically different route avoids some of the risk, and this is called "diverse" routing.Similarly, a computerised control system in a safety-critical role might be duplicated (or even triplicated), but the software running on the two systems - whilst functionally identical - is written by two completely different teams. Thus the probability of the same - critical - bug occuring in both is extremely small.

author: SteveThackery
author_rank: Super Contributor
timestamp: April 06, 2025, 11:14:03 am
content: There are plenty of examples of where resilience fails. For example we had a rack-based system with two PSUs. The PSUs were mounted on different shelves - a small but simple contribution to diversity. Either PSU was capable of running the whole system, and they were both powered up and running all the time, so they were load-sharing. If one failed, the other would simply take up the full load and continue to supply power to the system, which therefore continues to work without interruption.It all went wrong when the PSU on the lower shelf caught fire. The other PSU was on the next shelf up, but unfortunately it was directly above the failed PSU. It supported the system for a few minutes, as designed, but eventually the burning PSU destroyed its partner directly above it and the system came down. A case of insufficient diversity. The second PSU should have been higher up and in a different shelf position. Lessons learned.

author: SteveThackery
author_rank: Super Contributor
timestamp: April 06, 2025, 11:30:37 am
content: Threat assessment is very important when designing a resilient system.When I worked at BT we had a customer who was insistent on having diverse routing on his data links such that if one got dug up the other link would be fine. The cables left the equipment room at opposite ends of the room, were routed in different directions through the building, and the customer even dug two trenches in the car park from opposite corners of the building, such that the cables were a good 100 yards apart by the time they left the property. BT did its part by running one of the connections to an out-of-area exchange, so there was almost nothing in common between the two data connections.All went well for a couple of years until the customer reported the entire system was down. The visiting engineer couldn't get into the equipment room in the basement because it was half full of water. Most of the equipment in it was destroyed.The lesson: do a threat assessment before designing a resilient system. The customer was obsessed with cable dig-ups, hence the physically diverse routing, but really the greatest risk was flooding. I suspect that the flooding problem might already have been known about if only the senior manager had thought to ask the people who'd worked there for a few years.

author: MT
author_rank: Super Contributor
timestamp: April 06, 2025, 11:32:01 am
content: "Weakest link in the chain" ancient old ship engineering truism. or what the whipper said on the Roman slave trade ship when he saw one rower collapsing.

author: wraper
author_rank: Unknown
timestamp: April 06, 2025, 11:53:29 am
content: Redundancy

author: Bud
author_rank: Super Contributor
timestamp: April 06, 2025, 12:22:01 pm
content: Years ago we had a production server failed because its hard drive RAID Array went belly up. The RAID Array, a system that was designed to provide fault tolerance in the first place, failed because the CMOS backup battery on the RAID controller board gone bad. Good example as $1 component can throw your fault tolerance out of the window.

author: SteveThackery
author_rank: Super Contributor
timestamp: April 06, 2025, 12:57:07 pm
content: Quote from: wraper on April 06, 2025, 11:53:29 amYep, redundancy is a "how" - one way of providing resilience. Tends to be used when the main and standby are the same, but that isn't a hard rule.

author: Zero999
author_rank: Super Contributor
timestamp: April 06, 2025, 01:10:56 pm
content: Yes, a single failure should not result in fatality or serious injury, but that's not good enough. If a single fault occurs, but no one knows, then it only takes another fault, for the system to be dangerous.Ideally the fault will be automatically detected and the system safely stopped. If that's not possible, then the system can refuse to restart, or there needs to be an inspection schedule, so it gets rectified.

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 06, 2025, 01:39:00 pm
content: Quote from: SteveThackery on April 06, 2025, 12:57:07 pmIf the failure of any particular part of a system can have catastrophic ("fatal") consequences and the system cannot operate without it, then redundancy is pretty much the only option. Can be done in various ways too, from identical devices in parallel to devices with the same functionality but implemented completely differently - to limit the probability of all redundant devices to fail in the same way under the same conditions.In quite a few cases though, some parts of a system are not *essential* to the system (in the sense that it could operate, albeit possibly in a degraded mode, safely without them) but are designed in so that they can make the whole system fail if they fail. In that case, redundancy is not necessarily (or not at all) the answer, and making the system immune to such failure is a (sometimes better) option.

author: jonpaul
author_rank: Super Contributor
timestamp: April 06, 2025, 02:10:21 pm
content: Murphy' lawIf it can go wrong, it willj

author: SteveThackery
author_rank: Super Contributor
timestamp: April 06, 2025, 07:56:04 pm
content: Quote from: Zero999 on April 06, 2025, 01:10:56 pmYep, this is known as "fault coverage" in the trade, and refers to the percentage of faults which remain undetected until the subsystem is put into service.To be more specific, reliability engineers consider the fault coverage of both the running system and the standby system. Undetected faults on the standby system are far more common - it is not unusual for a failure in the standby system to go undetected*. Interestingly, failures in therunningsystem can sometimes go undetected by the diagnostics processes, so instead of an automatic changeover to the standby side, the faulty side stays in service until a user reports that there's a problem.There are ways of mitigating poor fault coverage in the standby system. A good way is load-sharing, such that both systems are running all the time so both enjoy the higher fault coverage of an operational system. A downside is that when an "un-covered" faultdoesoccur, it will often not be noticed by the users because load-sharing, by its nature, provides continuous service when a failure occurs.Another way is to switch between the main and standby system each day, so you run the 'A' side one day, the 'B' side the next day, then the 'A' side again, and so on. The big advantage of this approach is that if the 'B' side (say) is found to be faulty when switching to it, then you have a very high confidence that you can switch back to the 'A' side because you were using it up until a moment ago. You log the fault in the 'B' side and continue running on the temporarily non-redundant 'A' side. Hopefully the 'B' side will get fixed quickly, before the 'A' side suffers a failure.Reliability engineers also have to consider the reliability of the changeover mechanism itself. A service fault may be detected and a changeover to the standby system initiated, but the actual changeover fails. Rare, but non-zero.* We had a customer with a main and a standby data link, and they were paying good money to have both. One day an engineer needed to find an unused cable pair for a new installation. He found a "silent" pair with no data on it and used that. Literally months later our original customer suffered a failure and switched over to the standby route. As you have guessed, the standby route was dead because a long length of it was missing and had been so for months. BT had a policy of putting a DC voltage on any cable pair in service, including data pairs. The failure was that the engineer forgot to check for a DC voltage before stealing the pair. The complete lack of fault coverage on the standby route was a big contributing factor.Depending on the type of system, a large number of faults can be caused by human activity. They are known as "intervention faults" and, as you might expect, are always taken into account by reliability engineers.

author: TimFox
author_rank: Super Contributor
timestamp: April 06, 2025, 09:27:41 pm
content: One of my favorite lines in the movie "Apollo 13":"It's, it's reading a quadruple failure - that can't happen! It's, it's got to be instrumentation."The full investigation after the event found the single-point failure that caused the remaining failures.The book “Lost Moon”, on which the movie was based, has an appendix with the investigation results. The original paper trail sufficed to pinpoint the mistake that led to the first-point failure.

author: tszaboo
author_rank: Super Contributor
timestamp: April 06, 2025, 10:35:20 pm
content: Interesting idea in explosion safety, is the "countable fault". Where a component with a large, for example 50% safety margin can still fail, and your system needs to be safe with 1 or 2 of these failures still. You need proof of safety for every single scenario, where a combination of multiple components fail in different ways.

author: Andy Chee
author_rank: Super Contributor
timestamp: April 07, 2025, 01:46:15 am
content: Single point failure

author: SteveThackery
author_rank: Super Contributor
timestamp: April 07, 2025, 10:47:05 am
content: I do think Hannah Fry is a hoot.

author: SteveThackery
author_rank: Super Contributor
timestamp: April 07, 2025, 10:48:30 am
content: I wonder what has happened to the OP. Do you reckon it was a homework question?

author: incf
author_rank: Frequent Contributor
timestamp: April 07, 2025, 12:23:57 pm
content: Quote from: SteveThackery on April 07, 2025, 10:48:30 amNah. A family member got a minor electrical zap by not following procedure, and it got me thinking there have to be names for the various related types/classes of issue I had just observed.Other disciplines have all sort of cool "laws" that are helpful for explaining certain concepts - and all we've got is Murphy.I don't really have much to contribute other than passively absorbing the responses.

author: rogerggbr
author_rank: Contributor
timestamp: April 07, 2025, 01:17:56 pm
content: Quote from: incf on April 05, 2025, 09:02:00 pmTo answer that specific question, I would agree with others and call it "Fail Safe". No one died but your system (or part of it) is now not working. This seems to be quite common with machinery/process plant - if in doubt shut it down. If you want it to keep working then you are into redundancy/resilience etc.

author: SteveThackery
author_rank: Super Contributor
timestamp: April 07, 2025, 01:43:42 pm
content: Quote from: incf on April 07, 2025, 12:23:57 pmSo do you feel you've had a sufficient response to your question? I don't think Murphy's Law is the full story, but I don't think there exists a law which talks about redundancy, resilience, diversity, fault tolerance, fault coverage, intervention faults, etc.

author: rogerggbr
author_rank: Contributor
timestamp: April 07, 2025, 02:03:25 pm
content: There is a lot more than Murphy, try these:-https://www.chiefdelphi.com/t/the-laws-of-engineering/386223

author: Sensorcat
author_rank: Regular Contributor
timestamp: April 07, 2025, 07:50:04 pm
content: Quote from: SteveThackery on April 06, 2025, 10:43:39 amI was answering the question from the thread title. This question is not about not failing, it is about avoiding 'fatal' consequences - whatever that means in the respective case. If you look at your own reply, it is exacly what was asked for. Reliability, most probably your task as a Reliability Engineer, is a different thing. It is about not-failing.

author: incf
author_rank: Frequent Contributor
timestamp: April 07, 2025, 08:55:30 pm
content: Quote from: rogerggbr on April 07, 2025, 02:03:25 pmThat is a good list

author: Nominal Animal
author_rank: Super Contributor
timestamp: April 07, 2025, 11:24:27 pm
content: I'm sometimes called a zealot (by various other names), because I hate the single-point failure tendencies in softwaresystemsprogramming. A particular example of this is systemd. (I particularly dislike it, because its inclusion in Debian involved some serious social tricks. Initially, they promised co-operation with other init systems. Nowadays, the systemd developers and developers in related/subsumed projects are actively hostile to any other competing system, even deliberately blocking and removing interoperability features.)Now, people use and trust whatever they want, and that is okay. It is when systems suffering from plenty of single point of failure weaknesses and other issues, driven by people adept at social interactions but lacking any talent in engineering, are called "superior" and "preferable", that gets me aggressive. It's doubly so when my reasoned opposition and pointing out these issues –– like multiple single point of failure weaknesses –– is ignored by labeling me "anti-this" or "that-zealot" or "jealous", instead of rationally and logically examining those reasons.Therefore, I'd saysoftware engineeringis in an even worse position: not only is there no simple language to acknowledge these issues, but bringing them up labels you as an ideological opponent whose arguments should be ignored on principle.(Added: Don't let Tux, my mascot, fool you. I happily work with all sorts of licenses, and even under NDA. Just because I like open source and Creative Commons and GNU licenses, does not mean I dislike proprietary software. Tools are tools, and in some cases, the proprietary ones are the proper ones to use.)

author: Infraviolet
author_rank: Super Contributor
timestamp: April 08, 2025, 04:08:54 pm
content: Another phrase is "failing gracefully", or avoiding "cascading failures". The idea being that failures in one place should lead to a loss of "performance" rather than total failure.There's a book called "Normal Accidents" by Charles Perrow which is said to be a good description of these principles, I have a copy but still haven't got round to reading it.

author: TimFox
author_rank: Super Contributor
timestamp: April 08, 2025, 04:18:28 pm
content: The origin of the name "Murphy's Law" is generally held to go back to Edward A Murphy, Jr, who was running rocket-sled experiments on the effect of acceleration on humans between 1948 and 1949 for the US Air Force.After a bad run caused by miswiring of the sensors, he wrote: "If there are two or more ways to do something and one of those results in a catastrophe, then someone will do it that way."I have elsewhere seen his original law as "Whatever can be done wrong, will be done wrong", which is slightly different from the usual modern phrase.

author: SteveThackery
author_rank: Super Contributor
timestamp: April 08, 2025, 05:02:34 pm
content: Quote from: Nominal Animal on April 07, 2025, 11:24:27 pmActually I would like to expand that out to include application programming. I think there is, in general, less attention paid to software reliability and resilience than there is to those things in the world of mechanical engineering.I think I can safely say that most applications are programmed assuming that what is described in the code will happen. After all, software is deterministic, right? Except that there are bugs in most code of any consequence, so although it is deterministic, it can still do something you hadn't intended.Secondly, applications can fail when they consume bad data from an external source. Assume that the incoming data is positive integers, and it will malfunction if a negative integer finds its way in there.The accepted approach for handling errors in software is exception handling. But you know?... writing exception handlers for every piece of code, that will comprehensively address all possible errors, is very tedious and time consuming. I've tried writing such code and the exception handling stuff takes up as much or more space than the actual algorithm. Plus it makes the code harder to read.Even if the programmer does use exceptions for handling bumps in the road, it is all too tempting to handle exceptions at the highest possible level. But the higher they are handled the more generic and non-specific they become, so the harder it is to actually fix the exact cause. So, instead of an actual crash you might see a message box saying "The application has run into a problem and needs to restart", which hardly counts as resilience.I find the whole subject of making software systems resilient against internal bugs and external bad data fascinating. Apart from exception handling, we might consider sanity checking on data before it gets processed (and perhaps on the results after processing). We might consider routine sanity checking of internal data structures. And then there is the concept of a "diagnostics" thread/process, which interrogates other threads for responsiveness and gets an "I'm running OK" message back. A related system is the "heartbeat" method, where running threads send "I'm OK" to the diagnostics at regular intervals (ie they initiate it, rather than the diagnostics initiating it). This is reminiscent of the watchdog timer in an embedded system - a very useful tool that isn't normally available to computer applications.I imagine the software used in aircraft and spaceships is beautifully engineered in terms of reliability and resilience, and I'm sure there are lessons that could be learned and applied to computer applications in general.EDIT: I am not advocating using all of those techniques in every case. In mechanical engineering, FMEA (failure modes and effects analysis) is used to determine what mitigation is required where (and what isn't necessary or appropriate). I wonder how many computer apps or embedded programs begin with an FMEA before any code is written?

author: TimFox
author_rank: Super Contributor
timestamp: April 08, 2025, 05:13:18 pm
content: Quote from: rogerggbr on April 07, 2025, 02:03:25 pmAn excellent list, but it omitted "Fetridge's Law":"Important things that are supposed to happen do not happen, especially when people are looking; or, conversely, things that are supposed not to happen do happen, especially when people are looking."I have seen it stated "The probability of a welcome happenstance is inversely proportional to the number of people watching".Supposedly named after Claude Fetridge, a radio engineer who tried to broadcast the departure of the swallows from Capistrano on the feast day of St John in 1936 on a live NBC radio hookup. The stupid birds left the day before.This law was cited in a Michigan court case about a personal injury suffered on a Detroit city bus:https://law.justia.com/cases/michigan/supreme-court/1967/379-mich-405-2.html

author: fourfathom
author_rank: Super Contributor
timestamp: April 08, 2025, 08:41:35 pm
content: Add "Weinberg's Second Law" : If builders built houses the way programmers built programs, the first woodpecker to come along would destroy civilization.In some circuit-switched telecommunications gear we design with hardware redundancy to provide automatic fail-over. This can be hitless failover, or more often a limited-disruption fail-over, where the hit is only a few milliseconds.

author: ftg
author_rank: Frequent Contributor
timestamp: April 09, 2025, 06:56:18 am
content: Or they were writing an article.I particularly like the term "Swiss cheese model".https://en.wikipedia.org/wiki/Swiss_cheese_modelIt's a more memorable way to say defence in depth, while acknowledging that no single control is perfect.So the name already includes a rebuke to those who chase perfect silver bullets.

author: 5U4GB
author_rank: Super Contributor
timestamp: April 09, 2025, 11:56:29 am
content: Quote from: incf on April 05, 2025, 09:02:00 pmNo single point of failure (SPOF)?

author: EPAIII
author_rank: Super Contributor
timestamp: April 09, 2025, 01:00:56 pm
content: Redundant. BMTI! (Beat Me To It!)orNo Single Point of Failure!orThe story of my life as a broadcast engineer.The problem is, it is impossible to completely eliminate single points of failure. Instead you just wind up with increasingly complex systems that are increasingly difficult to even understand where/how they can fail. Software is a great example of this.Quote from: wraper on April 06, 2025, 11:53:29 am