"PICAXE is not recommended in safety critical systems.".... I have seen this warning posted many times for Picaxe. I understand it, but I am wondering a couple of things. What microcontroller would you recommend for safety critical systems? Why don't Arduino, Basic Stamp, BasicMicro, Athena, Dios, and other bootstrapped, entry-level microcontroller systems emphasize this more?
PICAXE is not recommended in safety critical systems?
- Thread starter artswan
- Start date
Lordy, you're going to start some very long multi-paragraph threads.
Everyone's an expert.
Hippy will fill 5 pages of A4 on his own on this one
Why don't the others emphasize it more? Dunno. Ask them.
Naturally, anyone who can programme C will be safer
If you look at many Data Sheets from BIG Manufacturer's they will also include long paragraphs on this.
Why?
1. Covering their bottoms.
2. They/we don't know who will use the device and in what app.
There are many people in this World. They range from mega-qualified/experienced all the way down to pot-plant.
3. Safety. Many devices can be used but it's HOW they are used and HOW they will fail.
4. Regulations, Law, Litigation , Liabitlity and Lawyers/solicitors.
5. Production devices will undergo many rigorous and vigorous tests to prove viablity and to determine failure.
This is why good stuff costs money.
6. Some semi manufacturers will have options on higher grade (ie. selected/tested) components too, but that's an aside and you have to contact them.
And, of course, erring on the side of caution.
But this thread is going tun into some big replies.
Lie back and endure.. sorry, I mean, enjoy.
Everyone's an expert.
Hippy will fill 5 pages of A4 on his own on this one
Why don't the others emphasize it more? Dunno. Ask them.
Naturally, anyone who can programme C will be safer
If you look at many Data Sheets from BIG Manufacturer's they will also include long paragraphs on this.
Why?
1. Covering their bottoms.
2. They/we don't know who will use the device and in what app.
There are many people in this World. They range from mega-qualified/experienced all the way down to pot-plant.
3. Safety. Many devices can be used but it's HOW they are used and HOW they will fail.
4. Regulations, Law, Litigation , Liabitlity and Lawyers/solicitors.
5. Production devices will undergo many rigorous and vigorous tests to prove viablity and to determine failure.
This is why good stuff costs money.
6. Some semi manufacturers will have options on higher grade (ie. selected/tested) components too, but that's an aside and you have to contact them.
And, of course, erring on the side of caution.
But this thread is going tun into some big replies.
Lie back and endure.. sorry, I mean, enjoy.
Last edited:
I have worked tens of years with industrial electronics, and with that background, I answer your question: NONE!!!
If REALLY someone is in danger, if a uP "tilts", it should not be used at all, OR THE SAFETY SHOULD BE ENSURED BY SOME OTHER WAY.
That kind of statements are a legal thing: manufacturer/reseller HAS TO WARN, that there is a POSSIBILITY of malfunction, wich CAN CAUSE danger and sever injury.
Understand, what I mean...
If a microprocessor is used in home a/v-system, and it goes haywire, the only danger is ,that you pop a vain in your head, when you get angry...
No other danger to physical injury.
If a microprocessor is used ,for example, in a car, in some critical system (engine, breaks,safety-equipment etc.), the failure can cause IMMINENT DEATH or injury.
In avionics, EVERY system is AT LEAST triple, when uP's used.
I DO NOT mean to be negative. Just tried to explain.
IF You use a microprosessor, THINK, what an error COULD CAUSE.
If ANY possible error CAN NOT cause any real danger to anyONE or anyTHING, use it with good consience.
If You find a POSSIBLE danger, use the device anyway,but NOT BEFORE YOU HAVE INVENTED, HOW TO PROHIBIT THE BAD CONSEQUENCES IN SOME OTHER WAY.
Many times, the "other way" means something very different, even a mechanical way. For example, if a machine could cause injury to people,when microprocessor malfunctions, build a fence round the machine!
The most important thing in making devices/programs in the "real" environment , is to think error-consequences and to prevent them!
Remember! Only Governments and Corporations can do "damage control" , not people or small companies!
The latter has to think things in advance...
Edit:some typo's corrected
Last edited:
hippy
Ex-Staff (retired)
My book on the subject will be available towards the end of the decade and available as an encyclopaedic set which includes walnut book case and floor strengthening supports. It will come with a comprehensive first volume which describes the dangers and risks of installing the complete work
What microcontroller would you recommend for safety critical systems?
A difficult one to give an actual answer for, though there are some which are more designed towards being used in safety critical situations than others. A few examples seems to be ...
http://autoelectronics.com/news/ti_launches_mcus_1105
http://www.st.com/stonline/stappl/cms/press/news/year2009/t2422.htm
http://www.edn-europe.com/infineonsmicrocontrollerfamilyforsafetycriticalfunctions+article+1645+Europe.html
There is no absolute rule on any micro being used or not being used in any safety critical system as it's the whole which has to be safe. Past generation microcontrollers, equally "not recommended for safety critical systems", have been used in such by applying this principle.
Why don't Arduino, Basic Stamp, BasicMicro, Athena, Dios, and other bootstrapped, entry-level microcontroller systems emphasize this more?
It's most likely an 'in context' thing and so only raises its head when a safety critical project or issue gets discussed. In discussion you need someone to have that knowledge, see that it applies, and have enough concern or courtesy to mention it.
I expect there are a high number of discussions out there which never mention safety critical issues when members of this forum would have brought the subject up if they'd been involved.
What microcontroller would you recommend for safety critical systems?
A difficult one to give an actual answer for, though there are some which are more designed towards being used in safety critical situations than others. A few examples seems to be ...
http://autoelectronics.com/news/ti_launches_mcus_1105
http://www.st.com/stonline/stappl/cms/press/news/year2009/t2422.htm
http://www.edn-europe.com/infineonsmicrocontrollerfamilyforsafetycriticalfunctions+article+1645+Europe.html
There is no absolute rule on any micro being used or not being used in any safety critical system as it's the whole which has to be safe. Past generation microcontrollers, equally "not recommended for safety critical systems", have been used in such by applying this principle.
Why don't Arduino, Basic Stamp, BasicMicro, Athena, Dios, and other bootstrapped, entry-level microcontroller systems emphasize this more?
It's most likely an 'in context' thing and so only raises its head when a safety critical project or issue gets discussed. In discussion you need someone to have that knowledge, see that it applies, and have enough concern or courtesy to mention it.
I expect there are a high number of discussions out there which never mention safety critical issues when members of this forum would have brought the subject up if they'd been involved.
Sorry, I wanted to "underline" the important parts, and did not want to use control codes everywhere, because it is slower...@KT - you seem to have a strange intermmittent caps lock problem. No need to shout (occasionally) mate
I know, that capitals can be translated as shouting ,too, and my intention was not to shout.
Though, the issue is important, and wanted to make myself clear.
Believe me, I have experience, twice have I been in a great danger because of malfunctioning control-hardware! (and cleared only with a very good luck)
I have also been a (I don't know the right term in english) work-enviroment-safety-inspector for a few years. My job was to detect any possible instance of danger to people in that company.
On those bases, I wan't to give all Picaxe-users the right attitude: Use to anything, but remember to think thoroughly, what might happen.
Happy now, no capital words...
fernando_g
Senior Member
"PICAXE is not recommended in safety critical systems.".... QUOTE]
RevEd is not doing anything out of the ordinary.
Most semiconductor companies carry a similar warning; you have to notify them in writing if you plan to do so.
I guess that they'll make you sign a 100-page document releasing them from all liability, etc, and make you to purchase insurance from Lloyd's.
Now seriously, any device can fail...but a well designed system will have redundancy in key areas, a very comprehensive validation and certification procedure, and more than one fail-safe and recovery mechanism.
BrendanP.... From what I am reading here, if you have three 08M in parallel with each other, along with the other necessary redundant circuitry, you and those tikes in the children's hospital should be plenty safe.
What microcontroller would you recommend for safety critical systems? Why don't Arduino, Basic Stamp, BasicMicro, Athena, Dios, and other bootstrapped, entry-level microcontroller systems emphasize this more?
Some great points above. Bottom line - all microcontrollers can fail. No problem if it is your mobile phone and it locks up and you have to pull the battery out to reset it (like I needed to this morning). So a safety analysis is not a matter of how something works, but how it fails. Say you are sensing one thing (a tank level) and turning on one thing (a pump). A microcontroller can fail to turn on, fail to turn off and can also fail by turning on and off rapidly. Results are flood, burnt out motor and burnt out controller then motor.
Is a microcontroller less reliable than a mechanical float switch or a relay, or even an analogue circuit? I'd suspect it is. A relay is more likely to survive lightening. An analogue circuit is more likely to survive the electromagnetic pulse from a nearby motor turning on.
My father is an engineer and he has a philosophy on control gear which says that you do the controlling with simple components like relays and mechanical devices, and when that system is working, you can layer on above that a control system that is based on microcontrollers. So you might have a tank emptying and filling with a float switch, but you might have a pressure sensor and a picaxe that might be sending data via SMS to a mobile phone. The latter part is not mission critical if it fails. But at the same time, it adds a very useful function to the overall system.
Some great points above. Bottom line - all microcontrollers can fail. No problem if it is your mobile phone and it locks up and you have to pull the battery out to reset it (like I needed to this morning). So a safety analysis is not a matter of how something works, but how it fails. Say you are sensing one thing (a tank level) and turning on one thing (a pump). A microcontroller can fail to turn on, fail to turn off and can also fail by turning on and off rapidly. Results are flood, burnt out motor and burnt out controller then motor.
Is a microcontroller less reliable than a mechanical float switch or a relay, or even an analogue circuit? I'd suspect it is. A relay is more likely to survive lightening. An analogue circuit is more likely to survive the electromagnetic pulse from a nearby motor turning on.
My father is an engineer and he has a philosophy on control gear which says that you do the controlling with simple components like relays and mechanical devices, and when that system is working, you can layer on above that a control system that is based on microcontrollers. So you might have a tank emptying and filling with a float switch, but you might have a pressure sensor and a picaxe that might be sending data via SMS to a mobile phone. The latter part is not mission critical if it fails. But at the same time, it adds a very useful function to the overall system.
Artswan, did you get the answers you needed?
You can see that, in general, it's not just the micro that has to be of a certain spec. , it's the whole thing.
A "mil-spec" micro isn't indestructable or totally reliable if the rest of the circuit is pants.
And then, of course, there's the code.
2 points generally:-
1. If you have ever been contracted for 'important' code you often see some stringent requests for redundancy and error checking.
Specifications for format, documentation, code behaviour and subsequent testing can be excruciatingly tight.
Even so, there have been some high-profile cockups.
2. Code sitting on firmware means more 'variables' in the unreliability equation.
It doesn't neccessarily mean failure per se but, as all these things are statistical, then it increases the odds of a failure.
I'm sure that for a few thousand quid someone can make a nice kevlar/ceramic shield for your device
You can see that, in general, it's not just the micro that has to be of a certain spec. , it's the whole thing.
A "mil-spec" micro isn't indestructable or totally reliable if the rest of the circuit is pants.
And then, of course, there's the code.
2 points generally:-
1. If you have ever been contracted for 'important' code you often see some stringent requests for redundancy and error checking.
Specifications for format, documentation, code behaviour and subsequent testing can be excruciatingly tight.
Even so, there have been some high-profile cockups.
2. Code sitting on firmware means more 'variables' in the unreliability equation.
It doesn't neccessarily mean failure per se but, as all these things are statistical, then it increases the odds of a failure.
I'm sure that for a few thousand quid someone can make a nice kevlar/ceramic shield for your device
slimplynth
Senior Member
http://hackaday.com/2010/05/18/modern-car-data-systems-lack-security/#comments
The bit about being able to lock one brake disc seems a bit worrying.. guessing the designers never had cause to think that someone would come along in 10 or 20 years and be able to hack their system. (must be how they got princess di)
The bit about being able to lock one brake disc seems a bit worrying.. guessing the designers never had cause to think that someone would come along in 10 or 20 years and be able to hack their system. (must be how they got princess di)
Yes, but is it true? Or just bar-room talk?
Always keep your pot of salt nearby ready to take a pinch
After all, wouldn't it be sensible for police to be able to remotely disable a car instead of that silly Stinger? The technology to be able to do that has been around for years and I'm sure someone will have thought of it , and maybe prototyped it, before.
(I can't be bothered to search).
Always keep your pot of salt nearby ready to take a pinch
After all, wouldn't it be sensible for police to be able to remotely disable a car instead of that silly Stinger? The technology to be able to do that has been around for years and I'm sure someone will have thought of it , and maybe prototyped it, before.
(I can't be bothered to search).
slimplynth
Senior Member
I agree, well i don't have any salt as still laying bed but I definitely agree about the police. Often wondered... it's a legal requirement to have lights, tyres... why not add an Rx engine slow down/shut-down unit to that list - my niece's quad has a wireless engine kill.
We recently had a soldier in Blackburn who narrowly escaped losing his licence because of his job. Think he'd got up to 140 ish before the chase ended.
In his defence, they could have put the flashing lights on their unmarked car much sooner. He naturally assumed someone (not the police) was chasing him
edit: http://www.lancashiretelegraph.co.uk/news/8121789.Blackburn_soldier_driving_at_143mph_escapes_ban_as_he___s_off_to_Afghanistan/
We recently had a soldier in Blackburn who narrowly escaped losing his licence because of his job. Think he'd got up to 140 ish before the chase ended.
In his defence, they could have put the flashing lights on their unmarked car much sooner. He naturally assumed someone (not the police) was chasing him
edit: http://www.lancashiretelegraph.co.uk/news/8121789.Blackburn_soldier_driving_at_143mph_escapes_ban_as_he___s_off_to_Afghanistan/
Last edited:
An example comes to mind re what can happen with software issues.
http://www.ccnr.org/fatal_dose.html
It is not only the hardware that needs to be fully tested but the software on it as well.
Marcwolf
http://www.ccnr.org/fatal_dose.html
It is not only the hardware that needs to be fully tested but the software on it as well.
Marcwolf
hippy
Ex-Staff (retired)
And to add to Marcwolf's and Dippy's earlier comment, it's not only hardware and software that needs testing and can fail, but the firmware and libraries that software uses, and the hardware within the chip and any microcode there. If any part cannot be guaranteed then nothing which builds upon it can be.
Some bugs, hardware, firmware or software, may be obvious and get picked up quickly, some are obvious but take time to be revealed, but there will be many which only occur under very specific circumstances, hard to reproduce and hard to test. Even with the best intent it's not possible to test all combinations of everything.
It's that inability to say 'hand on heart, this is 100% guaranteed safe' which brings about the "not recommended for safety critical system" and most things fall into that category.
Some bugs, hardware, firmware or software, may be obvious and get picked up quickly, some are obvious but take time to be revealed, but there will be many which only occur under very specific circumstances, hard to reproduce and hard to test. Even with the best intent it's not possible to test all combinations of everything.
It's that inability to say 'hand on heart, this is 100% guaranteed safe' which brings about the "not recommended for safety critical system" and most things fall into that category.
BeanieBots
Moderator
Hippy has hit the nail on head in post #19.
As an Engineer designing a safety circuit, it is the Engineer's responsibility to PROVE all failure mechanisms and the consequences of those failures.
If that Engineer does not know what a compiler or interpreter does to his code, he cannot KNOW how safe it is.
Equally, on the hardware aspect, if the internal architecture (at a detailed level) is not known, nor can the failure mechanisms.
Micros can and are used in safety critical systems but they are done in close collaboration with the micro manufacturer.
"I built ten and they ran OK for years" doesn't count for anything in a safety circuit.
You must clearly demonstrate that it is safe by design.
As an Engineer designing a safety circuit, it is the Engineer's responsibility to PROVE all failure mechanisms and the consequences of those failures.
If that Engineer does not know what a compiler or interpreter does to his code, he cannot KNOW how safe it is.
Equally, on the hardware aspect, if the internal architecture (at a detailed level) is not known, nor can the failure mechanisms.
Micros can and are used in safety critical systems but they are done in close collaboration with the micro manufacturer.
"I built ten and they ran OK for years" doesn't count for anything in a safety circuit.
You must clearly demonstrate that it is safe by design.
Last edited:
fritz42_male
Senior Member
They can already - did you not watch that factual program called 'Knightrider'?Yes, but is it true? Or just bar-room talk?
Always keep your pot of salt nearby ready to take a pinch
After all, wouldn't it be sensible for police to be able to remotely disable a car instead of that silly Stinger? The technology to be able to do that has been around for years and I'm sure someone will have thought of it , and maybe prototyped it, before.
(I can't be bothered to search).
Incidentally, over 30 years ago I did some college work experience with a company called Siliconix - our mil spec testing of the FETs we made included firing them out of a compressed air tube at a metal plate!