ISO26262’s HW Evaluation talks about 3 Classes of HW Components – Class I, II or III. There are 3 attributes we must use to determine this Class. Once we identify the Class, we need to evaluate them accordingly. At a first glance, this approach sounds simple and straight forward.
However, when we read deeper, we realize that the ISO Standard is ambiguous in describing how to determine HW Classes. While it does give 3 attributes, it does not mention how to correlate them. This makes it difficult to conclude how to classify some of the HW elements, especially the medium and high complexity HW ICs.
In this blog, we have shared our 2 cents on HW classification of Class II and Class III elements.
HW elements are classified based on 3 attributes:
- Complexity
- Ease of Identification of failure modes and
- Availability of Safety mechanisms
Based on these 3 attributes, Class of a HW element is identified as shown below.
Can you see the gap in the above table? It does not define how to correlate the 3 attributes. Is it an “AND” or “OR” condition between the three?
For example,
(COMPLEXITY=HIGH) AND (IDENTIFYING FAILURES MODES=DIFFICULT) AND (INBUILT SAFETY MECHANISMS=YES) => Class III?
Or
(COMPLEXITY=HIGH) OR (IDENTIFYING FAILURES MODES=DIFFICULT) OR (INBUILT SAFETY MECHANISMS=YES) => Class III?
There are several passive HW elements that satisfy all the Class I conditions (COMPLEXITY = LOW AND IDENTIFYING FAILURE MODES = EASY AND INBUILT SAFETY MECHANISMS = NO).
However, if we have a Medium Complex HW element that has inbuilt Safety mechanisms, is it Class II or III? If we have a highly complex HW element that has no inbuilt Safety mechanisms, is it Class III or Class II?
Let us take for example, an Automotive LED Driver that is used for Interior or Exterior lighting or for backlighting such as the popular ones from ROHM or TI. These can be categorized as Medium Complexity components because these are not as complex as Microcontrollers or DSPs. However, since LEDs are a crucial element for the Safety of a vehicle, there are many ECUs that have Safety goals for LEDs. Hence, LED Drivers provide many safety mechanisms to detect hardware failures of the LEDs connected to it (such as Open/Short faults, poor dimming etc). They also provide safety mechanisms to detect the internal faults of the LED Driver IC that may lead to not correctly indicating the LED. This is a classic example of COMPLEXITY=MEDIUM, IDENTIFYING FAILURE MODES=MEDIUM and INBUILT SAFETY MECHANISMS=YES. Now, should we categorize this LED Driver as Class II or Class III?
We can argue it in both ways. We can argue that it is a Class II component since it has a Medium complexity and hence, it is possible to cover the Systematic failures of the LED driver sufficiently via analysis and testing (as per Class II HW Evaluation). We may also argue that it must considered equivalent to Class III since it provides Safety mechanisms that are used in the Safety concept of the System that uses the LED Driver, and hence the device must be developed in compliance to ASIL. Which is the correct argument?
Let’s take another example of a NAND Flash device. NAND Flash devices have a controller for memory management and implement several techniques such as advanced wear-leveling, overprovisioning and firmware algorithms to increase NAND endurance. Undoubtedly, it is an extremely complex HW component. This is a classic example of COMPLEXITY=HIGH, IDENTIFYING FAILURE MODES=HIGH. Should we treat it as a Class III component, irrespective of whether it has inbuilt Safety mechanisms or not?
Here are our 2 cents on this topic:
- Any component that needs to be programmed atleast once must be treated as a Class III component. For example, a PMIC with OTP Memory.
- In cases of ambiguity, the same HW Component brainstormed in two different groups may be classified differently, as we described with our above example of LED Driver. Instead of looking for one single “right” answer, it is better to figure out what is the right classification for our System, depending upon various factors such as the Safety analysis of the system or the impact on the Safety goals if the Safety mechanisms do not work correctly.
- Any HW Component of high complexity that is crucial to the System’s Safety concept must be treated as Class III. If an ASIL decomposition can be applied in the System to decompose the component as QM(ASIL level), then it is not required to be ASIL compliant. If not, it must be ASIL compliant, and Tier 1s must demand ASIL compliant components from Suppliers even if the market does not have any.
- Even though additional methods of HW Evaluation such as confidence on field performance of the component are only required for Class III, they can also be used for Class II evaluation if the Component has been in operation for many years and the Supplier is willing to provide data on the field performance of the component.
The Class II or Class III classification may not be black and white in the Standard. However, what is more important is to understand the bigger purpose of this classification. The key question that a Safety Manager must ask is “How do I argue in my safety case that I have sufficiently covered the systematic failures of all the HW components of my System?”
How do you think we can prove this? Is it required and is it realistic to develop a HW evaluation plan, strategy and verification report for every Class II and Class III component of the program, as the ISO26262 states? We would love to hear your thoughts!