All product development includes an assessment of performance, quality and reliability before a product reaches market. This is especially true in the automotive industry, where manufacturers offer warrantees/guarantees based on mileage. The most common tool used by companies for design, system, and process is failure mode effects analysis, or FMEA. However the depth and focus placed on FMEA depends heavily on whether a company is satisfying an auditor’s requirements or whether FMEA is being used as a design tool in ASIC development programs.
In the case of ASIC development, FMEA is an essential tool to examine all aspects of a product specification, including the completeness and potential weaknesses of the technical and economic success of the project. Working with the customer, ASIC providers should also analyze the architecture and device specifications for energy efficiency using the FMEA procedure. In this way, FMEA can be an overall development tool beyond its commonly accepted scope of reliability (design for production) and failure sensitivity (design for test).
Automotive ASICs benefit with FMEA as a design tool
In many projects FMEA is used as a “must-create” mandatory document which includes only the most common entries. Indeed many project teams do not like it because they primarily think about the assessment, which is only a prioritizing step but not the heart of it. But FMEA can do much more. To get the most out of the FMEA concept it should be used at the very beginning of the project, long before starting design tasks.
In fact, the right time to begin FMEA is when technical contact starts with a customer. At this point, system architect and designers should begin gathering the input information for a joint system FMEA. In this phase discussions focus on the key parameters of the customer’s product and their correlation to the electrical functions of the ASIC. In this way, designers immediately get a good feel for what the customer needs and can note the functions immediately in the FMEA tool, not on paper.
Together with the customer ASIC-relevant technical details are determined for the intended functions as well as the environmental influences on the functions, even when they are related to end customer usage; additionally, this phase can uncover something that will be reported as necessary diagnosis functions of the ASIC.
Usually it is very easy to find the things needed for proper functioning. More effort will go into determining how to cover all the possible influences which might prevent the ASIC from doing its job properly, especially when the ASIC is expected to determine if its data are valid or corrupt (detection action), because this is one of the most important tasks for automotive electronics. Also designers can sort out what the ASIC cannot fix or detect without cost-intensive extensions to the first draft of the ASIC requirement specification.
What is the difference between using an FMEA tool or the FMEA methodology idea in comparison to the classical check list approach? It’s simple: Designers can be more complete when translating customer requirements into parameter specifications for the ASIC because the detailed discussion of functions, diagnostics, and possible malfunctions at top level were already completed. The FMEA tool makes them visible regarding functional trees or failure trees, and designers can automatically give them an ID. When a characteristic has an ID it is identified and therefore "visible," and designers can check only visible items for completeness.
Once this is done, the designer can translate the system FMEA outcome to an ASIC parameter specification. This way the ASIC functions and their electrical parameters are captured, along with the unique ID of every specified parameter. The ID is necessary for tracking and also for change management when the requirement specifications are changed.
Breakdown to buildup
From the ASIC functions it is possible to derive the needed building blocks using the work-breakdown structure (WBS) approach. This method can be used to identify the blocks for the design FMEA. In the best case, they correspond closely, or 1:1, to your WBS. Perhaps, however, the specifying individual responsible will define the right WBS level to be used. If well defined, the same blocks will occur in the project plan which gives a very consistent picture of the project without any additional cost. Also this approach covers the automotive SPICE requirement of traceability of parameters and their changes thoughout the project.
Now it is time to start with the design FMEA. The most important and difficult task is to define the scope of the design FMEA. One trap is to be teased to go into too small details and be lost in information. But setting the scope onto the system functions, let’s call them information outputs, to cover all possibilities of electrical and logical signal representations, gives the FMEA a good overall structure.
Adding attributes like power consumption or EMC rules as failure modes to the information outputs, covers energy efficiency and general environmental aspects. Then the center of focus is the main functions of the ASIC which feed the outputs (directly or indirectly via other building blocks). The possible failures of the main functions are directly connected to the failure possibilities of the information outputs.
I also agree with the need for an example. As well I got requests from non-automotive readers to add some general FMEA words which I will do next time.
The idea for power efficiency is to add this as an own category like "design" or "physical" as failure sources / root causes. The effort to add it here is small and it drives the team to discuss all the power related details before starting the design. The outcome will influence the architecture selection of the building blocks. This avoids improvements on designed blocks and the related (re-)design costs.
Join our online Radio Show on Friday 11th July starting at 2:00pm Eastern, when EETimes editor of all things fun and interesting, Max Maxfield, and embedded systems expert, Jack Ganssle, will debate as to just what is, and is not, and embedded system.