
<p><strong>LITERATURE REVIEW IN THE FIELDS OF STANDARDS, PROJECTS, INDUSTRY AND SCIENCE </strong></p><p>DOCUMENT TYPE: DELIVERABLE N<sup style="top: -0.29em;">0</sup>: </p><p><strong>DELIVERABLE D1.1 </strong></p><p>DISTRIBUTION LEVEL: <strong>PUBLIC </strong>DATE: </p><p><strong>11/07/2016 </strong></p><p>VERSION: </p><p><strong>FINAL </strong></p><p><strong>AUTHOR(S): </strong></p><p>LEONID LICHTENSTEIN, FLORIAN RIES, MICHAEL VÖLKER, JOS HÖLL, CHRISTIAN KÖNIG (TWT); JOSEF ZEHETNER (AVL); OLIVER KOTTE, ISIDRO CORAL, LARS MIKELSONS (BOSCH); NICOLAS AMRINGER, STEFFEN BERINGER, JANEK JOCHHEIM, STEFAN WALTER (DSPACE); CORINA MITROHIN, NATARAJAN NAGARAJAN (ETAS); TORSTEN BLOCHWITZ (ITI); DESHENG FU (LUH); TIMO HAID (PORSCHE); JEAN- MARIE QUELIN (RENAULT); RENE SAVELSBERG, SERGE KLEIN (RWTH); PACOME MAGNIN, BRUNO LACABANNE (SIEMENS); VIKTOR SCHREIBER (TU-IL); MARTIN KRAMMER, NADJA MARKO, MARTIN BENEDIKT, STEFAN THONHOFER, GEORG STETTINGER, MARKUS TRANNINGER (VIF); THIES FILLER (VW) </p><p><strong>REVIEWED: APPROVED: </strong></p><p>BRUNO LACABANNE (SIEMENS), JEAN-MARIE QUELIN (RENAULT), VALENTIN IVANOV (TUIL), JOSEF ZEHETNER (AVL), NADJA MARKO (VIF) </p><p>LEONID LICHTENSTEIN (TWT), MARTIN BENEDIKT (VIF) </p><p></p><ul style="display: flex;"><li style="flex:1">D1.1 </li><li style="flex:1">ACOSAR </li></ul><p></p><p>PROJECT ACRONYM: PROJECT TITLE: </p><p><strong>ACOSAR ADVANCED CO-SIMULATION OPEN SYSTEM ARCHITECTURE 14004 </strong></p><p>ITEA PROJECT N<sup style="top: -0.29em;">0</sup>: CHALLENGE: </p><p><strong>ENGINEERING </strong></p><p>PROJECT DURATION: PROJECT WEBSITE: COORDINATION: PROJECT LEADER: </p><p><strong>01/09/2015 - 31/08/2018 </strong><a href="/goto?url=http://www.acosar.eu/" target="_blank"><strong>WWW.ACOSAR.EU </strong></a><strong>VIRTUAL VEHICLE RESEARCH CENTER (AT) DR. MARTIN BENEDIKT </strong></p><p></p><ul style="display: flex;"><li style="flex:1">14004 – Deliverable D1.1 – Distribution Level: Public </li><li style="flex:1">2 / 126 </li></ul><p></p><ul style="display: flex;"><li style="flex:1">D1.1 </li><li style="flex:1">ACOSAR </li></ul><p></p><ul style="display: flex;"><li style="flex:1">14004 – Deliverable D1.1 – Distribution Level: Public </li><li style="flex:1">3 / 126 </li></ul><p></p><ul style="display: flex;"><li style="flex:1">D1.1 </li><li style="flex:1">ACOSAR </li></ul><p></p><p><strong>1 Contents </strong></p><p><a href="#4_0">1</a><a href="#5_0">2</a><a href="#7_0">3</a><a href="#8_0">4</a><br><a href="#4_0">Contents........................................................................................................................ 4 </a><a href="#5_0">Executive summary......................................................................................................... 5 </a><a href="#7_0">Introductio</a><a href="#7_0">n</a><a href="#7_0">.</a><a href="#7_0">.................................................................................................................. 7 </a><a href="#8_0">State of the Art .............................................................................................................. 8 </a></p><ul style="display: flex;"><li style="flex:1"><a href="#8_1">4.1 </a></li><li style="flex:1"><a href="#8_1">(Distributed) Discrete-Event Simulation ....................................................................... 8 </a></li></ul><p><a href="#12_0">(Distributed) Continuous Simulatio</a><a href="#12_0">n</a><a href="#12_0">.</a><a href="#12_0">..........................................................................12 </a><a href="#17_0">(Distributed) Hybrid Simulation .................................................................................17 </a><a href="#0_0">(Distributed)Real-Time Simulation .............................................................................22 </a><a href="#0_1">Communication Standards ........................................................................................27 </a><a href="#0_0">Real-Time System</a><a href="#0_0">s</a><a href="#0_0">.</a><a href="#0_0">.................................................................................................45 </a><a href="#0_0">Interoperability and Related Standard</a><a href="#0_0">s</a><a href="#0_0">.</a><a href="#0_0">......................................................................50 </a><a href="#0_0">Requirements, Modelling, Design, and Specification for Integratio</a><a href="#0_0">n</a><a href="#0_0">.</a><a href="#0_0">................................70 </a><a href="#0_2">Related Research Projects.........................................................................................75 </a><br><a href="#12_0">4.2 </a><a href="#17_0">4.3 </a><a href="#0_0">4.4 </a><a href="#0_1">4.5 </a><a href="#0_0">4.6 </a><a href="#0_0">4.7 </a><a href="#0_0">4.8 </a><a href="#0_2">4.9 </a></p><ul style="display: flex;"><li style="flex:1"><a href="#0_0">5</a></li><li style="flex:1"><a href="#0_0">Overview of State of Practice and Used Tool</a><a href="#0_0">s</a><a href="#0_0">.</a><a href="#0_0">....................................................................98 </a></li></ul><p></p><ul style="display: flex;"><li style="flex:1"><a href="#0_3">5.1 </a></li><li style="flex:1"><a href="#0_3">Introduction............................................................................................................98 </a></li></ul><p><a href="#0_4">Used Tools..............................................................................................................98 </a><a href="#0_5">Summary and Conclusion ......................................................................................</a><a href="#0_5">.</a><a href="#0_5">1</a><a href="#0_5">14 </a><br><a href="#0_4">5.2 </a><a href="#0_5">5.3 </a><br><a href="#0_0">6</a><a href="#0_0">7</a><a href="#0_0">8</a><a href="#0_0">9</a><br><a href="#0_0">Discussion and Conclusion............................................................................................</a><a href="#0_0">.</a><a href="#0_0">1</a><a href="#0_0">16 </a><a href="#0_0">Glossar</a><a href="#0_0">y</a><a href="#0_0">.</a><a href="#0_0">...................................................................................................................</a><a href="#0_0">.</a><a href="#0_0">1</a><a href="#0_0">18 </a><a href="#0_0">References.................................................................................................................</a><a href="#0_0">.</a><a href="#0_0">1</a><a href="#0_0">21 </a><a href="#0_0">Acknowledgment ........................................................................................................</a><a href="#0_0">.</a><a href="#0_0">1</a><a href="#0_0">26 </a></p><p></p><ul style="display: flex;"><li style="flex:1">14004 – Deliverable D1.1 – Distribution Level: Public </li><li style="flex:1">4 / 126 </li></ul><p></p><ul style="display: flex;"><li style="flex:1">D1.1 </li><li style="flex:1">ACOSAR </li></ul><p></p><p><strong>2 Executive summary </strong></p><p>The main goal of ACOSAR is to develop a non-proprietary real time (RT) co-simulation interface. This document presents a survey of the relevant state of the art and state of practice. Different technical domains that are relevant for the ACOSAR project were analysed, reviewed and summarized. A short summary of every chapter is presented in the following. </p><p><strong>Discrete-Event Simulation </strong>is a simulation method, where the operation is represented as a chronological sequence of events. There are various synchronization algorithms which are optimized for different systems and environments. These algorithms are relevant for ACOSAR in terms of the synchronized exchange of information between simulators and RT systems and have to be considered during the specification of the advanced co-simulation interface (ACI). </p><p><strong>Continuous Simulation </strong>serves as fundamental basis for numerical investigation of dynamic system behaviours and powerful explicit and implicit numerical solvers were developed for dedicated classes of systems. In contrast to numerical simulation, recently several approaches were published with respect to event-based simulation of continuous system dynamics, leading to significant benefits in terms of accuracy and simulation time reduction. Both approaches will be considered and incorporated into ACOSAR results. </p><p><strong>Hybrid Simulation </strong>represents an approach, where continuous and discrete system behaviours are handled. As cross-domain considerations of embedded systems and mechatronic products is mandatory hybrid system analysis become more and more relevant. Recently discussed approaches for simulation of hybrid systems are considered for ACI specification within ACOSAR to enable and support a common approach for integration if Real-Time Systems. </p><p><strong>Real-time simulation </strong>aims at providing the right information and data at the right time, while an actual system is operating. This type of simulation is typically employed in the later stages of a system development cycle, when real components are integrated and run in parallel to simulated systems. A large variety of real-time simulation approaches exists in the literature and practice. </p><p>ACOSAR’s goal is, therefore, to identify, tailor, and extend existing techniques in real-time </p><p>simulation to generate a standard interface for such simulations. In a co-simulation scenario, the <strong>communication layer </strong>realizes the data transmission between </p><p>the different participating systems. ACOSAR’s goal is to define a certain level of communication </p><p>protocol abstraction such that various existing communication protocols can be supported. The large group of existing communication standards can be roughly categorized in internet protocol (IP) based, automotive and industrial standards. Each category has its own applications. The ACI communication layer should be able to support a large variety of communication standards to make sure that all desired use cases can be properly addressed. The ACI communication layer should therefore be flexible enough to support the given communication standards while it can still be extended to support some additional communication standards in the future. </p><p>A <strong>real-time system </strong>is a combination of soft- and hardware that must process information and produce a response within a specified time. Usually it consists of a physical component and a controller, an entity observing and eventually controlling the physical part. Structured approaches and requirements have been reported in the literature for networked real-time systems, e.g., in terms of timeliness, predictability, efficiency, robustness, fault tolerance, and maintainability. Within ACOSAR, the challenge will be to close gaps between existing solutions at the levels of the simulation tool interface, communication protocol and the hardware interface. </p><p>Several <strong>interoperability standards </strong>exist for the integration of RT systems and non-RT systems. The review shows that there is an ongoing strong interest and effort to standardize interfaces of systems to further streamline the systems development process. None of the reviewed standards concerns a generic interface for executing RT co-simulations. Nevertheless, within ACOSAR, some concepts from existing standards shall be considered for reuse. </p><p></p><ul style="display: flex;"><li style="flex:1">14004 – Deliverable D1.1 – Distribution Level: Public </li><li style="flex:1">5 / 126 </li></ul><p></p><ul style="display: flex;"><li style="flex:1">D1.1 </li><li style="flex:1">ACOSAR </li></ul><p></p><p><strong>System modelling languages</strong>, like the Unified Modelling Language (UML), support requirements engineering, specification, analysis, design as wells as verification and validation of systems. Many system problems result from inadequately defined interfaces. These problems are often detected too late in the development process. The ACI aims at providing clear interface specifications for RT system integration at different development stages. The use of modelling languages for interface specification is favourable as it provides a way to continuous refinement through the use of recurring interface information. </p><p>A large set of recent and ongoing <strong>research projects </strong>was reviewed. A clear trend towards integrated, holistic approaches to model-based systems engineering in real time, across domains and enterprises with a focus on openness and standards was determined. ACOSAR aims for exactly this openness and flexibility in the systems development process. However, ACOSAR also faces the challenge of suiting a large group of divers use cases. </p><p>ACOSAR partners have provided information on their <strong>commonly used tools </strong>which clearly reflect the current state of practice within the consortium. The integration of RT systems is, however, limited due to the use of proprietary interfaces. ACOSAR aims on designing an open RT cosimulation interface. Further, the usage of the ACI can be ensured if all tool vendors of the consortium implement the ACI for their tools. </p><p>The comprehensive list of related standards and projects shows that there is a strong attempt to improve interoperability between tools and devices. None of the existing standards provides a generic and flexible interface which enables RT co-simulation. ACOSAR’s goal is to specify such an interface standard allowing a large amount of applications in different domains. To suit different use cases and domains the ACI has to provide the possibility to use different kinds of communication channels and therefore requires an abstraction of the communication layer. </p><p></p><ul style="display: flex;"><li style="flex:1">14004 – Deliverable D1.1 – Distribution Level: Public </li><li style="flex:1">6 / 126 </li></ul><p></p><ul style="display: flex;"><li style="flex:1">D1.1 </li><li style="flex:1">ACOSAR </li></ul><p></p><p><strong>3 Introduction </strong></p><p><em>This report describes the results of the work undertaken in Task 1 of Work Package 1 of the ACOSAR project. </em></p><p>The overall aim of ACOSAR is to develop a non-proprietary real-time co-simulation interface. This </p><p>“Advanced Co-Simulation Interface” (ACI) will be a substantial contribution to international </p><p>standardization activities (e.g. FMI) and will demonstrate a systems integration methodology that will save effort compared to the current state-of-practice. In Work Package 1 our goal is to define a set of requirements to the ACI that are well-structured and feasible. For a better judgement of feasibility and practicality, we have thoroughly investigated the relevant state-of-the-art and the state-of-practice, as described in Task 1.1. The results of the investigations are presented in this report. </p><p><strong>The goal of this deliverable is to present a detailed survey of the relevant state-of-the- </strong></p><p><strong>art and the state-of-practice. </strong>This document constitutes an important and valuable contribution both to the project and to the community. The overview will be a useful reference for the further course of the project. </p><p>To compile the report, the ACOSAR consortium has first identified an extensive collection of scientific publications, research projects, industrial standards and systems engineering tools that are relevant for the project. Subsequently, all these elements were reviewed, their important results and outcomes summarized, and the planned contributions of ACOSAR positioned. Finally, all subdomain specific information was further condensed and conclusions drawn. </p><p>The report is divided into two main chapters: state-of-the-art (Chapter <a href="#8_0">4) </a>and state-of-practice (Chapter <a href="#0_0">5)</a>. Chapter <a href="#0_0">5 </a>is further split into the following subdomains: </p><p></p><p>(Distributed) Discrete-Event Simulation (Distributed) Continuous Simulation (Distributed) Hybrid Simulation (Distributed) Real-Time Simulation Communication Standards Real-Time Systems Interoperability and Related Standards Requirements, Modelling, Design, and Specification for Integration </p><p></p><ul style="display: flex;"><li style="flex:1">14004 – Deliverable D1.1 – Distribution Level: Public </li><li style="flex:1">7 / 126 </li></ul><p></p><ul style="display: flex;"><li style="flex:1">D1.1 </li><li style="flex:1">ACOSAR </li></ul><p></p><p><strong>4 State of the Art </strong></p><p><strong>4.1 (Distributed) Discrete-Event Simulation </strong></p><p><strong>4.1.1 Introduction </strong></p><p>Discrete Event Simulation (DES) is a simulation method, where the operation of the system is represented as a chronological sequence of events. Each event occurs at an instant of time and triggers a change of system states. It is expected that DES takes advantage of the multi-processor environment as many other applications do. As consequence, approaches exist that try to reduce the execution time of DES in multi-processor environments. In the Distributed Discrete Event Simulation (DDES), multiple Physical Processes (PPs) in one computer or several loosely coupled computers are considered. The whole simulation model is partitioned into several components and each of them is implemented as a Logical Process (LP), which is assigned statically or dynamically to a PP. Compared with other simulation methods, DES benefits from the conservative estimation of the time of the next system operation. It provides a fast time advance for many systems, especially when the change of the system is hard to calculate but the time of decisive change is easy to estimate. </p><p>Causality error is the most challenging topic for DDES. It refers to the situation that one LP runs faster than another LP, and it receives an event from that LP with a time stamp that is smaller </p><p>than its current local time, i.e. this event should be processed locally “in the past”. Generally, there </p><p>are two ways to resolve the causality error. When an optimistic time-warp algorithm is applied, the LP rolls back to the time right before the time stamp of the event violating causality, while conservative synchronization algorithm synchronizes all LPs by their local virtual time thereby avoiding such inconsistencies. </p><p><strong>4.1.2 Relevant State of the Art Items </strong></p><p><strong>Parallel and Distributed Simulation Systems </strong></p><p><strong>Publication name </strong></p><p>Parallel and Distributed Simulation Systems </p><p><strong>Authors Year </strong></p><p>Richard M. Fujimoto 2001 </p><p><strong>Reference </strong></p><p><a href="/goto?url=http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=977259" target="_blank">http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=977259 </a></p><p>Print ISBN: 0-7803-7307-3 </p><p><strong>Summary </strong></p><p>This paper discusses the general structure of distributed discrete event simulation and the basic algorithms to avoid / solve causality error. It gives an overview of technologies to distribute the execution of simulation programs over multiple computer systems. Particular emphasis is placed on synchronization (also called time management) algorithms as well as data distribution techniques. </p><p><strong>Project </strong></p><p>N/A. </p><p><strong>ACOSAR relevance </strong></p><p>This paper discusses the general structure of distributed discrete event simulation. The Advanced Co-Simulation Interface (ACI) developed in ACOSAR should provide necessary mechanism so that the structure and the related algorithms could be applied to the simulators connected to ACI. </p><p><strong>Summarized by </strong>Desheng Fu (LUH) </p><p></p><ul style="display: flex;"><li style="flex:1">14004 – Deliverable D1.1 – Distribution Level: Public </li><li style="flex:1">8 / 126 </li></ul><p></p><ul style="display: flex;"><li style="flex:1">D1.1 </li><li style="flex:1">ACOSAR </li></ul><p></p><p><strong>Distributed Simulation: A Case Study in Design and Verification of Distributed Programs </strong></p><p><strong>Publication name </strong></p><p>Distributed Simulation: A Case Study in Design and Verification of Distributed Programs </p><p><strong>Authors Year </strong></p><p>Chandy, K.M.; Misra, J. 1979 </p><p><strong>Reference </strong></p><p><a href="/goto?url=http://ieeexplore.ieee.org/xpl/articleDetails.jsp?&arnumber=1702653" target="_blank">http://ieeexplore.ieee.org/xpl/articleDetails.jsp?&arnumber=1702653 </a></p><p>ISSN: 0098-5589 </p><p><strong>Summary </strong></p><p>In this paper, the most important CMB algorithm is presented. It described a basic architecture of the distributed discrete event simulation without shared variable by all parts of the system. The processes communicate only through messages with their neighbors. The CMB algorithm is aimed to synchronize the processes based on the look-ahead, and provided a solution to solve the deadlock between the processes through nullmessages. The correctness of a distributed system is also proven within the paper. </p><p><strong>Project </strong></p><p>N/A. </p><p><strong>ACOSAR relevance </strong></p><p>In this paper, the most important CMB algorithm (null-message) algorithms is presented. It is still applied today with a few optimizations. This algorithm shows a typical model that how the logical processes (the simulators) communicate with each other to achieve the synchronization. In the ACOSAR project, we should provide a similar channel, so that the simulators could exchange same information. Such an exchange channel might be implemented as a special state exchange in FMI (or similar cosimulation interfaces, e.g. ACI). This might be discussed in the relevant WPs. </p><p><strong>Summarized by </strong>Desheng Fu (LUH) </p><p><strong>Distributed Simulation: Non-committal Barrier Synchronization </strong></p><p><strong>Publication name </strong></p><p>Non-committal Barrier Synchronization </p><p><strong>Authors Year </strong></p><p>Nicol, D. M. 1995 </p><p><strong>Reference Summary </strong></p><p>Parallel Computing 21: 529 - 549 This paper described a very important method for the distributed barrier synchronization. In such systems, all process must be synchronized after the barrier primitive is executed. And they enter the next barrier after the global synchronization. A very popular algorithm for distributed barrier synchronization, called butterfly barrier algorithm is presented in this paper. It provides a balanced solution between the delay of the synchronization and the amount of messages to exchange. </p><p><strong>Project </strong></p><p>N/A. </p><p></p><ul style="display: flex;"><li style="flex:1">14004 – Deliverable D1.1 – Distribution Level: Public </li><li style="flex:1">9 / 126 </li></ul><p></p><ul style="display: flex;"><li style="flex:1">D1.1 </li><li style="flex:1">ACOSAR </li></ul><p></p><p><strong>ACOSAR relevance </strong></p><p>The simulators / processes connected to the ACI, which will be developed in the ACOSAR project, must be synchronized periodically for the state exchange. The synchronization between the simulators is similar as the synchronization in discrete simulation, especially when a state variable will be exchanged only if it has been modified. Thus, the distributed barrier synchronization might also be considered to replace the synchronization organized by a global controller for ACI. In this way, the delay for the synchronization can be reduced, and not all processes must be blocked and wait for the global synchronization. </p>
Details
-
File Typepdf
-
Upload Time-
-
Content LanguagesEnglish
-
Upload UserAnonymous/Not logged-in
-
File Pages126 Page
-
File Size-