Virtual system development is getting more and more important in a plenitude of industrial domains to reduce development times, stranded costs and time-to-market. Co-simulation is a particularly promising approach for modular and interoperable development. In practice the integration and coupling of real-time systems (especially systems of distributed hardware-in-the-loop systems and simulations) still requires enormous efforts. The aim of the ACOSAR project is to develop both a non-proprietary Advanced Co-simulation Interface (ACI) for real-time system integration and an according integration methodology. These proposals shall act as a substantial contribution to international standardization as the Functional Mock-up Interface (FMI) standard laid the foundations for simulations of physical systems. The results of ACOSAR will lead to a modular, considerably more flexible, as well as shorter system development process for numerous industrial domains and will enable the establishment of new business models.
With this paper the ACOSAR project is introduced. ACOSAR is the abbreviation for “Advanced Co-Simulation Open System Architecture". It is an ITEA 3 framework project. ITEA is the EUREKA cluster programme supporting innovative, industry-driven, pre-competitive research and development projects in the area of software-intensive systems and services (SiSS). SiSS are a key driver of innovation in Europe’s most competitive industries, such as automotive, communications, healthcare and aerospace1. ACOSAR is the first project of its kind being proposed and approved in Austria. It is led by VIRTUAL VEHICLE, a renowned automotive research center located in Graz, Austria. As of April 2016, the project is in the midst of its first year. Table 1 shows the key project facts at a glance.
ACOSAR responds to a strong market request in a plenitude of industrial domains: a consistent, seamless (virtual) system development and validation. In order to achieve this, ACOSAR uses a modular co-simulation approach, supporting flexible system development by its modular characteristics, to integrate 1 http://www.itea3.org
National funding agencies, total budget 7.9 million e 15 partners from 3 countries (Austria, France, Germany) 3 OEMs (Porsche, Renault, and Volkswagen)
http://www.acosar.eu domain-specific subsystems. In development stages, where real-time (RT) systems have to be integrated into simulation environments, huge configuration effort is still necessary due to complex system topologies, large numbers of signals, and numerous different parameters of algorithms for signal processing.
Drivetrain
Cooling Simulation Environment
FMU Simulation Environment
Li-Ion Battery
FMU Co(-Csoi-m)SuimlautliaotinonEEnnvviirroonnmmenetnt
Ordinary User PC or Computing Cluster
Smart Functions (e.g. adaptive coupling)
Wireless Wired Interprocess Communication Communication Communication (e.g. BlueTooth®) (e.g. CAN) (e.g. shared mem.)
(e.g. engine testbench)
Proprietary Interface
Functional Mockup Interface (FMI)
Advanced Co-Simulation Interface To enable effective and efficient RT-system integration, ACOSAR will provide innovations on different levels. First, ACOSAR focuses on the specification of a non-proprietary open RT-system interface, a so-called Advanced Co-simulation Interface (ACI) for sharing relevant information for efficient and safe operation of RT-systems, e.g. test beds. A communication architecture (including protocol) will be defined, which will be independent of the used communication systems. A functional framework for coupling strategies, highly efficient data transmission, and support of semantic data processing will supplement this. These aspects are illustrated in Figure 1. Furthermore, a comprehensive methodology for seamless integration of RT-systems during verification, test and validation phases within the development cycles of the classical V-process model will be defined. This methodology will support already existing tool chains, model-based systems engineering approaches, and methods for easy adaption of simulation tools from early development phases to late ones. The latter is supported by a continuous transfer of knowledge as progress in product development is made.
The open ACOSAR ACI not only will make it possible to extend cloudbased simulation applications towards the RT domain, but also to select and apply best-in-class RT-systems to compose a dedicated optimum overall system for specific present problems with reduced error proneness (e.g. interconnection of distributed HiL test beds for specific engineering purposes). Besides spreading such kind of solutions for the benefit of other domains, this also will help to improve the social acceptance of new technologies, e.g. autonomous driving. Furthermore, research on smart functionality including adaptive coupling strategies will be stimulated.
The major results of ACOSAR will be freely available.Thus, ACOSAR contributes to interoperability and open access. It also supports competition and will lead to a modular, more flexible, as well as much shorter system development process and will enable new business models.
The transfer of project results into standardization is the key goal of ACOSAR. Therefore, partners from relevant standardization committees (e.g. FMI/Modelica Association, ASAM) are actively involved to jointly create solutions and extensions to existing standards. To further bridge the gap between the automotive domain and other domains, leading partners from e.g. aviation and rail will be invited to ACOSAR as associated members. Not at least, ACOSAR’s innovations will enable small and medium-sized enterprises (SME) and suppliers from different domains (software tools, HiL systems, test beds,. . . ) getting access to major industries, resulting in more competitive markets in the long term. 3
Related Work The ACOSAR consortium reviewed numerous research projects, scientific papers and industry standards with respect to all relevant fields. This includes topics like modeling and simulation of continuous, discrete and hybrid systems, co-simulation and coupling mechanisms, communication systems, real-time applications as well as systems and safety engineering. The majority of these literature review results will be published in deliverable D1.1.
One of the most relevant standards considered for investigation is the
functional mock-up interface (FMI) standard [
Recent relevant publications include [
Some of the most relevant research projects included AGeSys, ASTERICS, AVANTI, INTO-CPS, MODELISAR, OPENPROD, ACORTA 1 and ACORTA 2, Transformers and VeTeSS. 4 4.1
The ACOSAR Approach
Project Overview and Structure An organizational overview is given in Figure 2. Work package (WP) 1 is named "Open System Architecture Requirements". It builds the foundation for all subsequent WPs and unifies the stakeholder’s views through specification of requirements (for this approach see Section 4.4). WP 2 is titled "Real-time system integration methodology". It focuses on system level activities, including system modelling and configuration approaches, as well as tool integration issues. WP 3 deals with "Simulation tool interfaces", and is targeted towards the needs of software tool vendors. WP 4 specifies the "Real-time system interface", and takes hardware and testing systems into account. WP 5 focuses on the "Communication protocol", which is used to interconnect multiple systems via commonly used communication media. Finally, WP 6 is intended to condense the results of WPs 3-5 and master the task of creating a first version of the ACI specification. Industrial and scientific demonstrator applications are planned, set up and assessed within WP 7 named "Application use-cases and assessment". Dissemination, standardization, and exploitation activities take place within WP 8, throughout the entire run-time of the project. WP 9 is concerned with overall project management activities. 4.2
Expected Outcomes of Workpackages and Deliverables The outcome of WP 1 are sets of requirements (D1.1: Open system architecture requirements ) targeting different application levels and levels of abstraction. They build on top of current standards, state-of-the-art technology, and best industry practices. The project’s 9 use cases of WP 7 support these steps. More on this in Section 4.4. The use cases will be assessed in WP 7’s deliverable D7.1: Documentation of use cases, tests, configurations, and measurement results, to demonstrate the impact of ACOSAR’s developments.
WP 2 defines the understanding of system simulation in the project, and assesses properties of interfaces and subsystems. If these can be described properly, 2 http://www.fmi-standard.org WP 2 – RT-System Integration Methodology MBSE for RT-System integration Co-simulation system configuration Tool-chain integration Current standards Funded associated projects FMI, ASAM XiL-API, XCP, etc. Modelisar, ACoRTA, etc.
Associated member groups
Aviation, Rail, Maritime, etc.
WP 1 – Open System Architecture Requirements Interfacing Requirements System architecture
Testing procedure WP 6 – Advanced cosimulation interface (ACI) Framework for coupling strategies Specification for the overall ACI
Commonly used communication media
ACI Industrial applications Scientific applications
WP 9 - Project Management
WP 8 – Dissemination & Exploitation Dissemination
tools (2015-2017) Standardization
actions (2017-2019) Exploitation plans and measures (2016-2018) WP 3 – Simulation tool interface 1. Interface specification 2. Prototype implementations 3. Initial test and evaluation WP 4 – RT-System interface 1. Interface specification 2. Prototype implementations 3. Initial test and evaluation WP 5 – Communication protocol 1. Abstraction of bus system 2. Prototype implementations 3. Initial test and evaluation
WP 6 – Application Use-Cases and Assessment
ACOSAR - HR/FRA Consortium Fig. 2. ACOSAR Project Structure. © VIRTUAL VEHICLE 2 an investigation of means for system configuration and tool chain integration is the next step. These results are consolidated in D2.1: Handbook on RT-system integration methodology, which is jointly developed with WPs 3-5. WP 3 will deliver D3.1: Specification of simulation tool interface, which aims at continuous and discrete simulation as well as real time constraints for co-simulation. The main output of WP 4 is D4.1: Specification of RT-system interface. It targets real-time-systems and includes related possible test specifications. WP 5’s main deliverable D5.1: Specification of communication architecture and communication protocol acts as a connector between WPs 2,3 and 4, from a communications point of view. The first version of the ACI specification, application guide and test suite will be published in the project’s core deliverables D6.1, D6.2, and D6.3.
Dissemination and exploitation plans are made in context of WP 8’s D8.2 and D8.3, respectively. The executive board (project and WP leaders) determines strategies to ensure the quality of deliverables, review and assessment criteria, as well as effective risk management throughout the project. This will be documented in D9.1: Quality assurance and risk management plan. 4.3
Use Cases and Assessment The ACOSAR partners contribute a total of 9 use cases to the project. On one hand, they are used as a starting point for the requirements engineering process. On the other hand, they help to assess the effectiveness of the ACI and analyze the impact of related process modifications. Due to the large number of use cases and their high variability within their configurations, a summary is given as follows. Popular scenarios include the coupling of offline simulation platforms with online real-time systems. Typical examples for real-time-systems are test beds for engines or vehicle brake dynamometers. Related to that, the exchange of single simulation models or software components with their real-time-system counterparts is a beneficial approach for X-in-the-loop testing. In this context, electronic control units (ECU) or virtual ECUs (vECU) are candidate platforms. One use case also includes a driving simulator for human interaction evaluation.
Different analyses were conducted on these use cases. Elicited technical challenges include e.g. the exchange of simulation data between offline and online simulation systems, or the integration of multiple ACI interfaces per device or platform. 4.4
Requirement Engineering for ACI Specification In WP 1 requirements for the ACI are collected and managed as they serve as a basis for subsequent work packages. In order to capture requirements of the entire project in a structured way, a project specific requirements engineering process has been created. It contains the artifacts shown in Figure 3.
Project Level WP Level
Project goals n m
Core requirements n m
Technical requirements n n m m
Use Cases n m ICT methods 1 n Technical scenarios
Project Goals represent the main objectives that are described in the project proposal. Together with ACOSAR’s industrial Use Cases they build the basis for the specification of ACI requirements. Use Cases (from WP 7) describe RT co-simulation scenarios for which ACOSAR partners want to achieve a solution. They are going to be demonstrated at the end of the project.
ICT methods describe functions of co-simulation scenarios on an abstract level of detail and mainly from a user’s point of view. The methods should on the one hand help to get a common understanding about the ACI functions within the project team and on the other hand be a basis for writing requirements and Technical scenarios. After the definition of ICT methods, partner related Use Cases are described in more detail by specifying Technical scenarios, which represent detailed activities of the co-simulation scenario of the Use Case. Table 2 shows the used template for specification of Technical scenarios, next to an example specification. As Technical scenarios are based on the abstract scenario from the ICT method, the template contains (in addition to the concrete Use Case) specific steps of the abstract scenario for traceability reasons. ID
Timing requirements are defined 1. Define communication step size per coupling signal 2. Define tolerable violation of timing requirements 3. Define timing constraints
Based on ICT methods and Technical scenarios, the Core and Technical requirements are derived. Core requirements are project requirements for the ACI and represent the main functionality. They are derived from Project goals and ICT methods. In contrast to Core requirements, Technical requirements are work package related and represent a detailed, technical specification.
For writing requirements, EARS boilerplates [
Exploitation & Innovation The major innovations of ACOSAR will influence different economic, industrial and scientific areas. Three potential fields of innovation can be identified. 1. ACOSAR features technological innovations by advancing solutions for interoperability problems. The considered communication architecture is based on the ACI and allows the implementation of end user key knowledge. The technological break-through results from dramatically shortened setup time for verification and validation activities within the generic V-diagram. 2. ACOSAR enhances the overall product development process. By using the ACI, the integration of real-time systems relies on information gathered earlier during system design and specification phases as well as during the system simulation phase. Therefore, a beneficial transfer of knowledge is introduced into the development process. 3. Using ACIs functional framework, users are able to implement smart functionalities in their real-time applications. For instance, crucial problems like communication latency of cyber-physical systems (CPS) can be addressed efficiently. This facilitates robust and accurate system development in a spatial and temporal distributed development environment. 6
Outlook In this paper we presented the ACOSAR project. Its primary goal is the development of the advanced co-simulation interface (ACI). Progress towards this high aim is already made, and the most significant results including the described materials will be available to the public in Summer 2018.