Ansys medini analyze uses an arithmetic formulas language to compute failure rates coming from failure rate handbooks such as SN29500 and IEC62380. Parameters and mission profiles are mapped to variables in these expressions that are used during failure rate computation. Each variable is identified by a name, has a value and a unit, and is defined at a SysML element. The variables are seen for example in the Prediction tab of the property view for an element.
NOTE [4] — If prediction mode FROM CATALOG is used for an element, the selection wizard from a built-in failure rate catalog will guarantee that all required variables are created at the element. These variables are also not deletable.
The set of variables for an element that is effectively used for the computation of its failure rate is determined including the context of the element. The context is given by the structure of the SysML model. Variables can be marked derived to use a value from the context, for example from a parent element (container) in SysML. The evaluation context for evaluation of failure rates is filled based on the following rules:
Variables defined at the element are always used prior to any other variables (except if marked derived). Note that this rule applies to all variables listed in the variables section of an element, not to variables embedded in a formula (see overwriting rules below).
Variables from container elements are used if variables are not defined or marked derived at an element. The variable lookup works recursively upwards, so that the "nearest" container variable is used.
If an element is typed, all variable values from the instance context are passed to the type. That means if variables are marked as derived at the type, the value from the instance is passed to the type so that each instance might use its own set of variables.
Mission profile variables are inserted (at last) from the containing model into the evaluation context.
NOTE [5] — The inheritance rules work recursively so that variables defined for an instance (potentially inherited from a parent) are passed to its type and further down to nested elements and their types, and so on. This is also true for variables from mission profiles so that the actual values for the instances are used, not the profile defined for a type.
Besides variables automatically added when using FROM CATALOG also user defined variables can be added for multiple purposes:
Scaling expressions can use the set of variables of an element to perform scaling. Therefore custom variables might be used to parameterize such an expression
Variables for nested elements can be added, for example to define a temperature for all contained elements
Variables can be added to overwrite a variable in a formula. For example, if a catalog formula defines a variable "lambda_base = ..." then a custom variable with the same name lambda_base overwrites the predefined expression, taking the value from the explicitly defined variable instead. Note that this is independent of the variable's unit.
RECOMMENDATION [7] — Only make variables available for multiple elements that are added by a catalog selection, since these are usually intended to be shared. Be careful with generic variables such as base failure rates (e.g. "lambda", "lambda_die", etc.) and electrical quantities (e.g. "P", "P_rated", "V_rated", etc.), because these might affect other elements. Use naming schema to guarantee that custom variables are not hiding variables from formulas, for example by introducing a prefix to their names.
WARNING [6] — All variable units are not automatically converted (e.g. mV into V). The failure rate handbooks provide consistent formulas regarding the units, but users need to ensure that inheritance of variables via "derived" are consistent, especially for user defined variables.