Print page

Email page

Functional safety concepts in motor control

ControlDesign.com

Keywords: Functional safety, machine safety, embedded software, machine control, programmable control, electromechanical and safety systems

Functional safety of embedded software-dependent controls is becoming a growing concern as programmable components replace traditional electromechanical components in safety-related systems.

WHILE MANY debate academic concerns regarding software complexity and reliability, it is clear that the motor control industry is capitalizing on the flexibility and low apparent cost of using embedded software. When this embedded software impacts the functional safety of the embedded system, risk must be managed with due diligence and in accordance with current industry practice or state-of-the-art.

Since consensus standards represent current accepted practice and a baseline for state-of-the-art, they provide a good framework to direct risk management activities. While some fundamental philosophical differences might exist among these emerging standards, there also are many similarities that demonstrate the universality of the present approach to software verification and validation activities (V&V) for the functional safety of motor control systems.

Understand Risk
While the word “risk” has many connotations depending on its technical, legal, social, or philosophical context, it is a concept that we all address every day. Risk is, for many, the motivating force behind conscious or subconscious decision-making. Understanding risk and the tools available to manage it can be invaluable to engineers striving for reliable, robust, and cost-effective designs.

Risk is the combination of the severity and probability of an event (hazard) that has the potential to negatively impact people, assets, potential assets, or the environment [1]. While software risks theoretically can be segregated as technical risks and business risks [2], these two domains frequently overlap when considering issues such as delayed market entry due to emergence of technical hazards (for example, undetected software anomalies) during the development process.

The scope of this article focuses on operational risk, with respect to the functional safety of embedded system software.

The Standards
In this context, functional safety is defined in IEC 61508, the standard for Functional Safety of Electrical/Electronic/Programmable Electronic Safety-Related Systems, as “part of the overall safety relating to the EUC [equipment under control] and the EUC control system which depends on the correct functioning of the E/E/PE [electrical/electronic/programmable electronic] safety-related systems, other technology safety-related system and external risk reduction facilities.”

UL/IEC 60730, the standard for Automatic Electrical Controls for Household and Similar Use, refers to the same concept through the definition of a “protective control” as a “control, the operation of which is intended to prevent a hazardous situation during abnormal operation of the equipment.” This standard also requires that control functions be classified as either Type 1 or Type 2 action.

Type 1 action controls perform functions in which deviation and drift of control parameters will not introduce a hazard to either the component (control) or the system (end-product where the control is installed). By contrast, Type 2 action controls have control parameters with critical deviation and drift characteristics, so exceeding design constraints such as limits or tolerances could result in a risk.

So, when evaluating functional safety, it’s crucial to properly identify the critical control parameters and understand the related component and system-level failure modes. Existing end product industry-consensus standards might help identify these safety-related parameters.

Availability vs. Reliability
One of the most significant differences between UL/IEC 60730 and IEC 61508 is whether the system can be designed to “fail safe” or “fail operational.”

UL/IEC 60730 allows consideration of fail-safe design, with the possibility to immediately shut down the operation. IEC 61508 provides mechanisms for ensuring increasing levels of operational integrity of the safety function, depending on the established Safety Integrity Level (SIL). The SIL is a discrete level--one out of a possible four--for specifying the safety integrity requirements of the safety functions to be allocated to the E/E/PE safety-related systems. SIL 4 has the highest level of safety integrity; SIL 1 has the lowest.

IEC 61508 uses this SIL concept to prescribe software and electronic design considerations that can satisfy the SIL requirements. UL/IEC 60730 is not a standalone document. It is made up of a Part 1 with general requirements, which for many application domains, are referenced by Part 2s, i.e, particular requirements for those specific application domains. With this structure, UL/IEC 60730 relies on the system requirements prescribed in the relevant end-product standards to establish operational characteristics such as response times, functional availability, and tolerances that often are under the control of the embedded software. Reliability of this software typically is one of the most important facets of assessing control system functional safety. Reliability can be considered “the probability that a system or product will accomplish its designated mission in a satisfactory manner” [7]. Thus, while software can be validated at particular instants in time, the verification activities can positively influence the stochastic aspects of system reliability over time.

Analysis Choices
Possibly the most important software verification activity for functional safety design is risk analysis. Due to the highly subjective nature of what constitutes acceptable levels of risk, neither UL/IEC 60730 nor IEC 61508 mandate specific methods for risk analysis.