ConfigurationDesk

Bus Manager Implementation

Guide
For ConfigurationDesk 2024-A (24.1)

Release 2024-A – May 2024

How to Contact dSPACE
Mail: dSPACE GmbH
Rathenaustraße 26
33102 Paderborn
Germany
Tel.: +49 5251 1638-0
E-mail: [email protected]
Web: https://www.dspace.com

How to Contact dSPACE Support

If you encounter a problem when using dSPACE products, contact your local dSPACE
representative:
§ Local dSPACE companies and distributors: https://www.dspace.com/go/locations
§ For countries not listed, contact dSPACE GmbH in Paderborn, Germany.
Tel.: +49 5251 1638-941 or e-mail: [email protected]

You can also use the support request form: https://www.dspace.com/go/supportrequest. If

you are logged on to mydSPACE, you are automatically identified and do not have to add
your contact details manually.

If possible, always provide the serial number of the hardware, the relevant dSPACE License
ID, or the serial number of the CmContainer in your support request.

Software Updates and Patches

dSPACE strongly recommends that you download and install the most recent patches
for your current dSPACE installation. Visit https://www.dspace.com/go/patches for the
software updates and patches themselves and for more information, such as how to
receive an automatic notification when an update or a patch is available for your dSPACE
software.

Important Notice
This publication contains proprietary information that is protected by copyright. All rights
are reserved. The publication may be printed for personal or internal use provided all the
proprietary markings are retained on all printed copies. In all other cases, the publication
must not be copied, photocopied, reproduced, translated, or reduced to any electronic
medium or machine-readable form, in whole or in part, without the prior written consent
of dSPACE GmbH.

© 2015 - 2024 by:

dSPACE GmbH
Rathenaustraße 26
33102 Paderborn
Germany

This publication and the contents hereof are subject to change without notice.

AURELION, AUTERA, ConfigurationDesk, ControlDesk, MicroAutoBox, MicroLabBox,

SCALEXIO, SIMPHERA, SYNECT, SystemDesk, TargetLink, and VEOS are registered
trademarks of dSPACE GmbH in the United States or other countries, or both. Other
brand names or product names are trademarks or registered trademarks of their respective
companies or organizations.
 Contents

Contents

About This Guide 11

Safety Precautions 15
General Warning .......................................................................................... 15

Introduction to the Bus Manager 17

Overview of the Bus Manager....................................................................... 17
Introduction to Bus Communication Defined in Communication
Matrices........................................................................................................ 23
Elements of the Bus Manager........................................................................ 25

Use Scenarios for Configuring Bus Communication with

the Bus Manager 29
Overview of the Use Scenarios for Configuring Bus Communication
with the Bus Manager................................................................................... 29
Use Scenarios for Simulating Bus Communication......................................... 31
Use Scenarios for Inspecting Bus Communication.......................................... 33
Use Scenarios for Manipulating Bus Communication..................................... 34
Use Scenarios for Gatewaying Bus Communication....................................... 36
Criteria for Simulating, Inspecting, or Manipulating Bus
Communication............................................................................................ 38
Special Use Scenario: Providing Received and Manipulated Data to a
Behavior Model............................................................................................. 40

Typical Workflows for Using the Bus Manager and

Building Real-Time Applications 43
Workflow for Using the Bus Manager and Configuring Bus
Communication for Real-Time Applications................................................... 43
Configuring Bus Communication for Real-Time Applications with a
Behavior Model............................................................................................. 45
Configuring Bus Communication for Real-Time Applications Without
a Behavior Model.......................................................................................... 48

3
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Contents

Typical Workflows for Using the Bus Manager and

Generating Bus Simulation Containers 51
Workflow for Configuring Bus Communication and Generating Bus
Simulation Containers................................................................................... 51
Generating Bus Simulation Containers with a Behavior Model....................... 53
Generating Bus Simulation Containers Without a Behavior Model................. 54

Aspects of Supported Bus Communication 57

Aspects of Supported PDUs and Signals.................................................................. 58
Supported PDU Types and Signal Data Types.................................................. 58
Signal Conversion by the Bus Manager.......................................................... 60

Aspects of Supported AUTOSAR Features............................................................... 63

Aspects of Multiplexed IPDUs........................................................................ 63
Aspects of Container IPDUs and Contained IPDUs......................................... 64
Aspects of Secure Onboard Communication (SecOC)........................ ............ 67
Aspects of End‑to‑End (E2E) Protection for ISignal Groups............................. 69
Aspects of Event‑Controlled Timings................................................. ............ 70
Aspects of Global Time Synchronization (GTS)............................................... 71
Aspects of Partial Networking........................................................... ............ 74
Aspects of PDU Gateways............................................................................. 76

Aspects of Supported CAN Bus Features................................................................. 77

Aspects of Miscellaneous Supported CAN Bus Features................................. 77
Aspects of the J1939 Protocol....................................................................... 80

Aspects of Supported LIN Bus Features................................................................... 88

Aspects of Miscellaneous Supported LIN Bus Features.................................... 88

Basics on the Bus Manager 91

Working with Communication Matrices........................................................ 92
Basics on Bus Configurations....................................................................... 100
Bus Configuration Tables............................................................................. 103
Bus Configuration Function Block................................................................ 109
Assigning Communication Matrix Elements to Bus Configurations............... 112
Removing Communication Matrix Elements from Bus Configurations.......... 120
Creating Restbus Configurations................................................................. 121
Specifying the Behavior for Assigning Communication Matrix
Elements and Adding Bus Configuration Features (Preview Version)............. 125
Copying, Cutting, and Pasting Bus Configuration Elements......................... 131
Using Event‑Controlled Timings for Transmitting PDUs................................. 136
Triggering the Transmission of Multiplexed IPDUs.............................. .......... 137

4
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Contents

Working with User Code............................................................................. 139

Implementing Secure Onboard Communication in Executable
Applications................................................................................................ 143
Implementing Partial Networking in Executable Applications....................... 146
Simulating PDU Gateways (Preview Version)................................................ 148
Accessing Bus Manager Features via the ConfigurationDesk
Automation Interface.................................................................................. 152

Handling Bus Access Requests 155

Basics on Bus Access Requests..................................................................... 155
Specifying the Hardware Access.................................................................. 157

Handling Bus Manager-Related Conflicts 163

Basics on Bus Manager-Related Conflicts..................................................... 163
Resolving Bus Manager-Related Conflicts..................................................... 167

Specifying CAN Frame Captures and Gateways 171

Capturing CAN Frames..................................................................... .......... 171
Specifying CAN Frame Gateways................................................................. 173
Specifying Filters for Frame Captures and Frame Gateways.......................... 177

Implementing Global Time Synchronization in

Executable Applications 181
Basics on Implementing Global Time Synchronization in Executable
Applications................................................................................................ 181
Simulating Time Masters and Time Slaves of Global Time Domains.............. 182
Transmitting Bus Communication of Bus Configurations
Synchronously to a Global Time........................................................ .......... 185
Transmitting Individual PDUs Synchronously to a Global Time...................... 188

Working with Bus Configuration Features 191

Basics on Working with Bus Configuration Features................................... .......... 192
Basics on Bus Configuration Features.......................................................... 192
Overview of Bus Configuration Features...................................................... 195
Configuring Function Ports for Bus Configuration Features.......................... 198
Accessing Function Ports with Enabled Test Automation Support in
Variable Description Files (TRC Files)............................................................. 202
Using TRC File Variables for XIL Mapping..................................................... 207
Triggering the Transmission of PDUs and Frames via User-Defined
Triggers....................................................................................................... 210

5
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Contents

Manipulating Bus Communication via Bus Configuration Features........................ 213

Basics on Bus Manipulation Features........................................................... 213
Recalculating End-to-End Protection and Authentication Information .......... 217
Execution Sequence of Bus Manipulation Features....................................... 220

Bus Configuration Features Available for ISignals.................................................. 221

Working with ISignal Values........................................................................ 221
Working with Counter Signals..................................................................... 223
Overwriting ISignal Values........................................................................... 228
Adding Offset Values to ISignal Values......................................................... 231

Bus Configuration Features Available for ISignal Groups....................................... 235

Observing the Status of Received End‑to‑End‑Protected ISignal
Groups........................................................................................................ 235

Bus Configuration Features Available for PDUs..................................................... 238

Enabling and Disabling the Transmission of PDUs.............................. .......... 238
Accessing the Payload of PDUs in Raw Data Format..................................... 240
Controlling the Cyclic Timing of CAN PDUs................................................. 243
Specifying User-Defined Triggers for Transmitting PDUs..................... .......... 246
Accessing the Payload Length of CAN PDUs................................................ 249
Observing the Status of Received PDUs........................................................ 251
Applying User Code to PDUs....................................................................... 254
Accessing the Priority of J1939-Compliant IPDUs......................................... 263
Accessing the Selector Field Value of Multiplexed IPDUs.............................. 266
Verifying the Authentication Information of Received Secured IPDUs........... 268
Invalidating the Authenticator of Secured IPDUs.......................................... 271
Overwriting the Freshness Value of Secured IPDUs....................................... 274
Suspending the Transmission of PDUs.......................................................... 278
Triggering the Execution of Functions in a Behavior Model via RX
Interrupts.................................................................................................... 281

Bus Configuration Features Available for Frames................................................... 288

Accessing CAN Frame Settings.................................................................... 288
Manipulating the Payload Length of CAN Frames........................................ 295
Suspending the Transmission of Frames....................................................... 298

Bus Configuration Features Available for Communication Controllers................... 302

Enabling and Disabling Communication Controllers..................................... 302
Sending Wake-Up Signals on a LIN Bus............................................. .......... 305
Working with LIN Schedule Tables............................................................... 307
Enabling and Disabling J1939 Network Management.................................. 310

Bus Configuration Features Available for Global Time Domains.................. .......... 313
Controlling the Timing of Time Synchronization.......................................... 313
Accessing the Time Base Data of Time Masters and Time Slaves.................. 315
Accessing Validity Checks for Time Synchronization Messages..................... 317

6
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Contents

Bus Configuration Features Available for Partial Network Clusters......................... 321

Including Partial Network Clusters in Executable Applications and
Enabling and Disabling the Clusters............................................................. 321

Bus Configuration Features Available for Frame Captures and Frame

Gateways............................................................................................................. 323
Accessing the Data of Captured Frames............................................ .......... 323
Specifying the Direction of CAN Frame Gateways........................................ 327
Controlling Filters of Frame Captures and Frame Gateways............... .......... 328

Bus Configuration Features Available for Bus Configurations................................ 331

Enabling and Disabling Bus Configurations.................................................. 331

Implementing Bus Communication in the Signal Chain

Using the Bus Manager 335
How to Add Communication Matrices to a ConfigurationDesk
Application....................................................................................... .......... 335
How to Add a Bus Configuration to a ConfigurationDesk
Application....................................................................................... .......... 338
How to Assign Communication Matrix Elements to a Bus
Configuration................................................................................... .......... 340
How to Specify the Hardware Access........................................................... 344
How to Enable Model Access for Function Ports.......................................... 351
How to Add Behavior Models to a ConfigurationDesk Application............... 352
Example of Selecting Multiple Similar Communication Matrix
Elements at Once........................................................................................ 355
Example of Mapping Model Ports to Bus Configuration Ports via
Tables.......................................................................................................... 358
Configuring CAN Bus Properties in CAN Function Blocks............................. 361
Configuring LIN Bus Properties in LIN Function Blocks.................................. 362

Tasks, Events, and Runnable Functions Provided by the

Bus Manager 363
Basics on Tasks, Events, and Runnable Functions Provided by the Bus
Manager..................................................................................................... 363
Fetch and Deliver Runnable Functions for Receiving and Transmitting
PDUs........................................................................................................... 366
Changing the Assignment of Fetch and Deliver Runnable Functions............ 368

Generating Bus Simulation Containers 373

Basics on Bus Simulation Containers (BSC Files)........................................... 373
Port Interface of Bus Simulation Containers................................................. 377

7
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Contents

How to Generate Bus Simulation Containers............................................... 379

How to Assign Behavior Models to Separate Application Processes.............. 381

Working Without Behavior Models 385

Basics on Working Without Behavior Models............................................... 385
How to Create Application Processes that Provide Default Tasks.................. 386
How to Manually Assign Bus Configurations to Application
Processes..................................................................................................... 387

Modifying Communication Matrices 391

Basics on Modifying Communication Matrices............................................. 391
Adding ISignal IPDUs to CAN Channels....................................................... 396
Adding ISignals to CAN PDUs...................................................................... 397
Adding Cyclic Timing Elements to IPDUs...................................................... 399
Adding Event‑Controlled Timing Elements to IPDUs..................................... 401
Specifying User-Defined PDU Gateways (Preview Version)............................ 404
Configurable Settings of Communication Clusters....................................... 408
Configurable Settings of Frames.................................................................. 409
Configurable Settings of PDUs.......................................................... .......... 414
Configurable Settings of ISignal Groups............................................ .......... 425
Configurable Settings of ISignals................................................................. 427

Replacing Assigned Communication Matrices 435

Basics on Replacing Assigned Communication Matrices............................... 435
How to Replace Assigned Communication Matrices.................................... 438

Working with the Bus Manager Demos 441

Introduction to the Bus Manager Demos.............................................................. 442
Overview of the Bus Manager Demos.......................................................... 442
How to Run a Selected Bus Manager Demo Python Script via
ConfigurationDesk...................................................................................... 443
Running a Selected Bus Manager Demo Python Script via an External
Interpreter................................................................................................... 445

Working with the Bus Manager Basics Demo........................................................ 448

Introduction to the Bus Manager Basics Demo............................................. 448
Overview of the Example Used in the Bus Manager Basics Demo................. 449
Steps of the Bus Manager Basics Demo Python Script.................................. 452
How to Replace the SIC Files in the Bus Manager Basics Demo.................... 462
Example of Experimenting with the Bus Manager Basics Demo in
ControlDesk................................................................................................ 463

8
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Contents

Working with the Bus Manager SecOC Demo............................................ .......... 471

Introduction to the Bus Manager SecOC Demo................................. .......... 471
Overview of the Example Used in the Bus Manager SecOC Demo................ 473
Steps of the Bus Manager SecOC Demo Python Script................................. 475
Definitions in the UserCode_SecOCDemo.c File........................................... 481
Example of Experimenting with the Bus Manager SecOC Demo in
ControlDesk................................................................................................ 488

Information for Former Users of the RTI CAN

MultiMessage Blockset and RTI LIN MultiMessage
Blockset 497
Starting Points for Former Users of the RTI CAN MultiMessage and RTI LIN
MultiMessage Blocksets........................................................................................ 498
Recommended Starting Points for Former Users of the RTI CAN
MultiMessage and RTI LIN MultiMessage Blocksets...................................... 498

Mapping Features of the RTI CAN MultiMessage Blockset.......................... .......... 500

Mapping Features of the RTI CAN MultiMessage Blockset to
Features of the Bus Manager....................................................................... 500
Using Features of the RTI CAN MultiMessage Blockset Independently
from the Bus Manager................................................................................ 508
Unsupported Features of the RTI CAN MultiMessage Blockset..................... 509

Mapping Features of the RTI LIN MultiMessage Blockset....................................... 511

Mapping Features of the RTI LIN MultiMessage Blockset to Features
of the Bus Manager.......................................................................... .......... 511
Unsupported Features of the RTI LIN MultiMessage Blockset........................ 516

Limitations for Using the Bus Manager 519

Limitations for Communication Matrices and Communication
Standards.................................................................................................... 519
Limitations for CAN Communication........................................................... 525
Limitations for LIN Communication.............................................................. 528
Limitations for Bus Configuration Handling................................................. 531
Limitations for Bus Simulation Containers.................................................... 533

Appendix 537
Mapping of Bus Manager PDU Types to Communication Standard
PDU Types................................................................................................... 537

9
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Contents

Optimized Set of TRC File Variables for Bus Configuration Function

Ports........................................................................................................... 540
Resolving the Bus Configuration Conflict: No Valid Application
Process Assigned......................................................................................... 543

ConfigurationDesk Glossary 547

Index 571

10
ConfigurationDesk Bus Manager Implementation Guide May 2024
 About This Guide

About This Guide

Content Introduces you to the Bus Manager in ConfigurationDesk. This guide

shows you how to configure bus communication with the Bus Manager in
ConfigurationDesk. This includes:
§ Implementing bus communication in ConfigurationDesk by using
communication matrices and bus configurations.
§ Specifying the model interface to exchange bus signals with a behavior model.
§ Building real-time applications and generating bus simulation containers.

Note

Two variants of the Bus Manager are available, the Bus Manager in
ConfigurationDesk and the Bus Manager (stand-alone). For information on
working with the Bus Manager (stand-alone), refer to Bus Manager (Stand-
Alone) Implementation Guide .

Target group This guide is primarily intended for engineers who configure bus communication
for simulation, inspection, and/or manipulation purposes. The target group
performs some or all of the following tasks:
§ Set up bus communication based on communication matrices.
§ Specify a model interface to exchange bus signals between ConfigurationDesk
and a behavior model modeled in a modeling tool such as
MATLAB®/Simulink®.
§ Build real-time applications or generate bus simulation containers that include
the configured bus communication.

Required knowledge Basic knowledge in the following areas is assumed:

§ Basics of ConfigurationDesk
§ Basics of SCALEXIO/MicroAutoBox III/MicroLabBox II hardware (in case of
configuring bus communication for real-time applications)
§ Used bus protocols

11
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 About This Guide

Symbols dSPACE user documentation uses the following symbols:

Symbol Description
Indicates a hazardous situation that, if not avoided,
V DANGER
will result in death or serious injury.
Indicates a hazardous situation that, if not avoided,
V WARNING could result in death or serious injury.
Indicates a hazardous situation that, if not avoided,
V CAUTION could result in minor or moderate injury.
Indicates a hazard that, if not avoided, could result in
NOTICE
property damage.
Indicates important information that you should take
Note
into account to avoid malfunctions.
Indicates tips that can make your work easier.
Tip
Indicates a link that refers to a definition in the
glossary, which you can find at the end of the
document unless stated otherwise.
Follows the document title in a link that refers to
another document.

Naming conventions dSPACE user documentation uses the following naming conventions:

%name% Names enclosed in percent signs refer to environment variables for

file and path names.

<> Angle brackets contain wildcard characters or placeholders for variable

file and path names, etc.

Special Windows folders Windows‑based software products use the following special folders:

Common Program Data folder A standard folder for application-specific

program data that is used by all users.
%PROGRAMDATA%\dSPACE\<InstallationGUID>\<ProductName>
or
%PROGRAMDATA%\dSPACE\<ProductName>\<VersionNumber>

Documents folder A standard folder for application‑specific files that are

used by the current user.
%USERPROFILE%\Documents\dSPACE\<ProductName>\<VersionNumber>

Local Program Data folder A standard folder for application-specific

program data that is used by the current user.
%USERPROFILE%\AppData\Local\dSPACE\<InstallationGUID>\
<ProductName>

12
ConfigurationDesk Bus Manager Implementation Guide May 2024
 About This Guide

Accessing dSPACE Help and After you install and decrypt Windows‑based dSPACE software, the
PDF files documentation for the installed products is available in dSPACE Help and as PDF
files.

dSPACE Help (local) You can open your local installation of dSPACE Help:
§ On its home page via Windows Start Menu
§ On specific content using context-sensitive help via F1

PDF files You can access PDF files via the icon in dSPACE Help. The PDF
opens on the first page.

dSPACE Help (Web) Independently of the software installation, you can

access the Web version of dSPACE Help at https://www.dspace.com/go/help.
To access the Web version, you must have a mydSPACE account.
For more information on the mydSPACE registration process, refer to
https://www.dspace.com/faq?097.

13
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 About This Guide

14
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Safety Precautions

Safety Precautions

General Warning

Danger potential Using dSPACE software can be dangerous. You must observe the following
safety instructions and the relevant instructions in the user documentation.

V WARNING

Risk of serious personal injury and/or property damage

Using the ConfigurationDesk software can have a direct effect on dSPACE
systems and technical (electrical, hydraulic, mechanical) systems connected
to them.
Improper or negligent use can result in serious personal injury and/or
property damage. The risk of property damage or personal injury also
exists when the behavioral properties of a dSPACE system are changed via
ConfigurationDesk before the dSPACE system is used in conjunction with a
technical system.
§ Only persons who are qualified to use dSPACE software, and
who have been informed of the above dangers and possible
consequences, are permitted to use it.
§ All applications where malfunctions or misoperation involve the danger of
injury or death must be examined for potential hazards by the user, who
must if necessary take additional measures for protection (for example,
emergency functions such as limp home, or an emergency off switch).

Liability It is your responsibility to adhere to instructions and warnings. Any unskilled

operation or other improper use of this product in violation of the respective
safety instructions, warnings, or other instructions contained in the user
documentation constitutes contributory negligence, which may lead to a
limitation of liability by dSPACE GmbH, its representatives, agents and regional
dSPACE companies, to the point of total exclusion, as the case may be. Any
exclusion or limitation of liability according to other applicable regulations,
individual agreements, and applicable general terms and conditions remain
unaffected.

15
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Safety Precautions

Data loss during operating The shutdown procedure of Microsoft Windows operating systems causes some
system shutdown required processes to be aborted although they are still being used by dSPACE
software. To avoid data loss, the dSPACE software must be terminated manually
before a PC shutdown is performed.

16
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Introduction to the Bus Manager

Introduction to the Bus Manager

Where to go from here Information in this section

Overview of the Bus Manager.................................................................. 17

Introduction to Bus Communication Defined in Communication

Matrices.................................................................................................. 23

Elements of the Bus Manager.................................................................. 25

Overview of the Bus Manager

Purpose of the Bus Manager The Bus Manager lets you configure bus communication for simulation,
inspection, and manipulation purposes. You can work with multiple
communication matrix files in various file formats and configure the
communication of multiple communication clusters at the same time.

17
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Introduction to the Bus Manager

Variants of the Bus Manager Two variants of the Bus Manager are available. The following illustration provides
an overview of the variants and their fields of application.
Bus Manager in SCALEXIO, MicroAutoBox III,
ConfigurationDesk MicroLabBox II
Real-time
application
Re
ap al-ti
pli me
ca
tio
n
Communication ControlDesk

Bu
ss
matrices

im
ula
NS_ :
Behavior

t
Projects
model

ion
NS_DESC_
CM_

</> BA_DEF_
BA_

c
VAL_

on
CAT_DEF_
CAT_

tai
ne
r
e
Bus Manager flin n
(stand-alone) Of latio n
VEOS u tio
sim lica
pp
Bus simulation a
container

Bus Manager in ConfigurationDesk The Bus Manager in

ConfigurationDesk lets you configure bus communication and implement it
directly in a real-time application for dSPACE SCALEXIO, MicroAutoBox III,
or MicroLabBox II systems. Alternatively, it lets you generate bus simulation
containers . Bus simulation containers can be used on various dSPACE
simulation platforms. For example, you can use bus simulation containers in
VEOS to implement the configured bus communication in an offline simulation
application .

Bus Manager (stand-alone) The Bus Manager (stand-alone) lets you

configure bus communication and generate bus simulation containers. To use
the configured bus communication on a specific dSPACE simulation platform,
you can import the bus simulation containers to VEOS or ConfigurationDesk,
for example. VEOS lets you implement the bus communication in an
offline simulation application, ConfigurationDesk lets you implement the bus
communication in a real-time application. You can also reuse projects you used
with the Bus Manager (stand-alone) with the Bus Manager in ConfigurationDesk
(e.g., to work with an already configured bus communication and implement it
in a real-time application).

18
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Overview of the Bus Manager

Video introducing the

Bus Manager in Introduction to the Bus Manager in ConfigurationDesk
ConfigurationDesk
This video shows you how you can configure CAN and LIN communication
by using the Bus Manager in ConfigurationDesk and implement the bus
communication in a real-time application.

To watch this video, click the following link or scan the QR code:
https://www.dspace.com/dspace-help/kqEcy

New features of the Bus The Bus Manager is continuously enhanced.

Manager § For an overview of the new features of the current Bus Manager version, refer
to New Features of ConfigurationDesk 2023-B (23.2) (ConfigurationDesk New
Features And Migration ).
§ For a complete history of features and migration steps, refer to
History of ConfigurationDesk Features (ConfigurationDesk New Features
And Migration ) and History of Version-Specific Migration Steps
(ConfigurationDesk New Features And Migration ), respectively.

Providing preview versions of Some features of the Bus Manager are provided as a preview version, i.e., the
Bus Manager features features are in an early but completely tested development stage. You can
unambiguously identify the respective features by the (preview version) suffix,
which is used for the feature descriptions in this document.

We provide these preview versions so you can use new features of the Bus
Manager as early as possible. Moreover, we would like to collect feedback that
we can consider in the further feature development. Do you have any feedback?
Contact dSPACE Support (www.dspace.com/go/supportrequest).

Note

Due to the further feature development, there might be incompatible

changes between the preview versions and the first stable release version
of a feature.

Bus Manager license The Bus Manager is license-protected. Refer to Required Licenses
(ConfigurationDesk Getting Started ).

ConfigurationDesk and the When you work with the Bus Manager, you can use all the elements of
Bus Manager ConfigurationDesk and all the ConfigurationDesk concepts apply to your work.

19
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Introduction to the Bus Manager

To work efficiently with ConfigurationDesk, you should be familiar with its

basic concepts. For a detailed description of the basic concepts, refer to Basic
Concepts of ConfigurationDesk (ConfigurationDesk Getting Started ). For a
brief description of frequently used terms, refer to ConfigurationDesk Glossary
on page 547.

Consistent user interface The Bus Manager provides a consistent user interface for different bus systems
and use cases, letting you configure the bus communication according to your
requirements. For example, you can configure the bus communication for various
bus systems simultaneously without switching between different tools or views.

Supported bus systems The Bus Manager supports the following bus systems:
§ CAN
§ LIN

For details on supported bus system features, refer to Aspects of Supported Bus
Communication on page 57.

Implementing bus The main elements for implementing bus communication in a ConfigurationDesk
communication in application are:
a ConfigurationDesk § Communication matrices
application § Bus configurations

Communication matrices contain the definitions for bus communication. They

serve as a library from which you can select elements to work with. The Bus
Manager lets you import communication matrices and create bus configurations.
When you assign communication matrix elements to a bus configuration, you
implement bus communication in the signal chain. You can configure this bus
communication for simulation, inspection, and manipulation purposes before
you build a real-time application or generate bus simulation containers.

For more information, refer to:

§ Introduction to Bus Communication Defined in Communication Matrices on
page 23
§ Overview of the Use Scenarios for Configuring Bus Communication with the
Bus Manager on page 29
§ Working with Communication Matrices on page 92
§ Basics on Bus Configurations on page 100

Tip

If you do not have a communication matrix, you can modify the

Basic_ComMatrix.arxml file and use it as a starting point to set up
CAN communication. For more information, refer to Basics on Modifying
Communication Matrices on page 391.

20
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Overview of the Bus Manager

Supported communication The Bus Manager supports the following communication matrix file formats:
matrix file formats § AUTOSAR system description files (ARXML files)
§ FIBEX files (XML files)
§ DBC files
§ LDF files

For details on the supported communication matrix file formats and versions,
refer to Working with Communication Matrices on page 92.

Working with behavior Behavior models can define the behavior of ECUs, for example.
models
When you configure bus communication with the Bus Manager, you can work
with or without behavior models .
§ If you work with behavior models and implement bus communication in a
real-time application, you can configure the bus communication independently
from a specific modeling tool, i.e., the behavior models can be modeled with
MATLAB®/Simulink® or other modeling tools.
§ If you work with behavior models and generate bus simulation containers, the
behavior models must be Simulink® implementation containers (SIC files).
To work with Simulink implementation containers, no local MATLAB/Simulink
installation is needed.

However, if you want to use the full functionality of the Bus Manager
when working with behavior models, MATLAB/Simulink must be installed and
connected to your dSPACE installation.

For overviews of typical workflows for building real-time applications or

generating bus simulation containers with and without behavior models, refer
to:
§ Typical Workflows for Using the Bus Manager and Building Real-Time
Applications on page 43
§ Typical Workflows for Using the Bus Manager and Generating Bus Simulation
Containers on page 51

Conflict handling The Bus Manager lets you configure the bus communication without strict
constraints. This lets you work more freely, but it can lead to conflicting
configuration settings, such as duplicate CAN identifiers for CAN frame
triggerings of one channel. Before building a real-time application or generating
bus simulation containers, you have to resolve at least the most severe conflicts.
You can view and resolve conflicts via the Conflicts Viewer.

For more information, refer to Basics on Bus Manager-Related Conflicts on

page 163.

21
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Introduction to the Bus Manager

Supported real-time hardware Real-time applications containing bus communication that is configured with the
Bus Manager are supported by SCALEXIO, MicroAutoBox III, and MicroLabBox II
systems with the following real-time hardware:
§ SCALEXIO real-time hardware:
§ DS2671 Bus Board
§ DS2672 Bus Module
§ DS6301 CAN/LIN Board
§ DS6341 CAN Board
§ DS6342 CAN Board
§ DS6344 CAN Board
§ DS6351 LIN Board
§ MicroAutoBox III real-time hardware:
§ DS1511/DS1511B1 Multi-I/O Board
§ DS1513 Multi-I/O Board
§ DS1521 Bus Board
§ DS4342 CAN FD Interface Module
§ MicroLabBox II real‑time hardware: DS1303 Multi‑I/O Board, supported
channel types:
§ CAN 9 channel type
§ LIN 5 channel type

Support of You can automate Bus Manager features via the ConfigurationDesk automation
the ConfigurationDesk interface. For more information, refer to Accessing Bus Manager Features via the
automation interface ConfigurationDesk Automation Interface on page 152.

Bus Manager tutorials Two tutorials are available for the Bus Manager:
§ Bus Manager Tutorial: Guides you through the basic steps when you start
working with the Bus Manager using the user interface. The tutorial introduces
you to typical workflows and provides detailed descriptions on the individual
workflow steps.
Refer to Bus Manager Tutorial .
§ Using Python for Automating the Bus Manager: Shows you how to automate
workflows that are provided by the Bus Manager Tutorial using Python.

Tip

It is recommended that you work through the Bus Manager Tutorial

before you start working with this tutorial.

Refer to Using Python for Automating the Bus Manager (ConfigurationDesk

Tutorials on Automating Tool Handling ).

Bus Manager demos Two demos are available for the Bus Manager:
§ Bus Manager Basics demo: Introduces you to the basic steps of accessing the
Bus Manager and configuring simple bus communication.

22
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Introduction to Bus Communication Defined in Communication Matrices

§ Bus Manager SecOC demo: Introduces you to implementing secure onboard

communication in an executable application by using the Bus Manager.

Both Bus Manager demos use automation to access the Bus Manager and
configure the bus communication. Refer to Working with the Bus Manager
Demos on page 441.

Introduction to Bus Communication Defined in Communication Matrices

Purpose of communication To work with the Bus Manager, you need at least one communication
matrices matrix. Communication matrices define the communication of a bus network.
A communication matrix can describe the bus communication of one
communication cluster or a bus network consisting of different bus systems and
communication clusters. The topology of the bus communication defined in a
communication matrix consists of various elements.

Example for bus The following illustration is an example of a communication matrix that defines a
communication defined in a simple bus communication network of a vehicle consisting of three bus systems
communication matrix (CAN, LIN, FlexRay) and five communication clusters.

Vehicle Dyn Vehicle Dyn

Body ECU 1 Body ECU 2 ECU 1 ECU 2

Channel A
Body CAN Channel B Vehicle Dyn FlexRay

ECU/network node
Powertrain Powertrain
Comfort ECU 1 Comfort ECU 2 ECU 1 ECU 2

Comfort CAN Powertrain FlexRay

Channel
Comfort LIN Communication
cluster

Comfort ECU 3 Central

Gateway ECU

23
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Introduction to the Bus Manager

Elements of a bus The following terms are used to describe the topology of the bus communication
communication topology defined in a communication matrix:
§ Channel
Describes the physical channel that is used for bus communication. Depending
on the bus protocol, one or more channels are used for bus communication:
for example, CAN and LIN use one channel, FlexRay uses up to two channels.
§ Communication cluster
Describes all the network nodes that are connected to the same physical
channel(s) and share the same bus protocol and address range.
§ ECU/network node
An ECU can be a member of multiple bus systems and communication
clusters. Depending on the focus of the bus communication that is performed
by an ECU, the following terms are used:
§ ECU addresses the entire bus communication of an ECU, i.e., the
communication for all the connected communication clusters.
§ Network node addresses the bus communication of an ECU for only one
communication cluster.

24
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Elements of the Bus Manager

Elements of the Bus Manager

User interface When you work with the Bus Manager, you use Bus Manager elements and
standard ConfigurationDesk elements. In the following illustration, the Bus
Manager elements are in bold letters.

View-set-specific Home
ribbon (here: specific for Working area
Buses view set) Buses Browser (Bus Manager-specific tables displayed)

Browsers for Navigation bar Tool windows

topologies (Buses view set selected) (Message Viewer displayed) Properties Browser

Bus Manager elements of the The following elements of the user interface are specific to the Bus Manager.
user interface
Buses view set Provides access to panes that are frequently used when you
configure bus communication with the Bus Manager. Additionally, the Home
ribbon provides access to frequently used commands when you configure bus
communication. Some of these commands are specific to the Bus Manager.

Buses Browser Lets you add new communication matrices to the active
ConfigurationDesk application and provides access to all the communication
matrices of the active application. You can select communication matrices
completely or partly to assign them to bus configurations.

25
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Introduction to the Bus Manager

Bus Manager-specific tables Provide access to all the bus configurations of

the active application. Via the different tables, you can configure the entire bus
communication of the signal chain .

Bus Configuration function block Provides a graphical view on function

ports of a bus configuration. When you configure bus communication in a
bus configuration, you can access the related Bus Configuration function block
in the Signal Chain Browser (available for the Signal Chain view set), for
example.

Bus Manager-specific elements in the Project Manager The Project

Manager (available in the Project view set) provides the following Bus Manager-
specific elements:
§ Communication Matrices node
Represents an application component. The node is unavailable until you add
the first communication matrix to the Buses Browser.
§ Generated Containers folder
Represents an application component. This folder is unavailable until you
generate bus simulation containers for the first time. Then, the folder displays
the generated bus simulation container (BSC) files.

26
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Elements of the Bus Manager

Tip

The Project Manager displays the project folder and its content, such
as application subfolders. You can include external documents, such as
communication matrices, in the project folder and/or its subfolders. External
documents are included in project and application backups. Refer to
Handling ConfigurationDesk Projects and Applications (ConfigurationDesk
Real-Time Implementation Guide ).

For a detailed description of ConfigurationDesk's user interface, refer to

Overview of the User Interface of ConfigurationDesk (ConfigurationDesk Getting
Started ).

27
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Introduction to the Bus Manager

28
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Use Scenarios for Configuring Bus Communication with the Bus Manager

Use Scenarios for Configuring Bus Communication

with the Bus Manager

Where to go from here Information in this section

Overview of the Use Scenarios for Configuring Bus

Communication with the Bus Manager.................................................... 29

Use Scenarios for Simulating Bus Communication.................................... 31

Use Scenarios for Inspecting Bus Communication.................................... 33

Use Scenarios for Manipulating Bus Communication............................... 34

Use Scenarios for Gatewaying Bus Communication................................. 36

Criteria for Simulating, Inspecting, or Manipulating Bus

Communication....................................................................................... 38

Special Use Scenario: Providing Received and Manipulated Data to

a Behavior Model.................................................................................... 40

Overview of the Use Scenarios for Configuring Bus Communication with the
Bus Manager

Introduction The Bus Manager lets you implement bus communication in a ConfigurationDesk
application. You can import communication matrices of different types and
configure the bus communication of various bus systems at the same time for
different use scenarios.

29
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Use Scenarios for Configuring Bus Communication with the Bus Manager

Overview of the use scenarios In general, you can configure the bus communication for the following use
scenarios:

Use Scenario Example Refer To …

Simulation To perform a restbus simulation. Use Scenarios for Simulating Bus Communication on
page 31
Inspection To observe the bus communication on a bus channel. Use Scenarios for Inspecting Bus Communication on
page 33
Manipulation To realize specified test cases by transmitting manipulated Use Scenarios for Manipulating Bus Communication
bus communication to the device under test. on page 34
Gateway To realize failure gateways between two CAN channels for Use Scenarios for Gatewaying Bus Communication on
hardware‑in‑the‑loop (HIL) tests. page 36

Configure bus communication The Bus Manager lets you independently configure the bus communication for
independently for the use simulation, inspection, manipulation, and/or gateway purposes. For example, if
scenarios you configure bus communication for simulation purposes or change the already
configured bus communication, this does not affect the bus communication that
is configured for inspection, manipulation, or gateway purposes.

To achieve this, dedicated bus configuration parts are available that let you
configure the bus communication. You can access the bus configuration parts in
the Bus Configurations table. Refer to Bus Configurations table on page 105.

Tip

In some cases, it might be difficult to decide whether simulating, inspecting,

or manipulating bus communication meets the requirements of your use
scenario, for example:
§ To access a PDU that is received on the bus, you can configure it for
simulation and/or inspection.
§ To access a PDU that is transmitted on the bus, you can configure it for
simulation and/or manipulation.
There are some criteria that can help you to select the suitable
configuration. Refer to Criteria for Simulating, Inspecting, or Manipulating
Bus Communication on page 38.

Implementing the configured Depending on your use scenario, you can implement the configured bus
bus communication in communication in a real-time application or in bus simulation containers:
real‑time applications or bus § Using a real-time application, you can load the bus communication to real-
simulation containers time hardware.
§ Using bus simulation containers, you can implement the bus communication in
an offline simulation application , for example.

You can access the bus communication of the real-time application and offline
simulation application via experiment software.

30
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Use Scenarios for Simulating Bus Communication

Accessing and manipulating Depending on your settings, you can access and manipulate the bus
bus communication via communication via experiment software such as ControlDesk during run time.
experiment software You can, for example:
§ Switch the signal sources between a static signal value specified in
ConfigurationDesk and dynamic signal values that are exchanged with the
behavior model.
§ Manipulate signal values to simulate value changes or faulty signals.

Related topics Basics

Introduction to Bus Communication Defined in Communication Matrices................................. 23

Use Scenarios for Simulating Bus Communication

Introduction The Bus Manager lets you simulate the bus communication between ECUs of the
same or different communication clusters or bus systems.

ECU or restbus simulation You can simulate individual ECUs or perform a restbus simulation.
§ ECU simulation
Simulating individual ECUs lets you, for example, test the behavior model of an
ECU before the real ECU is available.
§ Restbus simulation
Restbus simulation lets you test one or more ECUs while simulating the other
ECUs of the related communication clusters. ECUs under test can be one of
the following:
§ Real ECUs that are connected to a simulator.
§ V-ECU implementations that are implemented in SIL simulation .
For example, 'Comfort ECU 1' is available as a real ECU and connected to
a simulator. To test this ECU, you can simulate all the other members of the
'Comfort CAN' and 'Comfort LIN' clusters (restbus simulation). The following
illustration displays this example graphically:

31
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Use Scenarios for Configuring Bus Communication with the Bus Manager

Comfort ECU 1 Comfort ECU 2

Real ECU

Comfort CAN

Comfort LIN

Comfort ECU 3 Central

Gateway ECU

Simulated restbus

Tip

The Bus Manager can help you to configure a restbus simulation. Refer to
Creating Restbus Configurations on page 121.

Static and dynamic simulation Depending on the requirements of your simulation, you can perform a static
and/or dynamic simulation:

Simulation Description
Type
Static You can perform a static simulation to transmit or receive constant signal values on the bus. This is often sufficient
simulation in most use cases: For example, you perform a restbus simulation and the ECU under test expects a cabin
temperature within a specific temperature range from an ECU that is part of the simulated restbus. In this case,
you can let the simulated ECU transmit a constant temperature value that is within this temperature range.
You can use constant values that are defined in the communication matrix or specify user-defined constant values
in ConfigurationDesk. Static simulation lets you work without a behavior model that defines, for example, the
behavior of ECUs.
Dynamic When signals of a simulated ECU change dynamically during run time (e.g., cabin temperature values that
simulation are regulated by the ECU under test and exchanged with the simulated ECU), you have to perform a
dynamic simulation: You have to connect these signals to a behavior model that is, for example, modeled in
MATLAB®/Simulink®. The control algorithms of the behavior model calculate the dynamic signal values of the
simulated ECU during run time. If required, you can also switch between static and dynamic signal values during
run time.

Workflow To configure bus communication for simulation purposes, you have to assign
communication matrix elements to the Simulated ECUs part of one or more bus
configurations and add bus configuration features to the elements.

For an overview of the required workflow steps, refer to:

§ Typical Workflows for Using the Bus Manager and Building Real-Time
Applications on page 43

32
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Use Scenarios for Inspecting Bus Communication

§ Typical Workflows for Using the Bus Manager and Generating Bus Simulation
Containers on page 51

Tip

In some cases, it might be difficult to decide whether simulating, inspecting,

or manipulating bus communication meets the requirements of your use
scenario, for example:
§ To access a PDU that is received on the bus, you can configure it for
simulation and/or inspection.
§ To access a PDU that is transmitted on the bus, you can configure it for
simulation and/or manipulation.
There are some criteria that can help you to select the suitable
configuration. Refer to Criteria for Simulating, Inspecting, or Manipulating
Bus Communication on page 38.

Use Scenarios for Inspecting Bus Communication

Introduction The Bus Manager lets you inspect the bus communication of communication
clusters independently from the involved ECUs.

Inspecting bus communication The following illustration is an example of inspecting bus communication in
combination with a restbus simulation.

Comfort ECU 1 Comfort ECU 2

ECU under test

Inspection

Comfort CAN

Comfort LIN

Comfort ECU 3 Central

Gateway ECU

Restbus simulation

Inspecting bus communication is performed for each cluster and channel

separately. This allows you, for example:
§ To inspect the bus communication independently from the ECU development
stage.
For example, replacing a simulated ECU with a V‑ECU or real ECU has no
effect on your configurations for inspecting bus communication.

33
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Use Scenarios for Configuring Bus Communication with the Bus Manager

§ To reduce the effort for implementing bus communication in a

ConfigurationDesk application and to improve the run‑time performance.
For example, three ECUs receive the same PDU but you only want to know
that the PDU is available on the bus. In this case, the sender and receiver of
the PDU are of no interest and it is not necessary to process the PDU three
times at run time. For this, you need to configure the PDU only once for the
inspection and not separately for each receiving ECU.

Depending on your use scenario, you can use the inspected bus communication
in a mapped behavior model (e.g., to have a simulated ECU react on the
inspected bus communication).

Workflow To configure bus communication for inspection purposes, you have to assign
communication matrix elements to the Inspection part of one or more bus
configurations and add bus configuration features to the elements.

For an overview of the required workflow steps, refer to:

§ Typical Workflows for Using the Bus Manager and Building Real-Time
Applications on page 43
§ Typical Workflows for Using the Bus Manager and Generating Bus Simulation
Containers on page 51

Tip

In some cases, it might be difficult to decide whether inspecting or

simulating bus communication meets the requirements of your use scenario
for accessing data that is received on the bus.
There are some criteria that can help you to select the suitable
configuration. Refer to Criteria for Simulating, Inspecting, or Manipulating
Bus Communication on page 38.

Use Scenarios for Manipulating Bus Communication

Introduction The Bus Manager lets you manipulate the bus communication before it is
transmitted to the ECU under test (e.g., a real ECU that is connected to the
simulator). This lets you test the response of the ECU under test in case it
receives faulty bus communication, for example.

34
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Use Scenarios for Manipulating Bus Communication

Manipulating bus The following illustration is an example of manipulating bus communication in

communication combination with a restbus simulation.

Comfort ECU 1 Comfort ECU 2

ECU under test

Manipulation

Comfort CAN

Comfort LIN

Comfort ECU 3 Central

Gateway ECU

Restbus simulation

Manipulating bus communication is based on communication clusters, i.e., you

can manipulate the bus communication that is transmitted to the ECU under test
independently from the source that sends the bus communication.

The manipulation applies to frames and their included PDUs and ISignals
immediately before a frame is transmitted on the bus, regardless of the source
that sends the frame on the simulation platform. For example, the source can be
an ECU that is simulated by the Bus Manager, a frame gateway, or frames in a
data replay use scenario.

Depending on your use scenario, you can manipulate the bus communication
permanently or temporarily:
§ Permanent manipulation lets you test, for example, if and how the ECU under
test reacts on the faulty bus communication.
§ Temporarily manipulation lets you test, for example, the fault memory of the
ECU under test.

Note

In the Bus Manager context, manipulation applies only to bus

communication that is transmitted on the bus. You cannot use this
manipulation approach to provide manipulated data to a behavior model.
Providing manipulated data to a behavior model requires a special
configuration. Refer to Special Use Scenario: Providing Received and
Manipulated Data to a Behavior Model on page 40.

Workflow To configure bus communication for manipulation purposes, you have to assign
communication matrix elements to the Manipulation part of one or more bus
configurations and add bus configuration features to the elements.

35
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Use Scenarios for Configuring Bus Communication with the Bus Manager

For an overview of the required workflow steps, refer to:

§ Typical Workflows for Using the Bus Manager and Building Real-Time
Applications on page 43
§ Typical Workflows for Using the Bus Manager and Generating Bus Simulation
Containers on page 51

Tip

In some cases, it might be difficult to decide whether manipulating or

simulating bus communication meets the requirements of your use scenario
for accessing data that is transmitted on the bus.
There are some criteria that can help you to select the suitable
configuration. Refer to Criteria for Simulating, Inspecting, or Manipulating
Bus Communication on page 38.

Use Scenarios for Gatewaying Bus Communication

Introduction The Bus Manager lets you gateway bus communication, i.e., route bus
communication between different bus channels. This lets you exchange frames
between different communication clusters .

The Bus Manager offers two different approaches for gatewaying bus
communication:
§ You can gateway CAN frames that pass a specified filter between two
communication clusters.
§ You can simulate PDU gateways that are specified in communication matrices.
If a communication matrix does not specify a required PDU gateway, you can
modify the communication matrix to specify user‑defined PDU gateways.

CAN frame gateways Use scenario for CAN frame gateways A typical use scenario for a CAN
frame gateway is a failure gateway, i.e., the CAN frames are not only routed
from one channel to another but also manipulated. The following illustration is
an example for a failure gateway with real ECUs connected to the simulator.
Only the ECU under test receives the gatewayed and manipulated frame.

36
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Use Scenarios for Gatewaying Bus Communication

Comfort ECU 1
Simulator

ECU
under test 11001101 TX: Frame 1
RX: Frame 1 11001101

Comfort CAN‘ Manipulation

Real-time hardware Ch 2

Gateway

Ch 1

Comfort CAN

11001101
11001101
TX: Frame 1
RX: Frame 1

Comfort ECU 2 Comfort ECU 3

For more information on CAN frame gateways, refer to Specifying CAN Frame
Gateways on page 173.

Workflow To configure CAN frame gateways, you have to add Frame

Gateway elements to the Gateways part of one or more bus configurations
and configure the Frame Gateway elements.
For an overview of the required workflow steps, refer to:
§ Typical Workflows for Using the Bus Manager and Building Real-Time
Applications on page 43
§ Typical Workflows for Using the Bus Manager and Generating Bus Simulation
Containers on page 51

PDU gateways (preview Use scenario for PDU gateways A typical use scenario for a PDU gateway
version) is the simulation of a gateway ECU according to AUTOSAR, as shown in the
following example.

Gateway ECU
receive
Body CAN Source PDU (RX) Source PDU (RX)

transfer data

Target PDU 1 (TX) transmit

Comfort CAN

transmit
Comfort LIN Target PDU 2 (TX)

For more information, refer to Aspects of PDU Gateways on page 76.

Workflow To configure PDU gateways, you have to add the respective source
and target PDUs to the Simulated ECUs part of the same bus configuration. If a

37
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Use Scenarios for Configuring Bus Communication with the Bus Manager

communication matrix does not specify a required PDU gateway, you can modify
the communication matrix to specify user‑defined PDU gateways.
For an overview of the required workflow steps, refer to:
§ Typical Workflows for Using the Bus Manager and Building Real-Time
Applications on page 43
§ Typical Workflows for Using the Bus Manager and Generating Bus Simulation
Containers on page 51

Note

The current version of simulating PDU gateways is a preview version. Refer

to Providing preview versions of Bus Manager features on page 19.

Criteria for Simulating, Inspecting, or Manipulating Bus Communication

Introduction Depending on your use scenario, you can configure bus communication in
different ways:
§ To access data that is received on the bus, you can configure bus
communication for simulation and/or inspection.
§ To access data that is transmitted on the bus, you can configure bus
communication for simulation and/or manipulation.

In most use scenarios, it is sufficient to configure the bus communication in one

of these ways to access data that is received or transmitted on the bus. There are
some criteria that can help you to choose the suitable configuration for your use
scenario.

Tip

If it is required according to your use scenario, you can also combine the
different ways for configuring bus communication.
For example, if you simulate an ECU and you want to manipulate some of
the PDUs that are transmitted by the simulated ECU, you have to assign the
respective PDUs to the Simulated ECUs part and the Manipulation part of
a bus configuration:
§ The transmission of the PDUs is triggered according to their configuration
in the Simulated ECUs part.
§ Immediately before the PDUs are actually transmitted on the bus,
you can manipulate their data according to the configuration in the
Manipulation part.

Criteria for using RX The following criteria can help you to decide whether RX simulation or
simulation or inspection inspection is the better approach for your use scenario to access data that is
received on the bus:

38
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Criteria for Simulating, Inspecting, or Manipulating Bus Communication

Criteria RX Simulation Inspection

Design AUTOSAR‑like COM stack Simple COM stack
Focus ECU‑based: Simulate the behavior of one or more Communication‑cluster‑based: Receive any data on
ECUs, e.g., based on a behavior model. the bus, regardless of the sending ECUs.
Internal ECU states Simulation of internal ECU states No internal ECU states
Multiplicity of One element instance per receiving ECU Only one element instance per communication
elements For example: If a PDU is received by three ECUs, cluster, regardless of whether an element is received
there can be three PDU instances, one per ECU. by one or more ECUs on this cluster.
Element behavior Specific per ECU Specific per communication cluster, i.e., for each
For example: If a PDU is received by three ECUs, element, you can specify the inspection behavior
you can configure the PDU behavior separately for only once per communication cluster.
each ECU.
Run‑time performance Worse Better
Recommendation Use only when required, e.g., when you want to Use whenever possible.
simulate the behavior of one or more specific ECUs
and provide the simulated data separately for each
ECU to a mapped behavior model.

Criteria for using TX The following criteria can help you to decide whether TX simulation or
simulation or manipulation manipulation is the better approach for your use scenario to access data that
is transmitted on the bus:

Criteria TX Simulation Manipulation

Design AUTOSAR‑like COM stack Simple COM stack
Focus ECU‑based: Simulate the behavior of Communication‑cluster‑based:
one or more ECUs, e.g., based on a § Provide manipulated bus communication to the device under
behavior model. test (DUT) to test its reaction.
§ Manipulate data that is transmitted on the bus, regardless of
whether the related sending ECUs are simulated or available
as real ECUs.
Internal ECU states Simulation of internal ECU states No internal ECU states
Multiplicity of One element instance per transmitting Only one element instance per communication cluster, regardless
elements ECU of whether an element is transmitted by one or more ECUs on
For example: If a PDU is transmitted this cluster.
by three ECUs, there can be three PDU
instances, one per ECU.
Element behavior Specific per ECU Specific per communication cluster, i.e., for each element,
For example: If a PDU is transmitted by you can specify the manipulation behavior only once per
three ECUs, you can configure the PDU communication cluster.
behavior separately for each ECU.
Run‑time behavior The configured behavior applies Elements are dynamically manipulated:
permanently: § For each element, you can enable and disable its
§ You cannot disable the simulated manipulation.
behavior. § When manipulation is enabled, you can select whether
§ The simulated behavior applies until the respective element is permanently or temporarily
you change it explicitly. manipulated. For temporary manipulation, you can specify the
For example, if you change the length number of times the element is manipulated.
of a PDU, the specified length applies
until you explicitly change it again.

39
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Use Scenarios for Configuring Bus Communication with the Bus Manager

Criteria TX Simulation Manipulation

Run‑time Better Worse
performance
Recommendation Use whenever possible. Use only when required, e.g., when you want to manipulate an
element for a defined number of times.

Special Use Scenario: Providing Received and Manipulated Data to a Behavior

Model

Introduction A special use scenario is to receive data on a bus, manipulate some of the data,
and provide this data to a behavior model.

You cannot realize this use scenario by configuring bus communication for
manipulation, i.e., using the Manipulation part of bus configurations. This is
because this manipulation applies only to data that is transmitted on the bus.

Instead, you have to configure the bus communication for reception and
generate additional variables into the variable description file (TRC file). By this,
you can access and manipulate the received data via experiment software before
it is provided to the behavior model.

Note

Generating additional variables into the variable description file can

significantly reduce the run‑time performance. Therefore, generate these
variables only for data for which you require the variables.

Recommended workflow To ensure optimum run‑time performance for this use scenario, it is
recommended to configure the bus communication as shown in the following
illustration.

Bus configuration
Variable description: Complete

Receive bus Inspection:

communication (RX)
Bus inspection features

Function outports:
Enable model access and Model port block Behavior model
test automation support

40
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Special Use Scenario: Providing Received and Manipulated Data to a Behavior Model

Note the following points:

§ To generate the additional variables into the variable description file, set the
Variable description property of the bus configuration to Complete.

§ To ensure optimum run‑time performance, it is recommended to assign PDUs

as follows:
§ Assign the required PDUs to the Inspection part of the bus configuration.
§ Assign only the PDUs that you want to manipulate before they are
provided to the behavior model to this bus configuration. Use other bus
configurations to configure further required elements, e.g., to transmit
signals that are provided by the behavior model on the bus.
§ Configure the PDUs, the related frames, and/or the ISignals by using bus
configuration features.
§ Enable model access and test automation support for function outports.
§ Map the function outports to model port blocks.

For an overview of all required workflow steps, refer to:

§ Configuring Bus Communication for Real-Time Applications with a Behavior
Model on page 45
§ Generating Bus Simulation Containers with a Behavior Model on page 53

Manipulating the bus At run time, you can access the function outports with enabled test automation
communication at run time support via experiment software, such as ControlDesk. Using the experiment
software, you can manipulate the data that is received on the bus. You can
do this by using the TA_Switchvalue and TA_Replacevalue variables of the
function outports. The manipulated data is then provided to the behavior model.

For more information on the variables that are generated into the variable
description file, refer to Accessing Function Ports with Enabled Test Automation
Support in Variable Description Files (TRC Files) on page 202.

Tip

If you are using ControlDesk to access the data: The variables are not
available in the Bus Instruments. You have to manually select them in the
Variables pane and assign them to instruments.

41
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Use Scenarios for Configuring Bus Communication with the Bus Manager

42
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Typical Workflows for Using the Bus Manager and Building Real-Time Applications

Typical Workflows for Using the Bus Manager and

Building Real-Time Applications

Where to go from here Information in this section

Workflow for Using the Bus Manager and Configuring Bus

Communication for Real-Time Applications............................................. 43

Configuring Bus Communication for Real-Time Applications with

a Behavior Model.................................................................................... 45

Configuring Bus Communication for Real-Time Applications

Without a Behavior Model....................................................................... 48

Workflow for Using the Bus Manager and Configuring Bus Communication
for Real-Time Applications

Introduction Implementing bus communication by using the Bus Manager has only a minor
influence on the standard ConfigurationDesk workflows for building a real-time
application.

Overview The following illustration gives you an overview of the workflow for using the
Bus Manager and configuring bus communication for a real-time application.
Parts that are specific to this workflow are in bold letters. Parts that are optional
for configuring bus communication are marked by dashed lines.

43
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Typical Workflows for Using the Bus Manager and Building Real-Time Applications

Communication matrices
(created in external tool)

ConfigurationDesk

Model interface*
Signal chain

Bus configuration
Bus Configuration
function block

Bus access request

External CAN/LIN
function
devices blocks

Hardware
resources

* Depends on use scenario

Workflow Building a real-time application that includes bus communication configured by

using the Bus Manager comprises the following workflow steps:
1. Create a new or open an existing ConfigurationDesk project and application.
For more information on managing projects and applications, refer to
Managing ConfigurationDesk Projects and Applications (ConfigurationDesk
Real-Time Implementation Guide ).
2. Add one or more communication matrices to the application.
Refer to How to Add Communication Matrices to a ConfigurationDesk
Application on page 335.
3. Add one or more bus configurations to the application.
Refer to How to Add a Bus Configuration to a ConfigurationDesk
Application on page 338.
4. Depending on your use scenario, do the following:
§ To simulate, inspect, or manipulate bus communication, assign the
communication matrices completely or partly to the Simulated ECUs,
Inspection, or Manipulation part of the bus configurations.
Refer to How to Assign Communication Matrix Elements to a Bus
Configuration on page 340.
§ To specify CAN frame gateways, add Frame Gateway elements to the
Gateways part of the bus configurations.
Refer to Specifying CAN Frame Gateways on page 173.
For information on the use scenarios, refer to Overview of the Use Scenarios
for Configuring Bus Communication with the Bus Manager on page 29.

44
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Configuring Bus Communication for Real-Time Applications with a Behavior Model

5. Configure the bus communication:

§ Add bus configuration features to elements of bus configurations. Bus
configuration features let you configure ISignals, trigger TX PDUs, or
disable communication controllers, for example.
Refer to Working with Bus Configuration Features on page 191.
§ If required, specify user-defined settings for configurable communication
matrix elements.
Refer to Modifying Communication Matrices on page 391.
6. Specify the real-time hardware access.
Refer to How to Specify the Hardware Access on page 344.
7. Build a real-time application and download it to real-time hardware. The
necessary steps depend on your use scenario. For more information, refer to
the following workflows:
§ Configuring Bus Communication for Real-Time Applications with a
Behavior Model on page 45
§ Configuring Bus Communication for Real-Time Applications Without a
Behavior Model on page 48

Further information For general information on typical ConfigurationDesk workflows, refer to Typical
Workflows for Beginners (ConfigurationDesk Getting Started ).

Configuring Bus Communication for Real-Time Applications with a Behavior

Model

Introduction When signals that are assigned to a bus configuration have to change
dynamically during run time (e.g., for dynamic ECU simulation), you need a
behavior model and have to map the required signals to the model before you
build a real-time application.

Overview The following illustration gives you an overview of building a real‑time

application when working with a behavior model. Parts that are specific to this
use scenario are in bold letters. Parts that are optional for this use scenario are
marked by dashed lines.

45
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Typical Workflows for Using the Bus Manager and Building Real-Time Applications

Communication matrices
(created in external tool)

ConfigurationDesk Modeling tool

Model interface
Signal chain Behavior model

Bus configuration
Bus Configuration Model port Model port Control
function block blocks blocks system
Bus access request

External CAN/LIN
function
devices blocks

Hardware
resources

Modeling the executable

application and tasks

Configuring build process

Build

Build results
EXPSWCFG

SDF RTA

TRC MAP

Real-time hardware

SCALEXIO,
MicroAutoBox III,
Download MicroLabBox II

Workflow Building a real-time application that includes bus communication configured with
the Bus Manager and a behavior model comprises the following workflow steps:
1. Configure the bus communication via the Bus Manager. Refer to Workflow
for Using the Bus Manager and Configuring Bus Communication for Real-
Time Applications on page 43.
2. Enable model access for function ports.
Refer to How to Enable Model Access for Function Ports on page 351.
3. Add a behavior model to the ConfigurationDesk application and map the
function ports with enabled model access to model ports:
§ If you already have a suitable behavior model, add the behavior model to
the ConfigurationDesk application. When you do this, model port blocks

46
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Configuring Bus Communication for Real-Time Applications with a Behavior Model

are available in the Model Browser. You can then map the function ports
to the available model ports (e.g., via bus configuration tables).
Refer to How to Add Behavior Models to a ConfigurationDesk Application
on page 352.
§ If you do not have a suitable behavior model yet, ConfigurationDesk can
support you by creating the required model interface. This is possible only
if MATLAB®/Simulink® and Model Interface Package for Simulink are
installed.
For more information, refer to Transferring the ConfigurationDesk Model
Interface to a New Simulink Interface Model (ConfigurationDesk Real-Time
Implementation Guide ).
4. Model the executable application and tasks.

Tip

If you created a preconfigured application process when you added the

behavior model to the ConfigurationDesk application, you can usually
skip this step. The settings of the preconfigured application process and
the tasks are sufficient in most cases.

For basic information, refer to:

§ Introduction to Modeling Executable Applications and Tasks
(ConfigurationDesk Real-Time Implementation Guide ).
§ Basics on Tasks, Events, and Runnable Functions Provided by the Bus
Manager on page 363
5. Configure and start the build process.
During the build process, an EXPSWCFG and an EXPSWCFG.MAPPING file
are generated:
§ The EXPSWCFG file contains the bus configuration data. This file is used
by experiment software such as ControlDesk to access and manipulate bus
communication.
§ The EXPSWCFG.MAPPING file contains the mapping between the CAN
and/or LIN function blocks and the bus access requests of the bus
configurations for which the function blocks specify the bus access . This
file is used by experiment software to identify which bus access requests
form a run‑time communication cluster.
Refer to Building Real-Time Applications (ConfigurationDesk Real-Time
Implementation Guide ).
6. Download and execute the real-time application.
Refer to Loading and Executing Real-Time Applications (ConfigurationDesk
Real-Time Implementation Guide ).

Related topics Basics

Overview of the Use Scenarios for Configuring Bus Communication with the Bus
Manager.................................................................................................................................. 29

47
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Typical Workflows for Using the Bus Manager and Building Real-Time Applications

Configuring Bus Communication for Real-Time Applications Without a

Behavior Model

Introduction When signals that are assigned to a bus configuration do not have to change
dynamically during run time (e.g., in case of static ECU simulation) or you only
want to access the signals via an experiment software, you can work without a
behavior model.

Overview The following illustration gives you an overview of working without a behavior
model. Parts that are specific to this use scenario are in bold letters. Parts that are
optional for this use scenario are marked by dashed lines.

Communication matrices
(created in external tool)

ConfigurationDesk

Signal chain

Bus configuration
Bus Configuration
function block

Bus access request

External CAN/LIN
function
devices blocks

Hardware
resources

Creating application
processes providing
default tasks

Configuring build process

Build

Build results
EXPSWCFG

SDF RTA

TRC MAP

Real-time hardware

SCALEXIO,
MicroAutoBox III,
Download MicroLabBox II

48
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Configuring Bus Communication for Real-Time Applications Without a Behavior Model

Workflow Building a real-time application that includes bus communication configured with
the Bus Manager but no behavior model comprises the following workflow
steps:
1. Configure the bus communication via the Bus Manager.
Refer to Workflow for Using the Bus Manager and Configuring Bus
Communication for Real-Time Applications on page 43.
2. Create at least one application process that provides default tasks.
Refer to How to Create Application Processes that Provide Default Tasks on
page 386.
3. Configure and start the build process.
During the build process, an EXPSWCFG file is generated that contains the
bus configuration data. This file is used by an experiment software such as
ControlDesk to access and manipulate bus communication.
Refer to Building Real-Time Applications (ConfigurationDesk Real-Time
Implementation Guide ).
4. Download and execute the real-time application.
Refer to Loading and Executing Real-Time Applications (ConfigurationDesk
Real-Time Implementation Guide ).

Related topics Basics

Overview of the Use Scenarios for Configuring Bus Communication with the Bus
Manager.................................................................................................................................. 29

49
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Typical Workflows for Using the Bus Manager and Building Real-Time Applications

50
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Typical Workflows for Using the Bus Manager and Generating Bus Simulation Containers

Typical Workflows for Using the Bus Manager and

Generating Bus Simulation Containers

Where to go from here Information in this section

Workflow for Configuring Bus Communication and Generating

Bus Simulation Containers....................................................................... 51

Generating Bus Simulation Containers with a Behavior Model................. 53

Generating Bus Simulation Containers Without a Behavior Model........... 54

Workflow for Configuring Bus Communication and Generating Bus Simulation

Containers

Introduction You can use the Bus Manager to configure bus communication and generate
bus simulation containers that contain the configured bus communication.
Bus simulation containers can be used on various dSPACE simulation
platforms. For example, you can use bus simulation containers in VEOS or
ConfigurationDesk to implement the configured bus communication in offline
simulation applications or real-time applications , respectively.

Overview The following illustration gives you an overview of the workflow for using the
Bus Manager to configure bus communication and generate a bus simulation
container that contains the configured bus communication. Parts that are specific
to this workflow are in bold letters.

51
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Typical Workflows for Using the Bus Manager and Generating Bus Simulation Containers

Communication matrices
(created in external tool)
Bus Manager in ConfigurationDesk
or stand-alone

Model interface*
Signal chain

Bus configuration
Bus Configuration
function block

* Depends on use scenario

Workflow Generating a bus simulation container containing the bus communication

configured with the Bus Manager comprises the following workflow steps:
1. Create a new or open an existing ConfigurationDesk project and application.
For more information on managing projects and applications, refer to
Managing ConfigurationDesk Projects and Applications (ConfigurationDesk
Real-Time Implementation Guide ).
2. Add one or more communication matrices to the application.
Refer to How to Add Communication Matrices to a ConfigurationDesk
Application on page 335.
3. Add one or more bus configurations to the application.
Refer to How to Add a Bus Configuration to a ConfigurationDesk
Application on page 338.
4. Depending on your use scenario, do the following:
§ To simulate, inspect, or manipulate bus communication, assign the
communication matrices completely or partly to the Simulated ECUs,
Inspection, or Manipulation part of the bus configurations.
Refer to How to Assign Communication Matrix Elements to a Bus
Configuration on page 340.
§ To specify CAN frame gateways, add Frame Gateway elements to the
Gateways part of the bus configurations.
Refer to Specifying CAN Frame Gateways on page 173.
For information on the use scenarios, refer to Overview of the Use Scenarios
for Configuring Bus Communication with the Bus Manager on page 29.
5. Configure the bus communication, for example:
§ Add bus configuration features to elements of bus configurations. Bus
configuration features let you configure ISignals, trigger TX PDUs, or
disable communication controllers, for example.
Refer to Working with Bus Configuration Features on page 191.
§ Specify user-defined settings for configurable communication matrix
elements.
Refer to Modifying Communication Matrices on page 391.

52
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Generating Bus Simulation Containers with a Behavior Model

6. Generate the bus simulation container. The necessary steps depend on your
use scenario. For more information, refer to the following workflows:
§ Generating Bus Simulation Containers with a Behavior Model on page 53
§ Generating Bus Simulation Containers Without a Behavior Model on
page 54

Generating Bus Simulation Containers with a Behavior Model

Introduction When signals that are assigned to a bus configuration have to change
dynamically during run time (e.g., for dynamic ECU simulation), you need a
behavior model and have to map the required signals to the model before you
generate bus simulation containers. The behavior model must be a Simulink®
implementation container (SIC) file.

Overview The following illustration gives you an overview of working with a behavior
model. Parts that are specific to this use scenario are in bold letters.

Communication matrices
(created in external tool)
Bus Manager in ConfigurationDesk
or stand-alone MATLAB®/Simulink® +
Model Interface
Model interface Package for Simulink
Signal chain Simulink implementation
container
Bus configuration
Bus Configuration Model SIC
function block port
blocks

Modeling the executable

application and tasks

Generate

Bus simulation
container

BSC

Workflow Generating a bus simulation container that contains the bus communication
configured with the Bus Manager and a mapped Simulink implementation
container comprises the following workflow steps:
1. Configure the bus communication via the Bus Manager.
Refer to Workflow for Configuring Bus Communication and Generating Bus
Simulation Containers on page 51.

53
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Typical Workflows for Using the Bus Manager and Generating Bus Simulation Containers

2. Enable model access for function ports.

Refer to How to Enable Model Access for Function Ports on page 351.
3. Add a suitable Simulink implementation container (SIC) file to the
ConfigurationDesk application.
Refer to How to Add Behavior Models to a ConfigurationDesk Application
on page 352.

Tip

If you do not have a suitable SIC file yet but MATLAB®/Simulink®

and Model Interface Package for Simulink are installed,
ConfigurationDesk can support you by creating the required model
interface. When you do this, the model interface is created
in ConfigurationDesk and a MATLAB/Simulink model. From the
MATLAB/Simulink model, you can then generate an SIC file and add
this file to the ConfigurationDesk application.
For more information, refer to Transferring the ConfigurationDesk
Model Interface to a New Simulink Interface Model (ConfigurationDesk
Real-Time Implementation Guide ) and Generating Simulink
Implementation Containers (Model Interface Package for Simulink -
Modeling Guide ).

4. Map model ports of the SIC file to function ports of bus configurations.
§ For an example of mapping the ports via bus configuration tables, refer to
Example of Mapping Model Ports to Bus Configuration Ports via Tables on
page 358.
§ For basic information on model port mapping, refer to Model Port
Mapping (ConfigurationDesk Real-Time Implementation Guide ).
5. Model the executable application and tasks.
If you created a preconfigured application process when you added the SIC
file to the ConfigurationDesk application, you can usually skip this step. The
settings of the preconfigured application process and the tasks are sufficient
in most cases.
For basic information, refer to:
§ Introduction to Modeling Executable Applications and Tasks
(ConfigurationDesk Real-Time Implementation Guide ).
§ Basics on Tasks, Events, and Runnable Functions Provided by the Bus
Manager on page 363
6. Generate the bus simulation container.
Refer to How to Generate Bus Simulation Containers on page 379.

Generating Bus Simulation Containers Without a Behavior Model

Introduction When signals that are assigned to a bus configuration do not have to change
dynamically during run time (e.g., in case of static ECU simulation) or you only

54
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Generating Bus Simulation Containers Without a Behavior Model

want to access the signals via an experiment software, you can work without a
behavior model.

Overview The following illustration gives you an overview of working without a behavior
model. Parts that are specific to this use scenario are in bold letters.

Communication matrices
(created in external tool)
Bus Manager in ConfigurationDesk
or stand-alone

Signal chain

Bus configuration
Bus Configuration
function block

Creating application
processes providing
default tasks
Assigning bus
configurations to
application processes

Generate

Bus simulation
container

BSC

Workflow Generating bus simulation containers that contain the bus communication
configured with the Bus Manager but no behavior model comprises the
following workflow steps:
1. Configure the bus communication via the Bus Manager.
Refer to Workflow for Configuring Bus Communication and Generating Bus
Simulation Containers on page 51.
2. Create one or more application processes that provide default tasks.
Refer to How to Create Application Processes that Provide Default Tasks on
page 386.
3. Assign the bus configurations to the available application processes
manually.
Refer to How to Manually Assign Bus Configurations to Application
Processes on page 387.
4. Generate the bus simulation containers.
Refer to How to Generate Bus Simulation Containers on page 379.

55
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Typical Workflows for Using the Bus Manager and Generating Bus Simulation Containers

56
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Aspects of Supported Bus Communication

Aspects of Supported Bus Communication

Where to go from here Information in this section

Aspects of Supported PDUs and Signals................................................... 58

Aspects of Supported AUTOSAR Features................................................ 63

Aspects of Supported CAN Bus Features.................................................. 77

Aspects of Supported LIN Bus Features.................................................... 88

57
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Aspects of Supported Bus Communication

Aspects of Supported PDUs and Signals

Where to go from here Information in this section

Supported PDU Types and Signal Data Types............................................ 58

Signal Conversion by the Bus Manager.................................................... 60

Supported PDU Types and Signal Data Types

Supported PDU types The Bus Manager supports various PDU types according to AUTOSAR, FIBEX,
DBC, and LDF. To provide a consistent representation of the supported PDU
types, the Bus Manager uses PDU-specific element types that are derived from
the AUTOSAR PDU entities. PDUs of other communication standards are mapped
to these element types. The following PDU-specific element types are available:
§ Bus ISignal IPDU
§ Bus General-Purpose IPDU
§ Bus General-Purpose PDU
§ Bus DCM IPDU
§ Bus NMPDU
§ Bus NPDU
§ Bus Secured IPDU
§ Bus User-Defined IPDU
§ Bus User-Defined PDU
§ Bus Multiplexed IPDU
§ Bus Extended Multiplexed IPDU
§ Bus Container IPDU

Note

The Bus Manager does not provide access to all the features and functions
that are defined in the communication standards for the supported PDU
types.

Except for multiplexed IPDUs, container IPDUs, and secured IPDUs, the Bus
Manager provides the same functionalities for the supported PDU types.
These PDU types are named basic PDUs in the documentation. In the
ConfigurationDesk application, basic PDUs are represented by the or
symbol in tables and browsers. However, basic PDUs can be distinguished by
their PDU element type in tables, browsers, and via the automation interface.
Therefore, you can filter for specific PDU types in tables or access them directly
via XPath expressions in automation scripts, for example.

58
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Aspects of Supported PDUs and Signals

Further information
§ For more information on multiplexed IPDUs, refer to Aspects of Multiplexed
IPDUs on page 63.
§ For more information on container IPDUs, refer to Aspects of Container IPDUs
and Contained IPDUs on page 64.
§ For more information on secured IPDUs, refer to Aspects of Secure Onboard
Communication (SecOC) on page 67.
§ For more information on extended multiplexed IPDUs, refer to Aspects of
Miscellaneous Supported CAN Bus Features on page 77.
§ For more information on the mapping of the Bus Manager PDU types to the
AUTOSAR, FIBEX, DBC, and LDF PDU types, refer to Mapping of Bus Manager
PDU Types to Communication Standard PDU Types on page 537.
§ For more information on accessing Bus Manager elements via
XPath expressions, refer to Accessing Bus Manager Features via the
ConfigurationDesk Automation Interface on page 152.
§ For more information on limitations regarding the supported PDU types, refer
to:
§ Limitations for Communication Matrices and Communication Standards on
page 519
§ Limitations for CAN Communication on page 525
§ Limitations for LIN Communication on page 528

Supported signal data types The Bus Manager supports signals of the following data types:
§ Int8
§ Int16
§ Int32
§ Int64
§ UInt8
§ UInt16
§ UInt32
§ UInt64
§ UInt8[] (array signals)
§ Float (Float32)
§ Double (Float64)
§ Boolean

Other data types (e.g., ASCII string, char, bitfield) are not supported. Signals
whose signal length is a multiple of 8 and exceeds 64 bits are imported as
UInt8[] array signals with static length. For the support of array signals, some
limitations apply. Refer to Limitations for array signals on page 525.

59
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Aspects of Supported Bus Communication

Signal Conversion by the Bus Manager

Transmitting and receiving The Bus Manager accesses ISignals via their converted physical signal values
ISignals on the bus (e.g., EngineTempSig = 85 °C). Because physical signal values cannot be
transmitted on a bus, the Bus Manager converts physical signal values into coded
signal values (e.g., EngineTempSig = 0x17) and includes the ISignals in a
PDU (TX ISignals). When a PDU is received on the bus, the contained coded
ISignals are extracted and their signal values are converted to physical values (RX
ISignals).
ISignal/ISignal group
ISig
Physical ISig ISig ISig ISig (Converted physical values)

Bus Manager:
Signal conversion according
to computation methods
Coded

ISignal/ISignal group
ISig ISig ISig ISig ISig (Coded values)

ISig ISig ISig ISig ISig PDU

DLC PDU PDU PDU Frame

PCI DLC PDU PDU PDU LPDU

Computation methods for Computation methods define the algorithm for converting coded ISignal
converting ISignal values values into physical values and vice versa. Normally, the communication
matrix defines a computation method for each ISignal. If the communication
matrix does not define a computation method for an ISignal, the Bus Manager
uses a default computation method.

Aspect Description
Basics on Generally, computation methods can be specified in different ways, for example, as linear conversion or as a
computation rational function of higher order:
methods Num0 + Num1 ⋅ x + Num2 ⋅ x2 + Num3 ⋅ x3 + … + Numn ⋅ xn
y=
Denom0 + Denom1 ⋅ x + … + Denomn ⋅ xn

Supported The Bus Manager only supports computation methods that define a linear computation scale, i.e.:
Num0 + Num1 ⋅ x
y= , with Num1 ≠ 0
computation
methods Denom0
Num1
This also includes identical computation methods, i.e., with Num0 = 0 (offset) and = 1 (factor).
Denom0

60
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Aspects of Supported PDUs and Signals

Aspect Description
If a rational function is used as the computation method, the numerator and denominator arrays must be
defined as follows:
§ The numerator array must contain at least two elements and the second element must not be zero.
§ If the numerator array contains a third element, it and all following elements must be zero.
§ If a denominator array is defined, the first element must not be zero. If the array contains more elements,
they must all be zero.
If no denominator array is defined, the default denominator value 1 is used.
Examples:
Numerator[] = {0,1}
Denominator[] = {}

Numerator[] = {0,2.7,0,0,0}
Denominator[] = {3,0,0}

Numerator[] = {2,5.6,0,0}
Denominator[] = {4,0}

Default If the communication matrix does not define a computation method for a signal, the Bus Manager uses an
computation identical computation method by default.
method
Representation When you select an ISignal (e.g., in the Buses Browser), the Properties Browser provides the following
in the Bus properties:
Manager Num0
Denom0
§ Offset: Displays the offset of the computation method, i.e., .

Num1
Denom0
§ Scale: Displays the factor of the computation method, i.e., .

§ Numerators, Denominators: Let you specify user-defined settings for the numerator and denominator
arrays, respectively. However, whether these properties are available depend on the specifications in the
communication matrix. Refer to Configurable Settings of ISignals on page 427.

Regarding the computation methods, some limitations apply. For details, refer
to Limitations for Communication Matrices and Communication Standards on
page 519.

61
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Aspects of Supported Bus Communication

Determining the data type for If the communication matrix specifies data types for physical signal values, the
physical signal values Bus Manager uses these data types. If the communication matrix does not
specify data types for physical signal values but only for coded ISignals, the Bus
Manager determines the physical data type by using the computation method
definitions of the communication matrix:

Definition in Communication Matrix Determined Data Type of Physical Signal

No computation method defined Same data type as coded data type
Linear computation method with offset = 0 and Same data type as coded data type
factor = 1
§ Supported computation method with integer values for Smallest integer data type that is able to cover all possible
offset and factor physical signal values.
§ Data type for coded ISignals = integer The Bus Manager calculates the possible physical signal values
according to the computation method and the signal length
specified in the communication matrix.
§ Supported computation method with floating-point values Double
for offset and/or factor
§ Data type for coded ISignals = integer

In case of an array signal, the Bus Manager does not determine the physical data
type on the basis of computation methods. Instead, the Bus Manager uses the
same data type as specified for the coded data type of the array signal.

Regarding the determination of data types for physical signal values, some
limitations apply. For details, refer to Limitations for Communication Matrices
and Communication Standards on page 519.

62
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Aspects of Supported AUTOSAR Features

Aspects of Supported AUTOSAR Features

Where to go from here Information in this section

Aspects of Multiplexed IPDUs.................................................................. 63

Aspects of Container IPDUs and Contained IPDUs.................................... 64

Aspects of Secure Onboard Communication (SecOC)............................... 67

Aspects of End‑to‑End (E2E) Protection for ISignal Groups............. .......... 69

Aspects of Event‑Controlled Timings........................................................ 70

Aspects of Global Time Synchronization (GTS)......................................... 71

Aspects of Partial Networking.................................................................. 74

Aspects of PDU Gateways........................................................................ 76

Aspects of Multiplexed IPDUs

Introduction For CAN communication, the Bus Manager supports multiplexed IPDUs.
Multiplexing is used to transport varying ISignal IPDUs via the same bytes of a
multiplexed IPDU.

Parts of multiplexed IPDUs A multiplexed IPDU consists of one dynamic part, a selector field, and one
optional static part:
§ The dynamic part is one ISignal IPDU that is selected for transmission at run
time. Several ISignal IPDUs can be specified as dynamic‑part alternatives, i.e.,
as dynamic‑part IPDUs. One of these alternatives is transmitted at a time.
§ The selector field value indicates which ISignal IPDU is transmitted in the
dynamic part during run time. For each ISignal IPDU that is configured as
a dynamic‑part alternative, there must be a unique selector field value. The
selector field value is evaluated by the receiver of the multiplexed IPDU.
§ The static part is one ISignal IPDU, i.e., the static‑part IPDU, that is always
transmitted.

63
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Aspects of Supported Bus Communication

Triggering modes for According to AUTOSAR, the following triggering modes can be specified to
multiplexed IPDUs trigger the transmission of multiplexed IPDUs:

Triggering Mode Description

DYNAMIC-PART- Only dynamic‑part IPDUs can trigger the transmission of the
TRIGGER multiplexed IPDU.
STATIC-PART- Only the static‑part IPDU can trigger the transmission of the
TRIGGER multiplexed IPDU.
STATIC-OR- Dynamic‑part IPDUs or the static‑part IPDU can trigger the
DYNAMIC-PART- transmission of the multiplexed IPDU.
TRIGGER
NONE Neither dynamic‑part IPDUs nor the static‑part IPDU can trigger
the transmission of the multiplexed IPDU. If the transmission of
a dynamic‑part or static‑part IPDU is triggered, the data in the
multiplexed IPDU is updated, but the multiplexed IPDU is not
transmitted. Instead, the transmission can be triggered by an
AUTOSAR TriggerTransmit function, for example.

However, regardless of the specified triggering mode, the Bus Manager transmits
a multiplexed IPDU each time its transmission is triggered by a dynamic‑part IPDU
or the static‑part IPDU. Refer to Triggering the Transmission of Multiplexed IPDUs
on page 137.

Limitations For multiplexed IPDUs, some limitations apply. Refer to Limitations for
Communication Matrices and Communication Standards on page 519.

Aspects of Container IPDUs and Contained IPDUs

Introduction For CAN FD communication, the Bus Manager supports container IPDUs. A
container IPDU consists of several smaller IPDUs (i.e., contained IPDUs). The
contained IPDUs can be ISignal IPDUs or multiplexed IPDUs , for example. A
container IPDU can be used to transmit several classic CAN‑compliant IPDUs in
one CAN‑FD‑compliant IPDU on a CAN FD bus, for example.

Dynamic and static container The container layout of container IPDUs can be organized dynamically or
layout statically:

Container Description
Layout
Dynamic The contained IPDUs do not have a predefined position in the container IPDU. The receiving ECU identifies the
container contained IPDUs via their header IDs.
layout For this purpose, two header types are available (SHORT-HEADER, LONG-HEADER). A contained IPDU can provide
a separate header ID for each of these header types. The container IPDU defines the required header type: The
ID of the required header type must be specified for each contained IPDU and the receiving ECU evaluates only
these IDs.

64
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Aspects of Supported AUTOSAR Features

Container Description
Layout
Static container The contained IPDUs have a fixed position within the container IPDU. The receiving ECU identifies the contained
layout IPDUs unambiguously by their position within the container IPDU.
For this purpose, the header type of the container IPDU must be set to NO-HEADER and an offset value must
be specified for each contained IPDU. The offset value determines the position of the contained IPDU within the
container IPDU.

Triggering of container IPDUs The triggering of container IPDUs depends on various timing and triggering
conditions that can be specified for container and/or contained IPDUs in the
communication matrix. For example, a container IPDU can be transmitted:
§ When a specified timeout value elapses
§ Immediately after the first contained IPDU is added
§ When a specific contained IPDU triggers its transmission

The Bus Manager supports various AUTOSAR-compliant timing and triggering

conditions. Additionally, the Bus Manager also triggers the transmission of
container IPDUs with a static container layout if all of the following conditions
are met:
§ The CONTAINER-TRIGGER attribute of a container IPDU with a static container
layout is set to DEFAULT-TRIGGER.
§ The data of a contained IPDU has changed or its transmission is triggered but
the TRIGGER attribute of the contained IPDU is not specified.

Queuing of contained IPDUs For each contained IPDU that is transmitted on the bus, the communication
matrix must specify the collection semantics:

Collection Description
Semantics
Queued Several instances of the contained IPDU can be added to one container IPDU.
The queued semantics is supported only for contained IPDUs that are included in container IPDUs with a dynamic
container layout.
Last‑is‑best Only one instance of the contained IPDU can be added to one container IPDU. In this case, the data of the
contained IPDU is buffered and only the latest data is added to the container IPDU just before it is transmitted.
The last‑is‑best semantics is supported for contained IPDUs that are included in container IPDUs with a dynamic or
static container layout.

According to AUTOSAR, all contained IPDUs that are included in the same
container IPDU must have the same collection semantics specified. In contrast to
AUTOSAR, the Bus Manager supports both semantics within the same container
IPDU. The behavior is the following:
§ For contained IPDUs that are included in a container IPDU with a static
container layout, the specified collection semantics is not evaluated. Instead,
the last‑is‑best semantics applies to all contained IPDUs of this container IPDU.
§ For contained IPDUs that are included in a container IPDU with a dynamic
container layout, the collection semantics is evaluated: Each contained IPDU is
included in the container IPDU according to its specified collection semantics.

65
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Aspects of Supported Bus Communication

The Bus Manager lets you specify the collection semantics. Refer to Configurable
Settings of PDUs on page 414.

Adding additional bytes to Container IPDUs with a static container layout When a container IPDU
the related frame with a static container layout is added to a frame and the resulting frame length
is invalid according to CAN FD, padding bytes are added to the frame. Refer to
CAN FD protocol on page 77.

Container IPDUs with a dynamic container layout For container IPDUs

with a dynamic container layout, additional bytes can be added to the related
frame to indicate the end of the container IPDU in the payload of the frame:
§ SHORT-HEADER: Up to three bytes can be added.
§ LONG-HEADER: Up to four bytes can be added.
These bytes are filled with 0. However, if and how many bytes are added
depends on the resulting length of the frame: The bytes are added only if this
does not result in an invalid length according to CAN FD, as shown in the
following examples.

Case 1 Case 2 Case 3

Length of container IPDU in the frame (IPDU header plus 13 19 24
payload)
Next valid frame length according to CAN FD 16 20 24
Number of added 0‑bytes 3 1 0

If the maximum number of 0‑bytes is added to the frame and the resulting frame
length is still invalid according to CAN FD, additional padding bytes are added.
These padding bytes are filled with the unused bit pattern that is specified for
the container IPDU. If no unused bit pattern is specified, the padding bytes are
filled with 255.

Static container layout: When a container IPDU with a static container layout is transmitted, some of its
Identifying updated contained IPDUs might not have been updated since the previous transmission
contained IPDUs and therefore provide old data. There are two ways to identify the update state:

Setting Description
Update bit of Contained IPDUs can provide an update bit. The bit is set if a
contained IPDU contained IPDU has been updated between two transmissions of
the related container IPDU.
Unused bit pattern Container IPDUs can provide an unused bit pattern. If a contained
of container IPDU IPDU of the container IPDU is not updated, the content of the
contained IPDU is cleared and replaced with the unused bit
pattern.

Dynamic container layout: For container IPDUs with a dynamic container layout, the setting of the
Accepting received contained RX-ACCEPT-CONTAINED-IPDU attribute determines which contained IPDUs are
IPDUs accepted by the receiving ECU:

66
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Aspects of Supported AUTOSAR Features

Setting Description
ACCEPT-ALL In general, the receiving ECU accepts any contained IPDU, regardless of whether it is included in the container
IPDU according to the specifications in the communication matrix.
However, to accept a contained IPDU that is not included in the container IPDU according to the specifications in
the communication matrix, the following conditions must be met:
§ The communication matrix includes the IPDU in another container IPDU whose RX-ACCEPT-CONTAINED-
IPDU attribute is set to ACCEPT-ALL.
§ The header ID of the header type that is required by the container IPDU is specified for the contained IPDU.
ACCEPT- The receiving ECU accepts only contained IPDUs that are included in the container IPDU according to the
CONFIGURED specifications in the communication matrix.

Contained IPDUs that are not accepted are ignored by the receiving ECU, i.e.,
they are not extracted from the container IPDU and their data is not processed.

Limitations For container IPDUs and contained IPDUs, some limitations apply. Refer to
Limitations for container IPDUs on page 521.

Aspects of Secure Onboard Communication (SecOC)

Introduction For CAN communication, the Bus Manager supports secure onboard
communication (SecOC) according to AUTOSAR. Secure onboard communication
provides authentication mechanisms to identify PDU data that was modified or
transmitted without authorization, e.g., due to a replay attack.

PDUs for secure onboard In secure onboard communication scenarios, the following PDUs are used:
communication § Authentic IPDUs
Authentic IPDUs contain the payload that will be secured by the authentication
mechanisms of SecOC. The required authentication information itself is not
included in authentic IPDUs but in secured IPDUs. According to AUTOSAR,
authentic IPDUs can be ISignal IPDUs, container IPDUs, or multiplexed IPDUs,
for example.

§ Secured IPDUs and cryptographic IPDUs

Secured IPDUs are used to secure the payload of authentic IPDUs, i.e., they
contain the required authentication information. The sender includes the
authentication information in the secured IPDU and the receiver verifies the
received authentication information, as shown in the following example.
Sender Receiver

Generating
OK
authentication Verification
information
Processing

Authentication Authentication
Authentic IPDU Authentic IPDU Authentic IPDU Authentic IPDU
information information

Secured IPDU Secured IPDU

67
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Aspects of Supported Bus Communication

The handling of the related authentic IPDUs depends on whether secured

IPDUs are configured as cryptographic IPDUs:
§ If a secured IPDU is configured as a cryptographic IPDU, the related
authentic IPDU is not included in the secured IPDU. In this case, the
authentic IPDU and the cryptographic IPDU are separately transmitted on
the bus. The receiver verifies the authentication information each time the
authentic IPDU or cryptographic IPDU is received.
§ If a secured IPDU is not configured as cryptographic IPDU, i.e., it is a
non‑cryptographic IPDU, the related authentic IPDU is directly included in
the secured IPDU. In this case, only one PDU is exchanged on the bus.

Authentication information According to AUTOSAR, there are various ways for generating and verifying
authentication information. To generate and verify specific authentication
information, OEM-specific implementations are therefore required. In general,
authentication information that is included in a secured IPDU consists of a
freshness value and an authenticator:
§ Freshness value
The freshness value is a monotonous increasing value. Depending on the
OEM-specific implementation, the freshness value can be a counter value
or a time stamp value. The freshness value is required for calculating the
authenticator. Additionally, the freshness value can directly be included in the
secured IPDU. If it is, it can be included completely or in part, i.e., as truncated
freshness value.
§ Authenticator
The authenticator, also called message authentication code (MAC), is
calculated according to OEM-specific algorithms and keys. For calculating the
authenticator, the following data is required:
§ Data identifier of the secured IPDU
§ Payload of the authentic IPDU
§ Freshness value
The authenticator is either completely included in the secured IPDU or in part,
i.e., as truncated authenticator.

The following illustration is an example of authentication information in a

secured IPDU.

Sender
Key

Authenticator

Counter or Freshness
time stamp value

Payload
Data ID
Freshness
Authentic IPDU Authenticator
value

Secured IPDU
Authentication information

68
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Aspects of Supported AUTOSAR Features

Implementing secure onboard To implement secure onboard communication in executable applications , you
communication in executable have to enable SecOC support and provide the OEM-specific implementation
applications for generating and/or verifying authentication information via user code . Refer
to Implementing Secure Onboard Communication in Executable Applications on
page 143.

Limitations For secure onboard communication, some limitations apply. Refer to Limitations
for Communication Matrices and Communication Standards on page 519.

Aspects of End‑to‑End (E2E) Protection for ISignal Groups

Introduction The Bus Manager supports end-to-end (E2E) protection for ISignal groups
according to AUTOSAR end‑to‑end protection profiles (E2E profiles).

Supported end‑to‑end The Bus Manager the following AUTOSAR end-to-end protection profiles
protection features (E2E profiles) for ISignal groups:
§ Profile 01 (including the profile variants 1A, 1B, 1C)
§ Profile 02
§ Profile 05
§ Profile 11 (including the profile variants 11A, 11C)
§ Profile 22

The Bus Manager supports COM E2E callouts (only for profile 01 and profile 02)
and E2E transformers (for all supported profiles) for calling the end-to-end
communication protection library (E2E library).

The end-to-end protection of an ISignal group must be specified in the

communication matrix. Each end-to-end-protected ISignal group must be
mapped to exactly one ISignal IPDU. An ISignal IPDU can contain one or more
end-to-end-protected ISignal groups.

The Bus Manager can transmit and receive end-to-end-protected ISignals groups:
§ TX ISignal groups are transmitted with the end-to-end protection information
that is required according to the specified profile.
§ RX ISignal groups are received but the end-to-end protection information is
not evaluated by the Bus Manager, i.e., a received IPDU is decoded regardless
of whether the end-to-end protection of a contained ISignal group indicates
failures.

Limitations For end‑to‑end protection, some limitations apply. Refer to Limitations for
Communication Matrices and Communication Standards on page 519.

69
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Aspects of Supported Bus Communication

Aspects of Event‑Controlled Timings

Introduction For PDU transmission, the Bus Manager supports event‑controlled timings
according to AUTOSAR. With event‑controlled timings, ISignals and ISignal
groups can trigger the transmission of the PDUs in which they are included.

Event‑controlled timings and To trigger the transmission of a PDU according to event‑controlled timings,
transfer property each ISignal and ISignal group can provide a TRANSFER‑PROPERTY attribute. The
setting of this attribute determines if and how an ISignal/ISignal group triggers
the transmission of the PDU. The PDU must provide the event‑controlled timing.
The event‑controlled timing can specify the number of repetitions and the
repetition period, which apply to the transmission of the PDU if the transmission
is triggered with repetitions.

According to AUTOSAR, the setting of the TRANSFER‑PROPERTY attribute

determines the transmission of a PDU as follows:

Setting Description
PENDING The ISignal or ISignal group does not trigger the transmission of the PDU.
TRIGGERED The ISignal or ISignal group triggers the transmissions of the PDU with repetitions. The
transmission is triggered each time the ISignal/ISignal group is updated, regardless of
whether a signal value has changed.
TRIGGERED‑ON‑CHANGE The ISignal or ISignal group triggers the transmissions of the PDU with repetitions. The
transmission is triggered only if the ISignal/ISignal group is updated and a signal value has
changed, i.e.:
§ ISignal: The value of the ISignal has changed.
§ ISignal group: The value of at least one ISignal that is included in the ISignal group
has changed and the transfer property of this ISignal is either unspecified or set to
TRIGGERED‑ON‑CHANGE.
TRIGGERED‑WITHOUT‑REPETITION The ISignal or ISignal group triggers a single transmission of the PDU. The transmission
is triggered each time the ISignal/ISignal group is updated, regardless of whether a signal
value has changed.
TRIGGERED‑ON-CHANGE- The ISignal or ISignal group triggers a single transmission of the PDU. The transmission is
WITHOUT‑REPETITION triggered only if the ISignal/ISignal group is updated and a signal value has changed, i.e.:
§ ISignal: The value of the ISignal has changed.
§ ISignal group: The value of at least one ISignal that is included in the ISignal group
has changed and the transfer property of this ISignal is either unspecified or set to
TRIGGERED‑ON‑CHANGE.

For ISignal groups, the following rules apply according to AUTOSAR:

§ The transfer property of the included ISignals must be either unspecified or set
to PENDING or TRIGGERED‑ON‑CHANGE.
§ All ISignals that are included in the same ISignal group must have the transfer
property either specified or unspecified.

In contrast to AUTOSAR, the Bus Manager transmits PDUs according to

event‑controlled timings only if a coded ISignal value has changed. Therefore,
the Bus Manager evaluates the TRIGGERED setting in the same way as
the TRIGGERED‑ON‑CHANGE setting and the TRIGGERED‑WITHOUT‑REPETITION
setting in the same way as the TRIGGERED‑ON-CHANGE-WITHOUT‑REPETITION

70
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Aspects of Supported AUTOSAR Features

setting. Moreover, an ISignal/ISignal group can trigger a single transmission of a

PDU even if no event‑controlled timing is specified for this PDU. For ISignals that
are included in an ISignal group, the Bus Manager accepts any setting of the
transfer property.

Event‑controlled timings must be specified in the communication matrix. If the

communication matrix does not specify an event‑controlled timing for a PDU,
you can add it. Refer to Basics on Modifying Communication Matrices on
page 391.

However, to trigger the transmission of PDUs via ISignals/ISignal groups and use
event‑controlled timings, you have to enable the use of the transfer property.
Refer to Using Event‑Controlled Timings for Transmitting PDUs on page 136.

Limitations For event‑controlled timings, some limitations apply. Refer to Limitations for
Communication Matrices and Communication Standards on page 519.

Aspects of Global Time Synchronization (GTS)

Introduction The Bus Manager supports global time synchronization (GTS) according to
AUTOSAR. Global time synchronization means providing and distributing
synchronized times among all ECUs in a bus network. By this, the bus
communication of multiple ECUs can be synchronized, for example.

Time bases A synchronized time is called a time base. A time base is a unique time entity
characterized by the progression of time, ownership, and reference to the
physical world. There are two types of time bases:

Time Base Type Description

Synchronized time A synchronized time base is a time base that is synchronized with
base other time bases of different bus network participants. These
synchronized time bases constitute a global time.
Offset time base An offset time base is a time base that depends on a particular
synchronized time base and holds an offset value with respect to
that time base.

Time bases can provide absolute times (e.g., a UTC time) or relative times (e.g.,
time after power-up of an ECU or an operating hours counter). Because there
can be more than just one time in a bus network, multiple time bases can exist in
parallel. Per ECU, there can be up to 16 synchronized time bases and offset time
bases each.

Global time domains A global time domain contains components (e.g., network nodes ) that are
linked to the same synchronized time base. There can be several global time

71
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Aspects of Supported Bus Communication

domains in a bus network. In general, global time domains can be distinguished

by domain identifiers as follows:
§ Global time domains that use different synchronized time bases have different
domain identifiers.
§ Global time domains that use the same synchronized time base have the same
domain identifier.

Global time domains that use the same synchronized time base are connected
by the means of subdomains. A subdomain denotes which components are
linked to the related time base. Each subdomain is limited to exactly one
communication cluster . A global time domain can declare several other global
time domains as its subdomains.

The following illustration is an example for the distribution of a global time in

a bus network with four communication clusters and five global time domains.
GTD_S10 and GTD_S20 are subdomains of GTD_1. GTD_S11 and GTD_S21 are
subdomains of GTD_S10 and GTD_S20, respectively. All global time domains use
the same domain identifier.

GTD_1
ECU1

ECU2 CAN ECU6

Ethernet

ECU3 ECU7
GTD_S10

ECU4 CAN ECU8

GTD_S20

ECU5 ECU9 CAN

GTD_S11

ECU10
GTD_S21

Global time master Time master Time slave

Depending on its role in the network, an ECU can be a time master and/or a
time slave.

Time masters, time slaves, and Global time synchronization is based on a master-slave system. An ECU can
time gateways be both master and slave at the same time. Additionally, if synchronized times
are processed via multiple communication clusters, an ECU can act as a time
gateway. To distinguish between the different roles, the following terms are
used:

Role Description ECUs in the Previous

Illustration
Time master An entity that is the master for a certain time base and distributes this time base to a set ECU3 (only for
of time slaves within a certain cluster of a bus network. GTD_S11), ECU8 (only
for GTD_S21)

72
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Aspects of Supported AUTOSAR Features

Role Description ECUs in the Previous

Illustration
Global time A time master that is also the global owner and origin of the time base. ECU1
master
Time slave An entity that is the recipient of a certain time base within a cluster of a bus network. e.g., ECU2, ECU3 (only
Each time slave has its own time base instance, i.e., a local instance of the time. for GTD_S10), ECU4,
Whenever a time slave receives a new time from the time master, the time slave ECU7, ECU8 (only for
interpolates the time until the next synchronization with the time master. GTD_S20)
Time A time base instance that receives the synchronized time as a time slave from a time ECU3, ECU8
gateway master on one cluster and then forwards it to another cluster as a time master. A time
gateway typically consists of one time slave and one or more time masters.

Time synchronization The messages that distribute the time information are called time
messages synchronization messages.

With time synchronization over CAN, each time synchronization message

consists of two messages that are transmitted separately: a synchronization
(SYNC) message and a follow‑up (FUP) message. The latter completes the
synchronization process. SYNC and FUP messages are transmitted using the
same CAN identifier.

SYNC and FUP messages are identified by their message type, and their message
layout depends on whether they are CRC-secured:

CRC-Secured Message Layout

CRC-secured E2E sequence
counter
SYNC:
Message CRC Time User byte 0 Seconds
type domain

8 bits 8 bits 4 bits 4 bits 8 bits 32 bits

Byte 0 Byte 1 Byte 2 Byte 3 Byte 4 ... Byte 7
MSB LSB

E2E sequence Overflow of

counter SGW (1 bit) seconds (2 bits)
FUP:
Message CRC Time Reserved Nanoseconds
type domain

8 bits 8 bits 4 bits 4 bits 5 bits 32 bits

Byte 0 Byte 1 Byte 2 Byte 3 Byte 4 ... Byte 7

MSB LSB

§ SYNC message type: 0x20

§ FUP message type: 0x28

73
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Aspects of Supported Bus Communication

CRC-Secured Message Layout

Not secured E2E sequence
counter
SYNC:
Message User byte 1 Time User byte 0 Seconds
type domain

8 bits 8 bits 4 bits 4 bits 8 bits 32 bits

Byte 0 Byte 1 Byte 2 Byte 3 Byte 4 ... Byte 7

MSB LSB

E2E sequence Overflow of

counter SGW (1 bit) seconds (2 bits)
FUP:
Message User byte 2 Time Reserved Nanoseconds
type domain

8 bits 8 bits 4 bits 4 bits 5 bits 32 bits

Byte 0 Byte 1 Byte 2 Byte 3 Byte 4 ... Byte 7

MSB LSB

§ SYNC message type: 0x10

§ FUP message type: 0x18

Implementing global time Depending on your use scenario, there are different ways for implementing
synchronization in executable global time synchronization in executable applications . Refer to Basics
applications on Implementing Global Time Synchronization in Executable Applications on
page 181.

Limitations For global time synchronization, some limitations apply. Refer to Limitations for
Communication Matrices and Communication Standards on page 519.

Aspects of Partial Networking

Introduction The Bus Manager supports partial networking according to AUTOSAR 4.3. Partial
networking lets you reduce the power consumption, e.g., in a vehicle, by
deactivating specific bus communication interfaces in ECUs .

ISignal IPDU groups and The bus communication interfaces of an ECU are deactivated at function level:
partial network clusters For this purpose, the ECU communication can be structured in ISignal IPDU
groups. ISignal IPDU groups can be used to group PDUs with specific functions,
e.g., PDUs that control the seat settings. PDUs can be included in one or more
ISignal IPDU groups. The ISignal IPDU groups can be assigned to one or more
partial network clusters. A partial network cluster can be restricted to only one
communication cluster or can span over several communication clusters. Each

74
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Aspects of Supported AUTOSAR Features

partial network cluster can explicitly be enabled or disabled, which activates or

deactivates all of the assigned ISignal IPDU groups and their included PDUs.

The following illustration is an example of three ECUs whose communication

is structured in ISignal IPDU groups and assigned to different partial network
clusters, which are named PNC 01, PNC 02, and PNC 03.

ECU 1 ECU 2 ECU 3

ISignal IPDU group: Group 1 ISignal IPDU group: Group 1 ISignal IPDU group: Group 1
TX PDU A RX PDU A RX PDU A
TX PDU B RX PDU B RX PDU C
TX PDU C
ISignal IPDU group: Group 2 ISignal IPDU group: Group 2
ISignal IPDU group: Group 2 RX PDU A RX PDU A
TX PDU A RX PDU D RX PDU D
TX PDU D
ISignal IPDU group: Group 3 ISignal IPDU group: Group 3
TX PDU X RX PDU X
TX PDU Y RX PDU Y

PNC 01
PNC 02
PNC 03

PNC 01 PNC 02 PNC 03

ECU 1, ECU 2, ECU 3: Group 1 ECU 1, ECU 2, ECU 3: Group 1 ECU 2, ECU 3: Group 3
ECU 1, ECU 2, ECU 3: Group 2

Restrictions for partial According to AUTOSAR 4.3, the following restrictions apply concerning partial
networking according to networking:
AUTOSAR § Partial networking is supported for CAN communication clusters but not for
LIN communication clusters.
§ ISignal IPDU groups can contain only other ISignal IPDU groups, ISignal IPDUs,
or NMPDUs containing ISignals. Other PDU types such as container IPDUs or
secured IPDUs cannot be included in ISignal IPDU groups.

Implementing partial To implement partial networking in executable applications , the

networking in executable communication matrix must specify partial networking settings and you have
applications to use blocks from the AUTOSAR Network Management Solution. Refer to
Implementing Partial Networking in Executable Applications on page 146.

Limitations For partial networking, some limitations apply. Refer to Limitations for
Communication Matrices and Communication Standards on page 519.

75
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Aspects of Supported Bus Communication

Aspects of PDU Gateways

Introduction The Bus Manager supports PDU gateways according to AUTOSAR. With PDU
gateways, an ECU can route the data of PDUs from one or more
communication clusters to other communication clusters.

Source PDUs and target PDUs An ECU that acts as a gateway ECU specifies PDU gateways via IPDU mappings.
for PDU gateways Each IPDU mapping unambiguously maps one source PDU to one target PDU.
However, multiple IPDU mappings can be used to map the same source PDU
to multiple target PDUs (multicast PDU routing) and vice versa (multisource PDU
routing).

Source PDUs are always RX PDUs, target PDUs are always TX PDUs. When a
gateway ECU receives a source PDU on a communication cluster, it transfers the
PDU data to the related target PDUs and transmits these PDUs on one or more
communication clusters, as shown in the following example.

Gateway ECU
receive
Body CAN Source PDU (RX) Source PDU (RX)

transfer data

Target PDU 1 (TX) transmit

Comfort CAN

transmit
Comfort LIN Target PDU 2 (TX)

To use PDU gateways, you have to enable the PDU gateway support for
bus configurations. Refer to Simulating PDU Gateways (Preview Version) on
page 148.

Limitations For PDU gateways, some limitations apply. Refer to Limitations for PDU gateways
on page 524.

76
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Aspects of Supported CAN Bus Features

Aspects of Supported CAN Bus Features

Where to go from here Information in this section

Aspects of Miscellaneous Supported CAN Bus Features........................... 77

Aspects of the J1939 Protocol................................................................. 80

Aspects of Miscellaneous Supported CAN Bus Features

Identifier format The Bus Manager supports frames with the standard (11‑bit) and extended
(29‑bit) identifier format.

The identifier contains address information. It does not address individual bus
members, but refers to the information the frame contains. As a result, a frame
can be received by any number of bus members. Each bus member can filter out
frames of interest. The identifier must be defined for each CAN frame.

For each CAN frame, you can change the specified identifier format and specify a
user-defined identifier value.

CAN FD protocol The Bus Manager supports the CAN FD protocol. CAN FD stands for CAN with
Flexible Data Rate. Compared with the classic CAN protocol, CAN FD comes with
an increased bandwidth for serial communication. The improvement is based on
two factors:

Factor Description
Longer The data fields (payload length) of CAN FD frames can be up to 64 bytes long (classic CAN: 8 bytes). Valid CAN FD
payload payload lengths are: 0 … 8, 12, 16, 20, 24, 32, 48, and 64 bytes.
length If a CAN FD frame has an invalid payload length, the Bus Manager adds padding bytes to the frame and extends the
payload length to the next higher valid length. For example, to a payload length of 14 bytes, the Bus Manager adds
2 padding bytes.
In general, the value of each padding byte is 255. Only for the following PDU types, different values are used:
§ Container IPDUs with a dynamic container layout: The value of each padding byte is set to the value that is specified
for the unused bit pattern of the container IPDU. Only if no unused bit pattern is specified, 255 is used as the
padding value.
For more information, refer to Aspects of Container IPDUs and Contained IPDUs on page 64.
§ J1939‑22‑compliant IPDUs:
§ Multi‑PG protocol: The value of the first three padding bytes that are added is 0, the value of all subsequent
added padding bytes is 170 (0xAA).
§ Broadcast Announce Message protocol: The value of each padding byte is 170 (0xAA).
For more information, refer to Aspects of the J1939 Protocol on page 80.

77
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Aspects of Supported Bus Communication

Factor Description
Higher bit CAN frames consist of an arbitration phase and a data phase. The data phase spans the phase in which the data
rate for fields, CRC, and length information are transferred. The data phase of CAN FD frames can be transmitted with an
the data optional higher bit rate (e.g., higher by a factor of 8).
phase
Arbitration Arbitration
phase Data phase phase

Currently, there are two CAN FD protocols on the market which are not
compatible with each other.
§ The non‑ISO CAN FD protocol is the original CAN FD protocol from Bosch.
§ The ISO CAN FD protocol is the CAN FD protocol according to
ISO 11898‑1:2015.
The ISO CAN FD protocol comes with an improved failure detection capability.

The Bus Manager supports both CAN FD protocols and lets you use classic CAN
frames and CAN FD frames in parallel. For CAN FD frames, you can define a
separate bit rate for the data phase.

J1939 protocol The Bus Manager supports the J1939 protocol. For more information, refer to
Aspects of the J1939 Protocol on page 80.

Multiplexed IPDUs The Bus Manager supports CAN multiplexed IPDUs. For more information, refer
to Aspects of Multiplexed IPDUs on page 63.

Event‑controlled timings The Bus Manager supports event‑controlled timings, which let ISignals trigger the
transmission of the PDUs in which they are included. The Bus Manager supports
event‑controlled timings according to AUTOSAR. For more information, refer to
Aspects of Event‑Controlled Timings on page 70.

Tip

In case of DBC communication matrices, the Bus

Manager derives the settings of event‑controlled timings
from the GenMsgCycleTimeFast, GenMsgNrOfRepetition,
GenMsgNrOfRepetitions, and GenSigSendType attributes.

Extended signal multiplexing The Bus Manager supports extended signal multiplexing. Extended signal
multiplexing is possible only for bus communication that is specified in DBC files.

In general, the value of a multiplexer signal can determine that a multiplexed

signal is included in an IPDU. With extended signal multiplexing, a multiplexed
signal itself can serve as a multiplexer signal, i.e., its value can determine other
multiplexed signals to be included in the IPDU. The value that determines a
specific multiplexed signal to be included in an IPDU is called multiplexer value. A
multiplexed signal can be included in an IPDU due to one or more values and/or

78
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Aspects of Supported CAN Bus Features

value ranges of the multiplexer value. However, a multiplexed signal is included

in an IPDU only if the related multiplexer signal is also included in the IPDU.

In the Bus Manager, the multiplexer signals and multiplexed signals that are used
for extended signal multiplexing are included in extended multiplexed IPDUs.

The following illustration is an example of a multiplexer signal (MuxSignal1) and

multiplexed signals, where MuxedSignal1.1 serves as a multiplexer signal itself.
The signals that are included in the extended multiplexed IPDU depend on the
multiplexer values (MuxValue) of MuxSignal1 and MuxedSignal1.1.

MuxSignal1

MuxValue = 1 ... 3
MuxedSignal1.1

MuxValue = 5
MuxedSignal2.1

MuxValue = 5
MuxedSignal2.2

MuxValue = 6
MuxedSignal2.3

MuxValue = 4
MuxedSignal2.4
Payload of extended multiplexed IPDU:

MuxSignal1 MuxedSignal1.1
Case 1: MuxedSignal2.1 MuxedSignal2.2
MuxValue = 1 MuxValue = 5

MuxSignal1 MuxedSignal1.1
Case 2: MuxedSignal2.3
MuxValue = 2 MuxValue = 6

Case 3: MuxSignal1
MuxedSignal2.4
MuxValue = 4

If a multiplexed signal is not included in the extended multiplexed IPDU and this
results in unused bits, these bits are filled with a default unused bit pattern,
which is 255 for J1939‑compliant IPDUs and 0 for all other PDUs. If required,
you can modify the communication matrix in the ConfigurationDesk application
to specify a user-defined unused bit pattern. Refer to Basics on Modifying
Communication Matrices on page 391.

Limitations When you work with a CAN bus system, some limitations apply. Refer to
Limitations for CAN Communication on page 525.

Related topics Basics

Aspects of Supported AUTOSAR Features................................................................................. 63

79
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Aspects of Supported Bus Communication

Aspects of the J1939 Protocol

Introduction The Bus Manager supports the J1939 protocol as specified by the Society of
Automotive Engineers (SAE) J1939 standard.

The J1939 protocol is used, for example, for the communication in heavy-duty
vehicles, such as between a tractor and its trailer. It allows peer‑to‑peer and
broadcast communication, and supports large messages. The maximum message
size depends on whether the J1939‑21 or J1939‑22 protocol is used.

In the Bus Manager, J1939 messages are represented by J1939‑compliant

IPDUs , for example, by J1939‑compliant ISignal IPDUs or multiplexed
IPDUs .

J1939‑21 and J1939‑22 The characteristics of J1939‑compliant bus communication depend on whether
the J1939‑21 or J1939‑22 protocol is used, as shown in the following table.

Characteristics J1939‑21 J1939‑22

First SAE release July 1994 March 2021
CAN protocol Standard CAN CAN FD
Maximum baud rate 500 kBd 2 MBd
(speed)
Payload length of 0 … 1,785 bytes § Broadcast: 0 … 15,300 bytes plus 52 bytes of optional
IPDUs assurance data
§ Peer‑to‑peer: 0 … 16,777,215 bytes plus 52 bytes of
optional assurance data
Transmission of Depends on the payload length: Depends on the payload length:
IPDUs § 0 … 8 bytes: An IPDU can be directly § 0 … 60 bytes: An IPDU can be directly transmitted on
transmitted on the bus, i.e., as a J1939 direct the bus, i.e., as a J1939 contained parameter group
IPDU (C‑PG)
§ 9 … 1,785 bytes: An IPDU is segmented § 61 … 15,300/16,777,215 bytes: An IPDU is
into multiple packets that are separately segmented into multiple packets that are separately
transmitted on the bus. transmitted on the bus.
Transport protocols § Required only for segmenting IPDUs into § Required for directly and segmented transmitted
multiple packets and transmitting the packets IPDUs.
on the bus. § Applicable transport protocols:
§ Applicable transport protocols: § Direct transmission: Multi‑PG protocol, refer to
§ Broadcast: Broadcast Announce Message Transmitting IPDUs using the Multi‑PG protocol on
(BAM) protocol, refer to Transmitting IPDUs page 84
using the Broadcast Announce Message § Broadcast segmented transmission: Broadcast
(BAM) protocol on page 85 Announce Message (BAM) protocol, refer to
§ Peer‑to‑peer: Connection Mode Data Transmitting IPDUs using the Broadcast Announce
Transfer (CMDT) protocol, refer to Message (BAM) protocol on page 85
Transmitting IPDUs using the Connection § Peer‑to‑peer segmented transmission: Connection
Mode Data Transfer (CMDT) protocol on Mode Data Transfer (CMDT) protocol
page 86
CAN identifier and Extended (29‑bit) identifier format, i.e., PDU 1 § Extended (29‑bit) identifier format, i.e., PDU 1 format
PDU format format and PDU 2 format. Refer to Extended and PDU 2 format. Refer to Extended CAN identifier
CAN identifier on page 81. on page 81.
§ Standard (11‑bit) identifier format, i.e., PDU 3 format

80
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Aspects of Supported CAN Bus Features

For J1939‑22, the Bus Manager neither supports the CMDT protocol nor the
standard identifier format.

In contrast to the specifications of the J1939‑22 protocol, the Bus Manager

supports J1939‑21-compliant and J1939‑22-compliant communication in the
same communication cluster. However, for each J1939 transport protocol
connection, only one protocol type is supported, i.e., the communication must
comply either with J1939‑21 or J1939‑22.

Tip

§ When you select a J1939‑compliant IPDU, the Bus Communication

page of the Properties Browser displays the J1939 transport protocol
connection ( ) and its properties.
§ For DBC communication matrices, the Bus Manager derives the
J1939 transport protocol connections from the [priority, source
address, destination address] tuple.

Extended CAN identifier The J1939‑21 and J1939‑22 protocols support the 29-bit extended CAN
identifier. The identifier is segmented as follows:

Priority Parameter group number (PGN) Source address

28 26 25 8 7 0
29-bit extended CAN identifier

Segment Description
Priority The priority of the IPDU. A value of 0 represents the highest priority,
a value of 7 represents the lowest priority.
Parameter group A unique number that unambiguously references a parameter group,
number (PGN) i.e., the content of the IPDU. The PGN itself consists of four
segments.
Source address The transport protocol address of the network node that transmits
the IPDU.

The Bus Manager lets you access the priority of J1939‑21‑compliant IPDUs at run
time. Refer to Accessing the Priority of J1939-Compliant IPDUs on page 263.

Parameter group number (PGN), parameter groups, and

parameters The parameter group number (PGN) is an 18-bit number that
unambiguously references a parameter group. A parameter group is a group of
parameters that are included in the data field of an IPDU. For example, an engine
temperature parameter group can group parameters that provide the coolant
temperature, oil temperature, etc. Each parameter is unambiguously identified
by its suspect parameter number (SPN). The J1939 standard defines PGNs, the
referenced parameter groups, and the grouped parameters.

81
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Aspects of Supported Bus Communication

The PGN uses the bits 25 … 8 of the CAN identifier, which are segmented as
follows:
Extended data page (EDP)
Data page (DP)

PDU format (PDU-F) PDU specific (PDU-S)

PDU 1: 0...239 PDU 1: Destination address
PDU 2: 240...255 PDU 2: Group extension
25 24 23 16 15 8

Parameter group number (PGN)

Segment Description
Extended data Reserved for future use according to the J1939 standard.
page (EDP) Regardless of whether the EDP of an IPDU is set to 0 or 1, the Bus Manager handles the IPDU as
J1939‑compliant.
Data page (DP) Specifies the used data page (data page 0 or data page 1). The data pages are used to expand the PGN value
range.
PDU format Specifies the PDU format. Either PDU 1 or PDU 2.
(PDU‑F) § PDU 1:
§ PDU‑F value: 0 … 239 (0x00 … 0xEF)
§ Communication mode: Depends on the specified PDU‑S value (destination address):
§ 0 … 253: Peer‑to‑peer communication, i.e., the IPDU is transmitted to a specific destination network
node.
§ 255: Broadcast communication, i.e., the IPDU is transmitted to all network nodes in the communication
cluster.
§ PDU 2:
§ PDU‑F value: 240 … 255 (0xF0 … 0xFF)
§ Communication mode: Broadcast, i.e., the IPDU is transmitted to all network nodes in the communication
cluster.
PDU specific The usage depends on the specified PDU format:
(PDU‑S) § PDU 1:
Provides the transport protocol address of the destination.
§ PDU 2:
Provides the group extension. The group extension is used to increase the number of IPDUs that can be
broadcast in the communication cluster.

J1939 name and transport Each network node that participates in J1939 communication can be
protocol address identified by its J1939 name and its transport protocol address. Regarding the
J1939 name and transport protocol address, the following terms are used to
address a network node:

Node Name Description

J1939 Provides the J1939 name.
network The J1939 name is a 64‑bit value that unambiguously identifies each J1939 network node worldwide. Therefore,
management the J1939 name value must be unique worldwide. The J1939 name indicates the main function of the network
node (J1939 node and provides information on the manufacturer. For this purpose, the 64 bits are segmented as follows:
NM node)

82
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Aspects of Supported CAN Bus Features

Node Name Description

Arbitrary Industry Vehicle Vehicle Reserved Function Function ECU Manufacturer Identity
Address Group System System Instance Instance Code Number
Capable Instance

1 bit 3 bit 4 bit 7 bit 1 bit 8 bit 5 bit 3 bit 11 bit 21 bit

J1939 Provides the transport protocol address.

transport The transport protocol address is an 8‑bit value that specifies the source or destination of a J1939‑compliant IPDU
protocol in the communication cluster. For this purpose, the value must be unique in the communication cluster. If there
node (J1939 is an address conflict, the network node can dynamically claim an address to ensure unique addresses, if this is
TP node) enabled for the network node.
According to the J1939 standard, the following addresses are reserved:
§ Null address:
§ Address value: 254 (0xFE)
§ Used as the source address by network nodes that have not yet claimed an address or have failed to claim an
address.
§ Global address:
§ Address value: 255 (0xFF)
§ Used as a destination address that addresses all network nodes in a communication cluster, e.g., to broadcast
IPDUs of PDU 1 format or for address claims.

If a network node participates in J1939 communication but is not available in

the communication matrix, the Bus Manager generates a suitable ECU during
the import of the communication matrix. Refer to Generating missing ECUs on
page 95.

Address claiming The J1939 standard defines an address claiming procedure in which transport
protocol addresses are assigned to network nodes during communication cluster
initialization. This procedure ensures that each address is unique.

Each network node can send an address claim to the CAN bus. The nodes that
receive an address claim verify the claimed address. If there is an address conflict,
the network node with the lowest 64‑bit name value (i.e., the highest priority)
gets the claimed address. The other network nodes must either claim different
addresses or stop the communication. However, the arbitrary address
capable parameter of a network node's J1939 name determines whether the
node can claim a different address:
§ Arbitrary address capable set to 1: The network node can claim a
different address.
§ Arbitrary address capable set to 0: The network node cannot claim a
different address. In this case, it sends a cannot claim address message on the
bus and stops its J1939 communication.

The Bus Manager supports the address claiming procedure as follows:

§ The Bus Manager supports the address claiming procedure only for J1939‑21,
not for J1939‑22.
§ A J1939‑21‑compliant network node that is simulated by the Bus Manager can
participate in the address claiming procedure only if you enable J1939 network
management for the network node. Refer to Enabling and Disabling J1939
Network Management on page 310.

83
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Aspects of Supported Bus Communication

§ For PDUs that are inspected or manipulated by the Bus Manager, the source
and/or destination addresses are adjusted at run time if the related network
nodes have claimed a new transport protocol address.

Transmitting IPDUs using the To transmit and receive J1939‑22‑compliant IPDUs with up to 60 bytes payload,
Multi‑PG protocol the Multi‑PG protocol is used. The Multi‑PG protocol includes each IPDU in a
single Multi‑PG‑compliant CAN FD frame, i.e., the PDU is not segmented.

Contained parameter group (C‑PG) An IPDU that is included in a CAN FD

frame using the Multi‑PG protocol is called contained parameter group (C‑PG). In
general, a C‑PG can have a payload length of up to 60 bytes plus a header of
4 bytes. The header is segmented as follows:

Type of Trailer Contained parameter group number (CPGN) Payload length (PL)
service (TOS) format (TF)
3 bits 3 bits 18 bits 8 bits

Segment Description
Type of service Specifies the structure and the type of the content of the C‑PG:
(TOS) § 0: C‑PG used for padding unused bytes of the CAN FD frame to a valid CAN FD length. In this case, the
layout of the C‑PG is the following:
§ The header consists of maximum 3 bytes, the payload length (PL) segment is not available. Depending on
the required number of padding bytes, the header can also be shorter.
§ The maximum total length, i.e., header and payload, is limited to 15 bytes.
For more information on padding the CAN FD frame, refer to CAN FD frames according to the Multi‑PG
protocol on page 84.
§ 1: C‑PG with manufacturer‑specific assurance data.
§ 2: C‑PG with optional assurance data specified by SAE.
§ 3 … 7: Reserved for future use according to the J1939 standard.
Trailer format Required to specify the type of the assurance data that is used with the C‑PG. However, to specify the specific
(TF) assurance data type, the [TOS, TF] tuple is required. For example, the tuple [TOS = 2, TF = 0] specifies a
C‑PG without any assurance data.
Contained Specifies the parameter group number (PGN) of the C‑PG. In contrast to the PGN that is specified in the
parameter group extended CAN identifier, the CPGN does not specify the destination address because this is specified for the
number (CPGN) used CAN FD frame.
Payload length Specifies the number of bytes that are used for the payload of the C‑PG.
(PL)

For each C‑PG, the Bus Manager lets you specify the following:
§ You can specify the collection semantics, i.e., whether several instances of the
C‑PG can be included in the frame or only one instance.
§ You can specify whether the C‑PG can trigger the transmission of the
related frame. Moreover, you can specify a timeout value for triggering the
transmission.
§ You can specify the type of service (TOS) and the trailer format (TF).
For more information, refer to Configurable Settings of PDUs on page 414.

CAN FD frames according to the Multi‑PG protocol According to the

Multi‑PG protocol, a CAN FD frame can contain multiple IPDUs, i.e., multiple
contained parameter groups (C‑PG). The total length (i.e., payload and header)
of all C‑PGs that are included in the same CAN FD frame must not exceed
64 bytes.

84
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Aspects of Supported CAN Bus Features

In addition to the contained C‑PGs, the CAN FD frame contains the CAN
identifier. According to the Multi‑PG protocol, CAN FD frames with extended
identifier are always of PDU 1 format, i.e., their communication mode can be
peer‑to‑peer or broadcast. Refer to Extended CAN identifier on page 81.
If the payload length of the frame is invalid according to CAN FD, the length is
extended by padding bytes to the next higher valid length. For this purpose, a
C‑PG with TOS set to 0 is used. The total length of this C‑PG is determined by
the number of bytes that must be added to reach the valid length. The value of
the first three bytes of this C‑PG is always 0, the value of all following bytes is
170 (0xAA).

Transmitting IPDUs using the To broadcast J1939‑compliant IPDUs with more than 8 bytes payload (J1939‑21)
Broadcast Announce Message or 60 bytes payload (J1939‑22) to any network node in the communication
(BAM) protocol cluster, the Broadcast Announce Message (BAM) protocol is used. This protocol
has the following characteristics:

Characteristics Description
Communication Broadcast
mode
Parallel transmission J1939‑21: No J1939‑22: Yes
Each sending network node can transmit only Each sending network node can transmit up to four
one IPDU at a time by using the BAM protocol. IPDUs at a time by using the BAM protocol, i.e., there
can be up to four transfer sessions in parallel.
Acknowledgement The transfer is not acknowledged: The sending network node does not know which network node receives
the IPDU and the receiving network node cannot influence the transfer.
Maximum IPDU J1939‑21: 1,785 bytes J1939‑22: 15,300 bytes plus 52 bytes of optional
length assurance data
IPDU segmentation The data of an IPDU is segmented into multiple packets (data transfer (DT) messages), which are
transmitted on the bus.
Maximum number of Depending on the payload length, each IPDU can be segmented into up to 255 packets.
packets
Data field of each J1939‑21: J1939‑22:
packet § 8 bytes § Up to 64 bytes:
§ The first byte is reserved for the sequence § Except for the last packet, the data field of each
number of the packet, i.e., only 7 bytes of packet is 64 bytes long.
the data field are used for the IPDU data. § Depending on the payload length of the IPDU, the
§ Only for the last packet: Data bytes that are data field of the last packet might be shorter.
not used by the IPDU data are filled with 255 § The first four bytes are reserved. They contain
(0xFF). information such as the transfer session number of
the IPDU and the sequence number of the packet.
Therefore, only 60 bytes of the data field are used for
the IPDU data.
§ Only for the last packet: If the actual length of the
data field results in an invalid CAN FD length of the
related frame, the data field is extended by padding
bytes to reach the next valid CAN FD length of the
frame. The padding bytes are filled with 170 (0xAA).

85
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Aspects of Supported Bus Communication

Characteristics Description
Transmission The sending network node first sends a broadcast announce message (BAM). The BAM allows all receiving
sequence network nodes to prepare for reception. The data field of the BAM contains the following information:
§ The parameter group number (PGN) of the IPDU.
§ The number of data bytes of the IPDU.
§ The number of packets that are used to transmit the data bytes of the IPDU on the bus.
After sending the broadcast announce message, the sending network node starts the actual data transfer,
i.e., it transmits the packets on the bus.
Only J1939‑22:
§ After the last packet is transmitted, a J1939‑22‑compliant sending network node sends an
end‑of‑message status (EOMS). The EOMS indicates the end of the current data transfer and can
additionally contain assurance data.
§ If the sending network node cancels the transmission of packets before the last packet is transmitted, it
sends a connection‑abort message. In this case, all receiving network nodes discard the already received
packets.
Transfer duration J1939‑21: J1939‑22:
§ Depends on the number of packets and the § Depends on the number of packets and the time gap
time gap before each packet. before each packet.
§ 255 packets (IPDU payload length of § 255 packets (IPDU payload length of 15,300 bytes):
1,785 bytes): § Min. duration: 2.57 seconds (time gap of 10 ms)
§ Min. duration: 12.8 seconds (time gap of § Max. duration: 51.4 seconds (time gap of 200 ms)
50 ms)
§ Max. duration: 51.2 seconds (time gap of
200 ms)

For each J1939‑22‑compliant IPDU, you can specify the assurance data type, if
any. Moreover, you can specify the assurance data size. Refer to Configurable
Settings of PDUs on page 414.

Transmitting IPDUs using To transmit J1939‑21‑compliant IPDUs with more than 8 bytes payload to
the Connection Mode Data a specific destination, the Connection Mode Data Transfer (CMDT) protocol
Transfer (CMDT) protocol is used. For J1939‑21‑compliant IPDUs, this protocol has the following
characteristics:

Characteristics Description
Communication mode Peer‑to‑peer
Parallel transmission No. To a specific receiving network node, each sending network node can transmit only one IPDU at
a time by using the CMDT protocol.
Acknowledgement and § The transfer is acknowledged: The sending network knows whether the receiving network node
interaction has received the PDU.
§ The receiving network node can request individual packets again.
§ The sending and the receiving network node can cancel the transmission of an IPDU at any time.
Maximum PDU length 1,785 bytes
PDU segmentation The data of an IPDU is segmented into multiple packets (data transfer (DT) messages), which are
transmitted on the bus.
Maximum number of Depending on the payload length, each IPDU can be segmented into up to 255 packets.
packets
Data field of each packet § 8 bytes
§ The first byte is reserved for the sequence number of the packet, i.e., only 7 bytes of the data field
are used for the IPDU data.

86
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Aspects of Supported CAN Bus Features

Characteristics Description
Transmission sequence The sending network node first sends a request‑to‑send (RTS) message. The receiving network node
responds with either a clear‑to‑send (CTS) or a connection‑abort message if the connection cannot
be established. When the sending network node receives the CTS, it starts the actual data transfer.
The data transfer might be segmented, i.e., the receiving network sends further CTS to request data
packets. After the receiving network node has successfully received the complete data, it sends an
end‑of‑message acknowledgment (EOM).

Limitations For the support of the J1939 protocol, some limitations apply. Refer to
Limitations for J1939 on page 526.

87
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Aspects of Supported Bus Communication

Aspects of Supported LIN Bus Features

Aspects of Miscellaneous Supported LIN Bus Features

LIN specifications The Bus Manager lets you work with LIN communication that complies with the
following LIN specifications and SAE standards:
§ LIN specification 1.3
§ LIN specifications 2.0, 2.1, and 2.2
§ SAE J2602 standard (protocol version: J2602_1_1.0, language version:
J2602_3_1.0)
SAE J2602 is a vehicle LIN bus standard based on LIN 2.0 and defined by the
Society of Automotive Engineers (SAE).

Frame types The Bus Manager supports the following frame types:
§ Unconditional frames
An unconditional frame is a standard LIN frame. The frame header sent by the
LIN master is explicitly assigned to one frame response of a LIN node.
§ Event-triggered frames
An event-triggered frame consists of a frame header that is assigned to several
frame responses of different LIN nodes. A frame response is sent only if its
data changed since its last transmission. This allows frame transmission of
different LIN nodes via the same frame slot. If more than one LIN node tries to
send a frame response, a collision occurs. Collisions have to be resolved by the
LIN master (e.g., via collision resolver schedules).
§ Sporadic frames
A sporadic frame references a list of frames. The position of a frame in the
list determines the frame's priority. When a sporadic frame is scheduled, the
referenced list is checked for frames containing at least one changed signal.
The frame that contains a changed signal and has the highest priority is
transmitted.
§ Diagnostic frames
A diagnostic frame has eight data bytes and is either a master request frame
(ID 60) or a slave response frame (ID 61). Diagnostic frames are used for slave
node configuration and identification or for implementing diagnostic data
transfer between a LIN master and LIN slaves.

Checksum types The Bus Manager supports LIN frames with classic and enhanced checksum
calculation types.

With the classic checksum calculation type, only the data bytes of a LIN frame are
used to calculate the checksum. With the enhanced checksum calculation type,
the data bytes and the protected identifier (PID) byte are used to calculate the
checksum.

88
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Aspects of Supported LIN Bus Features

LIN masters and slaves The Bus Manager supports the simulation of LIN masters and LIN slaves .
Simulating a LIN master supports the following LIN master tasks at run time:
§ Send frame headers according to a schedule table that is defined in the
communication matrix.
§ Specify an initial schedule table that is started automatically after the
executable application was started, and change the active schedule table
during run time. For details, refer to Working with LIN Schedule Tables on
page 307.
§ Configure LIN slave nodes by transmitting master request frames with the
following configuration commands:
§ AssignNAD
§ AssignFrameId
§ UnassignFrameId
§ AssignFrameIdRange
§ ConditionalChangeNAD
§ FreeFormat
§ SaveConfiguration
§ DataDump
To transmit the master request frames, they must be elements of the
active schedule table. The configuration commands including their required
parameters must be specified in the communication matrix and cannot be
changed by the Bus Manager.
§ Resolve collisions of event-triggered frames by automatically executing a
related collision resolver schedule table. The collision resolver tables must be
specified in the communication matrix for each event-triggered frame.

Limitations When you work with a LIN bus system, some limitations apply. Refer to
Limitations for LIN Communication on page 528.

89
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Aspects of Supported Bus Communication

90
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Basics on the Bus Manager

Basics on the Bus Manager

Where to go from here Information in this section

Working with Communication Matrices................................................... 92

Basics on Bus Configurations................................................................. 100

Bus Configuration Tables....................................................................... 103

Bus Configuration Function Block.......................................................... 109

Assigning Communication Matrix Elements to Bus Configurations......... 112

Removing Communication Matrix Elements from Bus

Configurations...................................................................................... 120

Creating Restbus Configurations........................................................... 121

Specifying the Behavior for Assigning Communication Matrix

Elements and Adding Bus Configuration Features (Preview
Version)................................................................................................. 125

Copying, Cutting, and Pasting Bus Configuration Elements................... 131

Using Event‑Controlled Timings for Transmitting PDUs........................... 136

Triggering the Transmission of Multiplexed IPDUs................................... 137

Working with User Code....................................................................... 139

Implementing Secure Onboard Communication in Executable

Applications.......................................................................................... 143

Implementing Partial Networking in Executable Applications.................. 146

Simulating PDU Gateways (Preview Version).......................................... 148

Accessing Bus Manager Features via the ConfigurationDesk

Automation Interface............................................................................ 152

91
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Basics on the Bus Manager

Working with Communication Matrices

Basics on communication Communication matrices define the communication of bus systems according to
matrices various standards. The design and file format of a communication matrix depend
on the standard that is used to define the bus communication. Depending on
the standard, communication matrices can be generated by various commercial
off-the-shelf tools, by user-specific tools (e.g., OEM-specific database export tool)
or other methods.

For an example of bus communication defined in a communication matrix, refer

to Introduction to Bus Communication Defined in Communication Matrices on
page 23.

Tip

If you do not have a communication matrix, you can use the

Basic_ComMatrix.arxml communication matrix as a starting point to set
up CAN communication. However, to use the communication matrix, you
have to modify it. For more information, refer to Modifying Communication
Matrices on page 391.

Supported file formats and The Bus Manager supports the following communication matrix file formats:
versions

File Format Description

AUTOSAR AUTOSAR (AUTomotive Open System ARchitecture) is an industry partnership that aims to develop and establish
system an open standard for automotive electrics/electronics (E/E) architectures.
description file AUTOSAR system description files are files of AUTOSAR XML type (ARXML files) that describe a system
according to AUTOSAR. A system is a combination of a hardware topology, a software architecture, network
communication, and information on the mappings between these elements. AUTOSAR system description files
are instances of the AUTOSAR System Template. An AUTOSAR system description file usually describes more than
one bus system (e.g., CAN and LIN).
The Bus Manager supports AUTOSAR system description files based on the following AUTOSAR Releases:
§ AUTOSAR Classic Platform Release 3.2.1, 4.0.3, 4.2.1, 4.2.2, 4.3.0, 4.3.1, and 4.4.0
§ AUTOSAR Classic Platform Release R19-11, R20-11, R21-11, and R22-11
FIBEX file The Field Bus Exchange (FIBEX) format is an XML exchange file format. It is used for data exchange between
different tools that work with message-oriented bus communication. A FIBEX file usually describes more than one
bus system.
The Bus Manager supports FIBEX files based on FIBEX 3.1.0, 4.1.1, and 4.1.2.
DBC file The Data Base Container (DBC) file format was primarily developed to describe a CAN bus system but it can
also describe a LIN bus system. However, a DBC file can describe the communication of only one communication
cluster .
The Bus Manager does not support DBC files that describe a LIN bus system. For more information, refer to
Limitations for LIN Communication on page 528.
LDF file The LIN Description File (LDF) file format was specially developed for LIN networks. An LDF file describes one LIN
communication cluster and contains all the information necessary to configure it.
The Bus Manager supports LDF files based on LDF versions 1.3 up to and including 2.2.

92
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Working with Communication Matrices

Handling communication The Bus Manager lets you add communication matrices to the active
matrices in ConfigurationDesk application . There, they serve as a library from which
the ConfigurationDesk you can select elements to work with. You can assign communication
application matrix elements to bus configurations and specify user-defined settings for
configurable elements.

You can handle communication matrices in the user interface of the Bus
Manager and by using the ConfigurationDesk automation interface. For more
information on using automation, refer to Accessing Bus Manager Features via
the ConfigurationDesk Automation Interface on page 152.

Adding communication matrices You can add one or more communication

matrices to an active application. The communication matrices can have identical
names but they must differ in content. For instructions, refer to How to Add
Communication Matrices to a ConfigurationDesk Application on page 335.

Tip

The Message Viewer provides information on the import process, e.g.,

whether the communication matrix is imported successfully, the import
failed, or inconsistent settings are detected during the import.

The Bus Manager lets you add communication matrices to the active application
without strict constraints. This means that you can even add communication
matrices with inconsistent, conflicting, or unsupported settings. Depending on
the affected communication matrix elements, this results in one of the following:

§ The communication matrix is added to the active application but the affected
communication matrix elements are discarded and not added. In this case, the
Message Viewer provides information on the communication matrix elements
that are not added, as shown in the following example.

§ The affected communication matrix elements are added to the application

but conflicts occur. However, the display of communication matrix conflicts is
disabled by default. To view the conflicts, you have to enable the display in
the Conflicts Viewer. Refer to Basics on Bus Manager-Related Conflicts on
page 163.

93
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Basics on the Bus Manager

Tip

During the import, the Bus Manager also checks the communication matrix
for the following:
§ The Bus Manager checks whether all required ECUs that participate in bus
communication are part of the communication matrix. If a required ECU
is missing, it is generated during the import. Refer to Generating missing
ECUs on page 95.
§ The Bus Manager checks whether update bits are specified for ISignal
groups. For each update bit that is specified for an ISignal group, an
ISignal is generated. Refer to Generating ISignals for update bits of ISignal
groups on page 96.

Assigning communication matrix elements to bus configurations To be

able to simulate, inspect, or manipulate bus communication during run time,
you have to implement it in the signal chain . To do so, assign elements of
an added communication matrix to a bus configuration. For more information,
refer to Assigning Communication Matrix Elements to Bus Configurations on
page 112.

Specifying user-defined settings for configurable communication

matrix elements You can specify user-defined settings for configurable
communication matrix elements, for example, to resolve conflicts. For details,
refer to Modifying Communication Matrices on page 391.

Deleting communication matrices You can delete a communication matrix

from the active application using the Buses Browser. When you do this, you
can decide whether to delete only the matrix or also matrix elements that are
assigned to bus configurations.
§ Deleting only the communication matrix
When you delete the communication matrix via the Delete from Topology
context menu command, only the communication matrix is deleted. If
communication matrix elements are assigned to bus configurations, the
assigned elements become unresolved. These elements and the associated
higher-level elements are marked with a symbol and are still visible in the
Buses Browser.
Moreover, conflicts concerning the unresolved elements occur and no code is
generated for the affected bus configurations when you start the build process
or generate bus simulation containers.
§ Deleting the communication matrix and matrix elements that are assigned to
bus configurations
When you delete the communication matrix via the Delete Completely
context menu command, matrix elements that are assigned to bus
configurations are also deleted, i.e., all the related bus configuration elements
are removed. Because there are no unresolved elements, the communication
matrix is no longer visible in the Buses Browser and no conflicts concerning
the removed communication matrix occur.

94
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Working with Communication Matrices

Generating missing ECUs If a communication matrix contains PDUs for which no sending or receiving ECU
is specified and/or a specified ECU is not part of the communication matrix, the
required ECUs are generated during the import.

ECUs generated for classic CAN, CAN FD, and LIN PDUs For classic CAN
PDUs that are not J1939-compliant, CAN FD PDUs, and LIN PDUs, the generated
ECUs are named DS_UnknownSender or DS_UnknownReceiver.

The affected PDUs and their ISignals are assigned to the related sending or
receiving ECU.
In case of LIN, the following restrictions apply for generating ECUs:
§ The required ECUs can be generated only if the communication matrix
specifies the LIN master.
§ The generated ECUs contain only LIN slave communication controllers, no LIN
master communication controllers.

ECUs generated for J1939‑compliant IPDUs For J1939‑compliant IPDUs,

the generated ECUs are named DS_UnknownJ1939ECU_<transport protocol
address in hex>.

The affected IPDUs and ISignals are assigned to the generated ECUs as follows:

Affected Description
IPDUs
TX IPDUs TX IPDUs and all their ISignals are assigned to a generated ECU if it is the sending ECU, i.e., the transport protocol
address of the generated ECU is the transport protocol address that is specified as the source address of an
affected IPDU.
Peer‑to‑peer Peer‑to‑peer RX IPDUs and all their ISignals are assigned to a generated ECU if it is the receiving ECU, i.e.,
RX IPDUs the transport protocol address of the generated ECU is the transport protocol address that is specified as the
destination address of an affected peer‑to‑peer IPDU.
Broadcast Broadcast RX IPDUs can be received by any network node in a communication cluster. Therefore, no specific
RX IPDUs receiving ECU is specified for broadcast IPDUs. However, to handle broadcast IPDUs, the Bus Manager generates a
receiving ECU in the following cases:
§ The communication matrix does not assign any RX ISignals to a broadcast IPDU.
§ For at least one RX ISignal of a broadcast IPDU, the communication matrix does not specify a receiving ECU, or
the receiving ECU is not part of the communication matrix.

95
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Basics on the Bus Manager

Affected Description
IPDUs
In these cases, the generated ECU is named DS_UnknownJ1939ECU_0xFF and all affected broadcast RX IPDUs are
assigned to this ECU. However, related ISignals are assigned to this ECU only if the communication matrix does
not specify a receiving ECU for an ISignal, or the receiving ECU is not part of the communication matrix.

Tip

J1939 bridge ECUs are a typical use scenario in which ECUs are missing
in DBC communication matrices. Bridge ECUs route J1939‑compliant IPDUs
from one communication cluster to another by using the transport protocol
address of the original sending and/or receiving ECUs. Because a DBC file
specifies the communication of only one communication cluster, the original
sending and/or receiving ECUs are not available in the DBC file.

For more information on the J1939 protocol, refer to Aspects of the J1939
Protocol on page 80.

Import of dependent PDUs, In some cases, a communication matrix does not specify a sending and/or
ISignal groups, and ISignals receiving ECU for the following elements:
with missing sending and/or § Dependent PDUs, i.e.:
receiving ECU § Contained IPDUs of container IPDUs
§ Authentic IPDUs of non‑cryptographic secured IPDUs
§ Static‑part and dynamic‑part IPDUs of multiplexed IPDUs
§ ISignal groups
§ ISignals

If the communication matrix does not specify a sending and/or receiving ECU for
such an element, the element is imported. In the Buses Browser, the element is
available for its related higher‑level element. For example, if no receiving ECU is
specified for an ISignal, the ISignal is imported for its related ISignal IPDU and
available for all ECUs that receive this ISignal IPDU.

Tip

§ Because of this, more elements might be available for an ECU, IPDU, or

ISignal group than specified in the communication matrix.
§ You can use these elements in the ConfigurationDesk application without
any specific restrictions. For example, this is useful if the communication
matrix is an AUTOSAR ECU Extract, which specifies the communication
only of a single ECU.

Generating ISignals for Communication matrices can specify an update bit for ISignals and ISignal
update bits of ISignal groups groups. The value of the update bit indicates to the receiving ECU whether the
ISignal or ISignal group has changed since the last reception. For each update
bit that a communication matrix specifies for an ISignal group, the Bus Manager
generates an ISignal with the following characteristics:

96
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Working with Communication Matrices

Property Value
Name <name of ISignal group>_UpdateBit
Length 1 bit
Initial value 1
Base data type Boolean
Start bit position Position of the update bit of the ISignal group in the related
ISignal‑to‑IPDU mapping
Endianness Derived from the first ISignal of the ISignal group
Is start bit LSB

The generated ISignal lets you access the value of the update bit at run time. For
this purpose, you can configure the generated ISignal in bus configurations in
the same way as any other ISignal.

However, the Bus Manager does not generate the update bit functionality along
with the ISignal. Therefore, the value of the update bit remains unchanged by
default, regardless of whether the related ISignal group has changed. To have
the value of the update bit change with the update state of the related ISignal
group, you have to model the update bit functionality in a mapped behavior
model, for example.

According to AUTOSAR, it is not intended that ISignals use the position of

update bits that are specified for ISignal groups. If the communication matrix
specifies an ISignal that uses the position of the update bit of an ISignal group,
conflicts concerning overlapping ISignals occur.

Clusters and ECUs view The Bus Manager provides different views on communication matrix elements.
You can switch between the following views:
§ Clusters view (default view)
§ ECUs view

97
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Basics on the Bus Manager

Clusters View ECUs View

In the clusters view, all the communication clusters defined in the In the ECUs view, the bus communication defined in the
communication matrix are displayed and sorted by the bus system communication matrix is sorted by ECUs . All the ECUs
(CAN, LIN). For each cluster, the network nodes with the relevant with all their PDUs and ISignals are displayed, regardless
physical channels, PDUs , and ISignals are displayed. of which bus system or cluster they belong to. PDUs
The following example, BodyControlEcu is a member of that are transmitted or received via multiple clusters are
CanBodyCluster and LinDoorCluster. For both clusters, the displayed only once for the transmitting or receiving
BodyControlEcu network node is displayed with the cluster‑relevant ECU.
parts of the ECU communication. PDUs that are transmitted and
received on both clusters are displayed for each of the clusters.

Filtering communication For a better overview, you can filter the communication matrix elements in the
matrix elements Buses Browser. You can filter for:

Filter For Filter Via

Context Menu Home Ribbon
§ Used elements Empty area in the Buses Browser:
§ Unused elements
§ Unresolved elements

The active state is indicated by highlighting.

The active state is indicated by a check mark.

98
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Working with Communication Matrices

Filter For Filter Via

Context Menu Home Ribbon
Changed communication Empty area in the Buses Browser:
matrix elements

The active state is indicated by the selected

checkbox.

The active state is indicated by a check mark.

Names or regular expressions Column headers of the Buses Browser: –
(by specifying column filters)

The active state is indicated by a blue square:

Tip

§ If an added communication matrix is not displayed or you miss

communication matrix elements, make sure that all the filters are
deactivated.
§ You can deactivate all filters in one step using Clear All Filters, which
is available on the Home ribbon and on the context menu of the empty
area in the Buses Browser.
§ You can use the filters and the Select Elements by Type or Select
Elements by Direction command to easily select multiple similar
communication matrix elements at once. For an example, refer to
Example of Selecting Multiple Similar Communication Matrix Elements at
Once on page 355.

For details on using filters, refer to Using Display Filters (ConfigurationDesk Real-
Time Implementation Guide ).

Limitations Regarding the specifications of communication matrices, some limitations apply.

Refer to Limitations for Communication Matrices and Communication Standards
on page 519.

99
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Basics on the Bus Manager

Basics on Bus Configurations

Introduction Bus configurations let you implement bus communication in the signal
chain of ConfigurationDesk and configure it for simulation, inspection,
and/or manipulation purposes. Additionally, you can specify gateways for CAN
communication between communication clusters .

You can work with bus configurations in the user interface of the Bus
Manager and by using the ConfigurationDesk automation interface. For more
information on using automation, refer to Accessing Bus Manager Features via
the ConfigurationDesk Automation Interface on page 152.

Using multiple bus You can work with multiple bus configurations at the same time. This
configurations makes it possible for you to use a separate bus configuration, e.g., for each
communication cluster or each ECU you want to simulate.

Each bus configuration is represented by one Bus Configuration function block.

However, the number of Bus Configuration function blocks is not limited by
function block licenses. For more information, refer to Details on Function Block
Licenses (ConfigurationDesk Getting Started ).

Accessing bus configurations When you add a bus configuration to the signal chain, you can access
it via specific tables and its Bus Configuration function block. The tables
provide access to the complete structure of the bus configurations (e.g., to
the ISignals you want to simulate, their function ports, the bus access
requests, etc.) and they let you configure the bus communication for simulation,
inspection, and/or manipulation purposes, and specify gateways. The Bus
Configuration function block can be accessed via working views and provides a
structured overview of the ports of a bus configuration.

100
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Basics on Bus Configurations

For more information, refer to:

§ Bus Configuration Tables on page 103
§ Bus Configuration Function Block on page 109

Assigning communication To simulate, inspect, and/or manipulate bus communication, you have to
matrix elements assign communication matrix elements to different parts of one or more bus
and configuring bus configurations. Refer to Assigning Communication Matrix Elements to Bus
communication Configurations on page 112.

To configure the bus communication in each bus configuration, you can use
various bus configuration features. Refer to Working with Bus Configuration
Features on page 191.

Depending on the assigned communication matrix elements and the configured

bus communication, conflicts might occur. Before building a real-time application
or generating bus simulation containers, you must resolve at least the most
severe conflicts. However, the display of Bus Manager-related conflicts is disabled
by default. To view the conflicts, you have to enable the display in the Conflicts
Viewer. Refer to Basics on Bus Manager-Related Conflicts on page 163.

Removing communication You can remove an assigned communication matrix element from a bus
matrix elements from bus configuration by simply deleting it from the bus configuration. Refer to
configurations Removing Communication Matrix Elements from Bus Configurations on
page 120.

101
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Basics on the Bus Manager

Specifying gateways To exchange CAN communication between CAN communication clusters, you
can specify gateways. Refer to Specifying CAN Frame Captures and Gateways on
page 171.

Element identification via The node names in a bus configuration structure are used to identify bus
node names communication elements unambiguously within the structure. The names are
used in the variable description file (TRC file) and can, for example, be used to
access ISignals via automation scripts.

The node names of the bus configuration and the assigned communication
matrices are configurable. If you work with DBC or LDF communication matrices,
you can also configure the names of communication cluster nodes in the
bus configuration. Changing the node names applies only to the specific bus
configuration. Other bus configurations and the related communication matrix
are not affected.

It is recommended that you specify meaningful names without version or date

information for these nodes. This lets you, for example, replace an assigned
communication matrix without having to adapt test automation scripts later on.

Tip

§ DBC and LDF communication matrices specify the communication of

only one communication cluster. However, LDF matrices cannot specify
a name for the cluster and for DBC matrices specifying a cluster name
is optional. If no cluster name is specified, the cluster name is derived
from the communication matrix name when you add the matrix to the
ConfigurationDesk application. Therefore, the default cluster name might
contain version or date information.
§ Communication cluster nodes are available in a bus configuration
when you configure bus communication for inspection or manipulation
purposes. Nevertheless, you can access the cluster name via the
Properties Browser when you select a PDU that is assigned to any part
of a bus configuration.

Updating bus configurations Typically, the bus communication defined in a communication matrix is
frequently changed during the development process. Communication matrices
cannot be updated in the ConfigurationDesk application but you can import
the modified communication matrix regardless of whether its name has
changed. The Bus Manager updates a bus configuration when you replace the
assigned communication matrix by the modified communication matrix. Refer to
Replacing Assigned Communication Matrices on page 435.

Transferring configured bus You can easily transfer configured bus communication from one bus
communication to bus configuration to another. To do this, you can copy entire bus configurations,
configurations or copy or cut individual bus configuration elements and paste them to
one or more bus configurations. Refer to Copying, Cutting, and Pasting Bus
Configuration Elements on page 131.

102
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Bus Configuration Tables

Accessing real-time hardware To simulate, inspect, or manipulate bus communication on real-time hardware
during run time, the real-time hardware must provide bus channels. When
you assign communication matrix elements to a bus configuration, the
communication clusters of the assigned elements are represented by bus access
requests. To specify the bus access, you have to assign the bus access requests to
a CAN or LIN function block (bus function block). Via the bus function blocks,
you can assign suitable hardware resources and configure the bus channels
according to your requirements. Refer to Specifying the Hardware Access on
page 157.

Including bus communication To include bus communication in SIL simulation , you can generate
in offline simulation bus simulation containers . You can import bus simulation containers to
VEOS and implement the contained bus communication in an offline
simulation application . Refer to Basics on Bus Simulation Containers (BSC Files)
on page 373.

Related topics Basics

Limitations for Bus Configuration Handling............................................................................. 531

Bus Configuration Tables

Introduction The bus configuration tables are the main elements for accessing and working
with bus configurations:
§ They let you assign communication matrix elements to bus configurations.
§ They let you configure the bus communication for simulation, inspection,
and/or manipulation purposes.
§ They let you specify gateways.
§ They provide access to all the elements and properties of bus configurations.

The tables provide a high number of columns that let you access and work with
the bus configurations. For a better overview, not all of the columns that are
available for a table are displayed by default. The columns that are not displayed
are available in the Column Chooser. You can add or remove columns to or
from a table by dragging the columns from the Column Chooser to the table or
vice versa.

103
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Basics on the Bus Manager

Tip

§ You can access the Column Chooser via the context menu of the column
headers.

§ The Column Chooser applies only to the table for which you open it.
When you select another table, the Column Chooser is automatically
closed.
§ You can use the Reset Columns command to reset the columns of the
selected table to the default state. You can access the command when
you right‑click in an empty area of the table.

Moreover, you can customize the display of the tables according to your
requirements, for example, by using display filters, selecting elements by type,
or sorting columns. Some of the changes, such as added or removed columns,
apply to all ConfigurationDesk projects and are stored, even if you close the
tables or ConfigurationDesk. For more information, refer to Customizing Table
Rows and Columns (ConfigurationDesk Real-Time Implementation Guide ).

The following tables are specific for bus configurations:

§ Bus Configurations table on page 105
§ Bus Access Requests table on page 107
§ Bus Simulation Features table, Bus Inspection Features table, and Bus
Manipulation Features table on page 107
§ Bus Configuration Ports table on page 108

104
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Bus Configuration Tables

Tip

If a table is closed, you can open it via Show Panes on the View ribbon, for
example.

Bus Configurations table This table provides access to all the bus configurations of the
active ConfigurationDesk application. The following illustration is an
example of the Bus Configurations table structure for an application
with two bus configurations named 'Combi_BusConfiguration' and
'Controller_BusConfiguration'.

Bus configuration parts Each bus configuration consists of five bus

configuration parts. The Bus Configurations table provides access to the
following four parts:

Bus Description
Configuration
Part
Simulated ECUs Lets you assign communication matrix elements to the bus configuration for simulation purposes. Simulating
bus communication is ECU-dependent. Therefore, elements are assigned in the context of their sending or
receiving ECUs. You can select individual elements to access their properties in the Properties Browser and
add available bus configuration features.
Inspection § Lets you assign communication matrix elements to the bus configuration for inspection purposes. Inspecting
bus communication is cluster-dependent, i.e., ECU-independent. Therefore, elements are assigned in the
context of their communication cluster .

105
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Basics on the Bus Manager

Bus Description
Configuration
Part
§ Lets you add frame captures to capture CAN frames that are received on the bus. Frame captures are
independent from communication matrices, i.e., frames are captured on the basis of specified frame
parameters and not on the basis of communication matrix elements.
You can select individual elements to access their properties in the Properties Browser and add available bus
configuration features.
Manipulation Lets you assign communication matrix elements to the bus configuration for manipulation purposes.
Manipulating bus communication is cluster-dependent, i.e., ECU-independent. Therefore, elements are
assigned in the context of their communication cluster. You can select individual elements to access their
properties in the Properties Browser and add available bus configuration features.
Gateways Lets you specify gateways. Via a gateway, you can exchange CAN communication between two
communication clusters. Specifying gateways is independent from communication matrices, i.e., you cannot
assign communication matrix elements to this part. Instead, you have to add a frame gateway for each
gateway you want to specify.

Tip

§ The fifth part of each bus configuration is the Bus Access Requests part.
You can access this part via the Bus Access Requests table.
§ All the communication matrix elements that are assigned to a
bus configuration are displayed hierarchically, starting with the
communication matrix they are part of. Therefore, a communication
matrix can be represented by up to four communication matrix nodes,
one below each Simulated ECUs, Inspection, Manipulation, and Bus
Access Requests node. Changes you make to one communication matrix
node automatically apply to the other nodes.
§ When you drag communication matrix elements to a bus configuration
node, the elements are automatically assigned to the Simulated ECUs
part of the related bus configuration.

Further information
§ For an overview of the use scenarios for simulating, inspecting, manipulating,
and gatewaying bus communication, refer to Overview of the Use Scenarios
for Configuring Bus Communication with the Bus Manager on page 29.
§ For basic information on assigning communication matrix elements for
simulation, inspection, and manipulation purposes to bus configurations,
refer to Assigning Communication Matrix Elements to Bus Configurations on
page 112.
§ For basic information on capturing CAN frames, refer to Capturing CAN
Frames on page 171.
§ For basic information on specifying gateways, refer to Specifying CAN Frame
Gateways on page 173.
§ For more information on this table, refer to Bus Configurations Table
(ConfigurationDesk User Interface Reference ).
§ For an overview of all the available symbols, refer to Elements and Symbols
of Bus Configurations and Communication Matrices (ConfigurationDesk User
Interface Reference ).

106
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Bus Configuration Tables

Bus Access Requests table This table provides access to all the bus access requests of all bus
configurations of the active ConfigurationDesk application. Bus access requests
are generated for the following elements:
§ One bus access is generated for each pair of a communication cluster and
the Simulated ECUs, Inspection, or Manipulation part of a bus
configuration if at least one cluster element is assigned to the related part.
§ One bus access request is generated for each frame capture element that is
added to the Inspection part of a bus configuration.
§ Two bus access requests are generated for each frame gateway that is added
to the Gateways part of a bus configuration.

You can specify user-defined names for the bus access requests and assign the
bus access requests to bus accesses .

The following illustration is an example of the Bus Access Requests

table structure for an application with two bus configurations named
'Combi_BusConfiguration' and 'Controller_BusConfiguration'.

Further information
§ For more information on bus access requests and bus accesses, refer to Basics
on Bus Access Requests on page 155.
§ For more information on this table, refer to Bus Access Requests Table
(ConfigurationDesk User Interface Reference ).
§ For an overview of all the available symbols, refer to Elements and Symbols
of Bus Configurations and Communication Matrices (ConfigurationDesk User
Interface Reference ).

Bus Simulation Features Bus configurations provide various bus configuration features, which are
table, Bus Inspection Features available for specific elements and for simulation, inspection, and/or
table, and Bus Manipulation manipulation purposes.
Features table
The Bus Simulation Features table, Bus Inspection Features table, and
Bus Manipulation Features table provide access to the bus configuration
features that can be added to PDUs and ISignals for simulation, inspection,
and manipulation purposes, respectively. Each table lets you enable and
disable PDU-related and signal-related bus configuration features for all the
bus configurations of the active ConfigurationDesk application. Depending on

107
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Basics on the Bus Manager

the enabled bus configuration features, function ports and/or event ports are
added to the related bus configuration. You can access the ports via the Bus
Configurations and Bus Configuration Ports table, for example.

Tip

The Bus Simulation Features, Bus Inspection Features, and Bus

Manipulation Features table provide access only to bus configuration
features that are available for PDUs and ISignals. To access bus configuration
features that are available for other bus configuration elements, e.g.,
communication controllers, ISignal groups, global time domains, you have
to right-click the related elements in the Bus Configurations table.

The Bus Simulation Features, Bus Inspection Features, and Bus

Manipulation Features table provide the following subviews:

Subview Purpose
PDU Features Provides a list of all the PDUs that are assigned to the related bus
configuration part and the available PDU-related bus configuration
features. This is the default view.
Signal Provides a list of all the ISignals that are assigned to the related bus
Features configuration part and the available signal-related bus configuration
features.

The following illustration is an example of the Bus Simulation Features table,

displaying the PDU Features subview.

Further information
§ For more information on working with bus configuration features, refer to
Working with Bus Configuration Features on page 191.
§ For more information on these tables, refer to
§ Bus Simulation Features Table (ConfigurationDesk User Interface
Reference )
§ Bus Inspection Features Table (ConfigurationDesk User Interface
Reference )
§ Bus Manipulation Features Table (ConfigurationDesk User Interface
Reference )

Bus Configuration Ports table Bus configurations provide function ports and/or event ports for enabled
bus configuration features. The ports let you access ISignal values, LIN schedule
tables, PDU raw data, etc.

This table provides access to the available ports of all the bus configurations
of the active ConfigurationDesk application. In the table, you can configure the

108
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Bus Configuration Function Block

ports: For example, you can enable Model access for several function ports at
the same time or map model ports to function ports or event ports via drag &
drop. For a better overview, you can filter this table via various port filters. When
you select a port in the list, all the properties of the port are displayed in the
Properties Browser.

Further information
§ For more information on configuring function ports, refer to Configuring
Function Ports for Bus Configuration Features on page 198.
§ For an example of mapping model ports to function ports or event ports via
this table, refer to Example of Mapping Model Ports to Bus Configuration Ports
via Tables on page 358.
§ For more information on filtering elements, refer to Using Display Filters
(ConfigurationDesk Real-Time Implementation Guide ).
§ For more information on this table, refer to Bus Configuration Ports Table
(ConfigurationDesk User Interface Reference ).

Bus Configuration Function Block

Introduction In working views, each bus configuration can be accessed via its Bus
Configuration function block.

Port-based appearance of Bus The appearance of Bus Configuration function blocks is port-based, i.e., each
Configuration function blocks function block provides a hierarchically structured access to the ports of a bus
configuration. Because the available ports and the related hierarchies depend on
the configured bus communication, the appearance of each Bus Configuration
function block depends on the bus communication that is configured for the
related bus configuration.

Default view of Bus By default, bus configurations do not provide any ports. Therefore, a default Bus
Configuration function blocks Configuration function block displays only the name of the bus configuration.

Function ports of Bus Function ports are available when you configure bus communication by using
Configuration function blocks bus configuration features that provide function ports. In many cases, the bus
communication that is configured for a bus configuration results in hundreds of
signals that can be accessed via function ports. Therefore, Bus Configuration
function blocks can provide hundreds of function ports.

109
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Basics on the Bus Manager

To improve the overview, function ports with disabled model access are hidden
by default. The related hierarchical structures are also hidden. Because model
access is disabled for all the function ports by default, Bus Configuration
function blocks display no function ports by default.

When you enable model access for function ports, the function ports and the
related hierarchical structures are displayed. In the following example, model
access is enabled for four function ports.

Tip

To display function ports with disabled model access, you have to deactivate
the filter for mappable ports. To do so, right-click a free area of the
working view and clear Filter for Mappable Ports on the context menu.
The function ports with disabled model access are indicated by and
symbols.

110
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Bus Configuration Function Block

For more information on working with bus configuration features and

configuring function ports, refer to Basics on Working with Bus Configuration
Features on page 192.

Event ports of Bus Event ports are available only if you add bus configuration features that
Configuration function blocks provide event ports to the bus configuration. If you do this, the related
Bus Configuration function block displays the event ports, including their
hierarchical structure, as shown in the following example.

Tip

§ In contrast to function ports, all the available event ports are displayed by
default.
§ When you configure bus communication, events are created
automatically. However, for these events no event ports are available.
For more information, refer to Basics on Tasks, Events, and Runnable
Functions Provided by the Bus Manager on page 363.

Default view of Bus When you open a working view that contains a Bus Configuration function
Configuration function blocks block with a high number of mappable ports (i.e., function ports with enabled
providing a high number of model access and/or event ports), the function block is collapsed by default. To
mappable ports expand the function block, click the expand arrow.

If you click the expand arrow once and ports of the Bus Configuration function
block are mapped to model ports, the mapping lines are still collapsed and
drawn to the parent port of the function block. To expand the mapping lines as
well, click the expand arrow twice.

111
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Basics on the Bus Manager

Assigning Communication Matrix Elements to Bus Configurations

Introduction To simulate, inspect, and/or manipulate bus communication, you have to assign
communication matrix elements to specific bus configuration parts:
§ To simulate bus communication, assign communication matrix elements to the
Simulated ECUs bus configuration part.
§ To inspect bus communication, assign communication matrix elements to the
Inspection bus configuration part.
§ To manipulate bus communication, assign communication matrix elements to
the Manipulation bus configuration part.

You can access the bus configuration parts in the Bus Configurations table.

The bus configuration parts do not influence each other. Therefore, you can
configure the bus communication independently for simulation, inspection, and
manipulation purposes. For more information on these use scenarios, refer to
Overview of the Use Scenarios for Configuring Bus Communication with the Bus
Manager on page 29.

Assigning communication You can assign communication matrices completely or in part to bus
matrix elements to bus configurations. You can do this by selecting communication matrix elements in
configurations the Buses Browser and dragging them to the Bus Configurations table.

In the Buses Browser, you can select communication matrix elements in

different ways:
§ You can manually select one or more communication matrix elements of any
type and any communication matrix.
§ You can use filters and the Select Elements by Type or Select Elements by
Direction command of the Buses Browser to easily select multiple similar
elements. Refer to Filtering communication matrix elements on page 98.
§ If you want to perform a restbus simulation , you can assign all PDUs that
are involved in the communication of specific ECUs or network nodes to
a bus configuration in one step. Refer to Creating Restbus Configurations on
page 121.

When you drag selected communication matrix elements to the Bus

Configurations table, they are assigned to bus configurations as follows:

Dragging Elements To … Result

§ The empty Bus Configurations table. The elements are assigned to the Simulated ECUs part by default. If
§ The bus configuration node of an existing bus required, you can change this default behavior. Refer to Specifying the
configuration. Behavior for Assigning Communication Matrix Elements and Adding Bus
Configuration Features (Preview Version) on page 125.

112
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Assigning Communication Matrix Elements to Bus Configurations

Dragging Elements To … Result

The Simulated ECUs, Inspection, or Manipulation The elements are assigned to the respective part.
part node of an existing bus configuration.

In the Buses Browser, the assigned communication matrix elements are marked
by a chain symbol ( ). These elements are part of the signal chain and are
implemented in the real-time application when you build the application and
in bus simulation containers when you generate the containers.

General assignment rules When you assign a communication matrix element to a bus configuration, the
following general assignment rules apply:
§ Relevant higher-level elements are assigned as well.
§ Relevant subelements are assigned as well.
§ Elements of the same hierarchy level are not assigned.

Example:

Selected Elements Effects

§ RawThrottleISignal § RawThrottleISignal: The related higher-level ISignal IPDU is assigned as well. The ISignals on
§ CorrectedSensorIPdu the same hierarchy level as RawThrottleISignal are not assigned.
§ CorrectedSensorIPdu: All its subelements (i.e, the ISignal group and the ISignals) are assigned as
well.

Which higher-level elements and subelements are relevant and assigned as

well depends on the selected communication matrix element and the bus
configuration part (Simulated ECUs, Inspection, Manipulation) to which you
assign the selected element. For more information, refer to:
§ Assigning elements to the Simulated ECUs part on page 113
§ Assigning elements to the Inspection and/or Manipulation part on page 115
§ Notes on assigning specific PDU types on page 117

PDUs and ISignals that are assigned to a bus configuration are instantiated. For
more information, refer to Instantiating PDUs and ISignals on page 119.

Assigning elements to the Simulating bus communication is ECU-dependent. Therefore, communication

Simulated ECUs part matrix elements are assigned in the context of their sending or receiving ECU
when you assign the elements to the Simulated ECUs part.

113
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Basics on the Bus Manager

The assignment of the related higher-level elements and subelements differs,

depending on whether you select the communication matrix elements in the
Communication Matrices by Clusters or Communication Matrices by ECUs
view of the Buses Browser, as shown in the following examples.

Assigning elements from the Communication Matrices by Clusters

view If you assign a communication matrix element from the
Communication Matrices by Clusters view, it is assigned in the context of
the related network node and communication cluster .
Example:

Selected Element Assigned To Effects

Communication Matrices by Simulated Only the elements that are relevant for the bus communication of the
Clusters view: ECUs BodyControlEcu network node on CanBodyCluster are assigned as
CanBodyCluster - BodyControlEcu well.
network node - CarLockControlIPdu Elements that are relevant for the bus communication of the
BodyControlEcu network node on LinDoorCluster are not assigned.

Assigning elements from the Communication Matrices by ECUs view If

you assign a communication matrix element from the Communication
Matrices by ECUs view, it is assigned in the context of the related ECU .
Example:

Selected Element Assigned To Effects

Communication Matrices by Simulated The BodyControlEcu ECU transmits the PDU on two communication
ECUs view: ECUs clusters (CanBodyCluster, LinDoorCluster). Therefore, all elements that
BodyControlEcu ECU - are relevant for the bus communication on both communication clusters are
CarLockControlIPdu assigned as well.
However, other ECUs that transmit or receive the PDU as well (e.g.,
DoorRightEcu) are not affected and not assigned.

114
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Assigning Communication Matrix Elements to Bus Configurations

Assigning elements to Inspecting and manipulating bus communication is cluster-dependent.

the Inspection and/or Additionally, inspecting bus communication is only possible for received
Manipulation part bus communication while manipulating is only possible for transmitted bus
communication.

When you assign communication matrix elements to the Inspection or

Manipulation part, the elements are therefore assigned in the following ways:
§ The elements are assigned in the context of their communication clusters,
regardless of their sending and/or receiving ECUs.
§ If you assign elements to the Inspection part, the direction of the assigned
elements is always RX, regardless of whether you assign an RX or TX
communication matrix element.
§ If you assign elements to the Manipulation part, the direction of the
assigned elements is always TX, regardless of whether you assign a TX or
RX communication matrix element.

Assigning the related higher-level elements and subelements does not differ
for the Inspection and Manipulation parts. However, the assignment differs
depending on whether you select the communication matrix elements in the
Communication Matrices by Clusters or Communication Matrices by ECUs
view of the Buses Browser, as shown in the following examples.

Assigning elements from the Communication Matrices by Clusters

view If you assign a communication matrix element from the
Communication Matrices by Clusters view to the Inspection or
Manipulation part, it is assigned in the context of the related communication
cluster.

§ Example 1:

Selected Element Assigned To Effects

Communication Matrices by Inspection In the bus configuration, the direction of the PDU is converted to RX. All
Clusters view: the elements that are relevant for the bus communication of the related
LinDoorCluster - BodyControlEcu communication cluster are assigned as well.
network node - TX The network node for which the PDU is selected does not directly affect the
CarLockControlIPdu assignment. Therefore, the PDU is marked with the chain symbol for all the
network nodes of LinDoorCluster.

115
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Basics on the Bus Manager

§ Example 2:

Selected Element Assigned To Effects

Communication Matrices by Clusters view: Manipulation In the bus configuration, the direction of the PDU is converted to
LinDoorCluster - DoorLeftEcu network TX. The assignment of the relevant related elements is identical
node - RX CarLockControlIPdu to the assignment of the Inspection part.

Assigning elements from the Communication Matrices by ECUs view If

you assign a communication matrix element from the Communication
Matrices by ECUs view to the Inspection or Manipulation part, it is assigned
in the context of all the related communication clusters.
Example:

Selected Element Assigned To Effects

Communication Matrices by Inspection The direction of the PDU is converted to RX.
ECUs view: Because the ECU transmits the PDU on two communication clusters
BodyControlEcu ECU - TX (CanBodyCluster, LinDoorCluster), all the elements that are relevant for the bus
CarLockControlIPdu communication of both communication clusters are assigned as well.
However, the ECU for which the PDU is selected does not directly affect the
assignment. Therefore, the PDU is marked with the chain symbol for all the ECUs
of CanBodyCluster and LinDoorCluster.

Tip

If the PDU is assigned to the Manipulation part, the PDU direction is not
converted. The assignment of the relevant related elements is identical.

116
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Assigning Communication Matrix Elements to Bus Configurations

Notes on assigning specific Container IPDUs , multiplexed IPDUs , and non‑cryptographic secured
PDU types IPDUs have dependent IPDUs, which are displayed as subelements of the
IPDUs in the Buses Browser. To these IPDU types and their dependent IPDUs, the
same assignment rules apply as to other communication matrix elements.

For example, a container IPDU has two dependent IPDUs, i.e., contained IPDUs:

§ When you assign the container IPDU to a bus configuration, both contained
IPDUs are assigned as well.
§ When you assign one of the contained IPDUs to a bus configuration, the
container IPDU is assigned as well. The other contained IPDU is not assigned.

However, in bus configurations, PDUs are always displayed on the same hierarchy
level, as shown in the following example:

When you select a container IPDU, multiplexed IPDU, or secured IPDU in the
bus configuration, the Properties Browser provides the Contained IPDUs,
Multiplexed Part IPDUs, or Authentic IPDUs page. These pages display the
related dependent IPDUs that are also assigned to the bus configuration, as
shown in the following example:

117
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Basics on the Bus Manager

Tip

In the example above, the Is initial dynamic part and Selector field
code properties are grouped for the multiplexed IPDU. To display the
properties for each dynamic‑part IPDU, select the intersection mode in
the Properties Browser.

Special points to note for secured IPDUs In secure onboard

communication scenarios, a secured IPDU and its related authentic IPDU must
be assigned to the same bus configuration part of a bus configuration.
§ If the secured IPDU is configured as a non‑cryptographic IPDU, this happens
automatically when you assign any of the two IPDUs to a bus configuration.
This is because in this case, the authentic IPDU is a subelement of the secured
IPDU in the Buses Browser.

§ If the secured IPDU is configured as a cryptographic IPDU, this does not

happen automatically when you assign any of the two IPDUs to a bus
configuration. This is because in this case the authentic IPDU is not a
dependent IPDU of the secured IPDU. In the Buses Browser, both IPDUs are
therefore elements of the same hierarchy level.

118
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Assigning Communication Matrix Elements to Bus Configurations

You have to assign both IPDUs to the same bus configuration part of a bus
configuration manually.

Tip

When you do this, the Properties Browser provides the Authentic

IPDUs page for the secured IPDU.

Instantiating PDUs and PDUs and ISignals that are assigned to bus configurations are instantiated. The
ISignals instances of one PDU/ISignal are not synchronized. Therefore, you can configure
different settings for each instance.

Depending on the bus configuration part (Simulated ECUs, Inspection,

Manipulation) you assign PDUs and ISignals to, they are instantiated in the
following ways:

PDUs and ISignals assigned to the Simulated ECUs part PDUs and ISignals
that are assigned to the Simulated ECUs part of one or more bus configurations
are instantiated for each related transmitting or receiving ECU and for each bus
configuration.
In the following example, CarLockControlIPdu is assigned to two bus
configurations: To Bus Configuration (1), the PDU is assigned in the context
of two ECUs. To Bus Configuration (2), the PDU is assigned in the context of
three ECUs. Therefore, five instances are generated for the PDU.

PDUs and ISignals assigned to the Inspection or Manipulation part PDUs

and ISignals that are assigned to the Inspection or Manipulation part of one or
more bus configurations are instantiated for each related communication cluster
and channel, and for each bus configuration.
In the following example, CarLockControlIPdu is assigned to the Inspection
part of two bus configurations: To Bus Configuration (1), the PDU is assigned
in the context of one communication cluster. To Bus Configuration (2), the

119
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Basics on the Bus Manager

PDU is assigned in the context of two communication clusters. Therefore, three

instances are generated for the PDU.

Conflicting assignments A communication matrix can contain elements that cannot be used with the Bus
Manager, for example, PDUs with exceeding ISignals or ISignals with an invalid
coding. If you assign such elements to bus configurations, conflicts occur. In
most cases, you must resolve these conflicts before you can build a real-time
application or generate bus simulation containers that include the affected bus
configurations. Refer to Basics on Bus Manager-Related Conflicts on page 163.

Related topics Basics

Accessing Bus Manager Features via the ConfigurationDesk Automation Interface.................. 152
Basics on Bus Access Requests................................................................................................ 155
Introduction to the Properties Browser (ConfigurationDesk Real-Time
Implementation Guide )

Removing Communication Matrix Elements from Bus Configurations

Introduction You can remove communication matrix elements from bus configurations by
deleting them in bus configuration tables.

Removing communication To remove a communication matrix element from a bus configuration, you can
matrix elements in bus select it in a bus configuration table (e.g., in the Bus Configurations table
configuration tables or Bus Simulation Features table) and delete it via the context menu or the

120
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Creating Restbus Configurations

Delete key. Deleting a communication matrix element has the following effects
on the related bus configuration:
§ Subelements of the deleted element are removed as well.
§ Higher-level elements of the deleted element are removed as well if all of the
following conditions are fulfilled:
§ The higher-level elements have no other subelements.
§ The higher-level elements have no configurable properties themselves.
§ No bus configuration features are available for the higher-level elements.
§ Elements that directly depend on the deleted element are removed as well:
§ If you delete a container IPDU , the related contained IPDUs are removed
as well.
§ If you delete a multiplexed IPDU , the related static‑part and dynamic‑part
IPDUs are removed as well.
§ If you delete a secured IPDU that is configured as a non‑cryptographic
IPDU, the related authentic IPDU is removed as well.
§ If you delete a bus channel (available for the Inspection and Manipulation
bus configuration parts), the related cluster is removed as well.
§ If you delete a communication controller (available only for the Simulated
ECUs bus configuration part), all the elements that are transmitted or
received by the related ECU via the affected cluster are removed as well.
For example, you work with a bus configuration as shown in the following
illustration and you delete the 'FrontModule_CAN_Comfort_Controller'.

In this case, all the PDUs that are transmitted or received only via
'CAN_Comfort_Cluster' are removed as well. 'PDU_FrontModule_Burst' is
transmitted via two clusters. Therefore, the PDU itself is not removed but
only the frame that transmits the PDU via 'CAN_Comfort_Cluster'.

Creating Restbus Configurations

Introduction If you want to perform a restbus simulation for one or more ECUs under test
(e.g., real ECUs), you can create a restbus configuration. When you do this, all
the communication matrix elements that are required for the restbus simulation
are assigned to a bus configuration in one step.

121
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Basics on the Bus Manager

For an example of a restbus simulation, refer to Use Scenarios for Simulating Bus
Communication on page 31.

Creating a restbus To create a restbus configuration for the ECUs under test, you can select the
configuration related ECUs or network nodes in the Buses Browser. When you do this,
the Create Restbus Configuration command is available on the context menu.
This command assigns the communication matrix elements that are required for
the restbus simulation to a bus configuration.

Determining the required communication matrix elements To determine

the required communication matrix elements, the following principles apply:
§ For a selected ECU, the bus communication on all involved communication
clusters is considered.
§ For a selected network node, only the bus communication on the related
communication cluster is considered.
§ If you select multiple ECUs or network nodes, the bus communication that
is exchanged only between the selected ECUs or network nodes is not
considered.
In the following example, ECU 1 and ECU 2 are selected. For creating a restbus
configuration, all the elements that are transmitted and received by the selected
ECUs are considered, except the elements that are only exchanged between the
two ECUs.

Created restbus configuration

PDU 1_1
PDU 1_4
Selected ECUs
CAN 1 ECU 3

PDU 3_1
ECU 1

PDU 1_5
CAN 2 ECU 4
PDU 1_1
PDU 2_1 PDU 4_1
PDU 1_2 CAN 1 PDU 2_2 PDU 4_2
PDU 1_3

PDU 2_3
ECU 2 LIN 1 ECU 5
PDU 5_1

Assigning the required communication matrix elements to a bus

configuration Basically, the required communication matrix elements are
assigned to a bus configuration according to the following rules:
§ The selected ECUs or network nodes are not assigned to the bus configuration
because they are the ECUs under test and, for example, available as real ECUs.
§ All PDUs, including their subelements, that are received by a selected ECU
or network node are assigned to the Simulated ECUs part of the bus
configuration. The elements are assigned in the context of their transmitting
ECUs and the direction of the assigned elements is TX. At run time, the

122
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Creating Restbus Configurations

transmitting ECUs are simulated. The PDUs are transmitted and can be
received by the ECUs under test.
§ All PDUs, including their subelements, that are transmitted by a selected ECU
or network node are assigned to the Inspection part of the bus configuration.
When the ECUs under test transmit the PDUs at run time, they are received by
the bus configuration.
For the example above, the required communication matrix elements are
assigned to the bus configuration as follows:

Bus Configuration Part ECU or Communication Cluster PDUs

Simulated ECUs ECU 3 PDU 3_1
ECU 4 § PDU 4_1
§ PDU 4_2
ECU 5 PDU 5_1
Inspection CAN 1 § PDU 1_1
§ PDU 1_4
CAN 2 PDU 1_5
LIN 1 PDU 2_3

Tip

Moreover, you can specify a user‑defined bus configuration behavior.

When you do this, you can specify which bus configuration features are
automatically added to the communication matrix elements when they
are assigned to the Simulated ECUs and Inspection parts. For more
information, refer to Specifying the Behavior for Assigning Communication
Matrix Elements and Adding Bus Configuration Features (Preview Version)
on page 125.

Selecting a bus configuration for a restbus configuration By default, a

new bus configuration is added to the Bus Configurations table when you click
the Create Restbus Configuration command. If you want to add the restbus
configuration to an existing bus configuration, do the following:
1. Select the bus configuration in the Bus Configurations table.
2. Press the Ctrl key and select the ECUs or network nodes for which you
want to create the restbus configuration in the Buses Browser.
3. Right-click the selected ECUs/network nodes and select Create Restbus
Configuration on the context menu.
When you do this, all required communication matrix elements are assigned to
the selected bus configuration. Elements that were previously assigned to the
bus configuration remain unchanged.

Excluding ECUs from restbus You can exclude ECUs from a restbus configuration. For this purpose, the
configurations Restbus Configuration Exclude List is available. ECUs that are listed in the
exclude list are not considered for creating a restbus configuration. For example,
if ECU 3 from the example above is listed in the exclude list, the PDUs that
are exchanged between ECU 1 and ECU 3 are not included in the restbus
configuration.

123
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Basics on the Bus Manager

You can open the Restbus Configuration Exclude List via Show Panes on the
View ribbon.

To exclude ECUs, you can drag them from the Buses Browser to the exclude list
or type their names in the exclude list. If you type the names, use a semicolon to
separate the names.

Tip

The exclude list is string‑based, i.e., it can contain any string. However,
strings that are no ECU names have no effects, i.e., they are ignored when
you create a restbus configuration.

Restrictions for creating For creating restbus configurations, the following restrictions apply:
restbus configurations § You can create a restbus configuration only for ECUs or network nodes that
are specified in the same communication matrix.
§ You cannot exclude network nodes from a restbus configuration, i.e., you
cannot exclude the communication on individual clusters. When you add the
name of an ECU to the Restbus Configuration Exclude List, the ECU's bus
communication on all involved communication clusters is excluded from the
restbus configuration.
§ The entries of the Restbus Configuration Exclude List are not saved. When
you close the list or the ConfigurationDesk application, the list is cleared.
§ You cannot update a created restbus configuration, e.g., if elements that are
required for the restbus configuration have changed in an updated version of
the communication matrix.

Related topics Basics

Accessing Bus Manager Features via the ConfigurationDesk Automation Interface.................. 152
Specifying the Behavior for Assigning Communication Matrix Elements and Adding
Bus Configuration Features (Preview Version).......................................................................... 125

124
ConfigurationDesk Bus Manager Implementation Guide May 2024
Specifying the Behavior for Assigning Communication Matrix Elements and Adding Bus Configuration Features (Preview Version)

Specifying the Behavior for Assigning Communication Matrix Elements and

Adding Bus Configuration Features (Preview Version)

Introduction The Bus Manager provides a default behavior for configuring bus communication
in bus configurations, called default bus configuration behavior. This behavior
applies to the following actions:
§ Assigning communication matrix elements to bus configurations.
§ Adding bus configuration features to assigned communication matrix
elements.

If the default bus configuration behavior does not meet your requirements, you
can specify a user‑defined bus configuration behavior.

Note

The current version of specifying a user‑defined bus configuration behavior

is a preview version. Refer to Providing preview versions of Bus Manager
features on page 19.

Overview of the default bus With the default bus configuration behavior, the following behavior applies for
configuration behavior assigning communication matrix elements to bus configurations and adding bus
configuration features to assigned communication matrix elements:

Tip

For animated graphics, refer to dSPACE Help.

Elements Action Behavior

Communication Dragging communication matrix elements to the Bus The elements are assigned to the Simulated ECUs
matrix elements Configurations table as follows: part of a bus configuration as follows:
§ To the empty Bus Configurations table. § To a new bus configuration if the Bus
§ To the Bus Configurations table when only one Configurations table was empty.
bus configuration is available. § To the existing bus configuration if only one bus
configuration was available.

Note

If you drag communication matrix elements to the Bus Configurations table when two or more bus
configurations are available, the elements cannot be assigned to any bus configuration.

Dragging communication matrix elements to a bus The elements are assigned to the Simulated ECUs
configuration as follows: part of the respective bus configuration.
§ To the bus configuration node of a bus
configuration.
§ Between the bus configuration part nodes of a bus
configuration (indicated by a blue line).

125
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Basics on the Bus Manager

Elements Action Behavior

Dragging communication matrix elements to the The elements are assigned to the respective bus
Simulated ECUs, Inspection, or Manipulation part configuration part.
of a bus configuration.
Bus configuration Assigning communication matrix elements to the § The ISignal Value feature is added to ISignals.
features Simulated ECUs part of a bus configuration. § The LIN Schedule Table feature is added to LIN
master communication controllers.
Assigning communication matrix elements to the No bus configuration features are added.
Inspection or Manipulation part of a bus
configuration.
Function ports of Adding bus configuration features to communication § Model access is disabled for all function ports.
bus configuration matrix elements in the Simulated ECUs part of a bus § Test automation support is enabled for the Raw
features configuration (bus simulation features). Data function port (PDU Raw Data feature).
§ Test automation support is disabled for all other
function ports.
Adding bus configuration features to communication § Model access is disabled for all function ports.
matrix elements in the Inspection or Manipulation § Test automation support is enabled for all
part of a bus configuration (bus inspection features or function ports.
bus manipulation features).

Enabling and disabling If the default bus configuration behavior does not meet your requirements, you
a user‑defined bus can enable the use of a user‑defined bus configuration behavior. You can do this
configuration behavior in the following ways:
§ In the Bus Configuration Behavior table, set User‑defined configuration
to On.

Tip

You can open the Bus Configuration Behavior table via Windows on
the Home ribbon, for example.

§ On the Home ribbon, click the Enable button so that it is highlighted.

When enabled, the columns of the Bus Configuration Behavior table are
configurable and you can specify a user‑defined bus configuration behavior. This
behavior applies to all subsequently assigned communication matrix elements

126
ConfigurationDesk Bus Manager Implementation Guide May 2024
Specifying the Behavior for Assigning Communication Matrix Elements and Adding Bus Configuration Features (Preview Version)

and added bus configuration features. Refer to Specifying the user‑defined bus
configuration behavior on page 127.

When you disable the user‑defined configuration behavior, i.e., you set the
User‑defined configuration button to Off or click the Enable button again
so that it is not highlighted anymore, the default bus configuration behavior
applies. The Bus Configuration Behavior table is read‑only and displays
the default bus configuration behavior. However, the specified user‑defined
configuration is preserved and you can enable it again at any time.

Tip

The specified enable state is stored locally on the host PC and applies
to all ConfigurationDesk projects and applications, even if you close
ConfigurationDesk. For example, when you enable the user‑defined
configuration behavior before you close ConfigurationDesk, this behavior
is enabled when you open ConfigurationDesk the next time.

Specifying the user‑defined When you enable the user‑defined bus configuration behavior, the Bus
bus configuration behavior Configuration Behavior table lets you specify the user‑defined bus
configuration behavior as follows:

Tip

For animated graphics, refer to dSPACE Help.

Column Description
Forward The settings of this column apply only in the following cases:
Assignment § You drag communication matrix elements to the empty Bus Configurations table.
§ You drag communication matrix elements to the Bus Configurations table when only one bus configuration is
available.
§ You drag communication matrix elements directly onto a bus configuration node.
§ You drag communication matrix elements between the bus configuration part nodes of a bus configuration
(indicated by a blue line).

127
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Basics on the Bus Manager

Column Description
In these cases, the elements are assigned to the bus configuration parts for which the respective checkboxes are
selected. For example:

When you now drag TX and RX PDUs to a bus configuration node, the elements are assigned as follows:
§ All TX PDUs are assigned to the Simulated ECUs and Manipulation parts.
§ The ISignal groups and ISignals that are available for the TX PDUs are only assigned to the Simulated ECUs
part.
§ All RX PDUs, including their ISignal groups and ISignals, are assigned to the Inspection part.

128
ConfigurationDesk Bus Manager Implementation Guide May 2024
Specifying the Behavior for Assigning Communication Matrix Elements and Adding Bus Configuration Features (Preview Version)

Column Description

Tip

The checkboxes of required higher‑level and dependent lower‑level elements are selected/cleared
automatically when you select or clear the checkbox of an element. For example:
§ If you select RX Signals for Simulated ECUs, RX Signal Groups and RX PDUs are selected as well.
§ If you clear RX PDUs for Simulated ECUs, RX Signal Groups and RX Signals are cleared as well.

Add Feature The settings of this column apply whenever communication matrix elements are assigned to a bus configuration,
regardless of the source that assigns the elements, i.e.:
§ Assignments according to the settings of the Forward Assignment column or the Create Restbus
Configuration command.
§ Manual drag & drop operations.
§ Assignments via automation.
When you select a checkbox in this column, the selected bus configuration feature is added to the applicable
communication matrix elements when you assign the elements to the respective bus configuration part.
§ Test The settings of these columns apply whenever bus configuration features are added to communication matrix
Automation elements, regardless of the way in which the features are added, i.e.:
Support § Adding features according to the settings of the Add Feature column.
§ Model § Enabling features in the bus configuration feature tables.
Access
§ Adding features via context menu or automation.
When you select a checkbox in any of these columns, test automation support/model access is enabled for all
function ports of the related feature when you add it to a communication matrix element in the respective bus
configuration part.

Tip

§ You can search and filter for elements in the Name column using the
Search name and Filter for name edit fields, respectively:
§ Search name: While you are typing, each occurrence of the entered
search string is highlighted in yellow in the Name column.
§ Filter for name: While you are typing, the Name column is filtered for
the entered filter string.
§ For each column, you can easily select and clear all checkboxes in the
context of a selected higher‑level element using the Select All and Clear
All context menu commands.

Points to note for the Inspection and Manipulation parts The Bus
Configuration Behavior table lets you select TX and RX elements for
the Inspection and Manipulation parts, even though all elements in the
Inspection part have the RX direction and all elements in the Manipulation
part have the TX direction. Nevertheless, you can select TX and RX elements for

129
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Basics on the Bus Manager

both parts because the element direction in the Bus Configuration Behavior
table refers to the element direction in the Buses Browser, not to the element
direction in the respective bus configuration part. For example:

When you now drag the selected ISignals to a bus configuration node, the
behavior is the following:
§ The selected TX and RX ISignals, including the required higher‑level elements,
are assigned to the Inspection part. However, in the Inspection part, the
direction of all elements is RX.
§ The ISignal Value feature is added to LockCarISignal and UnlockCarISignal,
whose direction is RX in the Buses Browser.

§ The Counter Signal feature is added to CurrentGearISignal and

SpeedISignal, whose direction is TX in the Buses Browser.
§ For all function ports of the Counter Signal and ISignal Value features, test
automation support and model access are enabled.

Resetting the bus You can reset the user‑defined bus configuration behavior to the default
configuration behavior behavior by clicking Reset in the Bus Configuration Behavior table. When
you do this, a dialog opens, asking you whether you really want to reset
your user‑defined configuration behavior. When you click Yes, the specified
user‑defined configuration is lost and overwritten with the default bus
configuration behavior.

130
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Copying, Cutting, and Pasting Bus Configuration Elements

Tip

If you do not want to lose a user‑defined bus configuration behavior but

only want to temporarily switch it off, you can disable it. Refer to Enabling
and disabling a user‑defined bus configuration behavior on page 126.

Restrictions for specifying For specifying a user‑defined bus configuration behavior, the following
a user‑defined bus restrictions apply:
configuration behavior § You cannot add frame capture and frame gateway elements using a
user‑defined bus configuration behavior.
§ You cannot add the Partial Network Cluster Enable, GTS Transmission
Control, GTS Time Base Data, GTS Validation, Frame Capture Data,
Frame Gateway Direction, and Filter Control features using a user‑defined
bus configuration behavior.

Related topics Basics

Assigning Communication Matrix Elements to Bus Configurations.......................................... 112

Basics on Bus Configuration Features...................................................................................... 192
Configuring Function Ports for Bus Configuration Features..................................................... 198

Copying, Cutting, and Pasting Bus Configuration Elements

Introduction You can easily transfer configured bus communication from one bus
configuration to another using copy, cut, and paste in the Bus Configurations
table.

131
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Basics on the Bus Manager

Copying or cutting selected You can copy or cut elements as follows:

elements

Copy Cut
Using … § Copy context menu command § Cut context menu command
§ Ctrl + C shortcut § Ctrl + X shortcut
Applicable § One selected bus configuration One or more selected bus configuration elements,
elements § One or more selected bus configuration elements, e.g., e.g., multiple selected PDUs.
multiple selected PDUs
Restrictions § You can copy or cut elements only in the Bus Configurations table.
§ You can copy or cut multiple selected bus configuration elements only if all of the following applies:
§ All elements are of the same element type.
§ All elements are selected in the same bus configuration.
§ You cannot cut bus configurations.

Tip

§ When you cut elements, they are grayed out in the related bus
configuration. They are removed from the bus configuration when you
paste them to another bus configuration. If you do not paste the
elements, they are not removed from the bus configuration.
§ If you select the Simulated ECUs, Inspection, Manipulation, or
Gateways node of a bus configuration, not the node itself but all its
subelements are cut.

Effects of copying or cutting Additionally involved elements When you copy or cut a bus configuration
elements element, the following elements are also involved:

Copy Cut
Involved § All subelements, including available bus configuration feature nodes and bus configuration ports.
elements § All related higher‑level elements.
§ Required elements on the same hierarchy level.
For example, if you select a dynamic‑part IPDU, the related multiplexed IPDU is also involved.
Effects All involved elements are § All subelements are cut as well.
copied as well. § In most cases, higher‑level elements and required elements on the same hierarchy
level are only copied. These elements are cut only if all of the following applies:
§ The elements have no other subelements.
§ The elements have no configurable properties themselves.
§ No bus configuration features are available for the elements.
However, if you cut a bus channel (available for the Inspection and
Manipulation bus configuration parts), these conditions do not apply: In this
case, the related communication cluster is cut as well even though it has
configurable properties.

132
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Copying, Cutting, and Pasting Bus Configuration Elements

In the following example, the Mux2S3_dyn IPDU, which is a dynamic‑part IPDU

of the Mux2 multiplexed IPDU , is cut:

Result of the cut operation:

§ All subelements of Mux2S3_dyn, i.e., the bus configuration features and
ISignals, including their bus configuration features, are cut as well.
§ The higher‑level elements, i.e., ECU_4 and the communication matrix node,
are copied.
§ The required elements on the same hierarchy level, i.e., Mux2 and the
communication controller, are copied.
§ The other dynamic‑part IPDUs (Mux2S1_dyn, Mux2S2_dyn) and the
static‑part IPDU (Mux2S1_stat) are not required by Mux2S3_dyn and are
therefore not affected by the cut operation.
For an animated graphic, refer to dSPACE Help.

133
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Basics on the Bus Manager

Tip

In bus configurations, multiplexed IPDUs, container IPDUs , and secured

IPDUs are displayed on the same hierarchy level with their related IPDUs,
i.e., the contained IPDUs, static‑/dynamic‑part IPDUs, and authentic IPDUs:

For these IPDUs, the following applies:

§ Container IPDUs, multiplexed IPDUs, and secured IPDUs do not require
their related IPDUs. Therefore, if you copy/cut a container IPDU,
multiplexed IPDU, or secured IPDU, the related contained IPDUs,
static‑/dynamic‑part IPDUs, or authentic IPDUs are not cut/copied.
§ If a secured IPDU is configured as a cryptographic IPDU, the related
authentic IPDU does not require the secured IPDU. Therefore, if you
copy/cut the authentic IPDU, the secured IPDU is not copied/cut.

Effects on configured settings All elements are copied or cut with their
configured settings, e.g., copied/cut bus configuration features keep their
configured settings when you paste them to a bus configuration.
However, the following elements and settings are not copied or cut:
§ Bus configuration features of related higher‑level elements or of required
elements on the same hierarchy level. Therefore, no bus configuration features
are added to pasted higher‑level or required elements.
For an animated graphic, refer to dSPACE Help.
§ Port mappings. Therefore, pasted function ports or event ports are not
mapped to model ports.
§ Assigned bus accesses . Therefore, bus access requests of pasted elements
are not assigned to bus accesses.

134
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Copying, Cutting, and Pasting Bus Configuration Elements

§ Manually assigned application processes. Therefore, pasted bus configurations

have no manually assigned application processes.

Tip

Because port mappings and assigned bus accesses are not copied or cut
as well, pasted bus configurations are not assigned to any application
process.

Pasting copied or Pasting elements You can paste copied or cut elements to an existing
cut elements to bus bus configuration or to one or more new bus configurations in the Bus
configurations Configurations table:

Existing Bus Configuration New Bus Configurations

§ Right‑click a bus configuration and Right‑click in an empty area of the Bus Configurations table:
select Paste Into on the context § Select Paste Into on the context menu to create a new bus configuration and paste
menu. the elements to it.
§ Select a bus configuration and press § Select Paste Multiple Into on the context menu to create multiple new bus
Ctrl + V. configurations and paste the elements to them. Refer to Paste Multiple Into (Bus
Manager) (ConfigurationDesk User Interface Reference ).

Effects when pasting elements When you paste elements to a bus

configuration, the following applies:

Aspect Description
Bus configuration The elements are automatically added to that bus configuration part (Simulated ECUs, Inspection,
parts Manipulation, Gateways) from which you copied or cut them.
Existing elements If a copied/cut element is already available in the respective bus configuration part, the element in the bus
configuration is replaced with the copied/cut element.
Names of The names of communication matrices and communication clusters in the bus configuration are not
communication affected by the paste operation.
matrices and clusters When you paste elements of a communication matrix or a communication cluster to a bus configuration
that already has elements of that matrix/cluster assigned, the name of the matrix/cluster in the bus
configuration remains unchanged.
Frame gateways and Frame gateways and frame captures can only be identified by their names. If you paste frame gateways or
frame captures captures to a bus configuration, they cannot unambiguously be identified in the following cases:
§ You copied/cut frame gateways or captures with identical names.
§ The bus configuration contains at least two frame gateways or captures whose names are identical to
the pasted frame gateways/captures.
In these cases, the pasted frame gateways/captures are added to the bus configuration without replacing
existing frame gateways/captures. If required, the names of the pasted frame gateways/captures are
extended with Copy (<n>). However, the paste operation does not resolve the duplicate names.
Therefore, conflicts occur.

Limitations For copying, cutting, and pasting elements, some limitations apply. Refer to
Limitations for Bus Configuration Handling on page 531.

135
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Basics on the Bus Manager

Related topics Basics

Accessing Bus Manager Features via the ConfigurationDesk Automation Interface.................. 152

Using Event‑Controlled Timings for Transmitting PDUs

Introduction The Bus Manager supports event‑controlled timings according to AUTOSAR.

Refer to Aspects of Event‑Controlled Timings on page 70.

To transmit PDUs according to event‑controlled timings, you have to enable

the use of the transfer property. Additionally, you can specify event‑controlled
timings and configure the transfer property.

Enable the use of the transfer Each bus configuration provides the Use transfer property property. It lets you
property enable the use of the transfer property, which is available for ISignals and ISignal
groups.

If set to True, the setting of the transfer property is considered for transmitting
PDUs, and the PDUs can be transmitted according to event‑controlled timings.
Thus, depending on the specifications in the communication matrix, the
transmission of a PDU can be triggered in two ways: By ISignals and ISignal
groups that are included in the PDU and/or by a cyclic timing.

By default, the use of the transfer property is disabled, i.e., Use transfer
property is set to False.

Note

If Use transfer property is set to True, all ISignals and ISignal groups
for which the transfer property is specified can trigger the transmission
of their related PDUs. If many ISignals and ISignal groups can trigger the
transmission, the run‑time performance might be reduced. Therefore, it is
recommended to set the property to True only if you want to trigger the
transmission of PDUs according to the setting of the transfer property.

136
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Triggering the Transmission of Multiplexed IPDUs

Tip

§ Even if no event‑controlled timing is specified for a PDU, the included

ISignals and ISignal groups can trigger the transmission of the PDU if Use
transfer property is set to True. However, it depends on the setting of
the specific transfer property whether an ISignal/ISignal group triggers the
transmission.
§ In addition to cyclic and event‑controlled timings that are specified in
the communication matrix, the transmission of PDUs can be triggered by
the PDU Cyclic Timing Control, PDU Trigger, and Frame Access bus
configuration features. Refer to Overview of Bus Configuration Features
on page 195.

Specifying event‑controlled If the communication matrix does not specify an event‑controlled timing for an
timings and configuring the ISignal IPDU or extended multiplexed IPDU , you can add it. Refer to Adding
transfer property Event‑Controlled Timing Elements to IPDUs on page 401.

Moreover, you can specify user-defined settings for the following communication
matrix elements of PDUs, ISignal groups, and ISignals:
§ PDUs: Number of repetitions, repetition period, and minimum delay time of an
event‑controlled timing
Refer to Configurable Settings of PDUs on page 414.
§ ISignal groups and ISignals: Transfer property
Refer to Configurable Settings of ISignal Groups on page 425 and
Configurable Settings of ISignals on page 427, respectively.

Adding an event‑controlled timing or specifying user-defined settings for an

element changes all instances of the related PDU, ISignal group, and/or ISignal
in the communication matrix and all bus configurations. Refer to Basics on
Modifying Communication Matrices on page 391.

Limitations for For using event‑controlled timings, some limitations apply. Refer to Limitations
event‑controlled timings for transmitting PDUs according to event‑controlled timings on page 520.

Triggering the Transmission of Multiplexed IPDUs

Introduction The Bus Manager supports multiplexed IPDUs according to AUTOSAR. Refer to
Aspects of Multiplexed IPDUs on page 63.

With the Bus Manager, the transmission of multiplexed IPDUs can be triggered
by the dynamic‑part IPDUs or the static‑part IPDU as follows:
§ Via cyclic timings that are specified in the communication matrix.
To dynamic‑part IPDUs, these timings apply automatically. For the static‑part
IPDU, you can enable and disable the use of the cyclic timings. Refer to Using
cyclic timings of the communication matrix for static‑part IPDUs on page 138.

137
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Basics on the Bus Manager

§ Via event‑controlled timings that are specified in the communication matrix.

Refer to Using Event‑Controlled Timings for Transmitting PDUs on page 136.
§ Via the PDU Cyclic Timing Control feature. Refer to Controlling the Cyclic
Timing of CAN PDUs on page 243.
§ Via the PDU Trigger feature. Refer to Specifying User-Defined Triggers for
Transmitting PDUs on page 246.

If the static‑part IPDU triggers the transmission of the multiplexed IPDU, the
dynamic‑part IPDU that is also transmitted depends on various factors. Refer to
Transmitted dynamic‑part IPDU if the static‑part IPDU triggers the transmission on
page 138.

Using cyclic timings of the Each bus configuration provides the Use predefined cyclic timings of
communication matrix for static‑part IPDUs property. This property lets you enable and disable the use
static‑part IPDUs of cyclic timings that are specified in the communication matrix for static‑part
IPDUs.

If set to True, cyclic timings that are specified in the communication matrix
for static‑part IPDUs are considered for transmitting the IPDUs and their related
multiplexed IPDUs. If set to False, these cyclic timings are not considered.

By default, these cyclic timings are considered, i.e., Use predefined cyclic
timings of static‑part IPDUs is set to True.

Transmitted dynamic‑part In general, if the static‑part IPDU triggers the transmission of the related
IPDU if the static‑part IPDU multiplexed IPDU, the dynamic‑part IPDU that is also transmitted depends on
triggers the transmission the following:

Condition Transmitted Dynamic‑Part IPDU

The multiplexed IPDU is transmitted for the The dynamic‑part IPDU that is configured as the initial dynamic part.
first time. If the communication matrix does not specify an IPDU as the initial dynamic part,
The executable application is restarted the Bus Manager uses the IPDU with the smallest selector field value as the initial
and the Initial value usage property of dynamic part.
the bus configuration is set to At every For multiplexed IPDUs that are assigned to a bus configuration, you can configure the
application start. initial dynamic part. Refer to Configurable Settings of PDUs on page 414.

138
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Working with User Code

Condition Transmitted Dynamic‑Part IPDU

The multiplexed IPDU is not transmitted The dynamic‑part IPDU that was transmitted with the previous transmission of the
for the first time, i.e., it was transmitted multiplexed IPDU.
before.
The executable application is restarted
and the Initial value usage property of
the bus configuration is set to At first
application start.

Moreover, you can use the PDU Selector Field feature to specify a specific
dynamic‑part IPDU that is transmitted when the static‑part IPDU triggers the
transmission of the multiplexed IPDU. Refer to Accessing the Selector Field Value
of Multiplexed IPDUs on page 266.

Limitations for transmitting For transmitting multiplexed IPDUs, some limitations apply. Refer to Limitations
multiplexed IPDUs for Communication Matrices and Communication Standards on page 519.

Working with User Code

Introduction When you configure bus communication with the Bus Manager, you can work
with user code. You can use user code to implement user-specific algorithms in
executable applications .

User code and the When you work with user code, you also need the functionality of the Bus
DsBusCustomCode interface Custom Code interface.

User code User code is C code or C++ code that contains user-specific
algorithms. You can use user-specific algorithms to provide additional
functionality to the Bus Manager, for example, for calculating checksum
or counter signal values or generating authentication information in secure
onboard communication (SecOC) scenarios. A user code implementation in
ConfigurationDesk consists of one or more source files (*.c, *.cpp) and optional
include files (*.h, *.hpp), such as header files.

Bus Custom Code interface The Bus Custom Code interface is a C-based
API interface provided by dSPACE. It is required to implement user code and
its functionalities in executable applications. In general, the Bus Custom Code
interface lets you do the following:
§ Specify a user code ID for each user code implementation. This ID is
required to unambiguously reference specific user code implementations in
bus configurations.
§ Initialize the functionalities provided by user code in the executable
application.
§ Exchange data between the user code and the Bus Manager, for example,
to access properties of secured IPDUs or write calculated checksum values to
ISignals of a PDU.

139
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Basics on the Bus Manager

For more information on the Bus Custom Code interface, and on the required
content and structure of user code implementations, refer to Bus Custom Code
Interface Handling .

Implementing user code To implement user code in ConfigurationDesk applications, you have to add the
in ConfigurationDesk required user code implementations to build configuration sets and reference the
applications user code in bus configurations.

Adding user code implementations to build configuration sets You can

add user code implementations to a ConfigurationDesk application via properties
of build configuration sets. When you select a build configuration set in the
Build Configuration table, you can access the relevant properties in the
Properties Browser, as shown in the following example.

Tip

If the Build Configuration table is closed, you can open it on the View
ribbon via Show Panes.

Via the properties of the Bus Custom Code category of each build configuration
set, you can add one or more user code implementations. The related user code
applies to all application processes that are assigned to this build configuration
set. Application processes of other build configuration sets are not affected by
the user code.
When you build a real-time application or generate bus simulation containers,
the user code is included in the real-time application or bus simulation
containers, respectively.
Via the Bus Custom Code category, you can add the following files:
§ Source files (*.c; *.cpp)
§ Include files (*.h; *.hpp), such as header files

140
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Working with User Code

§ Non-build files (*.*), such as copyright information, read-me files, or

configuration files.

Tip

Non-build files are included only in bus simulation containers but not in
real-time applications. For example, if you use bus simulation containers
to archive bus communication, you can add non-build files to include
the information that is required to ensure that the archives comply with
applicable law.

For more information on build configuration sets, refer to Specifying Options for
the Build Process (ConfigurationDesk Real-Time Implementation Guide ).
For more information on the properties of the Bus Custom Code category, refer
to Build Configuration Table (ConfigurationDesk User Interface Reference ).

Referencing user code in bus configurations You can add various user
code implementations to a ConfigurationDesk application. This allows you to use
different user code implementations for different use cases, e.g., to implement
secure onboard communication or provide checksum algorithms to be used with
the PDU User Code feature.
To unambiguously reference specific user code implementations in bus
configurations, user code IDs are used. Exactly one source file (*.c, *.cpp)
of a user code implementation must specify a unique user code ID via the
DS_BUS_CUSTOM_CODE_FEATURE_NAME definition. You have to reference the
specified ID in the required user code ID property of a bus configuration. For
more information, refer to:
§ Implementing Secure Onboard Communication in Executable Applications on
page 143
§ Applying User Code to PDUs on page 254
However, to use the related user code, the bus configuration must be assigned
to an application process of the build configuration set to which you added the
referenced user code implementation.

Restrictions for
Restrictions for file and path names
implementing user code
in ConfigurationDesk § Names of include files must be unique
applications The names of include files (*.h; *.hpp) must be unique. This even involves
include files that are internally used by the Bus Manager.
For example, among others, the Bus Manager internally uses file names such
as StdTypes.h, SecOC.h, SecOCTypes.h, and Config.h. Your custom code
implementation must not contain any include files with such internally used
file names.

Tip

To ensure that you do not accidentally use include file names that are
already used by the Bus Manager, add user‑defined prefixes or postfixes
to the names of your include files.

141
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Basics on the Bus Manager

§ No support of special characters

Do not use special characters, such as { , }, or specific Unicode characters, such
as German umlauts, Japanese characters, etc., in file and path names. Instead,
use only the following characters:
§ A-Z, a-z, 0-9
§ Underscores _
§ Minus -
§ Dots .
§ Parentheses ()

Note

You must manually ensure that the file and path names comply with these
restrictions. If a file or path name does not comply with the restrictions, the
following applies:
§ When you build a real-time application, the build process is either aborted
or the run‑time behavior of the resulting real‑time application might be
unexpected.
§ When you generate bus simulation containers, BSC files are generated
but it might not be possible to integrate the BSC files in an executable
application .

Restrictions for application processes when working with user

code implementations Regarding user code implementations and build
configuration sets, the following principles apply:
§ User code implementations contain functions of the
DsBusCustomCode_SecOC and/or DsBusCustomCode_PduUserCode module
of the Bus Custom Code interface.
§ All user code implementations that are added to one build configuration set
apply to all application processes that are assigned to this build configuration
set.
These principles result in the following restriction: Each application process that
is assigned to a build configuration set must use all the modules, i.e., the
DsBusCustomCode_SecOC and/or DsBusCustomCode_PduUserCode module,
that are contained in any user code implementation of the build configuration
set.

Note

You must manually ensure that each application process uses all required
modules. If an application process does not use a required module, the
following applies:
§ When you build a real-time application, the build process is aborted.
§ When you generate bus simulation containers, a BSC file is generated for
the application process but this file is invalid.

An application process uses the modules, for example, in the following cases:
§ DsBusCustomCode_SecOC module: SecOC support is enabled for at least one
bus configuration of the application process.

142
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Implementing Secure Onboard Communication in Executable Applications

§ DsBusCustomCode_PduUserCode module: The PDU User Code feature is

added to at least one bus configuration of the application process.
For more information on the modules, refer to Basic Principles of the Bus Custom
Code Interface (Bus Custom Code Interface Handling ).

Related topics Basics

Restrictions for Working with the Bus Custom Code Interface (Bus Custom Code
Interface Handling )

Implementing Secure Onboard Communication in Executable Applications

Introduction The Bus Manager supports secure onboard communication (SecOC) according
to AUTOSAR. Refer to Aspects of Secure Onboard Communication (SecOC) on
page 67.

To implement secure onboard communication in executable applications , you

have to enable SecOC support and provide the OEM-specific implementation for
generating and/or verifying authentication information via user code . For basic
information on user code, refer to Working with User Code on page 139.

Enabling SecOC support Each bus configuration provides an Enable SecOC property that lets you enable
the support of secure onboard communication for the bus configuration.

§ If set to True, the bus configuration supports secure onboard communication.

§ If set to False, the bus configuration does not support secure onboard
communication. This is the default state.

Effects of enabled SecOC If the Enable SecOC property is set to True, the bus configuration supports
support secure onboard communication on the basis of the OEM‑specific implementation
that is provided by the user code. You have to reference the respective user
code via a user code ID. Refer to Providing user code for secure onboard
communication on page 144.

143
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Basics on the Bus Manager

When you do this, the following applies:

Secured IPDUs … Effects

Transmitted by this bus configuration The secured IPDUs secure the payload of the related authentic IPDUs. The Bus
Manager generates the required authentication information according to the
OEM-specific implementation.
Received by this bus configuration The authentication information of the secured IPDUs can be verified according to
the OEM-specific implementation.
Transmitted via the simulation platform by any The authentication information of the secured IPDUs can be manipulated before
member of the communication cluster , e.g., the IPDUs are transmitted on the bus.
in a data replay scenario

Effects of disabled SecOC If Enable SecOC is set to False, the bus configuration does not support secure
support onboard communication. No user code is used, regardless of whether it is
referenced by a user code ID. This has the following effects:

Secured IPDUs … Effects

Transmitted by this bus For the secured IPDUs, no authentication information is generated and the payload of the related
configuration authentic IPDUs is not secured. Depending on whether the secured IPDUs are configured as
cryptographic IPDUs, this results in the following:
§ Secured IPDUs configured as cryptographic IPDUs:
The secured IPDUs are not transmitted. Instead, only the related authentic IPDUs are transmitted.
§ Secured IPDUs configured as non‑cryptographic IPDUs:
§ The payload of the related authentic IPDUs is directly included in the secured IPDUs.
§ The bits of the secured IPDUs that are reserved for the authentication information are unused.
These bits are filled with the related bit pattern for unused bits, i.e., the Bus Manager's default
bit pattern 0 or the bit pattern that is specified for each affected secured IPDU.
Received by this bus The authentication information of the secured IPDUs cannot be verified.
configuration
Transmitted via the The authentication information of the secured IPDUs cannot be manipulated before the IPDUs are
simulation platform by transmitted on the bus.
any member of the
communication cluster, e.g., Note
in a data replay scenario
If bus configuration features that manipulate authentication information are enabled at run
time, the resulting bus communication is undefined.

Providing user code for secure To use secure onboard communication at run time, you have to provide
onboard communication the required OEM-specific implementation for generating and/or verifying
authentication information via user code as follows:
1. Specify the user code, i.e., the implementation for generating and/or
verifying authentication information, according to your requirements in
C code (*.c, *.h) or C++ code (*.cpp, *.hpp).
2. Extend the user code by functions for initializing secure onboard
communication and for exchanging data with the Bus Manager, such as
accessing properties of secured IPDUs or writing generated authentication
information to secured IPDUs. Use functions of the DsBusCustomCode and

144
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Implementing Secure Onboard Communication in Executable Applications

DsBusCustomCode_SecOC modules of the Bus Custom Code interface for

this purpose.
For more information, refer to Bus Custom Code Interface Handling .
3. Add the code files, i.e., the user code implementation , to the
ConfigurationDesk application. Refer to Implementing user code in
ConfigurationDesk applications on page 140.
4. Reference the user code in a bus configuration. To do so, type the
user code ID as specified in the user code implementation into the edit
field of the SecOC user code ID property of the bus configuration.
In the user code implementation, the user code ID is specified via the
DS_BUS_CUSTOM_FEATURE_NAME definition in the related source file (*.c,
*.cpp).

Tip

§ The user code applies only to the referencing bus configuration. In

each bus configuration, you can reference exactly one user code
implementation for secure onboard communication. However, you
can reference the same user code in multiple bus configurations
or use different user code implementations for different bus
configurations.
§ With this step, secured IPDUs that are transmitted by the bus
configuration, i.e., TX secured IPDUs that are assigned to the
Simulated ECUs part, are involved in secure onboard communication
and the Bus Manager generates the required authentication
information.

5. If your user code contains specifications for verifying received authentication

information, add the SecOC bus configuration feature to the RX secured
IPDUs whose authentication information you want to verify. Refer to
Verifying the Authentication Information of Received Secured IPDUs on
page 268.

Tip

To manipulate authentication information, you can use the SecOC

Authenticator Invalidation and/or SecOC Freshness Overwrite
Value bus configuration features. These features do not require
manipulation‑specific specifications in the user code. Refer to
Invalidating the Authenticator of Secured IPDUs on page 271 and
Overwriting the Freshness Value of Secured IPDUs on page 274,
respectively

145
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Basics on the Bus Manager

Limitations For implementing secure onboard communication in executable applications,

some limitations apply. Refer to Limitations for secure onboard communication
on page 522.

Implementing Partial Networking in Executable Applications

Introduction The Bus Manager supports partial networking according to AUTOSAR. Refer to
Aspects of Partial Networking on page 74.

To implement partial networking in executable applications , the following

preconditions must be fulfilled:
§ The communication matrix must specify required partial networking settings
such as the assignment of ISignal IPDU groups to partial network clusters.
§ You must use blocks from the AUTOSAR Network Management Solution, a
Simulink®‑based solution provided by dSPACE. For more information, contact
dSPACE Support (www.dspace.com/go/supportrequest).

Tip

The CAN function block provides partial networking properties. However, to

implement partial networking with the Bus Manager, it is not necessary to
enable partial networking for the CAN function block.

Accessing partial networking When you add a communication matrix that specifies partial networking settings
elements to the Buses Browser, the Buses Browser does not display any partial
networking elements.

Instead, when you assign any communication matrix element to the Simulated
ECUs part of a bus configuration, all partial network clusters that are specified
in the communication matrix are assigned automatically. This applies regardless
of whether the communication matrix element is a member of a partial network
cluster. The partial network clusters are grouped below the Partial Network
Clusters node, which is available for the communication matrix in the bus
configuration.

146
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Implementing Partial Networking in Executable Applications

Other partial networking elements such as ISignal IPDU groups cannot be

accessed in the Bus Manager.

Naming of partial network When importing the communication matrix, the names of the partial network
clusters clusters are derived from attributes of the PNC-MAPPING class according to the
following rules:
§ If the communication matrix specifies a value for the SHORT-LABEL attribute,
this is used as the name of the partial network cluster.
§ If the communication matrix does not specify a value for the SHORT-LABEL
attribute but for the SHORT-NAME attribute, the SHORT-NAME value is used as
the name of the partial network cluster.
§ If the communication matrix does not specify values for the SHORT-LABEL and
the SHORT-NAME attributes, the name is generated on the basis of the PNC-
IDENTIFIER attribute and according to the following naming convention:
PNC<value of PNC-IDENTIFIER>.

If required, the names of partial network clusters are truncated to

128 characters. The names of partial network clusters must be unique for each
communication matrix in the bus configuration. If the names are not unique,
conflicts occur. Refer to Handling Bus Manager-Related Conflicts on page 163.

Including partial network Partial network clusters that are available for a bus configuration are not
clusters in real-time automatically included in real-time applications and bus simulation containers.
applications and bus To include a partial network cluster in a real-time application or in bus simulation
simulation containers containers, you have to add the Partial Network Cluster Enable feature to the
partial network cluster. Refer to Including Partial Network Clusters in Executable
Applications and Enabling and Disabling the Clusters on page 321.

If you do not add the Partial Network Cluster Enable feature to a partial
network cluster, the partial network cluster is ignored during the build process
or the generation of bus simulation containers. At run time, the affected bus
communication is processed as if the communication matrix does not specify the
related partial network cluster.

147
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Basics on the Bus Manager

Using NMPDUs for partial In general, partial network clusters are enabled via NMPDUs. When you
networking implement partial networking by using the Bus Manager, you have to provide
the required NMPDUs to a Simulink model that uses blocks from the AUTOSAR
Network Management Solution. These blocks provide the functionality to enable
partial network clusters. For this purpose, the Bus Manager can transmit
NMPDUs that are provided by the blocks of the AUTOSAR Network Management
Solution on the bus.
§ To provide the required NMPDUs to the Simulink model, you can use the PDU
Raw Data feature or capture the raw data of the related frames via frame
captures, for example. Refer to Accessing the Payload of PDUs in Raw Data
Format on page 240 or Capturing CAN Frames on page 171, respectively.
§ To transmit NMPDUs that are provided by the Simulink model, you can
use the PDU Trigger feature. Refer to Specifying User-Defined Triggers for
Transmitting PDUs on page 246.

Restrictions for implementing For implementing partial networking in executable applications, the following
partial networking in restrictions apply:
executable applications § For simulating partial networking at run time, you must work with a Simulink
behavior model that uses blocks from the AUTOSAR Network Management
Solution.
§ Partial network clusters can neither be deleted from nor renamed in bus
configurations.
§ No partial-networking-specific properties are available. Therefore, you cannot
identify which PDUs are assigned to a partial network cluster, for example.
§ If you replace an assigned communication matrix in a bus configuration, the
following applies:
§ All partial network clusters of the newly assigned communication matrix are
added to the bus configuration, regardless of whether they were available in
the previously assigned communication matrix.
§ Obsolete partial network clusters are moved to the deprecated node of
the communication matrix but available Partial Network Cluster Enable
features are deleted. The related mappings to the Simulink model are lost.

Additionally, some limitations apply for implementing partial networking in

executable applications. Refer to Limitations for Communication Matrices and
Communication Standards on page 519.

Simulating PDU Gateways (Preview Version)

Introduction The Bus Manager supports PDU gateways according to AUTOSAR. Refer to
Aspects of PDU Gateways on page 76.

To simulate PDU gateways, you have to enable the PDU gateway support. When
you do this, you can simulate PDU gateways for PDUs that are assigned to the
Simulated ECUs part of a bus configuration.

148
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Simulating PDU Gateways (Preview Version)

PDU gateways must be specified in the communication matrix. If required, you

can specify user‑defined PDU gateways by modifying communication matrices.
For more information on user‑defined PDU gateways, refer to Specifying User-
Defined PDU Gateways (Preview Version) on page 404.

Note

The current version of simulating PDU gateways is a preview version. Refer

to Providing preview versions of Bus Manager features on page 19.

Enabling PDU gateways Each bus configuration provides the Enable PDU gateway property, which lets
you enable PDU gateway simulation for the related bus configuration.

If set to True, PDU gateways that are configured in the bus configuration are
considered for simulating bus communication. If set to False, PDU gateways are
ignored at run time, even if they are configured in the bus configuration. This is
the default state.

Supported bus systems for When PDU gateways are enabled for a bus configuration, the bus configuration
PDU gateways supports PDU gateways between classic CAN, CAN FD, and LIN communication
clusters in any combination, i.e.:

PDU Data Can be Transferred …

From To
Classic CAN Classic CAN, CAN FD, and/or LIN
CAN FD Classic CAN, CAN FD, and/or LIN
LIN Classic CAN, CAN FD, and/or LIN

Simulating PDU gateways To simulate a PDU gateway, you have to assign the respective source PDUs (RX
PDUs) and target PDUs (TX PDUs) to the Simulated ECUs part of the same bus
configuration, as shown in the following example.

149
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Basics on the Bus Manager

Tip

§ The Gateway source PDUs property and column display the source PDUs
that are specified for the target PDU in the communication matrix.
§ If the column is not available, you can add it via the Column Chooser.
Refer to Bus Configuration Tables on page 103.

At run time, PDU gateways are always simulated when you assign the source and
target PDUs to the Simulated ECUs part of the same bus configuration. If you
do not want to simulate a PDU gateway, you can do the following:
§ Set the Enable PDU gateway property of the bus configuration to False.
However, this disables all PDU gateways that are configured for this bus
configuration.
§ Assign the source and target PDUs to different bus configurations.
§ In case of a user‑defined PDU gateway, you can remove the user‑defined
gateway from the communication matrix. Refer to Removing user‑defined PDU
gateways on page 406.

Points to note regarding The Gateway source PDUs property and column display the source PDUs with
source PDUs the following syntax: PDU name [communication matrix\communication
cluster]. This helps you to unambiguously identify a source PDU:
§ In case of user‑defined PDU gateways, a source PDU can be specified in any
communication matrix that is available in the Buses Browser.
§ For PDU gateways, only the communication cluster on which a source PDU is
received is relevant. The related receiving ECUs are not relevant.

However, to simulate a PDU gateway at run time, the Bus Manager has to
simulate an ECU that receives the source PDU. If a source PDU can be received
by multiple ECUs on the same communication cluster, it is sufficient to assign the
source PDU in the context of only one ECU to the bus configuration. Refer to the
following example.

Source PDU GearboxInfo

Communication cluster of source PDU CanPowertrainCluster
Receiving ECUs § EngineEcu
§ CentralGatewayEcu
Target PDU CarLockControlIPdu

150
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Simulating PDU Gateways (Preview Version)

Configuration in Bus Configuration (1):

GearboxInfo is assigned to the Simulated ECUs part in the context of EngineEcu:

Run‑time behavior:
Each time GearboxInfo is transmitted on CanPowertrainCluster, e.g., by a real ECU that is connected to the simulator, Bus
Configuration (1) receives GearboxInfo and transfers its data to CarLockControlIPdu.

Run‑time behavior of PDU For PDU gateways, the following run‑time behavior applies:
gateways § When a source PDU is received on the bus, its raw data is written to the
related target PDUs.
§ If multiple source PDUs are configured for one target PDU, the raw data of the
source PDU that is received last is written to the target PDU.
§ If the lengths of the source PDU and the target PDU differ, the following
applies:
§ If the source PDU is longer than the target PDU, only the data of the bytes
that fit into the target PDU is written to the target PDU.
§ If the source PDU is shorter than the target PDU, the unused bytes of
the target PDU are filled with the unused bit pattern that is specified for
the target PDU. Refer to Specifying bit patterns for unused PDU bits on
page 418.

§ In the following cases, the transferred raw data is overwritten in the target
PDU before the PDU is transmitted on the bus:

Case Description
End‑to‑end‑protected The calculated end‑to‑end protection information replaces the raw data in the respective bytes.
ISignal groups
Bus simulation features Bus simulation features apply after the raw data was written to the target PDU.
If you add bus simulation features that write data to the payload of the target PDU, e.g., the PDU
User Code or ISignal Value feature, the following applies: If test automation support or model
access is enabled for function ports, the transferred raw data is replaced in the respective bytes.
For example, the ISignal Value feature is added to an ISignal of the target PDU. Model access and
test automation support are enabled for the Value function port. In this case, the raw data of the
respective PDU bytes is replaced: It is either replaced with a value that is provided by a mapped
behavior model or set via experiment software, or with the initial value of the function port.

151
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Basics on the Bus Manager

Case Description

Bus configuration
Target PDU (TX PDU) Target PDU (TX PDU)
Raw data byte 0 ISignal 1
ISignal Value feature:
Raw data byte 1
PDU gateway: Data set via Value
Write raw data Raw data byte 2 Apply bus function port
to target PDU simulation features
Receive source PDU Raw data byte 3 Raw data byte 3 Transmit target PDU
Raw data byte 4 Raw data byte 4
Raw data byte 5 Raw data byte 5
Raw data byte 6 Raw data byte 6
Raw data byte 7 Raw data byte 7

Bus manipulation features Bus manipulation features apply immediately before a PDU is transmitted on the bus.
If you configure the target PDU also in the Manipulation part of any bus configuration, the
following applies: When a bus manipulation feature that writes data to the PDU payload, e.g., the
PDU User Code or Overwrite ISignal Value feature, is enabled at run time, the transferred raw data
of the respective bytes is overwritten.

Restrictions for simulating The reception of a source PDU does not trigger the transmission of the related
PDU Gateways target PDUs. Instead, the transmission of the target PDUs must be triggered by
other means, for example, by timings that are specified in the communication
matrix or by using bus configuration features.

Moreover, some limitations apply for PDU gateways. Refer to Limitations for PDU
gateways on page 524.

Related topics Basics

Accessing Bus Manager Features via the ConfigurationDesk Automation Interface.................. 152

Accessing Bus Manager Features via the ConfigurationDesk Automation

Interface

Introduction You can automate Bus Manager features via the ConfigurationDesk automation
interface.

Accessing Bus Manager The automation interface lets you perform tasks such as accessing the following
features Bus Manager features:
§ Adding bus configurations and communication matrices to a
ConfigurationDesk application.
§ Assigning and removing communication matrix elements to and from bus
configurations.
§ Configuring bus configurations.

152
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Accessing Bus Manager Features via the ConfigurationDesk Automation Interface

§ Copying and pasting entire bus configurations, or copying, cutting, and

pasting individual bus configuration elements.
§ Specifying user-defined settings for communication matrix elements and
exporting overviews of the modified communication matrix elements.
§ Replacing the currently assigned communication matrix of a bus configuration
by another communication matrix.
§ Generating bus simulation containers that contain bus configurations of the
ConfigurationDesk application.

Accessing elements via XPath In addition to using standard queries to access elements, you can access
expressions elements of the Bus Manager by using XPath expressions. For example, you can
use XPath expressions to access an ISignal of a bus configuration directly without
having to go through the complete hierarchy of the bus configuration. You can
access elements by using regular expressions.

To access Bus Manager elements via XPath, the XPath expressions must comply
with XPath 1.0. Other XPath versions are not supported.

Further information § For details on automating Bus Manager features and accessing Bus Manager
elements via XPath expressions, refer to Automating Bus Manager Features
(ConfigurationDesk Automating Tool Handling ).
§ For examples of automating Bus Manager features, refer to Examples of
Automating Bus Manager Features (ConfigurationDesk Automating Tool
Handling ).
§ For a detailed description of the ConfigurationDesk automation interface, refer
to ConfigurationDesk Automating Tool Handling .

Tip

Moreover, the descriptions of the Bus Manager and ConfigurationDesk

commands provide information on whether you can automate the related
command, as shown in the following example.

You can access the descriptions by pressing F1 when you have a command
in focus or browse the command descriptions in the ConfigurationDesk
User Interface Reference , for example.

153
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Basics on the Bus Manager

154
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Handling Bus Access Requests

Handling Bus Access Requests

Where to go from here Information in this section

Basics on Bus Access Requests............................................................... 155

Specifying the Hardware Access............................................................. 157

Basics on Bus Access Requests

Introduction Bus access requests are generated for communication clusters and CAN frame
gateways of bus configurations.

Bus access request and bus Bus access requests contain the requirements regarding the bus access.
access
Bus access request Each communication cluster that is assigned to the
Simulated ECUs, Inspection, or Manipulation part of a bus configuration
requires access to a bus. This request is represented by a bus access request. The
bus access request contains the requirements for the bus channels that are to be
used for the cluster's bus communication at run time.
Additionally, each frame gateway that is added to the Gateways part of a bus
configuration generates two bus access requests. These bus access requests are
required to specify the bus channels for exchanging bus communication.

Bus access Communication clusters and CAN frame gateways of a bus

configuration can access bus channels of real-time hardware only via a bus
access.
A bus access defines a run-time communication cluster. To be a member of a
run-time communication cluster, a bus access request must be assigned to a bus
access.
In ConfigurationDesk, you can use a bus function block (CAN, LIN) to implement
a bus access. Via the hardware resource of the bus function block, a bus access

155
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Handling Bus Access Requests

request can access real-time hardware. Refer to Specifying the Hardware Access
on page 157.
The implemented bus accesses affect only real-time applications. If you generate
bus simulation containers, the bus accesses are not included in the generated
BSC files but only the bus access requests. Refer to Availability of bus access
requests in bus simulation containers on page 375.

Accessing bus access requests You can access all bus access requests of the active ConfigurationDesk
application via the Bus Access Requests table. Additionally, the table provides
access to the CAN and LIN function blocks that are used to implement the bus
accesses.

When you select a bus access request, the Properties Browser displays the
requirements it places on the bus access.

Names of bus access requests By default, each bus access request is generated with a unique name according
to the following scheme:

§ Names of bus access requests generated for elements assigned to the

Simulated ECUs, Inspection, or Manipulation part of a bus configuration:
Bus Access Request [<bus configuration name>\<bus configuration part name>\<communication cluster name>\name of
communication matrix in bus configuration>]

§ Names of bus access requests generated for frame gateways of the Gateways
part of a bus configuration:
Bus Access Request [<bus configuration name>\<frame gateway name>\<communication cluster name>]

156
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Specifying the Hardware Access

If you change a name that is used for the naming scheme, e.g., the name
of a bus configuration, the names of the affected bus access requests are
automatically synchronized. Therefore, the generated names unambiguously
identify the element for which a bus access request is generated.

Instead of using the generated names, you can specify user-defined names for
bus access requests.

Specifying user-defined If required, you can specify user-defined names for bus access requests.
names for bus access requests
To specify a user-defined name for a bus access request, you have to select the
Manual naming checkbox of the bus access request. Then, you can specify a
user-defined name via the Name property.

If you specify user-defined names for bus access requests, note the following:
§ The names of bus access requests must be unique in a ConfigurationDesk
application.
§ When you select the Manual naming checkbox of a bus access request, the
automatic synchronization of the name is disabled, regardless of whether you
change the generated name.
§ When you clear the Manual naming checkbox of a bus access request, the
name is synchronized immediately. Any changes you made to the generated
name are lost.

Specifying the Hardware Access

Introduction To implement bus communication in a real-time application, you have to specify

the hardware access for each bus access request .

Accessing real-time hardware Specifying the hardware access for a bus access request consists of two parts:
§ Bus access assignment
Assigns the bus access request to a bus access , i.e., to a suitable bus
function block (CAN, LIN).
You can assign multiple bus access requests to one bus access. Bus
access requests that are assigned to the same bus access form a run-time
communication cluster.

157
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Handling Bus Access Requests

§ Hardware resource assignment

Assigns a hardware resource to the bus function block.
The assigned real-time hardware is used for the bus communication during run
time.

The following illustration is an example of seven bus access requests that access
bus channels of real-time hardware via three bus accesses.
Bus access 1
Bus access Hardware
CAN1
assignment resource
assignment

Bus access 2 Real-time hardware

Hardware
CAN2 resource Ch 1
assignment
Bus access Ch 2
assignment Ch 3

Bus access 3
Bus access Hardware
LIN1
assignment resource
assignment

For more information on hardware resource assignment, refer to Assigning

Hardware Resources to Function Blocks (ConfigurationDesk Real-Time
Implementation Guide ).

In addition to the hardware resource assignment, you can configure further

settings via the bus function blocks (CAN, LIN). For example, you can specify
hardware-dependent settings or enable CAN bus statistics. For an overview of
the configurable settings, refer to:
§ Configuring CAN Bus Properties in CAN Function Blocks on page 361
§ Configuring LIN Bus Properties in LIN Function Blocks on page 362

Methods for specifying the There are two methods for specifying the bus access assignment:
bus access assignment

Method Description
Using new bus You can add a new suitable bus function block (CAN, LIN) to the signal chain and assign the selected bus
function blocks access request to the function block via one command. In this case, the bus function block is named according
to the related cluster, and default settings such as the baud rate are taken from the communication matrix .
Using existing bus When you use an existing bus function block, you have to ensure that the settings of the bus function block
function blocks and the related cluster match (e.g., the baud rates). If the settings differ, conflicts might occur. Refer to Basics
on Bus Manager-Related Conflicts on page 163.

You can assign bus access requests to bus accesses manually or let the Bus
Manager perform the assignment automatically. If you let the Bus Manager
assign bus access requests to bus accesses automatically, the Bus Manager
assigns the bus access requests to new and/or existing bus function blocks in
one step.

You can also use the ConfigurationDesk automation interface to assign bus
access requests to bus accesses. However, there are no Bus Manager‑specific
automation relations for performing the assignment. Instead, you can use
common ConfigurationDesk relations. For an example, refer to Examples

158
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Specifying the Hardware Access

of Automating Bus Manager Features (ConfigurationDesk Automating Tool

Handling ).

Regarding the bus function blocks, some limitations apply for specifying the bus
access. Refer to Limitations for Bus Configuration Handling on page 531.

Assigning bus access requests You can let the Bus Manager automatically assign bus access requests that are
to bus accesses automatically not assigned to a bus function block (CAN, LIN) yet to suitable bus function
blocks. When you do this, the Bus Manager checks for each relevant bus access
request if a suitable bus function block already exists in the signal chain.

No suitable bus function block available If no suitable bus function block

is available in the signal chain yet, the Bus Manager adds a new bus function
block to the signal chain and assigns the related bus access request to this block.
Bus access requests that result from the same communication cluster and whose
bus access is not specified yet are assigned to this block as well. The bus function
block is named <communication cluster name> (1), and default settings such
as the baud rate are taken from the communication matrix.

Suitable bus function block available If a suitable bus function block is

available in the signal chain, the Bus Manager checks if the bus function block
fulfills the following preconditions:
§ The bus function block is named after the related communication cluster of
the bus access request. The syntax of the bus function block name must
be <communication cluster name> or <communication cluster name>
(<number>).
If the bus function block's name differs, the Bus Manager ignores this function
block, i.e., the behavior is the same as if no suitable bus function block is
available (see above).
§ The bus function block's name is unique, i.e., there is exactly one bus function
block named <communication cluster name> or <communication cluster
name> (<number>).
If the bus function block's name is ambiguous, the Bus Manager does not
assign the bus access request to a bus access at all. In this case, the Message
Viewer displays an error message.
If the bus function block fulfills the preconditions, it is assigned to the bus access
request regardless of whether the bus function block is already assigned to other
bus access requests. Some settings of the bus function block are overwritten by
settings specified in the communication matrix (e.g., the baud rate). If settings
of the bus function block and the assigned bus access requests differ, conflicts
might occur. Refer to Basics on Bus Manager-Related Conflicts on page 163.

159
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Handling Bus Access Requests

After the Bus Manager assigned bus access requests to bus accesses
automatically, you must manually ensure that a hardware resource is assigned
to each bus function block that specifies a bus access.

Assigning multiple bus access Use scenarios for multiple assignments You can assign multiple bus access
requests to one bus access requests to one bus access. This is useful in the following cases:

Use Scenario Description

Network nodes In this case, the cluster is represented by one bus access request for each bus configuration.
of one In the following example, CentralGatewayEcu and BodyControlEcu are members of the same cluster but
communication assigned to different bus configurations. Therefore, CanBodyCluster is represented by two bus access requests,
cluster are one for each bus configuration.
assigned to
different bus
configurations.

Elements of In this case, the cluster is represented by one bus access request for each bus configuration part.
one In the following example, GeneralInfoIPdu and GearBoxInfoIPdu are exchanged via the same communication
communication cluster but assigned to the Simulated ECUs and Inspection parts of one bus configuration, respectively.
cluster are Therefore, CanBodyCluster is represented by two bus access requests, one for each bus configuration part.
assigned to
different parts
of one bus
configuration.

The bus In this case, the cluster of each communication matrix is represented by a bus access request.
communication In the following example, CentralGatewayEcu and BodyControlEcu are members of the same cluster but their
of one communication is defined in different communication matrices. Therefore, CanBodyCluster is represented by
communication two bus access requests, one for each communication matrix.
cluster is
defined in
multiple
communication
matrices.

Bus In this case, you have to access the bus channels that are used for simulation, manipulation, and/or inspection via
communication the bus access requests of a frame gateway.
that is

160
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Specifying the Hardware Access

Use Scenario Description

simulated, In the following example, GeneralInfoIPdu is received and inspected on one bus channel. The same PDU is
manipulated, manipulated before it is transmitted on another bus channel. To gateway the PDU from the receiving bus channel
and/or to the transmitting bus channel, the related bus accesses must be assigned to the bus access requests of the
inspected is to frame gateway.
be gatewayed.

Note

§ In this case, you must assign the bus access requests of the frame gateway to bus accesses manually. The
Bus Manager cannot assign the bus accesses automatically because the names of the communication
clusters differ.
§ To avoid a high bus load, some restrictions apply for assigning gateway bus access requests to bus
accesses. Refer to Specifying CAN Frame Gateways on page 173.

Conflicting assignments If you assign multiple bus access requests to one

bus access, conflicts might occur, e.g., because too many LIN slaves are assigned
to a LIN bus access. You must resolve these conflicts before you can build a real-
time application that includes the affected bus configurations. Refer to Basics on
Bus Manager-Related Conflicts on page 163.
In case of the following assignments, you must manually ensure that the run-
time behavior is correct:
§ Multiple LIN masters are assigned to one LIN bus access
There must be exactly one LIN master per communication cluster. When you
assign multiple LIN masters to one LIN bus access, a conflict occurs. However,
you can build a real‑time application without resolving this conflict. When you
do this, you must ensure that only one LIN master is active at a time. To do so,
you can disable bus configurations or communication controllers, or specify 0
as schedule index for LIN schedule tables, for example. Refer to Working with
Bus Configuration Features on page 191.
§ Variants of CAN or LIN frames are assigned to one bus access
The Bus Manager does not support variants of CAN or LIN frames for one
bus access. Refer to Limitations for CAN Communication on page 525 and
Limitations for LIN Communication on page 528, respectively.

Identifying assigned bus The Properties Browser helps you to identify bus access requests that are
access requests assigned to a bus function block (CAN, LIN). When you select the bus function
block, the General page of the Properties Browser provides a separate
property category for each assigned bus access request. The displayed properties

161
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Handling Bus Access Requests

are properties of the bus access requests that affect the bus access and might
result in conflicting bus access assignments (e.g., baud rate, required CAN FD
support, number of LIN slaves).

Exporting and importing ConfigurationDesk lets you export and import user-defined working views. When
working views containing bus you export a working view that contains a bus configuration but not all its
configurations assigned bus function blocks (CAN, LIN), new bus function blocks might be
added to the signal chain if you import the working view. For more information,
refer to Using Working Views (ConfigurationDesk Real-Time Implementation
Guide ).

However, if you import a working view that contains bus configurations,

limitations apply. Refer to Limitations for importing working views that contain
Bus Configuration function blocks on page 532.

162
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Handling Bus Manager-Related Conflicts

Handling Bus Manager-Related Conflicts

Where to go from here Information in this section

Basics on Bus Manager-Related Conflicts............................................... 163

Resolving Bus Manager-Related Conflicts............................................... 167

Basics on Bus Manager-Related Conflicts

Overview There are two types of Bus Manager-related conflicts, which depend on
the conflict source: Communication matrix conflicts and bus configuration
conflicts. The conflict types differ in their effects on the ConfigurationDesk
application and/or the executable application .

Handling these Bus Manager-related conflicts differs slightly from handling other
ConfigurationDesk conflicts.

Accessing conflicts The Conflicts Viewer lets you access all conflicts of a ConfigurationDesk
application and resolve many of them. The following illustration provides an
overview of the Conflicts Viewer.

163
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Handling Bus Manager-Related Conflicts

Navigation Values to be Effects (e.g., on the

tree corrected build process)
Context set and Affected Values that resolve a
severity filters properties conflict

Conflict Conflict Selection for Help text

hierarchy type resolving
Context set
nodes

Using context sets to display The Conflicts Viewer provides several context sets to which conflicts are
conflicts in the Conflicts assigned. To display specific conflicts in the Conflicts Viewer, you have to select
Viewer the related context set. The Bus Manager‑related conflicts are assigned to the
following context sets:
§ Communication matrix conflicts are assigned to the Communication
Matrices context set.
§ Bus configuration conflicts are assigned to the Bus Configurations context
set.

In the following example, only the Bus Configurations context set is selected.
Thus, the Conflicts Viewer displays only bus configuration conflicts.

164
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Basics on Bus Manager-Related Conflicts

Note

Displaying Bus Manager‑related conflicts might significantly reduce the

performance, especially when opening ConfigurationDesk projects or
activating ConfigurationDesk applications. For optimum performance, select
the Communication Matrices and Bus Configurations context sets only
when required. Refer to Best practice for handling Bus Manager-related
conflicts on page 166.

Tip

§ The Communication Matrices and Bus Configurations context sets are

cleared by default.
§ Conflicts of other context sets can also be related to the configuration
of bus communication. For example, conflicting settings for assigned bus
accesses can cause conflicts in the Function context set.
§ The selection of context sets is stored locally on the host PC and applies
to all ConfigurationDesk applications. The selection is preserved even
when you close ConfigurationDesk.
§ To temporarily suspend the display of all conflicts in one step, you can
click Suspend Display on the Home ribbon. However, there are some
points to note when you do this. Refer to Best practice for handling Bus
Manager-related conflicts on page 166.
§ When you build a real‑time application or generate bus simulation
containers, all conflicts are evaluated, regardless of whether the related
context sets are selected or the display of conflicts is temporarily
suspended.

Basics on communication Communication matrix conflicts occur in the following cases:

matrix conflicts § You import a communication matrix containing the following:
§ Elements that are not supported by the Bus Manager, such as unsupported
frame types.
§ Elements with conflicting settings, such as two or more ECUs with identical
names.
§ You modify a communication matrix in ConfigurationDesk and these
modifications result in conflicting settings. For example, you extend the length
of a PDU and due to this change, the PDU exceeds the boundaries of the
related frame.

Most of the communication matrix conflicts have no effect on building real-

time applications or generating bus simulation containers. In most cases, you
therefore do not have to resolve these conflicts before you start the build process
or generate bus simulation containers. Only the following two conflicts might
result in unintended behavior in ConfigurationDesk and/or at run time:
§ Communication matrix: Failed consistency checks during import of
communication matrix
§ Communication matrix: Failed schema check during import of communication
matrix

165
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Handling Bus Manager-Related Conflicts

Note

To prevent unintended behavior, e.g., faulty task generation by the Bus

Manager, it is recommended to resolve these two conflicts by correcting the
original communication matrix. Refer to Correct conflicting elements in the
original communication matrix on page 169.

Basics on bus configuration Bus configuration conflicts occur in the following cases:
conflicts § You assign conflicting communication matrix elements to a bus
configuration .
§ You configure conflicting settings for a bus configuration.
§ You do not configure all the necessary settings of a bus configuration.

Bus configuration conflicts affect the build process of real-time applications and
the generation of bus simulation containers. In most cases, you must therefore
resolve them before you can start the build process or generate bus simulation
containers.

Tip

In the Conflicts Viewer, many elements of bus configuration conflicts

provide the Select Related Elements in Bus Configurations Table
command on the context menu. You can use this command for the
following:
§ Select all element instances in the affected bus configuration that are
related to the conflicting element, e.g., all the PDUs that are included in a
conflicting frame and assigned to the bus configuration.
§ Access the properties of the selected element instances in the Properties
Browser.

Best practice for handling Bus Depending on the complexity of the bus communication that is specified
Manager-related conflicts in communication matrices, displaying Bus Manager‑related conflicts can
significantly influence the performance of the ConfigurationDesk application.
It is therefore recommended to display the conflicts only when and as long as
required.

Note

For optimum performance when opening ConfigurationDesk projects or

activating ConfigurationDesk applications, it is especially recommended to
clear the Communication Matrices and Bus Configurations context sets
in the Conflicts Viewer before you close the active ConfigurationDesk
application.

166
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Resolving Bus Manager-Related Conflicts

For optimum performance, the following is recommended:

Check for Recommendation

Conflicts
Communication Check a communication matrix once for conflicts after you add it to the ConfigurationDesk application.
matrices To do this, select the Communication Matrices context set in the Conflicts Viewer and resolve conflicts, if
required. Then, clear the context set.
Configured bus Repeatedly check the configured bus communication for conflicts.
communication To do this, configure a reasonable set of bus communication, e.g., the PDUs and ISignals of one ECU
you want to simulate. Then, select the Bus Configurations context set in the Conflicts Viewer and
resolve conflicts, if required. Finally, clear the context set and configure the next reasonable set of bus
communication.
While you are configuring the bus communication, you can alternatively click Suspend Display on the
Home ribbon to temporarily suspend the display of all conflicts in one step. When you do this, the selection
of context sets and severity filters is preserved.

Note

The state of the Suspend Display button is not stored when you close the activate ConfigurationDesk
application. Before you do this, always clear the Bus Configurations context set in the Conflicts
Viewer.

Related topics Basics

Basics on Resolving Conflicts (ConfigurationDesk Real-Time Implementation

Guide )

Resolving Bus Manager-Related Conflicts

Overview Depending on the conflict cause, you have the following options to resolve Bus
Manager-related conflicts:
§ Complete the implementation of the bus communication in the signal chain
on page 167.
§ Remove conflicting communication matrix elements from bus configurations
on page 168.
§ Remove or configure conflicting bus configuration features on page 168.
§ Correct conflicting communication matrix elements in ConfigurationDesk on
page 169.
§ Correct conflicting elements in the original communication matrix on
page 169.

Complete the implementation Some bus configuration conflicts occur each time you start implementing bus
of the bus communication in communication in the signal chain. In most cases, you resolve these conflicts
the signal chain automatically when you complete the implementation of the bus communication

167
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Handling Bus Manager-Related Conflicts

in the signal chain (e.g., as described in Implementing Bus Communication in the

Signal Chain Using the Bus Manager on page 335). Examples for this kind of
conflicts are:
§ Bus configuration: No valid application process assigned
§ Bus access request: No bus access assigned

Remove conflicting Bus configuration conflicts that result from conflicting communication matrix
communication matrix elements provide Is assigned properties: One for each conflicting element and
elements from bus one for the bus configuration, as shown in the following example.
configurations

You can resolve such conflicts for each separate conflicting element or for the
entire bus configuration by setting the related Is assigned property to False.

When you do this, the affected conflicting elements and their related
communication matrix elements are removed from the bus configuration, e.g., a
conflicting frame and the related PDUs.

Note

If you set the Is assigned property of the bus configuration to False,

more elements might be removed than necessary. For example, two ECUs
with identical names are assigned to one bus configuration. To resolve the
conflict, you have to remove or rename only one of these ECUs. However,
if you set the Is assigned property of the bus configuration to False, both
ECUs are removed.

Tip

The Select Related Elements in Bus Configurations Table command can

help you identify the elements that are also removed.

Remove or configure You can resolve bus configuration conflicts that result from conflicting
conflicting bus configuration bus configuration features by removing or configuring the conflicting bus
features configuration features.

Remove conflicting bus configuration features Bus configuration conflicts

that result from conflicting bus configuration features provide Enabled
properties: One for each conflicting feature and one for the bus configuration.
You can resolve these conflicts for each separate conflicting feature or for the
entire bus configuration by setting the related Enabled property to False.
If you set the Enabled property of the bus configuration to False and the
conflict results from an unsupported combination of bus configuration features,
all the conflicting features except the main feature are removed. You can identify

168
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Resolving Bus Manager-Related Conflicts

the main feature by its position in the hierarchy of the Conflicts Viewer, as
shown in the following example:

In the example above, the Frame Access feature is the main feature. If you set
the Enabled property of Controller_BusConfiguration to False, all displayed
bus configuration features except the Frame Access feature are removed.

Configure conflicting bus configuration features You can resolve some

bus configuration conflicts that result from conflicting bus configuration features
by specifying valid settings for the feature and/or by specifying user-defined
settings for the related communication matrix element as described below.

Correct conflicting You can resolve some Bus Manager-related conflicts by specifying user-defined
communication matrix settings for the conflicting communication matrix elements. By doing so,
elements in you change the communication matrix within the active ConfigurationDesk
ConfigurationDesk application. The changes apply to all the bus configurations of the active
application. The original communication matrix remains unchanged. For more
information, refer to Modifying Communication Matrices on page 391.

Correct conflicting elements You can resolve most of the Bus Manager-related conflicts by correcting the
in the original communication original communication matrix, for example, via the tool you used to generate
matrix it. You must delete the old, conflict-causing communication matrix from the
ConfigurationDesk application and import the corrected communication matrix
instead. If you assigned elements of the communication matrix to a bus
configuration, you must also replace these elements with the corrected elements.
For more information on replacing elements of a bus configuration, refer to
Replacing Assigned Communication Matrices on page 435.

Related topics Basics

Resolving Conflicts (ConfigurationDesk Real-Time Implementation Guide )

Resolving the Bus Configuration Conflict: No Valid Application Process Assigned.................... 543

169
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Handling Bus Manager-Related Conflicts

170
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Specifying CAN Frame Captures and Gateways

Specifying CAN Frame Captures and Gateways

Where to go from here Information in this section

Capturing CAN Frames.......................................................................... 171

Specifying CAN Frame Gateways........................................................... 173

Specifying Filters for Frame Captures and Frame Gateways.................... 177

Capturing CAN Frames

Introduction You can capture CAN frames that are received on a bus. Capturing CAN frames
lets you access specific parameters and the raw data of received frames, and
provide the captured data to a mapped behavior model, for example. To capture
CAN frames, you do not need a communication matrix. Instead, you can specify
the number of frames that can be captured and specify filters to capture only
specific frames.

Adding frame captures to a You can add one or more frame captures to a bus configuration. You can add
bus configuration a frame capture via the Add Frame Capture context menu command of the
Inspection bus configuration part. The Inspection part is available in the Bus
Configurations table.

171
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Specifying CAN Frame Captures and Gateways

Each frame capture is added with a unique default name. You can rename the
frame capture, for example, in the Bus Configurations table. However, the
name must be unique for all frame captures and frame gateways of the bus
configuration.

Configuring frame captures Each frame capture node in the bus configuration provides the following
properties that let you configure the frame capture:

Property Value Range Description

Maximum number of 1 … 256 Lets you specify the maximum number of frames that can be captured in
captured frames one sampling step.
Maximum frame 0 … 8, 12, 16, 20, 24, 32, Lets you specify the maximum payload length of frames that can be
length 48, and 64 bytes captured. Only the raw data of the specified number of bytes can be
captured at run time.

Note

For optimum run-time performance, it is recommended to specify only the

number of frames and bytes you really want to capture in one sampling
step.

The specified settings influence the data that can be accessed via the Frame
Capture Data feature.

Elements of frame captures For each frame capture, the following elements are available to let you specify
the frames to be captured:

Element Description
Bus access A bus access request is available that lets you specify the communication cluster for capturing frames:
request § If you build a real-time application later on, you have to assign the bus access request to a bus access . The
bus access lets you specify the bus channel of real-time hardware for capturing CAN frames.
§ If you generate bus simulation containers, you do not have to assign the bus access request to a bus access.
The bus access request is available in the generated BSC file regardless of whether you assign a bus access.
Refer to Basics on Bus Access Requests on page 155.
Frame Capture The Frame Capture Data feature lets you access the data of captured frames. Refer to Accessing the Data of
Data feature Captured Frames on page 323.
Frame capture The CAN Cluster Filter element lets you specify one or more filter rules for capturing CAN frames. Refer to
filter Specifying Filters for Frame Captures and Frame Gateways on page 177.

172
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Specifying CAN Frame Gateways

Element Description
Filter Control The Filter Control feature is available for the frame capture filter. It lets you enable and disable the filter, and
feature specify the filter mode. Refer to Controlling Filters of Frame Captures and Frame Gateways on page 328.

Restrictions for specifying You cannot specify frame captures for LIN clusters.
frame captures

Related topics Basics

Accessing Bus Manager Features via the ConfigurationDesk Automation Interface.................. 152

Specifying CAN Frame Gateways

Introduction You can specify gateways to exchange CAN frames between two communication
clusters .

Gateways for classic CAN and Gateways are supported for classic CAN and CAN FD frames as follows:
CAN FD frames § Classic CAN frames can be routed to classic CAN and CAN FD clusters.
§ CAN FD frames can only be routed to CAN FD clusters.
If you specify a gateway and a CAN FD frame is to be routed to a classic CAN
cluster, the CAN FD frame is discarded and lost, i.e., it is not routed to the
classic CAN cluster.

Note

It depends on the executable application whether you are informed

when CAN FD frames are lost because they are routed to a classic CAN
cluster:
§ In case of a real-time application, the Messages page of the SCALEXIO,
MicroAutoBox III, or MicroLabBox II system's web interface displays a
warning message when the first frame is lost.
§ In case of an offline simulation application, the frames are lost without
notice.

Specifying gateways via frame Adding frame gateways To specify a gateway between two communication
gateways clusters, you have to add a frame gateway to the Gateways part of a bus
configuration. You can add one or more frame gateways via the Add Frame
Gateway context menu command of the Gateways part. The Gateways part is
available in the Bus Configurations table.

173
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Specifying CAN Frame Captures and Gateways

Each frame gateway is added with a unique default name. You can rename the
frame gateways, for example, in the Bus Configurations table. However, the
name must be unique for all frame gateways and frame captures of the bus
configuration.

Elements of frame gateways For each frame gateway, the following

elements are available to let you specify the gateway:

Element Description
Bus access Two bus access requests are available. They are required for specifying the communication clusters between
request which the CAN communication is exchanged:
§ If you build a real-time application later on, you have to assign the bus access requests to bus accesses . The
bus accesses let you specify bus channels of real-time hardware for exchanging the CAN communication.
§ If you generate bus simulation containers, you do not have to assign the bus access requests to bus accesses.
The bus access requests are available in the generated BSC file regardless of whether you assign bus accesses.
Refer to Basics on Bus Access Requests on page 155.
Frame The Frame Gateway Direction feature lets you specify the gateway direction or disable a gateway. Refer to
Gateway Specifying the Direction of CAN Frame Gateways on page 327.
Direction
feature
Gateway filter The CAN Cluster 1 Filter and CAN Cluster 2 Filter elements let you specify filter rules for each communication
cluster. You can specify multiple filter rules for each filter element to filter frames for gatewaying. Refer to
Specifying Filters for Frame Captures and Frame Gateways on page 177.
Filter Control The Filter Control feature is available for each gateway filter element. The Filter Control feature lets you
feature enable and disable the related gateway filter, and specify the filter mode. Refer to Controlling Filters of Frame
Captures and Frame Gateways on page 328.

Specifying failure gateways A typical use scenario for CAN frame gateways is failure gateways. To specify a
failure gateway, you have to manipulate the respective frames, PDUs, and/or
ISignals on the TX side of the frame gateway, as shown in the following
example.

174
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Specifying CAN Frame Gateways

Bus configuration

Receiver Frame gateway:

frames (RX)
Filter frames

CAN cluster 1 Transfer

filtered frames

Manipulation: Transmit
Manipulate frames/PDUs/ISignals frames (TX)
CAN cluster 2

To achieve this, do the following:

1. Assign the respective CAN PDUs to the Manipulation part of a bus
configuration.
2. Add bus manipulation features to the PDUs and/or their ISignals.
3. Assign the bus access requests of the Manipulation part to the same bus
access that transmits the gatewayed frames on the bus.

Tip

If you generate bus simulation containers and import the BSC files
to VEOS , the bus access requests are available as communication
controllers. Assign the respective communication controllers to the
same bus access, i.e., communication cluster.

Restrictions for assigning When you assign gateway bus access requests to bus accesses, you must ensure
gateway bus access requests that the bus accesses are not connected in a loop. If bus accesses are connected
to bus accesses in a loop, the bus communication is gatewayed in an endless, multiplying loop
that results in a high bus load.

In ConfigurationDesk, there are different configurations that might result in

bus accesses that are connected in a loop. The following table provides some
examples of such configurations.

175
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Specifying CAN Frame Captures and Gateways

Example Configuration
1 The bus access requests of one frame gateway are assigned to the same bus access.

Bus access Bus access 1

assignment CAN1

2 The bus access requests of one frame gateway are assigned to different bus accesses, but the bus access requests of another
frame gateway are also assigned to these bus accesses.

Bus access Bus access 1

assignment CAN1

Bus access 2
CAN1

3 The bus access requests of one frame gateway are assigned to different bus accesses, but the used bus channels are physically
connected at the simulator.
Simulator

Bus access 1 Real-time hardware

Bus access
assignment CAN1 Pin Ch 1
Ch 1
Ch 2
Pin Ch 2

Bus access 2
CAN1

4 The bus access requests of two frame gateways are assigned to three bus accesses. The used bus channels of two bus accesses
are physically connected at the simulator.
Simulator

Bus access 1
Bus access CAN1
assignment

Real-time hardware
Bus access 2 Pin Ch 1
CAN1 Ch 1
Ch 2
Ch 3
Pin Ch 3

Bus access 3
CAN1

If you generate bus simulation containers and import the BSC files to VEOS, the
bus access requests are available as communication controllers. To avoid loops,

176
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Specifying Filters for Frame Captures and Frame Gateways

you must assign the communication controllers to separate bus accesses, i.e.,
communication clusters.

Restrictions for specifying The following restrictions apply for specifying frame gateways:
frame gateways § You cannot specify frame gateways for LIN clusters.
§ In global time synchronization (GTS) scenarios, the time base instances of
affected time slaves are not completely synchronous to the time base instance
of the related time master. For more information, refer to Simulating Time
Masters and Time Slaves of Global Time Domains on page 182.

Related topics Basics

Accessing Bus Manager Features via the ConfigurationDesk Automation Interface.................. 152
Use Scenarios for Gatewaying Bus Communication.................................................................. 36

Specifying Filters for Frame Captures and Frame Gateways

Introduction Frame captures and frame gateways provide filters that let you filter CAN frames
for capturing and gatewaying, respectively. To specify a filter, you have to add
one or more filter rules to the filter. Each filter rule lets you filter CAN frames by
their frame triggerings.

Filters of frame captures and For frame captures and frame gateways, the following filters are available:
frame gateways § For each frame capture, one filter is available.

§ For each frame gateway, two filters are available. The filters are
unambiguously assigned to the communication clusters of the frame gateway
as follows:
§ CAN Cluster 1 Filter is assigned to CAN Cluster 1.
§ CAN Cluster 2 Filter is assigned to CAN Cluster 2.

177
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Specifying CAN Frame Captures and Gateways

You cannot change this assignment.

The filters apply only to frames that are transmitted by the frame gateway.
They have no effect on frames that are received by the frame gateway. For
example, frames that are received by the frame gateway on CAN Cluster 1
are not filtered by CAN Cluster 1 Filter. Instead, these frames are filtered only
by CAN Cluster 2 Filter before the frame gateway transmits them on CAN
Cluster 2.

Frame gateway

CAN Cluster 2
Receive any frame (RX) Filter Transmit filtered frames (TX)
on CAN Cluster 1 on CAN Cluster 2

CAN Cluster 1
Transmit filtered frames (TX) Receive any frame (RX)
Filter
on CAN Cluster 1 on CAN Cluster 2

Specifying filter rules Adding filter rules To each filter, you can add one or more filter rules via
the Add CAN Filter Rule context menu command, as shown in the following
example.

For each filter rule, a separate filter rule element is added to the filter. The names
of the filer rule elements are derived from the specified filter settings.
If you add two or more filter rules to a filter, all frames that match at least one of
the filter rules pass the filter.

178
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Specifying Filters for Frame Captures and Frame Gateways

Specifying filter settings for filter rules Filter rules let you filter CAN
frames by their frame triggering. For this purpose, each filter rule element
provides the following properties:

Property Value Range Description

Extended Checkbox: Lets you filter frames by their identifier format:
addressing § Selected § Selected: Frames with extended identifier format
§ Cleared (29‑bit) pass the filter.
§ Cleared: Frames with standard identifier format
(11‑bit) pass the filter.
Minimum 0… Lets you specify the minimum and maximum identifier
identifier value 536870911 value to filter frames on the basis of an identifier value
Maximum range.
identifier value Frames whose identifier value is within the specified
value range pass the filter.
CAN FD frame Checkbox: Lets you filter frames by their CAN FD support status:
support § Selected § Selected: CAN FD frames pass the filter.
§ Cleared § Cleared: Classic CAN frames pass the filter.
Bit rate switch Checkbox: Lets you filter the frames by their bit rate switch:
§ Selected § Selected: Only CAN FD frames with enabled bit rate
§ Cleared switch pass the filter.
§ Cleared: CAN FD frames with disabled bit rate
switch and classic CAN frames pass the filter.

Only frames whose frame triggering matches all of the specified settings pass the
filter.

Note

To each filter rule, all of the settings apply for filtering frames. You cannot
disable individual settings for frame filtering.

Run-time behavior of the By default, frame capture and frame gateway filters are active at run time.
filters Frames that pass at least one filter rule of a filter are not captured or gatewayed
while all other frames of the related cluster are. You can change the default
behavior by using the Filter Control feature. Refer to Controlling Filters of
Frame Captures and Frame Gateways on page 328.

Restrictions for using frame Frame gateway filters do not support the J1939 Broadcast Announce Message
gateway filters (BAM) and Connection Mode Data Transfer (CMDT) protocols. These transport
protocols use specific ID ranges to transmit verifying information, e.g., request to
send (RTS), clear to send (CTS), and related data packets. Frames can be filtered
only on the basis of their frame triggering, not on the basis of their payload.
Therefore, J1939 communication can be significantly disturbed, e.g., if an RTS
passes a frame gateway filter while a related CTS is blocked.

For more information on the BAM and CMDT protocols, refer to Aspects of the
J1939 Protocol on page 80.

179
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Specifying CAN Frame Captures and Gateways

180
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Implementing Global Time Synchronization in Executable Applications

Implementing Global Time Synchronization in

Executable Applications

Where to go from here Information in this section

Basics on Implementing Global Time Synchronization in

Executable Applications......................................................................... 181

Simulating Time Masters and Time Slaves of Global Time Domains........ 182

Transmitting Bus Communication of Bus Configurations

Synchronously to a Global Time............................................................. 185

Transmitting Individual PDUs Synchronously to a Global Time................ 188

Basics on Implementing Global Time Synchronization in Executable

Applications

Introduction The Bus Manager supports global time synchronization (GTS) over CAN
according to AUTOSAR. Refer to Aspects of Global Time Synchronization (GTS)
on page 71.

There are different use scenarios for implementing global time synchronization in
executable applications .

Use scenarios for The following use scenarios are typical for implementing global time
implementing global time synchronization in executable applications:
synchronization § Simulating time masters and time slaves of global time domains by using the
Bus Manager. Refer to Simulating Time Masters and Time Slaves of Global
Time Domains on page 182.

181
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Implementing Global Time Synchronization in Executable Applications

§ Transmitting the bus communication of bus configurations synchronously to a

global time. Refer to Transmitting Bus Communication of Bus Configurations
Synchronously to a Global Time on page 185.
§ Transmitting individual PDUs that are assigned to bus configurations
synchronously to a global time by using the RTI Synchronized Time Base
Manager Blockset. Refer to Transmitting Individual PDUs Synchronously to a
Global Time on page 188.

You can focus on one use scenario or use a combination of the use scenarios to
implement global time synchronization in executable applications.

Tip

Moreover, the RTI Synchronized Time Base Manager Blockset lets you
specify rate and offset corrections to correct time shifts and time jumps
between a local time base and the global time. For more information,
refer to Correction Mechanisms of the Synchronized Time Base Manager
Using the STBM_SET_PARAMS Block (RTI Synchronized Time Base Manager
Blockset Reference ).

Limitations for implementing For implementing global time synchronization in executable applications,
global time synchronization some limitations apply. Refer to Limitations for Communication Matrices and
Communication Standards on page 519.

Simulating Time Masters and Time Slaves of Global Time Domains

Introduction If global time synchronization is specified in the communication matrix, the Bus
Manager lets you simulate time masters and time slaves of global time domains.

Representation of global time When you add a communication matrix specifying global time synchronization
domains to the Buses Browser, you can access global time domains via global time
domain elements that are available for general-purpose PDUs. For each global
time domain, there can be several global time domain elements, one element for
each ECU that is a member of this global time domain.

Because an ECU can be a member of multiple global time domains, there can
also be multiple global time domain elements for an ECU: For each global time
domain of which an ECU is a member, a separate global time domain element is
available. The direction of the global time domain element indicates whether the
ECU acts as time master or time slave:
§ TX global time domain element: Time master

182
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Simulating Time Masters and Time Slaves of Global Time Domains

§ RX global time domain element: Time slave

When you select a global time domain element, the Properties Browser
provides access to properties of the global time domain and the time master
or time slave, as shown in the following example.

Simulating time masters and You can configure global time domain elements for simulation purposes. For
time slaves of global time each global time domain element you assign to the Simulated ECUs part of a
domains bus configuration, an instance of the dSPACE ECU time base manager is created.
The dSPACE ECU time base manager implements functionalities of the AUTOSAR
synchronized time base manager, i.e., it provides the synchronized time base.

At run time, the time bases of global time domains can be synchronized only
after the related global time master has set the time at least once. Depending
on whether a real ECU provides the global time master, the time must be set as
follows:

Global Time Master Provided by Real ECU Global Time Master Not Provided by Real ECU
The global time master provided by the real You must simulate the global time master by using the RTI Synchronized
ECU must set the time and transmit the time Time Base Manager Blockset or the Bus Manager.
information on the bus at least once. However, even if you use the Bus Manager to simulate the global time
After the SCALEXIO, MicroAutoBox III, or master, you must work with a Simulink® behavior model and use blocks
MicroLabBox II system has received the time, the from the RTI Synchronized Time Base Manager Blockset: If a TX global
related time bases can be synchronized, i.e.: time domain element that is a global time master is assigned to a bus
§ Simulated time slaves can synchronize their local configuration, the Bus Manager can simulate the global time master and
time base instances. synchronize time bases only after the blockset's STBM_SET_GLOBAL_TIME
§ Simulated time masters can distribute the block has set the time at least once.
synchronized time among their global time For more information on the RTI Synchronized Time Base Manager Blockset,
domain. refer to RTI Synchronized Time Base Manager Blockset Reference .

Additionally, bus configuration features are available for global time domain
elements that are assigned to bus configurations. Via the bus configuration
features, you can access the time base data of time masters and time slaves, for
example. Refer to Bus Configuration Features Available for Global Time Domains
on page 313.

183
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Implementing Global Time Synchronization in Executable Applications

Run-time behavior regarding The synchronization period of a time master determines the time that is available
synchronization periods for transmitting a synchronization message and its related follow‑up message on
the bus. If the synchronization period is shorter than required for transmitting
both messages, the time synchronization is executed as fast as possible, i.e., both
messages are transmitted and not interrupted.

This applies regardless of whether a synchronization period is specified in the

communication matrix or via the GTS Transmission Control bus configuration
feature.

Handling CRC-secured time Time synchronization can be secured by checksum algorithms, i.e., CRC-secured.
synchronization For this purpose, time masters and time slaves provide the following properties:

Property Available For Purpose

CRC‑secured Time master Specifies whether time synchronization is CRC‑secured.
CRC validation Time slave Specifies whether received CRC‑secured data is
validated.

The settings of the properties are derived from the communication matrix. If the
communication matrix does not specify settings for the properties or specified
settings are invalid, the Bus Manager uses the following default settings:

Property Setting Purpose

CRC‑secured CRC not CRC support is disabled for time synchronization.
supported
CRC validation CRC ignored CRC‑secured data is ignored, i.e., regardless of
whether CRC‑secured data is received it is not
validated.

Validating received time Time synchronization messages that are received by time slaves are validated,
synchronization messages i.e., the synchronization (SYNC) message and its related follow‑up (FUP) message
are validated. The time base of the time slave is synchronized only if both
messages pass the validity checks.

Tip

The GTS Validation feature lets you access the validation results and
exclude certain validity checks from the validation of time synchronization
messages.

Restrictions for simulating For simulating time masters and time slaves of global time domains, the
time masters and time slaves following restrictions apply:
of global time domains § You can only simulate time masters and time slaves of global time domains.
Therefore, configuring global time domain elements for inspection or
manipulation purposes is not supported.
§ If you configure frame gateways for exchanging synchronized time bases, the
time base instances of the affected time slaves are not completely synchronous

184
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Transmitting Bus Communication of Bus Configurations Synchronously to a Global Time

to the time base instance of the related time master. There is a delay resulting
from the time that is required for exchanging frames via the gateway.
§ If you configure a TX global time domain element for simulation purposes, i.e.,
a time master, you cannot use any bus configuration feature that is available
for the related TX PDU and TX frame.

Additionally, some limitations apply for global time synchronization. Refer to

Limitations for Communication Matrices and Communication Standards on
page 519.

Transmitting Bus Communication of Bus Configurations Synchronously to a

Global Time

Introduction You can transmit the bus communication of a bus configuration synchronously
to a global time. For this purpose, you can use a synchronized timer
event to trigger the periodic task to which the BusCfg_MainFunctionFetch
[<bus configuration name>] and BusCfg_MainFunctionDeliver [<bus
configuration name>] runnable functions of the bus configuration are
assigned.

Basics on synchronized timer A synchronized timer event lets you trigger a periodic task cyclically and
events synchronously to a global time. For this purpose, the synchronized timer event
provides the following properties:

Property Description
Global time Lets you reference a global time domain by specifying its global time domain identifier. The periodic task is
domain synchronously executed to the global time of this global time domain.
identifier The time master that provides the referenced global time domain must be available in one of the following ways:
§ The time master is provided by a real ECU that is connected to the SCALEXIO, MicroAutoBox III, or
MicroLabBox II system.
§ The time master is simulated by the Bus Manager. Refer to Simulating Time Masters and Time Slaves of Global
Time Domains on page 182.
§ The time master is implemented by the RTI Synchronized Time Base Manager Blockset. Refer to RTI
Synchronized Time Base Manager Blockset Reference .
Period Lets you specify the period (in seconds) for the cyclic execution of the task.
Offset Lets you specify an offset (in seconds) to the global time.

For example, you specify a period of 5 ms and an offset of 1 ms. In this case,
the periodic task is triggered when the global time of the referenced global time
domain is 1 ms, 6 ms, 11 ms, …

Effects on the timing of the The periodic task to which the BusCfg_MainFunctionFetch [<bus
bus communication configuration name>] and BusCfg_MainFunctionDeliver [<bus
configuration name>] runnable functions of a bus configuration are assigned

185
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Implementing Global Time Synchronization in Executable Applications

determines the timing of the bus communication. Triggering this task by a

synchronized timer event has the following effects on the timing:
§ To ensure that the cyclic transmission of PDUs is synchronous to the global
time, the timing for transmitting PDUs cyclically is always n · <period of
PDU cyclic timing> + <offset of PDU cyclic timing>.
This applies even if there was a delay between the trigger for transmitting a
PDU and the actual transmission: Subsequent cyclic timings are calculated on
the basis of the original timing and not on the basis of the point in time when
the PDU was actually transmitted.

Tip

This does not apply to event‑controlled timings. For example, subsequent

timings due to a repetition period are calculated on the basis of the point
in time when the related PDU was actually transmitted.

§ Time shifts and time jumps between the local time base of the bus
configuration and the global time are detected and corrected.

For more information, refer to Basics on Tasks, Events, and Runnable Functions
Provided by the Bus Manager on page 363.

Assigning synchronized timer You can assign synchronized timer events to periodic tasks in the Executable
events to periodic tasks Application table. You can do this by adding a new synchronized timer event or
replacing the existing timer event.

Tip

You can open the Executable Application table via Switch Controlbars
on the View ribbon.

Adding a new synchronized timer event to a periodic task You can add
a new synchronized timer event to a periodic task via context menu. To do this,
right‑click the task and select New - Synchronized Timer Event on the context
menu.

The synchronized timer event is named Synchronized Timer Event

(<number>) and is added with default settings. You can configure the name
and the settings according to your requirements in the Properties Browser.

186
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Transmitting Bus Communication of Bus Configurations Synchronously to a Global Time

To prevent conflicts, you have to delete the assignment of the existing timer
event from the task. To do this, right‑click Timer Event and select Delete
Assignment on the context menu.

Replacing the existing timer event with a synchronized timer event You
can replace the existing timer event of a periodic task with a synchronized
timer event. To do this, right‑click the timer event and select Replace with
Synchronized Timer Event on the context menu.

The timer event is replaced with a synchronized timer event. The values for
Period and Offset of the synchronized timer event are derived from the
timer event. However, the name remains unchanged. To avoid confusion, it is
recommended to specify a meaningful name for the event, e.g., Synchronized
Timer Event.

Restrictions for using When you use synchronized timer events and you generate bus simulation
synchronized timer events containers, the synchronized timer events are not included in the resulting BSC
files. Instead, the synchronized timer events are replaced with timer events. This
has the following effects:
§ The settings of the timer events, i.e., Name, Time, and Offset, are derived
from the synchronized timer events.
§ The settings of the Global time domain identifier properties of the
synchronized timer events are lost.

This results in the following restrictions for using the affected BSC files:
§ If you use an affected BSC file in an offline simulation application running
on VEOS, the affected periodic tasks are not triggered by synchronized timer
events but by timer events.
§ If you import an affected BSC file to ConfigurationDesk, you have to
replace the affected timer events with synchronized timer events before you
build a real‑time application. You can do this in the same way as for bus
configurations.

187
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Implementing Global Time Synchronization in Executable Applications

The names of the synchronized timer events are derived from the related timer
events. If required, you can change the names. Period and Offset of the
synchronized timer events are read‑only and set to the values of the related
timer events. Therefore, you only have to reference the required global time
domain via the Global time domain identifier property of each synchronized
timer event.

Related topics Basics

Accessing Bus Manager Features via the ConfigurationDesk Automation Interface.................. 152

Transmitting Individual PDUs Synchronously to a Global Time

Introduction You can transmit individual PDUs synchronously to a global time by using
the STBM_SYNCHRONOUS_TRIGGER block of the RTI Synchronized Time Base
Manager Blockset and the PDU Trigger feature of the Bus Manager.

The STBM_SYNCHRONOUS_TRIGGER block can provide cyclic triggers that are

synchronous to a specific global time. You can use these triggers with the PDU
Trigger feature to transmit individual PDUs of a bus configuration synchronously
to the settings that are specified in the STBM_SYNCHRONOUS_TRIGGER block.

Recommended workflow For transmitting individual PDUs synchronously to a global time, the following
workflow is recommended:
1. Add the STBM_SYNCHRONOUS_TRIGGER block of the RTI Synchronized
Time Base Manager Blockset to your Simulink® model. To do this, type
rtistbm in the MATLAB Command Window and drag the block from the
blockset library to your Simulink model.
2. Configure the STBM_SYNCHRONOUS_TRIGGER block according to your
requirements. Refer to STBM_SYNCHRONOUS_TRIGGER (RTI Synchronized
Time Base Manager Blockset Reference ).
3. Add a Data Outport block to your Simulink model. For example, type data
outport in an empty area of the Simulink model and select the block from
the list.

188
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Transmitting Individual PDUs Synchronously to a Global Time

4. Specify a meaningful name for the Data Outport block, for example, GTS
Trigger.
5. Map the Data Outport block to the Trigger port of the
STBM_SYNCHRONOUS_TRIGGER block.
6. Right‑click the Data Outport block and select Model Port Blocks - Update
All Selected Outport Blocks from Input Signals on the context menu.
7. Depending on whether your Simulink model is already available in the
ConfigurationDesk application, add it to the ConfigurationDesk application
or analyze the model including task information. You can use commands on
the ConfigurationDesk menu of the Simulink Editor for this purpose.

8. Add the PDU Trigger feature to the PDUs whose transmission you want to
trigger synchronously to the global time.

9. Map model ports of the Data Outport block to the Trigger function ports.

According to the default settings of the PDU Trigger feature, i.e., Trigger
mode is set to Positive edge and Initial value of the Trigger function ports
is set to False, the transmission of the related PDUs is disabled by default. At
run time, the transmission is triggered synchronously to the global time each

189
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Implementing Global Time Synchronization in Executable Applications

time the related trigger of the RTI Synchronized Time Base Manager Blockset is
received.

Note

If you want to generate bus simulation containers later on, you have to
generate a Simulink implementation container from the Simulink model and
replace the model with the container in the ConfigurationDesk application.

190
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Working with Bus Configuration Features

Working with Bus Configuration Features

Where to go from here Information in this section

Basics on Working with Bus Configuration Features............................... 192

Manipulating Bus Communication via Bus Configuration Features......... 213

Bus Configuration Features Available for ISignals................................... 221

Bus Configuration Features Available for ISignal Groups........................ 235

Bus Configuration Features Available for PDUs....................................... 238

Bus Configuration Features Available for Frames.................................... 288

Bus Configuration Features Available for Communication

Controllers............................................................................................ 302

Bus Configuration Features Available for Global Time Domains.............. 313

Bus Configuration Features Available for Partial Network Clusters.......... 321

Bus Configuration Features Available for Frame Captures and

Frame Gateways.................................................................................... 323

Bus Configuration Features Available for Bus Configurations................. 331

191
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with Bus Configuration Features

Basics on Working with Bus Configuration Features

Where to go from here Information in this section

Basics on Bus Configuration Features..................................................... 192

Overview of Bus Configuration Features................................................ 195

Configuring Function Ports for Bus Configuration Features.................... 198

Accessing Function Ports with Enabled Test Automation Support

in Variable Description Files (TRC Files)................................................... 202

Using TRC File Variables for XIL Mapping............................................... 207

Triggering the Transmission of PDUs and Frames via User-Defined

Triggers................................................................................................. 210

Basics on Bus Configuration Features

Introduction You can add bus configuration features to certain elements of a bus
configuration . The bus configuration features provide element-specific
functionalities, which you can configure for run time. For example, bus
configuration features let you access the value of ISignals, trigger the
transmission of PDUs, or manipulate the length of CAN frames.

For an overview of the available bus configuration features, refer to Overview of

Bus Configuration Features on page 195.

Tip

In addition to the bus configuration features, you can influence

the bus communication by specifying user-defined settings for certain
communication matrix elements. Refer to Modifying Communication
Matrices on page 391.

Adding bus configuration There are three ways to add bus configuration features:
features § You can select a bus configuration element in the Bus Configurations,
Bus Simulation Features, Bus Inspection Features, or Bus Manipulation
Features table and add an available bus configuration feature via the context
menu.

192
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Basics on Working with Bus Configuration Features

Tip

You can also add bus configuration features via context menu for multi-
selected elements, even if their element types differ. When you select
a feature on the context menu, it is added to all selected elements for
which it is valid.

§ To add a bus configuration feature to a PDU or ISignal, you can select the
PDU or ISignal in the PDU Features or Signal Features subview of the
Bus Simulation Features, Bus Inspection Features, or Bus Manipulation
Features table and enable an available bus configuration feature in the related
column.

Note

For a better overview, not all columns that let you enable and/or
configure bus configuration features are available in the tables by default.
Instead, these columns are available in the Column Chooser, which is
accessible via the context menu of the column headers. From the Column
Chooser, you can add required columns to the tables via drag & drop. For
more information, refer to Bus Configuration Tables on page 103.

§ You can select bus configuration features in the Bus Configuration Behavior
table. When you do this, the features are automatically added to the
applicable communication matrix elements when you assign the elements to
bus configurations. For more information, refer to Specifying the Behavior
for Assigning Communication Matrix Elements and Adding Bus Configuration
Features (Preview Version) on page 125.

193
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with Bus Configuration Features

Tip

By default, the following bus configuration features are added

automatically:
§ The ISignal Value and LIN Schedule Table features are added to ISignals
and LIN master communication controllers when you assign the elements
to the Simulated ECUs part of a bus configuration.
§ The Frame Capture Data and Filter Control features are added to
frame capture elements when you add the elements to the Inspection
part of a bus configuration.
§ The Frame Gateway Direction and Filter Control features are added to
frame gateway elements when you add the elements to the Gateways
part of a bus configuration.

Effects of added bus A bus configuration feature applies only to the bus configuration element
configuration features for which it was added. The related communication matrix, instances of the
element in the related and other bus configurations, and other bus configuration
elements are not affected by the bus configuration feature.

Each bus configuration feature provides feature-specific properties and/or

function ports . Depending on the available properties and function ports, you
can configure the bus configuration feature and/or specify initial settings for the
feature. Via the function ports, you can access the related feature settings at run
time.

Depending on the bus configuration feature for which function ports are added,
you cannot access the related feature at run time by default. To access such
features at run time, you have to change the function port default settings.
For more information, refer to Configuring Function Ports for Bus Configuration
Features on page 198.

Tip

If no bus configuration feature is added to a bus configuration, the bus

configuration does not have any function ports.

Disabling bus configuration You can disable bus configuration features if you do not need them. Disabling
features a bus configuration feature removes the related function ports from the bus
configuration. You can disable a bus configuration feature in the following ways:
§ Right-click on a feature node ( ) in the Bus Configurations table and select
Delete from Application on the context menu.

Tip

You can also press the Delete key to delete a selected feature node.

§ To disable a bus configuration feature for a PDU or ISignal, you can also select
the PDU or ISignal in the Bus Simulation Features, Bus Inspection Features,

194
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Basics on Working with Bus Configuration Features

or Bus Manipulation Features table and select Disabled on the list of the
related table column.

Related topics Basics

Accessing Bus Manager Features via the ConfigurationDesk Automation Interface.................. 152

Overview of Bus Configuration Features

Introduction The Bus Manager provides various bus configuration features, which are specific
for the bus configuration element (e.g., ISignal, PDU) and the bus configuration
part (i.e., Simulated ECUs, Inspection, Manipulation, or Gateways) an
element is assigned to.

Bus configuration features for For ISingals and ISignal groups, the following bus configuration features are
ISignals and ISignal groups available:

Bus Configuration Purpose Available for Further Information

Feature Elements Assigned
to …
ISignal Value Lets you access the signal value of § Simulated ECUs Working with ISignal Values on page 221
an ISignal. § Inspection
Counter Signal Lets you specify an ISignal as a § Simulated ECUs Working with Counter Signals on
counter signal. § Inspection page 223
ISignal Overwrite Value Lets you overwrite the value of an Manipulation Overwriting ISignal Values on page 228
ISignal with a user-defined value.
ISignal Offset Value Lets you add an offset value to the Manipulation Adding Offset Values to ISignal Values on
value of an ISignal. page 231
ISignal Group End-to- Lets you observe the status of § Simulated ECUs Observing the Status of Received
End Protection Status a received end-to-end-protected § Inspection End‑to‑End‑Protected ISignal Groups on
ISignal group. page 235

Bus configuration features for For PDUs, the following bus configuration features are available:
PDUs

Bus Configuration Purpose Available for Further Information

Feature Elements Assigned
to …
PDU Enable Lets you enable and disable the Simulated ECUs Enabling and Disabling the
transmission of a PDU. Transmission of PDUs on page 238
PDU Raw Data Lets you access the payload of a PDU in raw § Simulated ECUs Accessing the Payload of PDUs in Raw
data format. § Inspection Data Format on page 240

195
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with Bus Configuration Features

Bus Configuration Purpose Available for Further Information

Feature Elements Assigned
to …
PDU Cyclic Timing Lets you control the cyclic timing of a CAN Simulated ECUs Controlling the Cyclic Timing of CAN
Control PDU. PDUs on page 243
PDU Trigger Lets you trigger the transmission of a PDU Simulated ECUs Specifying User-Defined Triggers for
according to a user-defined trigger. Transmitting PDUs on page 246
PDU Length Lets you access the payload length of a § Simulated ECUs Accessing the Payload Length of CAN
CAN PDU, e.g., to simulate a dynamic § Inspection PDUs on page 249
length CAN PDU.
PDU RX Status Lets you observe the status of a received § Simulated ECUs Observing the Status of Received
PDU. § Inspection PDUs on page 251
PDU User Code Lets you apply user code to a PDU. § Simulated ECUs Applying User Code to PDUs on
§ Inspection page 254
§ Manipulation
J1939 PDU Priority Lets you access the priority of a § Simulated ECUs Accessing the Priority of J1939-
J1939‑21‑compliant IPDU. § Inspection Compliant IPDUs on page 263
§ Manipulation
PDU Selector Field Lets you access the selector field value of a § Simulated ECUs Accessing the Selector Field Value of
multiplexed IPDU. § Inspection Multiplexed IPDUs on page 266
SecOC Lets you verify the authentication § Simulated ECUs Verifying the Authentication
information of a received secured IPDU. § Inspection Information of Received Secured
IPDUs on page 268
SecOC Authenticator Lets you invalidate the authenticator (MAC) Manipulation Invalidating the Authenticator of
Invalidation before transmitting a secured IPDU. Secured IPDUs on page 271
SecOC Freshness Lets you overwrite the freshness value of a Manipulation Overwriting the Freshness Value of
Overwrite Value secured IPDU with a user-defined freshness Secured IPDUs on page 274
value.
Suspend PDU Lets you suspend the transmission of a Manipulation Suspending the Transmission of PDUs
Transmission PDU. on page 278
PDU RX Interrupt Lets you use RX interrupts to trigger the Simulated ECUs Triggering the Execution of Functions
execution of functions in a behavior model. in a Behavior Model via RX Interrupts
on page 281

Bus configuration features for For frames, the following bus configuration features are available:
frames

Bus Configuration Purpose Available for Further Information

Feature Elements Assigned
to …
Frame Access Lets you access settings of a CAN Simulated ECUs Accessing CAN Frame Settings on
frame. page 288
Frame Length Lets you manipulate the payload Manipulation Manipulating the Payload Length of CAN
length of a CAN frame. Frames on page 295
Suspend Frame Lets you suspend the transmission of Manipulation Suspending the Transmission of Frames
Transmission a frame. on page 298

196
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Basics on Working with Bus Configuration Features

Bus configuration features For communication controllers, the following bus configuration features are
for communication controllers available:
and partial network clusters

Bus Configuration Purpose Available for Further Information

Feature Elements
Assigned to …
Communication Lets you enable and disable a Simulated ECUs Enabling and Disabling Communication
Controller Enable communication controller of an ECU. Controllers on page 302
LIN Wake‑Up Lets you send LIN wake‑up signals on the Simulated ECUs Sending Wake-Up Signals on a LIN Bus
LIN bus. on page 305
LIN Schedule Table Lets you access the schedule tables of a Simulated ECUs Working with LIN Schedule Tables on
LIN master. page 307
J1939 Network Lets you enable and disable J1939 Simulated ECUs Enabling and Disabling J1939 Network
Management Enable network management for a network node Management on page 310
and specify the enable state.
Partial Network Cluster Lets you include partial network clusters Simulated ECUs Including Partial Network Clusters in
Enable in executable applications and enable and Executable Applications and Enabling
disable the clusters. and Disabling the Clusters on page 321

Bus configuration features for For global time domains, the following bus configuration features are available:
global time domains

Bus Configuration Purpose Available for Further Information

Feature Elements
Assigned to …
GTS Transmission Lets you control the timing of time Simulated ECUs Controlling the Timing of Time
Control synchronization. Synchronization on page 313
GTS Time Base Data Lets you access the time base data of Simulated ECUs Accessing the Time Base Data of Time
time masters and time slaves. Masters and Time Slaves on page 315
GTS Validation Lets you access the validity checks for Simulated ECUs Accessing Validity Checks for Time
time synchronization messages. Synchronization Messages on page 317

Bus configuration features For frame captures, gateways, and bus configurations, the following bus
for frame captures, gateways, configuration features are available:
and bus configurations

Bus Configuration Purpose Available for Further Information

Feature Elements Assigned
to …
Frame Capture Data Lets you access the data that is captured Inspection Accessing the Data of Captured
by a CAN frame capture. Frames on page 323
Frame Gateway Lets you specify the gateway direction of Gateways Specifying the Direction of CAN
Direction a CAN frame gateway. Frame Gateways on page 327
Filter Control Lets you specify the filter mode of a § Inspection Controlling Filters of Frame Captures
frame capture or frame gateway filter, § Gateways and Frame Gateways on page 328
and enable or disable the filter.

197
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with Bus Configuration Features

Bus Configuration Purpose Available for Further Information

Feature Elements Assigned
to …
Bus Configuration Lets you enable and disable a bus - (available only Enabling and Disabling Bus
Enable configuration. for bus configuration Configurations on page 331
nodes)

Configuring Function Ports for Bus Configuration Features

Introduction Some settings of bus configuration features can be accessed via function ports.
The behavior of these settings is determined by the related function ports.
For the function ports, you can configure the following settings to specify the
behavior of the related bus configuration feature settings.

Specifying initial values Every function port provides a default initial value that is specific for the related
bus configuration feature. Via the function port's Initial value property, you can
specify a user-defined initial value.

Note

Depending on the related bus configuration feature, a user-defined initial

value might be saturated, for example, if you replace or modify a
communication matrix.

The function port value is set to the initial value during system initialization. This
value is used directly after an executable application is started. During run
time, an initial function port value can be overwritten, for example, by a value
that is received on the bus, provided by a behavior model , or changed via
experiment software.

Each bus configuration provides an Initial value usage property. This property
lets you specify how the initial values of the bus configuration's function ports
are used. You can specify whether the initial values are set only once at
first application start or every time the application starts, including when the
application state switches from stopped to running.

198
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Basics on Working with Bus Configuration Features

Tip

§ If you enable test automation support, you can additionally specify an

initial substitute value. You can select whether the value of the Initial
value or Initial substitute value property is used as the initial function
port value. Refer to Enabling test automation support on page 199.
§ The setting of the Initial value usage property applies to both initial
values, i.e, to the values of the Initial value and Initial substitute value
properties.
§ You can access the properties in the Properties Browser and in the Bus
Configuration Ports table.

Enabling model access To exchange data between bus configuration features and a behavior model, you
have to set the Model access property for the related function ports to Enabled
and map the function ports to model port blocks . This lets you, for example:
§ Use signal values that are dynamically calculated by the control algorithms of
the behavior model.
§ Provide status information to the behavior model.

By default, model access is disabled for all function ports that are available
for bus configuration features. You can change this default behavior using
the Bus Configuration Behavior table. Refer to Specifying the Behavior
for Assigning Communication Matrix Elements and Adding Bus Configuration
Features (Preview Version) on page 125.

Note

Enabling model access increases the complexity of Bus Configuration

function blocks and the signal chain . For optimum performance, it is
therefore recommended to enable model access only for those function
ports whose values you want to exchange with the behavior model.

Tip

You can access the property in the Properties Browser and in the Bus
Configuration Ports table.

Enabling test automation Basics on test automation support To access bus configuration features via
support experiment software such as ControlDesk or automation scripts, you have to set
the Activate test automation support property for the related function ports
to Enabled. This lets you, for example:
§ Switch the signal source, i.e., use the original signal or a substitute signal.
§ Manipulate signal values via experiment software.
§ Carry out test automation tasks.
When test automation support is enabled for a function port, you can specify
the initial signal source (i.e., the original signal or substitute signal) via the Initial
switch setting property.

199
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with Bus Configuration Features

For the substitute signal, each function port provides a default initial substitute
value that is specific for the related bus configuration feature. Via the Initial
substitute value property, you can specify a user-defined initial substitute value.

Tip

§ For the values of the Initial substitute value and Initial value
properties, the same rules apply. For example, if the default value of the
Initial value property is derived from the communication matrix, this also
applies to the default value of the Initial substitute value property.
§ You can access the properties in the Properties Browser and in the Bus
Configuration Ports table.

Note

Depending on the related bus configuration feature, a user-defined initial

substitute value might be saturated, for example, if you replace or modify a
communication matrix.

When test automation support is enabled, variables are generated into the
variable description file when you build a real-time application or generate
bus simulation containers. The variables let you access the function port via
experiment software and automation scripts. Moreover, the generated variables
determine which value is used as the initial function port value. Refer to
Accessing Function Ports with Enabled Test Automation Support in Variable
Description Files (TRC Files) on page 202.

Default enable state The default enable state of test automation support
depends on the bus configuration feature for which a function port is available
and the function port type, as shown in the following table.

Bus Configuration Function Default Settings of Function Ports

Feature Port Type
Test Automation Initial Switch
Support Setting
Bus simulation features In Disabled -
Out § Disabled Only for the Raw
§ Only for the Raw Data function port
Data function port (PDU Raw Data
(PDU Raw Data feature): I/O signal
feature): Enabled
Bus inspection features In Enabled Substitute value
Out Enabled I/O signal
Bus manipulation In Enabled Substitute value
features Out Enabled I/O signal
Bus gateway features In Disabled -

Tip

For bus gateway features, no function outports are available.

200
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Basics on Working with Bus Configuration Features

You can change the default enable state using the Bus Configuration Behavior
table. Refer to Specifying the Behavior for Assigning Communication Matrix
Elements and Adding Bus Configuration Features (Preview Version) on page 125.

Specifying saturation values If required, the values of function inports are saturated at run time. By
for function inports default, system-specific saturation limits are used. Depending on the related bus
configuration feature, the system-specific limits are derived from the function
inport's data type, for example. For some function inports, you can specify
user-defined saturation values to limit the minimum and maximum values of the
function port.

Note

Depending on the related bus configuration feature, user-defined saturation

values might be saturated, for example, if you replace or modify a
communication matrix.

To use user-defined saturation values, you must set the Saturation usage
property of the related bus configuration to User min/max value, as shown
in the following example.

If you do this, the function inports that let you specify user-defined saturation
values provide a Saturation minimum value and Saturation maximum value
property, as shown in the following example.

The properties let you specify user-defined minimum and maximum saturation
values in the range of the function inport's value range. If necessary, the Bus

201
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with Bus Configuration Features

Manager automatically adjusts the specified saturation values to avoid overflows

at run time, for example, when an ISignal is encoded in a PDU and the
specified saturation values exceed the ISignal's boundaries.

For details on working with saturation values, refer to Specifying User Saturation
(ConfigurationDesk I/O Function Implementation Guide ).

Related topics References

Bus Configuration (ConfigurationDesk Function Block Properties )

Accessing Function Ports with Enabled Test Automation Support in Variable

Description Files (TRC Files)

Introduction For function ports with enabled test automation support, variables are generated
into the variable description file (TRC file ) when you build a real-time
application or generate bus simulation containers. The variables let you access
the function ports via experiment software and automation scripts.

Overview of the variables In general, up to four variables can be generated for each function port with
enabled test automation support, as shown in the following example.

Bus Configuration

TA_Switchvalue

Model
MDL_Signal
outport
Function inport IO_Signal TA switch

TA_Replacevalue

TA_Switchvalue

Function outport IO_Signal

Model
TA switch MDL_Signal
inport
TA_Replacevalue

Variables in variable Signal direction

description file

202
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Basics on Working with Bus Configuration Features

Tip

Examples of the function port types are:

§ Function inports: Value function port of the ISignal Value feature that
is added to a TX ISignal
§ Function outports: Value function ports of the ISignal Value feature
that is added to an RX ISignal

The variables are used as follows:

Variable Purpose
IO_Signal § Function inport: Provides the input signal to the function port.
§ Function outport: Provides the output signal of the function port.
MDL_Signal § Function inport: Provides the output signal of a mapped model
port, i.e., of the related function in the behavior model.
§ Function outport: Provides the input signal to a mapped model
port, i.e., to the related function in the behavior model.
TA_Switchvalue Lets you switch the signal source between the original signal or a
substitute signal. The original signal depends on the function port
type:
§ Original signal of a function inport: Signal of the MDL_Signal
variable.
§ Original signal of a function outport: Signal of the IO_Signal
variable.
TA_Replacevalue Provides the value of the substitute signal.

However, the configuration of each function port determines which variables are
generated. By default, an optimized set of variables is generated for each bus
configuration function port.

Optimized set of variables When you add a bus configuration to the ConfigurationDesk application, an
optimized set of variables is generated for each of its function ports by default.
This ensures optimum run-time performance.

Note

For bus configurations that were added to the ConfigurationDesk

application with dSPACE Release 2020‑B or earlier, the default setting
differs. Refer to Bus configurations added with dSPACE Release 2020‑B or
earlier on page 206.

For each function port of the bus configuration, only those variables are
generated into the TRC file that are typically used in common bus use scenarios.
To determine these variables, the following aspects are considered:
§ Function port type, i.e., function inport or function outport
§ Function port mapped to model port
§ TRC file generated for real-time application or bus simulation container

The optimized set of variables also determines the value that is used as the initial
function port value.

203
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with Bus Configuration Features

The following table provides an overview of the optimized set of variables.

Function Conditions Generated Variables Initial Function Port Value

Port Type
In Function port mapped to model port § IO_Signal Depends on the Initial switch setting property:
§ MDL_Signal § Initial switch setting set to Model signal:
§ TA_Replacevalue Value specified for the Initial value property.
§ TA_Switchvalue § Initial switch setting set to Substitute
value: Value specified for the Initial
substitute value property.
All of the following conditions: § IO_Signal Value specified for the Initial substitute value
§ TRC file generated for real-time § TA_Replacevalue property.
application
§ Function port not mapped to model
port, regardless of the setting of the
Model access property
All of the following conditions: § IO_Signal Value specified for the Initial substitute value
§ TRC file generated for bus simulation § TA_Replacevalue property.
container
§ Function port not mapped to model
port and Model access set to Disabled
All of the following conditions: § IO_Signal Depends on the Initial switch setting property:
§ TRC file generated for bus simulation § MDL_Signal § Initial switch setting set to Model signal:
container § TA_Replacevalue Value specified for the Initial value property.
§ Function port not mapped to model § TA_Switchvalue § Initial switch setting set to Substitute
port and Model access set to Enabled value: Value specified for the Initial
substitute value property.
Out Function port mapped to model port § IO_Signal Value specified for the Initial value property.
§ MDL_Signal
Function port not mapped to model port IO_Signal Value specified for the Initial value property.

For details on the optimized set of variables, refer to Optimized Set of TRC File
Variables for Bus Configuration Function Ports on page 540.

Specifying the set for Each bus configuration provides a Variable description property that lets you
generating variables specify whether the optimized set of variables or a complete set is generated.

Note

For optimum run-time performance, it is strongly recommended to generate

the optimized set of variables.

When you select a bus configuration (e.g., in the Bus Configurations table), the
Variable description property is available on the Model Interface page in the
Properties Browser.

204
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Basics on Working with Bus Configuration Features

The Variable description property lets you specify which set of variables to
generate for all function ports of the bus configuration:
§ Optimized: The optimized set of variables is generated. Moreover, for
function inports, further optimizations are used at run time to improve the
run‑time performance. Refer to Run‑time optimizations of the Optimized
mode for function inports on page 205.
§ Complete: The complete set of variables is generated.

Tip

If you set the Variable description property for the Bus Configuration
function block type in the Function Browser, the setting applies to all
newly added bus configurations.

You can use bus configurations with different settings of the Variable
description property in the same ConfigurationDesk application.

Complete set of variables If you set the Variable description property to Complete, the following
variables are generated:

Function Port Type Condition Generated Variables

In - § IO_Signal
§ MDL_Signal
§ TA_Replacevalue
§ TA_Switchvalue
Out Mapped to model port § IO_Signal
§ MDL_Signal
§ TA_Replacevalue
§ TA_Switchvalue
Not mapped to model port IO_Signal

For more information, refer to Configuring Test Automation Support

(ConfigurationDesk I/O Function Implementation Guide )

Run‑time optimizations of the Setting the Variable description property to Optimized has effects on the
Optimized mode for function TA_Switchvalue and IO_Signal variables of function inports: For optimum
inports run‑time performance, the TA_Switchvalue variable is not evaluated in every
sampling step but only when the transmission of the related PDU is triggered.
Because of this, the value of the IO_Signal variable is updated only when the
transmission of the related PDU is triggered.

For example, you add the ISignal Value feature to a TX ISignal, i.e., the
respective Value function port is a function inport. You map the function port
to a model port and enable test automation support. Moreover, you add the
PDU Trigger feature to the related PDU and the transmission of the PDU is
triggered only by this feature.

205
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with Bus Configuration Features

When you now change the value of the Value function inport at run time, the
IO_Signal variable is updated when you trigger the transmission of the PDU
using the PDU Trigger feature.

Tip

§ If you use Bus Instruments in ControlDesk to access the variables, the

IO_Signal variable is assigned to the Inspect Value fields of the
instruments.

In the example above, Substitute Value of CurrentGearISignal was

changed to 12. However, the transmission of the related PDU was not
triggered yet. Therefore, Inspect Value is not updated.
§ This behavior applies only if both the TA_Switchvalue and IO_Signal
variables are generated into the TRC file. If only the IO_Signal variable is
generated into the TRC file, its value is updated immediately.

Bus configurations added If the ConfigurationDesk application contains bus configurations that were
with dSPACE Release 2020‑B added with dSPACE Release 2020-B or earlier, the Variable description
or earlier property of these bus configurations is set to Complete. For optimum run-time
performance, it is recommended to set the Variable description property of the
bus configurations to Optimized. If you do this and you use automation scripts
to access variables of TRC files, you might have to adapt the automation scripts.

Restrictions for the optimized For the function ports of the following bus configuration features, no optimized
set of variables set of variables can be generated:
§ Frame Capture Data feature
§ Filter Control feature
§ LIN Schedule Table feature

206
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Basics on Working with Bus Configuration Features

Instead, the complete set of variables is always generated for the function ports
of these features, even if the Variable description property is set to Optimized.
Moreover, no run‑time optimizations are used for the function inports of these
features.

Using TRC File Variables for XIL Mapping

Introduction When you build a real‑time application or generate bus simulation containers,
the Bus Manager generates an XIL mapping file for each application process.
In XIL mapping scenarios according to the ASAM XIL standard, the XIL
mapping files let you access the TRC file variables that are available for bus
configuration function ports. You can use the XIL mapping files, for example, in
experiment software such as ControlDesk to decouple the access to the TRC file
variables from their exact path in the TRC file.

For an introduction to XIL mapping and its integration into the dSPACE tool
chain, refer to Getting Started with XIL Mapping .

For more information on the TRC file variables that are available for bus
configuration function ports, refer to Accessing Function Ports with Enabled Test
Automation Support in Variable Description Files (TRC Files) on page 202.

Content of the XIL mapping The XIL mapping files that are generated by the Bus Manager contain the
files following:

Content Description
Framework The framework labels are generated for the TRC file variables of bus
labels configuration function ports. Framework labels consist of a label name,
i.e., the label ID, and a data type. The label IDs must be unique for each
framework label.
§ The Bus Manager uses a default template to generate unique
framework label IDs. Refer to Default XIL framework label ID template
on page 208.
§ You can configure the template to generate framework label IDs
according to your requirements. Refer to Configuring the XIL
framework label ID template on page 209.
Testbench The testbench labels contain the path of the TRC file variables in the TRC
labels file.
Label The label mappings map the framework labels to the related testbench
mappings labels.

Including the XIL mapping Depending on whether you build a real‑time application or generate bus
files in real‑time applications simulation containers, the following applies:
and bus simulation containers
Real‑time application During the build process, the XIL mapping files
that are generated by the Bus Manager are merged with XIL mapping files
that are available for other elements of the ConfigurationDesk application.

207
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with Bus Configuration Features

The resulting overall XIL mapping file is named <name of the real‑time
application>.xilmapping.xml and is available in the Build Results folder.

For more information, refer to Using Elements that Provide XIL Mapping Files
(ConfigurationDesk Real-Time Implementation Guide ).

Bus simulation containers The XIL mapping files are included in the
generated bus simulation containers. You can use the resulting BSC files, for
example, as follows:
§ Import the BSC files to ConfigurationDesk to include them in a
real‑time application. When you do this, the XIL mapping files of
the BSC files are merged with other available XIL mapping files. The
resulting overall XIL mapping file is named <name of the real‑time
application>.xilmapping.xml and is available in the Build Results folder.
§ Import the BSC files to VEOS and include them in an offline simulation
application. Use the resulting OSA file in the ApplTools XILMapper of the
ApplTools Solution to merge the XIL mapping files of the BSC files with other
available XIL mapping files. The ApplTools XILMapper names the resulting
overall XIL mapping file Merged.xilmapping.xml and stores it in the same
folder as the OSA file.
For an overview of the process when using VEOS, refer to VEOS (Getting
Started with XIL Mapping ).

Default XIL framework By default, the Bus Manager uses the following template to generate framework
label ID template label IDs for each applicable TRC file variable:

<bus configuration name>_<bus configuration part>_<communication matrix name>_<frame capture name>_<frame gateway
name>_<ECU name>_<PDU name>_<PDU direction>_<bus configuration feature>_<function port name>_<variable name>

This template ensures that the resulting framework label IDs are unique for all
TRC file variables that are available for bus configuration function ports of the
active ConfigurationDesk application.

Tip

If a macro is not applicable for a specific TRC file variable, it is ignored. For
details, refer to the following description.

208
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Basics on Working with Bus Configuration Features

Configuring the XIL If required, you can configure the XIL framework label ID template according to
framework label ID template your requirements. You can do this in the Buses category on the Options page.
You can access the Options page on the File ribbon.

You can configure the template in the XIL framework label ID template edit
field using static texts and macros from the Available macros list. To apply the
changes, you have to click Apply. When you do this, the configured template
becomes the active template, i.e., the framework label IDs are generated
according to this template.

For an animated graphic providing an example of configuring the XIL framework

label ID template, refer to dSPACE Help.

Note

When you configure the XIL framework ID template, note the following:
§ You have to manually ensure that the resulting framework label IDs are
unique. For example, deleting the %VariableName% macro from the
template will result in ambiguous IDs. This is because up to four TRC
file variables can be available for each function port.
If framework label IDs are ambiguous, the affected framework labels
cannot be used in XIL mapping scenarios. Refer to Effects of ambiguous
framework label IDs on page 210.
§ The configured template is stored locally with your user profile on the
host PC. It is not stored with the ConfigurationDesk project. Because of
this, the following applies:
§ The configured template is not included in the ZIP archive when you
back up the ConfigurationDesk project and/or application.
§ The configured template is not available when you log on to the host
PC using another user profile or you open the project on another PC.

209
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with Bus Configuration Features

Tip

§ The macros are only evaluated for applicable TRC file variables. For
example, for TRC file variables that are available for function ports of
bus inspection features, the %BMECU% macro is not applicable. For these
variables, the macro is ignored for generating the framework label IDs.
§ You can use braces, i.e., { and }, to specify macro groups. Macro groups
let you group macros and static texts. When the macros of a macro group
are not applicable for specific TRC file variables, the macros and the static
texts of the macro group are ignored for generating the framework label
ID.

For a complete description of all elements in the Buses category, refer to

Configuration Options (ConfigurationDesk User Interface Reference ).

Effects of ambiguous If you configure the XIL framework label ID template in a way that results in
framework label IDs ambiguous framework label IDs, the following applies:
§ When you build a real‑time application, the affected framework labels are not
included in the overall XIL mapping file. Warning messages in the Message
Viewer and the dSPACE Log provide information on the affected framework
labels.
§ When you integrate affected BSC files in an offline simulation application and
use the ApplTools XILMapper to generate the overall XIL mapping file, each
first affected framework label is added to the file. All other framework labels
that have the same framework label ID are ignored. Warning messages in
the ApplTools XILMapper Log provide information on the affected framework
labels.

Accessing and configuring the You can use automation to get the default and the
template using automation currently active template, and to configure the template. You
can do this using the GetBmXilFrameworkLabelIdTemplate and
ConfigureBmXilFrameworkLabelIdTemplate operations of the Configure
method. For an example, refer to Examples of Automating Bus Manager Features
(ConfigurationDesk Automating Tool Handling ).

Triggering the Transmission of PDUs and Frames via User-Defined Triggers

Introduction Typically, the transmission of PDUs and frames is triggered according to

specifications in the communication matrix, such as cyclic timings. Via the PDU
Trigger and Frame Access feature, you can specify user-defined triggers to
trigger the transmission of PDUs and frames. This lets you transmit PDUs and
frames continuously or asynchronously to a cyclic timing, for example.

210
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Basics on Working with Bus Configuration Features

Specifying user-defined Specifying user-defined triggers for transmitting a PDU or frame comprises the
triggers for the transmission following basic steps:
of PDUs and frames 1. Add the PDU Trigger or Frame Access feature to the PDU. Refer to Adding
bus configuration features on page 192.
For more information on the features, refer to Specifying User-Defined
Triggers for Transmitting PDUs on page 246 and Accessing CAN Frame
Settings on page 288, respectively.
2. Select a triggering mode. Refer to Triggering modes for triggering the
transmission of PDUs and frames on page 211.
3. Configure the Trigger function port. Refer to Configuring Trigger function
ports on page 212.

Triggering modes for When you add the PDU Trigger or Frame Access feature to a PDU, a Trigger
triggering the transmission of mode property is available, as shown in the following example.
PDUs and frames

Via the Trigger mode property, you can select one of the following triggering
modes to specify the trigger behavior:
§ Positive edge: The transmission of the PDU or frame is triggered once each
time a positive edge is detected, i.e., when the value of the related Trigger
function port changes from 0 to 1.

Tip

If the function port value was set via an experiment software during
run time, the function port value is automatically reset to 0 after the
PDU/frame was triggered.

§ Level-triggered: The transmission of the PDU or frame is triggered

continuously as long as the value of the related Trigger function port is set
to 1. The transmission of the PDU/frame stops when the function port value is
set to 0 via model input or experiment software.

The selected triggering mode does not influence the timing of the transmission.
This is determined as follows:

Feature Description
PDU The timing depends on the task to which the related BusCfg_MainFunctionDeliver [<bus configuration
Trigger name>] runnable function is assigned. Moreover, specifications of the communication matrix might influence the
timing, e.g., if a minimum delay time is specified for the PDU or the PDU is a contained IPDU and for the related
container IPDU a container timeout value is specified.
Frame The timing depends on the task to which the related BusCfg_MainFunctionDeliver [<bus configuration
Access name>] runnable function is assigned. Specifications of the communication matrix do not influence the timing.
When the deliver runnable function evaluates the trigger, the frame data is calculated according to the specified
settings of the Frame Access feature and the frame is transmitted on the bus.

211
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with Bus Configuration Features

For more information on BusCfg_MainFunctionDeliver [<bus

configuration name>] runnable functions, refer to Fetch and Deliver
Runnable Functions for Receiving and Transmitting PDUs on page 366.

Configuring Trigger function When you add the PDU Trigger or Frame Access feature to a PDU, a Trigger
ports function port is available that lets you trigger the transmission of the PDU or its
related frame at run time.

The default settings of the Trigger function port prohibit the transmission of the
related PDU or frame during run time. Depending on the selected triggering
mode, you must therefore change the default settings of the Trigger function
port to trigger the transmission of the PDU/frame during run time:
§ If you selected Positive edge as the triggering mode, the transmission of the
PDU/frame is triggered when the function port value changes from 0 to 1
during run time. To change the function port value during run time, you have
to enable model access or test automation support for the function port.
§ If you selected Level-triggered as the triggering mode, the transmission of
the PDU/frame is triggered when the function port value is 1 during run time.
You can specify 1 as a constant value by setting the function port's Initial
value to True. Alternatively, you can enable model access or test automation
support to change the function port value during run time.

For more information on enabling model access and test automation support,
refer to Configuring Function Ports for Bus Configuration Features on page 198.

Related topics Basics

Limitations for Communication Matrices and Communication Standards................................ 519

212
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Manipulating Bus Communication via Bus Configuration Features

Manipulating Bus Communication via Bus Configuration

Features
Where to go from here Information in this section

Basics on Bus Manipulation Features...................................................... 213

Recalculating End-to-End Protection and Authentication

Information........................................................................................... 217

Execution Sequence of Bus Manipulation Features................................. 220

Basics on Bus Manipulation Features

Introduction Manipulating bus communication differs slightly from simulating or inspecting

bus communication: In addition to feature-specific elements and settings,
each bus manipulation feature provides common manipulation elements and
settings. These elements and settings influence the run-time behavior of bus
communication manipulation.

Common manipulation Overview The following elements and settings are common to bus
elements and settings manipulation features:

Element/Setting Description Refer to …

Permanent or temporary For each bus manipulation feature, you can specify Permanent or temporary manipulation
manipulation to manipulate the bus communication permanently or on page 214
temporarily.
Feature switch For bus manipulation features that are available for ISignals, Feature switch of ISignals on page 214
you can specify which feature is active at run time.
Tunable properties Bus manipulation features let you access their tunable Accessing tunable properties on
properties in different ways. page 214
Recalculate end-to-end For bus manipulation features that affect end-to-end- Recalculating End-to-End Protection
protection protected ISignal groups, you can specify whether the end-to- and Authentication Information on
end protection information is recalculated. page 217
Recalculate For bus manipulation features that affect secure onboard Recalculating End-to-End Protection
authentication communication, you can specify whether the authentication and Authentication Information on
information information of secured IPDUs is recalculated. page 217

Specifying the manipulation behavior Via the common manipulation

elements and settings of bus manipulation features, you can specify the
manipulation behavior in one of the following ways:
§ For bus manipulation features that do not apply to ISignals, you can specify
the manipulation behavior via the feature-specific feature node, its related

213
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with Bus Configuration Features

function ports, and the Bus Manipulation Features table. Refer to Specifying
the manipulation behavior for bus manipulation features that do not apply to
ISignals on page 215.
§ For bus manipulation features that apply to ISignals, you can specify the
manipulation behavior via the ISignal's feature switch, its related function
ports, and the Bus Manipulation Features table. Refer to Specifying the
manipulation behavior for bus manipulation features that apply to ISignals on
page 216.
Additionally, if an element is affected by multiple bus manipulation features at
run time, the execution sequence influences the manipulation behavior. Refer to
Execution Sequence of Bus Manipulation Features on page 220.

Permanent or temporary For each bus manipulation feature, you can specify whether it manipulates the
manipulation related bus configuration element permanently or temporarily at run time:
§ Permanent manipulation
The related bus configuration element is manipulated by the bus manipulation
feature until the manipulation is explicitly stopped, e.g., via experiment
software.
§ Temporary manipulation
During temporary manipulation, the bus configuration element is manipulated
for a defined number of times. You can specify the number of manipulations
via a countdown value. The specified countdown value is decremented with
each transmission of the bus configuration element. When the value reaches
0, the manipulation stops and the bus configuration element is transmitted
with its regular value, for example. You can use temporary manipulation to
test the fault memory of an ECU, for example.

Feature switch of ISignals When you manipulate ISignals via bus manipulation features, only one feature
can be active at a time. Therefore, a feature switch is available for each ISignal
when you add a bus manipulation feature to the ISignal, as shown in the
following example.

Via the feature switch, you can specify which of the available bus manipulation
features is active and whether it manipulates the ISignal permanently or
temporarily. Via the available function ports, you can change the specified
settings at run time. When you remove all bus manipulation features from the
ISignal, the feature switch is deleted automatically.

Accessing tunable properties Tunable properties can be accessed and changed at run time, e.g., via
experiment software. Typically, the tunable properties that are available for bus
configuration features can be accessed in the ConfigurationDesk application
via function ports only. For bus manipulation features, most of the tunable

214
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Manipulating Bus Communication via Bus Configuration Features

properties that are represented by function inports can additionally be accessed

in the following ways:
§ Via properties of the related feature node ( ) and/or Feature Switch node
( ) in the Bus Configurations table.

§ Via the Bus Manipulation Features table

However, not all columns that are available for the table are displayed by
default. You can add required columns via the Column Chooser. Refer to Bus
Configuration Tables on page 103.

The values that are specified via the properties of the related nodes or in the Bus
Manipulation Features table apply to the Initial value and Initial substitute
value properties of the related function ports and vice versa. If you specify
different values for the Initial value and Initial substitute value properties of a
function port, the related property and table cell display both values.

For more information on the Initial value and Initial substitute value
properties of function ports, refer to Configuring Function Ports for Bus
Configuration Features on page 198.

Specifying the manipulation You can specify the manipulation behavior by means of various elements. For bus
behavior for bus manipulation features that do not apply to ISignals, these elements are available
manipulation features that do as properties of the feature-specific feature node ( ), as function ports, and/or
not apply to ISignals in the Bus Manipulation Features table as follows:

215
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with Bus Configuration Features

Element Node Function Table Value Range Purpose

Name Property Port Entry
Enable ✓ ✓ – § 0: Disabled Specifies the initial state of the feature.
§ 1: Permanently If the feature is temporarily enabled, it manipulates the
enabled related bus configuration element for the number of times
§ 2: Temporarily that are specified for Countdown start value. Then, this
enabled manipulation feature is disabled. However, the related bus
configuration element can still be manipulated by other bus
manipulation features.
Bus manipulation features are disabled by default.
Enable state – ✓ – 0 … 255 Provides the current state of the feature, e.g., to a mapped
behavior model.
Countdown ✓ ✓ ✓ 0 … UInt32max Specifies the countdown start value. If the bus manipulation
start value feature is temporarily enabled, this value determines how
often the bus configuration element is manipulated.
If you specify the countdown start value via the Bus
Manipulation Features table, the value applies to all
manipulation features of the selected bus configuration
element. If you specify the countdown start value via
a feature node or function port, it applies only to
the individual manipulation feature of the related bus
configuration element.
Current – ✓ – 0 … UInt32max Provides the current countdown value, e.g., to a
countdown mapped behavior model. If the bus manipulation feature
value is temporarily enabled, the current countdown value
is decremented with each transmission of the bus
configuration element. When the value reaches 0, the bus
manipulation feature is disabled.

For the Enable and Countdown Start Value function ports, you can additionally
specify user-defined saturation values to limit the minimum and maximum values
of the function ports. Refer to Specifying saturation values for function inports
on page 201.

Specifying the manipulation You can specify the manipulation behavior by means of various elements. For
behavior for bus bus manipulation features that apply to ISignals, these elements are available as
manipulation features that properties of the ISignal's Feature Switch node ( ), as function ports, and/or in
apply to ISignals the Bus Manipulation Features table as follows:

216
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Manipulating Bus Communication via Bus Configuration Features

Element Node Function Table Value Range Purpose

Name Property Port Entry
Feature switch ✓ ✓ ✓ § 0: None Specifies the initially active feature and its state.
§ n: <bus If the active feature is temporarily enabled, it
manipulation manipulates the related ISignal for the number of times
feature 1> that is specified for Countdown start value. Then,
(permanently) the manipulation of the ISignal stops, i.e., the feature
§ n+1: <bus switch is set to 0: None.
manipulation The default value of the feature switch is 0: None.
feature 1>
(temporarily) Tip
§ m: <bus
manipulation The feature switch value unambiguously relates
feature 2> to a specific feature and its state. For example,
(permanently) a value of 3 enables the ISignal Offset Value
§ m+1: <bus feature permanently, regardless of whether other
manipulation manipulation features are added to the ISignal.
feature 2>
(temporarily)
Selected – ✓ – 0 … UInt32max Provides the number of the currently active feature,
feature e.g., to a mapped behavior model.
Countdown ✓ ✓ ✓ 0 … UInt32max Specifies the countdown start value. If the active bus
start value manipulation feature is temporarily enabled, this value
determines how often the ISignal is manipulated.
Current – ✓ – 0 … UInt32max Provides the current countdown value, e.g., to a
countdown mapped behavior model. If the active bus manipulation
value feature is temporarily enabled, the current countdown
value is decremented with each transmission of the
ISignal. When the value reaches 0, the manipulation of
the ISignal stops.

For the Feature Switch and Countdown Start Value function ports, you can
additionally specify user-defined saturation values to limit the minimum and
maximum values of the function ports. Refer to Specifying saturation values for
function inports on page 201.

Recalculating End-to-End Protection and Authentication Information

Introduction In the following cases, using bus manipulation features might result in
unintended effects:
§ You manipulate ISignals that are included in an end-to-end-protected ISignal
group.
§ You manipulate PDUs and/or ISignals that are secured by a secured IPDU .

In these cases, the end-to-end protection information of the ISignal group

and/or the authentication information of the secured IPDU might become
incorrect because the related information is calculated without considering the
manipulated data.

217
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with Bus Configuration Features

To prevent this, you can enable recalculation of the related end-to-end protection
and/or authentication information before transmission.

Enabling and disabling the For bus manipulation features that can affect end-to-end protection and/or
recalculation authentication information, you can enable and disable the recalculation as
follows:

Bus Manipulation Properties Browser Bus Manipulation

Feature Features Table
Affecting …
End-to-end Via the Recalculate end-to-end In the Recalculate End-
protection protection property that is to-End Protection -
information available for the feature node <feature> column.
( ).
Authentication Via the Recalculate SecOC In the Recalculate SecOC
information information property that is Information -<feature>
available for the feature node column.
( ).

However, in the Bus Manipulation Features table, not all of the columns are
available by default. You can add required columns via the Column Chooser.
Refer to Bus Configuration Tables on page 103.

For most bus manipulation features that can affect end-to-end protection and/or
authentication information, the recalculation is enabled by default. You cannot
change the specified setting during run time.

Run-time behavior for Data is recalculated if an ISignal group or secured IPDU is affected by at least
recalculating data one bus manipulation feature at run time for which recalculation is enabled.
This applies even if the ISignal group/secured IPDU is also affected by bus
manipulation features for which recalculation is disabled.

For example, a secured IPDU contains an ISignal IPDU with two ISignals, each of
which configured as follows:

Element Bus Manipulation Feature Recalculate SecOC Information

Secured IPDU SecOC Authenticator Invalidation -
ISignal IPDU PDU User Code ✓
ISignal 1 ISignal Overwrite Value ✓
ISignal 2 ISignal Overwrite Value ✓
ISignal Offset Value -

At run time, the authentication information of the secured IPDU is recalculated

as long as the PDU User Code feature of the ISignal IPDU or the ISignal
Overwrite Value feature of ISignal 1 or ISignal 2 is enabled permanently or
temporarily.

218
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Manipulating Bus Communication via Bus Configuration Features

Tip

Different enable states for recalculating the related data might be useful
if you want to configure an element once for different manipulation
scenarios. For example, with the settings above, you can enable and disable
the related features at run time to switch between data manipulation that
affects the authentication information and data manipulation that does not.

However, recalculating the end-to-end protection or authentication information

is performed only once per sampling step, regardless of whether it is enabled for
multiple bus manipulation features that affect the ISignal group or secured IPDU.
For more information, refer to Execution Sequence of Bus Manipulation Features
on page 220.

Specific aspects for Enabling and disabling the recalculation for specific bus manipulation
recalculating authentication features For the following bus manipulation features, special points are
information to note for enabling and disabling the recalculation of the authentication
information:
§ SecOC Freshness Overwrite Value feature: You cannot disable the
recalculation. Refer to Overwriting the Freshness Value of Secured IPDUs on
page 274.
§ SecOC Authenticator Invalidation feature: The recalculation is disabled by
default because this is required for most use cases. Refer to Invalidating the
Authenticator of Secured IPDUs on page 271.

Recalculating the authentication information for cryptographic

IPDUs To recalculate the authentication information, the secured IPDU and
its related authentic IPDU are required. If a secured IPDU is configured as a
cryptographic IPDU, the cryptographic IPDU and its related authentic IPDU are
transmitted separately on the bus. Because of this, the following applies: If
the transmission of the cryptographic IPDU is triggered first at run time, the
transmission is delayed until the data of the authentic IPDU is available. Then
the authentication information is recalculated and after that, both IPDUs are
transmitted in the original order.
Moreover, some limitations apply for calculating the authentication information.
For more information, refer to Limitations for secure onboard communication on
page 522.

Related topics Basics

Aspects of End‑to‑End (E2E) Protection for ISignal Groups......................................................... 69

219
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with Bus Configuration Features

Execution Sequence of Bus Manipulation Features

Introduction Bus configuration elements can be affected by multiple bus manipulation

features. In this case, the data that is provided to bus manipulation features
and/or transmitted on the bus is determined by the sequence in which the
features are executed.

This particularly applies if end-to-end protection or authentication information

is recalculated: For an affected bus configuration element, the recalculation is
performed only once per sampling step, regardless of whether recalculation is
enabled for multiple bus manipulation features.

Moreover, the manipulation applies immediately before a frame is transmitted

on the bus. Refer to Use Scenarios for Manipulating Bus Communication on
page 34.

Execution sequence of bus At run time, bus manipulation features are executed in the following sequence:
manipulation features 1. Suspend Frame Transmission feature
2. Manipulation features that are available for ISignals
3. Recalculate end-to-end protection information
4. SecOC Authenticator Invalidation feature
5. PDU User Code feature
6. SecOC Freshness Overwrite Value feature and recalculate authentication
information
7. Frame Length feature

220
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Bus Configuration Features Available for ISignals

Bus Configuration Features Available for ISignals

Where to go from here Information in this section

Working with ISignal Values.................................................................. 221

Working with Counter Signals............................................................... 223

Overwriting ISignal Values..................................................................... 228

Adding Offset Values to ISignal Values................................................... 231

Working with ISignal Values

Introduction You can work with the values of ISignals that are assigned to the Simulated
ECUs or Inspection part of a bus configuration.

Conditions for accessing To access the value of an ISignal, you have to add the ISignal Value feature to
ISignal values the ISignal. Refer to Adding bus configuration features on page 192.

You can add the feature to TX and RX ISignals.

By default, the ISignal Value feature is added automatically to ISignals that

are assigned to the Simulated ECUs part. For ISignals that are assigned to
the Inspection part of a bus configuration, you have to add the ISignal
Value feature manually. You can change this default behavior using the
Bus Configuration Behavior table. Refer to Specifying the Behavior for
Assigning Communication Matrix Elements and Adding Bus Configuration
Features (Preview Version) on page 125.

Effects of adding the ISignal Depending on the direction of the ISignal (TX or RX ), a TX Value function
Value feature port or RX Value function port is available for the ISignal.

The following illustration is an example of the function ports as displayed in the

Bus Configurations table:

221
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with Bus Configuration Features

Accessing ISignal values The Value function port provides the ISignal value as follows:
§ For TX ISignals, the function port value specifies the ISignal value that is
transmitted on the bus.
§ For RX ISignals, the function port provides the received ISignal value, e.g., to a
mapped behavior model.

The data type and value range of the function port are determined by the
physical base data type of the ISignal.

By default, the initial function port value is the ISignal value that is specified in
the communication matrix . If the communication matrix does not specify an
ISignal value, 0 is used as the initial function port value.

Via the function port's Initial value property, you can specify a user-defined
initial ISignal value. If required, the value of the Initial value property is
automatically saturated when the physical base data type of the ISignal changes.
This can happen in the following cases:
§ You modify the communication matrix. Refer to Basics on Modifying
Communication Matrices on page 391.
§ You replace the assigned communication matrix. Refer to Replacing Assigned
Communication Matrices on page 435.

To access the ISignal value at run time, you have to enable model access or test
automation support for the function port. Refer to Configuring Function Ports
for Bus Configuration Features on page 198.

Specifying saturation values By default, TX ISignal values are limited by the ranges of the ISignal's physical
for TX ISignals base data type and automatically saturated at run time if required. Via the TX
Value function port, you can specify user-defined saturation values to limit the
minimum and maximum TX ISignal values. If you want to do this, you have to
first set the bus configuration's Saturation usage property to User min/max
value. Refer to Specifying saturation values for function inports on page 201.
However, you can specify user‑defined saturation values only for TX ISignals
whose physical base data type is not set to Boolean.

If required, the saturation values are automatically saturated when the physical
base data type changes. This can happen in the following cases:
§ You modify the communication matrix. Refer to Basics on Modifying
Communication Matrices on page 391.
§ You replace the assigned communication matrix. Refer to Replacing Assigned
Communication Matrices on page 435.

Restrictions for using the If you use the ISignal Value feature, the following restrictions apply:
ISignal Value feature § You cannot use the ISignal Value feature in parallel with the following bus
configuration features:
§ Counter Signal feature (applies only to TX ISignals and TX PDUs)
§ PDU Raw Data feature (applies only to TX ISignals and TX PDUs)
§ Frame Access feature

222
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Bus Configuration Features Available for ISignals

If you add the ISignal Value feature and at least one of the other features to
an ISignal or to a PDU in which the ISignal is included, conflicts occur.

Tip

If you add the ISignal Value, Counter Signal, and PDU Raw Data
feature to an RX ISignal and to the RX PDU in which the ISignal is
included, the values provided by each feature are updated at run time
and can be accessed in parallel.

§ Enabling model access and/or test automation support for a high number
of ISignals might reduce the performance. For optimum performance, enable
these function port properties only if you really need them, i.e.:
§ Enable model access only for those ISignals whose signal values you want to
exchange with the behavior model.
§ Enable test automation support only for those ISignals whose signal values
you want to access via an experiment software such as ControlDesk.

Related topics References

Function Inport Properties (Bus Configuration) (ConfigurationDesk Function Block

Properties )
Function Outport Properties (Bus Configuration) (ConfigurationDesk Function Block
Properties )

Working with Counter Signals

Introduction You can configure ISignals that are assigned to the Simulated ECUs or
Inspection part of a bus configuration as counter signals. You can use counter
signals to detect lost PDUs or test counters that are implemented in the ECU
under test, for example.

Conditions for working with To use an ISignal as a counter signal, you have to add the Counter Signal
counter signals feature to the ISignal. Refer to Adding bus configuration features on page 192.
Moreover, you have to specify the available counter settings.

You can add the feature to TX and RX ISignals with the following base data
types:
§ Physical base data type: Int8 … Int64
§ Physical base data type: UInt8 … UInt64

However, you cannot add the Counter Signal feature to array signals.

223
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with Bus Configuration Features

Effects of adding the Counter Adding the Counter Signal feature to an ISignal has the following effects:
Signal feature

§ Counter settings are available for the ISignal that let you configure the
counter. You can access the counter settings in two ways:
§ In the Properties Browser when you select the Counter Signal node in the
Bus Configurations table.

§ In the Bus Simulation Features or Bus Inspection Features table, as

shown in the following example.

Tip

If a required column is not available, you can add it via the Column
Chooser. Refer to Bus Configuration Tables on page 103.

You cannot change the counter settings at run time. Therefore, no function
ports are available for these settings.
§ If you add the Counter Signal feature to an RX ISignal, a Counter State
function port is available for the ISignal. The function port provides the
counter state, i.e., if a received counter value is the expected value according
to the counter settings that are specified for the RX ISignal.

Overview of the configurable When you add the Counter Signal feature to an ISignal, you can configure the
counter settings following counter settings:

Counter Purpose Value Range

Setting
Minimum Lets you specify the minimum counter value. § Depends on the physical and coded base data
value types, and the length of the ISignal.

224
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Bus Configuration Features Available for ISignals

Counter Purpose Value Range

Setting
§ Maximum range: Int32min … Int32max
§ Default value: Minimum valid value according
to the conditions above
Maximum Lets you specify the maximum counter value. § Depends on the physical and coded base data
value types, and the length of the ISignal.
§ Maximum range: Int32min … Int32max
§ Default value: Maximum valid value according
to the conditions above
Increment Lets you specify the step size for incrementing the counter value. § -(<maximum value> - <minimum value>) ...
value +(<maximum value> - <minimum value>)
Note § Default value: 1

If the increment value is 0, the counter is disabled.

Initial value Lets you specify the initial value of the counter. § <minimum value> … <maximum value>
The specified value is used as the counter's initial value directly § Default value: <minimum value>
after the executable application is started. Depending on the
setting of the bus configuration's Initial value usage property,
the specified initial value is set only once at first application
start or every time the application starts, including when the
application state switches from stopped to running.
Step length Lets you specify the frequency for incrementing the counter § 1 … Int32max
value, i.e., if the counter value is incremented with each § Default value: 1
transmission/reception of the related PDU, with every other
transmission/reception etc.

The following table provides examples of counter values according to the

specified counter settings.

Minimum Maximum Increment Initial Step Counter Values

Value Value Value Value Length
0 15 2 0 1 0, 2, 4, 6, 8, 10 …
0 15 2 0 2 0, 0, 2, 2, 4, 4, 6,
6…
-8 15 2 -6 1 -6, -4, -2, 0, 2, 4 …
-8 15 -4 15 1 15, 11, 7, 3, -1,
-5 …

Counter behavior Basic counter behavior Counter values are calculated according to the
counter settings that are specified for the counter signal in the bus configuration.
Depending on the direction of the counter signal (TX or RX ), this results in
the following counter behavior:
§ In case of a TX counter signal, the counter value is calculated each time the
transmission of the related TX PDU is triggered. The calculated counter value is
then included in the PDU and transmitted on the bus.
The timing for calculating TX counter signal values depends on the task
to which the related BusCfg_MainFunctionDeliver [<bus configuration

225
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with Bus Configuration Features

name>] runnable function is assigned. Refer to Fetch and Deliver Runnable

Functions for Receiving and Transmitting PDUs on page 366.
§ In case of an RX counter signal, the counter value is calculated each time
the related RX PDU is received on the bus. The calculated counter value is
compared with the counter value that is actually received with the PDU. The
Counter State function port indicates if the received counter value was an
expected value. Refer to Counter states on page 226.
Some bus configuration features can influence the calculation of the counter
values. Refer to Effects of bus configuration features on counter values on
page 227.

Counter behavior when exceeding the counter limits If the counter

value exceeds the maximum or minimum counter value, the counter continues
counting as shown in the following examples:
§ Maximum counter value is exceeded:

Minimum Maximum Increment Initial Step Counter Values

Value Value Value Value Length
0 10 3 0 1 0, 3, 6, 9, 1, 4, 7,
10, 2, 5 …
-5 10 3 -5 1 -5, -2, 1, 4, 7, 10,
-3, 0, 3, 6 …

§ Minimum counter value is exceeded:

Minimum Maximum Increment Initial Step Counter Values

Value Value Value Value Length
0 10 -3 10 1 10, 7, 4, 1, 9, 6, 3,
0, 8, 5 …
-4 10 -3 10 1 10, 7, 4, 1, -2, 10,
7, 4, 1, -3, 0 …

Counter states RX counter signals provide a Counter State function port. The function port
value indicates the counter states as follows:

Function Port Counter State

Value
0 Ok: The counter signal is received with the expected counter value.
4 Initial state: The counter signal is not received yet.
7 Error: The counter signal is only partially received, e.g., because of a
reduced PDU length. Therefore, the counter signal is not decoded at
all.
64 Wrong sequence: The counter signal is received with an unexpected
counter value.

By default, the initial function port value is 4: Initial state. Via the function
port's Initial value property, you can change the default initial value. To
access the counter state at run time, you have to enable model access or test
automation support for the function port. Refer to Configuring Function Ports
for Bus Configuration Features on page 198.

226
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Bus Configuration Features Available for ISignals

Calculation of the expected counter value The expected counter value

is calculated according to the counter settings that are specified for the RX
counter signal in the bus configuration. However, the basis for calculating the
expected counter value is the last received counter value, regardless of whether
this counter value was an expected or unexpected value.
This synchronizes the RX counter with the related TX counter and ensures that
one received unexpected counter value does not result in permanent counter
errors.

Signal conversion of counter Like all signals that are transmitted and received by the Bus Manager, counter
signal values signal values are converted in the following ways:
§ For transmission, the physical signal values are converted into coded signal
values.
§ For reception, the coded signal values are converted into physical signal values.

The signal values are converted according to computation methods that are
specified in the communication matrix. For more information, refer to Signal
Conversion by the Bus Manager on page 60.

Depending on the computation methods, rounding effects might occur. The

rounding effects can result in different physical signal values on the sender and
receiver side. However, these effects have no influence on the counter state
that is provided by the Counter State function port because the function port
evaluates the coded counter signal values.

Effects of bus configuration The following bus configuration features can affect the calculation of counter
features on counter values values.

PDU Enable feature The calculation of counter values stops if a counter

signal is included in a TX PDU and the transmission of the PDU is disabled via
the PDU Enable feature. When the transmission of the PDU is enabled again,
the calculation of counter values continues, starting on the basis of the last
transmitted counter value. This ensures that no counter errors occur due to the
PDU Enable feature.

Communication Controller Enable feature and LIN Schedule Table

feature The calculation of counter values stops if a counter signal is included
in a PDU that is not transmitted or received via a communication cluster because
of at least one of the following reasons:
§ The related communication controller is disabled via the Communication
Controller Enable feature.
§ The LIN communication of the cluster is disabled via the LIN Schedule Table
feature.

Note

If the PDU is transmitted or received via multiple clusters, the calculation of

counter signals stops only if the PDU cannot be transmitted or received via
any of the related clusters.

227
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with Bus Configuration Features

When the PDU is transmitted or received via at least one of the related clusters
again, the counter value is reset to the initial counter value.

Restrictions for using the If you use the Counter Signal feature, the following restrictions apply:
Counter Signal feature § You cannot use the Counter Signal feature in parallel with the following bus
configuration features:
§ ISignal Value feature (applies only to TX ISignals and TX PDUs)
§ PDU Raw Data feature (applies only to TX ISignals and TX PDUs)
§ Frame Access feature
If you add the Counter Signal feature and at least one of the other features
to an ISignal or to a PDU in which the ISignal is included, conflicts occur.

Tip

If you add the Counter Signal, ISignal Value, and PDU Raw Data
feature to an RX ISignal and to the RX PDU in which the ISignal is
included, the values provided by each feature are updated at run time
and can be accessed in parallel.

§ If a counter signal is included in a TX PDU that is transmitted via a CAN

communication cluster and a LIN communication cluster, the counter values
are calculated only when the transmission of the PDU is triggered via the CAN
cluster. The counter values are not calculated when the transmission of the
PDU is triggered via the LIN cluster.

Related topics References

Function Outport Properties (Bus Configuration) (ConfigurationDesk Function Block

Properties )

Overwriting ISignal Values

Introduction You can overwrite the signal values of ISignals that are assigned to the
Manipulation part of a bus configuration with user-defined signal values.

Conditions for overwriting To overwrite the value of an ISignal with a user-defined value, you have to
ISignal values add the ISignal Overwrite Value feature to the ISignal. Refer to Adding bus
configuration features on page 192.

In general, you can add the feature to any ISignal that is assigned to the
Manipulation part. However, for ISignals that are included in J1939‑compliant
IPDUs, some limitations apply. Refer to Limitations for J1939 on page 526.

228
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Bus Configuration Features Available for ISignals

Effects of adding the ISignal Adding the ISignal Overwrite Value feature to an ISignal has the following
Overwrite Value feature effects:
§ If not already available, a feature switch is added to the ISignal. For the ISignal
Overwrite Value feature, the feature switch provides the following values:
§ 1: ISignal Overwrite Value (permanently)
§ 2: ISignal Overwrite Value (temporarily)
The feature switch lets you select the active bus manipulation feature and
specify whether it manipulates the ISignal permanently or temporarily. For
more information, refer to Basics on Bus Manipulation Features on page 213.

§ An Overwrite value property is available that lets you specify the value that
overwrites the ISignal value. You can access the property in following ways:
§ In the Properties Browser when you select the ISignal Overwrite Value
node in the Bus Configurations table.

§ In the Bus Manipulation Features table.

Tip

If the column is not available, you can add it via the Column Chooser.
Refer to Bus Configuration Tables on page 103.

§ If the ISignal is included in an end-to-end-protected ISignal group and/or

involved in secure onboard communication, a Recalculate end-to-end
protection and/or Recalculate SecOC information checkbox is available.
You can access the checkboxes in the following ways:
§ In the Properties Browser when you select the ISignal Overwrite Value
node in the Bus Configurations table.
§ In the Recalculate End-to-End Protection - ISignal Overwrite Value and
Recalculate SecOC Information - ISignal Overwrite Value columns of
the Bus Manipulation Features table, respectively.
If the related checkbox is selected, the end-to-end protection information of
the affected ISignal group or the authentication information of the affected
secured IPDU is recalculated before transmission. For more information, refer
to Recalculating End-to-End Protection and Authentication Information on
page 217.
§ An Overwrite Value function port is available. The following illustration is an
example of the function port as displayed in the Bus Configurations table:

229
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with Bus Configuration Features

Specifying overwrite values You can specify an overwrite value via the Overwrite value property. The
specified value applies to the Initial value and Initial substitute value
properties of the Overwrite Value function port automatically.

The value range of the properties is determined by the physical base data type of
the ISignal. If required, the property values are automatically saturated when the
physical base data type changes. This can happen in the following cases:
§ You modify the communication matrix. Refer to Basics on Modifying
Communication Matrices on page 391.
§ You replace the assigned communication matrix. Refer to Replacing Assigned
Communication Matrices on page 435.

However, the maximum valid overwrite value also depends on the ISignal
length. If the specified overwrite value exceeds the maximum valid value, it is
automatically saturated at run time.

Run-time behavior of The specified value overwrites the original ISignal value at run time only if the
specified overwrite values ISignal Overwrite Value feature is enabled. The exact behavior depends on
whether the feature is permanently or temporarily enabled. Refer to Basics on
Bus Manipulation Features on page 213.

To change the specified overwrite value at run time, you have to enable model
access or test automation support for the Overwrite Value function port. Refer to
Configuring Function Ports for Bus Configuration Features on page 198.

Specifying saturation values By default, overwrite values are limited by the ranges of the ISignal's physical
for overwrite values base data type and automatically saturated at run time if required. Via the
Overwrite Value function port, you can specify user-defined saturation values
to limit the minimum and maximum overwrite values. If you want to do this,
you have to first set the bus configuration's Saturation usage property to
User min/max value. Refer to Specifying saturation values for function inports
on page 201. However, you can specify user‑defined saturation values only for
ISignals whose physical base data type is not set to Boolean.

If required, the saturation values are automatically saturated when the physical
base data type changes. This can happen in the following cases:
§ You modify in the communication matrix. Refer to Basics on Modifying
Communication Matrices on page 391.
§ You replace the assigned communication matrix. Refer to Replacing Assigned
Communication Matrices on page 435.

230
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Bus Configuration Features Available for ISignals

Related topics References

Function Inport Properties (Bus Configuration) (ConfigurationDesk Function Block

Properties )

Adding Offset Values to ISignal Values

Introduction You can add offset values to the values of ISignals that are assigned to the
Manipulation part of a bus configuration.

Conditions for adding offset To add an offset value to the value of an ISignal, you have to add the ISignal
values to ISignal values Offset Value feature to the ISignal. Refer to Adding bus configuration features
on page 192.

You can add the feature to ISignals with the following base data types:
§ Physical base data type: Int8 … Int32
§ Physical base data type: UInt8 … UInt32

However, you cannot add the ISignal Offset Value feature to array
signals. Moreover, some limitations apply for ISignals that are included in
J1939‑compliant IPDUs. Refer to Limitations for J1939 on page 526.

Effects of adding the ISignal Adding the ISignal Offset Value feature to an ISignal has the following effects:
Offset Value feature § If not already available, a feature switch is added to the ISignal. For the ISignal
Offset Value feature, the feature switch provides the following values:
§ 3: ISignal Offset Value (permanently)
§ 4: ISignal Offset Value (temporarily)
The feature switch lets you select the active bus manipulation feature and
specify whether it manipulates the ISignal permanently or temporarily. For
more information, refer to Basics on Bus Manipulation Features on page 213.

§ An Offset value, Minimum ISignal value, and Maximum ISignal value

property are available that let you specify the offset value and the range of the
ISignal. You can access the properties in following ways:
§ In the Properties Browser when you select the ISignal Offset Value node
in the Bus Configurations table.

231
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with Bus Configuration Features

§ In the Bus Manipulation Features table.

Tip

If a required column is not available, you can add it via the Column
Chooser. Refer to Bus Configuration Tables on page 103.

§ If the ISignal is included in an end-to-end-protected ISignal group and/or

involved in secure onboard communication, a Recalculate end-to-end
protection and/or Recalculate SecOC information checkbox is available.
You can access the checkboxes in the following ways:
§ In the Properties Browser when you select the ISignal Offset Value node
in the Bus Configurations table.
§ In the Recalculate End-to-End Protection - ISignal Offset Value and
Recalculate SecOC Information - ISignal Offset Value columns of the
Bus Manipulation Features table, respectively.
If the related checkbox is selected, the end-to-end protection information of
the affected ISignal group or the authentication information of the affected
secured IPDU is recalculated before transmission. For more information, refer
to Recalculating End-to-End Protection and Authentication Information on
page 217.
§ The following function ports are available:
§ Offset Value function port
§ Minimum ISignal Value function port
§ Maximum ISignal Value function port
The following illustration is an example of the function ports as displayed in
the Bus Configurations table:

Working with offset values To work with offset values, you have to specify the following values:
§ The offset value
§ The minimum value of the ISignal
§ The maximum value of the ISignal

At run time, the specified offset value is added to the value of the ISignal. If
the resulting ISignal value exceeds the specified minimum or maximum value, the
ISignal value overruns, as shown in the following examples:

232
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Bus Configuration Features Available for ISignals

ISignal Minimum Maximum Offset Resulting

Value ISignal Value ISignal Value Value ISignal Value
4 0 6 4 1
4 -6 6 4 -5
4 0 6 -5 6
4 3 6 -5 3

Specifying offset, minimum, You can specify the offset value, minimum ISignal value, and maximum ISignal
and maximum values value via the Offset value, Minimum ISignal value, and Maximum ISignal
value property, respectively. The specified value applies to the Initial value and
Initial substitute value properties of the related function port automatically.

Value range of the properties The value range of the properties (including
the value range of the function port properties) is determined by the physical
base data type of the ISignal.
If the physical base data type is an unsigned integer type, the value range of the
Offset value property is derived from the related integer type. For example, the
physical base data type is UInt8. In this case, the value range of the Offset value
property is Int8min … Int8max. The same applies to the Initial value and Initial
substitute value properties of the Offset Value function port.
If required, the property values are automatically saturated when the physical
base data type changes. This can happen in the following cases:
§ You modify the communication matrix. Refer to Basics on Modifying
Communication Matrices on page 391.
§ You replace the assigned communication matrix. Refer to Replacing Assigned
Communication Matrices on page 435.
However, the maximum valid value of the properties also depends on the ISignal
length. If a specified property value exceeds the maximum valid value, the value
is automatically saturated at run time.

Run-time behavior of the The specified values apply to the ISignal at run time only if the ISignal Offset
specified values Value feature is enabled. The exact behavior depends on whether the feature
is permanently or temporarily enabled. Refer to Basics on Bus Manipulation
Features on page 213.

To change the specified values at run time, you have to enable model access
or test automation support for the related function ports. Refer to Configuring
Function Ports for Bus Configuration Features on page 198.

Specifying saturation values By default, the offset value and the minimum and maximum ISignal values
for the offset, minimum, and are limited by the ranges of the ISignal's physical base data type. At run
maximum values time, the offset, minimum, and maximum values are automatically saturated
if required. Via the Offset Value, Minimum ISignal Value, and Maximum ISignal
Value function ports, you can specify user-defined saturation values to limit the
minimum and maximum values of the function ports. If you want to do this,
you have to first set the bus configuration's Saturation usage property to User

233
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with Bus Configuration Features

min/max value. Refer to Specifying saturation values for function inports on

page 201.

If required, the saturation values are automatically saturated when the physical
base data type changes. This can happen in the following cases:
§ You modify the communication matrix. Refer to Basics on Modifying
Communication Matrices on page 391.
§ You replace the assigned communication matrix. Refer to Replacing Assigned
Communication Matrices on page 435.

Related topics References

Function Inport Properties (Bus Configuration) (ConfigurationDesk Function Block

Properties )

234
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Bus Configuration Features Available for ISignal Groups

Bus Configuration Features Available for ISignal Groups

Observing the Status of Received End‑to‑End‑Protected ISignal Groups

Introduction During run time, you can observe the status of end‑to‑end‑protected RX ISignal
groups that are assigned to the Simulated ECUs or Inspection part of a bus
configuration.

Conditions for observing To observe the status of a received end‑to‑end‑protected ISignal group at run
the status of received time, you have to add the ISignal Group End‑to‑End Protection Status feature
end‑to‑end‑protected ISignal to the ISignal group. Refer to Adding bus configuration features on page 192.
groups
You can add the feature to any RX ISignal group that is end‑to‑end‑protected.
For information on end‑to‑end protection, refer to Aspects of End‑to‑End (E2E)
Protection for ISignal Groups on page 69.

Effects of adding the ISignal When you add the ISignal Group End‑to‑End Protection Status feature to an
Group End‑to‑End Protection ISignal group, the following function ports are available for the ISignal group:
Status feature § Calculated CRC function port
§ State function port

The following illustration is an example of the function ports as displayed in the

Bus Configurations table:

Observing the status of The function ports let you observe the status of a received end‑to‑end‑protected
end‑to‑end‑protected ISignal ISignal group. When you enable model access or test automation support for
groups via function ports a function port, you can use the data that is provided by the function port
in a mapped behavior model or in experiment software, respectively. For more
information, refer to Configuring Function Ports for Bus Configuration Features
on page 198.

The Bus Manager processes received ISignal groups even if the status indicates
an error. If you want to reject an ISignal group in this case, you have to
model the rejection in a behavior model, e.g., by using data that is provided
by the State function port. Refer to Data provided by the State function port on
page 236.

235
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with Bus Configuration Features

Data provided by the The Calculated CRC function port provides the checksum value that is calculated
Calculated CRC function port for the received ISignal group. The value is calculated according to the AUTOSAR
end‑to‑end protection profile that is specified for the ISignal group.

By default, the initial function port value is 0 until the ISignal group is received
for the first time. Via the function port's Initial Value property, you can specify a
user-defined initial value. Refer to Specifying initial values on page 198.

The valid range of the function port depends on the related end‑to‑end
protection profile, as shown in the following table.

End‑to‑End Protection Profile of ISignal Value Range of Calculated CRC

Group Function Port
Profile 01 0 … UInt8max
Profile 02 0 … UInt8max
Profile 05 0 … UInt16max
Profile 11 0 … UInt8max
Profile 22 0 … UInt8max

Data provided by the State The State function port provides the state of the end‑to‑end protection, i.e.,
function port whether the received end‑to‑end protection information indicates an error. For
each end‑to‑end protection profile, the possible states are specified in the
AUTOSAR end‑to‑end communication protection library (E2E library).

The following table provides an overview of the possible function port values and
the resulting states.

Function Port Value Resulting Available For Description

State
0: OK OK § Profile 01 The received end‑to‑end protection information is correct.
§ Profile 02
§ Profile 05
§ Profile 11
§ Profile 22
1: No new data Error § Profile 01 The end‑to‑end protection information has not changed between two
§ Profile 02 consecutive receptions of the ISignal group.
§ Profile 05
§ Profile 11
§ Profile 22
2: Wrong checksum Error § Profile 01 The received checksum value is incorrect.
§ Profile 02 Only for profile 01 with E2E_P01DataIdMode parameter set to
E2E_P01_DATAID_NIBBLE: Alternatively, the low nibble of the high byte
of the Data ID is incorrect.
3: Synchronization in Not valid § Profile 01 The received end‑to‑end protection information is correct, but a previously
progress § Profile 02 received counter value was incorrect. The continuity check of the current
counter value has not finished yet.
4: Initial state Initial § Profile 01 The received checksum value is correct, but the received counter value
§ Profile 02 cannot be verified because it is the first received counter value.
7: Error Error § Profile 01 § Bus Manager‑specific and for all profiles: The ISignal group is not
§ Profile 02 completely received because the payload length of the PDU is too short
§ Profile 05

236
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Bus Configuration Features Available for ISignal Groups

Function Port Value Resulting Available For Description

State
§ Profile 11 to include the complete ISignal group (i.e, ISignals, counter, checksum) in
§ Profile 22 the payload.
§ Only for profile 05, 11, and 22: According to the E2E library, the
received end‑to‑end protection information is incorrect, e.g., because
of an incorrect checksum value. However, the received counter value is
correct.
8: Repeated data Error § Profile 01 An identical counter value was received for two consecutive receptions of
§ Profile 02 the ISignal group.
§ Profile 05
§ Profile 11
§ Profile 22
32: OK, but some OK § Profile 01 The received end‑to‑end protection information is correct but some data
data lost § Profile 02 might be lost. However, the received counter value is in the range of the
§ Profile 05 specified counter tolerance.
§ Profile 11
§ Profile 22
64: Wrong sequence Error § Profile 01 The received end‑to‑end protection information is incorrect because the
§ Profile 02 received counter value exceeds the specified maximum counter tolerance.
§ Profile 05
§ Profile 11
§ Profile 22

The default initial value of the function port depends on the end‑to‑end
protection profile. For the profiles 01 and 02, the initial value is 4: Initial state.
For all other profiles, the initial value is 0: OK. The default initial value applies
until the ISignal group is received for the first time. Via the function port's Initial
Value property, you can change the default initial value. Refer to Specifying
initial values on page 198.

Restrictions for using the You cannot use the ISignal Group End‑to‑End Protection Status and the
ISignal Group End‑to‑End Frame Access feature in parallel. If you add the ISignal Group End‑to‑End
Protection Status feature Protection Status feature to an ISignal group that is included in a PDU for
which the Frame Access feature is added, conflicts occur. This also applies if the
PDU is included in another PDU and the Frame Access feature is added to this
PDU.

Related topics References

Function Outport Properties (Bus Configuration) (ConfigurationDesk Function Block

Properties )

237
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with Bus Configuration Features

Bus Configuration Features Available for PDUs

Where to go from here Information in this section

Enabling and Disabling the Transmission of PDUs................................... 238

Accessing the Payload of PDUs in Raw Data Format............................... 240

Controlling the Cyclic Timing of CAN PDUs........................................... 243

Specifying User-Defined Triggers for Transmitting PDUs.......................... 246

Accessing the Payload Length of CAN PDUs.......................................... 249

Observing the Status of Received PDUs.................................................. 251

Applying User Code to PDUs................................................................. 254

Accessing the Priority of J1939-Compliant IPDUs................................... 263

Accessing the Selector Field Value of Multiplexed IPDUs......................... 266

Verifying the Authentication Information of Received Secured

IPDUs.................................................................................................... 268

Invalidating the Authenticator of Secured IPDUs.................................... 271

Overwriting the Freshness Value of Secured IPDUs................................. 274

Suspending the Transmission of PDUs.................................................... 278

Triggering the Execution of Functions in a Behavior Model via RX

Interrupts.............................................................................................. 281

Enabling and Disabling the Transmission of PDUs

Introduction You can enable and disable the transmission of basic PDUs and multiplexed
IPDUs that are assigned to the Simulated ECUs part of a bus configuration.

Conditions for enabling and To enable or disable the transmission of a PDU, you have to add the PDU Enable
disabling the transmission of feature to a selected TX PDU. Refer to Adding bus configuration features on
PDUs page 192.

In general, you can add the feature to the following PDU types:
§ TX basic PDUs
However, you can add the feature to a TX general-purpose PDU only if the
PDU does not contain a global time domain in the bus configuration.
§ TX multiplexed IPDUs

238
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Bus Configuration Features Available for PDUs

Effects of adding the PDU When you add the PDU Enable feature to a TX PDU, an Enable function
Enable feature port is available for the PDU that lets you specify the enable state. The
following illustration is an example of the function port as displayed in the Bus
Configurations table:

Specifying the enable state The Enable function port lets you specify the enable state of the PDU as follows:
§ False (0): The transmission of the PDU is disabled.
§ True (1): The transmission of the PDU is enabled. This is the default state.

Via the Initial value property of the function port, you can change the default
enable state. To change the state at run time, you have to enable model access
or test automation support for the function port. Refer to Configuring Function
Ports for Bus Configuration Features on page 198.

Effects of disabling the When you disable the transmission of a PDU, you disable it for a specific
transmission of PDUs transmitting ECU. This lets you test, for example, if another ECU in the
communication cluster transmits the PDU instead.

Disabling the transmission of a PDU has the following effects on the active bus
communication:
§ If you disable the transmission of a PDU while the PDU is being transmitted,
the transmission is not interrupted. The transmission of the PDU is disabled
after the PDU is completely transmitted.
§ If the transmission of a PDU is triggered while the transmission of the PDU
is disabled, the trigger is discarded and lost, i.e., the trigger is not processed
when the transmission of the PDU is enabled again.

Effects of re-enabling the Re-enabling the transmission of a PDU at run time (i.e., switching the state from
transmission of PDUs False to True) has the following effects on the active bus communication:

Element Available For Effects

End-to-end protection End-to-end-protected The counters of end-to-end-protected ISignal groups keep the last counter
counters ISignal groups (according to value and continue counting on the basis of this value.
the corresponding end-to-
end protection profile)
Counter signals ISignals with enabled Counter signals keep the last counter value and continue counting on the
Counter Signal feature basis of this value.
Cyclic timing PDU The time period, time offset, and minimum delay time of the cyclic timing
of the PDU keep their last values, i.e., elapsed time spans are considered for
the next cyclic transmission of the PDU.
Event‑controlled PDU The number of repetitions, repetition period, and minimum delay time
timing of the event‑controlled timing of the PDU keep their last values, i.e.,
elapsed numbers of repetitions and time spans are considered for the next
event‑controlled transmission of the PDU.

239
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with Bus Configuration Features

Restrictions for using the PDU If you use the PDU Enable feature, the following restrictions apply:
Enable feature § You can enable and disable the transmission of a PDU only for the entire
transmitting ECU and not selectively for specific frames, channels, or clusters.
For example, if you disable a PDU that is included in two frames, none of the
frames transmits the PDU.
§ You cannot use the PDU Enable and the Frame Access feature in parallel. If
you add both features to a PDU, conflicts occur. This also applies if the PDU is
included in another PDU and the Frame Access feature is added to this PDU.

Related topics References

Function Inport Properties (Bus Configuration) (ConfigurationDesk Function Block

Properties )

Accessing the Payload of PDUs in Raw Data Format

Introduction You can access the payload of PDUs that are assigned to the Simulated ECUs or
Inspection part of a bus configuration in raw data format.

Conditions for accessing the To access the payload of a PDU in raw data format, you have to add the
payload of PDUs in raw data PDU Raw Data feature to the selected PDU. Refer to Adding bus configuration
format features on page 192.

In general, you can add the feature to any RX and TX PDU whose payload
length is > 0 bytes. However, you can add the feature to a TX general-purpose
PDU only if the PDU does not contain a global time domain in the bus
configuration.

Effects of adding the PDU Adding the PDU Raw Data feature to a PDU has the following effects:
Raw Data feature § A Raw Data function port is available for the PDU.

240
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Bus Configuration Features Available for PDUs

§ If you add the PDU Raw Data feature to a TX basic PDU , an Access mode
property is available that lets you specify to read or write the payload in raw
data format. You can access the property in two ways:
§ In the Properties Browser when you select the PDU Raw Data node in the
Bus Configurations table.

§ In the Bus Simulation Features table.

Tip

If the column is not available, you can add it via the Column Chooser.
Refer to Bus Configuration Tables on page 103.

Accessing the payload via the The Raw Data function port lets you access the payload of a PDU in raw data
Raw Data function port format.

Read or write raw data By default, the function port provides read access to
the payload raw data. This applies regardless of whether the PDU is an RX or TX
PDU. You can change the access mode of the function port to write raw data to
the payload only if you add the PDU Raw Data feature to a TX basic PDU. Refer
to Writing raw data to the payload of a TX basic PDU on page 242.

Reading raw data Reading the payload raw data lets you observe the
payload data that is actually available on the bus, i.e.:
§ RX PDU: The raw data that is received on the bus.
§ TX PDU: The raw data that is transmitted on the bus.
If you only read the payload raw data, you can access signal-based payload data
in parallel, e.g., you can add the ISignal Value and Counter Signal features
to ISignals of the PDU to transmit or receive the values of ISignals and counter
signals.

Accessing the payload raw data at run time To access the payload raw
data at run time, you have to enable model access or test automation support
for the Raw Data function port. Refer to Configuring Function Ports for Bus
Configuration Features on page 198.

241
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with Bus Configuration Features

Writing raw data to the If you add the PDU Raw Data feature to a TX basic PDU, you can write raw data
payload of a TX basic PDU to the payload of the PDU. For this purpose, you can change the access mode of
the Raw Data function port via the Access mode property as follows:
§ Read: The payload of the TX basic PDU is read in raw data format. This is the
default mode.
§ Write: Raw data is written to the payload of the TX basic PDU.

Setting the Access mode property to Write has the following effects:
§ The port type of the Raw Data function port changes: The function
outport is converted to a function inport .

Note

If the function port is mapped to a model port, the mapping is lost.

§ The payload of the TX basic PDU can be transmitted in raw data format only,
i.e., you cannot transmit signal-based payload data, such as ISignal values, in
parallel.

Value range and initial values The value of the Raw Data function port is a vector. The vector size is the length
of the Raw Data function port of the related PDU, e.g., for a PDU with a length of 2 bytes the vector size is
2. The vector size is automatically adjusted when the PDU length changes in the
communication matrix. This can happen in the following cases:
§ You modify the communication matrix. Refer to Basics on Modifying
Communication Matrices on page 391.
§ You replace the assigned communication matrix. Refer to Replacing Assigned
Communication Matrices on page 435.

The value range of each vector element is 0 … 255, the default value is 0. Via
the function port's Initial value and Initial substitute value properties, you
can specify a user-defined initial raw data. Refer to Specifying initial values on
page 198.

Restrictions for using the PDU If you use the PDU Raw Data feature, the following restrictions apply:
Raw Data feature § You can access only the complete payload of a PDU in raw data format. You
cannot specify specific bytes of the payload to be accessed in raw data format.
§ You cannot use the PDU Raw Data feature in parallel with the following bus
configuration features:
§ Frame Access feature
§ For TX basic PDUs whose Access mode property is set to Write:
§ Counter Signal feature
§ ISignal Value feature
If you add the PDU Raw Data feature and at least one of the other features
to a PDU, its included ISignals, and/or to a PDU the PDU is included in,
conflicts occur.

242
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Bus Configuration Features Available for PDUs

Related topics References

Function Inport Properties (Bus Configuration) (ConfigurationDesk Function Block

Properties )
Function Outport Properties (Bus Configuration) (ConfigurationDesk Function Block
Properties )

Controlling the Cyclic Timing of CAN PDUs

Introduction You can control the cyclic timing of CAN TX PDUs that are assigned to the
Simulated ECUs part of a bus configuration.

Conditions for controlling the To control the cyclic timing of a CAN TX PDU, you have to add the PDU Cyclic
cyclic timing of CAN PDUs Timing Control feature to the PDU. Refer to Adding bus configuration features
on page 192.

In general, you can add the feature to any CAN TX basic PDU . However, you
can add the feature to a TX general-purpose PDU only if the PDU does not
contain a global time domain in the bus configuration.

The PDU Cyclic Timing Control feature is independent of cyclic timings

specified in the communication matrix , i.e., you can add the feature to a CAN
TX PDU regardless of whether the communication matrix specifies a cyclic timing
for the PDU.

Effects of adding the PDU When you add the PDU Cyclic Timing Control feature to a PDU, two function
Cyclic Timing Control feature ports are available for the PDU:
§ Timing Control Period function port
This function port lets you specify a period (i.e., a cycle time) in seconds for the
PDU.
§ Timing Control Offset function port
This function port lets you specify an offset (i.e., a delay time) in seconds for
the PDU.

The following illustration is an example of the function ports as displayed in the

Bus Configurations table:

243
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with Bus Configuration Features

Controlling the cyclic timing When you add the PDU Cyclic Timing Control feature to a PDU, the default
of CAN PDUs via function period and offset are derived from the communication matrix. These values are
ports used as the initial values of the related function ports. If the communication
matrix does not specify a period and/or offset, 0 is used as the initial value of
the related function port. Via the Initial value property of the Timing Control
Period function port and Timing Control Offset function port, you can specify a
user-defined initial period and offset, respectively.

Note

If the period is 0, the PDU is not transmitted.

To change the period and offset at run time, you have to enable model access
or test automation support for the related function port. Refer to Configuring
Function Ports for Bus Configuration Features on page 198.

The actual timing for transmitting a PDU cyclically depends on the task to which
the related BusCfg_MainFunctionDeliver [<bus configuration name>]
runnable function is assigned. Refer to Fetch and Deliver Runnable Functions
for Receiving and Transmitting PDUs on page 366. Moreover, specifications of
the communication matrix might influence the timing, e.g., if a minimum delay
time is specified for the PDU or the PDU is a contained IPDU and for the related
container IPDU a container timeout value is specified.

Notes on working with an Specifying an offset via the Timing Control Offset function port lets you delay
offset for a PDU each first transmission of the related PDU after the following events:
§ The executable application is started or restarted.
§ The related communication controller is enabled (e.g., via the
Communication Controller Enable feature).
§ You change the specified offset at run time.

Modifying the specified Modifying the period at run time When you reduce or extend the period
period and offset at run time at run time, the active period is reduced or extended according to the changed
period. The following illustration is an example of extending the period at run
time:
Old period: 20 ms
New period: 30 ms Originally scheduled trigger
Trigger

Old period Old period Old period Current period New period
0 10 20 30 40 50 60 70 80 90 100 110 120 t (ms)
PDU
trigger New period specified at
start current application time

If you reduce the period at run time so much that the PDU would have had
to be triggered in the past, the PDU is triggered immediately, as shown in the
following example:

244
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Bus Configuration Features Available for PDUs

Old period: 20 ms
New period: 30 ms Immediate trigger Originally scheduled trigger
Trigger

Old period Old period Old period

0 10 20 30 40 50 60 70 80 90 100 110 120 t (ms)
PDU
trigger
start Current period New period

New period
specified at current
application time

Modifying the offset at run time Extending or reducing the offset at run
time directly affects the active period as well. The following illustrations are
examples for the effects of a changed offset on the active period and the related
PDU trigger:

§ Extended offset
The active period is extended by the time difference between the old and the
new offset:
Period: 30 ms
Old offset: 15 ms
New offset: 25 ms Originally scheduled trigger

Delayed Delayed
trigger trigger
Old offset Period Period Current period +10ms Period
0 10 20 30 40 50 60 70 80 90 100 110 120 130 140 150 t (ms)

PDU
trigger
start
New offset specified at
current application time

§ Reduced offset
The active period is reduced by the time difference between the old and the
new offset:
Period: 30 ms
Old offset: 15 ms
New offset: 5 ms Originally scheduled trigger
Negative
delayed
Delayed trigger
trigger -10ms
Old offset Period Period Current period Period Period
0 10 20 30 40 50 60 70 80 90 100 110 120 130 140 150 t (ms)
PDU
trigger
start
New offset specified at
current application time

245
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with Bus Configuration Features

If the PDU would have had to be triggered in the past due to the reduced
offset, the PDU is triggered immediately:
Period: 30 ms
Old offset: 15 ms
New offset: 5 ms Originally scheduled trigger

Immediate
Delayed trigger
trigger -10ms
Old offset Period Period Current period Period Period
0 10 20 30 40 50 60 70 80 90 100 110 120 130 140 150 160 t (ms)
PDU
trigger
start
New offset specified at
current application time

Restrictions for using the PDU You cannot use the PDU Cyclic Timing Control and the Frame Access feature
Cyclic Timing Control feature in parallel. If you add both features to a PDU, conflicts occur. This also applies if
the PDU is included in another PDU and the Frame Access feature is added to
this PDU.

Related topics References

Function Inport Properties (Bus Configuration) (ConfigurationDesk Function Block

Properties )

Specifying User-Defined Triggers for Transmitting PDUs

Introduction You can specify user-defined triggers to trigger the transmission of basic
PDUs that are assigned to the Simulated ECUs part of a bus configuration.
For example, user-defined triggers let you trigger the transmission of PDUs
continuously or asynchronously to a cyclic timing.

Conditions for specifying To specify user-defined triggers for transmitting a PDU at run time, you have to
user-defined triggers for add the PDU Trigger feature to the PDU. Refer to Adding bus configuration
transmitting PDUs features on page 192.

In general, you can add the PDU Trigger feature to the following basic PDUs :
§ CAN TX PDUs
§ LIN TX PDUs that are included in event-triggered or sporadic frames

However, you can add the feature to a TX general-purpose PDU only if the PDU
does not contain a global time domain in the bus configuration.

The PDU Trigger feature is independent of event‑controlled timings specified

in the communication matrix , i.e., you can add the feature to a TX PDU

246
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Bus Configuration Features Available for PDUs

regardless of whether the communication matrix specifies an event‑controlled

timing for the PDU.

Effects of adding the PDU Adding the PDU Trigger feature to a PDU has the following effects:
Trigger feature § A Trigger mode property is available for the PDU that lets you specify the
triggering mode for the PDU. You can access the property in two ways:
§ In the Properties Browser when you select the PDU Trigger node in the
Bus Configurations table.

§ In the Bus Simulation Features table.

Tip

If the column is not available, you can add it via the Column Chooser.
Refer to Bus Configuration Tables on page 103.

You cannot change the triggering mode during run time. Therefore, no
function port is available for the triggering mode.
§ A Trigger function port is available for the PDU. Via the function port, you can
trigger the transmission of the PDU at run time. The following illustration is an
example of the function port as displayed in the Bus Configurations table:

Specifying user-defined Specifying user-defined triggers for the transmission of a PDU comprises the
triggers following basic steps:
1. Add the PDU Trigger feature to the PDU.
2. Select a triggering mode via the Trigger mode property.
3. Configure the Trigger function port.

For more information, refer to Triggering the Transmission of PDUs and Frames
via User-Defined Triggers on page 210.

Effects of triggering the When you trigger the transmission of a PDU at run time, the PDU is transmitted
transmission of PDUs via the via all involved frames and communication clusters.
PDU Trigger feature

247
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with Bus Configuration Features

To identify the involved frames and communication clusters, you can select the
PDU in the Bus Configurations table or Bus Simulation Features table. If you
do this, the Bus Communication page of the Properties Browser displays all
the involved frames and clusters, as shown in the following example.

Tip

If you do not want to trigger the transmission of the PDU via a

specific frame, you can do the following: Remove the PDU from the bus
configuration. Then, drag the PDU from the Communication Matrices by
Clusters view of the Buses Browser to assign it to the bus configuration
in the context of a specific communication cluster. Refer to Assigning
Communication Matrix Elements to Bus Configurations on page 112.

The actual timing for transmitting the PDU depends on the task to which
the related BusCfg_MainFunctionDeliver [<bus configuration name>]
runnable function is assigned. Refer to Fetch and Deliver Runnable Functions
for Receiving and Transmitting PDUs on page 366. Moreover, specifications of
the communication matrix might influence the timing, e.g., if a minimum delay
time is specified for the PDU or the PDU is a contained IPDU and for the related
container IPDU a container timeout value is specified.

Restrictions for using the PDU You cannot use the PDU Trigger and the Frame Access feature in parallel. If
Trigger feature you add both features to a PDU, conflicts occur. This also applies if the PDU is
included in another PDU and the Frame Access feature is added to this PDU.

Related topics Basics

Limitations for Bus Configuration Handling............................................................................. 531

Limitations for LIN Communication......................................................................................... 528

References

Function Inport Properties (Bus Configuration) (ConfigurationDesk Function Block

Properties )

248
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Bus Configuration Features Available for PDUs

Accessing the Payload Length of CAN PDUs

Introduction You can access the payload length of CAN PDUs that are assigned to the
Simulated ECUs or Inspection part of a bus configuration at run time, e.g.,
to simulate or inspect dynamic length CAN PDUs.

Conditions for accessing the To access the payload length of a CAN PDU at run time, you have to add the
payload length of CAN PDUs PDU Length feature to the PDU. Refer to Adding bus configuration features on
page 192.

You can add the PDU Length feature to the following PDU types:
§ RX container IPDUs
§ TX and RX basic PDUs that fulfill all of the following conditions:
§ The basic PDUs are included only in CAN frames .
§ The basic PDUs are not configured in any of the following ways:
§ Contained IPDU that is included in a container IPDU with a static
container layout
§ Authentic PDU of a non‑cryptographic secured IPDU
§ Static‑part or dynamic‑part IPDU of a multiplexed IPDU
§ TX general-purpose PDU that contains a global time domain in the bus
configuration

Effects of adding the PDU Depending on the direction of the PDU (TX or RX ), a TX Length function
Length feature port or RX Length function port is available that lets you access the payload
length at run time. The following illustration is an example of the function port
as displayed in the Bus Configurations table:

Accessing the payload length The Length function port provides the payload length in bytes as follows:

TX Length Function Port RX Length Function Port

For TX PDUs, the TX Length function port specifies For RX PDUs, the RX Length function port provides the received payload
the payload length with which the PDU is transmitted length, e.g., to a mapped behavior model:
on the bus. § For basic PDUs that are directly included in a frame, the function port
For basic PDUs that are directly included in a frame, provides the length of the related frame.
the specified length also applies to the related § For contained IPDUs and J1939‑compliant IPDUs, the function port
frame, i.e., the frame length that is specified in provides the length of the PDU.
the communication matrix is ignored. However,
§ For container IPDUs with a dynamic container layout, the function port
this does not apply to contained IPDUs and
provides the lengths of the contained IPDUs including the lengths of the
J1939‑compliant IPDUs.
related header type.

249
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with Bus Configuration Features

TX Length Function Port RX Length Function Port

§ For container IPDUs with a static container layout, the function port
provides the length of the related frame.

By default, the initial function port value is the PDU length that is specified in
the communication matrix. Via the function port's Initial value property, you
can specify a user-defined initial payload length in the range 0 …. <PDU length
specified in the communication matrix>.

The maximum valid function port value changes if the PDU length changes in the
communication matrix. This can happen in the following cases:
§ You modify the communication matrix. Refer to Basics on Modifying
Communication Matrices on page 391.
§ You replace the assigned communication matrix. Refer to Replacing Assigned
Communication Matrices on page 435.

If required, you must adjust the initial payload length manually.

To access the payload length at run time, you have to enable model access or
test automation support for the function port. Refer to Configuring Function
Ports for Bus Configuration Features on page 198.

Run-time effects of changed Changed payload lengths have the following effects at run time:
payload lengths

Effect Description
Saturation of TX If the payload length of a TX PDU changes at run time and the new length exceeds the maximum valid TX
Length function Length function port value, the length is automatically saturated.
port
Valid CAN FD If a TX basic PDU that is directly included in a frame is transmitted and the specified payload length is invalid
lengths according to CAN FD, the length of the related frame is automatically extended with padding bytes to the next
valid CAN FD length. Refer to CAN FD protocol on page 77.

Tip

If the PDU Length feature is also added to an RX instance of such a basic PDU, the RX Length function
port provides the frame length including the padding bytes.

New TX If the payload length of a TX contained IPDU with last‑is‑best collection semantics is extended at run time,
container IPDUs the following applies: If the length exceeds the boundaries of the related container IPDU, the contained IPDU
is not included in the container IPDU. Instead, this contained IPDU and all the following contained IPDUs are
included in a new container IPDU. In this case, the first container IPDU is transmitted immediately. If applicable,
a remaining timeout value of the first container IPDU applies to the new container IPDU.
Only complete Depending on the direction of the PDU (i.e., TX or RX), a reduced payload length has the following effects on
ISignals included ISignals:
or decoded § TX PDU: The Bus Manager includes only ISignals in the PDU that completely fit into the specified payload
length. ISignals that do not completely fit into the specified payload length are not transmitted. This results
in unused bits.
§ RX PDU: The Bus Manager decodes ISignals only if they are received completely. If an ISignal is only partially
received because of a reduced payload length, the ISignal is not decoded at all. As a result, the raw data of
the affected payload bits might change but the value of the ISignal remains unchanged (e.g., if you access
the value via the ISignal Value feature).

250
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Bus Configuration Features Available for PDUs

Effect Description
Unused bits filled Unused bits of the payload are filled with the value of the unused bit pattern that is specified for the PDU. For
with the unused example, bits might be unused in the following cases:
bit pattern § ISignals are not included in a TX PDU because they do not completely fit into the payload.
§ The payload length of a TX PDU is extended via the TX Length function port.

Specifying saturation values For TX Length function ports, you can specify saturation values to limit the
for TX Length function ports minimum and maximum payload length of TX PDUs. If you want to do this,
you have to first set the bus configuration's Saturation usage property to User
min/max value. Refer to Specifying saturation values for function inports on
page 201.

The valid saturation values of the TX Length function port might change if
the PDU length changes in the communication matrix. This can happen in the
following cases:
§ You modify the communication matrix. Refer to Basics on Modifying
Communication Matrices on page 391.
§ You replace the assigned communication matrix. Refer to Replacing Assigned
Communication Matrices on page 435.

If required, you must adjust the specified saturation values manually.

Related topics References

Function Inport Properties (Bus Configuration) (ConfigurationDesk Function Block

Properties )

Observing the Status of Received PDUs

Introduction During run time, you can observe the status of RX PDUs that are assigned to the
Simulated ECUs or Inspection part of a bus configuration.

Conditions for observing the To observe the status of a received PDU at run time, you have to add the PDU
status of received PDUs RX Status feature to the PDU. Refer to Adding bus configuration features on
page 192.

You can add the feature to any RX PDU.

Effects of adding the PDU RX When you add the PDU RX Status feature to a PDU, the following function
Status feature ports are available for the PDU:
§ Counter function port
§ State function port

251
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with Bus Configuration Features

§ Loopback function port

§ Time function port
§ Delta Time function port

The following illustration is an example of the function ports as displayed in the

Bus Configurations table:

Observing the status of The function ports let you observe the status of a received PDU. When you
received PDUs via function enable model access or test automation support for a function port, you can use
ports the data that is provided by the function port in a mapped behavior model or
in experiment software, respectively. For more information on enabling model
access and test automation support, refer to Configuring Function Ports for Bus
Configuration Features on page 198.

Data provided by the Counter function port This function port provides
the value of the counter that is implemented for the PDU when you add the
PDU RX Status feature. Refer to Counter values available for the PDU on
page 253.

Data provided by the State function port This function port provides the
state of the PDU, i.e., whether the PDU is received in the current sampling step:
§ False (0): The PDU is not received in the current sampling step. This is the
default state.
§ True (1): The PDU is received in the current sampling step.
Via the function port's Initial value property, you can change the default state
of the PDU.

Data provided by the Loopback function port This function port indicates
whether the PDU is received as a loopback PDU, i.e., the PDU is transmitted and
received by the same bus access (CAN or LIN function block):
§ False (0): The PDU is not received as a loopback PDU, i.e., it is received from
another bus access or a real ECU, for example. This is the default state.
§ True (1): The PDU is received as a loopback PDU.
Via the function port's Initial value property, you can change the default state
of the PDU. The function port value is reset to the initial value each time the
executable application starts, regardless of the setting of the Initial value
usage property.

Data provided by the Time function port This function port provides the
time (in seconds) of the executable application when the PDU was received.
By default, the initial function port value is 0 until the PDU is received for
the first time. Via the function port's Initial value property, you can specify a
user-defined initial value. The function port value is reset to the initial value each

252
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Bus Configuration Features Available for PDUs

time the executable application starts, regardless of the setting of the Initial
value usage property.

Data provided by the Delta Time function port This function port provides
the time difference (in seconds) between the current and the previous reception
of the PDU. By default, the initial function port value is 0 until the PDU is
received for the first time. Via the function port's Initial value property, you can
specify a user-defined initial value. The function port value is reset to the initial
value each time the executable application starts, regardless of the setting of the
Initial value usage property.
Because there is no actual time difference when the PDU is received for the
first time, the function port provides the time of the executable application in
this case. With the second reception of the PDU, the function port provides the
actual time difference.

For more information on initial function port values, refer to Specifying initial
values on page 198.

Counter values available for Basics on the counter When you add the PDU RX Status feature to a PDU,
the PDU a counter is implemented for this PDU. The counter's data type is UInt32 and the
counter's initial value is 0. The counter value is incremented by 1 each time the
PDU is received on the bus. If an overflow occurs, the counter value is reset to 0.

Values provided by the Counter function port You can access the counter
value via the Counter function port. For the Counter function port, you can
specify an initial value via the function port's Initial value property.

Note

Do not confuse the counter's initial value with the function port's initial
value.

The counter's initial value is always 0, regardless of the value specified

for the function port's Initial value property. The value of the Initial
value property applies only to the function port. It is used until the
related BusCfg_MainFunctionFetch [<bus configuration name>] runnable
function is executed for the first time. Then, the function port provides the
counter value (i.e., the counter's initial value or the number of received PDUs).
For more information on the runnable function, refer to Fetch and Deliver
Runnable Functions for Receiving and Transmitting PDUs on page 366.

Counter behavior when restarting an executable application When you

stop and restart the executable application, the counter behavior depends on the
setting specified for the Initial value usage property of the bus configuration.
The specified setting also influences the value provided by the Counter function
port, as shown in the following table:

Initial Value Usage Effect

Property Set to ...
At first application start The counter continues counting even if the application is stopped and restarted, i.e., the counter
value is not reset. The value provided by the Counter function port is not reset either. Therefore, the
function port provides the last received counter value when you restart the application.

253
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with Bus Configuration Features

Initial Value Usage Effect

Property Set to ...
At every application The counter stops counting and is reset to 0 when you restart the application. The value of the
start Counter function port is reset to the value specified for the function port's Initial value property.

Restrictions for using the PDU You cannot use the PDU RX Status and the Frame Access feature in parallel. If
RX Status feature you add both features to a PDU, conflicts occur. This also applies if the PDU is
included in another PDU and the Frame Access feature is added to this PDU.

Related topics References

Common Function Block Properties (Bus Configuration) (ConfigurationDesk

Function Block Properties )
Function Outport Properties (Bus Configuration) (ConfigurationDesk Function Block
Properties )

Applying User Code to PDUs

Introduction You can apply user code to PDUs that are assigned to the Simulated ECUs,
Inspection, or Manipulation part of a bus configuration. For example, you can
do this to write checksum values that are calculated according to user-specific
algorithms to ISignals of the related PDUs.

For basic information on user code, refer to Working with User Code on
page 139.

Conditions for applying user To apply user code to a PDU, you have to add the PDU User Code feature to the
code to PDUs selected PDU. Refer to Adding bus configuration features on page 192.

In general, you can add the feature to the following PDU types:
§ Basic PDUs
§ Secured IPDUs
§ Multiplexed IPDUs

However, you can add the feature to a TX general-purpose PDU only if the PDU
does not contain a global time domain in the bus configuration. Moreover,
some limitations apply for J1939‑compliant IPDUs that are assigned to the
Manipulation part of a bus configuration. Refer to Limitations for J1939 on
page 526.

254
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Bus Configuration Features Available for PDUs

Effects of adding the PDU Adding the PDU User Code feature to a PDU has the following effects:
User Code feature § A User code ID property is available that lets you reference the user code ID of
the required user code implementation . You can access the property in the
following ways:
§ In the Properties Browser when you select the PDU User Code node in
the Bus Configurations table.

§ In the related bus configuration features table, i.e., Bus Simulation

Features, Bus Inspection Features, or Bus Manipulation Features table,
as shown in the following example.

Tip

If the column is not available, you can add it via the Column Chooser.
Refer to Bus Configuration Tables on page 103.

§ Except for multiplexed IPDUs, a Number of user signals property and,

depending on the specified number of user signals, User signal [<number>]
properties are available that let you specify the user signals. You can access the
properties in the following ways:
§ In the Properties Browser when you select the PDU User Code node in
the Bus Configurations table.
§ In the related bus configuration features table, i.e., Bus Simulation
Features, Bus Inspection Features, or Bus Manipulation Features table,
and in the Bus Configurations table.
§ A Number of user ports property and, depending on the specified number of
user ports, Direction of user port [<number>] properties are available that
let you specify the direction of the user ports. You can access the properties in
the following ways:
§ In the Properties Browser when you select the PDU User Code node in
the Bus Configurations table.
§ In the related bus configuration features table, i.e., Bus Simulation
Features, Bus Inspection Features, or Bus Manipulation Features table,
and in the Bus Configurations table.
§ If you add the PDU User Code feature to an RX PDU, a Result function port
is available. The function port can provide data of the user code, for example,
the verification result of a received checksum value that was evaluated by the

255
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with Bus Configuration Features

user code. The following illustration is an example of the function port as

displayed in the Bus Configurations table:

§ If you add the PDU User Code feature to a PDU that is assigned to the
Manipulation part, additional manipulation-specific properties and function
ports are available. Refer to Manipulation-specific properties and function
ports on page 260.

Workflow for applying user Applying user code to a PDU consists of the following workflow steps:
code to a PDU 1. Specify the user code, i.e, the required user-specific algorithms, according to
your requirements in C code (*.c, *.h) or C++ code (*.cpp, *.hpp).
2. Extend the user code by functions for initializing the functionalities of the
user code and for exchanging data with the Bus Manager, such as accessing
properties of PDUs or writing checksum values to ISignals of PDUs. Use
functions of the DsBusCustomCode and DsBusCustomCode_PduUserCode
modules of the Bus Custom Code interface for this purpose.
§ For general information on the Bus Custom Code interface and the
available functions, refer to Bus Custom Code Interface Handling .
§ For information on the Bus Custom Code interface functions that are
required for exchanging data with the PDU User Code feature, refer to
the following descriptions.
3. Add the code files, i.e., the user code implementation, to the
ConfigurationDesk application. Refer to Implementing user code in
ConfigurationDesk applications on page 140.
4. Add the PDU User Code feature to a PDU. Refer to Adding bus
configuration features on page 192.
5. Reference the user code implementation in the PDU User Code feature.
To do so, type the user code ID as specified in the user code
implementation into the edit field of the feature's User code ID property.
In the user code implementation, the user code ID is specified via the
DS_BUS_CUSTOM_FEATURE_NAME definition in the related source file (*.c,
*.cpp).

Tip

The user code applies only to the referencing PDU User Code feature.
However, you can reference the same user code in multiple PDU User
Code features or use different user code implementations for different
PDU User Code features.

Depending on the PDU to which you add the PDU User Code feature, you can
additionally specify the following settings:
§ If you add the feature to a PDU that contains ISignals, you can specify user
signals. Refer to Specifying user signals on page 257.
§ If you add the feature to an RX PDU, you can specify an initial value for the
Result function port. Refer to Data provided by the Result function port on
page 260.

256
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Bus Configuration Features Available for PDUs

Moreover, you can specify user-defined function ports for each PDU that let you
exchange data with the user code. Refer to Specifying user ports on page 257.

Furthermore, additional configurations are required if you want to access the

run‑time frame triggering of TX CAN PDUs that are assigned to the Simulated
ECUs part. Refer to Accessing the run‑time frame triggering of simulated TX
CAN PDUs on page 258.

Specifying user signals If you add the PDU User Code feature to a PDU that contains ISignals, you can
specify user signals. User signals allow the user code to directly access ISignals of
the PDU. You can specify user signals via the following properties:

Property Value Range Description

Number of user 0 … 20 Lets you specify the maximum number of user signals, i.e., the maximum number of
signals signals that can be accessed by the user code. The specified number determines the
available number of User signal [<number>] properties.
User signal [0] … <available ISignals Lets you map an ISignal that is specified for the PDU in the communication matrix to
User signal according to the user signal, regardless of whether the ISignal is assigned to the bus configuration. At
[<max. number communication run time, the user code can directly access the mapped ISignal, e.g., to use the ISignal
of user signals>] matrix> value for calculating checksum values or to overwrite the original ISignal value with a
calculated value.
If a user signal is not mapped to an ISignal, the user signal is not configured, i.e., the
user code cannot access this user signal at run time.

In the user code, use the following functions of the Bus Custom Code interface
to access the specified user signals:

Action Required Function of the Bus Custom Code Interface

Access the specified number of user DsBusCustomCodeUserCodePduFeature_getNumberOfUserSignals (Bus Custom Code
signals. Interface Handling )
Access the user signal array. The user DsBusCustomCodeUserCodePduFeature_getUserSignals (Bus Custom Code Interface
signal array provides the data of the Handling )
configured user signals.

For an example of using the functions in the user code, refer to Example
of Implementing User-Specific PDU Functionalities via the Bus Custom Code
Interface (Bus Custom Code Interface Handling ).

Specifying user ports You can specify user-defined function ports for each PDU to which you add the
PDU User Code feature. You can use these user ports to provide data to the
user code, such as data that is received from a behavior model, or write user
code data to the user ports.

You can specify user-defined function ports via the following properties:

Property Value Description

Range
Number of user ports 0 … 20 Lets you specify the number of user ports. The specified number determines the available
number of Direction of user port [<number>] properties.

257
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with Bus Configuration Features

Property Value Description

Range
Direction of user port § In Lets you specify the direction of each user port. The default direction depends on the direction
[0] … Direction § Out of the related PDU:
of user port [<max. § TX PDU: The default user port direction is In.
number of user § RX PDU: The default user port direction is Out.
ports>] The specified direction also determines the name of the user ports:
§ User inport: <PDU name> User Inport [<number>]
§ User outport: <PDU name> User Outport [<number>]
If you change the direction of a user port while the port is mapped to a model port, the
mapping becomes invalid. In this case, you have to delete the mapping line in the signal chain.

By default, the initial value of each user‑defined function port is 0. Via each
function port's Initial value property, you can specify a user-defined initial value
in the range Doublemin … Doublemax. To access the value of a user‑defined
function port at run time, you have to enable model access or test automation
support for the related function port. Refer to Configuring Function Ports for Bus
Configuration Features on page 198.

In the user code, use the following functions of the Bus Custom Code interface
to access the specified user ports:

Action Required Function of the Bus Custom Code Interface

Access the specified number of DsBusCustomCodeUserCodePduFeature_getNumberOfUserPorts (Bus Custom Code Interface
user ports. Handling )
Access the user port array. The DsBusCustomCodeUserCodePduFeature_getUserPorts (Bus Custom Code Interface
user port array provides access to Handling )
the specified user ports.
Access the direction of the user DsBusCustomCodeUserPort_getDirection (Bus Custom Code Interface Handling )
ports.
Provide data of the user code to § DsBusCustomCodeUserPort_setPortData (Bus Custom Code Interface Handling )
the user ports or vice versa. § DsBusCustomCodeUserPort_getPortData (Bus Custom Code Interface Handling )

For an example of using the functions in the user code, refer to Example
of Implementing User-Specific PDU Functionalities via the Bus Custom Code
Interface (Bus Custom Code Interface Handling ).

Accessing the run‑time frame In general, the Bus Custom Code interface provides two functions that let you
triggering of simulated TX access the frame triggering of CAN PDUs:
CAN PDUs § DsBusCustomCodePdu_getCanFrameTriggering: Accesses the frame
triggering that is specified for a PDU in the communication matrix.
§ DsBusCustomCodeUserCodePduFeature_
getRuntimeCanFrameTriggering: Accesses the run‑time frame triggering of
a PDU, i.e., the frame triggering that is actually available on the bus.

258
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Bus Configuration Features Available for PDUs

However, if you want to access the run‑time frame triggering of a TX PDU that is
assigned to the Simulated ECUs part, you have to do the following:
§ Set the Execute user code on frame transmission property of the bus
configuration to True.

§ Extend the user code by the following functions of the Bus Custom Code
interface:
1. Implement the DsBusCustomCode_onFrameTransmissionExecution
function in the user code file that contains the user code ID.
2. Implement the DsBusCustomCodeUserCodePduFeature_
getRuntimeCanFrameTriggering function in the
DsBusCustomCode_onFrameTransmissionExecution function.

Note

§ The Execute user code on frame transmission property neither has

effects on RX PDUs that are assigned to the Simulated ECUs part, nor on
PDUs that are assigned to the Inspection or Manipulation part. If you
want to access the run‑time frame triggering of such PDUs, you have to
implement the DsBusCustomCodeUserCodePduFeature_
getRuntimeCanFrameTriggering function in the
DsBusCustomCode_onPduFeatureExecution function.
§ You can access the run‑time frame triggering of a TX PDU that is assigned
to the Simulated ECUs part only if the PDU is directly included in a
frame. You cannot access the run‑time frame triggering of a simulated TX
PDU if it is configured in any of the following ways:
§ Authentic IPDU of a non‑cryptographic secured IPDU
§ Dynamic‑part or static‑part IPDU of a multiplexed IPDU
§ Contained IPDU of a container IPDU

For more information, refer to Implementing

the DsBusCustomCodeUserCodePduFeature_getRuntimeCanFrameTriggering
Function in the User Code (Bus Custom Code Interface Handling ).

Run-time behavior of applied Depending on the direction of the PDU (TX or RX ), applying user code to a
user code PDU results in the following behavior at run time:
§ In case of a TX PDU, the PDU data is provided to the user code each time the
transmission of the TX PDU is triggered. On the basis of the PDU data, the
user-specified algorithms are executed and the calculated values are written to
the PDU. Then, the PDU is transmitted on the bus.
However, if you add the PDU User Code feature to a TX PDU that is assigned
to the Manipulation part, this behavior applies only if the feature is enabled

259
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with Bus Configuration Features

at run time. Refer to Configuring the run-time behavior for manipulation on

page 261.
The timing for executing the user code depends on the task to which
the related BusCfg_MainFunctionFetch [<bus configuration name>]
and BusCfg_MainFunctionDeliver [<bus configuration name>] runnable
functions are assigned. Refer to Fetch and Deliver Runnable Functions for
Receiving and Transmitting PDUs on page 366.
§ In case of an RX PDU, the PDU data is provided to the user code each
time the RX PDU is received on the bus. On the basis of the received PDU
data, the user-specified algorithms are executed. For example, a received
checksum value can be passed to the user code to be evaluated by the related
verification algorithms.

Data provided by the Result For RX PDUs, a Result function port is available. The Result function port can
function port provide data of the user code, for example, the verification result of a received
and evaluated checksum value. However, the specific data that is provided by
the Result function port depends on the definitions in the related user code
implementation.

To provide user code data to the Result function port, use

the DsBusCustomCodeUserCodePduFeature_setResult function of
the Bus Custom Code interface in the user code. Refer to
DsBusCustomCodeUserCodePduFeature_setResult (Bus Custom Code Interface
Handling ).

By default, the initial function port value is 0. Via the function port's Initial
value property, you can specify a user-defined initial value in the range
0 … UInt32max. To access the function port value at run time, you have to
enable model access or test automation support for the function port. Refer to
Configuring Function Ports for Bus Configuration Features on page 198.

Manipulation-specific In addition to the feature-specific properties and function ports, the following
properties and function ports manipulation-specific properties and function ports are available if you add the
PDU User Code feature to a PDU that is assigned to the Manipulation part:
§ A Countdown start value and an Enable property are available that let you
configure the run-time behavior for applying the user code to the PDU. You
can access the properties in following ways:
§ You can access both properties in the Properties Browser when you select
the PDU User Code node in the Bus Configurations table.

260
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Bus Configuration Features Available for PDUs

§ You can also access the Countdown start value property in the Bus
Manipulation Features table.

§ If the PDU is involved in secure onboard communication, a Recalculate

SecOC information checkbox is available. You can access the checkbox in
the following ways:
§ In the Properties Browser when you select the PDU User Code node in
the Bus Configurations table.
§ In the Recalculate SecOC Information - PDU User Code column of the
Bus Manipulation Features table.
If the checkbox is selected, the authentication information of the affected
secured IPDU is recalculated before transmission. For more information, refer
to Recalculating End-to-End Protection and Authentication Information on
page 217.
§ The following function ports are available:
§ Current Countdown Value function port
§ Countdown Start Value function port
§ Enable function port
§ Enable State function port
The following illustration is an example of the function ports as displayed in
the Bus Configurations table:

Configuring the run-time When you add the PDU User Code feature to a TX PDU that is assigned to
behavior for manipulation the Manipulation part, the user code applies to the PDU only if the feature is
enabled at run time.

You can enable the feature via the Enable property or the Initial value and
Initial substitute value properties of the Enable function port as follows:
§ Set the related property to 1: Permanently enabled.
The user code applies to the PDU until you disable the feature explicitly, e.g.,
via experiment software.
§ Set the related property to 2: Temporarily enabled.
The user code applies to the PDU for a defined number of times. You can
specify the number of times via the Countdown start value property or the
Initial value and Initial substitute value properties of the Countdown Start
Value function port.

You can access the current enable state and countdown value via the Enable
State and Current Countdown Value function ports, respectively. For more
information, refer to Basics on Bus Manipulation Features on page 213.

261
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with Bus Configuration Features

By default, you can change the specified settings via experiment software at run
time. If you want to change the settings via a behavior model or provide function
port values to a behavior model, you have to enable model access for the related
function port. Refer to Configuring Function Ports for Bus Configuration Features
on page 198.

Restrictions for using the PDU For using the PDU User Code feature and its related user code, the following
User Code feature and its restrictions apply:
related user code § You cannot use the PDU User Code and the Frame Access feature in parallel.
If you add both features to a PDU, conflicts occur. This also applies if the PDU
is included in another PDU and the Frame Access feature is added to this
PDU.
§ In the user code, you cannot specify whether the user code applies to the PDU
User Code feature for simulation, inspection, or manipulation. This results in
the following restrictions:
§ For example, your user code contains algorithms for calculating checksum
values and manipulating the calculated values. By default, the manipulation
algorithms also apply to the PDU User Code simulation and inspection
features that reference this user code. To apply the manipulation algorithms
only to the PDU User Code manipulation feature, you can do the following:
§ Use a user port: In the user code, access the user port and implement the
manipulation algorithms in such a way that they are only executed if the
user port has a specific value, e.g., 1. At run time, set this user port only
for the PDU User Code manipulation feature to the specified value.
§ Use two different user code implementations and include the
manipulation algorithms only in one of them. Then, reference the
manipulating user code implementation in the PDU User Code
manipulation feature and the other one in the PDU User Code simulation
and/or inspection feature.
§ If you want to access the run‑time frame triggering of TX CAN
PDUs that are simulated and manipulated, you have to use two
different user code implementations. Refer to Implementing the
DsBusCustomCodeUserCodePduFeature_getRuntimeCanFrameTriggering
Function in the User Code (Bus Custom Code Interface Handling ).

Additionally, restrictions concerning the general usage of user code apply. Refer
to Restrictions for implementing user code in ConfigurationDesk applications on
page 141.

Related topics Basics

Basic Principles of the Bus Custom Code Interface (Bus Custom Code Interface
Handling )

262
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Bus Configuration Features Available for PDUs

References

Function Inport Properties (Bus Configuration) (ConfigurationDesk Function Block

Properties )
Function Outport Properties (Bus Configuration) (ConfigurationDesk Function Block
Properties )

Accessing the Priority of J1939-Compliant IPDUs

Introduction You can access the priority of J1939‑21‑compliant IPDUs that are assigned to the
Simulated ECUs, Inspection, or Manipulation part of a bus configuration.

Conditions for accessing the To access the priority of a J1939‑21‑compliant IPDU, you have to add the J1939
J1939 priority PDU Priority feature to a selected IPDU. Refer to Adding bus configuration
features on page 192.

You can add the feature to any IPDU that complies with J1939‑21 and that is not
included in a multiplexed IPDU , container IPDU , or secured IPDU .

Effects of adding the J1939 Adding the J1939 PDU Priority feature to a J1939‑21‑compliant IPDU has the
PDU Priority feature following effects:
§ Depending on the direction of the J1939‑21‑compliant IPDU (TX or RX ),
a TX J1939 Priority function port or RX J1939 Priority function port is
available for the IPDU. The function port lets you access the priority. The
following illustration is an example of the function port as displayed in the Bus
Configurations table:

263
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with Bus Configuration Features

§ If you add the J1939 PDU Priority feature to a J1939‑21‑compliant IPDU that
is assigned to the Manipulation part, the following additional properties and
function ports are available:
§ A J1939 priority property that lets you specify an initial priority for the
IPDU. You can access the property in following ways:
§ In the Properties Browser when you select the J1939 PDU Priority node
in the Bus Configurations table.

§ In the Bus Manipulation Features table.

Tip

If the column is not available, you can add it via the Column
Chooser. Refer to Bus Configuration Tables on page 103.

§ A Countdown start value and an Enable property are available that let
you configure the run-time behavior for manipulating the J1939 priority.
You can access the properties in following ways:
§ You can access both properties in the Properties Browser when you
select the J1939 PDU Priority node in the Bus Configurations table.
§ You can also access the Countdown start value property in the Bus
Manipulation Features table.
§ The following function ports are available:
§ Current Countdown Value function port
§ Countdown Start Value function port
§ Enable function port
§ Enable State function port
The following illustration is an example of the function ports as displayed in
the Bus Configurations table:

Accessing the J1939 priority The J1939 Priority function port provides the J1939 priority as follows:
§ For TX IPDUs, the function port specifies the J1939 priority that is transmitted
on the bus.

264
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Bus Configuration Features Available for PDUs

§ For RX IPDUs, the function port provides the J1939 priority that is received on
the bus, e.g., to a mapped behavior model.

The default priority is derived from the communication matrix. Via the Initial
value property of the function port, you can specify a user‑defined initial priority
in the range 0 … 7. The lower the value, the higher the priority of the IPDU.

If the IPDU is assigned to the Manipulation part, you can also use the J1939
priority property to specify a user‑defined initial priority. When you do this, the
specified value automatically applies to the initial value of the function port.

To access the priority at run time, you have to enable model access or test
automation support for the function port. Refer to Configuring Function Ports
for Bus Configuration Features on page 198.

Configuring the run-time When you add the J1939 PDU Priority feature to an IPDU that is assigned to
behavior for manipulation the Manipulation part, the J1939 priority is manipulated only if the feature is
enabled at run time.

You can enable the feature via the Enable property or the Initial value and
Initial substitute value properties of the Enable function port as follows:
§ Set the related property to 1: Permanently enabled.
The J1939 priority of the IPDU is manipulated until you disable the feature
explicitly, e.g., via experiment software.
§ Set the related property to 2: Temporarily enabled.
The J1939 priority of the IPDU is manipulated for a defined number of times.
You can specify the number of times via the Countdown start value property
or the Initial value and Initial substitute value properties of the Countdown
Start Value function port.

You can access the current enable state and countdown value via the Enable
State and Current Countdown Value function ports, respectively. For more
information, refer to Basics on Bus Manipulation Features on page 213.

To change the specified settings at run time, you have to enable model access
or test automation support for the related function ports. Refer to Configuring
Function Ports for Bus Configuration Features on page 198.

Specifying saturation values For the TX J1939 Priority, Countdown Start Value, and Enable function ports,
you can specify user-defined saturation values to limit the minimum and
maximum values of the function ports. If you want to do this, you have to first
set the bus configuration's Saturation usage property to User min/max value.
Refer to Specifying saturation values for function inports on page 201.

Restrictions for using the You cannot add the J1939 PDU Priority feature to IPDUs that comply with
J1939 PDU Priority feature J1939‑22.

265
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with Bus Configuration Features

Related topics References

Function Inport Properties (Bus Configuration) (ConfigurationDesk Function Block

Properties )

Accessing the Selector Field Value of Multiplexed IPDUs

Introduction You can access the selector field value of multiplexed IPDUs that are assigned
to the Simulated ECUs or Inspection part of a bus configuration.

For example, this lets you specify the dynamic‑part IPDU that is included in
the multiplexed IPDU when the static‑part IPDU triggers the transmission of the
multiplexed IPDU.

Conditions for accessing the To access the selector field value of a multiplexed IPDU, you have to add the
selector field value PDU Selector Field feature to a selected multiplexed IPDU. Refer to Adding bus
configuration features on page 192.

You can add the feature to TX and RX multiplexed IPDUs.

Effects of adding the PDU Depending on the direction of the multiplexed IPDU (TX or RX ), a TX
Selector Field feature Selector Field Value function port or RX Selector Field Value function port is
available for the IPDU.

The following illustration is an example of the function port as displayed in the

Bus Configurations table:

Accessing the selector field The Selector Field Value function port lets you access the value of the selector
value field as follows:

Function Port Description

RX Selector For RX multiplexed IPDUs, the RX Selector Field Value function port provides the selector field value that is
Field Value port received on the bus, e.g., to a mapped behavior model.
TX Selector If the static‑part IPDU triggers the transmission of the TX multiplexed IPDU, the value of the TX Selector Field
Field Value port Value function port determines the dynamic‑part IPDU that is included in the multiplexed IPDU:
§ If a dynamic‑part IPDU with a matching selector field value is assigned to the bus configuration, this IPDU is
included in the multiplexed IPDU.

266
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Bus Configuration Features Available for PDUs

Function Port Description

§ If no such IPDU is assigned to the bus configuration, the behavior is the following:
§ If the multiplexed IPDU was not transmitted beforehand, the initial dynamic‑part IPDU is included in the
multiplexed IPDU.

Tip

In most cases, the communication matrix specifies which IPDU is the initial dynamic‑part IPDU. If
required, you can change this setting. Refer to Configurable Settings of PDUs on page 414.

§ If the multiplexed IPDU was transmitted beforehand, the previously transmitted dynamic‑part IPDU is
included in the multiplexed IPDU.
If a dynamic‑part IPDU triggers the transmission of the TX multiplexed IPDU, the function port value has no
effects.

The default function port value is the selector field value of the initial
dynamic‑part IPDU. If the communication matrix does not specify an initial
dynamic‑part IPDU, the lowest selector field value that is specified for any of
the dynamic‑part IPDUs is used as the default value.

Via the Initial value property of the function port, you can specify a
user‑defined initial selector field value in the range <data type>min … <data
type>max of the function port. The data type of the function port is derived from
the length of the selector field in the multiplexed IPDU:

Selector Field Length Function Port Data Type

1 … 8 bits UInt8
9 … 16 bits UInt16
17 … 32 bits UInt32
33 … 64 bits UInt64

Tip

According to AUTOSAR, the valid range of the selector field length is 1 …

16 bits.

To access the selector field value at run time, you have to enable model access
or test automation support for the function port. Refer to Configuring Function
Ports for Bus Configuration Features on page 198.

Specifying saturation values For TX Selector Field Value function ports, you can specify saturation values to
for TX Selector Field Value limit the minimum and maximum selector field value. If you want to do this,
function ports you have to first set the bus configuration's Saturation usage property to User
min/max value. Refer to Specifying saturation values for function inports on
page 201.

Restrictions for using the PDU You cannot use the PDU Selector Field and the Frame Access feature in
Selector Field feature parallel. If you add both features to an IPDU, conflicts occur. This also applies
if the IPDU is included in another IPDU and the Frame Access feature is added to
this IPDU.

267
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with Bus Configuration Features

Related topics References

Function Inport Properties (Bus Configuration) (ConfigurationDesk Function Block

Properties )
Function Outport Properties (Bus Configuration) (ConfigurationDesk Function Block
Properties )

Verifying the Authentication Information of Received Secured IPDUs

Introduction You can verify the authentication information of received secured IPDUs that
are assigned to the Simulated ECUs or Inspection part of a bus configuration.

Conditions for verifying the To verify the authentication information of a received secured IPDU, you have to
authentication information of do the following:
received secured IPDUs § Add the SecOC feature to the RX secured IPDU. Refer to Adding bus
configuration features on page 192.
§ If the secured IPDU is configured as a cryptographic IPDU, manually assign the
related authentic IPDU to the same bus configuration part of the same bus
configuration.

Tip

In case of a non‑cryptographic IPDU, this happens automatically when

you assign the secured IPDU to the bus configuration. Refer to Notes on
assigning specific PDU types on page 117.

§ Enable SecOC support for the bus configuration and provide user code for
secure onboard communication. The user code must contain the algorithms
for verifying the authentication information. Refer to Implementing Secure
Onboard Communication in Executable Applications on page 143.
Moreover, the user code must contain specific functions of the Bus Custom
Code interface for exchanging data with the SecOC feature. Refer to the
following descriptions.

Effects of adding the SecOC Depending on the bus configuration part, the following function ports are
feature available when you add the SecOC feature to a secured IPDU:

Function Port Available For Purpose

Enable Verification § Simulated Lets you enable and disable the verification of
ECUs the authentication information.
§ Inspection
State § Simulated Can provide the state of the verification, for
ECUs example, whether the verified authentication
§ Inspection information is valid.

268
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Bus Configuration Features Available for PDUs

Function Port Available For Purpose

Authenticator Value Inspection Provides the authenticator value (MAC) that is
received on the bus.
Freshness Value Inspection Provides the freshness value that is received
on the bus.
Calculated Inspection Can provide the freshness value that is
Freshness Value calculated in the user code.

The following illustration is an example of the function ports as displayed in the

Bus Configurations table:

Run-time behavior of When a secured IPDU for which the SecOC feature was added is received, the
verifying authentication value of the Enable Verification function port must be accessed by the user code.
information
The definitions in the user code must determine which value of the Enable
Verification function port enables the verification. If the verification is enabled,
the received PDU data can be evaluated by verification algorithms that are
specified in the user code. The State function port can provide data of the user
code, for example, to indicate that a received freshness value was invalid.

When you add the SecOC feature to a secured IPDU that is assigned to the
Inspection part, you can additionally do the following:
§ Access the authenticator value and freshness value that is received with the
secured IPDU via the Authenticator Value and Freshness Value function port,
respectively.
§ Access data of the user code via the Calculated Freshness Value function port.
For example, the function port can provide the complete freshness value that
was calculated in the user code. However, the actual provided data depends
on the definitions in the user code.

To access function port values at run time, you have to enable model access
or test automation support for the related function port. Refer to Configuring
Function Ports for Bus Configuration Features on page 198.

The Bus Manager processes received secured IPDUs even if the verification
indicates an error. If you want to reject a secured IPDU in this case, you have
to model the rejection in a behavior model, e.g., by using data that is provided
by the State function port.

Accessing the Enable In the user code, use the following functions of the Bus Custom Code interface
Verification, Calculated to access the Enable Verification, Calculated Freshness Value, and State function
Freshness Value, and State ports:
function ports in the user
code

269
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with Bus Configuration Features

Action Required Function of the Bus Custom Code Interface

Access the value of the Enable DsBusCustomCodeSecOCRxPduFeature_getEnableVerification (Bus Custom Code Interface
Verification function port. Handling )
Provide data of the user code to the DsBusCustomCodeSecOCRxPduFeature_setCalculatedFreshnessValue (Bus Custom Code
Calculated Freshness Value function Interface Handling )
port.
Provide data of the user code to the DsBusCustomCodeSecOCRxPduFeature_setVerificationResult (Bus Custom Code Interface
State function port. Handling )

Recommended usage of The specifications in the user code determine how the values of the Enable
specific function port values Verification and State function ports are evaluated. The following table provides
an overview of the recommended usage of specific function port values.

Function Port Value Use For

Enable 0 Disable verification.
Verification 1 Enable verification.
State 0 SECOC_VERIFICATIONSUCCESS: Verification was successful.
1 SECOC_VERIFICATIONFAILURE: Verification failed, for
example, because the related verification function of the user
code indicates an error.
2 SECOC_FRESHNESSFAILURE: Verification failed because of an
unexpected freshness value.
62 SECOC_MESSAGELINKERFAILURE: Verification failed because
of an unexpected message linker value.
63 SECOC_VERIFICATIONNOTEXECUTED: Verification is not
executed because it is disabled.

Specifying initial function When you add the SecOC feature to a secured IPDU, the function ports provide
port values default initial values. Via the Initial value property of each function port, you
can specify a user-defined initial value. The value range depends on the related
function port, as shown in the following table.

Function Port Initial Value Value Range

Enable Verification 0 0 … UInt32max
State 63 0 … UInt32max
Authenticator Value § Vector, vector size determined by 0 … 255 for each
the value of the Authentication TX vector element
length property of the secured IPDU
§ Initial value of each vector element: 0
Freshness Value 0 0 … UInt64max
Calculated Freshness 0 0 … UInt64max
Value

For more information on initial values, refer to Specifying initial values on

page 198.

270
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Bus Configuration Features Available for PDUs

Restrictions for using the When you use the SecOC feature, restrictions concerning the general usage
SecOC feature of user code apply. Refer to Restrictions for implementing user code in
ConfigurationDesk applications on page 141.

Related topics References

Function Inport Properties (Bus Configuration) (ConfigurationDesk Function Block

Properties )
Function Outport Properties (Bus Configuration) (ConfigurationDesk Function Block
Properties )

Invalidating the Authenticator of Secured IPDUs

Introduction You can invalidate the authenticator (MAC) of secured IPDUs that are assigned
to the Manipulation part of a bus configuration.

Conditions for invalidating To invalidate the authenticator of a secured IPDU, you have to do the following:
the authenticator of secured § Add the SecOC Authenticator Invalidation feature to the secured IPDU.
IPDUs Refer to Adding bus configuration features on page 192.
§ If the secured IPDU is configured as a cryptographic IPDU, manually assign
the related authentic IPDU to the Manipulation part of the same bus
configuration.

Tip

In case of a non‑cryptographic IPDU, this happens automatically when

you assign the secured IPDU to the bus configuration. Refer to Notes on
assigning specific PDU types on page 117.

§ Enable SecOC support for the bus configuration and provide user code for
secure onboard communication. Refer to Implementing Secure Onboard
Communication in Executable Applications on page 143.

271
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with Bus Configuration Features

Effects of adding the SecOC Adding the SecOC Authenticator Invalidation feature to a secured IPDU has
Authenticator Invalidation the following effects:
feature § A Countdown start value and an Enable property are available that let you
configure the run-time behavior for invalidating the authenticator. You can
access the properties in following ways:
§ You can access both properties in the Properties Browser when you select
the SecOC Authenticator Invalidation node in the Bus Configurations
table.

§ You can also access the Countdown start value property in the Bus
Manipulation Features table.

Tip

If the column is not available, you can add it via the Column Chooser.
Refer to Bus Configuration Tables on page 103.

§ A Recalculate SecOC information checkbox is available. You can access the

checkbox in the following ways:
§ In the Properties Browser when you select the SecOC Authenticator
Invalidation node in the Bus Configurations table.
§ In the Recalculate SecOC Information - SecOC Authenticator
Invalidation column of the Bus Manipulation Features table.

Note

Selecting this checkbox might result in unintended behavior at run time.

Refer to Recalculating authentication information on page 274.

§ The following function ports are available:

§ Current Countdown Value function port
§ Countdown Start Value function port
§ Enable function port
§ Enable State function port

272
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Bus Configuration Features Available for PDUs

The following illustration is an example of the function ports as displayed in

the Bus Configurations table:

Configuring the run-time As long as the SecOC Authenticator Invalidation feature is enabled at
behavior for invalidating the run time, the authenticator (MAC) is invalidated: After the authentication
authenticator information (i.e., authenticator and freshness value) is calculated in the user code
and written to the secured IPDU, the value of the most significant bit of the
authenticator is inverted.

You can enable the feature via the Enable property or the Initial value and
Initial substitute value properties of the Enable function port as follows:
§ Set the related property to 1: Permanently enabled.
The most significant bit of the authenticator is invalidated until you disable the
feature explicitly, e.g., via experiment software.
§ Set the related property to 2: Temporarily enabled.
The most significant bit of the authenticator is invalidated for a defined
number of times. You can specify the number of times via the Countdown
start value property or the Initial value and Initial substitute value
properties of the Countdown Start Value function port.

You can access the current enable state and countdown value via the Enable
State and Current Countdown Value function ports, respectively. For more
information, refer to Basics on Bus Manipulation Features on page 213.

To change the specified settings at run time, you have to enable model access
or test automation support for the related function ports. Refer to Configuring
Function Ports for Bus Configuration Features on page 198.

Providing the feature enable You can provide the enable state of the SecOC Authenticator
state to the user code Invalidation feature to the user code by using the
DsBusCustomCodeSecOCTxPduFeature_getAuthenticationType function
of the Bus Custom Code interface in the user code:
§ When the feature is enabled at run time, the provided state is 0.
§ When the feature is disabled at run time, the provided state is 1.

Tip

You can use the SecOC Authenticator Invalidation feature at run time
without providing the enable state to the user code. However, providing the
enable state might be useful if you want to manipulate the authenticator
in the user code when the SecOC Authenticator Invalidation feature is
disabled, for example.

Refer to DsBusCustomCodeSecOCTxPduFeature_getAuthenticationType (Bus

Custom Code Interface Handling ).

273
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with Bus Configuration Features

Recalculating authentication In general, if the Recalculate SecOC information checkbox is selected, the
information authentication information of the secured IPDU is recalculated before the
secured IPDU is transmitted. By this, the invalidated authenticator is overwritten.

Note

You cannot change this setting at run time. Therefore, if the checkbox is
selected, the invalidated authenticator will never be transmitted.

By default, the Recalculate SecOC information checkbox is cleared. In most

cases, it is recommended to keep the default setting.

However, if the secured IPDU is affected by other bus manipulation features

for which the Recalculate SecOC information checkbox is selected, the
authentication information might be recalculated even if the checkbox is
cleared for this feature. For more information, refer to Recalculating End-to-End
Protection and Authentication Information on page 217.

Specifying saturation values For the Countdown Start Value and Enable function ports, you can specify
user-defined saturation values to limit the minimum and maximum values of
the function ports. If you want to do this, you have to first set the bus
configuration's Saturation usage property to User min/max value. Refer to
Specifying saturation values for function inports on page 201.

Restrictions for using When you use the SecOC Authenticator Invalidation feature, restrictions
the SecOC Authenticator concerning the general usage of user code apply. Refer to Restrictions for
Invalidation feature implementing user code in ConfigurationDesk applications on page 141.

Moreover, some limitations apply for calculating authentication information.

Refer to Limitations for secure onboard communication on page 522.

Related topics References

Function Inport Properties (Bus Configuration) (ConfigurationDesk Function Block

Properties )
Function Outport Properties (Bus Configuration) (ConfigurationDesk Function Block
Properties )

Overwriting the Freshness Value of Secured IPDUs

Introduction You can overwrite the freshness value of secured IPDUs that are assigned to
the Manipulation part of a bus configuration.

274
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Bus Configuration Features Available for PDUs

Conditions for overwriting To overwrite the freshness value of a secured IPDU, you have to do the following:
the freshness value of secured § Add the SecOC Freshness Overwrite Value feature to the secured IPDU.
IPDUs Refer to Adding bus configuration features on page 192.
§ If the secured IPDU is configured as a cryptographic IPDU, manually assign
the related authentic IPDU to the Manipulation part of the same bus
configuration.

Tip

In case of a non‑cryptographic IPDU, this happens automatically when

you assign the secured IPDU to the bus configuration. Refer to Notes on
assigning specific PDU types on page 117.

§ Enable SecOC support for the bus configuration and provide user code for
secure onboard communication. Refer to Implementing Secure Onboard
Communication in Executable Applications on page 143.
Moreover, the user code must contain specific functions of the Bus Custom
Code interface for exchanging data with the SecOC Freshness Overwrite
Value feature. Refer to the following descriptions.

Effects of adding the SecOC Adding the SecOC Freshness Overwrite Value feature to a secured IPDU has
Freshness Overwrite Value the following effects:
feature § The following properties are available:
§ A Countdown start value and an Enable property that let you configure
the run-time behavior for overwriting the freshness value.
§ A Freshness Overwrite Value property that lets you specify an initial value
for overwriting the freshness value.
§ A Recalculate SecOC information property, indicating that the
authentication information of the secured IPDU is recalculated before the
PDU is transmitted on the bus.
You can access the properties in following ways:
§ You can access all properties in the Properties Browser when you select
the SecOC Freshness Overwrite Value node in the Bus Configurations
table.

§ You can also access the Countdown start value and Freshness Overwrite
Value properties in the Bus Manipulation Features table.

275
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with Bus Configuration Features

Tip

If a required column is not available, you can add it via the Column
Chooser. Refer to Bus Configuration Tables on page 103.

§ The following function ports are available:

§ Current Countdown Value function port
§ Countdown Start Value function port
§ Enable function port
§ Enable State function port
§ Freshness Overwrite Value function port
The following illustration is an example of the function ports as displayed in
the Bus Configurations table:

Configuring the run-time As long as the SecOC Freshness Overwrite Value feature is enabled at run
behavior for overwriting the time, the original freshness value is overwritten with a specified overwrite value.
freshness value
You can enable the feature via the Enable property or the Initial value and
Initial substitute value properties of the Enable function port as follows:
§ Set the related property to 1: Permanently enabled.
The freshness value is overwritten until you disable the feature explicitly, e.g.,
via experiment software.
§ Set the related property to 2: Temporarily enabled.
The freshness value is overwritten for a defined number of times. You can
specify the number of times via the Countdown start value property or the
Initial value and Initial substitute value properties of the Countdown Start
Value function port.

You can access the current enable state and countdown value via the Enable
State and Current Countdown Value function ports, respectively. For more
information, refer to Basics on Bus Manipulation Features on page 213.

To change the specified settings at run time, you have to enable model access
or test automation support for the related function ports. Refer to Configuring
Function Ports for Bus Configuration Features on page 198.

Specifying overwrite values You can specify an overwrite value via the Freshness overwrite value property
in the value range 0 … UInt64max. The specified value applies to the Initial
value and Initial substitute value properties of the Freshness Overwrite Value
function port automatically.

By default, you can change the specified overwrite value via experiment software
at run time. If you want to change the overwrite value via a behavior model, you

276
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Bus Configuration Features Available for PDUs

have to enable model access for the Freshness Overwrite Value function port.
Refer to Configuring Function Ports for Bus Configuration Features on page 198.

Specifying saturation values For the Countdown Start Value, Enable, and Freshness Overwrite Value function
ports, you can specify user-defined saturation values to limit the minimum and
maximum values of the function ports. If you want to do this, you have to first
set the bus configuration's Saturation usage property to User min/max value.
Refer to Specifying saturation values for function inports on page 201.

Required specifications in the To manipulate the authentication information by using the freshness overwrite
user code value, specify the following in the user code:
§ Provide the enable state of the SecOC Freshness Overwrite Value feature to
the user code by using the DsBusCustomCodeSecOCTxPduFeature_
getEnableFreshnessValueCalculation function of the Bus Custom Code
interface in the user code:
§ When the feature is enabled at run time, the provided state is 0.
§ When the feature is disabled at run time, the provided state is 1.
For more information, refer to
DsBusCustomCodeSecOCTxPduFeature_getEnableFreshnessValueCalculation
(Bus Custom Code Interface Handling ).
§ When the feature is enabled at run time, i.e., the provided state is 0,
use the specified freshness overwrite value to calculate the authenticator
(MAC). To access the specified freshness overwrite value, use the
DsBusCustomCodeSecOCTxPduFeature_getUserDefinedFreshnessValue
function of the Bus Custom Code interface in the user code.
For more information, refer to
DsBusCustomCodeSecOCTxPduFeature_getUserDefinedFreshnessValue (Bus
Custom Code Interface Handling ).
§ If the authentication information that is included in the secured IPDU consists
of the authenticator and the freshness value, include the specified overwrite
value in the secured IPDU. However, consider the Freshness value TX length
setting of the secured IPDU to determine whether the overwrite value must be
truncated.

Recalculating the For the SecOC Freshness Overwrite Value feature, the Recalculate SecOC
authentication information information checkbox is selected and read-only. Therefore, when the feature
is enabled at run time, the authentication information of the secured IPDU is
always recalculated before the PDU is transmitted on the bus.

However, if the SecOC Freshness Overwrite Value and the SecOC

Authenticator Invalidation features are enabled at the same time, the
authentication information is recalculated after the authenticator was invalidated
by the SecOC Authenticator Invalidation feature. Therefore, the invalidated
authenticator is not transmitted on the bus. Refer to Invalidating the
Authenticator of Secured IPDUs on page 271.

277
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with Bus Configuration Features

For basic information on recalculating the authentication information, refer

to Recalculating End-to-End Protection and Authentication Information on
page 217.

Restrictions for using the When you use the SecOC Freshness Overwrite Value feature, restrictions
SecOC Freshness Overwrite concerning the general usage of user code apply. Refer to Restrictions for
Value feature implementing user code in ConfigurationDesk applications on page 141.

Moreover, some limitations apply for calculating authentication information.

Refer to Limitations for secure onboard communication on page 522.

Related topics References

Function Inport Properties (Bus Configuration) (ConfigurationDesk Function Block

Properties )
Function Outport Properties (Bus Configuration) (ConfigurationDesk Function Block
Properties )

Suspending the Transmission of PDUs

Introduction You can suspend the transmission of PDUs that are assigned to the
Manipulation part of a bus configuration.

Conditions for suspending the To suspend the transmission of a PDU, you have to add the Suspend PDU
transmission of PDUs Transmission feature to the PDU. Refer to Adding bus configuration features on
page 192.

You can add the feature to J1939‑22‑compliant IPDUs with a payload length of
up to 60 bytes, i.e., to IPDUs that are transmitted using the Multi‑PG protocol.
For more information on J1939‑22‑compliant IPDUs and the Multi‑PG protocol,
refer to Aspects of the J1939 Protocol on page 80.

278
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Bus Configuration Features Available for PDUs

Effects of adding the Suspend Adding the Suspend PDU Transmission feature to a PDU has the following
PDU Transmission feature effects:
§ A Countdown start value and an Enable property are available that let you
configure the run-time behavior for suspending the PDU transmission. You can
access the properties in following ways:
§ You can access both properties in the Properties Browser when you select
the Suspend PDU Transmission node in the Bus Configurations table.

§ You can also access the Countdown start value property in the Bus
Manipulation Features table.

Tip

If the column is not available, you can add it via the Column Chooser.
Refer to Bus Configuration Tables on page 103.

§ The following function ports are available:

§ Current Countdown Value function port
§ Countdown Start Value function port
§ Enable function port
§ Enable State function port
The following illustration is an example of the function ports as displayed in
the Bus Configurations table:

Configuring the run-time As long as the Suspend PDU Transmission feature is enabled at run time, the
behavior for suspending the transmission of the PDU is suspended.
PDU transmission
You can enable the feature via the Enable property or the Initial value and
Initial substitute value properties of the Enable function port as follows:
§ Set the related property to 1: Permanently enabled.
The transmission of the PDU is suspended until you disable the feature
explicitly, e.g., via experiment software.

279
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with Bus Configuration Features

§ Set the related property to 2: Temporarily enabled.

The transmission of the PDU is suspended for a defined number of times. You
can specify the number of times via the Countdown start value property or
the Initial value and Initial substitute value properties of the Countdown
Start Value function port.

You can access the current enable state and countdown value via the Enable
State and Current Countdown Value function ports, respectively. For more
information, refer to Basics on Bus Manipulation Features on page 213.

To change the specified settings at run time, you have to enable model access
or test automation support for the related function ports. Refer to Configuring
Function Ports for Bus Configuration Features on page 198.

Effects of suspending the Suspending the transmission of a PDU has the following effects on the active bus
transmission of a PDU communication:
§ If you suspend the transmission of a PDU while the PDU is being transmitted,
the transmission is not interrupted. The transmission of the PDU is suspended
after the PDU is completely transmitted.
§ If you suspend the transmission of the PDU, the PDU is not queued, i.e., the
suspended transmissions are discarded and lost. The suspended transmissions
are not processed when the transmission of the PDU is enabled again. This
applies to all suspended transmissions, regardless of whether they are cyclic
transmissions or event‑triggered transmissions.
§ A frame that is transmitted according to the Multi‑PG protocol can contain
multiple PDUs (contained parameter groups, C‑PGs). This results in the
following effects:
§ If you suspend the transmission of a PDU, this neither affects the
transmission of the frame nor of the other PDUs that are included in this
frame.
§ If you suspend the transmission of a PDU, the length of the related frame is
shortened accordingly to avoid unused frame bytes.
§ If multiple instances of a PDU are included in a frame and you suspend the
transmission of this PDU temporarily, the following applies: The number of
PDU instances that are included in the frame is reduced by the number of
suspended transmissions.
For example, five PDU instances are to be included in the frame. If you
suspend the transmission of the PDU for two times, the first two PDU
instances are lost. The remaining three PDU instances are included in the
frame.
§ If you suspend the transmission of all PDUs that are included in one frame,
the transmission of the frame is suspended as well.

Specifying saturation values For the Countdown Start Value and Enable function ports, you can specify
user-defined saturation values to limit the minimum and maximum values of
the function ports. If you want to do this, you have to first set the bus
configuration's Saturation usage property to User min/max value. Refer to
Specifying saturation values for function inports on page 201.

280
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Bus Configuration Features Available for PDUs

Related topics References

Function Inport Properties (Bus Configuration) (ConfigurationDesk Function Block

Properties )
Function Outport Properties (Bus Configuration) (ConfigurationDesk Function Block
Properties )

Triggering the Execution of Functions in a Behavior Model via RX Interrupts

Introduction You can use CAN RX PDUs that are assigned to the Simulated ECUs part of a
bus configuration to trigger the execution of functions in a behavior model via
RX interrupts.

Conditions for triggering the To trigger the execution of functions in a behavior model via RX interrupts, you
execution of functions in have to add the PDU RX Interrupt feature to a CAN RX PDU. Refer to Adding
a behavior model via RX bus configuration features on page 192.
interrupts
You can add the PDU RX Interrupt feature to a CAN RX PDU only if it fulfills all
of the following conditions:
§ The CAN RX PDU is directly included in one frame and not affected by
secured IPDUs . Therefore, the PDU can be one of the following types:
§ Container IPDU that is not configured as an authentic IPDU of a secured
IPDU.
§ Multiplexed IPDU that is not configured as an authentic IPDU, contained
IPDU, or J1939-compliant IPDU
§ Basic PDU that is not configured in any of the following ways:
§ Authentic IPDU
§ Contained IPDU
§ Static‑part or dynamic‑part IPDU of a multiplexed IPDU
§ J1939-compliant IPDU
§ If the PDU is a container IPDU or multiplexed IPDU, all its included PDUs must
be assigned to the same ECU connector port as the PDU itself.
§ The frame in which the PDU is included has exactly one frame triggering .

Effects of adding the PDU RX When you add the PDU RX Interrupt feature to a CAN RX PDU, the following
Interrupt feature ports are available for the PDU:
§ RX Interrupt Enable function port
This function port lets you enable and disable the PDU RX Interrupt feature.
§ Received event port
This event port provides an event (i.e., the RX interrupt) each time the
related CAN RX PDU is received.

281
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with Bus Configuration Features

The following illustration is an example of the ports as displayed in the Bus

Configurations table:

Use scenario for working with RX interrupts let you work independently of the periodic task to
RX interrupts which the BusCfg_MainFunctionFetch [<bus configuration name>]
and BusCfg_MainFunctionDeliver [<bus configuration name>] runnable
functions of the bus configuration are assigned. This has the following effects:
§ The timing for triggering functions in the behavior model does not depend on
the periodic task. Instead, the functions can be triggered by the RX interrupt,
i.e., by the event that is generated each time the related RX PDU is received on
the bus.
§ The data that is available for the function ports of the RX PDU and the
involved elements is updated immediately with the reception of the PDU. The
timing for updating the function port values does not depend on the task
to which the related BusCfg_MainFunctionFetch [<bus configuration
name>] runnable function is assigned.
The involved elements are elements that are included in the PDU and that are
assigned to the Simulated ECUs part of the same bus configuration. Elements
that are included in the RX PDU can be ISignals, contained IPDUs, or static‑part
or dynamic‑part IPDUs.

Required steps for using RX To use RX interrupts in the behavior model, you have to do the following:
interrupts § Add the PDU RX Interrupt feature to a CAN RX PDU.
§ Map the Received event port to a runnable function port .
Refer to Mapping event ports to runnable function ports on page 283.
§ Model the triggering behavior in the behavior model.
The modeling in the behavior model depends on your requirements and
the type of the behavior model. For information on modeling the triggering
behavior in a MATLAB®/Simulink® model, refer to Modeling the triggering
behavior in a MATLAB/Simulink behavior model on page 284.

Enabling and disabling the The value of the RX Interrupt Enable function port determines the enable state of
PDU RX Interrupt feature the PDU RX Interrupt feature.

Specifying the initial state Via the Initial value property of the function
port, you can specify the initial state of the PDU RX Interrupt feature as follows:
§ False (0): The PDU RX Interrupt feature is disabled.
§ True (1): The PDU RX Interrupt feature is enabled. This is the default state.

Changing the enable state at run time To change the enable state at
run time, you have to enable model access or test automation support for the
function port. Refer to Configuring Function Ports for Bus Configuration Features
on page 198.

282
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Bus Configuration Features Available for PDUs

Note

To ensure optimum run‑time behavior, it is recommended to enable model

access for the RX Interrupt Enable function port and to use it in the behavior
model by mapping it to a model port block . In the behavior model, make
sure that the related model port block is executed according to a periodic
task, i.e., a task that is executed cyclically. For information on modeling
this behavior in a MATLAB/Simulink behavior model, refer to Modeling the
triggering behavior in a MATLAB/Simulink behavior model on page 284.

Effects of disabling the PDU RX Interrupt feature When you add the PDU
RX Interrupt feature to a PDU, the processing of the PDU data according to the
periodic task to which the BusCfg_MainFunctionFetch [<bus configuration
name>] and BusCfg_MainFunctionDeliver [<bus configuration name>]
runnable functions are assigned is disabled. This applies regardless of whether
you enable or disable the PDU RX Interrupt feature.
Thus, disabling the PDU RX Interrupt feature does not enable the cyclic
processing of the PDU data according to the related periodic task. Instead, if
you disable the PDU RX Interrupt feature, the processing of the PDU data
is disabled completely: When the PDU is received on the bus, the data of
the related function ports is not updated, no event is generated (i.e., no RX
interrupt), and the affected functions of the behavior model are not triggered.

Mapping event ports to To use the PDU RX Interrupt feature at run time, you have to map the Received
runnable function ports event port to a runnable function port.

Runnable function ports are available when you add a behavior model to
the ConfigurationDesk application and this behavior model provides Runnable
Function blocks . To map an available runnable function port to an event port,
you can drag the runnable function port from the Model Browser to the event
port in the Bus Configurations or Bus Configuration Ports table, for example.

For a detailed example, refer to Example of Mapping Model Ports to Bus

Configuration Ports via Tables on page 358.

When you map a runnable function port to the event port, the related runnable
function and I/O event are assigned to a task. For more information, refer to
Basics on Tasks, Events, and Runnable Functions Provided by the Bus Manager on
page 363.

If you do not map the Received event port to a runnable function port, a conflict
occurs. If you do not resolve the conflict, the PDU RX Interrupt feature is
inactive and you cannot use the feature at run time. Instead, the PDU data
is processed according to the task to which the BusCfg_MainFunctionFetch

283
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with Bus Configuration Features

[<bus configuration name>] and BusCfg_MainFunctionDeliver [<bus

configuration name>] runnable functions are assigned.

Tip

If you work with a MATLAB/Simulink behavior model and the model does
not provide Runnable Function blocks, you can create the required blocks
from within the ConfigurationDesk application. Refer to Points to note for
creating model port blocks on page 285.

Modeling the triggering If you work with a MATLAB/Simulink behavior model, you can model the
behavior in a triggering behavior by using a Runnable Function block and a function‑call
MATLAB/Simulink behavior subsystem. To do this, you can map the Runnable Function block that provides
model the event of the PDU RX Interrupt feature to the function{} port of a
function‑call subsystem. In this case, the subsystem is executed each time the
event is generated. Therefore, the functions that you model in the subsystem are
executed each time the related RX PDU is received on the bus.

In the following cases, no event can be generated:

§ The PDU RX Interrupt feature is disabled.
§ The related communication controller is disabled via the Communication
Controller Enable feature.
§ The related bus configuration is disabled via the Bus Configuration Enable
feature.
§ The RX PDU cannot be received because the transmission of the related TX
PDU is disabled via the PDU Enable feature, the Communication Controller
Enable feature, or the Bus Configuration Enable feature.

Note

Depending on the modeling in the behavior model and the specified

settings in the ConfigurationDesk application, you cannot enable the
features again at run time. In this case, the event generation is permanently
disabled and the function‑call subsystem, including its functions, will never
be executed at run time.

To ensure that you can enable the event generation again at run time, do the
following:
§ In the ConfigurationDesk application, enable model access for the RX Interrupt
Enable function port and map it to a data outport .
§ In the Simulink model, ensure that the related model port block is executed
according to a periodic task, i.e., do not place it in a function‑call subsystem.

284
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Bus Configuration Features Available for PDUs

Instead, place it in a subsystem that is executed according to the Bus

Configuration task, for example.
§ If you use model port blocks that are mapped to the Enable function port of
the Communication Controller Enable feature, Bus Configuration Enable
feature, or PDU Enable feature, ensure that these model port blocks are also
executed according to a periodic task.

In the following example, the model port blocks that are mapped to Enable
function ports are included in the Bus Configuration (1) subsystem, which is
executed according to the Bus Configuration task. Because the function‑call
subsystem is placed on the same level as the model port blocks, it does not
affect their execution.

If your model does not have suitable model port blocks, you can create the
required blocks from within the ConfigurationDesk application. However, there
are some points to note.

Points to note for creating For unmapped event ports and function ports of bus configurations, you can
model port blocks create model port blocks , i.e., Runnable Function blocks and data port
blocks. However, the default settings of bus configurations prohibit the creation
of Runnable Function blocks.

Basics on creating model port blocks In general, when you select a bus
configuration, you can create the required model port blocks in a new or an
existing Simulink model via the Generate New Simulink Model Interface or
Propagate to Simulink Model commands.

285
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with Bus Configuration Features

Note

If ports of the bus configuration are already mapped to model ports and
the related Simulink model is available in the Model Browser, you change
the model when you use the Propagate to Simulink Model command.
In Simulink, you cannot undo the changes. Refer to Basics of Connecting
ConfigurationDesk and Simulink Behavior Models (ConfigurationDesk Real-
Time Implementation Guide ).

To create Runnable Function blocks, you have to change the default setting for
the structure of model port blocks.

Specifying the structure of model port blocks Each bus configuration

provides a Model port block structure property that lets you specify the
structure of model port blocks when you create the blocks from within the
ConfigurationDesk application. By default, the property is set to Block-based.
This has the following effects when you create model port blocks for the bus
configuration:
§ Up to two data port blocks are created:
§ If the bus configuration has unmapped function inports, one data port block
providing data outports is created.
§ If the bus configuration has unmapped function outports, one data port
block providing data inports is created.
§ No Runnable Function blocks are created, even if the bus configuration has
unmapped event ports.
To create Runnable Function blocks for unmapped event ports and separate
data port blocks for unmapped function ports, you have to set the Model port
block structure property to Function-based or Port-based.

Note

Setting the Model port block structure property to Function-based or

Port-based can significantly increase the number of created model port
blocks. This might reduce performance.

To optimize the number of created model port blocks, it is recommended to

create model port blocks according to the following workflow:
1. Configure the bus communication via bus configuration features according
to your requirements but without the PDU RX Interrupt feature.
2. Enable model access for the function ports whose data you want to use in
the behavior model but for which you do not need separate model port
blocks.
3. Use the default setting of the Model port block structure property, i.e.,
Block-based, and create model port blocks for the bus configuration.

286
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Bus Configuration Features Available for PDUs

4. Add the PDU RX Interrupt feature to the required PDUs. Enable model
access for the function ports whose data you want to use in the behavior
model and for which you need separate model port blocks.
5. Set Model port block structure to Function-based or Port-based and
create the remaining model port blocks.
For more information, refer to Specifying Options for Creating Model Port Blocks
(ConfigurationDesk Real-Time Implementation Guide ).

Restrictions for using the PDU If you use the PDU RX Interrupt feature, the following restrictions apply:
RX Interrupt feature § You cannot use the PDU RX Interrupt and the Frame Access feature in
parallel. If you add both features to a PDU, conflicts occur.
§ If you use RX interrupts in the behavior model to trigger functions that
provide data to bus configurations that is to be transmitted on the bus, the
timing for transmitting the data on the bus depends on the task to which
the related BusCfg_MainFunctionDeliver [<bus configuration name>]
runnable function is assigned.
§ In general, you can use one event to trigger the execution of multiple runnable
functions by mapping one event port to multiple runnable function ports.
However, if you generate bus simulation containers, it depends on the specific
simulation platform (e.g., VEOS) whether this triggering behavior is supported.
§ RX masks, which can be specified in the communication matrix, are ignored.
Instead, the complete identifier of a received CAN frame is considered for
evaluating whether the frame matches the related frame triggering settings.

Related topics Basics

Basics on Configuring Tasks (ConfigurationDesk Real-Time Implementation

Guide )
Basics on Tasks, Events, and Runnable Functions Provided by the Bus Manager....................... 363
Working with Simulink Behavior Models (ConfigurationDesk Real-Time
Implementation Guide )

References

Function Outport Properties (Bus Configuration) (ConfigurationDesk Function Block

Properties )

287
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with Bus Configuration Features

Bus Configuration Features Available for Frames

Where to go from here Information in this section

Accessing CAN Frame Settings.............................................................. 288

Manipulating the Payload Length of CAN Frames.................................. 295

Suspending the Transmission of Frames................................................. 298

Accessing CAN Frame Settings

Introduction You can access the settings of CAN frames that are assigned to the Simulated
ECUs part of a bus configuration and change settings at run time.

Conditions for accessing CAN To access and change settings of a CAN frame at run time, you have to add the
frame settings Frame Access feature to a PDU that is included in the frame. Refer to Adding
bus configuration features on page 192.

You can add the Frame Access feature to a PDU only if the PDU and the related
frame fulfill all of the following conditions:
§ The PDU is a CAN PDU that is directly included in one frame. Therefore, the
PDU can be of one of the following types:
§ Container IPDU that is not configured as an authentic IPDU of a
non‑cryptographic secured IPDU
§ Multiplexed IPDU that is neither configured as an authentic IPDU of a
non‑cryptographic secured IPDU, nor configured as a contained IPDU or
J1939-compliant IPDU
§ Secured IPDU that is not configured as a contained IPDU
§ Basic PDU that is not configured in any of the following ways:
§ Authentic IPDU of a non‑cryptographic secured IPDU
§ Contained IPDU
§ Static‑part or dynamic‑part IPDU of a multiplexed IPDU
§ J1939-compliant IPDU
§ General-purpose PDU that contains a global time domain in the bus
configuration.
§ The PDU has exactly one frame triggering and this triggering is a CAN frame
triggering.
§ The related CAN frame has exactly one PDU-to-frame mapping.

288
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Bus Configuration Features Available for Frames

Effects of adding the Frame Adding the Frame Access feature to a PDU has the following effects:
Access feature § A Maximum length and Trigger mode property are available that let you
specify the frame's maximum length and the triggering mode for the frame's
transmission, respectively. The Trigger mode property is available only for TX
PDUs. You can access the properties in two ways:
§ In the Properties Browser when you select the Frame Access node in the
Bus Configurations table.

§ In the Bus Simulation Features table.

Tip

If a required column is not available, you can add it via the Column
Chooser. Refer to Bus Configuration Tables on page 103.

§ Depending on the direction of the PDU (TX or RX ), the following function

ports are available:

Function Ports Available for …

TX PDUs RX PDUs
Trigger function port State function port
TX Length function port RX Length function port
TX Raw Data function port RX Raw Data function port
Identifier function port Identifier function port
Extended Addressing function port Extended Addressing function port
CAN FD Frame Support function port CAN FD Frame Support function port
Bit Rate Switch function port Bit Rate Switch function port

289
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with Bus Configuration Features

The following illustration is an example of the function ports as displayed in

the Bus Configurations table:

Accessing CAN frames via the Adding the Frame Access feature to a PDU lets you do the following:
Frame Access feature § You can trigger the transmission of the frame. Refer to Triggering the frame
transmission on page 290.
§ You can access the length of the frame. Refer to Accessing the frame length
on page 290.
§ You can access the payload of the frame in raw data format. Refer to
Accessing the payload of the frame in raw data format on page 291.
§ You can access the frame triggering. Refer to Accessing the frame triggering
on page 293.
§ You can access the state of the frame. Refer to Accessing the frame state on
page 294.

Triggering the frame When you add the Frame Access feature to a TX PDU, you cannot transmit the
transmission PDU according to cyclic timings, e.g., as specified in the communication matrix.
To transmit the PDU and the related frame, you have to specify the transmission
of the frame in the following way:
1. Add the Frame Access feature to the TX PDU.
2. Select a triggering mode via the Trigger mode property.
3. Configure the Trigger function port.

For more information, refer to Triggering the Transmission of PDUs and Frames
via User-Defined Triggers on page 210.

Accessing the frame length When you add the Frame Access feature to a TX or RX PDU, you can specify
the maximum payload length of the frame and access the payload length at run
time.

290
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Bus Configuration Features Available for Frames

Specifying the maximum payload length The Maximum length property

lets you specify the maximum payload length of the frame in bytes. Valid values
are 1 … 8, 12, 16, 20, 24, 32, 48, and 64 bytes. The default maximum length is
64 bytes. The specified maximum length determines the following:
§ The valid maximum value of the Length function port.
§ The data width of the Raw Data function port.
You cannot change the specified maximum length during run time.

Accessing the frame length at run time The Length function port provides
the payload length of the frame as follows:
§ For TX PDUs, the function port value specifies the payload length with which
the related frame is transmitted on the bus.
§ For RX PDUs, the function port provides the received payload length of the
related frame, e.g., to a mapped behavior model.
By default, the initial function port value is the frame's payload length that
is specified in the communication matrix. Via the function port's Initial value
property, you can specify a user-defined initial payload length in the range 0 …
<maximum length>. In the following cases, the payload length is automatically
adjusted at run time:
§ For classic CAN frames, the maximum length is saturated to 8 bytes.
§ A payload length that is invalid according to CAN FD is extended by padding
bytes to the next higher valid length. The value of each padding byte is 255.
Refer to CAN FD protocol on page 77.
To access the payload length at run time, you have to enable model access or
test automation support for the function port. Refer to Configuring Function
Ports for Bus Configuration Features on page 198.

Accessing the payload of the When you add the Frame Access feature to a TX or RX PDU, you can access the
frame in raw data format payload of the related frame (including the PDU) in raw data format only. The
Raw Data function port provides the raw data of the payload as follows:
§ For TX PDUs, the function port value specifies the raw data with which the
related frame is transmitted on the bus.
§ For RX PDUs, the function port provides the received raw data of the related
frame, e.g., to a mapped behavior model.

Configuring the Raw Data function port The value of the Raw Data
function port is a vector. The default value of each vector element is 0. Via
the function port's Initial value property, you can specify a user-defined initial
raw data in the range 0 … 255 for each vector element.
To access the raw data at run time, you have to enable model access or test
automation support for the function port. Refer to Configuring Function Ports
for Bus Configuration Features on page 198.

Effects of the Maximum length property The data width of the Raw Data
function port is derived from the Maximum length property. If you change the
Maximum length property, the function port's data width adjusts accordingly.
Because the data width determines the vector size of the function port value,

291
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with Bus Configuration Features

this has the following effects on the function port's Initial value and Initial
substitute value properties:
§ If the data width is reduced, the vector size of both properties reduces
accordingly. The vector elements are deleted from right to left and the values
specified for these elements are lost, as shown in the following example.

§ If the data width is increased, the vector size of both properties increases
accordingly. The new vector elements are added to the right of the existing
vector elements. The default value of the new vector elements is 0.

Data provided by the Raw Data function port The vector size of Raw Data
function ports determines the maximum number of bytes that are available for
the related Raw Data function port. The available bytes are used as follows:
§ The frame data is written to the Raw Data function port bytes from left to
right.
§ For TX frames, the frame length that is specified via the Length function port
determines the number of the Raw Data function port bytes that transmit
raw data. If the specified frame length is shorter than the vector size of the
Raw Data function port, the values of the unused function port bytes are not
transmitted on the bus.
§ For RX frames, the received frame length determines the number of function
port bytes that are updated with the received frame data. If the received frame
length is shorter than the vector size of the Raw Data function port, the
unused function port bytes keep their last value.
The value provided by a TX Raw Data function port might not be the value that
is transmitted on the bus. This can happen if the length of a TX frame is invalid
according to CAN FD. In this case, padding bytes are added to the frame length.
The padding bytes' value (i.e., 255) is transmitted on the bus but not available at
the TX Raw Data function port.

Example for accessing the frame's payload via the Frame Access
feature In the following example, the Frame Access feature is added to a
TX and an RX instance of a PDU. The vector size of both Raw Data function
ports (TX, RX) is 16 bytes. For the TX Raw Data function port, the raw data of
all bytes is 40. The actual length of the related TX frame is 9 bytes. Therefore,
only the raw data of the first 9 bytes is transmitted on the bus. Because 9 bytes
is an invalid length according to CAN FD but 12 bytes is a valid CAN FD length,
the frame length is extended by 3 padding bytes with a value of 255 each. The
following table provides an overview of this example.

292
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Bus Configuration Features Available for Frames

Byte
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Data of TX Raw Data function port 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40
Length of TX frame x x x x x x x x x - - - - - - -
Padding byte - - - - - - - - - 255 255 255 - - - -
Data transmitted on the bus 40 40 40 40 40 40 40 40 40 255 255 255 - - - -

The data that is transmitted on the bus is received by the RX Raw Data function
port of the related RX PDU instance. The data is received as the RX frame data. In
the following example, the old data of the RX Raw Data function port was 125.
Then, the 12 bytes of the RX frame are received. The first 12 bytes of the RX Raw
Data function port are updated with the received data. The last 4 bytes of the
function port keep their previous value, as shown in the following table.

Byte
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Old data of RX Raw Data function 125 125 125 125 125 125 125 125 125 125 125 125 125 125 125 125
port
New data of RX frame 40 40 40 40 40 40 40 40 40 255 255 255 - - - -
New data of RX Raw Data function 40 40 40 40 40 40 40 40 40 255 255 255 125 125 125 125
port

Tip

On RX side, it is not possible to identify the origin of the received frame

data, i.e., it cannot be identified whether the values of the bytes 10, 11,
and 12 are padding byte values or values of the frame's original payload.

Accessing the frame When you add the Frame Access feature to a TX or RX PDU, you can access the
triggering frame triggering via the following function ports:

Function Port Purpose Value Range

Extended Lets you access the identifier format of the frame. § 0: Standard identifier format (11-bit)
Addressing § 1: Extended identifier format (29-bit)
function port
Identifier Lets you access the identifier of the frame. Depends on the identifier format specified for the
function port Extended Addressing function port:
Note § Standard identifier format: 0 … 211 -1
§ Extended identifier format: 0 … 229 -1
If the identifier is invalid according to the identifier
format that is specified for the Extended Addressing
function port, the frame is not transmitted or
received at run time.

CAN FD Frame Lets you access the state of the frame's CAN FD support. § 0: CAN FD support disabled, i.e., the frame is a
Support If CAN FD support is enabled, the payload length of the classic CAN frame
function port § 1: CAN FD support enabled

293
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with Bus Configuration Features

Function Port Purpose Value Range

frame can be up to 64 bytes and the data phase of the
frame can be transmitted with a higher bit rate.

Note

If CAN FD support is enabled for the frame but not

for the related CAN function block that specifies the
bus access, the frame is not transmitted or received
at run time.

Bit Rate Switch Lets you access the state of the bit rate switch. If switching § 0: Bit rate switch disabled, i.e., the data phase
function port the bit rate is enabled, the data phase of the frame can be of the frame is transmitted with the bit rate that
transmitted with a higher bit rate. is specified for the Baud rate property of the
The function port value applies only to the related frame if related CAN communication cluster.
CAN FD frame support is enabled. § 1: Bit rate switch enabled, i.e., the data phase
of the frame is transmitted with the bit rate
that is specified for the Data phase baud rate
property of the related CAN communication
cluster.

The default values of the function ports are derived from the related frame
settings that are specified in the communication matrix. Via the Initial value
property of each function port, you can specify a user-defined initial function
port value. To access the function port values at run time, you have to enable
model access or test automation support for the function ports. Refer to
Configuring Function Ports for Bus Configuration Features on page 198.

For the Identifier function port, you can additionally specify user-defined
saturation values to limit the minimum and maximum values of the function
port. For more information, refer to Specifying saturation values for function
inports on page 201.

Accessing the frame state When you add the Frame Access feature to an RX PDU, a State function port is
available that provides the state of the frame as follows:
§ 0: The frame is not received in the current sampling step. This is the default
state of the function port.
§ 1: The frame is received in the current sampling step.

Via the function port's Initial value property, you can specify a user-defined
initial value in the range 0 … 255. To access the function port value at run time,
you have to enable model access or test automation support for the function
port. Refer to Configuring Function Ports for Bus Configuration Features on
page 198.

Restrictions for using the If you use the Frame Access feature, the following restrictions apply:
Frame Access feature § You cannot use the Frame Access feature with any other PDU- or ISignal-
related bus configuration feature in parallel. This applies to the PDU to which
you add the Frame Access feature and to its included elements, i.e.:
§ PDUs that are used as contained IPDUs if you add the feature to a container
IPDU.

294
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Bus Configuration Features Available for Frames

§ PDUs that are used as an authentic IPDU if you add the feature to a
non‑cryptographic secured IPDU.
§ PDUs that are used as static‑part or dynamic‑part IPDUs if you add the
feature to a multiplexed IPDU.
§ ISignals that are directly included in the PDU or in any of its included PDUs.
If you use the Frame Access feature with any other PDU- or ISignal-related
feature in parallel, conflicts occur.
§ If you add the Frame Access feature to TX PDUs, these PDUs cannot
participate in secure onboard communication or end‑to‑end protection:
§ Secured IPDUs are transmitted without authentication information.
§ PDUs that contain end‑to‑end‑protected ISignal groups are transmitted
without end‑to‑end protection information.
§ Cyclic timings that are specified in the communication matrix are ignored.
Instead, the transmission of the PDU is only triggered according to the settings
specified for the Frame Access feature.
§ RX masks, which can be specified in the communication matrix, are ignored.
Instead, the complete frame identifier that is accessed via the Identifier
function port is considered for receiving the related PDU.

Related topics References

Function Inport Properties (Bus Configuration) (ConfigurationDesk Function Block

Properties )
Function Outport Properties (Bus Configuration) (ConfigurationDesk Function Block
Properties )

Manipulating the Payload Length of CAN Frames

Introduction You can manipulate the payload length of CAN frames that are assigned to
the Manipulation part of a bus configuration.

Conditions for manipulating To manipulate the payload length of a CAN frame, you have to add the Frame
the payload length of CAN Length feature to a PDU that is included in the frame. Refer to Adding bus
frames configuration features on page 192.

You can add the Frame Length feature to a PDU only if the PDU and the related
frame fulfill all of the following conditions:
§ The PDU is a CAN PDU that is directly included in one frame. Therefore, the
PDU can be one of the following types:
§ Container IPDU that is not configured as an authentic IPDU of a
non‑cryptographic secured IPDU
§ Multiplexed IPDU that is neither configured as an authentic IPDU of a
non‑cryptographic secured IPDU, nor configured as a contained IPDU
§ Secured IPDU that is not configured as a contained IPDU

295
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with Bus Configuration Features

§ Basic PDU that is not configured in any of the following ways:

§ Authentic IPDU of a non‑cryptographic secured IPDU
§ Contained IPDU
§ Static‑part or dynamic‑part IPDU of a multiplexed IPDU
§ J1939‑22‑compliant IPDU
§ The PDU has exactly one frame triggering for the channel of the
communication cluster for which the PDU is assigned to the Manipulation
part.
§ The related frame has exactly one PDU-to-frame mapping.

Effects of adding the Frame Adding the Frame Length feature to a PDU has the following effects:
Length feature § The following properties are available:
§ A Countdown start value and an Enable property that let you configure
the run-time behavior for manipulating the frame length.
§ A Length and a Padding value property that let you specify an initial
payload length and a value for padding bytes, respectively.
You can access the properties in following ways:
§ You can access all properties in the Properties Browser when you select
the Frame Length node in the Bus Configurations table.

§ You can also access the Countdown start value, Length, and Padding
value properties in the Bus Manipulation Features table.

Tip

If a required column is not available, you can add it via the Column
Chooser. Refer to Bus Configuration Tables on page 103.

§ The following function ports are available:

§ Current Countdown Value function port
§ Countdown Start Value function port
§ Enable function port
§ Enable State function port
§ Length function port

296
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Bus Configuration Features Available for Frames

The following illustration is an example of the function ports as displayed in

the Bus Configurations table:

Configuring the run-time As long as the Frame Length feature is enabled at run time, the payload length
behavior for manipulating the of the frame is manipulated.
payload length
You can enable the feature via the Enable property or the Initial value and
Initial substitute value properties of the Enable function port as follows:
§ Set the related property to 1: Permanently enabled.
The length of the frame is manipulated until you disable the feature explicitly,
e.g., via experiment software.
§ Set the related property to 2: Temporarily enabled.
The length of the frame is manipulated for a defined number of times. You
can specify the number of times via the Countdown start value property or
the Initial value and Initial substitute value properties of the Countdown
Start Value function port.

You can access the current enable state and countdown value via the Enable
State and Current Countdown Value function ports, respectively. For more
information, refer to Basics on Bus Manipulation Features on page 213.

To change the specified settings at run time, you have to enable model access
or test automation support for the related function ports. Refer to Configuring
Function Ports for Bus Configuration Features on page 198.

Specifying the payload length When you add the Frame Length feature to a PDU, the initial payload length is
derived from the frame's payload length that is specified in the communication
matrix. Via the Length property, you can specify a user-defined payload length
in the range 0 … 64 bytes. However, the valid range depends on the bus
protocol:
§ Classic CAN: 0 ... 8 bytes
§ CAN FD: 0 … 8, 12, 16, 20, 24, 32, 48, and 64 bytes

The specified value applies to the Initial value and Initial substitute value
properties of the Length function port automatically.

If you specify an invalid length for classic CAN frames, conflicts occur. If you
specify an invalid length for CAN FD frames, the length is automatically extended
with padding bytes to the next valid CAN FD length before the frame is
transmitted on the bus. The value of each padding byte is 255.

To change the specified length at run time, you have to enable model access
or test automation support for the Length function port. Refer to Configuring
Function Ports for Bus Configuration Features on page 198.

297
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with Bus Configuration Features

Specifying a padding value If you extend the length of a frame via the Frame Length feature, the added
for added bytes bytes are filled with a padding value. The default padding value depends on the
specifications in the communication matrix as follows:
§ If the communication matrix specifies a bit pattern for unused bits of the
related PDU, this value is used as padding value.
§ If the communication matrix does not specify a bit pattern for unused bits of
the related PDU, 0 is used as padding value.

Via the Padding value property, you can specify a user-defined padding value in
the range 0 ... 255. You cannot change the specified padding value at run time.

Note

The value of the Padding value property does not apply to padding bytes
that are used to extend the frame length to a valid CAN FD length. These
padding bytes are always filled with 255.

For example, a frame has a length of 8 bytes with a value of 125 each. Via the
Frame Length feature, you add 2 bytes and specify a Padding value of 55.
The next valid frame length according to CAN FD is 12 bytes. This results in the
following frame value:

Byte 1 2 3 4 5 6 7 8 9 10 11 12
Value 125 125 125 125 125 125 125 125 55 55 255 255

Specifying saturation values For the Countdown Start Value, Enable, and Length function ports, you can
specify user-defined saturation values to limit the minimum and maximum values
of the function ports. If you want to do this, you have to first set the bus
configuration's Saturation usage property to User min/max value. Refer to
Specifying saturation values for function inports on page 201.

Related topics References

Function Inport Properties (Bus Configuration) (ConfigurationDesk Function Block

Properties )
Function Outport Properties (Bus Configuration) (ConfigurationDesk Function Block
Properties )

Suspending the Transmission of Frames

Introduction You can suspend the transmission of frames that are assigned to the
Manipulation part of a bus configuration.

298
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Bus Configuration Features Available for Frames

Conditions for suspending the To suspend the transmission of a frame, you have to add the Suspend Frame
transmission of frames Transmission feature to a PDU that is included in the frame. Refer to Adding bus
configuration features on page 192.

You can add the Suspend Frame Transmission feature to a PDU only if the PDU
and the related frame fulfill all of the following conditions:
§ The PDU is directly included in one frame. Therefore, the PDU can be one of
the following types:
§ Container IPDU that is not configured as an authentic IPDU of a
non‑cryptographic secured IPDU
§ Multiplexed IPDU that is neither configured as an authentic IPDU of a
non‑cryptographic secured IPDU, nor configured as a contained IPDU
§ Secured IPDU that is not configured as a contained IPDU
§ Basic PDU that is not configured in any of the following ways:
§ Authentic IPDU of a non‑cryptographic secured IPDU
§ Contained IPDU
§ Static‑part or dynamic‑part IPDU of a multiplexed IPDU
§ J1939‑22‑compliant IPDU
§ The PDU has exactly one frame triggering for the channel of the
communication cluster for which the PDU is assigned to the Manipulation
part.
§ The related frame has exactly one PDU-to-frame mapping.

Effects of adding the Suspend Adding the Suspend Frame Transmission feature to a PDU has the following
Frame Transmission feature effects:
§ A Countdown start value and an Enable property are available that let you
configure the run-time behavior for suspending the frame transmission. You
can access the properties in following ways:
§ You can access both properties in the Properties Browser when you select
the Suspend Frame Transmission node in the Bus Configurations table.

§ You can also access the Countdown start value property in the Bus
Manipulation Features table.

299
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with Bus Configuration Features

Tip

If the column is not available, you can add it via the Column Chooser.
Refer to Bus Configuration Tables on page 103.

§ The following function ports are available:

§ Current Countdown Value function port
§ Countdown Start Value function port
§ Enable function port
§ Enable State function port
The following illustration is an example of the function ports as displayed in
the Bus Configurations table:

Configuring the run-time As long as the Suspend Frame Transmission feature is enabled at run time, the
behavior for suspending the transmission of the frame is suspended.
frame transmission
You can enable the feature via the Enable property or the Initial value and
Initial substitute value properties of the Enable function port as follows:
§ Set the related property to 1: Permanently enabled.
The transmission of the frame is suspended until you disable the feature
explicitly, e.g., via experiment software.
§ Set the related property to 2: Temporarily enabled.
The transmission of the frame is suspended for a defined number of times.
You can specify the number of times via the Countdown start value property
or the Initial value and Initial substitute value properties of the Countdown
Start Value function port.

You can access the current enable state and countdown value via the Enable
State and Current Countdown Value function ports, respectively. For more
information, refer to Basics on Bus Manipulation Features on page 213.

To change the specified settings at run time, you have to enable model access
or test automation support for the related function ports. Refer to Configuring
Function Ports for Bus Configuration Features on page 198.

Effects of suspending the Suspending the transmission of a frame has the following effects on the active
transmission of a frame bus communication:
§ If you suspend the transmission of a frame while the frame is being
transmitted, the transmission is not interrupted. The transmission of the frame
is suspended after the frame is completely transmitted.
§ If you suspend the transmission of the frame, the frame is not queued, i.e., the
suspended transmissions are discarded and lost. The suspended transmissions
are not processed when the transmission of the frame is enabled again. This

300
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Bus Configuration Features Available for Frames

applies to all suspended transmission, regardless of whether they are cyclic

transmissions or event‑triggered transmissions.

Specifying saturation values For the Countdown Start Value and Enable function ports, you can specify
user-defined saturation values to limit the minimum and maximum values of
the function ports. If you want to do this, you have to first set the bus
configuration's Saturation usage property to User min/max value. Refer to
Specifying saturation values for function inports on page 201.

Related topics References

Function Inport Properties (Bus Configuration) (ConfigurationDesk Function Block

Properties )
Function Outport Properties (Bus Configuration) (ConfigurationDesk Function Block
Properties )

301
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with Bus Configuration Features

Bus Configuration Features Available for Communication

Controllers
Where to go from here Information in this section

Enabling and Disabling Communication Controllers............................... 302

Sending Wake-Up Signals on a LIN Bus.................................................. 305

Working with LIN Schedule Tables......................................................... 307

Enabling and Disabling J1939 Network Management............................ 310

Enabling and Disabling Communication Controllers

Introduction You can enable and disable communication controllers that are assigned to the
Simulated ECUs part of a bus configuration.

Conditions for enabling Each network node of a communication cluster has one communication
and disabling communication controller (CAN communication controller, LIN slave communication controller,
controllers or LIN master communication controller).

To enable or disable a communication controller, you have to add the

Communication Controller Enable feature to a selected communication
controller. Refer to Adding bus configuration features on page 192.

Effects of adding the When you add add the Communication Controller Enable feature, the
Communication Controller following function ports are available for the communication controller:
Enable feature § Enable function port
This function port lets you enable and disable the communication controller.
§ Enable State function port
This function port provides the current state of the communication controller
(e.g., to a mapped behavior model).

The following illustration is an example of the function ports as displayed in the

Bus Configurations table:

302
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Bus Configuration Features Available for Communication Controllers

Note

If you enable multiple LIN master communication controllers, you must

ensure that only one LIN master is active per LIN bus at a time. For more
information, refer to Specifying the Hardware Access on page 157.

Specifying the enable state The Enable function port lets you specify the enable state of the communication
controller as follows:
§ False (0): The communication controller is disabled.
§ True (1): The communication controller is enabled. This is the default state.

The Enable State function port provides the currently active enable state.

Via the Initial value properties of the function ports, you can change the default
enable state. To change the enable state of the communication controller at run
time and to access the function port values, you have to enable model access
or test automation support for the function ports. Refer to Configuring Function
Ports for Bus Configuration Features on page 198.

Effects of disabling a General effects on the bus communication When you disable a
communication controller communication controller, you stop the communication of the related network
node. The network node does not transmit frames on the bus and received
frames are not evaluated. This lets you, for example, exclude the network node
from being simulated without adapting the configured bus communication.
If you disable a LIN master communication controller, the LIN master is disabled
and therefore the communication of the entire LIN cluster stops. Disabling a LIN
slave or CAN communication controller does not directly affect other network
nodes.

Effects on the currently active bus communication The following effects

apply to the currently active bus communication:
§ If you disable a communication controller while a frame is being
transmitted/received, the frame is not interrupted. The communication
controller is disabled after the frame is completely transmitted/received. This
behavior also applies to LIN master headers and slave responses.
§ If the transmission of a frame is triggered while the related communication
controller is disabled, the trigger is discarded and lost, i.e., the trigger is not
processed when the communication controller is active again.
§ Disabling a LIN master communication controller has the following effects on
the LIN schedule tables:
§ Disabling the communication controllers suspends the active LIN schedule
table at the end of the currently active slot.
§ If a request to switch the active LIN schedule table occurs while the
communication controller is disabled, the request is discarded and lost, i.e.,
the request is not processed when the communication controller is active
again.
For more information on working with LIN schedule tables, refer to Working
with LIN Schedule Tables on page 307.

303
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with Bus Configuration Features

Effects of re-enabling Re-enabling a communication controller at run time (i.e., switching the state
communication controllers from False to True) has the following effects:

Element Available For Effects

End-to-end End-to-end-protected ISignal The counters of end-to-end-protected ISignal groups are reset to 0.
protection counters groups (according to the
corresponding end-to-end
protection profile)
Counter signals ISignals with enabled Counter signals are reset to the specified initial counter value.
Counter Signal feature
Cyclic timings PDUs The cyclic timings of PDUs are reset to the values specified for the time
period, time offset, and minimum delay time, i.e., remaining time spans are
discarded.
Event‑controlled PDUs The event‑controlled timings of PDUs are reset to the values specified for
timings the number of repetitions, repetition period, and minimum delay time, i.e.,
remaining numbers of repetitions and time spans are discarded.
Container IPDUs CAN communication § The container timeout of TX container IPDUs is reset to its initial state.
§ The queues of contained IPDUs in container IPDUs with a dynamic
container layout are cleared, i.e., no contained IPDUs are queued.
§ The send buffer of contained IPDUs in container IPDUs with a static
container layout is cleared, i.e., no contained IPDUs are buffered.
PDU counters PDUs with enabled PDU RX PDU counters keep the last counter value and continue counting on the
Status simulation feature basis of this value.
TX and RX global Network nodes that are § The counters of time masters and time slaves are reset to 0.
time domains configured as time masters § The timings of time masters are reset to their initial states.
or time slaves in global time § The message queues are cleared, i.e., follow‑up (FUP) messages are lost
synchronization scenarios if their related synchronization (SYNC) messages were transmitted before
the communication controller was disabled.
Transport protocol Communication controllers § Only if the J1939 Network Management Enable feature is set to the 2:
address with enabled J1939 Dynamic address handling enable state: The transport protocol address
Network Management of the communication controller is reset to the address value that is
Enable feature specified in the communication matrix.
§ The communication controller sends an address claim on the CAN bus.
LIN schedule tables LIN masters § The active LIN schedule table starts from the beginning, regardless of the
resume position that is specified in the communication matrix.
§ The Schedule Index function port of the LIN Schedule Table feature is
reset to its initial value.

Note

If you enable a LIN master communication controller, you must ensure that
only one LIN master is active per LIN bus at a time. For more information,
refer to Specifying the Hardware Access on page 157.

304
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Bus Configuration Features Available for Communication Controllers

Related topics References

Function Inport Properties (Bus Configuration) (ConfigurationDesk Function Block

Properties )
Function Outport Properties (Bus Configuration) (ConfigurationDesk Function Block
Properties )

Sending Wake-Up Signals on a LIN Bus

Introduction You can send wake‑up signals via LIN communication controllers that are
assigned to the Simulated ECUs part of a bus configuration.

Conditions for sending To send a wake‑up signal on a LIN bus, you have to add the LIN Wake‑Up
wake‑up signals on a LIN bus feature to a LIN communication controller. Refer to Adding bus configuration
features on page 192.

You can add the feature to LIN master and LIN slave communication controllers.

Effects of adding the LIN When you add the LIN Wake‑Up feature, the following function ports are
Wake‑Up feature available for the communication controller:
§ Wake‑Up function port
This function port lets you specify whether the communication controller sends
wake‑up signals on the bus.
§ Wake‑Up State function port
This function port indicates whether the communication controller has
detected a wake‑up signal on the bus.

The following illustration is an example of the function ports as displayed in the

Bus Configurations table:

Sending wake‑up signals The Wake‑Up function port lets you specify whether the communication
controller sends wake‑up signals:
§ False (0): No wake‑up signal is sent. This is the default state.
§ True (1): A wake‑up signal is sent.

Via the function port's Initial value property, you can change the default state.
To change the state at run time, you have to enable model access or test
automation support for the function port. Refer to Configuring Function Ports
for Bus Configuration Features on page 198.

305
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with Bus Configuration Features

Processing of wake‑up signals Wake‑up signals are only processed if the LIN bus is in sleep mode. If a wake‑up
signal is sent while the LIN bus is in any other mode (e.g., active mode or
initialization mode), the wake‑up signal is ignored by the bus members.

The LIN bus switches to sleep mode if it is inactive for at least 4 seconds. The
LIN bus is inactive if there is no bus communication, no wake‑up signals are sent,
etc.

If the LIN communication is inactive directly after an executable

application starts, the LIN bus cannot switch to sleep mode. If a wake‑up
signal is sent in this case, it is ignored by the bus members. The LIN bus can
switch to sleep mode only after there was LIN bus communication (e.g., a frame
was sent on the bus). If then the bus is inactive for at least 4 seconds, wake-up
signals can be processed by the bus members.

Wake‑up signals detected by The value of the Wake‑Up State function port indicates whether a wake-up
the communication controller signal is detected by the communication controller:
§ 0: No wake-up signal is detected, e.g., because no wake‑up signal is sent on
the bus or the communication controller is already active.
§ 1: A wake-up signal is detected.

By default, the initial function port value is 0. Via the function port's Initial
value property, you can specify a user-defined initial value in the range 0 … 255.
To access the function port value at run time, you have to enable model access
or test automation support for the function port. Refer to Configuring Function
Ports for Bus Configuration Features on page 198.

Restrictions for using the LIN If you use the LIN Wake‑Up feature, the following restrictions apply:
Wake‑Up feature § Communication controllers that are disabled via the Communication
Controller Enable feature cannot send or receive wake‑up signals.
Before you have such communication controllers send or receive wake‑up
signals, you must enable the controllers via the Communication Controller
Enable feature.
§ If you set the Initial value or Initial substitute value property of the
Wake‑Up function port to True, a wake‑up signal is sent directly after
an executable application starts. However, this wake‑up signal cannot be
processed by the bus members.
Directly after starting an executable application the LIN bus is never in sleep
mode, even if no bus communication is active. Refer to Processing of wake‑up
signals on page 306.

Related topics References

Function Inport Properties (Bus Configuration) (ConfigurationDesk Function Block

Properties )
Function Outport Properties (Bus Configuration) (ConfigurationDesk Function Block
Properties )

306
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Bus Configuration Features Available for Communication Controllers

Working with LIN Schedule Tables

Introduction Each LIN master provides schedule tables that are used to regulate the
communication on the LIN bus. For LIN master communication controllers that
are assigned to the Simulated ECUs part of a bus configuration, you can specify
an initial schedule table and change the active schedule table during run time.

Basics on schedule tables Schedule tables define the sequence in which the LIN master transmits frame
headers on the bus and requests the answers from the connected LIN slaves .
A communication matrix can define one or more schedule tables for a LIN
master. In general, there are two types of schedule tables:
§ Continuous schedule tables
A continuous schedule table is repeated until it is stopped by another
continuous schedule table or interrupted by a run-once schedule table.
§ Run-once schedule tables
A run-once schedule table is processed only once and can be neither stopped
nor interrupted. If a run-once schedule table ends and no other schedule table
is pending, the LIN communication stops.

Switch behavior between Depending on the schedule table type, a switch request to start a new schedule
different schedule tables table has different effects on the currently active schedule table:
§ Active frame slots of continuous schedule tables cannot be stopped. If a switch
request is sent while a frame slot of a continuous schedule table is active, the
switch is delayed. The new schedule table starts at the end of this frame slot.

Continuous 1 1 2 3 4 5

Continuous 2 1 2 3 4 5 6 1 2 3 ...

delay

§ When a continuous schedule table is stopped by another continuous schedule

table, the new continuous schedule table is processed until it is stopped or
interrupted itself.
§ When a continuous schedule table is interrupted by a run-once schedule table,
the run-once schedule table is processed until it ends:
§ If no other schedule table is pending in the request queue, the original
continuous schedule table is processed again. Depending on the schedule
table's resume position, which is defined in the communication matrix, the
schedule table starts either from the beginning or from the point where it
was interrupted. The following illustration is an example for the latter case.

Continuous 1 1 2 3 4 5 1 2 3 4 5 1 ...

Run-once 1 1 2 3 4

delay

307
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with Bus Configuration Features

§ If another schedule table is pending in the request queue, this schedule

table starts.

Continuous 1 1 2 3

Run-once 1 1 2 3 4

Continuous 2 1 2 3 4 5 6 1 2 3 ...

delay

The request queue can store up to 5 schedule tables. When the request
queue is full, no further schedule tables can be added. These schedule tables
are lost.
§ If a switch request is sent while a run-once schedule table is active, the switch
is delayed until the run-once schedule table finished.

Run-once 2 1 2 3 4 5 6 7

Continuous 1 1 2 3 4 5 1 2 ...

delay

Accessing schedule tables via You can access schedule tables in two ways:
the Bus Manager § Via the LIN bus channel
When you select the LIN bus channel (e.g., in the Communication Matrices
by Clusters view of the Buses Browser), the Properties Browser displays all
the schedule tables that are defined for the LIN master.

§ Via PDUs
When you select a LIN PDU (e.g, in the Buses Browser), the Bus
Communication page of the Properties Browser displays all the schedule
tables that contain a frame triggering of the selected PDU.

Working with the LIN By default, the LIN Schedule Table feature is added automatically to each
Schedule Table feature LIN master communication controller that is assigned to the Simulated ECUs
part of a bus configuration. You can change this default behavior using
the Bus Configuration Behavior table. Refer to Specifying the Behavior

308
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Bus Configuration Features Available for Communication Controllers

for Assigning Communication Matrix Elements and Adding Bus Configuration

Features (Preview Version) on page 125.

For the LIN Schedule Table feature, a Schedule Index function port is available.
Via this function port, you can specify an initial schedule table for the related
LIN master. If you enable model access and/or test automation support, you can
change the active LIN schedule table during run time.

Note

§ By default, no initial schedule table is specified. Therefore, LIN

communication is disabled. Since model access and test automation
support of the function port are disabled by default as well, you cannot
select a schedule table during run time. To enable LIN communication,
you must either specify an initial schedule table or enable model access
and/or test automation support for the function port.
§ If you enable LIN communication via LIN schedule tables for multiple LIN
masters, you must ensure that only one LIN master is active per LIN bus at
a time. For more information, refer to Specifying the Hardware Access on
page 157.

For more information on enabling model access and test automation support,
refer to Configuring Function Ports for Bus Configuration Features on page 198.

The following illustration is an example of the function port as displayed in the

Bus Configurations table:

Notes on specifying an initial The Initial value property of a Schedule Index function port references the
schedule table position of a schedule table in the communication matrix: For example, an Initial
value of 2 references the second schedule table the communication matrix
specifies for the LIN master. This schedule table is used as the initial schedule
table.

Tip

The Properties Browser displays the position of schedule tables in the

communication matrix as a comma‑separated index behind the name of
each LIN schedule table, as shown in the following example.

309
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with Bus Configuration Features

If the Initial value is set to 0, no initial schedule table is used and no frames are
transmitted or received directly after the executable application is started. If the
Initial value is higher than the number of schedule tables defined for the LIN
master, a conflict occurs.

Limitations When you work with LIN schedule tables, some limitations apply. For details,
refer to Limitations for LIN Communication on page 528.

Related topics References

Function Inport Properties (Bus Configuration) (ConfigurationDesk Function Block

Properties )

Enabling and Disabling J1939 Network Management

Introduction You can enable, disable, and specify the enable state of J1939 network
management for CAN communication controllers that are assigned to the
Simulated ECUs part of a bus configuration.

If J1939 network management is enabled, the related network

node participates in the J1939 address claiming procedure. This procedure
ensures that a network node participates in J1939 communication only if its
transport protocol address is unique in the communication cluster. For more
information on the address claiming procedure, refer to Aspects of the J1939
Protocol on page 80.

Conditions for enabling and To enable or disable J1939 network management for a CAN communication
disabling J1939 network controller, you have to add the J1939 Network Management Enable feature
management to the communication controller. Refer to Adding bus configuration features on
page 192.

You can add the feature to any CAN communication controller that participates
in J1939 communication and that is configured as J1939 network management
node, i.e., the communication matrix specifies the J1939 name.

Note

The J1939 Network Management Enable feature has only effects on

J1939‑21 communication. It has no effects on J1939‑22 communication,
i.e., the feature is ignored for communication controllers that participate in
J1939‑22 communication. Refer to Limitations for CAN Communication on
page 525.

310
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Bus Configuration Features Available for Communication Controllers

Effects of adding the J1939 When you add the J1939 Network Management Enable feature, a J1939
Network Management Enable Network Management Enable node is added to the communication controller
feature in the Bus Configurations table, as shown in the following example.

The node provides an Enable property, which lets you specify the network
management enable state as follows:
§ 0: Disabled: J1939 network management is disabled.
§ 1: Static address handling: Static J1939 network management is enabled.
This is the default state.
§ 2: Dynamic address handling: Dynamic J1939 network management is
enabled.

You cannot change the specified enable state at run time.

The J1939 Network Management Enable feature does not provide any
settings that can be configured at run time. Therefore, no function ports are
available for this feature.

Effects of disabling J1939 If you set the Enable property to 0: Disabled, the network node neither
network management transmits address claims nor responds to received address claims at run time.
This results in the following:
§ The network node participates in the J1939 communication regardless of
whether its transport protocol address is unique in the communication cluster.
§ Other members of the communication cluster are not informed about the used
transport protocol address. Therefore, they cannot detect whether there is an
address conflict with their own transport protocol address.

Effects of enabling J1939 If you set the Enable property to 1: Static address handling or 2: Dynamic
network management address handling, the network node transmits an address claim in the
following situations at run time:
§ At application start if the bus configuration and the communication controller
are enabled.
§ The state of the bus configuration changes, i.e., it is set to enabled via the
Bus Configuration Enable feature, while the communication controller is
enabled.
§ The state of the communication controller changes, i.e., it is set to enabled via
the Communication Controller Enable feature, while the bus configuration
is enabled.

However, if the 2: Dynamic address handling enable state is selected for a

network node, the following applies: Before the network node transmits the
address claim, its transport protocol address is reset to the address value that is

311
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with Bus Configuration Features

specified in the communication matrix. This way, the network node always tries
to claim its initial transport protocol address.

The reactions on received address claims differ for the 1: Static address
handling and 2: Dynamic address handling enable states:

Enable Reaction on Received Address Claims

State
1: Static § If the network node receives an address claim that conflicts with its own transport protocol address, the network
address node responds as follows:
handling § If the network node has a higher priority, it transmits an address claim itself and participates in the J1939
communication.
According to J1939‑81, the network node that transmitted the conflicting address claim must either claim
another address or stop its J1939 communication.
§ If the network node has a lower priority, it transmits a cannot claim address message and stops its J1939
communication. This applies even if its arbitrary address capable parameter is set to 1.
§ If the network node receives address claims indicating that other network nodes have claimed new transport
protocol addresses, the network node does not adjust its J1939 communication: It transmits data to and receives
data from the transport protocol addresses that are specified in the communication matrix. This applies regardless
of whether the addresses are used by the network nodes specified by the communication matrix as the receiving
and transmitting network nodes.
2: Dynamic § If the network node receives an address claim that conflicts with its own transport protocol address, the network
address node responds as follows:
handling § If the network node has a higher priority, it transmits an address claim itself and participates in the J1939
communication.
According to J1939‑81, the network node that transmitted the conflicting address claim must either claim
another address or stop its J1939 communication.
§ If the network node has a lower priority, the response depends on the value of the arbitrary address
capable parameter:
§ Arbitrary address capable set to 0: The network node transmits a cannot claim address message and
stops its J1939 communication.
§ Arbitrary address capable set to 1: The network node claims a new transport protocol address in the
range 128 … 247 and communicates the claimed address by sending an address claim on the bus.
The network node transmits a cannot claim address message and stops its J1939 communication only if
the network node cannot claim a new address, e.g., because all addresses in the value range are used by
network nodes that have a higher priority.
§ If the network node receives address claims indicating that other network nodes have claimed new transport
protocol addresses, the network node adjusts its J1939 communication: It transmits data to and receives data from
the transport protocol addresses that are used by the network nodes the communication matrix specifies as the
receiving and transmitting network nodes.

When the enable state is set to 2: Dynamic address handling, the network
node additionally claims a new address in the following situation:
§ The arbitrary address capable parameter is set to 1.
§ The initial transport protocol address is set to 254.

Related topics Basics

Limitations for CAN Communication...................................................................................... 525

312
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Bus Configuration Features Available for Global Time Domains

Bus Configuration Features Available for Global Time Domains

Where to go from here Information in this section

Controlling the Timing of Time Synchronization..................................... 313

Accessing the Time Base Data of Time Masters and Time Slaves............ 315

Accessing Validity Checks for Time Synchronization Messages............... 317

Controlling the Timing of Time Synchronization

Introduction You can control the timing of the time synchronization of time masters that are
assigned to the Simulated ECUs part of a bus configuration.

Conditions for controlling To control the timing of the time synchronization of a time master, you have
the timing of time to add the GTS Transmission Control feature to the related TX global time
synchronization domain. Refer to Adding bus configuration features on page 192.

When you do this, you can specify the synchronization period or trigger the time
synchronization asynchronously.

Effects of adding the GTS When you add the GTS Transmission Control feature to a TX global time
Transmission Control feature domain, the following function ports are available:
§ Period function port
This function port lets you specify the synchronization period for cyclic time
synchronization.
§ Trigger function port
This function port lets you trigger the time synchronization asynchronously.

The following illustration is an example of the function ports as displayed in the

Bus Configurations table:

Specifying the The synchronization period determines the time that is available for transmitting
synchronization period a synchronization message and its related follow-up message. For more
information, refer to Run-time behavior regarding synchronization periods on
page 184.

313
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with Bus Configuration Features

The Period function port lets you specify the synchronization period in seconds
for cyclic time synchronization. By default, the initial function port value is
the synchronization period that is specified the communication matrix. If the
communication matrix does not specify a synchronization period, 0 is used as the
initial function port value. Via the function port's Initial value property, you can
specify a user-defined initial synchronization period.

Note

If the period is 0, cyclic time synchronization is disabled.

To change the synchronization period at run time, you have to enable model
access or test automation support for the function port. Refer to Configuring
Function Ports for Bus Configuration Features on page 198.

The actual timing of the time synchronization depends on the task to which
the related BusCfg_MainFunctionDeliver [<bus configuration name>]
runnable function is assigned. Refer to Fetch and Deliver Runnable Functions
for Receiving and Transmitting PDUs on page 366.

Specifying saturation values For the Period function port, you can specify user-defined saturation values
for the synchronization to limit the minimum and maximum values of the synchronization period. If
period you want to do this, you have to first set the bus configuration's Saturation
usage property to User min/max value. Refer to Specifying saturation values for
function inports on page 201.

Triggering time The Trigger function port lets you trigger time synchronization, e.g.,
synchronization asynchronously to cyclic time synchronization. Each time a rising edge is
asynchronously detected, i.e., the function port value changes from 0 to 1, a synchronization
message and its related follow-up message are transmitted once.

The default settings of the Trigger function port prohibit triggering time
synchronization asynchronously during run time. To trigger time synchronization
during run time, you must at least enable model access or test automation
support for the function port. Refer to Configuring Function Ports for Bus
Configuration Features on page 198.

By default, the initial function port value is 0. Via the function port's Initial
value property, you can specify the following values:
§ False (0): During run time, the first change of the function port value results in
a rising edge. Therefore, time synchronization is triggered asynchronously with
the first value change.

Tip

If the function port value was changed via experiment software during
run time, the function port value is automatically reset to 0 after the time
synchronization was triggered.

314
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Bus Configuration Features Available for Global Time Domains

§ True (1): During run time, the first change of the function port value results in
a falling edge. Therefore, time synchronization is not triggered asynchronously
with the first value change but with the second value change.

The actual timing of the asynchronous time synchronization depends on the task
to which the related BusCfg_MainFunctionDeliver [<bus configuration
name>] runnable function is assigned. Refer to Fetch and Deliver Runnable
Functions for Receiving and Transmitting PDUs on page 366.

Related topics Basics

Simulating Time Masters and Time Slaves of Global Time Domains......................................... 182

References

Function Inport Properties (Bus Configuration) (ConfigurationDesk Function Block

Properties )

Accessing the Time Base Data of Time Masters and Time Slaves

Introduction You can access the time base data of time masters and time slaves that are
assigned to the Simulated ECUs part of a bus configuration.

Conditions for accessing the To access the time base data of a time master or a time slave, you have to add
time base data of time the GTS Time Base Data feature to the related TX or RX global time domain.
masters and time slaves Refer to Adding bus configuration features on page 192.

Effects of adding the GTS When you add the GTS Time Base Data feature to a global time domain, the
Time Base Data feature following function ports are available:

Function Port Available For Purpose

Time § Time master Provides the time when the time synchronization message is transmitted by the time master
§ Time slave or received by the time slave, respectively. This is the time to which the time master and time
slave are synchronized.
The function port provides the time information of the synchronization (SYNC) message and
its related follow‑up (FUP) message in seconds.
Status Time master Provides the synchronization status of the time base. Refer to Status information provided by
the Status function port on page 316.
Synchronized to Time slave Provides the received synchronization state of the time base, i.e, the value of the SGW bit of
Gateway the follow‑up message:
§ False (0): The time base is directly synchronized with the global time master.
§ True (1): The time base is synchronized with a time gateway, i.e., it is not directly
synchronized with the global time master. Instead, it is synchronized with a time master
subordinate to the global time master.

315
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with Bus Configuration Features

Function Port Available For Purpose

User Bytes § Time master Provides the values of the user bytes.
§ Time slave The function port always provides three bytes, regardless of the actual number of used user
bytes. The actual number of used user bytes is provided by the User Data Length function
port.
User Data Length § Time master Provides the actual number of used user bytes.
§ Time slave

The following illustration is an example of the function ports as displayed in the

Bus Configurations table:

Specifying initial function By default, the value of all function ports is 0. Via the Initial value property of
port values and accessing the the each function port, you can specify a user-defined initial function port value.
time base data at run time To access the time base data that is provided by the function ports at run time,
you have to enable model access or test automation support for the function
ports. Refer to Configuring Function Ports for Bus Configuration Features on
page 198.

Status information provided The Status function port that is available for time masters provides the following
by the Status function port status information:

Bit Bit Name Bit Values

Position
Bit 0 (LSB) TIMEOUT § 0: No synchronization timeout.
§ 1: Synchronization timeout.
The time base was not synchronized for a longer period than specified for the Sync
loss timeout parameter in the communication matrix.
Bit 2 SYNC_TO_GATEWAY § 0: The time base is directly synchronized with the global time master.
(GTW) § 1: The time base is synchronized with a time gateway, i.e., it is not directly synchronized
with the global time master. Instead, it is synchronized with a time master subordinate of
the global time master.
Bit 3 GLOBAL_TIME_BASE § 0: The time base has never been synchronized with the global time master, e.g., because
it is based on a local clock.
§ 1: The time base has been synchronized with the global time master at least once.

316
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Bus Configuration Features Available for Global Time Domains

Bit Bit Name Bit Values

Position

Note

The time master can transmit time synchronization messages only if this bit is set to 1,
i.e., time synchronization with this time base is disabled as long as the bit value is 0.

Bit 4 TIMELEAP_FUTURE § 0: No leap into the future within the received time for the time base, i.e., the received
time does not exceed the threshold specified by the Time leap future threshold
parameter in the communication matrix.
§ 1: Leap into the future, i.e., the received time exceeds the threshold specified by the Time
leap future threshold parameter in the communication matrix.
The bit value is reset to 0 after the time has been received correctly for the number of
times specified via the Time leap healing counter parameter in the communication
matrix.
Bit 5 TIMELEAP_PAST § 0: No leap into the past within the received time for the time base, i.e., the received time
does not exceed the threshold specified by the Time leap past threshold parameter
in the communication matrix.
§ 1: Leap into the past, i.e., the received time exceeds the threshold specified by the Time
leap past threshold parameter in the communication matrix.
The bit value is reset to 0 after the time has been received correctly for the number of
times specified via the Time leap healing counter parameter in the communication
matrix.

All other bits of the Status function port are reserved and set to 0.

Related topics Basics

Simulating Time Masters and Time Slaves of Global Time Domains......................................... 182

References

Function Outport Properties (Bus Configuration) (ConfigurationDesk Function Block

Properties )

Accessing Validity Checks for Time Synchronization Messages

Introduction You can access the validity checks that are performed for time synchronization
messages received by time slaves that are assigned to the Simulated ECUs part
of a bus configuration.

Conditions for accessing To access the validity checks that are performed for the time synchronization
validity checks for time messages received by a time slave, you have to add the GTS Validation feature
synchronization messages to the related RX global time domain. Refer to Adding bus configuration features
on page 192.

317
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with Bus Configuration Features

Effects of adding the GTS When you add the GTS Validation feature to an RX global time domain, the
Validation feature following function ports are available:
§ Result function port
This function port provides the results of the validity checks that are performed
for a time synchronization message, i.e., the synchronization (SYNC) message
and its related follow‑up (FUP) message.
§ Partial Validation function port
This function port lets you exclude certain validity checks from the validation of
time synchronization messages.

The following illustration is an example of the function ports as displayed in the

Bus Configurations table:

Accessing the results of For each time synchronization message that is received by a time slave, several
validity checks validity checks are performed. In most cases, the time base of the time slave
is not synchronized if a validation check indicates an error. The result of each
validity check is written to a specific bit of the Result function port. A bit value of
1 indicates an error.

To access the results of the validity checks, you have to enable model access
or test automation support for the function port. Refer to Configuring Function
Ports for Bus Configuration Features on page 198.

The following table provides an overview of the Result function port bits that
provide results of validity checks, including the related validity checks. Bits that
are not listed in the table are reserved for future use. The value of these bits is
always 0. The table also shows which validity checks affect the synchronization
of the slave's time base.

Bit Validity Check Bit Value Affects

Position Time Base
Synchronization
Bit 0 Received two consecutive synchronization messages. § 0: No No
The first received synchronization message is ignored. § 1: Yes
Bit 2 Received synchronization message with wrong message type. § 0: No Yes
Example: A synchronization message is CRC‑secured but its message type is 0x10. § 1: Yes
Bit 4 Received synchronization message whose message length is neither 8 bytes nor § 0: No Yes
16 bytes. § 1: Yes
Bit 5 Received synchronization message whose message length is shorter than 8 bytes. § 0: No Yes
§ 1: Yes
Bit 6 Received synchronization message whose message length differs from the message § 0: No Yes
length specified in the communication matrix § 1: Yes
Bit 8 Received synchronization message whose sequence counter is either not incremented or § 0: No Yes
incremented by a value greater than specified via the sequence counter jump width § 1: Yes
attribute.

318
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Bus Configuration Features Available for Global Time Domains

Bit Validity Check Bit Value Affects

Position Time Base
Synchronization
Bit 9 Received synchronization message whose sequence counter was not incremented by 1. § 0: No No
§ 1: Yes
Bit 10 Received CRC-secured synchronization message whose CRC validated attribute is set § 0: No Yes
to CRC optional or CRC validated and whose checksum value is incorrect. § 1: Yes
Bit 11 Received CRC-secured synchronization message whose CRC validated attribute is set § 0: No Yes
to CRC optional, but no data IDs are available. § 1: Yes
Bit 16 Received two consecutive follow‑up messages. § 0: No Yes
§ 1: Yes
Bit 18 Received follow‑up message with incorrect message type. § 0: No Yes
Example: A follow‑up message is CRC‑secured but its message type is 0x18. § 1: Yes
Bit 19 Received follow‑up message whose message type does not correspond to the message § 0: No Yes
type of the related synchronization message. § 1: Yes
Example: A follow‑up message is CRC‑secured but the related synchronization message
is not CRC‑secured.
Bit 20 Received follow‑up message whose message length is neither 8 bytes nor 16 bytes. § 0: No Yes
§ 1: Yes
Bit 21 Received follow‑up message whose message length is shorter than 8 bytes. § 0: No Yes
§ 1: Yes
Bit 22 Received follow‑up message whose message length differs from the message length § 0: No Yes
specified in the communication matrix. § 1: Yes
Bit 24 Received follow‑up message whose sequence counter value differs from the sequence § 0: No Yes
counter value of the related synchronization message. § 1: Yes
Bit 26 Received CRC‑secured follow‑up message whose CRC validated attribute is set to CRC § 0: No Yes
optional or CRC validated and whose checksum value is incorrect. § 1: Yes
Bit 27 Received CRC‑secured follow‑up message whose CRC validated attribute is set to CRC § 0: No Yes
optional, but no data IDs are available. § 1: Yes
Bit 28 Received follow‑up message too late, i.e., the maximum time span between the receipt § 0: No Yes
of the synchronization message and the follow‑up message has elapsed. § 1: Yes

By default, the initial function port value is 0. Via the function port's Initial
value property, you can specify a user-defined initial value in the range
UInt32min … UInt32max. Refer to Specifying initial values on page 198.

Excluding validity checks via Enabling and disabling partial validation The Partial Validation function
partial validation port lets you enable and disable partial validation as follows:
§ False (0): Partial validation is disabled. This is the default state.
§ True (1): Partial validation is enabled.
Via the Initial value property of the function port, you can change the default
enable state. To change the enable state at run time, you have to enable model
access or test automation support. Refer to Configuring Function Ports for Bus
Configuration Features on page 198.

Effects of enabling partial validation When you enable partial validation,

certain validity checks are excluded from the validation of time synchronization
messages. The time base of the time slave is synchronized even if any of the
excluded validity checks indicates an error.

319
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with Bus Configuration Features

Tip

§ Validity checks that do not affect the time base synchronization are not
affected by partial validation.
§ The results of all validity checks are written to the Result function port,
regardless of whether they are affected by partial validation.

When you enable partial validation, only the following validity checks are used
for validating time synchronization messages:

Validity Check Bit Position of Result

Function Port
Received synchronization message whose message length Bit 5
is shorter than 8 bytes.
Received two consecutive follow‑up messages. Bit 16
Received follow‑up message whose message length is Bit 21
shorter than 8 bytes.

Related topics Basics

Simulating Time Masters and Time Slaves of Global Time Domains......................................... 182

References

Function Inport Properties (Bus Configuration) (ConfigurationDesk Function Block

Properties )
Function Outport Properties (Bus Configuration) (ConfigurationDesk Function Block
Properties )

320
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Bus Configuration Features Available for Partial Network Clusters

Bus Configuration Features Available for Partial Network

Clusters

Including Partial Network Clusters in Executable Applications and Enabling

and Disabling the Clusters

Introduction You can include partial network clusters that are available for the Simulated
ECUs part of a bus configuration in executable applications and enable and
disable the clusters.

For basic information on working with partial network clusters, refer to

Implementing Partial Networking in Executable Applications on page 146.

Conditions for including If a communication matrix specifies partial network clusters, all of the clusters are
partial network clusters in automatically added to a bus configuration when you assign any communication
executable applications and matrix element to the bus configuration.
enabling and disabling the
To include a partial network cluster in an executable application, you have to
clusters
add the Partial Network Cluster Enable feature to a selected cluster. Refer to
Adding bus configuration features on page 192. The feature also lets you enable
and disable the partial network cluster.

Effects of adding the Partial When you add the Partial Network Cluster Enable feature to a partial network
Network Cluster Enable cluster, an Enable function port is available for the cluster that lets you specify
feature the enable state. The following illustration is an example of the function port as
displayed in the Bus Configurations table:

Specifying the enable state When you add the Partial Network Cluster Enable feature to a partial network
and simulating partial cluster, the cluster is included in real-time applications and bus simulation
networking containers. Moreover, the Enable function port lets you specify the enable state
for the partial network cluster as follows:
§ 0: Disabled: The partial network cluster is disabled.
§ 1: Enabled: The partial network cluster is enabled. This is the default state.
§ 2: Reserved: Reserved for future use.

Via the Initial value property of the function port, you can change the default
enable state.

321
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with Bus Configuration Features

To simulate partial networking at run time, you have to enable model access
for the function port and map it to blocks from the AUTOSAR Network
Management Solution, which must be used in a Simulink® behavior model.
To access the function port value at run time, you can additionally enable test
automation support for the function port. Refer to Configuring Function Ports
for Bus Configuration Features on page 198.

Effects of re-enabling partial Re-enabling a partial network cluster at run time (i.e., switching the state
network clusters from 0: Disabled to 1: Enabled) has the following effects on the active bus
communication. However, these effects apply only if the affected elements are
not included in another partial network cluster that is already enabled.

Element Available For Effects

End-to-end protection End-to-end-protected ISignal The counters of end-to-end-protected ISignal groups keep the last counter
counters groups (according to the value and continue counting on the basis of this value.
corresponding end-to-end
protection profile)
Counter signals ISignals with enabled Counter signals keep the last counter value and continue counting on the
Counter Signal feature basis of this value.
Cyclic timings PDUs The cyclic timings of PDUs are reset to the values specified for the time
period, time offset, and minimum delay time, i.e., remaining time spans
are discarded.
Event‑controlled PDUs The event‑controlled timings of PDUs are reset to the values specified for
timings the number of repetitions, repetition period, and minimum delay time,
i.e., remaining numbers of repetitions and time spans are discarded.

Related topics Basics

Limitations for Communication Matrices and Communication Standards................................ 519

322
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Bus Configuration Features Available for Frame Captures and Frame Gateways

Bus Configuration Features Available for Frame Captures and

Frame Gateways
Where to go from here Information in this section

Accessing the Data of Captured Frames................................................. 323

Specifying the Direction of CAN Frame Gateways.................................. 327

Controlling Filters of Frame Captures and Frame Gateways.................... 328

Accessing the Data of Captured Frames

Introduction You can access the data of frames that are captured by frame captures of the
Inspection part of a bus configuration.

For more information on frame captures, refer to Capturing CAN Frames on

page 171.

Basics on accessing the data Each frame capture lets you capture received CAN frames independently from a
of captured frames communication matrix. Via the Frame Capture Data feature, you can access the
captured frame data.

When you add a frame capture to the Inspection part, the Frame Capture
Data feature is added automatically. This feature provides the following function
ports that let you access captured data:
§ State function port
§ Time function port
§ Length function port
§ Raw Data function port
§ Identifier function port
§ Extended Addressing function port
§ CAN FD Frame Support function port
§ Bit Rate Switch function port

323
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with Bus Configuration Features

The following illustration is an example of the function ports as displayed in the

Bus Configurations table:

Accessing captured data via The function ports of the Frame Capture Data feature let you access the
function ports captured data of all captured frames. For this purpose, the value of each
function port is a vector: Except for the Raw Data function port, there is one
vector element for each frame that can be captured. The required number of
vector elements is determined by the Maximum number of captured frames
property of the related frame capture. Refer to Configuring frame captures on
page 172. For information on the vector elements of the Raw Data function
port, refer to Data provided by the Raw Data function port on page 325.

The following table provides an overview of the data that is provided by the
function ports.

Function Port Description

State function port Each vector element indicates whether a frame is captured in the current sampling step:
§ False (0): No frame is captured in the current sampling step.
§ True (1): A frame is captured in the current sampling step.
For example, the vector size of the function port is 10, i.e., a maximum of 10 frames can be captured in one
sampling step. In the current sampling step, only 6 frames are captured. As a result, the value of the first 6
vector elements is 1, the value of the remaining vector elements is 0.
Time function port Each vector element provides the time (in seconds) of the executable application when a captured frame
was received.
Length function port Each vector element provides the payload length (in bytes) of a captured frame.
Raw Data function Provides the raw data of captured frames. Refer to Data provided by the Raw Data function port on
port page 325.
Identifier function Each vector element provides the frame identifier of a captured frame.
port
Extended Each vector element indicates whether a captured frame uses the extended identifier format:
Addressing function § False (0): The frame uses the standard identifier format (11-bit).
port § True (1): The frame uses the extended identifier format (29-bit).
CAN FD Frame Each vector element indicates whether a captured frame is a CAN FD frame:
Support function § False (0): The frame is a classic CAN frame.
port § True (1): The frame is a CAN FD frame.
Bit Rate Switch Each vector element indicates whether a captured CAN FD frame supports switching the bit rate:
function port § False (0): The frame does not support switching the bit rate, i.e., the data phase and the arbitration
phase of the frame are transmitted with the same bit rate.
§ True (1): The frame supports switching the bit rate, i.e., the data phase of the frame can be transmitted
with a higher bit rate than the arbitration phase.
For more information on the bit rate switch, refer to CAN FD protocol on page 77.

324
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Bus Configuration Features Available for Frame Captures and Frame Gateways

The default values of the function ports are False or 0. Via the Initial value
property of each function port, you can specify a user-defined initial function
port value. To access the captured data at run time, you have to enable model
access or test automation support for the function ports. Refer to Configuring
Function Ports for Bus Configuration Features on page 198.

Data provided at run time At run time, frames are captured in the order in which they are received. The
captured data is written to the vector elements of the function ports from left
to right and in descending chronological order, i.e., data of the latest captured
frame is written to the first vector element.

For example, Maximum number of captured frames of the related frame

capture is set to 6. In the first sampling step of the executable application , only
3 frames are captured, in the second sampling step 4. Except for the Raw Data
function port, this results in the following function port data:

Sampling Function Port Data of Vector Element

Step
1 2 3 4 5 6
Sampling State function 1 1 1 0 0 0
step 1 port
All other Captured Captured Captured Initial function Initial function Initial function
function ports, frame 3 frame 2 frame 1 port value port value port value
except Raw Data
Sampling State function 1 1 1 1 0 0
step 2 port
All other Captured Captured Captured Captured Captured Captured
function ports, frame 4 of frame 3 of frame 2 of frame 1 of frame 3 of frame 2 of
except Raw Data sampling sampling sampling sampling sampling sampling
step 2 step 2 step 2 step 2 step 1 step 1

Data provided by the Raw The Raw Data function port provides the raw data of all captured frames. For this
Data function port purpose, the number of vector elements of the function port is determined by
the Maximum number of captured frames and Maximum frame length
properties of the related frame capture as follows: <Value of Maximum
number of captured frames> · <value of Maximum frame length>

For example, the following settings are specified:

§ Maximum number of captured frames: 4
§ Maximum frame length: 3 bytes

In this case, the value of the Raw Data function port is a vector with 12
elements. The elements 1 … 3 provide the raw data of the latest captured frame,
the elements 4 … 6 the raw data of the previously captured frame, etc.

325
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with Bus Configuration Features

The mapping of vector elements to the frames is static. This results in the
following:
§ If the payload length of a captured frame exceeds the specified maximum
frame length, the raw data of the exceeding number of bytes is not captured.
§ If the payload length of a captured frame is smaller than the specified
maximum frame length, vector elements are unused. These elements keep
their old data.

For example, in the first sampling step of the executable application, only one
frame with a payload length of 6 bytes is captured. In the second sampling step,
three frames are captured. The payload lengths of the first two captured frames
are 3 bytes each. The payload length of the third captured frame is 2 bytes. With
the specified settings above, this results in the following function port data:

Raw Data Function Port: Data of Vector Element

1 2 3 4 5 6 7…9 10 … 12
Sampling Captured Captured Captured Initial Initial Initial Initial Initial
step 1 frame 1, frame 1, frame 1, function function function function port function port
byte 0 byte 1 byte 2 port value port value port value value value
Sampling Captured Captured Old data: Captured Captured Captured Captured Captured
step 2 frame 3 of frame 3 of Captured frame 2 of frame 2 of frame 2 of frame 1 of frame 1 of
sampling sampling frame 1 of sampling sampling sampling sampling sampling
step 2, step 2, sampling step 2, step 2, step 2, step 2, byte step 1, byte
byte 0 byte 1 step 1, byte 0 byte 1 byte 2 0…2 0…2
byte 2

Tip

The Length function port provides the payload length of each captured
frame. Therefore, you can use the Length function port to identify whether
the Raw Data function port provides the raw data of all bytes of a frame
and/or if vector elements are unused and provide old data.

Effects of deleting the Frame If you delete the Frame Capture Data feature, the related frame capture is
Capture Data feature not deleted automatically. As a result, frames are captured at run time but
you cannot access the captured data. For optimum run-time performance, it is
therefore recommended to directly delete a frame capture and not its related
Frame Capture Data feature if you do not need the frame capture.

Related topics References

Function Outport Properties (Bus Configuration) (ConfigurationDesk Function Block

Properties )

326
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Bus Configuration Features Available for Frame Captures and Frame Gateways

Specifying the Direction of CAN Frame Gateways

Introduction You can specify the gateway direction for frame gateways that are added to the
Gateways part of a bus configuration.

Basics on specifying the Each frame gateway that is added to the Gateways part of a bus configuration
direction of CAN frame lets you exchange CAN communication between two communication clusters .
gateways When you add a frame gateway to the Gateways part, the Frame Gateway
Direction feature and its Direction function port are added automatically. The
function port lets you specify the gateway direction.

The following illustration is an example of the function port as displayed in the

Bus Configurations table:

However, to gateway bus communication at run time, you have to assign bus
accesses to the bus access requests of a frame gateway. Refer to Specifying CAN
Frame Gateways on page 173.

Specifying the gateway The Direction function port lets you specify the gateway direction as follows:
direction § Disabled (0): Gatewaying is disabled.
§ Routing cluster 1 to 2 (1): The bus communication is routed from cluster 1 to
cluster 2.
§ Routing cluster 2 to 1 (2): The bus communication is routed from cluster 2 to
cluster 1.
§ Bidirectional (3): The bus communication is routed from cluster 1 to cluster 2
and vice versa (bidirectional gateway). This is the default state.

Via the function port's Initial value property, you can change the default state.
To change the gateway direction at run time, you have to enable model access
or test automation support for the function port. Refer to Configuring Function
Ports for Bus Configuration Features on page 198.

Specifying saturation values For the Direction function port, you can specify user-defined saturation values to
limit the minimum and maximum values of the function port. If you want to do
this, you have to first set the bus configuration's Saturation usage property to
User min/max value. Refer to Specifying saturation values for function inports
on page 201.

327
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with Bus Configuration Features

Effects of deleting the Frame If you delete the Frame Gateway Direction feature from a frame gateway,
Gateway Direction feature the frame gateway itself is not deleted automatically. Therefore, the bus
communication is still gatewayed at run time: The gateway direction is
bidirectional and you can neither change the gateway direction nor disable the
gateway.

Related topics References

Function Inport Properties (Bus Configuration) (ConfigurationDesk Function Block

Properties )

Controlling Filters of Frame Captures and Frame Gateways

Introduction You can enable, disable, and specify the filter mode of filters that are available
for the following elements:
§ Frame captures of the Inspection part of a bus configuration.
§ Frame gateways of the Gateways part of a bus configuration.

For basic information on capturing and gatewaying frames, refer to Capturing

CAN Frames on page 171 and Specifying CAN Frame Gateways on page 173,
respectively.

Basics on controlling filters To each filter, the Filter Control feature is added automatically. This has the
following effects:
§ For the Filter Control feature node, a Filter mode property is available. This
property lets you select whether the CAN frames that pass the related filter are
included in or excluded from capturing or gatewaying.

§ An Enable function port is available that lets you specify the enable state of
the related filter. The following illustration is an example of the function port
as displayed in the Bus Configurations table:

328
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Bus Configuration Features Available for Frame Captures and Frame Gateways

However, to filter CAN frames, you have to add at least one filter rule to each
filter. Refer to Specifying Filters for Frame Captures and Frame Gateways on
page 177.

Specifying the filter mode The Filter mode property of the Filter Control feature node lets you select the
following filter modes:
§ Exclude: The CAN frames that pass a filter rule of the related filter are not
captured or gatewayed. Instead, all other CAN frames of the communication
cluster are captured/gatewayed. This is the default mode.
§ Include: Only the CAN frames that pass a filter rule of the related filter are
captured/gatewayed.

The specified filter mode applies to all the filter rules of the related filter, i.e.,
you cannot specify different filter modes for individual filter rules of one filter.
Additionally, you cannot change the specified filter mode at run time.

Specifying the enable state of The Enable function port lets you specify the enable state of the related filter as
a filter follows:
§ False (0): The filter is disabled, i.e., all CAN frames of the cluster can be
captured/gatewayed.
§ True (1): The filter is enabled and the CAN frames can be filtered for
capturing/gatewaying. This is the default state.

Via the function port's Initial value property, you can change the default state.
To change the state at run time, you have to enable model access or test
automation support for the function port. Refer to Configuring Function Ports
for Bus Configuration Features on page 198.

Effects of deleting the Filter If you delete the Filter Control feature from a filter, the filter and its filter rules
Control feature are not deleted automatically. Therefore, the CAN frames of the cluster are still
filtered for capturing/gatewaying:
§ The filter is permanently enabled.
§ All CAN frames that pass a specified filter rule are excluded from
capturing/gatewaying.

329
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with Bus Configuration Features

Related topics References

Function Inport Properties (Bus Configuration) (ConfigurationDesk Function Block

Properties )

330
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Bus Configuration Features Available for Bus Configurations

Bus Configuration Features Available for Bus Configurations

Enabling and Disabling Bus Configurations

Introduction You can enable and disable bus configurations to enable and disable the bus
communication of a bus configuration completely or partly in one step.

Basics on enabling and To enable or disable a bus configuration, you have to add the Bus
disabling bus configurations Configuration Enable feature to the bus configuration. Refer to Adding bus
configuration features on page 192.

When you do this, an Enable function port is available for the bus configuration
that lets you specify the enable state. The following illustration is an example of
the function port as displayed in the Bus Configurations table:

Specifying the enable state of The Enable function port lets you specify the enable state of the bus
a bus configuration configuration as follows:
§ 0: Disabled: The complete bus configuration is disabled, i.e., no data is
received or transmitted on the bus.
§ 1: Enabled: The complete bus configuration is enabled, i.e., data can be
received and transmitted on the bus. This is the default state.
§ 2: RX enabled only: The bus configuration is partly enabled: Data is only
received on the bus but no data can be transmitted on the bus.

Via the function port's Initial value property, you can change the default state.
To change the bus configuration state at run time, you have to enable model
access or test automation support for the function port. Refer to Configuring
Function Ports for Bus Configuration Features on page 198.

Specifying saturation values For the Enable function port, you can specify user-defined saturation values to
limit the minimum and maximum values of the function port. If you want to do
this, you have to first set the bus configuration's Saturation usage property to
User min/max value. Refer to Specifying saturation values for function inports
on page 201.

331
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with Bus Configuration Features

Behavior of bus Setting the state of a bus configuration to 0: Disabled or 2: RX enabled only
configurations in disabled or results in the following behavior at run time:
RX enabled only state
State Run-Time Behavior
0: Disabled The entire bus communication of the bus configuration is disabled, i.e., no
bus communication is simulated, inspected, manipulated, or gatewayed.
Therefore, the bus configuration has no effects on the executable
application. For example, this allows you to use the same bus access for
variants of bus communication.
2: RX The bus configuration only receives data on the bus, i.e., the reception of
enabled bus communication can be simulated and received bus communication can
only be inspected. The received data can be provided to a mapped behavior
model, for example.
In contrast, simulating the transmission of bus communication,
manipulating bus communication, or gatewaying bus communication is not
possible. This applies even if data must be transmitted, e.g., according to
a used bus protocol. For example, no acknowledgment data is sent even
though this might be required in J1939 communication.

Switching the bus Switching the bus configuration state at run time from 0: Disabled to 2: RX
configuration state from enabled only has the following effects:
disabled to RX enabled only

Element Available For Effects

End-to-end End-to-end-protected ISignal groups The counters of end-to-end-protected ISignal groups are reset
protection (according to the corresponding end-to-end to 0.
counters protection profile)
Counter signals ISignals with enabled Counter Signal Counter signals are reset to the specified initial counter value.
feature
PDU counters PDUs with enabled PDU RX Status feature PDU counters keep the last counter value and continue
counting on the basis of this value.
RX global time ECUs that are configured as time slaves in The counters of time slaves are reset to 0.
domains global time synchronization scenarios
Transport protocol Communication controllers with enabled Only if the J1939 Network Management Enable feature is
address J1939 Network Management Enable set to the 2: Dynamic address handling enable state: The
feature transport protocol address of the communication controller
is reset to the address value that is specified in the
communication matrix.

332
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Bus Configuration Features Available for Bus Configurations

Switching the bus Switching the bus configuration state at run time from 0: Disabled or 2: RX
configuration state from enabled only to 1: Enabled has the following effects:
disabled or RX enabled only
to enabled

Element Available For Effects

End-to-end End-to-end-protected The counters of end-to-end-protected ISignal groups are reset to 0.
protection counters ISignal groups (according to
the corresponding end-to-
end protection profile)
Counter signals ISignals with enabled Counter signals are reset to the specified initial counter value.
Counter Signal feature
Cyclic timings PDUs The cyclic timings of PDUs are reset to the values specified for the time
period, time offset, and minimum delay time, i.e., remaining time spans are
discarded.
Event‑controlled PDUs The event‑controlled timings of PDUs are reset to the values specified for
timings the number of repetitions, repetition period, and minimum delay time, i.e.,
remaining numbers of repetitions and time spans are discarded.
Container IPDUs CAN communication § The container timeout of TX container IPDUs is reset to its initial state.
§ The queues of contained IPDUs in container IPDUs with a dynamic
container layout are cleared, i.e., no contained IPDUs are queued.
§ The send buffer of contained IPDUs in container IPDUs with a static
container layout is cleared, i.e., no contained IPDUs are buffered.
PDU counters PDUs with enabled PDU RX PDU counters keep the last counter value and continue counting on the basis
Status feature of this value.
TX and RX global ECUs that are configured § The counters of time masters and time slaves are reset to 0.
time domains as time masters or time § The timings of time masters are reset to their initial states.
slaves in global time § The message queues are cleared, i.e., follow‑up (FUP) messages are lost if
synchronization scenarios their related synchronization (SYNC) messages were transmitted before the
bus configuration was disabled.
Transport protocol Communication controllers § Only if the bus configuration state is switched from 0: Disabled to 1:
address with enabled J1939 Enabled and the J1939 Network Management Enable feature is set to
Network Management the 2: Dynamic address handling enable state: The transport protocol
Enable feature address of the communication controller is reset to the address value that
is specified in the communication matrix.
§ The communication controller sends an address claim on the CAN bus.
LIN schedule tables LIN masters § The active LIN schedule table starts from the beginning, regardless of the
resume position that is specified in the communication matrix.
§ The Schedule Index function port of the LIN Schedule Table feature is
reset to its initial value.
Manipulation Enabled bus manipulation Manipulation counters keep the last counter value and continue counting on
counters features the basis of this value. This affects the countdown values of bus manipulation
features: The countdown values are not reset but decremented with the next
transmission or reception of the related bus configuration elements.
Frame gateways Gateways bus The queues of frame gateways are cleared, i.e., no bus communication is
configuration part with queued for being gatewayed.
added frame gateways

333
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with Bus Configuration Features

Note

§ If you enable bus configurations that contain LIN masters, you must
ensure that only one LIN master is active per LIN bus at a time. For more
information, refer to Specifying the Hardware Access on page 157.
§ If you configure variants of bus communication by using different
bus configurations but the same bus accesses, you must ensure that
only one of the bus configurations is enabled at a time. Refer to
Limitations for CAN Communication on page 525 and Limitations for LIN
Communication on page 528, respectively.

Related topics References

Function Inport Properties (Bus Configuration) (ConfigurationDesk Function Block

Properties )

334
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Implementing Bus Communication in the Signal Chain Using the Bus Manager

Implementing Bus Communication in the Signal

Chain Using the Bus Manager

Where to go from here Information in this section

How to Add Communication Matrices to a ConfigurationDesk

Application............................................................................................ 335

How to Add a Bus Configuration to a ConfigurationDesk

Application............................................................................................ 338

How to Assign Communication Matrix Elements to a Bus

Configuration........................................................................................ 340

How to Specify the Hardware Access..................................................... 344

How to Enable Model Access for Function Ports.................................... 351

How to Add Behavior Models to a ConfigurationDesk Application......... 352

Example of Selecting Multiple Similar Communication Matrix

Elements at Once.................................................................................. 355

Example of Mapping Model Ports to Bus Configuration Ports via

Tables.................................................................................................... 358

Configuring CAN Bus Properties in CAN Function Blocks....................... 361

Configuring LIN Bus Properties in LIN Function Blocks............................ 362

How to Add Communication Matrices to a ConfigurationDesk Application

Objective To make bus network descriptions available in the ConfigurationDesk

application, you have to add one or more communication matrices to the
application.

335
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Implementing Bus Communication in the Signal Chain Using the Bus Manager

Basics For basic information, refer to Working with Communication Matrices on

page 92.

Precondition A ConfigurationDesk project with an application is open.

Method To add communication matrices to a ConfigurationDesk application

1 Switch to the Buses view set if necessary.
2 Right-click in the Buses Browser to open the context menu.
3 Click the Clear All Filters command if the command is available.

All active filters of the Buses Browser are cleared at once, i.e.:
§ All active element filters, which are indicated by a check mark on the
context menu and highlighted on the Home ribbon.
§ All active column filters, which are indicated by a blue square in the
column header.

Tip

§ If the Buses Browser is closed, you can open it via Windows on the
Home ribbon.
§ Depending on the active filters, a communication matrix might be
hidden when you import it. In this case, the Buses Browser displays
a text, informing you that no elements match the filter conditions. By
clearing all active filters you prevent the communication matrix from
being hidden.
§ You can also access the Clear All Filters command on the Home
ribbon.

336
ConfigurationDesk Bus Manager Implementation Guide May 2024
 How to Add Communication Matrices to a ConfigurationDesk Application

4 Right-click in the Buses Browser and select Add Communication Matrix

on the context menu.

Tip

You can also access the command on the Home ribbon.

The Add Communication Matrix dialog opens.

5 In the dialog, navigate to the communication matrices you want to add.
6 Select one or more communication matrices and click Open.
The selected communication matrices are added to the ConfigurationDesk
application. The Message Viewer provides information on the import:
§ If the Message Viewer displays an error message, the import failed, e.g.,
because you tried to add a communication matrix while a matrix with
identical content already exists in the application.
§ If the Message Viewer displays warning messages, inconsistent and/or
invalid communication matrix settings were detected during the import. In
this case, the affected communication matrix is imported but at least one
of the following communication matrix conflicts occurs:
§ Communication matrix: Failed consistency checks during import of
communication matrix
§ Communication matrix: Failed schema check during import of
communication matrix

Note

The inconsistent and invalid settings might result in unintended

behavior in ConfigurationDesk or at run time. It is recommended
that you correct the original communication matrix and work with
the corrected matrix. For more information, refer to Basics on Bus
Manager-Related Conflicts on page 163.

Result The selected communication matrices are added to the ConfigurationDesk

application and displayed in the Buses Browser. Depending on the selected
view, the communication matrix elements are sorted by clusters or ECUs.

337
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Implementing Bus Communication in the Signal Chain Using the Bus Manager

The drop-down list of the Buses Browser lets you change the view.

Tip

You can also add communication matrices by dragging them from the file
system to the Buses Browser .

Next step To make bus communication available in the signal chain, you can now add a
bus configuration to the application. Refer to How to Add a Bus Configuration
to a ConfigurationDesk Application on page 338.

How to Add a Bus Configuration to a ConfigurationDesk Application

Objective To be able to implement bus communication in the signal chain , you have to
add one or more bus configurations to a ConfigurationDesk application.

Precondition A ConfigurationDesk project with an application is open.

Method To add a bus configuration to an application

1 Switch to the Buses view set if necessary.

338
ConfigurationDesk Bus Manager Implementation Guide May 2024
 How to Add a Bus Configuration to a ConfigurationDesk Application

2 On the Home ribbon, click .

A new bus configuration with a unique default name is added. The Bus
Configurations table displays the bus configuration and its Simulated
ECUs, Inspection, Manipulation, and Gateways parts.

The Global working view displays the related Bus Configuration function
block.

Tip

§ If the Bus Configurations table is closed, you can open it via

Windows on the Home ribbon.
§ You can access the Global working view via the Signal Chain view
set, for example.
§ You can also add a bus configuration in the following ways:
§ By dragging communication matrix elements to the Bus
Configurations table if no bus configuration is available in the
application yet.
§ Via context menu of the Bus Configurations table.
§ By dragging a Bus Configuration function block from the
Function Browser to a working view. Refer to How to Add
Function Blocks via the Function Library (ConfigurationDesk Real-
Time Implementation Guide ).
§ Via the context menu of the Bus Configuration table, you can also
add multiple bus configurations to the application at the same time.

3 You are recommended to rename the bus configuration according to your

requirements.
To do so, select the bus configuration in the Bus Configurations table and
rename it.

Tip

You can also rename the bus configuration via the related function
block, in the Function Browser, Properties Browser, or in other
tables. Refer to How to Rename Function Blocks (ConfigurationDesk
Real-Time Implementation Guide ).

Result You added a bus configuration to the application.

339
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Implementing Bus Communication in the Signal Chain Using the Bus Manager

Next steps To make bus communication available in the signal chain and configure it
for simulation, inspection, or manipulation purposes, you can now assign
communication matrix elements to the bus configuration. Refer to How to
Assign Communication Matrix Elements to a Bus Configuration on page 340.

Related topics Basics

Basics on Bus Configurations.................................................................................................. 100

Bus Configuration Tables........................................................................................................ 103

How to Assign Communication Matrix Elements to a Bus Configuration

Objective To make bus communication available in the signal chain, you have to assign
communication matrix elements to a bus configuration.

Additionally, it is recommended to rename the communication matrix nodes in

the bus configuration, especially if you want to work with test automation scripts
later on. If you work with DBC or LDF communication matrices, this also applies
to the names of communication clusters. For more information, refer to Element
identification via node names on page 102.

Basics Depending on the communication matrix element and the bus configuration
part you assign the element to, related higher-level elements and subelements
are assigned as well. For more information, refer to Assigning Communication
Matrix Elements to Bus Configurations on page 112.

The Bus Manager provides a default behavior for assigning communication

matrix elements to bus configurations. If this default behavior does not
meet your requirements, you can specify a user‑defined behavior. For more
information, refer to Specifying the Behavior for Assigning Communication
Matrix Elements and Adding Bus Configuration Features (Preview Version) on
page 125.

Precondition A communication matrix is available in the active ConfigurationDesk application.

Method To assign communication matrix elements to a bus configuration

1 Switch to the Buses view set if necessary.

2 In the Buses Browser, select one or more communication matrix elements

and drag them to the Bus Configurations table.

340
ConfigurationDesk Bus Manager Implementation Guide May 2024
 How to Assign Communication Matrix Elements to a Bus Configuration

The selected elements are assigned to a bus configuration in one of the

following ways. For animated graphics, refer to dSPACE Help.
§ If no bus configuration existed in the ConfigurationDesk application
beforehand, a new bus configuration is added. If only one bus
configuration existed beforehand, the selected communication matrix
elements are assigned to this bus configuration. By default, the
communication matrix elements are assigned to the Simulated ECUs part
of the new or existing bus configuration.

However, the behavior might differ if the User‑Defined Configuration

checkbox on the Home ribbon is selected. If this is the case, a
user‑defined behavior for assigning communication matrix elements is
enabled and the elements are assigned to the bus configuration according
to this behavior.

Note

If two or more bus configurations existed beforehand, the

communication matrix elements are not assigned to any
bus configuration when you drag the elements to the Bus
Configurations table.

§ If you drag the communication matrix elements to the bus configuration

node or above or below any part node of an existing bus configuration,
the communication matrix elements are assigned to the Simulated ECUs
part by default.

Tip

§ If you drag elements above or below a part node, a blue line

indicates that the elements will be assigned to the Simulated
ECUs part when you drop them, as BodyControlEcu in the
following example.

§ If the User‑Defined Configuration checkbox is selected, the

behavior might differ.

§ If you drag the communication matrix elements to the Simulated ECUs,

Inspection, or Manipulation node of an existing bus configuration,

341
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Implementing Bus Communication in the Signal Chain Using the Bus Manager

the communication matrix elements are assigned to the respective bus

configuration part, as shown in the following example.

Relevant higher-level elements and subelements of the communication

matrix elements are assigned as well. All the assigned elements of the
communication matrix are marked by a chain symbol.
3 In the Bus Configurations table, select a communication matrix node and
specify a meaningful name for it.

Tip

Each communication matrix that is assigned to a bus configuration is

represented by up to four communication matrix nodes. Changes you
make for one of these nodes always apply to the other nodes as well.

The communication matrix node is renamed. The Properties Browser

displays:
§ The Name of the communication matrix nodes in the bus configuration
structure
§ The File name of the assigned communication matrix file
§ The File path of the communication matrix file
The Buses Browser displays the communication matrix file name without
file name extension.

4 If you assigned elements of a DBC or LDF communication matrix, specify a

meaningful name for the communication cluster:
§ If you assigned elements to the Simulated ECUs part, select an assigned
PDU and edit the cluster name on the Bus Communication page of the
Properties Browser.

342
ConfigurationDesk Bus Manager Implementation Guide May 2024
 How to Assign Communication Matrix Elements to a Bus Configuration

§ If you assigned elements to the Inspection or Manipulation

part, rename the related communication cluster node in the Bus
Configurations table.

5 Repeat the steps above to assign further elements of one or more

communication matrices to the bus configuration.

Tip

You can use the communication matrix filters and the Select Elements
by Type command to easily select multiple similar communication
matrix elements at once and assign them to a bus configuration. For an
example, refer to Example of Selecting Multiple Similar Communication
Matrix Elements at Once on page 355.

Result You assigned communication matrix elements to a bus configuration and

renamed the communication matrix nodes of the bus configuration structure.
If you work with a DBC or LDF communication matrix, you also renamed the
communication cluster in the bus configuration.

Next steps § You can now configure the bus communication of the bus configurations.
For example, you can add bus configuration features or specify user-defined
settings for communication matrix elements. For overviews of the configurable
elements, refer to:
§ Basics on Bus Configuration Features on page 192
§ Basics on Modifying Communication Matrices on page 391
§ If you want to build a real-time application later on, you can specify the
hardware access for the bus access requests of the bus configuration to access
bus channels of a real-time hardware. Refer to How to Specify the Hardware
Access on page 344.
§ If you want to work with a behavior model and the behavior model already
exists, you can add the model to the ConfigurationDesk application. Refer to
How to Add Behavior Models to a ConfigurationDesk Application on page 352
§ If you want to work without a behavior model, you can assign the bus
configurations to application processes. Refer to Working Without Behavior
Models on page 385.

343
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Implementing Bus Communication in the Signal Chain Using the Bus Manager

How to Specify the Hardware Access

Objective To assign a communication cluster of a bus configuration to bus channels of

real-time hardware, you have to specify the hardware access for the bus access
request of the cluster.

Basics For basic information, refer to Specifying the Hardware Access on page 157.

Overview of the required Specifying the hardware access comprises the following steps:
steps § Assign a suitable bus function block (CAN, LIN) to a bus access request.
§ Assign a suitable hardware resource to the bus function block (CAN, LIN).

Preconditions § A bus configuration with assigned communication matrix elements is available

in the active ConfigurationDesk application.
§ At least one hardware resource providing bus channels, e.g., the DS2671 Bus
Board, is available in the hardware topology.
For basic information on managing the real-time hardware
in ConfigurationDesk, refer to Managing Real-Time Hardware
(ConfigurationDesk Real-Time Implementation Guide ).

Possible methods There are three methods to specify the hardware accesses:
§ Assign suitable bus function blocks (CAN, LIN) to bus access requests
automatically. Refer to Method 1 on page 344.
In this case, the Bus Manager assigns new and/or existing bus function blocks
to the relevant bus access requests that are not assigned to a bus function
block yet. For details, refer to Assigning bus access requests to bus accesses
automatically on page 159.
§ Use a new bus function block (CAN, LIN). Refer to Method 2 on page 347.
§ Use an existing bus function block (CAN, LIN). Refer to Method 3 on
page 348.
Using an existing bus function block might be useful if one cluster is
represented by two or more bus access requests. For details, refer to Assigning
multiple bus access requests to one bus access on page 160.

Method 1 To specify the hardware access by assigning bus function blocks

automatically
1 Switch to the Buses view set if necessary.
2 On the Home ribbon, click Windows - Bus Access Requests to open the
Bus Access Requests table.

344
ConfigurationDesk Bus Manager Implementation Guide May 2024
 How to Specify the Hardware Access

3 Assign bus function blocks (CAN, LIN) to bus access requests automatically
in one of the following ways:
§ To assign bus function blocks to all the bus access requests of the active

ConfigurationDesk application in one step, click on the Home ribbon.

§ To assign bus function blocks to specific bus access requests automatically,
select the Bus Access Requests table. In the table, right-click the Bus
Access Requests node of a bus configuration or one of its lower-level
nodes and select Automatic Bus Access Assignment on the context
menu.

In this case, the Bus Manager assigns bus function blocks either to all
the lower-level bus access requests of the selected node or only to the
selected bus access request.
The Bus Manager assigns new and/or existing suitable bus function blocks
(CAN, LIN) to the relevant bus access requests that are not assigned to
a bus function block yet. Bus access requests resulting from the same
communication cluster are assigned to the same bus function block. Bus
access requests are not assigned to a bus function block if two or more
suitable bus function blocks with ambiguous names exist in the signal chain.
The Bus Access Requests table displays the assigned bus function blocks
below each related bus access request.

345
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Implementing Bus Communication in the Signal Chain Using the Bus Manager

4 Select a bus function block in the Bus Access Requests table.

5 Check the properties of the bus function block in the Properties Browser:
§ On the General page, check that the settings specified for properties of
the bus function block and the bus access requests match. If required,
adapt configurable properties or change the bus access assignment.

Tip

§ The Conflicts Viewer can support you by resolving conflicts

related to mismatching settings.
§ Conflicts related to mismatching settings of bus access requests
and the assigned bus accesses are assigned to the Function
context set.

§ On the Electrical Interface page, check the assigned hardware resource.

If not already done, assign a hardware resource via the Hardware
Assignment properties.

By assigning the hardware resource, you select the bus channels that will
be used for the bus communication of the related cluster.

Tip

You can also assign a hardware resource by dragging a suitable

hardware resource from the Hardware Resource Browser to the
bus function block in the Bus Access Requests table.

6 Repeat the steps 4 and 5 for all bus function blocks that are assigned to a
bus access request.

346
ConfigurationDesk Bus Manager Implementation Guide May 2024
 How to Specify the Hardware Access

Method 2 To specify the hardware access by using a new bus function block
1 Switch to the Buses view set if necessary.
2 On the Home ribbon, click Windows - Bus Access Requests to open the
Bus Access Requests table.
3 In the Bus Access Requests table, expand the Bus Access Requests node
down to the communication cluster node or to a bus access requests node
of the Simulated ECUs, Inspection, Manipulation, or Gateways part for
which you want to specify the hardware access.
4 Right-click the required node and select Bus Access Assignment - Create
and Assign Suitable Access on the context menu.

Tip

You can also assign a new bus function block by dragging a suitable
bus function block type from the Function Browser to the required
node.

The Bus Manager adds a new suitable bus function block to the signal chain.
The bus function block is either assigned to all the bus access requests of
the selected communication cluster, or only to the selected Simulated ECUs,
Inspection, Manipulation, or Gateways bus access request node. For each
bus access request, the Bus Access Requests table and the Properties
Browser display the assigned bus function block. The bus function block
is named according to the related cluster, and default settings such as the
baud rate are taken from the communication matrix.

Tip

If a bus function block was previously assigned to an affected bus

access request, the function block is replaced by the newly assigned bus
function block.

5 In the Bus Access Requests table, select the bus function block.

347
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Implementing Bus Communication in the Signal Chain Using the Bus Manager

6 On the Electrical Interface page of the Properties Browser, assign the

hardware resource via the Hardware Assignment properties.

By assigning the hardware resource, you select the bus channels that will be
used for the bus communication of the related cluster.

Tip

§ You can also assign a hardware resource by dragging a suitable

hardware resource from the Hardware Resource Browser to the
bus function block in the Bus Access Requests table.
§ The General page of the Properties Browser displays the bus access
requests that are assigned to the bus function block.

Method 3 To specify the hardware access by using an existing bus function block
1 Switch to the Buses view set if necessary.
2 On the Home ribbon, click Windows - Bus Access Requests to open the
Bus Access Requests table.
3 In the Bus Access Requests table, expand the Bus Access Requests node
down to the communication cluster node or to a bus access requests node
of the Simulated ECUs, Inspection, Manipulation, or Gateways part for
which you want to specify the hardware access.

4 Right-click the required node and select the suitable command on the
context menu:
§ Select Bus Access Assignment - First Fit to have the Bus Manager select
the first suitable existing bus function block that is located in the Global
working view.

348
ConfigurationDesk Bus Manager Implementation Guide May 2024
 How to Specify the Hardware Access

§ Select Bus Access Assignment - Assignable Accesses - <function block

name> to select a specific existing bus function block manually.

Tip

You can also assign a specific existing bus function block by dragging
the bus function block from the Function Browser to the required
node.

The selected bus function block is either assigned to all the bus access
requests of the selected communication cluster, or only to the selected
Simulated ECUs, Inspection, Manipulation, or Gateways bus access
request node. The bus function block is assigned regardless of whether it
is already being used by other bus access requests. When you select the bus
function block, the General page of the Properties Browser displays the
bus access requests that are assigned to the block.

349
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Implementing Bus Communication in the Signal Chain Using the Bus Manager

Tip

If a bus function block was previously assigned to an affected bus

access request, the function block is replaced by the newly assigned bus
function block.

5 Make sure that the settings of the bus function block and the bus access
requests match.

Tip

§ The Conflicts Viewer can support you by resolving conflicts related

to mismatching settings.
§ Conflicts related to mismatching settings of bus access requests and
the assigned bus accesses are assigned to the Function context set.

6 If not already done, assign the hardware resource via the bus function
block's Hardware Assignment properties (located on the Electrical
Interface page of the Properties Browser).

Tip

You can also assign a hardware resource by dragging a suitable

hardware resource from the Hardware Resource Browser to the bus
function block in the Bus Access Requests table.

Result You specified the hardware access for bus access requests.

Note

When you use a bus function block (CAN, LIN) to specify the hardware
access for a bus access request, do not map the Configuration function
port of the bus function block to a model port. To exchange configuration
data, the function block and the bus access request are internally
connected. This connection is not visualized by a mapping line.

Next steps § If you used an existing bus function block for the bus access, conflicts might
occur. You have to resolve the conflicts before you can build a real-time
application for the bus configuration. For details, refer to Basics on Bus
Manager-Related Conflicts on page 163.
§ If required, you can configure the bus communication of the bus
configurations. To do so, you can add bus configuration features, specify user-
defined settings for communication matrix elements, or configure properties
of the used bus systems via the bus function blocks. For overviews of the
configurable elements, refer to:
§ Basics on Bus Configuration Features on page 192
§ Basics on Modifying Communication Matrices on page 391

350
ConfigurationDesk Bus Manager Implementation Guide May 2024
 How to Enable Model Access for Function Ports

§ Configuring CAN Bus Properties in CAN Function Blocks on page 361

§ Configuring LIN Bus Properties in LIN Function Blocks on page 362

How to Enable Model Access for Function Ports

Objective To exchange data between bus configurations and a behavior model (e.g., to
use dynamic signal values during run time), you have to enable model access for
function ports .

Precondition § Communication matrix elements are assigned to a bus configuration.

§ Bus configuration features that provide function ports are added to the bus
configuration.
For more information on bus configuration features, refer to Basics on Bus
Configuration Features on page 192.

Method To enable model access for function ports

1 Switch to the Buses view set if necessary.
2 Open the Bus Configuration Ports table.
The table displays all ports of all the bus configurations of the active
application.
3 Select one or multiple function ports whose model access you want to
enable.

Tip

You can use the Ctrl and Shift keys for multiselection.

4 Enable the model access:

§ If you selected one function port, select Enabled from the Model Access
column.

§ If you selected multiple function ports, right-click the Model Access

column of a selected function port and select Fill with one of - Enabled
on the context menu.

351
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Implementing Bus Communication in the Signal Chain Using the Bus Manager

You enabled model access for the selected function ports.

Tip

You can also enable model access for each function port in the
Properties Browser.

Result You enabled model access for the selected function ports. In working views,
the function ports are displayed for the Bus Configuration function blocks.
Enabling model access allows you to map model ports to the function ports and
to exchange dynamic signal values with the behavior model.

Next steps You can now map the function ports to model ports:
§ If model port blocks are already available in the ConfigurationDesk application,
you can manually map them to the function ports. For an example, refer to
Example of Mapping Model Ports to Bus Configuration Ports via Tables on
page 358. For basic information on model port mapping, refer to Model Port
Mapping (ConfigurationDesk Real-Time Implementation Guide ).
§ If you already have a suitable behavior model but it is not available in the
ConfigurationDesk application yet, add the model to the ConfigurationDesk
application. When you do this, model port blocks are available in the Model
Browser. You can then map the function ports to the available model ports.
Refer to How to Add Behavior Models to a ConfigurationDesk Application on
page 352.
§ If you do not have a suitable behavior model yet but MATLAB®/Simulink®
and Model Interface Package for Simulink are installed, you can generate
the required model port blocks for ConfigurationDesk and a MATLAB/Simulink
model. For more information, refer to Working with Simulink Behavior Models
(ConfigurationDesk Real-Time Implementation Guide ).

Related topics Basics

Configuring Function Ports for Bus Configuration Features..................................................... 198

How to Add Behavior Models to a ConfigurationDesk Application

Objective To exchange data between ConfigurationDesk and a behavior model,

ConfigurationDesk requires information on the behavior model. Therefore, you
have to add the behavior model to the ConfigurationDesk application.

352
ConfigurationDesk Bus Manager Implementation Guide May 2024
 How to Add Behavior Models to a ConfigurationDesk Application

Preconditions § A ConfigurationDesk project with an application is open.

§ A behavior model exists.

Note

If you want to generate bus simulation containers later on, the behavior
model must be a Simulink® implementation container (SIC file). For more
information, refer to Basics on Bus Simulation Containers (BSC Files) on
page 373.

Method To add a behavior model to a ConfigurationDesk application

1 Select the Model Browser.

2 Right-click in the Model Browser and select Import - Add Model on the
context menu.
The Add Model dialog opens.
3 In the Add Model dialog, click Add model.

353
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Implementing Bus Communication in the Signal Chain Using the Bus Manager

4 Select your behavior model:

§ If it is displayed in the Models open in Simulink list, select it in the list.
§ If it is not displayed, click Add model from file to open a standard Open
dialog and select your behavior model (e.g., *.mdl, *.slx, *.sic, or *.fmu)
from the file system.
The selected behavior model is displayed in the Add Model dialog.

Note

If you want to generate bus simulation container (BSC) files later on,
ensure that Create one preconfigured application process for each
model is selected from the Application Process Options list. For more
information, refer to Basics on Bus Simulation Containers (BSC Files) on
page 373.

5 Click OK.
The dialog closes and the Model Browser displays the analyzed model
topology. The following illustration is an example of a Simulink model that
was generated for a bus configuration named 'Bus Configuration (1)'.

Result You added a behavior model to the application.

If the behavior model and the signal chain contain model port blocks
whose identities match, these model port blocks of the signal chain become
resolved. For more information, refer to Basics of Connecting ConfigurationDesk
and Simulink Behavior Models (ConfigurationDesk Real-Time Implementation
Guide ).

For basic information on handling the model interface, refer to Basics on the
Model Interface (ConfigurationDesk Real-Time Implementation Guide ).

354
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Example of Selecting Multiple Similar Communication Matrix Elements at Once

Next steps If function ports of bus configurations are not mapped to model ports yet, you
can now map them. For an example, refer to Example of Mapping Model Ports
to Bus Configuration Ports via Tables on page 358.

Related topics References

Add Model (ConfigurationDesk User Interface Reference )

Example of Selecting Multiple Similar Communication Matrix Elements at

Once

Introduction You can easily select multiple similar communication matrix elements in the
Buses Browser by using filters and the Select Elements by Type or Select
Elements by Direction command. This is useful, for example, if you want to
assign multiple similar communication matrix elements to a bus configuration.

Tip

If you want to perform a restbus simulation , you can select all PDUs
that are involved in the communication of specific ECUs or network
nodes in one step. Refer to Creating Restbus Configurations on
page 121.

355
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Implementing Bus Communication in the Signal Chain Using the Bus Manager

This example shows you how to select multiple similar LIN elements that are
displayed in the Buses Browser at once.

Tip

The example is based on the BusManagerBasicsDemo.arxml

communication matrix, which is available in the BusManagerBasicsDemo
folder of your Documents folder .

Method To select multiple similar communication matrix elements at once

1 Add the BusManagerBasicsDemo.arxml communication matrix to your
ConfigurationDesk application. Refer to How to Add Communication
Matrices to a ConfigurationDesk Application on page 335.
2 In the Buses Browser, select the Communication Matrices by Clusters
view.
3 Right-click the Name column and select Set Column Filter on the context
menu.
A dialog opens for you to specify the column filter.
4 In the dialog, specify door as the Filter expression.

356
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Example of Selecting Multiple Similar Communication Matrix Elements at Once

5 Make sure that only Regular expression is selected.

6 Click OK.
The dialog closes and the Name column is filtered for all elements whose
name contains door. A blue square in the column header indicates that a
filter is active.

7 Choose one of the following alternatives to select similar LIN elements at

once:
§ To select all LIN ISignal IPDUs at once, right‑click the LIN node and select
Select Elements by Type - ISignal IPDU on the context menu.
§ To select all LIN TX PDUs at once, right‑click the LIN node and select
Select Elements by Direction - TX PDUs on the context menu.
The related elements are selected and highlighted. The following illustration
is an example of the elements that were selected by using the Select
Elements by Direction command.

357
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Implementing Bus Communication in the Signal Chain Using the Bus Manager

8 Right-click the Name column and select Clear Column filter on the context
menu.
The column filter is cleared and all elements of the communication matrix
are displayed. The selected elements are still highlighted.

Result You selected similar LIN elements that were displayed in the Buses Browser at
once by using a filter and the Select Elements by Type or Select Elements by
Direction command. Elements that were not displayed in the Buses Browser
because of the active filter were not selected.

Next steps You can now assign the selected elements to a bus configuration in the Bus
Configurations table. Refer to How to Assign Communication Matrix Elements
to a Bus Configuration on page 340.

Example of Mapping Model Ports to Bus Configuration Ports via Tables

Introduction When a behavior model is available in the Model Browser and you have to map
model ports to bus configuration ports manually, you can map the ports in a
working view or via the following tables:
§ Bus Configurations table
§ Bus Configuration Ports table

358
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Example of Mapping Model Ports to Bus Configuration Ports via Tables

Mapping model ports to bus configuration ports via tables is often more
convenient because the tables provide a better overview of the available ports
than a working view. Additionally, the Model Browser and the tables provide
various column and port filter options that reduce the number of the displayed
ports.

In the following example, model ports are mapped to bus configuration function
ports via the Bus Configuration Ports table and by using some of the available
filter options.

Preconditions § A behavior model providing at least one unmapped model outport is available
in the Model Browser.
§ At least one bus configuration provides an unmapped function inport.

Method To map model ports to bus configuration ports via tables

1 Switch to the Buses view set if necessary.
2 In the Model Browser, right-click in an empty area and select the following
filters on the context menu:
§ Filter for Unconnected Ports
§ Filter for Outports
The selected filters are active. The Model Browser displays all the model
outports that are not mapped to function ports.

Tip

Active port filters are indicated by check marks on the context menu.

3 Open the Bus Configuration Ports table.

4 In the Bus Configuration Ports table, right-click in an empty area and
select the following filters on the context menu:
§ Filter for Unconnected Ports
§ Filter for Inports
The Bus Configuration Ports table displays all the function inports that are
not mapped to model ports.

359
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Implementing Bus Communication in the Signal Chain Using the Bus Manager

5 To map a model port to a function port, drag the model port from the
Model Browser to a function port in the Bus Configuration Ports table.

Tip

If you drag a model port to a function port with disabled model access,
model access is automatically enabled for this function port.

The model port is mapped to the function port. Because Filter for
Unconnected Ports is still active in the Model Browser and the Bus
Configuration Ports table, none of the ports are displayed.

Note

Selected port filters are active until you deactivate them explicitly. Active
port filters are indicated only on the context menu and neither in the
Model Browser or Bus Configuration Ports table, nor on the Home
ribbon. However, when you select a browser or table with at least one
active filter, Clear All Filters is enabled, e.g., on the Home ribbon.

6 On the context menus of the Model Browser and Bus Configuration

Ports table, clear Filter for Unconnected Ports.
The Model Browser and Bus Configuration Ports table display the
mapped ports. The Connected Model Ports column of the Bus
Configuration Ports table displays the model ports that are mapped to
function ports.

Tip

If you mapped a model port to a function port by mistake, you can

undo the mapping (e.g., via Ctrl+Z).

7 Repeat the steps above to map further model ports to bus configuration
ports. If required, change the selected filter options, sort the displayed
columns, or specify column filters, for example.

Result You mapped model ports to bus configuration ports via the Bus Configuration
Ports table by using some of the available filter options.

Next steps You can inspect the mapping states of the specified mappings in a working view
(e.g., to identify conflicting mappings). For an overview of the available mapping
states, refer to Mapping States and Their Effects (ConfigurationDesk Real-Time
Implementation Guide ). If required, you can remove mappings by deleting
mapping lines in the working view.

360
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Configuring CAN Bus Properties in CAN Function Blocks

Tip

You can neither inspect the mapping states nor remove mappings in the
Bus Configurations or Bus Configuration Ports table.

Configuring CAN Bus Properties in CAN Function Blocks

Introduction You can configure various CAN bus properties in CAN function blocks.

Tip

You can also configure CAN bus properties via bus configuration features or
by specifying user-defined settings for communication matrix elements. For
overviews, refer to:
§ Basics on Bus Configuration Features on page 192
§ Basics on Modifying Communication Matrices on page 391

CAN bus properties in CAN You can configure the following CAN bus properties in CAN function blocks:
function blocks § Transceiver type
§ Baud rate
§ Sample point
§ CAN FD support, including the baud rate and sample point for the data phase
of CAN FD frames
§ Frame transmission gap
§ Termination
§ Feedthrough mode
§ Low-power mode
§ Power wake-up
§ Partial networking mode
§ Bus statistics

Moreover, the CAN function block lets you do the following:

§ You can virtualize CAN controllers on SCALEXIO, MicroAutoBox III, and
MicroLabBox II systems.
§ You can enable data streaming functionalities.
§ You can select whether the baud rates and sample points are configured in the
CAN function block or provided by a mapped behavior model.

For more information on the CAN function block, refer to CAN

(ConfigurationDesk I/O Function Implementation Guide ).

361
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Implementing Bus Communication in the Signal Chain Using the Bus Manager

Configuring LIN Bus Properties in LIN Function Blocks

Introduction You can configure various LIN bus properties in LIN function blocks.

Tip

You can also configure LIN bus properties via bus configuration features or
by specifying user-defined settings for communication matrix elements. For
overviews, refer to:
§ Basics on Bus Configuration Features on page 192
§ Basics on Modifying Communication Matrices on page 391

LIN bus properties in LIN You can configure the following LIN bus properties in LIN function blocks:
function blocks § Transceiver type
§ Baud rate
§ Termination
§ Power wake-up

For more information on the LIN function block, refer to LIN (ConfigurationDesk
I/O Function Implementation Guide ).

362
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Tasks, Events, and Runnable Functions Provided by the Bus Manager

Tasks, Events, and Runnable Functions Provided by

the Bus Manager

Where to go from here Information in this section

Basics on Tasks, Events, and Runnable Functions Provided by the

Bus Manager......................................................................................... 363

Fetch and Deliver Runnable Functions for Receiving and

Transmitting PDUs................................................................................. 366

Changing the Assignment of Fetch and Deliver Runnable

Functions............................................................................................... 368

Basics on Tasks, Events, and Runnable Functions Provided by the Bus

Manager

Introduction When you configure bus communication with the Bus Manager, the tasks ,
events , and runnable functions that are required to trigger the bus
communication at run time are created and configured automatically.

The preconfigured settings are sufficient in most use scenarios so that you do
not have to make any manual changes. However, you can change some of the
preconfigured settings if required.

363
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Tasks, Events, and Runnable Functions Provided by the Bus Manager

Overview The following table provides an overview of the tasks, events, and runnable
functions that can be created automatically.

Name Type Created for/Assigned to …

Bus Configuration Periodic task Created for each bus configuration that is added to the
ConfigurationDesk application.
BusCfg_MainFunctionFetch [<bus Runnable function Automatically assigned to the Bus Configuration task of each
configuration name>] bus configuration.
BusCfg_MainFunctionDeliver [<bus Runnable function Automatically assigned to the Bus Configuration task of each
configuration name>] bus configuration.
Timer Event Timer event Automatically assigned to the Bus Configuration task of each
bus configuration.
Transmit [<frame name>, <frame Asynchronous task Created for each LIN TX frame that is assigned to the
triggering ID>] Simulated ECUs part of a bus configuration.
Send Response Runnable function Automatically assigned to each Transmit [<frame name>,
<frame triggering ID>] task.
Header Received I/O event Automatically assigned to each Transmit [<frame name>,
<frame triggering ID>] task.

Tip

§ The BusCfg_MainFunctionFetch [<bus configuration name>]

and BusCfg_MainFunctionDeliver [<bus configuration name>]
runnable functions are the main elements for receiving and transmitting
PDUs. Refer to Fetch and Deliver Runnable Functions for Receiving and
Transmitting PDUs on page 366.
§ Bus Configuration function blocks do not provide event ports for
Header Received I/O events. If you create model port blocks for bus
configurations, no Runnable Function blocks are created for these I/O
events.

The following illustration is an example of the different tasks, events, and

runnable functions available for a bus configuration.

The tasks that are available for a bus configuration are grouped by task groups
as follows:
§ All tasks of a bus configuration are grouped by a task group that is named
after the bus configuration, e.g., 'Bus Configuration (1)'.
§ All Transmit [<frame name>, <frame triggering ID>] tasks of a bus
configuration are additionally hierarchically grouped by three task groups. The

364
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Basics on Tasks, Events, and Runnable Functions Provided by the Bus Manager

names of these task groups are derived from higher-level elements of the
related LIN TX frame as follows:

Level of Task Task Group Name Derived from ...

Group
First Communication matrix node in the bus configuration, e.g.,
'BusManagerBasicsComMatrix'
Second Transmitting ECU, e.g., 'BodyControlEcu'
Third LIN cluster, e.g., 'LinDoorCluster'

Overview of the The tasks, events, and runnable functions that are automatically generated when
preconfigured settings you configure bus communication with the Bus Manager provide the following
preconfigured settings:
§ The priority of each Bus Configuration task is specified. If required, you can
change the preconfigured priority. The higher the numerical value, the lower
the priority of the task.
§ The Transmit [<frame name>, <frame triggering ID>] tasks inherit the
priority of their related <LIN cluster name> task group. If required, you can
change the preconfigured priority of the task group.
§ The assignment of events and runnable functions to Bus Configuration
tasks takes place automatically when you add bus configurations to the
ConfigurationDesk application.
§ You can assign the runnable functions of a Bus Configuration task to
another periodic task. Changing the assignment can optimize the data
processing, for example, between a bus configuration and a mapped
behavior model. Refer to Changing the Assignment of Fetch and Deliver
Runnable Functions on page 368.
§ You can replace the timer event of a Bus Configuration task with a
synchronized timer event. When you do this, you can trigger the task
synchronously to a global time. Refer to Transmitting Bus Communication
of Bus Configurations Synchronously to a Global Time on page 185.
§ For the timer event of each Bus Configuration task, a period of 1 ms is
specified. If required, you can change the preconfigured period. You can also
specify an offset for the event.

You can also configure further settings for tasks via their configurable properties.
For more information, refer to Configuring Tasks in ConfigurationDesk
(ConfigurationDesk Real-Time Implementation Guide ).

However, some limitations apply for configuring task, events, and runnable
functions. Refer to Limitations for Bus Configuration Handling on page 531.

Events provided by the PDU When you add the PDU RX Interrupt feature to a CAN RX PDU, an I/O event is
RX Interrupt feature generated each time the PDU is received on the bus. For this I/O event, the bus
configuration provides an event port. To use the I/O event at run time, you have
to map the event port to a runnable function port of a behavior model. When
you do this, an asynchronous task is created and the I/O event and runnable
function are assigned to this task. This task is not included in the task group of
the bus configuration.

365
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Tasks, Events, and Runnable Functions Provided by the Bus Manager

For more information on the PDU RX Interrupt feature, refer to Triggering the
Execution of Functions in a Behavior Model via RX Interrupts on page 281.

Tasks, events, and runnable When you assign a CAN function block to a bus access request of a bus
functions of CAN function configuration, the CAN function block provides an asynchronous task with an
blocks assigned I/O event and a runnable function. The default name of the task is
CAN RX Task (<number>). If you use the PDU RX Interrupt feature, the task is
required to ensure that CAN messages are received by the real-time application
with a low latency. For this purpose, the task requires a high priority. Therefore,
the default priority of the task is 0, which is the highest priority.

Note

§ To ensure optimum run-time behavior, do not change the default priority.

§ To ensure that the bus configuration provides only current data (e.g., to
a mapped behavior model), all other tasks of the bus configuration must
have a lower priority. A lower priority means a higher numerical value.

For more information on bus access requests, refer to Basics on Bus Access
Requests on page 155.

Further information For more information on tasks, events, runnable functions, and their effects
on executable applications, refer to Modeling Executable Applications and Tasks
(ConfigurationDesk Real-Time Implementation Guide ).

Fetch and Deliver Runnable Functions for Receiving and Transmitting PDUs

Introduction The BusCfg_MainFunctionFetch [<bus configuration name>] and

BusCfg_MainFunctionDeliver [<bus configuration name>] runnable
functions of a bus configuration are the main elements for receiving and
transmitting PDUs that are assigned to the bus configuration.

Execution in periodic task The fetch and deliver runnable functions are executed in a periodic task. The task
calls the runnable functions when it is triggered by its timer event. The period

366
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Fetch and Deliver Runnable Functions for Receiving and Transmitting PDUs

and offset that are specified for the timer event determine the interval in which
the task is triggered.

Timer event

triggers according to period and offset

Periodic task

calls

BusCfg_MainFunctionFetch [<bus configuration name>]

BusCfg_MainFunctionDeliver [<bus configuration name>]

By default, the runnable functions are executed in the periodic Bus

Configuration [<bus configuration name>] task of the related bus
configuration. If required, you can assign the runnable functions to any other
unlocked periodic task of the same application process to have them executed
in this task.
§ For information on the Bus Configuration [<bus configuration name>]
task, refer to Basics on Tasks, Events, and Runnable Functions Provided by the
Bus Manager on page 363.
§ For information on changing the assignment, refer to Changing the
Assignment of Fetch and Deliver Runnable Functions on page 368.

Fetch runnable function for The BusCfg_MainFunctionFetch [<bus configuration name>] runnable
receiving PDUs function is responsible for receiving PDUs. Each time the runnable function is
executed, the data of the RX PDUs that are assigned to the Simulated ECUs and
Inspection parts of the related bus configuration is updated with the data that is
received on the bus.

Deliver runnable function for The BusCfg_MainFunctionDeliver [<bus configuration name>] runnable
transmitting PDUs function is responsible for transmitting PDUs that are assigned to the Simulated
ECUs part of a bus configuration.

Tip

The runnable function is not responsible for transmitting PDUs that

are assigned to the Manipulation part of a bus configuration. This is
because PDUs that are assigned to the Manipulation part are not actively
transmitted by this part.
For example, a PDU is assigned to the Simulated ECUs part and to the
Manipulation part. In this case, the PDU is transmitted according to
its configuration in the Simulated ECUs part. When a bus manipulation
feature is enabled at run time, it applies to the PDU immediately before it is
transmitted on the bus.
For more information, refer to Use Scenarios for Manipulating Bus
Communication on page 34.

Timing aspects for transmitting PDUs Each time the

BusCfg_MainFunctionDeliver [<bus configuration name>] runnable
function is executed, a PDU that is assigned to the Simulated ECUs part can

367
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Tasks, Events, and Runnable Functions Provided by the Bus Manager

be transmitted once. The timing of the actual transmission depends on the

following process steps:

Step Description
1 The transmission of a PDU is triggered, for example:
§ According to cyclic or event‑controlled timings that are specified in the communication matrix.
§ By a behavior model or experiment software, e.g., according to the PDU Trigger bus configuration feature.
2 The BusCfg_MainFunctionDeliver [<bus configuration name>] runnable function is called by the task to which it is
assigned. Now, the trigger for transmitting the PDU is evaluated and the required data is written to the PDU, such as ISignal
values, counter signal values, end-to-end protection information, etc.
There might be a delay between the trigger for transmitting the PDU and its evaluation by the deliver runnable function, for
example, due to the priority of the related task or an offset that is specified for the related timer event.
3 The PDU can be transmitted according to the specifications in the related communication matrix.
Depending on these specifications, the transmission might be delayed or the PDU is not transmitted at all, as shown in the
following examples:
§ The PDU is a contained IPDU and the transmission of its related container IPDU is not triggered yet.
§ The PDU has a LIN frame triggering and the transmission of the related LIN frame is not scheduled by the LIN master.

Tip

You can additionally prohibit the transmission of the PDU by using bus configuration features, such as the Bus
Configuration Enable, Communication Controller Enable, or PDU Enable feature.

Observing the bus load Moreover, the Bus Manager observes the bus
load when the BusCfg_MainFunctionDeliver [<bus configuration name>]
runnable function is executed:
§ If the transmission of too many PDUs is triggered in one sampling step, the
transmission of those PDUs that cannot be transmitted in the current sampling
step is shifted to the next sampling step.
§ To continuously optimize the bus load, subsequent timings such as cyclic
timings are calculated from the point in time when a PDU was actually
transmitted, not from the point in time when the transmission was initially
triggered. However, this applies only if the default timer event is used. With
a synchronized timer event, this behavior differs. Refer to Transmitting Bus
Communication of Bus Configurations Synchronously to a Global Time on
page 185.

For transmitting PDUs that are assigned to the Simulated ECUs part of a bus
configuration, some limitations apply. Refer to Limitations for Bus Configuration
Handling on page 531.

Changing the Assignment of Fetch and Deliver Runnable Functions

Introduction You can change the assignment of the BusCfg_MainFunctionFetch

[<bus configuration name>] and BusCfg_MainFunctionDeliver [<bus
configuration name>] runnable functions to a task. For example, this can
be useful if you work with a behavior model and you want to optimize the data
processing between bus configurations and the model.

368
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Changing the Assignment of Fetch and Deliver Runnable Functions

Optimizing the data By default, the runnable functions that are provided by bus configurations and
processing when working behavior models are executed in different tasks. In some cases, this might result
with a behavior model in unfavorable data processing, e.g., concerning the timing behavior. To improve
the data processing, you can assign the runnable functions to the same task, as
shown in the following example.

Default Configuration Optimized Configuration

Sampling step 1 Sampling step 2 Sampling step 1

Model task Periodic task

BusConfig1
Model RF Deliver RF
provide provide
calculated transmit
calculated
results to calculated
results to
BusConfig1 results on
BusConfig1
bus
BusConfig1 Model RF
Deliver RF
provide
provide received transmit received
data to model calculated data to
results on bus model
BusConfig1 BusConfig1
Fetch RF Fetch RF

receive data receive data

BusConfig1 task from bus from bus

Execution
Execution
Bus order
Bus
order
Time
Time

The data of the model is provided to the bus configuration after the The data of the model is provided to the bus
respective deliver runnable function was called. Thus, the transmission of configuration before the respective deliver runnable
the data is shifted to the next sampling step. function is called. Thus, the data is transmitted in
the current sampling step.

Changing the assignment You can assign the fetch and deliver runnable functions of a bus configuration
to any unlocked periodic task that is assigned to the same application process .
You can change the assignment of the runnable functions in the Task
Configuration table, which is available in the Tasks view set:

§ To remove the runnable functions from a Bus Configuration task, select the
task and clear the checkboxes of the Assigned runnable function property.

§ To assign the runnable functions to a periodic task, select the related task
and select the respective checkboxes of the Assigned runnable function
property.

369
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Tasks, Events, and Runnable Functions Provided by the Bus Manager

Tip

Alternatively, you can change the assignment in the following ways:

§ In the Executable Application table by dragging the runnable functions
from the Bus Configuration task to another task.
§ Using the Assign Runnable Function context menu command of tasks.

Points to note when changing To ensure correct run‑time behavior, note the following points when you change
the assignment the assignment of fetch and deliver runnable functions:

Aspects Description
Assignment to the It is recommended that you assign the fetch and deliver runnable functions of one bus configuration to the
same task same periodic task.
If you assign the runnable functions to different tasks, you must ensure that the related timer events specify
the same period.
Execution order Ensure that the execution order of the runnable functions matches your requirements. In most use
scenarios, it is required that the fetch runnable function is executed before its related deliver runnable
function.
You can specify the execution order using the Execution Order property of the runnable functions.

Tip

In the Executable Application table, you can specify the execution order by changing the order of
the runnable functions in the task using drag & drop.

370
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Changing the Assignment of Fetch and Deliver Runnable Functions

Aspects Description
Default settings of When you change the assignment of the fetch and deliver runnable functions, check whether the
the task and its timer default settings of the task, e.g., its priority, and of the related timer event, e.g., its period, match your
event requirements.
Remaining Bus You cannot delete a Bus Configuration task. However, when you remove the fetch and deliver runnable
Configuration task functions from the task, the task is ignored when you build a real‑time application or generate bus
simulation containers.

371
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Tasks, Events, and Runnable Functions Provided by the Bus Manager

372
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Generating Bus Simulation Containers

Generating Bus Simulation Containers

Where to go from here Information in this section

Basics on Bus Simulation Containers (BSC Files)..................................... 373

Port Interface of Bus Simulation Containers........................................... 377

How to Generate Bus Simulation Containers......................................... 379

How to Assign Behavior Models to Separate Application Processes........ 381

Basics on Bus Simulation Containers (BSC Files)

Introduction The Bus Manager lets you generate bus simulation containers (BSC files). Bus
simulation containers contain bus communication configured with the Bus
Manager and let you use it independently from the Bus Manager on various
dSPACE simulation platforms.

Fields of application for bus The main fields of application for bus simulation containers are:
simulation containers § Implementing bus communication in offline simulation applications
You can import bus simulation containers to VEOS . VEOS lets you assign the
bus communication to different communication clusters and implement it in
an offline simulation application to perform sIL simulation .
§ Implementing bus communication in real-time applications
You can add bus simulation containers as a model implementation to
ConfigurationDesk applications. ConfigurationDesk lets you specify the access
to real-time hardware and implement the bus communication in a real-
time application for dSPACE SCALEXIO, MicroAutoBox III, or MicroLabBox II
systems.

373
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Generating Bus Simulation Containers

Tip

§ Because the code related to the bus communication is already included

in the bus simulation container, this code is not generated during
the build process. This reduces the effort for building the real-time
application.
§ If you work with the Bus Manager in ConfigurationDesk, you can
implement bus communication in real-time applications without using
bus simulation containers. Refer to Typical Workflows for Using the Bus
Manager and Building Real-Time Applications on page 43.

§ Implementing bus communication in RTMaps‑based applications

You can use bus simulation containers in RTMaps to implement the bus
communication in an RTMaps‑based application for the AUTERA AutoBox, for
example.

Moreover, bus simulation containers let you handle the configured bus
communication independently of the ConfigurationDesk project. For example,
you can use bus simulation containers for the following:
§ To archive the configured bus communication.
§ To exchange the configured bus communication between different users.

Working with or without To generate bus simulation containers, you can work with or without behavior
behavior models models.

Working with Behavior Models Working Without Behavior Models

If you work with a behavior model, the behavior model must be a Simulink® If you work without a behavior model, you
implementation container (SIC file). have to create application processes and
§ For an overview of a typical workflow, refer to Generating Bus Simulation assign bus configurations to the application
Containers with a Behavior Model on page 53. processes manually.
§ For more information on the required SIC files, refer to Compatible SIC files on For an overview of a typical workflow, refer
page 374. to Generating Bus Simulation Containers
Without a Behavior Model on page 54.
Note

ConfigurationDesk lets you work with multiple behavior models in one

application process. This is not supported for generating bus simulation
containers. If you work with multiple behavior models, you must ensure that
you create a separate application process for each model. For instructions,
refer to How to Add Behavior Models to a ConfigurationDesk Application on
page 352.

Compatible SIC files When you work with behavior models to generate bus simulation containers,
the respective SIC files must be generated with the Model Interface Package for
Simulink . You can use SIC files that were generated with the current Release
of the Model Interface Package for Simulink, or with one of the previous 6
Releases.

374
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Basics on Bus Simulation Containers (BSC Files)

Note

§ In principle, you can also use SIC files that are generated with versions
of the Model Interface Package for Simulink outside the supported range.
However, in this case a conflict and a warning message occur, informing
you that this is not officially supported and that you use the SIC file at
your own risk.
§ When generating SIC files, you have to specify the target architecture.
The specified target architecture must be compatible with the operating
system of your VEOS, SCALEXIO, MicroAutoBox III, or MicroLabBox II
system. Refer to Basics on Simulink Implementation Containers (Model
Interface Package for Simulink - Modeling Guide ).

Generating bus simulation You can generate bus simulation containers via one command. When you
containers start generating bus simulation containers, one BSC file is generated for each
application process that fulfills the following conditions:
§ The application process contains no or only one behavior model. If the
application process contains a behavior model, it must be a Simulink
implementation container.
§ The application process contains at least one bus configuration.

Note

During the generation of bus simulation containers, existing BSC files are
deleted from the Generated Containers folder without notice. If you want
to keep these BSC files, you have to store them in another folder before you
start the generation process.

The generated BSC files contain all the bus configurations that are part of
the related application processes, regardless of whether the bus configurations
are mapped to model ports of Simulink implementation containers. Only bus
configurations for which conflicts exist that abort the code generation are not
included in the BSC files. Refer to How to Generate Bus Simulation Containers
on page 379.

Modifying bus You cannot modify the bus communication that is included in a bus simulation
communication in bus container. If you want to do so (e.g., add ISignals to a bus configuration, specify
simulation containers bus configuration features etc.), you have to modify the bus configurations for
which you generated the bus simulation container. Then, you have to generate a
new bus simulation container.

Availability of bus access Bus access requests are included in the BSC files when you generate bus
requests in bus simulation simulation containers. To access bus channels, you have to assign the bus access
containers requests to bus accesses in VEOS or ConfigurationDesk as follows:

375
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Generating Bus Simulation Containers

Bus access requests in VEOS In VEOS, the bus access requests are available
as communication controllers, as shown in the following example of the VEOS
Player :

To specify the bus access, you have to connect the communication controllers to
communication clusters.

Bus access requests in ConfigurationDesk In ConfigurationDesk,

Configuration Port blocks are available providing Configuration ports:

To specify the bus access, you have to map the Configuration ports to suitable
bus function blocks (CAN, LIN) and assign hardware resources to the bus
function blocks.

Port interface of bus Bus simulation containers provide a port interface that can include model
simulation containers ports of Simulink implementation containers and function ports of bus
configurations. Ports that are included in the port interface can be used in VEOS
and ConfigurationDesk. Refer to Port Interface of Bus Simulation Containers on
page 377.

Precompiling BSC files After you have generated bus simulation containers, you can precompile the
resulting BSC files using the ConfigurationDesk automation interface. Refer to
Creating Precompiled BSC Files (ConfigurationDesk Real-Time Implementation
Guide ).

Using bus communication in For bus communication that is configured via the Bus Manager, the paths of
offline simulation and real- variable descriptions are the same in offline simulation applications and real-time
time applications applications. This lets you, for example, use the same ControlDesk layouts for
offline simulation applications and real-time applications.

376
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Port Interface of Bus Simulation Containers

Limitations for working with When you work with bus simulation containers, some limitations apply. Refer to
bus simulation containers Limitations for Bus Simulation Containers on page 533.

Related topics Basics

Accessing Bus Manager Features via the ConfigurationDesk Automation Interface.................. 152

Port Interface of Bus Simulation Containers

Introduction Bus simulation containers that are generated with the Bus Manager provide
a port interface that can include model ports of Simulink® implementation
containers and function ports of bus configurations. Ports that are included in
the port interface can be used in VEOS and ConfigurationDesk.

In addition to the ports of the port interface, bus simulation containers provide
elements for accessing bus channels when you import BSC files to VEOS or
ConfigurationDesk. Refer to Availability of bus access requests in bus simulation
containers on page 375.

Ports included in the port Model ports and function ports are included in the port interface of bus
interface simulation containers if the following preconditions are fulfilled:

Preconditions for
Model Ports Function Ports
§ The model ports are part of a Simulink implementation container that is § The function ports are part of a bus
assigned to the application process for which a bus simulation container is configuration that is assigned to the application
generated. process for which a bus simulation container is
§ The model ports are not mapped to ports of a bus configuration, i.e., they generated.
are unmapped or mapped to ports of other ConfigurationDesk function § Model access is enabled for the function ports
blocks. but they are not mapped to model ports.

Tip

This applies to data inports , data outports , and runnable function

ports of the Simulink implementation container.

The port interface is not valid for event ports, i.e., event ports of bus
configurations are not included in the port interface, regardless of whether they
are mapped to runnable function ports.

377
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Generating Bus Simulation Containers

Note

For optimum run-time performance, it is recommended to include as few

function ports as possible in the port interface of bus simulation containers,
i.e.:
§ Enable model access only for those bus configuration function ports
whose data you want to exchange with a behavior model.
§ Whenever reasonable, map bus configuration function ports with enabled
model access to suitable model ports before you generate BSC files.

Using ports of the port In VEOS, data inports, data outports, and function ports of the port interface
interface in VEOS are available as signals. For example, you can connect these signals to signals of
different plant models when you configure the bus communication, e.g., in the
VEOS Player.

Note

Runnable function ports are not available in VEOS and the related runnable
functions cannot be executed at run time. If you import a BSC file
that contains runnable function ports to VEOS, warning messages occur
in VEOS.

Using ports of of In ConfigurationDesk, the following model port blocks can be available:
the port interface in § Data port blocks
ConfigurationDesk These blocks are available for the data inports, data outports, and function
ports of the port interface.
§ Runnable Function blocks
These blocks are available for runnable function ports of the port interface.

378
ConfigurationDesk Bus Manager Implementation Guide May 2024
 How to Generate Bus Simulation Containers

You can use the ports in the signal chain and map them to ConfigurationDesk
function blocks or model ports of other behavior models.

Note

Mapping model ports in an unfavorable way might reduce the run-

time performance. For optimum run-time performance, it is therefore
recommended to observe specific mapping rules if you map model ports
of BSC files to model ports of other behavior models. Refer to Model
Communication Recommendations for Model Port Blocks with Structured
Data Ports (ConfigurationDesk Real-Time Implementation Guide ).

How to Generate Bus Simulation Containers

Objective To use the bus communication you configured with the Bus Manager
independently from the Bus Manager, you can generate bus simulation container
(BSC) files.

Basics For basic information, refer to Basics on Bus Simulation Containers (BSC Files) on
page 373.

379
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Generating Bus Simulation Containers

Preconditions § The ConfigurationDesk application you want to generate the BSC files for is
active.
§ Bus communication is configured in one or more bus configurations.
§ If function ports of a bus configuration are mapped to model ports, the model
ports are part of exactly one Simulink® implementation container.
§ A separate application process is available for each Simulink implementation
container and no other model implementations are assigned to the
application process.

Tip

You can check the assignment of Simulink implementation containers to

application processes in the Executable Application table, as shown in
the following example.

If multiple behavior models are assigned to an application process, you

must change the assignment. Refer to How to Assign Behavior Models to
Separate Application Processes on page 381

§ Conflicts of the Generate no code category must not exist for bus
configurations you want to include in the BSC files.
§ Conflicts of the Abort BSC file generation category must not exist for
application processes you want to generate the BSC files for.

Method To generate bus simulation containers

1 Switch to the Buses view set if necessary.

2 On the Home ribbon, click .

Result The generation of BSC files starts and the Message Viewer provides information
on the generation progress. Each available application process is analyzed to
check whether its configuration is valid for generating a BSC file. For each
application process that passes the analysis, one BSC file is generated.

380
ConfigurationDesk Bus Manager Implementation Guide May 2024
 How to Assign Behavior Models to Separate Application Processes

Note

If inconsistencies are detected during BSC file generation, you are informed
about them in the Message Viewer. Due to these inconsistencies, BSC file
generation might abort for the affected application processes.

The generated BSC files are displayed in the Project Manager below the
Generated Containers node of the active application.

Next steps You can import the generated BSC files to VEOS to implement the bus
communication in an offline simulation application. For more information, refer
to Basics on Integrating Bus Simulation Containers (BSCs) (VEOS Manual ).

Related topics Basics

Basics on Bus Manager-Related Conflicts................................................................................ 163

How to Assign Behavior Models to Separate Application Processes

Objective To generate a bus simulation container for an application process, no or exactly

one behavior model must be assigned to the application process. The behavior
model must be a Simulink® implementation container. If two or more behavior
models are assigned to the application process, you must change the assignment
and assign each behavior model to a separate application process before you can
generate bus simulation containers.

Method To assign behavior models to separate application processes

1 Open the Build Configuration table, for example, via Show Panes on the
View ribbon.

381
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Generating Bus Simulation Containers

The Build Configuration table displays the available application processes

and the assigned behavior models, as shown in the following example.

2 Right-click an application process to which multiple behavior models are

assigned and select Delete from Application on the context menu.

The application process is deleted from the ConfigurationDesk application.

3 Repeat step 2 for all application processes to which multiple behavior models
are assigned.
4 Open the Model Browser.
The Model Browser displays the available behavior models. Behavior
models that are assigned to application processes are indicated by a chain
symbol.

5 Right-click a behavior model that is not assigned to an application process

and select Create Preconfigured Application Process - In Existing
Processing Unit Application - <name of processing unit application>
on the context menu.
A new application process is created and the behavior model is assigned to
this application process. The application process is named after the behavior
model. If model ports of the behavior model are mapped to function ports
of a bus configuration, the bus configuration is automatically assigned to the
application process.

382
ConfigurationDesk Bus Manager Implementation Guide May 2024
 How to Assign Behavior Models to Separate Application Processes

6 Repeat step 5 for all behavior models that are not assigned to application
processes.

Note

If function ports of a bus configuration are mapped to model ports of

different behavior models, conflicts occur. You must resolve the conflicts
before you can generate bus simulation containers. To do so, map the
function ports of the bus configuration to only one behavior model.

Result Each behavior model is assigned to a separate application process.

Next step You can now generate bus simulation containers. Refer to How to Generate Bus
Simulation Containers on page 379.

383
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Generating Bus Simulation Containers

384
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Working Without Behavior Models

Working Without Behavior Models

Where to go from here Information in this section

Basics on Working Without Behavior Models......................................... 385

How to Create Application Processes that Provide Default Tasks............. 386

How to Manually Assign Bus Configurations to Application

Processes............................................................................................... 387

Basics on Working Without Behavior Models

Overview To implement bus communication in real-time applications or bus simulation

containers, you can work without behavior models. If you do this, you
have to manually create application processes and tasks, and assign the bus
configurations to the application processes.

Introduction to application Application processes are structuring elements that contain tasks. Tasks are
processes and tasks pieces of code whose execution is controlled by the simulation platform, e.g.,
by the real-time operating system (RTOS). Tasks are required during the execution
of executable applications .

For more information, refer to Modeling Executable Applications and Tasks

(ConfigurationDesk Real-Time Implementation Guide ).

Creating application processes When you work without a behavior model, application processes are not created
when working without a automatically. Instead, you have to manually create application processes that
behavior model provide default tasks. The default tasks are required in addition to the tasks that
are created when you configure bus communication with the Bus Manager.

For each ConfigurationDesk application, you have to create at least one

application process. If you create more application processes, you can assign

385
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working Without Behavior Models

bus configurations to different application processes. When you generate bus

simulation containers, one BSC file is generated for each of these application
processes. However, if you build a real-time application later on, the number of
application processes is limited by the number of the available processing unit
cores. For more information, refer to Basics on Modeling Executable Applications
(ConfigurationDesk Real-Time Implementation Guide ).

Refer to How to Create Application Processes that Provide Default Tasks on

page 386.

Assigning bus configurations Each bus configuration must be assigned to one application process. When you
to application processes work without a behavior model, you can assign bus configurations to application
processes in the following ways:
§ Specify the access to real-time hardware
When you assign a bus access request of a bus configuration to a bus
access , the bus configuration is automatically assigned to the related
application process.
For information on assigning bus access requests to bus accesses, refer to
Specifying the Hardware Access on page 157. For a graphical overview of the
dependencies between application processes and real-time hardware, refer to
Terms and Definitions for Building Executable Applications (ConfigurationDesk
Real-Time Implementation Guide ).
§ Assign bus configurations to application processes manually.
You can manually assign each bus configuration to an available application
process. This lets you, for example:
§ Assign bus configurations to application processes if you work without real-
time hardware.
§ Change the assignment of a bus configuration to an application process.
If you do this while bus access requests of the bus configuration are
assigned to bus accesses, the related bus function blocks (CAN, LIN) are
assigned to the selected application process automatically. Depending on
the assigned hardware resources, conflicts might occur in this case. Refer to
Basics on Bus Manager-Related Conflicts on page 163.
Refer to How to Manually Assign Bus Configurations to Application Processes
on page 387.

How to Create Application Processes that Provide Default Tasks

Objective To work without a behavior model, you have to manually create application
processes that provide default tasks.

Basics For basic information, refer to Basics on Working Without Behavior Models on
page 385.

386
ConfigurationDesk Bus Manager Implementation Guide May 2024
 How to Manually Assign Bus Configurations to Application Processes

Method To create application processes that provide default tasks

1 Open the Task Configuration table, for example, via Show Panes on the
View ribbon.
2 In the Task Configuration table, right-click an empty area and select New -
Application Process (Providing Default Task) on the context menu.
An application process and a default task are created and displayed in the
Task Configuration table.

Tip

§ If this is the first application process in the ConfigurationDesk

application, bus configurations that have at least one bus access
request assigned to a bus access are automatically assigned to
this application process.
§ You can rename application processes, e.g., in the Name column
of the Task Configuration table. This is especially useful if you
generate bus simulation containers because the generated BSC files
are named after the related application processes.

3 Repeat the step above to create as many application processes as required.

For information on the required number, refer to Basics on Working Without
Behavior Models on page 385.

Result You created application processes that provide default tasks.

Next step You can now assign bus configurations to the created application processes in
one of the following ways:
§ Assign bus access requests of bus configurations to bus accesses. Refer to How
to Specify the Hardware Access on page 344.
§ Assign bus configurations to application processes manually or change
the assignment. Refer to How to Manually Assign Bus Configurations to
Application Processes on page 387.

How to Manually Assign Bus Configurations to Application Processes

Objective To manually assign bus configurations to application processes.

387
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working Without Behavior Models

Basics For basic information, refer to Basics on Working Without Behavior Models on
page 385.

Preconditions An application process is available in the active ConfigurationDesk application.

Method To manually assign bus configurations to application processes

1 Select a bus configuration, for example, in the Bus Configurations table.
2 On the General page of the Properties Browser, select an available
application process from the list of the Manually assigned application
process property.

The bus configuration is assigned to the selected application process.

3 Repeat the steps above to manually assign further bus configurations to
application processes.

Result You manually assigned bus configurations to the selected application processes.
The Assigned application processes property displays all the application
processes the related bus configuration is assigned to.

If the bus configuration is assigned to more than one application process,

conflicts occur. For example, this can happen if the bus configuration is mapped
to a behavior model and the behavior model is assigned to a different application
process. Refer to Basics on Bus Manager-Related Conflicts on page 163.

If bus access requests of the bus configuration are assigned to bus accesses ,
the related bus function blocks (CAN, LIN) are automatically assigned to the
selected application process as well. You can inspect the assignment via the
Executable Application table, for example.

388
ConfigurationDesk Bus Manager Implementation Guide May 2024
 How to Manually Assign Bus Configurations to Application Processes

Tip

§ You can open the Executable Application table via Show Panes on the
View ribbon, for example.
§ In the example above, the CanBodyCluster (1) and LinDoorCluster (1)
function blocks are CAN and LIN function blocks that specify the bus
access for bus access requests of Bus Configuration (1).

Depending on the hardware resources that are assigned to the bus function
blocks, conflicts might occur. For example, this can happen if the bus function
blocks are now connected to multiple processing units due to a changed
application process assignment.

Related topics Basics

Basics on Working Without Behavior Models.......................................................................... 385

389
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working Without Behavior Models

390
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Modifying Communication Matrices

Modifying Communication Matrices

Where to go from here Information in this section

Basics on Modifying Communication Matrices....................................... 391

Adding ISignal IPDUs to CAN Channels.................................................. 396

Adding ISignals to CAN PDUs................................................................ 397

Adding Cyclic Timing Elements to IPDUs................................................ 399

Adding Event‑Controlled Timing Elements to IPDUs............................... 401

Specifying User-Defined PDU Gateways (Preview Version)...................... 404

Configurable Settings of Communication Clusters................................. 408

Configurable Settings of Frames............................................................ 409

Configurable Settings of PDUs............................................................... 414

Configurable Settings of ISignal Groups................................................. 425

Configurable Settings of ISignals........................................................... 427

Basics on Modifying Communication Matrices

Introduction You can modify communication matrices within the active ConfigurationDesk
application. You can add user‑defined elements, specify user‑defined PDU
gateways, and specify user‑defined settings for configurable elements. For
example, this allows you to do the following:
§ Resolve conflicts in the active ConfigurationDesk application that result from
conflicting communication matrix settings.
§ Work with a preliminary version of a communication matrix.

391
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Modifying Communication Matrices

§ Work with the Basic_ComMatrix.arxml communication matrix.

If you do not have a communication matrix, you can use the
Basic_ComMatrix.arxml communication matrix as a starting point: You
can add user-defined elements to the communication matrix and specify user-
defined settings for elements. Then, you can assign these elements to bus
configurations to implement and configure basic CAN communication in the
signal chain.
The Basic_ComMatrix.arxml file is available in the
BusManagerBasicsDemo subfolder of the Documents folder .

Overview Adding user-defined elements You can add the following user-defined
elements to a communication matrix:
§ ISignal IPDUs
Refer to Adding ISignal IPDUs to CAN Channels on page 396.
§ ISignals
Refer to Adding ISignals to CAN PDUs on page 397.
§ Cyclic timings
Refer to Adding Cyclic Timing Elements to IPDUs on page 399.
§ Event‑controlled timings
Refer to Adding Event‑Controlled Timing Elements to IPDUs on page 401.

Specifying user‑defined PDU gateways You can specify user‑defined PDU

gateways to route the data of basic PDUs from one or more communication
clusters to other communication clusters. Refer to Specifying User-Defined PDU
Gateways (Preview Version) on page 404.

Configurable settings of communication matrix elements The following

table provides an overview of the communication matrix elements that provide
configurable settings:

Element Configurable Settings Further Information

Communication § Baud rate Configurable Settings of
cluster § Data phase baud rate (only for CAN clusters) Communication Clusters on
page 408
Frame § Payload length Configurable Settings of Frames
§ CAN frame triggering: on page 409
§ Identifier
§ RX mask
§ Extended addressing
§ CAN FD frame support
§ Bit rate switch
§ LIN frame triggering:
§ Identifier
§ Checksum type
PDU § Name (only for user-defined ISignal IPDUs) Configurable Settings of PDUs
§ Payload length on page 414
§ Bit pattern for unused bits

392
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Basics on Modifying Communication Matrices

Element Configurable Settings Further Information

§ Cyclic timing:
§ Time offset
§ Time period
§ Minimum delay time
§ Event‑controlled timing:
§ Number of repetitions
§ Repetition period
§ Minimum delay time
§ Initial dynamic part (only for multiplexed IPDUs )
§ Collection semantics, timeout value, and trigger condition (only for
contained IPDUs and J1939‑22‑compliant IPDUs)
ISignal group Transfer property Configurable Settings of ISignal
Groups on page 425
ISignal § Name (only for user-defined ISignals) Configurable Settings of ISignals
§ Length on page 427
§ Initial value
§ Base data type for the coded and physical signal type
§ Category
§ Computation scale: Numerators and denominators (only for computation
methods that have the Interpreted category set to LINEAR)
§ ISignal-to-IPDU mapping:
§ Start bit position
§ Endianness
§ Transfer property

Effects of modifying General effects Modifying a communication matrix has the following effects:
communication matrices § When you add elements to a communication matrix, required related elements
are added automatically. For example, if you add an ISignal IPDU, related
elements such as a frame and a frame triggering are added as well.
§ When you specify user-defined settings for configurable elements, the changes
apply to the communication matrix element and all its instances. For example,
if you modify the length of a TX ISignal, the changes apply to both directions
of the ISignal (TX and RX), and all the ISignal instances in all bus configurations
of the active ConfigurationDesk application.
§ The modifications apply only to the communication matrix in the active
ConfigurationDesk application. The original communication matrix and
inactive applications remain unchanged.
Depending on the specifications in the communication matrix and/or the use of
modified elements in bus configurations, the changes might result in conflicting
settings. For more information, refer to Basics on Bus Manager-Related Conflicts
on page 163.

Effects when deleting or replacing communication matrices The

modifications are lost if you delete a communication matrix from the Buses
Browser.

393
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Modifying Communication Matrices

Replacing an assigned communication matrix in a bus configuration has the

following effects on the modified elements that are assigned to the bus
configuration:
§ Added ISignal IPDUs and ISignals are transferred to the newly assigned
communication matrix only if they fulfill all replacing conditions. Otherwise,
they are lost. For information on the replacing conditions, refer to Basics on
Replacing Assigned Communication Matrices on page 435.
§ Added cyclic and event‑controlled timings, user‑defined PDU gateways, and
user-defined settings of configurable elements are lost, i.e., the changes are
not transferred to the newly assigned communication matrix even if it contains
identical elements.

Identifying modified You can identify modified communication matrix elements via the Properties
communication matrix Browser: Elements that were added or modified by the user have the Changes
elements to communication matrix property set to True.

You can also access modified communication matrix elements via

ConfigurationDesk's automation interface and generate an overview of all the
modified elements of the active ConfigurationDesk application. For an example,
refer to Examples of Automating Bus Manager Features (ConfigurationDesk
Automating Tool Handling ).

Filter for modified You can filter the communication matrices of the active application for modified
communication matrix elements. The Filter for Changes to Communication Matrices is available via
elements the context menu of the Buses Browser and on the Home ribbon. When the
filter is active, the Buses Browser displays only the modified communication
matrix elements and their related higher-level elements.

For an overview of further filters for communication matrices, refer to Filtering

communication matrix elements on page 98. For details on using the filters, refer
to Using Display Filters (ConfigurationDesk Real-Time Implementation Guide ).

Undo modifications You can undo the modifications of communication matrices. The Undo All
Changes command of the Home ribbon lets you undo all the modifications of
all the communication matrices of the active application. The Undo Changes
to Communication Matrix command of a selected element in the Properties
Browser lets you undo the modifications of only this element as follows:
§ If the element was added to the communication matrix, it is deleted from the
communication matrix, including the elements that were added automatically
(e.g., the frame of an added user-defined ISignal IPDU).

394
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Basics on Modifying Communication Matrices

Tip

For ISignal IPDUs and ISignals that were added to the communication
matrix, the command is also available in the Communication Matrices
by Clusters view of the Buses Browser.

§ If the selected element was not added but has user-defined settings, the
settings are reset to the default values, i.e, the original values specified in the
communication matrix or the system default values.

Moreover, you can remove individual source PDUs of user‑defined PDU gateways
from the related target PDU using the Remove User-Defined Gateway Source
PDU command. Refer to Removing user‑defined PDU gateways on page 406.

Restrictions for working You can work with a modified communication matrix only in the active
with modified communication ConfigurationDesk application. You cannot reuse the modifications in other
matrices ConfigurationDesk applications or transfer the changes to the original
communication matrix.

Tip

If you need the modifications of a communication matrix in more than

one ConfigurationDesk application, use automation scripts for modifying
a communication matrix. This reduces the effort for modifying the
communication matrix in each required ConfigurationDesk application
significantly and reduces the risk of failures. For an example of modifying
communication matrices via automation scripts, refer to Examples of
Automating Bus Manager Features (ConfigurationDesk Automating Tool
Handling ).

If you assign user-defined ISignal IPDUs or ISignals to bus configurations, some

limitations apply for importing working views. Refer to Limitations for importing
working views that contain Bus Configuration function blocks on page 532.

Related topics Basics

Accessing Bus Manager Features via the ConfigurationDesk Automation Interface.................. 152
Working with Communication Matrices.................................................................................... 92

References

Filter for Changes / Filter for Changes to Communication Matrices

(ConfigurationDesk User Interface Reference )
Undo All Changes (ConfigurationDesk User Interface Reference )
Undo Changes to Communication Matrix (ConfigurationDesk User Interface
Reference )

395
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Modifying Communication Matrices

Adding ISignal IPDUs to CAN Channels

Introduction You can add ISignal IPDUs to CAN channels that are specified in a
communication matrix. For example, you can use these user-defined ISignal
IPDUs to configure ISignal IPDUs in bus configurations that are not available yet
in the current version of the communication matrix.

Conditions for adding ISignal For adding ISignal IPDUs to a communication matrix, the following conditions
IPDUs apply:
§ You can add ISignal IPDUs only to CAN channels.
§ You can add an ISignal IPDU to one CAN channel only, i.e., you cannot use an
added ISignal IPDU on multiple channels.

Adding ISignal IPDUs You can add TX and RX ISignal IPDUs via context menu when you select a
CAN channel in the Communication Matrices by Clusters view of the Buses
Browser, as shown in the following example.

Effects of adding ISignal When you add an ISignal IPDU, the following elements are added as well:
IPDUs § A PDU triggering
§ A cyclic timing including a time period and a time offset
§ A frame
§ A frame triggering

The ISignal IPDU is added with a unique default name, i.e.,

User_defined_IPDU_<number>. The names of the frame and the frame
triggering are derived from the PDU name. You can rename the PDU, for
example, in the Buses Browser or the Properties Browser. If you do this,
the frame and the frame triggering are renamed accordingly, as shown in the
following example.

396
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Adding ISignals to CAN PDUs

The PDU and the related elements are added with default settings. You can
change some of these settings. For more information, refer to:
§ Configurable Settings of Frames on page 409
§ Configurable Settings of PDUs on page 414

Restrictions for adding ISignal You cannot add instances of an ISignal IPDU to a communication matrix. For
IPDUs example, you cannot add a TX instance and an RX instance of an ISignal IPDU to
a communication matrix. Instead, you must add two separate ISignal IPDUs, one
TX ISignal IPDU and one RX ISignal IPDU.

Adding ISignals to CAN PDUs

Introduction You can add ISignals to CAN PDUs. For example, you can use these user-
defined ISignals to configure ISignals in bus configurations that are not available
yet in the current version of the communication matrix.

Conditions for adding ISignals For adding ISignals to a communication matrix, the following conditions apply:
§ You can add ISignals to a PDU only if the PDU is exchanged via exactly one
communication cluster , which is a CAN cluster.
§ You can add ISignals only to PDUs that can contain ISignals. For example, you
can add ISignals to basic PDUs such as ISignal IPDUs or NMPDUs but not
to container IPDUs , multiplexed IPDUs , or secured IPDUs .

Adding ISignals You can add ISignals via context menu when you select a supported CAN PDU
in the Communication Matrices by Clusters view of the Buses Browser, as
shown in the following example.

397
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Modifying Communication Matrices

The direction of the ISignal (TX or RX ) is set automatically according to the

direction of the selected PDU.

Effects of adding ISignals If multiple instances of a PDU are available in the communication matrix, ISignals
are added to all instances of the related PDU, regardless of the direction (TX or
RX). For example, if you add an ISignal to a TX PDU while an RX instance of
the PDU is available in the communication matrix as well, the ISignal is added to
both instances. The direction of the ISignal is adjusted automatically.

However, the ISignal is not assigned to bus configurations automatically, even

if an instance of the PDU is assigned. If you want to use the ISignal in a bus
configuration, you have to assign it manually for each required PDU instance.

When you add an ISignal, the following elements are added as well:
§ The base data types for the coded and physical signal types
§ A linear computation method including a computation scale
§ An ISignal-to-IPDU mapping

The ISignal is added with a unique default name, i.e.,

User_defined_ISignal_<number>. The names of the computation method and
the ISignal-to-IPDU mapping are derived from the ISignal name. You can rename
the ISignal, for example, in the Buses Browser or the Properties Browser.
If you do this, the computation method and the ISignal-to-IPDU mapping are
renamed accordingly, as shown in the following example.

The ISignal and the related elements are added with default settings. You can
change some of these settings. For more information, refer to Configurable
Settings of ISignals on page 427.

398
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Adding Cyclic Timing Elements to IPDUs

Adding Cyclic Timing Elements to IPDUs

Introduction You can add cyclic timing elements to ISignal IPDUs and extended multiplexed
IPDUs . For example, you can use these user-defined cyclic timing elements to
specify a cyclic transmission of the related IPDU if it is not yet specified in the
current version of the communication matrix.

Conditions for adding cyclic For adding cyclic timing elements to an IPDU, the following conditions apply:
timing elements § You can add cyclic timing elements only to ISignal IPDUs and extended
multiplexed IPDUs.
§ You can add a cyclic timing element to an IPDU only if it is not available yet for
the IPDU.
§ You can add a missing cyclic timing element only if the available cyclic timing
elements are not grouped in the Properties Browser.
If the communication matrix specifies multiple cyclic timings for an IPDU, the
cyclic timing elements are grouped by default. To add missing elements in this
case, you have to ungroup the elements by selecting the intersection mode
in the Properties Browser.

Overview of the cyclic timing You can add the following cyclic timing elements to an ISignal IPDU or extended
elements multiplexed IPDU:
§ Cyclic Timing
If no cyclic transmission is specified yet for the IPDU, you can add the Cyclic
Timing element.
§ Time Offset
If a cyclic transmission but no time offset (delay time) is specified for the IPDU,
you can add the Time Offset element.
§ Time Period
If a cyclic transmission but no time period (cycle time) is specified for the IPDU,
you can add the Time Period element.
§ Minimum Delay
If a cyclic transmission but no minimum delay time is specified for the IPDU,
you can add the Minimum Delay element.

399
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Modifying Communication Matrices

Adding cyclic timing elements When you select an ISignal IPDU or extended multiplexed IPDU, for example, in
the Buses Browser, you can add a cyclic timing element on the General page of
the Properties Browser as follows:
§ You can add a missing Cyclic Timing element via context menu of the IPDU
node.

§ You can add a missing Time Offset, Time Period, or Minimum Delay
element via context menu of the Cyclic Timing node.

Effects of adding cyclic timing Involved IPDU instances If multiple instances of an IPDU are available, cyclic
elements timing elements are added to all instances of the related IPDU, regardless
of the direction (TX or RX) and the location (communication matrix or bus
configuration).
For example, if you add cyclic timing elements to a TX IPDU while TX and RX
instances of the IPDU are available in the communication matrix and/or in bus
configurations, the elements are added to all the instances of the IPDU, including
the RX instances and the instances in the bus configurations.

Added elements and their settings For the added elements and their
settings, the following applies:
§ When you add a Cyclic Timing element, a Time Offset and Time Period
element are added automatically. If the communication matrix specifies a
minimum delay time for the IPDU, a Minimum Delay element is added
automatically as well.
§ When you add a Time Offset or Time Period element, only the related
element is added.
§ When you add a Minimum Delay element, it is added to all Cyclic Timing
and Event‑Controlled Timing elements that are available for the IPDU.

400
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Adding Event-Controlled Timing Elements to IPDUs

§ The elements are added with default settings. You can change some of these
settings. For more information, refer to Configurable Settings of PDUs on
page 414.

Note

Two Cyclic Timing elements might be available, one for each

transmission mode (True and False). In this case, the Bus Manager only
uses the cyclic timing of the True transmission mode, the cyclic timing
of the False transmission mode is ignored. Changes you make to the
cyclic timing of the False transmission mode have no effects at run time.
Refer to Limitations for Communication Matrices and Communication
Standards on page 519.

Tip

The Is in transmission mode property of Cyclic Timing elements

displays the related transmission mode.

Restrictions for cyclic timing For cyclic timing elements, the following restrictions apply:
elements § For the Cyclic Timing element, the Time Period element is mandatory while
the Time Offset element is optional. If required, you can delete the Time
Offset element but you must not delete the Time Period element.
§ If the communication matrix specifies a minimum delay time for the IPDU, you
cannot delete the Minimum Delay element.
§ If the communication matrix does not specify a minimum delay time and you
delete the Minimum Delay element, it is deleted for all Cyclic Timing and
Event‑Controlled Timing elements.

Adding Event‑Controlled Timing Elements to IPDUs

Introduction You can add event‑controlled timing elements to ISignal IPDUs and
extended multiplexed IPDUs . For example, you can use these user-defined
event‑controlled timing elements to specify an event‑controlled transmission
of the related IPDU if it is not yet specified in the current version of the
communication matrix.

However, to transmit IPDUs according to event‑controlled timings, you have to

enable the use of the transfer property of ISignals. The setting of the transfer
property determines if and how ISignals can trigger the transmission of the
IPDU in which they are included. Refer to Using Event‑Controlled Timings for
Transmitting PDUs on page 136.

401
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Modifying Communication Matrices

Conditions for adding For adding event‑controlled timing elements to an IPDU, the following conditions
event‑controlled timing apply:
elements § You can add event‑controlled timing elements only to ISignal IPDUs and
extended multiplexed IPDUs.
§ You can add an event‑controlled timing element to an IPDU only if it is not
available yet for the IPDU.
§ You can add a missing event‑controlled timing element only if the available
event‑controlled timing elements are not grouped in the Properties Browser.
If the communication matrix specifies multiple event‑controlled timings for an
IPDU, the event‑controlled timing elements are grouped by default. To add
missing elements in this case, you have to ungroup the elements by selecting
the intersection mode in the Properties Browser.

Overview of the You can add the following event‑controlled timing elements to an ISignal IPDU or
event‑controlled timing extended multiplexed IPDU:
elements § Event‑Controlled Timing
If no event‑controlled transmission is specified yet for the IPDU, you can add
the Event‑Controlled Timing element.
§ Repetition Period
If an event‑controlled transmission but no repetition period is specified for the
IPDU, you can add the Repetition Period element.
§ Minimum Delay
If an event‑controlled transmission but no minimum delay time is specified for
the IPDU, you can add the Minimum Delay element.

Adding event‑controlled When you select an ISignal IPDU or extended multiplexed IPDU, for example,
timing elements in the Buses Browser, you can add an event‑controlled timing element on the
General page of the Properties Browser as follows:
§ You can add a missing Event‑Controlled Timing element via context menu of
the IPDU node.

402
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Adding Event-Controlled Timing Elements to IPDUs

§ You can add a missing Repetition Period or Minimum Delay element via
context menu of the Event‑Controlled Timing node.

Effects of adding Involved IPDU instances If multiple instances of an IPDU are available,
event‑controlled timing event‑controlled timing elements are added to all instances of the related IPDU,
elements regardless of the direction (TX or RX) and the location (communication matrix or
bus configuration).
For example, if you add event‑controlled timing elements to a TX IPDU while TX
and RX instances of the IPDU are available in the communication matrix and/or
in bus configurations, the elements are added to all the instances of the IPDU,
including the RX instances and the instances in the bus configurations.

Added elements and their settings For the added elements and their
settings, the following applies:
§ When you add an Event‑Controlled Timing element, a Repetition Period
and Minimum Delay element are added automatically.
§ When you add a Repetition Period element, only the related element is
added.
§ When you add a Minimum Delay element, it is added to all
Event‑Controlled Timing and Cyclic Timing elements that are available for
the IPDU.
§ The elements are added with default settings. You can change some of these
settings. For more information, refer to Configurable Settings of PDUs on
page 414.

Note

Two Event‑Controlled Timing elements might be available, one for

each transmission mode (True and False). In this case, the Bus
Manager only uses the event‑controlled timing of the True transmission
mode, the event‑controlled timing of the False transmission mode is
ignored. Changes you make to the event‑controlled timing of the False
transmission mode have no effect at run time. Refer to Limitations for
Communication Matrices and Communication Standards on page 519.

403
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Modifying Communication Matrices

Tip

The Is in transmission mode property of Event‑Controlled Timing

elements displays the related transmission mode.

Restrictions for For event‑controlled timing elements, the following restrictions apply:
event‑controlled timing § If the communication matrix specifies a minimum delay time for the IPDU, you
elements cannot delete the Minimum Delay element.
§ If the communication matrix does not specify a minimum delay time and you
delete the Minimum Delay element, it is deleted for all Event‑Controlled
Timing and Cyclic Timing elements.

Specifying User-Defined PDU Gateways (Preview Version)

Introduction The Bus Manager supports PDU gateways according to AUTOSAR. Refer to
Aspects of PDU Gateways on page 76.

You can specify user‑defined PDU gateways to route the data of RX

PDUs (source PDUs) to a TX PDU (target PDU). You can do this by adding
RX PDUs to a TX PDU that is assigned to a bus configuration.

Note

The current version of specifying user‑defined PDU gateways is a preview

version. Refer to Providing preview versions of Bus Manager features on
page 19.

Conditions For specifying user‑defined PDU gateways, the following conditions apply:
§ You can specify PDU gateways between classic CAN, CAN FD, and LIN
communication clusters in any combination.
§ You can specify PDU gateways only for basic PDUs that are not configured
in any of the following ways:
§ Contained IPDU of a container IPDU
§ Static‑part or dynamic‑part IPDU of a multiplexed IPDU
§ Authentic IPDU of a non‑cryptographic secured IPDU
§ J1939-compliant IPDU
§ extended multiplexed IPDU
§ The source and target PDUs can be specified in the same or different
communication matrices.

404
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Specifying User-Defined PDU Gateways (Preview Version)

Adding source PDUs to a You can specify a user‑defined PDU gateway by adding RX PDUs (source) to a TX
target PDU PDU (target). To do this, do the following:
1. Assign a TX PDU you want to use as the target PDU to the Simulated ECUs
part of a bus configuration.
2. Select the RX PDUs you want to use as the source PDUs in any
communication matrix in the Buses Browser.
3. Press and hold the Ctrl key.

4. Drag the selected RX PDUs to the TX PDU in the bus configuration.

If not assigned yet, the RX PDUs are assigned to the Simulated ECUs part
of the bus configuration. The PDU gateway is set up and the RX PDUs
are displayed as the gateway source PDUs for the TX PDU. The source
PDUs are displayed with the following syntax: PDU name [communication
matrix\communication cluster].

For an animated graphic, refer to dSPACE Help.

To simulate a PDU gateway at run time, the source and target PDUs must be
assigned to the Simulated ECUs part of the same bus configuration. Moreover,
you have to enable the PDU gateway support for this bus configuration. Refer to
Simulating PDU Gateways (Preview Version) on page 148.

Effects of adding source PDUs When you add a user‑defined source PDU to a target PDU, the following applies:
to target PDUs
Tip

For animated graphics, refer to dSPACE Help.

§ According to AUTOSAR, PDU gateways are specified per ECU. Therefore, the
source PDU is added to the target PDU only in the context of the ECU for
which the target PDU is assigned to the bus configuration. The source PDU is
not added to target PDU instances of other ECUs.
§ Target PDUs are always TX PDUs. Therefore, the source PDU is added only to
the TX instances of the target PDU in the respective ECU. The source PDU is
not added to RX instances of the target PDU.

§ The source PDU is added to the target PDU instances of all communication
clusters on which the respective ECU transmits the target PDU. This applies

405
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Modifying Communication Matrices

regardless of whether the target PDU is configured for all of these clusters in
the bus configuration.
For example:
§ BodyControlEcu transmits CarLockControlIPdu on CanBodyCluster and
LinDoorCluster.
§ CarLockControlIPdu is assigned to Bus Configuration (1) in the context
of CanBodyCluster and to Bus Configuration (2) in the context of
LinDoorCluster.
§ GearboxInfoIPdu is added as the source PDU to CarLockControlIPdu in
Bus Configuration (1).
As a result, PDU gateways are set up for CanBodyCluster and
LinDoorCluster. However, only the PDU gateway on CanBodyCluster will
be simulated at run time because the source PDU is only assigned to Bus
Configuration (1).

§ The source PDU is added to the target PDU only in the context of that
communication cluster for which you select the source PDU in the Buses
Browser.
If a source PDU can be received on multiple communication clusters and you
want to set up PDU gateways for two or more of these clusters, you have to
add the source PDU in the context of each cluster to the target PDU.
§ Even though adding a source PDU to a target PDU takes place in a
bus configuration, the mapping of the source PDU to the target PDU is
independent from the bus configuration. For example, deleting the source
PDU from the bus configuration, deleting the bus configuration itself, or
assigning the target PDU to another bus configuration has no effect on the
mapping.

Removing user‑defined PDU You can remove user‑defined PDU gateways in one step using the Undo All
gateways Changes or Undo Changes to Communication Matrix commands. Refer to
Undo modifications on page 394.

406
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Specifying User-Defined PDU Gateways (Preview Version)

Moreover, you can remove individual user‑defined source PDUs from the related
target PDU. You can do this using the Remove User-Defined Gateway Source
PDU command, which is available on the context menu of the target PDU. The
command provides a submenu with all user‑defined source PDUs, as shown in
the following example.

Tip

The submenu of the command only provides user‑defined source PDUs.

It does not provide the source PDUs that are originally specified
in the communication matrix. In the previous example, IPdu2 [CAN-
LIN_Gateway\LIN3] is originally specified in the communication matrix and is
therefore not available on the submenu.

To remove a specific source PDU, select it on the submenu. When you do this,
the following applies:
§ The source PDU is removed from the target PDU. With this, all PDU gateways
that are set up for this source PDU in the context of the respective
communication cluster and the target PDU are removed.
In the following example, CarLockControlIPdu is specified as source PDU
in the context of CanBodyCluster and LinDoorCluster. When you remove
CarLockControlIPdu in the context of CanBodyCluster, the PDU gateway in
the context of LinDoorCluster remains unchanged.

§ If the source PDU is assigned to the bus configuration, the assignment remains
unchanged.

407
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Modifying Communication Matrices

Note

You cannot remove a user‑defined source PDU from the target PDU by
deleting the source PDU from the bus configuration.

Restrictions You cannot specify user‑defined PDU gateways for container IPDUs ,
multiplexed IPDUs , or secured IPDUs .

Related topics Basics

Accessing Bus Manager Features via the ConfigurationDesk Automation Interface.................. 152

Configurable Settings of Communication Clusters

Overview Communication clusters provide the following configurable settings:

§ Baud rate
§ Data phase baud rate (only for CAN clusters)

Tip

For communication clusters of DBC and LDF communication matrices,

you can additionally change the communication cluster name in the bus
configuration. Refer to Element identification via node names on page 102.

Accessing the configurable In the ConfigurationDesk application, you can access the configurable settings in
settings the following ways:
§ Select a communication cluster node in the Communication Matrices by
Clusters view of the Buses Browser or in the Bus Configurations table.
You can access the available baud rates on the General page of the
Properties Browser.

408
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Configurable Settings of Frames

§ Select a PDU node in the Buses Browser or in one of the following tables:
§ Bus Configurations table
§ Bus Simulation Features table
§ Bus Inspection Features table
§ Bus Manipulation Features table
You can access the available baud rates of the related cluster on the Bus
Communication page of the Properties Browser. The specified baud rates
apply not only to the selected PDU, but to all PDUs of the cluster.

Specifying the baud rates The Properties Browser provides the following properties for specifying the
baud rates of communication clusters.

Baud rate Lets you specify the baud rate (in bit/s) that applies to all PDUs
of the cluster. The valid range depends on the cluster's bus protocol and the
hardware that is used for the bus communication.

Data phase baud rate Available only for CAN clusters. Lets you specify the
baud rate (in bit/s) that applies to the data phase of CAN FD frames. For more
information, refer to CAN FD protocol on page 77. The valid range depends on
the hardware that is used for the bus communication.

Configurable Settings of Frames

Overview Frames provide the following configurable settings:

§ Payload length
§ CAN frame triggering: Extended addressing, identifier, RX mask, CAN FD
support, and bit rate switch
§ LIN frame triggering: Identifier and checksum type

However, for J1939, no configurable CAN frame settings are available.

Configuring these settings affects the related frame independently of its

direction, i.e., changes you make for TX instances of a frame affect its RX
instances as well and vice versa.

409
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Modifying Communication Matrices

Accessing the configurable In the ConfigurationDesk application, you can access the configurable settings of
settings a frame only when you select a PDU that is included in the frame. To access the
configurable settings, you can select a PDU in the Buses Browser or in one of
the following tables:
§ Bus Configurations table
§ Bus Simulation Features table
§ Bus Inspection Features table
§ Bus Manipulation Features table

For the selected PDU, the Bus Communication page of the Properties Browser
provides properties for configuring the payload length and the frame triggering
of the related frame. The configurable frame triggering properties differ for CAN
and LIN frames, as shown in the following illustrations:
§ Configurable properties available for CAN frames:

§ Configurable properties available for LIN frames:

410
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Configurable Settings of Frames

Tip

When a frame is exchanged via multiple communication clusters, multiple

frame triggerings apply to the frame. However, in most cases a PDU is
selected in the context of only one communication cluster. In this case, the
Properties Browser displays only one frame triggering of the frame. To
identify the other frame triggerings that also apply to the frame, filter the
Buses Browser for the PDU name, select all displayed PDU instances, and
select the intersection mode in the Properties Browser, for example.

Even though you access the frame properties via a PDU, the specified settings
apply to the frame itself, i.e., if several PDUs are included in one frame (e.g., via a
container IPDU ), you have to configure the frame only for one of these PDUs.
The specified settings are automatically available for all the other PDUs that are
included in this frame.

Specifying the payload length When you select a PDU, the Bus Communication page of the Properties
of CAN and LIN frames Browser provides the following property for specifying the payload length of the
related frame.

Length Lets you specify the payload length of CAN and LIN frames in bytes.
The valid range depends on the bus system and bus protocol:
§ Classic CAN: 0 ... 8 bytes
§ CAN FD: 0 ... 64 bytes, whereby only the following values are valid according
to CAN FD: 0 … 8, 12, 16, 20, 24, 32, 48, and 64 bytes
§ LIN: 1 ... 8 bytes
Points to note regarding CAN FD:
§ The CAN FD value range is available only if all the frame triggerings that apply
to the frame support CAN FD.
§ If you specify an invalid payload length according to CAN FD, the Bus Manager
extends the payload length to the next valid CAN FD length by adding
padding bytes. The value of each padding byte is 255.

Tip

If you want to specify the frame length for individual CAN frame instances,
you can use the Frame Access or Frame Length bus configuration feature.
Refer to Accessing CAN Frame Settings on page 288 or Manipulating the
Payload Length of CAN Frames on page 295, respectively.

Specifying the frame When you select a CAN PDU, the Bus Communication page of the Properties
triggering of CAN frames Browser provides the following properties for specifying the frame triggering of
the related CAN frame.

Extended addressing Lets you specify whether the CAN frame uses a
standard identifier format (11-bit) or extended identifier format (29-bit):
§ True: Extended identifier format
§ False: Standard identifier format

411
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Modifying Communication Matrices

Identifier Lets you specify the identifier of the CAN frame in decimal format.
The identifier of a CAN frame arbitrates and prioritizes the frame. The valid value
range depends on the identifier format (specified via the Extended addressing
property):
§ Extended identifier format: valid Identifier range 0 … 536,870,911
§ Standard identifier format: valid Identifier range 0 … 2,047
When you specify the identifier in decimal format, Identifier (hex) is adjusted
accordingly.

Identifier (hex) Lets you specify the identifier of the CAN frame in
hexadecimal format. The identifier of a CAN frame arbitrates and prioritizes the
frame. The valid value range depends on the identifier format (specified via the
Extended addressing property):
§ Extended identifier format: valid Identifier (hex) range
0x0000 0000 … 0x1FFF FFFF
§ Standard identifier format: valid Identifier (hex) range
0x0000 0000 … 0x0000 07FF
When you specify the identifier in hexadecimal format, Identifier is adjusted
accordingly.

Tip

§ You can enter a decimal value. When you do this, the value is
automatically converted to a hexadecimal value.
§ The hexadecimal format of the identifier can help you specify an RX mask.
§ If you access this property via automation, its value is provided in decimal
format.

RX mask Lets you specify a mask for the identifier of the CAN frame. The
RX mask defines the relevant bits for a received identifier: A received identifier
must match only the relevant bits, the non‑relevant bits can differ. Therefore,
any received frame whose identifier matches the relevant bits is processed and is
accepted for receiving the related PDU.

Note

A specified RX mask might also influence the manipulation of frames

and PDUs: If a frame or PDU is configured to be manipulated by the
Bus Manager, any CAN frame whose identifier matches the relevant bits
is processed by the Manipulation part of the related bus configuration.
Because of the masked identifier, multiple configured PDUs might use
the same frame. If two or more PDUs that use the same frame are
simultaneously manipulated at run time, the manipulation behavior is
undefined.

The RX mask is a hexadecimal value that is displayed in two blocks of 2

bytes each. The blocks mask the bits of the identifier from right (bit 0) to left
(<identifier format max. number of bits>). The bits of the RX mask
that are set to 1 determine the relevant bits of the identifier. If no RX mask
is specified, all bits of the identifier are relevant. For example, if you specify
0x0000 002F as the RX mask, the bits 0, 1, 2, 3, and 5 of the identifier are
relevant.

412
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Configurable Settings of Frames

Tip

If you access this property via automation, its value is provided in decimal
format.

CAN FD frame support Lets you specify whether CAN FD is supported for
the frame:
§ True: CAN FD is supported for the frame, i.e, the payload length of the frame
can be up to 64 bytes and the data phase of the frame can be transmitted
with a higher bit rate. For more information, refer to CAN FD protocol on
page 77.
§ False: CAN FD is not supported for the frame, i.e., the frame is treated as a
classic CAN frame.

Bit rate switch Lets you specify the bit rate used to transmit the data phase
of the frame. The specified setting applies only to CAN FD frames. It has no
effects on classic CAN frames. You can select one of the following values:
§ True: The data phase of the frame is transmitted with the bit rate that
is specified for the Data phase baud rate property of the related CAN
communication cluster.
§ False: The data phase of the frame is transmitted with the bit rate that
is specified for the Baud rate property of the related CAN communication
cluster.
The baud rate properties of communication clusters can be configured. For
more information, refer to Configurable Settings of Communication Clusters on
page 408.

Tip

If you want to specify the frame triggering for individual CAN frame
instances, you can use the Frame Access bus configuration feature. Refer
to Accessing CAN Frame Settings on page 288.

Specifying the frame When you select a LIN PDU, the Bus Communication page of the Properties
triggering of LIN frames Browser provides the following properties for specifying the frame triggering of
the related LIN frame.

Identifier Lets you specify the identifier value (ID) of the LIN frame in decimal
format. The identifier is part of the protected identifier (PID) of a LIN frame
header and assigns the header to a frame response. You can specify an ID in
the range 0 … 63. The specified ID must be unique for each LIN frame that the
communication matrix assigns to the same LIN channel.
According to the LIN specifications, the ID determines the frame type as follows:
§ ID 0 … 59: Data-carrying frame (e.g., unconditional frame or event-triggered
frame)
§ ID 60: Diagnostic frame (master request frame)
§ ID 61: Diagnostic frame (slave response frame)

413
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Modifying Communication Matrices

§ ID 62: Reserved for OEM-specific LIN communication

§ ID 63: Reserved for future use
When you specify the identifier in decimal format, Identifier (hex) is adjusted
accordingly.

Identifier (hex) Lets you specify the identifier value (ID) of the LIN frame in
hexadecimal format. The identifier is part of the protected identifier (PID) of a LIN
frame header and assigns the header to a frame response. You can specify an ID
in the range 0x00 … 0x3F. The specified ID must be unique for each LIN frame
that the communication matrix assigns to the same LIN channel.
According to the LIN specifications, the ID determines the frame type as follows:
§ ID 0x00 … 0x3B: Data-carrying frame (e.g., unconditional frame or event-
triggered frame)
§ ID 0x3C: Diagnostic frame (master request frame)
§ ID 0x3D: Diagnostic frame (slave response frame)
§ ID 0x3E: Reserved for OEM-specific LIN communication
§ ID 0x3F: Reserved for future use
When you specify the identifier in hexadecimal format, Identifier is adjusted
accordingly.

Tip

§ You can enter a decimal value. When you do this, the value is
automatically converted to a hexadecimal value.
§ If you access this property via automation, its value is provided in decimal
format.

Checksum type Lets you specify the checksum type of the LIN frame. The
checksum is part of the frame response and validates the frame response. You
can select one of the following values:
§ Classic: Only the data bytes of a LIN frame are used to calculate the checksum.
§ Enhanced: The data bytes and the protected identifier (PID) byte are used to
calculate the checksum.

Configurable Settings of PDUs

Overview PDUs provide the following configurable settings:

§ Name (only for user-defined ISignal IPDUs )
§ Payload length
§ Bit pattern for unused bits (not for container IPDUs with dynamic container
layout)
§ Cyclic transmission: Cyclic timing, time period, time offset, and minimum delay
time (only for ISignal IPDUs and extended multiplexed IPDUs )
§ Event‑controlled transmission: Number of repetitions, repetition period, and
minimum delay time (only for ISignal IPDUs and extended multiplexed IPDUs)

414
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Configurable Settings of PDUs

§ Initial dynamic part (only for multiplexed IPDUs )

§ Collection semantics, timeout value, and trigger condition (only for contained
IPDUs and J1939‑22‑compliant IPDUs)
§ Type of service, trailer format, assurance data type, and assurance data size
(only for J1939‑22‑compliant IPDUs)

Configuring these settings affects the related PDU independently from its
direction, i.e., changes you make for TX instances of a PDU affect its RX
instances as well and vice versa.

Accessing the configurable In the ConfigurationDesk application, you can access most of the configurable
settings settings when you select a PDU in the Buses Browser or in one of the following
tables:
§ Bus Configurations table
§ Bus Simulation Features table
§ Bus Inspection Features table
§ Bus Manipulation Features table

The General page of the Properties Browser provides properties for accessing
the configurable settings, as shown in the following examples. Depending on the
specifications in the communication matrix, not all of the displayed properties are
available for a selected PDU.

415
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Modifying Communication Matrices

Tip

You can also configure the name, payload length, time period, and time
offset in the Name, Length, Time Period, and Time Offset columns of the
previously listed tables. If a column is not available, you can add it via the
Column Chooser. Refer to Bus Configuration Tables on page 103.

However, you cannot access the property that lets you configure the initial
dynamic part of a multiplexed IPDU when you select the IPDU in the Buses
Browser. Instead, you have to select the multiplexed IPDU in one of the
tables. When you do this, the Multiplexed Part IPDUs page is available in the
Properties Browser. This page provides the related property.

416
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Configurable Settings of PDUs

Specifying the name of user- When you select a user-defined ISignal IPDU, the General page of the
defined ISignal IPDUs Properties Browser provides the following property for specifying the PDU's
name.

Name Lets you specify the name of a user-defined ISignal IPDU. The name
can have a maximum length of 128 characters and must be unique for all
PDUs of the same ECU and direction (TX or RX). It is recommended to use only
alphabetic and numeric ASCII characters and underscores for the name. For more
information, refer to Limitations for element names on page 531.
When you specify the name, the names of the related frame and frame
triggering are adjusted accordingly. For more information, refer to Adding ISignal
IPDUs to CAN Channels on page 396.

Specifying the payload length When you select a PDU, the General page of the Properties Browser provides
of PDUs the following property for specifying the PDU's payload length.

Length Lets you specify the payload length of the PDU in bytes. The valid
range depends on the bus system and bus protocol as follows:
§ Classic CAN and LIN: 0 … 8 bytes
§ CAN FD: 0 … 64 bytes
§ J1939‑21: 0 … 1,785 bytes
§ J1939‑22:
§ Peer‑to‑peer communication (i.e., Destination address set to 0 … 253 and
Broadcast set to False): 0 … 60 bytes
§ Broadcast communication (i.e., Destination address set to 255 and/or
Broadcast set to True): 0 … 15,352 bytes
However, the CAN FD value range is available only if CAN FD is supported by all
the frames in which the PDU is included, i.e.:
§ If the PDU is included in CAN and LIN frames, the CAN FD value range is not
available. This applies even if all the CAN frames support CAN FD.
§ If the PDU is included only in CAN frames, all the frame triggerings of all the
frames must support CAN FD. You can specify the CAN FD support. Refer to
Configurable Settings of Frames on page 409.
Moreover, the valid maximum payload length depends on various factors, for
example:
§ The usable payload length of the related frame.
§ The usable payload length of a related multiplexed IPDU or container IPDU.
§ Whether assurance data is included in a J1939‑22‑compliant IPDU that is used
for broadcast communication.

417
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Modifying Communication Matrices

Tip

If you specify a payload length that is invalid in the context in which the
PDU is used, conflicts occur. The conflicts can help you specify a valid
payload length for the specific context. Refer to Basics on Bus Manager-
Related Conflicts on page 163.

If you modify the PDU length while a related Raw Data function port of the PDU
Raw Data feature exists, the function port is affected in the following ways:
§ The data width of the function port depends on the PDU length. Therefore,
the function port's data width adjusts to the modified PDU length.
§ The data width determines the vector size of the function port's Initial value
and Initial substitute value properties. This has the following effects on the
specified values:
§ If the data width is reduced, the vector size of both properties reduces
accordingly. The vector elements are deleted from right to left and the
values specified for these elements are lost, as shown in the following
example.

§ If the data width is increased, the vector size of both properties increases
accordingly. The new vector elements are added to the right of the existing
vector elements. The default value of the new vector elements is 0.
For more information on Raw Data function ports and the PDU Raw Data
feature, refer to Accessing the Payload of PDUs in Raw Data Format on
page 240.

Specifying bit patterns for To prevent unintended behavior, unused PDU bits are filled with a specific bit
unused PDU bits pattern. AUTOSAR-compliant communication matrices can specify a bit pattern
for ISignal IPDUs , multiplexed IPDUs , secured IPDUs , container IPDUs ,
and NMPDUs for this purpose. If a communication matrix does not specify
a bit pattern for a PDU (e.g., because the communication matrix does not
comply with AUTOSAR), the Bus Manager uses a default bit pattern: For
J1939‑compliant IPDUs, the default bit pattern is 255. For all other PDUs, the
default bit pattern is 0.

For basic PDUs , multiplexed IPDUs, secured IPDUs, and container IPDUs with
static container layout, you can specify a user-defined bit pattern on the General
page of the Properties Browser via the following property.

Unused bit pattern Lets you specify a bit pattern for the selected PDU in the
range 0 … 255.

418
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Configurable Settings of PDUs

Tip

For container IPDUs with a dynamic container layout, the Bus Manager
uses a specified unused bit pattern as the value of padding bytes, which
are added to the related frame if the frame length is invalid according to
CAN FD. Refer to CAN FD protocol on page 77.

Specifying cyclic transmission ISignal IPDUs and extended multiplexed IPDUs can provide Cyclic Timing,
for IPDUs Time Period, Time Offset, and Minimum Delay elements, which let
you specify cyclic transmission: You can add missing elements and specify
user‑defined settings for configurable properties.

For information on adding missing elements, refer to Adding Cyclic Timing

Elements to IPDUs on page 399.

Note

Two Cyclic Timing elements might be available, one for each transmission
mode (True and False). In this case, the Bus Manager only uses the cyclic
timing of the True transmission mode, the cyclic timing of the False
transmission mode is ignored. Changes you make to the cyclic timing of the
False transmission mode have no effects at run time. Refer to Limitations
for Communication Matrices and Communication Standards on page 519.

Tip

§ The Is in transmission mode property of Cyclic Timing elements

displays the related transmission mode.
§ If two Cyclic Timing elements are available, their properties are grouped
by default. Select the intersection mode in the Properties Browser to
display the properties for each element.

When you select an ISignal IPDUs or extended multiplexed IPDU, the General
page of the Properties Browser can provide the following properties for
specifying the cyclic transmission of the IPDU.

Value (Time Period) If the Time Period element is available, its Value
property lets you specify a time period for the cyclic transmission of the selected
IPDU. The IPDU is transmitted cyclically according to the specified time period
(cycle time). You can specify a time period in the range 0 … 3,600 seconds.

Tip

If you specify the time period in the Time Period column, which is available
for bus configuration tables, the specified value automatically applies to the
cyclic timing that is used by the Bus Manager. The Transmission Mode
(Cyclic Timing) column displays the transmission mode of the used cyclic
timing.

419
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Modifying Communication Matrices

Value (Time Offset) If the Time Offset element is available, its Value
property lets you specify a time offset for the cyclic transmission of the selected
IPDU. The cyclic transmission of the IPDU is delayed according to the specified
time offset (delay time). You can specify a time offset in the range 0 …
3,600 seconds.

Tip

If you specify the time offset in the Time Offset column, which is available
for bus configuration tables, the specified value automatically applies to the
cyclic timing that is used by the Bus Manager. The Transmission Mode
(Cyclic Timing) column displays the transmission mode of the used cyclic
timing.

Value (Minimum Delay) If the Minimum Delay element is available, its

Value property lets you specify a minimum delay time, i.e., the minimum
time span between two transmissions of the selected IPDU. You can specify a
minimum delay time in the range 0 … 3,600 seconds.
For each IPDU, the Bus Manager supports only one minimum delay time.
Therefore, the specified minimum delay time also applies to the Minimum
Delay element of event‑controlled timings.
In general, the minimum delay time is considered regardless of the source that
triggers the transmission of the IPDU at run time: The minimum delay time
applies to all timings that are specified in the communication matrix and to
user‑defined triggers via bus configuration features. However, the minimum
delay time does not apply to the Frame Access feature.

Tip

If you want to specify cyclic transmission for individual IPDU instances, you
can use the PDU Cyclic Timing Control feature. Refer to Controlling the
Cyclic Timing of CAN PDUs on page 243.

Specifying event‑controlled ISignal IPDUs and extended multiplexed IPDUs can provide
transmission for IPDUs Event‑Controlled Timing, Repetition Period, and Minimum Delay elements,
which let you specify event‑controlled transmission. You can add missing
elements and specify user‑defined settings for configurable properties.

For basic information on event‑controlled timings, refer to Using

Event‑Controlled Timings for Transmitting PDUs on page 136. For information
on adding missing elements, refer to Adding Event‑Controlled Timing Elements
to IPDUs on page 401.

420
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Configurable Settings of PDUs

Note

Two Event‑Controlled Timing elements might be available, one for

each transmission mode (True and False). In this case, the Bus
Manager only uses the event‑controlled timing of the True transmission
mode, the event‑controlled timing of the False transmission mode is
ignored. Changes you make to the event‑controlled timing of the False
transmission mode have no effect at run time. Refer to Limitations for
Communication Matrices and Communication Standards on page 519.

Tip

§ The Is in transmission mode property of Event‑Controlled Timing

elements displays the related transmission mode.
§ If two Event‑Controlled Timing elements are available, their properties
are grouped by default. Select the intersection mode in the Properties
Browser to display the properties for each element.

When you select an ISignal IPDU or extended multiplexed IPDU, the General
page of the Properties Browser can provide the following properties for
specifying the event‑controlled transmission of the IPDU.

Number of repetitions Lets you specify the number of repetitions in the

range 0 … 255. If an ISignal or ISignal group triggers the transmission of the
IPDU with repetitions, the specified value determines how often the transmission
of the IPDU is repeated after the first transmission. If the value is 0, the
transmission is not repeated and the IPDU is transmitted only once.

Value (Repetition Period) If the Repetition Period element is available, its

Value property lets you specify a repetition period, i.e., the period with which
the transmission of the IPDU is repeated. You can specify a repetition period in
the range 0 … 3,600 seconds. If the value is 0, the transmission of the IPDU is
repeated as fast as possible.

Value (Minimum Delay) If the Minimum Delay element is available, its

Value property lets you specify a minimum delay time, i.e., the minimum
time span between two transmissions of the selected IPDU. You can specify a
minimum delay time in the range 0 … 3,600 seconds.
For each IPDU, the Bus Manager supports only one minimum delay time.
Therefore, the specified minimum delay time also applies to the Minimum
Delay element of cyclic timings.
In general, the minimum delay time is considered regardless of the source that
triggers the transmission of the IPDU at run time: The minimum delay time
applies to all timings that are specified in the communication matrix and to
user‑defined triggers via bus configuration features. However, the minimum
delay time does not apply to the Frame Access feature.

Tip

If you want to specify a user-defined trigger to transmit individual IPDU

instances, you can use the PDU Trigger or Frame Access feature. Refer
to Specifying User-Defined Triggers for Transmitting PDUs on page 246 and
Accessing CAN Frame Settings on page 288, respectively.

421
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Modifying Communication Matrices

Specifying the initial dynamic When you select a multiplexed IPDU in a bus configuration, e.g., in the Bus
part for multiplexed IPDUs Configurations table, the Multiplexed Part IPDUs page is available in the
Properties Browser. This page provides the following property for specifying
the initial dynamic‑part IPDU.

Initial dynamic‑part IPDU Lets you specify the initial dynamic‑part IPDU for
the multiplexed IPDU. You can select an IPDU that is specified as a dynamic‑part
alternative from the list. By default, the IPDU that the communication matrix
specifies as the initial dynamic‑part IPDU is selected. When you change the
default selection, the value of the Is initial dynamic part property of all
dynamic‑part IPDUs is adjusted accordingly.

Note

You can select an IPDU from the list regardless of whether it is assigned to
the bus configuration.

Tip

§ The Multiplexed Part IPDUs page displays the dynamic‑part and

static‑part IPDUs of the multiplexed IPDU that are assigned to the bus
configuration.
§ Some properties of the dynamic‑part IPDUs are grouped on the page by
default. Select the intersection mode in the Properties Browser to
display the properties for each dynamic‑part IPDU.

Specifying the collection For contained IPDUs and J1939‑22‑compliant IPDUs, you can specify the
semantics, timeout value, and collection semantics, a timeout value, and the trigger condition. Depending on
trigger condition the selected IPDU, the Properties Browser provides the related properties on
the following pages:
§ Contained IPDU: General page
§ J1939‑22‑compliant IPDU: Bus Communication page

Note

For J1939‑22‑compliant IPDUs, the specified settings apply only if an IPDU

is transmitted using the Multi‑PG protocol. For more information, refer to
Aspects of the J1939 Protocol on page 80.

Collection semantics Lets you specify the collection semantics as follows:

Value Contained IPDU J1939‑22‑Compliant IPDU (Multi‑PG Protocol)

QUEUED Several instances of the contained IPDU can be added to one Several instances of the J1939‑22‑compliant IPDU
container IPDU. can be added to one Multi‑PG‑compliant CAN FD
According to AUTOSAR, the queued semantics is supported frame.
only for contained IPDUs that are included in container IPDUs
with a dynamic container layout.

422
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Configurable Settings of PDUs

Value Contained IPDU J1939‑22‑Compliant IPDU (Multi‑PG Protocol)

LAST_IS_BEST Only one instance of the contained IPDU can be added to one Only one instance of the J1939‑22‑compliant
container IPDU. In this case, the data of the contained IPDU IPDU can be added to one Multi‑PG‑compliant
is buffered and only the latest data is added to the container CAN FD frame. In this case, the data of the IPDU
IPDU just before it is transmitted. is buffered and only the latest data is added to
According to AUTOSAR, the last-is-best semantics is supported the frame just before it is transmitted.
for contained IPDUs that are included in container IPDUs with a
dynamic or static container layout.

However, for the queued semantics, the Bus Manager displays only the last
received instance of the contained IPDU or J1939‑22‑compliant IPDU.

Trigger Lets you specify the trigger condition as follows:

Value Contained IPDU J1939‑22‑Compliant IPDU (Multi‑PG

Protocol)
ALWAYS The contained IPDU triggers the The J1939‑22‑compliant IPDU triggers the
transmission of the container transmission of the Multi‑PG‑compliant
IPDU when it is included in the CAN FD frame when it is included in the
container IPDU. frame.
NEVER The contained IPDU does not The J1939‑22‑compliant IPDU does
trigger the transmission of the not trigger the transmission of the
container IPDU. Instead, the Multi‑PG‑compliant CAN FD frame.
transmission of the container Instead, the transmission of the
IPDU can be triggered by another frame can be triggered by another
contained IPDU or a timeout, for J1939‑22‑compliant IPDU or a timeout, for
example. example.

Timeout Lets you specify a timeout value in the range 0 … 65,535 seconds.
The timeout value applies only if Trigger is set to NEVER for the related IPDU. If
this is the case, the effects of the timeout value depend on the specific IPDU:

IPDU Effect
Contained IPDU The specified value can reduce the timeout of the related container IPDU. The timeout of the container
IPDU starts when the first contained IPDU is added to the container IPDU. When the shortest timeout
ends (i.e., container timeout or timeout of a contained IPDU), the transmission of the container IPDU is
triggered.
If the timeout value is unspecified or 0, it has no effect on the timeout of the container IPDU. To trigger
the transmission of the container IPDU according to a timeout, the container IPDU or at least one of its
contained IPDUs must have a timeout value > 0 specified.
J1939‑22‑compliant The specified value determines the transmission of the related frame. The timeout starts when the
IPDU (Multi‑PG IPDU is added to the frame. When the timeout ends, the transmission of the frame is triggered. If
protocol) multiple J1939‑22‑compliant IPDUs are added to the frame, the shortest timeout value determines the
transmission.
If the timeout value is unspecified or 0, the transmission of the frame is not triggered. To trigger the
transmission of the frame according to a timeout, another J1939‑22‑compliant IPDU that is included in
the frame must have a timeout value > 0 specified.

Specifying the type of service, When you select a J1939‑22‑compliant IPDU, the Bus Communication page of
trailer format, assurance data the Properties Browser provides the following properties for specifying the type
type, and assurance data size of service, trailer format, assurance data type, and assurance data size:

423
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Modifying Communication Matrices

Type of service Lets you specify the type of service (TOS) for
J1939‑22‑compliant IPDUs in the range 0 … 7.

Note

The type of service applies only to J1939‑22‑compliant IPDUs that are

transmitted using the Multi‑PG protocol, i.e., it applies to contained
parameter groups (C‑PGs). For more information, refer to Aspects of the
J1939 Protocol on page 80.

According to the SAE J1939‑22 specification, the specified value determines the
structure and the type of the content of the C‑PG as follows:

Value Description
0 The C‑PG is used for padding unused bytes of the CAN FD frame to a valid CAN FD length. In this case, the layout of the
C‑PG is the following:
§ The header consists of maximum 3 bytes, the payload length (PL) segment is not available. Depending on the required
number of padding bytes, the header can also be shorter.
§ The maximum total length, i.e., header and payload, is limited to 15 bytes.
For more information on padding CAN FD frames according to the Multi‑PG protocol, refer to Transmitting IPDUs using the
Multi‑PG protocol on page 84.
1 The C‑PG contains manufacturer‑specific assurance data.
2 The C‑PG contains optional assurance data specified by SAE.
3 … 7 Reserved for future use according to the J1939 standard.

Trailer format Lets you specify the trailer format (TF) for J1939‑22‑compliant
IPDUs in the range 0 … 7.

Note

The type of service applies only to J1939‑22‑compliant IPDUs that are

transmitted using the Multi‑PG protocol, i.e., it applies to contained
parameter groups (C‑PGs). For more information, refer to Aspects of the
J1939 Protocol on page 80.

The trailer format is required to specify the type of the assurance data that is
used with the C‑PG. However, according to the SAE J1939‑22 specification, the
[type of service (TOS), trailer format (TF)] tuple is required to
specify the specific assurance data type. Using this tuple, the specific assurance
data type is specified as follows:

Type of Service (TOS) Trailer Format (TF) Assurance Data Type

1 0 Reserved
1 1 32‑bit cybersecurity assurance data (manufacturer‑specific)
1 2 32‑bit functional safety assurance data (manufacturer‑specific)
1 3 32‑bit cybersecurity assurance data followed by 32-bit functional safety assurance
data (manufacturer‑specific)
1 4 Reserved
1 5 64‑bit cybersecurity assurance data (manufacturer‑specific)
1 6 64‑bit functional safety assurance data (manufacturer‑specific)
1 7 Reserved

424
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Configurable Settings of ISignal Groups

Type of Service (TOS) Trailer Format (TF) Assurance Data Type

2 0 No assurance data (SAE‑specific)
2 1…7 Reserved
3…7 0…7 Reserved

Assurance data type Lets you specify the assurance data type (AD Type) for
J1939‑22‑compliant IPDUs.

Note

The assurance data type applies only to J1939‑22‑compliant IPDUs that are
transmitted using the Broadcast Announce Message (BAM) protocol. For
more information, refer to Aspects of the J1939 Protocol on page 80.

You can specify the assurance data type as follows:

Value Description
No assurance data The IPDU contains no assurance data.
Cybersecurity (manufacturer‑specific) The IPDU contains cybersecurity assurance data (manufacturer‑specific).
Functional safety (manufacturer‑specific) The IPDU contains functional safety assurance data (manufacturer‑specific).
Cybersecurity and functional safety The IPDU contains cybersecurity assurance data followed by functional safety
(manufacturer‑specific) assurance data (manufacturer‑specific).

Assurance data size Lets you specify the assurance data size (AD Size) for
J1939‑22‑compliant IPDUs in the range 0 … 52 bytes. The specified value
determines how many bytes of the IPDU's payload length are used by the
assurance data.

Note

The assurance data type applies only to J1939‑22‑compliant IPDUs that are
transmitted using the Broadcast Announce Message (BAM) protocol. For
more information, refer to Aspects of the J1939 Protocol on page 80.

Related topics Basics

Limitations for LIN Communication......................................................................................... 528

Configurable Settings of ISignal Groups

Overview You can specify user-defined settings for the transfer property of ISignal groups.

Configuring the setting affects the related ISignal group independently from its
direction, i.e., changes you make for TX instances of an ISignal group affect its
RX instances as well and vice versa.

425
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Modifying Communication Matrices

Accessing the configurable In the ConfigurationDesk application, you can access the configurable setting in
setting the Properties Browser when you select an ISignal group in the Buses Browser
or in the Bus Configurations table.

Specifying user-defined The Properties Browser provides the following property for specifying user-
settings for ISignal groups defined settings for the ISignal‑to‑IPDU mapping of ISignal groups.

Transfer property Lets you specify the transfer property of the ISignal group.
If the Use transfer property property of the bus configuration is set to True,
the setting of the transfer property determines if and how the ISignal group can
trigger the transmission of the PDU in which it is included. For more information,
refer to Using Event‑Controlled Timings for Transmitting PDUs on page 136.
You can specify the transfer property as follows:

Value Description
<empty The ISignal group does not trigger the transmission of the PDU.
value> Nevertheless, ISignals that are included in the ISignal group can trigger
Pending the transmission of the PDU according to the setting of their transfer
property.
Triggered The ISignal group triggers the transmission of the PDU with repetitions if
with all of the following applies:
repetition § The coded value of an included ISignal has changed.
Triggered on § The transfer property of this ISignal is unspecified.
change with However, transmission with repetitions is possible only if an
repetition event‑controlled timing is specified for the PDU. If no event‑controlled
timing is specified, the ISignal group triggers only a single transmission.
Triggered The ISignal group triggers a single transmission of the PDU if all of the
without following applies:
repetition § The coded value of an included ISignal has changed.
Triggered on § The transfer property of this ISignal is unspecified.
change
without
repetition

Concerning the evaluation of the transfer property, some limitations apply. Refer
to Limitations for transmitting PDUs according to event‑controlled timings on
page 520.

426
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Configurable Settings of ISignals

Configurable Settings of ISignals

Overview ISignals provide the following configurable settings:

§ Name (only for user-defined ISignals)
§ Signal length
§ Initial value
§ Base data type for the coded and physical signal type
§ Coded signal type: Category
§ Computation scale: Numerators and denominators (only for computation
methods that have the Interpreted category set to LINEAR)
§ ISignal-to-IPDU mapping: Start bit position, endianness, and transfer property

Configuring these settings affects the related ISignal independently from its
direction, i.e., changes you make for TX instances of an ISignal affect its RX
instances as well and vice versa.

Accessing the configurable In the ConfigurationDesk application, you can access the configurable settings
settings when you select an ISignal in the Buses Browser or in one of the following
tables:
§ Bus Configurations table
§ Bus Simulation Features table
§ Bus Inspection Features table
§ Bus Manipulation Features table

The General page of the Properties Browser provides properties for accessing
the configurable settings, as shown in the following examples. Depending on the
specifications in the communication matrix, not all of the displayed properties are
available for a selected ISignal.

427
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Modifying Communication Matrices

Tip

You can also configure the name, signal length, and initial value in the
Name , Length, and Initial Value columns of the previously listed tables.
Moreover, you can configure the endianness in the Endianness column of
the Bus Configurations table. If a column is not available, you can add it
via the Column Chooser. Refer to Bus Configuration Tables on page 103.

Specifying user-defined The Properties Browser provides the following properties for specifying user-
settings for ISignals defined settings for ISignals.

Name Available only for user-defined ISignals. Lets you specify the name of
a user-defined ISignal. The name can have a maximum length of 128 characters
and must be unique for all ISignals and ISignal groups of the same PDU.
It is recommended to use only alphabetic and numeric ASCII characters and
underscores for the name. For more information, refer to Limitations for element
names on page 531.
When you specify the name, the names of the related computation method
and the ISignal-to-IPDU mapping are adjusted accordingly. For more information,
refer to Adding ISignals to CAN PDUs on page 397.

Length Lets you specify the signal length:

Signal Type Range Description

Standard ISignals (i.e., ISignals 1 … 64 bits The valid signal length depends on the coded base data type of the
with Category set to ISignal:
STANDARD_LENGTH_TYPE) § If the coded base data type is an integer type (Int, UInt), the number
of bits specified for the signal length must be equal or smaller than
the number of bits specified for the coded base data type. Example:
For a coded base data type of Int8, the valid signal length range is
1 ... 8 bits.
If the number of bits specified for the signal length is smaller than the
number of bits specified for the coded base data type and a signal

428
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Configurable Settings of ISignals

Signal Type Range Description

value exceeds the value range of the signal length, the signal value is
automatically saturated to the next valid value.
§ If the coded base data type is a float or double type, the number of
bits specified for the signal length must be equal to the number of
bits specified for the coded base data type. Example: For a coded base
data type of Float64, the valid signal length is 64 bits.
Array signals (i.e., ISignals § Classic CAN and LIN: The applicable value range depends on the ISignal IPDUs in which
with Category set to 1 … 64 bits the ISignal is included. If the ISignal is included in one or more
ARRAY_TYPE) § CAN FD: IPDUs that are used in different use scenarios, e.g., for CAN and LIN
1 … 512 bits communication, the smallest valid value range applies.
§ J1939‑21: For example, an ISignal is included in an IPDU with one LIN frame
1 … 14,280 bits triggering and one CAN frame triggering for which CAN FD support
§ J1939‑22: is enabled. In this case, only the value range for classic CAN and LIN is
§ Peer‑to‑peer available for the ISignal length.
communication1): The specified length determines the vector size of the initial value
1 … 480 bits and the data width of the Value function port of the ISignal Value
§ Broadcast feature. If required, the vector size and the data width are automatically
communication2): adjusted.
1 … 122,816 bits
1) Peer‑to‑peer communication: J1939‑22‑compliant IPDUs with Destination address set
to 0 … 253 and Broadcast set to False
2) Broadcast communication: J1939‑22‑compliant IPDUs with Destination address set to
255 and/or Broadcast set to True

Initial value Lets you specify the coded initial signal value:

Signal Type Description

Standard ISignals (i.e., The valid range depends on the specified coded base data
ISignals with Category set to type. If you specify an initial value that exceeds the valid
STANDARD_LENGTH_TYPE) range, the value is automatically saturated to the next valid
value.
Array signals (i.e., ISignals The initial value is a vector. The vector size is the signal
with Category set to length in bytes (e.g., for a signal length of 16 bits, the
ARRAY_TYPE) vector size is 2). The value range of each vector element is
0 … 255.

The ISignal's initial value and the initial value of Value function ports of the
ISignal Value feature influence each other:
§ When you add the ISignal Value feature to an ISignal, the ISignal's initial
value is used as the initial value of the Value function port. If the ISignal's initial
value exceeds the valid range of the function port's initial value, the function
port's initial value is automatically saturated to the next valid value.

Tip

The valid range of the function port's initial value depends on the
specified physical base data type of the ISignal.

§ If you change the ISignal's initial value while a related Value function port
already exists, the function port's initial value is not updated.
§ If the ISignal's and function port's initial values differ, the function port's initial
value is used at run time.

429
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Modifying Communication Matrices

For more information on the Value function port of the ISignal Value feature,
refer to Working with ISignal Values on page 221.

Base data type (Coded Type) Lets you specify the base data type for the
coded signal value. For an introduction to coded and physical signal values, refer
to Signal Conversion by the Bus Manager on page 60.
The valid values depend on the signal type:
§ Standard ISignals (i.e., ISignals with Category set to
STANDARD_LENGTH_TYPE): For an overview of the valid values, refer to
Supported signal data types on page 59.
§ Array signals (i.e., ISignals with Category set to ARRAY_TYPE): The coded
base data type must be UInt8.
The specified coded base data type determines the valid initial value and length
range of the ISignal:
§ If required, the specified initial value is automatically saturated to the next valid
value when you change the data type.
§ If required, you must adapt the signal length manually when you change the
data type. Refer to Length on page 428.
Additionally, the coded base data type affects settings of the Counter Signal
feature. If you change the coded base data type while the Counter Signal
feature is already added to instances of the ISignal, you might have to adapt
counter settings. Refer to Working with Counter Signals on page 223.

Category (Coded Type) Lets you specify the category of the ISignal, i.e., the
signal type:

Value Description
STANDARD_LENGTH_TYPE The ISignal is a standard ISignal, i.e., a scalar.
ARRAY_TYPE The ISignal is an array signal, i.e., a vector. The number of
vector elements is derived from the specified signal length.
This type is available only if the coded base data type is
UInt8.

The specified category determines the valid length range of the ISignal. If
required, you must adapt the signal length manually when you change the
category. Refer to Length on page 428.

Base data type (Physical Type) Lets you specify the base data type for the
physical signal value. For an overview of the valid values, refer to Supported
signal data types on page 59. For an introduction to coded and physical signal
values, refer to Signal Conversion by the Bus Manager on page 60.
The physical base data type influences the ISignal as follows:
§ It determines if you can add the Counter Signal and ISignal Offset Value
features to instances of the ISignal. For the Counter Signal feature, the
physical base data type additionally influences some counter settings.
§ For the function ports of the ISignal Value, ISignal Overwrite Value, and
ISignal Offset Value features, the physical base data type determines:
§ The data type and the value range of the function ports.
§ The saturation range (if available)
If you change the physical base data type while the bus configuration features
are already added to instances of the ISignal, the relevant properties are

430
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Configurable Settings of ISignals

automatically updated and saturated, if required. However, conflicts might occur.

For more information on the bus configuration features, refer to:
§ Working with ISignal Values on page 221
§ Working with Counter Signals on page 223
§ Overwriting ISignal Values on page 228
§ Adding Offset Values to ISignal Values on page 231

Specifying user-defined Depending on the specifications in the communication matrix, the Properties
settings for computation Browser provides access to the computation methods and the computation
scales scales of ISignals. For ISignals with a computation method whose Interpreted
category is set to LINEAR, the Properties Browser provides the following
properties for specifying user-defined settings for the computation scale.

Numerators Lets you specify the numerator array of a linear computation

scale. The specified array must comply with the following rules:
§ The array must contain at least two elements and the second element must
not be 0.
§ If the array contains a third element, it and all following elements must be 0.

Denominators Lets you specify the denominator array of a linear

computation scale. The specified array must comply with the following rules:
§ The first element of the array must not be 0.
§ If the array contains a second element, it and all following elements must be 0.

For more information on computation methods and computation scales, refer to

Signal Conversion by the Bus Manager on page 60.

Specifying user-defined The Properties Browser provides the following properties for specifying user-
settings for ISignal-to-IPDU defined settings for the ISignal-to-IPDU mapping of ISignals.
mappings
Start bit position Lets you specify the position of the ISignal's start bit within
the related ISignal IPDU. The value is the number of the related bit in the payload
of the ISignal IPDU.
You must specify a start bit position ≥ 0. The valid maximum start bit position
depends on various factors, for example:
§ The usable payload length of the related ISignal IPDU.
§ The ISignal length.
§ The endianness of the ISignal.

Tip

If you specify a start bit position that is invalid in the context in which the
ISignal is used, conflicts occur. The conflicts can help you specify a valid start
bit position for the specific context. Refer to Basics on Bus Manager-Related
Conflicts on page 163.

431
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Modifying Communication Matrices

Endianness Lets you specify the endianness, i.e., the byte order of the ISignal
within the related ISignal IPDU and the ISignal's start bit:

Value Description
Little endian The least significant byte of the ISignal is stored first and the least
significant bit is the start bit.
Big endian The most significant byte of the ISignal is stored first and the most
significant bit is the start bit.
Opaque The byte order is similar to the Little endian format.

The following illustration shows the different layouts resulting from a Little
endian and Big endian endianness for an ISignal with 10 bits and a start bit
position of 3.

ISignal IPDU: Byte 0 1

ISignal IPDU: Bit 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8
Start bit position

ISignal with little endian 24 23 22 21 20 - - - - - - 29 28 27 26 25

ISignal with big endian - - - - 29 28 27 26 25 24 23 22 21 20 - -

For array signals (i.e., ISignals with Category set to ARRAY_TYPE), only Little
endian and Opaque are supported as the endianness.

Transfer property Lets you specify the transfer property of the ISignal.
If the Use transfer property property of the bus configuration is set to True,
the setting of the transfer property determines if and how the ISignal can trigger
the transmission of the PDU in which it is included. For more information, refer
to Using Event‑Controlled Timings for Transmitting PDUs on page 136.
You can specify the transfer property as follows:

Value Description
<empty value> The ISignal does not trigger the transmission of the PDU.
Pending
Tip

If a DBC communication matrix specifies Cyclic for the

GenSigSendType attribute, the Bus Manager maps this to
Pending.

Triggered with The ISignal triggers the transmission of the PDU with repetitions when
repetition the coded signal value has changed.
Triggered on However, transmission with repetitions is possible only if an
change with event‑controlled timing is specified for the PDU. If no event‑controlled
repetition timing is specified, the ISignal triggers only a single transmission.

Triggered The ISignal triggers a single transmission of the PDU when the coded
without signal value has changed.
repetition
Triggered on
change
without
repetition

432
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Configurable Settings of ISignals

Concerning the evaluation of the transfer property, some limitations apply. Refer
to Limitations for transmitting PDUs according to event‑controlled timings on
page 520.

433
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Modifying Communication Matrices

434
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Replacing Assigned Communication Matrices

Replacing Assigned Communication Matrices

Where to go from here Information in this section

Basics on Replacing Assigned Communication Matrices......................... 435

How to Replace Assigned Communication Matrices............................... 438

Basics on Replacing Assigned Communication Matrices

Use scenario Communication matrices are often subject to change. To adjust a bus
configuration to a communication matrix that was modified externally from
ConfigurationDesk, you can replace an assigned communication matrix with the
modified communication matrix.

General replacing rules You can replace a communication matrix only with a communication matrix that
is not already assigned to the related bus configuration. When you replace a
communication matrix, this affects the following:
§ Only the communication matrix elements that are assigned to the selected bus
configuration.
Elements of other communication matrices that are assigned to the bus
configuration and other bus configurations remain unchanged.
§ All bus configuration parts (Bus Access Requests, Simulated ECUs,
Inspection, Manipulation) of the selected bus configuration that contain
elements of the communication matrix, regardless for which part you replace
the matrix.

When you replace a currently assigned communication matrix, the Bus Manager
compares the assigned elements of this communication matrix with the elements
specified in the newly assigned communication matrix. Elements that can
unambiguously be identified are replaced, all the other elements are either left
unchanged or ignored.

435
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Replacing Assigned Communication Matrices

Due to the changes between the replaced and newly assigned communication
matrix, the replacement might result in conflicting bus configurations. The
conflicts are displayed in the Conflicts Viewer. For more information, refer to
Basics on Bus Manager-Related Conflicts on page 163.

Replacing elements in a bus Conditions for replacing elements The Bus Manager compares the names
configuration and the position in the bus hierarchy of the currently assigned elements with
the newly assigned communication matrix. The currently assigned elements are
replaced if:
§ The elements are found in both the bus configuration and the newly assigned
communication matrix.
§ The following definitions match:
§ Communication cluster (not compared for elements of DBC and LDF
communication matrices)
§ ECU (only compared for communication matrix elements that are assigned
to the Simulated ECUs part)
§ Frame
§ Channel
§ Direction (only compared for TX and RX elements, such as PDUs or ISignals)
§ Element name (e.g., PDU name, ISignal name)

Effects on element settings In general, settings of elements that are

replaced by the newly assigned communication matrix are derived from the new
communication matrix (e.g., communication cluster baud rates, PDU lengths, or
initial ISignal values). If you specified user-defined settings, the effects depend on
the setting and/or the element you specified it for. The following table provides
an overview of the effects.

User-Defined Settings Effects Further Information

User-defined initial values of The user-defined initial values remain unchanged or are Specifying initial values on
function ports automatically saturated if necessary (e.g., due to a changed page 198
function port data type).
User-defined saturation values The user-defined saturation values remain unchanged or are Specifying saturation values for
of function ports automatically saturated if necessary (e.g., due to a changed function inports on page 201
function port data type).
User-defined settings of The user-defined settings are not transferred to the newly Basics on Modifying
communication matrix assigned communication matrix. Thus, the user-defined Communication Matrices on
elements settings are lost for the replaced elements. page 391

Leaving elements in a bus Elements of the replaced communication matrix that are assigned to the
configuration unchanged bus configuration but cannot unambiguously be identified in the newly
assigned communication matrix remain unchanged. They are moved to a new
communication matrix node named <communication matrix node name>
(deprecated <number>).

The elements of the deprecated node are still part of the bus configuration
and are used in the signal chain with their previously configured settings (e.g.,

436
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Basics on Replacing Assigned Communication Matrices

user-defined settings and mappings to model port blocks remain unchanged).

You can, for example:
§ Explore the deprecated node to check which elements can no longer be used
with the newly assigned communication matrix.
§ Delete the deprecated node from the bus configuration if you do not need its
elements anymore.
§ Configure the deprecated node if you still need some or all of its elements in
the bus configuration (e.g., rename the node, assign bus accesses to its bus
access requests etc.).

Ignoring elements of Elements of the newly assigned communication matrix that are not found in the
the newly assigned bus configuration are ignored and not assigned to the bus configuration. For
communication matrix example, if an ISignal IPDU of the replaced communication matrix is assigned to
the bus configuration and the newly assigned communication matrix defines
new ISignals or frame triggerings for this IPDU, the new elements are not
assigned to the bus configuration. If you want to use the new elements, you
have to assign them manually.

Note

You can access some communication matrix elements, such as frame

triggerings, only via the Properties Browser when you select the related
higher-level element (e.g., in the Buses Browser). To assign such elements
to a bus configuration, you have to drag the related higher-level element to
the bus configuration.

Effects on the name of When you replace an assigned communication matrix in a bus configuration, the
communication matrix nodes name of the communication matrix node remains unchanged. Therefore, the bus
configuration structure remains unchanged regarding the communication matrix
nodes. If you work with test automation scripts later on, for example, you do not
have to adjust the scripts.

Tip

If you work with DBC or LDF communication matrices, the same applies
to the name of the communication cluster node, which is available for
elements that are assigned to the Inspection or Manipulation part of the
bus configuration.

For details on node names, refer to Element identification via node names on
page 102.

Effects on the model interface Model port blocks that are mapped to the bus configuration are not updated
automatically. You must update the model interface (e.g., delete obsolete model
port blocks or add new model port blocks).

437
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Replacing Assigned Communication Matrices

Tip

If you work with a MATLAB®/Simulink® behavior model and

MATLAB/Simulink and Model Interface Package for Simulink are
installed, ConfigurationDesk can update the model port blocks in
ConfigurationDesk and the Simulink model. However, when you do
this, it is recommended that you protect parts of your Simulink model
from being accidentally changed by setting subsystems to read-only in
Simulink. For more information, refer to Handling the Model Interfaces of
ConfigurationDesk and Simulink Behavior Models (ConfigurationDesk Real-
Time Implementation Guide ).

Limitations When you replace an assigned communication matrix, some limitations apply.
Refer to Limitations for Bus Configuration Handling on page 531.

Related topics Basics

Accessing Bus Manager Features via the ConfigurationDesk Automation Interface.................. 152

How to Replace Assigned Communication Matrices

Objective To update a bus configuration to a new version of an assigned communication

matrix, you can replace the assigned communication matrix.

Preconditions § Two or more communication matrices must be available in the

ConfigurationDesk application.
§ Communication matrix elements must be assigned to a bus configuration.

Method To replace an assigned communication matrix

1 Switch to the Buses view set if necessary.
2 Select the Bus Configurations table.

Tip

You can also select the Bus Access Requests table.

3 Expand the Simulated ECUs, Inspection, Manipulation, or Bus Access

Requests node down to the level of the communication matrix nodes.
4 Select the communication matrix node for which you want to replace the
assigned communication matrix.

438
ConfigurationDesk Bus Manager Implementation Guide May 2024
 How to Replace Assigned Communication Matrices

5 Right-click the selected node and select Communication Matrix

Assignment - <communication matrix name> on the context menu.

Tip

On the context menu, the currently assigned communication matrix is

unavailable and marked by a symbol.

Result You replaced the previously assigned communication matrix with the selected
communication matrix. The replacement affects all bus configuration parts of the
selected bus configuration that have at least one element of the communication
matrix assigned.

Elements that are assigned to the bus configuration and that can be
unambiguously identified in the newly assigned communication matrix are
replaced. Elements that cannot be unambiguously identified in the newly
assigned communication matrix are moved to a new communication matrix
node named <communication matrix node name> (deprecated <number>).
Elements that are part of only the newly assigned communication matrix but not
of the bus configuration are not assigned.

For the communication matrix node, the Properties Browser displays the name
of the newly assigned communication matrix.

439
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Replacing Assigned Communication Matrices

Tip

If more than one communication matrix is assigned to the bus

configuration, the assigned elements of the other communication matrices
are not affected by the replacement.

440
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Working with the Bus Manager Demos

Working with the Bus Manager Demos

Where to go from here Information in this section

Introduction to the Bus Manager Demos............................................... 442

Working with the Bus Manager Basics Demo......................................... 448

Working with the Bus Manager SecOC Demo........................................ 471

441
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with the Bus Manager Demos

Introduction to the Bus Manager Demos

Where to go from here Information in this section

Overview of the Bus Manager Demos.................................................... 442

How to Run a Selected Bus Manager Demo Python Script via

ConfigurationDesk................................................................................ 443

Running a Selected Bus Manager Demo Python Script via an

External Interpreter................................................................................ 445

Overview of the Bus Manager Demos

Introduction Two Bus Manager demos are available:

§ Bus Manager Basics demo
The Bus Manager Basics demo introduces you to the basic steps of accessing
the Bus Manager and configuring simple bus communication. Refer to
Introduction to the Bus Manager Basics Demo on page 448.
§ Bus Manager SecOC demo
The Bus Manager SecOC demo introduces you to implementing secure
onboard communication in an executable application by using the Bus
Manager. Refer to Introduction to the Bus Manager SecOC Demo on
page 471.

Both Bus Manager demos use automation to access the Bus Manager and
configure the bus communication. To work with the Bus Manager demos, you
have to run the related Bus Manager demo Python scripts.

Running the Bus Manager There are two methods for running the Bus Manager demo Python scripts:
demo Python scripts § Running the Bus Manager demo Python scripts via ConfigurationDesk.
Refer to How to Run a Selected Bus Manager Demo Python Script via
ConfigurationDesk on page 443.
§ Running the Bus Manager demo Python scripts from outside
ConfigurationDesk via an external interpreter, such as Python.exe. Refer
to Running a Selected Bus Manager Demo Python Script via an External
Interpreter on page 445.

442
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Introduction to the Bus Manager Demos

How to Run a Selected Bus Manager Demo Python Script via

ConfigurationDesk

Objective To run a selected Bus Manager demo Python script via ConfigurationDesk.

Preconditions § The Bus Manager, ConfigurationDesk - CAN Module, and

ConfigurationDesk - LIN Module licenses are available and accessible.
Refer to Required Licenses (ConfigurationDesk Getting Started ).
§ You started ConfigurationDesk and no unsaved project is open.

Method To run a selected Bus Manager demo Python script

1 On the Automation ribbon, click Run Script.

The Run Script dialog opens.

2 In the Run Script dialog, click the Browse button next to File name and
navigate to the Python demo script you want to run:
§ Bus Manager Basics demo: ConfigurationDesk Documents folder -
BusManagerBasicsDemo folder - BusManagerBasicsDemo.py file
§ Bus Manager SecOC demo: ConfigurationDesk Documents folder -
BusManagerSecOCDemo folder - BusManagerSecOCDemo.py file
3 Select the related Python file and click Open.

4 In the Run Script dialog, click Run.

The selected Bus Manager demo Python script is executed. This takes a
while. After the execution has finished, ConfigurationDesk displays the
Buses view set, as shown in the following example. The Message Viewer
displays the steps initiated by the demo script.

443
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with the Bus Manager Demos

5 On the View ribbon, click Show Panes - Interpreter.

The Interpreter opens. It displays version information on the script, steps

initiated by the script, and potential error messages.

Result You run the selected Bus Manager demo Python script via ConfigurationDesk
and the related Bus Manager demo is set up.

444
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Introduction to the Bus Manager Demos

Next steps You can now work with the related Bus Manager demo. Refer to:
§ Bus Manager Basics demo: Working with the Bus Manager Basics Demo on
page 448
§ Bus Manager SecOC demo: Working with the Bus Manager SecOC Demo on
page 471

Running a Selected Bus Manager Demo Python Script via an External

Interpreter

Introduction You can run a selected Bus Manager demo Python script from outside
ConfigurationDesk via an external interpreter, such as Python.exe, which is
included in the dSPACE Python distribution. If you want to do this, you have
to adapt the related Bus Manager demo Python script.

Note

dSPACE is not responsible for the correct functioning of the Bus Manager
demos once you make changes to the Python scripts.

For an overview of the external interpreters that are included in the dSPACE
Python distribution, refer to Basics on External Interpreters (ConfigurationDesk
Automating Tool Handling ).

Preconditions § To access a Bus Manager demo Python script, you must have started
ConfigurationDesk at least once. By this, the Documents folder is set up.
§ To run a Bus Manager demo Python script, the Bus Manager,
ConfigurationDesk - CAN Module, and ConfigurationDesk - LIN Module
licenses must be available and accessible. Refer to Required Licenses
(ConfigurationDesk Getting Started ).

Adapting a Bus Manager To run a Bus Manager demo Python script via an external interpreter, you have to
demo Python script adapt the script as follows:
1. Navigate to the required Bus Manager demo Python script:
§ Bus Manager Basics demo: ConfigurationDesk Documents folder -
BusManagerBasicsDemo folder - BusManagerBasicsDemo.py file
§ Bus Manager SecOC demo: ConfigurationDesk Documents folder -
BusManagerSecOCDemo folder - BusManagerSecOCDemo.py file
2. Open the related Python file in an editor.
3. Go to the def CreateApplication(self) code line.

445
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with the Bus Manager Demos

4. In the definition of the CreateApplication method, do the following:

§ Remove the #, including the
whitespace before globals()['Application'] =
Dispatch('ConfigurationDesk.Application').
§ If there is no # before globals()['Application'] =
Dispatch('BusManager.Application'), add it.
The resulting code looks as follows:
1 def CreateApplication(self):
2 ...
3 globals()['Application'] = Dispatch('ConfigurationDesk.Application')
4 # globals()['Application'] = Dispatch('BusManager.Application')

5. Save the Python file.

Running the demo script After you adapted the Python file, you can run the script via an external
interpreter.

When you run the script, it starts ConfigurationDesk and sets up the related Bus
Manager demo.

The script execution takes a while. After the script has finished,
ConfigurationDesk displays the Buses view set, as shown in the following
example. The Message Viewer displays the steps initiated by the demo script.

446
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Introduction to the Bus Manager Demos

Next steps You can now work with the related Bus Manager demo. Refer to:
§ Bus Manager Basics demo: Working with the Bus Manager Basics Demo on
page 448
§ Bus Manager SecOC demo: Working with the Bus Manager SecOC Demo on
page 471

447
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with the Bus Manager Demos

Working with the Bus Manager Basics Demo

Where to go from here Information in this section

Introduction to the Bus Manager Basics Demo....................................... 448

Overview of the Example Used in the Bus Manager Basics Demo........... 449

Steps of the Bus Manager Basics Demo Python Script............................ 452

How to Replace the SIC Files in the Bus Manager Basics Demo.............. 462

Example of Experimenting with the Bus Manager Basics Demo in

ControlDesk.......................................................................................... 463

Introduction to the Bus Manager Basics Demo

Overview The Bus Manager Basics demo illustrates the basic steps of using a Python
automation script to configure bus communication with the Bus Manager and
build a real-time application.

The demo is based on a simple example of door and window mechanisms of a

car.

Demonstrated features The Bus Manager Basics demo covers the following features of the Bus Manager:
§ Adding bus configurations and communication matrices to a
ConfigurationDesk application
§ Assigning communication matrix elements to the bus configurations
§ Configuring the bus configurations

The demo also covers several ConfigurationDesk features not specific to the Bus
Manager, such as creating projects and ConfigurationDesk applications, adding
Simulink® implementation containers, and building a real-time application.

Demo files The Bus Manager Basics demo files are located in the BusManagerBasicsDemo
subfolder of the ConfigurationDesk Documents folder . Specifically, these are:

File Description
BusManagerBasicsDemo.py The Python script that sets up the Bus Manager Basics demo in ConfigurationDesk. For
more information, refer to:
§ Running the Bus Manager demo Python scripts on page 442
§ Steps of the Bus Manager Basics Demo Python Script on page 452
BusManagerBasicsDemo.arxml The communication matrix of the simulated bus network.

448
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Working with the Bus Manager Basics Demo

File Description
§ CentralGatewayECU_64‑bit.sic The Simulink implementation containers that are used in the Bus Manager Basics
§ EngineAndBodyECUs_64‑bit.sic demo:
§ CentralGatewayECU_32‑bit.sic § The CentralGatewayECU_64‑bit.sic and EngineAndBodyECUs_64‑bit.sic files
§ EngineAndBodyECUs_32‑bit.sic are added to the ConfigurationDesk application by the demo script.
§ The CentralGatewayECU_32‑bit.sic and EngineAndBodyECUs_32‑bit.sic files
can be used to replace the SIC files that are added by the demo script. This is
necessary if you want to generate an executable application and your simulation
platform requires a 32‑bit target architecture.
§ CentralGatewayECU.slx The Simulink models on which the SIC files are based.
§ EngineAndBodyECUs.slx

Overview of the Example Used in the Bus Manager Basics Demo

Use cases The Bus Manager Basics demo lets you build an application to simulate locking
and unlocking the front doors of a car as well as opening and closing the side
windows.

Specifically, this includes the following use cases:

§ Centrally locking/unlocking the doors
§ Automatic central locking
§ Locking/unlocking the doors individually
§ Opening/closing the side windows

To illustrate the functionality of the demo, the automatic central locking use case
is explained in more detail below.

ECUs and communication The example used in the Bus Manager Basics demo consists of five ECUs that
clusters are members of three communication clusters :

Communication Cluster ECUs

CAN Powertrain § Central Gateway
§ Gearbox
CAN Body § Central Gateway
§ Body Control
LIN Door § Body Control
§ Door Left
§ Door Right

The Gearbox ECU, Body Control ECU, and the Door ECUs are part of a restbus
simulation, while the Central Gateway ECU simulates a real ECU.

The following illustration shows the ECUs and how they are organized
in communication clusters. The grayed-out elements are contained in the
communication matrix of the Bus Manager Basics demo, but are not used
in the demo.

449
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with the Bus Manager Demos

Real ECU

Central Gateway ECU

CAN Powertrain CAN Body

Restbus
simulation
Body Control ECU
Engine LIN Door
ECU
Seat ECU Door Left
Left ECU
Gearbox
ECU Seat ECU Door Right
Right ECU

Functionality The following illustration summarizes the functionality of the Bus Manager Basics
demo. It shows all relevant signals together with their directions and associated
ECUs. The labels inside the Body Control, Central Gateway, and Door ECUs
represent internal ports of the corresponding Simulink® models, which are not
accessible in ConfigurationDesk. Their values can be displayed as part of an
experiment in ControlDesk, for example.

450
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Working with the Bus Manager Basics Demo

Gearbox

CAN
Engine Speed [km/h]
Powertrain

Central Gateway
Car Locking Info
Car Unlocking Info

DoorLeftClosed
DoorLeftLocked
CAN
Speed [km/h] DoorRightClosed
Body DoorRightLocked
Lock/UnlockCar

Body Control
Automatic Central Locking

Lock/UnlockCar Lock/UnlockCar
Open/CloseWindowLeft Open/CloseWindowRight
LIN
DoorLeftClosed Door DoorRightClosed
DoorLeftLocked DoorRightLocked
Door Left Door Right
Window Position Window Position
DoorLeftToOpenWindowRight
DoorLeftToCloseWindowRight

451
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with the Bus Manager Demos

Automatic central locking The following schematic illustrates the signal

sequencing of the automatic central locking use case.
4 4
DoorLeftLocked=1 DoorLeftLocked=0
DoorRightLocked=1 Door Left/Right DoorRightLocked=0
ECU
1 DoorLeft/RightClosed=1

Body Control ECU

2 Automatic Central Locking=1

Speed > 10 km/h Speed £ 10 km/h

LockCar=1 3 LockCar=0

4 CarLockingInfo=1 Central Gateway ECU CarLockingInfo=0 4

(5 sec)

1. When one of the doors is closed, the Body Control ECU receives the
DoorLeft/RightClosed signal with a value of 1 from the Door Left/Right
ECUs.
2. The Body Control ECU sets the internal Automatic Central Locking flag
to 1.
3. If the Speed signal exceeds 10 km/h, the Body Control ECU sends the
LockCar signal with a value of 1 to the Door ECUs and to the Central
Gateway ECU.
4. The Central Gateway ECU sets the internal CarLockingInfo port to 1 for
five seconds to indicate the locking procedure in the cockpit. As soon as the
doors are locked, the Door ECUs send the DoorLocked signals with a value
of 1.

Steps of the Bus Manager Basics Demo Python Script

Overview When you run the Bus Manager Basics demo Python script, it executes the
following steps:

Steps of the Python Script Refer to ...

A new project is created along with a ConfigurationDesk Creating a new ConfigurationDesk project and application on
application. page 453
Two Simulink® implementation containers are added to the Adding Simulink implementation containers on page 454
ConfigurationDesk application.
A hardware topology is created. Creating a hardware topology on page 455
A communication matrix is added to the ConfigurationDesk Adding a communication matrix on page 455
application.
Two bus configurations are added to the ConfigurationDesk Adding bus configurations on page 456
application.

452
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Working with the Bus Manager Basics Demo

Steps of the Python Script Refer to ...

Communication matrix elements are assigned to the bus Assigning communication matrix elements to bus
configurations. configurations on page 456
The bus configuration function ports are configured. Configuring bus configuration function ports on page 457
Function ports are mapped to model ports. Mapping function ports to model ports on page 458
Bus function blocks are assigned to bus access requests and Adding and configuring bus function blocks on page 458
configured.
A 12 V power supply for the LIN controller is added as an Adding an external device and connecting the CAN controllers
external device and the CAN controllers are connected. on page 459
A preconfigured application process is created for each model. Creating application processes on page 460
A real-time application is built. Building a real-time application on page 461

After the execution of the script has finished, you can load the real-time
application to real-time hardware or generate bus simulation containers, for
example. Refer to Next steps on page 461.

Creating a new In the first step, the Python script creates a

ConfigurationDesk project project named BusManagerBasicsDemo, which contains the
and application BusManagerBasicsDemoApplication application as shown in the following
illustration.

If a project with a name containing the BusManagerBasicsDemo string already

exists, the Python script names the new project BusManagerBasicsDemo and
extends it by an increasing number, i.e., BusManagerBasicsDemo_001 and so
on.

The corresponding method is named CreateApplication. It also defines

variables in which the required API components and relations are stored, for
example:
1 self.BusManager = self.ActiveApplication.Components.Item('BusManager')
2 self.BusConfigurationsRelation = self.ActiveApplication.Relations.Item('BusConfigurations')

453
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with the Bus Manager Demos

For more information on the required API components and relations,

refer to ICaComponent <<Collection>> (ConfigurationDesk Automating Tool
Handling ) and ICaRelation <<Interface>> (ConfigurationDesk Automating
Tool Handling ), respectively.

Adding Simulink The LoadSimulinkModel method adds the CentralGatewayECU_64-bit.sic

implementation containers and EngineAndBodyECUs_64-bit.sic files to the application. It takes only the
file name part as its argument, prefixes the current path, and extends the file
name part with the extension .sic, as shown in the following excerpt from the
method definition.
1 def LoadSimulinkModel(self, SimulinkModelFile):
2 ...
3 self.ModelTopology.Configure('AddModel', ['%s\\%s.sic' % (self.CurrentPath, SimulinkModelFile)])
4 ...

The following illustration shows the Model Browser displaying the model
topologies.

In the Model Browser, the _64-bit suffix of the model names is not displayed.
This is because for model implementations with the <model name>_xx-
bit naming scheme, the _xx-bit suffix is omitted in the ConfigurationDesk
application. However, when you select a model in the Model Browser, the
Properties Browser displays the full name of the SIC file, as shown in the
following illustration.

454
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Working with the Bus Manager Basics Demo

Tip

§ The SIC files were generated for a 64‑bit target architecture, i.e., they can
be used with SCALEXIO. MicroLabBox II, and VEOS running on a Linux
64‑bit operating system.
§ Omitting the _xx-bit suffix of the SIC file names also has effects on the
names of the related application processes. Refer to Creating application
processes on page 460.

Creating a hardware topology The global PreferredHardware variable specifies the hardware topology to be
used. It is evaluated by the CreateHardwareTopology method, which sets up
the hardware topology according to the value of PreferredHardware:

Value of PreferredHardware Hardware Topology

None Empty topology
Default (preset) Default SCALEXIO configuration:
§ SCALEXIO Processing Unit
§ DS2680 I/O Unit with a DS2672 Bus Module
§ DS2703 6-Slot Unit with a DS2671 Bus Board
<path to htfx file> As specified in the given htfx file.
<name of registered platform> Corresponding to the registered platform.

Unless PreferredHardware is set to Default, the CreateHardwareTopology

method uses the Configure method of the ConfigurationDesk API
ICaComponent element to set up the hardware topology. The following code
lines illustrate this for the case of a path to a htfx file.
1 if os.path.isabs(os.path.expandvars(PreferredHardware)):
2 self.HardwareTopology.Configure('Create', [1, 'PredefinedHardware', os.path.expandvars(PreferredHardware)])
3 else:
4 htxpath = os.path.abspath(os.path.join(os.path.dirname(self.ActiveProject.FullPath), os.pardir)) +\
5 os.sep + 'PredefinedHardware' + os.sep + PreferredHardware
6 if os.path.exists(htxpath):
7 self.HardwareTopology.Configure('Create', [1, 'PredefinedHardware', htxpath])

The following illustration shows the default hardware topology as displayed in

the Hardware Resource Browser.

For more information on the ICaComponent, refer to ICaComponent

<<Collection>> (ConfigurationDesk Automating Tool Handling ).

Adding a communication The LoadCommunicationMatrix method checks if a communication matrix has

matrix already been added to the ConfigurationDesk application. If this is not the

455
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with the Bus Manager Demos

case, it adds the communication matrix named after the Python script, i.e.,
BusManagerBasicsDemo.arxml, from the current directory, as shown in the
following code listing.
1 def LoadCommunicationMatrix(self)
2 ComMatrixFile = '%s\%s.arxml' % (self.CurrentPath, self.ScriptName)
3 try:
4 # Check whether a communication matrix has already been loaded.
5 if (self.CommunicationMatricesByEcusRelation.GetTopNodes().Count == 0):
6 self.BusManager.Configure('AddCommunicationMatrix', [ComMatrixFile])
7 except com_error as ComError:
8 self.SubmitErrorAndExit('Failed to load communication matrix file named "%s".' % (ComMatrixFile))

Adding bus configurations The bus configuration names are stored in the BusConfigurationName list. The
list is passed to the CreateBusConfiguration method of the Python script,
which adds the bus configurations to the ConfigurationDesk application. The
following code listing shows the relevant lines of the method definition.
1 def CreateBusConfiguration(self, BusCfgName):
2 ...
3 BusConfiguration =\
4 self.BusConfigurationsRelation.CreateDataObject(self.BusConfigurationsRelation.GetCreatableTypes().Item(0))
5 BusConfiguration.Name = BusCfgName
6 ...
7 return BusConfiguration

Assigning communication The AssignEcuToBusCfg method is called with two arguments,

matrix elements to bus BusConfiguration and ECUs. It assigns all communication matrix elements
configurations that belong to the ECUs in the ECUs list to the bus configuration specified
in BusConfiguration. The communication matrix elements contained in the
ExcludeListOfComMatrixElementNames list are excluded. This list is defined
at the start of the Python script.

The following code listing shows the relevant part of the method definition.
1 def AssignEcuToBusCfg(self, BusConfiguration, ECUs):
2
3 CommunicationMatrix = self.CommunicationMatricesByEcusRelation.GetTopNodes().Item(0)
4
5 WriteTransaction = self.OpenTransaction('AssignElements')
6 try:
7 for Ecu in self.CommunicationMatricesByEcusRelation.GetElements(CommunicationMatrix):
8 if (Ecu.Name in ECUs):
9 for Pdu in self.CommunicationMatricesByEcusRelation.GetElements(Ecu):
10 # Check content of bus element exclude list.
11 if (not Pdu.Name in ExcludeListOfComMatrixElementNames):
12 for Signal in self.CommunicationMatricesByEcusRelation.GetElements(Pdu):
13 if (not Signal.Name in ExcludeListOfComMatrixElementNames):
14 self.BusManager.Configure('AssignElements', [[Signal], BusConfiguration])
15 ...

The following illustration shows a part of the Buses view set that displays
the resulting bus configurations in the Bus Configurations table and the
corresponding communication matrix in the Buses Browser.

456
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Working with the Bus Manager Basics Demo

Configuring bus configuration The ActivateModelAndTAAccess method performs the configuration of the
function ports bus configuration function ports:
§ It activates model access for all bus configuration function ports
of the given bus configuration except for those specified in the
ExcludeListOfModelAccessFunctionPortNames list.
§ For the bus configuration function ports with disabled model access, it sets the
initial state of the source switch to the substitute value, i.e., these function
ports are initialized with the value that is specified for their Initial substitute
value property.
§ It enables test automation support for all bus configuration function ports,
without exceptions.

The following code listing shows the relevant part of the method definition:
1 def ActivateModelAndTAAccess(self, BusConfiguration):
2
3 WriteTransaction = self.OpenTransaction('ActivateModelAndTAAccess')
4 ...
5 for FunctionPort in self.BusConfigurationsRelation.FindByXPath('/BusConfiguration[@Name = "' +\
6 BusConfiguration.Name + '"]//FunctionPort'):
7 if (not FunctionPort.Name in ExcludeListOfModelAccessFunctionPortNames):
8 FunctionPort.Properties['IsMappable'].TrySetValue(True)
9 else:
10 # Model access is not enabled. Set the initial switch setting to the substitute value.
11 FunctionPort.Properties['InitialSwitchSetting'].TrySetValue(1)
12 FunctionPort.Properties['IsTestAutomationSupportEnabled'].TrySetValue(True)
13 ...

Enabling LIN communication ConfigurationDesk does not activate LIN

communication by default. The Python script enables LIN communication by
setting the Initial value and Initial substitute value properties of the Schedule
Index function ports to 1:
1 ScheduleIndexes = DemoController.BusConfigurationsRelation.FindByXPath('/BusConfiguration//\
2 BusCommunicationControllerLinScheduleTableAccess/FunctionPort')
3 for SchedulIndex in ScheduleIndexes:
4 SchedulIndex.Properties['InitialValue'].Value = 1
5 SchedulIndex.Properties['InitialSubstituteValue'].Value = 1

The following illustration shows the Schedule Index function port in

the Bus Configurations table and the function port properties in the
Properties Browser. Because the Schedule Index function port is on the

457
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with the Bus Manager Demos

ExcludeListOfModelAccessFunctionPortNames list, Model access is set to

Disabled and Initial switch setting is set to Substitute value.

Mapping function ports to The CreatePortLinks method maps function ports to model ports as shown in
model ports the following excerpt of the method code.

1 def CreatePortLinks(self, BusConfiguration, Model):

2 ...
3 for ModelEcu in Model:
4 EcuName = ModelEcu.Name
5 BusEcus = self.BusConfigurationsRelation.FindByXPath('/BusConfiguration[@Name = "%s"]//BusEcu[@Name =\
6 "%s"]' % (BusConfugration.Name, ModelEcu.Name))
7 if (BusEcus.Count > 0):
8 for ModelPortBlock in ModelEcu:
9 for ModelFunctionPort in ModelPortBlock:
10 # Make sure the model port is not mapped yet.
11 if ModelFunctionPort.Links.Count == 0:
12 xPath = '/BusConfiguration//BusEcu[@Name = "%s"]//FunctionPort[@Name = "%s"\
13 and @PortType != "%s"]' % (ModelEcu.Name, ModelFunctionPort.Name,\
14 str(ModelFunctionPort.Properties['PortType'].Value))
15 BusFunctionPorts = self.BusConfigurationsRelation.FindByXPath(xPath)
16 for BusFunctionPort in BusFunctionPorts:
17 # Make sure the function port is not mapped yet.
18 if BusFunctionPort.Links.Count == 0:
19 self.ActiveApplication.ConnectObjects(BusFunctionPort, ModelFunctionPort)
20 ...

Adding and configuring bus The CreateBusAccess method adds suitable CAN and LIN function blocks to
function blocks the signal chain and assigns them to the bus access requests . By this, the
function blocks specify the bus access of each communication cluster .

The CreateBusAccess method is called with six arguments, which are used
consecutively as follows:
1. BusConfiguration: The bus configuration to which bus function blocks
are assigned.
2. ClusterName: The communication cluster for which the bus function block
is used.
3. BusAccessName: The name of the bus function block.
4. ProtocolName: The bus protocol of the bus function block, i.e., CAN or LIN.

458
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Working with the Bus Manager Basics Demo

5. ChannelSetName: The channel set from which a channel is assigned to the

bus function block.
6. ChannelIndex: The index of the channel that is assigned to the bus
function block.

The following code listing shows the method call for each bus access that has to
be specified. For this, the hardware resources are used as follows:
§ Bus 1 channel type (DS2671 Bus Board): Used for the bus access requests
related to the Central Gateway ECU.
§ CAN 1 and LIN 1 channel types (DS2672 Bus Module): Used for the bus access
requests related to the ECUs of the simulated restbus.
1 DemoController.CreateBusAccess(CentralGatewayConfiguration, 'CanBodyCluster', 'CentralGateway CAN Body
Access', 'CAN', 'Bus 1', 'Channel 1')
2 DemoController.CreateBusAccess(EngineAndBodyConfiguration, 'CanBodyCluster', 'BodyControl CAN Body
Access', 'CAN', 'CAN 1', 'Channel 1')
3 DemoController.CreateBusAccess(CentralGatewayConfiguration, 'CanPowertrainCluster', 'CentralGateway CAN Powertrain
Access', 'CAN', 'Bus 1', 'Channel 2')
4 DemoController.CreateBusAccess(EngineAndBodyConfiguration, 'CanPowertrainCluster', 'Gearbox CAN Powertrain
Access', 'CAN', 'CAN 1', 'Channel 2')
5 DemoController.CreateBusAccess(EngineAndBodyConfiguration, 'LinDoorCluster', 'LIN Door Access', 'LIN', 'LIN
1', 'Channel 1')

CAN transceiver termination The Python script implements termination of

the CAN transceivers in the following lines.
1 TranceiverTerminations =
DemoController.BusConfigurationsRelation.FindByXPath('/BusConfiguration//FunctionBlock/@Termination')
2 for Termination in TranceiverTerminations:
3 Termination.TrySetValue(0)

When you select a CAN function block in ConfigurationDesk, you can access the
related property on the General page of the Properties Browser, as shown in
the following illustration.

Adding an external device The SetupDeviceWiring method creates an external device representing a
and connecting the CAN 12 V power supply and connects it to the LIN controller. This external device
controllers is required if you use a SCALEXIO platform: In this case, the LIN communication
does not work without an external power supply.

459
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with the Bus Manager Demos

Tip

The MicroAutoBox III and MicroLabBox II do not require this external device
because they provide an integrated power supply for LIN communication.

The implementation of the external device in the Python script is analogous to

the setup of the hardware topology.

The following illustration shows the resulting connections in the Signal Chain
Browser.

The SetupDeviceWiring method also connects the CAN controllers, as shown

in the following illustration.

Creating application processes The CreateProcessAndTasks method creates a processing unit application if
none exists yet, and a corresponding preconfigured application process for
each behavior model.

The following illustration shows the result in the Task Configuration table.
The periodic tasks are provided by the behavior models and the CAN tasks are
provided by the CAN function blocks.

460
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Working with the Bus Manager Basics Demo

Tip

The application processes are automatically named after the behavior

models. However, because the _xx-bit suffix of the SIC file names is
omitted in the ConfigurationDesk application, the suffix is not part of the
application process names. This can reduce the efforts for replacing models
in the ConfigurationDesk application to a minimum.

Building a real-time The following code lines start the build process:
application
1 DemoController.ActiveApplication.BuildManagement.Properties['DownloadAfterBuild'].TrySetValue(False)
2 if DemoController.CurrentComApplicationName == 'ConfigurationDesk':
3 DemoController.SubmitInfo('Build started.')
4 DemoController.ActiveApplication.BuildManagement.Build()

Tip

The first code line prevents an automated download of the real-time

application to real-time hardware. If TrySetValue(False) is changed
to TrySetValue(True), the real-time application can automatically be
downloaded to real-time hardware. However, this is possible only if a
matching real-time hardware platform is available and registered.

The build results are saved under

BusManagerBasicsDemo/BusManagerBasicsDemoApplication/Build
Results in the ConfigurationDesk Documents folder .

Next steps You can use the results of the Python script execution to simulate the
functionality of the Bus Manager Basics demo in ControlDesk. There are
two ways to prepare this, depending on whether you use a SCALEXIO,
MicroAutoBox III, MicroLabBox II, or VEOS platform:

SCALEXIO/MicroAutoBox III/MicroLabBox II VEOS

1. Register your SCALEXIO/MicroAutoBox III/MicroLabBox II 1. Replace the SIC files in the ConfigurationDesk application
platform in ConfigurationDesk. Refer to Registering if you use a VEOS platform that runs on one of the
Hardware in ConfigurationDesk (ConfigurationDesk Real- following operating systems:
Time Implementation Guide ). § Windows 32‑bit or 64‑bit
§ Linux 32‑bit
Refer to How to Replace the SIC Files in the Bus Manager
Basics Demo on page 462.

461
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with the Bus Manager Demos

SCALEXIO/MicroAutoBox III/MicroLabBox II VEOS

2. Adapt the following settings according to your 2. Generate bus simulation containers: In ConfigurationDesk,
SCALEXIO/MicroAutoBox III/MicroLabBox II platform: click BSC - Generate on the Home ribbon in the Buses view
§ Only if you use the MicroAutoBox III or MicroLabBox II: set.
Delete the PowerSupply device block from the signal ConfigurationDesk generates one bus simulation container
chain. for each application process and saves the generated bus
§ Only if you use the MicroAutoBox III: Replace the SIC files simulation containers to BusManagerBasicsDemo\
in the ConfigurationDesk application. Refer to How to BusManagerBasicsDemoApplication\Generated
Replace the SIC Files in the Bus Manager Basics Demo on Containers in the ConfigurationDesk Documents folder .
page 462. 3. Import the bus simulation containers to VEOS and integrate
them into an offline simulation application:
§ Adapt the created hardware topology. Refer to Basics
on Hardware Topologies (ConfigurationDesk Real-Time § VEOS on Windows: Save the OSA file to
Implementation Guide ). the VEOS Documents folder and name it
BusManagerBasicsDemoApplication.osa.
§ Adapt the assigned hardware resources of the CAN
and LIN function blocks. Refer to Methods for § VEOS on Linux: Add a new folder to your home
Assigning Hardware Resources (ConfigurationDesk Real- directory and name it BusManagerBasicsDemo. Save
Time Implementation Guide ). the OSA file to this folder and name the file
If you make any changes, you have to build a new real-time BusManagerBasicsDemoApplication.osa.
application. To do this, click Build - Start on the Home Refer to How to Build an Offline Simulation Application
ribbon. (VEOS Manual ).
3. Connect the used CAN channels of your real‑time hardware
Tip
physically:
§ Physically connect the channels you assigned to the When you save the OSA file, VEOS informs you that at
CentralGateway CAN Body Access and BodyControl least one signal is not connected. You can ignore this
CAN Body Access function blocks. because the related signals are not used in the demo
§ Physically connect the channels you assigned to the project.
CentralGateway CAN Powertrain Access and Gearbox
CAN Powertrain Access function blocks. 4. Load the OSA file to VEOS without starting the offline
4. Load the real-time application to the simulation application. Refer to How to Load and Run an
SCALEXIO/MicroAutoBox III/MicroLabBox II platform. Refer Offline Simulation Application (VEOS Manual ).
to How to Load a Real-Time Application (ConfigurationDesk
Real-Time Implementation Guide ).

Once you have loaded the executable application to the simulation platform,
you can use ControlDesk's Bus Navigator to experiment with the bus
communication. Refer to Example of Experimenting with the Bus Manager Basics
Demo in ControlDesk on page 463.

How to Replace the SIC Files in the Bus Manager Basics Demo

Objective The Bus Manager Basics demo uses SIC files that are built for a 64‑bit target
architecture, which can only be used with SCALEXIO, MicroLabBox II, and VEOS
running on a Linux 64‑bit operating system. If you use a VEOS platform that runs
on a different operating system or you use the MicroAutoBox III, you have to
replace the SIC files in the Bus Manager Basics demo.

For basic information on the target architecture of SIC files, refer to Basics on
Simulink Implementation Containers (Model Interface Package for Simulink -
Modeling Guide ).

462
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Working with the Bus Manager Basics Demo

Method To replace the SIC files in the Bus Manager Basics demo
1 Select the Buses view set.
2 In the Model Browser, right‑click CentralGatewayECU and select Replace
Model on the context menu.
The Replace Model dialog opens.
3 In the Replace Model dialog, click Add model - Add model from file.
A standard Open dialog opens.
4 In the Open dialog, navigate to the BusManagerBasicsDemo folder in the
ConfigurationDesk Documents folder .
5 Select CentralGatewayECU_32-bit.sic and click Open.

The dialog closes.

6 In the Replace Model dialog, click OK.
The dialog closes and the model is replaced in the Model Browser.
7 For the EngineAndBodyECUs Simulink® implementation container, repeat
steps 2 … 6 to replace it with the EngineAndBodyECUs_32-bit.sic file.

Result You replaced the SIC files in the Bus Manager Basics demo.

Example of Experimenting with the Bus Manager Basics Demo in ControlDesk

Introduction This example illustrates how you can experiment with the results of the Bus
Manager Basics demo Python script execution in ControlDesk.

The example is based on the automatic central locking scenario described in

Automatic central locking on page 452.

Preconditions § You built a real-time application of the Bus Manager Basics demo and loaded
it to a SCALEXIO, MicroAutoBox III, or MicroLabBox II platform.
- OR -
§ You generated bus simulation containers, built an offline simulation
application, and loaded it to VEOS.

463
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with the Bus Manager Demos

§ You have a decrypted installation of ControlDesk. For information on installing

and decrypting dSPACE software, refer to Installing dSPACE Software .

For information on building the executable application and loading it to the

simulation platform, refer to Next steps on page 461.

Workflow The example consists of the following parts:

§ Preparing an experiment in ControlDesk. Refer to Part 1 on page 464.
§ Preparing a layout in ControlDesk. Refer to Part 2 on page 466.
§ Experimenting and measuring in ControlDesk. Refer to Part 3 on page 469.

Part 1 To prepare an experiment in ControlDesk

1 Start ControlDesk.
2 Register VEOS or the SCALEXIO/MicroAutoBox III/MicroLabBox II platform.

3 Create a new project and experiment. The settings depend on whether you
use VEOS, SCALEXIO, MicroAutoBox III, or MicroLabBox II.

Project Experiment Platform Variable Description File

BusManagerBasicsDemo VEOS Simulation VEOS § VEOS on Windows: <VEOS Documents folder>\
BusManagerBasicsDemoApplication.sdf
§ VEOS on Linux: ~/BusManagerBasicsDemo/
BusManagerBasicsDemoApplication.sdf
BusManagerBasicsDemo SCALEXIO Simulation SCALEXIO <ConfigurationDesk Documents folder>\
BusManagerBasicsDemo\
BusManagerBasicsDemoApplication\
Build Results\
BusManagerBasicsDemoApplication.sdf
BusManagerBasicsDemo MicroAutoBox III Simulation MicroAutoBox III <ConfigurationDesk Documents folder>\
BusManagerBasicsDemo\
BusManagerBasicsDemoApplication\
Build Results\
BusManagerBasicsDemoApplication.sdf
BusManagerBasicsDemo MicroLabBox II Simulation MicroLabBox II <ConfigurationDesk Documents folder>\
BusManagerBasicsDemo\
BusManagerBasicsDemoApplication\
Build Results\
BusManagerBasicsDemoApplication.sdf

464
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Working with the Bus Manager Basics Demo

After you finish, the Project Manager and the Platforms/Devices

controlbar look as shown in the following examples.

Example of a VEOS Platform Example of a SCALEXIO Platform

4 In the Project Manager, right-click the platforms and rename them via the
Rename Platform/Device context menu command as follows:
§ Rename the platform to which the CentralGatewayECU.trc file is loaded
to CentralGatewayECU_Platform.
§ Rename the platform to which the EngineAndBodyECUs.trc file is
loaded to EngineAndBodyECUs_Platform.
The following illustration is an example of the renamed platforms.

465
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with the Bus Manager Demos

Interim result You created a project and experiment in ControlDesk. You can now prepare a
layout. Continue with the next part.

Part 2 To prepare a layout in ControlDesk

1 Select the Bus Navigator.
The Bus Navigator displays a hardware‑related view
on the bus communication that is accessed via the
BusManagerBasicsDemoApplication.sdf file, starting with the platforms
to which the bus communication of the CentralGatewayECU.trc and
EngineAndBodyECUs.trc files are loaded.

Tip

The illustration above is an example of the Bus Navigator tree for a

VEOS simulation platform. Depending on the used simulation platform,
the following elements differ:
§ The extension of the platform name, i.e., the value in the brackets.

§ The names of the communication controllers.

2 In the Bus Navigator, select the following PDU for

EngineAndBodyECUs_Platform [<xxx>]: LinDoorCluster - DoorLeftEcu
- DoorLeftStatusLinFrame - DoorLeftStatusIPdu.

466
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Working with the Bus Manager Basics Demo

3 Right-click DoorLeftStatusIPdu and select Generate TX Layout on the

context menu.
A new layout with a Bus Instrument (TX type) is generated.
4 For LinDoorCluster, select the following PDU: DoorRightEcu -
DoorRightStatusLinFrame - DoorRightStatusIPdu.

5 Drag the PDU to an empty area of the layout.

A list opens.
6 From the list, select Bus Navigator TX Instrument to add a Bus Instrument
(TX type) to the layout.
7 For EngineAndBodyECUs_Platform [<xxx>], proceed as in steps 5 and 6
to add Bus Instruments (TX type) for the following PDUs to the layout:
§ CanBodyCluster - BodyControlEcu - CarLockControlCanFrame -
CarLockControlIPdu
§ CanPowertrainCluster- GearboxEcu - GearboxInfoFrame -
GearboxInfoIPdu

467
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with the Bus Manager Demos

8 Arrange the instruments as follows:

9 In the CarLockControlIPdu instrument, select the Value function port of

LockCarISignal.
10 Right-click Value and select Variables - Copy to Instrument - Variable
Array on the context menu.
A Variable Array is added to the layout, displaying the variables mapped to
the Value function port.
11 In the Variable Array, right-click LockCarISignal Value/MDL_Signal and
select Variables - Copy to Instrument - Time Plotter on the context
menu.
A Time Plotter is added to the layout, displaying MDL_Signal on the y-axis.
12 Arrange the Variable Array and Time Plotter as follows:

13 In the Variables controlbar, navigate to the following block:

BusManagerBasicsDemoApplication.sdf - EngineAndBodyECUs.trc -
Model Root - BodyControlEcu - Automatic Central Locking.

14 In the variable list on the right, right-click Automatic Central Locking and
select Visualize Variables on the context menu.

468
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Working with the Bus Manager Basics Demo

A Time Plotter providing the Automatic Central Locking variable is added

to the layout.
15 Right-click the Time Plotter and select Axis/Signals Properties on the
context menu.
The Axes/signals dialog opens.
16 In the Axes/signals dialog, select Y-Axis and specify Automatic Central
Locking as the Label.

17 Arrange the Automatic Central Locking Time Plotter to the right of the
MDL_Signal Time Plotter.

Interim result You generated Bus Instruments to manipulate signals of the Bus Manager Basics
demo and created Time Plotters to visualize the results. You can now start
experimenting and measuring, i.e., you can access signals and parameters of the
executable application . Continue with the next part.

Part 3 To experiment and measure in ControlDesk

1 On the Home ribbon, click Start Measuring.

ControlDesk starts the measurement.
Actual Value of the Value function ports of DoorLeftClosedISignal and
DoorRightClosedISignal is True, i.e., both doors are closed. However,
Actual Value of the Value function ports of DoorLeftLockedISignal and
DoorRightLockedISignal is False, meaning that neither door is locked yet.

Therefore, the value in the Automatic Central Locking Time Plotter is 1:

As soon as the speed exceeds 10 km/h, the doors can be locked by the
automatic central locking function.

469
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with the Bus Manager Demos

2 In the GearboxInfoIPdu instrument, specify the following settings for the

Value function port of SpeedISignal:

Element Setting
Substitute Value 11
Source Switch Substitute value

The speed exceeds 10 km/h and the automatic central locking function
locks the doors: MDL_Signal of LockCarISignal briefly switches to 1 and
Actual Value of the Value function ports of DoorLeftLockedISignal and
DoorRightLockedISignal is True. After the doors are locked, Automatic
Central Locking switches to 0.

3 On the Home ribbon, click Stop Measuring.

Result You simulated automatic central locking in ControlDesk.

470
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Working with the Bus Manager SecOC Demo

Working with the Bus Manager SecOC Demo

Where to go from here Information in this section

Introduction to the Bus Manager SecOC Demo...................................... 471

Overview of the Example Used in the Bus Manager SecOC Demo.......... 473

Steps of the Bus Manager SecOC Demo Python Script........................... 475

Definitions in the UserCode_SecOCDemo.c File..................................... 481

Example of Experimenting with the Bus Manager SecOC Demo in

ControlDesk.......................................................................................... 488

Introduction to the Bus Manager SecOC Demo

Overview The Bus Manager SecOC demo illustrates the basic steps for implementing
secure onboard communication in a real-time application and in bus simulation
containers by using a Python automation script.

Demonstrated features The Bus Manager SecOC demo covers the following features for implementing
secure onboard communication in the ConfigurationDesk application and in
executable applications :
§ Enabling the SecOC support for bus configurations.
§ Assigning secured IPDUs and authentic IPDUs to bus configurations.
§ Adding bus configuration features to the secured IPDUs that let you do the
following at run time:
§ Manipulate the authentication information before it is transmitted.
§ Verify the received authentication information.
§ Adding the required user code files to the ConfigurationDesk application. At
run time, the authentication information is calculated and verified according to
the specifications in the user code files.

Moreover, the demo covers several features that are not specific
for implementing secure onboard communication, such as creating a
ConfigurationDesk project and application, modifying the communication matrix
in the ConfigurationDesk application, and building a real‑time application and
generating bus simulation containers.

Demo files The Bus Manager SecOC demo files are located in the
BusManagerSecOCDemo subfolder of the ConfigurationDesk Documents
folder . The following table provides a brief overview of the files.

471
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with the Bus Manager Demos

Note

§ You can use the source and header files as a starting point to write your
own user code. If you do this, dSPACE is not responsible for the correct
functioning of your user code.
§ dSPACE is not responsible for the correct functioning of the Bus Manager
SecOC demo once you make changes to the demo files.

Tip

For further information on the specifications in the source and header files
listed in the table, refer to the descriptions that are included in the files.

File Description
BusManagerSecOCDemo.py The Python script that sets up the Bus Manager SecOC demo in ConfigurationDesk. For
more information, refer to:
§ Running the Bus Manager demo Python scripts on page 442
§ Steps of the Bus Manager SecOC Demo Python Script on page 475
BusManagerSecOCDemo.arxml The communication matrix with the specifications of the simple secured bus
communication.
§ DsAes.c The source and header files that implement the 128‑bit Advanced Encryption Standard
§ DsAes.h (AES) algorithm. This algorithm is used to generate the message authentication code
(MAC) for secured IPDUs by using a symmetric key.
§ DsCmac.c The source and header files that implement the AES‑CMAC algorithm according to
§ DsCmac.h RFC 4493 and NIST SP800‑38B. This algorithm is used to generate the message
authentication code (MAC) for secured IPDUs by using a symmetric key. The resulting
MAC is cipher‑based (CMAC).
§ DsCmacKey.c The source and header files that implement a simple key handling mechanism that
§ DsCmacKey.h is used to identify, set, and generate a 16-byte encryption key for the AES‑CMAC
algorithm.
§ DsTimeManager.cpp The source and header files that implement functions for reading the current CPU time.
§ DsTimeManager.h The CPU time is used as a seed for the pseudo-random number generator (PRNG) that is
used for generating keys for the AES-CMAC algorithm.
§ UserCode_CsmDemo.c The source and header files of the user code that implement the AUTOSAR Crypto
§ UserCode_CsmDemo.h Service Manager (CSM).
§ UserCode_FvmDemo.c The source and header files of the user code that implement parts of the AUTOSAR
§ UserCode_FvmDemo.h Freshness Value Manager (FVM). The files implement only those specifications of the
Freshness Value Manager that apply to freshness values based on freshness counters.
However, freshness counter synchronization is not implemented.

472
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Working with the Bus Manager SecOC Demo

File Description
§ UserCode_SecOCConfiguration.c The source and header files of the user code that implement a mapping table for
§ UserCode_SecOCConfiguration.h mapping secured IPDUs, authentic IPDUs, and keys. The mapping table is required for the
simple key handling mechanism that is used for the AES-CMAC algorithm.

Tip

The mapping table provides three options for specifying a key:

§ Use a user-defined key for each secured IPDU.
§ Let the user code randomly generate a key with 16 bytes. This option is used in
the Bus Manager SecOC demo.
§ Use a global default key.
In general, a combination of all options can be used in user code. You
can use the mapping table as a template for implementing these options in
your own user code. For more information, refer to the explanations in the
UserCode_SecOCConfiguration.c file.

UserCode_SecOCDemo.c The source file of the user code that implements the algorithms that are used by the
demo for calculating and verifying the authentication information in the executable
application . For more information, refer to Definitions in the UserCode_SecOCDemo.c
File on page 481.
§ UserCode_SecOCHelperDemo.c The source and header files of the user code that implement helper functions that are
§ UserCode_SecOCHelperDemo.h required for the user code of the demo.
UserCode_Types.h The header file of the user code that implements type definitions that are required for
the user code of the demo.

Overview of the Example Used in the Bus Manager SecOC Demo

Scope of the example used in The Bus Manager SecOC demo focuses on the basic steps for implementing
the demo secure onboard communication in a ConfigurationDesk application and in an
executable application by using the Bus Manager. To demonstrate the basic
steps for implementing secure onboard communication, the demo uses a
simple example of secured bus communication. Specifying the secure onboard
communication itself and complex implementation use cases such as model
communication are out of focus of the demo.

Example used in the demo In general, two ECUs are used, one for transmitting and one for receiving
secured IPDUs . The demo uses the IPdu02_FVCounter_secured secured
IPDU, which has the following characteristics:
§ The IPdu02_FVCounter_secured IPDU is a non-cryptographic IPDU, i.e., its
related IPdu02_FVCounter authentic IPDU is included in the secured IPDU
and only one IPDU is transmitted on the bus.
§ A freshness counter is used as the freshness value of the secured IPDU.
§ The authentication information of the secured IPDU is calculated according to
the AES-CMAC algorithm and by using a randomly generated key.

473
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with the Bus Manager Demos

The Bus Manager SecOC demo Python script sets up the following configuration
for the bus communication:

BusConfiguration_TX BusConfiguration_RX

Simulated ECUs Simulated ECUs

ECU_1 ECU_2
IPdu02_FVCounter_secured IPdu02_FVCounter_secured
User code: IPdu02_FVCounter SecOC User code:
Calculate Verify received
PDU Trigger PDU RX Status
authentication authentication
information IPdu02_FVCounter information
PDU RX Status
Manipulation
IPdu02_FVCounter_secured Inspection
SecOC Authenticator Invalidation IPdu02_FVCounter_secured
SecOC Freshness Overwrite Value SecOC
IPdu02_FVCounter IPdu02_FVCounter

IPdu02_FVCounter_secured

IPdu02_FVCounter Authentication information

CANCluster

At run time, the behavior is the following:

TX Side RX Side
The authentication information of the The verification of the received authentication information of
TXIPdu02_FVCounter_secured IPDU is calculated in the the RX IPdu02_FVCounter_secured IPDU can be enabled via
user code. Before the IPDU is transmitted, the calculated the SecOC feature. If enabled, the authentication information
authentication information can be manipulated via the is verified in the user code. The SecOC and PDU RX
SecOC Authentication Invalidation or SecOC Freshness Status features provide the verification state and further state
Overwrite Value features. The transmission of the TX information on the received IPdu02_FVCounter_secured
IPdu02_FVCounter_secured IPDU can be triggered via the PDU IPDU and its related IPdu02_FVCounter authentic IPDU.
Trigger feature of the related IPdu02_FVCounter authentic
IPDU.

Restrictions for verifying Because of the simple freshness value handling in the demo, the following
the received authentication restrictions apply for verifying the received authentication information:
information § On the RX side, any freshness counter value that is equal to or larger than the
previously received freshness counter value is accepted as valid. Therefore, only
a freshness counter value that is smaller than the previously received freshness
counter value results in verification failure.
§ There is no synchronization between the freshness counter values on the
TX side and the RX side. Therefore, the verification always fails once the
transmitted freshness counter value and the expected freshness counter value
differ.
§ In the communication matrix, FRESHNESS-VALUE-TX-LENGTH is set to 8 bits,
i.e., one byte is used for the transmitted freshness counter. Due to this, the
freshness counter overflows when it exceeds 255. This might result in an
unexpected behavior at run time.

474
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Working with the Bus Manager SecOC Demo

Steps of the Bus Manager SecOC Demo Python Script

Overview Tip

Many steps of the Bus Manager SecOC demo Python script are also
executed by the Bus Manager Basics demo Python script.
In this topic, only the steps that are specific for the Bus Manager SecOC
demo Python script are described in detail. For a detailed description of the
steps that are also executed by the Bus Manager Basics demo Python script,
refer to Steps of the Bus Manager Basics Demo Python Script on page 452.

When you run the Bus Manager SecOC demo Python script, it executes the
following steps:

Steps of the Python Script Refer to ...

A new project is created along with a ConfigurationDesk Steps of the Bus Manager Basics Demo Python Script on
application. page 452
A hardware topology is created. Steps of the Bus Manager Basics Demo Python Script on
page 452
A communication matrix is added to the ConfigurationDesk Steps of the Bus Manager Basics Demo Python Script on
application. page 452
Two bus configurations are added to the ConfigurationDesk Adding bus configurations and enabling the SecOC support on
application and the support of secure onboard communication is page 476
enabled for both bus configurations.
The required user code files are added to the Adding user code files on page 476
ConfigurationDesk application.
Communication matrix elements are assigned to the bus Steps of the Bus Manager Basics Demo Python Script on
configurations. page 452
The cyclic timing that is specified in the communication matrix is Modifying the cyclic timing in the communication matrix on
modified. page 477
Bus configuration features are added to IPDUs. Adding bus configuration features to IPDUs on page 478
The recalculation of the authentication information is disabled Disabling the recalculation of authentication information on
for some bus manipulation features. page 478
The bus configuration function ports are configured. Configuring bus configuration function ports on page 479
CAN function blocks are assigned to the bus access Steps of the Bus Manager Basics Demo Python Script on
requests and configured. page 452
An application process that provides a default task is created Creating an application process and assigning it to the bus
and assigned to the bus configurations. configurations on page 479
A real-time application is built. Steps of the Bus Manager Basics Demo Python Script on
page 452
A bus simulation container (BSC file) is generated. Generating bus simulation containers on page 480

After the execution of the script has finished, you can load the real-time
application to real-time hardware or build an offline simulation application to
simulate the functionality of the Bus Manager SecOC demo in ControlDesk.
Refer to Next steps on page 480.

475
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with the Bus Manager Demos

Adding bus configurations The CreateBusConfiguration method adds a bus configuration to the
and enabling the SecOC ConfigurationDesk application. It also enables the support of secure onboard
support communication by setting the Enable SecOC support property of the
bus configuration to True. This is mandatory for each bus configuration
that configures bus communication for secure onboard communication. The
following code listing shows the relevant lines of the method definition.
1 def CreateBusConfiguration(self, BusCfgName):
2 ...
3 BusConfiguration =
4 self.BusConfigurationsRelation.CreateDataObject(self.BusConfigurationsRelation.GetCreatableTypes().Item(0))
5 BusConfiguration.Name = BusCfgName
6 BusConfiguration.Properties['Enable SecOC'].TrySetValue(True)
7 ...

In addition to enable the SecOC support, it is mandatory to reference the user

code ID that is specified in the related user code file. The ID must be referenced
via the SecOC user code ID property. However, this step is not included in the
Python script because the UserCode_SecOCDemo.c file of the demo uses the
default user code ID, i.e., SecOC, which is preset in the SecOC user code ID
property.

The CreateBusConfiguration method is called twice in the

CreateBusManagerSecOCDemo function to add two bus configurations. The bus
configuration names are taken from the BusConfigurationName list:
1 def CreateBusManagerSecOCDemo():
2 ...
3 BusConfiguration_TX = DemoController.CreateBusConfiguration(BusConfigurationName[0])
4 BusConfiguration_RX = DemoController.CreateBusConfiguration(BusConfigurationName[1])
5 ...

The following illustration shows the resulting configuration in the

ConfigurationDesk application.

Adding user code files The AssignSecOCUserCodeFiles method adds the user code files that are
required to perform secure onboard communication to the ConfigurationDesk
application. These files specify the algorithms for calculating and verifying the
authentication information of secured IPDUs . The files are source files (*.c;
*.cpp) and include files (*.h; *.hpp) and must be added via the properties of the
Bus Custom Code Set category, which is available for build configuration sets.
The Python script adds the files to the related properties of the Default Build
Configuration Set. The following code listing shows the relevant lines of the
method definition.
1 def AssignSecOCUserCodeFiles(self):
2 ...

476
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Working with the Bus Manager SecOC Demo

3 SecOCUserCodeSourceFiles =
4 [FileName for FileName in os.listdir(self.CurrentPath) if FileName.endswith('.c') or FileName.endswith('.cpp')]
5 SecOCUserCodeIncludeFiles =
6 [FileName for FileName in os.listdir(self.CurrentPath) if FileName.endswith('.h') or FileName.endswith('.hpp')]
7
8 ExecutableApplication = self.ApplicationConfigurationRelation.GetTopNodes().Item(0)
9 DefaultBuildConfigurationSet =
10 self.BuildConfigurationRelation.GetElements(ExecutableApplication).Item('Default Build Configuration Set')
11 BusCustomCodeSet =
12 self.PropertyDataObjectsRelation.GetElements(DefaultBuildConfigurationSet).Item('Bus Custom Code Set')
13
14 BusCustomCodeSet.Properties['BusCustomCodeBaseDirectory'].TrySetValue(self.CurrentPath)
15 BusCustomCodeSet.Properties['BusCustomCodeSourceFiles'].TrySetValue(SecOCUserCodeSourceFiles)
16 BusCustomCodeSet.Properties['BusCustomCodeIncludeFilesAndDirectories'].TrySetValue(SecOCUserCodeIncludeFiles)
17 ...

In the ConfigurationDesk application, you can access the Default Build

Configuration Set via the Build Configuration table.

Tip

If the Build Configuration table is closed, you can open it via Show Panes
on the View ribbon.

Modifying the cyclic timing in The communication matrix specifies a cyclic timing period of 5 ms for the
the communication matrix authentic IPDUs. If you want to simulate the functionality of the Bus Manager
SecOC demo in experiment software such as ControlDesk, this makes it difficult
to observe the effects, e.g., when you manipulate the bus communication.

You cannot change the period that is specified in the communication matrix
at run time. Therefore, the Python script sets the period to 0 ms. With this,
cyclic transmission of the IPDUs is disabled. Instead, you can manually trigger the
transmission at run time. The following code listing shows the relevant lines of
the CreateBusManagerSecOCDemo function.
1 def CreateBusManagerSecOCDemo():
2 ...
3 AuthenticIPdus =
4 DemoController.BusConfigurationsRelation.FindByXPath(
5 '/BusConfiguration[1]/BusConfigurationPartSimulatedEcus//BusISignalIPdu')
6 for AuthenticIPdu in AuthenticIPdus:
7 CyclicTiming = DemoController.PropertyDataObjectsRelation.GetElements(AuthenticIPdu).Item('Cyclic Timing')
8 TimePeriod = DemoController.PropertyDataObjectsRelation.GetElements(CyclicTiming).Item('Time Period')
9 TimePeriod.Properties['Value'].TrySetValue(0)
10 ...

477
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with the Bus Manager Demos

Adding bus configuration The AddFeature method adds bus configuration features to IPDUs. The IPDUs
features to IPDUs are accessed by the bus configuration and bus configuration part to which
they are assigned, and by their PDU type. The following code listing shows the
relevant lines of the method definition.
1 def AddFeature(self, BusConfiguration, BusConfigurationPart, TypeOfPdus, FeatureName):
2 ...
3 Pdus = self.BusConfigurationsRelation.FindByXPath(
4 '/BusConfiguration[@Name="{0}"]/BusConfigurationPart{1}//{2}'.format(BusConfiguration.Name, BusConfigurationPart,
5 TypeOfPdus))
6 self.BusManager.Configure('AddFeature', [FeatureName, Pdus])
7 ...

The method is called seven times in the CreateBusManagerSecOCDemo function

to add the PDU Trigger, SecOC Authenticator Invalidation, SecOC Freshness
Overwrite Value, PDU RX Status, and SecOC features to the secured and/or
authentic IPDUs:
1 def CreateBusManagerSecOCDemo():
2 ...
3 DemoController.AddFeature(BusConfiguration_TX, 'SimulatedEcus', 'BusISignalIPdu', 'BusPduTriggerAccess')
4 DemoController.AddFeature(BusConfiguration_TX, 'Manipulation' , 'BusSecuredIPdu',
5 'BusPduSecOCAuthenticatorInvalidationManipulation')
6 DemoController.AddFeature(BusConfiguration_TX, 'Manipulation' , 'BusSecuredIPdu',
7 'BusPduSecOCFreshnessOverwriteValueManipulation')
8 DemoController.AddFeature(BusConfiguration_RX, 'SimulatedEcus', 'BusISignalIPdu', 'BusPduRxStatusAccess')
9 DemoController.AddFeature(BusConfiguration_RX, 'SimulatedEcus', 'BusSecuredIPdu', 'BusPduRxStatusAccess')
10 DemoController.AddFeature(BusConfiguration_RX, 'SimulatedEcus', 'BusSecuredIPdu', 'BusPduSecOCAccess')
11 DemoController.AddFeature(BusConfiguration_RX, 'Inspection' , 'BusSecuredIPdu', 'BusPduSecOCInspection')
12 ...

Tip

Additionally, the ISignal Value feature is automatically added to all ISignals

that are assigned to the Simulated ECUs part of the bus configurations.

Disabling the recalculation of To prevent unintended manipulation of secured bus communication, some bus
authentication information manipulation features provide a Recalculate SecOC information checkbox. For
most of these bus manipulation features, the checkbox is selected by default,
i.e., the authentication information is recalculated after the related IPDU was
manipulated.

For the SecOC Freshness Overwrite Value feature, the checkbox is selected
and read‑only, i.e., the authentication information is always recalculated
after the freshness value was overwritten. For the SecOC Authenticator
Invalidation feature, the checkbox can be configured. To transmit an invalidated
authenticator value (MAC) at run time, it must be ensured that the checkbox is
cleared for this feature. In the CreateBusManagerSecOCDemo function, this is
done via the following lines:
1 def CreateBusManagerSecOCDemo():
2 ...
3 RecalculateProperties = DemoController.BusConfigurationsRelation.FindByXPath('//@Recalculate_SecOC_information')
4 for RecalculateProperty in RecalculateProperties:
5 RecalculateProperty.TrySetValue(False)
6 ...

478
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Working with the Bus Manager SecOC Demo

Configuring bus configuration The EnableTestAutomation method enables test automation support for all
function ports function ports of all available bus configuration features. The following code
listing shows the relevant lines of the method definition.
1 def EnableTestAutomation(self):
2 ...
3 TestAutomationProperties =
4 self.BusConfigurationsRelation.FindByXPath('//FunctionPort/@IsTestAutomationSupportEnabled')
5 for TestAutomationProperty in TestAutomationProperties:
6 TestAutomationProperty.TrySetValue(True)
7 ...

Depending on the specific bus configuration feature and the related bus
configuration part, the SetInitialSourceSwitch method specifies initial
settings for some function ports. For example, the function ports of the SecOC
simulation feature are configured as follows:
§ All function ports of the feature: Initial switch setting is set to Substitute
value.
§ State function port: Initial substitute value is set to 63. According to
the specifications in the UserCode_SecOCDemo.c user code file, this value
indicates that the verification of the received authentication information is not
executed.
§ Enable Verification function port: Initial substitute value is set to 1.
According to the specifications in the UserCode_SecOCDemo.c user code file,
this value enables the verification of the received authentication information.

The following code listing shows the relevant lines of the method definition for
the example above.
1 def SetInitialSourceSwitch(self):
2 ...
3 for FunctionPort in self.BusConfigurationsRelation.FindByXPath('//BusPduSecOCAccess/FunctionPort'):
4 FunctionPort.Properties['InitialSwitchSetting'].TrySetValue(1)
5 if FunctionPort.Name.endswith('State'):
6 FunctionPort.Properties['InitialSubstituteValue'].TrySetValue(63)
7 elif FunctionPort.Name.endswith('Enable Verification'):
8 FunctionPort.Properties['InitialSubstituteValue'].TrySetValue(1)
9 ...

Creating an application The CreateProcessAndTasks method creates a processing unit application if

process and assigning it to the none exists yet, creates an application process that provides a default task, and
bus configurations names the application process BusManagerSecOCDemoApplication. Creating
this application process is necessary because no behavior model is used in the
Bus Manager SecOC demo. The following code listing shows the relevant lines of
the method definition.
1 def CreateProcessAndTasks(self):
2 ...
3 ExecutableApplication = self.ApplicationConfigurationRelation.GetTopNodes().Item(0)
4 if ExecutableApplication.GetCount() == 0:
5 ProcessingUnitApplication = ExecutableApplication.CreateChild(ExecutableApplication.DataObjectTypes.Item(0),
6 'DemoProcessingUnitApplication')
7 else:
8 ProcessingUnitApplication = ExecutableApplication.Item(0)

479
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with the Bus Manager Demos

9
10 ApplicationProcess = ProcessingUnitApplication.CreateChild(ProcessingUnitApplication.DataObjectTypes.Item(0),
11 'BusManagerSecOCDemoApplication')
12 ApplicationProcess.Properties['ProvideDefaultTask'].TrySetValue(True)
13 ...

Additionally, the CreateBusManagerSecOCDemo function explicitly assigns the

application process to the bus configurations:
1 def CreateBusManagerSecOCDemo():
2 ...
3 BusConfiguration_TX.Properties['ManuallyAssignedApplicationProcess'].TrySetValue(ApplicationProcess)
4 BusConfiguration_RX.Properties['ManuallyAssignedApplicationProcess'].TrySetValue(ApplicationProcess)
5 ...

Tip

§ In general, assigning the application process explicitly to the bus

configurations is necessary only for the Bus Manager (stand‑alone). With
the Bus Manager in ConfigurationDesk, this happens automatically when
bus accesses are assigned to the bus access requests . Nevertheless,
the Python script explicitly assigns the application process regardless of
the Bus Manager variant.
§ When the bus simulation container is generated later on, the resulting
BSC file is automatically named after the application process.

Generating bus simulation Finally, the CreateBusManagerSecOCDemo function generates a bus simulation
containers container. This is done by the following code line:

1 def CreateBusManagerSecOCDemo():
2 ...
3 DemoController.BusManager.Configure('GenerateContainers', [])
4 ...

Next steps You can use the results of the Python script execution to simulate the
functionality of the Bus Manager SecOC demo in ControlDesk. There are
two ways to prepare this, depending on whether you use a SCALEXIO,
MicroAutoBox III, MicroLabBox II , or VEOS platform:

SCALEXIO/MicroAutoBox III/MicroLabBox II VEOS

1. Register your SCALEXIO/MicroAutoBox III/MicroLabBox II 1. Import the generated bus simulation container, which is
platform in ConfigurationDesk. Refer to Registering located in the Generated Containers folder of the
Hardware in ConfigurationDesk (ConfigurationDesk Real- BusManagerSecOCDemo project folder, to VEOS and
Time Implementation Guide ). integrate it into an offline simulation application.
2. Adapt the following settings according to your § VEOS on Windows: Save the OSA file to
SCALEXIO/MicroAutoBox III/MicroLabBox II platform: the VEOS Documents folder and name it
§ The created hardware topology. Refer to Basics BusManagerSecOCDemoApplication.osa.
on Hardware Topologies (ConfigurationDesk Real-Time § VEOS on Linux: Add a new folder to your home
Implementation Guide ). directory and name it BusManagerSecOCDemo. Save
§ The assigned hardware resources of the CAN function the OSA file to this folder and name the file
blocks. Refer to Methods for Assigning Hardware BusManagerBasicsDemoApplication.osa.
Resources (ConfigurationDesk Real-Time Implementation Refer to How to Build an Offline Simulation Application
Guide ). (VEOS Manual ).

480
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Working with the Bus Manager SecOC Demo

SCALEXIO/MicroAutoBox III/MicroLabBox II VEOS

If you make any changes, you have to build a new real-time 2. Load the OSA file to VEOS without starting the offline
application. To do this, click Build - Start on the Home simulation application. Refer to How to Load and Run an
ribbon. Offline Simulation Application (VEOS Manual ).
3. Physically connect the CAN channels of your real‑time
hardware that you assigned to the CAN function blocks.
4. Load the real-time application to the
SCALEXIO/MicroAutoBox III/MicroLabBox II platform. Refer
to How to Load a Real-Time Application (ConfigurationDesk
Real-Time Implementation Guide ).

Once you have loaded the executable application to the simulation platform,
you can use ControlDesk's Bus Navigator to experiment with the bus
communication. Refer to Example of Experimenting with the Bus Manager
SecOC Demo in ControlDesk on page 488.

Definitions in the UserCode_SecOCDemo.c File

Introduction The UserCode_SecOCDemo.c file implements the algorithms that are used by
the Bus Manager SecOC demo for calculating and verifying the authentication
information. It uses functions of the Bus Custom Code interface to exchange
data between the Bus Manager and the user code, e.g., to access specifications
of the communication matrix or provide the calculated freshness value at run
time.

Tip

The example of implementing secure onboard communication in

the documentation of the Bus Custom Code interface uses the
UserCode_SecOC.c file. The UserCode_SecOCDemo.c file is based on this
file. Therefore, many definitions are the same in both C files.
In this topic, only the definitions that are specific for the Bus Manager
SecOC demo are described in detail. For a detailed description of the
definitions that are also included in the UserCode_SecOC.c file, refer to
Example of Implementing Secure Onboard Communication (SecOC) via the
Bus Custom Code Interface (Bus Custom Code Interface Handling ).

Defining the user code ID The UserCode_SecOCDemo.c file defines the user code ID as follows:

1 #define DS_BUS_CUSTOM_FEATURE_NAME SecOC

SecOC is the user code ID that is referenced by each bus configuration by default
for which the SecOC support is enabled. For each user code implementation ,
there must be one unique user code ID. It must be the first definition in the
related user code file.

481
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with the Bus Manager Demos

Defining the handling of keys Overview In the Bus Manager SecOC demo, a randomly generated
key is used for calculating the authentication information of the
IPdu02_FVCounter_secured IPDU:
§ The generation of the key is implemented via the DsCmacKey.c/.h files.
§ The key is generated according to the AES‑CMAC algorithm, which is
implemented via the DsAes.c/.h and DsCmac.c/.h files.
§ To generate the key, a mapping table is used, which is defined in the
UserCode_SecOCConfiguration.c/.h files.

Initializing the generated key The UserCode_SecOCDemo.c file initializes

the generated key with 0:
1 #if NUMBER_OF_IPDUS > 0
2 static int cmacKeyGenerated = 0;
3 #endif

NUMBER_OF_IPDUS provides the number of [secured IPDU, authentic

IPDU, key] tuples that are defined in the mapping table. Because the
IPdu02_FVCounter_secured IPDU is available in the mapping table,
NUMBER_OF_IPDUS is > 0.

Generating the key in the DsBusCustomCode_onApplicationInit

function For each [secured IPDU, authentic IPDU] tuple, the key is generated
once during the initialization phase of the executable application when
the DsBusCustomCode_onApplicationInit function is executed. It is
generated on the basis of the AUTOSAR Crypto Service Manager and
according to the AES‑CMAC algorithm. For this purpose, functions of the
UserCode_CsmDemo.c/.h and UserCode_SecOCHelperDemo.c/.h files are
called. The UserCode_SecOCDemo.c file also uses functions of the Bus Custom
Code interface to access the key. The following code listing shows the relevant
lines.
1 Std_ReturnType DsBusCustomCode_onApplicationInit(DsBusCustomCodePduFeatureHandle PduFeatureHandle)
2 {
3 ...
4 DSBUSCUSTOMCODE_TRY(featureDescriptor,
5 UserCode_SecOCHelper_Create_CryptoJob_For_CMAC_AES_128_Authentication(&featureInstanceData->CsmJobHandle,
6 dataToAuthentictatorLength));
7 ...
8 #if NUMBER_OF_IPDUS > 0
9 if (cmacKeyGenerated == 0)
10 {
11 DsCmacKey_initializeKeyPerPdu();
12 cmacKeyGenerated = 1;
13 }
14 #endif
15 ...
16 char* pduSpecificKey = DsCmacKey_getPduSpecificKey(securedIPduName, authenticPduName);
17 ...
18 DSBUSCUSTOMCODE_TRY(featureDescriptor, UserCode_SecOCHelper_DeriveKeyFromString(pduSpecificKey, &keyPtr,
19 &keyLength));
20 DSBUSCUSTOMCODE_TRY(featureDescriptor, DsBusCustomCodeSecOCPduFeature_setKeyPtr(PduFeatureHandle, keyPtr));
21 DSBUSCUSTOMCODE_TRY(featureDescriptor, DsBusCustomCodeSecOCPduFeature_setKeyLength(PduFeatureHandle, keyLength));
22
23 DSBUSCUSTOMCODE_TRY(featureDescriptor, UserCode_Csm_KeyElementSet(featureInstanceData->CsmJobHandle, keyId,
24 CRYPTO_KE_MAC_KEY, keyPtr, keyLength));
25 ...
26 }

482
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Working with the Bus Manager SecOC Demo

During the execution of the executable application, the key is used by functions
that are called in the DsBusCustomCode_onPduFeatureExecution function to
calculate the authenticator (MAC).

Implementing the handling of The freshness value of the IPdu02_FVCounter_secured IPDU is a freshness
freshness counters counter. Therefore, no freshness time stamp handling is required and the
AUTOSAR Freshness Value Manager is only initialized for IPDUs that use a
freshness counter.

The DsBusCustomCode_onApplicationInit function calls functions of the

Bus Custom Code interface to access data in the communication matrix that
is required for the AUTOSAR Freshness Value Manager implementation of
this demo. Then, it calls the UserCode_SecOC_Fvm_Init function, which is
specified in the UserCode_FvmDemo.c/.h files and initializes the implemented
AUTOSAR Freshness Value Manager. The following code listing shows the
relevant lines.
1 Std_ReturnType DsBusCustomCode_onApplicationInit(DsBusCustomCodePduFeatureHandle PduFeatureHandle)
2 {
3 ...
4 boolean useFreshnessTimestamp;
5 returnValue = DsBusCustomCodeSecuredIPdu_getUseFreshnessTimestamp(securedIPdu_PduHandle, &useFreshnessTimestamp);
6
7 if (returnValue == E_PARAMETER_NOT_SET)
8 {
9 useFreshnessTimestamp = FALSE;
10 }
11 else if (returnValue != E_OK)
12 {
13 return E_NOT_OK;
14 }
15
16 if(useFreshnessTimestamp)
17 {
18 USERCODE_DEBUG_PRINT("Freshness time stamp handling is not implemented.\n");
19 return E_NOT_OK;
20 }
21
22 uint16 freshnessValueId = 0;
23 DSBUSCUSTOMCODE_TRY(featureDescriptor, DsBusCustomCodeSecuredIPdu_getFreshnessValueId(securedIPdu_PduHandle,
24 &freshnessValueId));
25
26 uint32 authenticationRetries = 0;
27 if(!isTx)
28 {
29 DSBUSCUSTOMCODE_TRY(featureDescriptor,
30 DsBusCustomCodeSecuredIPdu_getAuthenticationRetries(securedIPdu_PduHandle, &authenticationRetries));
31 }
32
33 DSBUSCUSTOMCODE_TRY(featureDescriptor, UserCode_SecOC_Fvm_Init(featureDataPtr, useFreshnessTimestamp,
34 (uint16)authenticationRetries));
35 ...
36 }

483
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with the Bus Manager Demos

Implementing the The IPdu02_FVCounter_secured IPDU is configured as a non‑cryptographic

non‑cryptographic use case IPDU. Therefore, the payload of the authentic IPDU is completely copied to the
secured IPDU.

The DsBusCustomCode_onPduFeatureExecution function determines the

actual length of the payload of the authentic IPDU and copies the relevant bytes
to the secured IPDU. Additionally, it determines the positions of the freshness
value and authenticator (MAC) in the secured IPDU. The following code listing
shows the relevant lines.
1 Std_ReturnType DsBusCustomCode_onPduFeatureExecution(DsBusCustomCodePduFeatureHandle PduFeatureHandle)
2 {
3 ...
4 if (authPduHeaderLength == 0)
5 {
6 authenticIPdu_ActualLength = authenticIPdu_SduLength;
7 }
8 else if (authPduHeaderLength == 1)
9 {
10 uint8* header = securedIPdu_SduDataPtr;
11 authenticIPdu_ActualLength = USER_CODE_INT8_FROM_BE(*header);
12 }
13 else if (authPduHeaderLength == 2)
14 {
15 uint16* header = (uint16*)securedIPdu_SduDataPtr;
16 authenticIPdu_ActualLength = USER_CODE_INT16_FROM_BE(*header);
17 }
18 else if (authPduHeaderLength == 4)
19 {
20 uint32* header = (uint32*)securedIPdu_SduDataPtr;
21 authenticIPdu_ActualLength = USER_CODE_INT32_FROM_BE(*header);
22 }
23 else
24 {
25 return E_NOT_OK;
26 }
27
28 if (authenticIPdu_ActualLength > authenticIPdu_SduLength)
29 {
30 return E_NOT_OK;
31 }
32
33 securedIPduFreshnessValuePosition = securedIPduAuthenticIPduPosition + authenticIPdu_ActualLength * 8;
34 securedIPduAuthenticatorPosition = securedIPduFreshnessValuePosition + freshnessValueTxLength;
35 ...
36 }

Verifying the authentication The verification of the received authentication information must be enabled
information in the user code in the Bus Manager via the SecOC feature. If this is the case, the received
authentication information is verified according to the algorithm in the
UserCode_SecOCDemo.c file.

Verifying the received freshness value The

DsBusCustomCode_onPduFeatureExecution function calls the
UserCode_SecOC_GetRxFreshness function, which is specified in the
UserCode_FvmDemo.c/.h files. This function accesses the received freshness
value and verifies it.

484
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Working with the Bus Manager SecOC Demo

To avoid problems due to different data types, the

DsBusCustomCode_onPduFeatureExecution function copies the data
of the non-truncated freshness value and freshness length that is
accessed by the UserCode_SecOC_GetRxFreshness function to the local
freshnessVerifyValue and freshnessVerifyValueLength variables. It
also passes the value of the freshnessVerifyValue variable to the
FreshnessRxValue element of the UserCode_FeatureData_Type struct
to use the non-truncated freshness value for further calculations. The
UserCode_FeatureData_Type struct is a global struct that is specified in the
UserCode_Types.h file.
The following code listing shows the relevant lines.
1 Std_ReturnType DsBusCustomCode_onPduFeatureExecution(DsBusCustomCodePduFeatureHandle PduFeatureHandle)
2 {
3 ...
4 boolean useFreshnessTimestamp;
5 returnValue = DsBusCustomCodeSecuredIPdu_getUseFreshnessTimestamp(securedIPdu_PduHandle, &useFreshnessTimestamp);
6 if (returnValue == E_PARAMETER_NOT_SET)
7 {
8 useFreshnessTimestamp = FALSE;
9 }
10 else if (returnValue != E_OK)
11 {
12 return E_NOT_OK;
13 }
14
15 uint32 freshnessVerifyValueLength = freshnessValueLength;
16 uint64 freshnessVerifyValue = 0;
17
18 returnValue = UserCode_SecOC_GetRxFreshness(featureDataPtr,
19 securedIPdu_SduDataPtr + (securedIPduFreshnessValuePosition / 8), freshnessValueTxLength,
20 ((UserCode_FeatureData_Type*)featureDataPtr)->AuthVerifyAttemptCounter, (uint8*)&freshnessVerifyValue,
21 &freshnessVerifyValueLength);
22
23 if (returnValue == SECOC_FRESHNESSFAILURE)
24 {
25 DSBUSCUSTOMCODE_TRY(featureDescriptor,
26 DsBusCustomCodeSecOCRxPduFeature_setVerificationResult(PduFeatureHandle, SECOC_FRESHNESSFAILURE));
27 freshnessFailure = TRUE;
28 USERCODE_DEBUG_PRINT("Verification failed because of an unexpected freshness value.\n");
29 }
30 else if (returnValue == E_NOT_OK)
31 {
32 USERCODE_DEBUG_PRINT("Verification failed because of a general error.\n");
33 }
34
35 ((UserCode_FeatureData_Type*)featureDataPtr)->FreshnessRxValue = freshnessVerifyValue;
36 ...
37 }

Verifying the authenticator To verify the authenticator (MAC), the

DsBusCustomCode_onPduFeatureExecution function executes the following
steps:
1. It calls the DsBusCustomCodeSecOCRxPduFeature_
setCalculatedFreshnessValue function of the Bus Custom Code
interface to set the expected non‑truncated freshness value, which is stored
in the FreshnessRxValue element of the UserCode_FeatureData_Type
struct.

485
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with the Bus Manager Demos

2. It calls the UserCode_SecOCHelper_PrepareDataToAuthenticator

function, which is specified in the UserCode_SecOCHelper.c/.h files,
to collect the received data that is required for calculating the expected
authenticator.
3. It calls the UserCode_Csm_MacGenerate function, which is specified in the
UserCode_CsmDemo.c/.h files, to calculate the expected authenticator.
4. It calls the UserCode_SecOCHelper_CompareBits function, which is
specified in the UserCode_SecOCHelperDemo.c/.h files, to compare
the received authentication information with the expected authentication
information.
The following code listing shows the relevant lines.
1 Std_ReturnType DsBusCustomCode_onPduFeatureExecution(DsBusCustomCodePduFeatureHandle PduFeatureHandle)
2 {
3 ...
4 DSBUSCUSTOMCODE_TRY(featureDescriptor,
5 DsBusCustomCodeSecOCRxPduFeature_setCalculatedFreshnessValue(PduFeatureHandle,
6 ((UserCode_FeatureData_Type*)featureDataPtr)->FreshnessRxValue));
7
8 DSBUSCUSTOMCODE_TRY(featureDescriptor, UserCode_SecOCHelper_PrepareDataToAuthenticator(dataId,
9 authenticIPdu_SduDataPtr + actualSecuredAreaOffset, actualSecuredAreaLength,
10 ((UserCode_FeatureData_Type*)featureDataPtr)->FreshnessRxValue, freshnessValueLength,
11 Crypto_Job->PrimitiveInputOutput->inputPtr, &Crypto_Job->PrimitiveInputOutput->inputLength));
12
13 USERCODE_DEBUG_PRINTDATA("RX data used for authenticator calculation:",
14 Crypto_Job->PrimitiveInputOutput->inputPtr, Crypto_Job->PrimitiveInputOutput->inputLength);
15
16 authenticatorLength = Crypto_Job->jobPrimitiveInfo->primitiveInfo->resultLength;
17 *(Crypto_Job->PrimitiveInputOutput->outputLengthPtr) = authenticatorLength;
18
19 DSBUSCUSTOMCODE_TRY(featureDescriptor, UserCode_Csm_MacGenerate(csmJobHandle,
20 Crypto_Job->PrimitiveInputOutput->mode, Crypto_Job->PrimitiveInputOutput->inputPtr,
21 Crypto_Job->PrimitiveInputOutput->inputLength, Crypto_Job->PrimitiveInputOutput->outputPtr,
22 Crypto_Job->PrimitiveInputOutput->outputLengthPtr));
23
24 USERCODE_DEBUG_PRINTDATA("Received MAC:", securedIPdu_SduDataPtr + (securedIPduAuthenticatorPosition / 8),
25 (authInfoTxLength + 7) / 8);
26
27 Std_ReturnType result = UserCode_SecOCHelper_CompareBits(securedIPdu_SduDataPtr +
28 (securedIPduAuthenticatorPosition / 8), freshnessValueTxLength % 8, Crypto_Job->PrimitiveInputOutput->outputPtr,
29 0, authInfoTxLength);
30 ...
31 }

Providing the verification state The result variable provides the

result of the UserCode_SecOCHelper_CompareBits function. If this
function returns any other value than E_OK, the result of the
UserCode_SecOC_GetRxFreshness function is evaluated, which is provided
by the freshnessFailure variable. After evaluating the provided states,
AuthVerifyAttemptCounter is reset to 0 and freshnessFailure to FALSE, if
required. The following code listing shows the relevant lines.
1 Std_ReturnType DsBusCustomCode_onPduFeatureExecution(DsBusCustomCodePduFeatureHandle PduFeatureHandle)
2 {
3 ...
4 if (result != E_OK)
5 {
6 if(!freshnessFailure)
7 {
8 ((UserCode_FeatureData_Type*)featureDataPtr)->AuthVerifyAttemptCounter++;

486
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Working with the Bus Manager SecOC Demo

9 DSBUSCUSTOMCODE_TRY(featureDescriptor,
10 DsBusCustomCodeSecOCRxPduFeature_setVerificationResult(PduFeatureHandle, SECOC_VERIFICATIONFAILURE));
11 USERCODE_DEBUG_PRINT("Verification failed.\n");
12 }
13 else
14 {
15 if( ((UserCode_FeatureData_Type*)featureDataPtr)->AuthVerifyAttemptCounter > 0 )
16 {
17 ((UserCode_FeatureData_Type*)featureDataPtr)->AuthVerifyAttemptCounter=0;
18 }
19 freshnessFailure = FALSE;
20 }
21 }
22 else
23 {
24 ((UserCode_FeatureData_Type*)featureDataPtr)->AuthVerifyAttemptCounter = 0;
25 DSBUSCUSTOMCODE_TRY(featureDescriptor,
26 DsBusCustomCodeSecOCRxPduFeature_setVerificationResult(PduFeatureHandle, SECOC_VERIFICATIONSUCCESS));
27 USERCODE_DEBUG_PRINT("Authentication information successfully verified.\n");
28 }
29 ...
30 }

Exchanging data between the The UserCode_SecOCDemo.c file uses the following functions of the Bus
Bus Manager and the user Custom Code interface to exchange data between the Bus Manager and the
code user code:

Function Usage in the UserCode_SecOCDemo.c

File
DsBusCustomCodeSecOCTxPduFeature_getEnableFreshnessValueCalculation Gets the enable state of the SecOC
Freshness Overwrite Value feature.
When the feature is disabled, the
freshness value is calculated in the user
code.
DsBusCustomCodeSecOCTxPduFeature_getUserDefinedFreshnessValue Gets the value of the Overwrite Value
function port of the SecOC Freshness
Overwrite Value feature.
DsBusCustomCodeSecOCRxPduFeature_getEnableVerification Gets the enable state of the SecOC
feature. When the feature is enabled,
the received authentication information is
verified in the user code.
DsBusCustomCodeSecOCRxPduFeature_setVerificationResult Provides the verification result to the State
function port of the SecOC feature.
DsBusCustomCodeSecOCRxPduFeature_setCalculatedFreshnessValue Provides the expected freshness value to
the Calculated Freshness Value function
port of the SecOC feature.

487
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with the Bus Manager Demos

Example of Experimenting with the Bus Manager SecOC Demo in ControlDesk

Introduction This example illustrates how you can experiment with the results of the Bus
Manager SecOC demo Python script execution in ControlDesk.

Preconditions § You built a real-time application of the Bus Manager SecOC demo and loaded
it to a SCALEXIO, MicroAutoBox III, or MicroLabBox II platform.
- OR -
§ You built an offline simulation application and loaded it to VEOS.
§ You have a decrypted installation of ControlDesk. For information on installing
and decrypting dSPACE software, refer to Installing dSPACE Software .

For information on building the executable application and loading it to the

simulation platform, refer to Next steps on page 480.

Workflow The example consists of the following parts:

§ Preparing an experiment in ControlDesk. Refer to Part 1 on page 488.
§ Preparing a layout in ControlDesk. Refer to Part 2 on page 489.
§ Experimenting in ControlDesk. Refer to Part 3 on page 491.

Part 1 To prepare an experiment in ControlDesk

1 Start ControlDesk.
2 Register VEOS or the SCALEXIO/MicroAutoBox III/MicroLabBox II platform.

3 Create a new project and experiment. The settings depend on whether you
use VEOS, SCALEXIO, MicroAutoBox III, or MicroLabBox II.

Project Experiment Platform Variable Description File

BusManagerSecOCDemo VEOS Simulation VEOS § VEOS on Windows: <VEOS Documents folder>\
BusManagerSecOCDemoApplication.sdf
§ VEOS on Linux: ~/BusManagerSecOCDemo/
BusManagerSecOCDemoApplication.sdf
BusManagerSecOCDemo SCALEXIO SCALEXIO <ConfigurationDesk Documents folder>\
Simulation BusManagerSecOCDemo\BusManagerSecOCDemoApplication\
Build Results\BusManagerSecOCDemoApplication.sdf
BusManagerSecOCDemo MicroAutoBox III MicroAutoBox III <ConfigurationDesk Documents folder>\
Simulation BusManagerSecOCDemo\BusManagerSecOCDemoApplication\
Build Results\BusManagerSecOCDemoApplication.sdf
BusManagerSecOCDemo MicroLabBox II MicroLabBox II <ConfigurationDesk Documents folder>\
Simulation BusManagerSecOCDemo\BusManagerSecOCDemoApplication\
Build Results\BusManagerSecOCDemoApplication.sdf

488
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Working with the Bus Manager SecOC Demo

After you finish, the Project Manager and Platforms/Devices controlbars

look as shown in the following example of a VEOS platform.

Interim result You created a project and experiment in ControlDesk. You can now prepare a
layout. Continue with the next part.

Part 2 To prepare a layout in ControlDesk

1 Select the Bus Navigator.

The Bus Navigator displays a hardware‑related view
on the bus communication that is accessed via the
BusManagerSecOCDemoApplication.sdf file, starting with the platform
to which the file is loaded. However, the Bus Navigator tree differs for the
simulation platforms as follows:

Bus Navigator VEOS SCALEXIO, MicroAutoBox III, MicroLabBox II

Overview

Names The extension of the platform name, i.e., the value The extension of the platform name, i.e., the value in
Platform in the brackets, is derived from the SDF file. the brackets, is a consecutive number.

489
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with the Bus Manager Demos

Bus Navigator VEOS SCALEXIO, MicroAutoBox III, MicroLabBox II

The name depends on the specification in VEOS, The name depends on the specification in
i.e., it is the channel name of the related ConfigurationDesk, i.e., it is the name of the related
Controller
communication cluster. CAN function block.
Structure In this demo, the communication of only one communication cluster is simulated. Because of this, the
structure of the Bus Navigator tree differs as follows:
Only one controller is available, which accesses the Two controllers are available, one for each CAN
CAN channel that is simulated by VEOS. channel you use on your real‑time hardware. However,
because these channels are physically connected, they
form one communication cluster.

2 In the Bus Navigator, select the RX IPdu02_FVCounter_secured IPDU

that is received by ECU_2. If you use SCALEXIO, MicroAutoBox III, or
MicroLabBox II, select the IPDU for ECU_2 below RX CAN Access.

VEOS SCALEXIO, MicroAutoBox III,

MicroLabBox II

3 Right-click IPdu02_FVCounter_secured and select Generate Inspection

Layout on the context menu.
A new layout with a Bus Instrument (Inspection type) is generated.
4 Select the same IPdu02_FVCounter_secured IPDU and drag it to an empty
area of the layout.
A list opens.
5 From the list, select Bus Navigator RX Instrument to add a Bus Instrument
(RX type) to the layout.
6 Drag the IPdu02_FVCounter IPDU that is the lower‑level element of the
previously selected IPdu02_FVCounter_secured IPDU to the layout and add
a Bus Instrument (RX type).
7 Drag the following IPDUs to the layout and add the related instruments:

Controller ECU IPDU Instrument

§ VEOS: CanPhysicalChannel ECU_1 IPdu02_FVCounter_secured Bus Instrument (Manipulation
§ SCALEXIO, MicroAutoBox III, MicroLabBox II: TX CAN type)
Access IPdu02_FVCounter Bus Instrument (TX type)

490
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Working with the Bus Manager SecOC Demo

8 Arrange the instruments as follows:

Interim result You generated Bus Instruments to simulate, manipulate, and inspect the
bus communication of the Bus Manager SecOC demo. You can now start
experimenting. Continue with the next part.

Part 3 To experiment in ControlDesk

1 On the Home ribbon, click Go Online.

Online calibration starts and the CAN communication is active. However,
the transmission of the IPdu02_FVCounter_secured IPDU is not triggered
yet. In the PDU RX Status Access regions of the Bus Instrument (RX type)
instruments, the values of the Counter, Time, and Delta Time function
ports therefore are 0.

2 In the PDU Trigger Access region of the Bus Instrument (TX type), select the
Trigger checkbox.

The transmission of the IPdu02_FVCounter IPDU is triggered once and this

triggers the transmission of the IPdu02_FVCounter_secured IPDU. After
the transmission is triggered, the checkbox is cleared.

491
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with the Bus Manager Demos

The Bus Instrument (Inspection type) and Bus Instrument (RX type)
instruments display the following states:

§ In the PDU SecOC Inspection and PDU SecOC Access regions, the
values of the Enable Verification function ports are set to 1. Therefore,
the user code verifies the received authentication information of the
IPdu02_FVCounter_secured IPDU that is assigned to the Inspection
and Simulated ECUs parts of BusConfiguration_RX. In both regions,
the values of the State function ports are 0, which indicate that the
verification was successful.
§ In the PDU SecOC Inspection region, the following is displayed:
§ Authenticator Value [<0> … <2>] display the authenticator (MAC)
that is received on the bus. The TX length of the authenticator is 24 bits.
Therefore, the value of the Authenticator Value function port is a
3‑bytes array and each field displays the value of one byte.
§ The Freshness Value function port provides the freshness value that is
received on the bus. Because the freshness value is a freshness counter
and the secured IPDU was triggered once, the freshness value is 1.
§ The Calculated Freshness Value function port provides the expected
freshness value that is calculated in the user code.
§ In the PDU RX Status Access regions, the Counter function ports
provide the number of receptions of the IPdu02_FVCounter_secured
and IPdu02_FVCounter IPDUs, respectively. The Time function ports
provide the application time when the IPDUs were received.

Tip

§ In the PDU RX Status Access regions, the values of the State

function ports indicate whether the IPDUs were received in the
current sampling step. The displayed state is False because the
sampling step when the IPDUs were received has already ended.
§ The values of the Loopback function ports indicate that the IPDUs
were received as loopback IPDUs, i.e., the IPDU were transmitted
and received by the same bus access .

3 Select the Trigger checkbox again.

The IPDUs are transmitted a second time. The values of the Freshness
Value, Calculated Freshness Value, and Counter function ports are
incremented by 1. The Delta Time function ports provide the time
difference between the first and the second reception. The Authenticator
Value [<0> … <2>] fields display the updated authenticator that is received
on the bus.

492
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Working with the Bus Manager SecOC Demo

4 In the PDU SecOC Inspection region, set Enable Verification to 0. If you

type the value in the edit field, press Enter to confirm it.
5 Trigger the transmission of the IPDUs once.
For the IPdu02_FVCounter_secured IPDU that is assigned to the
Inspection part, the verification of the received authentication information
is disabled. Therefore, the value of the State function port is 63, which
indicates that the verification was not executed. The Calculated Freshness
Value function port provides the value that was calculated for the previous
reception of the IPDU. However, the Freshness Value function port provides
the actual received freshness value, which is the same as provided by the
Counter function port in the PDU RX Status Access region. Nevertheless,
verifying the authentication information is still enabled for the IPDU that is
assigned to the Simulated ECUs part. In the PDU SecOC Access region,
the value of the State function port therefore is 0, i.e., the verification was
successful.

6 In the PDU SecOC Inspection region, set Enable Verification to 1 and

trigger the transmission of the IPDUs once.
The verification of the authentication information is enabled again and the
authentication information is successfully verified: The Freshness Value and
Calculated Freshness Value function ports provide the same values, and
the value of the State function port is 0.
7 In the SecOC Authenticator Invalidation Manipulation region, set
Substitute Value of the Enable function port to 1: Permanently enabled
and trigger the transmission once.

The authenticator is manipulated after it was calculated in the user code. In

the PDU SecOC Inspection and PDU SecOC Access regions, the values of
the State function ports therefore are 1, which indicate that the verification
failed. Nevertheless, the freshness value is not affected by this manipulation.
Therefore, the Counter, Freshness Value, and Calculated Freshness Value
function ports provide the same values.

493
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with the Bus Manager Demos

8 In the SecOC Authenticator Invalidation Manipulation region, set

Substitute Value of the Enable function port to 0: Disabled and trigger
the transmission once.
Manipulating the authenticator is disabled and the authentication
information is successfully verified.
9 In the SecOC Freshness Overwrite Value Manipulation region, specify the
following settings:

Function Port Substitute Value

Enable 1: Permanently enabled
Freshness Overwrite Value 10

10 Trigger the transmission once.

The freshness value is manipulated and overwritten by 10. On the TX
side, the user code uses this value to calculate the authenticator. Then,
IPdu02_FVCounter_secured, including its authentic IPDU, is transmitted on
the bus.
In the PDU RX Status Access regions, the Counter function ports provide
the number of the receptions of the IPDUs, which is 7. In the PDU SecOC
Inspection region, the value of the Freshness Value function port indicates
that the transmitted freshness value is 10. Nevertheless, the algorithm for
handling the freshness value accepts any freshness value larger than the
previously received freshness value as valid. Therefore, the value of the
Calculated Freshness Value function port is 10 and the value of the State
function port is 0, i.e., the authentication information is successfully verified.

494
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Working with the Bus Manager SecOC Demo

11 In the SecOC Freshness Overwrite Value Manipulation region, set

Substitute Value of the Freshness Overwrite Value function port to 5
and trigger the transmission once.
The freshness value is manipulated and overwritten by 5. On the TX side, the
user code uses this value to calculate the authentication information that is
transmitted on the bus.
The manipulated freshness value is smaller than the previously transmitted
freshness value. The algorithm for handling the freshness value interprets
this as a counter overflow and the following applies:
§ According to the specifications in the communication matrix, the TX
freshness value is truncated to 8 bits. The TX freshness value is 5, i.e.,
the bits are set to 0000 0101.
§ On the RX side, a counter overflow due to the truncated TX freshness
value is assumed. Therefore, the non‑truncated RX freshness value is
reconstructed via <received truncated freshness value> + 1,
i.e., the lower bits of the non‑truncated RX freshness value are set to
0001 0000 0101. Converted to a decimal value, this is 261, which is
displayed as the calculated freshness value.
On the RX side, the expected authenticator is calculated by using the
calculated freshness value. As a result, the received and the expected
authenticators differ. In the PDU SecOC Inspection region, the value of
the State function port therefore is 1, i.e., the verification failed.

12 Trigger the transmission twice.

The freshness value is manipulated two more times. Because the value does
not change, the calculated freshness value also remains unchanged, i.e., it is
261. The communication matrix specifies two authentication retries, i.e., the
user code tries to verify the authentication information two more times after
the first verification has failed. These two additional verification attempts
have ended. As a result, the value of the State function port in the PDU
SecOC Inspection region is 2, which indicates that the verification failed
because of an unexpected freshness value.

495
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Working with the Bus Manager Demos

13 In the SecOC Freshness Overwrite Value Manipulation region, set

Substitute Value of the Enable function port to 0: Disabled and trigger
the transmission once.
The freshness value is no longer manipulated and the correct freshness
value, which is 11, is used by the user code on the TX side to calculate the
authentication information that is transmitted on the bus.
On the RX side, 11 is received as the freshness value. However, because of
the simple freshness value handling in this demo, the TX and RX freshness
counters are not synchronized once they differ. Therefore, only the lower
8 bits of the non‑truncated RX freshness value are updated with the received
freshness value, the 9th bit remains unchanged, i.e., the bits are set to
0001 0000 1011. Converted to a decimal value, this is 267, which is
displayed as the calculated freshness value. Because this value is used to
calculate the expected authenticator, the verification fails and the value of
the State function port in the PDU SecOC Inspection region is 1.

14 Trigger the transmission once.

On the TX side, the freshness value is incremented by 1 and the
authenticator is calculated by using this value. On the RX side, the newly
received freshness value is used to calculate the expected freshness value.
The calculated freshness value is also incremented by 1 but because the
TX and RX counters are not synchronized, the received and the calculated
freshness value still differ. Therefore, the verification fails again.
15 Trigger the transmission once.
On the TX side, the freshness value is incremented by 1 and the
authenticator is calculated by using this value. On the RX side, the calculated
freshness value still differs from the received freshness value. However, the
value of the Calculated Freshness Value function port is not updated. This
is because the verification attempts have ended and resulted in a verification
failure due to an unexpected freshness value. This is indicated by the value
of the State function port in the PDU SecOC Inspection region.
16 On the Home ribbon, click Go Offline.

Result You simulated, manipulated, and inspected the bus communication of the Bus
Manager SecOC demo in ControlDesk.

496
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Information for Former Users of the RTI CAN MultiMessage Blockset and RTI LIN MultiMessage Blockset

Information for Former Users of the RTI CAN

MultiMessage Blockset and RTI LIN MultiMessage
Blockset

Where to go from here Information in this section

Starting Points for Former Users of the RTI CAN MultiMessage

and RTI LIN MultiMessage Blocksets....................................................... 498

Mapping Features of the RTI CAN MultiMessage Blockset...................... 500

Mapping Features of the RTI LIN MultiMessage Blockset........................ 511

497
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Information for Former Users of the RTI CAN MultiMessage Blockset and RTI LIN MultiMessage Blockset

Starting Points for Former Users of the RTI CAN MultiMessage

and RTI LIN MultiMessage Blocksets

Recommended Starting Points for Former Users of the RTI CAN MultiMessage
and RTI LIN MultiMessage Blocksets

Introduction The concepts for working with the RTI CAN MultiMessage or RTI LIN
MultiMessage Blockset and the Bus Manager differ. Nevertheless, the
functionalities of many features of the RTI CAN MultiMessage and RTI LIN
MultiMessage Blocksets are also available for the Bus Manager.

Recommended starting points To familiarize yourself with the basic concepts of the Bus Manager, the following
starting points are recommended:

Video introducing the Bus Manager in ConfigurationDesk

Introduction to the Bus Manager in ConfigurationDesk

This video shows you how you can configure CAN and LIN communication
by using the Bus Manager in ConfigurationDesk and implement the bus
communication in a real-time application.

To watch this video, click the following link or scan the QR code:
https://www.dspace.com/dspace-help/wupe2

Bus Manager Tutorial The Bus Manager Tutorial guides you through the
basic steps when you start working with the Bus Manager. The tutorial
introduces you to the use scenarios for simulating, inspecting, and manipulating
bus communication and covers different Bus Manager workflows. For former
users of the RTI CAN MultiMessage and RTI LIN MultiMessage Blocksets, the
workflows for building a real‑time application are especially relevant. Refer to Bus
Manager Tutorial .

Use scenarios for configuring bus communication with the Bus

Manager The Bus Manager provides different approaches for configuring bus
communication for simulation, inspection, manipulation, and gateway purposes.
For an overview of the different approaches and for criteria that can help you
to select the suitable approach for your use scenario, refer to Use Scenarios for
Configuring Bus Communication with the Bus Manager on page 29.

498
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Starting Points for Former Users of the RTI CAN MultiMessage and RTI LIN MultiMessage Blocksets

Aspects of supported CAN, LIN, and AUTOSAR features The Bus Manager
uses an AUTOSAR-oriented way to implement CAN and LIN communication. The
following topics can help you familiarize yourself with this approach:
§ Aspects of Supported AUTOSAR Features on page 63
§ Aspects of Supported CAN Bus Features on page 77
§ Aspects of Supported LIN Bus Features on page 88
The AUTOSAR-oriented approach also affects the representation of elements
in the Bus Manager. For example, a BO_ message that is specified in a DBC
communication matrix is represented as an ISignal IPDU in the Bus Manager.
For an overview of the mapping of element types, refer to Mapping of Bus
Manager PDU Types to Communication Standard PDU Types on page 537.

499
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Information for Former Users of the RTI CAN MultiMessage Blockset and RTI LIN MultiMessage Blockset

Mapping Features of the RTI CAN MultiMessage Blockset

Where to go from here Information in this section

Mapping Features of the RTI CAN MultiMessage Blockset to

Features of the Bus Manager................................................................. 500

Using Features of the RTI CAN MultiMessage Blockset

Independently from the Bus Manager.................................................... 508

Unsupported Features of the RTI CAN MultiMessage Blockset............... 509

Mapping Features of the RTI CAN MultiMessage Blockset to Features of the

Bus Manager

Introduction The functionalities of many features of the RTI CAN MultiMessage Blockset are
also available for the Bus Manager.

Feature mapping The following table maps features of the RTI CAN MultiMessage Blockset to
features of the Bus Manager. It also provides links to further information in the
Bus Manager documentation.

In some cases, there are two ways to implement the functionalities of features of
the RTI CAN MultiMessage Blockset in the Bus Manager:
§ By using bus configuration features.
Use bus configuration features if you want to configure a feature only for a
specific instance of an element, e.g., of a frame . For basic information, refer
to Basics on Bus Configuration Features on page 192.
§ By modifying the communication matrix.
Modify settings in the communication matrix if you want to change
all instances of an element in the communication matrix and all
bus configurations. For basic information, refer to Basics on Modifying
Communication Matrices on page 391.

RTI CAN MultiMessage Blockset Bus Manager

Block or Page Feature Feature Refer to …
RTICANMM Configure access Specify the bus access for bus access Basics on Bus Access Requests on
ControllerSetup block to the real‑time requests . page 155
hardware.
General Settings Enable CAN FD Enable CAN FD support for the CAN function Configuring CAN Bus Properties in
page (RTICANMM support. block that specifies the bus access . CAN Function Blocks on page 361
MainBlock) Modify the CAN FD support that is specified Configurable Settings of Frames
in the communication matrix on page 409

500
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Mapping Features of the RTI CAN MultiMessage Blockset

RTI CAN MultiMessage Blockset Bus Manager

Block or Page Feature Feature Refer to …
General Settings Use variants of Use different bus configurations to configure § Assigning Communication
page (RTICANMM configured bus variants of bus communication. Add the Matrix Elements to Bus
MainBlock) communication on Bus Configuration Enable feature to each Configurations on page 112
one CAN channel. bus configuration and assign the bus access § Enabling and Disabling Bus
requests of the bus configurations to the Configurations on page 331
same bus accesses . At run time, make sure § Specifying the Hardware Access
that only one bus configuration is enabled at on page 157
a time.
General Settings Specify the sample Configure the period of the Timer Event of a Basics on Tasks, Events, and
page (RTICANMM time. bus configuration. Runnable Functions Provided by
MainBlock) the Bus Manager on page 363
General Settings View a report Check the messages in the Message Viewer Adding communication matrices
page (RTICANMM containing warnings after the import of a communication matrix. on page 93
MainBlock) and errors on the Select the Communication Matrices Basics on Bus Manager-Related
selected database file. context set in the Conflicts Viewer to Conflicts on page 163
display conflicts that result from conflicting
communication matrix settings.
General Settings Update the Replace an assigned communication matrix in Basics on Replacing Assigned
page (RTICANMM configured bus a bus configuration. Communication Matrices on
MainBlock) communication to a page 435
newer version of
the communication
matrix.
General Settings Handle messages with Modify the length of the related IPDU, the § Configurable Settings of PDUs
page (RTICANMM overlapping signals. length of the ISignals, and/or the start bit on page 414
MainBlock) position of the ISignals in the communication § Configurable Settings of
matrix so that the ISignals do not overlap in ISignals on page 427
an IPDU.
Assign the ISignals that overlap in an IPDU to Assigning Communication Matrix
different bus configurations. Elements to Bus Configurations on
page 112
Network Node Use J1939 network Use the J1939 Network Management Enabling and Disabling J1939
Selection page management for Enable feature to enable or disable J1939 Network Management on
(RTICANMM J1939‑compliant network management for a communication page 310
MainBlock) network nodes . controller of a network node.
Various pages of Access data of the Enable test automation support and/or model Configuring Function Ports for
the RTICANMM bus communication access for function ports that are available for Bus Configuration Features on
MainBlock, e.g., via TRC file entries bus configuration features. page 198
Network Node and/or exchange data
Enable, Message with the behavior
Cyclic, and Message model.
Kickout pages
Network Node Enable Enable and disable Use the Communication Controller Enabling and Disabling
page (RTICANMM network nodes . Enable feature to enable or disable the Communication Controllers on
MainBlock) communication controller of a network node. page 302
Network Node Preselect a set Select the ECUs View or Clusters View of Working with Communication
Preselection page of network nodes the Buses Browser to sort PDUs by their Matrices on page 92
(RTICANMM for further message ECUs or network nodes . This lets you
MainBlock) setup. select PDUs in the context of their ECUs or
network nodes.

501
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Information for Former Users of the RTI CAN MultiMessage Blockset and RTI LIN MultiMessage Blockset

RTI CAN MultiMessage Blockset Bus Manager

Block or Page Feature Feature Refer to …
If you want to perform a restbus simulation Creating Restbus Configurations
for one or more ECUs or network nodes on page 121
under test, you can create a restbus
configuration. When you do this, all the
communication matrix elements that are
required for the restbus simulation are
assigned to a bus configuration in one step.
§ TX Messages Select TX and RX Assign PDUs that are available in the § Bus Configuration Tables on
page (RTICANMM messages. communication matrix to the Simulated page 103
MainBlock) ECUs, Inspection, and/or Manipulation § Assigning Communication
§ RX Messages part of a bus configuration, for example, Matrix Elements to Bus
page (RTICANMM by manually selecting individual PDUs or Configurations on page 112
MainBlock) selecting all PDUs that are transmitted and/or
received by specific network nodes at once.
Free Raw Messages Specify free raw Add user‑defined ISignal IPDUs to CAN § Adding ISignal IPDUs to CAN
page (RTICANMM messages. channels in the communication matrix. Channels on page 396
MainBlock) Assign these IPDUs to a bus configuration § Assigning Communication
and use the Frame Access feature to access Matrix Elements to Bus
the IPDUs at run time. Configurations on page 112
§ Accessing CAN Frame Settings
on page 288
Capture Messages Capture messages on Specify CAN frame captures. Capturing CAN Frames on
page (RTICANMM the CAN bus whose page 171
MainBlock) identifiers match a
specified filter.
Triggering Options Specify global enable Use the Bus Configuration Enable feature Enabling and Disabling Bus
page (RTICANMM options and/or global to enable or disable a bus configuration Configurations on page 331
MainBlock) enable TX options. completely or partly.
Message Enable Enable and disable Use the PDU Enable feature to enable and Enabling and Disabling the
page (RTICANMM the transmission of disable the transmission of a PDU. Transmission of PDUs on page 238
MainBlock) messages.
§ Message Cyclic Specify cyclic Use the PDU Cyclic Timing Control feature Controlling the Cyclic Timing of
page (RTICANMM transmission for to specify a user‑defined cyclic timing for a CAN PDUs on page 243
MainBlock) messages and/or PDU.
§ Cycle Time specify default values Modify the cyclic timing of a PDU in the Configurable Settings of PDUs on
Defaults page for cyclic timings. communication matrix. page 414
(RTICANMM
MainBlock)
§ TX Cycle Time
page (RTICANMM
MainBlock)
Message Kickout Kick out messages. Use the PDU Trigger feature to specify a Specifying User-Defined Triggers
page (RTICANMM user‑defined trigger for the transmission of a for Transmitting PDUs on
MainBlock) PDU. page 246
Modify the event‑controlled timing of a PDU Configurable Settings of PDUs on
in the communication matrix. page 414
TX Delay Time Specify delay times for Modify the minimum delay time of a PDU in Configurable Settings of PDUs on
page (RTICANMM TX messages. the communication matrix. page 414
MainBlock)

502
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Mapping Features of the RTI CAN MultiMessage Blockset

RTI CAN MultiMessage Blockset Bus Manager

Block or Page Feature Feature Refer to …
§ Base/Update Specify an update Enable the use of the transfer property Using Event‑Controlled Timings
Messages page time and the update of ISignals. When you do this, the for Transmitting PDUs on
(RTICANMM number for TX transmission of a PDU can be triggered page 136
MainBlock) messages. when a value of an included ISignal
§ Base/Update Time has changed. If the communication matrix
page (RTICANMM specifies an event‑controlled timing for this
MainBlock) PDU, the transmission can be triggered with
repetitions.
TX Timeout Enable Specify timeouts for Use the Suspend Frame Transmission Suspending the Transmission of
page (RTICANMM TX messages. feature to suspend the transmission of a Frames on page 298
MainBlock) frame either permanently or temporarily.
Trigger Reaction Trigger reactions on Use the PDU RX Interrupt feature to trigger Triggering the Execution of
page (RTICANMM the receipt of specific the execution of functions in a behavior Functions in a Behavior Model via
MainBlock) RX messages. model by the reception of an RX PDU. RX Interrupts on page 281
Mapping page Map a behavior Enable model access for function ports that § Overview of Bus Configuration
(RTICANMM model to trigger are available for bus configuration features Features on page 195
MainBlock) the transmission of that can trigger the transmission of PDUs. § Configuring Function Ports for
messages. Map the function ports to model port blocks. Bus Configuration Features on
page 198
§ Configuring Bus
Communication for Real-Time
Applications with a Behavior
Model on page 45
TX Status Ports Use status ports for Add the PDU RX Status feature to an Observing the Status of Received
page (RTICANMM TX messages. RX instance of the related TX PDU. The PDUs on page 251
MainBlock) Loopback function port of the feature
provides information on whether the PDU is
received as a loopback PDU, i.e., whether the
PDU is transmitted by the Bus Manager in the
current sampling step.
RX Status Ports Use status and Use the PDU RX Status feature to access Observing the Status of Received
page (RTICANMM time ports for RX status information on an RX PDU. PDUs on page 251
MainBlock) messages.
RX ID Port Access the identifier Use the Frame Access feature to access Accessing CAN Frame Settings on
page (RTICANMM (ID) and identifier the identifier and identifier format of an RX page 288
MainBlock) format of RX frame. Moreover, this feature lets you access
messages. further frame settings, such as the payload
length and the payload in raw data format.
However, you cannot access the ID and
identifier format of J1939‑compliant IPDUs.
This is not supported by the Bus Manager.
RX Message Use length ports for Use the PDU Length feature to access the Accessing the Payload Length of
Length Port RX messages. received payload length of an RX PDU. CAN PDUs on page 249
page (RTICANMM
MainBlock)
RX Message Counter Use RX message Use the PDU RX Status feature to access Observing the Status of Received
page (RTICANMM counters. status information of an RX PDU. The value PDUs on page 251
MainBlock) of the Counter function port indicates how
many times the PDU was received.

503
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Information for Former Users of the RTI CAN MultiMessage Blockset and RTI LIN MultiMessage Blockset

RTI CAN MultiMessage Blockset Bus Manager

Block or Page Feature Feature Refer to …
§ TX Raw Data Access the raw data Use the PDU Raw Data feature to access Accessing the Payload of PDUs in
page (RTICANMM of TX and RX the payload of a TX or RX PDU in raw data Raw Data Format on page 240
MainBlock) messages. format.
§ TX Raw
Data Display
page (RTICANMM
MainBlock)
§ RX Raw Data
page (RTICANMM
MainBlock)
§ RX Raw
Data Display
page (RTICANMM
MainBlock)
§ RX Error Ports Use RX error ports. Use the Counter Signal feature for an RX Working with Counter Signals on
page (RTICANMM ISignal. The State function port indicates page 223
MainBlock) whether a received counter value was the
§ RX Error Display expected value.
page (RTICANMM Use the PDU User Code feature to apply Applying User Code to PDUs on
MainBlock) checksum algorithms to a TX PDU and to page 254
evaluate received checksum values of an RX
PDU.
Use the ISignal Group End-to-End Observing the Status of
Protection Status feature to observe the Received End‑to‑End‑Protected
status of an end-to-end-protected RX ISignal ISignal Groups on page 235
group.
Manipulation Options Use dynamic message Use the Frame Length feature to Manipulating the Payload Length
page (RTICANMM lengths. dynamically manipulate the length of a of CAN Frames on page 295
MainBlock) frame.
Manipulation Options Use dynamic Use the PDU User Code feature to apply Applying User Code to PDUs on
page (RTICANMM checksum algorithms. checksum algorithms to a TX PDU that is page 254
MainBlock) assigned to the Manipulation part of a bus
configuration. For example, you can do the
following:
§ Specify different checksum algorithms
in the user code and apply these
algorithms to specific ISignals via specified
user signals. You can also switch the
applicable checksum algorithms depending
on specific values of specified user ports.
§ Use temporary manipulation to manipulate
the TX PDUs for a defined number of
times.
TX ID Modify the identifier Use the Frame Access feature to change Accessing CAN Frame Settings on
page (RTICANMM (ID) of TX messages. the identifier of a TX frame. Moreover, this page 288
MainBlock) feature lets you change the identifier format,
specify a user‑defined trigger for the frame,
and access further frame settings, such as the
payload length and the payload in raw data
format.

504
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Mapping Features of the RTI CAN MultiMessage Blockset

RTI CAN MultiMessage Blockset Bus Manager

Block or Page Feature Feature Refer to …
TX Message Length Modify the length of Use the PDU Length feature to change the Accessing the Payload Length of
page (RTICANMM TX messages. length of a TX PDU. CAN PDUs on page 249
MainBlock)
Message Defaults Specify default values Modify the unused bit pattern of a PDU in Configurable Settings of PDUs on
page (RTICANMM for message bits that the communication matrix. page 414
MainBlock) are not used by
signals.
Message Variations Use message variants. Assign a PDU to different bus configurations Assigning Communication Matrix
page (RTICANMM and configure it differently for each bus Elements to Bus Configurations on
MainBlock) configuration, e.g., assign different ISignals to page 112
the bus configurations.
§ Checksum Implement checksum Specify the checksum algorithms in user code Applying User Code to PDUs on
Definition page algorithms for and use the PDU User Code feature to apply page 254
(RTICANMM messages. the user code to a PDU.
MainBlock)
§ Checksum
Messages page
(RTICANMM
MainBlock)
Checksum Definition Use end‑to‑end (E2E) End‑to‑end protection must be specified § Aspects of End‑to‑End (E2E)
page (RTICANMM protection. in the communication matrix. If it is, Protection for ISignal Groups on
MainBlock) you can assign end‑to‑end‑protected ISignal page 69
groups to bus configurations and use § Observing the Status of
the ISignal Group End-to-End Protection Received End‑to‑End‑Protected
Status feature to access status information ISignal Groups on page 235
on received end‑to‑end‑protected ISignal § Recalculating End-to-End
groups. Protection and Authentication
Moreover, if you manipulate ISignals that Information on page 217
are included in end‑to‑end protected ISignal
groups, you can enable the recalculation
of the end‑to‑end protection to prevent
unintended manipulation of the end-to-end
protection information.
Secure Onboard Use secure onboard Specify secure onboard communication in § Implementing Secure Onboard
Communication communication user code and enable the use of this Communication in Executable
page (RTICANMM (SecOC). user code for a bus configuration. Moreover, Applications on page 143
MainBlock) use the SecOC, SecOC Authenticator § Working with the Bus Manager
Invalidation, and/or SecOC Freshness SecOC Demo on page 471
Overwrite Value features to access and/or § Verifying the Authentication
manipulate secure onboard communication. Information of Received
Secured IPDUs on page 268
§ Invalidating the Authenticator
of Secured IPDUs on page 271
§ Overwriting the Freshness Value
of Secured IPDUs on page 274
Custom Code Specify custom code Specify custom code functions in user code Applying User Code to PDUs on
page (RTICANMM functions for TX and use the PDU User Code feature to apply page 254
MainBlock) messages. the user code to a TX PDU.

505
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Information for Former Users of the RTI CAN MultiMessage Blockset and RTI LIN MultiMessage Blockset

RTI CAN MultiMessage Blockset Bus Manager

Block or Page Feature Feature Refer to …
§ Model Signals (TX) Use TX model signals: Use the ISignal Value feature to access the § Working with ISignal Values on
page (RTICANMM § Select TX signals as value of a TX ISignal. To exchange the value page 221
MainBlock) TX model signals. of an ISignal with a behavior model, enable § Configuring Bus
§ Input Manipulation § Configure settings model access for the Value function port and Communication for Real-Time
page (RTICANMM of TX model map the function port to a model port. Applications with a Behavior
MainBlock) signals, such as the Model on page 45
§ Saturation page input manipulation
(RTICANMM or the signal
MainBlock) saturation limits
§ Signal Ranges
§ Specify the
page (RTICANMM
mapping to a
MainBlock)
behavior model.
§ Signal Mappings
page (RTICANMM
MainBlock)
Signal Defaults Specify default values Use the ISignal Value feature and specify Working with ISignal Values on
page (RTICANMM for signals. a user‑defined initial value for the Value page 221
MainBlock) function port.
Modify the initial value of an ISignal in the Configurable Settings of ISignals
communication matrix. on page 427
Custom Signal Specify custom signal Use the PDU User Code feature to apply Applying User Code to PDUs on
Manipulation manipulation. user code to a TX PDU that is assigned to the page 254
page (RTICANMM Manipulation part of a bus configuration.
MainBlock) In the user code, specify signal manipulation
algorithms and apply these algorithms to
ISignals of the PDU via specified user signals.
§ Dynamic Signal Use dynamic signal Use the ISignal Overwrite Value and/or § Overwriting ISignal Values on
Values page values, i.e., transmit ISignal Offset Value feature to dynamically page 228
(RTICANMM signal values for a manipulate the value of an ISignal. § Adding Offset Values to ISignal
MainBlock) defined number of Values on page 231
§ Dynamic Signal times.
Defaults page
(RTICANMM
MainBlock)
Toggle page Use toggle signals. Use the PDU User Code feature to apply Applying User Code to PDUs on
(RTICANMM user code to a PDU. In the user code, specify page 254
MainBlock) toggle and/or parity signals and assign these
Parity page Use parity signals. signals via specified user signals to ISignals of
(RTICANMM the PDU.
MainBlock)
Counter page Use counter signals. Use the Counter Signal feature to use an Working with Counter Signals on
(RTICANMM ISignal as a counter signal. page 223
MainBlock)
Signal Default Specify the default Specify the default enable state for bus § Use Scenarios for Manipulating
Manipulation manipulation for manipulation features. Depending on the Bus Communication on
page (RTICANMM signals. specific bus manipulation feature, you can do page 34
MainBlock) this via the following elements: § Basics on Bus Manipulation
§ The Enable function port Features on page 213
§ The feature switch
Specifying the enable state can also affect
ISignals that are simulated by the Bus

506
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Mapping Features of the RTI CAN MultiMessage Blockset

RTI CAN MultiMessage Blockset Bus Manager

Block or Page Feature Feature Refer to …
Manager. For example, you add the Counter
Signal simulation feature to one instance of
an ISignal and the ISignal Overwrite Value
manipulation feature to another instance.
When the manipulation feature is disabled
at run time, the counter signal is transmitted
on the bus. When the manipulation feature
is enabled, the counter signal is manipulated
before it is transmitted on the bus.
Model Signals (RX) Use RX model signals. Use the ISignal Value feature to access the § Working with ISignal Values on
page (RTICANMM value of an RX ISignal. To exchange the value page 221
MainBlock) of an ISignal with a behavior model, enable § Configuring Bus
model access for the Value function port and Communication for Real-Time
map the function port to a model port. Applications with a Behavior
Model on page 45
§ Gateway Signals Specify a gateway Specify CAN frame gateways. If required, § Specifying CAN Frame
page (RTICANMM to exchange signals you can use bus manipulation features to Gateways on page 173
MainBlock) between two CAN manipulate bus communication before it is § Overview of Bus Configuration
§ Gateway Defaults buses. passed to the receiving CAN bus. Features on page 195
page (RTICANMM
MainBlock)
§ Signal Default
Manipulation
page (Gateway)
(RTICANMM
MainBlock)
Code Options Prevent RX status for Use the PDU RX Status feature to access the Observing the Status of Received
page (RTICANMM loopback messages. status of a received PDU. Provide the values PDUs on page 251
MainBlock) of the Loopback and State function ports
to a behavior model. In the behavior model,
use the provided values to set the RX status,
i.e., set the RX status only if the PDU is not
received as a loopback PDU in the current
sampling step.
Code Options Use specific data types The data type of bus configuration -
page (RTICANMM for ports. function ports is determined by the
MainBlock) related bus configuration feature and/or
bus configuration element and cannot be
changed.
However, ConfigurationDesk lets you
generate model ports for function ports.
When you do this, the data type of the
generated model ports is inherited from the
related function ports by default. Via the
Model port data type property of each bus
configuration, you can set the data type to
Float64 for all model ports to be generated.
You can access the property on the Model
Interface page of the Properties Browser
when you select a bus configuration.

507
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Information for Former Users of the RTI CAN MultiMessage Blockset and RTI LIN MultiMessage Blockset

RTI CAN MultiMessage Blockset Bus Manager

Block or Page Feature Feature Refer to …
Code Options Specify the kickout Use the PDU Trigger or Frame Access Triggering the Transmission of
page (RTICANMM behavior. feature to specify a user‑defined trigger for PDUs and Frames via User-Defined
MainBlock) the transmission of a PDU or frame and Triggers on page 210
specify the triggering behavior.
Peripheral Options Create a Traffic Select the Bus statistics checkbox of a CAN § Basics on Bus Access Requests
page (RTICANMM outport. function block that specifies a bus access . on page 155
MainBlock) Map the Busload function port to a model § Configuring CAN Bus Properties
port block. in CAN Function Blocks on
page 361
§ Handling the Model Interface
(ConfigurationDesk Real-Time
Implementation Guide )

Using Features of the RTI CAN MultiMessage Blockset Independently from the
Bus Manager

Introduction Some features of the RTI CAN MultiMessage Blockset can be implemented
independently from the Bus Manager.

Feature mapping The following table provides an overview of those features of the RTI CAN
MultiMessage Blockset that can be realized independently from the Bus
Manager. It also provides links to further information in the user documentation.

RTI CAN MultiMessage Do the Following Refer to …

Blockset
Page of the Feature
RTICANMM
MainBlock
Includes page Specify In ConfigurationDesk, add header files to application § Specifying Options for the Build
header files processes via properties of build configuration sets. Process (ConfigurationDesk Real-Time
to be Implementation Guide )
included in § Limitations Concerning the Build and
the build Download Process (ConfigurationDesk
process Real-Time Implementation Guide )
Experimental Enable CAN § In ConfigurationDesk: § CAN (ConfigurationDesk I/O Function
Software page message § Assign a hardware resource to a CAN function Implementation Guide )
handling in block to access a channel of your real‑time § Building Real-Time Applications
real-time hardware. (ConfigurationDesk Real-Time
testing. § Configure the CAN function block according Implementation Guide )
Code Options Enable the to your requirements. Do not map the § Loading and Executing Real-Time
page log view. Configuration function port and do not assign Applications (ConfigurationDesk Real-
any bus access requests to the function block. Time Implementation Guide )
§ Monitoring and Logging Bus
§ Build a real‑time application and load it to your
Communication (ControlDesk Bus
real‑time hardware.
Navigator )

508
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Mapping Features of the RTI CAN MultiMessage Blockset

RTI CAN MultiMessage Do the Following Refer to …

Blockset
Page of the Feature
RTICANMM
MainBlock
§ Use the ControlDesk Bus Navigator to monitor
and/or log the bus communication of the accessed
channel in raw data format.

Unsupported Features of the RTI CAN MultiMessage Blockset

Introduction Some features of the RTI CAN MultiMessage Blockset are no longer supported.
These features can neither be implemented by using the Bus Manager nor by
other means, such as ControlDesk or the Bus Navigator.

Overview of unsupported The following table provides an overview of the features of the RTI CAN
features MultiMessage Blockset that are no longer supported.

Page of the RTICANMM Unsupported Feature

MainBlock
Naming page Specify the naming of TRC file attributes.
Naming Mapping page Specify the naming of specific strings in TRC files.
Network Node Identification Specify the node addresses and 64‑bit names of network nodes for identification purposes.
page
Source Destination Mapping Specify the mapping of source network node and destination network node for J1939
page messages.
Instance to Container page Define an instance of a J1939 message to be shown in an associated J1939 container.
Capture Messages page Prevent RX status for captured messages that are received as loopback messages.
§ Network Node Enable page Specify whether the source values of TRC variables and inports are combined by a logical AND
§ Triggering Options page or OR.
§ Message Enable page
§ Message Cyclic page
RX ID Port page Access the identifier (ID) and identifier format of received J1939 messages.
Cycle Time Error page Specify the ranges for calculating cycle time errors.
J1939 TX ID page Modify the priority and the source and destination nodes of J1939 TX messages during run
time.
Signal Ranges page Use saturation range limits that are specified in a database.
Signal Errors page Specify error values for signals to be transmitted.
Code Options page § Specify how to reset all the RTICANMM MainBlock settings and values written to TRC file
variables and outports.
§ Specify whether the cycle time of a TX message is reset by kickout.

509
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Information for Former Users of the RTI CAN MultiMessage Blockset and RTI LIN MultiMessage Blockset

Page of the RTICANMM Unsupported Feature

MainBlock
§ Specify how to handle the extended data page (EDP) bit of CAN message identifiers for
J1939.

Tip

The Bus Manager processes J1939‑compliant IPDUs regardless of whether the EDP bit is
set to 0 or 1.

TRC Options page Specify general settings for the TRC file, such as the hierarchy and the topmost nodes.
TRC Extras page Add additional information to the TRC file.
Peripheral Options page Specify whether an ECU hierarchy or message‑oriented hierarchy is used as the output port bus
structure.

510
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Mapping Features of the RTI LIN MultiMessage Blockset

Mapping Features of the RTI LIN MultiMessage Blockset

Where to go from here Information in this section

Mapping Features of the RTI LIN MultiMessage Blockset to

Features of the Bus Manager................................................................. 511

Unsupported Features of the RTI LIN MultiMessage Blockset.................. 516

Mapping Features of the RTI LIN MultiMessage Blockset to Features of the

Bus Manager

Introduction The functionalities of many features of the RTI LIN MultiMessage Blockset are
also available for the Bus Manager.

Feature mapping The following table maps features of the RTI LIN MultiMessage Blockset to
features of the Bus Manager. It also provides links to further information in the
Bus Manager documentation.

In general, there are two ways to implement the functionalities of features of the
RTI LIN MultiMessage Blockset in the Bus Manager:
§ By using bus configuration features.
Bus configuration features apply only to a specific instance of an element, e.g.,
of an ISignal . For basic information, refer to Basics on Bus Configuration
Features on page 192.
§ By modifying the communication matrix.
Modifying settings in the communication matrix changes all instances of
an element in the communication matrix and all bus configurations. For
basic information, refer to Basics on Modifying Communication Matrices on
page 391.

RTI LIN MultiMessage Blockset Bus Manager

Block or Page Feature Feature Refer to …
RTILINMM Configure access Specify the bus access for bus access requests. Basics on Bus Access Requests on
ControllerSetup block to the real‑time page 155
hardware.
General Settings Use variants of Use different bus configurations to configure § Assigning Communication
page (RTILINMM configured bus variants of bus communication. Add the Matrix Elements to Bus
MainSetup) communication on Bus Configuration Enable feature to each Configurations on page 112
one LIN channel. bus configuration and assign the bus access § Enabling and Disabling Bus
requests of the bus configurations to the Configurations on page 331
same bus accesses . At run time, make sure § Specifying the Hardware
Access on page 157

511
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Information for Former Users of the RTI CAN MultiMessage Blockset and RTI LIN MultiMessage Blockset

RTI LIN MultiMessage Blockset Bus Manager

Block or Page Feature Feature Refer to …
that only one bus configuration is enabled at
a time.
General Settings View a report Check the messages in the Message Viewer Adding communication matrices
page (RTILINMM containing warnings after the import of a communication matrix. on page 93
MainSetup) and errors on the Select the Communication Matrices Basics on Bus Manager-Related
selected database file. context set in the Conflicts Viewer to Conflicts on page 163
display conflicts that result from conflicting
communication matrix settings.
General Settings Update the configured Replace an assigned communication matrix in Basics on Replacing Assigned
page (RTILINMM bus communication a bus configuration. Communication Matrices on
MainSetup) to a newer version page 435
of the communication
matrix.
Network Node Preselect a set of Select the ECUs View or Clusters View of Working with Communication
Preselection network nodes for the Buses Browser to sort PDUs by their Matrices on page 92
page (RTILINMM further frame setup. ECUs or network nodes . This lets you
MainSetup) select PDUs in the context of their ECUs or
network nodes.
If you want to perform a restbus simulation Creating Restbus Configurations
for one or more ECUs or network nodes on page 121
under test, you can create a restbus
configuration. When you do this, all the
communication matrix elements that are
required for the restbus simulation are
assigned to a bus configuration in one step.
Various pages of the Access data of the Enable test automation support and/or model Configuring Function Ports for
RTILINMM MainSetup bus communication access for function ports that are available for Bus Configuration Features on
block, e.g., Master via TRC file entries bus configuration features. page 198
Selection, Network and/or exchange data
Node Enable, and with the behavior
Event Triggered TX model.
pages
Master Selection Simulate LIN masters. Assign network nodes that contain a § Bus Configuration Tables on
page (RTILINMM LIN master communication controller to the page 103
MainSetup) Simulated ECUs part of a bus configuration. § Assigning Communication
Matrix Elements to Bus
Configurations on page 112
Master Selection The RTILINMM Use the LIN Schedule Table feature and set Working with LIN Schedule
page (RTILINMM MainSetup block does the value of the Schedule Index function port Tables on page 307
MainSetup) not schedule the LIN to 0. In this case, the LIN communication
communication (no must be scheduled by another LIN master,
master). e.g., by a LIN master that is provided by a real
ECU.
Master Selection Select the default LIN Use the LIN Schedule Table feature and Working with LIN Schedule
page (RTILINMM schedule table. specify the initially active LIN schedule table Tables on page 307
MainSetup) via the Schedule Index function port.
Network Node Enable Enable and disable Use the Communication Controller Enable Enabling and Disabling
page (RTILINMM network nodes. feature to enable or disable a communication Communication Controllers on
MainSetup) controller of a network node . page 302

512
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Mapping Features of the RTI LIN MultiMessage Blockset

RTI LIN MultiMessage Blockset Bus Manager

Block or Page Feature Feature Refer to …
Network Node Sleep Send a sleep Transmit a master request frame (ID 60) § Accessing the Payload of
page (RTILINMM command on the bus. whose byte 0 is set to 0 on the bus, PDUs in Raw Data Format on
MainSetup) e.g., as follows: Assign a TX PDU that page 240
is mapped to the master request frame § Working with ISignal Values
to the Simulated ECUs part of a bus on page 221
configuration. Set byte 0 of the frame to 0: § Configurable Settings of
Use the PDU Raw Data or ISignal Value ISignals on page 427
feature, or modify the initial value of the § Working with LIN Schedule
related ISignal in the communication matrix. Tables on page 307
Schedule the transmission of the frame via
the LIN Schedule Table feature.
According to the LIN standard, transmitting
such a master request frame results in a sleep
command.
Network Node Sleep Set the transceiver to Use the Communication Controller Enable § Enabling and Disabling Bus
page (RTILINMM sleep mode without or Bus Configuration Enable feature to Configurations on page 331
MainSetup) sending a sleep enable or disable a communication controller § Enabling and Disabling
command. of a network node or the entire bus Communication Controllers on
configuration. page 302
Network Node Send wake‑up frames. Use the LIN Wake‑Up feature to send Sending Wake-Up Signals on a
Wakeup page wake‑up signals via a LIN communication LIN Bus on page 305
(RTILINMM controller.
MainSetup)
§ TX Frames Select TX and RX Assign PDUs that are available in the § Bus Configuration Tables on
page (RTILINMM frames. communication matrix to the Simulated page 103
MainSetup) ECUs, Inspection, and/or Manipulation § Assigning Communication
§ RX Frames part of a bus configuration, for example, Matrix Elements to Bus
page (RTILINMM by manually selecting individual PDUs or Configurations on page 112
MainSetup) selecting all PDUs that are transmitted and/or
received by specific network nodes at once.
Event triggered TX Trigger the Use the PDU Trigger feature to specify a § Aspects of Miscellaneous
page (RTILINMM transmission of user‑defined trigger for the transmission of a Supported LIN Bus Features on
MainSetup) event‑triggered PDU. page 88
frames. The Bus Manager handles event‑triggered § Specifying User-Defined
frames automatically: PDUs are configured in Triggers for Transmitting PDUs
the context of unconditional frames. When on page 246
the transmission of a PDU is triggered by
the PDU Trigger feature, the frame slot of
the associated event‑triggered frame is used
automatically.
However, collisions of event‑triggered frames
can be resolved only if the LIN master is
simulated by the Bus Manager and the
required collision resolver tables are specified
in the communication matrix.
Event triggered RX Specify decoding The Bus Manager decodes received § Aspects of Miscellaneous
page (RTILINMM options for event‑triggered frames automatically. For Supported LIN Bus Features on
MainSetup) event‑triggered frames example, use the PDU Raw Data and/or page 88
received on the bus. PDU RX Status feature to access the
data of a received PDU. By this, you
assign the related unconditional frames to
the bus configuration. When an associated

513
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Information for Former Users of the RTI CAN MultiMessage Blockset and RTI LIN MultiMessage Blockset

RTI LIN MultiMessage Blockset Bus Manager

Block or Page Feature Feature Refer to …
event‑triggered frame is received, it is § Accessing the Payload of
decoded automatically. PDUs in Raw Data Format on
page 240
§ Observing the Status of
Received PDUs on page 251
Enable Frames Enable and disable Use the PDU Enable feature to enable and Enabling and Disabling the
page (RTILINMM the transmission of disable the transmission of a PDU. Transmission of PDUs on
MainSetup) frames. page 238
TX Timeout Enable Specify timeouts for Use the Suspend Frame Transmission Suspending the Transmission of
page (RTILINMM TX frames. feature to suspend the transmission of a Frames on page 298
MainSetup) frame either permanently or temporarily.
RX Status and Time Enable status ports Use the PDU RX Status feature to access Observing the Status of Received
Ports page (RTILINMM and time ports for RX status information on an RX PDU. PDUs on page 251
MainSetup) frames.
§ TX Raw Data Access the raw data of Use the PDU Raw Data feature to access the Accessing the Payload of PDUs in
page (RTILINMM TX and RX frames. payload of a PDU in raw data format. Raw Data Format on page 240
MainSetup)
§ TX Raw
Data Display
page (RTILINMM
MainSetup)
§ RX Raw Data
page (RTILINMM
MainSetup)
§ RX Raw
Data Display
page (RTILINMM
MainSetup)
§ RX Error Ports Use RX error ports. Use the Counter Signal feature for an RX Working with Counter Signals on
page (RTILINMM ISignal. The State function port indicates page 223
MainSetup) whether a received counter value was the
§ RX Error Display expected value.
page (RTILINMM Use the PDU User Code feature to apply Applying User Code to PDUs on
MainSetup) checksum algorithms to a TX PDU and to page 254
evaluate received checksum values of an RX
PDU.
Use the ISignal Group End-to-End Observing the Status of
Protection Status feature to observe the Received End‑to‑End‑Protected
status of an end-to-end-protected RX ISignal ISignal Groups on page 235
group.
Frame Defaults Specify default values Modify the unused bit pattern of a PDU in the Configurable Settings of PDUs on
page (RTILINMM for frame bits that are communication matrix. page 414
MainSetup) not used by signals.
§ User Checksum Implement Specify the user‑defined checksum algorithms Applying User Code to PDUs on
Definition page user‑defined in user code and use the PDU User Code page 254
(RTILINMM checksum algorithms feature to apply the user code to a PDU. If
MainSetup) for frames. you want to dynamically apply user‑defined
§ User Checksum checksum algorithms to PDUs, use the PDU
Frames Page User Code manipulation feature.
(RTILINMM
MainSetup)

514
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Mapping Features of the RTI LIN MultiMessage Blockset

RTI LIN MultiMessage Blockset Bus Manager

Block or Page Feature Feature Refer to …
For example, you can do the following by
using the PDU User Code feature:
§ Specify different checksum algorithms in
the user code and apply these algorithms
to specific ISignals via specified user
signals. You can also switch the applicable
checksum algorithms depending on specific
values of specified user ports.
§ Use temporary manipulation for the
PDU User Code manipulation feature to
manipulate TX PDUs for a defined number
of times.
Custom Code Specify custom code Specify custom code functions in user code Applying User Code to PDUs on
page (RTILINMM functions for TX and use the PDU User Code feature to apply page 254
MainSetup) frames. the user code to a TX PDU.
§ Model Signals (TX) Use TX model signals: Use the ISignal Value feature to access the § Working with ISignal Values
page (RTILINMM § Select TX signals as value of a TX ISignal. To exchange the value on page 221
MainSetup) TX model signals. of an ISignal with a behavior model, enable § Configuring Bus
§ Input Manipulation § Configure settings model access for the Value function port and Communication for Real-Time
page (RTILINMM of TX model signals, map the function port to a model port. Applications with a Behavior
MainSetup) such as the input Model on page 45
§ Saturation page manipulation or the
(RTILINMM signal saturation
MainSetup) limits
§ Signal Ranges
page (RTILINMM
MainSetup)
Signal Defaults Specify default values Use the ISignal Value feature and specify Working with ISignal Values on
page (RTILINMM for signals. a user‑defined initial value for the Value page 221
MainSetup) function port.
Modify the initial value of an ISignal in the Configurable Settings of ISignals
communication matrix. on page 427
§ Dynamic Signal Use dynamic signal Use the ISignal Overwrite Value and/or § Overwriting ISignal Values on
Values page values, i.e., transmit ISignal Offset Value feature to dynamically page 228
(RTILINMM signal values for a manipulate the value of an ISignal. § Adding Offset Values to ISignal
MainSetup) defined number of Values on page 231
§ Dynamic Signal times.
Defaults page
(RTILINMM
MainSetup)
Counter page Use counter signals. Use the Counter Signal feature to use an Working with Counter Signals on
(RTILINMM ISignal as a counter signal. page 223
MainSetup)
Signal Default Specify the default Specify the default enable state for bus § Use Scenarios for
Manipulation manipulation for manipulation features. Depending on the Manipulating Bus
page (RTILINMM signals. specific bus manipulation feature, you can do Communication on page 34
MainSetup) this via the following elements: § Basics on Bus Manipulation
§ The Enable function port Features on page 213
§ The feature switch
Specifying the enable state can also affect
ISignals that are simulated by the Bus

515
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Information for Former Users of the RTI CAN MultiMessage Blockset and RTI LIN MultiMessage Blockset

RTI LIN MultiMessage Blockset Bus Manager

Block or Page Feature Feature Refer to …
Manager. For example, you add the Counter
Signal simulation feature to one instance of
an ISignal and the ISignal Overwrite Value
manipulation feature to another instance.
When the manipulation feature is disabled at
run time, the counter signal is transmitted
on the bus. When the manipulation feature
is enabled, the counter signal is manipulated
before it is transmitted on the bus.
Model Signals (RX) Use RX model signals. Use the ISignal Value feature to access the § Working with ISignal Values
page (RTICANMM value of an RX ISignal. To exchange the value on page 221
MainBlock) of an ISignal with a behavior model, enable § Configuring Bus
model access for the Value function port and Communication for Real-Time
map the function port to a model port. Applications with a Behavior
Model on page 45
Mapping page Specify the mapping Enable model access for function ports that § Overview of Bus Configuration
(RTICANMM of signals to a are available for bus configuration features of Features on page 195
MainBlock) user‑defined bus PDUs and/or ISignals. Map the function ports § Configuring Function Ports for
structure. to model port blocks. Bus Configuration Features on
page 198
§ Configuring Bus
Communication for Real-Time
Applications with a Behavior
Model on page 45

Unsupported Features of the RTI LIN MultiMessage Blockset

Introduction Some features of the RTI LIN MultiMessage Blockset are not supported by the
Bus Manager.

Overview of unsupported The following table provides an overview of the features of the RTI LIN
features MultiMessage Blockset that are no longer supported.

Page of the RTILINMM MainSetup Unsupported Feature

Block
Naming page Specify the naming of TRC file attributes.
Naming Mapping page Specify the naming of specific strings in TRC files.
Master Selection page § Access the status of the active LIN schedule table.
§ Specify a LIN schedule table as breakable.
§ Allow the LIN master to directly transmit a frame header from a simulation model
without the need for a schedule.
Network Node Selection page Select slave nodes for node configuration simulation.
Network Node Identification page Specify initial node configuration parameters for slave nodes.
Frame ID Assignment page Assign frame IDs to slave node frames (node configuration use case).

516
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Mapping Features of the RTI LIN MultiMessage Blockset

Page of the RTILINMM MainSetup Unsupported Feature

Block
§ Network Node Enable page Specify whether the source values of TRC variables and inports are combined by a
§ Network Node Sleep page logical AND or OR.
§ Network Node Wakeup page
§ Event Triggered RX page
§ Enable Frames page
Network Node Sleep page Create a bus state output to display the current state of the LIN bus.
Collision Resolver page Select event-triggered frames and specify collision resolver schedules for them.
Capture Frames page Specify the capturing of frames.
RX Frames Length Ports page Provide the lengths of RX frames to an outport.
RX Frames Checksum Ports page Access the received checksum values of RX frames via an outport.
RX Frames Checksum Display page Access the received checksum values of RX frames via TRC variables.
Frame Length page Modify the lengths of RX and TX frames.
Dynamic LIN Frame Checksum page Manipulate the checksums of LIN frames.
Signal Ranges page Use saturation range limits that are specified in a database.
Signal Errors page Specify error values for signals to be transmitted.
TRC Options page Specify general settings for the TRC file, such as the hierarchy and the topmost nodes.
TRC Extras page Add additional information to the TRC file.
Periphery Options page Create a traffic output port to display whether there is activity on the bus.

517
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Information for Former Users of the RTI CAN MultiMessage Blockset and RTI LIN MultiMessage Blockset

518
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Limitations for Using the Bus Manager

Limitations for Using the Bus Manager

Where to go from here Information in this section

Limitations for Communication Matrices and Communication

Standards.............................................................................................. 519

Limitations for CAN Communication..................................................... 525

Limitations for LIN Communication........................................................ 528

Limitations for Bus Configuration Handling............................................ 531

Limitations for Bus Simulation Containers.............................................. 533

Limitations for Communication Matrices and Communication Standards

Limitation for adding You can add communication matrices to the Buses Browser using drag & drop.
communication matrices using However, this is possible only if you access ConfigurationDesk and the respective
drag & drop file location as the same user. For example, if you start ConfigurationDesk
using the Run as administrator command but your user account is not an
administrator account, drag & drop is not possible.

Limitations for using Support of only one transmission mode The Bus Manager supports only
transmission modes according one transmission mode. According to the AUTOSAR and FIBEX standards, a
to AUTOSAR and FIBEX communication matrix can specify two transmission modes (True and False) for
a PDU. In this case, the Bus Manager evaluates the transmission modes in the
following order:
1. True transmission mode
2. False transmission mode
The Bus Manager uses the first found cyclic and/or event‑controlled timing for
transmitting a PDU. Other cyclic or event‑controlled timings and transmission
modes are ignored.

519
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Limitations for Using the Bus Manager

No switching of transmission modes during run time You cannot switch

between the transmission modes (True and False) of a PDU during run time.

Limitations for transmitting Only a changed coded ISignal value can trigger the transmission The
PDUs according to transmission of a PDU can be triggered only if the coded value of an ISignal
event‑controlled timings has changed. This has the following effects on the evaluation of the transfer
property:
§ The Triggered with repetition value is interpreted in the same way as the
Triggered on change with repetition value.
§ The Triggered without repetition value is interpreted in the same way as
the Triggered on change without repetition value.

Bus Manager-specific handling of ISignal groups and their included

ISignals The Bus Manager does not support the restrictive AUTOSAR
specifications that apply to the transfer property of ISignals if the ISignals are
included in ISignal groups. Instead, the Bus Manager accepts any setting of the
ISignal transfer property. In contrast to AUTOSAR, the Bus Manager therefore
also supports the following constellations:
§ ISignals whose transfer property is unspecified and those whose transfer
property is specified can be included in the same ISignal group.
§ The transfer property of ISignals that are included in an ISignal group can be
set to Triggered without repetition and Triggered on change without
repetition.
§ Even if the transfer property of an ISignal group is set to Pending, the transfer
property of the included ISignals can be set to any value.
The Bus Manager evaluates the transfer property of an ISignal group only
for included ISignals whose transfer property is unspecified. This results in the
following:
§ If the coded value of an included ISignal changes and the transfer property of
this ISignal is specified, the transmission of the PDU is triggered according to
the setting of the ISignal's transfer property. The setting of the ISignal group's
transfer property is ignored.
§ Only if the coded value of an included ISignal changes and the transfer
property of this ISignal is unspecified, is the transfer property of the ISignal
group evaluated. Only in this case the transmission of the PDU is triggered
according to the setting of the ISignal group's transfer property.

ISignals cannot trigger the transmission of extended multiplexed

IPDUs ISignals that are included in extended multiplexed IPDUs, which can
be specified in DBC communication matrices, cannot trigger the transmission of
the related IPDUs. For these ISignals, the value of the transfer property is ignored
and has no effects at run time.

Restricted use of the GenMsgNrOfRepetition attribute In DBC

communication matrices, the number of repetitions can be specified by the
GenMsgNrOfRepetition and GenMsgNrOfRepetitions attributes. If a DBC
communication matrix specifies both attributes, the Bus Manager evaluates only
the GenMsgNrOfRepetitions attribute. The GenMsgNrOfRepetition attribute
is ignored in this case.

520
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Limitations for Communication Matrices and Communication Standards

Limitations for minimum The Bus Manager supports only one minimum delay time for a PDU. According
delay times to the FIBEX standard, a communication matrix can specify more than one
minimum delay time for a PDU. In this case, the Bus Manager uses only the
first specified minimum delay time.

Limitations for the position of The Bus Manager supports only PDUs that are placed in the beginning of their
PDUs in frames related frames, i.e., a PDU‑to‑frame mapping must specify the position of a PDU
in such a way that there are no unused bits in the beginning of the frame.

Limitations for multiplexed To transmit a multiplexed IPDU, the Bus Manager does not evaluate the
IPDUs TRIGGER-MODE attribute. Instead, the Bus Manager transmits a multiplexed IPDU
each time its transmission is triggered by an ISignal IPDU that is configured as a
dynamic‑part alternative or as the static part.

Limitations for container No support of nested container IPDUs The Bus Manager does not support
IPDUs nested container IPDUs, i.e., container IPDUs that are included in other container
IPDUs. This applies regardless of the nesting level. For example, this also applies
to container IPDUs that contain at least one secured IPDU whose authentic IPDU
is a container IPDU.

No support of Trigger Transmit mode For the AUTOSAR parameter

IpduMContainerTxTriggerMode, the Bus Manager does not support the
Trigger Transmit mode, i.e., instances of a container IPDU cannot be queued
(e.g., if adding a contained IPDU to the container IPDU exceeds the boundaries
of the container IPDU).

No support of IPDUs with dynamic length for container IPDUs with static
container layout For container IPDUs with a static container layout, the Bus
Manager does not support contained IPDUs with dynamic length.

Limitation for transmitting container IPDUs with static container

layout For container IPDUs with a static container layout, the Bus Manager
ignores the THRESHOLD-SIZE attribute, i.e., the transmission of the container
IPDUs cannot be triggered by a specified threshold size. Instead, the transmission
of container IPDUs with a static container layout can be triggered by a container
timeout or container IPDU triggering, for example.

Limitation for the last‑is‑best collection semantics of contained secured

IPDUs For contained secured IPDUs with the last‑is‑best collection semantics,
the Bus Manager does not update the data in the container IPDU just before the
container IPDU is transmitted. Instead, the data of the secured IPDU is written
to the container IPDU when the transmission of the related authentic IPDU is
triggered. This data is not updated even if there is a delay between the trigger
and the actual transmission of the container IPDU.

Limitation for accessing data of received contained IPDUs with a queued

collection semantics When a container IPDU that contains several instances
of a contained IPDU (queued collection semantics) is received, the following
applies: Function ports of bus configuration features that are added to the

521
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Limitations for Using the Bus Manager

contained IPDU or its included elements, such as ISignals, only provide the data
of the last received instance.
However, depending on the specific bus configuration feature, all received
instances are considered for calculating function port values. For example, the
value of the Counter function port of the PDU RX Status feature is incremented
by the number of all received contained IPDU instances. The value of the
Delta Time function port is 0 because all contained IPDU instances are received
with the same container IPDU. Therefore, the time difference between the last
received instance and the previously received instance is 0 seconds.

Limitations for secure No automatic rejection of received secured IPDUs and authentic
onboard communication IPDUs The Bus Manager processes received secured IPDUs and the related
authentic IPDUs regardless of whether the received authentication information is
verified and the verification indicates a communication error. To reject a secured
IPDU and the related authentic IPDU in case of a communication error, you have
to verify the authentication information via the SecOC bus configuration feature
and provide the verification result to a mapped behavior model that realizes the
rejection.

Restricted support of multiple secured IPDUs per network node for

securing the same authentic IPDU For simulation and manipulation, the
Bus Manager does not support multiple secured IPDUs per network node that
secure the payload of the same authentic IPDU. This applies regardless of
whether the secured IPDU is configured as cryptographic IPDU. If two or more
secured IPDUs of one network node are assigned to the Simulated ECUs or
Manipulation part of a bus configuration and these IPDUs secure the payload
of the same authentic IPDU, a conflict occurs.

No support of secured PDU headers for received secured IPDUs The Bus
Manager does not support secured PDU headers for received secured IPDUs. If
the useSecuredPduHeader attribute is specified for a received secured IPDU
and set to any value but noHeader, the related authentic IPDU cannot be
decoded. Instead, only the raw data can be accessed, e.g., via experiment
software.

Limitations for calculating authentication information To calculate

authentication information, the secured IPDU and its related authentic IPDU are
required. This results in the following:
§ The authentication information can be calculated only if both IPDUs
are assigned to the same bus configuration part (i.e., Simulated ECUs,
Inspection, or Manipulation) of the same bus configuration. This applies
regardless of whether the secured IPDU is configured as a cryptographic IPDU.
§ If the secured IPDU is configured as a cryptographic IPDU, the following
applies: The authentication information cannot be calculated if both IPDUs are
contained in a TX static container IPDU and the TX cryptographic IPDU triggers
the transmission of the container IPDU before the authentic IPDU is included in
the container IPDU.

Limitations for using secure onboard communication on simulation

platforms via bus simulation containers When you configure secure
onboard communication via the Bus Manager and generate bus simulation
containers (BSC files), the configured secure onboard communication is included

522
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Limitations for Communication Matrices and Communication Standards

in the generated BSC files. BSC files are supported by various simulation
platforms. It depends on the specific simulation platform whether the configured
secure onboard communication is supported.

Limitations for end-to-end The Bus Manager processes received IPDUs and the contained ISignal groups
protection regardless of whether the received end-to-end protection information is
evaluated and the evaluation indicates a communication error. To reject an IPDU
and a contained ISignal group in case of a communication error, you have to
evaluate the end-to-end protection information using the ISignal Group End-
to-End Protection Status bus configuration feature and provide the evaluation
result to a mapped behavior model that realizes the rejection.

Limitations for global time Support as of AUTOSAR Release 4.3.0 The Bus Manager supports global
synchronization time synchronization according to AUTOSAR Release 4.3.0 and later AUTOSAR
Releases. Global time synchronization according to older AUTOSAR Releases is
not supported.

No support of offset time bases The Bus Manager does not support offset
time bases.

No support of immediate time synchronization The Bus Manager does

not support the immediate time synchronization functionality.

Implementing global time synchronization in offline simulation

applications requires a behavior model If you want to implement global
time synchronization in offline simulation applications , you have to simulate
global time masters either by using the Bus Manager or the RTI Synchronized
Time Base Manager Blockset. In both cases, the time must be set via
the STBM_SET_GLOBAL_TIME block in a Simulink® model. Therefore, bus
simulation containers without mapped behavior models are not supported for
implementing global time synchronization in offline simulation applications.

Limitations for partial Restricted support of partial networking functionalities The Bus
networking Manager supports only partial networking functionalities that were introduced
with AUTOSAR Release 4.3. Partial networking functionalities from later
AUTOSAR Releases, such as enabling and disabling PDUs via the PDU router
module, are not supported.

No support of nested ISignal IPDU groups The Bus Manager does not
support nested ISignal IPDU groups, i.e., the Bus Manager supports only ISignal
IPDUs and NMPDUs containing ISignals in ISignal IPDU groups.

Partial networking only for TX PDUs The partial networking applies only
to TX PDUs. If a partial network cluster is disabled, only the transmission of
the related TX PDUs stops. RX PDUs are decoded and processed, regardless
of whether the related partial network cluster is disabled. If a TX PDU is not
transmitted due to a disabled partial network cluster, the related RX PDU is not
reset to its initial values.

523
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Limitations for Using the Bus Manager

PDUs assigned to multiple partial network clusters If PDUs are assigned

to multiple partial network clusters, the transmission of the PDUs stops only if all
of the related partial network clusters are disabled.

Limitations for PDU gateways For PDU gateways, the following limitations apply:
§ The Bus Manager does not support PDU gateways for container IPDUs ,
multiplexed IPDUs , secured IPDUs , extended multiplexed IPDUs , or
J1939‑compliant IPDUs.
§ The Bus Manager does not consider timing constraints for gatewaying
PDUs. For example, delays between the reception of a source PDU and the
transmission of the target PDU might occur.
§ The Bus Manager does not evaluate the DEFAULT-VALUE-ELEMENT and PDU-
MAX-LENGTH attributes, which can be specified for PDU gateways in ARXML
communication matrices. The settings of these attributes are ignored.

Limitations for coded and No interface for coded ISignal values The Bus Manager does not provide
physical ISignal values an interface for coded ISignal values. Therefore, you cannot use coded ISignal
values from the behavior model or an experiment software in the Bus Manager.
Instead, the Bus Manager accesses ISignals via their converted physical signal
values.

Only linear computation methods supported To transmit or receive

ISignals on the bus, physical signal values must be converted to coded values.
The Bus Manager supports only linear computation methods for the conversion
of physical signal values to coded values and vice versa. If no linear computation
method is defined, an ISignal value is not converted and no code can be
generated.

Limited precision for linear scalings If a linear computation method that

is specified for a signal is not an identical computation method, the scaling is
performed with double precision arithmetic (IEEE 754). This results in at most 52
significant bits.

No support of multiple computation scales The Bus Manager does not

support multiple computation scales for the conversion of physical signal values
to coded values and vice versa. If the communication matrix defines multiple
computation scales for an ISignal, the Bus Manager uses the first linear scale it
finds and ignores all the following scales. However, in this case the conversion
might not be deterministic.

No code generation for ISignals without a data type for physical

values If the communication matrix does not define a data type for the
physical value of an ISignal, the Bus Manager can determine a data type
according to the computation scale specified for a coded ISignal. If the
communication matrix specifies an inconsistent or unsupported computation
method for a coded ISignal, the Bus Manager cannot determine a physical data
type.
Because the data type of a function port cannot be undefined, the Bus Manager
defines Double as the data type for the function ports of the ISignal in this case.
However, no code can be generated for this ISignal and a conflict occurs for the
affected bus configuration.

524
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Limitations for CAN Communication

Limitations for array signals Limitations for data types and byte order formats The Bus Manager only
supports array signals (i.e., signals with a width > 1) of the following type:
§ Data type: UInt8
§ Byte order format: Opaque
Other data types and byte order formats are not supported for array signals.

No support of dynamic length array signals The Bus Manager does not
support dynamic length array signals, i.e., array signals of UINT8_DYN data type.

No support of computation methods The Bus Manager does not support

computation methods for array signals. If the communication matrix specifies
computation methods for array signals, they are ignored by the Bus Manager.

No support for Scale The Bus Manager does not support Scale Constraints and Invalid Values.
Constraints and Invalid Values

No automatic usage of ISignal The communication matrix can provide upper and lower signal value limits for TX
value limits specified in the ISignals. The Bus Manager cannot identify these values to use them as default
communication matrix minimum or maximum saturation values.

Limitations for CAN Communication

Limitations for transmitting If more than one CAN frame is to be transmitted via one communication
CAN frames cluster in one sampling step, the transmission sequence is undefined.

Limitations for CAN frame The Bus Manager does not support CAN frame variants within one
variants communication cluster. CAN frame variants are frames with the same CAN
identifier and addressing mode (standard or extended) but different frame-
related settings (e.g., CAN FD support, bit rate switch, or frame length). If CAN
frame variants are exchanged via a communication cluster at run time, their
behavior is undefined.

If you want to work with CAN frame variants for a communication cluster, you
have to configure the frames in one of the following ways:
§ Assign each frame variant to a separate bus configuration and add the Bus
Configuration Enable feature to all the bus configurations. At run time, you
must ensure that only one of the bus configurations is active at a time, i.e., the
state of all other bus configurations must be set to 0: Disabled.
§ Add the Frame Access feature to the frame variants. At run time, you must
specify unique frame settings for each frame variant.

Refer to Working with Bus Configuration Features on page 191.

525
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Limitations for Using the Bus Manager

Limitations for CAN remote The Bus Manager does not support CAN remote frames, i.e.:
frames § The Bus Manager cannot transmit remote frames for configured CAN RX
PDUs.
§ The transmission of CAN TX PDUs cannot be triggered by received remote
frames.

Limitations for decoding data For CAN PDUs, the number of data bytes that are transmitted on the bus might
bytes of received PDUs differ from the number of data bytes that is specified in the communication
matrix. The Bus Manager can receive such PDUs. However, the following
limitations apply in this case:
§ If a received PDU has more data bytes than specified in the communication
matrix, the Bus Manager decodes only the number of data bytes that is
specified in the communication matrix. The other data bytes are ignored.
§ The Bus Manager decodes signals only if they are received completely.
Therefore, if a signal is only partially received because the related PDU is
transmitted with fewer data bytes than specified in the communication matrix,
the Bus Manager does not decode this signal at all.

However, in case of a J1939-compliant IPDU that is transmitted using the

Connection Mode Data Transfer protocol, the Bus Manager returns the
number of data bytes that are actually received with the end‑of‑message
acknowledgment (EOM).

Limitations for CAN FD The Bus Manager does not support multiple PDUs per CAN FD frame. Each
CAN FD frame must contain exactly one PDU.

Limitations for J1939 No support of J1939 diagnostic communication manager

(J1939DCM) The Bus Manager does not support the J1939 diagnostic
communication manager according to J1939‑73. If a communication matrix
specifies J1939 diagnostic messages, these messages are imported to the
ConfigurationDesk application but treated as standard ISignal IPDUs.

No support of J1939 request manager The Bus Manager does not support
the J1939 request manager, i.e., the Bus Manager cannot automatically trigger
the transmission of a TX PDU when a J1939 request message is received on the
bus.
To trigger the transmission of a TX PDU with the receipt of a J1939 request
message, you have to configure this behavior manually. For example, you can
do this as follows: Assign the RX PDU that contains the J1939 request message
and the related TX PDU to the Simulated ECUs part of a bus configuration.
Add the PDU RX Status feature to the RX PDU and the PDU Trigger feature
to the TX PDU. In a mapped behavior model, you can model the triggering
behavior by using the value of the State function port as the input source for the
Trigger function port. For more information, refer to Basics on Bus Configuration
Features on page 192.

J1939 communication specified in ARXML files as of AUTSOAR Release

4.3.0 The Bus Manager supports J1939 communication that is specified in

526
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Limitations for CAN Communication

ARXML files according to AUTOSAR Release 4.3.0 and later AUTOSAR Releases.
J1939 according to older AUTOSAR Releases is not supported.

Limitations for J1939‑21 For J1939‑21, the following limitations apply:

§ If J1939‑21 communication is exchanged by using the Connection Mode
Data Transfer (CMDT) protocol, the Bus Manager does not transmit any
acknowledgement data if the bus communication is received via the
Inspection part of a bus configuration. For example, if a request‑to‑send
(RTS) message is received via the Inspection part, the Bus Manager does not
transmit a clear‑to‑send (CTS) or connection‑abort message.
To have the Bus Manager transmit acknowledgement data, the receiving
J1939 transport protocol node (J1939 TP node) must be simulated. For
example, if an RX PDU representing an RTS message is assigned to the
Simulated ECUs part of a bus configuration, the Bus Manager transmits a
CTS or connection‑abort message when the RTS message is received.
§ For manipulation, the Bus Manager supports only J1939‑21‑compliant IPDUs
with a payload length of up to 8 bytes. You can assign J1939‑21‑compliant
IPDUs with a payload length of more than 8 bytes to the Manipulation part
but you cannot add bus manipulation features to the IPDUs or their included
ISignals.

Limitations for J1939‑22 For J1939‑22, the following limitations apply:

§ The Bus Manager does not support the PDU 3 format (i.e., the standard CAN
identifier) for J1939‑22‑compliant IPDUs.
§ The Bus Manager does not support the Connection Mode Data Transfer
(CMDT) protocol for J1939‑22‑compliant IPDUs.
§ The Bus Manager does not support network management for J1939‑22
communication, i.e., network nodes that are involved in J1939‑22
communication cannot participate in the J1939 address‑claiming procedure.
§ For manipulation, the Bus Manager supports only J1939‑22‑compliant IPDUs
with a payload length of up to 60 bytes, i.e., IPDUs that are transmitted
using the Multi‑PG protocol. You can assign J1939‑22‑compliant IPDUs with
a payload length of more than 60 bytes to the Manipulation part but you
cannot add bus manipulation features to the IPDUs or their included ISignals.
§ The Bus Manager does not support container IPDUs or secured IPDUs that are
specified as J1939‑22‑compliant IPDUs in the communication matrix.
§ For DBC communication matrices, the Bus Manager does not support the
J1939MultiPgSizeThreshold parameter. If the parameter is specified, it is
ignored during the import of the DBC file. Instead, the Bus Manager uses a
fixed threshold of 53, i.e., the transmission of a Multi‑PG‑compliant CAN FD
frame is triggered when 53 bytes of the frame's payload are used. By this, the
transmission is triggered when a C‑PG with a payload of 8 bytes no longer fits
into the frame.

Limitations for extended For extended signal multiplexing with the Bus Manager, the following limitations
signal multiplexing apply:
§ Only scalar signals of integer type are supported as multiplexer signals.
If required, you can modify a multiplexer signal to change its coded category
and base data type. Refer to Basics on Modifying Communication Matrices on
page 391.

527
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Limitations for Using the Bus Manager

§ The Bus Manager does not check extended multiplexed IPDUs for overlapping
signals.
§ Up to five nesting levels are supported. If extended multiplexed IPDUs with
more nesting levels are assigned to a bus configuration, the run‑time behavior
is undefined.
§ Multiplexer values with up to 10 values or value ranges are supported.
If multiplexed signals are assigned to a bus configuration to which more
multiplexer values apply, the run‑time behavior is undefined.

Limitations for LIN Communication

Limitations for AUTOSAR files AUTOSAR Release 3.2.1 does not support collision resolver tables. Thus, resolving
collisions of event-triggered frames by automatically executing a related collision
resolver table is not possible with AUTOSAR files according to Release 3.2.1.

Limitations for DBC files The DBC file format provides no definitions for master nodes or schedules.
Because the Bus Manager supports only the transmission of LIN IPDUs according
to a schedule defined by the LIN master, the Bus Manager does not support DBC
files for describing a LIN bus system.

Limitations for SAE J2602 Limitations for master parameters and node attributes of LDF
support files J2602-compliant LDF files can contain optional master parameters and
node attributes. The following parameters/attributes are not evaluated by the
Bus Manager:
§ Master parameters
§ max_header_length
§ response_tolerance
§ Node attributes
§ response_tolerance
§ wakeup_time
§ poweron_time
If an LDF file contains these parameters/attributes, they are ignored by the Bus
Manager.

Unused frame bits are dominant In contrast to the SAE J2602 standard,
unused bits of a frame are transmitted as dominant bits (0), not as recessive bits.

ISignals included only once in a frame The SAE J2602 standard allows to
include ISignals more than once in a frame. The Bus Manager does not support
such frames. Each ISignal of a frame must be included exactly once in that
frame.

Response tolerances limited by dSPACE hardware The SAE J2602

standard allows response tolerances of less than 40% for LIN slaves. It cannot be
ensured that response tolerances of less than 40% can be achieved for simulated
LIN slaves on dSPACE hardware.

528
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Limitations for LIN Communication

Errors do not abort the transmission of frame headers and responses In

contrast to the SAE J2602 standard, the Bus Manager does not abort the
transmission of frame headers or frame responses if an error occurs during the
transmission.

No automatic parameterization of J2602 status bytes According to the

SAE J2602 standard, the first data byte of each frame is a status byte. The Bus
Manager does not parameterize the status bytes automatically (e.g., set a valid
bit ID). The parameterization of the status bytes has to be done via a mapped
behavior model, for example.

Limitations for J2602 error states The Bus Manager does not support the
J2602-compliant ID parity, framing, and bit error states. It is therefore not
possible to detect these errors during run time by using the status bytes as
intended by the SAE J2602 standard. To detect these errors at run time, you can
use checksum algorithms instead.

Limitations for J2602 functionalities The Bus Manager does not

automatically support the following J2602 functionalities:
§ Targeted Reset
§ Broadcast Reset
§ Wake-up Timings
To use these functionalities, they have to be modeled in a mapped behavior
model.

No automatic generation of errors due to sleep mode According to the

SAE J2602 standard, an error must be generated if sleep mode lasts for more
than four seconds. The Bus Manager does not automatically generate an error in
this case. The error generation has to be modeled in a mapped behavior model.

Limitations for LIN schedule Maximum number of scheduled frames per LIN schedule table A LIN
tables schedule table can schedule the transmission of one or more frames. The Bus
Manager supports only schedule tables that schedule the transmission of a
maximum of 255 frames.

Resume positions of interrupted LIN schedule tables specified in FIBEX

files For interrupted LIN schedule tables, the FIBEX standard supports the
following resume positions (e.g., after collision resolving):
§ Start from the beginning.
§ Start from the position where the schedule table was interrupted.
§ Start from any specific position.
The Bus Manager does not support the start from any specific position. Instead,
the Bus Manager treats the FIBEX-specific resume position like AUTOSAR-specific
resume positions. This results in the following behavior:
§ ResumePositon = 0: Start from the beginning.
§ ResumePositon ≥ 1: Start from the position where the schedule table was
interrupted.

Resume positions of interrupted LIN schedule tables specified in LDF

files LDF files do not support definitions for the resume position of
interrupted LIN schedule tables. An interrupted schedule table always starts from
the position where it was interrupted.

529
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Limitations for Using the Bus Manager

Limitations for LIN transport The Bus Manager does not provide automatic support for the LIN transport
protocol support protocol, which can be used for diagnostic purposes. You have to implement the
related functions with basic features, such as standard master request and slave
response frames.

Limitations for slave node Slave node configuration is performed by the LIN master. For example, if you
configuration work with off‑the‑shelf slave nodes, the LIN master can use special slave node
configuration commands in LIN schedule tables to set the network addresses and
frame identifiers of these slave nodes. For such a slave node configuration, the
following limitations apply:
§ The LIN master is simulated by the Bus Manager:
In this case, the Bus Manager can transmit slave node configuration
commands via master request frames. These commands must be specified
in LIN schedule tables in the communication matrix. If a required parameter
for such a command is missing (e.g., for the AssignNAD command), a sleep
command is generated, i.e., the first data byte of the master request frame is
set to 0. The next valid header that is sent wakes up the bus.
§ A LIN slave is simulated by the Bus Manager:
The Bus Manager does not respond to received slave node configuration
commands. Instead, the simulated LIN slave is configured according to the
specifications in the communication matrix.

Limitations for frames and Transmission of unconditional LIN frames Unconditional LIN frames can
PDUs be transmitted only according to a schedule defined by the LIN master. Timings
defined for PDUs that are included in an unconditional LIN frame are ignored.

Transmission of substituted frames of sporadic frames The Bus Manager

cannot transmit substituted frames of a sporadic frame according to an external
LIN scheduling. Substituted frames of a sporadic frame are transmitted only if the
transmission is scheduled by a LIN master that is assigned to a bus configuration.

No support of multiplexed IPDUs The Bus Manager does not support LIN
multiplexed IPDUs.

No support of LIN frame variants The Bus Manager does not support LIN
frame variants within one communication cluster. LIN frame variants are frames
with identical LIN identifier but different frame-related settings (e.g., frame type,
checksum type, or frame length). If LIN frame variants are exchanged via a
communication cluster at run time, their behavior is undefined.
If you want to work with LIN frame variants for a communication cluster, you
have to assign each frame variant to a separate bus configuration and add the
Bus Configuration Enable feature to all the bus configurations. At run time,
you must ensure that only one of the bus configurations is active at a time, i.e.,
the state of all other bus configurations must be set to 0: Disabled.
Refer to Working with Bus Configuration Features on page 191.

530
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Limitations for Bus Configuration Handling

Limitations for simulating LIN The Bus Manager does not support the simulation of more than one LIN slave
slave responses response via one bus access at the same time.
§ Effects on real-time applications:
If two LIN slave responses are to be transmitted via one bus access at the same
time, only the last response is sent at run time. If more than two LIN slave
responses are to be transmitted, the real-time application stops and the web
interface of the real-time hardware displays an error message in the message
viewer.
§ Effects on offline simulation applications:
If two or more LIN slave responses are to be transmitted via one bus access at
the same time, only the last response is sent at run time.

Limitations for Bus Configuration Handling

Bus Manager and RTI CAN Bus configurations and signals provided by blocks of the RTI CAN MultiMessage
MultiMessage Blockset/RTI LIN Blockset and/or RTI LIN MultiMessage Blockset must not be mapped to the same
MultiMessage Blockset CAN/LIN function block. When you work with the Bus Manager and a behavior
model that contains blocks of these blocksets, make sure that you use separate
CAN/LIN function blocks to specify the hardware access for them.

One bus configuration must The Bus Manager supports multicore (MC) and multi-processing-unit (multi-PU)
run on one core applications. However, a bus configuration must always be assigned to one
core. You cannot split a bus configuration to run parts of it on different cores.
Therefore, you must not connect one bus configuration to two or more behavior
models that are assigned to different application processes, for example.

Limitation for replacing When you replace an assigned communication matrix, existing ISignals can be
an assigned communication identified only by their name. They cannot be identified by their start bits.
matrix

Limitations for element Depending on the tool chain you use (operating system, experiment software,
names modeling tool, etc.), UTF-16 characters might not be supported. To avoid
problems, use only alphabetic and numeric ASCII characters and underscores
for names of communication matrix elements and bus configuration elements.
Additionally, to avoid conflicts in the TRC file generation, do not use the
following characters:
§ "
§ /
§ .

For most bus configuration elements (e.g., ECUs, communication controllers,

PDUs etc.), you cannot edit the names in the ConfigurationDesk application.

531
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Limitations for Using the Bus Manager

For these elements, adhere to the restrictions above when specifying the names
within the communication matrix.

Limitation for event periods Depending on the configured bus communication, various events with
preconfigured periods are generated automatically for each bus configuration.
If you want to change a preconfigured period while you are working without a
behavior model, the minimum supported period is 1 ms.

Limitations for transmitting The transmission of PDUs that are assigned to the Simulated ECUs part of a bus
PDUs that are assigned to the configuration is influenced by the related BusCfg_MainFunctionDeliver [<bus
Simulated ECUs part configuration name>] runnable function. Regarding the deliver runnable
function, the following limitations apply:
§ Triggers for transmitting PDUs cannot be queued. If there are two or more
triggers before the first trigger is evaluated by the deliver runnable function,
only the last trigger is evaluated and the PDU is transmitted according to this
trigger.
§ After the transmission of a PDU is triggered, data such as ISignal values is
written to the PDU when the related deliver runnable function evaluates the
trigger. The PDU is transmitted with this data. If there is a delay between the
trigger and its evaluation by the deliver runnable function, this might not be
the data when the trigger occurred.

Limitation for using physical When you create model port blocks for function outports of ISignal values, the
ISignal values as initial values physical ISignal values that are specified in the communication matrix can be
of model inports used as the initial value of related model inports. This is possible only if you
create model port blocks via the Generate New Simulink Model Interface
command.

No support for stop values ConfigurationDesk lets you use stop values for signals. Bus configurations do not
support stop values.

Limitations for copy and cut § You cannot directly copy or cut communication controllers, partial network
operations clusters, or global time domains of a bus configuration. However, these
elements are copied or cut if you copy/cut related elements.
§ You cannot copy or cut unresolved elements of a bus configuration.

Limitations for importing You can import working views to a ConfigurationDesk application via CAFX
working views that contain (ConfigurationDesk application fragment) files. When a CAFX file contains Bus
Bus Configuration function Configuration function blocks, the following limitations apply.
blocks
No support of CAFX files exported with Release 2020‑B or earlier You
cannot import CAFX files that were exported with dSPACE Release 2020‑B or
earlier. If you try to do so, the import is aborted and a warning message is
displayed.

532
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Limitations for Bus Simulation Containers

No support of merging or replacing signal chains in working views You

cannot import the CAFX file via the Merge Signal Chain into Working View
or Replace Signal Chain in Working View commands. If you try to do so, the
import is aborted and a warning message is displayed.
You can import the CAFX file only via the Add Signal Chain to Working View
command.

Limitations for communication matrices For the used communication

matrices, the following limitations apply:
§ The communication matrices that were used to configure the Bus
Configuration function blocks must be available in the Buses Browser. If
one of the required communication matrices is missing, the import is aborted
and a warning message is displayed.
§ If user-defined ISignal IPDUs and/or ISignals were used to configure the Bus
Configuration function blocks, you must add the same user-defined ISignal
IPDUs and ISignals to the related communication matrix in the Buses Browser,
i.e., the following settings must match:
§ Related higher-level elements
§ Names
§ Direction (TX or RX)
If a required user-defined ISignal IPDU or ISignal is missing, the import is
aborted and a warning message is displayed.
§ User-defined settings of communication matrix elements are not included
in CAFX files. If communication matrix elements with user-defined settings
were used to configure Bus Configuration function blocks, e.g., PDUs with
user-defined cyclic timings or ISignals with modified base data types, the user-
defined settings are lost when you import a CAFX file. Instead, the original
communication matrix settings are used.

Limitations for the target ConfigurationDesk application Importing

a CAFX file that contains Bus Configuration function blocks to a
ConfigurationDesk application might cause problems when you build a real-
time application or generate bus simulation containers later on. To avoid these
problems, adhere to the following limitations:
§ Do not import the CAFX file to the ConfigurationDesk application from which
it was exported.
§ Do not import the CAFX file to the same ConfigurationDesk application more
than once.

Limitations for Bus Simulation Containers

Introduction For bus simulation containers that are generated with the Bus Manager, some
limitations apply.

533
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Limitations for Using the Bus Manager

Limitations for generating bus Only Simulink® implementation container (SIC) files as model
simulation containers by using implementation If you work with behavior models, you must work with
the Bus Manager Simulink implementation container (SIC) files as a model implementation .
Other file formats, such as FMU or SLX files, are not supported. If an application
process contains a model implementation that is no SIC file, no bus simulation
container is generated for this application process and the Message Viewer
displays a warning message.

Limitations for SIC files If you work with behavior models, the following
limitations apply for the required SIC files:
§ You cannot use SIC files that are generated with TargetLink.
§ You cannot use precompiled SIC files.
§ The SIC files must not contain A2L variable descriptions.
If an unsupported SIC file is assigned to an application process, no bus
simulation container is generated for this application process and the Message
Viewer displays a warning message.

Only one behavior model per application process You can generate bus
simulation containers only for application processes to which no or exactly one
behavior model is assigned. Multiple behavior models per application process
are not supported for bus simulation container generation. If multiple behavior
models are assigned to an application process, no bus simulation container
is generated for this application process and the Message Viewer displays a
warning message.

Reduced run‑time performance if a required SIC file is not included in a

bus simulation container In general, there are two ways to exchange data
with a behavior model:
§ Mapping model ports of an SIC file to bus configuration function ports before
you generate bus simulation containers, i.e., including the SIC file in the bus
simulation container.
§ Generating bus simulation containers and mapping the resulting BSC files to
behavior models in ConfigurationDesk or VEOS.
However, mapping BSC files to behavior models can significantly reduce the
run‑time performance, especially when a high number of signals is exchanged.
For optimum run‑time performance, it is strongly recommended to map a
required SIC file to bus configuration function ports before you generate bus
simulation containers.

Limitations for using BSC When you add BSC files as a model implementation to a ConfigurationDesk
files in ConfigurationDesk application, the following limitations apply:
applications
No MTFX export for elements of BSC files ConfigurationDesk does not
support exporting a complete model topology containing a BSC file into an
MTFX file. All parts of the model topology related to the BSC file, i.e., all
subsystems and all model port blocks of the BSC file, are ignored during an
MTFX export.

534
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Limitations for Bus Simulation Containers

Naming restrictions for SIC files and bus configurations When you use
BSC files in a ConfigurationDesk application, you must observe the following
naming restrictions:
§ If a BSC file contains a Simulink implementation container (SIC file), the name
of the model implementation that the SIC file describes must be unique in
the application process to which the BSC file is assigned. This applies to the
following:
§ All model implementations assigned to the application process.
§ All model implementations described by SIC files that are included in other
BSC files assigned to the application process.
§ The names of bus configurations that are included in a BSC file must be
unique in the application process to which the BSC file is assigned. This applies
to all BSC files and Bus Configuration function blocks that are assigned to
the application process.

Implementing the bus communication of BSC files in real-time

applications When implementing the bus communication of a BSC file in
a real-time application, the following restrictions apply:
§ You must map the Configuration ports of a BSC file to suitable bus
function blocks (CAN, LIN) to implement the bus communication in a real-time
application. If a Configuration port is not mapped to a suitable bus function
block, the related bus communication is not implemented in the real-time
application.
§ If a BSC file contains Configuration ports resulting from LIN bus access
requests, at least one of these Configuration ports must be mapped to a
LIN function block. This applies even if you do not want to implement LIN
communication in the real‑time application.
§ The bus function blocks (CAN, LIN) to which you map Configuration ports of
a BSC file must be used only by BSC files. The bus function blocks must not
be used by bus access requests of bus configurations or by ECU Interface
Configuration function blocks.

Limitations for using bus For using bus simulation containers on simulation platforms, the following
simulation containers on general limitations apply:
simulation platforms § Bus simulation containers can be used only on dSPACE platforms (e.g., VEOS,
SCALEXIO systems), including dSPACE platforms that support RTMaps, such as
AUTERA AutoBox or MicroAutoBox Embedded PC. Bus simulation containers
cannot be used on third-party platforms.
§ Bus simulation containers that contain a behavior model can only be used
with VEOS, SCALEXIO, MicroAutoBox III, or MicroLabBox II systems. Such bus
simulation containers cannot be used on other dSPACE platforms.

Limitations for using BSC files BSC files that contain LIN communication cannot be used with RTMaps. If you
with RTMaps try to generate artifacts for an RTMaps application from a BSC file that contains
LIN communication, an error message is displayed and the artifact generation is
aborted.

535
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Limitations for Using the Bus Manager

Limitations for using BSC files When you use BSC files with VEOS, the following limitations apply:
with VEOS § Precompiled BSC files can be used with VEOS only if they contain the original
source files.
§ BSC files that contain SIC files generated for the 64‑bit target architecture
cannot be used with VEOS running on a Windows operating system. To use
BSC files that contain SIC files with VEOS running on a Windows operating
system, the SIC file must be generated for the 32‑bit target architecture,
regardless of whether Windows 32‑bit or 64‑bit is used.
§ When an offline simulation application that contains one or more imported
BSC files runs on VEOS and you stop and restart the application, the
simulation results might be incorrect. To avoid this, you must unload the
offline simulation application before you restart it.

Limitations for using Task information variables are located at different places in offline offline
automation scripts for SIL simulation applications and real-time applications. Therefore, you must adapt
simulation and real-time automation scripts for VEOS and SCALEXIO/MicroAutoBox III/MicroLabBox II
simulation if the scripts unconditionally evaluate CallCounter, OverrunCount, or
TurnaroundTime variables.

536
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Appendix

Appendix

Where to go from here Information in this section

Mapping of Bus Manager PDU Types to Communication Standard

PDU Types............................................................................................. 537

Optimized Set of TRC File Variables for Bus Configuration

Function Ports....................................................................................... 540

Resolving the Bus Configuration Conflict: No Valid Application

Process Assigned................................................................................... 543

Mapping of Bus Manager PDU Types to Communication Standard PDU Types

Introduction The Bus Manager supports various PDU types according to AUTOSAR, FIBEX,
DBC, and LDF. To provide a consistent representation of the supported PDU
types, the Bus Manager uses PDU-specific element types that are derived from
the AUTOSAR PDU entities. PDUs of other communication standards are mapped
to these element types.

Mapping of PDU types The following table provides an overview of the mapping of the PDU types in the
Bus Manager to the PDU types provided by the AUTOSAR, FIBEX, DBC, and LDF
standards.

537
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Appendix

Bus Manager PDU Types AUTOSAR FIBEX / DBC / LDF

PDU Category Diagnostic PDU Type/ XCP Entity Category
Element Configuration
Type
Bus – § Diagnostic PDU Type: – ContainerIPdu – § FIBEX: –
Container § XCP Configuration: – § DBC: –
IPDU § LDF: –
Bus DCM – § Diagnostic PDU Type: DIAG- DcmIPdu DIAG-REQUEST § FIBEX: DIAG-REQUEST
IPDU REQUEST (diagPduType § DBC: –
§ XCP Configuration: – property) § LDF: –
– § Diagnostic PDU Type: DIAG- DcmIPdu DIAG-RESPONSE § FIBEX: DIAG-RESPONSE
RESPONSE (diagPduType § DBC: –
§ XCP Configuration: – property) § LDF: –
Bus – § Diagnostic PDU Type: – – – § FIBEX: –
Extended § XCP Configuration: – § DBC: Signal attribute:
Multiplexed SG_MUL_VAL_
IPDU § LDF: –
Bus – § Diagnostic PDU Type: – GeneralPurposeIPdu DLT § FIBEX: –
General- § XCP Configuration: – § DBC: –
Purpose § LDF: –
IPDU – § Diagnostic PDU Type: – GeneralPurposeIPdu SOMEIP_ § FIBEX: –
§ XCP Configuration: – SEGMENTED_IPDU § DBC: –
§ LDF: –
XCP § Diagnostic PDU Type: – GeneralPurposeIPdu XCP (plus § FIBEX:
§ XCP Configuration: XCP_PRE_ XCP_PRE_CONFIGURED
XCP_PRE_CONFIGURED CONFIGURED § DBC: –
frame category) § LDF: –
XCP § Diagnostic PDU Type: – GeneralPurposeIPdu XCP (plus § FIBEX: XCP_RUNTIME_
§ XCP Configuration: XCP_RUNTIME_ CONFIGURED
XCP_RUNTIME_ CONFIGURED § DBC: –
CONFIGURED frame category) § LDF: –
Bus – § Diagnostic PDU Type: – GeneralPurposePdu DoIP § FIBEX: –
General- § XCP Configuration: – § DBC: –
Purpose § LDF: –
PDU – § Diagnostic PDU Type: – GeneralPurposePdu SD § FIBEX: –
§ XCP Configuration: – § DBC: –
§ LDF: –
GLOBAL_TIME § Diagnostic PDU Type:– GeneralPurposePdu GLOBAL_TIME § FIBEX: –
§ XCP Configuration: – § DBC: –
§ LDF: –
Bus ISignal – § Diagnostic PDU Type: – ISignalIPdu – § FIBEX: APPLICATION
IPDU § XCP Configuration: – § DBC: BO_
§ LDF: Frame
Bus – § Diagnostic PDU Type: – MultiplexedIPdu – § FIBEX: APPLICATION
Multiplexed § XCP Configuration: – § DBC: BO_ with mode
IPDU signals
§ LDF: –
Bus – § Diagnostic PDU Type: – NmPdu – § FIBEX: NM
NMPDU § XCP Configuration: – § DBC: –
§ LDF: –

538
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Mapping of Bus Manager PDU Types to Communication Standard PDU Types

Bus Manager PDU Types AUTOSAR FIBEX / DBC / LDF

PDU Category Diagnostic PDU Type/ XCP Entity Category
Element Configuration
Type
Bus NPDU – § Diagnostic PDU Type: – NPdu – § FIBEX: TPL
§ XCP Configuration: – § DBC: –
§ LDF: Diagnostic_frames
(MasterReq, SlaveResp)
Bus – § Diagnostic PDU Type: – SecuredIPdu – § FIBEX: –
Secured § XCP Configuration: – § DBC: –
IPDU § LDF: –
Bus User- – § Diagnostic PDU Type: – UserDefinedIPdu – § FIBEX: –
Defined § XCP Configuration: – § DBC: –
IPDU § LDF: –
BAP § Diagnostic PDU Type: – UserDefinedIPdu BAP (cdd type § FIBEX: –
§ XCP Configuration: – property) § DBC: –
§ LDF: –
DIAG-STATE § Diagnostic PDU Type: – UserDefinedIPdu DIAG-STATE (cdd § FIBEX: DIAG-STATE
§ XCP Configuration: – type property) § DBC: –
§ LDF: –
SERVICE § Diagnostic PDU Type: – UserDefinedIPdu SERVICE (cdd type § FIBEX: –
§ XCP Configuration: – property) § DBC: –
§ LDF: –
XCP § Diagnostic PDU Type: – UserDefinedIPdu XCP (cdd type § FIBEX: –
§ XCP Configuration: property) plus § DBC: –
XCP_PRE_CONFIGURED XCP_PRE_ § LDF: –
CONFIGURED
(frame category)
XCP § Diagnostic PDU Type: – UserDefinedIPdu XCP (cdd type § FIBEX: –
§ XCP Configuration: property) plus § DBC: –
XCP_RUNTIME_CONFIGURED XCP_RUNTIME_ § LDF: –
CONFIGURED
(frame category)
Bus User- – § Diagnostic PDU Type: – UserDefinedPdu – § FIBEX: OTHER
Defined § XCP Configuration: – § DBC: –
PDU § LDF: –
BAP § Diagnostic PDU Type: – UserDefinedPdu BAP (cdd type § FIBEX: BAP
§ XCP Configuration: – property) § DBC: –
§ LDF: –
DIAG-STATE § Diagnostic PDU Type: – UserDefinedPdu DIAG-STATE (cdd § FIBEX: –
§ XCP Configuration: – type property) § DBC: –
§ LDF: –
SERVICE § Diagnostic PDU Type: – UserDefinedPdu SERVICE (cdd type § FIBEX: SERVICE
§ XCP Configuration: – property) § DBC: –
§ LDF: –
XCP § Diagnostic PDU Type: – UserDefinedPdu XCP (cdd type § FIBEX: –
§ XCP Configuration: property) plus § DBC: –
XCP_PRE_CONFIGURED XCP_PRE_ § LDF: –
CONFIGURED
(frame category)

539
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Appendix

Bus Manager PDU Types AUTOSAR FIBEX / DBC / LDF

PDU Category Diagnostic PDU Type/ XCP Entity Category
Element Configuration
Type
XCP § Diagnostic PDU Type: – UserDefinedIPdu XCP (cdd type § FIBEX: –
§ XCP Configuration: property) plus § DBC: –
XCP_RUNTIME_CONFIGURED XCP_RUNTIME_ § LDF: –
CONFIGURED
(frame category)

Tip

In automation scripts, you can access the Bus Manager PDU types via their
primary role. The primary role of a PDU is the PDU element type without
spaces or hyphens, and adapted capitalization, for example:
§ BusISignalIPdu
§ BusContainerIPdu
§ BusGeneralPurposeIPdu
For more information, refer to Automating Bus Manager Features
(ConfigurationDesk Automating Tool Handling ).

Optimized Set of TRC File Variables for Bus Configuration Function Ports

Introduction For each function port with enabled test automation support, variables are
generated into the variable description file (TRC file ) when you build a real-
time application or generate bus simulation containers. When the Variable
description property of a bus configuration is set to Optimized, an optimized
set of variables is generated. The generated variables depend on various aspects,
such as the function port type and the mapping to a model port.

Function inports mapped to For function inports that are mapped to model ports, the following applies:
model ports
Generated
TA_Switchvalue
variables

Model
MDL_Signal
outport
Function
IO_Signal TA switch
inport
TA_Replacevalue

Variables in variable Signal direction

description file

Initial Depends on the setting of the Initial switch setting property, which is
function used as the initial value of the TA_Switchvalue variable.
port value
Description You can switch the signal source between the original signal (MDL_Signal)
and the substitute signal (TA_Replacevalue). The value specified for the

540
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Optimized Set of TRC File Variables for Bus Configuration Function Ports

Initial value property of the function port is used as the original signal
value.
At run time, the TA_Switchvalue variable is evaluated only when the
transmission of the related PDU is triggered. Because of this, the value of
the IO_Signal variable is updated only in this case. Refer to Run‑time
optimizations of the Optimized mode for function inports on page 205.

Function inports not mapped For function inports that are not mapped to model ports, the generation of
to model ports variables depends on the following cases:

Case A and Case B For the cases A and B, the following applies:
Condition § Case A:
TRC file generated for real-time application.
§ Case B:
TRC file generated for bus simulation container and Model access of
the function port set to Disabled.
Generated Function
IO_Signal TA_Replacevalue
variables inport

Variables in variable Signal direction

description file

Initial Value specified for the Initial substitute value property, which is used as
function the initial value of the TA_Replacevalue variable.
port value
Description The signal source of the function port is the substitute signal
(TA_Replacevalue). The signal source cannot be changed. The setting
of the Initial switch setting property has no effects on the function port.

Case C For case C, the following applies:

Condition TRC file generated for bus simulation container and Model access of the
function port set to Enabled.
Generated
TA_Switchvalue
variables

MDL_Signal
Function
IO_Signal TA switch
inport
TA_Replacevalue

Variables in variable Signal direction

description file

Initial Depends on the setting of the Initial switch setting property, which is
function used as the initial value of the TA_Switchvalue variable.
port value
Description You can switch the signal source between the original signal (MDL_Signal)
and the substitute signal (TA_Replacevalue). The value specified for the
Initial value property of the function port is used as the original signal
value.

541
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Appendix

Tip

Function ports that are not mapped to model ports are available
at the port interface of bus simulation containers. Because all
variables are generated for the function port, you can use it
without restrictions, e.g., if you use the bus simulation container in
ConfigurationDesk or VEOS . For more information, refer to Port
Interface of Bus Simulation Containers on page 377.

At run time, the TA_Switchvalue variable is evaluated only when the

transmission of the related PDU is triggered. Because of this, the value of
the IO_Signal variable is updated only in this case. Refer to Run‑time
optimizations of the Optimized mode for function inports on page 205.

Function outports mapped to For function outports that are mapped to model ports, the following applies:
model ports
Generated Function Model
IO_Signal MDL_Signal
variables outport inport

Variables in variable Signal direction

description file

Initial Value specified for the Initial value property, which is used as the initial
function value of the IO_Signal variable.
port value
Description The signal source of the function port is the original signal (IO_Signal).
This signal value is provided to the model port. The signal source cannot be
changed. The setting of the Initial switch setting property has no effects
on the function port.

Function outports not For function outports that are not mapped to model ports, the following applies:
mapped to model ports
Generated Function
IO_Signal
variables outport

Variables in variable Signal direction

description file

Initial Value specified for the Initial value property, which is used as the initial
function value of the IO_Signal variable.
port value
Description The signal source of the function port is the original signal (IO_Signal).
The signal source cannot be changed. The setting of the Initial switch
setting property has no effects on the function port.

Tip

Because the function port is not mapped to a model port, there

is no recipient for the function port value in the behavior model.
Therefore, the generated variables can be reduced to a minimum.
However, you can access the function port via experiment software,
and the function port is available at the port interface of generated
bus simulation containers.

542
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Resolving the Bus Configuration Conflict: No Valid Application Process Assigned

Restrictions for the optimized For the function ports of the following bus configuration features, no optimized
set of variables set of variables can be generated:
§ Frame Capture Data feature
§ Filter Control feature
§ LIN Schedule Table feature

Instead, the complete set of variables is always generated for the function ports
of these features, even if the Variable description property is set to Optimized.
Moreover, no run‑time optimizations are used for the function inports of these
features.

Further information For more information, refer to Accessing Function Ports with Enabled Test
Automation Support in Variable Description Files (TRC Files) on page 202.

Resolving the Bus Configuration Conflict: No Valid Application Process

Assigned

Overview This conflict occurs if a bus configuration is assigned to no or more

than one application process. Therefore, this conflict occurs each time you
start implementing bus communication in the signal chain because the bus
configurations are not assigned to an application process yet. In most cases,
you resolve this conflict automatically when you complete implementing the
bus communication in the signal chain (e.g., as described in Implementing Bus
Communication in the Signal Chain Using the Bus Manager on page 335).

If the conflict is not resolved after you completed the implementation of the bus
communication in the signal chain or the conflict occurs after you modified the
implemented bus communication, the conflict causes and remedies that apply to
your case depend on the following use scenarios:
§ Use scenario 1: Working without a behavior model on page 543
§ Use scenario 2: Working with a behavior model on page 544
§ Use scenario 3: Working with multiple behavior models (multicore application)
on page 545

Use scenario 1: Working Conflict cause If you work without a behavior model, a possible conflict
without a behavior model cause is that no application process is available.

Remedy Assign the bus configuration to one application process. For

example, perform the following actions:
§ Create an application process with a default task. Refer to How to Create
Application Processes that Provide Default Tasks on page 386.

543
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Appendix

§ Assign the bus configuration to the application process in one of the following
ways:
§ Assign at least one bus access request of the bus configuration to a bus
function block (CAN, LIN) and assign a hardware resource. Refer to How to
Specify the Hardware Access on page 344.
§ Assign the bus configuration to the application process manually. Refer to
How to Manually Assign Bus Configurations to Application Processes on
page 387.

Use scenario 2: Working with Conflict cause If you work with a behavior model, possible conflict causes
a behavior model are:
§ The behavior model is not available in the ConfigurationDesk application.
§ The behavior model is available in the ConfigurationDesk application, but no
application process exists.
§ None of the behavior model's data ports are mapped to function ports of the
bus configuration.
§ A data port of the behavior model is mapped to a function port of the
bus configuration. Due to a manually assigned application process, the bus
configuration is assigned to two application processes, to the manually
assigned application process and to the application process of the behavior
model.

Remedy Assign the bus configuration to one application process. For

example, perform the following actions:
§ If not already done, add the behavior model to the ConfigurationDesk
application. Refer to How to Add Behavior Models to a ConfigurationDesk
Application on page 352.
§ Ensure that an application process is created: Right-click the model in the
Model Browser and select Create Preconfigured Application Process on
the context menu.
§ Map at least one data port of the behavior model to a function port of the bus
configuration. For an example of mapping ports to bus configurations, refer
to Example of Mapping Model Ports to Bus Configuration Ports via Tables on
page 358.
§ Undo the manual assignment to an application process: Select the bus
configuration, for example, in the Bus Configurations table and select the
blank entry from the list of the Manually assigned application process
property in the Properties Browser.

544
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Resolving the Bus Configuration Conflict: No Valid Application Process Assigned

Use scenario 3: Working with Conflict cause If you work with multiple behavior models, possible conflict
multiple behavior models causes are:
(multicore application)

§ The bus configuration is mapped to two or more behavior models that are
assigned to different application processes, as shown in the following example.
ConfigurationDesk

SCALEXIO

Processing unit
Bus Configuration Application process 1
Behavior model 1
I/O unit
Model Model
port block port block
Bus hardware
CH1 CH2 Bus
CH3 CH4 Configuration
function block Application process 2
Behavior model 2
Hardware resource Model Model
assignment port block port block

CAN function block Bus access request

§ The bus configuration and an assigned bus function block (CAN, LIN) are
mapped to different behavior models that are assigned to different application
processes, as shown in the following example.
ConfigurationDesk

SCALEXIO

Processing unit Bus Configuration Application process 1

Behavior model 1
I/O unit Model Model
Bus port block port block
Bus hardware Configuration
function block
CH1 CH2
CH3 CH4

Hardware resource Bus access request Application process 2

assignment
Behavior model 2

CAN function block Model Model

port block port block

Tip

You can identify the assignment of behavior models to application processes

via the Build Configuration table, for example.

Remedy Assign the bus configuration to one application process. For

example, perform the following actions:
§ If you want to build a real-time application, assign the behavior models to only
one application process. For example, you can do this in the following way:
1. In the Processing Resource Assignment table, delete all related
application processes but one.

545
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Appendix

2. Right-click the remaining application process and assign the behavior

models via the Assign Model command.
3. Right-click the application process and select Optimize Configuration on
the context menu.
§ If you want to generate bus simulation containers, do the following:
§ Map all the function ports of the bus configuration to model ports of only
one behavior model.
§ If bus function blocks (CAN, LIN) are assigned to the bus configuration and
have function ports mapped to a behavior model, ensure that it is the same
model to which the function ports of the bus configuration are mapped.
Alternatively, remove the assigned bus accesses, for example, in the Bus
Access Requests table.

Further information For more details on application processes and tasks, refer to Modeling Executable
Applications and Tasks (ConfigurationDesk Real-Time Implementation Guide ).

546
ConfigurationDesk Bus Manager Implementation Guide May 2024
 ConfigurationDesk Glossary

ConfigurationDesk Glossary

Introduction The glossary briefly explains the most important expressions and naming
conventions used in the ConfigurationDesk documentation.

Where to go from here Information in this section

A........................................................................................................... 548

B........................................................................................................... 548

C........................................................................................................... 551

D........................................................................................................... 554

E........................................................................................................... 555

F............................................................................................................ 557

G........................................................................................................... 558

H........................................................................................................... 559

I............................................................................................................ 559

L............................................................................................................ 560

M.......................................................................................................... 561

N........................................................................................................... 564

O........................................................................................................... 564

P........................................................................................................... 564

R........................................................................................................... 565

S........................................................................................................... 566

T........................................................................................................... 568

U........................................................................................................... 569

V........................................................................................................... 569

547
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 ConfigurationDesk Glossary

W.......................................................................................................... 570

X........................................................................................................... 570

Application There are two types of applications in ConfigurationDesk:

§ A part of a ConfigurationDesk project: ConfigurationDesk application .
§ An application that can be executed on dSPACE real-time hardware: real-time
application .

Application process A component of a processing unit application . An

application process contains one or more tasks .

Application process component A component of an application process .

The following application process components are available in the Components
subfolder of an application process:
§ Behavior models that are assigned to the application process, including their
predefined tasks , runnable functions , and events .
§ Function blocks that are assigned to the application process.

AutomationDesk A dSPACE software product for creating and managing

any kind of automation tasks. Within the dSPACE tool chain, it is mainly used for
automating tests on dSPACE hardware.

AUTOSAR system description file An AUTOSAR XML (ARXML) file that

describes a system according to AUTOSAR. A system is a combination of a
hardware topology, a software architecture, a network communication, and
information on the mappings between these elements. The described network
communication usually consists of more than one bus system (e.g., CAN, LIN,
FlexRay).

Basic PDU A general term used in the documentation to address all the PDUs
the Bus Manager supports, except for container IPDUs , multiplexed IPDUs ,
and secured IPDUs . Basic PDUs are represented by the or symbol in
tables and browsers. Unless stated otherwise, the Bus Manager provides the
same functionalities for all basic PDUs, such as ISignal IPDUs or NMPDUs.

Behavior model A model that contains the control algorithm for a

controller (function prototyping system) or the algorithm of the controlled
system (hardware-in-the-loop system). It does not contain I/O functionality

548
ConfigurationDesk Bus Manager Implementation Guide May 2024
 B

nor access to the hardware. Behavior models can be modeled, for example,
in MATLAB®/Simulink® by using Simulink Blocksets and Toolboxes from the
MathWorks®.
You can add Simulink behavior models to a ConfigurationDesk application.
You can also add code container files containing a behavior model such as
Functional Mock-up Units , or Simulink implementation containers to a
ConfigurationDesk application.

Bidirectional signal port A signal port that is independent of a data

direction or current flow. This port is used, for example, to implement bus
communication.

BSC file A bus simulation container file that is generated with the
Bus Manager or the Ethernet Configuration Package. A BSC file that is
generated with the Bus Manager contains the configured bus communication
of one application process . A BSC file that is generated with the Ethernet
Configuration Package contains the configured bus communication of one
project.

Build Configuration table A pane that lets you create build configuration
sets and configure build settings, for example, build options, or the build and
download behavior.

Build Log Viewer A pane that displays messages and warnings during the
build process .

Build process A process that generates an executable real-time application

based on your ConfigurationDesk application that can be run on dSPACE
real-time hardware. The build process can be controlled and configured via the
Build Log Viewer . If the build process is successfully finished, the build result
files (build results ) are added to the ConfigurationDesk application.

Build results The files that are created during the build process . Build
results are named after the ConfigurationDesk application and the application
process from which they originate. You can access the build results in the
Project Manager .

Bus access The representation of a run-time communication cluster . By

assigning one or more bus access requests to a bus access, you specify which
communication clusters form one run-time communication cluster.
In ConfigurationDesk, you can use a bus function block (CAN, LIN) to
implement a bus access. The hardware resource assignment of the bus
function block specifies the bus channel that is used for the bus communication.

Bus access request The representation of a request regarding the bus

access . There are two sources for bus access requests:
§ At least one element of a communication cluster is assigned to the
Simulated ECUs, Inspection, or Manipulation part of a bus configuration .
The related bus access requests contain the requirements for the bus channels
that are to be used for the cluster's bus communication.
§ A frame gateway is added to the Gateways part of a bus configuration. Each
frame gateway provides two bus access requests that are required to specify
the bus channels for exchanging bus communication.

549
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 ConfigurationDesk Glossary

Bus access requests are automatically included in BSC files . To build a real-time
application , each bus access request must be assigned to a bus access.

Bus Access Requests table A pane that lets you access bus access
requests of a ConfigurationDesk application and assign them to bus
accesses .

Bus configuration A Bus Manager element that implements bus

communication in a ConfigurationDesk application and lets you configure
it for simulation, inspection, and/or manipulation purposes. The required bus
communication elements must be specified in a communication matrix and
assigned to the bus configuration. Additionally, a bus configuration lets you
specify gateways for exchanging bus communication between communication
clusters . A bus configuration can be accessed via specific tables and its related
Bus Configuration function block .

Bus Configuration Ports table A pane that lets you access and configure
function ports and event ports of bus configurations .

Bus Configurations table A pane that lets you access and configure bus
configurations of a ConfigurationDesk application .

Bus Custom Code interface A C-based API interface provided by dSPACE.

It is required to implement user code and its functionalities in executable
applications . In general, the Bus Custom Code interface lets you do the
following:
§ Specify the unique user code ID for each user code implementation . The ID
is required to unambiguously reference the user code implementation in bus
configurations .
§ Initialize the functionalities provided by user code in the executable
application.
§ Exchange data between the user code and the Bus Manager, for example, to
access properties of secured IPDUs or write calculated checksum values to
ISignals of an IPDU .

Bus Inspection Features table A pane that lets you access and configure
bus configuration features of a ConfigurationDesk application for inspection
purposes.

Bus Manager
§ Bus Manager in ConfigurationDesk
A ConfigurationDesk component that lets you configure bus communication
and implement it in real-time applications or generate bus simulation
containers .
§ Bus Manager (stand-alone)
A dSPACE software product based on ConfigurationDesk that lets you
configure bus communication and generate bus simulation containers.

Bus Manipulation Features table A pane that lets you access and
configure bus configuration features of a ConfigurationDesk application for
manipulation purposes.

Bus simulation container A container that contains bus communication

configured with the Bus Manager or the Ethernet Configuration Package.

550
ConfigurationDesk Bus Manager Implementation Guide May 2024
 C

Bus simulation container (BSC ) files that are generated with the Bus Manager
contain CAN and/or LIN communication, BSC files generated with the Ethernet
Configuration Package contain Ethernet communication.
Depending on the contained bus communication, BSC files can be used in
VEOS , in ConfigurationDesk, and/or in RTMaps:
§ In VEOS, they let you implement the bus communication in an offline
simulation application to perform SIL simulation on VEOS.
§ In ConfigurationDesk, they let you implement the bus communication in a
real-time application for SCALEXIO, MicroAutoBox III, or MicroLabBox II.
§ In RTMaps, they let you implement the bus communication in an
RTMaps‑based application for the AUTERA AutoBox, for example.

Bus Simulation Features table A pane that lets you access and configure
bus configuration features of a ConfigurationDesk application for simulation
purposes.

Buses Browser A pane that lets you display and manage the communication
matrices of a ConfigurationDesk application . For example, you can access
communication matrix elements and assign them to bus configurations. This
pane is available only if you work with the Bus Manager .

Cable harness A bundle of cables that provides the connection between the
I/O connectors of the real-time hardware and the external devices , such as the
ECUs to be tested. In ConfigurationDesk, it is represented by an external cable
harness component.

CAFX file A ConfigurationDesk application fragment file that contains signal

chain elements that were exported from a user-defined working view or the
Temporary working view of a ConfigurationDesk application . This includes
the elements' configuration and the mapping lines between them.

Channel multiplication A feature that allows you to enhance the max.

current or max. voltage of a single hardware channel by combining several
channels. ConfigurationDesk uses a user-defined value to calculate the number
of hardware channels needed. Depending on the function block type , channel
multiplication is provided either for current enhancement (two or more channels
are connected in parallel) or for voltage enhancement (two or more channels are
connected in series).

Channel request A channel assignment required by a function block .

ConfigurationDesk determines the type(s) and number of channels required
for a function block according to the assigned channel set , the
function block features, the block configuration and the required physical
ranges. ConfigurationDesk provides a set of suitable and available hardware
resources for each channel request. This set is produced according to the
hardware topology added to the active ConfigurationDesk application . You

551
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 ConfigurationDesk Glossary

have to assign each channel request to a specific channel of the hardware

topology.

Channel set A number of channels of the same channel type located on

the same I/O board or I/O unit. Channels in a channel set can be combined, for
example, to provide a signal with channel multiplication .

Channel type A term to indicate all the hardware resources (channels) in

the hardware system that provide exactly the same characteristics. Examples for
channel type names: Flexible In 1, Digital Out 3, Analog In 1. An I/O board
in a hardware system can have channel sets of several channel types. Channel
sets of one channel type can be available on different I/O boards.

Cluster A short form of communication cluster .

Common Program Data folder A standard folder for application-specific

program data that is used by all users.
%PROGRAMDATA%\dSPACE\<InstallationGUID>\<ProductName>
or
%PROGRAMDATA%\dSPACE\<ProductName>\<VersionNumber>

Communication cluster A communication network of network nodes that

are connected to the same physical channels and share the same bus protocol
and address range.

Communication matrix A file that defines the communication of a bus

network. It can describe the bus communication of one communication
cluster or a bus network consisting of different bus systems and clusters. Files
of various file formats can be used as a communication matrix: For example,
AUTOSAR system description files , DBC files , LDF files , and FIBEX files .

Communication package A package that bundles Data Inport blocks which

are connected to Data Outport blocks. Hence, it also bundles the signals that
are received by these blocks. If Data Inport blocks are executed within the
same task and belong to the same communication package , their data
inports are read simultaneously. If Data Outport blocks that are connected to the
Data Inport blocks are executed in the same task, their output signals are sent
simultaneously in one data package. Thus, communication packages guarantee
simultaneous signal updates within a running task (data snapshot).

Configuration port A port that lets you create the signal chain for the
bus communication implemented in a Simulink behavior model. The following
configuration ports are available:
§ The configuration port of a Configuration Port block .
§ The Configuration port of a CAN, LIN, or FlexRay function block.
To create the signal chain for bus communication, the configuration port of a
Configuration Port block must be mapped to the Configuration port of a
CAN, LIN, or FlexRay function block.

552
ConfigurationDesk Bus Manager Implementation Guide May 2024
 C

Configuration Port block A model port block that is created in

ConfigurationDesk during model analysis for each of the following blocks found
in the Simulink behavior model:
§ RTICANMM ControllerSetup block
§ RTILINMM ControllerSetup block
§ FLEXRAYCONFIG UPDATE block
Configuration Port blocks are also created for bus simulation containers. A
Configuration Port block provides a configuration port that must be mapped
to the Configuration port of a CAN, LIN, or FlexRay function block to create the
signal chain for bus communication.

ConfigurationDesk application A part of a ConfigurationDesk

project that represents a specific implementation. You can work with only one
application at a time, and that application must be activated.
An application can contain:
§ Device topology
§ Hardware topology
§ Model topology
§ Communication matrices
§ External cable harness
§ Build results (after a successful build process has finished)

ConfigurationDesk model interface The part of the model interface that

is available in ConfigurationDesk. This specific term is used to explicitly
distinguish between the model interface in ConfigurationDesk and the model
interface in Simulink.

Conflict A result of conflicting configuration settings that is displayed in

the Conflicts Viewer . ConfigurationDesk allows flexible configuration without
strict constraints. This lets you work more freely, but it can lead to conflicting
configuration settings. ConfigurationDesk automatically detects conflicts and
provides the Conflicts Viewer to display and help resolve them. Before you build
a real-time application , you have to resolve at least the most severe conflicts
(e.g., errors that abort the build process ) to get proper build results .

Conflicts Viewer A pane that displays the configuration conflicts that exist
in the active ConfigurationDesk application . You can resolve most of the
conflicts directly in the Conflicts Viewer.

Container IPDU A term according to AUTOSAR. An IPDU that contains

one or more smaller IPDUs (i.e., contained IPDUs). Contained IPDUs can be
multiplexed IPDUs , secured IPDUs , and ISignal IPDUs , for example.

ControlDesk A dSPACE software product for managing, instrumenting

and executing experiments for ECU development. ControlDesk also supports
calibration, measurement and diagnostics access to ECUs via standardized
protocols such as CCP, XCP, and ODX.

Countdown event An event that triggers a task exactly once, after a

specified time (offset) has elapsed. Countdown events are provided by bus
simulation containers (BSC files).

553
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 ConfigurationDesk Glossary

Custom code Custom source, header, and library files that must be compiled
and linked to real-time applications . Custom code files can be specified via
the Build Configuration Set options in the Build Configuration table . Do not
confuse custom code with user code , which is a term used in the Bus Manager
context.

Cycle time restriction A value of a runnable function that indicates the

sample time the runnable function requires to achieve correct results. The cycle
time restriction is indicated by the Period property of the runnable function in
the Properties Browser .

Data inport A port that supplies data from ConfigurationDesk's function

outports to the behavior model.
In a multimodel application, data inports also can be used to provide data from a
data outport associated to another behavior model (model communication ).

Data outport A port that supplies data from behavior model signals to
ConfigurationDesk's function inports.
In a multimodel application, data outports also can be used to supply data to a
data inport associated to another behavior model (model communication ).

Data.CfgDeskApp file A ConfigurationDesk application file that contains

links to all the documents related to an application.

DBC file A Data Base Container file that describes CAN or LIN bus systems.
Because the DBC file format was primarily developed to describe CAN networks,
it does not support definitions of LIN masters and schedules.

Delayed event An event that triggers a task when the specified delay time
has expired after the execution of the source task started.

Device block A graphical representation of devices from the device

topology in the signal chain . It can be mapped to function blocks via
device ports .

Device connector A structural element that lets you group device pins in a
hierarchy in the External Device Connectors table to represent the structure of
the real connector of your external device .

Device pin A representation of a connector pin of your external device .

Device ports are assigned to device pins. ConfigurationDesk can use the
device pin assignment together with the hardware resource assignment and
the device port mapping to calculate the external cable harness .

Device port An element of a device topology that represents the signal of

an external device in ConfigurationDesk.

Device port group A structural element of a device topology that can

contain device ports and other device port groups.

554
ConfigurationDesk Bus Manager Implementation Guide May 2024
 E

Device topology A component of a ConfigurationDesk application that

represents external devices in ConfigurationDesk. You can create a device
topology from scratch or easily extend an existing device topology. You can
also merge device topologies to extend one. To edit or create device topologies
independently of ConfigurationDesk, you can export and import DTFX and
XLSX files.

Documents folder A standard folder for application‑specific files that are

used by the current user.
%USERPROFILE%\Documents\dSPACE\<ProductName>\<VersionNumber>

dSPACE Help The dSPACE online help that contains all the relevant user
documentation for dSPACE products. Via the F1 key or the Help button in the
dSPACE software you get context-sensitive help on the currently active context.

dSPACE Log A collection of errors, warnings, information, questions, and

advice issued by all dSPACE products and connected systems over more than one
session.

DTFX file A device topology export file that contains information on

the interface to the external devices , such as the ECUs to be tested. The
information includes details of the available device ports , their characteristics,
and the assigned pins.

ECHX file An external cable harness file that contains the wiring
information for the external cable harness. The external cable harness is the
connection between the I/O connectors of the real-time hardware and the
devices to be tested, for example, ECUs.

ECU Abbreviation of electronic control unit.

An embedded computer system that consists of at least one CPU and associated
peripherals. An ECU contains communication controllers and communication
connectors, and usually communicates with other ECUs of a bus network. An
ECU can be member of multiple bus systems and communication clusters .

ECU application An application that is executed on an ECU . In ECU

interfacing scenarios, parts of the ECU application can be accessed (e.g., by a
real-time application ) for development and testing purposes.

ECU function A function of an ECU application that is executed on the

ECU . In ECU interfacing scenarios, an ECU function can be accessed by
functions that are part of a real-time application , for example.

ECU Interface Manager A dSPACE software product for preparing ECU

applications for ECU interfacing . The ECU Interface Manager can generate
ECU interface container (EIC ) files to be used in ConfigurationDesk.

ECU interfacing A generic term for methods and tools to read and/or
write individual ECU functions and variables of an ECU application . In
ECU interfacing scenarios, you can access ECU functions and variables for

555
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 ConfigurationDesk Glossary

development and testing purposes while the ECU application is executed on

the ECU . For example, you can perform ECU interfacing with SCALEXIO
systems or MicroAutoBox III systems to access individual ECU functions by
a real-time application .

EIC file An ECU interface container file that is generated with the ECU
Interface Manager and describes an ECU application that is configured for
ECU interfacing . You can import EIC files to ConfigurationDesk to perform
ECU interfacing with SCALEXIO systems , MicroAutoBox III, or MicroLabBox II
systems.

Electrical interface unit A segment of a function block that provides the

interface to the external devices and to the real-time hardware (via hardware
resource assignment ). Each electrical interface unit of a function block usually
needs a channel set to be assigned to it.

Event A component of a ConfigurationDesk application that triggers the

execution of a task . The following event types are available:
§ Timer event
§ I/O event
§ Software event
§ Delayed event
§ Countdown event
§ Synchronized timer event

Event port An element of a function block . The event port can be mapped
to a runnable function port for modeling an asynchronous task.

Executable application The generic term for real-time applications and

offline simulation applications . In ConfigurationDesk, an executable
application is always a real-time application since ConfigurationDesk does not
support offline simulation applications.

Executable application component A component of an executable

application . The following components can be part of an executable
application:
§ Imported behavior models including predefined tasks , runnable
functions , and events . You can assign these behavior models to
application processes via drag & drop or by selecting the Assign Model
command from the context menu of the relevant application process.
§ Function blocks added to your ConfigurationDesk application including
associated I/O events . Function blocks are assigned to application processes
via their model port mapping.

Executable Application table A pane that lets you model executable

applications (i.e., real-time applications ) and the tasks used in them.

EXPSWCFG file An experiment software configuration file that contains

configuration data for automotive fieldbus communication. It is created during
the build process and contains the data in XML format.

Extended multiplexed IPDU An IPDU that is used for extended signal

multiplexing, which can be specified only in DBC communication matrices.
The IPDU contains multiplexer signals and multiplexed signals: The value of a

556
ConfigurationDesk Bus Manager Implementation Guide May 2024
 F

multiplexer signal can determine that specific multiplexed signals are included in
the IPDU. However, with extended signal multiplexing, a multiplexed signal itself
can serve as a multiplexer signal.

External cable harness A component of a ConfigurationDesk

application that contains the wiring information for the external cable harness
(also known as cable harness ). It contains only the logical connections and
no additional information such as cable length, cable diameters, dimensions
or the arrangement of connection points, etc. It can be calculated by
ConfigurationDesk or imported from a file so that you can use an existing cable
harness and do not have to build a new one. The wiring information can be
exported to an ECHX file or XLSX file .

External device A device that is connected to the dSPACE hardware, such as

an ECU or external load. The external device topology is the basis for using
external devices in the signal chain of a ConfigurationDesk application .

External Device Browser A pane that lets you display and manage the
device topology of your active ConfigurationDesk application .

External Device Configuration table A pane that lets you access and
configure the most important properties of device topology elements via table.

External Device Connectors table A pane that lets you specify the
representation of the physical connectors of your external device including
the device pin assignment.

FIBEX file An XML file according the ASAM MCD-2 NET standard (also
known as Field Bus Exchange Format) defined by ASAM. The file can describe
more than one bus system (e.g., CAN, LIN, FlexRay). It is used for data exchange
between different tools that work with message-oriented bus communication.

Find Results Viewer A pane that displays the results of searches you
performed via the Find command.

FMU file A Functional Mock-up Unit file that describes and implements the
functionality of a model. It is an archive file with the file name extension FMU.
The FMU file contains:
§ The functionality defined as a set of C functions provided either in source or in
binary form.
§ The model description file (modelDescription.xml) with the description of
the interface data.
§ Additional resources needed for simulation.
You can add an FMU file to the model topology just like adding a Simulink
model based on an SLX file .

Frame A piece of information of a bus communication. It contains an

arbitrary number of non-overlapping PDUs and the data length code (DLC).

557
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 ConfigurationDesk Glossary

CAN frames and LIN frames can contain only one PDU. To exchange a frame via
bus channels, a frame triggering is needed.

Frame triggering An instance of a frame that is exchanged via a bus

channel. It includes transmission information of the frame (e.g., timings, ID,
sender, receiver). The requirements regarding the frame triggerings depend on
the bus system, e.g., CAN or LIN.

Function block A graphical representation in the signal chain that is

instantiated from a function block type . A function block provides the I/O
functionality and the connection to the real-time hardware. It serves as a
container for functions, for electrical interface units and their logical signals .
The function block's ports (function ports and/or signal ports ), provide the
interfaces to the neighboring blocks in the signal chain.

Function block type A software plug-in that provides a specific I/O

functionality. Every function block type has unique features that are different
from other function block types.
To use a function block type in your ConfigurationDesk application , you have
to create an instance of it. This instance is called a function block . Instances
of function block types can be used multiple times in a ConfigurationDesk
application. The types and their instantiated function blocks are displayed in the
function library of the Function Browser .

Function Browser A pane that displays the function library in a

hierarchical tree structure. Function block types are grouped in function
classes. Instantiated function blocks are added below the corresponding
function block type.

Function inport A function port that inputs the values from the behavior
model to the function block to be processed by the function.

Function library A collection of function block types that allows access

to the I/O functionality in ConfigurationDesk. The I/O functionality is based on
function block types. The function library provides a structured tree view on the
available function block types. It is displayed in the Function Browser .

Function outport A function port that outputs the value of a function to

be used in the behavior model .

Function port An element of a function block that provides the interface

to the behavior model via model port blocks .

Functional Mock-up Unit An archive file that describes and implements

the functionality of a model based on the Functional Mock-up Interface (FMI)
standard.

Global working view The default working view that always contains all
signal chain elements.

558
ConfigurationDesk Bus Manager Implementation Guide May 2024
 H

Hardware resource A hardware element (normally a channel on an I/O

board or I/O unit) that is required to execute a function block . A hardware
resource can be localized unambiguously in a hardware system. Every hardware
resource has specific characteristics. A function block therefore needs a hardware
resource that matches the requirements of its functionality. This means that not
every function block can be executed on every hardware resource. There could
be limitations on a function block's features and/or the physical ranges.

Hardware resource assignment An action that assigns the electrical

interface unit of a function block to one or more hardware resources .
Function blocks can be assigned to any hardware resource that is suitable
for the functionality and available in the hardware topology of your
ConfigurationDesk application .

Hardware Resource Browser A pane that lets you display and manage all
the hardware components of the hardware topology that is contained in your
active ConfigurationDesk application in a hierarchical structure.

Hardware topology A component of a ConfigurationDesk

application that contains information on a specific hardware system which
can be used with ConfigurationDesk. It provides information on the components
of the system, such as channel type and slot numbers. It can be scanned
automatically from a registered platform , created in ConfigurationDesk's
Hardware Resource Browser from scratch, or imported from an HTFX file .

HTFX file A file containing the hardware topology after an explicit export.
It provides information on the components of the system and also on the
channel properties, such as board and channel types and slot numbers.

I/O event An asynchronous event triggered by I/O functions. You can use
I/O events to trigger tasks in your application process asynchronously. You can
assign the events to the tasks via drag & drop, via the Properties Browser if you
have selected a task, or via the Assign Event command from the context menu
of the relevant task.

Interface model A temporary Simulink model that contains blocks from the
Model Interface Blockset. ConfigurationDesk initiates the creation of an interface
model in Simulink. You can copy the blocks with their identities from the
interface model and paste them into an existing Simulink behavior model.

Interpreter A pane that lets you run Python scripts and execute line-based
commands.

Inverse model port block A model port block that has the same
configuration (same name, same port groups, and port names) but the inverse
data direction as the original model port block from which it was created.

559
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 ConfigurationDesk Glossary

IOCNET Abbreviation of I/O carrier network.

A dSPACE proprietary protocol for internal communication in a SCALEXIO
system between the real-time processors and I/O units. The IOCNET lets you
connect more than 100 I/O nodes and place the parts of your SCALEXIO system
long distances apart.

IPDU Abbreviation of interaction layer protocol data unit.

A term according to AUTOSAR. An IPDU contains the communication data
that is routed from the interaction layer to a lower communication layer and
vice versa. An IPDU can be implemented, for example, as an ISignal IPDU ,
multiplexed IPDU , or container IPDU .

ISignal A term according to AUTOSAR. A signal of the interaction layer

that contains communication data as a coded signal value. To transmit the
communication data on a bus, ISignals are instantiated and included in ISignal
IPDUs .

ISignal IPDU A term according to AUTOSAR. An IPDU whose

communication data is arranged in ISignals . ISignal IPDUs allow the exchange
of ISignals between different network nodes .

LDF file A LIN description file that describes networks of the LIN bus system
according to the LIN standard.

LIN master A member of a LIN communication cluster that is responsible

for the timing of LIN bus communication. A LIN master provides one LIN master
task and one LIN slave task. The LIN master task transmits frame headers on
the bus, and provides LIN schedule tables and LIN collision resolver tables. The
LIN slave task transmits frame responses on the bus. A LIN cluster must contain
exactly one LIN master.

LIN schedule table A table defined for a LIN master that contains the
transmission sequence of frame headers on a LIN bus. For each LIN master,
several LIN schedule tables can be defined.

LIN slave A member of a LIN communication cluster that provides only

a LIN slave task. The LIN slave task transmits frame responses on the bus
when they are triggered by a frame header. The frame header is sent by a LIN
master . A LIN cluster can contain several LIN slaves.

Local Program Data folder A standard folder for application-specific

program data that is used by the current user.
%USERPROFILE%\AppData\Local\dSPACE\<InstallationGUID>\
<ProductName>

Logical signal An element of a function block that combines all the signal
ports which belong together to provide the functionality of the signal. Each
logical signal causes one or more channel requests . Channel requests are
available after you have assigned a channel set to the logical signal.

560
ConfigurationDesk Bus Manager Implementation Guide May 2024
 M

Logical signal chain A term that describes the logical path of a signal
between an external device and the behavior model . The main elements
of the logical signal chain are represented by different graphical blocks (device
blocks , function blocks and model port blocks ). Every block has ports to
provide the mapping to neighboring blocks.
In the documentation, usually the short form 'signal chain' is used instead.

MAP file A file that maps symbolic names to physical addresses.

Mapping line A graphical representation of a connection between two ports

in the signal chain . You can draw mapping lines in a working view .

MCD file A model communication description file that is used to implement

a multimodel application . It lets you add several behavior models that were
separated from an overall model to the model topology .
The MCD file contains information on the separated models and information on
the connections between them. The file is generated with the Model Separation
Setup Block in MATLAB/Simulink. The block resides in the Model Interface
Blockset (dsmpblib) from dSPACE.

MDL file A Simulink model file that contains the behavior model . You can
add an MDL file to your ConfigurationDesk application .
As of MATLAB® R2012a, the file name extension for the Simulink model file has
been changed from MDL to SLX by The MathWorks®.

Message Viewer A pane that displays a history of all error and warning
messages that occur during work with ConfigurationDesk.

Model analysis A process that analyzes the model to determine the interface
of a behavior model . You can select one of the following commands:
§ Analyze Simulink Model (Model Interface Only)
Analyzes the interface of a behavior model. The model topology of your
active ConfigurationDesk application is updated with the properties of the
analyzed behavior model.
§ Analyze Simulink Model (Including Task Information)
Analyzes the model interface and the elements of the behavior model
that are relevant for the task configuration. The task configuration in
ConfigurationDesk is then updated accordingly.

Model Browser A pane that lets you display and access the model
topology of an active ConfigurationDesk application . The Model Browser
provides access to all the model port blocks available in the behavior
models that are linked to a ConfigurationDesk application. The model
elements are displayed in a hierarchy, starting with the model roots. Below the
model root, all the subsystems containing model port blocks are displayed as well
as the associated model port blocks.

561
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 ConfigurationDesk Glossary

Model communication The exchange of signal data between the models

within a multimodel application . To set up model communication, you must
use a mapping line to connect a data outport (sending model) to a data inport
(receiving model). The best way to set up model communication is using the
Model Communication Browser .

Model Communication Browser A pane that lets you open and browse
working views like the Signal Chain Browser , but shows only the Data
Outport and Data Inport blocks and the mapping lines between them.

Model Communication Package table A pane that lets you create

and configure model communication packages which are used for model
communication in multimodel applications .

Model implementation An implementation of a behavior model . It can

consist of source code files, precompiled objects or libraries, variable description
files, and a description of the model’s interface. Specific model implementation
types are, for example, model implementation containers , such as Functional
Mock-up Units or Simulink implementation containers .

Model implementation container A file archive that contains a model

implementation . Examples are FMUs and SIC files.

Model interface An interface that connects ConfigurationDesk with a

behavior model . This interface is part of the signal chain and is implemented
via model port blocks. The model port blocks in ConfigurationDesk can provide
the interface to:
§ Model port blocks (from the Model Interface Package for Simulink ) in
a Simulink behavior model. In this case, the model interface is also called
ConfigurationDesk model interface to distinguish it from the Simulink model
interface available in the Simulink behavior model.
§ Different types of model implementations based on code container files, e.g.,
Simulink implementation containers and Functional Mock-up Units.

Model Interface Package for Simulink A dSPACE software product that

lets you specify the interface of a behavior model that you can directly use
in ConfigurationDesk. You can also create a code container file (SIC file ) that
contains the model code of a Simulink behavior model . The SIC file can be
used in ConfigurationDesk and VEOS .

Model port An element of a model port block . Model ports provide the
interface to the function ports and to other model ports (in multimodel
applications ).
These are the types of model ports:
§ Data inport
§ Data outport
§ Runnable function port
§ Configuration port

Model port block A graphical representation of the ConfigurationDesk

model interface in the signal chain . Model port blocks contain model ports
that can be mapped to function blocks to provide the data flow between the
function blocks in ConfigurationDesk and the behavior model . The model
ports can also be mapped to the model ports of other model port blocks with

562
ConfigurationDesk Bus Manager Implementation Guide May 2024
 M

data inports or data outports to set up model communication . Model port

blocks are available in different types and can provide different port types:
§ Data port blocks with data inports and data outports
§ Runnable Function blocks with runnable function ports
§ Configuration Port blocks with configuration ports . Configuration Port
blocks are created during model analysis for each of the following blocks
found in the Simulink behavior model:
§ RTICANMM ControllerSetup block
§ RTILINMM ControllerSetup block
§ FLEXRAYCONFIG UPDATE block
Configuration Port blocks are also created for bus simulation containers.

Model Separation Setup Block A block that is contained in the Model

Interface Package for Simulink . It is used to separate individual models from
an overall model in MATLAB/Simulink. Additionally, model separation generates
a model communication description file (MCD file ) that contains information
on the separated models and their connections. You can use this MCD file in
ConfigurationDesk.

Model topology A component of a ConfigurationDesk application that

contains information on the subsystems and the associated model port blocks
of all the behavior models that have been added to a ConfigurationDesk
application.

Model-Function Mapping Browser A pane that lets you create and update
signal chains for Simulink behavior models . It directly connects them to I/O
functionality in ConfigurationDesk.

MTFX file A file containing a model topology when explicitly exported. The
file contains information on the interface to the behavior model , such as the
implemented model port blocks including their subsystems and where they are
used in the model.

Multicore real-time application A real-time application that is executed

on several cores of one PU of the real-time hardware.

Multimodel application A real-time application that executes several

behavior models in parallel on dSPACE real-time hardware.

Multiplexed IPDU A term according to AUTOSAR. An IPDU that consists

of one dynamic part, a selector field, and one optional static part. Multiplexing
is used to transport varying ISignal IPDUs via the same bytes of a multiplexed
IPDU.
§ The dynamic part is one ISignal IPDU that is selected for transmission at run
time. Several ISignal IPDUs can be specified as dynamic‑part alternatives, i.e.,
as dynamic‑part IPDUs. One of these alternatives is transmitted at a time.
§ The selector field value indicates which ISignal IPDU is transmitted in the
dynamic part during run time. For each ISignal IPDU that is configured as
a dynamic‑part alternative, there must be a unique selector field value. The
selector field value is evaluated by the receiver of the multiplexed IPDU.
§ The static part is one ISignal IPDU, i.e., the static‑part IPDU, that is always
transmitted.

563
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 ConfigurationDesk Glossary

Multi-PU application Abbreviation of multi-processing-unit application. A

multi-PU application is a real-time application that is partitioned into several
processing unit applications . Each processing unit application is executed on a
separate PU of the real-time hardware. The processing units are connected via
IOCNET and can be accessed from the same host PC.

Navigation bar An element of ConfigurationDesk's user interface that lets

you switch between view sets .

Network node A term that describes the bus communication of an

ECU for only one communication cluster .

Offline simulation application An application that runs on VEOS to

perform SIL simulation . For example, you can use the VEOS Player to build
an offline simulation application and load the resulting OSA file to VEOS.

OSA file An offline simulation application file that is built with VEOS to
perform SIL simulation .

Parent port A port that you can use to map multiple function
ports and model ports . All child ports with the same name are mapped.
ConfigurationDesk enforces the mapping rules and allows only mapping
lines that agree with them.

PDU Abbreviation of protocol data unit.

A term according to AUTOSAR. A PDU transports data (e.g., control information
or communication data) via one or multiple network layers according to the
AUTOSAR layered architecture. Depending on the involved layers and the
function of a PDU, various PDU types can be distinguished, e.g., ISignal IPDUs ,
multiplexed IPDUs , or NMPDUs.

Physical signal chain A term that describes the electrical wiring of external
devices (ECU and loads) to the I/O boards of the real-time hardware. The
physical signal chain includes the external cable harness , the pinouts of the
connectors and the internal cable harness.

564
ConfigurationDesk Bus Manager Implementation Guide May 2024
 R

Pins and External Wiring table A pane that lets you access the external
wiring information

Platform A dSPACE real-time hardware system that can be registered and

displayed in the Platform Manager .

Platform Manager A pane that lets you handle registered hardware

platforms . You can download, start, and stop real-time applications via the
Platform Manager. You can also update the firmware of your dSPACE real-time
hardware.

Preconfigured application process An application process that was

created via the Create preconfigured application process command. If you
use the command, ConfigurationDesk creates new tasks for each runnable
function provided by the model that is not assigned to a predefined task.
ConfigurationDesk assigns the corresponding runnable function and (for periodic
tasks) timer events to the new tasks. The tasks are preconfigured (e.g., DAQ
raster name, period).

Processing Resource Assignment table A pane that lets you configure and
inspect the processing resources in an executable application . This table is
useful especially for multi-processing-unit applications .

Processing unit application A component of an executable application .A

processing unit application contains one or more application processes .

Project A container for ConfigurationDesk applications . You must define

a project or open an existing one to work with ConfigurationDesk. Projects are
stored in a project location .

Project location A designated folder in your file system where

ConfigurationDesk stores project and application folders. Several projects
can use the same project location. ConfigurationDesk uses the Documents
folder as the default project location. You can specify further project locations,
but only one can be active at a time.

Project Manager A pane that provides access to ConfigurationDesk

projects and applications and all the components and files they contain.

Properties Browser A pane that lets you access the properties of selected
elements.

PU Abbreviation of processing unit.

A hardware assembly that consists of a motherboard or a dSPACE processor
board, possibly additional interface hardware for connecting I/O boards, and an
enclosure, e.g., a SCALEXIO Processing Unit.

Real-time application An application that can be executed in real time on

dSPACE real‑time hardware. The real-time application is the result of a build

565
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 ConfigurationDesk Glossary

process . It can be downloaded to real-time hardware via an RTA file . There

are different types of real-time applications:
§ Single-core real-time application .
§ Multicore real-time application .
§ Multi-PU application .

Restbus simulation A simulation method to test real ECUs by connecting

them to a simulator that simulates the other ECUs in the communication
clusters .

RTA file A real-time application file. An RTA file is an executable object file
for processor boards. It is created during the build process . After the build
process it can be downloaded to the real-time hardware.

Runnable function A function that is called by a task to compute results.

A model implementation provides a runnable function for its base rate task.
This runnable function can be executed in a task that is triggered by a timer
event. In addition, a Simulink behavior model provides a runnable function for
each Hardware-Triggered Runnable Function block contained in the Simulink
behavior model. This runnable function is suitable for being executed in an
asynchronous task.

Runnable Function block A type of model port block . A Runnable

Function block provides a runnable function port that can be mapped to
an event port of a function block for modeling an asynchronous task.

Runnable function port An element of a Runnable Function block . The

runnable function port can be mapped to an event port of a function
block for modeling an asynchronous task.

RX Communication data that is received by a bus member.

SCALEXIO system A dSPACE hardware-in-the-loop (HIL) system consisting of

one or more real-time industry PCs (PUs ), I/O boards, and I/O units. They
communicate with each other via the IOCNET . The system simulates the
environment to test an ECU . It provides the sensor signals for the ECU,
measures the signals of the ECU, and provides the power (battery voltage) for
the ECU and a bus interface for restbus simulation .

SDF file A system description file that contains information on the

CPU name(s), the corresponding object file(s) to be downloaded and the
corresponding variable description file(s). It is created during the build process.

Secured IPDU A term according to AUTOSAR. An IPDU that secures the

payload of another PDU (i.e., authentic IPDU) for secure onboard communication
(SecOC). The secured IPDU contains the authentication information that is used
to secure the authentic IPDU's payload. If the secured IPDU is configured as a
cryptographic IPDU, the secured IPDU and the authentic IPDU are mapped to
different frames . If the secured IPDU is not configured as a cryptographic IPDU,

566
ConfigurationDesk Bus Manager Implementation Guide May 2024
 S

i.e., it is a non‑cryptographic IPDU, the authentic IPDU is directly included in the

secured IPDU.

SIC file A Simulink implementation container file that contains the

model code of a Simulink behavior model . The SIC file can be used in
ConfigurationDesk and in VEOS.

Signal chain A term used in the documentation as a short form for logical
signal chain . Do not confuse it with the physical signal chain .

Signal Chain Browser A pane that lets you open and browse working
views such as the Global working view or user-defined working views.

Signal inport A signal port that represents an electrical connection point

of a function block which provides signal measurement (= input) functionality.

Signal outport A signal port that represents an electrical connection point

of a function block which provides signal generation (= output) functionality.

Signal port An element of a function block that provides the interface to

external devices (e.g., ECUs ) via device blocks . It represents an electrical
connection point of a function block.

Signal reference port A signal port that represents a connection point for
the reference potential of inports , outports and bidirectional ports . For
example: With differential signals, this is a reference signal, with single-ended
signals, it is the ground signal (GND).

SIL simulation Abbreviation of software‑in‑the‑loop simulation.

A purely PC-based simulation scenario without a connection to a physical
system, i.e., neither simulator hardware nor ECU hardware prototypes are
needed. SIL simulations are independent from real time and can run on VEOS .

Simulink implementation container A container that contains the model

code of a Simulink behavior model. A Simulink implementation container is
generated from a Simulink behavior model by using the Model Interface Package
for Simulink . The file name extension of a Simulink implementation container
is SIC.

Simulink model interface The part of the model interface that is available
in the connected Simulink behavior model.

Single-core real-time application An executable application that is

executed on only one core of the real-time hardware.

Single-PU system Abbreviation of single-processing-unit system.

A system consisting of exactly one PU and the directly connected I/O units and
I/O routers.

SLX file A Simulink model file that contains the behavior model . You can
add an SLX file to your ConfigurationDesk application .
As of MATLAB® R2012a, the file name extension for the Simulink model file has
been changed from MDL to SLX by The MathWorks®.

Software event An event that is activated from within a task to trigger

another subordinate task. Consider the following example: A multi-tasking
Simulink behavior model has a base rate task with a sample time = 1 ms and
a periodic task with a sample time = 4 ms. In this case, the periodic task is

567
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 ConfigurationDesk Glossary

triggered on every fourth execution of the base rate task via a software event.
Software events are available in ConfigurationDesk after model analysis .

Source Code Editor A Python editor that lets you open and edit Python
scripts that you open from or create in a ConfigurationDesk project in a window
in the working area . You cannot run a Python script in a Source Code Editor
window. To run a Python script you can use the Run Script command in the
Interpreter or on the Automation ribbon or the Run context menu command
in the Project Manager .

Structured data port A hierarchically structured port of a Data Inport block

or a Data Outport block. Each structured data port consists of more structured
and/or unstructured data ports. The structured data ports can consist of signals
with different data types (single, double, int8, int16, int32, int64, uint8, uint16,
uint32, uint64, Boolean).

Synchronized timer event A periodic event that lets you trigger a

task periodically and synchronously to a global time. You can specify a period,
a global time domain identifier, and an optional offset for a synchronized timer
event.

Table A type of pane that offers access to a specific subset of elements and
properties of the active ConfigurationDesk application in rows and columns.

TargetLink A dSPACE software product for production code generation.

It lets you generate highly efficient C code for microcontrollers in electronic
control units (ECUs). It also helps you implement control systems that have been
modeled graphically in a Simulink/Stateflow diagram on a production ECU.
TargetLink is able to provide a Simulink implementation container (SIC file) to be
used in ConfigurationDesk.

Task A piece of code whose execution is controlled by a real-time operating

system (RTOS). A task is usually triggered by an event , and executes one
or more runnable functions . In a ConfigurationDesk application, there are
predefined tasks that are provided by executable application components . In
addition, you can create user-defined tasks that are triggered, for example, by I/O
events. Regardless of the type of task, you can configure the tasks by specifying
the priority, the DAQ raster name, etc.

Task Configuration table A pane that lets you configure the tasks of an
executable application .

Temporary working view A working view that can be used for drafting a
signal chain segment, like a notepad.

Timer event A periodic event with a sample rate and an optional offset.

Topology A hierarchy that serves as a repository for creating a signal chain .

All the elements of a topology can be used in the signal chain, but not every
element needs to be used. You can export each topology from and import it to

568
ConfigurationDesk Bus Manager Implementation Guide May 2024
 U

a ConfigurationDesk application . Therefore a topology can be used in several

applications.
A ConfigurationDesk application can contain the following topologies:
§ Device topology
§ Hardware topology
§ Model topology

TRC file A variable description file that contains all variables (signals and
parameters) which can be accessed via the experiment software. It is created
during the build process .

TX Communication data that is transmitted by a bus member.

User code A term used in the Bus Manager context. User code is C
code or C++ code containing user-specific algorithms. The algorithms provide
additional functionality to the Bus Manager, such as calculating checksum values
or generating authentication information for secured IPDUs . To implement
user code in executable applications , you have to use functions of the
Bus Custom Code interface and add the user code implementation to
ConfigurationDesk. Do not confuse user code with custom code .

User code implementation A term used in the Bus Manager context.

An implementation of user code in ConfigurationDesk. A user code
implementation consists of one or more source files (*.c, *.cpp) and optional
include files (*.h, *.hpp), such as header files.

User function An external function or program that is added to the

Automation – User Functions ribbon group for quick and easy access during
work with ConfigurationDesk.

VEOS The dSPACE software product for building offline simulation

applications and performing SIL simulation . VEOS is a PC‑based simulation
platform that allows SIL simulation independently from real time. VEOS can run
on Windows or Linux and consists of different components, such as the VEOS
Player .

VEOS Player A component of VEOS . The VEOS Player is the graphical user
interface for VEOS on Windows. For example, you can use the VEOS Player
to import bus simulation containers to VEOS, integrate the respective bus
communication in an offline simulation application , and load the application
to VEOS.

569
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 ConfigurationDesk Glossary

View set A specific arrangement of some of ConfigurationDesk's panes. You

can switch between view sets by using the navigation bar . ConfigurationDesk
provides preconfigured view sets for specific purposes. You can customize
existing view sets and create user-defined view sets.

VSET file A file that contains all view sets and their settings from the current
ConfigurationDesk installation. A VSET file can be exported and imported via the
View Sets page of the Customize dialog.

Working area The central area of ConfigurationDesk's user interface.

Working view A view of the signal chain elements (blocks, ports,

mappings, etc.) used in the active ConfigurationDesk application . A working
view can be opened in the Signal Chain Browser or the Model Communication
Browser . ConfigurationDesk provides two default working views: The Global
working view and the Temporary working view . In the Working View
Manager , you can also create user-defined working views that let you focus
on specific signal chain segments according to your requirements.
You can export the signal chain elements from a working view to a CAFX
file and import them to a working view in a different ConfigurationDesk
application.

Working View Manager A pane that lets you manage the working
views of the active ConfigurationDesk application . You can use the
Working View Manager for creating, renaming, and deleting working views,
and also to open a working view in the Signal Chain Browser or the Model
Communication Browser .

XLSX file A Microsoft Excel™ file format that is used for the following
purposes:
§ Creating or configuring a device topology outside of ConfigurationDesk.
§ Exporting the wiring information for the external cable harness .

570
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Index
Index
user‑defined 127 simulating 148
A Bus Configuration Enable feature 331 user-defined 404
bus configuration features runnable functions 363
adding
adding 192 secure onboard communication 67
behavior model 352
basics 192 simulation use scenarios 31
bus communication to signal chain 340
Bus Configuration Enable 331 supported PDU types 58
bus configuration 338
Communication Controller Enable 302 supported signal data types 58
communication matrix 335
configuring function ports 198 tasks 363
application process 385
Counter Signal 223 user code 139
assigning
Filter Control 328 variants 17
communication matrix to bus
Frame Access 288 Bus Manager Basics demo
configuration 340
Frame Capture Data 323 overview 448
authentic IPDUs 67
Frame Gateway Direction 327 steps of the Python script 452
automation interface 152
Frame Length 295 Bus Manager demos
GTS Time Base Data 315 overview 442
B GTS Transmission Control 313 Bus Manager SecOC demo
behavior model GTS Validation 317 definitions in the UserCode_SecOCDemo.c
configuring bus communication for real-time ISignal Group End‑to‑End Protection file 481
applications with a behavior model 45 Status 235 overview 471
configuring bus communication for real-time ISignal Offset Value 231 steps of the Python script 475
applications without a behavior model 48 ISignal Overwrite Value 228 bus simulation container
generating bus simulation containers with a ISignal Value 221 basics 373
behavior model 53 J1939 PDU Priority 263 bus access request 375
generating bus simulation containers without LIN Schedule Table 307 generating 379
a behavior model 54 LIN Wake-Up 305 port interface 377
working without a behavior model 385 manipulating bus communication 213
BSC files Partial Network Cluster Enable 321 C
basics 373 PDU Cyclic Timing Control 243
CAN
generating 379 PDU Enable 238
aspects of supported features 77
bus access 155 PDU Length 249
bus properties 361
assigning 344 PDU Raw Data 240
CAN FD 77
bus access request 155 PDU RX Interrupt 281
container IPDUs 64
bus simulation container 375 PDU RX Status 251
extended signal multiplexing 78
Bus Access Requests bus configuration part 107 PDU Selector Field 266
hardware access 157
bus communication defined in communication PDU Trigger 246
J1939 80
matrix 23 PDU User Code 254
multiplexed IPDUs 63
bus configuration SecOC 268
secure onboard communication 67
adjusting to a changed communication SecOC Authenticator Invalidation 271
cluster 23
matrix 435 SecOC Freshness Overwrite Value 274
coded signal value 60
assigning communication matrix Suspend Frame Transmission 298
Common Program Data folder 12, 552
elements 112 Suspend PDU Transmission 278
Communication Controller Enable feature 302
basics 100 Bus Custom Code interface 139
communication matrix
Bus Access Requests part 107 Bus Manager
adding elements 391
configurable node names 102 automation interface 152
assigning elements to bus
deprecated node 435 CAN bus features 77
configurations 112
features 192 container IPDUs 64
basics 92
filter for mappable ports 109 end-to-end protection 69
configurable elements 391
frame capture 105 event‑controlled timings 70
defining bus communication 23
function block 109 events 363
generating missing ECUs 95
Gateways part 105 gateway use scenarios 36
removing elements from bus
handling conflicts 163 implementing global time
configurations 120
Inspection part 105 synchronization 181
replacing 435
Manipulation part 105 implementing partial networking 146
supported file formats and versions 92
parts 103 implementing secure onboard
user-defined settings 391
removing communication matrix communication 143
computation methods 60
elements 120 inspection use scenarios 33
configurable node names 102
Simulated ECUs part 105 LIN bus features 88
conflicts
simulating PDU gateways 148 manipulation use scenarios 34
bus configuration 163
specifying frame captures 171 multiplexed IPDUs 63
communication matrix 163
specifying frame gateways 173 overview 17
container IPDUs 64
tables 103 partial networking 74
Counter Signal feature 223
bus configuration behavior PDU gateways
creating restbus configurations 121
default 125 AUTOSAR 76
cryptographic IPDUs 67

571
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Index

D H partial networking 74
implementing in executable applications 146
demos of the Bus Manager 442 hardware access 157
PDU
deprecated communication matrix node 435 specifying 344
instance 119
Documents folder 12, 555 hardware resources
PDU Cyclic Timing Control feature 243
dynamic simulation 31 assigning 344
PDU Enable feature 238
PDU gateways
E I AUTOSAR 76
E2E protection 69 initial values 198 simulating 148
ECU simulation 31 inspection user-defined 404
ECUs use scenarios 33 PDU Length feature 249
generating during communication matrix Inspection bus configuration part 105 PDU Raw Data feature 240
import 95 instantiating PDU RX Interrupt feature 281
element identification via node names 102 PDUs and ISignals 119 PDU RX Status feature 251
end-to-end protection 69 ISignal PDU Selector Field feature 266
event‑controlled timings 70 instance 119 PDU Trigger feature 246
events signal conversion 60 PDU User Code feature 254
provided by the Bus Manager 363 ISignal Group End‑to‑End Protection Status physical signal value 60
extended signal multiplexing 78 feature 235 port interface
ISignal Offset Value feature 231 bus simulation container 377
F ISignal Overwrite Value feature 228

failure gateway
ISignal Value feature 221 R
overview 36 recalculate
specifying 174 J end-to-end protection information 217
Filter Control feature 328 J1939 SecOC information 217
filters basics 80 replacing a communication matrix 435
communication matrix 98 bridge ECUs 95 restbus configuration
Frame Access feature 288 J1939 PDU Priority feature 263 create 121
frame capture 105 restbus simulation 31
Frame Capture Data feature 323 create restbus configuration 121
L
frame captures runnable functions
LIN provided by the Bus Manager 363
filters 177
aspects of supported features 88
specifying 171
bus properties 362
Frame Gateway Direction feature 327
hardware access 157
S
frame gateways
LIN Schedule Table feature 307 saturation values 201
filters 177
LIN Wake-Up feature 305 SecOC Authenticator Invalidation feature 271
specifying 173
Local Program Data folder 12, 560 SecOC feature 268
Frame Length feature 295
SecOC Freshness Overwrite Value feature 274
function ports
secure onboard communication 67
configuring 198 M
implementing in executable applications 143
manipulating bus communication 213 secured IPDUs 67
G execution sequence 220 Simulated ECUs bus configuration part 105
recalculate end-to-end protection simulation
gateways
information 217 dynamic 31
filters 177
recalculate SecOC information 217 ECU 31
simulating PDU gateways 148
manipulation restbus 31
specifying frame gateways 173
use scenarios 34 static 31
use scenarios 36
Manipulation bus configuration part 105 use scenarios 31
Gateways bus configuration part 105
model access 199 specifying
generating
enabling 351 hardware access 344
bus simulation container 379
multiplexed IPDUs 63 static simulation 31
global time synchronization
global time domain elements 182 Suspend Frame Transmission feature 298
implementing in executable applications 181 N Suspend PDU Transmission feature 278
using synchronized timer events 185 network node 23 synchronized timer events 185
using triggers of the RTI Synchronized Time node names 102
Base Manager Blockset 188 T
GTS Time Base Data feature 315
O tasks
GTS Transmission Control feature 313
overview of the Bus Manager 17 provided by the Bus Manager 363
GTS Validation feature 317
test automation support 199

P
Partial Network Cluster Enable feature 321

572
ConfigurationDesk Bus Manager Implementation Guide May 2024
 Index

U
use scenarios of the Bus Manager
gateways 36
inspection 33
manipulation 34
overview 29
simulation 31
user code 139
user interface
Bus Manager-specific elements 25
using the Bus Manager and building real-time
applications
workflows 43

V
variants of the Bus Manager 17

W
workflow
configuring bus communication and
generating bus simulation containers 51
configuring bus communication for real-time
applications 43
configuring bus communication for real-time
applications with a behavior model 45
configuring bus communication for real-time
applications without a behavior model 48
generating bus simulation containers with a
behavior model 53
generating bus simulation containers without
a behavior model 54
working without a behavior model 385

573
May 2024 ConfigurationDesk Bus Manager Implementation Guide
 Index

574
ConfigurationDesk Bus Manager Implementation Guide May 2024