On Sat, 23 Apr 2016 00:54:56 -0700, Don Y <blockedofcourse@foo.invalid> wrote:>On 4/22/2016 11:29 PM, upsidedown@downunder.com wrote: >>> In my case, "just waiting" (i.e., for the plane to land) isn't a >>> practical option -- the system is intended to run 24/7/365 so there's >>> no "scheduled down time" or "end of flight" :> >> >> Use a redundant system with at least two identical units, say A and B. >> If A needs to be reseted, doing some self test or do some application >> or OS upgrade, switch control to B, do the required maintenance >> operation (including hardware replacement) on A. Check that A is up >> and running, then you can switch back to A. > >The problem comes with I/O's. Not only do you have to "duplicate" >the field interface -- but, you also have to provide a RELIABLE means >to switch between any actuators driven by those two "duplicates".This is often done with a voting system or majority logic systems with three or more controllers. The final output state is the one most controllers can agree on. There can be different forms of voters, from logic gates to relays to hydraulics etc. One very simple mechanical voter is a horizontal bar connected to some mechanical control point with three coils on the bar driven by three control systems. The mechanical bar moved in that direction that at least two control systems are actively ordered to move left or right. The disagreeing unit and coil is overridden by the other system and the third does the actual movement. Simpler methods exists, when there is one "safe" state and an other "dangerous" state which should not be entered by mistake or hardware failure is to use a vertical bar with some weight to pull it down to the safe state. A coil is then driven to the "dangerous" state. Both ends could be driven separately preferably from different systems. One other approach is to use the select/execute method, in which one separate signal is needed to activate the relay power supply and an other to activate the actual relay. A timer is needed to deactivate the relay power supply, if no actual relay command is received. Thus, a separate Select or separate Execute can not do any action. Cross feeding select and execute from different controllers in a redundant system reduces the risk of spurious activity.> >I.e., if A has an output set ON and B thinks it *really* should be OFF, >how is the controlled device to know who to listen to? > >I consider physical I/O replication to be too troublesome. So, I >only provide redundancy on "virtual" entities (processes, state, etc.). >In that way, all I need are spare CPU's...Relays and hydraulic valves may also fail, so you should look at the big picture and not just software.
Remote "watchdog"s
Started by ●April 20, 2016
Reply by ●April 23, 20162016-04-23
Reply by ●April 23, 20162016-04-23
On 4/23/2016 3:46 AM, upsidedown@downunder.com wrote:> On Sat, 23 Apr 2016 00:54:56 -0700, Don Y > <blockedofcourse@foo.invalid> wrote: > >> On 4/22/2016 11:29 PM, upsidedown@downunder.com wrote: >>>> In my case, "just waiting" (i.e., for the plane to land) isn't a >>>> practical option -- the system is intended to run 24/7/365 so there's >>>> no "scheduled down time" or "end of flight" :> >>> >>> Use a redundant system with at least two identical units, say A and B. >>> If A needs to be reseted, doing some self test or do some application >>> or OS upgrade, switch control to B, do the required maintenance >>> operation (including hardware replacement) on A. Check that A is up >>> and running, then you can switch back to A. >> >> The problem comes with I/O's. Not only do you have to "duplicate" >> the field interface -- but, you also have to provide a RELIABLE means >> to switch between any actuators driven by those two "duplicates". > > This is often done with a voting system or majority logic systems with > three or more controllers. The final output state is the one most > controllers can agree on. There can be different forms of voters, from > logic gates to relays to hydraulics etc.Yes, and the voting logic is also subject to failure. And, of course, the actuators being controlled, etc. You've got a "loose thread" on a garment and tugging on it just keeps unraveling the next layer. There's a point at which you say "what is the value of redundancy" compared to the *cost*? What "extra" redundancy would have saved Columbia?
Reply by ●April 23, 20162016-04-23
On Sat, 23 Apr 2016 04:08:32 -0700, Don Y <blockedofcourse@foo.invalid> wrote:>On 4/23/2016 3:46 AM, upsidedown@downunder.com wrote: >> On Sat, 23 Apr 2016 00:54:56 -0700, Don Y >> <blockedofcourse@foo.invalid> wrote: >> >>> On 4/22/2016 11:29 PM, upsidedown@downunder.com wrote: >>>>> In my case, "just waiting" (i.e., for the plane to land) isn't a >>>>> practical option -- the system is intended to run 24/7/365 so there's >>>>> no "scheduled down time" or "end of flight" :> >>>> >>>> Use a redundant system with at least two identical units, say A and B. >>>> If A needs to be reseted, doing some self test or do some application >>>> or OS upgrade, switch control to B, do the required maintenance >>>> operation (including hardware replacement) on A. Check that A is up >>>> and running, then you can switch back to A. >>> >>> The problem comes with I/O's. Not only do you have to "duplicate" >>> the field interface -- but, you also have to provide a RELIABLE means >>> to switch between any actuators driven by those two "duplicates". >> >> This is often done with a voting system or majority logic systems with >> three or more controllers. The final output state is the one most >> controllers can agree on. There can be different forms of voters, from >> logic gates to relays to hydraulics etc. > >Yes, and the voting logic is also subject to failure.Yes, the horizontal bar with three actuator coils is subject to earthquakes :-).>And, of course, the actuators being controlled, etc.The voting is done in the solid mechanical bar. Of course, this could brake, but in such situations, how much is alive anyway ?>You've got a "loose thread" on a garment and tugging on it just >keeps unraveling the next layer. > >There's a point at which you say "what is the value of redundancy" >compared to the *cost*?Usually customers with a daily production volume more than 1 million USD/EUR each day require redundant systems. In other cases, when there is a risk to human life or there are a risk of ending into CNN main news :-), redundant systems are often used. In the nuclear industry, there is not a point of using more than a few _identical_ units, since in Fukushima, all the diesels required by the emergency cooling system got wet by the tsunami. Using 3+3 different emergency cooling systems would have saved the plant.>What "extra" redundancy would have saved Columbia?The STS was an idiotic design (due to weight constraints), so no redundancy would have saved the crew.
Reply by ●April 23, 20162016-04-23
On 4/23/2016 7:26 AM, upsidedown@downunder.com wrote:>> You've got a "loose thread" on a garment and tugging on it just >> keeps unraveling the next layer. >> >> There's a point at which you say "what is the value of redundancy" >> compared to the *cost*? > > Usually customers with a daily production volume more than 1 million > USD/EUR each day require redundant systems. In other cases, when there > is a risk to human life or there are a risk of ending into CNN main > news :-), redundant systems are often used.I've worked in industries where a single machine could produce greater value per run-time *hour*. "Redundancy" was not addressed ON the machines, at all. Manufacturing was kept "available" by having spare machines instead of having more RELIABLE machines. My point is that redundancy adds cost and complexity to a design. Toilet flappers fail regularly. Why not incorporate some redundancy in their design to eliminate/reduce this possibility?
Reply by ●April 27, 20162016-04-27
Den l�rdag den 23. april 2016 kl. 21.59.19 UTC+2 skrev Don Y:> On 4/23/2016 7:26 AM, upsidedown@downunder.com wrote: > >> You've got a "loose thread" on a garment and tugging on it just > >> keeps unraveling the next layer. > >> > >> There's a point at which you say "what is the value of redundancy" > >> compared to the *cost*? > > > > Usually customers with a daily production volume more than 1 million > > USD/EUR each day require redundant systems. In other cases, when there > > is a risk to human life or there are a risk of ending into CNN main > > news :-), redundant systems are often used. > > I've worked in industries where a single machine could produce > greater value per run-time *hour*. "Redundancy" was not addressed > ON the machines, at all. Manufacturing was kept "available" by > having spare machines instead of having more RELIABLE machines. > > My point is that redundancy adds cost and complexity to a design. >a guy went to work with worked nights at a local paper printing delivery list, they had some big IBM monster of a mechanical printer and since failure to print the lists meant no paper delivered they had an expensive "guaranteed in a few hours" service eventually they just got a row of regular laser printers, as long as few of them worked they could make the lists on time so they didn't need some service technician on standby. and buying a new was cheaper than fixing -Lasse
Reply by ●April 27, 20162016-04-27
On 4/27/2016 3:25 PM, lasselangwadtchristensen@gmail.com wrote:> Den l�rdag den 23. april 2016 kl. 21.59.19 UTC+2 skrev Don Y: >> On 4/23/2016 7:26 AM, upsidedown@downunder.com wrote: >>>> You've got a "loose thread" on a garment and tugging on it just >>>> keeps unraveling the next layer. >>>> >>>> There's a point at which you say "what is the value of redundancy" >>>> compared to the *cost*? >>> >>> Usually customers with a daily production volume more than 1 million >>> USD/EUR each day require redundant systems. In other cases, when there >>> is a risk to human life or there are a risk of ending into CNN main >>> news :-), redundant systems are often used. >> >> I've worked in industries where a single machine could produce >> greater value per run-time *hour*. "Redundancy" was not addressed >> ON the machines, at all. Manufacturing was kept "available" by >> having spare machines instead of having more RELIABLE machines. >> >> My point is that redundancy adds cost and complexity to a design. > > a guy went to work with worked nights at a local paper printing delivery > list, they had some big IBM monster of a mechanical printer and since failure to print the lists meant no paper delivered they had an expensive "guaranteed > in a few hours" service > > eventually they just got a row of regular laser printers, as long as few of them worked they could make the lists on time so they didn't need some > service technician on standby. and buying a new was cheaper than fixingYeah, which is why I have many PC's. OTOH, we have exactly ONE furnace in the house, one ACbrrr, one roof, one set of exterior walls, etc. we *could* implement redundancy for each of these things -- at considerable cost and complexity! Having walls up, heat and a roof overhead goes far beyond the "few hours service" sort of guarantee!
