Modelon Modelica executable requirements Ansys Conference 2016

7 June, 2016
Copyright © 2016 by Modelon Inc.
Dr. Hubertus Tummescheit
Board Member, Modelica Association
CEO, Modelon Inc.
Applying FMI/FMU & Modelica for Design and
Co-simulation of Complex Dynamic Systems

 The Functional Mockup Interface: FMI overview
 Modelica: a very brief overview
 A Real-World Example: Active Grill Shutter Controls
 Vehicle Thermal Management with Modelica
 Continuous Validation of System Requirements
• Intermediate results from ITEA3 MODRIO project
 Iterative Controller Development Using Modelica
 Conclusions

•
 an application
programming interface
and its semantics
 an xml schema that
describes the model
structure and capabilities
 the structure of a zip file
that is used to package the
model, its resources and
documentation.
• 85 tools support FMI in 9
different categories.
Supported by >85 tools:
• 0/1-D ODE Simulators
• Multibody Simulators
• HIL Simulators /SIL tool chains
• Scientific Computation tools
• Data analysis tools
• Co-simulation Backplanes
• Software development tools
• Systems engineering tools
• SDKs

1. Separate the model authoring tool from the
model execution tool!
2. Free the model unit (FMU) from license
restrictions
3. Make the standard widely accepted:
https://fmi-standard.org/tools
4. Increased Collaboration possibilities among
typically disparate functional areas
5. Reduced risk & reduction in liability through
better virtual verification

 What’s under consideration for the next releases?


•




•
•
•

• Modelica is a special purpose programming language
for modeling cyber-physical systems. Modelica is:
 A vendor-neutral standard
 Multi-domain
 Object oriented
 Equation based (acausal)
 Covers multiple formalisms
 With a consistent graphical and textual system representation
• Modelica is like LEGO for Physical Systems Modeling

Object-Oriented Modeling
Component
• Each Icon represents one physical component.
For example, electrical resistance, mechanical device, pump
Connection
• A connection line represent the actual physical
coupling. For example, electrical wire,
rigid mechanical coupling.
Connector
• Variables in the connectors define the
Interaction to other objects
• A component consists of connected sub-components
(= hierarchical structure) and/or is described by equations.
Analysis

•
•
•
•
•
•
•
•
•
•
•
•
Commercial
Open
Source

•




Hardware Model:
Dymola/Modelica
Controller/Software development
platform:
IBM Rational Rhapsody
ANSYS SCADE Suite
The MathWorks® Simulink®
etc.

 Target: best-in-class fuel economy
•
•

 Non-MBSE approach:
•
•
•
•
Sample
Vehicle!

 Integrated model for fuel economy and vehicle thermal
management
• Vehicle model with loads and losses
• Vehicle heat loads (engine, friction, transmission)
• Lumped engine thermal model
• Coolant and oil circuits with possible additions of other
thermal fluid circuits
• Drive cycles (speed, grade, wind, etc.)
• Airflow effects
• Key vehicle and thermal controls (fan, grill, etc.)

 Multi-domain physical model libraries in Modelica
 Libraries developed by Modelon domain experts leveraging
industrial experience and consulting projects

 Thermal
 Mechanical
 Electrical
 Coolant
 Air

Air Flow
Coolant Circuit
Heat from vehicle
systems enters
coolant fluid
Coolant

Boundary conditions define test
case conditions:
• Road grade and surface
• Ambient air (temperature,
pressure, wind speed, etc.)
• Desired vehicle speed profile
(drive cycle)
Ambient
Road
Drive Cycle

0 250 500
-5
0
5
10
15
20
25
30
35
40
Time [s]
0 250 500
-40
0
40
80
120
160
Time [s]
0 250 500
1000
2000
3000
4000
5000
Time [s]
0 250 500
-0.2
0.0
0.2
0.4
0.6
0.8
1.0
1.2
1.4
Time [s]

Fan speed is low
When vehicle is fast
Thermostat opens
As engine warms up
Temperature can
only be exceeded for
at most X seconds

 MBSE
approach:
Stakeholder Requirements
Design Requirements
Requirements
Manager

 MBSE
approach:
Design Requirements
Requirements
Manager
Virtual SystemReal System

 MBSE
approach:
Design Requirements
Requirements
Manager
Formalized
Requirements

 MBSE
approach:
Design Requirements
Requirements
Manager
Formalized
Requirements
Translate to
Executables
Test Cases
Requirements
Monitors
Verifier Models
Batch
Execution
Executable
Environment

 MBSE
approach:
Design Requirements
Requirements
Manager
Formalized
Requirements
Translate to
Executables
Test Cases
Requirements
Monitors
Verifier Models
Batch
Execution
Executable
EnvironmentAll
Pass?
Result Report
Done
Modify:
• Reqs
• System
• Model
Yes
No
Complete
Coverage?

 MBSE
approach:
Design Requirements
Requirements
Manager
Formalized
Requirements
Translate to
Executables
Test Cases
Requirements
Monitors
Verifier Models
Batch
Execution
Executable
EnvironmentAll
Pass?
Result Report
Done
Modify:
• Reqs
• System
• Model
Yes
No
Complete
Coverage?
These are usually
high level, not always
easily testable.

 MBSE
approach:
Design Requirements
Requirements
Manager
Formalized
Requirements
Translate
to
Executable
s
Test Cases
Requirements
Monitors
Verifier Models
Batch
Execution
Executable
EnvironmentAll
Pass?
Result Report
Done
Modify:
• Reqs
• System
• Model
Yes
No
Complete
Coverage?
These are low level
and testable. When
possible also specified
in an open standard
language.

 MBSE
approach:
Design Requirements
Requirements
Manager
Formalized
Requirements
Translate to
Executables
Test Cases
Requirements
Monitors
Verifier Models
Batch
Execution
Executable
EnvironmentAll
Pass?
Result Report
Done
Modify:
• Reqs
• System
• Model
Yes
No
Complete
Coverage?
These exercise the
system dynamics.

 MBSE
approach:
Design Requirements
Requirements
Manager
Formalized
Requirements
Translate to
Executables
Test Cases
Requirements
Monitors
Verifier Models
Batch
Execution
Executable
EnvironmentAll
Pass?
Result Report
Done
Modify:
• Reqs
• System
• Model
Yes
No
Complete
Coverage?
These are the executable checks to
verify the requirements are met.

 MBSE
approach:
Design Requirements
Requirements
Manager
Formalized
Requirements
Translate to
Executables
Test Cases
Requirements
Monitors
Verifier Models
Batch
Execution
Executable
EnvironmentAll
Pass?
Result Report
Done
Modify:
• Reqs
• System
• Model
Yes
No
Complete
Coverage?
Specifying the requirements in a
standard way opens the possibility
to automatically generate the
executable monitors.

 MBSE
approach:
Design Requirements
Requirements
Manager
Formalized
Requirements
Translate to
Executables
Test Cases
Requirements
Monitors
Verifier Models
Batch
Execution
Executable
EnvironmentAll
Pass?
Result Report
Done
Modify:
• Reqs
• System
• Model
Yes
No
Complete
Coverage?
Combining a test
case with one or
more monitors
allows requirements
to be verified.

 MBSE
approach:
Design Requirements
Requirements
Manager
Formalized
Requirements
Translate to
Executables
Test Cases
Requirements
Monitors
Verifier Models
Batch
Execution
Executable
EnvironmentAll
Pass?
Result Report
Done
Modify:
• Reqs
• System
• Model
Yes
No
Complete
Coverage?
The complete set of
executable verifier
models can be tested
automatically.

 MBSE
approach:
Design Requirements
Requirements
Manager
Formalized
Requirements
Translate to
Executables
Test Cases
Requirements
Monitors
Verifier Models
Batch
Execution
Executable
EnvironmentAll
Pass?
Result Report
Done
Modify:
• Reqs
• System
• Model
Yes
No
Complete
Coverage?
The report shows a
summary overview of
the pass/fail results.

 MBSE
approach:
Design Requirements
Requirements
Manager
Formalized
Requirements
Translate to
Executables
Test Cases
Requirements
Monitors
Verifier Models
Batch
Execution
Executable
EnvironmentAll
Pass?
Result Report
Done
Modify:
• Reqs
• System
• Model
Yes
No
Complete
Coverage?
When requirements are
not met, modifications can
be made to the system,
model or even the
requirements.

 MBSE
approach:
Design Requirements
Requirements
Manager
Formalized
Requirements
Translate to
Executables
Test Cases
Requirements
Monitors
Verifier Models
Batch
Execution
Executable
EnvironmentAll
Pass?
Result Report
Done
Modify:
• Reqs
• System
• Model
Yes
No
Complete
Coverage?
The requirements manager
should be able to verify that
all requirements will be
tested by the set of verifier
models.

Translate to
Executables
 MBSE
approach:
Design Requirements
All
Pass?
Test Cases
Requirements
Monitors
Verifier Models
Batch
Execution
Result Report
Done
Modify:
• Reqs
• System
• Model
Executable
EnvironmentYes
Requirements
Manager
No
Complete
Coverage?
Formalized
Requirements
Degree of
Automation?

Design Requirements
Requirements
Manager
 Requirements management tools
 IBM DOORS/DOORS NG
 Requirements quality tools
 Requirements Quality Suite from The Reuse Company
 Requirements traceability
 IBM Requisite Pro, integration with ClearQuest for testing, ..
 Reqtify (Dassault Systèmes), links Modelica code to req. in DOORS
 Requirements formalization?
 Testing of requirements against system model?
 Continuous Integration tools to repeat tests for every change to the system?

Translate
to
Executable
s
 MBSE
approach:
Design Requirements
All
Pass?
Test Cases
Requirements
Monitors
Verifier Models
Batch
Execution
Result Report
Done
Modify:
• Reqs
• System
• Model
Executable
EnvironmentYes
Requirements
Manager
No
Complete
Coverage?
Formalized
Requirements
Focus on
this part

•
Requirements Formalized
requirements
Executable model of
requirements (e.g. FMU)
Physical plant Model of plant
Deployable model
of plant (FMU)
Software spec Software model
or prototype
Deployable model
of software (FMU)
Deployable model
of environment
Automate Analysis
& Deploy to team!
Development of a customized workflow to allow
rapid iterations of plant & software configuration

 ITEA3 Project:
• Model Driven Physical Systems Operation
 WP: Define requirements formally and check them automatically
whenever a Modelica system model is simulated
Example
„Pumps should not cavitate when they are operating“ (p(t) ≥ pcav if operating)
→ Define formally + associate conveniently to all pumps
+ check automatically
+ report issues automatically
Otter et al: Formal Requirements Modeling for Simulation-Based Verification, Modelica’2015
State of the art
• Not practical (impossible) with available Model Checkers since requirements
depend on the numerical solution of Differential-Algebraic Equations (DAE).
• Limited tool support for connecting „textual requirements“ with simulation models
(e.g. Simulink with Validation & Verification toolbox + IBM DOORS;
3DExperience with Reqtify + Dymola, ...).
• Research languages + tools (e.g. ModelicaML from Airbus Innov./LiU).

Natural language:
„Pumps should not cavitate when they are operating“
FORM_L (formal language developed by N. Thuy, EDF)
required property R2 = { P in Pumps | during P.InOperation check not P.Cavitate };
1. Define requirements formally
2. Design Architecture
(e.g. with SysML)
3. Provide Behavioral Models
to evaluate design (Modelica)
4. Associate requirements and
architecture with
behavioral models
5. Verify Behavior
Otter et al: Formal Requirements Modeling for Simulation-Based Verification, Modelica’2015

 Modelica extension to express requirements (under development)
 FORM-L-inspired Modelica library, based on 3-valued logic:
Satisfied, Undecided, Violated
 Large Library of pre-defined requirement structures
  Executable and formal model of requirements, in Modelica
language
(x,y) coordinates of input must stay within
closed polygon
(output: closest distance to polygon +
property)

Test cases exercise system
(or parts of system) under
various operating conditions
Test cases exercise system
(or parts of system) under
various operating conditions
Adding test cases can
improve coverage

Monitors used to check
pass/fail status of
requirements from test cases

• Monitors from the new Modelica
Requirements library (Otter et al., 2015)
• Checks the conditions of the requirement
• Reports pass, fail, or undecided
• Constructed from standard blocks from the
Requirements library
• Monitors can be collected in one submodel,
and be compiled into an FMU as well
M. Otter, N. Thuy, D. Bouskela, L. Buffoni, H. Elmqvist, P. Fritzson, A. Garro, A. Jardin, H. Olsson, M. Payelleville,
W. Schamai, E. Thomas, AND A. Tundis. Formal Requirements Modeling for Simulation-Based Verification. Proceedings of the 11th International
Modelica Conference, Paris, France, September 21-23., pp. 625-635 2015. http://www.ep.liu.se/ecp/118/067/ecp15118625.pdf

Monitors added to test
cases – in this case a
unit test of the simple
controller
Requirements violated (0 of 2):
None
Requirements untested (0 of 2):
None
Requirements satisfied (2 of 2):
(checkReq3.requirement): Grill shutter opened below 15 m/s
(checkReq4.requirement): Grill shutter closed above 18 m/s
0 4 8 12 16 20
-20
-10
0
10
20
0 4 8 12 16 20
-0.2
0.0
0.2
0.4
0.6
0.8
1.0
1.2
Time [s]
Overall pass
or fail log
direct from
library
VehicleVelocity[m/s]GrillCommand[1=open,0=closed]
Vehicle Velocity
Grill Command

 Key features
• Modelica and FMI cross testing platform
• Flexible test authoring
• Automated test execution and reporting
 Architecture
• Core
Command line tool for running tests
Uses OPTIMICA compiler toolkit for test retrieval
• GUI
Tool for creating, updating and running tests
Reviewing and updating results

• Test suite defines a
collection of test cases
for batch execution
• Automated execution of
complete suite of tests

Report shows summary
of results with
hyperlinks to detailed
reports

• CI integration for automated
requirement verification
• Hudson, Jenkins, TeamCity
• The test specification can be in
the Modelica code and
converted
• The test specification can be
created in the GUI and version
controlled
• Multiple reports from same
data:
• Human readable HTML
report
• Machine readable Junit xml
report

1. User commits change to controller
2. Automated testing verifies all
requirements are met
Rapid feedback to developer
when things get broken!

 Initial bang-bang controller with hysteresis
0 250 500
0
10
20
30
40
Time [s]
Vehicle Speed
Closing Threshold
Opening Threshold
Close the shutters
when the vehicle
speed exceeds the
closing thresholdClose Close
Open Open
Open the shutters
when the vehicle
speed is below the
opening threshold

 Implemented as a state machine from Modelica
StateGraph2 library
Activation of states
completely opens or
closes grill shutters
DONE

 State machine transitions
Initial state is
grillOpen
Transition condition to
closed state based on
vehicle speed thresholds

Baseline system without
grill shutters
0 250 500
-5
0
5
10
15
20
25
30
35
40
Null controller holds
grill shutters in wide
open position
Vehicle runs the
US06 drive cycle
VehicleVelocity[m/s]

Baseline system without grill shutters
0 250 500
0
4
8
12
16
20
0 250 500
1000
2000
3000
4000
5000
0 250 500
-500
0
500
1000
1500
2000
2500
3000
0 250 500
80
84
88
92
96
0 250 500
-5
0
5
10
15
20
25
30
35
40
Fuel Economy [mpg]
Engine Speed [RPM]
Coolant Temp [°C]
Fan Speed [RPM]
Vehicle Speed [m/s]
-------- 100.0 % of US06_no_shutters requirements are satisfied -------------
None
None
(checkReq1_1.requirement): Coolant temperature must not exceed 368.15K for longer than 20 seconds
(checkReq2_1.requirement): Coolant temperature shall not exceed 371.15K
(checkReq3_1.requirement): Grill shutter opened below 15 m/s

 Connect to system model
Controller commands grill
shutter position, modifies air
flow to stack and aero drag
Replace grill null position controller
with state based control logic

 Execute test cases
0 250 500
-5
0
5
10
15
20
25
30
35
40
Repeat the US06 drive cycle

Review results from
continuous integration

0 250 500
0
4
8
12
16
20
Baseline
Simple Controller
0 250 500
75
80
85
90
95
100
105
110
115
Baseline
Simple Controller
0 250 500
-500
0
500
1000
1500
2000
2500
3000
Baseline
Simple Controller
0 250 500
1000
2000
3000
4000
5000
Baseline
Simple Controller
0 250 500
-5
0
5
10
15
20
25
30
35
40
Baseline
Simple Controller
System with simple grill shutters
Fuel Economy [mpg]
Engine Speed [RPM]
Coolant Temp [°C]
Fan Speed [RPM]
Vehicle Speed [m/s]
-------- 50.0 % of US06_FMU_simpleGC requirements are satisfied -------------
(checkReq1_1.requirement at 86.3981 s): Coolant temperature must not exceed 368.15K for longer than
20 seconds
(checkReq2_1.requirement at 111.523 s): Coolant temperature shall not exceed 371.15K
None
(checkReq4_1.requirement): Grill shutter closed above 18 m/s
Failed thermal requirements
400 440 480 520 560 600
15.5
16.0
16.5
17.0
17.5
18.0
18.5
19.0
Baseline
Simple Controller
In addition to failed
thermal requirements,
fuel economy actually
decreased!
Fuel Economy [mpg]
75 100 125
94
95
96
97
98
99
100
Baseline
Simple Controller
Temperature exceeds 95°C for
more than 20 seconds
Temperature exceeds 98°C

0 250 500
0
4
8
12
16
20
Baseline
Simple Controller
0 250 500
75
80
85
90
95
100
105
110
115
Baseline
Simple Controller
0 250 500
-500
0
500
1000
1500
2000
2500
3000
Baseline
Simple Controller
0 250 500
1000
2000
3000
4000
5000
Baseline
Simple Controller
0 250 500
-5
0
5
10
15
20
25
30
35
40
Baseline
Simple Controller
System with simple grill shutters
Fuel Economy [mpg]
Engine Speed [RPM]
Coolant Temp [°C]
Fan Speed [RPM]
Vehicle Speed [m/s]
0 250 500
-500
0
500
1000
1500
2000
2500
3000
Baseline
Simple Controller
Closed grill shutters reduces air flow through the stack. Compensated for by
increased the fan speed, draws more electrical power from the alternator…
and ultimately the engine.
Fan Speed

 Improved controller
Additional inputs to account for
system temperatures

Additional state for new logic

PID modulates grill position based on
weighted average temperature

Replace the simple bang-bang control
logic with the improved controller
0 250 500
-5
0
5
10
15
20
25
30
35
40
Repeat the US06
drive cycle

Review results from
continuous integration
Requirements now pass
across multiple test cases

0 250 500
0
4
8
12
16
20
Baseline
Simple Controller
Improved Controller
0 250 500
1000
2000
3000
4000
5000
Baseline
Simple Controller
Improved Controller
0 250 500
75
80
85
90
95
100
105
110
115
Baseline
Simple Controller
Improved Controller
0 250 500
-500
0
500
1000
1500
2000
2500
3000
Baseline
Simple Controller
Improved Controller
0 250 500
-5
0
5
10
15
20
25
30
35
40
Baseline
Simple Controller
Improved Controller
System with improved grill controller
Fuel Economy [mpg]
Engine Speed [RPM]
Coolant Temp [°C]
Fan Speed [RPM]
Vehicle Speed [m/s]
-------- 100.0 % of US06_FMU_advancedGC requirements are satisfied -------------
None
None
(checkReq1_1.requirement): Coolant temperature must not exceed 368.15K for longer than 20 seconds
(checkReq2_1.requirement): Coolant temperature shall not exceed 371.15K
Requirements now pass
400 440 480 520 560 600
15.5
16.0
16.5
17.0
17.5
18.0
18.5
19.0
19.5
Baseline
Simple Controller
Improved Controller
Fuel economy improved,
also over baseline
Fuel Economy [mpg]

• Further integration with MBSE/Reqs tools
for fully automated traceability
• Complete automation of requirements
verifcation process
• … much more progress on tools is needed to
have a coherent work flow from
 stakeholder requirements to
 formal requirements and finally
 fully automated requirements verification.

• FMI simplifies tool connectivity and allows more
efficient work flows & processes
• FMI enables true MBSE, with executable models
• Requirements monitors make the requirements
executable and enables the ability to check
requirements compliance continuously during
systems development
• Process automation is key to integrate the
requirements verification with MBD.

Modelon Modelica executable requirements Ansys Conference 2016

Modelon Modelica executable requirements Ansys Conference 2016

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (11)

Similaire à Modelon Modelica executable requirements Ansys Conference 2016

Similaire à Modelon Modelica executable requirements Ansys Conference 2016 (20)

Plus de Modelon

Plus de Modelon (18)

Dernier

Dernier (20)

Modelon Modelica executable requirements Ansys Conference 2016

Notes de l'éditeur