Industrial I/O

This all amounts to the effort of getting requirements right in the first place. Requirements should only state WHAT needs to be done. The design specifications should then concentrate on the HOW.
As for redundant processing, you need to look at the types of failures you need to protect against. If it is a multi-channel solution then you can demand that one team employ positively asserted logic while the second team employ negatively asserted logic. This will eliminate much of the designed in problems. If you need a third channel, then that could be in a different technology (I have done systems this way before).
With regard to the PMR (Pulse Maintained Relay) as a watchdog, you need the software to be able to flip the state based on the outcome of a series of tests and only when the back-stop in the main process is reached. Tying in the results of walking memory tests, checks on correct I/O operation and other sanity checks will make it quite useful as a means of determining the systems health or otherwise.
Of course, developing for Safety Critical Systems will mean an involvement in Certification, usually with the oversight of a regulatory agency or two. This will mean that your development process and documentation needs to also be very sound and of a quality that it becomes hard evidence that you approached the whole task properly.
--
******************************************************************** 
Paul E. Bennett IEng MIET..... 
 Click to see the full signature
Reply to
Paul E Bennett
Loading thread data ...
I once saw a flow chart for operation of one of the early PLCs. IIRC it was something like this if you modernise it a bit:
DO scan program area for memory errors set watchdog flag read all inputs to input buffers read status of all outputs process user program (all outputs go to buffers at this stage) update physical outputs from output buffers clear watchdog flag LOOP
Note that you can't pause the main loop to run timers! If you do the watchdog will flag an error. If the watchdog flag is high for too long it stops the program and clears all outputs to zero. This is done in hardware.
To make, say, a 200ms delay you clear a 100ms timer flag. That goes high again after 100ms so you do it again. The timer flags were, I think, set by interrupts, but they may just have been software.
All inputs and outputs are buffered so that input changes mid-program don't cause problems (this was programmed in ladder logic).
Reply to
mick
Obviously no hardware experience :)
This what I do.
A more sophisticated idea I've seen is where the program is split into must-see functions.
A counter is zeroed at the start of the loop, and each function increments this on successful completion. At the end of the loop the counter is checked, and only if it has the correct value is the output toggled.
If the program freezes there will be no toggle, and depending on the hardware timeconstant the main loop will get a number of chances to get it right.
Voting systems have been done in critical systems for some time. Space projects tend to favour 5 computers I believe.
--
W J G
Reply to
Folderol
Can't remember where/when, but in one case independent teams both made the same incorrect assumption, with disastrous results.
--
Windmill, TiltNot@NoneHome.com       Use  t m i l l 
J.R.R. Tolkien:-                            @ S c o t s h o m e . c o m 
 Click to see the full signature
Reply to
Windmill
It's good to keep in mind that nothing real is perfect. ;-)
--
-michael - NadaNet 3.1 and AppleCrate II: http://home.comcast.net/~mjmahon
Reply to
Michael J. Mahon
That's easy to do if the problem is in the specs.
"Problem" can be lack of clarity rather than an outright bug.
--
These are my opinions.  I hate spam.
Reply to
Hal Murray
Speaking of specs and disastrous results...
I am near the North Anna nuclear plant which experienced an earthquake a couple of years ago. There were a number of issues at the plant as it was not designed for an earthquake of the severity felt. One that got my attention is when one of the generators failed. The plant automatically disconnected from the power grid and the backup generators start to power the cooling systems. After some time one of them blew a head gasket. No big deal, right? They have spare generators, and another started up and all was fine... until they dug into why it failed...
Seems the head gasket was installed incorrectly, not because someone munged up the installation. It was installed incorrectly because the installation procedures were wrong! Potentially they *all* could have been installed badly and *every generator could have failed within minutes of starting up*!!!
This plant has been in operation since 1973 and only now did they find a faulty installation procedure. How many potential disasters are out there waiting to be discovered in a nuclear event somewhere in the 100+ power reactors in the US?
--

Rick
Reply to
rickman
The generators are run up periodically to ensure that they are in fact capable of running.
Joe Public may have been born yesterday: Engineers are not.
--
Everything you read in newspapers is absolutely true, except for the  
rare story of which you happen to have first-hand knowledge. ? Erwin Knoll
Reply to
The Natural Philosopher
And yet one failed, eh? So what was to prevent others from failing.... luck! You can not prove a system is fault free by testing unless you can test all modes and all conditions. For a complex system the testing required is also complex and subject to faults.
You are missing the point. There are *no* significant systems that are infallible. In particular thinking a system is infallible is a major component of the failure modes.
--

Rick
Reply to
rickman
Well all engineering is in the final analysis down to luck.
It didn't crash yesterday so it probably wont crash tomorrow.
If you want certainty try the Pope.
Do what?
In particular thinking a system is infallible is a major
Well that's your problem not mine.
The sun might not rise tomorrow.
I wont lose any sleep over it tho.
--
Everything you read in newspapers is absolutely true, except for the  
rare story of which you happen to have first-hand knowledge. ? Erwin Knoll
Reply to
The Natural Philosopher
Good little book if you can find it: _Systemantics_ by John Gall. Introduction to the science of General Systemantics, approximately in the style of C. Northcote Parkinson.
Mel.
Reply to
Mel Wilson
There was a L-1011 (3 engines) that just barely made it back to Florida after the guy who changed the oil forgot to put the o-rings back in.
formatting link
"We believe it to be faulty indications since the chance of all three engines having zero oil pressure and zero quantity is almost nil."
-------
Bugs in documentation have long been an "interesting" problem in the software area.
Many years ago, I read a neat story, probably on usenet. Our hero was on a US destroyer in the south pacific. He was in charge of the 5 inch guns. They worked, but weren't quite as accurate as they should have been. They even had a factory rep flown out. He didn't fix anything. When their time was up and they were headed back home, one if his guys said, roughly, "Everything is clean and polished, how about I take a look at the gun controller?" The guy was good at that sort of stuff, so the answer was "go for it". This was analog computer days. Picture gears all over the place, like a kid taking apart a clock. As things were put back together, the guy turned one gear over. That fixed it. The picture in the book showed it in the wrong way.
--
These are my opinions.  I hate spam.
Reply to
Hal Murray
{Odd -- "reply" is resulting in a blank TO: and blank NEWSGROUP: header -- hard to submit a response that way}
On Sat, 26 Jul 2014 16:25:55 -0500, snipped-for-privacy@ip-64-139-1-69.sjc.megapath.net (Hal Murray) declaimed the following:
Seems like a reasonable belief... After all, what are the odds that one mechanic would service all three engines and repeat the same mistake on all three?
That said -- I managed a $400 gain when trading up my (high mileage according to BlueBook) Vespa GT200 for an Aprilia Scarabeo 500 ABS... The dealer admitted that all my problems over the prior 6 months (having to have the nut on the drive shaft replaced almost monthly) was due to a mechanic (since fired -- for the behavior following) reusing the nut when replacing the drive belt. The nuts are nylon locking types... By reusing it, it didn't lock, and spun loose. That led to the front pulley damaging the threads on the drive shaft (which is the end of the crank shaft) such that new nuts would be damaged on install. After a month in the shop waiting for a crank shaft from Italy, the shop owner offered me the trade (I had been looking at the "DungBeetle" but didn't like the eggshell white they had in stock -- turns out a silver one had come in...)
Boy, I wish I could document a story I have as hearsay...
Some ship (don't recall the class) had come in for refitting after a few years at sea. One of the chiefs at the facility told some lower level to go to the ship's machine shop and mill a replacement for some part. He was told the ship didn't have a machine shop. He insisted that it did, as he'd been involved in the original installation. Led them below deck to where he was sure the shop was. No hatch... They proceded to check all sides and found no hatches. Cut an opening in the bulkhead to reveal: A pristine, unused, full machine shop!
--
	Wulfraed                 Dennis Lee Bieber         AF6VN 
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/
Reply to
Dennis Lee Bieber
Very interesting example in that it shows the tendency of *people* to ignore potentially significant hazards when they don't result in an accident. Notice the last sentence in the section "Cause".
"Contributing to the cause of the incident was the failure of Federal Aviation Administration maintenance inspectors to assess the significance of the incidents involving master chip detectors and to take effective surveillance and enforcement measures to prevent the recurrence of the incidents."
The problem existed with the mechanics, the supervisors and the FAA inspectors... three levels of humans all failed to comprehend the significance of the "similar previous occurrences".
--

Rick
Reply to
rickman
I don't follow. I'd say the chances are not so bad. What are the chances that all three indicators would fail in the same way? *That* is pretty slim.
Bizarre, but believable. A ship is such a huge thing I can see how a room would be built and somehow the hatchway into it was omitted at some point. I would expect a machine shop to be fitted out before all the bulkheads go up. I guess no one spotted the mistake because few people know the full plan, they just follow their own set of instructions.
--

Rick
Reply to
rickman
A related story comes from NASA.
In the hope of avoiding human error, they had three inspectors independently inspect every wiring harness, connector, pipe, etc.
They discovered that each of the three inspectors did a less thorough inspection because they knew that two other inspectors would be covering the same ground!
They returned to single inspectors, who did a much better job because the understood that the success of the mission depended upon their vigilance.
--
-michael - NadaNet 3.1 and AppleCrate II: http://home.comcast.net/~mjmahon
Reply to
Michael J. Mahon
...and there was the case of a self-designed add-on second floor on a farmhouse near where I grew up in NZ. It wasn't until a late arrival at the house-warming party asked to see the new upstairs rooms that the owner realised they'd forgotten to put in a staircase. It seems that he and the workmen were so used to going up and down the scaffolding that nobody had noticed the omission.
--
martin@   | Martin Gregorie 
gregorie. | Essex, UK 
 Click to see the full signature
Reply to
Martin Gregorie
Did you ever find what you were looking for? Or are you still looking?
--

Rick
Reply to
rickman
I found some modules:
formatting link

but these aren't Modbus. Unfortunately everthing is proprietary and as usual closed source. There is some kind of reverse engeneering for the FHEM project, but actually I'm still looking...
H.
Reply to
Helmuth Kranz
Why does it need to be open source, and what is FHEM?
--

Rick
Reply to
rickman

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.