ETAS MODEL-SIMULATOR V3.1

User GuideCopyright
The data in this document may not be altered or amended without special notification from ETAS GmbH. ETAS GmbH undertakes no further obligation in relation
to this document. The software described in it can only be used if the customer isin possession of a general license agreement or single license. Using and copying
is only allowed in concurrence with the specifications stipulated in the contract.
Under no circumstances may any part of this document be copied, reproduced,
transmitted, stored in a retrieval system or translated into another language
without the express written permission of ETAS GmbH.
© Copyright 2024 ETAS GmbH, Stuttgart
The names and designations used in this document are trademarks or brands
belonging to the respective owners.
MATLAB and Simulink are registered trademarks of The MathWorks, Inc. See mathworks.com/trademarks for a list of additional trademarks.
MODEL-SIMULATOR V3.1 | User Guide R03 EN | 08.2024

Contents | 3

Contents
1

Introduction

7

1.1

Intended Use

7

1.2

Target Group7

1.3

Data Protection

7

1.4

Data and Information Security

7

1.4.1

Data and Storage Locations

8

1.4.1.1

8

1.4.2

License Management

Technical and Organizational Measures82

About MODEL-SIMULATOR

93

Basics of MODEL-SIMULATOR

11

3.1

Service Basics

11

3.2

Workflow11

3.3

Projects

12

3.3.1

Projects

12

3.3.2

Test Executions

13

3.3.2.1

Estimated Time and Estimated Costs of Test executions

14

3.3.2.2

Calculated Costs for Test executions

15

3.4

Campaigns

16

3.5

Models16

3.5.1

Real Time Factor (RTF)

17

3.6

Compatibility of Campaigns and Models

19

3.7

Reports20

3.8

Report Templates

20

3.9

Upload Files Overview and Supported File Formats (Artifacts)

21

3.9.1

Upload Files for MODEL-SIMULATOR

21

3.9.2

General Conventions for Uploaded Data

22

3.9.3

Required Data Structure of Subsystem campaigns

23

3.9.4

Required Data Structure of Virtual vehicle campaigns

23

3.9.5

Required Data Structure of Test Execution Campaigns

25

3.9.6

Required Data Structure of Models

28

3.9.7

Required Data Structure of Models (Use Case independent)

29

3.9.7.1

Files Specification of the simConfig Folder

31

3.9.7.2

Files Description of the simConfig Folder

32

3.9.8

Required Data Structure of Models (Test Execution Use Case)

34

3.9.9

Required Data Structure of Report Templates

34

MODEL-SIMULATOR V3.1 | User Guide

Contents | 4

3.10

Stimuli File Requirements (*.mf4)

34

3.11

Overview of Status Labels

35

3.11.1

Test Execution Status

36

3.11.2

Result Status in Projects

36

3.11.3Campaign and Model Status

37

3.11.4Tooltips for Campaign Status

38

3.11.5Tooltips for Model Status

40

3.11.6

Tooltips for Report Template Status

42

4

Getting Started

44

4.1

Check System Requirements

44

4.2

First Steps for Users

45

4.3

Check Model Data

47

4.4

Check Campaign Data

48

4.4.1

Data Structure for Subsystem Campaign

48

4.4.2

Data Structure for Virtual Vehicle Campaign

49

4.4.3

Data Structure for Test Execution Campaign

49

5Working with MODEL-SIMULATOR

52

5.1

Toolchain and Tool Versions

52

5.1.1

52

VLAB Bundle Versions

5.2

Process Steps

54

5.3

User Interface

55

5.4

Input Forms

55

5.5

Multi-Factor Authentication

56

5.5.1

Set up TOTP Authentication

56

5.5.2

Sign in via TOTP

57

5.6

Header
5.6.1

57
Change Password

58

5.7

Home

58

5.8

Projects

60

5.8.1

Open Projects Overview

60

5.8.2

Search Projects

60

5.8.3

Filter Projects Overview

61

5.8.4

Sort Projects Overview

61

5.8.5

Create a Project

61

5.8.6

Delete a Project

62

5.8.7

Delete Multiple Projects

62

MODEL-SIMULATOR V3.1 | User Guide

Contents | 5

5.9

5.8.8

Edit a Project

62

5.8.9

Open Project Details

63

5.8.10

Add Test Execution Group(s) to a Project63

5.8.11

Run Test Executions in a Project64

5.8.12

Stop Test Executions in a Project64

5.8.13

Delete a Test Execution Group in a Project65

5.8.14

Delete a Test Execution Job in a Project65

5.8.15

Delete a Test Execution Run in a Project66

5.8.16

Download Test Execution Results

66

Campaigns

66

5.9.1

Status Labels for Campaigns

67

5.9.2

Required Preprocessing Steps for Campaigns

68

5.9.2.1

Preprocessing Steps for Virtual Vehicle Campaigns

69

5.9.2.2

Preprocessing Steps for Test Execution Campaigns

69

5.9.2.3

5.10

ECU-Test Support and Limitations for Test Execution Campaigns

69

5.9.3

MF4 File Creation Tools

71

5.9.4

Modify Existing MF4 File

72

5.9.5

Open Campaigns Overview

72

5.9.6

Search Campaigns

72

5.9.7

Filter Campaigns Overview

72

5.9.8

Sort Campaigns Overview

73

5.9.9

Create a Subsystem Campaign

73

5.9.10Create a Virtual Vehicle Campaign

74

5.9.11Create a Test Execution Campaign

74

5.9.12

Delete a Campaign

75

5.9.13

Delete Multiple Campaigns

75

5.9.14

Edit a Campaign

75

5.9.15

Open Campaign Details

76

5.9.16

Use Campaign(s) in a Project76

5.9.17

Download Stimuli Files of a Campaign

77

Models77

5.10.1

Status Labels for Models

78

5.10.2

Use Cases

79

5.10.3Required Preprocessing Steps for Models

79

5.10.4Models in COSYM

81

5.10.5Create a STI File81

5.10.6Create a SMF File82

5.10.7

Open Models Overview

83

5.10.8Search Models

83

MODEL-SIMULATOR V3.1 | User Guide

Contents | 6

5.10.9Filter Models Overview

84

5.10.10

Sort Models Overview

84

5.10.11Create a Model

84

5.10.12

Delete a Model

85

5.10.13

Delete multiple Models

85

5.10.14

Edit a Model

85

5.10.15

Edit Real Time Factor

86

5.10.16

Open Model Details

86

5.10.17

Use Model in a Project86

5.10.18

Download Files of a Model

87

6

Troubleshooting

88

7

Contact Information

89

Glossary

90

Figures

93

Tables94

MODEL-SIMULATOR V3.1 | User Guide

1 Introduction | 7

1

Introduction
In this chapter, you can find information about the intended use, the addressedtarget group, and information about safety and privacy related topics.

1.1

Intended Use
ETAS Cloud-Services is a cloud-based platform intended for virtualization purposes by providing a toolchain for continuous integration, test, and validation ofsoftware in automotive electrical/electronic (e/e) systems.
With ETAS MODEL-SIMULATOR, it is possible to run simulations or automated test
executions in the cloud in order to significantly speed up this process in particular for large simulation and test tasks. As a result, simulation or test execution
results can be downloaded. The results of the simulation depend on the qualityof the plant models and software models as well as on the choice of suitable
excitation signals (input stimuli), quality and representativeness of test procedures for the intended development task. The results should therefore bechecked for suitability for subsequent investigations by the user.
ETAS Cloud-Services runs in a native cloud environment and is offered as a service (SaaS). ETAS GmbH cannot be made liable for damage which is caused byincorrect use and not adhering to the safety information
ETAS MODEL-SIMULATOR CLI allows you to run the test executions in the cloud.
The CLI can be installed on the local PC or can be integrated into automation
scripts. Currently only Windows is supported.

1.2

Target Group
This product is directed at trained qualified personnel in the simulation and calibration sector of powertrain ECUs (e.g. calibration engineer, function developeror simulation model developer). Technical knowledge in simulation of vehicle systems and control unit engineering as well as pre-calibration or calibration of
those is a prerequisite.

1.3

Data Protection
If the product contains functions that process personal data, legal requirementsof data protection and data privacy laws shall be complied with by the customer.
As the data controller, the customer usually designs subsequent processing.
Therefore, he must check if the protective measures are sufficient.

1.4

Data and Information Security
To securely handle data in the context of this product, see the next sections
about data and storage locations as well as technical and organizational measures.

MODEL-SIMULATOR V3.1 | User Guide

1 Introduction | 8

1.4.1

Data and Storage Locations
The following sections give information about data and their respective storage
locations for various use cases.

1.4.1.1

License Management
When using the ETAS License Manager in combination with user-based licenses
that are managed on the FNP license server within the customer's network, thefollowing data are stored for license management purposes:
Data
Communication data: IP address
User data: Windows user ID
Storage location
FNP license server log files on the customer network
When using the ETAS License Manager in combination with host-based licenses
that are provided as FNE machine-based licenses, the following data are stored
for license management purposes:
Data
Activation data: Activation IDl

Used only for license activation, but not continuously during license
usage

Storage location
FNE trusted storage
C:\ProgramData\ETAS\FlexNet\fne\license\ts

1.4.2

Technical and Organizational Measures
We recommend that your IT department takes appropriate technical and organizational measures, such as classic theft protection and access protection to
hardware and software.

MODEL-SIMULATOR V3.1 | User Guide2 About MODEL-SIMULATOR | 92

About MODEL-SIMULATORETAS Cloud-Services is a highly secured cloud-based platform, operated by ETAS
GmbH. One of the offered services within this platform is a MODEL-SIMULATOR
service, that enables massive parallelization of simulations with up to 1000 simulations in parallel. This massive parallelization of simulations allows many simulations within short time and thus increases software development efficiency
for model based developments. Furthermore, massive parallelization of simulations enables statistical evaluation of systems.
The MODEL-SIMULATOR supports the simulation of models, that are generated
with the ETAS product COSYM. Basically, these models can be open-loop or
closed-loop models. Simulations can be triggered by combining a simulation
model with a test scenario (campaign) within a project.
After successful simulation, the simulation outputs are aggregated in a reportand can be downloaded for analysis. Besides a report, the MODEL-SIMULATOR
provides simulation results for download.

Note
MODEL-SIMULATOR V3.1 is released with the CLI client V2.1.0.

Features at a Glance
up to 1000 simulations in parallel
allows simulation of complex systems like vehicle networks, consisting ofvirtual vehicle control units, vehicle buses and simulation models
measurement of 1000 signals within every simulation run
generating simulation results
generating reports based on customized report layout
highly secured cloud environment by fulfillment of information security
standards according to ISO/IEC 27000 & 27001
support of third party test automation tool ECU-Test for test executions
Support of COSYM and VLAB as simulators

Use Cases
statistical evaluation of (complex) system models
parameter studies with separate parametersets for simulations on simulation run level
determination of the probability of failure against the development target
time-efficient execution of (large) software testing tasks, e.g. regression
tests in the DevOps work mode

MODEL-SIMULATOR V3.1 | User Guide2 About MODEL-SIMULATOR | 10

Depenencies/Licenses
The uploaded artifacts should not contain:
any reference to external libraries/dependencies
any artifacts (e.g. FMUs/VECUs) which are needing additional licenses

Note
If you are using VECU-BUILDER, then use Go License for your artifacts.

MODEL-SIMULATOR V3.1 | User Guide

3 Basics of MODEL-SIMULATOR | 113

Basics of MODEL-SIMULATOR
In this chapter, you find descriptions of the basic concepts of the MODELSIMULATOR to get an understanding of the service. It describes the typical workflow and its elements more detailed.

Note
If you want to start right away, check "Getting Started" on page 44 and "Working with MODEL-SIMULATOR" on page 52.

3.1

Service Basics
The MODEL-SIMULATOR enables the user to execute simulations in the cloud.
Models and stimuli files are used as input, result files and reports are the output.

For this procedure the user has to create a project which consists of a simulation
model and one or more campaigns. A campaign is integrated in a test executiongroup within a project. The user can download the report, see 3.1.
The MODEL-SIMULATOR provides a model repository, where users can upload
and manage simulation models. It also provides a Campaigns overview, where all
campaigns can be uploaded and managed. In addition, users can upload a reporttemplate to create a customized report according to used signals.
Major elements of the MODEL-SIMULATOR are simulation models (models) andstimuli files (campaigns), which are brought together in a project.

3.2

Workflow
The typical workflow in the MODEL-SIMULATOR is designed in the following
steps, see in Fig. 3-1.
1. Create a model by uploading simulation model.
2. Create a campaign by uploading stimuli files for simulation or test execution.

MODEL-SIMULATOR V3.1 | User Guide

3 Basics of MODEL-SIMULATOR | 12

3. Optional: Create a report template by uploading an EATB template (if notalready available).
4. Create a project by selecting one model from the model repository and adefault report template.
5. Add a test execution group to project by selecting campaigns.
6. Run the test execution in the project.
7. Wait until the test executions are completed.
8. Download the report (*.html) ortest execution results (*.zip).

Fig. 3-1: Overview workflow steps in the MODEL-SIMULATOR

For further information see:
5 "Working with MODEL-SIMULATOR" on page 52
5.10.3 "Required Preprocessing Steps for Models" on page 79
5.9.2 "Required Preprocessing Steps for Campaigns" on page 68

3.3

Projects
The Projects section in the MODEL-SIMULATOR provides the possibility to manage simulations and test executions. Within a project models and campaigns are
combined to run simulations or test executions. In addition results and reports
can be downloaded for further analysis or tests.

3.3.1

Projects
Projects are used to create and manage individual automated software tests. To
assign one or multiple campaigns to a project, a new test execution group has tobe created. In a project simulation models and test configuration files are combined to run the test execution in the cloud. The automated test procedure is created with a test automation software (e.g. ECU-Test).

Features Overview
The MODEL-SIMULATOR offers the following activities:
Create, start or stop test executions of project on different levels:ltest execution groupsltest execution jobsltest execution runs
see 3.3.2 "Test Executions" on the next page

MODEL-SIMULATOR V3.1 | User Guide

3 Basics of MODEL-SIMULATOR | 13

Create or delete test execution group, test execution job and test execution run
Check test execution (see 3.11 "Overview of Status Labels" on page 35)
Download test execution results on different levels:l test execution groups as *.zipltest execution jobs as *.zipltest execution runs as *.zip

Search or sort projects
Edit Project details (project name, description)
For instructions see chapter 5 "Working with MODEL-SIMULATOR" on page 52
and subchapter 5.8 "Projects" on page 60.

3.3.2

Test Executions
During test executions, control mechanisms are applied to run the simulation sothat the concept is not time-driven but event-driven. This means that events
such as "engine on" lead to the next control step, e.g. "switch on ignition". Suitable controls must be implemented in the model.
Test executions can be run by combining one model with one or more test execution campaign within a project. The executions are part of the project, whichallows the user to run many test executions by assigning campaigns to the project. To assign campaigns, test execution groups have to be created.
Test executions are represented by the test execution groups within a project.
The test execution can be based on one or multiple test execution groups, which
are based on one ore multiple test execution jobs (campaigns). The test execution jobs itself are based on one or multiple test execution runs (test units).
The structure is depicted in Fig. 3-2.

MODEL-SIMULATOR V3.1 | User Guide

3 Basics of MODEL-SIMULATOR | 14

Fig. 3-2: Structure of simulation hierarchy
This test execution hierarchy with group, job and run level allows a flexible use.
On every level test executions can be triggered and results can be downloaded.
The test execution group is the highest hierarchy level. By triggering a test execution on this level, all the test executions with all nested elements will be
executed. Starting a test execution on any level will lead to costs.

3.3.2.1

Estimated Time and Estimated Costs of Test executions
Estimated time and estimated costs are shown in a pop-up right before starting atest execution. Due to the event-driven control of the simulation, the duration of
the simulation is highly dependent on the behavior of the model. So, an estimation of the duration is not possible in advance. Therefore, the user can only be
informed which costs (cloud computation hours) will arise depending on the execution period. It is recommended to observe the test execution especially during
the first execution in order to prevent unintentionally long test runs.

MODEL-SIMULATOR V3.1 | User Guide

3 Basics of MODEL-SIMULATOR | 15

Fig. 3-3: Shown estimated time and estimated costs (tests tab of a project)

3.3.2.2

Calculated Costs for Test executions
The MODEL-SIMULATOR costs are based on a pay-per-use concept. The currency is cloud computation hours. The costs will be calculated individually foreach test execution run. The used amount of cloud computation hours will thenbe subtracted from the cloud computation hours contingent of your organization. Costs are charged in one hour steps.
The current status of cloud computation hours can be checked in the header: My
account > Cloud computation hours contingent.
More information about accounting can be found in contractual documents.

MODEL-SIMULATOR V3.1 | User Guide

3 Basics of MODEL-SIMULATOR | 16

3.4

Campaigns
Campaigns define the simulation task to be applied to the model. Campaigns are
created and managed as separate elements so that they can be applied to different models. However, the compatibility between campaign and model must be
ensured. Campaigns contain the information how a simulation should beexecuted.
The user can choose between 3 types.
subsystem campaign: contains customer specific signals (*.mf4)
virtual vehicle campaign: has to contain the signals vehicle target speed,
gear and road slope (*.mf4). Parameters (*.cdfx) that are optionally defined
will overwrite the parameters, which were defined within the model (CDFX
file in the simConfig folder).
test execution campaign: contains configuration of an automated test procedure created with a test automation software e.g. ECU-TEST (*.prj)

Note
The compatibility of campaign and model has to be ensured by the user.
See also 3.6 "Compatibility of Campaigns and Models" on page 19.

Features Overview
The Campaigns section offers the following activities:
Create or delete campaigns
Edit Campaign details (campaign name, description)
Check and refresh status of campaigns
Search or sort campaigns
Download stimuli files in Files tab of a campaign (see 3.9 "Upload Files Overview and Supported File Formats (Artifacts)" on page 21):l measurement files as *.mf4
lparameter files as *.cdfx (only for virtual vehicle campaign)ltest units as *.prj (only for test execution campaign)

For instructions see chapter 5 "Working with MODEL-SIMULATOR" on page 52
and subchapter 5.9 "Campaigns" on page 66.

3.5

ModelsA model is a mathematical representation of a physical system. It is used to calculate the resulting system behavior (model outputs) according to the fed excitation signals (input stimuli). The model contains the deployables of thesimulation system (build target generated in COSYM V3.4) and some configuration files, like parameters or signal filter.

MODEL-SIMULATOR V3.1 | User Guide

3 Basics of MODEL-SIMULATOR | 17

In the MODEL-SIMULATOR the user can upload these models for simulation andchoose between two types: subsystem model and virtual vehicle model (seetechnical details in 3.9.6 "Required Data Structure of Models" on page 28).
Whereas a virtual vehicle model has to contain the inputs vehicle target speed,
gear and road slopeModels act as individual elements and can be assigned to different projects, where the model can be simulated by combining with campaigns.
Once a model is uploaded in the model repository, it can be used for simulation ofdifferent campaigns.

Note
The compatibility of campaign and model has to be ensured by the user.
See also 3.6 "Compatibility of Campaigns and Models" on page 19.

3.5.1

Real Time Factor (RTF)
The RTF is a factor that describes how fast a simulation runs in comparison toreal time. An initial value can be determined by running a simulation in COSYM anddividing the simulation time by the duration of stimuli file.
RTF = Duration of simulation/Duration of stimuli file
Example: If the simulation time (computing time on a machine) and the durationof stimuli file (driving time in the car) are equal and both take 1 hour, the RTF
equals 1. If the simulation time takes more than the duration of stimuli file, the RTF
is greater than 1.
Duration of simulation ≙ Duration of stimuli file ⇒ RTF = 1
Duration of simulation > Duration of stimuli file ⇒ RTF > 1
Duration of simulation < Duration of stimuli file ⇒ RTF < 1
The RTF is entered during each model upload process to display the predictedsimulation time. Therefore the determination is needed before uploading thesimulation model to the MODEL-SIMULATOR. The RTF can be changed and adjusted afterwards in the model properties of a model. This change has an influence
to all projects, wherever the model is used, but no influence on running simulations.
The RTF is used to calculate the predicted simulation time by multiplying it withthe duration of stimuli file. The duration of MF4 files can be seen in the Files tabof a campaign.

MODEL-SIMULATOR V3.1 | User Guide

3 Basics of MODEL-SIMULATOR | 18

Before a simulation starts, the predicted time is displayed in the simulations tabof a Project. This predicted time may differ from the actual required time, depending on how valid the RTF for all stimuli files is.
The RTF depends on the complexity of the simulation model, i.e. number of elements and stiffness of the differential equation system and the number andsampling frequency of the recorded channels. That means the lower the complexity, the lower the RTF will be.
A history of the RTF with statistics can be seen in the Model properties tab inevery model. Based on run simulations a new RTF might be proposed which canbe applied easily.

Note
The RTF value has no influence on the real simulation duration (charged hours)or the simulation speed. It only displays the predicted simulation time and predicted simulation costs based on the entered RTF.

Features Overview
The model repository offers the following activities:
Create or delete models
Edit Model details (model name, description)
Edit Model properties (RTF)
Check real time factor statistics
Check and refresh status of models
Search or sort models
Download Files (see 3.9 "Upload Files Overview and Supported File Formats(Artifacts)" on page 21):l metadata as *.jsonlmodel binaries/executable as *.ziplparameter file as *.cdfx

MODEL-SIMULATOR V3.1 | User Guide

3 Basics of MODEL-SIMULATOR | 19lsignal mapping file as *.smf

ldatalogger configuration file as *.dlc4linterpolation file as *.sti

For instructions see chapter 5 "Working with MODEL-SIMULATOR" on page 52
and subchapter 5.10 "Models" on page 77.

3.6

Compatibility of Campaigns and Models
The combination of campaigns and models in a project has to be compatible. The
compatibility is visualized in Fig. 3-4. Depending on model type and campaign
type different inputs and signals have to be considered. This set up can be used
for simulation or test execution use case, depending on the uploaded data.

Fig. 3-4: Compatibility of inputs (models) and signals (campaigns)
The suitability of each model can be identified in the "Usecase" column of themodel repository. Only the available models and campaigns are displayed in thecorresponding project types during the project creation.

Fig. 3-5: Use case column in the model repository

MODEL-SIMULATOR V3.1 | User Guide

3 Basics of MODEL-SIMULATOR | 20

3.7

Reports
Reports are used to visualize the simulation results of a project. The Reports are
created by another ETAS tool called EATB (ETAS Analytics Toolbox), which is integrated in the MODEL-SIMULATOR. After finishing a simulation, the results of asimulation group are collected to automatically generate an HTML report. Thatmeans all simulations belonging to a simulation group have to be completed, sothat report creation starts. These automatically generated reports are named"Default report". Additionally, reports can be created manually with an own nameand selected completed simulation groups. Reports must be downloaded in order
to view them in the browser.
Reports are retained even if simulations are deleted, because simulation only has
to be carried out successfully once. In addition, it is also possible to create
reports manually. The reports are linked to templates on which they are based.
That means you can create report templates according to your needs.
See also 4.1 "Check System Requirements" on page 44.
For more information, especially for usage and menu description, see separate
EATB Report Guide or introduction video in the ETAS Download Center.

3.8

Report Templates
Report templates are used as a base for the report creation in a project. They
define the structure and design of the report. All templates are combined in a collection and can be managed as well as uploaded in a dedicated space. The easiest way to create a template is using EATB.
The report template is uploaded as a ZIP file containing at least one EATB (*.eatb)
file for the different signals to be simulated and measured. The configuration fileconfig_signals.csv or config_signals.m needs to be stored in the root
folder.

MODEL-SIMULATOR V3.1 | User Guide

3 Basics of MODEL-SIMULATOR | 21

3.9

Upload Files Overview and Supported File Formats (Artifacts)
In the MODEL-SIMULATOR different data has to be uploaded for campaigns andmodels. This chapter gives you an overview of all data types and the specifications.

3.9.1

Upload Files for MODEL-SIMULATOR

Object/Item

Description and Content

FormatSubsystem

Stimuli file(s)*.mf4campaign

Version 4.1, ASAM
Standard for MDF

Virtual vehicle Stimuli file(s) that contain vehicle target speed, gear
campaign*.zip

and road slope.
Zip file includes subordinate campaign folder withsimulation run folders, each simulation run folder contains one MF4 file (mandatory) and one CDFX file
(optional).

Test exe-

ECU-Test files as a *.zip (without Report folder) thatcution cam-

contains at least Packages, Configurations andpaign.workspace folders.

*.zip

MODEL-SIMULATOR V3.1 | User Guide

3 Basics of MODEL-SIMULATOR | 22

Object/Item

Description and Content

FormatModels

Virtual vehicle model: contains the description of the*.zipvirtual vehicle with the inputs vehicle target speed,
gear and road slope.
Subsystem model: contains the description of a customer specific simulation model which in consequence has specific inputs.
The ZIP file consists of COSYMprj folder with:> deployables as *.zip (mandatory) = cloud_deployable.zip of OS folder in COSYM projectand simConfig folder with:signal interpolation file as *.sti (mandatory)
datalogger configuration file as *.dlc4 (optional)
parameter file as *.cdfx (optional)
signal mapping file as *.smf (optional)

Note
A signal mapping file is only required if the labelsin the CDFX file do not match the model'sinternal calibration variable names to ensure correct mapping. Otherwise, this could lead towrong simulation results.
Optionally the ZIP file can contain a metadata folder
to submit custom data, e.g. reason for model creation, scope, etc. with:metadata file as *.json
For projects only the deployables (cloud_deployable.zip) in COSYMprj folder as a *.zip is required.
Tab. 3-1: Upload files overview for MODEL-SIMULATOR
See also 3.6 "Compatibility of Campaigns and Models" on page 19.

3.9.2

General Conventions for Uploaded Data
Following conventions have to be fulfilled for all uploaded data in MODELSIMULATOR:
Maximum characters: 1024
Can only start with any
l lower case characterslupper case characterslnumberslspecial characters: _ .

MODEL-SIMULATOR V3.1 | User Guide

3 Basics of MODEL-SIMULATOR | 23

Can contain any
l lower case characterslupper case characterslspecial characters like: ! - _ . ( )Not allowed:lother special characters like: 'lwhite spaces

Due to character limitation of 140 characters for simulation group name, thename will be truncated. Each component can be up to 44 characters long. [Campaign_name]_[Folder_name]_[File_name]_[Sequence_number]
To ensure that the file name is not truncated, make sure that campaign name,files names of *.zip and *.mf4 are not longer than 44 characters.
Used characters are shown during creation at the right edge of the text input
field.

3.9.3

Required Data Structure of Subsystem campaigns
In a subsystem campaign one or more stimuli files can be uploaded at once, eachas an MDF file (*.mf4) considering the ASAM Standard for MDF.
See also 3.10 "Stimuli File Requirements (*.mf4)" on page 34. For conceptual background information see 5.9 "Campaigns" on page 66.

3.9.4

Required Data Structure of Virtual vehicle campaigns
For the virtual vehicle campaigns a dedicated data structure has to be fulfilled fora successful upload.

Fig. 3-6: Virtual vehicle campaign ZIP file composition (required structure)

MODEL-SIMULATOR V3.1 | User Guide

3 Basics of MODEL-SIMULATOR | 24

A virtual vehicle campaign has to be uploaded as one ZIP file, e.g.
VirtualVehicleCampaign.zip (see Fig. 3-7). This ZIP file must contain asuperordinate folder containing one or multiple folders for each simulation run.
Each of these folder must contain an MF4 file (ASAM Standard for MDF) and cancontain a CDFX file (optionally), see in Fig. 3-8. The provided CDFX file(s) overwrite the values of the model CDFX file. If no CDFX file is provided, the parameters
are constant and taken from the model.
There are no naming conventions, but you can lean on the examples in thescreenshots. The used file names will be displayed in the Files tab of a campaign.
See also 3.9.2 "General Conventions for Uploaded Data" on page 22.

Fig. 3-7: Content of campaign folder in virtual vehicle campaign ZIP file

MODEL-SIMULATOR V3.1 | User Guide

3 Basics of MODEL-SIMULATOR | 25

Fig. 3-8: Content of simulation run folder in virtual vehicle campaign
See also 3.10 "Stimuli File Requirements (*.mf4)" on page 34. For conceptual background information see 5.9 "Campaigns" on page 66.

3.9.5

Required Data Structure of Test Execution Campaigns
The ECU test tool supports external dependencies provided as part of workspaces. An ECU test workspace that make use of a library feature can be
uploaded via campaign services.
The use of the library feature is optional and both (with library feature andwithout library feature) campaign structures are supported.
For the test execution campaign a dedicated data structure has to be fulfilled fora successful upload.

Note
All the artifacts required to run the test cases must be packaged inside theworkspace. The test bench configuration (.tbc) and test configuration (.tcf)
files must contain only the relative paths to any artifacts they refer to within
the workspace. If absolute paths are provided the test case execution in thecloud will fail.

MODEL-SIMULATOR V3.1 | User Guide

3 Basics of MODEL-SIMULATOR | 26

Campaigns Without Use of Library Feature
The ECU test data has to be zipped (without Report folder) and uploaded for thetest execution use case. At least the ZIP file must contain the packages, configurations and workspace folder of the ECU test project for campaigns without
libraries.

Fig. 3-9: Test execution campaign ZIP file composition (required structure) for
campaigns without libraries

MODEL-SIMULATOR V3.1 | User Guide

3 Basics of MODEL-SIMULATOR | 27

Campaigns With Use of Library Feature
For campaigns with libraries the following ZIP file composition has to be considered. ECU test data has to be zipped (without Report folder) and uploaded forthe test execution use case. At least the ZIP file must contain a root folder, one
or more library workspaces, a project folder with the packages, configurations
and workspace folder of the . ECU test project for campaigns with libraries.

Fig. 3-10: Test execution campaign ZIP file composition (required structure) for
campaigns with libraries

MODEL-SIMULATOR V3.1 | User Guide

3 Basics of MODEL-SIMULATOR | 28

3.9.6

Required Data Structure of Models
Models are represented in ZIP files with a specific data container. A dedicateddata structure has to be fulfilled for a successful upload. Depending on the use
case, the following content is required:Fig. 3-11: Model ZIP file composition (required structure)

MODEL-SIMULATOR V3.1 | User Guide

3 Basics of MODEL-SIMULATOR | 29

3.9.7

Required Data Structure of Models (Use Case independent)
A virtual vehicle model or subsystem model has to be uploaded as one ZIP file,e.g. SimulationModel.zip (see Fig. 3-11). This model ZIP file must contain afolder called COSYMprj and can contain a metadata folder (optionally). The
COSYMprj folder must contain the deployables as a ZIP (build target generated
with COSYM V3.4) and a configuration folder, which must be named simConfig
and contain an STI file. The use of SMF file is optional. This construct can be used
for projects.
The data structure of subsystem model or virtual vehicle model is the same, thedeployables are just composed differently in COSYM. In both cases COSYM creates a cloud_deployable.zip. You can enable cloud deployable creation via
View > Settings in COSYM. For more details see topics "Settings" and "Build" in
COSYM User Guide or press F1 in COSYM and navigate to User Interface > Set-tings and System Build > Build.
There are no naming conventions for the deployables, model ZIP file or configuration files, but you can lean on the example in the screenshot. The used filenames will be displayed in the file information tab of a model.
See also 3.9.2 "General Conventions for Uploaded Data" on page 22.

Fig. 3-12: Content of model ZIP fileFig. 3-13: Content of COSYMprj folder in model ZIP file (use case independent)

Fig. 3-14: Content of simConfig folder in COSYMprj folder
The SimulationModel.zip contains:> COSYMprj folder with

MODEL-SIMULATOR V3.1 | User Guide

3 Basics of MODEL-SIMULATOR | 30

model binaries/executable as *.zip, e.g. cloud_deployable.zip (mandatory)
configuration files in simConfig folder:lsignal mapping file as *.smf (optional)

Note
A signal mapping file is only required if the labels in the CDFX file do
not match the model's internal calibration variable names to ensure
correct mapping. Otherwise, this could lead to wrong simulation results.
lparameter file as *.cdfx (optional)ldatalogger configuration file as *.dlc4 (optional)lsignal interpolation file as *.sti (mandatory)

metadata folder

MODEL-SIMULATOR V3.1 | User Guide

3 Basics of MODEL-SIMULATOR | 31

3.9.7.1

Files Specification of the simConfig Folder
Currently complex data types like maps, curves or arrays are supported, strings
are not supported.

Object/Item

Description

FormatCreation Tool

Signal map-

Used for calibration parameter name*.smf

Sut Mapping Fileping filemapping

Version 3.1 or 4.0 Editor(usually comes
Only one SMF(optional)

file, ETAS specific standard

with COSYM
installation)and format

Note
A signal mapping file is only required if the labels in the CDFX file do not match the model'sinternal calibration variable names to ensure correct mapping. Otherwise, this could leadto wrong simulation results.
Parameter file

Global parameters of the model*.cdfxCOSYM, EE(optional)

Just scalar elements are supported,

Version 2.0,

(Experiment<CATEGORY> type of parameter

ASAM standard

must be therefore VALUE or BOOLEAN. for CDF
Possible types: real64, real32, uint8,
uint16, uint32, uint64, sint8, sint16,
sint32, sint64.
Example:<CATEGORY>VALUE</CATEGORY>

Only one CDFX

Environment) orother ASAM CDF
supported tool

file containing
Value or Boolean
as Category
type

MODEL-SIMULATOR V3.1 | User Guide

3 Basics of MODEL-SIMULATOR | 32

Object/Item

Description

FormatCreation Tool

Note
Model's internal variable names have to match with the parameter file (*.cdfx) within themodel ZIP or in a virtual vehicle campaign you want to use for simulation.
<SHORT-NAME> tag of CDFX (within <SW-INSTANCE> block) file has to use the same nameas the label in the signal mapping file (“SUTMap Testlabel" in the SMF file).
Datalogger

Signal selection for data recording,configuration

this reduces the data to be processed Only one DLC4and speeds up the simulation.
file, ETAS spe-file (optional)*.dlc4EE (Experiment
Environment) 
Datalogger tabcific file format
Interpolation

Interpolation details variable values*.stifile (man-Just linear or forward interpolation is

ASAM standard

supported, <Interpolation value>

for STI

must be therefore eLinear or eFor-

Only one STI filedatory)ward.
Example: <Interpolation xsi:type="InterpolationType"value="eLinear" />Tab. 3-2: Model ZIP file: content of simConfig folder and specifications

Note
If a model is simulated with a virtual vehicle campaign, the provided CDFX file ofthe campaign overwrites the values of the model CDFX file.
See conceptual background information in 5.10 "Models" on page 77.

3.9.7.2

Files Description of the simConfig Folder<SignalMappingFileName>.smf (optional):
Signal mapping file (*.smf) is used to provide proper mapping between
labels inside the CDFX file with the model's internal calibration variablenames, if they do not match. Otherwise this could lead to wrong simulation
results.
<ParameterFileName>.cdfx (optional):
Global parameters of model used for initialization of model variables withpredefined values.
<DataloggerConfigurationFileName>.dlc4 (optional):
The capture of signals only with scalar data types (eBOOLEAN, eINT,
eUINT, eFLOAT) is supported by COSYM simulator (i.e X-Simulator). If thedata logger file specifies capturing of signals other than the above scalar

MODEL-SIMULATOR V3.1 | User Guide

3 Basics of MODEL-SIMULATOR | 33

data types, then simulation would result in an ERROR. If the data logger fileis not provided as part of the SUT (System Under Test) then all the signals(as listed below) with scalar data types (eBOOLEAN, eINT, eUINT, eFLOAT)
are captured in the simulation result MF4 file.
l

All the in-ports of the SUTlAll the out-ports of the SUTlAll the characteristic and measurement variables of the SUT

The data logger file if provided must contain at least one signal to be captured as a simulation result (i.e it should have at least one entry in<RecordingSignals>).
If the above condition is not met then that file is invalid and not supported.
The raster (i.e step size) for the recording can be configured via the task
as below:<RecordingSignal label="..." ... task="AutoMapTask1_
10ms" ... />All the <RecordingSignal> entries must have the same task name (i.etask="<Task_Name>")
Providing different task names for the <RecordingSignal> entries is notsupported
The task name provided in the dlc4 file must be defined in the COSYM project.
If the task is "Acquisition" (i.e task="Acquisition") then the default raster of
100 ms is considered for recording.
<SignalInterpolationFileName>.sti (mandatory):
Global mapping of simulation model inputs to stimuli file signal names (e.g.
the model uses input name A and the stimuli file use X, this must be
mapped). Within this file you can address several mapping names coming
out of different stimuli files. Time resolution in the stimuli file might be too
low with respect to the simulation model requirements, therefore the input
signals need to be interpolated to determine the stimuli file information
within a finer timescale. Usable types of interpolation are: eLinear and eForward.

MODEL-SIMULATOR V3.1 | User Guide

3 Basics of MODEL-SIMULATOR | 34

3.9.8

Required Data Structure of Models (Test Execution Use Case)
Regarding the test execution use case, only the deployables are required in a
dedicated data structure. This model can then be only used for projects. The
metadata folder is an optional part of the ZIP file (see Fig. 3-11 in "Required Data
Structure of Models" on page 28).

Fig. 3-15: Content of model ZIP fileFig. 3-16: Content of COSYMprj folder in model ZIP file (test execution use case)

3.9.9

Required Data Structure of Report Templates
The report template is uploaded as a ZIP file and can contain several EATB and M
files for the different signals to be simulated and measured. The report templateis created with the Configuration Creator in EATB. How to create a template is
described in the separate User Guide of EATB, see Chapter "Configuration
Creator". You can also watch an introduction video, see https://www.etas.com/de/downloadcenter/39989.php.
For the upload, the ZIP file must contain at least one EATB file (*.eatb) and theconfig_signals.csv or config_signals.m provided in the root folder. The
report template has to fit to the model outputs, otherwise the report will be
empty.

3.10

Stimuli File Requirements (*.mf4)
MDF (*.mf4) is a binary format (ASAM standard) used for the stimulation of amodel in the MODEL-SIMULATOR. The data is organized in data blocks. The channel group (CG) block contains channels (CN). One channel describes a recorded
signal including the encoding of the values in the records for the CG block.

MODEL-SIMULATOR V3.1 | User Guide

3 Basics of MODEL-SIMULATOR | 35

The MDF format offers a wide range of possible applications. The following configuration is required for uploaded MF4 files to ensure a proper data processing:
MDF 4.x format
time stamps always start at 0 and are not negative
only 1 channel grouptime unit is seconds
sample rate is fixed
See more information: https://www.asam.net/standards/detail/mdf/

3.11

Overview of Status Labels
In the MODEL-SIMULATOR different status labels are defined and shown. The
tables give an overview of all status labels and their meaning.
In general there is a color coding applied.
light blue : ready, user action neededblue : in progress, process working
green : finished, process completed
yellow : stopped, process not completed
red : not working, something went wrong, repeat process
grey: unavailable, process not available
There is a specific workflow followed for the status display after the simulation
has been started. This sequence is shown in the following graphic.

MODEL-SIMULATOR V3.1 | User Guide

3 Basics of MODEL-SIMULATOR | 36

3.11.1

Test Execution Status
The test execution status can be found in each project in the Execution status
column of the Tests tab.

LabelsDescription

READY

test execution on group, job or run level is ready to use.

PROCESSING

test execution is going to start. Setting up a simulation can take upsome time, when a new simulation node has to be deployed.

RUNNING

test execution on run level is running and can be stopped by user in a

(only for simulation certain time frame.
run and test execution run)
INCOMPLETE

At least one of the or test execution run was stopped by user, thisleads to an incomplete job.
Results of STOPPED simulations can be downloaded. It is recommended to avoid too many "incomplete" jobs in projects, this can lead
to issues for report generation.
Incomplete label is also shown, if one or more runs in a job or group arecomplete but none is currently running.

COMPLETED

test execution is completed.

FAILED

test execution failed. Check files of campaign(s) and eventually startagain. Possible other reason could be cloud computation hours limit isreached.
Tab. 3-3: Overview status labels for simulation status in projects

3.11.2

Result Status in Projects
The result status can be found in each project in the Result status column of theTests tab.

MODEL-SIMULATOR V3.1 | User Guide

3 Basics of MODEL-SIMULATOR | 37

LabelsDescription

N/A

Test is not available due to not already started test execution. Execution status is READY .

FAILED

Test is failed due to not matching conditions.

INCONCLUSIVE

Trigger condition of trace analysis did not occur, no evaluation possible.

NONE

No comparison of actual and expected value in the project available.

SUCCESSAll test steps are passed with expected results.

ERROR

A tool error occurred.

UNAVAILABLE

Test is not available. See Output File Details in CLI User Guide for more
information.

3.11.3Campaign and Model Status
The campaign, model or status can be found in the Status column of the overview pages or in each campaign, model.

MODEL-SIMULATOR V3.1 | User Guide

3 Basics of MODEL-SIMULATOR | 38

LabelsDescription

PROCESSING

Campaign/model is created, but some process in the background is running (e.g. unzipping of files).
Refresh and check the latest status, using the refresh button in Campaigns overview or model repository.

AVAILABLE

Campaign/model is available and ready to use for simulation.

UNAVAILABLE

Campaign/model is created, but some background processing failed(e.g. unzipping). Campaign/model is not available and cannot be used
for simulations.
See more information in tooltips (hover over labels) inCampaigns overview or model repository.Check the reason for unavailability and eventually create a new campaign/model.

See also 3.11.4 "Tooltips for Campaign Status" below and 3.11.5 "Tooltips
for Model Status" on page 40.
Tab. 3-4: Overview status labels for campaign/model status

3.11.4Tooltips for Campaign Status
If a campaign is UNAVAILABLE , we provide detailed information in the tooltip for
possible reasons. Hover over the label to see the details.

MODEL-SIMULATOR V3.1 | User Guide

3 Basics of MODEL-SIMULATOR | 39

Tooltip

Description and Help

<No.> of <No.> routes failed due to internal error. Campaign could not be created. Contact
support for more details.
The campaign is unavailable because the .work-

Test execution campaign must containspace/Packages/Configurations/ files were not

the following files:.workspace folder with configuration

found.

files
Packages folder with PKG and PRJ files
The campaign is unavailable because the Configurations folder/s were not found.

Configurations folder with TBC and
TCF files
Check and see 3.9.5 "Required Data Structure of Test Execution Campaigns" onpage 25.

Stimuli length unavailable.

Check if MF4 requirements are fulfilled.
See 3.10 "Stimuli File Requirements(*.mf4)" on page 34.

One or more files are present at a invalid path.
Invalid zip file: <filename>.zip
Trip contains non accepted files other than MF4
and CDFX.
Trip contains invalid combination.
One or more empty trips are present.
Artifacts contain invalid file formats.
Folder exists already.

Data for virtual vehicle campaign must follow a dedicated structure. The folders
within the ZIP file for a virtual vehicle campaign must only contain one MF4 file (Mandatory) and one CDFX file in each folder.
Check and see 3.9.4 "Required Data Structure of Virtual vehicle campaigns" onpage 23.
There is an internal error. Contact support to report the error, specifying thename.

MODEL-SIMULATOR V3.1 | User Guide

3 Basics of MODEL-SIMULATOR | 40

Tooltip

Description and Help

Invalid characters in data context/Object name

There are some general conventions forthe uploaded data. This is only checked
after data upload. Ensure that the conventions are fulfilled and upload the data
again.
Check and see 3.9.2 "General Conventions for Uploaded Data" on page 22.

Artifacts contains invalid file formats.

Check that trips are stored in separate
folders for virtual vehicle campaigns andeach is provided with one MF4 file andone optionally CDFX file.
See 3.9.4 "Required Data Structure of Virtual vehicle campaigns" on page 23.

One or more files are present at invalid path.

MF4 and optionally CDFX files have to be
stored in folders for each trip.
Check and see 3.9.4 "Required Data Structure of Virtual vehicle campaigns" onpage 23.

3.11.5Tooltips for Model Status
If a model is UNAVAILABLE , we provide detailed information in the tooltip for possible reasons. Hover over the label to see the details. The combination of single
tooltips within one tooltip is possible, check separate descriptions.

MODEL-SIMULATOR V3.1 | User Guide

3 Basics of MODEL-SIMULATOR | 41

Tooltip

Description and Help

Fail to unpack the uploaded model.

Data for virtual vehicle model & subsystem model
must follow a dedicated structure. Use Winzip or
7-Zip for ZIP file creation. ZIP files created with®

MATLAB or "send to compressed folder" featureof Windows are not working.
See 3.9.6 "Required Data Structure of Models" onpage 28 and "General Conventions for Uploaded
Data" on page 22.
Contact support for more details.
We could not find the simConfig folder.

Data for virtual vehicle model must follow a ded-

Please add one with mandatory config

icated structure.

files to your model zip file.

Check and see 3.9.6 "Required Data Structure ofModels" on page 28.

Mandatory zip file is missing.

The ZIP file for model upload must only containone ZIP file. This ZIP file is the target build output
of COSYM (cloud_deployable.zip).
See 3.9.6 "Required Data Structure of Models" onpage 28.

The ZIP file is present at invalid path.

The ZIP file for model upload must only containone ZIP file (cloud_deployable.zip) stored in the
COSYMprj folder.
See 3.9.6 "Required Data Structure of Models" onpage 28.

The SMF/CDFX file have an invalid file

SMF and CDFX file have to be stored in thepath structure.

simConfig folder.
Check and see 3.9.6 "Required Data Structure ofModels" on page 28.

Multiple SMF files are present.

Only one SMF file must be stored in the simConfig
folder.
Check and see 3.9.6 "Required Data Structure ofModels" on page 28.

Multiple CDFX files are present.

Only one CDFX file must be stored in the simConfig
folder.
Check and see 3.9.6 "Required Data Structure ofModels" on page 28.

MODEL-SIMULATOR V3.1 | User Guide

3 Basics of MODEL-SIMULATOR | 42

Tooltip

Description and HelpMultiple DLC4 files are present.

Only one DLC4 file must be stored in the simConfig
folder.
Check and see 3.9.6 "Required Data Structure ofModels" on page 28.

Multiple STI files are present

Only one STI file must be stored in the simConfig
folder.
Check and see 3.9.6 "Required Data Structure ofModels" on page 28.

Multiple ZIP files are present.

The ZIP file for model upload must only containone ZIP file. This ZIP file is the target build output
of COSYM (cloud_deployable.zip).
See 3.9.6 "Required Data Structure of Models" onpage 28.

The files in the uploaded model have an Data for virtual vehicle model & subsystem model
invalid file structure.

must follow a dedicated structure.
Check and see 3.9.6 "Required Data Structure ofModels" on page 28.

Tab. 3-5: Overview tooltips for model status

3.11.6

Tooltips for Report Template Status
If a report template is UNAVAILABLE , we provide detailed information in the tooltip for possible reasons. Hover over the label to see the details.

Tooltip

Description and Help

Path cannot exceed 1024 characters.

The total character length must not exceed 1024.
See "General Conventions for Uploaded Data" onpage 22.

Invalid characters in data context/Object There are some general conventions for thenameuploaded data. This is only checked after data
upload. Ensure that the conventions are fulfilled
and upload the data again.
Check and see 3.9.2 "General Conventions for
Uploaded Data" on page 22.

The report template zip should contain at Report template ZIP file must contain at least
least one EATB file.

one EATB file (*.eatb or *.m).
Check and see 3.9.9 "Required Data Structure ofReport Templates" on page 34.

MODEL-SIMULATOR V3.1 | User Guide

3 Basics of MODEL-SIMULATOR | 43

Tooltip

Description and Help

We found that either config_signals.csv

The configuration file config_signals.csv

or config_signals.m file or both are at anmust to be stored in the root folder.

invalid path in the ZIP.

Check and see 3.9.9 "Required Data Structure ofReport Templates" on page 34.

Mandatory files are missing in the report

Report template ZIP file must contain at least

template. Please upload a ZIP file with

one EATB file (*.eatb or *.m). The configuration

either config_signals.csv or config_sig-

file config_signals.csv must to be stored innals.m file and at least one EATB file.

the root folder.
Check and see 3.9.9 "Required Data Structure ofReport Templates" on page 34.

The ZIP file cannot be unpacked. The

Data for report template must follow a dedicatedstructure of the ZIP is invalid as one or

structure. Use Winzip or 7-Zip for ZIP file creation.

more file(s) in the ZIP contains path as

ZIP files created with MATLAB or "send to com-name.

pressed folder" feature of Windows are not work-®

ing.
See 3.9.9 "Required Data Structure of Report
Templates" on page 34 and "General Conventions for Uploaded Data" on page 22.

MODEL-SIMULATOR V3.1 | User Guide

4 Getting Started | 444

Getting Started
To get started with the MODEL-SIMULATOR some preparatory actions are
required:ü User account created.
ü Verification process completed.
ü Authentication app is downloaded and configured (see "Set up TOTP
Authentication" on page 56).
ü System requirements are fulfilled (see "Check System Requirements" below).
ü Data preparation are fulfilled (see "Check Campaign Data" on page 48 and"Check Model Data" on page 47).

4.1

Check System Requirements
Before starting with MODEL-SIMULATOR, be sure you meet the general system
requirements.
Required firewall settings for general use: HTTPS traffic enabled (port TCP
443 )Required COSYM version and license for model preparation (projects): Version V3.4 for test execution use caseRequired Visual Studio version and license for FMUs (FMI Version 2.0): 2013or 2017
Recommendation portable self-contained FMU without dependencies
Required ECU-TEST version and license: V2023.2.3
For ECU-TEST project (necessary for test execution campaign used in project) without external references to projects or packages, see
Required EATB version and license for template creation: V5.0
Required VLAB version and license: V2.8.3
Required MOBI version: V5.0.1
Recommended browser version for reports at least:l Mozilla Firefox: v72.0.2 (64-bit)l

Google Chrome: v84.0.4147.135(64-bit)llatest versions of the browser are recommended

Recommended browser version for general use:l Mozilla Firefox: 91.8.0 (32-bit)l

Google Chrome: 100.0.4896.127 (64-bit)

Recommended screen resolution: 1920x1080 (Full HD), at least 1366x768(Wide XGA)
See also supplied Release Notes for System Requirements.

MODEL-SIMULATOR V3.1 | User Guide

4 Getting Started | 45

Note
Check whether there are company-specific restrictions regarding upload size.
This has to be enabled by your administrator if necessary.

4.2

First Steps for Users
This chapter gives you an overview and rough information of the first steps andhow to start.
Activate your account
The activation link is sent to the registered e-mail address and valid for a limited
time frame. Set your initial password as soon as possible. If your link got invalid,order a new one by contacting the support team or Admin User. Beside the
MODEL-SIMULATOR account you get an account for the Customer Support
Portal.

Note
You may check your spam e-mail folder as the registration e-mails sometimes
got there.
Sign in with multi-factor authentication
With each sign in you will receive an authentication code as time-based one-time
password (TOTP) to authenticate your user. See "Multi-Factor Authentication"
on page 56.
Welcome to the dashboard
To successfully create a project (3) we recommend to start with your model
upload (1) and your campaign creation (2).

MODEL-SIMULATOR V3.1 | User Guide

4 Getting Started | 46

Fig. 4-1: First steps in the MODEL-SIMULATOR
Step 1: Upload your simulation model into the model repository
The model repository is a dedicated space to upload and manage all models.
You can either select a virtual vehicle or a subsystem.
Both model types require a ZIP file to be uploaded. The ZIP must include thedeployables as a ZIP and a simConfig folder including an STI file at least – both ina folder called COSYMprj. See "Check Model Data" on the next page.
For instructions see chapter 5 "Working with MODEL-SIMULATOR" on page 52
and subchapter 5.10 "Models" on page 77.

Note
Only the deployables (cloud_deployable.zip) can be generated withCOSYM. The overall ZIP file and the remaining files and the folder inside must be
created and added manually.
You can enable cloud deployable creation via View > Settings in COSYM. For
more details see topics "Settings" and "Build" in COSYM User Guide or press F1 in
COSYM and navigate to User Interface > Settings and System Build > Build.
Step 2: Create a campaign and upload or generate your stimuli file(s)Campaigns are used to manage simulation campaigns with individual scope.
You can either select a virtual vehicle campaign, subsystem campaign or test execution campaign according to your selected model.
A subsystem campaign requires one or more measurements files in MDF format(*.mf4). A virtual vehicle campaign must be uploaded as one ZIP file, with a subordinate folder containing one or multiple folders for each simulation run (trip).
Each of these folders contains one stimuli file (*.mf4) and optionally one parameter file (*.cdfx). For the test execution campaign you need a ZIP file with your

MODEL-SIMULATOR V3.1 | User Guide

4 Getting Started | 47

ECU-Test project folder, without Report folder.
For instructions see chapter 5 "Working with MODEL-SIMULATOR" on page 52
and subchapter 5.9 "Campaigns" on page 66.
Step 3: Create a project and run simulations
Projects are used to create and manage individual simulation or test execution
tasks. Assign a model and one or multiple campaigns to the project.
To assign one or multiple campaigns to a project, a new /test execution group
has to be created in the simulations/tests tab.
For instructions see chapter 5 "Working with MODEL-SIMULATOR" on page 52
and subchapter 5.8 "Projects" on page 60.
The outputs of simulations are reports (*.html) and simulation results (*.mf4) or
test execution results (*.zip). They can be downloaded in the reports, simulations or tests tab.

4.3

Check Model Data
Simulation models used in MODEL-SIMULATOR have to be created with COSYM
Software , V3.4 for projects). Other models cannot be processed by the application.

Data Structure
The application expects a dedicated folder structure.
The SimulationModel.zip contains:> COSYMprj folder withmodel binaries/executable as *.zip, e.g. cloud_deployable.zip (mandatory)
configuration files in simConfig folder:lsignal mapping file as *.smf (optional)

Note
A signal mapping file is only required if the labels in the CDFX file do
not match the model's internal calibration variable names to ensure
correct mapping. Otherwise, this could lead to wrong simulation results.
lparameter file as *.cdfx (optional)ldatalogger configuration file as *.dlc4 (optional)lsignal interpolation file as *.sti (mandatory)

metadata folder
For projects only the deployables (cloud_deployable.zip of COSYM) are requiredin the following composition.

MODEL-SIMULATOR V3.1 | User Guide

4 Getting Started | 48

Fig. 4-2: Model ZIP file composition (required structure)
See also 3.9.6 "Required Data Structure of Models" on page 28 and 5.2 "Process
Steps" on page 54.
All data has to be zipped in a file for upload. You can enable cloud deployable creation via View > Settings in COSYM. For more details see topics "Settings" and"Build" in COSYM User Guide or press F1 in COSYM and navigate to User Interface> Settings and System Build > Build.

Note
Only the deployables (cloud_deployable.zip) can be generated withCOSYM. The overall ZIP file and the remaining files and the folder inside must be
created and added manually.
See 5.10.3 "Required Preprocessing Steps for Models" on page 79.

4.4

Check Campaign Data
Stimuli files used in MODEL-SIMULATOR have to be created in an appropriate
way. You must ensure the correct mapping of measuring channels from the timeseries and the model inputs by providing an SMF file (see 4.3 "Check Model Data"on the previous page). Deviating data cannot be processed by the application.
See also 3.6 "Compatibility of Campaigns and Models" on page 19.

4.4.1

Data Structure for Subsystem Campaign
The following dedicated requirements have to be fulfilled:*.mf4 Version (ASAM Standard for MDF)

MODEL-SIMULATOR V3.1 | User Guide

4 Getting Started | 49

After uploading the MF4 files are shown and downloadable in the Files tab of thecampaign.

4.4.2

Data Structure for Virtual Vehicle Campaign
The following dedicated requirements have to be fulfilled:*.zip contains subordinate folder with one or multiple simulation run folders
each folder with one *.mf4 (ASAM Standard for MDF) and optionally one*.cdfx file (ASAM Standard for CDF)

Fig. 4-3: Virtual vehicle campaign ZIP file composition (required structure)
See also 3.9.4 "Required Data Structure of Virtual vehicle campaigns" on page 23
and 3.10 "Stimuli File Requirements (*.mf4)" on page 34.

Note
It is necessary to ensure the compatibility of the simulation model and the usedcampaigns. See 3.6 "Compatibility of Campaigns and Models" on page 19
After upload the MF4 and CDFX files are shown and downloadable in the Files tabof the campaign.

4.4.3

Data Structure for Test Execution Campaign
The following dedicated requirements have to be fulfilled for campaigns without
libraries:*.zip contains a folder (e.g. Test)
test folder contains at least Packages, Configurations and .workspacefolder of ECU-Test.

MODEL-SIMULATOR V3.1 | User Guide

4 Getting Started | 50

Fig. 4-4: Test execution campaign ZIP file composition for campaigns without libraries (required structure)
The following dedicated requirements have to be fulfilled for campaigns with libraries:*.zip contains a folder (e.g. Test)*zip contains one ore more library workspace folder*.zip contains the folder "Project"
Project folder contains at least Packages, Configurations and .workspacefolder of ECU test.

MODEL-SIMULATOR V3.1 | User Guide

4 Getting Started | 51

Fig. 4-5: Test execution campaign ZIP file composition (required structure) for
campaigns with libraries
The ECU test project folder can be zipped (without Report folder) and uploaded.
It is only important that the individual folders are embedded in a parent folder andthat this folder is zipped. In the Files tab of the campaign only PRJ files are shownand downloadable.

MODEL-SIMULATOR V3.1 | User Guide5 Working with MODEL-SIMULATOR | 52

5

Working with MODEL-SIMULATOR
The Working with section provides information with focus on step-by-step
instructions as how-tos. In addition, the subchapters also contain descriptions at
the beginning.
Conceptual background of the MODEL-SIMULATOR is described in 3 "Basics of
MODEL-SIMULATOR" on page 11.

5.1

Toolchain and Tool Versions
MODEL-SIMULATOR supports different tool chains and VLAB bundle versions. For
more information, see Toolchain and Tool Versions in CLI User Guide.
Toolchain

Supported Tool Versions

Required
Artifacts

VersionTool

ECUTEST +ECUTEST

2023.2.3

Campaign,

COSYM

COSYM

3.4

vehicleECUTEST

2024.2.3

COSYM

3.4.1

ECUTEST +ECUTEST

2023.2.3

MOBI

MOBI

5.0.1

ECUTEST

2024.2.3

MOBI

5.0.1

ECUTEST

2023.2.3

ECUTEST +VLAB_BUNDLE + VLAB_BUNDLE
MOBI

Campaign

Campaign

2.0(see VLAB Bundle for 2.0)
MOBI

5.0.1

ECUTEST

2024.2.3

VLAB_BUNDLE

2.0(see VLAB Bundle for 2.0)
MOBI

5.0.1

ECUTEST

2024.2.3

VLAB_BUNDLE

3.0(see VLAB Bundle for 3.0)
MOBI

5.1.1

5.0.1

VLAB Bundle Versions
A VLAB bundle is a combination of a specific version of the VLAB tool and tool
boxes.

MODEL-SIMULATOR V3.1 | User Guide5 Working with MODEL-SIMULATOR | 53

VLAB Bundle 2.0
The following table shows the components of VLAB_BUNDLE 2.0.
VLAB

2.8.5

can-2.5.0-win-vc140-x64.vlabtoolbox

2.5.0

rh850-3.4.4-win-vc140-x64.vlabtoolbox

3.4.4

rh850-icum-3.4.1-win-vc140-x64.vlabtoolbox

3.4.1

rh850g4-icum-126.0-win 140-x64.vlabtoolbox

1.26.0rh850g4-1.26.0-win-vc140-x64.vlabtoolbox

1.26.0

ASAM XiL

2.1.0

Custom Tool Adapter

1.0

VLAB Bundle 3.0
The following table shows the components of VLAB_BUNDLE 3.0.
VLAB

2.9.3

can-3.0.0-win-vc142-x64.vlabtoolbox

3.0.0

rh850g4-icum-2.0.0-win-vc142-x64.vlabtoolbox

2.2.0

rh850g4-2.2.0-win-vc142-x64.vlabtoolbox

2.2.0

ASAM XiL

2.1.0

Custom Tool Adapter

1.0

MODEL-SIMULATOR V3.1 | User Guide5 Working with MODEL-SIMULATOR | 54

5.2

Process Steps
The typical overall workflow is designed in the following steps.
1. Preprocessing for models (not covered by the MODEL-SIMULATOR):l

Integrate models in COSYM V3.4 on the PC.

lBuild the deployables (Target = SiL_target) in COSYM V3.4 on the PC.
(You can enable cloud deployable creation via View > Settings in
COSYM. For more details see topics "Settings" and "Build" in COSYM
User Guide or press F1 in COSYM and navigate to User Interface > Set-tings and System Build > Build.)l

Mandatory: Create the interpolation file (*.sti) with a text editor and thesample file format, see "Create a STI File" on page 81.

l

Optional: Create the signal mapping file (*.smf) with Sut Mapping File
Editor (tool usually comes with COSYM), see "Create a SMF File" onpage 82.

l

Optional: Create the parameterization file (*.cdfx) with COSYM, EE(Experiment Environment) or other ASAM CDF supported tool.

l

Optional: Create the datalogger configuration file (*.dlc4) with EE(Experiment Environment)g Datalogger tab.

l

Configure the model ZIP file on the PC and check all files (see 3.9.6"Required Data Structure of Models" on page 28).

lIntegrate models in COSYM V3.4 on the PC.

2. Sign in to the MODEL-SIMULATOR.
3. Create model by uploading simulation model (see 5.10.11 "Create a Model"
on page 84).
4. Optional: Preprocess virtual vehicle campaign (not covered by MODELSIMULATOR)
see 4.4 "Check Campaign Data" on page 48 or 3.9 "Upload Files Overview
and Supported File Formats (Artifacts)" on page 21.
5. Create campaign by uploading stimuli file(s) or campaign ZIP file for simulation (see 5.9.9 "Create a Subsystem Campaign" on page 73, 5.9.10"Create a Virtual Vehicle Campaign" on page 74 or "Create a Test Execution
Campaign" on page 74).
6. Optional: Create a report template by uploading an EATB template (if notalready available).
7. Create project(see "Create a Project" on page 61).
8. Run test execution in the project (see 5.8.11 "Run Test Executions in a Project" on page 64).
9. Download test execution results (see "Download Test Execution Results"
on page 66).

MODEL-SIMULATOR V3.1 | User Guide5 Working with MODEL-SIMULATOR | 55

5.3

User Interface
The user interface is divided into 4 areas:
Header (1): gives you direct access to, among others, home screen, notifications of current processes or user documentation.
Breadcrumb (2): shows where you are and allows you to use for navigation.
Navigation bar (3): provides you access to home (on page 58), Projects(on page 60), Campaigns (on page 66) model repository (on page 77).
Interaction area (4): Depending on the selection in the navigation bar, different content is displayed and different features are available.

Fig. 5-1: Overview of user interface areas
After signing in, you get to the home screen with your dashboard showing an
extract of the latest , projects, campaigns and models each in a separate tile.
Every menu item of the navigation bar contains the possibility to open an overview or to create an item according to the selection.

5.4

Input Forms
For creating projects, campaigns or models input forms are used. This supports
you to easily create items on one page. The input forms are designed similarly.
The campaigns section gives you the possibility to access the entry sections via
the summarized steps on the right instead of just scrolling down.

MODEL-SIMULATOR V3.1 | User Guide5 Working with MODEL-SIMULATOR | 56

5.5

Multi-Factor Authentication
The multi-factor authentication provides a secure way to sign in to the MODELSIMULATOR. Every sign in you have to authenticate your user with an authentication code.
That means you need a generated password in addition to the self-created password. For the authentication you need an application on your mobile phone,mobile device or on your PC that generates a time-based one-time password(TOTP). There are several authentication apps on the market which are working
very similar. They can be found in the internet or app stores using the keywords"Authentication" or "TOTP" for example.

5.5.1

Set up TOTP Authentication
For setting up the time-based one-time password (TOTP) authentication the following workflow is designed.

ü Prerequisite: Authentication app is downloaded on mobile device or PC andready to use.
1. Enter username and password in the MODEL-SIMULATOR.
2. Scan QR code with the TOTP application on your device.

or

MODEL-SIMULATOR V3.1 | User Guide5 Working with MODEL-SIMULATOR | 57

Enter secret code in the TOTP application on your device.
ð A TOTP code will be shown.
3. Enter this code in the OTP code field.
ð Sign In page is shown.
4. Enter username and password .
5. Enter this code in the OTP code field.
The MODEL-SIMULATOR dashboard is shown.

5.5.2

Sign in via TOTP
1. Open TOTP application on PC or mobile device.
2. Go to Sign in page of the MODEL-SIMULATOR.
3. Enter username and password.
4. Enter the code you received via TOTP application.
The MODEL-SIMULATOR dashboard is shown.

5.6

HeaderIn the header you can check current processes (1) or open support section (2).
With the user profile symbol (3) you can change your password and sign out. The
ETAS logo brings you to the ETAS website (4), the breadcrumb (5) shows where
you are and allows you to use for navigation.

Fig. 5-2: Overview of header areas
The header section provides you several features:

MODEL-SIMULATOR V3.1 | User Guide5 Working with MODEL-SIMULATOR | 58

Opens home section with your dashboard.
Shows current background actions and theirprogress:blue symbolizes an ongoing action,
red symbolizes a failed action,
yellow shows a partly successful action,andgreen shows a successful procedure.
By clicking on it you get more details. The number indicates number of current actions.
Opens support section with access to User
documentation, Support contact, Data protection notice, Imprint or Safety Advice andmore.
Opens my account section where you canchange your password or sign out.
Opens ETAS website in a new tab.

5.6.1

Change Password
Quick Access:(header) > Change password
1. Go to My accountg Change password in the header.

ð Change password site is displayed.
2. Enter required fields and Change password.

5.7

Home
The home section with your dashboard gives you an overview of the latest:
Projects (1)campaigns (2)Model repository (3)see Fig. 5-3: "Overview of dashboard (home) areas" on the next page
It shows a selection of each, within every tile you can directly jump into the sections and elements.
The dashboard combines many functionalities of the MODEL-SIMULATOR, thatmeans you can use it as central control and it is the fastest way to execute most

MODEL-SIMULATOR V3.1 | User Guide5 Working with MODEL-SIMULATOR | 59features except simulations. Within every section you can get to the overviews or
the details of a selected item and create a project, campaign or model. Test executions are located in a separate tab in a project.

Fig. 5-3: Overview of dashboard (home) areas
The home section provides you several features:
Opens overview of selected item (projects,
campaigns or models).
Opens detail site of selected item (projects,
campaign or model). You can also click on a
project, campaign or modelname to get to thedetail site. Afterwards you have the possibility
to edit details.
Opens project section with entry form where
you can create a new project.
Opens campaigns section with entry form
where you can create a new subsystem campaign. Use split button to select virtual vehicle
campaign, test execution campaign for campaign creation.
Opens models section with entry form where
you can create a new model.

MODEL-SIMULATOR V3.1 | User Guide5 Working with MODEL-SIMULATOR | 60

5.8

Projects
A Project contains the following items.
Tests (including campaigns): show and manage tests (add, run, stop or
delete tests), see further information like execution status and result
statusModels: show used models (type and status)
Project details: show and edit project information
Every item can be addressed via a separate tab in an opened project.

Fig. 5-4: Project details (screenshot)
If you are interested in conceptual background information, check 3.3.1 "Projects"
on page 12.

5.8.1

Open Projects Overview
Quick Access:Projects(navigation bar) > Projects overview

1. Go to Projects g Projects overview in the navigation bar.
ð All projects are displayed.
2. Open project by clicking on name or using

5.8.2

to get to the detail site.

Search Projects
Quick Access:Projects(navigation bar) > Projects overview>

1. Go to Projects g Projects overview in the navigation bar.
ð All projects are displayed.

MODEL-SIMULATOR V3.1 | User Guide5 Working with MODEL-SIMULATOR | 61

2. Type in your keyword into the search box (Filter projects) to filter listof all projects.
ð All columns are searched while typing and results are displayed.
Search operators like "", *, AND, etc. cannot be used.

5.8.3

Filter Projects Overview
Quick Access:Projects(navigation bar) > Projects overview

1. Go to Projects g Projects overview in the navigation bar.
ð All projects are displayed.
2. Click on dropdown (Limit filter columns) to limit columns to which
the search filter should be applied.
ð Selected columns are searched while typing and results are displayed.
Search operators like "", *, AND, etc. cannot be used.

5.8.4

Sort Projects Overview
Quick Access:Projects(navigation bar) > Projects overview>

1. Go to Projects g Projects overview in the navigation bar.
ð All projects are displayed.
2. Click on column heading to sort projects ascending

and descendingalphabetically or by time (column created on).
ð Selected columns are sorted. When sorting, only the selected column
is considered, the other columns are neglected.

5.8.5

Create a Project
Quick Access:Projects(navigation bar) > New project

1. Go to Projects g New project in the navigation bar.
ð All projects are displayed.
2. Enter required fields:> Project name
> Description (optional)> Select tool chain and corresponding version> Select model
3. Click Create.
ð Project is created and displayed on top of Projects overview.

MODEL-SIMULATOR V3.1 | User Guide5 Working with MODEL-SIMULATOR | 62

5.8.6

Delete a Project
Quick Access:Projects(navigation bar) > Projects overview>

1. Go to Projects g Projects overview in the navigation bar.
ð All projects are displayed.
2. Clickof the project you want to delete (Actions column) and confirm

dialog.
ð Project containing all tests and test results will be deleted.

Note
If you delete an item, this has an influence to the joint use and is deleted for all
current users.

5.8.7

Delete Multiple Projects
Quick Access:Projects(navigation bar) > Projects overview>>

1. Go to Projects g Projects overview in the navigation bar.
ð All projects are displayed.
2. Select multiple projects by activating the check boxes of projects you want
to delete.
3. Clickand confirm dialog.

ð Project containing all tests and test results will be deleted.

Note
You can select all projects by using the checkbox in the table
header. If you delete an item, this has an influence to the joint use
and is deleted for all current users.

5.8.8

Edit a Project
Quick Access:Projects(navigation bar) > Projects overview>

1. Go to Projects g Projects overview in the navigation bar.
ð All projects are displayed.
2. Select project you want to edit by clicking on project name or using.

ð Project details are opened.

MODEL-SIMULATOR V3.1 | User Guide5 Working with MODEL-SIMULATOR | 63

3. Go to Project details tab.
4. To adjust project name or Description selectEdit.

5. Click Save.

5.8.9

Open Project Details
Quick Access:Projects(navigation bar) > Projects overview>

1. Go to Projects g Projects overview in the navigation bar.
ð All projects are displayed.
2. Select project you want to open by clicking on project name or using.

ð Project details are opened.
3. Browse through the tabs.

5.8.10

Add Test Execution Group(s) to a Project
Quick Access:Projects(navigation bar) > Projects overview>> Tests tab

ü Prerequisite: project created. (See Create a Project)
ü Prerequisite: campaign(s) created. (See "Create a Test Execution Campaign"on page 74)
1. Go to Projects g Projects overview in the navigation bar.
2. Select project you want to provide with test(s) by clicking on project nameor using.

ð Project details are opened.
3. Go to Tests tab.
4. Click New test execution group.

ð New test execution group entry form is opened.
5. Enter required fields:> Test execution group name
> Description (optional)> Select campaign(s) with double click

Note
You can select more than one campaign by using STRG/CTRL key andwant to select all campaigns, use. If you.

6. Click Create.
ð Test execution group is created and displayed on top of Tests tab.

MODEL-SIMULATOR V3.1 | User Guide5 Working with MODEL-SIMULATOR | 64

5.8.11

Run Test Executions in a Project
Quick Access:Projects(navigation bar) > Projects overview>> Tests tab >ü Prerequisite: project created. (See Create a Project)
ü Prerequisite: test execution group(s) created and labeled with READY . (See
Add Test Execution Group(s) to a Project)
1. Go to Projects g Projects overview in the navigation bar.
ð All projects are displayed.
2. Select project by clicking on project name or using.

ð Project details are opened. Tests tab is shown.
3. Select

to start test execution.

ð Test execution is started.

Note
You can also start single tests of the test execution group. Expand test execution groupand click individual start button of the test level (test exe-

cution run or test execution job).

For information on status labels see 3.11.1 "Test Execution Status" on page 36 and3.11.4 "Tooltips for Campaign Status" on page 38.

5.8.12

Stop Test Executions in a Project
Quick Access:Projects(navigation bar) > Projects overview>> Tests tab >NoteTest executions can just be stopped within a certain time frame.

ü Prerequisite: project created. (See Create a Project)
ü Prerequisite: test execution group(s) created and labeled with RUNNING . (See
Add Test Execution Group(s) to a Project)
1. Go to Projects g Projects overview in the navigation bar.
ð All projects are displayed.
2. Select project by clicking on project name or using.

ð Project details are opened. Tests tab is shown.

MODEL-SIMULATOR V3.1 | User Guide5 Working with MODEL-SIMULATOR | 65

3. Select

to stop selected test execution on e.g. test execution run level.

ð Test execution is stopped and labeled with STOPPED , test execution
job and test execution group are labeled with
INCOMPLETE .
See also 3.11.1 "Test Execution Status" on page 36.

5.8.13

Delete a Test Execution Group in a Project
Quick Access:Projects(navigation bar) > Projects overview>> Tests tab >1. Go to Projects g Projects overview in the navigation bar.
ð All projects are displayed.
2. Select project by clicking on project name or using.

ð Project details are opened. Tests tab is shown.
3. Clickof the test execution group and confirm dialog.

ð Test execution group and containing test execution job(s) and test
execution run(s) as well as containing tests are deleted.

Note
If you delete an item, this has an influence to the joint use and is deleted for all
current users.

5.8.14

Delete a Test Execution Job in a Project
Quick Access:Projects(navigation bar) > Projects overview>> Tests tab >1. Go to Projects g Projects overview in the navigation bar.
ð All projects are displayed.
2. Select project by clicking on project name or using.

ð Project details are opened. Tests tab is shown.
3. Expand4. Click

test execution group to see containing test execution job(s).
of the test execution job and confirm dialog.

ð Test execution job and containing test execution runs are deleted.

Note
If you delete an item, this has an influence to the joint use and is deleted for all
current users.

MODEL-SIMULATOR V3.1 | User Guide5 Working with MODEL-SIMULATOR | 66

5.8.15

Delete a Test Execution Run in a Project
Quick Access:Projects(navigation bar) > Projects overview>> Tests tab >1. Go to Projects g Projects overview in the navigation bar.
ð All projects are displayed.
2. Select project by clicking on project name or using.

ð Project details are opened. Tests tab is shown.
3. Expandtest execution group and test execution job(s) to see con-taining test execution run(s).
4. Clickof the test execution run and confirm dialog.

ð Test execution run is deleted.

Note
If you delete an item, this has an influence to the joint use and is deleted for all
current users.

5.8.16

Download Test Execution Results
Quick Access:Projects(navigation bar) > Projects overview>> Tests tab >ü Prerequisite: Test execution finished and test execution group labeled with
COMPLETED.
1. Go to Projects g Projects overview in the navigation bar.
ð All projects are displayed.
2. Select project you want to open by clicking on project name or using.

ð Project details are opened, Tests tab is shown.
3. Click

5.9

to download the test execution result on different levels.

Campaigns
A Campaign contains the following items.
Campaign details: show and edit campaign information
Campaign properties: show details of testing tool (only for test execution
campaign)
Files: show details and download files.
l parameters (*.cdfx) and measurement (*.mf4) files of a subsystem campaignlmeasurement (*.mf4) files of a virtual vehicle campaign

MODEL-SIMULATOR V3.1 | User Guide5 Working with MODEL-SIMULATOR | 67ltestunit (*.prj) files of a test execution campaign

Reason for unavailability is shown.
Every item can be addressed via a separate tab in an opened campaign.

Fig. 5-5: Campaign details (screenshot)
If you are interested in conceptual background information, check 3.4 "Campaigns" on page 16.

5.9.1

Status Labels for Campaigns
The overview and opened campaigns show also the status:

MODEL-SIMULATOR V3.1 | User Guide5 Working with MODEL-SIMULATOR | 68

Label

Description

AVAILABLE

Campaign is created successfully and ready to use in simulations.

PROCESSING

Campaign is created, but some process in the background isrunning (e.g. unzipping of files).
Refresh and check the latest status, using the refresh button
in Campaigns overview.

UNAVAILABLE

Campaign is created, but some background processing failed(e.g. unzipping). Campaign is not available and cannot be used
for simulations.
See more information in tooltips (hover over labels) in Campaigns overview. Check the reason for unavailability and create
a new campaign.

Tab. 5-1: Overview status labels for campaigns
See also 3.11.4 "Tooltips for Campaign Status" on page 38.

5.9.2

Required Preprocessing Steps for Campaigns
There are 4 campaign types available in the MODEL-SIMULATOR:
subsystem campaigns
virtual vehicle campaigns
test execution campaigns
For subsystem campaigns you just have to be sure to upload MF4 files in Version
4.1 (ASAM Standard for MDF) and to meet 3.10 "Stimuli File Requirements (*.mf4)"
on page 34.

MODEL-SIMULATOR V3.1 | User Guide5 Working with MODEL-SIMULATOR | 69

5.9.2.1

Preprocessing Steps for Virtual Vehicle Campaigns
1. Select the stimuli files on the PC (MDF files as *.mf4, Version 4.1, ASAM
Standard for MDF).
2. Optional: Create the parameter file on the PC (*.cdfx, Version 3.1 or 4.0,
ASAM standard for CDF).
3. Configure the virtual vehicle campaign ZIP on the PC and check all files(see 3.9.4 "Required Data Structure of Virtual vehicle campaigns" onpage 23).

5.9.2.2

Preprocessing Steps for Test Execution Campaigns
1. Create test and configuration in ECU-Test V2023.2.3.
2. Configure the test execution campaign ZIP on the PC and check all files(see 3.9.5 "Required Data Structure of Test Execution Campaigns" onpage 25).

5.9.2.3

ECU-Test Support and Limitations for Test Execution Campaigns
On the tool side, the MODEL-SIMULATOR supports the following features of ECUTest:
ECU-Test Version: V2023.2.3
Workspace ConfigurationlActive projects (PRJ file): Use only active projects as inactive projects
are treated as active projects. If your workspace contains inactive
products delete them in ECU-Test or in the data you upload in the
MODEL-SIMULATOR. If you upload them anyway, they will be shown andused for test execution.
ECU-Test: Project editor: Context menu > Activate

MODEL-SIMULATOR V3.1 | User Guide5 Working with MODEL-SIMULATOR | 70lReferenced projects/packages (PRJ/PKG file): Use artifacts available inworkspace as external references are not supported. If you have references linked, include them into the workspace folder you use for
upload into the MODEL-SIMULATOR. All data which should be used,must be available in the uploaded data (self-contained).
In general the ECU-TEST-workspace has not to contain any externallinks to any artifacts or to any folder (e.g. external folder for reports).

lModel access (TCF file): Use only one model file (e.g. MAPortConfig.xml) and configure one model access in TCF file as multiple runningmodels in parallel are not yet supported. This used model has then bealso selected in the project.
ECU-Test: Test configuration editor: Platform tab > Model accessnode > Model file

Simulation ControllSimulation Control configured in test bench configuration (TBC file):
Start and Stop properties are supported> immediately on loading in TBC> with running the test case> no automatically simulation start or stop
ECU-Test: Test bench configuration editor: Select model node
(Tools and ports) > Properties windowlMultiple configuration changes in project (TBC/TCF file)

Test Result (TRF file)lPossible test result states (displayed in Result status column in Projects)> SUCCESS: All test steps are passing with expected results.
> FAILED: Test is failing due to not matching conditions.
> ERROR: A tool error occured, or a test result is specified as ERROR.
> INCONCLUSIVE: Trigger condition did not occur, no evaluation possible.
ECU-Test: Package editor: Signal recordings & Trace analysis tab> NONE: No comparison of actual and expected value in the project available.
ECU-Test: Package editor: Test case tab
We show in the Result status the label you have set in the Test stepAssertion and Test step result checkbox in ECU-Test, this test step canbe found in the Miscellaneous folder of the Default test steps folder inthe Actions window.

Test Report (TCF file)

MODEL-SIMULATOR V3.1 | User Guide5 Working with MODEL-SIMULATOR | 71lReport configuration is supported (e.g. user-defined information or filters).

lReport format: All report formats are supported with the limitation that
all formats without TRFSPLITReportFormat or only TRFSPLITReportFormat is working due to a ECU-Test defect (this works locally but
not on cloud).

lCollection of LOG files (Content of Messages window of ECU-Test) arepart of the generated report.

Timing (TBC file)In the system two clocks are used: "wall clock" time (ECU-Test) and simulation time (Model). Depending on the model, the model runs faster than inreal time. That means when you use "wait" in ECU-Test, it could be themodel runs longer in simulation, because there is no synchronization. It
must be considered, that these two clocks are not synchronized.
lUsing multiple measurements to check if a certain condition is fulfilled
as time synchronizationis not supported.

lTimeout of test execution (e.g. not meeting trigger condition): Takecare about timeout-configuration in ECU-Test, there is no global timeout setting in MODEL-SIMULATOR available.

l

Not supported: Time synchronization between "wall clock"-time of ECUTest and simulation time of simulation-ms datalogging via trigger condition (via mapping file).

Interaction of Model created in COSYM and ECU-TestlASAM XIL API supported (see ASAM XIL API Documentation in COSYM)
ECU-Test: Actions window: Jobs tab > Generic-XIL-API and TBC filelSupported elements from COSYM model in ECU-TestlStandard COSYM modules (e.g. COSYM-CCode, Simulink): All elements like Inports, Outports, Measurements and Calibration variables
are supported.

lImported modules (e.g. FMU): Only Inports and Outports are supported.

ECU-Test: Actions window: Model access tab
See also Known Issue List in Release Notes for more specific information.
After the preprocessing you can create test execution campaigns and upload
the data to the MODEL-SIMULATOR.

5.9.3

MF4 File Creation Tools
MDF4 Lib and MATLAB functions can be used to generate MF4 files automaticallyfor Signals from Simulink. There are also tools available which record data in MDF
format.

MODEL-SIMULATOR V3.1 | User Guide5 Working with MODEL-SIMULATOR | 72

5.9.4

Modify Existing MF4 Fileü Prerequisite: MDA readable tool available (e.g. ETAS MDA or ETAS ASCMO).
1. Open MF4 file.
2. Export MF4 file as ASCII.
3. Open ASCII file in Excel.
4. Change Data.
5. Import ASCII file.
6. Export selected signals as MF4.
You can also use the Calculated Signal function of MDA and extend the existing
MF4 file.

5.9.5Open Campaigns Overview
Quick Access:Campaigns(navigation bar) > Overview

1. Go to Campaigns g Overview in the navigation bar.
ð All campaigns are displayed.
2. Open campaign by clicking on name or using

5.9.6

to get to the detail site.

Search Campaigns
Quick Access:Campaigns(navigation bar) > Overview>

1. Go to Campaigns g Overview in the navigation bar.
ð All campaigns are displayed.
2. Type in your keyword into the search box (Filter campaigns) to filter
list of all campaigns.
ð All columns are searched while typing and results are displayed. Search
operators like "", *, AND, etc. cannot be used.

Note
You can also search for status labels with "available" for example. See
also "Status Labels for Campaigns" on page 67 or "Campaign and Model
Status" on page 37.

5.9.7

Filter Campaigns Overview
Quick Access:Campaigns(navigation bar) > Overview

MODEL-SIMULATOR V3.1 | User Guide5 Working with MODEL-SIMULATOR | 73

1. Go to Campaigns g Overview in the navigation bar.
ð All campaigns are displayed.
2. Click on dropdown (Limit filter columns) to limit columns to which
the search filter should be applied.
ð Selected columns are searched while typing and results are displayed.
Search operators like "", *, AND, etc. cannot be used.

5.9.8

Sort Campaigns Overview
Quick Access:Campaigns(navigation bar) > Overview>

1. Go to Campaigns g Overview in the navigation bar.
ð All campaigns are displayed.
2. Click on column heading to sort Campaigns ascendingalphabetically or by time (column created on).

and descendingð Selected columns are sorted. When sorting, only the selected column
is considered, the other columns are neglected.

5.9.9

Create a Subsystem Campaign
Quick Access:Campaigns(navigation bar) >New subsystem campaign

ü Prerequisite: Campaign data checked. (See "Data Structure for Subsystem
Campaign" on page 48.)
1. Go to Campaigns g New subsystem campaign in the navigation bar.
2. Enter required fields:> Campaign name
> Description (optional)
3. Uploadstimuli file(s) in *.mf4 format. (See "Check Campaign Data" onpage 48 and 3.10 "Stimuli File Requirements (*.mf4)" on page 34)

Note
The status check and status display VALID or INVALID refers only to thefile format not to its content.
4. Click Create.
ð Campaign is created and displayed in Campaigns overview. Upload
progress of files can be seen in the header.

MODEL-SIMULATOR V3.1 | User Guide5 Working with MODEL-SIMULATOR | 74

5.9.10Create a Virtual Vehicle Campaign
Quick Access:Campaigns(navigation bar) >New virtual vehicle campaign

ü Prerequisite: Campaign data checked. (See "Check Campaign Data" onpage 48)
1. Go to Campaigns g New virtual vehicle campaign in the navigation bar.
2. Enter required fields:> Campaign name
> Description (optional)
3. Upload campaign file in *.zip format with required structure. (See "Check
Campaign Data" on page 48 and 3.10 "Stimuli File Requirements (*.mf4)" onpage 34)Note
The status check and status display VALID or INVALID refers only to thefile format not to its content.
4. Click Create.
ð Campaign is created and displayed in Campaigns overview. Upload
progress of files can be seen in the header.

5.9.11Create a Test Execution Campaign
Quick Access:Campaigns(navigation bar) >New test execution campaign

ü Prerequisite: Campaign data checked. (See "Data Structure for Test Execution
Campaign" on page 49).
1. Go to Campaigns g New test execution campaign in the navigation bar.
2. Enter required fields:> Campaign name
> Description (optional)> Select testing tool
3. Upload ECU-Test data in *.zip format with required structure. (See "Data
Structure for Test Execution Campaign" on page 49).

Note
The status check and status display VALID or INVALID refers only to thefile format not to its content.

MODEL-SIMULATOR V3.1 | User Guide5 Working with MODEL-SIMULATOR | 75

4. Click Create.
ð Campaign is created and displayed in Campaigns overview. Upload
progress of files can be seen in the header.

5.9.12

Delete a Campaign
Quick Access:Campaigns(navigation bar) > Overview>

1. Go to Campaigns g Overview in the navigation bar.
ð All campaigns are displayed.
2. Clickof the campaign you want to delete (Actions column) and con-firm dialog.

Note
If you delete an item, this has an influence to the joint use and is deleted for all
current users.

5.9.13

Delete Multiple Campaigns
Quick Access:Campaigns(navigation bar) > Overview>>

1. Go to Campaigns g Overview in the navigation bar.
ð All campaigns are displayed.
2. Select multiple campaigns by activating the check boxes of campaigns you
want to delete.
3. Clickand confirm dialog.

Note
You can select all campaigns by using the checkbox in the table
header. If you delete an item, this has an influence to the joint use
and is deleted for all current users.

5.9.14

Edit a Campaign
Quick Access:Campaigns(navigation bar) > Overview>

1. Go to Campaigns g Overview in the navigation bar.
2. Select campaign you want to edit by clicking on campaign name or using.

MODEL-SIMULATOR V3.1 | User Guide5 Working with MODEL-SIMULATOR | 76

ð Campaign details are opened.
3. Select

5.9.15

Edit to adjust campaign name or Description.

Open Campaign Details
Quick Access:Campaigns(navigation bar) > Overview>

1. Go to Campaigns g Overview in the navigation bar.
2. Select campaign you want to open by clicking on campaign name or using.
ð Campaign details are opened.
3. Browse through the tabs.

5.9.16

Use Campaign(s) in a Project
Quick Access:Projects> Overview(navigation bar) >> Tests tab >ü Prerequisite: project created. (See Create a Project)
ü Prerequisite: test execution campaign(s) created and labeled with AVAILABLE .
(See Create a Test Execution Campaign)
1. Go to Projects g Overview in the navigation bar.
2. Select project by clicking on name or using.

ð Project details are opened.
3. Click New test execution groupto add a test exe-

cution group.
ð Create new test execution group entry form is opened.
4. Enter required fields:> Test execution group name
> Description (optional)
5. Select campaign(s) with double click.

Note
You can select more than one campaign by using STRG/CTRL key andwant to select all campaigns, use. If you.

6. Click Create.
ð Test execution group is created and shown in Tests tab of project.

MODEL-SIMULATOR V3.1 | User Guide5 Working with MODEL-SIMULATOR | 77

5.9.17

Download Stimuli Files of a Campaign
Quick Access:Campaigns(navigation bar) > Overview>> Files tab >1. Go to Campaigns g Overview in the navigation bar.
ð All campaigns are displayed.
2. Select campaign you want to open by clicking on campaign name or using.
ð Campaign details are opened.
3. Open Files tab.
4. Expand

5.10

data and clickfor download.

ModelsA Model contains the following items.
Model details: show and edit model information
Model properties: show and edit real time factor
Files: shows an overview of the uploaded data for the selected model.
These files can be downloaded:l metadata (*.json)ldeployables/executable (*.zip)lsignal mapping (*.smf)

lglobal parameter (*.cdfx)ldatalogger configuration (*.dlc4)lsignal interpolation (*.sti)

Reason for unavailability is shown.

Note
Not all data may be available for download. That depends on what was
uploaded while model creation.

Every item can be addressed via a separate tab in an opened model.

MODEL-SIMULATOR V3.1 | User Guide5 Working with MODEL-SIMULATOR | 78

Fig. 5-6: Model details (screenshot)
If you are interested in conceptual background information, check 3.5 "Models"on page 16.

5.10.1

Status Labels for Models
The overview and opened models show also the status:
Label

Description

PROCESSING

Model is created, but some process in the background is running (e.g. unzipping of files).
Refresh and check the latest status, using the refresh button
in model repository.

AVAILABLE

Model is created successfully and ready to use in projects.

UNAVAILABLE

Model is created, but some background processing failed (e.g.
unzipping). Model is not available and cannot be used for simulations.
See more information in tooltips (hover over labels) in model
repository. Check the reason for unavailability and create a
new model.

Tab. 5-2: Overview status labels for models

MODEL-SIMULATOR V3.1 | User Guide5 Working with MODEL-SIMULATOR | 79

See also 3.11.5 "Tooltips for Model Status" on page 40.

5.10.2

Use Cases
Depending on uploaded data, the following use cases are displayed in the model
repository (usecase column):
All: *.zip with simConfig folder with SMF file and cloud_deployable.zip in
COSYMprj folder is uploaded and can be used for projects, see "Required
Data Structure of Models (Use Case independent)" on page 29.
Test: *.zip with cloud_deployable.zip in COSYMprj folder (without
simConfig folder) is uploaded and can be used only for projects, see"Required Data Structure of Models (Use Case independent)" on page 29.
None: not usable due to incorrect data upload or missing cloud_deployable.zip.

Hovering with the mouse over the Usecase type, the tooltip shows for which use
case this model can be used.

In this example the model can only be used in a projectcombined with a test execution campaign.

5.10.3Required Preprocessing Steps for Models
There are some steps required for the data you have to upload into the Modelrepository.
1. Integrate models in COSYM on the PC(V3.4 for projects).
2. Build the deployables in COSYM on the PC. You can enable cloud deployable creation via View > Settings in COSYM. For more details see topics"Settings" and "Build" in COSYM User Guide or press F1 in COSYM and navigate to User Interface > Settings and System Build > Build.
3. Mandatory: Create the interpolation file (*.sti) with a text editor and thesample file format, see "Create a STI File" on page 81.
4. Optional: Create the signal mapping file (*.smf) with Sut Mapping File Editor(tool usually comes with COSYM).

MODEL-SIMULATOR V3.1 | User Guide5 Working with MODEL-SIMULATOR | 80

Note
The Model's internal variable names have to match with the parameter
file (*.cdfx) within the model ZIP file.
<SHORT-NAME> tag of CDFX (within <SW-INSTANCE> block) file has touse the same name as the label in the mapping file (“SUTMap Testlabel"in the SMF file).
5. Optional: Create the parameterization file (*.cdfx) with COSYM, EE (Experiment Environment) or other ASAM CDF supported tool.
6. Optional: Create the datalogger configuration file (*.dlc4) with EE (Experiment Environment) g Datalogger tab.
7. Configure the model ZIP file on the PC and check all files (see 3.9.6"Required Data Structure of Models" on page 28).

Fig. 5-7: Workflow required preprocessing steps for Models
After the preprocessing you can create and upload Models in the MODELSIMULATOR.

Note
Only the deployables (cloud_deployable.zip) can be generated withCOSYM. The overall ZIP file and the remaining files and the folder inside must be
created and added manually.
See 3.9.6 "Required Data Structure of Models" on page 28.

MODEL-SIMULATOR V3.1 | User Guide5 Working with MODEL-SIMULATOR | 81

5.10.4Models in COSYM
The following workflow steps are required to build a model in COSYM. For detailed
information see seperate COSYM User Guide or press F1 within COSYM to open
the online help.

Fig. 5-8: Overview of steps in COSYM for model creation

5.10.5Create a STI FileThe STI file is a mandatory part of the model ZIP file (see Fig. 3-11 in 3.9.6"Required Data Structure of Models" on page 28) and refers to the ASAM
XIL standard.
1. Open a text editor.
2. Copy the given content below.
3. Enter your values.
4. If necessary copy the SignalDescription section for each signal of thestimuli MF4 file.
5. Go to File > Save As and save your file as STI. (*.sti).
Save that file in the simconfig folder (see Fig. 3-11 in 3.9.6 "Required Data Structure of Models" on page 28 ).
STI File Copy Content<?xml version="1.0" encoding="utf-8"?><SignalDescriptionFile xmlns="http://www.asam.net/XIL/Signal/2.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.asam.net/XIL/Signal/2.0 SignalDescriptionFormat.xsd" version="2.0"><!--XIL API Signal Description File - generated by ETAS Experiment
Environment, ETAS GmbH--><SignalDescriptionSet name="ECS"><!-- Beginning of paragraph <SignalDescription>. Copy for each signal. --><!-- Enter the <SignalDescription name and id>, <DataVectorName> and

MODEL-SIMULATOR V3.1 | User Guide5 Working with MODEL-SIMULATOR | 82

<interpolation value>.--><SignalDescription name="<!-- fill in here -->" id="<!-- fill inhere -->"><SegmentSignalDescription><DataFileSegment><Duration xsi:type="ConstSymbol"><Value></Value> <!-- To be filled in by MODEL-SIMULATOR --></Duration><DataVectorName><!-- fill in here --></DataVectorName><FileName></FileName> <!-- To be filled in by MODEL-SIMULATOR --><Interpolation xsi:type="InterpolationType" value="<!-- fill inhere-->" /><Start><Value>0</Value></Start><TimeVectorName /><ChannelSource /><ChannelPath /><GroupName /><GroupSource /><GroupPath /></DataFileSegment></SegmentSignalDescription></SignalDescription></SignalDescriptionSet><!-- End of paragraph <signalDescription>. --><!-- Link the <SignalDescription> to the signal in the stimuli MF4file.--><Assignments><Link key="<!-- fill in here -->" value="<!-- fill in here-->" /></Assignments></SignalDescriptionFile>

STI is an XML-based data format and can be created with a text editor. See more
information about STI on ASAM website: https://www.asam.net/standards/detail/xil/

5.10.6Create a SMF File
1. Open Sut Mapping File/SMF Editor (e.g press the Windows key and starttyping "Sut ..") .
2. Configure signal mapping file.
3. Go to File > Save As and save your file as SMF. (Smf File Version = Version
4.0, Smf File Version 3.1 = Version 3.1)
See also Sut Mapping File/SMF Editor User Guide (Help > User Guide) for more
information.
SMF is an XML-based data format, see the basic structure:<?xml version="1.0" encoding="utf-8"?><SutLabelMapping xmlns:xsi= "http://www.w3.org/2001/XMLSchemainstance" xmlns:xsd= "http://www.w3.org/2001/XMLSchema" ext=".smf" verr="4.0" typ="SuT Mapping File"><ToolLabelList><ToolLabelInfo /><DataTypeInfo /></ToolLabelList><TestLabelList>

MODEL-SIMULATOR V3.1 | User Guide5 Working with MODEL-SIMULATOR | 83

<TestLabelMapper /></TestLabelList><HierarchyList><Hierarchy Path /></HierarchyList></SutLabelMapping>See one example for Signal v_TargetSpeed (SMF Version 3.1)<?xml version="1.0" encoding="utf-8"?><file xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" ext=".smf"
typ="SUT Mapping File" ver="3.1" xsi:noNamespaceSchemaLocation="http://www.etasgroup.com/downloads/xmlns/labcar_automation/lca_smf_
v3.1.xsd"><!--Target Speed--><SUTMap TestLabel="v_TargetSpeed" ToolLabel="TripAdapter/Inports/v_Stim_kmph" Hierarchy="TripAdapter" SUTTypee="Measurement" ObjectType="Scalar" DataType="Float" Comment=" Target
Speed for Trip Adapter" Max="" Min="" Unit="" XUnit="kmph" YUnit=""/></file>5.10.7

Open Models Overview
Quick Access:Models(navigation bar) > Overview

1. Go to Models g Overview in the navigation bar.
ð All Models are displayed.
2. Open model by clicking on name or using

5.10.8

to get to the detail site.

Search Models
Quick Access:Models(navigation bar) > Overview>

1. Go to Models g Overview in the navigation bar.
ð All Models are displayed.
2. Type in your keyword into the search box (Filter models) to filter list of
all Models.
ð All columns are searched while typing and results are displayed. Search
operators like "", *, AND, etc. cannot be used.

Note
You can also search for status labels with "available" or model type with"virtual" for virtual vehicle models for example. See also "Status Labels for
Models" on page 78 or "Campaign and Model Status" on page 37.

MODEL-SIMULATOR V3.1 | User Guide5 Working with MODEL-SIMULATOR | 84

5.10.9Filter Models Overview
Quick Access:Models(navigation bar) > Overview

1. Go to Models g Overview in the navigation bar.
ð All Models are displayed.
2. Click on dropdown (Limit filter columns) to limit columns to which
the search filter should be applied.
ð Selected columns are searched while typing and results are displayed.
Search operators like "", *, AND, etc. cannot be used.

5.10.10

Sort Models Overview
Quick Access:Models(navigation bar) > Overview>

1. Go to Models g Overview in the navigation bar.
ð All Models are displayed.
2. Click on column heading to sort models ascending

and descendingalphabetically or by time (column created on).
ð Selected columns are sorted. When sorting, only the selected column
is considered, the other columns are neglected.

5.10.11Create a Model
Quick Access:Models(navigation bar) >New model

ü Prerequisite: Model data checked.
1. Go to Models g

New model in the navigation bar.

2. Select model type. (See "Models" on page 16 for more information.)
3. Enter required fields:> Model name> Real time factor> Description (optional)
4. Click Upload and select ZIP file. (See Check Model Data)

Note
The status check and status display VALID or INVALID refers only to thefile format not to its content.

MODEL-SIMULATOR V3.1 | User Guide5 Working with MODEL-SIMULATOR | 85

5. Click Create.
ð Model is created and displayed in model repository when upload was
successful. Upload progress of files can be seen in the header.

5.10.12

Delete a Model
Quick Access:Models(navigation bar) > Overview>

1. Go to Models g Overview in the navigation bar.
ð All Models are displayed.
2. Clickof the model you want to delete (Actions column) and confirm

dialog.

Note
If you delete an item, this has an influence to the joint use and is deleted for all
current users.

5.10.13

Delete multiple Models
Quick Access:Models(navigation bar) > Overview>>

1. Go to Models g Overview in the navigation bar.
ð All models are displayed.
2. Select multiple models by activating the check boxes of models you want
to delete.
3. Clickand confirm dialog.

Note
You can select all models by using the checkbox in the table
header. If you delete an item, this has an influence to the joint use
and is deleted for all current users.

5.10.14

Edit a Model
Quick Access:Models(navigation bar) > Overview>

1. Go to Models g Overview in the navigation bar.
2. Select model you want to edit by clicking on model name or using.

ð Model details are opened.

MODEL-SIMULATOR V3.1 | User Guide5 Working with MODEL-SIMULATOR | 86

3. Select

Edit to adjust model name or description.

Real time factor can be edited in the Model properties tab. See also "Edit
Real Time Factor" below.

5.10.15

Edit Real Time Factor
Quick Access:Models(navigation bar) > Overview>

Based on run simulations a new RTF might be proposed which can be applied easily.
1. Go to Models g Overview in the navigation bar.
2. Select model you want to edit by clicking on model name or using.

ð Model details are opened, metadata tab is shown.
3. Go to Model properties tab.
4. Select

5.10.16

Edit to adjust real time factor.

Open Model Details
Quick Access:Models(navigation bar) > Overview>

1. Go to Models g Overview in the navigation bar.
2. Select model you want to open by clicking on model name or using.

ð Model details are opened.
3. Browse through the tabs.

5.10.17

Use Model in a Project
Quick Access:Projects(navigation bar) >New projectü Prerequisite: project created. (See Create a Project)
ü Prerequisite: model created and labeled with AVAILABLE . (See Create aModel)
1. Go to Projects g New project in the navigation bar.
2. Enter required fields:> Project name
> Description (optional)
3. Select one model with double click.
4. Click Create.
ð Project is created and displayed on top of Projects overview.

MODEL-SIMULATOR V3.1 | User Guide5 Working with MODEL-SIMULATOR | 87

5.10.18

Download Files of a Model
Quick Access:Models(navigation bar) > Overview>> Files tab >1. Go to Models g Overview in the navigation bar.
ð All models are displayed.
2. Select model you want to open by clicking on model name or using.

ð Model details are opened.
3. Go to Files tab.
4. Clickfor download.

MODEL-SIMULATOR V3.1 | User Guide

6 Troubleshooting | 88

6

Troubleshooting
What is the difference between a virtual vehicle model anda subsystem model?

VIRTUAL VEHICLE
MODEL vs.
SUBSYSTEM MODEL

A virtual vehicle model represents a powertrain system andhence expects the specific inputs vehicle target speed, gearand road slope. A subsystem model can represent any kind ofsystem.
Read more "Models" on page 16 and "Compatibility of Campaigns and Models" on page 19.
What is a multi-factor authentication? Why do I need that?
To ensure a secure sign in into the MODEL-SIMULATOR we use

MULTI-FACTORAUTHENTICATIONa multi-factor authentication concept. This means only you cansign in with your username, password and a code received by anauthentication application on your mobile device or computer.
Read more "Multi-Factor Authentication" on page 56.

Why does my password need to have 20 characters?

PASSWORDREQUIREMENTS

In general a password is better the longer it is. A password of 20
characters or more is considered to be secure.
More information "Change Password" on page 58.

MODEL-SIMULATOR V3.1 | User Guide

7 Contact Information | 897

Contact Information
Technical Support
For details of your local sales office as well as your local
technical support team and product hotlines, take a look at
the ETAS website:www.etas.com/hotlines
ETAS offers trainings for its products:
www.etas.com/academy

ETAS Headquarters
ETAS GmbH
Borsigstraße 24

Phone:+49 711 3423-0

70469 Stuttgart

Fax:+49 711 3423-2106

Germany

Internet:

www.etas.com

MODEL-SIMULATOR V3.1 | User GuideGlossary | 90

Glossary
This glossary contains abbreviations and explanations of special terms that areimportant.
Campaign
A campaign is based on one or many stimuli files, which are used to feed the
inputs of the simulation model. In the MODEL-SIMULATOR 3 types are selectable: subsystem campaign, virtual vehicle campaign and test execution campaign.
See 3.4 "Campaigns" on page 16.
CDFX
Calibration Data Format (ASAM standard), created with e.g. COSYM, EE (Experiment Environment) or other ASAM CDF supported tool and used to parameterize the models. It can be part of a virtual vehicle campaign or of a model(configuration files) and must be created and added manually.
See 3.4 "Campaigns" on page 16 and 5.10 "Models" on page 77.
It stores calibration parameters of different data types, the physical values
and unit. The XML-based format can be easily validated, edited, imported andexported by calibration tools and XML editors.
DLC4 (ETAS specific file format)
Datalogger configuration, created with e.g. EE (Experiment Environment),
which is used to limit signals for data recording. The file can be used to reduce
processing time, only the listed signals will be part of the simulation result
instead of all. It can be part of a model (configuration files) and must be created and added manually.
See 3.5 "Models" on page 16 and 3.9 "Upload Files Overview and Supported File
Formats (Artifacts)" on page 21.
Home/dashboard
The dashboard is the starting point in MODEL-SIMULATOR and gives an overview of latest projects, campaigns and models. You can create projects andcampaigns or upload models.
MF4/MDF
Measurement Data Format (ASAM standard) used for time series data, e.g.
simulation data results or input stimuli. It is part of a campaign.
See 3.4 "Campaigns" on page 16.
Model
A model is a mathematical representation of a physical system.

MODEL-SIMULATOR V3.1 | User GuideGlossary | 91

It calculates the resulting system behavior (model outputs) according to thefed excitation signals (input stimuli). In the MODEL-SIMULATOR two types ofmodel can be uploaded: subsystem model and virtual vehicle model.
While a subsystem model can represent any kind of system, a virtual vehicle
model represents a powertrain system, hence expects the specific inputs
vehicle target speed, gear and road slope.
Model repository
The model repository is a dedicated space to upload and manage all models in
the MODEL-SIMULATOR.
Real time factor (RTF)
The RTF is a factor that describes how fast a simulation runs in comparison toreal time. An initial value can be determined by running a simulation in COSYM
and dividing the simulation time by the duration of stimuli file. RTF = Durationof simulation/Duration of stimuli fileSee 3.5.1 "Real Time Factor (RTF)" on page 17.
SMF (ETAS specific file format)
Signal mapping file, created with e.g. Sut Mapping File Editor (usually comeswith COSYM) and used for global mapping of vehicle model variables to stimuli
file signal names. It can be part of a model (configuration files) and must be
created and added manually.
See 3.5 "Models" on page 16 and 3.9 "Upload Files Overview and Supported File
Formats (Artifacts)" on page 21.
The XML-based format can be edited by an XML editor.
STI
Generic Simulator Interface (ASAM standard), Interpolation file, created withe.g. EE (Experiment Environment) and used to interpolate input signals. It
must be part of a model (configuration files) and must be created and added
manually.
See 3.5 "Models" on page 16 and 3.9 "Upload Files Overview and Supported File
Formats (Artifacts)" on page 21.
Stimuli files
Stimuli files are needed to feed the model inputs and thus needed to start asimulation. In the MODEL-SIMULATOR it can be measurement files as *.mf4(subsystem campaign) or the combination of measurement files as *.mf4 andparameter files as *.cdfx in folders within a ZIP file (virtual vehicle campaign).
See 3.4 "Campaigns" on page 16.
Subsystem campaign
A subsystem campaign is a campaign based on one or many measurement
files (*.mf4).
See 3.4 "Campaigns" on page 16 and 3.9 "Upload Files Overview and Supported

MODEL-SIMULATOR V3.1 | User GuideGlossary | 92

File Formats (Artifacts)" on page 21.
Subsystem model
A subsystem model represents a part of the vehicle in form of a simulation
model and can be used to represent any kind of system.
See 3.5 "Models" on page 16.
Test execution campaign
A test execution campaign is a campaign based on configured testunits created with ECU-Test. These tests are defined by packages/projects, configurations, data bases, utilities, test reports and configuration files handled ina workspace.
See 3.4 "Campaigns" on page 16 and 3.9.4 "Required Data Structure of Virtual
vehicle campaigns" on page 23.
Virtual vehicle campaign
A virtual vehicle campaign is a campaign based on one or many trips (simulation runs). These trips are defined by one stimuli file (*.mf4) and one parameter file (*.cdfx), whereas the stimuli files have to contain vehicle target
speed, gear and road slope.
See 3.4 "Campaigns" on page 16 and 3.9.4 "Required Data Structure of Virtual
vehicle campaigns" on page 23.
Virtual vehicle model
A virtual vehicle model can be used to represent a whole vehicle in form of asimulation model with respect to a development domain like powertrain.
See 3.5 "Models" on page 16.

MODEL-SIMULATOR V3.1 | User Guide

Figures | 93

FiguresFig. 3-1: Overview workflow steps in the MODEL-SIMULATOR

12

Fig. 3-2: Structure of simulation hierarchy

14

Fig. 3-3: Shown estimated time and estimated costs (tests tab of a project)

15

Fig. 3-4: Compatibility of inputs (models) and signals (campaigns)

19

Fig. 3-5: Use case column in the model repository

19

Fig. 3-6: Virtual vehicle campaign ZIP file composition (required structure)

23

Fig. 3-7: Content of campaign folder in virtual vehicle campaign ZIP file24

Fig. 3-8: Content of simulation run folder in virtual vehicle campaign

25

Fig. 3-9: Test execution campaign ZIP file composition (required structure) for campaigns
without libraries

26

Fig. 3-10: Test execution campaign ZIP file composition (required structure) for campaigns
with libraries

27

Fig. 3-11: Model ZIP file composition (required structure)

28

Fig. 3-12: Content of model ZIP file29

Fig. 3-13: Content of COSYMprj folder in model ZIP file (use case independent)

29

Fig. 3-14: Content of simConfig folder in COSYMprj folder

29

Fig. 3-15: Content of model ZIP file34

Fig. 3-16: Content of COSYMprj folder in model ZIP file (test execution use case)

34

Fig. 4-1: First steps in the MODEL-SIMULATOR

46

Fig. 4-2: Model ZIP file composition (required structure)48

Fig. 4-3: Virtual vehicle campaign ZIP file composition (required structure)

49

Fig. 4-4: Test execution campaign ZIP file composition for campaigns without libraries(required structure)

50

Fig. 4-5: Test execution campaign ZIP file composition (required structure) for campaigns
with libraries

51

Fig. 5-1: Overview of user interface areas

55

Fig. 5-2: Overview of header areas

57

Fig. 5-3: Overview of dashboard (home) areas

59

Fig. 5-4: Project details (screenshot)

60

Fig. 5-5: Campaign details (screenshot)

67

Fig. 5-6: Model details (screenshot)

78

Fig. 5-7: Workflow required preprocessing steps for Models

80Fig. 5-8: Overview of steps in COSYM for model creation

81

MODEL-SIMULATOR V3.1 | User GuideTables | 94

TablesTab. 3-1: Upload files overview for MODEL-SIMULATOR

22

Tab. 3-2: Model ZIP file: content of simConfig folder and specifications

32

Tab. 3-3: Overview status labels for simulation status in projects

36

Tab. 3-4: Overview status labels for campaign/model status

38

Tab. 3-5: Overview tooltips for model status

42

Tab. 5-1: Overview status labels for campaigns

68

Tab. 5-2: Overview status labels for models

78

MODEL-SIMULATOR V3.1 | User Guide