Skip to content

Design requirements

You can use design-requirements to express requirements on the values of variables. These are, for instance, useful if you want to specify a component's size, set a bound on a "flow" variable in or to a component or set bounds on a key performance indicator.

For instance, we can express a minimum required water flow of the pump. Let's look at an example we added to the world definition to embody this:

world.esl
1
2
3
4
5
6
7
world
  variables
    torque is a MechanicalEnergyFlow
    water-flow is a LiquidMaterialFlow

  design-requirements
    min-water-flow: water-flow must be at least 1.0 [L/s]
world.esl
 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
define type
  MechanicalEnergyFlow is a real with unit Nm
  ElectricalEnergyFlow is a real with unit W
  LiquidMaterialFlow is a real with unit L/s
  EnergyPotential is a real with unit Wh


define verbs
  provide to
  convert into


# ---8<--- [start:highlight]
world
  variables
    torque is a MechanicalEnergyFlow
    water-flow is a LiquidMaterialFlow

  design-requirements
    min-water-flow: water-flow must be at least 1.0 [L/s]
# ---8<--- [end:highlight]

  components
    pump is a CentrifugalPump
    drive-mechanism is an ElectricalDriveMechanism

  goal-requirements
    provide-torque: drive-mechanism must provide torque to pump


define component CentrifugalPump
  variables
    torque is a MechanicalEnergyFlow
    water-flow is a LiquidMaterialFlow

  transformation-requirements
    convert-torque: must convert torque into water-flow


define component ElectricalDriveMechanism
  variables
    power-potential is an EnergyPotential
    power is an ElectricalEnergyFlow
    torque is a MechanicalEnergyFlow

  transformation-requirements
    convert-power-potential: must convert power-potential into torque

  components
    motor is a BrushlessMotor
    power-source is a Battery
    power-switch is a Switch

  goal-requirements
    provide-power: power-source must provide power to motor


define component BrushlessMotor
  variables
    power is an ElectricalEnergyFlow
    torque is a MechanicalEnergyFlow

  transformation-requirements
    convert-power: must convert power into torque


define component Battery
  empty


define component Switch
  empty

Note

The unit [L/s] specified to this requirement must match a unit that is associated with its Type definition.

Note

Note that the minimum water flow is not coupled to any specific component at this point. It is only a general statement for now. Tying this requirement to the instance of the pump is explained later on in Parameters and properties.

Design rule

Design requirements are expressed using the design rule syntax, which is re-used in other parts of the specification later on.

A design rule, of which water-flow must be at least 1.0 [L/s] is an example, can be used to express (in)equalities or objectives.

The syntax follows one of:

  1. [subject variable] must be [comparison] [bound variable]
  2. [subject variable] must be [comparison] [value] [[optional unit]]
  3. [subject variable] must be [objective]

Where the first expresses an (in)equality between two variables, the second is used to express an (in)equality for a variable with a value, and the third is to set a design objective for that variable.

Comparison

The [comparison] should be one of:

Comparison Mathematical equivalent
equal to ==
not equal to !=
at least >=
at most <=
greater than >
smaller than <
approximately ~

This logic may be extended using or within a single rule. Adding multiple "and" like statements, however, is usually done by providing them as parallel (separate) requirements, which is equivalent and more readable. Bracketing logic is not supported for the same reason.

Objective

The [objective] may be one of:

  • maximized
  • minimized

Placeholder value

The values that quantify design requirements are often subject to discussion during a design process. The compiler therefore accepts t.b.d. as a valid value for anything, which stands for "to be determined". This indicates that the exact value of a bound within a design rule should be determined at a later point in time.

For example, this is a valid requirement:

1
2
3
4
5
6
7
8
9
define type
  foo is a real with unit bar

world
  variable
    baz is a foo

  design-requirement
    dr1: baz must be at most t.b.d. [bar]  # note, it does have a unit!

Next!

Press next (or N on your keyboard) to head over to the next page! P is for Previous.