Skip to content

Parametric Diagrams

ESL

Design requirements in ESL are used to specify bounds on the values of variables using (in)equalities or objectives. When using (in)equalities, the values can be compared to either values or another variable. The objectives of a design requirement may be maximized or minimized, and are used to define the optimization goal of the system.

Behavior requirements are used to describe the dynamic behavior of (a part of) the system. It contains multiple cases, each with its own conditions, actions and/or results. However, behavior-requirements are not full behavior models.

Relations are used to relate the interdependency of variables. Variables may be related by mathematical equations, models, laws of physics, or any other means of interdependency. The relations may be directed (requiring or returning ), or undirected (related). The explicit mathematics are not addressed in ESL by design, as the language is not intended to replace specialized computational environments or programming languages. Its purpose is to provide a means to accurately capture the dependencies.

design-requirement
1
2
  design-requirements
    min-water-flow: water-flow must be at least 1.0 [L/s]
relation
1
2
3
4
5
  relations
    efficiency-model: battery-efficiency-model
      relating arguments
      * power-potential
      * power
behavior-requirement
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
  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]

SysML

The design-requirements, design-constraints, behavior-requirements and relations are captured as constraint definitions in a Block Definition Diagram. Afterwards, they are instantiated in a Parametric Diagram. The constraint definition can include bounds on values. This is specifically useful for mapping (in)equality design requirements. min-water-flow, dc-drive-length and convert-power-s1 are examples of inequality design requirements, as shown in the example below. The constraint definition can also be empty, save for parameters as in efficiency-model, to visualize relations. If/then statements can be used to map behavior-requirements, as in toggle-power.

storage-tank

List of constraints based on design-requirements, design-constraints, behavior-requirements and relations.

The constraint definitions must be instantiated in a Parametric Diagram, which is owned by a block. As a sanity-check, the Valuetype of the input-pin in the Parametric Diagram and the Constraint Definition must be equal. The instantiation of the constraint definitions in a Parametric Diagrams looks as follows:

storage-tank

A few words of caution:

  • ESL does not include specifications of equations that describe dependencies. However, SysML does contain the option to specify an equation within a constraint block.
  • Behavior-requirements are not full behavior models, and are therefore not mapped to SysML as state-machine diagrams but as constraint blocks with an if/then statement.
  • Relations in constraint blocks are undirectional. Information about directed relations is lost when moving from ESL to SysML.
  • SysML also defines objective functions, however their meaning differs slightly. SysML objective functions specify measures of effectiveness that should be maximized or minimized, rather than directly imposing design requirements.

Warning

A constraint block should always be linked to a block and a requirement. Otherwise, the constraint is not owned!

Next!

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