Fdmu pro step_2010_final
Upcoming SlideShare
Loading in...5




Total Views
Views on SlideShare
Embed Views



7 Embeds 1,794

http://www-past.igd.fraunhofer.de 1367
http://www.igd.fhg.de 200
http://www-past.igd.fhg.de 190
http://www.igd.fraunhofer.de 33
http://www.slideshare.net 2
http://webcache.googleusercontent.com 1
http://translate.googleusercontent.com 1



Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

Fdmu pro step_2010_final Fdmu pro step_2010_final Presentation Transcript

  • FunctionalDMU: towards experiencing behavior of mechatronic systems in DMU Dr.-Ing. André Stork Fraunhofer Institut für Graphische Datenverarbeitung IGD Fraunhoferstraße 5 64283 Darmstadt Tel.: +49 (0) 6151 155 – 469 Fax.: +49 (0) 6151 155 – 139 E-Mail: andre.stork@igd.fraunhofer.de http://www.igd.fraunhofer.de
  •  Video
  • What is going on behind the scenes?  FunctionalDMU run-time environment Mastersimulator Wrapper Wrapper Wrapper Rhapsody Dymola Simpack
  • DMU  In DMU multi-CAD data is typically converted into one representation …  … to provide functionality such as … © Siemens AG  detecting collisions  checking possibility to assemble / disassemble parts  measuring  annotating
  • FDMU  In addition to geometry models behavior models of the mechatronic domains:  software  electronics  mechanics integration behavior models in diffe- DMU geometry models rent modelling languages
  •  So the question arises: What is the equivalent for geometric integration with respect to behavior models?  Approaches  mapping of the heterogeneous behavior models into one standard?  no existing standard with full representative power  execution of such an integrated behavior model in a ‚super simulator‘?
  •  Co-simulation matrix (Prof. Dr.-Ing. Marcus Geimer, Universität Karlsruhe) number of modeling tools integration of >1 co-simulation models integrating „classic“ =1 different simulation simulators =1 >1 number of simulation algorithms
  •  We decided to go for a  flexible  open  extensible  vendor-independent  co-simulation framework: the FDMU framework Mastersimulator Wrapper Wrapper Wrapper Rhapsody Bild Dymola Simpack
  •  We want to use the native behavior models …  as unchanged as possible  but some small adaptations are needed  in / out values  parameters to be changed native model connector communication-enabled model
  •  FDMU connector library for  Modelica (Dymola)  MAST (Saber)  MATLAB/Simulink
  •  Connectors to map native syntax to standardized syntax  Which standards?  SysML  Modelica  VHDL-AMS  SysML (Systems Modeling Language)  Modeling language for systems engineering  XML base  UML/XML tools exist to create and process SysML  Requirements and systems modeling
  •  Mapping of internal interfaces to a standardized form  Encapsulation of behavior models (example: controller) Controller (SysML) Unified description of interface variables of the behavior model Controller (native) native interface of behavior model
  •  ‚Glueing‘ functional building blocks together to create a simulation model U  up f down s I   and adding geometry models to embed them in an OO way
  •  Next: the simulators Spice Rhapsody Dymola simulators
  •  They are as heterogeneous as the behavior models with respect to:  programming languages and APIs  communication schemes  platforms simulators Rhapsody Dymola Dymola Simpack Simpack  How to cope with their heterogeniety?
  •  Solution strategy: Wrapper  controlling the simulator  communicating and mapping data  standardizing interfaces Wrapper Wrapper Wrapper simulators Rhapsody Dymola Simpack
  •  Which information does a wrapper receive? interface Wrapper Wrapper Wrapper description simulators Rhapsody Dymola Simpack behavior models
  •  Wrapper  different communication strategies  based on configuration of connectors
  •  Wrapper  simulator control commands, e.g.  configure  initialize  run Wrapper  start data control commands exchange  suspend  resume  stop Simulator  terminate
  •  What else do we need?  a master for communication and co-ordination   Which information does the Mastersimulator need? system behavior model Mastersimulator interface Wrapper Wrapper Wrapper description simulator Rhapsody Dymola Simpack behavior models
  •  Mastersimulator  TransferHandler  adapt data communication
  •  Mastersimulator  TransferHandler  support different protocols constant data flow constant data flow with upsampling constant data flow with downsampling event based input with sampling event based input /output
  •  To complete the FDMU framework …  system behavior model interactive visualization and geometry models system behavior model Mastersimulator interface Wrapper Wrapper Wrapper description simulator Rhapsody Dymola Simpack behavior models
  •  Video: SW simulation with Rhapsody Mastersimulator Wrapper Wrapper Wrapper Rhapsody Dymola Simpack
  • Integration of FE analysis: E-motor example  Demand to integrate and possible couple with finite element analysis  Challenge: FE known to be slow  A coupling scenario for an E-motor  E-motor with electronic control  Electronics on a PCB mounted at heat sources the backside of the E-motor  The electric behavior of the parts on the PCB depends on the thermal conditions (heat)  -> thermo-dynamic simulation warming of the PCB (transistors, controller)
  • Integration of FE analysis: E-motor example  General questions that may arise in the design process:  How warm will the transistors get?  What is the contribution of the engine to the temperature of the transistors?  Does the warming have effects on other elements, e.g. the controller?  What kind of cooling to attach to the transistors?  What happens if the distance between motor and PCB is changed?  Etc.
  • Integration of FE analysis: E-motor example  Physical model controller load software time motor (converter) time signal electronics mechanics signal power loss power loss influence on behavior thermo-dynamics
  • Integration of FE analysis: E-motor example  Physically-motivated splitting into partial models TE1: temperature transistor 1 TE2: temperature transistor 2 TM: temperature motor winding PE1: power loss transistor 1 PE2: power loss transistor 2 PM: power loss motor
  • Integration of FE analysis: E-motor example  We started to model the thermal behavior within ANSYS  approx. 50.000 nodes (volume mesh)  simulation time in the range of hours  way too slow for interactive simulation
  • Integration of FE analysis: E-motor example  Reduced model  Model order reduction  reduced systems of equations: 50.00 nodes > 100 nodes  Execution time  almost interactive  little impact on accuracy (we have not measured precision yet)
  • Integration of FE analysis: E-motor example  Mapping of the behavior models to simulators Saber Dymosim Dymosim Feed forward control - Matlab - direct user input input file Reduced thermo-dyn. Model (Dymosim)
  • E-motor example  Video
  • Other applications
  • Achievements  FunctionalDMU framework  open, extensible, flexible FDMU visualization FDMU  distributed, service-oriented architecture service s Berlin  unique combination of features Saber  solvers Dresden Darmstadt  methodology  visualization features Mastersimulator Rhapsody FDMU-Editor Simulink, Visu  Wrappers for Dymola Simulink SimPack Dymola, Mastersim.  Rhapsody, SimPack, Saber, Dymola (Modelica), Matlab/Simulink, …  Methodology for modelling, integrating and running FDMU simulations  Proof-of-concept scenarios
  • Benefits  end-user point of view  earlier multi-domain problem detection  visual insights and communication  integrated 2D/3D interactive visualization  shorter set-up of mechatronic simulations  re-use of behavior models (FBB) in different configurations  no transformation of models  running behavior models as services (without forwarding know-how)  simulation tool provider point of view  re-usable components for simulation coupling and  integrated visualisation
  • Outlook  Wish list / research issues  fast and flexible simulations, esp. FEM  coupling-in more different FE domains  taking environment conditions and tolerances into account  real-time requirements  ‚informed‘ CAD models  data management -> MechatronicPLM  optimization  organizational aspects  IP issues  LTP of behavior models
  • Das Produkt muss vollständig als Gesamtsystem simulierbar sein. (Bernd Ehrenberg, Daimler AG)
  • Contact and consortium for slides and videos see: www.functionalDMU.org