ESL0002  Relation syntax modification¶
LEP 
ESL0002 
Author(s) 

Reviewer(s) 
A.T. Hofkamp, T.J.L. Schuijbroek 
Status 
Accepted 
Type 
Standard (S) 
Created 
24102019 
Finalized 
t.b.d. 
Abstract¶
In this LEP the relation parameter syntax is replaced with an extended form stating the type of each parameter and direction of the data with respect to the relation environment. This introduces specifying inputoutput relations. In addition, the interface of a relation is explicitly defined, which is useful for instantiating a relation as well as improving type checking.
Motivation¶
In engineering design detailed (mathematical) analysis is usually required to ensure that a system will function according to the set requirements. An analysis often consists of defining a mathematical function that requires a set of input arguments and returns a set of output arguments. Based on the values of the input arguments, the values of the output arguments are computed. The values of the output arguments are subsequently (manually) verified against the set requirements.
The current version of ESL contains relations
, which can be used to denote the
existence of a (mathematical) relation between variables. For example, in the listing
below the relation definition newtonssecondlaw
(line 2) is defined. Relation
r1
(line 9) is an instance of newtonssecondlaw
with arguments f
, m
,
and a
.
1 2 3 4 5 6 7 8 9 10  define relation
newtonssecondlaw
world
variables
f, m, a is a real
relation
r1: newtonssecondlaw with arguments
f, m, a

Relation r1
denotes the existence a (mathematical) dependency between variables
f
, m
, and a
, which is described by relation definition
newtonssecondlaw
. The relation definition name newtonssecondlaw
is
considered to be an implicit reference to an external file in which the mathematical
relation is implemented.
The current relation syntax, however, has a few shortcomings. First of all, the expected
type of arguments and the number of arguments of newtonssecondlaw
is not
specified. As such, the compiler cannot verify correct use of a relation.
Secondly, a relation definition could be instantiated multiple times with different numbers of arguments of different types, which could lead to erroneous specifications.
Third of all, relations are considered to be undirected. That is, neither input nor output is specified. In practice, however, many analyses have distinct input and output variables. In the literature, inputoutput relations are often visualized in a parameter dependency structure matrix (DSM). By sequencing a parameter DSM one typically aims to obtain an optimal sequence in which the values of the parameters should be determined to minimize design iterations. Supporting such analysis fits well within the scope of ESL. However, due to the current lack of directionality it cannot be supported.
Hence, in this LEP, we replace the relation syntax with an extended version to enable type checking, to ensure one correctly instantiates relations, and enable one to define directed and undirected relations between variables. The number of parameters of a relations can be defined as a being fixed or arbitrary.
Rationale¶
The amount of information one has one a relation between variables may change during the course of a design project. At the start of a design project, one may only be aware of the existence of a relation. Later, one may obtain additional information that denotes the inputoutput relations. Therefore, the proposed relation syntax allows for the specification of directed and undirected relations. This enables users to convert undirected relations into directed relations during the course of the design project.
For example, the listing below shows an example specification in which two relations are
defined and instantiated following the proposed syntax. At line 2, relation ohmslaw
is defined which requires parameters current
and resistance
as input and returns
parameter voltage
as output. At line 9, relation newtonssecondlaw
is defined
which relates parameters force
, mass
, and acceleration
.
At line 21, ohmslaw
is instantiated as relation r1
which requires arguments
I
and R
and returns argument U
. At line 28, newtonssecondlaw
is
instantiated as relation r2
which relates arguments F
, m
, and a
.
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  define relation
ohmslaw
requiring parameters
current is a real
resistance is a real
returning parameter
voltage is a real
newtonssecondlaw
relating parameters
force is a real
mass is a real
acceleration is a real
world
variables
I, R, U is a real
F, m, a is a real
relation
r1: ohmslaw
requiring arguments
I
R
returning argument
U
r2: newtonssecondlaw
relating arguments
F
m
a

The relations between the parameters of ohmslaw
are directed and follow a clear
inputoutput pattern. The relation between the parameters of newtonssecondlaw
are
undirected. That is, the requiring
keyword indicates that all parameters that follow
are inputs to the relation. The returning
keyword indicates that all parameters that
follow are outputs of the relation. The relating
keyword indicates that one has not
decided whether the parameters that follow are input or output of the relation.
All parameters within relation definitions are assigned a type. The type of each
parameter must match the type of the respective positional argument upon instantiation.
For example, the type of argument a
must be equal to the type of parameter
acceleration
. This mechanism allows for automated type checking. That is, the
compiler can automatically check if all relations are instantiated with the correct
number and correct type of arguments.
So far, the proposed syntax requires the user to define all relation parameters a
priori. However, many mathematical formulas can take an arbitrary number of arguments.
For example, a summation or balance equation. Therefore, the one or more
keywords
are introduced which indicate that a relation requires one or more parameters of a
certain type. For example, in the following listing the relation costsummation
requires one or more cost
arguments as input and returns the variable totalcost
as argument.
1 2 3 4 5 6  define relation
costsummation
requiring parameters
one or more cost is a real
returning parameter
totalcost is a real

Specification¶
In this section the formal syntax and dependency derivation rules are given and discussed.
Syntax ====== The EBNF listing below shows the new syntax for relation definitions and a
relation section. A relationdefinition
starts with the keywords define
relation
followed by a new line. The new line starts with a RELATIONDEFNAME
,
which is the name of the relation definition. On the following lines the input, output
and undirected parameters lists are specified. A parameter list starts with one of the
keywords requiring
, returning
or relating
followed by the keyword
parameter
followed by the respective input, output, or undirected parameter list.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15  relationdefinition ::=
"define" "relation" \n
{ RELATIONDEFNAME \n
{ ( "requiring"  "returning"  "relating" ) "parameter" \n
{ ["one" "or" "more"] PARAMETERNAME "is" ("a"  "an") TYPENAME \n }+
}+ (*At most one requiring, returning and relating.*)
}+
relationsection ::=
"relation" \n
{ RELATIONNAME ":" RELATIONDEFNAME \n
{ ( "requiring"  "returning"  "relating" ) "argument" \n
{ ARGUMENTNAME \n }+
}+ (*At most one requiring, returning and relating.*)
}+

A parameter list consists of one or more lines that start with the optional keywords
one
or
more
, a PARAMETERNAME
followed by the keywords is
a
or
is
an
and a TYPENAME
. A relation definition can have at most one input, one
output, and one undirected parameter list. The order of the parameter lists is
unconstrained.
A relationsection
starts with the keyword relation
and a new line. Next one can
instantiate one or more relations. A relation instantiation starts with a
RELATIONNAME
followed by a :
, a RELATIONDEFNAME
and a new line.
Subsequently, one must specify the input, output, and undirected arguments lists.
Dependency derivations¶
The new syntax imposes a partitioning of the variables used by a relation. Therefore, a relation \(r \in \mathcal{R}\) is given:
where \(V\) is the set of input variables, \(V'\) is the set of output variables and \(V''\) is the set of undirected variables. The partioning requires a reformulation of the set of relation dependencies as well. The set of dependencies between relations \(E_\mathrm{r}\) is given by:
That is, two relations \(r_i\) and \(r_i\) have a dependency if the intersection of the union of the output variables \(V_i'\) and undirected variables \(V_i''\) of relation \(r_i\) with the union of the input variables \(V_j\) and undirected variables \(V_j''\) of relation \(r_j\) is not empty. In other words, if an output or undirected variable of \(r_i\) is an input or undirected variable of \(r_j\), then \(r_j\) depends on \(r_i\). Note that if \(V''\) is empty for all \(r \in \mathcal{R}\) that all relation dependencies become directed.
The set of design dependencies between variables \(E_\mathrm{v_d}\) is affected by the partioning as well. Let \(\mathcal{Q}\) be the set of all design rules. Reformulation of \(E_\mathrm{v_d}\) then yields:
That is, two variables \(v_i\) and \(v_j\) have a dependency if there exists a design rule \((v_i, v_j) \in \mathcal{Q}\) or there exists a relation \(r = (V, V', V'') \in \mathcal{R}\) such that \(v_i\) is a member of the union of the output variables \(V'\) and undirected variables \(V''\) and \(v_j\) is a member of the union of the input variables \(V\) and undirected variables \(V''\) of \(r\). Note that if \(V''\) is empty for all \(r \in \mathcal{R}\) that all dependencies between variables become directed.
To determine the mapping relations between relations and all other ESL elements one can simply use the existing formulas and use \(V_r = V \cup V' \cup V''\) as the set of variables used by a relation \(r\).
Backwards Compatibility¶
This modification will break all existing ESL specifications that contain relation definitions and instantiations. As such, backwards compatibility issues are expected.
The simplest way to resolve these issues is to add relating parameters
and parameter
type information to all relation definitions and to add relating arguments
to all
relation instantiations.
Proof of concept¶
The section will be added once the syntax modifications have been implemented.
Rejected Ideas¶
The following ideas where rejected.
Explicit link to external files¶
The name of a relation definition is considered to be an implicit reference to an external file in which the mathematical relation is implemented. We explored the possibility to add explicit references to external files. However, such references are not stable over time and differ per file system. As such, explicit references may quickly break a specification. Therefore, an external mapping should be created that takes the name of the relation definition, and links it to an external definition chosen by the user.
Open Issues¶
The following open issues are identified.
Format of mapping file¶
In the Rejected Ideas Section, it has been proposed to to create an external mapping file in which relation definition names are mapped to names of external definitions. The format of such files has yet to be designed.
Copyright¶
Copyright is owned by Ratio Computer Aided Systems Engineering B.V.