# US 11,030,034 B2 · Quantitative software failure mode and effects analysis > Agents: this data is available as JSON from the patentgrep API and MCP server — see https://patentgrep.com/llms.txt - Number: US 11,030,034 B2 - Document ID: US11030034B2 - Status: Granted - Kind: B2 - Application number: 16/267,612 - Filed: 2019-02-05 - Published: 2019-08-01 - Granted: 2021-06-08 - Earliest claimed: 2019-02-05 - Assignees: Intel Corporation - Applicants: Intel Corporation - Inventors: Rigels Gordani; Luca Fogli; Francesco Pingitore; Giovanni Satori - Web page: https://patentgrep.com/patent/US11030034B2 ## CPC - G06F 11/079: {Root cause analysis, i.e. error or fault diagnosis (in a hardware test environment G06F11/22; in a software test environment G06F11/36)} - G06F 11/0751: {Error or fault detection not based on redundancy (power supply failures G06F1/30; network fault management H04L41/06)} - G06F 11/0754: {by exceeding limits} - G06F 11/0769: {Readable error formats, e.g. cross-platform generic formats, human understandable formats} - G06F 11/0793: {Remedial or corrective actions (recovery from an exception in an instruction pipeline G06F9/3861; by retry G06F11/1402; for recovering from a failure of a protocol instance or entity H04L69/40)} - G06F: ELECTRIC DIGITAL DATA PROCESSING (computer systems based on specific computational models G06N) ## Abstract Systems and methods may be used to perform a software failure mode and effects analysis (SW FMEA) for a software component. The SW FMEA may include a quantitative approach, for example based on a risk priority number for the software component. The risk priority number may be based on a severity of a failure in the software component, an occurrence likelihood of a failure in the software component, or a detectability of a failure in the software component. A safety integrity level may be determined for the software component based on the risk priority number. ## Claims ### Claim 1 A control device for performing a software failure mode and effects analysis (SW FMEA) comprising: a processor; memory, including instructions, which when executed by the processor, cause the processor to: receive threshold values for safety integrity levels for a software component within a system; monitor the software component, wherein to monitor the software component includes to monitor an interaction between the software component and at least one of: a second component or a subcomponent; determine, based at least in part on a result of the monitoring of the software component, a preliminary risk priority number for the software component, the risk priority number based on a ranking of a possibility of failure of the software component, the ranking determined by a severity, an occurrence likelihood, and a detectability of a failure of the software component; compare the preliminary risk priority number to the threshold values to identify a preliminary safety integrity level corresponding to the software component; and output the preliminary safety integrity level; apply a mitigation to the system for the software component, wherein the mitigation is at least one of: improving a code in at least one of: the software component, the second component, or the subcomponent, swapping at least a portion of at least one of: the software component, the second component or the subcomponent, rewriting at least a portion of: the software component, the second component or the subcomponent, or changing an interaction between the software component and at least one of the second component or the subcomponent; and a display device to present, on a user interface, the preliminary safety integrity level. ### Claim 2 (depends on 1) The control device of claim 1, wherein the instructions further cause the processor to: determine an updated risk priority number; and output an updated preliminary safety integrity level based on the updated risk priority number. ### Claim 3 (depends on 2) The control device of claim 2, wherein the occurrence likelihood and the detectability change in response to the mitigation while the severity remains constant. ### Claim 4 (depends on 2) The control device of claim 2, wherein the instructions that cause the processor to apply the mitigation include instructions that cause the processor to suggest a control measure, a detection measure, or a prevention measure including a corresponding effectiveness of implementing the respective measure; and wherein the display is further configured to present the respective measure and the corresponding effectiveness. ### Claim 5 (depends on 1) The control device of claim 1, wherein the preliminary risk priority number is a mathematical product of the severity, the occurrence likelihood, and the detectability. ### Claim 6 (depends on 5) The control device of claim 5, wherein the severity and the occurrence likelihood are integers between 1 and 10 inclusive, and the detectability is an integer between 1 and 3 inclusive. ### Claim 7 (depends on 1) The control device of claim 1, wherein the instructions that cause the processor to determine the preliminary risk priority number include instructions that cause the processor to determine whether the software component is periodic, and wherein when the software component is not periodic, the preliminary risk priority number is lower than when the software component is periodic. ### Claim 8 (depends on 1) The control device of claim 1, wherein the preliminary safety integrity level is a safety integrity level (SIL) according to an International Electrotechnical Commission (IEC) 61508 standard or an automotive safety integrity level (ASIL) according to an International Organization for Standardization (ISO) 26262 standard. ### Claim 9 (depends on 1) The control device of claim 1, wherein the instructions further cause the processor to: determine the severity based on a failure mode type and function operability of the software component; determine the occurrence likelihood based on a predicted frequency of failure of the software component during operation; and determine the detectability based on a likelihood of identifying an error and whether the error is likely to be identified before or after the error occurs. ### Claim 10 At least one non-transitory machine-readable medium including instructions for performing a software failure mode and effects analysis (SW FMEA), which when executed by a machine, cause the machine to: receive threshold values for safety integrity levels for a software component within a system; monitor the software component, wherein to monitor the software component includes to monitor an interaction between the software component and at least one of: a second component or a subcomponent; determine, based at least in part on a result of the monitoring of the software component, a preliminary risk priority number for the software component, the risk priority number based on a ranking of a possibility of failure of the software component, the ranking determined by a severity, an occurrence likelihood, and a detectability of a failure of the software component; compare the preliminary risk priority number to the threshold values to identify a preliminary safety integrity level corresponding to the software component; apply a mitigation to the system for the software component, wherein the mitigation is at least one of: improving a code in at least one of: the software component, the second component, or the subcomponent, swapping at least a portion of at least one of: the software component, the second component or the subcomponent, rewriting at least a portion of: the software component, the second component or the subcomponent, or changing an interaction between the software component and at least one of the second component or the subcomponent; and output the preliminary safety integrity level for display. ### Claim 11 (depends on 10) The at least one machine-readable medium of claim 10, wherein the instructions further cause the machine to: determine an updated risk priority number, based on the applied mitigation; and output an updated preliminary safety integrity level based on the updated risk priority number. ### Claim 12 (depends on 11) The at least one machine-readable medium of claim 11, wherein the occurrence likelihood and the detectability change in response to the mitigation while the severity remains constant. ### Claim 13 (depends on 11) The at least one machine-readable medium of claim 11, wherein the instructions that cause the machine to apply the mitigation include instructions that cause the machine to suggest a control measure, a detection measure, or a prevention measure including a corresponding effectiveness of implementing the respective measure; and wherein the display is further configured to present the respective measure and the corresponding effectiveness. ### Claim 14 (depends on 10) The at least one machine-readable medium of claim 10, wherein the preliminary risk priority number is a mathematical product of the severity, the occurrence likelihood, and the detectability. ### Claim 15 (depends on 14) The at least one machine-readable medium of claim 14, wherein the severity and the occurrence likelihood are integers between 1 and 10 inclusive, and the detectability is an integer between 1 and 3 inclusive. ### Claim 16 (depends on 10) The at least one machine-readable medium of claim 10, wherein the instructions that cause the machine to determine the preliminary risk priority number include instructions that cause the machine to determine whether the software component is periodic, and wherein when the software component is not periodic, the preliminary risk priority number is lower than when the software component is periodic. ### Claim 17 (depends on 10) The at least one machine-readable medium of claim 10, wherein the preliminary safety integrity level is a safety integrity level (SIL) according to an International Electrotechnical Commission (IEC) 61508 standard or an automotive safety integrity level (ASIL) according to an International Organization for Standardization (ISO) 26262 standard. ### Claim 18 (depends on 10) The at least one machine-readable medium of claim 10, wherein the instructions further cause the machine to: determine the severity based on a failure mode type and function operability of the software component; determine the occurrence likelihood based on a predicted frequency of failure of the software component during operation; and determine the detectability based on a likelihood of identifying an error and whether the error is likely to be identified before or after the error occurs. ### Claim 19 A method for performing a software failure mode and effects analysis (SW FMEA) comprising: receiving, at a processor, threshold values for safety integrity levels for a software component within a system; monitoring the software component, wherein monitoring the software component includes to monitor an interaction between the software component and at least one of: a second component or a subcomponent; determining, based at least in part on a result of the monitoring of the software component, using the processor, a preliminary risk priority number for the software component, the risk priority number based on a ranking of a possibility of a failure of the software component, the ranking determined by a severity, an occurrence likelihood, and a detectability of a failure of the software component; comparing the preliminary risk priority number to the threshold values to identify a preliminary safety integrity level corresponding to the software component; applying a mitigation to the system for the software component, wherein the mitigation is at least one of: improving a code in at least one of: the software component, the second component, or the subcomponent, swapping at least a portion of at least one of: the software component, the second component or the subcomponent, rewriting at least a portion of: the software component, the second component or the subcomponent, or changing an interaction between the software component and at least one of the second component or the subcomponent; and outputting the preliminary safety integrity level for display. ### Claim 20 (depends on 19) The method of claim 19, further comprising: determining an updated risk priority number, based on the applied mitigation; and outputting an updated preliminary safety integrity level based on the updated risk priority number. ### Claim 21 (depends on 20) The method of claim 20, wherein the occurrence likelihood and the detectability change in response to the mitigation while the severity remains constant. ### Claim 22 (depends on 19) The method of claim 19, wherein determining the preliminary risk priority number includes determining whether the software component is periodic, and wherein when the software component is not periodic, the preliminary risk priority number is lower than when the software component is periodic. ### Claim 23 (depends on 19) The method of claim 19, wherein the preliminary safety integrity level is a safety integrity level (SIL) according to an International Electrotechnical Commission (IEC) 61508 standard or an automotive safety integrity level (ASIL) according to an International Organization for Standardization (ISO) 26262 standard. ### Claim 24 (depends on 19) The method of claim 19, further comprising: determining the severity based on a failure mode type and function operability of the software component; determining the occurrence likelihood based on a predicted frequency of failure of the software component during operation; and determining the detectability based on a likelihood of identifying an error and whether the error is likely to be identified before or after the error occurs.