Skip to content

Introduction

Modern systems engineering demands precise specification and clear communication of component interactions, behaviors, and requirements. There are many tools available for requirement management, where SysML is the most well-known. SysML is a diagram-based language that visualizes interactions and behaviors of a system. However, ensuring correctness of the model based on the requirements is a demanding and time consuming task. The Elephant Specification Language (ESL) offers a complementary approach to this challenge, through structured textual definitions and correct-by-construction system visualization.

This guide demonstrates how both languages can be used together to enhance system clarity and consistency. Even though ESL is lightly explained in this guide, a basic understanding of ESL is recommended. A more in-depth explanation can be found in the tutorials.

ESL and SysML

The Elephant Specification Language (ESL) is a textual language that allows for the specification of components and their interactions in a system. ESL is based on the concept of components, which are defined using a hierarchy. These components can be decomposed into subcomponents. The interactions between different components can be defined by variables, parameters, and requirements. ESL supports the definition of various types of requirements, such as: goal-, need-, transformation-, design-, and behavioral requirements. ESL provides a specific syntax for defining requirements, enabling automatic linking to components and resulting in a clear and traceable model of the system.

SysML, in constrast, is a diagram-based language used to specify blocks and their interactions within a system. Blocks in SysML correspond to ESL components, where parts, properties, ports and flows capture the internal composition and external interactions of the blocks. The core aspects of SysML are: Behavior diagrams, Structure diagrams, and Requirement diagrams:

  • The structure of the system is defined in a Block Definition Diagram (BDD), which contains blocks that represent the system components. These blocks can be decomposed into subcomponents (also referred to as “parts”) using Internal Block Diagrams (IBD).
  • The behavior of the system is represented using Activity Diagrams. The behavior can be linked to blocks using the allocation relationship.
  • The requirements are specified in Requirement Diagrams and can be linked to other model elements (e.g., blocks, activities, state machines) using the relationships: satisfy, verify, and derive.

sysml_structure

The figure shows the SysML diagram taxonomy. The main pillars of SysML are the behavior, structure, and requirement diagrams.

In the following sections, we will demonstrate the mapping using an example of a pump and drive-mechanism:

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
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
# Specification of a drive-mechanism driving a pump.
define type
  mechanical-energy-flow is a real with unit Nm
  electrical-energy-flow is a real with unit W
  liquid-material-flow is a real with unit L/s
  energy-potential is a real with unit Wh
  control-signal is a boolean
  distance is a real with unit m
  spatial-measure is a distance of at least 0.0 [m]
  efficiency is a real  of at least 0.0 and at most 1.0


define verb
  provide to
  convert into
  send to


define relation
  battery-efficiency-model
    relating parameters
    * potential is an energy-potential
    * output is an electrical-energy-flow


world
  variables
    torque is a mechanical-energy-flow #< Comments on variable torque.
    water-flow is a liquid-material-flow
    drive-length is a spatial-measure
    pump-length is a spatial-measure



  components
    pump is a CentrifugalPump with arguments
      * torque
      * water-flow
      * pump-length

    drive-mechanism is an ElectricalDriveMechanism with arguments
      * torque
      * drive-length



  comments
    pump #< Can be sourced by manufacturer XYZ.
         #< Part number CFG.PMP.0.1


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



  design-requirements
    min-water-flow: water-flow must be at least 1.0 [L/s]



  design-constraints
    dc-drive-length: drive-length must be equal to pump-length

  need
    IP68: drive-mechanism must be IP68 compliant


define component CentrifugalPump
  parameters
    torque is a mechanical-energy-flow
    water-flow is a liquid-material-flow
    length is a spatial-measure property

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


define component ElectricalDriveMechanism
  parameters
    torque is a mechanical-energy-flow
    length is a spatial-measure property

  variables
    power-potential is an energy-potential
    power is an electrical-energy-flow
    motor-control-signal is a control-signal

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


  components
    power-source is a Battery with arguments
      * power-potential
      * power

    motor is a BrushlessMotor with arguments
      * power
      * torque

    power-Switch is a Switch with arguments
      * motor-control-signal


  goal-requirements
    provide-power: power-source must provide power to motor
    send-control-signal: power-Switch must send motor-control-signal to power-source


  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]


define component BrushlessMotor
  parameters
    power is an electrical-energy-flow
    torque is a mechanical-energy-flow

  variables
    conversion is an efficiency

  transformation-requirements
    convert-power: must convert power into torque with subclauses
      * s1: conversion must be at least 0.8


define component Battery
  parameters
    power-potential is an energy-potential
    power is an electrical-energy-flow

  transformation-constraints
    convert-potential: does convert power-potential into power


  relations
    efficiency-model: battery-efficiency-model
      relating arguments
      * power-potential
      * power


define component Switch
  parameters
    motor-control-signal is a control-signal

Next!

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