FailureEvaluation
Engineering conclusion about the sufficiency of safety measures for a Failure, or of the analysis recorded in an Analysis or InterfacePointAnalysis. The shared contract is SafetyAssessment.
This qualitative conclusion applies to software, hardware and systems. Safety measures can include safety mechanisms, architectural controls and applicable prevention or verification activities. A process claim needs evidence explaining how it addresses this failure; merely following a process does not establish sufficiency. Record the reasoning, assumptions, applicable criteria and evidence references in SafetyAssessment.argument. Each applicable software failure needs its own conclusion, even when several failures share supporting measures.
null means no conclusion has been recorded. GAP records an unresolved deficiency. SUFFICIENT and RESIDUAL distinguish adequate measures from a justified remaining uncovered contribution or limitation. Neither asserts zero remaining risk, authorizes a risk waiver, nor exempts the object from other model rules. Numerical Failure.diagnosticCoverage and issue-tracker priorities or action status are separate from this conclusion.
Method references
These publications inform the interpretation; none prescribes this three-value enum or requires a split into adequacy and acceptance enums. The values summarize STIG engineering conclusions, not standardized fault classes.
AIAG & VDA, FMEA Handbook, first edition (2019), §§2.5.3–2.5.5, 2.5.10 and 2.6.3: document prevention/detection controls and their effectiveness; justify adequate existing controls or take action. Action Priority concerns the need for action and does not decrease merely because an action is assigned. Appendix E addresses software in the system context. FMEA Detection Controls (DC) are not diagnostic coverage.
Bosch, Booklet 14: Failure Mode and Effects Analysis (June 2012), §§3.4–3.6: distinguish measures, effectiveness and revised evaluations; responsible persons decide acceptability of remaining risk at FMEA release. This enum does not replace that release decision.
Leveson & Thomas, STPA Handbook (2018), pp. 37–38, 69 and 111–112: analyse the adequacy of safeguards, remaining scenarios, limitations and assumptions. Safeguards do not justify omitting unsafe control actions from the analysis.
Entries
Applicable safety measures sufficiently address the failure for the stated scope and development stage. Measures need not be a local diagnostic mechanism; relevant architectural or process measures can support the conclusion when their applicability and effectiveness are justified. This does not assert 100% diagnostic coverage. At analysis level, it can also record a justified scope decision, such as omitting detailed analysis of a QM interface point or one outside the architected safety functions; it does not claim that omitted work was performed. See InterfacePointAnalysis.belongsToSafetyFunction.
An identified uncovered contribution or limitation remains, with an engineering argument explaining why no further measure is required under the applicable criteria. Reference the containing safety argument when justification depends on aggregate results, such as hardware architectural metrics; a single failure cannot establish those totals. The value also applies to justified system or software limitations, but cannot excuse a missing argument or an unmet safety requirement. It does not itself declare residual risk acceptable.
Properties
Functions
Returns the enum constant of this type with the specified name. The string must match exactly an identifier used to declare an enum constant in this type. (Extraneous whitespace characters are not permitted.)
Returns an array containing the constants of this enum type, in the order they're declared.