This section describes the rationale and design behind safety analyses in medini analyze. It introduces some general definitions which are common through the different safety analyses methods supported by the tool. New users should take the time to read through the following subsections before executing any analysis.
All safety analysis methods in medini analyze are based on (design) models. Here "based on" means that models define structure and behavior of the system to be developed and all safety methods augment these with an analysis of potential failures. Ansys medini analyze supports the SysML modeling language for expressing various aspects of the functional architecture, as well as system design with (physical) structure and behavior.
Failures are in most cases directly attached to model elements, i.e. they are contained inside the model elements and then shown in different analyses such as FTA, FMEA, or FMEDA. Therefore, all analyses provide a consistent view on the failure models. For example, a failure mode "short circuit" of a physical model might appear in an FMEDA as well as an event in a fault tree. If the failure rate of the element/failure mode changes, both analyses will automatically be synchronized, since the data is stored in the underlying model. If models are imported from development tools (e.g. SCADE Architect, IBM Rhapsody), failures are annotated to imported model elements and preserved during update of the models.
Measures are the generic concept in medini analyze to express all means to prevent, detect, control, mitigate or correct failures of a system (in an FMEA, they appear as design controls). In addition, Safety Mechanisms are specific measures that are implemented into systems and that provide a diagnostic coverage (DC) of failures, i.e. they cover a proportion of the failure rate of a failure mode. Some standards call them simply "diagnostics".
We use the term failure as a general classification of all abnormal conditions leading to the inability of that element to perform its required functions (within given requirements). Depending on the model/element under consideration the tool distinguishes further between the following failure types:
Hazard: failure that is considered to be a potential source of harm which is exposed to users of the system. Hazards are usually interpreted in terms of ISO 26262 and IEC 61508, but there is no fixed semantics built into the tool. Nevertheless, they are used as part of the hazard analysis and risk assessment and constitute (part of the) system level effects in an FMEA.
Malfunction: failure in a function of a component, (sub-)system, item, or behavioral model (e.g. process). Malfunctions are mostly a qualitative concept[1] and can have cause/effect relationships to other failures. Malfunctions are used to describe the malfunctioning behavior as defined in the hazard analysis and risk assessment of ISO 26262-3.
Failure mode: (mode of) failure of an element in a design model that might be quantified by means of a failure rate/failure density. In contrast to malfunctions, they are primarily applied to structural and physical models. Failure modes can be permanent and transient and have cause/effect relationships to other failures types.
Error: failures related to software as well as external failures of the system context/operating conditions. Errors are used to express any systematic or random failure that occurs due to wrong production, wrong environment, and/or wrong operation of the system. Errors can have cause/effect relationships to other failures.
These definitions are intended to be as generic as possible and imply only a few limitations in the usage of the tool. For example, malfunctions are contained only in functions/activities/actions, failure modes are contained in all components or parts, and so on.
Beside hazards as top level effects, all other failure types can be freely connected using the cause/effect relationship. This "failure net" can span various design models, hence, analyze supports analysis in a hierarchical manner across different abstraction levels. For example, malfunctions in a system architecture model can be connected to failure modes of a physical (hardware) model as the causes and to hazards of the hazard analysis as effects.
We recommend to setup some modeling guideline that is consistent with the design models created in the system development process. If you need further help or guidance to setup your projects please contact our service team.
[1] The tool can calculated failure rates for malfunctions implicitly via their causes. This might be useful when taking data over into an FTA. However, the primary means of a malfunction is of qualitative nature.