SPRY348A October 2023 – March 2024 RM57L843

Two attributes of functional safety system design

Functional safety standards assume that all systems will fail (not a matter of if, just a matter of when), and there is no such thing as zero risk.

The two attributes of a functional safety system design are developing a system to deliver an intended function and developing the same system to meet a safety function such as a certain SIL or automotive SIL (ASIL).

Designers often approach the two aspects disparately, or serially. Designing functionally safe systems for high-volume applications while preserving design budget requirements is challenging. Table 1 outlines examples of intended functions and safety functions in control and drive applications.

To better explain this concept, look at the elevator motor example in Table 1.

The intended function of the elevator is to move people up and down based on user input. If you push a button to get to the fifth floor, the elevator should take you there.

The safety functions of the elevator take it a step further, and could include:

Taking you smoothly from floor to floor.
Stopping in level with the landing on each floor.
Applying the brake automatically if the elevator exceeds a safe speed.

Table 1 Intended and safety function examples in control and drive applications.

Functional safety application	Intended function example	Safety function example (and corresponding SIL or ASIL target)
Industrial: elevator motor	Move elevator up and down in response to user requests	Start or stop elevator safely (avoid jerks) (SIL 2) Apply automatic braking if elevator is traveling too fast (SIL 3)
Automotive: electric vehicle (EV) traction motor	Move EV forward and backward per driver command through accelerator or brake	Prevent insufficient or excess torque at acceleration (ASIL C) Prevent braking too hard (to avoid being rear-ended) (ASIL D)
Industrial: steel press	Control servo-drive system that operates a steel press without lowering factory productivity	Safe-torque-off (STO) de-energizes drive controller if over torque or over speed occurs (SIL 3) Safe-limited-speed (SLS) keeps motor speed within acceptable limits if operator is close (SIL 2) Trigger STO if SLS exceeds a bounds check (to balance between productivity and safety that drives a higher SIL, for example, SIL-3)

To better understand how intended functions and safety functions work together, assume that the elevator in a building with 20 floors has a push-button circuit (see Figure 1) with a fault the elevator motor controller interprets as sending the elevator to the 25th or 30th floor (that is, floors that don’t exist in the building). A bounds check would catch the fault before it results in an error, or eventually, a failure. This is the accepted progression in functional safety: “faults” lead to “errors,” while some errors can lead to “failures.”

Figure 1 Example of a modern elevator push button.

Let's review the processes for an intended function design and a safety function design.

In the intended function design process for a motor drive, a systems engineer selects a microcontroller (MCU) to meet requirements of the intended function. Subsequently, they allocate sense capability, such as integrated analog-to-digital converter (ADC) channels to monitor rotor position, line current, phase voltage and system temperature. The systems engineer then proceeds to use the available processing capabilities of the MCU, such as its CPU’s million instructions per second (MIPS) to run the motor-control algorithm, and available actuation peripherals such as pulse-width modulators (PWMs) to drive the motor-driver circuits. This process typically takes several months and also involves designing a printed circuit board (PCB), developing the motor-control algorithms, and developing and debugging all of the embedded software.

In organizations where a separate, somewhat siloed team handles the safety function design process, a separate functional safety expert comes along and reviews the functional safety manual for the MCU that the system engineer originally chose. In some cases, the functional safety expert may discover that the safety-element-out-of-context (SEooC) safety concept calls for the use of SW test of function including error tests, hardware redundancy, a digital-to-analog converter (DAC)-to-ADC loopback check, or monitoring the enhanced PWM through enhanced capture. Recalling the earlier elevator example, it may be necessary to use multiple ADC channels to monitor the level sensor on each floor to protect against a “stuck-at” fault in the MCU’s ADC.

If there are insufficient ADC and PWM channels or insufficient CPU MIPS to achieve functional safety, it may be necessary to go back to the drawing board and select a different MCU to realize the functionally safe system – potentially undoing the work completed so far by that separate systems design team.

Even if the design steps do not happen serially, they frequently happen in separate organizational silos; that is, the systems engineer typically does not have any functional safety expertise, and the functional safety expert is not a systems engineer. This siloed approach ultimately results in the same issues: increased system costs and months of time-to-market delays.