Bridging between different modeling formalisms - results from the MULTIFORM project Martin Hüfner, Christian Sonntag, Sebastian Engell Process Dynamics and Operations Group Department of Biochemical and Chemical Engineering TU Dortmund Germany System Design meets Equation-based Languages, Sept. 19, 2012, Lund
Outline • The MULTIFORM project • Design flow example • Tool developments • Model exchange and model transformations • Lessons learned 2
MULTIFORM: EU ICT STREP 9/2008 – 5/2012 • TUDO (Coordinator) – TU Dortmund, Germany AAU/KVCA Sebastian Engell TUE/ESI • TUE – TU Eindhoven, Netherlands Koos Rooda, Bert van TUDO Beek, Jos Baeten • Verimag/ UJF RWTH/VEMAC – Universite Joseph Fourier, Grenoble, France Goran Frehse, Oded Maler UJF • RWTH Verimag/UJF – RWTH Aachen, Germany Stefan Kowalewski • AAU – Aalborg Universitet, Denmark • • VEMAC KVCA Kim Larsen, Brian Nielsen – – “Danish Cooling Cluster” Aachen, Germany • ESI Michael Reke Jens Andersen – Stichting Embedded – Closely working with Systems Institute DANFOSS Ed Brinksma, Boudewijn 3 Haverkort
Example: Design of a Pipeless Plant Camera Color stations Product AGVs Mixing station Control PC Storage station Charging stations 4
Challenges for Model-based Design (1) • Design and validation on different Camera levels of abstraction – Specification Color stations • Specification of the tasks and of Product the performance of the system – High-level design AGVs • Choice of the equipment, Mixing station Control PC feasibility and bottleneck Storage station analysis, throughput Charging stations maximization, plant layout optimization – Low-level design System specification Performance analysis • Optimization and control of processing steps and motion High-level design High-level tests Validation Design dynamics, logic control Low-level design • Choice of sensors and actuators, Low-level tests communication system Implementation Implementation tests – Implementation • PLCs, embedded controllers, communication system 5
Challenges for Model-based Design (2) • The control system spans the Camera complete control hierarchy Timed or – Coordination control Color stations hybrid models • Scheduling and performance Product optimization – Advanced control AGVs • Control of batch processes Mixing station Control PC • AGV path planning Continuous Storage station models Charging – Regulatory control stations Discrete-event, • AGV motion control hybrid, and • Docking control continuous models • Sequence control in the processing stations • Low-level continuous control – Low-level safety-related control Discrete-event, timed, and hybrid models 6
Design tasks Models Results First design parameters Requirements Boderc key drivers and assumptions Design parameters Feasible plant layouts & assumptions Feasibility analysis Timed Chi (1 mixing, 2 filling or 2 mixing, 3 filling stations) Schedules Plant layout design Uppaal Cost optimal plant layout Plant (1 mixing, 2 filling, 2 AGV) layout & Docking schedule time and scheduling trace trace Docking Modelica Docking time (10 s) and Maximum Speed & Speed & optimal station angle (90 ° ) acceleration acceleration AGV speed analysis gPROMS Maximum speed (500 mm/s) Maximum Model- and acceleration (500 mm/s²) speed & Update of splitting acceleration times Modelica 1 Validation Visualization and validation Linear model SpaceEx Docking controller validation Hybrid Chi Controller design Controller only Controller for stations CIF Programming Controller Code instructions Controller PLC Code Code validation code generation AGV ECUs Forwarded information Arcade 1 : Complete Modelica model based on Feedback information 7 Uppaal model; used as basis for in-depth Model transformation Modelica and gPROMS models Model fragmentation / composition
Integrated Model-based Design • Integrated modeling and design of the system itself and of the multi- layered and networked control system – Including a structured approach to the management of specifications, design decisions, models, and results • Coverage of all layers of the automation and design hierarchy – Integrated tool support on all layers of the automation and design hierarchies • Current state: Islands of support for specific design and analysis tasks • Trans-level integration of model-based design approaches • Support of iterations in the design process • Propagation of faults and unexpected behaviors • Modifications over the life cycle without top-down redesign Improvement of the tool support for the design steps Tool integration and Design Framework Exchange of models between tools via the CIF (Compositional Interchange Format) 8
MULTIFORM Tools and Tool Chains Logic Controller Design Verification Code Analysis • Integrated controller design Verification tool SpaceEx Code and requirements and analysis (successor of PHAVer ) analysis for ECUs using • Arcade and UPPAAL Consistency checking Informal and vague Systematic specifications analysis methods using UPPAAL Refinement • Step-wise refinement based on HCIF Formal and precise specifications Plant model Algorithmic Synthesis Control System Specification using DC/FT Preco condition Action Informal Formal Informal Formal Qualifier Tank level is to H> H_max Open drain valve V1:=1 S high 9
The MULTIFORM Design Framework [ESI] Design Flow • Consistent integration of design DS DD DESIGN FLOW DS models into a common software DD option DD DS design design DS DD DD DS decision step DS framework option option assure/predict qualities INFORMAL • Support of a generic design flow environment VIEW analysis results system model 100% DESIGN STEP – Design decisions M M – System design M M M M analysis ~10% results • Consistency management formalism accuracy credibility – Communication of design CONCRETE MODEL working range structure/abstraction FORMAL parameters model facts decision taking OUTPUT INPUT assumption verification – Conflict detection errors measurements analysis specification unknown uncertainties – Models and results management tool tool tool tool 10
VEMAC Development Process V-Model Real Test Bench Test cases Requirements analysis UPPAAL Specifications Timed model Concepts Unit Test Test cases Implementation Arcade Source Code Queries 11
Customized Design Framework Prototype 12
Model Exchange Using the Compositional Interchange Format (CIF) • Incompatibility of tools is one of the major obstacles for a broader acceptance of model-based design in industry → Achieve inter -operability by (algorithmic) model transformations • One possibility: Bi-lateral transformations – Problems • Many transformations may be needed • The developer of a transformation must be familiar with many different formalisms 13
Model Exchange with the Compositional Interchange Format (CIF) • Incompatibility of tools is one of the major obstacles for a broader acceptance of model-based design in industry → Achieve inter -operability by (algorithmic) model transformations • One possibility: Bi-lateral transformations • Interchange format – Generic and sufficiently rich modelling formalism – Only transformations from/to the interchange format are necessary → Reduction of the implementation effort 14
The Compositional Interchange Format (CIF) [Bert van Beek et al., TUE] • Purposes – Establish inter-operability of a wide range of tools – Provide a generic formalism for general hybrid systems • Major features – Formal and compositional semantics • Independent of implementation aspects • Mathematical correctness proofs of translations → Property -preserving model transformations possible – Fully implicit DAE dynamics (possibly discontinuous) – Hierarchy and re-usability • Parallel composition with different communication concepts – Model component interaction • Point to point communication, multi-component synchronization, broadcast communication, shared variables – Different urgency concepts http://devel.se.wtb.tue.nl/trac/cif/ 15
The Compositional Interchange Format (CIF) [Bert van Beek et al., TUE] Transition State Guards (transition can only be taken if guard is true) Invariants e.g.: a > b (equations that are Initial Updates active when state (Conditions if state (new discrete values is active) is initially active) or reinitialization) e.g.: e.g.: z := 5, {v}: new (v) = 2 v‘ = -g Synchronization (between different automata via labels or channels) Urgency (nondeterminism, determinism, stochastic) Formal definition by Structural Operational Semantics (SOS) rules, e.g.: 16
Transformations – gPROMS CIF (Excerpt) model automaton // for unconditional // equations z 01 Process v = -g automaton // for conditional model // equations equations Model Task automaton // for sequential // statements s 1 :=true, s 1 =false algorithmic ∧ s 2 =false z 13 s 2 :=true z 10 z 11 z 12 tcp true statements automaton // for loops Parallelism provided by parallel automata s 1 =true b h <0 true z 21 z 24 z 25 z 20 z 22 true ¬true { b v , b h } : z 23 z 26 17 s 1 :=false new ( b v )= - b e * b v ¬true , b h = 0
Recommend
More recommend
