# ESL0007 - Function traceability¶

Field | Value |
---|---|

Author(s) |
T. Wilschut |

Reviewer(s) |
A.T. Hofkamp, T.J.L. Schuijbroek |

Status |
Final |

Type |
Standard (S) |

Created |
21-03-2020 |

Finalized |
t.b.d. |

Warning

This LEP's syntax enhancement is written using an EBNF syntax as opposed to the current PEG syntax since it was finalized before the switch.

## Abstract¶

This LEP introduces new mathematics to derive traceability dependencies from ESL specifications to support functional traceability and completeness checks. The goal- and transformation-specifications domains are merged into a single function domain. Transformation specifications are assigned a set of sub-functions composed of chains of goal- and transformation-specifications that describe functional dependency paths between the input and output variables of the parent transformation.

## Motivation¶

In the literature, one can find many works focused on functional modelling in
engineering^{1}^{2}. A frequently encountered goal in functional
modelling is achieving functional traceability and completeness. That is, enable engineers to trace
how top level system functions are achieved by functions of system sub-components. This traceability
is required to be able to verify whether the system will actually fulfil the all desired top-level
functions.

In this LEP, we aim to extend and improve the functional traceability features of ESL such that ESL better aligns with current systems engineering practice. Moreover, by doing so we aim to increase the usability and consistency of the derived dependency network between goal- and transformation specifications and allow for the introduction completeness rules.

## Rationale¶

Currently, ESL supports goal-specification (function) migration as described by *Crilly et
al.*^{1}. That is, goal-specifications that are formulated at decomposition level
\(k\) automatically migrate to decomposition level \(k' > k\) if the subject or indirect object
(component) of a goal-specification is decomposed. This feature supports function traceability.

Traceability of transformation-specifications (functions) is, however, not fully supported since transformation-specifications do not automatically migrate through the system specification. While adding more detail while decomposing a component, a transformation function is realized by a chain of goal and transformation functions at a more detailed level, but the latter are not formally linked to the former higher level transformation.

In essence, a transformation-specification \(t\) specified at level \(k\) is an abstraction of the chain of goal- and transformation-specifications specified at level \(k' > k\). In graph terms, transformation-specification \(t\) is the parent of all the goal- and transformation-specifications with the chains that describe the transformation of input variables \(V_t\) to output variables \(V_t'\). Thus, ESL can support the derivations of traceability dependencies to support functional traceability. In general, a transformation-specification may have multiple goal- and transformation specifications as children.

The introduction of function traceability has two consequences. First of all, the goal-and transformation domains should no longer be treated as separate domains. Goals and transformations should be considered different types of function within the function domain. This is required to ensure that a consistent traceability network is obtained. Since all elements within a such a network to be part of the same domain (dogs cannot have cats as children).

Secondly, goal-specifications should only have indirect dependencies via one or more transformation-specifications. Otherwise, 'bypasses' occur in the network of function dependencies. Such bypasses are problematic when performing sequence analysis.

### Example function chain¶

```
flowchart LR
c -->|g| x
subgraph c'
direction LR
x(x)
y(y)
z(z)
x -->|t| y
y -->|t'| z
end
z --> c''
```

For example, this figure shows an example function chain of goal-specification \(g\) that states that component \(c\) must provide flow \(x\) to component \(c'\), transformation-specification \(t\) that states that component \(c'\) must transform flow \(x\) into flow \(y\), transformation-specification \(t'\) that states that component \(c'\) must transform flow \(y\) into flow \(z\) and goal-specification \(g'\) that states that component \(c'\) must provide flow \(z\) to component \(c''\). This specification defines the function chain \(g \rightarrow t \rightarrow t' \rightarrow g'\). A direct dependency between \(g\) and \(g'\) would bypass transformation \(t\) and \(t'\). Such bypasses clutter sequence analysis results and are therefore undesired.

In summary, ESL can support the derivation of traceability dependencies without the need for any syntactical changes by merging the goal- and transformation specification domains into a single function domain and changing the dependency derivation rules.

## Specification¶

In this section, first the derivations rules to compute the set of children of transformation specifications are presented. Secondly, modifications to the dependency derivation rules for goal-specification dependencies, transformations-specification dependencies, goal-transformation dependencies, and functional dependencies between variables are introduced. As a reference to the nomenclature please see the Dependency derivation section of the ESL reference manual. Here only a subset of the nomenclature is explained.

In the remainder of this section, \(\mathcal{G}\) is the set of all goal-specifications and \(\mathcal{T}\) is the set of all transformation-specifications and \(\mathcal{C}\) is the set of all components over an instantiated ESL specification. An arbitrary, transformation specification is given by:

where \(c_t \in \mathcal{T}\) is the subject component, \(V_t\) is the set of input variables, \(V_t'\) is the set of output variables, and \(S_t\) is the set of subclauses of \(t\).

A component is given by:

where \(V_c\) is the set of variables, \(N_c\) is the set of needs, \(C_c\) is the set of components, \(G_c\) is the set of goal-specifications, \(T_c\) is the set of transformation specifications, \(D_c\) is the set of design specifications, and \(R_c\) is the set of relations instantiated within the body of \(c\).

### Traceability dependencies¶

Let \(\mathcal{F}=\mathcal{T} \cup \mathcal{G}\) be the set of all transformation-and goal-specifications over an instantiated ESL specification. The children of transformation-specification \(t \in \mathcal{T}\), denoted \(F(t) \subset \mathcal{F}\), have to be part of a function chain starting with an input variable \(v_i \in V_t\) and ending at an output variable \(v_j \in V_t'\). The set of all variables that are part of a path starting at an input variable \(v_i \in V_t\) and ending at an an output variable \(v_j \in V_t'\) over the scope of subject component \(c_t\) is given by:

where \(path(v_i, v_j, c_t)\) is defined in the Dependency derivation section.

\(V(v_i, v_j, c_t)\) is used to compute the set of children of transformation functions \(F(t) \subset \mathcal{F}\). The set of children of an arbitrary transformation specification \(t\) is given by:

That is, a transformation specification \(t'\) is a child of transformation specification \(t\) if the subject component \(c_t'\) is a child of subject component \(c_t\), there exists a path from input variable \(v_i\) to output variable \(v_j\) over the scope of \(c_t\) such the the intersection of the set of input variables \(V_{t'}\) and the set of path variables \(V(v_i, v_j, c_t)\) and the intersection of output variables \(V_{t'}'\) and the set of path variables \(V(v_i, v_j, c_t)\) are non empty sets. In other words, \(t'\) is a child of transformation specification \(t\) if it is part of the function chain describing the transformation of an input variable \(v_i\) to an output variable \(v_j\).

A goal-specification \(g\) is a child of transformation-specification \(t\) if the subject component \(c_g\) and indirect object component \(c_g'\) are children of subject component \(c_t\) and the intersection of the set of goal variables \(V_g\) with \(V(v_i, v_j, c_t)\) is a non empty set. In other words, if one or more variables in \(V_g\) are path of an input-output path.

#### Example function chain for traceability dependencies¶

Goal- and transformation-specifications can be part of multiple function chains describing multiple parent transformations. For example, the figure below shows two transformations \(t_i\) and \(t_j\) with subject component \(c\) describing transformations from \(x\) to \(y\) and \(x\) to \(z\), respectively.

```
flowchart LR
subgraph c
direction LR
x((x))
y((y))
z((z))
q((q))
x --> x'
q' --> q
q --> q''
q --> q'''
y'' --> y
z''' --> z
subgraph c'
direction LR
x'((x))
q'((q))
x' -.->|t'| q'
end
subgraph c''
direction LR
q''((q))
y''((y))
q'' -.->|t''| y''
end
subgraph c'''
direction LR
q'''((q))
z'''((z))
q''' -.->|t'''| z'''
end
x -.->|t<sub>i</sub>| y
x -.->|t<sub>j</sub>| z
end
```

The three transformations \(t'\), \(t''\), and \(t'''\), where \(c_{t'}, c_{t''}, c_{t'''} \in C_c\), describe these transformations in more detail. \(t'\) describes a transformation from \(x\) to \(q\), \(t''\) describes a transformation from \(q\) to \(y\), and \(t'''\) describes a transformation from \(q\) to \(z\). So, \(t'\), \(t''\), and \(t'''\) describe the two transformation paths \(x \rightarrow q \rightarrow y\) and \(x \rightarrow q \rightarrow z\). As such, \(t' \in F(t_i)\) and \(t' \in F(t_j)\) both hold.

Therefore, \(t'\) has two parent functions (\(t_i\) and \(t_j\)) as it contributes to the fulfillment of both of these functions. In other words, the function hierarchies form directed acyclic graphs rather than tree structures as often used in the literature.

### Dependencies between functions¶

The introduction of traceability dependencies requires the modification of the derivation rules for dependencies between goal- and transformation specifications, as discussed in the the Rationale section.

Currently, separate sets of goal-function dependencies (\(E_\mathrm{g}\)), transformation-specification dependencies (\(E_\mathrm{t}\)), and goal-transformation mapping relations (\(M_\mathrm{gt}\)) are derived. This LEP proposes to replace these sets by a single set of function dependencies (\(E_\mathrm{f}\)), which is given by:

That is, transformation-specification \(t_j\) depends on transformation-specification \(t_i\) if the intersection of output variable set \(V_{t_i}'\) and input variable set \(V_{t_j}\) \(t_j\) is a non-empty set. Note that, no direct goal-specification dependencies \((g_i, g_j)\) are derived to avoid bypasses.

A goal-specification \(g\) depends on transformation-specification \(t\) if the intersection of output variable set \(V_t'\) with variable set \(V_g\) is not empty.

Similarly, transformation specification \(t\) depends on goal-specification \(g\) if the intersection of variable set \(V_g\) with input variable set \(V_t\) is not empty.

These new dependency derivations rules imply that only transformation-specifications that share the same subject component can have direct dependencies. Transformation-specifications that do not have the same subject component can only have indirect dependencies via goal-specifications. Goal-specifications can only have indirect dependencies via transformation-specifications.

As a consequence, a user must specify transformation functions at all decomposition levels to obtain complete function chains and traceability network. This differs from the current convention of only specifying transformation-specifications within leaf components (\(\{ c \mid C_c = \emptyset \}\)). This is a price we are willing to pay as it provides functional traceability and allows for completeness checks. Completeness checks are further discussed in the next section.

### Functional dependencies between variables¶

The rules for deriving the traceability dependencies make use of the \(path(v_i, v_j, c)\) function that searches for dependency paths starting at variable \(v_i\) and ending at \(v_j\) over the scope of component \(c\). To find these paths the set of functional dependencies between variables \(E_\mathrm{v_f}\) is required.

In the Rationale section, we argued that dependencies 'bypasses' are undesired in the function domain. These are equally undesired in the variable domain. In fact, dependency bypasses in the variable domain will by definition yield dependency bypasses in the function domain. Therefore, the dependency derivation rules for \(E_\mathrm{v_f}\) are modified as well, \(E_\mathrm{v_f}\) is now given by:

That is, variable \(v_j\) depends on variable \(v_i\) if \(v_i\) is a member of input variable set \(V_t\), \(v_j\) is a member of output variable set \(V_t'\), and the set of child component \(C_{c_t}\) is an empty set. In other words, only transformations of leaf components (those with no sub-components) are used to derive the functional dependencies between variables.

An additional advantage of the modifications of these derivation rules is that the set \(E_\mathrm{v_f}\) can be used to check the functional completeness of a specification. For example, assume we have a transformation specification \(t = (c_t, V_t, V_t', S_t)\) for which \(C_{c_t} \neq \emptyset\) then \(t\) is traceable if \(path(v_i, v_j, c_t) \neq \emptyset \ \forall v_i \in V_t, v_j \in V_t'\). That is, the transformations specified within leaf components of the tree with root \(c_t\) should describe a transformation path for all input variables \(v_i \in V_t\) to all output variables \(v_j \in V_t'\). The non-existence of such a path implies that the transformation \(t\) that should be fulfilled by \(c_t\) is not traceable to the subcomponents of \(c_t\). Thus, the specification is incomplete.

## Backwards Compatibility¶

This LEP does not require any syntactical changes to ESL. Therefore, no compatibility issues are expected at the input side of the compiler. However, as the dependency derivation rules are modified, different dependency networks may be derived. This especially holds for goal-specifications, as they no longer have direct dependencies. These direct dependencies, however, could be reconstructed by analyzing the dependency paths via transformation specifications.

## Proof of concept¶

In this section the proof of concept is shown using a small example specification of a pumping
system. The specification is shown in the listing below. Using this example we first of all aim to
show the derivation of function chains at the first and second decomposition level. Secondly, we aim
to show how transformation requirement `dm-convert-power-potential`

(line 48) of component
`drive-mechanism`

can be traced down to transformation `ba-convert-potential`

(line 78) of component
`power-supply`

, goal `ps-provide-power`

(line 60) and transformation `bm-convert-power`

(line 69) of
component `electric-motor`

.

The two figures below show two component - function specification multi-domain matrices. The function specification parts contains both transformation and goal function specifications.

The first figure shows the component - function specification MDM at decomposition level 1. At this
level the specifications contains two component: `drive-mechanism`

and `pump`

. These components must
fulfil three functions as shown in the component - function mapping matrix. From the function DSM
one can identify the function-chain `dm-convert-power-potential`

\(\rightarrow\) `dm-provide-torque`

\(\rightarrow\) `cp-convert-torque`

, which denotes to conversion of chemical energy into
mechanical-energy (torque), the transfer of mechanical-energy, and finally the conversion of
mechanical energy into a water flow.

The second figure shows the component - function specification MDM at decomposition level 2. Here
the component `drive-mechanism`

is decomposed into the sub-components `power-supply`

and
`electric-motor`

. Note that within the function specification DSM the transformation
`dm-convert-power-potential`

has been replaced bij the transformation `ba-convert-potential`

of
component `power-supply`

, goal `ps-provide-power`

and transformation `bm-convert-power`

of
`electric-motor`

.

One can now identify the function chain `ba-convert-potential`

\(\rightarrow\) `ps-provide-power`

\(\rightarrow\) `bm-convert-power`

\(\rightarrow\) `dm-provide-torque`

\(\rightarrow\)
`cp-convert-torque`

. This chain denotes a longer function chain that starts at `power-supply`

and
ends at `pump`

.

To make the replacement of transformation functions specified at level \(i\) by goal and
transformation functions at level \(i+1\) traceable, *traceability dependencies* are added to the
graph.

The figure below shows the traceability dependencies between
the function specs part of the example specification. Within the matrix one can indeed see that
transformation specification `dm-convert-power-potential`

to functions `ba-convert-potential`

,
`ps-provide-power`

, and `bm-convert-power`

.

## Rejected ideas¶

No ideas were rejected.

## Open issues¶

The following open issues are identified:

### Visualization of dependencies between variables¶

Dependency set \(E_\mathrm{v_f}\) only contains functional dependencies between variables derived from leaf transformations. When visualizing a multi-domain-matrix at an arbitrary decomposition level \(k < k_\mathrm{max}\), where \(k_\mathrm{max}\) is the maximum depth of the component decomposition tree, not all variables are displayed. As such, abstraction of edges is required in order to obtain a consistent dependency network between variables at all decomposition levels.