Skip to content

Behavior requirements

You can specify all static behavior using goal, transformation, and design requirements. That is, the workings or capabilities of a system that are (desired to be) present at all times. Specifying dynamic behavior requires an additional construct. Enter behavior-requirements.

Let's review an example that we added to the ElectricalDriveMechanism definition that describes the amount power that should go from the power-source to the motor depending on whether the motor-control-signal is turned on:

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
define component ElectricalDriveMechanism
  variables
    power-potential is an EnergyPotential
    power is an ElectricalEnergyFlow
    torque is a MechanicalEnergyFlow
    motor-control-signal is a ControlSignal

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

  behavior-requirements
    toggle-power:
      case on:
        when
          * c1: motor-control-signal is equal to True [-]
        then
          * r1: power must be at least 300 [W]
      case off:
        when no other case applies
        then
          * r2: power must be equal to 0 [W]

  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
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
73
74
75
76
77
78
79
80
81
82
83
84
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
  ControlSignal is a boolean


define verb
  provide to
  convert into


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]

  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

# ---8<--- [start:highlight]
define component ElectricalDriveMechanism
  variables
    power-potential is an EnergyPotential
    power is an ElectricalEnergyFlow
    torque is a MechanicalEnergyFlow
    motor-control-signal is a ControlSignal

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

  behavior-requirements
    toggle-power:
      case on:
        when
          * c1: motor-control-signal is equal to True [-]
        then
          * r1: power must be at least 300 [W]
      case off:
        when no other case applies
        then
          * r2: power must be equal to 0 [W]

  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
# ---8<--- [end:highlight]


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

When this hold, then that should, too

We specified a goal-requirement before for the ElectricalDriveMechanism that states that power must be provided to the motor. Using the behavior-requirement toggle-power, we specify which values this power should assume under different circumstances or a set of caseclauses. It requires that it must be at least300 [W]when the conditions for caseon are satisfied (motor-control-signal is true).

Note

Note how all when and then clauses are all design rules that we just introduced!

When no other case applies

Furthermore, it includes a fallback case off using the when no other case applies sequence, stating it must then be 0 [W].

What behaviors are not

Even though behavior requirements describe different states (cases) for variables to be in, they don't form a full behavior model as their starting states, transitions, and other mathematics are missing. What you can do, is accurately describe how a variable should respond to stimuli (other variables).

For complete supervisory controllers/automata-models/PLC-code that include starting states, (un-)controlled transitions and more, you should look elsewhere. ESL is not meant to replace such tools, but rather provide them with a accurately documented starting point of the "things that should always hold".

Tip

We can highly recommend taking a look at CIF by Eclipse ESCET™. Another language that was conceived at the Eindhoven University of Technology and now part of Eclipse that enables you to declaratively model your system and supervisory controller by means of automata and generate guaranteed-to-be-correct PLC code right from your model. Simulation batteries included.

Next!

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