SystemDesk - EB tresos Studio - Workflow Descriptions

SystemDesk - EB tresos Studio

Workflow Descriptions

Usable with Versions:

dSPACE SystemDesk 3.0 and 3.1
EB tresos Studio 2010.a, 10.0

January 04, 2012

1 / 23
SystemDesk - EB tresos Studio - Workflow Descriptions Descriptions

Contents
Contents ..................................................................................................................................................2

1 Introduction ..........................................................................................................................................3

2 Glossary ...............................................................................................................................................4

3 dSPACE SystemDesk..........................................................................................................................5
3.1 Overview .........................................................................................................................................5
3.2 Software Architecture for a Single ECU ..........................................................................................5
3.2.1 Modeling the Software Architecture .......................................................................................5
3.3 Software Architecture for an ECU Network ....................................................................................7
3.3.1 Handling Network Descriptions .............................................................................................7
3.3.2 DBC, LDF, FIBEX ..................................................................................................................8
3.3.3 AUTOSAR System Description ...........................................................................................10
3.4 Connection with AUTOSAR Service Components .......................................................................11
3.5 AUTOSAR ECU Extract ................................................................................................................11

4 EB tresos Studio ................................................................................................................................14

4.1 Creating a Project .........................................................................................................................14
4.2 Importing Data ..............................................................................................................................15
4.2.1 AUTOSAR System Description Importer .............................................................................15
4.2.2 Importing a Network Description .........................................................................................19
4.3 Configuring the Basic Software ....................................................................................................20
4.4 Configuring the RTE .....................................................................................................................21
4.4.1 Data Mapping ......................................................................................................................21
4.4.2 Runnable Entity Mapping ....................................................................................................22
4.4.3 Service Port Mapping ..........................................................................................................22

5 Using the EB tresos SW-C Editor Instead of dSPACE SystemDesk ............................................23

6 Restrictions ........................................................................................................................................23

2 / 23
SystemDesk - EB tresos Studio - Workflow Descriptions

1 Introduction
This document describes the interaction between two AUTOSAR tools, dSPACE SystemDesk and EB
tresos Studio, versions

 SystemDesk 3.0 and 3.1

 EB tresos Studio 2010.a

It is assumed that you are familiar with using these tools, so no introduction to them is provided here.

In the workflows described here, SystemDesk is used as a software design tool, and optionally as a
system design tool. EB tresos Studio is used to configure and generate the AUTOSAR basic software,
as well as for RTE configuration and generation.

This application note is subdivided according to tools and to typical use cases. The following use cas-
es are described:

1. Creating the software architecture with dSPACE SystemDesk

a. Creating a software architecture for a single ECU (see section 3.2)
b. Creating a software architecture for an ECU network (see section 3.3)
c. Connecting with AUTOSAR service components (see section 3.4)
d. Using an AUTOSAR ECU extract (see section 3.5)

2. Configuring the basic software incl. RTE with EB tresos Studio (see chapter 4)

The terms used in this document are explained in chapter 2. Chapter 3 looks at the system design tool
SystemDesk and presents different workflows according to different use cases.

Chapter 4 describes how to configure the basic software and RTE in EB tresos Studio. Chapter 5 is
an extra section on the differences when the EB tresos SW-C editor is used instead of dSPACE Sys-
temDesk.

3 / 23
SystemDesk - EB tresos Studio - Workflow Descriptions Descriptions

2 Glossary
ECU composition Composition type of an AUTOSAR application that represents the
interfaces of a single electronic control unit. If only the software ar-
chitecture of a single ECU is described in SystemDesk, the software
architecture element is the ECU composition.
ECU software composition Composition that contains the basic software service components. It
comprises the following modules: ComM, Dcm, Dem, Det, EcuM,
NvM, Os, and WdgM – in other words, all the modules in the basic
software that provide their services to the application in the form of
an AUTOSAR SWC ARXML file.
software architecture The application software, i.e., the software above the RTE.
(SWA)
top-level composition The form in which an application is always referenced by EB tresos
Studio. From SystemDesk's point of view, an EB tresos Studio top-
level composition can also be an ECU composition. This is because
EB tresos Studio always has a view of only a single ECU, unlike
SystemDesk, which provides a view of a whole system.
signal mapping – data Mapping between the data elements of a software architecture and
mapping the network signals. In SystemDesk, this mapping is called signal
mapping, and in EB tresos Studio, it is called data mapping.

4 / 23
SystemDesk - EB tresos Studio - Workflow Descriptions

3 dSPACE SystemDesk
3.1 Overview
This chapter on dSPACE SystemDesk describes workflows for creating a software architecture in
different use cases.
Section 3.2 gives instructions on creating a software architecture for a single ECU in SystemDesk.
Because only one ECU is developed in this scenario, it is not necessary to model a complete system
level. Steps such as signal mapping are performed in EB tresos Studio.

Section 3.3 then presents the workflow for creating a software architecture for an ECU network. In this
workflow, system-related steps such as SWC-to-ECU mapping and signal mapping are performed in
SystemDesk and then transferred to EB tresos Studio.

Section 3.4 explains how to connect the service components to the application components.

Finally, section 3.5 contains important points to note when using an AUTOSAR ECU extract.

3.2 Software Architecture for a Single ECU

This section describes the workflow for creating an AUTOSAR software architecture for a single ECU
only. To create a multi-ECU software architecture, you have to follow the workflow in section 3.3.
SystemDesk is used to model a software architecture, which is then used directly in EB tresos Studio
in the context of a single ECU.

3.2.1 Modeling the Software Architecture

The software architecture is modeled in SystemDesk. In SystemDesk 3.0 and 3.1, the Software Archi-
tecture element is always located within a system. You must therefore first create a system. This sys-
tem already contains a default Software Architecture. In AUTOSAR, a software architecture is speci-
fied as a composition type that is used as a top-level composition in the context of a system. Thus, in
the workflow described here, the software architecture is exported as an AUTOSAR composition type
in SystemDesk and then imported in EB tresos as a top-level composition for an ECU.
This document does not describe how to model a software architecture in SystemDesk, so you should
refer to the SystemDesk Guide for this.

After creating the software architecture in SystemDesk, you should also validate it in SystemDesk
before exporting it to an AUTOSAR file. This helps identify some possible sources of error at this early
stage. However, validation in SystemDesk cannot identify all the potential problems that might be re-
ported by EB tresos Studio in a later step.

In AUTOSAR, elements are always placed in packages. Packages are a namespace concept in
ARXML files. All references between AUTOSAR objects are described by absolute package paths.
Error messages in EB tresos Studio each contain the absolute package path of an AUTOSAR ele-
ment.
SystemDesk does not force you to assign elements to AUTOSAR packages. However, assigning ele-
ments to AUTOSAR packages is recommended, as otherwise the paths that are output in EB tresos
Studio cannot be traced back to the SystemDesk project. You can assign SystemDesk elements to
packages either manually (see the SystemDesk Guide) or by using a script that automatically keeps
the library structure and the package structure synchronized (see SystemDesk Solutions).

When validation has run successfully, and all the elements have been assigned to packages, the AU-
TOSAR export can be performed. To do this, select the software architecture element in SystemDesk
and click Export→AUTOSAR 3.x in its context menu (see Fig. 1).

5 / 23
SystemDesk - EB tresos Studio - Workflow Descriptions Descriptions

Fig. 1: Exporting a software architecture from SystemDesk 3.0

In the dialog that opens, make the settings shown in Fig. 2. These settings are particularly important:
1) "Reference setting: Export all referenced elements recursively". This setting ensures that not
only the software architecture itself is exported, but also all its dependent elements such as
software components, interfaces, data types, etc.
2) "Schema version: Use AUTOSAR 3.1.4 schema". (Schema Version 3.1.4. is the current ver-
sion at the time of writing this document. There may now be a later version that you should
use.)
3) "Base type references: Use BaseTypeGeneric package (best for TargetLink exchange)".
4) "Export internal limits for data types": SystemDesk always uses physical values to specify min-
imum and maximum values, but an RTE generator expects values that have been converted
to the internal representation. This setting ensures that the internal values are also available in
the exported AUTOSAR files.

6 / 23
SystemDesk - EB tresos Studio - Workflow Descriptions

Fig. 2: Settings for AUTOSAR export in SystemDesk 3.0

All other steps are now performed in EB tresos Studio. If changes are made to the software architec-
ture in SystemDesk later, you have to repeat the export and then the import in EB tresos Studio.

3.3 Software Architecture for an ECU Network

Section 3.2 described how a software architecture is modeled for a single ECU. This section now de-
scribes the steps for modeling a multi-ECU software architecture.

The software architecture itself is created in exactly the same way as in section 3. The difference is
that it now contains software components not only for a single ECU, but also for several ECUs.

In SystemDesk, the software components are assigned to the individual ECUs (SWC-to-ECU map-
ping) within a system that already contains the software architecture, according to the AUTOSAR me-
thododology.

Before you can map the components to the ECUs, you first have to tell SystemDesk which ECUs are
involved. They can be created manually, or automatically by importing a DBC, LDF or Fibex file. You
can then use the SWC-to-ECU Mapping Editor to map the software components to the ECUs in the
hardware topology.

Before you can perform the export from SystemDesk to an AUTOSAR file, you have to decide how to
handle network descriptions. There are several ways to do this, as described below.

3.3.1 Handling Network Descriptions

Section 4.2 explains how to handle network descriptions for a single ECU in EB tresos Studio. You
can also use this procedure for several ECUs. The network descriptions are not imported in System-
Desk, but exclusively in EB tresos Studio, as described in section 4.2. In EB tresos Studio, it is always
one single ECU that is described, so the AUTOSAR files have to be imported separately for each
ECU. You also have to perform signal mapping separately for each ECU.

7 / 23
SystemDesk - EB tresos Studio - Workflow Descriptions Descriptions

Alternatively, you can additionally import the network descriptions in SystemDesk. This has the advan-
tage that you do not have to perform signal mapping several times at ECU level, but only once at sys-
tem level. Another advantage is that it is considerably easier to perform signal mapping in System-
Desk, because SystemDesk analyzes the overall system, and the Signal Mapping Editor displays only
those data elements that really have to be mapped. Another alternative is to let SystemDesk perform
signal mapping automatically according to a defined name schema (see Signal Mapping Creator in the
SystemDesk Solutions).

The next sections describe the workflows for performing signal mapping in SystemDesk and then
transferring it to EB tresos Studio.

3.3.2 DBC, LDF, FIBEX

SystemDesk lets you import DBC, LDF and FIBEX files. The imported data is used to specify the
mapping of data elements in the software components to the signals in the network messages (signal
mapping). This mapping can then be imported in EB tresos Studio.

SystemDesk 3.0 and 3.1 are not designed to convert DBC, LDF or FIBEX files to the AUTOSAR sys-
tem description format. It is basically possible to export an AUTOSAR system description from Sys-
temDesk, but the descriptions of the network parts are incomplete. You therefore have to additionally
import the DBC, LDF or FIBEX files in EB tresos Studio so that you can perform automatic configura-
tion of the COM stack.

The basic procedure is shown in Fig. 3. The individual steps are described in detail below.

DBC
LDF
1 Fibex

2 SystemDesk

3
-Software architecture
-SWC-to-ECU mapping
-Signal mapping ARXML
-No network 4
communication

EB tresos Studio

Fig. 3: Workflow with DBC, LDF and FIBEX Files

First you have to import the network description in SystemDesk (step 1 in Fig. 3). You will find instruc-
tions in the SystemDesk Guide.

In the next step, open the Signal Mapping Editor in SystemDesk (step 2 in Fig. 3). In this step, Sys-
temDesk analyzes the software architecture and also the mapping of the software components it con-
tains to the ECUs. The Editor then displays only data elements from ports that are connected to ports
of software components on other ECUs.
However, there are cases where component ports have to remain unconnected because the corres-
ponding transmit or receive ECUs are not described in the SystemDesk project (or not according to

8 / 23
SystemDesk - EB tresos Studio - Workflow Descriptions

AUTOSAR). Nevertheless, the data elements in these ports have to be mapped to network signals. To
allow SystemDesk's Signal Mapping Editor to display the ports' data elements, you have to specify
them as being externally defined. To specify the port of an atomic software component in this way,
open its context menu within the software architecture and click Externally Defined (see Fig. 4). When
you click the Update button in the Signal Mapping Editor, the data elements of the externally defined
ports are displayed.

Fig. 4: Specifying a port as externally defined

The SWC-to-ECU mapping and also the signal mapping have now been specified in SystemDesk. The
system is ready for export to an AUTOSAR file (step 3 in Fig. 3). As described above, SystemDesk is
not designed to convert DBC, LDF or FIBEX files into a complete AUTOSAR system description. The
system description is therefore exported without the communication parts. It does contain the signal
mapping and the SWC-to-ECU mapping, however.
Before running the export, ensure that the elements of the communication matrix are assigned to an
AUTOSAR package. EB tresos Studio always uses a fixed name structure. You can choose any name
for the first package. The subpackages must be used as follows:
 All system signals must be in the SYSSIGNALS subpackage.
 All frames must be in the FRAMES subpackage.
 All I-signals must be in the ISIGNALS subpackage.
 All PDUs must be in the PDUS subpackage.

SystemDesk 3.0/3.1 automatically creates this structure when DBC, LDF or Fibex files are imported,
so manual modifications are not usually necessary. However, you do have to assign the communica-
tion folders under the Network Communication to AUTOSAR packages. You can do this either ma-
nually or automatically with the help of the PackageSync script (see SystemDesk Solutions on the
dSPACE website). SystemDesk always gives the top communication folder the same name as the
imported file. You must use this name as the package name when you subsequently perform the im-
port in EB tresos Studio, so that the signal mappings can be assigned correctly. Fig. 5 shows the set-
tings for exporting the system description without the communication parts. All the other settings can
be made as shown in Fig. 2.

9 / 23
SystemDesk - EB tresos Studio - Workflow Descriptions Descriptions

Fig. 5: System export without communication parts

The AUTOSAR system description exported from SystemDesk contains all the specified ECUs. It is
therefore not formally an ECU extract. From the point of view of EB tresos Studio, this is not a prob-
lem, because EB tresos Studio forces the selection of exactly one ECU during the AUTOSAR import
and therefore works internally with an ECU extract.

3.3.3 AUTOSAR System Description

The workflow described in this section is similar to the previous one, except that the network descrip-
tion is already available as an AUTOSAR system description. In other words, in this scenario the
communication matrices are not created in SystemDesk, but are already available.

Because SystemDesk 3.0/3.1 is not designed to store the AUTOSAR communication parts in the
project completely, this scenario also uses the approach of importing the communication matrices in
SystemDesk and in EB tresos Studio.

In SystemDesk 3.0/3.1, the AUTOSAR system description is imported (step 1 in Fig. 6). SystemDesk
then creates a system node that contains a hardware topology and a network communication. If the
file already contains a software architecture, that is also imported. Alternatively, it can be modeled
after import into SystemDesk.
In the next step, the SWC-to-ECU mapping and the signal mapping in SystemDesk are performed
(step 2 in Fig. 6). In the final step, the system is exported back to an AUTOSAR file (step 3 in Fig. 6),
though in this case the communication parts are not exported. You should therefore make the export
settings as shown in Fig. 5.

10 / 23
SystemDesk - EB tresos Studio - Workflow Descriptions

-Network
communication
ARXML
1

2 SystemDesk

3
-Software architecture
-SWC-to-ECU mapping
-Signal mapping ARXML
-No network 4
communication

EB tresos Studio

Fig. 6: Workflow with ARXML network descriptions

Both AUTOSAR files are imported in EB tresos Studio. You have to create two system description
importers in EB tresos Studio as described in section 4.2.1. One importer imports the software archi-
tecture (see Fig. 13), the other importer imports the communication parts (see Fig. 14).

3.4 Connection with AUTOSAR Service Components

In AUTOSAR, there are some basic software modules that have an interface to the application com-
ponents (for example, DEM and EcuM). Such modules are also called service components because
they make specific services available to the application components just like software components do.
The actual specification of the service components is always project-dependent. First, you have to
configure a module of this kind in EB tresos Studio, then you can generate the service component
description, and finally, you can connect the ports of the service components to the ports of the appli-
cation components. All these steps can be performed in EB tresos Studio (see section 4.4.3).
You must ensure that the ports of the application components are compatible with the ports of the
service components, as otherwise RTE generation is not possible. This means that the interface de-
scriptions of the services are required during the creation of the software architecture in SystemDesk.

EB tresos Studio therefore lets you export all the service components in the basic software in an ele-
ment called the ECU software composition. This step is shown in Fig. 19 (button 2). For further details
on the service components in EB tresos Studio, refer to section 4.4.3.

The ECU software composition exported from EB tresos Studio now does not need to be completely
imported in SystemDesk. Instead, you should import only the required interfaces into the library of a
SystemDesk project. These can then be used for the ports of the application components.

3.5 AUTOSAR ECU Extract

This section describes the workflow for handling an AUTOSAR ECU extract in use cases where one is
made available to the SystemDesk user. There are two different kinds of ECU extract:
1. The ECU extract contains only the communication parts.
2. In addition to the communication parts, the ECU extract already contains the software compo-
nents (usually in the form of compositions) and mappings (SWC-to-ECU and data elements-
to-network signals).

11 / 23
SystemDesk - EB tresos Studio - Workflow Descriptions Descriptions

The workflow for cases where the ECU extract contains only the communication parts was described
in section 3.3.3 above. The following description therefore relates to cases where the ECU extract also
contains software components.

Because the ECU extract provided by the OEM already contains the communication parts and the
signal mapping, only the software components (incl. the top-level composition) are imported and ex-
ported in SystemDesk. The communication parts and the mapping are then imported directly in EB
tresos Studio (see Fig. 7).
ECU-Extract:
-Network communication
ARXML -ECU composition
1 -Signal mapping

2 SystemDesk

-ECU composition
3

ARXML

EB tresos Studio

Fig. 7: Workflow with an AUTOSAR ECU extract

In the first step, you have to import the top-level composition, including all its dependent elements,
from the ECU extract to the project library of a SystemDesk project (step 1 in Fig. 7). This top-level
composition is sometimes called an ECU composition (this must not be confused with an ECU soft-
ware composition, which contains only the basic software service components). In the import dialog,
select only the ECU composition, but not the system element. SystemDesk then selects all the depen-
dent elements automatically. Finally, click Finish Import to import the ECU composition as a composi-
tion type. If you also want to use this element as a software architecture element in SystemDesk, you
can now create a new system in SystemDesk and then drag the ECU composition to the new system
from the library.
Fig. 8 shows an example of SystemDesk's AUTOSAR Import dialog. As you can see, the imported
ARXML file also contains a system element that is always a part of an AUTOSAR ECU extract. You
must select only the ECU composition in the dialog, but not the system itself. In this example, the
name of the ECU composition is ECUComposition. This name is not mandatory, however.
Fig. 9 shows the imported ECU composition both as a composition type in the project library and as a
software architecture in a system.

12 / 23
SystemDesk - EB tresos Studio - Workflow Descriptions

Fig. 8: Importing an ECU composition from an ECU extract file

Fig. 9: Imported ECU composition

After the import, you can work with the ECU composition in SystemDesk. Note the following points:
The original ECU extract might already contain references to the imported elements. For example,
there might be signal mapping from the data elements to the network signals. To ensure that these
references remain valid, they must not be modified at this stage. Specifically, the following items must
not be changed:
1) The names and the package assignments of the imported components
2) The names of the ports of the imported components
3) The names, the package assignments and all the properties of the imported interfaces, data
types, scalings, etc.

13 / 23
SystemDesk - EB tresos Studio - Workflow Descriptions Descriptions

It follows that you can edit only "empty" compositions in the imported software architecture, in other
words, ones that contain no components and no connectors. You can add components and connec-
tors to these compositions. The ports of the imported compositions must not be changed.

When you have finished creating the software architecture in SystemDesk, you can export it (step 3 in
Fig. 7). You can either export the composition type directly from the library or export the software ar-
chitecture from the system. You have to make some settings for this, as shown in Fig. 2. You must
use the same schema version as was used in the previously imported ECU extract.

Both AUTOSAR files are now imported in EB tresos Studio as shown in Fig. 7. Create two system
description importers in EB tresos Studio as described in section 4.2.1. One importer imports the soft-
ware architecture as shown in Fig. 13, the other imports the communication parts as shown in Fig. 14.

4 EB tresos Studio
The entire basic software, including the RTE, is configured in EB tresos Studio.

A project in EB tresos Studio always has a view of one single ECU. Thus, from the point of view of EB
tresos Studio, it basically makes no difference whether the software architecture was created for a
single ECU or for an ECU network.

However, there are some small differences with a few work steps. The following description contains
details of these. Apart from these few exceptions, the work steps are generic and can be grouped as
follows:
 Creating a project
 Importing data
 Configuring the basic software
 Configuring the RTE

4.1 Creating a Project

First you have to create a configuration project in EB tresos Studio. Activate System Model support as
shown in Fig. 10. This setting is also made automatically when the RTE module is added.

Fig. 10 EB tresos Studio - Creating a project – System Model

In the next step, it is recommended to clear the checkbox Automatically add the minimum number of
child elements in lists. The workflows presented here work with importers that automatically create all
the elements of the communication stack in the configuration lists, so this checkbox can be cleared as
shown in Fig. 11.

14 / 23
SystemDesk - EB tresos Studio - Workflow Descriptions

Fig. 11 EB tresos Studio - Creating a project – Minimum number of child elements in lists

You then have to add all the required basic software modules and the RTE. When you add the RTE,
an importer is created automatically. Its configuration is described in section 4.2.

4.2 Importing Data

The following data items are imported:
 Network description
 Software architecture

As shown in Table 1, in EB tresos Studio the software architecture is imported only with an AUTO-
SAR system description importer. This importer is also used if a pure software component description
is imported as described in section 3.2.1, i.e., a software architecture for a single ECU.

A network description, i.e., information on signals and frames, is contained in DBC, FIBEX and LDF
files. A network description can also be additionally contained in the AUTOSAR system description.

AUTOSAR System Description DBC/FIBEX/LDF

Importer Importer
Software Architecture (SWA) x -
Network description optional x
Table 1: Data in an AUTOSAR system description or DBC/FIBEX/LDF file

4.2.1 AUTOSAR System Description Importer

To import the software architecture in EB tresos Studio, you must add a system description importer to
the configuration project.

As shown in the workflows in Fig. 6 and Fig. 7, you can also add several system description importers
to a configuration project. The first step in configuring the importers (Fig. 12) is identical for both kinds
of importers. The rest of the configuration steps are different as shown in Table 2:

15 / 23
SystemDesk - EB tresos Studio - Workflow Descriptions Descriptions

System Model Import ECU Configuration Import

Importer for the Software Architecture enable disable
Importer for the communication parts enable enable
Table 2: EB tresos Studio – System Description Importers - Overview

Fig. 12: EB tresos Studio – System description importers – All models

One or more ARXML files can be specified as the input files as shown in Fig. 12. For example, the
software architecture can be read in from one ARXML file, and the standard AUTOSAR types from a
second ARXML file.
If you want to use different importer applications (SWA/network description), on the other hand, you
have to create two different importers as shown in Table 2 .

When you have selected the input files, the meta model version is automatically read out and set. The
system and the ECU instance must be selected only for an ECU network.

For the software architecture importer, activate Enable system model import as shown in Fig. 13.

16 / 23
SystemDesk - EB tresos Studio - Workflow Descriptions

Fig. 13 EB tresos Studio - System description importers – System model import

Overwrite existing model

If the input files are changed and you repeat the import procedure, you have to select this checkbox. If
different importers write to a system model, this checkbox must be cleared, and EB tresos Studio itself
brings the information together.

Software component import

When importing a software architecture for a single ECU, you must select Import software compo-
nents from top level composition, do not import mappings. When importing a software architecture for
an ECU network, select Import software components, data and service port mappings from system.

The network description can also be read in via the system description importer. To use this method,
you must add the ECU configuration import settings to the configuration of the system description
importer as shown in Fig. 14.

17 / 23
SystemDesk - EB tresos Studio - Workflow Descriptions Descriptions

Fig. 14 EB tresos Studio - Importing an ECU configuration by system description importer

Click Apply to save the importer settings. Then click Run Importer to perform the actual import.

During the import, EB tresos Studio checks whether the system description is AUTOSAR-compliant. If
the software architecture is incompletely modeled, for example, the EB tresos Studio importer outputs
an error message stating the line number in the system description. The line number lets you identify
the AUTOSAR path that contains the error.

This could be a path like the following: /ApplDatatypes/dt_wls. To find this element in the Sys-
temDesk project, select the element in SystemDesk's Package Manager as shown in Fig. 15. Then
select Locate Element in Project Manager from the context menu to select the element in the project
hierarchy.

18 / 23
SystemDesk - EB tresos Studio - Workflow Descriptions

Fig. 15: Identifying an AUTOSAR element in the SystemDesk Package Manager

4.2.2 Importing a Network Description

EB tresos Studio lets you import DBC, FIBEX and LDF files. The modules are automatically confi-
gured according to Table 3:

DBC FIBEX LDF

Can x
CanIf x
CanNm x
CanTp x
Fr x
FrIf x
Lin x
LinIf x
Com x x x
EcuC x x x
IpduM x x x
PduR x x x
Table 3: List of modules described by importing an ECU configuration

Each time you import a network description, you must select Enable system model import as shown in
Fig. 16 so that the system signals are created. This is always necessary because each signal in the
COM module configuration has a reference to a system signal.

19 / 23
SystemDesk - EB tresos Studio - Workflow Descriptions Descriptions

Fig. 16: EB tresos Studio - DBC import

You should usually clear the Overwrite existing model checkbox, because a network description im-
porter works in addition to a system description importer, and the system information in the system
description importer would otherwise be overwritten.

Even if the system signals have been imported via the Enable system model import option, for a single
ECU, data mapping is not performed via system signals, but via the ECU configuration as shown in
step 1c in Fig. 17.

If timeouts are defined in the software architecture, the RTE editor writes them to the COM configura-
tion. The RTE editor also creates the configuration of the callbacks in the COM module.

In the workflow for an ECU network, the AUTOSAR package name in Fig. 16 must match the network
communication element described in section 3.3.2. This connects the COM signals to the data ele-
ments of the SWCs via the system signals.

It is optionally also possible to create mappings via name matches in the RTE editor. If the names of
the data elements in the system description match the names of the signals in the network description,
the RTE can perform auto-mapping and connect the data elements of the SWCs to the signals from
the basic software without your having to perform any further configuration.

4.3 Configuring the Basic Software

The integrator and the application designer should work together on configuring the OS. All the neces-
sary tasks are created in the OS module configuration together with their priorities and scheduling
behavior.

The communication modules are configured by importers as described in section 4.2.

The configuration of the RTE is described in section 4.4.

For information on configuring the rest of the basic software modules, see the EB tresos AutoCore
documentation.

20 / 23
SystemDesk - EB tresos Studio - Workflow Descriptions

4.4 Configuring the RTE

TopLevelComposition
SW-C / system
description
SWC-1 SWC-2 SWC-3
Runnable 1

Runnable 2

1a
configuration

1c 2 3c
Data Runnable Entity Service Port
RTE

Mapping Mapping Mapping

1b

Ecu SW Composition
service
service
configuration

Com module configuration Os module configuration component

component
ECU

(e.g.
(e.g. Dem)
Dem)
3a
generate
generate
SW-CD
SW-CD

export
Ecu SW3b
Composition
Dem module configuration

Fig. 17: SWC / system description, ECU configuration and the connecting RTE

RTE configuration is subdivided into the following steps as shown in Fig. 17:
 Data mapping (Fig. 17, item 1)
 Runnable entity mapping (Fig. 17, item 2)
 Service port mapping (Fig. 17, item 3)

4.4.1 Data Mapping

Data mapping is performed in different ways in different workflows.

With a single ECU, no system signals were imported, so data is mapped directly to the COM signals
(Fig. 17, 1c).
This is done by setting Signal source to ECU Configuration (Fig. 18). In this configuration, the RTE
displays all the relevant signals that are configured in the COM module.

In the workflow for an ECU network, the data mapping is imported and does not have to be configured
in EB tresos Studio. You can visualize an imported mapping by setting Signal source to System De-
scription.

21 / 23
SystemDesk - EB tresos Studio - Workflow Descriptions Descriptions

Fig. 18: EB tresos Studio – Rte Editor – Signal source

4.4.2 Runnable Entity Mapping

Runnable entity mapping means mapping all the runnables to the tasks configured in the OS.

4.4.3 Service Port Mapping

Service port mapping is done in two steps:
 Generate the SWC description of the service modules (Fig. 17, item 3a)
 Connect the service ports to the application ports in EB tresos Studio (Fig. 17, item 3c)

The basic workflow for generating service components is shown in steps 3a, 3b, and 3c in Fig. 17.

First you have to configure the service modules (ComM, Dcm, Dem, Det, EcuM, NvM, Os, WdgM) in
EB tresos Studio.

Then generate the SWC descriptions (step 3a in Fig. 17). One way to do this is by clicking the genera-
tion button in the Rte Editor (item 1 in Fig. 19). The ECU software composition containing all the SWC
descriptions of the basic software can be exported if desired (step 3b in Fig. 17) by clicking the button
(item 2 in Fig. 19). The interfaces, data types, etc., in a SystemDesk project can be imported from this
file so that they can be used at the ports of the application components (see section 3.4).

Fig. 19 EB tresos Studio - Service components in EB tresos Studio

The service ports can be mapped directly in the Rte Editor in EB tresos Studio.

22 / 23
SystemDesk - EB tresos Studio - Workflow Descriptions

5 Using the EB tresos SW-C Editor Instead of dSPACE Sys-

temDesk
The workflows described here are also applicable if the EB tresos SW-C Editor is used instead of
dSPACE SystemDesk. You have to use the procedure described in section 3.2 for this.

6 Restrictions
For detailed information on known problems or function limitations in dSPACE SystemDesk, refer to
the release notes issued for SystemDesk.

For detailed information on known problems or function limitations in EB tresos Studio, refer to the
release notes issued for EB tresos Studio.

23 / 23