ESL0007  Function traceability¶
LEP 
ESL0007 
Author(s) 

Reviewer(s) 
A.T. Hofkamp, T.J.L. Schuijbroek 
Status 
Accepted 
Type 
Standard (S) 
Created 
21032020 
Finalized 
t.b.d. 
Abstract¶
This LEP introduces new mathematics to derive traceability dependencies from ESL specifications to support functional traceability and completeness checks. The goal and transformationspecifications domains are merged into a single function domain. Transformation specifications are assigned a set of subfunctions composed of chains of goal and transformationspecifications 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. See for example, [Cri13] and [SEG17]. 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 subcomponents. This traceability is required to be able to verify whether the system will actually fulfil the all desired toplevel 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 goalspecification (function) migration as described by [Cri13]. That is, goalspecifications that are formulated at decomposition level \(k\) automatically migrate to decomposition level \(k' > k\) if the subject or indirect object (component) of a goalspecification is decomposed. This feature supports function traceability.
Traceability of transformationspecifications (functions) is, however, not fully supported since transformationspecifications 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 transformationspecification \(t\) specified at level \(k\) is an abstraction of the chain of goal and transformationspecifications specified at level \(k' > k\). In graph terms, transformationspecification \(t\) is the parent of all the goal and transformationspecifications 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 transformationspecification 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, goalspecifications should only have indirect dependencies via one or more transformationspecifications. Otherwise, ‘bypasses’ occur in the network of function dependencies. Such bypasses are problematic when performing sequence analysis.
For example, Figure 8 shows an example function chain of goalspecification \(g\) that states that component \(c\) must provide flow \(x\) to component \(c'\), transformationspecification \(t\) that states that component \(c'\) must transform flow \(x\) into flow \(y\), transformationspecification \(t'\) that states that component \(c'\) must transform flow \(y\) into flow \(z\) and goalspecification \(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 goalspecification dependencies, transformationsspecification dependencies, goaltransformation dependencies, and functional dependencies between variables are introduced. As a reference to the nomenclature please see the Dependency derivations 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 goalspecifications and \(\mathcal{T}\) is the set of all transformationspecifications 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 goalspecifications, \(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 goalspecifications over an instantiated ESL specification. The children of transformationspecification \(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 derivations 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 goalspecification \(g\) is a child of transformationspecification \(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 inputoutput path.
Note that goal and transformationspecifications can be part of multiple function chains describing multiple parent transformations. For example, Figure 9 shows two transformations \(t_i\) and \(t_j\) with subject component \(c\) describing transformations from \(x\) to \(y\) and \(x\) to \(z\), respectively.
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 goalfunction dependencies (\(E_\mathrm{g}\)), transformationspecification dependencies (\(E_\mathrm{t}\)), and goaltransformation 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, transformationspecification \(t_j\) depends on transformationspecification \(t_i\) if the intersection of output variable set \(V_{t_i}'\) and input variable set \(V_{t_j}\) \(t_j\) is a nonempty set. Note that, no direct goalspecification dependencies \((g_i, g_j)\) are derived to avoid bypasses.
A goalspecification \(g\) depends on transformationspecification \(t\) if the intersection of output variable set \(V_t'\) with variable set \(V_g\) is not empty.
Similarly, transformation specification \(t\) depends on goalspecification \(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 transformationspecifications that share the same subject component can have direct dependencies. Transformationspecifications that do not have the same subject component can only have indirect dependencies via goalspecifications. Goalspecifications can only have indirect dependencies via transformationspecifications.
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 transformationspecifications 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 subcomponents) 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 nonexistence 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 goalspecifications, 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
dmconvertpowerpotential
(line 48) of component drivemechanism
can be
traced down to transformation baconvertpotential
(line 78) of component
powersupply
, goal psprovidepower
(line 60) and transformation
bmconvertpower
(line 69) of component electricmotor
.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78  # Specification of a drivemechanism driving a pump.
define type
mechanicalenergyflow is a real
electricalenergyflow is a real
liquidmaterialflow is a real
chemicalenergyflow is a real
define verb
provide to
convert into
world
variables
torque is a mechanicalenergyflow
waterflow is a liquidmaterialflow
components
pump is a CentrifugalPump with arguments
* torque
* waterflow
drivemechanism is an ElectricalDriveMechanism with arguments
* torque
goalrequirement
dmprovidetorque: drivemechanism must provide torque to pump
define component CentrifugalPump
parameters
torque is a mechanicalenergyflow
waterflow is a liquidmaterialflow
transformationrequirements
cpconverttorque: must convert torque into waterflow
define component ElectricalDriveMechanism
parameters
torque is a mechanicalenergyflow
variables
power is an electricalenergyflow
powerpotential is a chemicalenergyflow
transformationrequirements
dmconvertpowerpotential: must convert powerpotential into torque
components
powersource is a Battery with arguments
* power
* powerpotential
motor is a BrushlessMotor with arguments
* power
* torque
goalrequirement
psprovidepower: powersource must provide power to motor
define component BrushlessMotor
parameters
power is an electricalenergyflow
torque is a mechanicalenergyflow
transformationrequirements
bmconvertpower: must convert power into torque
define component Battery
parameters
powerout is an electricalenergyflow
powerpotential is a chemicalenergyflow
transformationconstraint
baconvertpotential: does convert powerpotential into powerout

Figure 10 and Figure 11 show two component  function specification multidomain matrices. The function specification parts contains both transformation and goal function specifications.
Figure 10 shows the component  function specification MDM at
decomposition level 1. At this level the specifications contains two component:
drivemechanism
and pump
. These components must fulfil three functions as shown
in the component  function mapping matrix. From the function DSM one can identify the
functionchain dmconvertpowerpotential
\(\rightarrow\) dmprovidetorque
\(\rightarrow\) cpconverttorque
, which denotes to conversion of chemical
energy into mechanicalenergy (torque), the transfer of mechanicalenergy, and finally
the conversion of mechanical energy into a water flow.
Figure 11 shows the component  function specification MDM at
decomposition level 2. Here the component drivemechanism
is decomposed into the
subcomponents powersupply
and electricmotor
. Note that within the function
specification DSM the transformation dmconvertpowerpotential
has been replaced
bij the transformation baconvertpotential
of component powersupply
, goal
psprovidepower
and transformation bmconvertpower
of electricmotor
.
One can now identify the function chain baconvertpotential
\(\rightarrow\)
psprovidepower
\(\rightarrow\) bmconvertpower
\(\rightarrow\)
dmprovidetorque
\(\rightarrow\) cpconverttorque
. This chain denotes a
longer function chain that starts at powersupply
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.
Figure 12 shows the traceability dependencies between the function
specs part of the example specification. Within the matrix one can indeed see that
transformation specification dmconvertpowerpotential
to functions
baconvertpotential
, psprovidepower
, and bmconvertpower
.
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 multidomainmatrix 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.
Copyright¶
Copyright is owned by Ratio Computer Aided Systems Engineering B.V.