critical-embedded systems (safety)

I have a question regarding, functional safety in embedded systems.Suppose we have a critical embedded controller which controls the motor speed. How we could deal with wrong inputs from user? I mean, what are the possibilities in hardware or software by which we could detect and mitigate wrong inputs from user?

--------------------------------------- Posted through

formatting link

Reply to
ari.gh
Loading thread data ...

This question has so many dimensions to "it depends" that any meaningful answer has to be really vague, and long to boot.

Basically there has to be a clear and certain definition of what a "wrong input" is, and the definition has to depend only on information that the system has. Then, to complicate your life, the system has to be capable of processing the information. As a silly example, asking it to stop in the presence of loud noise may work, but asking it to stop if someone yells "STOP!" in any human language, past or present, won't.

To complicate things, if you are working within any sort of a regulatory or litigatious environment, you not only need to make the system work, but you have to prove that it will work all the time, and you probably need to not only determine the probability that a wrong user input will fail to be properly mitigated, but the probability that a _correct_ user input will be improperly determined to be "wrong", and the situation made dangerous by the system "mitigating" the "wrong" input.

I've been on the far edges of efforts like this: if you go there, you're going to spend a lot more time on the systems engineering aspects (i.e., determining exactly what makes an input correct or wrong) than you will on either the software or hardware aspects. Then you'll spend even more time yet verifying that you're right.

--
Tim Wescott 
Wescott Design Services 
 Click to see the full signature
Reply to
Tim Wescott

The sensible way to do that is to define valid i/p high and low limits, or valid data, whatever, then reject everything outside that range as an error. It's much more hard work to try and define all possible error cases. All well defined systems should have designed limits of operation, so it should be easy to assume everything else = error. It also makes it much easier to demonstrate that the system works as expected.

On a motor speed controller, you might use a 2 prong approach, rejecting invalid control inputs as well as a second independent loop limiting the output speed range of the controller via a tacho or back emf signal, for example...

Reply to
Chris Quayle

ari.gh schreef op 17-Jul-15 om 4:12 PM:

It is not the controller itself that is critical, but the system that it is part of. Safety should be designed at system level. Subsequently, on the lower levels, safety aspects are just like any other sub-system requirement that must be fulfilled.

So you question of "how to deal with wrong input" (which assumes some definition of "wrong"): as is required by the system design. Which might in practice mean for instance:

- run the motor at full speed

- continue with the last valid input

- engage the emergency brakes

Wouter

Reply to
Wouter van Ooijen

If you are working on a safety critical system, then that is a very fundamental question, the answer to which should pop out from following the processes described in your system development plan. The plan will prescribe a process for first identifying sources of failures and determining the effect of the failure, and result in safety requirements that mitigate the perceived risks. How you implement the safety requirements is then purely a system design issue which nobody can answer for you because they don't know what your system is. Provided you can trace each safety requirement through your complete product lifecycle to a test that proves the safety requirement is being met, you are ok, and it might be that requirements are met by hardware rather than software.

Regards, Richard.

  • formatting link
    Designed for simplicity. More than 113000 downloads in 2014.

  • formatting link
    IoT, Trace, Certification, FAT FS, TCP/IP, Training, and more...

Reply to
FreeRTOS info

First, ask yourself what *you* and your system consider to be "wrong inputs". I.e., if you don't *know* how to recognize them, then how can you expect to design hardware/software that can recognize them?

If the motor is commanded to "GHTEKKKYUOP", is that a "wrong input"?

If the motor is commanded to "Go", is that a "wrong input"? (e.g., how fast? to where? in what manner??)

If the motor is currently stopped and is then abruptly commanded to "move at full speed", is *that* a "wrong input"? I.e., do you expect the user to incrementally increase the commanded speed at some particular maximum rate of change? Likewise, if the motor is commanded to reduce speed at a rate that it can not accommodate (inertial loading)? Or, reverse direction?

If the motor is commanded to move at a speed that exceeds it's capacity (given its current load), is *that* a "wrong input"?

If a motion command is issued at a time when the rest of the mechanism is in a state that prohibits motion, is that a "wrong input"?

If you are controlling some other aspect of the motor's behavior (e.g., torque) and exceed it's limits, rate of change or appropriateness for current mechanism state, is that a "wrong input"?

Software remedies boil down to identifying illegal state transitions for every "current state" (of motor behavior, mechanism, etc.) and inhibiting those commands -- or, converting them to something more predictable (e.g., force any illegal input to be treated as "IMMEDIATE STOP" -- if that makes sense).

The obvious hardware remedies are things like hardware (safety) interlocks: preventing motion when the mechanism is in a state that puts the user or some other asset at risk. Additionally, things like "keys" on connectors to ensure a motor isn't connected to its controls "backwards". Also, heuristics to detect anomalous situations that *should* have been caght by other means (e.g., the "access panel" is open, the hardware interlocks should be preventing the motor from operating! So, why am I seeing "consequences" of motor operation? Has someone *bypassed* an interlock??)

You can implement virtually every software prohibition in a corresponding *hardware* mechanism as well. It's just usually more costly to do so.

Reply to
Don Y

Have you noticed how many times the phrase "system engineering" has come into the conversation so far?

I have NOT read this book, nor do I know anyone who has. But I know the author and in all our exchanges he's shown good judgement so far (except for choosing me to write a chapter in one of his other books -- there's no excuse for that). The title should prove a good starting place for other books if you don't want to get this one:

"Mission-Critical and Safety-Critical Systems Handbook" by Kim Fowler.

This IS, at the least, a book-length subject; if you're working in that market it's not a bad idea to get at least one good book and read it.

--
Tim Wescott 
Wescott Design Services 
 Click to see the full signature
Reply to
Tim Wescott

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.