Physical Modeling with SimScape

(1)

A. Van den Brand, Mday 29-4-2011 1

Physical Modeling

with SimScape

Adriaan van den Brand

Mday 29-4-2011

Saving energy with Physical Modeling

(2)

Bio

• Adriaan van den Brand

• System architect Sogeti High Tech • Embedded systems experience:

− Embedded Software

− Software architecture, system architecture

− 7 years automotive (Ford, BMW, Visteon, NXP)

• Current role

− System architect at Philips Innovation Services − Hybrid drive trains for commercial vehicles

(3)

Recognizable?

3 Smart phone : 300 hour standby-tijd or 1 day usage?

Car: 3.9 l/100km in brochure  5.8 l/100km in real life?

(4)

Agenda

• Title & Bio • Agenda • Project • Model

− Common vs. physical modeling − abstract to reality

− Wat, how & why

• Experiences & Conclusions • Q&A

(5)

Project

Goals

Challenges

Role

Titel & Bio Agenda Project Model

Conclusions Q&A

(6)

Project background

• Hybrid drive train commercial vehicles

• Requirements (!)

− Maximum CO2 reduction − Maximum fuel savings

− Realistic estimations fuel usage

(7)

Goal : Model

• Model is used to determine

− Energy saving potential (and CO2, ….) − Optimum system architecture

− Component selection

− Strategies (regeneration)

•  Understand before building

(8)

Challenge 1

• What is maximum?

• Which „knobs‟ to turn?

• What to model ?

•  Modeling energy streams

− Chemical (Internal combustion engine) − Electrical (Battery)

− Mechanical (Rotation) − Mechanical(Translation)

(9)

Understanding energy flows

• Saving starts with understanding energy flows

Aux Air Resistance Vehicle Inertia Regenerative Breaking Brakes (Hydraulic/Pneumatic) HVAC Rolling resistance Battery Losses Waste Heat Cooling

Mechanic losses vehicle Mechanic losses body

(10)

Challenge 2 : Multi-disciplinary model

• Disciplines

− Electric, Mechanics, Pneumatics, Hydraulics, Software

• Interfaces?

• Environment?

• Re-use of existing Simulink models?

• How to fill the missing pieces?

(11)

Project : model centric

Key Performance Indicators Real world data System model

control &

software Electric

(12)

Steps

• 1. Understanding energy in basic function

− Traction, air drag, rolling resistance, electric system Domains:

◦ Mechanical (Newton’s laws)

◦ Electrical (iso-efficiency curves)

• 2. Understanding real use

− Observing the users, harvesting data from measurements

• 3. Understanding energy in ALL other functions

− Air-conditioning, power steering, braking, ….

− Domains: mechanic, electric, hydraulic, pneumatic, thermal

4

1 2 3

(13)

Design Space Exploration (project)

• Analysis of optimal system

− Top down analysis − Application domain

• Model refinement

− Energy conservation

• Component

-choices

1 4

Design Space

F=M*a P=½mv2 Application Available technology E-Motor-x Hybrid mode series parallel E-Motor-y Users

(14)

• 1st model: simplicity “brick on wheels”

• 2nd iteration

− Model with detailed subsystems

◦ Motor-behavior, gear boxes, battery models etc. • Finally

− Virtual prototype with the same interfaces as the real product

Model in project

Simple, cheap

Determine ideal results “Best case prediction”

(15)

Models

Reference process

Physical modeling

Conclusions Q&A

(16)

Models :

Backward facing (reference)

Reference Environment

Model Result

Standard drive cycle speed = f(t)

Backward facing model

(17)

Models:

Backward facing (common) (2)

• Vehicle„pulls‟ at the wheels • Wheels turn the gears

• Gears „turn‟ the motor

• Calculate required energy extraction from battery

• reverse world…. Model != reality

−  doesn’t fit expectations

1 8 gear

ω

wheel

v

_vehicle

F

_roll

+F

_drag 1T

ω

motor

Τ

motor

P

_mech

η

_wheel

η

_gear

η

_motor

η

_battery

M +

U

batt

i

batt

= P

_electric / / / /

(18)

Realistic model (forward facing/physical)

• Action = - Reaction

• Model reflects reality

Controls Driver Route Traffic G Alternator Engine _Vehicle 1T Tyre Model Gear&diff M + Battery E-motor

(19)

Physical Modeling

• Physical signals

− Voltage and currents (electric domain) − Torque and ω (mechanic domain)

− Flow and pressure (and temperature) (pneumatic domain)

−  interface independent of implementation! −  Energy in Watt

• Preservation of energy

− Energy preserving ports (bi-directional)

− Direction of signals is determined by solver

◦ Action = - reaction

− Energy can be translated to other domains − Waste energy (heat) is also energy

2 0

(20)

Physical Modeling : Electric Motor

Result: torque

Cause: current

• Electric motor : current  rotation

Current source M i ground Mechanic reference (chassis) U rotatie

(21)

Physical Modeling : Electric Motor (2)

2 2

100 Nm

Cause: torque Result: current/voltage • Regenerative braking

• Kinetic energy of vehicle is converted in electricity • Motor as alternator M i ground Mechanic reference (chassis) U rotation

(22)

Physical Modeling : inside E-motor

• Motor is also a model • Parameters

• Electric substitution • Non ideal attributes

i ground rotation U R L friction inertia Electric Interface (Rotating) Mechanic interface Τ:=K*i U:=K*ω (K=constant of proportionality V/ (rad/s) )

(23)

Physical interfaces Simulink

• Normal Simulink model:

• Physical model

Fewer connections

Better maintainability Physical model

(24)

M i ground Mechanic reference (chassis) U rotatie 2

Physical Modeling : Top Down

1 3 G Alternator Engine _Vehicle 1T Tyre Model Gear&diff M + Battery E-motor i ground rotation U R L friction inertia Electric Interface (Rotating) Mechanic interface Τ:=K*i U:=K*ω

(25)

Physical Modeling: energy centric

Energy is important: in all domains

- Concepts comparable

- (resistance, load, buffer)

- Coupling domains using converters

- Motor = converter (electric   rotering mechanic) Energy ◦ Losses (heat) = thermal energy

◦ Piston (Pneumatic/hydraulic) ◦ Pump ….

2 6

(26)

Same interfaces, different models

• Interfaces are stabile

− Components exchangeable using variants

◦ Runtime configurable variants

− Scalable simulation accuracy

◦ System level: >>2x real time

› Lookup tables (datasheet info); straightforward

◦ Mean level : 1-2x real time

› i.e. E-motor model reveals 3-phase control

◦ Detailed level:10-20x slower than real time

› i.e. PWM modulation of E-motor inverter

(27)

Model features

• Variation of

− Driving cycles

− Components & Component parameters − Topology

− Driver behaviour

(28)

Conclusions

Experiences

Conclusions Project

(29)

Project: scaleable model

• Evolutionary model (grows with project)

− Top down

◦ (system) to detailed level ◦ Further refinement possible

◦ No surprises in model validation

◦ Maximum energy saving

− Multi-disciplinairy

◦ Energy centric

• Interfaces stabile

− Physical interfaces = reality

• Tooling

− Matlab/Simulink − Extra SimScape/SimDriveline (physical modeling) 3 0 Design Space F=M*a P=½mv2 Application Available technology E-Motor-x Hybrid mode series parallel E-Motor-y Users

(30)

Experiences

• Learning time

− Physical model != average Simulink model

− Idealized models don’t work (physically impossible) − Limited knowledge in industry

− Modeling is learning about the domain

• Tool

− SimScape family is very powerful

◦ Little need to dive into bondgraphs and diff. equations − SimDriveline: powerful interfaces, (too) simple components − SimElectronics, SimMechanics: interesting toolboxes

(31)

Experiences: tool improvements

• Room for improvements in tools:

− Hard-to-find Solver issues − Infinite logging to HD

◦ Much time is lost into squeezing logging into <2GB

− Sampled logging

◦ No interest in femto-second events

◦ decimation doesn’t scale with large step size

− Diff/Merge support

• Wish list for our model

− Nightly builds/runs

(32)

Conclusions

• “Physical modeling”

 Excellent for mechatronic models

 Modeler is forced into realistic designs  (Extremely) scaleable model

 Ideal for for energy saving  Good interfaces

 Fewer interfaces, with higher quality

 Re-useable components

− Disadvantages

◦ Learning time from simulink (different way of thinking) ◦ Solver limitations for control & plant