DID FinderBack
Source
DI-SESS-82426

Model-Based Engineering Failure Modes, Effects, and Criticality Analysis Profile (SysML Version)

Prescribes the failure modes, effects, and criticality analysis (FMECA) data elements and design views to be captured in a digital system model, including a SysML profile example, so FMECA data can be interactively delivered to the program office.

Approval DateOctober 30, 2023
AMSC NumberN10444
Preparing ActivityAS
Project NumberSESS-2023-041
OPR—
DTIC ApplicableYes
GIDEP ApplicableYes
Limitation—
Applicable Forms—
Approval Limitation—
Form Version—
DID Formatfree_text
963C CompliantYes
DISTRIBUTION STATEMENT A: Approved for public release; distribution is unlimited.
Supersedes
—
Related
—

Description & Purpose

—

Application & Interrelationship

—

Use & Relationship

The failure modes, effects, and criticality analysis (FMECA) is a foundational reliability and maintainability (R&M) engineering design activity implemented during the design and development of a product or system. The FMECA identifies potential failure modes for independent single-item or functional failures, as well as the resulting effects on mission success, performance, safety, reliability, and maintainability. The FMECA, when performed early in the design process, allows for the implementation of appropriate corrective actions needed to eliminate Severity I and II failure modes or control risks associated with each remaining failure mode. Controlling critical failures can improve operational readiness and reduce life cycle cost.

This Systems Modeling Language (SysML) profile supports the move from static document delivery in this DID to interactive model delivery of FMECA data to allow FMECA data to be dynamically provided to the program office and other users allowing quicker engagement, decreasing design cycle times, and increasing design influence. This enables reliability and other engineering functions to continuously exchange information to identify and eliminate or control failure modes throughout a system's life cycle and apply the information as a basis for detecting and isolating faults, determining operator and maintainer actions, and identifying test requirements. The MBE approach allows engineers to interrogate the design to address the design views in Table 1. Figure 1 is an example implementation using a SysML profile.

This profile contains standard data elements needed to generate MBE FMECA design views as required by the specific and discrete tasks described in the solicitation (contract statement of work). The selection of required design views should be tailored appropriately by selecting only those views in Table 1 needed for the program.

This Data Item Description (DID) contains the format, content, and intended use information for the data product resulting from the work task described in the contract SOW.

To be considered compliant, with this DID, it is encouraged to use SysML to add and manage the data elements listed in this DID and report the design views with the properties described in this DID. This does not mean that it is required to use the accompanying MBE FMECA Profile; however, it can be used as an out-of-the-box tool to allow a team to easily be compliant with this DID.

This DID is intended to prescribe the FMECA data elements that need to be captured for a system and define the Design Views, or the format that the data should be reported back in. The SysML Profile is intended to be an out of the box SysML tool to assist in this DID compliance by:

- Allowing the capture of the prescribed data elements through the use of a FMECA stereotype and tags

- Allowing the compilation of those data elements into the required design views by using generic tables

While the provided MBSE FMECA Profile will assist in compliance, with this DID, it is not required to be used. The MBSE Team is welcome to modify the provided FMECA Profile or create their own, provided that it captures the DID Data Elements and Design Views.

Further instructions for how to implement, model, and customize the accompanying SysML Profile can be found in the model itself.

Preparation Instructions

1Reference Documents
1.1Integrated ProcessThe FMECA process shall be integrated within the digital system model. The Digital System Model shall represent the functions described in the system specification requirements as elements of the model.
1.2Model InterrogationThe MBE approach shall provide methods and access for the government to interrogate the digital system model to view data elements and their relationships per the pre-defined design views in Table 1. The interrogation shall have the ability to query, filter, or sort by:
1.2.1Data Elemente.g., A1, A4, B2, F3.
1.2.2Design View or Design View Subcategorye.g., 1.3, 2.1, 2.3, 6.4.
1.2.3MetachainCombination of data elements not defined in Table 1 Design Views.
2FormatThe FMECA shall be delivered in the native file format(s) of the modeling tool(s) or developed directly in the Integrated Digital Data Environment (IDDE) as identified in the Contractor's Systems Engineering Management Plan. The FMECA shall include documentation regarding necessary software tool(s) configurations, access types (e.g., readonly or write access), dashboards, views, data integrations, data flows, reporting mechanisms outside of dashboards (e.g., report building tools), security, size, and configuration management details.
3ContentThe design views and associated data elements provided in Table 1, document the relationship of the FMECA to the SysML model, digital engineering artifacts, and R&M engineering analyses, as required by the contract statement of work.
3.1The FMECA shall state how it isincorporated into the Digital System Model.
3.2The FMECA shall state how flowsare analyzed.
3.3Functional TraceabilityThe Digital System Model shall contain a traceability matrix demonstrating that all functions requested in the specification requirements are covered.
3.4FlowsThe FMECA data shall be linked to model elements of the Digital System Model representing power flows between LRUs; fluid flows (e.g., fuel, cooling) between LRUs; internal communications flows between software components; external communications flows between the system and other systems or actors in the system context; and other signal flows such as relay closures, synchronization clock signals, and similar flows between line replaceable units and/or software components.
3.5Data elements
3.5.1Item Function
3.5.1.1A1 - Identification NumberSerial number, Logistics Control Number (LCN) or other reference designation identification number is assigned for traceability purposes.
3.5.1.2A2 - Item Identification NomenclatureThe name or nomenclature of the item or system function being analyzed for failure mode and effects.
3.5.1.3A3 - FunctionA concise statement of the performance required by the function of the item including any performance standards.
3.5.1.4A4 - Function Failure DescriptionWays an item can either partially (with upper and/or lower performance limits) or totally fail to perform its functions.
3.5.1.4.1Incorrect DispositionThe item is not in a state that bears the desired function when the function is called.
3.5.1.4.2Interrupted Change of DispositionThe item exited from state such that it can no longer physically complete the desired function.
3.5.1.4.3PerformanceThe item was in and remained in proper state and physically performed the desired function, but some quality of the function's execution did not meet performance.
3.5.2Failure Modes and Effects
3.5.2.1B1 - Failure ModesFrom the data entity perspective, the description of the relational difference between the desired condition and the predicted failed condition pointing from desired to fail. For incorrect disposition type failures, this will point between two operational states. For interrupted disposition type failures, this will point from operational to failed states. For performance failures, this will point from predicted (failed) performance to performance requirement (e.g., open, short, low torque, loss of power, etc.).
3.5.2.2B2 - Failure CausesIdentification and description of the root cause(s) of the failure modes. The model should include process models that lead to a failure mode. Root cause is the point of deviation that leads to the failure mode (e.g., failure mechanism such as fracture, fatigue, corrosion, spalling, etc.).
3.5.2.3B3 - Operational/Mission PhaseDescription of the required higher-level process within which the failure may occur. Performed for all mission profile(s), under worst-case conditions.
3.5.2.4B4 - Operational Mode/StateDescription of the operational state of an item defined by a set of functions.
3.5.2.5B5 - Failure EffectsPerformance effects that identify the impact of a failure mode on the operation and function of a linked item.
3.5.3Failure Detection and Isolation
3.5.3.1C1 - Failure SignaturesUnique set of characteristics that will support detection and isolation of the failure.
3.5.3.2C2 - Failure Detection MethodDescription of the methods by which occurrence of the failure mode is detected by the operator or maintainer at the system level.
3.5.3.3C3 - Isolation ProcedureDescription of the most direct procedure that allows a maintainer to isolate the malfunction or failure. Describes the method by which ambiguities are resolved when more than one failure mode causes the same failure indication. Identifies to what indenture level failures can be isolated by the use of BIT features and indicate when ancillary test equipment will be required for failure isolation.
3.5.4Compensating Provisions
3.5.4.1D1 - Compensating Provisions (Design / Operator)Compensating provisions, either design provisions or operator actions, that circumvent or mitigate the effect of the failure.
3.5.4.2D2 - ProtectionProtective or preventative measures to prevent the failure effect from occurring.
3.5.4.3D3 - MitigationMitigation of the end effect.
3.5.4.4D4 - Protective CommentsExplanation of the protective measure or documentation of uncertainty.
3.5.4.5D5 - Implemented ByThe system feature, component, or instructions that allow the operator to implement the compensating provisions.
3.5.5Intermediate Interactions
3.5.5.1E1 - Intermediate EffectsIdentification of each of the effects (secondary failures) as the primary failure propagates through the system until its end effect.
3.5.5.2E2 - Intermediate CausesThe failure causes associated with each of the intermediate effects.
3.5.5.3E3 - Intermediate ItemsIdentification of each item along the failure's path of propagation through the system until its end effect.
3.5.5.4E4 - Intermediate DetectionsList of all detection mechanisms other than the primary and end effect detections along the propagation path.
3.5.5.5E5 - Intermediate ProtectionsList of all protection measures other than the primary and end effect protection measures along the propagation path.
3.5.5.6E6 - Intermediate MitigationsList of all mitigations other than the primary and end effect mitigations along the propagation path.
3.5.5.7E7 - Intermediate CommentsExplanation or uncertainties on the intermediate detections, mitigations, or protections.
3.5.6End Effects
3.5.6.1F1 - End EffectsEnd effects used to evaluate and identify the total performance effect of a failure on the mission and the surrounding environment.
3.5.6.2F2 - End CauseThe cause of the failure at the end item.
3.5.6.3F3 - End ItemThe item at which the failure propagation terminates.
3.5.7Severity
3.5.7.1G1 - Severity ClassificationCategories (I-IV) assigned to each failure mode, without considering compensating provisions, according to the failure effect at the uppermost system. The severity classification categories are:
3.5.7.1.1Category I - CatastrophicA failure that may cause death or system loss (i.e., aircraft, tank, missile, ship)
3.5.7.1.2Category II - CriticalA failure that may cause severe injury, major property damage, or major system damage that will result in mission loss.
3.5.7.1.3Category III - MarginalA failure that may cause minor injury, minor property damage, or minor system damage that will result in delay or loss of availability or mission degradation.
3.5.7.1.4Category IV - MinorA failure not serious enough to cause injury, property damage, or system damage, but will result in unscheduled maintenance or repair.
3.5.7.2G2 - Severity CommentExplanation or uncertainty in determining the severity.
3.5.7.3G3 - Unmitigated Severity ClassificationCategories (I-IV) assigned to each failure mode, without the consideration of any compensating provisions, according to the failure effect at the uppermost system.
3.5.8Maintenance Actions
3.5.8.1H1 - Basic Corrective Maintenance ActionsThe basic actions taken by the maintainer to correct the failure (e.g., remove and replace LRU)
3.5.8.2H2 - Basic Preventative Maintenance ActionsThe basic actions taken by the maintainer to prevent the failure (e.g., oil change).
3.5.9Design Remarks
3.5.9.1I1 - RemarksAny pertinent remarks or contractor's rationale pertaining to and clarifying any other columns or recommendations for design improvements.
3.5.10FMEA/FMECA Data
3.5.10.1J1 - Failure ProbabilityAssessment of failure modes in terms of probability of occurrence (Levels A-E):
3.5.10.1.1Level A - FrequentHigh probability of occurrence, which may be defined as a single failure mode probability greater than or equal to 10^-1 of the overall probability of failure during the operating time interval.
3.5.10.1.2Level B - Reasonably probableReasonable probability of occurrence, which may be defined as a single failure mode probability of occurrence that is more than 10^-2 but less than 10^-1 of the overall probability of failure during the item operating time.
3.5.10.1.3Level C - OccasionalOccasional probability of occurrence, which may be defined as a single failure mode probability of occurrence that is more than 10^-3 but less than 10^-2 of the overall probability of failure during the item operating time.
3.5.10.1.4Level D - RemoteRemote probability of occurrence, which may be defined as a single failure mode probability of occurrence that is more than 10^-6 but less than 10^-3 of the overall probability of failure during the item operating time.
3.5.10.1.5Level E - Extremely unlikelyExtremely unlikely, which may be defined as a single failure mode probability of occurrence that is less than 10^-6 of the overall probability of failure during the item operating time.
3.5.10.2J2 - Failure Rate Data SourceWhen failure rate data are to be used in the calculation of criticality numbers (item W), the data source of the failure rates used in each calculation. When a failure probability is listed, the remaining items J3-J6 are not required.
3.5.10.3J3 - Failure Effect Probability (Beta)The conditional probability that the failure effect will result in the identified criticality classification, given that the failure mode occurs. The values represent the analyst's judgment as to the conditional probability the loss will occur and should be quantified in accordance with the following:
3.5.10.3.1Actual Loss= 1.0
3.5.10.3.2Probable Loss> 0.10 to < 1.0
3.5.10.3.3Possible Loss> 0 to = 0.10
3.5.10.3.4No Effect= 0
3.5.10.4J4 - Failure Mode Ratio (Alpha)The fraction of the part failure rate related to the particular failure mode under consideration.
3.5.10.5J5 - Failure Rate (Lambda)The failure rate from the appropriate reliability prediction.
3.5.10.6J6 - Operating Time (t)The operating time of the item per mission derived from the government-approved operational concept or System Requirements Specifications.
3.5.10.7J7 - Failure Mode Criticality Number [cm = (Beta Alpha Lambda t)]A relative measure of consequence of a failure mode and its frequency of occurrence.
3.5.10.8J8 - Item Criticality Number [cr = sum of (Beta Alpha Lambda t)]A relative measure of consequence of an item failure and its frequency of occurrence.
3.5.11Design Actions Taken
3.5.11.1K1 - FMEA Prevention ActionDescription of how a potential cause resulting in a given failure mode is mitigated using existing and planned activities.
3.5.11.2K2 - FMEA Detection ActionThe simulations or tests available to detect that the potential failure mode during the manufacturing or production process.
3.5.11.3K3 - Responsible OrganizationOrganization responsible for corrective action.
3.5.11.4K4 - Target Completion DateDate corrective action is due.
3.5.11.5K5 - StatusCurrent status of corrective action development.
3.5.11.6K6 - Actions Taken with Reference to EvidenceDescription of the corrective action and evidence that it was effective.
3.5.12SchemaExample of how to apply data element stereotypes to capture system FMECA data (Figure 1).

References

—

Figures

Figure Table 1: Design Views

Figure Table 1. Design Views

Figure 1: Example of Schema for Application of SysML Profile

Figure 1. Example of Schema for Application of SysML Profile

Schema v3.0Community-maintained · Verify against ASSIST
Community-maintained — not an official government database.
Verify against ASSIST·GitHub·About·Disclaimer