When designing functionally safe motor-control applications, should you tackle functional safety compliance at the beginning, as an initial design requirement? Or should you treat functional safety as an add-on feature, incorporated into the final stages of your design?
Functional safety should be part of the initial design requirements – interwoven with the intended functionality of the motor drive. This isn’t the norm, because traditional system design workflows don’t approach safety compliance synergistically. But neglecting to consider how you need to meet safety integrity compliance at the outset can result in costly delays when introducing systems to market.
The onset of Industry 4.0 and the growth of vehicle electrification and connectivity require that we change our approach to functional safety compliance. Simply put, we now have more motor systems in more applications, and a high bar for complying with functional safety standards.
Bharat Rajaram
Systems Engineering Manager
Arm-Based Microcontrollers
1 Defining functional safety compliance | The goal of functional safety standards is to manage and mitigate systematic
faults while also being able to detect and prevent (or, at minimum, render
safe) random hardware failures when they occur. |
2 Two attributes of functional safety system design | Functional safety involves developing systems to deliver an intended
function and to meet a safety integrity level. |
3 The recommended approach to designing functionally safe motor-control and drive systems | System engineers designing functionally safe systems should approach
functional safety compliance at the outset of the design process – not as an
afterthought. |
The goal of functional safety standards such as International Electrotechnical Commission (IEC) 61508 and International Organization for Standardization (ISO) 26262 is to manage and mitigate systematic faults while also being able to detect and prevent (or, at minimum, render safe) random hardware failures when they occur.
The adoption of a rigorous development process with independent verification and validation can help manage for systematic faults.
It is possible to detect, prevent or render safe random hardware failures by:
The pairing of safety mechanisms with each situational hazard then helps designers meet quantitative metrics such as safe failure fraction (SFF) and probability of failures/hour (PFH) as required by IEC 61508. For example, a Safety Integrity Level (SIL) 2 system must have an SFF≥90% and a PFH of ≤1000 failures in time over 1 billion hours of operation.
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:
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 |
|
Automotive: electric vehicle (EV) traction motor | Move EV forward and backward per driver command through accelerator or brake |
|
Industrial: steel press | Control servo-drive system that operates a steel press without lowering factory productivity |
|
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.”
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.