The failure rate prediction capabilities embedded into the SysML language provide a wide range of modelling options to address diverse use cases. This section describes the recommended modelling practices to be applied for failure rates and the associated single and latent point fault HW metrics (FMEDA) and points out potential pitfalls.

In general, failure rates are modelled in a SysML model and used by either other models or in safety analyses such as FMEDA (DC Worksheets, HW Metrics) or FTA. Whenever changing a failure rate, a parameter to a failure rate (variables, mission profiles), or dependent elements used to compute the failure rate (e.g. percentage of distribution for a failure mode) a recomputation is required to update a project.

The tool internal failure rate unit is FIT (Failure in Time, i.e. 1 failure per 10⁹ hours) and all failure rate values are internally stored in that scale. In the same way, all computations take place in FIT, but the tool UI can convert the values into other units (failures per hours, failure per million hours) depending on the project settings.

NOTE [1]  —  Failure rates might be affected by any model change including update of SysML models from 3rd Party tools, Excel imports, library updates, element deletions, compare and merge, manual changes of variables, failure mode distribution, failure net, and so on.

NOTE [2]  —  Failure rates using mission profiles have a dependency on the mission profile. Whenever the project settings change an assigned mission profile, all models using this mission profile must be recomputed.

RECOMMENDATION [1]  —  Recompute failure rates should be triggered frequently, especially whenever a SysML model is modified to check whether failure rate are affected or computation is broken.

RECOMMENDATION [2]  —  Failure rates shall be recomputed before (1) exporting data from a project, (2) generating a report, and (3) checking a project into a configuration management system, or (4) using any other way to hand over a project to another user.