DOCSLIB.ORG

Making Simulink Models Robust with Respect to Change Making Simulink Models Robust with Respect to Change

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Making Simulink Models Robust with Respect to Change Making Simulink Models Robust with Respect to Change Making Simulink Models Robust with Respect to Change Making Simulink Models Robust with Respect to Change By Monika Jaskolka, B.Co.Sc., M.A.Sc. a thesis submitted to the Department of Computing and Software and the School of Graduate Studies of McMaster University in partial fulfillment of the requirements for the degree of Doctor of Philosophy Doctor of Philosophy (December 2020) McMaster University (Software Engineering) Hamilton, ON, Canada Title: Making Simulink Models Robust with Respect to Change Author: Monika Jaskolka B.Co.Sc. (Laurentian University) M.A.Sc. (McMaster University) Supervisors: Dr. Mark Lawford, Dr. Alan Wassyng Number of Pages: xi, 206 ii For my husband, Jason iii Abstract Model-Based Development (MBD) is an approach that uses software models to describe the behaviour of embedded software and cyber-physical systems. MBD has become an increasingly prevalent paradigm, with Simulink by MathWorks being the most widely used MBD platform for control software. Unlike textual programming languages, visual languages for MBD such as Simulink use block diagrams as their syntax. Thus, some software engineering principles created for textual languages are not easily adapted to this graphical notation or have not yet been supported. A software engineering principle that is not readily supported in Simulink is the modularization of systems using information hiding. As with all software artifacts, Simulink models must be constantly maintained and are subject to evolution over their lifetime. This principle hides likely changes, thus enabling the design to be robust with respect to future changes. In this thesis, we perform repository mining on an industry change management system of Simulink models to understand how they are likely to change. Then, we explore the various modelling mechanisms available in the Simulink language to see how they could support modular design with information hiding. Next, we propose a module structure, syntactic interface, and modelling conventions for Simulink designs, which are supported by our iv open-source Simulink Module Tool. Finally, we apply the proposed techniques on case studies from the aerospace and nuclear domains, in order to demonstrate their practicality and validate their effectiveness. Overall, the approach helped support information hiding by encapsulating secrets and facilitating likely changes. It also had a positive effect on interface complexity, cohesion, and coupling. The larger system also exhibited reductions to cyclomatic complexity, testing effort, and execution time, but the smaller case study benefited less in these areas. v Acknowledgments My sincerest appreciation to Dr. Mark Lawford and Dr. Alan Wassyng for supervising me throughout my graduate studies. Thank you for encouraging me and providing me with incredible opportunities that enriched my studies. Many thanks to Dr. Jacques Carette and Dr. Ryszard Janicki for serving on my supervisory committee, as well as for providing constructive input and thought-provoking questions that shaped the course of my doctoral research. I would also like to thank my external examiner Dr. Pieter J. Mosterman for reviewing my thesis and for the interesting discussions at my defence. Thank you to Dr. Vera Pantelic for her indispensable input and guidance. It was a pleasure to work with you over the years. Many thanks to my colleagues and friends from the McMaster Centre for Software Certification (McSCert). I have immensely enjoyed publishing, developing tools, and working with such a dynamic group. Thank you to Stephen Scott for his collaboration on content presented in this thesis. vi Table of Contents Descriptive Note............................. ii Dedication................................ iii Abstract.................................v Acknowledgments............................ vi List of Figures.............................. xii List of Tables............................... xv List of Acronyms............................. xvi 1 Introduction.......................1 1.1 Motivation . .1 1.1.1 Why Simulink? . .2 1.2 Research Questions . .4 1.3 Thesis Contributions . .5 1.4 Related Publications and Submissions . .9 1.5 Thesis Outline . 10 2 Preliminaries....................... 11 2.1 Principles for Supporting Likely Changes . 11 2.1.1 Information Hiding . 12 2.1.2 Modularity . 13 2.1.3 Encapsulation . 13 2.1.4 Separation of Concerns . 14 2.1.5 Object-Orientation . 14 2.1.6 Aspect-Orientation . 15 2.2 Simulink . 15 2.2.1 Subsystems . 17 vii 2.2.1.1 Virtual Subsystem . 19 2.2.1.2 Nonvirtual Subsystem . 21 2.2.2 Library . 25 2.2.3 Model Reference . 26 2.2.4 Data Passing . 28 2.2.4.1 Data Store Memory . 28 2.2.4.2 Goto, From, and Goto Tag Visibility . 29 2.2.5 Workspaces and Data Dictionaries . 29 2.2.6 Exporting Data . 30 2.2.7 Stateflow . 30 2.3 C to Simulink Concept Mapping . 31 2.4 Chapter Summary . 32 3 Model Changes...................... 33 3.1 Related Work . 34 3.2 Methodology . 36 3.2.1 Tool Support . 38 3.2.2 Model Comparison Utility . 40 3.3 Changes in Simulink Models . 42 3.3.1 What basic elements change the most? . 44 3.3.2 What blocks are most often involved in changes? . 46 3.3.3 What does a commit usually entail? . 47 3.3.4 What are identified categories of change? . 50 3.3.4.1 Changes to Interface Elements . 54 3.3.4.2 Changes to Signal Routing and Attributes . 55 3.4 Chapter Summary . 56 4 Decomposition of Simulink Models............ 57 4.1 Related Work . 58 4.2 Comparison of Constructs . 60 4.2.1 Use in Industry . 61 4.2.2 Reusability . 64 4.2.3 Sharing of Program State . 66 4.2.4 Information Hiding and Encapsulation . 68 4.2.4.1 Limitation of Use . 69 viii 4.2.4.2 Restriction of Data Passing . 70 4.2.5 Code Generation . 78 4.2.6 Comparison Summary . 81 4.3 Conversion and Limitations . 82 4.4 Conventions for Modularity . 83 4.5 Chapter Summary . 85 5 A Simulink Module Structure............... 87 5.1 Related Work . 88 5.1.1 Model Structure . 88 5.1.2 Interfaces . 91 5.2 A Simulink Module . 92 5.3 A Simulink Module Interface . 94 5.3.1 Definition . 96 5.3.2 Limitations . 101 5.3.3 Representation . 102 5.3.4 Benefits . 102 5.4 Modelling Guidelines . 105 5.4.1 Simulink Functions . 105 5.4.2 Interfaces . 108 5.5 The Simulink Module Tool . 111 5.5.1 Subsystem to Simulink Function Conversion . 111 5.5.2 Scope Changes . 112 5.5.3 Function Calling . 114 5.5.4 Automatic Function Configuration . 115 5.5.5 Interface Generation . 116 5.5.6 Dependency Viewing . 117 5.5.7 Guideline Checking . 117 5.6 Chapter Summary . 117 6 Case Studies....................... 120 6.1 Evaluation Methods . 120 6.1.1 Design Equivalence . 121 6.1.2 Information Hiding . 123 6.1.3 Interface Complexity . 123 ix 6.1.4 Coupling and Cohesion . 124 6.1.5 Cyclomatic Complexity . 125 6.1.6 Testability . 126 6.1.7 Performance Comparison . 127 6.2 Aerospace Case Study . 127 6.2.1 Flight Control Computer(FCC) Components . 128 6.2.1.1 Attitude and Heading Reference System (AHRS) Voter . 128 6.2.1.2 Helicopter Outer Loop Control(HOLC).... 132 6.2.1.3 Helicopter Inner Loop Control(HILC)..... 132 6.2.1.4 Actuator Loop(AL)............... 133 6.2.2 Application of the Simulink Module Structure . 133 6.2.2.1 Attitude and Heading Reference System (AHRS) Voter . 134 6.2.2.2 Attitude and Heading Reference System (AHRS) Control . 135 6.2.2.3 Actuator Loop(AL)............... 139 6.2.3 Using the Simulink Module Tool . 139 6.2.4 Evaluation . 140 6.2.4.1 Information Hiding . 141 6.2.4.2 Interface Complexity . 142 6.2.4.3 Coupling and Cohesion . 143 6.2.4.4 Cyclomatic Complexity . 145 6.2.4.5 Testability . 146 6.2.4.6 Performance Comparison . 147 6.2.5 Case Study Summary . 147 6.3 Nuclear Case Study . 148 6.3.1 Application of the Simulink Module Structure . 149 6.3.1.1 Power Estimation(PE) Module . 149 6.3.1.2 Entire Shut Down System(SDS)........ 150 6.3.2 Using the Simulink Module Tool . 153 6.3.3 Evaluation . 157 6.3.3.1 Information Hiding . 157 6.3.3.2 Interface Complexity . 158 x 6.3.3.3 Coupling and Cohesion . 159 6.3.3.4 Cyclomatic Complexity . 161 6.3.3.5 Testability . 163 6.3.3.6 Performance Comparison . 163 6.3.4 Case Study Summary . 164 6.4 Challenges and Limitations . 165 6.4.1 Variable-Step Solvers and Continuous States . 165 6.4.2 Inheriting Sample Time . 166 6.4.3 Block States . 166 6.4.4 Algebraic Loops . 167 7 Conclusion........................ 172 7.1 Summary of Contributions . 172 7.2 Future Work . 174 7.3 Closing Remarks . 177 A Construct Comparison Generated Code.......... 178 A.1 Virtual Subsystem Generated Code . 178 A.2 Atomic Subsystem Generated Code . 183 A.3 Simulink Function Generated Code . 188 A.4 Library Import Generated Code . 193 A.5 Model Reference Generated Code . 198 Bibliography....................... 207 xi List of Figures 2.1 Simplified Simulink metamodel. 16 2.2 A simple Simulink example computing integer sums. 18 2.3 Summary of subsystems, classified as virtual and non-virtual. ..
Load more

Recommended publications
  • Automated Annotation of Simulink Generated C Code Based on the Simulink Model
    DEGREE PROJECT IN COMPUTER SCIENCE AND ENGINEERING, SECOND CYCLE, 30 CREDITS STOCKHOLM, SWEDEN 2020 Automated Annotation of Simulink Generated C Code Based on the Simulink Model SREEYA BASU ROY KTH ROYAL INSTITUTE OF TECHNOLOGY SCHOOL OF ELECTRICAL ENGINEERING AND COMPUTER SCIENCE Automated Annotation of Simulink Generated C Code Based on the Simulink Model SREEYA BASU ROY Master in Embedded Systems Date: September 25, 2020 Supervisor: Predrag Filipovikj Examiner: Matthias Becker School of Electrical Engineering and Computer Science Host company: Scania CV AB Swedish title: Automatisk Kommentar av Simulink Genererad C kod Baserad på Simulink Modellen iii Abstract There has been a wave of transformation in the automotive industry in recent years, with most vehicular functions being controlled electron- ically instead of mechanically. This has led to an exponential increase in the complexity of software functions in vehicles, making it essential for manufactures to guarantee their correctness. Traditional software testing is reaching its limits, consequently pushing the automotive in- dustry to explore other forms of quality assurance. One such technique that has been gaining momentum over the years is a set of verification techniques based on mathematical logic called formal verification tech- niques. Although formal techniques have not yet been adopted on a large scale, these methods offer systematic and possibly more exhaus- tive verification of the software under test, since their fundamentals are based on the principles of mathematics. In order to be able to apply formal verification, the system under test must be transformed into a formal model, and a set of proper- ties over such models, which can then be verified using some of the well-established formal verification techniques, such as model check- ing or deductive verification.
    [Show full text]
  • Lecture #4: Simulation of Hybrid Systems
    Embedded Control Systems Lecture 4 – Spring 2018 Knut Åkesson Modelling of Physcial Systems Model knowledge is stored in books and human minds which computers cannot access “The change of motion is proportional to the motive force impressed “ – Newton Newtons second law of motion: F=m*a Slide from: Open Source Modelica Consortium, Copyright © Equation Based Modelling • Equations were used in the third millennium B.C. • Equality sign was introduced by Robert Recorde in 1557 Newton still wrote text (Principia, vol. 1, 1686) “The change of motion is proportional to the motive force impressed ” Programming languages usually do not allow equations! Slide from: Open Source Modelica Consortium, Copyright © Languages for Equation-based Modelling of Physcial Systems Two widely used tools/languages based on the same ideas Modelica + Open standard + Supported by many different vendors, including open source implementations + Many existing libraries + A plant model in Modelica can be imported into Simulink - Matlab is often used for the control design History: The Modelica design effort was initiated in September 1996 by Hilding Elmqvist from Lund, Sweden. Simscape + Easy integration in the Mathworks tool chain (Simulink/Stateflow/Simscape) - Closed implementation What is Modelica A language for modeling of complex cyber-physical systems • Robotics • Automotive • Aircrafts • Satellites • Power plants • Systems biology Slide from: Open Source Modelica Consortium, Copyright © What is Modelica A language for modeling of complex cyber-physical systems
    [Show full text]
  • Introduction to Simulink
    Introduction to Simulink Mariusz Janiak p. 331 C-3, 71 320 26 44 c 2015 Mariusz Janiak All Rights Reserved Contents 1 Introduction 2 Essentials 3 Continuous systems 4 Hardware-in-the-Loop (HIL) Simulation Introduction Simulink is a block diagram environment for multidomain simulation and Model-Based Design. It supports simulation, automatic code generation, and continuous test and verification of embedded systems.1 Graphical editor Customizable block libraries Solvers for modeling and simulating dynamic systems Integrated with Matlab Web page www.mathworks.com 1 The MathWorks, Inc. Introduction Simulink capabilities Building the model (hierarchical subsystems) Simulating the model Analyzing simulation results Managing projects Connecting to hardware Introduction Alternatives to Simulink Xcos (www.scilab.org/en/scilab/features/xcos) OpenModelica (www.openmodelica.org) MapleSim (www.maplesoft.com/products/maplesim) Wolfram SystemModeler (www.wolfram.com/system-modeler) Introduction Model based design with Simulink Modeling and simulation Multidomain dynamic systems Nonlinear systems Continuous-, Discrete-time, Multi-rate systems Plant and controller design Rapidly model what-if scenarios Communicate design ideas Select/Optimize control architecture and parameters Implementation Automatic code generation Rapid prototyping for HIL, SIL Verification and validation Essentials Working with Simulink Launching Simulink Library Browser Finding Blocks Getting Help Context sensitive help Simulink documentation Demo Working with a simple model Changing
    [Show full text]
  • FMI Target for Simulink Coder, It Is Now Possible to Export Models from Simulink to Any Platform That Supports Fmus for Co-Simulation
    Supporting your vision Cross-Platform Modeling with FMI Target for Simulink® Coder™ Open technology standards for an integrated product lifecycle Engine Transmission Thermal EV/HV Chassis Compo- Models Models Systems Models nents Models Functional Mock-Up Interface The challenge for manufacturers of complex machinery that heavily rely on components from suppliers is the seamless exchange of data and specifications during the development. The same holds true for large corporates with multiple R&D departments at various locations using several development tools due to different objectives. Those challenges include different programming languages from the various tools, the lack of standardized model interfaces and the concerns for the protection of intellectual property. The development of the Functional Mock-up Interface (FMI) has enabled software-, model- and hardware-in-the-loop simulations with dynamic system models from different software environments. With the FMI Target for Simulink Coder, it is now possible to export models from Simulink to any platform that supports FMUs for Co-Simulation. FMI for Co-Simulation The goal is to couple two or more models with solvers in a co-simulation environment. The data exchange between subsystems is restricted to discrete communication points. The subsystems are processed independently from each other by their individual solvers during the time interval between two communication points. Master algorithms control the synchronization of all slave simulation solvers and the data exchange between the subsystems. The interface allows for both standard and advanced master algorithms, such as variable communication step sizes, signal extrapolation of higher order and error checking. FMI Target for Simulink® Coder™ FMI for Co-Simulation For the exchange of models across different platforms, the FMI Target for Simulink Coder enables the export of models from Simulink as FMUs for Co-Simulation.
    [Show full text]
  • Modeling and Simulation in Scilab/Scicos Mathematics Subject Classification (2000): 01-01, 04-01, 11 Axx, 26-01
    Stephen L. Campbell, Jean-Philippe Chancelier and Ramine Nikoukhah Modeling and Simulation in Scilab/Scicos Mathematics Subject Classification (2000): 01-01, 04-01, 11 Axx, 26-01 Library of Congress Control Number: 2005930797 ISBN-10: 0-387-27802-8 ISBN-13: 978-0387278025 Printed on acid-free paper. © 2006 Springer Science + Business Media, Inc. All rights reserved. This work may not be translated or copied in whole or in part without the written permission of the publisher (Springer Science+Business Media, Inc., 233 Spring Street, New York, NY 10013, USA), except for brief excerpts in connection with reviews or scholarly analysis. Use in connection with any form of information storage and retrieval, electronic adaption, computer software, or by similar or dissimilar methodology now known or hereafter developed is forbidden. The use in this publication of trade names, trademarks, service marks, and similar terms, even if they are not identified as such, is not to be taken as an expression of opinion as to whether or not they are subject to proprietary rights. Printed in the United States of America. (BPR/HAM) 9 8 7 6 5 4 3 2 1 springeronline.com Preface Scilab (http://www.scilab.org) is a free open-source software package for scientific com- putation. It includes hundreds of general purpose and specialized functions for numerical computation, organized in libraries called toolboxes that cover such areas as simulation, optimization, systems and control, and signal processing. These functions reduce consid- erably the burden of programming for scientific applications. One important Scilab toolbox is Scicos. Scicos (http://www.scicos.org) provides a block-diagram graphical editor for the construction and simulation of dynamical sys- tems.
    [Show full text]
  • A Modelica Power System Library for Phasor Time-Domain Simulation
    2013 4th IEEE PES Innovative Smart Grid Technologies Europe (ISGT Europe), October 6-9, Copenhagen 1 A Modelica Power System Library for Phasor Time-Domain Simulation T. Bogodorova, Student Member, IEEE, M. Sabate, G. Leon,´ L. Vanfretti, Member, IEEE, M. Halat, J. B. Heyberger, and P. Panciatici, Member, IEEE Abstract— Power system phasor time-domain simulation is the FMI Toolbox; while for Mathematica, SystemModeler often carried out through domain specific tools such as Eurostag, links Modelica models directly with the computation kernel. PSS/E, and others. While these tools are efficient, their individual The aims of this article is to demonstrate the value of sub-component models and solvers cannot be accessed by the users for modification. One of the main goals of the FP7 iTesla Modelica as a convenient language for modeling of complex project [1] is to perform model validation, for which, a modelling physical systems containing electric power subcomponents, and simulation environment that provides model transparency to show results of software-to-software validations in order and extensibility is necessary. 1 To this end, a power system to demonstrate the capability of Modelica for supporting library has been built using the Modelica language. This article phasor time-domain power system models, and to illustrate describes the Power Systems library, and the software-to-software validation carried out for the implemented component as well as how power system Modelica models can be shared across the validation of small-scale power system models constructed different simulation platforms. In addition, several aspects of using different library components. Simulations from the Mo- using Modelica for simulation of complex power systems are delica models are compared with their Eurostag equivalents.
    [Show full text]
  • OMG Sysphs: Integrating Sysml, Simulink, Modelica And
    OMG SysPhs: Integrating SysML, Simulink, Modelica and FMI | ref.: 3DS_Document_2015 | ref.: 2/13/20 | Confidential Information | Information | Confidential Nerijus Jankevicius Systèmes CATIA | No Magic Dassault © INCOSE IW, Torrance, Jan 27, 2020 3DS.COM System Model as an Integration Framework © 2012-2014 by Sanford Friedenthal SysML as co-simulation environment 35 Reduce and standardize mappings 4 Unified Physics Domain Flowing Substance Flow rate Potential to flow Electrical Charge Current Voltage Hydraulic Volume Volumetric flow rate Pressure Rotational Angular momentum Torque Angular velocity Translational Linear momentum Force Velocity Thermal Entropy Entropy flow Temperature flow rate = amount of substance/time flow rate * potential = energy / time = power The Standard : SysPhs •SysPhS - https://www.omg.org/spec/SysPhS/1.0 • SysML Mapping to SiMulink and Modelica • SysPhS profile • SysPhS library Simulation profile Modelica vs Simulink • Modelica • SiMulink • Language is better suited for physical • Language is well-suited for control modeling (plant) algorithMs • Object oriented approach for • TransforMational seMantics of signals modeling physical and signal processing coMponents (Mechanical, electrical, etc.) • Causal seMantics (inputs -> outputs) • Causal and A-Causal seMantics • Well integrated into the “MATLAB (equations) universe” • Open standard (of the textual • Widely used in industry (standard de- language) facto) • Multi tool support (although DyMola • Many existing tool integrations is doMinant) • Code generation to
    [Show full text]
  • TPT Tutorial
    Time Partition Testing Systematic automated testing of embedded systems PikeTec GmbH, http://www.piketec.com There are only a few tools for testing embedded systems in the automotive domain. Their function usually lies in the test-management or automation of tests by means of test scripts. Time Partition Testing (TPT) noticeably exceeds this. It combines a systematic and very graphic modelling technique for test cases with a fully automatic test execution in different environments and automatic test evaluation in a unique way. In doing so, TPT even supports testing of control systems. Time Partition Testing (TPT) was developed to graphically and compactly model tests of embedded systems – especially those with continuous behaviour –, to automate those tests and to offer a systematic that supports the tester in selecting an ideal amount of test cases. The intuitive graphic modelling technique for test cases, the mechanisms for the structuring of complex test problems, the simple integration in any test- bench and a number of additional interesting features makes TPT a unique test solution. All this has contributed to TPT becoming the central testing tool in a large number of development projects at car manufacturers and suppliers and has become an integral part of the process chain. Embedded systems TPT is specialized on testing embedded systems whose inputs and outputs can be represented as signals. Most control systems belong to this system class. The implementation language of the embedded system (e.g. ‘C’ code, C++, MATLAB/Simulink/Stateflow, Statemate or a combination of multiple languages) is irrelevant for TPT. TPT does not require a particular implementation language.
    [Show full text]
  • Tpt Test Design and Test Generation
    TPT IN A NUTSHELL TPT TEST DESIGN DASHBOARD ASSESSMENT TRACEABILITY OF TESTING SAFETY TPT is a tool for functional testing of embed- AND TEST User interfaces can be designed for expe- OF TESTS AND REQUIREMENTS AND SYSTEMS PikeTec GmbH ded software interfacing a huge number of riments with a System under Test. Manual standard development tools. GENERATION validation, test observation and interaction REPORTING TEST CASES TPT supports qualified testing and Waldenserstr. 2 - 4 are possible. verification of safety related systems. 10551 Berlin | Germany TPT is suitable for all development phases. Expressing test cases with TPT is both, TPT supports fully automated assessment TPT supports analysis and coverage Tel. +49 30 394 096 830 TPT can be used for MiL, SiL, PiL, HiL powerful and easy to handle. The Dashboard is a powerful feature and documentation of test results including examination of requirements and tests. Safety standard directives can be satisfied Mail. [email protected] and in vehicles. of TPT for many reasons: Requirements can be imported from while testing with TPT up to the highest EMBEDDED TESTING Use automatons for structuring test phases: several formats and tools. safety level. Related standards are: www.piketec.com Back-to-Back testing with relative Tests can be created graphically by the Dashboards can be used for exper- and absolute tolerances STARTS HERE user or generated automatically. INIT imental testing long before test design Requirements can be analyzed, linked ISO 26262 light on Pass and fail criteria Dashboards can also be used to test cases and reported along with IEC 61508 IF Test phase 2 Powerful signal pattern The tests are executed, assessed and bright changing light together with automated tests the tests.
    [Show full text]
  • Vissim User's Guide
    Version 8.0 VisSim User's Guide By Visual Solutions, Inc. Visual Solutions, Inc. VisSim User's Guide Version 8.0 Copyright © 2010 Visual Solutions, Inc. Visual Solutions, Inc. All rights reserved. 487 Groton Road Westford, MA 01886 Trademarks VisSim, VisSim/Analyze, VisSim/CAN, VisSim/C-Code, VisSim/C- Code Support Library source, VisSim/Comm, VisSim/Comm C-Code, VisSim/Comm Red Rapids, VisSim/Comm Turbo Codes, VisSim/Comm Wireless LAN, VisSim/Fixed-Point, VisSim/Knobs & Gauges, VisSim/Model-Wizard, VisSim/Motion, VisSim/Neural-Net, VisSim/OPC, VisSim/OptimzePRO, VisSim/Real-TimePRO, VisSim/State Charts, VisSim/Serial, VisSim/UDP, VisSim Viewer,and flexWires are trademarks of Visual Solutions. All other products mentioned in this manual are trademarks or registered trademarks of their respective manufacturers. Copyright and use The information in this manual is subject to change without notice and restrictions does not represent a commitment by Visual Solutions. Visual Solutions does not assume any responsibility for errors that may appear in this document. No part of this manual may be reprinted or reproduced or utilized in any form or by any electronic, mechanical, or other means without permission in writing from Visual Solutions. The Software may not be copied or reproduced in any form, except as stated in the terms of the Software License Agreement. Acknowledgements The following engineers contributed significantly to preparation of this manual: Mike Borrello, Allan Corbeil, and Richard Kolk. Contents Introduction 1 What is VisSim.........................................................................................................................
    [Show full text]
  • FMI TOOLBOX for MATLAB®/Simulink
    FMI TOOLBOX for MATLAB®/Simulink SCOPE KEY FEATURES BENEFITS • Integration of physical models • Export and import of Model Exchange and • Reduced time and cost for development of in MATLAB®/Simulink Co-Simulation FMUs control systems supported by physical models • Dynamic simulation • Simulink blockset and MATLAB script interface • Leverage state of the art physical modeling tools • Control system development • Design of Experiments and design space exploration • Maintain flexibility with the FMI standard • HIL simulation on dSPACE DS1006 systems MI Toolbox for MATLAB®/Simulink MATLAB®/Simulink environment. Fenables easy to use integration of Support for the FMI standard ensures THE FUNCTIONAL physical models developed in state of flexibility and cross-platform inter- MOCK-UP INTERFACE the art modeling tools in the MATLAB®/ operability. The Functional Mock-up Interface Simulink environment. The toolbox (FMI) is an open standard for exchange of The Toolbox enables simulation of dynamic models, targeting tool interoper- relies on the open FMI standard and is FMUs as part of Simulink models and ability and model reuse. FMI compliant ideal for control systems development. in MATLAB scripts. In addition, Simu- models (Functional Mock-up Units (FMUs)), High-fidelity physical models are key link models can be exported into Model are self-contained compiled models components in development of control Exchange or Co-simulation FMUs. which can be integrated in a wide range of applications where dynamic models are systems and contribute to increased Hardware In the Loop (HIL) simulation is needed. Modeling IP is protected since quality and shorter development cycles. supported on dSPACE DS1006 systems. only compiled code and interface defini- Modeling languages such as Modelica tions are distributed in FMUs.
    [Show full text]
  • Deploying Teamcenter MBSE Integration Gateway
    SIEMENS Teamcenter MBSE Integration Gateway 4.2 Deploying Teamcenter MBSE Integration Gateway PLM00189 • 4.2 Contents Getting started with Teamcenter MBSE Integration Gateway . 1-1 What is Teamcenter MBSE Integration Gateway? . 1-1 Understanding the Model Management Gateway framework . 1-2 Understanding System Analysis . 1-2 Understanding the different integration modes . 1-3 Installing Teamcenter MBSE Integration Gateway . 2-1 Overview of installing Teamcenter MBSE Integration Gateway . 2-1 Installing Teamcenter MBSE Integration Gateway on a Teamcenter server . 2-2 Install MBSE Integration Gateway on a supported Teamcenter environment . 2-2 Install Teamcenter MBSE Integration Gateway features on a 2-tier or 4-tier Teamcenter server . 2-3 Update the Teamcenter MBSE Integration Gateway patch . 2-5 Installing Teamcenter MBSE Integration Gateway on a local machine . 2-7 Install the Teamcenter MBSE Integration Gateway client . 2-7 Install only the Behavior Modeling client for Simcenter Amesim and Simcenter System Synthesis integration . 2-8 Install Teamcenter MBSE Integration Gateway features using Deployment Center . 2-10 Configuring Teamcenter MBSE Integration Gateway . 3-1 Performing server-side configurations for Teamcenter MBSE Integration Gateway . 3-1 Mapping the data using the integration definition file . 3-1 Set up common connector-based integration . 3-7 Enable the Active Workspace Open in Tool command . 3-9 Configure an analysis request . 3-11 Classifying models . 3-13 Create behavior modeling objects in Teamcenter . 3-14 Performing client-side configurations for Teamcenter MBSE Integration Gateway . 3-14 Set up context and target folders . 3-14 Set up the cache directory . 3-16 Enable data logging . 3-16 Enable support for multiple instances of Teamcenter MBSE Integration Gateway .
    [Show full text]