New Features and Migration

New Features and Migration
dSPACE Release
New Features and
Migration
Release 2015‑B – November 2015
How to Contact dSPACE
Mail:
dSPACE GmbH
Rathenaustraße 26
33102 Paderborn
Germany
Tel.:
+49 5251 1638-0
Fax:
+49 5251 16198-0
E-mail:
[email protected]
Web:
http://www.dspace.com
How to Contact dSPACE Support
To contact dSPACE if you have problems and questions, fill out the support request form
provided on the website at http://www.dspace.com/go/supportrequest.
The request form helps the support team handle your difficulties quickly and efficiently.
In urgent cases contact dSPACE via phone: +49 5251 1638-941 (General Technical
Support)
Software Updates and Patches
dSPACE strongly recommends that you download and install the most recent patches for
your current dSPACE installation. Visit http://www.dspace.com/go/support for software
updates and patches.
Important Notice
This document contains proprietary information that is protected by copyright. All rights
are reserved. The document may be printed for personal or internal use provided all the
proprietary markings are retained on all printed copies. In all other cases, the document
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.
© 2000 - 2015 by:
dSPACE GmbH
Rathenaustraße 26
33102 Paderborn
Germany
This publication and the contents hereof are subject to change without notice.
CalDesk, ConfigurationDesk, ControlDesk, MicroAutoBox, SCALEXIO, 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
About This Document
11
Document Symbols and Conventions..................................... 11
Accessing Online Help and PDF Files...................................... 12
Overview of dSPACE Release 2015‑B
General Enhancements and Changes.....................................
64‑Bit Version of RCP and HIL Software.................................
Product Version Overview......................................................
New Product Key Features.....................................................
15
15
19
20
24
Aspects of Migrating from Previous
Releases
33
Migrating to dSPACE Release 2015‑B.................................... 33
Changes to TRC File Generation
35
Basics on the TRC File Changes.............................................. 35
Migrating Changes in Software that Generates TRC Files....... 41
Migrating Changes in Software That Uses TRC Files............... 42
Changes to the Python 2.7 Distribution
Main Changes in Python 2.7..................................................
Main Changes of the dSPACE Python Distribution............. ....
General Information on Using Python Installations.................
Enhancements to the Standard Python 2.7 Distribution.........
45
45
46
46
47
AutomationDesk
49
New Features of AutomationDesk 5.1................................... 49
Automotive Simulation Models (ASM)
53
ASM Base InCylinder Blockset......................................................... 54
New Features of ASM Base InCylinder Blockset 2.1................ 54
Migrating to ASM Base InCylinder Blockset 2.1...................... 54
New Features and Migration
November 2015
3
t
s Contents t
ASM Diesel Engine Blockset............................................................
New Features of ASM Diesel Engine Blockset 2.2...................
Migrating to ASM Diesel Engine Blockset 2.2.................... ....
ASM Diesel Exhaust Blockset..........................................................
Migrating to ASM Diesel Exhaust Blockset 2.1.1....................
ASM Diesel InCylinder Blockset.......................................................
New Features of ASM Diesel InCylinder Blockset 2.1..............
Migrating to ASM Diesel InCylinder Blockset 2.1....................
ASM Drivetrain Basic Blockset.........................................................
New Features of ASM Drivetrain Basic Blockset 4.1.1.............
Migrating to ASM Drivetrain Basic Blockset 4.1.1.............. ....
ASM Electric Components Blockset............................................ ....
New Features of ASM Electric Components Blockset 3.1........
Migrating to ASM Electric Components Blockset 3.1......... ....
ASM Environment Blockset.............................................................
New Features of ASM Environment Blockset 4.3....................
Migrating to ASM Environment Blockset 4.3..................... ....
ASM Gasoline Engine Basic Blockset...............................................
New Features of ASM Gasoline Engine Basic Blockset
2.0.2.....................................................................................
Migrating to ASM Gasoline Engine Basic Blockset 2.0.2.........
ASM Gasoline Engine Blockset................................................... ....
New Features of ASM Gasoline Engine Blockset 3.2.......... ....
Migrating to ASM Gasoline EngineBlockset 3.2.....................
ASM Gasoline InCylinder Blockset.............................................. ....
New Features of ASM Gasoline InCylinder Blockset 2.1..........
Migrating to ASM Gasoline InCylinder Blockset 2.1........... ....
ASM Optimizer...............................................................................
New Features of ASM Optimizer 1.7......................................
Migrating to ASM Optimizer Blockset 1.7..............................
ASM Traffic Blockset.................................................................. ....
New Features of ASM Traffic Blockset 3.3......................... ....
Migrating to ASM Traffic Blockset 3.3...................................
ASM Trailer Blockset.......................................................................
New Features of ASM Trailer Blockset 2.4..............................
Migrating to ASM Trailer Blockset 2.4............................... ....
ASM Truck Blockset........................................................................
New Features of ASM Truck Blockset 2.3...............................
Migrating to ASM Truck Blockset 2.3................................ ....
4
s
New Features and Migration
November 2015
55
55
57
59
59
60
60
61
62
62
62
63
63
64
66
66
66
67
67
68
70
70
72
74
74
75
76
76
77
78
78
79
80
80
81
82
82
83
s Contents t
ASM Turbocharger Blockset....................................................... ....
New Features of ASM Turbocharger Blockset 3.1.1........... ....
Migrating to ASM Turbocharger Blockset 3.1.1.....................
ASM Vehicle Dynamics Blockset................................................. ....
New Features of ASM Vehicle Dynamics Blockset 3.2........ ....
Migrating to ASM Vehicle Dynamics Blockset 3.2..................
84
84
85
87
87
88
ConfigurationDesk
89
ConfigurationDesk – Implementation............................................. 90
New Features of ConfigurationDesk 5.4 (Implementation
Version)................................................................................. 90
Migrating to ConfigurationDesk 5.4...................................... 95
Container Management
97
New Features of Container Management.......................... .... 97
ControlDesk Next Generation
New Features of ControlDesk Next Generation
(ControlDesk 5.5).........................................................................
New Features of Platform Management and
Platforms/Devices (ControlDesk 5.5).................................. ..
New Variable Management Features (ControlDesk 5.5)..... ..
New Visualization and Instrument Features
(ControlDesk 5.5)................................................................
New Measurement and Recording Features
(ControlDesk 5.5)................................................................
New Bus Navigator Features (ControlDesk 5.5)....................
New Data Set Management Features (ControlDesk 5.5).......
New Signal Editor Features (ControlDesk 5.5)......................
New Electrical Error Simulation Features (ControlDesk 5.5) ..
New Automation Features (ControlDesk 5.5).......................
Migrating to ControlDesk Next Generation (ControlDesk 5.5).......
Discontinuations in ControlDesk..........................................
Migrating to ControlDesk Next Generation
(ControlDesk 5.5)................................................................
99
100
100
103
105
107
108
109
109
110
111
113
113
116
DCI Configuration Tool
123
New Features of the DCI Configuration Tool 3.5.................. 123
New Features and Migration
November 2015
5
t
s Contents t
dSPACE FlexRay Configuration Package
125
New Features of dSPACE FlexRay Configuration Package
3.6...................................................................................... 125
dSPACE HIL API .NET
127
New Features of dSPACE HIL API .NET 2.0........................... 127
dSPACE Python Extensions
129
New Features of dSPACE Python Extensions 2.0................ .. 129
dSPACE XIL API
133
New Features of dSPACE XIL API 2015‑B............................. 133
ECU Interface Manager
135
New Features of ECU Interface Manager 1.7..................... .. 135
Migrating to ECU Interface Manager 1.7............................. 136
Firmware Manager
139
New Features of Firmware Manager 2.0.............................. 139
Model Compare
141
New Features of Model Compare 2.6.................................. 141
Migration to Model Compare 2.6........................................ 143
ModelDesk
145
New Features of ModelDesk 4.2.......................................... 145
Model Interface Package for Simulink
147
Features of the Model Interface Package for Simulink 3.1.... 147
MotionDesk
149
New Features of MotionDesk 3.7...................................... .. 149
Migrating to MotionDesk 3.7.............................................. 150
Real-Time Testing
151
New Features of Real-Time Testing 2.6................................ 151
6
s
New Features and Migration
November 2015
s Contents t
RTI/RTI-MP and RTLib
153
New Features of RTI/RTI-MP and RTLib................................. 153
Migration Aspects of RTI/RTI-MP and RTLib.......................... 156
RTI Bypass Blockset
157
New Features of the RTI Bypass Blockset 3.5........................ 157
Migrating to RTI Bypass Blockset 3.5................................. .. 158
RTI CAN MultiMessage Blockset
161
New Features of the RTI CAN MultiMessage Blockset 4.2.. .. 161
Migrating to RTI CAN MultiMessage Blockset 4.2................ 162
RTI Electric Motor Control Blockset
165
New Features of RTI Electric Motor Control Blockset 1.2...... 165
RTI FPGA Programming Blockset
167
New Features of the RTI FPGA Programming Blockset 3.0.... 167
Migrating to RTI FPGA Programming Blockset 3.0............. .. 170
RTI LIN MultiMessage Blockset
173
New Features of the RTI LIN MultiMessage Blockset 2.5.1.... 173
Migrating to RTI LIN MultiMessage Blockset 2.5.1............. .. 173
SCALEXIO Firmware
175
New Features of the SCALEXIO Firmware 3.3.................... .. 175
SystemDesk
New Features of SystemDesk 4.5..................................................
New General Features.........................................................
Modeling Software Architectures...................................... ..
Working with Diagrams.......................................................
Configuring ECUs................................................................
Simulating Systems..............................................................
Automating SystemDesk................................................... ..
Variation Binding.................................................................
New Features and Migration
November 2015
177
178
178
179
179
181
187
187
188
7
t
s Contents t
Migrating to SystemDesk 4.5........................................................ 190
Migrating to SystemDesk 4.5............................................... 190
TargetLink
191
New Features of TargetLink 4.1 and TargetLink Data Dictionary
4.1...............................................................................................
Modeling in Simulink or Stateflow...........................................
Newly Supported Simulink Blocks........................................
Improvements to Custom Look-up Tables............................
Support of Simulink's Simplified Mode and IC Structures.....
Support of Structures in Stateflow Action Language............
Code Generation Core Functionality........................................
MISRA-C Compliance........................................................ ..
Improved Code Efficiency....................................................
Component-Based Development..............................................
Improvements to Function Reuse.........................................
AUTOSAR................................................................................
Supported AUTOSAR Releases.............................................
Support of NvData Communication.....................................
Data Transformation......................................................... ..
Activation Reasons of Runnables.........................................
Port-Defined Argument Values............................................
Miscellaneous AUTOSAR Features..................................... ..
Target Simulation (PIL).............................................................
Changes in the Target Simulation Modules..........................
Folder for TSM Extensions................................................. ..
Data Dictionary and Data Management...................................
Improvements to the Data Dictionary................................ ..
New DD MATLAB API Functions..........................................
Referencing DD CodegenOptions Objects at TargetLink
Main Dialog Block...............................................................
Code Generator Options..........................................................
New Code Generator Options........................................... ..
Tool Chain Integration.............................................................
Exporting Functional Mock-up Units....................................
Requirement Information in the Data Dictionary..................
Other.......................................................................................
General Enhancements and Changes...................................
TargetLink Demos............................................................. ..
8
s
New Features and Migration
November 2015
192
192
193
193
194
194
195
195
196
199
199
200
200
201
201
201
202
202
203
203
205
206
206
207
208
208
208
209
210
210
211
211
213
s Contents t
API Functions and Hook Functions...........................................
New API Functions............................................................ ..
New Hook Functions...........................................................
Migrating to TargetLink 4.1 and TargetLink Data Dictionary 4.1. ..
Upgrade of Models, Libraries, and Data Dictionaries.................
Migrating to TargetLink 4.1.................................................
How to Upgrade a Data Dictionary with Included DD Files...
How to Manually Upgrade Libraries and Models Via the
API......................................................................................
Code Generator Options..........................................................
Migration Aspects Regarding Code Generator Options........
API Functions and Hook Functions...........................................
Changes in TargetLink and TargetLink Data Dictionary API
Functions.......................................................................... ..
AUTOSAR-Related Migration Aspects.......................................
AUTOSAR-Related Migration Aspects..................................
Code Changes.........................................................................
Code Changes.....................................................................
Other.......................................................................................
Various Migration Aspects...................................................
Obsolete..................................................................................
Obsolete Limitations............................................................
Changes in Future TargetLink Versions.....................................
Features to Be Discontinued................................................
API Functions to Be Discontinued...................................... ..
215
215
216
218
219
219
220
222
223
223
226
226
226
226
227
227
242
242
244
244
245
245
246
VEOS
247
New Features of VEOS 3.5................................................... 247
Migrating to VEOS 3.5...................................................... .. 250
Compatibility Information
Supported MATLAB Releases...............................................
Operating System................................................................
Run-Time Compatibility of dSPACE Software.......................
Limitations for 64-Bit Windows Operating Systems in
Combination with 32-Bit dSPACE Software....................... ..
New Features and Migration
November 2015
253
254
255
257
258
9
t
s Contents t
Products on the 64-Bit dSPACE DVD Set and Their
MATLAB Support.............................................................. .. 259
General Limitations for Windows 7...................................... 261
Index
10
s
New Features and Migration
263
November 2015
About This Document
Contents
This document informs you about the new features of all the dSPACE
software products in Release 2015‑B. It also gives you an overview of
software products with no or minor changes. There are instructions
on migrating from earlier dSPACE releases, especially from earlier
product versions, if required.
Where to go from here
Information in this section
Document Symbols and Conventions
11
Accessing Online Help and PDF Files
12
Document Symbols and Conventions
Symbols
The following symbols may be used in this document.
Indicates a general hazard that may cause personal injury
of any kind if you do not avoid it by following the
instructions given.
Indicates the danger of electric shock which may cause
death or serious injury if you do not avoid it by following
the instructions given.
Indicates a hazard that may cause material damage if you
do not avoid it by following the instructions given.
Indicates important information that should be kept in
mind, for example, to avoid malfunctions.
New Features and Migration
November 2015
11
t
s About This Document t
Indicates tips containing useful information to make your
work easier.
Naming conventions
The following abbreviations and formats are used in this document:
%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.
Precedes the document title in a link that refers to another
document.
Indicates that a link refers to another document, which is available
in dSPACE HelpDesk.
Special folders
Some software products, for example, ControlDesk Next Generation
and AutomationDesk, use the following special folders:
Common Program Data folder A standard folder for applicationspecific configuration data that is used by all users.
%PROGRAMDATA%\dSPACE\<InstallationGUID>\<ProductName>
Documents folder A standard folder for user-specific documents.
%USERPROFILE%\My Documents\dSPACE\<ProductName>\
<VersionNumber>
Local Program Data folder A standard folder for applicationspecific configuration data that is used by the current, non-roaming
user.
%USERPROFILE%\AppData\Local\dSPACE\<InstallationGUID>\
<ProductName>
Accessing Online Help and PDF Files
Objective
After you install your dSPACE software, the documentation for the
installed products is available as online help and Adobe® PDF files.
Online help
You can access the online help, dSPACE HelpDesk, as follows:
Windows Start menu Select Start – (All) Programs –
<ProductName> – dSPACE HelpDesk (<ProductName>) to open
dSPACE HelpDesk with the start page of the selected product
12
s
New Features and Migration
November 2015
s Accessing Online Help and PDF Files t
displayed. You can also navigate and search in the user
documentation of any other installed software product and its
supported hardware.
Context-sensitive Press the F1 key or click the Help button in the
dSPACE software to get help on the currently active context.
In some software products, context-sensitive help is not
available.
Help menu in the dSPACE software On the menu bar, select
Help – Contents or Help – Search (not available in all software
products) to open dSPACE HelpDesk. It opens at the start page of the
currently active product. You can also navigate and search in the user
documentation of any other installed software product and its
supported hardware.
PDF files
You can access the PDF files as follows:
dSPACE HelpDesk Click the PDF link at the beginning of a
document:
New Features and Migration
November 2015
13
t
s About This Document t
14
s
New Features and Migration
November 2015
Overview of dSPACE
Release 2015‑B
Objective
Gives you an overview of the new key features in Release 2015‑B and
information about unchanged products.
Where to go from here
Information in this section
General Enhancements and Changes
15
64‑Bit Version of RCP and HIL Software
19
Product Version Overview
20
New Product Key Features
24
General Enhancements and Changes
Objective
The following new features and changes concern several dSPACE
products.
Support of new dSPACE
hardware
With dSPACE Release 2015‑B, new dSPACE hardware is introduced:
n DS2655M2 I/O Module
This SCALEXIO module can be mounted on a DS2655 FPGA Base
Board and is supported by the RTI FPGA Programming Blockset,
refer to New Features of the RTI FPGA Programming Blockset 3.0
on page 167.
New Features and Migration
November 2015
15
t
s Overview of dSPACE Release 2015‑B t
Distribution of 32-bit and
64-bit software
The dSPACE software is distributed on two DVD sets, each with the
same content but with the following differences:
n One set with two 32-bit DVDs containing only 32-bit dSPACE
software products (e.g., to support 32-bit MATLAB versions).
n One set with two 64-bit DVDs containing:
n
n
n
All MATLAB-related dSPACE products which support 64-bit
MATLAB versions.
All 32-bit dSPACE products which also support 64-bit MATLAB
versions.
All 32-bit dSPACE products that do not relate to MATLAB (e.g.,
ControlDesk Next Generation).
You can therefore install dSPACE software from the 64bit DVD set without changing to the 32-bit DVD set
during the installation procedure.
For a list of all dSPACE products contained on the 64-bit dSPACE
DVD set and their MATLAB support, refer to Products on the 64Bit dSPACE DVD Set and Their MATLAB Support on page 259.
Contents of DVD sets
The dSPACE software is provided on two disks for each DVD set (32bit and 64-bit). The disks contain the following dSPACE software
packages and main products:
n Disk 1:
n
AutomationDesk 5.1
n
ControlDesk Next Generation (ControlDesk 5.5)
n
TargetLink 4.1
n
Model Compare 2.6
Product use prohibited in United States
You are not licensed to use Model Compare in the
United States. You are not allowed to use or permit
others to use this product in the United States or in
any way that violates the laws of the United States.
16
s
n
SystemDesk 4.5 (supports AUTOSAR 4.x)
n
VEOS 3.5
n
Various other dSPACE software tools
New Features and Migration
November 2015
s General Enhancements and Changes t
n Disk 2:
n
RCP and HIL software
RCP and HIL software is a generic term for a software package
containing several dSPACE software products, such as RTI,
ConfigurationDesk, MotionDesk, and ModelDesk.
Disk 2 does not contain any other dSPACE software
products.
New hardware dongles for
dongle licenses
As of dSPACE Release 2014-B, the hardware dongle for dongle
licenses is now a CodeMeter instead of a WibuKey. Both are products
of WIBU-SYSTEMS and are shown below.
WibuKey dongle
CodeMeter dongle
With dSPACE Release 2014-B, the new CodeMeter hardware dongles
are shipped with new dSPACE systems for the first time.
Keep the following compatibility information in mind:
n In general, you can use dSPACE Release 2015-B with an already
delivered WibuKey dongle. As of dSPACE Release 2014-B, the
drivers for both dongle versions are installed on your host PC. The
driver software automatically detects which dongle is used. No
further user action is necessary.
n If you want to use dSPACE Release 2014-A and earlier with the
new CodeMeter dongle, you have to install dSPACE Installation
Manager 3.8 (or later) on your host PC. This version contains the
driver for the new dongle. You can download the latest version of
dSPACE Installation Manager from
http://www.dspace.com/go/imupdate.
n dSPACE Release 6.3 and earlier versions have not been tested for
the new CodeMeter dongle. If necessary, contact dSPACE
Support.
Restrictions when working
with dSPACE HelpDesk
dSPACE HelpDesk is installed in release-specific folders in C:\Program
Files\Common Files\dSPACE on a 32-bit operating system and in
C:\Program Files(x86)\Common Files\dSPACE on a 64-bit operating
system. For example, if you have installed products from dSPACE
Release 2015‑A and products from dSPACE Release 2015‑B, two
dSPACE HelpDesks are available.
Note the following restrictions:
New Features and Migration
November 2015
17
t
s Overview of dSPACE Release 2015‑B t
Links to documents might not work and might return the following
error message: Selection is not associated with any topics. The
possible reasons are:
n The documents for the product are not installed, because the
product is not included in your license key.
n The documents for the product are installed in another dSPACE
HelpDesk. For example, if a product in the current dSPACE Release
is unchanged, its user documentation is installed in the dSPACE
HelpDesk version that the product setup was created for.
After you install dSPACE Release 2015‑B, you can find the user
documentation in dSPACE HelpDesk 2015‑A for the following
products:
n
dSPACE ECU Flash Programming Tool 2.2.6
n
SYNECT Server 1.4.1
If you are not sure where to find the user documentation for your
product, use the product‑specific dSPACE HelpDesk shortcut in the
Windows Start menu to open the online help.
Printed user documentation
With dSPACE Release 2015‑B, the printed user documentation is not
delivered automatically. You can now decide which of the available
printed documents you want to have. To order printed
documentation, refer to
http://www.dspace.com/go/requestreleasematerial.
If you do not order printed documentation, use dSPACE
HelpDesk or PDF files to obtain information about new
features, enhancements, and the safety precautions
regarding your products.
Software support
discontinuation
Planned discontinuation of 32‑bit software support dSPACE
Release 2015-B is the last release supporting 32-bit operating systems
and 32-bit MATLAB variants. As of dSPACE Release 2016-A, dSPACE
software supports only 64-bit operating systems and only 64-bit
MATLAB variants.
Planned discontinuation of MicroAutoBox software support
dSPACE Release 2015-B is the last release supporting MicroAutoBox
with its variants 1401/1501, 1401/1504, 1401/1505/1506,
1401/1505/1507, and 1401/1507. As of dSPACE Release 2016‑A,
dSPACE software supports only MicroAutoBox II with its variants
1401/1507, 1401/1511, 1401/1513, 1401/1511/1514, and
1401/1513/1514.
18
s
New Features and Migration
November 2015
s 64‑Bit Version of RCP and HIL Software t
64‑Bit Version of RCP and HIL Software
Objective
The RCP and HIL software products support 64‑bit MATLAB versions.
Product support in RCP and
HIL (64‑bit) software
In general, the RCP and HIL (64‑bit) software contains the same
products as the RCP and HIL software available on dSPACE
Release 2015‑B (32‑bit) DVD.
For an overview of RCP and HIL and all other dSPACE software
products concerning the 64‑bit MATLAB support, refer to Products on
the 64-Bit dSPACE DVD Set and Their MATLAB Support on page 259.
Supported MATLAB
versions
The RCP and HIL (64‑bit) software supports:
n MATLAB R2014a (64‑bit)
n MATLAB R2014b (64‑bit)
n MATLAB R2015a (64‑bit)
n MATLAB R2015b (64‑bit)
See also Supported MATLAB Releases on page 254.
Supported MEX compiler
For building MEX functions, the RCP and HIL (64‑bit) software
supports only Microsoft Windows SDK 7.1.
This compiler is a free download from Microsoft. The compiler
requires .NET framework 4.0, which is also available at no charge
from Microsoft. Download links and instructions for the compiler and
framework can be found at
http://www.mathworks.com/support/compilers/R2015a/index.html.
You must install this compiler and configure it as a MEX compiler in
MATLAB if you intend to use RCP and HIL products that require a
MEX compiler such as:
n RTI CAN MultiMessage Blockset
n RTI LIN MultiMessage Blockset
n Automotive Simulation Models
n MotionDesk Blockset
System requirements
The RCP and HIL (64‑bit) software requires Windows 7 Enterprise
(64‑bit version) with Service Pack 1. Other 64‑bit operating systems
(Windows XP and Windows Vista) are not supported.
New Features and Migration
November 2015
19
t
s Overview of dSPACE Release 2015‑B t
The host PC main memory must be at least 4 GB RAM. 8 GB RAM or
more is recommended.
See also Operating System on page 255.
Product Version Overview
Objective
The following table is an extract from product version histories
showing the product versions of the current release and of the three
preceding releases. If a product has new features, there is a link to
the brief description in this document.
Product
20
s
dSPACE Release
2014‑A
2014‑B
2015‑A
2015‑B
AutomationDesk
4.1
4.1
5.0
Automotive Simulation Models
6.0
7.0
8.0
ConfigurationDesk
5.1
5.2
5.3
Container Manager
4.2
4.3
4.3
ControlDesk Next Generation
5.2
5.3
5.4
DCI Configuration Tool
3.2.2
3.3
3.4
dSPACE CAN API
dSPACE ECU Flash Programming
Tool
2.7.1
2.2.5
2.7.1
2.2.5
2.7.1
2.2.6
5.1
See AutomationDesk
on page 49.
8.1
See Automotive
Simulation Models (ASM)
on page 53.
5.4
See ConfigurationDesk
on page 89.
4.4
See Container
Management
on page 97.
5.5
See ControlDesk Next
Generation on page 99.
3.5
See DCI Configuration
Tool on page 123.
2.7.4
2.2.6
New Features and Migration
November 2015
s Product Version Overview t
Product
dSPACE Release
2014‑A
2014‑B
2015‑A
2015‑B
dSPACE FlexRay Configuration
Package
3.3
3.4
3.5
dSPACE HIL API .NET
1.6
1.6
1.8
dSPACE Python Extensions
1.6
1.7
1.8
dSPACE XIL API
–
2.0
2015-A
ECU Interface Manager
1.4.1
1.5
1.6
Firmware Manager
1.1
1.2
1.3
Model Compare
2.4
2.5
2.5
ModelDesk
3.2
4.0
4.1
Model Interface Package for
Simulink
–
–
3.0
MotionDesk
3.4
3.5
3.6
MotionDesk Blockset
2.3
2.3.1
2.3.2
Real-Time Testing
2.3
2.4
2.5
3.6
See dSPACE FlexRay
Configuration Package
on page 125.
2.0
See dSPACE HIL API .NET
on page 127.
2.0
See dSPACE Python
Extensions on page 129.
2015‑B
See dSPACE XIL API
on page 133.
1.7
See ECU Interface
Manager on page 135.
2.0
See Firmware Manager
on page 139.
2.6
See Model Compare
on page 141.
4.2
See ModelDesk
on page 145.
3.1
See Model Interface
Package for Simulink
on page 147.
3.7
See MotionDesk
on page 149.
2.4
See MotionDesk
on page 149.
2.6
See Real-Time Testing
on page 151.
New Features and Migration
November 2015
21
t
s Overview of dSPACE Release 2015‑B t
Product
22
s
dSPACE Release
2014‑A
2014‑B
2015‑A
2015‑B
RTI1)
7.2
7.3
7.4
RTI-MP2)
7.2
7.3
7.4
RTI AUTOSAR Package
RTI Bypass Blockset
1.3.1
3.2
–
3.3
–
3.4
RTI CAN Blockset
RTI CAN MultiMessage Blockset
3.2
3.0
3.3
4.0
3.4
4.1
RTI Electric Motor Control Blockset
–
1.0
1.1
RTI Ethernet Blockset
RTI Ethernet (UDP) Blockset
RTI FPGA Programming Blockset
1.0
1.3
2.7
1.1
1.3
2.8
1.2
1.4
2.9
RTI LIN MultiMessage Blockset
2.3
2.4
2.5
RTI RapidPro Control Unit Blockset
RTI USB Flight Recorder Blockset
RTI Watchdog Blockset
SCALEXIO firmware
2.2
1.1
1.0
3.0
2.2
1.2
1.0
3.1
2.2.1
1.2
1.0
3.2
SYNECT server
SystemDesk 4.x3)
1.3.1
4.2
1.4
4.3
1.4.1
4.4
7.5
See RTI/RTI-MP and RTLib
on page 153.
7.5
See RTI/RTI-MP and RTLib
on page 153.
–
3.5
See RTI Bypass Blockset
on page 157.
3.4.1
4.2
See RTI CAN
MultiMessage Blockset
on page 161.
1.2
See RTI Electric Motor
Control Blockset
on page 165.
1.2
1.4
3.0
See RTI FPGA
Programming Blockset
on page 167.
2.5.1
See RTI LIN MultiMessage
Blockset on page 173.
2.2.1
1.2
1.0
3.3
See SCALEXIO Firmware
on page 175.
1.4.1
4.5
See SystemDesk
on page 177.
New Features and Migration
November 2015
s Product Version Overview t
Product
dSPACE Release
2014‑A
2014‑B
2015‑A
2015‑B
TargetLink/TargetLink Data
Dictionary
3.5
4.0
4.0
Variable Editor
VEOS
1.8
3.2
1.8
3.3
2.1
3.4
4.1
See TargetLink
on page 191.
2.2
3.5
See VEOS on page 247.
1)
Including the standard I/O blocksets.
Including the RTI Gigalink Blockset.
3) Supporting AUTOSAR 4.x
2)
If you have not updated regularly, refer to the New Features and
Migration documents for the dSPACE Releases listed above for
information about the new features and necessary migration steps.
New Features and Migration
November 2015
23
t
s Overview of dSPACE Release 2015‑B t
New Product Key Features
Objective
Information in this topic
This is an overview of each product's new key features. For more
details, refer to the product-specific sections.
AutomationDesk on page 24
ConfigurationDesk (Implementation Version) on page 25
Container management on page 25
ControlDesk Next Generation on page 25
DCI Configuration Tool on page 26
dSPACE FlexRay Configuration Package on page 27
dSPACE HIL API .NET on page 27
dSPACE XIL API on page 27
ECU Interface Manager on page 27
Firmware Manager on page 27
Model Compare on page 27
ModelDesk on page 28
MotionDesk on page 28
Python Extensions on page 28
Real-Time Testing on page 28
RTI, RTI-MP and RTLib on page 28
RTI Bypass Blockset on page 29
RTI CAN MultiMessage Blockset on page 29
RTI Electric Motor Control Blockset on page 29
RTI FPGA Programming Blockset on page 29
RTI LIN MultiMessage Blockset on page 30
SCALEXIO firmware on page 30
SystemDesk on page 30
TargetLink on page 30
VEOS on page 31
AutomationDesk
The new key features of AutomationDesk are:
n Enhancements to signal‑based testing, such as the new time tag
feature
n Enhancements to the AutomationDesk API
n Usability enhancements: e.g., new editors for specifying
expressions and conditions
n New Variable Browser supporting the enhanced trace file
generation
24
s
New Features and Migration
November 2015
s New Product Key Features t
n Enhanced Signal Generator support for the DS1007 PPC Processor
Board and MicroLabBox
For details on the new features, refer to New Features of
AutomationDesk 5.1 on page 49.
ConfigurationDesk
(Implementation Version)
The new key features of ConfigurationDesk are:
n Support of the Simulink Coder features concerning parameter
handling introduced with MATLAB R2014a
n Support of precompiled SIC files
For details on the new features, refer to ConfigurationDesk –
Implementation on page 90.
Container management
The new key feature of container management is:
n Improved assignment of elements to container files in
SystemDesk 4.5
For details on the new features, refer to New Features of Container
Management on page 97.
ControlDesk
Next Generation
The new key features of ControlDesk Next Generation
(ControlDesk 5.5) are:
n Platform/device enhancements:
n
n
n
Support of the new DCI‑CAN2 (including CAN FD support)
CAN Bus Monitoring device: Support for FIBEX and AUTOSAR
system description files
FlexRay Bus Monitoring device: Support for AUTOSAR system
description files
n
Further platforms that support automatic reconnect
n
Specifying the master for a simulation time group
n
Improvements to virtual validation scenarios
n Variable management enhancements:
n
New Variable Browser
n
Support of structs and struct arrays
n
Display of the original connection path
New Features and Migration
November 2015
25
t
s Overview of dSPACE Release 2015‑B t
n Instrument and visualization enhancements:
n
n
Customizing the connection assignment of variables to
instruments
Time Plotter and Index Plotter enhancements:
n
n
n
Saving Time Plotter data as a new measurement (Time
Plotter only)
Synchronization of the x‑axis
Multiswitch enhancement
n Measurement and recording enhancements:
n
ASAM MDF 4.x new default exchange format
n
Handling a large number of measurement rasters
n
Measurement Data API enhancements
n Data set management enhancement:
n
CDFX new default exchange format
n Bus Navigator enhancements:
n
Bus Instrument generation for Bus Manager configurations
n
CAN bus communication replay via MicroLabBox
n
CAN FD support for SCALEXIO and DCI‑CAN2
n
CAN Bus Monitoring device: Support for FIBEX and AUTOSAR
system description files
n Signal Editor enhancements:
n
Full support of the DS1007
n
Support of DS1202 MicroLabBox
n Electrical error simulation (failure simulation) enhancement:
n
New XIL API EESPort graphical user interface (successor to
ControlDesk's Failure Simulation Module)
n Automation enhancements:
n
n
Measuring and recording look-up tables (maps and curves)
Event when adding signals to or removing signals from the
measurement signal list
For details on the new features, refer to New Features of ControlDesk
Next Generation (ControlDesk 5.5) on page 100.
DCI Configuration Tool
The new key feature of the DCI Configuration Tool is:
n Improved A2L file adaptation
26
s
New Features and Migration
November 2015
s New Product Key Features t
For details on the new features, refer to New Features of the
DCI Configuration Tool 3.5 on page 123.
dSPACE FlexRay
Configuration Package
The new key features of the dSPACE FlexRay Configuration Tool are:
n Support of AUTOSAR System Template 4.2.1
n Support of opaque byte order format
For details on the new features, refer to New Features of dSPACE
FlexRay Configuration Package 3.6 on page 125.
dSPACE HIL API .NET
The new key features of dSPACE HIL API .NET are:
n Support of the enhanced trace file generation
n Enhanced stimulus support
For details on the new features, refer to dSPACE HIL API .NET
on page 127.
dSPACE XIL API
The new key features of dSPACE XIL API are:
n Support of the enhanced trace file generation
n Enhanced stimulus support
For details on the new features, refer to New Features of dSPACE XIL
API 2015‑B on page 133.
ECU Interface Manager
The new key features of the ECU Interface Manager are:
n Support of built-in dSPACE Calibration and Bypassing Service
configured for DPMEM plug-on devices (PODs)
n Specifying the behavior when execution control insertion fails
For details on the new features, refer to New Features of
ECU Interface Manager 1.7 on page 135.
Firmware Manager
The new key feature of the Firmware Manager is:
n Support of SCALEXIO systems
For details on the new feature, refer to New Features of Firmware
Manager 2.0 on page 139.
Model Compare
The new key features of Model Compare are:
n Hook mechanism that lets you control the creation of dump files
n Copying property values in the Property Inspector
n Model Compare Quick Guide which summarizes the most
important features
New Features and Migration
November 2015
27
t
s Overview of dSPACE Release 2015‑B t
For details on the new features, refer to New Features of Model
Compare 2.6 on page 141.
ModelDesk
The new key features of ModelDesk are:
n Support of new simulation platforms: DS1007 PPC Processor
Board and MicroLabBox
n Tool automation extended for processing and plotting
For details on the new features, refer to New Features of ModelDesk
4.2 on page 145.
MotionDesk
The new key features of MotionDesk are:
n New instrument feature: Instrument Panel
n New supported platform: MicroLabBox
n Instruments can be assigned to several observers
n Tool automation extended to handle observers
For details on the new features, refer to New Features of MotionDesk
3.7 on page 149.
Python Extensions
The new key features of dSPACE HIL API Python Implementation for
MAPort are:
n Support of the enhanced trace file generation
n Enhanced stimulus support
The new key features of matlablib2 are:
n New and enhanced methods and properties for MATLAB and
MATFile instances.
For details on the new features, refer to dSPACE Python Extensions
on page 129.
Real-Time Testing
The new key features of Real-Time Testing are:
n New supported platform: MicroLabBox
For details on the new features, refer to New Features of Real-Time
Testing 2.6 on page 151.
RTI, RTI-MP and RTLib
The new key features of RTI, RTI-MP and RTLib are:
n Support of the new Simulink Coder features introduced with
MATLAB R2015b, reflected by the enhanced trace file generation
28
s
New Features and Migration
November 2015
s New Product Key Features t
n Enhanced RTI support for MicroLabBox
n Support of nonvolatile data handling (NVDATA) for MicroLabBox
and DS1007
For details on the new features, refer to New Features of RTI/RTI-MP
and RTLib on page 153.
RTI Bypass Blockset
The new key features of the RTI Bypass Blockset are:
n Support of XCP 1.3
n CAN FD support
For details on the new features, refer to New Features of the RTI
Bypass Blockset 3.5 on page 157.
RTI CAN MultiMessage
Blockset
The new key features of the RTI CAN MultiMessage Blockset are:
n CAN FD support for SCALEXIO systems
n Support of ISO CAN FD protocol
n Sample points for the arbitration phase and data phase of CAN FD
messages
n Support of opaque byte order format
For details on the new features, refer to New Features of the RTI CAN
MultiMessage Blockset 4.2 on page 161.
RTI Electric Motor Control
Blockset
The new key feature of the RTI Electric Motor Control Blockset is:
n Support of EnDat interface‑based encoders for position
measurement
For details on the new features, refer to New Features of RTI Electric
Motor Control Blockset 1.2 on page 165.
RTI FPGA Programming
Blockset
The new key features of the RTI FPGA Programming Blockset are:
n Extended Xilinx® software support
n Enhancements to the FPGA framework for a DS2655 FPGA Base
Board
n New FPGA frameworks for the DS2655M2 Digital I/O Module.
n Enhancement to the FPGA frameworks for the DS2655M1 Multi-
I/O Module.
For details on the new features, refer to New Features of the RTI
FPGA Programming Blockset 3.0 on page 167.
New Features and Migration
November 2015
29
t
s Overview of dSPACE Release 2015‑B t
RTI LIN MultiMessage
Blockset
The new key feature of the RTI LIN MultiMessage Blockset is:
n Support of opaque byte order format
For details on the new features, refer to New Features of the RTI LIN
MultiMessage Blockset 2.5.1 on page 173.
SCALEXIO firmware
The new key features of the SCALEXIO firmware are:
n Support of the DS2655M2 Digital I/O Module
For details on the new features, refer to New Features of the
SCALEXIO Firmware 3.3 on page 175.
SystemDesk
The new key features of SystemDesk 4.5 are:
n Support of AUTOSAR 4.2.2, 4.2.1, 4.1.3, 4.1.2, 4.1.1, and 4.0.3.
n Improvements to SystemDesk's diagrams for graphical modeling
n Support for the basic software module description template
according to AUTOSAR
n Improved RTE generation
n Support for the NVRAM manager for virtual validation
n Variation binding of variant-rich models
For details on the new feature, refer to New General Features
on page 178.
TargetLink
The new key features of TargetLink are:
n AUTOSAR
n
Revision 4.2.1 support
n
NvData communication
n
Data transformation
n
Port-defined argument values
n
Activation reasons
n Improved function reuse now supports referenced models (with
multiple instances) and incremental subsystems
n FMU export of TargetLink subsystems to simulate the generated
production code in FMI-compliant tools
n Support for Simulink's simplified initialization mode, including
initial condition structures for buses
n Support for buses in Stateflow
30
s
New Features and Migration
November 2015
s New Product Key Features t
n Support for storing requirement information in the Data Dictionary
via DD RequirementInfo objects that can be referenced from
TargetLink blocks and Stateflow Chart objects
For details on all the new features, refer to New Features of
TargetLink 4.1 and TargetLink Data Dictionary 4.1 on page 192.
For details on the TargetLink migration aspects (TargetLink, TargetLink
AUTOSAR module, TargetLink Data Dictionary), refer to Migrating to
TargetLink 4.1 and TargetLink Data Dictionary 4.1 on page 218.
VEOS
The new key features of VEOS are:
n More intuitive user interface
n Enabling/disabling the generation of debug information (MSVC,
GCC)
n Accessing call stack information in case of an exception
For details on the new features, refer to VEOS on page 247.
New Features and Migration
November 2015
31
t
s Overview of dSPACE Release 2015‑B t
32
s
New Features and Migration
November 2015
Aspects of Migrating from
Previous Releases
Objective
After you install products of the current dSPACE Release, some
additional steps might be necessary. The migration steps required
when you come from the last dSPACE Release are described in the
product‑specific migration topics in this document. If you come from
an older dSPACE Release, refer to the related New Features and
Migration document.
Where to go from here
Information in this section
Migrating to dSPACE Release 2015‑B
33
Information in other sections
Changes to TRC File Generation
35
Migrating to dSPACE Release 2015‑B
Objective
After you install Release 2015‑B, some additional steps might be
necessary.
Migrating from dSPACE
Release 2015‑A
Product-specific migration steps Product-specific migration steps
are usually performed automatically by the products. For exceptions,
refer to the product-specific migration descriptions.
New Features and Migration
November 2015
33
t
s Aspects of Migrating from Previous Releases t
Migrating from dSPACE
Release 2014‑B or earlier
To migrate from dSPACE Release 2014‑B or earlier to Release 2015‑B,
you also have to perform the migration steps of the intervening
dSPACE Releases. All of the required migration steps can be
performed with Release 2015‑B installed.
For more details on the required migration steps, refer to the New
Features and Migration documents of the intervening dSPACE
Releases.
Previous release documents
The PDF files of previous releases are called
NewFeaturesAndMigrationxx.pdf, where xx stands for the release
number.
You can find the New Features and Migration files for previous
releases at the following locations:
n In the installation folder of the current dSPACE HelpDesk, refer to
C:\Program Files<(x86)>\Common Files\dSPACE\HelpDesk 2015‑B\P
rint\PreviousReleases.
n On the dSPACE DVDs, refer to \Doc\Print\PreviousReleases.
n Download them from www.dspace.com/go/migration. Here you
can also find New Features and Migration documents for very
early releases.
34
s
New Features and Migration
November 2015
Changes to TRC File Generation
Where to go from here
Information in this section
Basics on the TRC File Changes
35
Basics on the changes of the TRC file generation.
Migrating Changes in Software that Generates TRC Files
41
Information on required manual migration.
Migrating Changes in Software That Uses TRC Files
42
Information on required manual migration.
Basics on the TRC File Changes
Objective
The enhanced code generation leads to improvements for the
simulation behavior of the executable application. To profit from
these improvements in dSPACE software, the TRC file generation was
enhanced.
Enhancements in the
generated TRC file
With the MATLAB/Simulink R2014a release, the enhanced code
generation by Simulink® CoderTM was introduced to optimize the
simulation behavior. It provides a simpler behavior for tuning all
parameters and support for referenced models. Additional Simulink
Coder functions introduced with MATLAB R2015b now allow dSPACE
to fully support these new features via the enhanced TRC file
generation.
New Features and Migration
November 2015
35
t
s Changes to TRC File Generation t
The main advantages of the enhanced TRC file generation are:
n Same view on model parameters in MATLAB workspace and
TRC file
All tunable model parameters defined by MATLAB workspace
variables are available in the top‑level Tunable Parameters group
in the TRC file. This lets you access global parameters very quickly
and independently of the model hierarchy. Modifying the model
hierarchy later on will not affect the variable path already specified
for layout connections or test scripts.
n Working with MATLAB structures
If a MATLAB structure is tunable according to the Simulink Coder
rules, the structure levels and structure fields are generated into
the code.
This means:
n
n
n
Structured parameters are available in the TRC file
Non‑virtual Simulink buses are represented more efficiently in
the TRC file.
Bus arrays are available in the TRC file
n Higher performance
For non‑virtual Simulink buses, the performance of code
generation and compiling will be highly increased.
n More compact models by using tunable parameter expressions
Complex workarounds for modelling parameter expressions can
be simplified, for example, as shown in the model below. The
MATLAB workspace variables K and L are automatically generated
as tunable parameters.
n Handling of global parameters for Default parameter behavior =
Tunable or Inlined (formerly Inline Parameters option off and on)
36
s
New Features and Migration
November 2015
s Basics on the TRC File Changes t
The mapping between the configured tunable workspace variables
and Simulink.Parameter objects, and variables in the generated
code does not depend on the Default parameter behavior option
(formerly Inline Parameters option).
n Improved model referencing support
Simulink referenced models were restricted to using the Inline
Parameters option set to On (MATLAB R2015b: Default
parameter behavior set to Inlined). Now, the dSPACE toolchain
also supports the Default parameter behavior option set to
Tunable for referenced models when MATLAB R2015b is used.
n Support of Simulink mask parameters
Simulink mask parameters are now available in the TRC file and
can be accessed by dSPACE software, such as ControlDesk Next
Generation.
n Same behavior of Simulink simulation and simulations running on
dSPACE platforms
As a result of the above mentioned enhancements for consistent
parameter tuning, the behavior of a Simulink simulation and a
simulation on dSPACE platforms will be the same.
Support of Simulink Coder
enhancements
For the support of the coder enhancements in the generated TRC file,
MathWorks and dSPACE together developed additional build
functionality which was released with MATLAB R2015b. The resulting
additions of the TRC file syntax required complex modifications in all
the TRC file‑generating and TRC file‑consuming dSPACE products.
The full support of these enhancements is realized with dSPACE
Release 2015‑B used with MATLAB R2015b. If you use dSPACE
Release 2015‑B with an earlier MATLAB version, the code generation
mainly remains the same.
No migration is required, if you change the dSPACE Release but keep
the MATLAB Release.
New Features and Migration
November 2015
37
t
s Changes to TRC File Generation t
For an overview of the different behavior, refer to the following table:
dSPACE Release 2015-B used with MATLAB ...
R2014a
R2014b
R2015a
Same behavior of Simulink Coder code
generation and dSPACE TRC file generation
as with MATLAB R2013b and earlier.
Sharing the same parameter
variable across several blocks is
supported for block parameters
that are defined with an
unstructured MATLAB workspace
variable and without expressions.
All other block parameter
definitions have the previous
behavior.
The behavior must be enforced by executing Internal adaptions to the coder
the Simulink command
changes are automatically done.
revertInlineParametersOffToR2013b before
you use RTI or the Model Interface Package
for Simulink.
Using the Inline Parameters option set to Off for referenced models is not
supported.
1)
R2015b
Full support of
the above
mentioned
Simulink coder
features.
The standard
Simulink Coder
behavior is used.
Using the Inline
Parameters
option set to Off
for referenced
models is
supported.1)
With MATLAB R2015b the setting is similar to Default parameter behavior set to Tunable.
Details on the TRC file
changes introduced with
MATLAB R2015b
The following changes are done with dSPACE Release 2015‑B and
MATLAB R2015b.
Model Root group The entries in the Model Root group have
changed as follows:
n To improve performance and usability, entries for virtual Simulink
buses and muxed signals (e.g., Out1{SubArray1}), are no longer
generated into the variable description.
This also applies to the labels of these signals.
This is an incompatible change that requires manual migration,
refer to Migrating Changes in Software that Generates TRC Files
on page 41.
n Entries for non‑virtual Simulink buses are now generated as one
structured variable in the variable description, e.g., Out1{MyField}
has changed to Out1.MyField.
This also applies to the labels of non‑virtual Simulink buses.
38
s
New Features and Migration
November 2015
s Basics on the TRC File Changes t
This is an incompatible change that requires manual migration,
refer to Migrating Changes in Software that Generates TRC Files
on page 41.
n Simulink mask parameters are now generated into the variable
description at the entries of the related masked subsystems.
n Input signals of signal sink blocks are now generated into the
variable description also when you use ConfigurationDesk or VEOS
for the build process.
n The Include states and Include derivatives options are now also
available for ConfigurationDesk and VEOS.
Tunable Parameters group The entries in the Tunable Parameters
group have changed as follows:
n MATLAB workspace variables and Simulink.Parameter objects,
which are used as block parameters in the model, are now
generated as global variables in the Tunable Parameters group.
Internal optimizations during code generation might be the reason
that a variable will not be generated into the variable description.
If a block's parameter definition contains an expression, the local
block parameter is no longer available. This is an incompatible
change that requires manual migration, refer to Migrating
Changes in Software that Generates TRC Files on page 41.
n Structured workspace variables and Simulink.Parameter objects
that are used as block parameters in the model are now generated
as global structured parameters in the Tunable Parameters group.
The structure has to fulfill the Simulink Coder conditions for a
tunable structured parameter.
n Previously, each referenced model of a model referencing hierachy
had its own Tunable Parameters group. These groups are no
longer generated.
All global parameters referenced in the top‑level model or in the
referenced models are generated into the Tunable Parameters
group of the top‑level model.
This is an incompatible change that requires manual migration,
refer to Migrating Changes in Software that Generates TRC Files
on page 41.
Handling n‑D Lookup Tables With dSPACE Release 2015‑B
Lookup Table blocks with a dimension higher than 2, such as a 4x3x2
matrix, are no longer automatically divided into two‑dimensional
slices.
New Features and Migration
November 2015
39
t
s Changes to TRC File Generation t
This is an incompatible change that requires manual migration, refer
to Migrating Changes in Software that Generates TRC Files
on page 41.
Data Stores group To improve performance and data consistency
with other blocks, the Data Stores group is no longer generated into
the variable description.
This is an incompatible change that requires manual migration, refer
to Migrating Changes in Software that Generates TRC Files
on page 41.
Structured variables Structured variables, such as non‑virtual buses
or tunable structured parameters, are generated into the code and
represented in the variable description as a struct element. The
hierarchy of fields and members in a structured element is described
in dot notation, for example, myStruct.mySubstruct.myValue[0][1]..
References A variable description now contains block parameters as
references. The source of a reference can be a global parameter: e.g.,
a MATLAB workspace variable available in the Tunable Parameters
group, or a mask parameter. For structured parameters, the reference
can specify a field of a structure.
For the support of structures and references, the following
keywords have been added to the TRC file syntax:
n array‑incr
n offs
n struct
n endstruct
n refvar
n refgroup
n refelem
n DEPRECATED
If you have used one of these keywords as a variable name,
it is detected during the generation of the TRC file and not
added to the file. There might be definitions in user code
that you must check. Otherwise, there might be an error in
the software that uses the TRC file.
Up‑to‑date information
40
s
For further information on TRC file generation and the latest
migration instructions, refer to the dSPACE website:
http://www.dspace.com/go/trc.
New Features and Migration
November 2015
s Migrating Changes in Software that Generates TRC Files t
Migrating Changes in Software that Generates TRC Files
Objective
Despite the complex changes in the code generation, only a few
manual migrations are required. Most of the changes based on the
enhancements are automatically migrated by the dSPACE products.
Using MATLAB R2014a with
dSPACE Release 2015-B
The behavior of Simulink Coder code generation and dSPACE TRC file
generation is the same as with MATLAB R2013b and earlier. This
means that none of the Simulink Coder changes are available.
The support is based on the Simulink command
revertInlineParametersOffToR2013b that must be run before
generating code with RTI, or the Model Interface Package for
Simulink used with ConfigurationDesk and VEOS. You can run the
command either manually after MATLAB started, or by adding it as a
call in the startup.m or dsstartup.m scripts.
Using the Inline Parameters option set to Off for referenced models is
not supported.
Using MATLAB R2014b with
dSPACE Release 2015-B
There is no manual migration required. The variable description
contains further global parameters in the Tunable Parameters group
for unstructured workspace variables. These global parameters are
shared with the corresponding block parameters if the block
parameter is not defined with an expression. Writing a new value to
one of the global parameters changes the related block parameters
too.
Using the Inline Parameters option set to Off for referenced models is
not supported.
Using MATLAB R2015a with
dSPACE Release 2015-B
Same notes as with MATLAB R2014b.
Using MATLAB R2015b with
dSPACE Release 2015-B
If you use MATLAB R2015b, the new Simulink Coder features are
fully supported. The incompatible changes require migration steps
that are described below in general. Detailed instructions are not
given, because they depend on various conditions such as the
complexity of your model, the software you are using, and the
internal structure of your test scripts, for example. There are therefore
only some basic examples to show a general way to migrate.
For more details, refer to http://www.dspace.com/go/trc.
New Features and Migration
November 2015
41
t
s Changes to TRC File Generation t
Migration steps required in
TRC file generating
software
dSPACE products that generate TRC files such as RTI,
ConfigurationDesk or VEOS, support the new Simulink Coder
enhancements as is. There are only the following changes that might
require a manual migration to provide information in the variable
description.
Update assertion mode (only RTI) The rtiAssertionMode variable
is no longer generated into the variable description. The Assertion
mode setting on the RTI simulation options page is still available for
configuring the mode before you start the build process.
Update access to Data Stores group The Data Stores group is no
longer generated into the variable description. Instead of using Data
Store Memory blocks, you have to use Data Store Read blocks for
read access or the combination of Constant blocks with Data Store
Write blocks for write access. Instead of the entries in the Data Stores
group you then find entries of the Data Store Read blocks or the
Constant blocks in the Model Root group.
For this migration step, it is not required to use dSPACE Release
2015‑B. You can also do it with earlier dSPACE releases.
Migrating Changes in Software That Uses TRC Files
Objective
Products that use TRC files, such as ControlDesk Next Generation, use
the generated variable description to connect elements in the
software with variables in the simulation application. Most of the
variable path modifications caused by the TRC file changes can be
automatically migrated by the dSPACE products, but for some
changes you have to do manual migration in your software product.
Migration steps required in
TRC file consuming
software
If you have already used ControlDesk, AutomationDesk, or test scripts
of any kind that are accessing variables via their variable paths and
you rebuild the simulation application with MATLAB R2015b, you
have to check whether the variable paths have been discontinued or
changed in the variable description.
If you are using ControlDesk you get support for finding inconsistent
connections: for example, via specially marked instruments or the
Check Mapping command in the Signal Editor. In AutomationDesk,
variable access is realized via variable aliases. Therefore, modifications
in the variable description cannot be automatically recognized.
42
s
New Features and Migration
November 2015
s Migrating Changes in Software That Uses TRC Files t
However, if you are using a variable pool in your project, it is
sufficient to update this.
To graphically support the new TRC file features, such as structures
and references, ControlDesk and AutomationDesk provide the new
Variable Browser.
For the changes that were not able to be migrated automatically in
the software, you have to perform the following manual migration.
Issue
Migration Step
Update variable
paths of parameters
with expressions
Update any connections in ControlDesk or variables defined in test scripts that contain expressions with
MATLAB workspace variables, mask parameters, or Simulink Parameter objects.
Usually, it is not sufficient to change the variable path to the generated global parameter only to get the
required variable access for controlling. You also have to consider any element of the expression or the
resulting variable of the block.
Update variable
paths of virtual
Simulink buses
Update any connections in ControlDesk and test scripts accessing signals within a virtual Simulink bus to
directly accessed signal source blocks. As an alternative, you can add a Bus Selector block to your model
and then connect the block's output variables.
Update variable
paths of non‑virtual
Simulink buses
Update connections in ControlDesk and test scripts that access signals within a non‑virtual Simulink bus to
the corresponding field of the structured variable.
The formerly generated measurement arrays in the variable description are now represented by struct
elements.
The syntax of structured elements has changed from Out1{myField.mySubField} to
Out1.myField.mySubField.
This might conflict with variable names containing dots.
Update variable
paths of Tunable
Parameters groups
for referenced
models
Update any connections in ControlDesk or variables defined in test scripts that refer to tunable parameters
of referenced models. The variable path of such a variable must be changed to the top‑level Tunable
Parameters group.
Update access to
Data Stores group
Update any connections in ControlDesk and test scripts that refer to the variables of the discontinued
Data Stores group to the variables of the inserted Data Store Read or Write blocks in your model.
Update connections
to lookup tables
n ControlDesk does not recognize all the lookup tables in a TRC file. As a result, these lookup tables are
not available as maps or curves, for example, in ControlDesk's Variable Browser.
The recognition of lookup tables does not work in the following cases:
n The table data of the lookup table is contained in a structured parameter.
n The table data of the lookup table references mask parameters.
n The lookup table has three or more dimensions.
To update the connection to such a lookup table, connect the individual variables of the lookup table
in these cases.
n ControlDesk no longer provides a map or curve for the tableData parameter of a lookup table if the
tableData parameter was parameterized with numeric values.
To update the connection to such a parameter, connect the LookUpTableData variable of the lookup
table (instead of the tableData parameter).
New Features and Migration
November 2015
43
t
s Changes to TRC File Generation t
ControlDesk automatically migrates variable connections
after you rebuild a simulation application with MATLAB
R2015b and reload the application's variable description.
However, if you then reload the variable description of the
simulation application built with a MATLAB Release earlier
than R2014a, the migrated variable connections are lost,
and you have to update these connections manually.
For more details on TRC file changes, refer to Basics on the TRC File
Changes on page 35.
44
s
New Features and Migration
November 2015
Changes to the Python 2.7
Distribution
Objective
Gives you information on the changes in the Python distribution
provided by dSPACE.
If you want to migrate from an earlier version of Python to
Python 2.7, refer to the migration steps described in the New
Features and Migration document for dSPACE Release 2013‑B.
You can also find this information on the dSPACE website, refer to
http://www.dspace.com/go/Python27Migration.
Where to go from here
Information in this section
Main Changes in Python 2.7
45
Main Changes of the dSPACE Python Distribution
46
General Information on Using Python Installations
46
Enhancements to the Standard Python 2.7 Distribution
47
Main Changes in Python 2.7
Objective
Provides information on the changes in the Python 2.7 distribution
that comes with dSPACE Release 2015‑B.
New Features and Migration
November 2015
45
t
s Changes to the Python 2.7 Distribution t
What's New documentation
from the Python Software
Foundation
The What's New document for the updated Python version is
available from the Python Software Foundation:
n What's New for Python 2.7
http://docs.python.org/2.7/whatsnew/2.7.html
Main Changes of the dSPACE Python Distribution
Objective
The Python distribution provided by dSPACE contains some
dSPACE‑specific changes.
Components of the dSPACE
Python distribution
The Python 2.7 distribution on the dSPACE DVD provides the
following Python components.
Python Component
Version
Python core
PyWin32
Numpy
Matplotlib
WxPython
Py2exe
Comtypes
PIL
Python for .NET
2.7.9
219.10
1.7.1
1.2.1
2.9.4.0
0.6.9
0.6.2
1.1.7
2.0p3
General Information on Using Python Installations
Objective
The following information is relevant if you want to use both Python
versions on your computer.
Using Python 2.5 and
Python 2.7 in parallel
Both Python versions can be used in parallel on your computer, with
the following restrictions:
n The file associations for PY and PYW files can only be set to one
Python version. This is usually the latest installed Python version.
46
s
New Features and Migration
November 2015
s Enhancements to the Standard Python 2.7 Distribution t
n Environment variables are used by both Python versions. Their
values (e.g., for PYTHONHOME), must be set to the Python installation
you want to work with. For an overview of the environment
variables set by Python, refer to
http://docs.python.org/2/using/cmdline.html.
Using dSPACE test
automation with both
Python versions in parallel
If your test automation scripts use dSPACE Python modules
distributed either via the dSPACE Python 2.5 setup or via the dSPACE
Python Extensions setup available up to dSPACE Release 2013‑A, and
you do not want to migrate your scripts, you have to work with both
Python versions.
Enhancements to the Standard Python 2.7 Distribution
Objective
There are some dSPACE‑specific enhancements to the standard
Python 2.7. These either ensure the same behavior as before or solve
known bugs. The following enhancements are available with dSPACE
Release 2015‑B.
Enhancements to solve
known Python bugs
The following changes have been made to solve a known bug from
Python 2.7:
n Changes to the PyWin32 package from the former versions were
adopted.
n The Python for .NET package was fixed to run with .NET 4.5.2.
n The Python for .NET package was fixed to run with WPF user
interfaces.
For the latest information on bugs in Python 2.7 and their solutions,
refer to http://bugs.python.org.
To identify the PyWin32 files changed by dSPACE, the
version number of the files was changed from 219.0 to
219.10.
New Features and Migration
November 2015
47
t
s Changes to the Python 2.7 Distribution t
48
s
New Features and Migration
November 2015
AutomationDesk
New Features of AutomationDesk 5.1
Information in this topic
General enhancements on page 49
Enhanced user interface on page 49
Support of the enhanced trace file generation on page 50
Enhancements to the libraries on page 50
Dialogs library on page 50
Signal-Based Testing library on page 51
XIL API library on page 50
Enhancements to the COM API on page 51
Discontinuations for future versions on page 51
General enhancements
Enhanced user interface The following user interface
enhancements facilitate working with AutomationDesk:
n The new Expression Editor is used to specify conditions according
to the ASAM General Expression Syntax (GES): e.g., trigger
conditions for capture tasks defined with the XIL API library.
n The Condition Editor has been updated to the same look&feel of
the new Expression Editor.
n The Signal Editor comes with some enhancements:
n
New Time Tag feature to graphically specify logical time tags.
These tags can then be connected to segments for configuring
trigger conditions.
n
Properties of the Signal Editor have been updated.
n
Inherited properties are displayed in a different color.
New Features and Migration
November 2015
49
t
s AutomationDesk t
n
n
The commands of the editor are now provided by a separate
ribbon.
Undo and Redo actions are supported by the editor.
n The Library Favorites Viewer comes with some enhancements:
n
n
n
You can now add an entire library folder with its contained
blocks and data objects to the favorites list.
You can import and export the favorites in XML format.
Favorites that refer to elements and that are not available in
the Library Browser are now detected and displayed by another
icon and in red text.
n You can now open a custom library by dragging its related ADL
file from a file explorer to the Library Browser.
Support of the enhanced trace file generation AutomationDesk
libraries that access a simulation application via a variable description
support the new features coming with the enhanced trace file
generation. For more details, refer to Changes to TRC File Generation
on page 35. The Variable Browser used o parameterize the Platform
data object and the MAPortConfiguration data object has been
updated to support the new TRC file features.
Enhancements to the
libraries
The following libraries have been enhanced:
Dialogs library The library supports the following new methods
that you can use in an Exec block:
n EnterGESExpression
To open the Expression Editor.
n EnterPythonExpression
To open the Condition Editor.
For further information, refer to Dialogs (
Reference).
AutomationDesk Library
XIL API library The XIL API library now provides the Mapping data
object. It can be used to provide the variables in your simulation
application in XIL API‑based format. The XIL API mapping contains the
variable name as an abstract identifier and the variable path as the
concrete identifier (Alias). To create a XIL API mapping file, you can
use the new Mapping Editor, which you can execute from the
context menu of the new Mapping Viewer that opens when you
double‑click a Mapping data object.
50
s
New Features and Migration
November 2015
s New Features of AutomationDesk 5.1 t
There are the following enhancements to stimulus generation using
the XIL API SignalGenerator elements:
n Support of MicroLabBox
n If you use a multicore or multiprocessor application on a DS1007
PPC Processor Board, model variables can now be stimulated on
each connected application processor.
For more details, refer to XIL API (
Reference).
AutomationDesk Library
Signal-Based Testing library The implementation blocks of the
Signal‑Based Testing library have been internally enhanced to support
the new time tag feature of the Signal Editor.
For more details, refer to Signal-Based Testing Library
( AutomationDesk Library Reference).
Enhancements to the
COM API
The AutomationDesk COM API provides the following enhancement:
n New methods to import and export library favorites.
n New method to import a XIL API mapping to a Mapping data
object.
For more details, refer to
Discontinuations for future
versions
AutomationDesk API Reference.
The following libraries, automation blocks and data objects will be
discontinued in future versions of AutomationDesk:
n Test Framework library
You should migrate your projects based on the Test Framework
library to the Test Builder library. For migration help, refer to
http://www.dspace.com/go/TestBuilderMigration.
n Platform Access library
The Platform Access library is delivered for the last time with
dSPACE Release 2016‑A. You should migrate your projects based
on the Platform Access library to the XIL API library or to the XIL
API Convenience library. This provides the MAPort for reading,
writing and stimulating variables of a connected platform.
For migration help, refer to http://www.dspace.com/go/pscta.
n Failure simulation automation blocks in the ControlDeskNG Access
library
New Features and Migration
November 2015
51
t
s AutomationDesk t
ControlDesk's Failure Simulation Module is delivered for the last
time with dSPACE Release 2016‑A. To prepare electrical error
simulation via automation, use the Electrical Error Simulation Port
(EESPort) in the XIL API library or in the XIL API Convenience library
instead of the failure simulation blocks in the ControlDeskNG
Access library.
For migration help, refer to http://www.dspace.com/go/pscta.
n InitCaptureResultIDFReader and InitCaptureResultIDFWriter
automation blocks in the XIL API library
The InitCaptureResultIDFReader and InitCaptureResultIDFWriter
automation blocks are delivered for the last time with dSPACE
Release 2016‑A. Because the IDF format will be discontinued in
future versions, you should replace these automation blocks with
the CaptureResultReader and CaptureResultWriter data objects
which support the MDF format. For more details, refer to
CaptureResultReader (Data Object) ( AutomationDesk Library
Reference) and CaptureResultWriter (Data Object)
( AutomationDesk Library Reference).
The elements that are planned to be discontinued are specially
marked in the Library Browser.
52
s
New Features and Migration
November 2015
Automotive Simulation Models
(ASM)
Where to go from here
Information in this section
ASM Base InCylinder Blockset
54
ASM Diesel Engine Blockset
55
ASM Diesel Exhaust Blockset
59
ASM Diesel InCylinder Blockset
60
ASM Drivetrain Basic Blockset
62
ASM Electric Components Blockset
63
ASM Environment Blockset
66
ASM Gasoline Engine Basic Blockset
67
ASM Gasoline Engine Blockset
70
ASM Gasoline InCylinder Blockset
74
ASM Optimizer
76
ASM Traffic Blockset
78
ASM Trailer Blockset
80
ASM Truck Blockset
82
ASM Turbocharger Blockset
84
ASM Vehicle Dynamics Blockset
87
Information in other sections
Migrating ASM Models (
ASM User Guide)
Provides general information on the migration of ASM models.
New Features and Migration
November 2015
53
t
s Automotive Simulation Models (ASM) t
ASM Base InCylinder Blockset
Where to go from here
Information in this section
New Features of ASM Base InCylinder Blockset 2.1
54
Migrating to ASM Base InCylinder Blockset 2.1
54
New Features of ASM Base InCylinder Blockset 2.1
ENGINE_SETUP
The ENGINE_SETUP block now has additional switches for
parameterization with ModelDesk:
n Const_max_num_PortInjector_PressureDrop
n Sw_Turbo_Stage[1SingleStage|2TwoStage]
n Sw_Turbo_Model [1phys|2LUT]
n Sw_ExhMan [1phys|2simple|3LUT]
n Sw_InMan[1phys|2LUT]
Until now, these were parameterized by the CPT structure.
The Sw_Turbo_Model_[1phys|2LUT] and
Sw_Turbo_Stage_[1SingleStage|2TwoStage] outports are new.
These changes have an effect in the engine model if the turbocharger
model contains the Turbo_Adv model and/or the Turbo_2Stage
model.
Migrating to ASM Base InCylinder Blockset 2.1
ENGINE_SETUP
54
s
The new parameters and inputs are set to dummy values. In migrated
models, the original CPT variables are still used for the switches.
New Features and Migration
November 2015
s ASM Diesel Engine Blockset t
ASM Diesel Engine Blockset
Where to go from here
Information in this section
New Features of ASM Diesel Engine Blockset 2.2
55
Migrating to ASM Diesel Engine Blockset 2.2
57
New Features of ASM Diesel Engine Blockset 2.2
Model start script go.m file
The standard start script go.m file for the ASM demo models has
been adapted in order to take the changes of the supported
simulation platforms into account.
The revised go.m file now contains the following platform options:
n 'RTI': DS1005, DS1006, DS1007, MicroLabBox
n 'SCALEXIO': SCALEXIO hardware
n 'VEOS': VEOS (offline simulation platform)
For more information on the calling procedures of the go.m file, refer
to the corresponding file header or Model Initialization ( ASM User
Guide).
The start script go.m file also takes the changes to the VEOS target
into account. With Release 2015-B, VEOS uses the DSRT target
instead of the DSOffSim target (refer to Migrating to VEOS 3.5
on page 250). The go.m file in the ASM demo projects has been
adapted to trigger the correct compiler settings.
ENGINE_SETUP
The ENGINE_SETUP block now has additional switches for
parameterization with ModelDesk:
n Const_max_num_PortInjector_PressureDrop
n Sw_Turbo_Stage[1SingleStage|2TwoStage]
n Sw_Turbo_Model [1phys|2LUT]
Until now, this parameterization was done by the SWITCHES_TURBO
block.
New Features and Migration
November 2015
55
t
s Automotive Simulation Models (ASM) t
The Sw_Turbo_Model_[1phys|2LUT] and
Sw_Turbo_Stage_[1SingleStage|2TwoStage] outports are new. These
changes have an effect in the engine model if the turbocharger
model contains the Turbo_Adv model and/or the Turbo_2Stage
model.
The turbo model can now be switched from the ModelDesk Engine
Setup page if the turbocharger model included in the engine model
contains the components.
COMMON_ENGINE_
PARAMETERS
The Const_kappa_Fuel parameter has been added for calculations
with gaseous fuel.
For this, the block has been expanded by the corresponding outports:
n kappa_Fuel[]
n cv_Fuel[J|[kgK]]
n cp_Fuel[J|[kgK]]
INJECTOR
The block has been fixed for use with 20 cylinders. There was a bug
assigning the injection to cylinder 19 instead of to cylinder 20, where
it was supposed to be.
UNIT_INJECTOR
The block has been fixed for use with 20 cylinders. There was a bug
assigning the injection to cylinder 19 instead of to cylinder 20, where
it was supposed to be.
PORTINJECTOR_TIMING
The block can now calculate a higher injection time to account for a
lower fuel quantity if the pressure difference between the injector
fuel supply and the intake manifold is too low.
The Map_mdot_Fuel_Gain_Red parameter has been added. Two new
inports for fuel pressure difference calculation have been created:
p_InMan[Pa] and p_Fuel[Pa].
The PORTINJECTOR_TIMING block can be used with multiple air
intake engine setups, such as V-engines. The Map_Inj2Cyl and
Const_max_num_PortInjector_PressureDrop parameters are used to
assign the intake manifold, injection and cylinder.
Test cycles
The Ftp_75 test cycle has been updated with an engine switch-off
phase. After a total duration of 1369 seconds, the engine is switched
off for 10 minutes. This is then followed by a warm engine restart.
Moreover, the new test cycles WLTC (Worldwide Harmonized Light
Vehicle Test Procedure) with three classes (depending on the powerto-mass ratio) have been implemented. The new test cycles can be
found in the test cycles folder of the new engine demos.
56
s
New Features and Migration
November 2015
s ASM Diesel Engine Blockset t
Migrating to ASM Diesel Engine Blockset 2.2
RAIL_CONTROL_
CRANKBASED
The Const_disable_FMU_q_Inj, Const_enable_FMU_n_Engine, and
Const_enable_FMU_q_Inj parameters have been removed, as these
thresholds have no functional influence anymore. The change has no
functional effect on the model behavior.
The Map_eta_DeltaAngle parameter has been renamed to
Map_phi_FMU_energized. The change has no functional effect on
the model behavior.
The Map_phi_FMU_FF parameter has been added in order to improve
the control strategy by means of a feedforward table.
The Sw_phi_FMU_Update parameter has been added in order to
improve the pulsed control mode with a defined pump angle update
of the control variable within a pump cycle.
The Map_ValveDelay parameter has been added in order to account
for delays in the valve actuation.
The inactive elements in the phi_FMU_energized output vector are
now replaced by 999, in parallel to the I/O behavior. A crank angle of
999 will be interpreted as invalid in the high pressure pump plant
model. Consequently, the corresponding pump cycle will not deliver
any fuel to the high pressure rail.
DPF_REGENERATION
A data type conversion block has been inserted in order to account
for data type consistency checks in MATLAB/Simulink. The change has
no functional effect and just prevents warnings in MATLAB during
Update diagram.
HPP_CRANKBASED
The block has been modified to also account for negative TDC offset
definitions.
In order to take pump cycles without FMU actuation into account, the
vector containing the FMU actuation information will now be
reordered. Based on that, the pump block will consider only the
actuation signals that belong to the current pump cycle.
ENGINE_SETUP
The block's parameters will be initialized with dummy values. The
new outports will be terminated.
COMMON_ENGINE_
PARAMETERS
The parameters will be initialized with dummy values. The new
outports will be terminated.
New Features and Migration
November 2015
57
t
s Automotive Simulation Models (ASM) t
INJECTOR
The block has been fixed for use with 20 cylinders. The injection that
is supposed to be in cylinder 20 will now be correctly assigned to
cylinder 20.
UNIT_INJECTOR
The block has been fixed for use with 20 cylinders. The injection that
is supposed to be in cylinder 20 will now be correctly assigned to
cylinder 20.
58
s
New Features and Migration
November 2015
s ASM Diesel Exhaust Blockset t
ASM Diesel Exhaust Blockset
Migrating to ASM Diesel Exhaust Blockset 2.1.1
DIESEL_OXIDATION_
CATALYST
The PT1 term has been moved to apply a delay on not only the
pressure drop information but also the output pressure. This
modification affects the simulation behavior. Hence, during
migration, the link is changed to a former version of the block.
New Features and Migration
November 2015
59
t
s Automotive Simulation Models (ASM) t
ASM Diesel InCylinder Blockset
Where to go from here
Information in this section
New Features of ASM Diesel InCylinder Blockset 2.1
60
Migrating to ASM Diesel InCylinder Blockset 2.1
61
New Features of ASM Diesel InCylinder Blockset 2.1
Model start script go.m file
The standard start script go.m file for the ASM demo models has
been adapted in order to take the changes of the supported
simulation platforms into account.
The revised go.m file now contains the following platform options:
n 'RTI': DS1005, DS1006, DS1007, MicroLabBox
n 'SCALEXIO': SCALEXIO hardware
n 'VEOS': VEOS (offline simulation platform)
For more information on the calling procedures of the go.m file, refer
to the corresponding file header or Model Initialization ( ASM User
Guide).
The start script go.m file also takes the changes to the VEOS target
into account. With Release 2015-B, VEOS uses the DSRT target
instead of the DSOffSim target (refer to Migrating to VEOS 3.5
on page 250). The go.m file in the ASM demo projects has been
adapted to trigger the correct compiler settings.
Test cycles
The Ftp_75 test cycle has been updated with an engine switch-off
phase. After a total duration of 1369 seconds, the engine is switched
off for 10 minutes. This is then followed by a warm engine restart.
Moreover, the new test cycles WLTC (Worldwide Harmonized Light
Vehicle Test Procedure) with three classes (depending on the powerto-mass ratio) have been implemented. The new test cycles can be
found in the test cycles folder of the new engine demos.
60
s
New Features and Migration
November 2015
s ASM Diesel InCylinder Blockset t
Migrating to ASM Diesel InCylinder Blockset 2.1
DPF_REGENERATION
A data type conversion block has been inserted in order to account
for data type consistency checks in MATLAB/Simulink. The change has
no functional effect.
New Features and Migration
November 2015
61
t
s Automotive Simulation Models (ASM) t
ASM Drivetrain Basic Blockset
Where to go from here
Information in this section
New Features of ASM Drivetrain Basic Blockset 4.1.1
62
Migrating to ASM Drivetrain Basic Blockset 4.1.1
62
New Features of ASM Drivetrain Basic Blockset 4.1.1
CYCLES
The CYCLES block now accepts the definitions of test cycles with an
engine switch-off phase. The engine can now be switched off and
restarted during the test to test a warm restart. In the test cycle
definition file a new variable (Sw_Engine) can be added. This variable
has a value of 0 to switch the engine off and 1 to switch it on.
For an example, refer to the Ftp_75 test cycle in the new Engine
demo models. A lower engine speed is also implemented as a new
parameter to prevent the test bench from switching the engine off
during the execution of a dynamometer test cycle.
Migrating to ASM Drivetrain Basic Blockset 4.1.1
CYCLES
62
s
During migration, the new Const_n_Engine_Min parameter for the
lower engine speed is added. This parameter will have a default value
of 0 to keep the old behavior unchanged.
New Features and Migration
November 2015
s ASM Electric Components Blockset t
ASM Electric Components Blockset
Where to go from here
Information in this section
New Features of ASM Electric Components Blockset 3.1
63
Migrating to ASM Electric Components Blockset 3.1
64
New Features of ASM Electric Components Blockset 3.1
Model start script go.m file
The standard start script go.m file for the ASM demo models has
been adapted in order to take the changes of the supported
simulation platforms into account.
The revised go.m file now contains the following platform options:
n 'RTI': DS1005, DS1006, DS1007, MicroLabBox
n 'SCALEXIO': SCALEXIO hardware
n 'VEOS': VEOS (offline simulation platform)
For more information on the calling procedures of the go.m file, refer
to the corresponding file header or Model Initialization ( ASM User
Guide).
The start script go.m file also takes the changes to the VEOS target
into account. With Release 2015-B, VEOS uses the DSRT target
instead of the DSOffSim target (refer to Migrating to VEOS 3.5
on page 250). The go.m file in the ASM demo projects has been
adapted to trigger the correct compiler settings.
ALTERNATOR
The block has a new outport for the execution current: I_Excitation.
ASM_EC_STARDELTA
This block is new. It is used for current (or voltage) conversion from
three-phase supply variables to three-phase machine variables, and in
the other direction.
PMSM_D_Q_NONLINEAR
A new parameter has been added to switch the machine
configuration. The machine can now be modeled in either a star or a
delta configuration.
New Features and Migration
November 2015
63
t
s Automotive Simulation Models (ASM) t
PMSM_MAGNET_
SYNCHRONOUS_
MACHINE_D_Q
A new parameter has been added to switch the machine
configuration. The machine can now be modeled in either a star or a
delta configuration.
SQUIRREL_CAGE_
ASYNCHRONOUS_
MACHINE_D_Q
A new parameter has been added to switch the machine
configuration. The machine can now be modeled in either a star or a
delta configuration.
PMSM_CONTROLLER
A new parameter has been added to control the machine according
to its configuration.
PMSM_CONTROLLER_
THREE_LEVEL
A new parameter has been added to control the machine according
to its configuration.
SCIM_CONTROLLER
A new parameter has been added to control the machine according
to its configuration.
Migrating to ASM Electric Components Blockset 3.1
SOFT_ECU_HYBRID_
MANAGER
The block is split in the subcomponent blocks BRAKE_CONTROL,
DRIVE_MANAGEMENT, TRQ_REQUEST_COORDINATION,
KEY_SIGNALS_ICE, STARTER_ICE, CLUTCH_CONTROL and
HYBRID_VEHICLE_SWITCH. The change has no functional effect but it
lets you to modify the SoftECU Hybrid Manager easier.
Renamed inports and
outports
There are changes in the names of inports and outports:
n v_Stator[a;b;c][V] is renamed to v[a;b;c][V]
n i_Stator[a;b;c][V] to i[a;b;c][V]
This applies to the following blocks:
n PMSM_D_Q_NONLINEAR
n BRUSHLESS_DC_MACHINE_ALPHA_BETA
n PMSM_MAGNET_SYNCHRONOUS_MACHINE_D_Q
n SQUIRREL_CAGE_ASYNCHRONOUS_MACHINE_D_Q
n PMSM_CONTROLLER
n PMSM_CONTROLLER_BASIC
n PMSM_CONTROLLER_THREE_LEVEL
n SCIM_CONTROLLER
64
s
New Features and Migration
November 2015
s ASM Electric Components Blockset t
n SCIM_CONTROLLER_BASIC
n THREE_PHASE_INVERTER
n THREE_LEVEL_THREE_PHASE_INVERTER
n THREE_PHASE_DCM_INVERTER
Renamed inports
The v_Stator[a;b;c][V] inport is renamed to v[a;b;c][V].
This applies to the following blocks:
n SPACE_VECTOR_MODULATOR
n THREE_LEVEL_SPACE_ VECTOR_MODULATOR
The i_Stator[a;b;c][V] inport is renamed to i[a;b;c][V].
This applies to the following blocks:
n BLDC_CONTROLLER
n BLDC_CONTROLLER_BASIC
New Features and Migration
November 2015
65
t
s Automotive Simulation Models (ASM) t
ASM Environment Blockset
Where to go from here
Information in this section
New Features of ASM Environment Blockset 4.3
66
Migrating to ASM Environment Blockset 4.3
66
New Features of ASM Environment Blockset 4.3
LATERAL_CONTROL1/
LATERAL_CONTROL2
The steering wheel angle will be reset at a global reset.
Migrating to ASM Environment Blockset 4.3
LATERAL_CONTROL1/
LATERAL_CONTROL2
The steering wheel angle will be reset at a global reset.
ROAD
The distance calculations are executed for a dynamic number of
traffic objects. Thus, the corresponding Simulink ports of the ROAD
block have a dynamically sized width.
There are changes due to Simulink diagnostics.
BASIC_ROAD
There are changes due to Simulink diagnostics.
MANEUVER_SCHEDULER
There are changes due to Simulink diagnostics.
GEAR_SHIFTER
The bevahior after reset has been corrected.
66
s
New Features and Migration
November 2015
s ASM Gasoline Engine Basic Blockset t
ASM Gasoline Engine Basic Blockset
Where to go from here
Information in this section
New Features of ASM Gasoline Engine Basic Blockset
2.0.2
67
Migrating to ASM Gasoline Engine Basic Blockset 2.0.2
68
New Features of ASM Gasoline Engine Basic Blockset 2.0.2
Model start script go.m file
The standard start script go.m file for the ASM demo models has
been adapted in order to take the changes of the supported
simulation platforms into account.
The revised go.m file now contains the following platform options:
n 'RTI': DS1005, DS1006, DS1007, MicroLabBox
n 'SCALEXIO': SCALEXIO hardware
n 'VEOS': VEOS (offline simulation platform)
For more information on the calling procedures of the go.m file, refer
to the corresponding file header or Model Initialization ( ASM User
Guide).
The start script go.m file also takes the changes to the VEOS target
into account. With Release 2015-B, VEOS uses the DSRT target
instead of the DSOffSim target (refer to Migrating to VEOS 3.5
on page 250). The go.m file in the ASM demo projects has been
adapted to trigger the correct compiler settings.
WALL_FILM
The Reset inport to this block had no effect and was fixed to work
correctly.
PORTINJECTOR
The block can now calculate a lower fuel quantity if the pressure
difference between the fuel supply and the intake manifold is low.
This is used in compressed natural gas engines.
The Map_mdot_Fuel_Gain_Red parameter has been added. Two new
inports for fuel pressure difference calculation have been created:
p_InMan[Pa] and p_Fuel[Pa].
New Features and Migration
November 2015
67
t
s Automotive Simulation Models (ASM) t
COMMON_ENGINE_
PARAMETERS
The Const_kappa_Fuel parameter has been added for calculations
with gaseous fuel.
For this, the block has been expanded by the corresponding outports:
n kappa_Fuel[]
n cv_Fuel[J|[kgK]]
n cp_Fuel[J|[kgK]]
PORTINJECTOR_TIMING
The block can now calculate a higher injection time to account for a
lower fuel quantity if the pressure difference between the injector
fuel supply and the intake manifold is too low.
The Map_mdot_Fuel_Gain_Red parameter has been added. Two new
inports for fuel pressure difference calculation have been created:
p_InMan[Pa] and p_Fuel[Pa].
The PORTINJECTOR_TIMING block can be used with multiple air
intake engine setups, such as V-engines. The Map_Inj2Cyl and
Const_max_num_PortInjector_PressureDrop parameters are used to
assign the intake manifold, injection and cylinder.
Test cycles
The Ftp_75 test cycle has been updated with an engine switch-off
phase. After a total duration of 1369 seconds, the engine is switched
off for 10 minutes. This is then followed by a warm engine restart.
Moreover, the new test cycles WLTC (Worldwide Harmonized Light
Vehicle Test Procedure) with three classes (depending on the powerto-mass ratio) have been implemented. The new test cycles can be
found in the test cycles folder of the new engine demos.
Migrating to ASM Gasoline Engine Basic Blockset 2.0.2
WALL_FILM
The reset will now work as intended.
PORTINJECTOR
The new parameters and inputs will be set up so that the new
functionality has no effect.
ENGINE_SETUP
The parameters will be initialized with dummy values. The new
outports will be terminated.
68
s
New Features and Migration
November 2015
s ASM Gasoline Engine Basic Blockset t
COMMON_ENGINE_
PARAMETERS
The parameters will be initialized with dummy values. The new
outports will be terminated.
PORTINJECTOR_TIMING
The new parameters and inputs will be set up so that the new
functionality has no effect.
New Features and Migration
November 2015
69
t
s Automotive Simulation Models (ASM) t
ASM Gasoline Engine Blockset
Where to go from here
Information in this section
New Features of ASM Gasoline Engine Blockset 3.2
70
Migrating to ASM Gasoline EngineBlockset 3.2
72
New Features of ASM Gasoline Engine Blockset 3.2
Model start script go.m file
The standard start script go.m file for the ASM demo models has
been adapted in order to take the changes of the supported
simulation platforms into account.
The revised go.m file now contains the following platform options:
n 'RTI': DS1005, DS1006, DS1007, MicroLabBox
n 'SCALEXIO': SCALEXIO hardware
n 'VEOS': VEOS (offline simulation platform)
For more information on the calling procedures of the go.m file, refer
to the corresponding file header or Model Initialization ( ASM User
Guide).
The start script go.m file also takes the changes to the VEOS target
into account. With Release 2015-B, VEOS uses the DSRT target
instead of the DSOffSim target (refer to Migrating to VEOS 3.5
on page 250). The go.m file in the ASM demo projects has been
adapted to trigger the correct compiler settings.
WALL_FILM
The Reset inport to this block had no effect and was fixed to work
correctly.
PORTINJECTOR
The block can now calculate a lower fuel quantity if the pressure
difference between the fuel supply and the intake manifold is low.
This is used in compressed natural gas engines.
The Map_mdot_Fuel_Gain_Red parameter has been added. Two new
inports for fuel pressure difference calculation have been created:
p_InMan[Pa] and p_Fuel[Pa].
70
s
New Features and Migration
November 2015
s ASM Gasoline Engine Blockset t
DIRECTINJECTOR
The block has been fixed for use with 20 cylinders. There was a bug
assigning the injection supposed to be in cylinder 20 to cylinder 19.
ENGINE_SETUP
The ENGINE_SETUP block now has additional switches for
parameterization with ModelDesk:
n Const_max_num_PortInjector_PressureDrop
n Sw_Turbo_Stage[1SingleStage|2TwoStage]
n Sw_Turbo_Model [1phys|2LUT]
Until now, this parameterization was done by the SWITCHES_TURBO
block.
The Sw_Turbo_Model_[1phys|2LUT] and
Sw_Turbo_Stage_[1SingleStage|2TwoStage] outports are new. These
changes have an effect in the engine model if the turbocharger
model contains the Turbo_Adv model and/or the Turbo_2Stage
model.
The turbo model can now be switched from the ModelDesk Engine
Setup page if the turbocharger model included in the engine model
contains the components.
COMMON_ENGINE_
PARAMETERS
The Const_kappa_Fuel parameter has been added for calculations
with gaseous fuel.
For this, the block has been expanded by the corresponding outports:
n kappa_Fuel[]
n cv_Fuel[J|[kgK]]
n cp_Fuel[J|[kgK]]
PORTINJECTOR_TIMING
The block can now calculate a higher injection time to account for a
lower fuel quantity if the pressure difference between the injector
fuel supply and the intake manifold is too low.
The Map_mdot_Fuel_Gain_Red parameter has been added. Two new
inports for fuel pressure difference calculation have been created:
p_InMan[Pa] and p_Fuel[Pa].
The PORTINJECTOR_TIMING block can be used with multiple air
intake engine setups, such as V-engines. The Map_Inj2Cyl and
Const_max_num_PortInjector_PressureDrop parameters are used to
assign the intake manifold, injection and cylinder.
New Features and Migration
November 2015
71
t
s Automotive Simulation Models (ASM) t
New blocks
The following blocks are new:
n CNG_PRESSURE_REGULATOR
n CNG_SHUTOFF_VALVE
n CNG_HIGH_PRESSURE_LINE
n CNG_TANK
n CNG_RAIL
Test cycles
The Ftp_75 test cycle has been updated with an engine switch-off
phase. After a total duration of 1369 seconds, the engine is switched
off for 10 minutes. This is then followed by a warm engine restart.
Moreover, the new test cycles WLTC (Worldwide Harmonized Light
Vehicle Test Procedure) with three classes (depending on the powerto-mass ratio) have been implemented. The new test cycles can be
found in the test cycles folder of the new engine demos.
Migrating to ASM Gasoline EngineBlockset 3.2
RAIL_CONTROL_
CRANKBASED
The Const_disable_FMU_q_Inj, Const_enable_FMU_n_Engine, and
Const_enable_FMU_q_Inj parameters have been removed, as these
thresholds have no functional influence anymore. The change has no
functional effect on the model behavior.
The Map_eta_DeltaAngle parameter has been renamed to
Map_phi_FMU_energized. The change has no functional effect on
the model behavior.
The Map_phi_FMU_FF parameter has been added in order to improve
the control strategy by means of a feedforward table.
The Sw_phi_FMU_Update parameter has been added in order to
improve the pulsed control mode with a defined pump angle update
of the control variable within a pump cycle.
The Map_ValveDelay parameter has been added in order to account
for delays in the valve actuation.
The inactive elements in the phi_FMU_energized output vector are
now replaced by 999, in parallel to the I/O behavior. A crank angle of
999 will be interpreted as invalid in the high pressure pump plant
model. Consequently, the corresponding pump cycle will not deliver
any fuel to the high pressure rail.
72
s
New Features and Migration
November 2015
s ASM Gasoline Engine Blockset t
HPP_CRANKBASED
The block has been modified to also account for negative TDC offset
definitions.
In order to take pump cycles without FMU actuation into account, the
vector containing the FMU actuation information will now be
reordered. Based on that, the pump block will consider only the
actuation signals that belong to the current pump cycle.
PORTINJECTOR_TIMING
The new parameters and inputs will be set up so that the new
functionality has no effect.
PORTINJECTOR
The new parameters and inputs will be set up so that the new
functionality has no effect.
Related topics
Basics
• Migrating ASM Models (
ASM User Guide)
New Features and Migration
November 2015
73
t
s Automotive Simulation Models (ASM) t
ASM Gasoline InCylinder Blockset
Where to go from here
Information in this section
New Features of ASM Gasoline InCylinder Blockset 2.1
74
Migrating to ASM Gasoline InCylinder Blockset 2.1
75
New Features of ASM Gasoline InCylinder Blockset 2.1
Model start script go.m file
The standard start script go.m file for the ASM demo models has
been adapted in order to take the changes of the supported
simulation platforms into account.
The revised go.m file now contains the following platform options:
n 'RTI': DS1005, DS1006, DS1007, MicroLabBox
n 'SCALEXIO': SCALEXIO hardware
n 'VEOS': VEOS (offline simulation platform)
For more information on the calling procedures of the go.m file, refer
to the corresponding file header or Model Initialization ( ASM User
Guide).
The start script go.m file also takes the changes to the VEOS target
into account. With Release 2015-B, VEOS uses the DSRT target
instead of the DSOffSim target (refer to Migrating to VEOS 3.5
on page 250). The go.m file in the ASM demo projects has been
adapted to trigger the correct compiler settings.
PORTINJECTOR_TIMING
The block can now calculate a higher injection time to account for a
lower fuel quantity if the pressure difference between the injector
fuel supply and the intake manifold is too low.
The Map_mdot_Fuel_Gain_Red parameter has been added. Two new
inports for fuel pressure difference calculation have been created:
p_InMan[Pa] and p_Fuel[Pa].
The PORTINJECTOR_TIMING block can be used with multiple air
intake engine setups, such as V-engines. The Map_Inj2Cyl and
Const_max_num_PortInjector_PressureDrop parameters are used to
assign the intake manifold, injection and cylinder.
74
s
New Features and Migration
November 2015
s ASM Gasoline InCylinder Blockset t
PORTINJECTOR
The block can now calculate a lower fuel quantity if the pressure
difference between the fuel supply and the intake manifold is low.
This is used in compressed natural gas engines.
The Map_mdot_Fuel_Gain_Red parameter has been added. Two new
inports for fuel pressure difference calculation have been created:
p_InMan[Pa] and p_Fuel[Pa].
Test cycles
The Ftp_75 test cycle has been updated with an engine switch-off
phase. After a total duration of 1369 seconds, the engine is switched
off for 10 minutes. This is then followed by a warm engine restart.
Moreover, the new test cycles WLTC (Worldwide Harmonized Light
Vehicle Test Procedure) with three classes (depending on the powerto-mass ratio) have been implemented. The new test cycles can be
found in the test cycles folder of the new engine demos.
Migrating to ASM Gasoline InCylinder Blockset 2.1
PORTINJECTOR_TIMING
The new parameters and inputs will be set up so that the new
functionality has no effect.
PORTINJECTOR
The new parameters and inputs will be set up so that the new
functionality has no effect.
New Features and Migration
November 2015
75
t
s Automotive Simulation Models (ASM) t
ASM Optimizer
Where to go from here
Information in this section
New Features of ASM Optimizer 1.7
76
Migrating to ASM Optimizer Blockset 1.7
77
New Features of ASM Optimizer 1.7
Separation of data,
execution, and
postprocessing
The settings for data, execution, and postprocessing are separated
more clearly now. Because of this, several inputs are now located on
a different page. The axis definition is moved from the CalcEOPC
script to a seperate settings file in the postprocessing.
The General Settings file of ModelDesk can be reused.
Improved update behavior
Update processes are automatically performed. For example, changes
in the mapping automatically trigger a regeneration of the OPData
structure.
Import of ModelDesk
measurement data files
ModelDesk measurement data files (*.md) can be used as the source
for mean value measurement and mapping import.
Improved restart behavior
The results of gradient optimization algorithms depend on the start
conditions. Now, each operation point of each task is either loaded or
optimized. This ensures that repeated execution of an optimization
reproduces the same results.
Redesigned postprocessing
The postprocessing pages are redesigned similar to the optimization
task handling. The Manage Postprocessing page is introduced to keep
global postprocessing settings. For each optimization task, a separate
Postprocessing Task page is created.
Post-optimization function
A function can be added after each task. These functions can be uesd
to modify the OPData. The task results are also available for further
plots, for example.
76
s
New Features and Migration
November 2015
s ASM Optimizer t
Migrating to ASM Optimizer Blockset 1.7
General
All settings are transferred to the new location. With the existing axis
definitions of the EOPV calculation, a Settings file is created. For
existing post commands, a Post Optimization Function is generated.
Due to changes in the result structure, existing results are deleted if
an optimization is started.
New Features and Migration
November 2015
77
t
s Automotive Simulation Models (ASM) t
ASM Traffic Blockset
Where to go from here
Information in this section
New Features of ASM Traffic Blockset 3.3
78
Migrating to ASM Traffic Blockset 3.3
79
New Features of ASM Traffic Blockset 3.3
Model start script go.m file
The standard start script go.m file for the ASM demo models has
been adapted in order to take the changes of the supported
simulation platforms into account.
The revised go.m file now contains the following platform options:
n 'RTI': DS1005, DS1006, DS1007, MicroLabBox
n 'SCALEXIO': SCALEXIO hardware
n 'VEOS': VEOS (offline simulation platform)
For more information on the calling procedures of the go.m file, refer
to the corresponding file header or Model Initialization ( ASM User
Guide).
The start script go.m file also takes the changes to the VEOS target
into account. With Release 2015-B, VEOS uses the DSRT target
instead of the DSOffSim target (refer to Migrating to VEOS 3.5
on page 250). The go.m file in the ASM demo projects has been
adapted to trigger the correct compiler settings.
FUEL_CONSUMPTION
The FUEL_CONSUMPTION block has been added to the ENGINE
subsystem to simulate the fuel consumption and the carbon dioxide
emissions. The calculations are approximated, since the focus of the
demo is the vehicle dynamics. The fuel consumption is calculated on
the basis of a brake-specific fuel consumption map, which is a
measurement of the fuel efficiency.
The block is implemented in the new demo only and will not be
automatically added during the migration. To use the block, drag it
from the library and connect the related ports.
78
s
New Features and Migration
November 2015
s ASM Traffic Blockset t
Migrating to ASM Traffic Blockset 3.3
CUSTOM_SENSOR_
SCOPEZONE
The implementation has been changed. Demux blocks are used
instead of Selector blocks.
CUSTOM_SENSOR_OUTPUT
The implementation has been changed. Demux blocks are used
instead of Selector blocks.
TRAFFIC_SCHEDULER
The ASMSignalBus has been changed. For details, refer to Traffic
Scheduler ( ASM Traffic Reference).
FELLOW_PARAMETERS
The width of the PosVec_mainPnt_Fellows[x;y;z][m] outport is now
defined by a workspace variable.
SENSOR_POSITION
There are changes due to Simulink diagnostics.
COORDINATE_
TRANSFORMATION
There are changes due to Simulink diagnostics.
NEAREST POINT
There are changes due to Simulink diagnostics.
FELLOW_POSITION
There are changes due to Simulink diagnostics.
NEAREST SURFACE
There are changes due to Simulink diagnostics.
RADARSENSOR_3D
There are changes due to Simulink diagnostics.
New Features and Migration
November 2015
79
t
s Automotive Simulation Models (ASM) t
ASM Trailer Blockset
Where to go from here
Information in this section
New Features of ASM Trailer Blockset 2.4
80
Migrating to ASM Trailer Blockset 2.4
81
New Features of ASM Trailer Blockset 2.4
Model start script go.m file
The standard start script go.m file for the ASM demo models has
been adapted in order to take the changes of the supported
simulation platforms into account.
The revised go.m file now contains the following platform options:
n 'RTI': DS1005, DS1006, DS1007, MicroLabBox
n 'SCALEXIO': SCALEXIO hardware
n 'VEOS': VEOS (offline simulation platform)
For more information on the calling procedures of the go.m file, refer
to the corresponding file header or Model Initialization ( ASM User
Guide).
The start script go.m file also takes the changes to the VEOS target
into account. With Release 2015-B, VEOS uses the DSRT target
instead of the DSOffSim target (refer to Migrating to VEOS 3.5
on page 250). The go.m file in the ASM demo projects has been
adapted to trigger the correct compiler settings.
SUSCOMP_RIGID_SYM_xxx
80
s
A new parameter has been added to the block:
Map_Angle_Gamma_Axle_F_y. It takes the axle rotation due to
lateral force into account.
New Features and Migration
November 2015
s ASM Trailer Blockset t
Migrating to ASM Trailer Blockset 2.4
SUSCOMP_RIGID_SYM_xxx
A new parameter has been added: Map_Angle_Gamma_Axle_F_y.
SUSKIN_RIGID_SYM_xxx
There has been a bug fix for the Taylor series arcsin calculation
(wrong sign at the third Taylor series).
New Features and Migration
November 2015
81
t
s Automotive Simulation Models (ASM) t
ASM Truck Blockset
Where to go from here
Information in this section
New Features of ASM Truck Blockset 2.3
82
Migrating to ASM Truck Blockset 2.3
83
New Features of ASM Truck Blockset 2.3
Model start script go.m file
The standard start script go.m file for the ASM demo models has
been adapted in order to take the changes of the supported
simulation platforms into account.
The revised go.m file now contains the following platform options:
n 'RTI': DS1005, DS1006, DS1007, MicroLabBox
n 'SCALEXIO': SCALEXIO hardware
n 'VEOS': VEOS (offline simulation platform)
For more information on the calling procedures of the go.m file, refer
to the corresponding file header or Model Initialization ( ASM User
Guide).
The start script go.m file also takes the changes to the VEOS target
into account. With Release 2015-B, VEOS uses the DSRT target
instead of the DSOffSim target (refer to Migrating to VEOS 3.5
on page 250). The go.m file in the ASM demo projects has been
adapted to trigger the correct compiler settings.
SUSCOMP_RIGID_SYM_xxx
A new parameter has been added to the block:
Map_Angle_Gamma_Axle_F_y. It takes the axle rotation due to
lateral force into account.
Drivetrain
The Drivetrain model has been changed to a 6x6 configuration with
one front-driven axis and two rear-driven axes. In the new demo, the
rigid drivetrain approach has been used. Two central, one front, and
two rear differentials build the new drivetrain configuration. For this
purpose, the multi-instance feature of the ASM blocks has been used.
82
s
New Features and Migration
November 2015
s ASM Truck Blockset t
The new configuration will only be available in the new demo.
However, the old flexible drivetrain configuration from the vehicle
dynamics demo model can still be used.
Migrating to ASM Truck Blockset 2.3
SUSCOMP_RIGID_SYM_xxx
A new parameter has been added: Map_Angle_Gamma_Axle_F_y.
SUSKIN_RIGID_SYM_xxx
There has been a bug fix for the Taylor series arcsin calculation
(wrong sign at the third Taylor series).
New Features and Migration
November 2015
83
t
s Automotive Simulation Models (ASM) t
ASM Turbocharger Blockset
Where to go from here
Information in this section
New Features of ASM Turbocharger Blockset 3.1.1
84
Migrating to ASM Turbocharger Blockset 3.1.1
85
New Features of ASM Turbocharger Blockset 3.1.1
POSTTURBHPMAN
The block has new outports for mass fraction consistency when two
turbochargers are used:
n Xsi_Fuel_PostTurbHPMan[0_1]
n Xsi_Air_PostTurbHPMan[0_1]
n Xsi_Exh_PostTurbHPMan[0_1]
TURBINE
The Sw_TurbineType inport has been removed. The Sw_Ctrl_VTG_On
parameter has been added to set up whether the turbine is controlled
via variable turbine geometry (VTG) actuation. The inport for the VTG
actuation signal now awaits a position signal.
The power balance has been fixed for backflow through the turbine.
TURBINE_HP
The Sw_TurbineType inport has been removed. The Sw_Ctrl_VTG_On
parameter has been added to set up whether the high-pressure
turbine is controlled via variable turbine geometry (VTG) actuation.
The inport for the VTG actuation signal now awaits a position signal.
The power balance has been fixed for backflow through the turbine.
TURBINE_SAEJ922
The block is now also available for ASM Gasoline Engine. The
functions have been modified for higher compatibility with different
turbine data.
The Sw_TurbineType inport has been removed. The Sw_Ctrl_VTG_On
parameter has been added to set up whether the high-pressure
turbine is controlled via variable turbine geometry (VTG) actuation.
The inport for the VTG actuation signal now awaits a position signal.
84
s
New Features and Migration
November 2015
s ASM Turbocharger Blockset t
The Sw_mdot_Conv, Const_ConvScaling_mdot, Sw_omega_TC_Conv,
and Const_ConvScaling_omega parameters were added to customize
the conversion scaling.
The Map_HeatLoss_Turb_Rel parameter is new to take the heat flux
at the turbine casing into account.
WASTEGATE_VALVE
The Sw_TurbineType inport was removed.
The Sw_Ctrl_WGate_On parameter has been added to set up whether
the wastegate is controlled or not. The inport for the wastegate
actuation signal now awaits a position signal.
WASTEGATE_VALVE_HP
The Sw_TurbineType inport was removed.
The Sw_Ctrl_WGate_On parameter has been added to set up whether
the wastegate is controlled or not. The inport for the wastegate
actuation signal now awaits a position signal.
TURBO_BASIC
The MAPS_TC block has been renamed to TURBO_BASIC.
The Sw_Ctrl_TC inport has been removed and added as the
Sw_Ctrl_TC parameter to decide whether to use the wastegate, VTG,
or no actuation signal.
TURBO_BASIC_2STAGE
The MAPS_TC_2STAGE block has been renamed to
TURBO_BASIC_2STAGE.
The Sw_Ctrl_TC inport has been removed and added as the
Sw_Ctrl_TC parameter to decide if the system uses the incoming
actuation signal.
Migrating to ASM Turbocharger Blockset 3.1.1
Former version
The following systems are moved to a former version during
migration:
n POSTTURBHPMAN
n TURBINE
n TURBINE_HP
n TURBINE_SAEJ922
n WASTEGATE_VALVE
n WASTEGATE_VALVE_HP
New Features and Migration
November 2015
85
t
s Automotive Simulation Models (ASM) t
n TURBO_BASIC
n TURBO_BASIC_2STAGE
n SWITCHES_TURBO_2_0
86
s
New Features and Migration
November 2015
s ASM Vehicle Dynamics Blockset t
ASM Vehicle Dynamics Blockset
Where to go from here
Information in this section
New Features of ASM Vehicle Dynamics Blockset 3.2
87
Migrating to ASM Vehicle Dynamics Blockset 3.2
88
New Features of ASM Vehicle Dynamics Blockset 3.2
Model start script go.m file
The standard start script go.m file for the ASM demo models has
been adapted in order to take the changes of the supported
simulation platforms into account.
The revised go.m file now contains the following platform options:
n 'RTI': DS1005, DS1006, DS1007, MicroLabBox
n 'SCALEXIO': SCALEXIO hardware
n 'VEOS': VEOS (offline simulation platform)
For more information on the calling procedures of the go.m file, refer
to the corresponding file header or Model Initialization ( ASM User
Guide).
The start script go.m file also takes the changes to the VEOS target
into account. With Release 2015-B, VEOS uses the DSRT target
instead of the DSOffSim target (refer to Migrating to VEOS 3.5
on page 250). The go.m file in the ASM demo projects has been
adapted to trigger the correct compiler settings.
SUSCOMP_RIGID_SYM_xxx
A new parameter has been added to the block:
Map_Angle_Gamma_Axle_F_y. It takes the axle rotation due to
lateral force into account.
FUEL_CONSUMPTION
The FUEL_CONSUMPTION block has been added to the ENGINE
subsystem to simulate the fuel consumption and the carbon dioxide
emissions. The calculations are approximated, since the focus of the
demo is the vehicle dynamics. The fuel consumption is calculated on
the basis of a brake-specific fuel consumption map, which is a
measurement of the fuel efficiency.
New Features and Migration
November 2015
87
t
s Automotive Simulation Models (ASM) t
The block is implemented in the new demo only and will not be
automatically added during the migration. To use the block, drag it
from the library and connect the related ports.
Migrating to ASM Vehicle Dynamics Blockset 3.2
VEHICLE_MOVEMENT_
INFO_CAR
The "Not a number avoidance" at the calculation of the vehicle
sideslip angle has been removed. The calculation now uses the atan2
function from Simulink. Therefore, the division by zero is already
avoided.
SUSCOMP_RIGID_SYM_xxx
A new parameter has been added: Map_Angle_Gamma_Axle_F_y.
SUSKIN_RIGID_SYM_xxx
There has been a bug fix for the Taylor series arcsin calculation
(wrong sign at the third Taylor series).
SOFT_ECU_
POWERSTEERING
The Bus2Vector block has been added to avoid the "Bus signal
treated as vector" warning.
STEERING_3DOF_
VARIABLE_RATIO
The Bus2Vector block has been added to avoid the "Bus signal
treated as vector" warning.
The calculation of the exponential spring friction element at the
steering rod and steering column has been corrected to avoid "Not a
Number" generation.
STEERING
The Bus2Vector block has been added to avoid the "Bus signal
treated as vector" warning.
STEERING_VARIABLE_RATIO
The Bus2Vector block has been added to avoid the "Bus signal
treated as vector" warning.
88
s
New Features and Migration
November 2015
ConfigurationDesk
Objective
ConfigurationDesk is a tool that can be applied in many different
scenarios. You can use it to implement real-time applications and
configure RapidPro hardware.
New Features and Migration
November 2015
89
t
s ConfigurationDesk t
ConfigurationDesk – Implementation
Where to go from here
Information in this section
New Features of ConfigurationDesk 5.4 (Implementation
Version)
90
Migrating to ConfigurationDesk 5.4
95
New Features of ConfigurationDesk 5.4 (Implementation
Version)
Support of the enhanced
trace file generation
ConfigurationDesk supports the Simulink Coder features concerning
parameter handling introduced with MATLAB R2014a.
For more details, refer to Changes to TRC File Generation on page 35
Support of precompiled SIC
files
ConfigurationDesk lets you add Simulink implementation container
files (SIC files) to a ConfigurationDesk application. An SIC file is a
container file containing the behavior model code. ConfigurationDesk
now provides a method for you to precompile an SIC file. The
following variants are possible:
n Precompiled SIC files without readable source files
ConfigurationDesk lets you convert SIC files with source files into
SIC files without source files but with a SCALEXIO-compatible
library file, which might be desirable for IP protection.
n Precompiled SIC files that contain the original source files
ConfigurationDesk lets you create precompiled SIC files that still
contain the original source files. This can be useful if you want to
use them in VEOS Player.
The build process is faster when you use such a precompiled SIC file.
You can add the converted SIC files to your ConfigurationDesk
application. For details, refer to Creating Precompiled SIC Files
( ConfigurationDesk Real-Time Implementation Guide).
Support of protected
Simulink models
90
s
ConfigurationDesk lets you build real-time applications that contain
Simulink behavior models and/or Simulink implementation containers
New Features and Migration
November 2015
s ConfigurationDesk – Implementation t
that contain protected referenced models. Refer to Features of the
Model Interface Package for Simulink 3.1 on page 147.
New features of the FMU
support
Support of several FMUs with identical data port names
ConfigurationDesk now identifies each port of an FMU via the FMU’s
model name and the name of the port, including its hierarchical
structure as defined in the FMU’s model description file. Thus, ports in
different FMUs have different identities, even if they have the same
names. This means that:
n You can add different FMUs with identical port names to your
ConfigurationDesk application without creating a Model port
block: Duplicate ID conflict.
n If you replace an FMU with an FMU with the same port names,
but with a different model name, all ports that are provided by the
original FMU and are used in the ConfigurationDesk application
become unresolved.
FMU import: Support of enumerations ConfigurationDesk now
supports the enumeration data type in FMUs. This means that:
n FMU inputs and outputs with the enumeration data type are
available as data port in ConfigurationDesk.
n FMU variables with the enumeration data type are available in the
TRC file.
For details, refer to Integrating Functional Mock-up Units in
ConfigurationDesk ( ConfigurationDesk Real-Time Implementation
Guide).
New features of the V-ECU
support
Supported V-ECU Implementation container versions The
following table shows the tool versions that export V-ECU
implementation containers, and the related container versions:
V‑ECU Implementations Created With
Products of...
V‑ECU
Implementation
Version
dSPACE Release 2013-B and earlier:
n SystemDesk 3.x
n TargetLink 3.5
dSPACE Release 2014-A:
n SystemDesk 4.2
dSPACE Release 2014-B:
n SystemDesk 4.3
n TargetLink 4.0
1.0
New Features and Migration
November 2015
2.0
2.1
91
t
s ConfigurationDesk t
V‑ECU Implementations Created With
Products of...
V‑ECU
Implementation
Version
dSPACE Release 2015-A:
n SystemDesk 4.4
dSPACE Release 2015-B:
n SystemDesk 4.5
n TargetLink 4.1
2.2
2.3
Support of several V-ECU implementations with identical port
names ConfigurationDesk now identifies each V-ECU
implementation port via the V-ECU implementation name, the port
name, and the path of the port within the V-ECU implementation.
Thus, ports in different V-ECU implementations have different
identities, even if they have the same name and the same path within
the V-ECU implementation. This means that:
n You can add different V-ECU implementations with identical port
names to your ConfigurationDesk application without creating a
Model port block: Duplicate ID conflict.
n If you replace a V-ECU implementation with a V-ECU
implementation that has the same port names but a different VECU implementation name, all ports that are provided by the
original V-ECU implementation and are used in the
ConfigurationDesk application become unresolved.
Data type transformation
when extending the signal
chain
Data type transformation for digital function ports For the
global Extend signal chain options on the Configuration page of the
ConfigurationDesk Options dialog, the following applies:
If you set the Model port data type setting to Inherited, a model port
with the Boolean data type is created for digital function ports that
have an integer data type with the value range [0|1] during signal
chain extension, for example, digital signals.
User-specific saturation value range When you use the Extend
signal chain command, the following applies if you specified your
own saturation values:
n The specified value range is written to the Unit property of a
model port generated with the Extend Signal Chain command.
n The specified value range is written to the value range of the
function block in the TRC file generated during the build process.
Saturation rules for Extend signal chain ConfigurationDesk lets
you specify user saturation values for function ports. If you use System
min/max values, a data type transformation between the model port
92
s
New Features and Migration
November 2015
s ConfigurationDesk – Implementation t
and the function port is performed automatically if necessary. If you
specify your own User min/max values for function ports and then use
the Extend Signal Chain ‑ Create Suitable Model Port Block command,
specific saturation rules apply to the value ranges of function inports
and function outports.
Refer to Specifying Global Options for Extending the Signal Chain
( ConfigurationDesk Real-Time Implementation Guide)
Enhanced function block
types
Current In, Voltage In The Current In and Voltage In function
blocks provide the following new features:
n Capturing of angle positions. The angle position values are
captured synchronously to the measured current/voltage values.
n Enabling or disabling the capturing of time stamp and angle
position data to save computation time
For details, refer to Configuring the Basic Functionality (Current In)
( ConfigurationDesk I/O Function Implementation Guide) or
Configuring the Basic Functionality (Voltage In) ( ConfigurationDesk
I/O Function Implementation Guide).
Current Signal Capture, Voltage Signal Capture The Current
Signal Capture and Voltage Signal Capture function blocks provide
the following new features:
n Capturing of angle positions for all samples of all the captured
sequences in a model step
n Capturing of start angle positions for each complete captured
sequence
n Enabling or disabling the capturing of angle positions and start
angle positions to save computation time
For details, refer to Configuring the Basic Functionality (Current Signal
Capture) or Configuring the Basic Functionality (Voltage Signal
Capture) ( ConfigurationDesk I/O Function Implementation Guide).
CAN The CAN function block now supports the CAN FD mode for
the DS2671 Bus Board. The CAN FD frames must either comply with
the Non‑ISO CAN FD protocol developed by Bosch or the ISO CAN FD
protocol according to the upcoming ISO 11898‑1:2015 standard
(expected release in late 2015).
For details, refer to CAN (
Implementation Guide)
New features of the Bus
Manager
ConfigurationDesk I/O Function
Communication matrix modification The Bus Manager now lets
you specify user-defined settings for communication matrix elements.
The defined settings apply only to the active ConfigurationDesk
New Features and Migration
November 2015
93
t
s ConfigurationDesk t
application. This allows you to work with modified communication
matrix elements without changing the original communication matrix,
for example. For details, refer to Specifying User-Defined Settings for
Communication Matrix Elements ( ConfigurationDesk Bus Manager
Implementation Guide).
LIN Schedule Table function ports for LIN masters The Bus
Manager now provides a LIN Schedule Table function port for each
LIN master that is assigend to a bus configuration. The LIN Schedule
Table function port lets you specify an initial schedule table and
enable to switch the active schedule table during run time. For details,
refer to Working With LIN Schedule Tables ( ConfigurationDesk Bus
Manager Implementation Guide).
New filter features
Preconfigured view sets After you installed ConfigurationDesk,
the view sets 1 and 2 are preconfigured in the following way:
n Standard
This view set provides the default screen arrangement of
ConfigurationDesk, which is suitable for most use cases and
screen resolutions.
n Small Screen Resolution
This view set provides a screen arrangement that is most useful for
signal chain configuration in the working area on displays with a
relatively small screen resolution, such as a notebook display.
New features of the
automation interface
ConfigurationDesk's automaton interface is enhanced and supports
further features of ConfigurationDesk. For example, now you can
access Bus Manager elements via XPath expressions. The XPath
expressions must comply with XPath 1.0.
For detailed information on the enhancements and changes, refer to
Changes to the Automation Interface from Release 2015‑A
( ConfigurationDesk Automating Tool Handling)
New documentation
features
Glossary with ConfigurationDesk terminology The glossary
briefly explains the most important expressions and naming
conventions used in the ConfigurationDesk documentation. Refer to
ConfigurationDesk Glossary .
Custom function block documentation You can find all the
information on creating custom function blocks in a separate new
document:
ConfigurationDesk Custom I/O Function
Implementation Guide.
94
s
New Features and Migration
November 2015
s ConfigurationDesk – Implementation t
The document contains:
n An introduction to custom function blocks and basics on defining
custom function blocks and their elements
n Examples of implementing custom function blocks for serial and
Ethernet communication
n Current limitations for custom function block implementation
n An XML element reference describing the structure and purpose
of all elements that you can use in a custom function XML file
Migrating to ConfigurationDesk 5.4
Changes in TRC file
generation
You have to note some modifications on TRC file generation in
ConfigurationDesk. Refer to Changes to TRC File Generation
on page 35.
New Features and Migration
November 2015
95
t
s ConfigurationDesk t
96
s
New Features and Migration
November 2015
Container Management
New Features of Container Management
Improved assignment of
elements to container files
in SystemDesk 4.5
With this version of the Container Manager, assignment of AUTOSAR
elements to container file assignments has been improved for
SystemDesk 4.5. The file assigments are required for exchanging
software components between SystemDesk and TargetLink.
With the Dependent AR elements command that is available from the
Container Management context menu of atomic software
component types in SystemDesk, you can assign elements easily.
The command opens the Dependent AR elements dialog which lets
you manage file assignments for all the AUTOSAR elements that are
referenced by the selected software component type. The command
suggests an asignment for all the elements that you have not
assigned yet. You can create new file assignments and change file
assignments for each element or complete packages. The dialog
assists you by displaying if an element is used by the selected
software component type only (
types ( ).
New Features and Migration
) or by several software component
November 2015
97
t
s Container Management t
The following illustration shows an example from SystemDesk 4.5:
Further reading
98
s
For more details on assigning elements to container file assignments
in SystemDesk 4.5, refer to How to Assign AR Elements to Container
Files ( Container Management Document).
New Features and Migration
November 2015
ControlDesk Next Generation
Where to go from here
Information in this section
New Features of ControlDesk Next Generation
(ControlDesk 5.5)
100
Migrating to ControlDesk Next Generation
(ControlDesk 5.5)
113
Information in other sections
ControlDesk Next Generation Migration Guide
Explains migration from ControlDesk 3.x, CalDesk and prior versions of
ControlDesk Next Generation to ControlDesk 5.5.
ControlDesk Next Generation Migration of
ControlDesk 3.x Automation
Explains migration from ControlDesk 3.x automation to ControlDesk Next
Generation automation.
New Features and Migration
November 2015
99
t
s ControlDesk Next Generation t
New Features of ControlDesk Next Generation
(ControlDesk 5.5)
Where to go from here
Information in this section
New Features of Platform Management and
Platforms/Devices (ControlDesk 5.5)
100
New Variable Management Features (ControlDesk 5.5)
103
New Visualization and Instrument Features
(ControlDesk 5.5)
105
New Measurement and Recording Features
(ControlDesk 5.5)
107
New Bus Navigator Features (ControlDesk 5.5)
108
New Data Set Management Features (ControlDesk 5.5)
109
New Signal Editor Features (ControlDesk 5.5)
109
New Electrical Error Simulation Features
(ControlDesk 5.5)
110
New Automation Features (ControlDesk 5.5)
111
New Features of Platform Management and
Platforms/Devices (ControlDesk 5.5)
Information in this topic
Support of the new DCI‑CAN2 on page 101
CAN FD support on page 101
CAN Bus Monitoring device: Support for FIBEX and AUTOSAR system
description files on page 101
FlexRay Bus Monitoring device: Support for AUTOSAR system description
files on page 102
Further platforms that support automatic reconnect on page 102
Specifying the master for a simulation time group on page 102
Viewing application process information on page 102
Improvements to virtual validation scenarios on page 103
100
s
New Features and Migration
November 2015
s New Features of ControlDesk Next Generation (ControlDesk 5.5) t
Support of the new
DCI‑CAN2
ControlDesk supports the new DCI‑CAN2. The DCI‑CAN2 lets you
connect your host PC to a CAN FD or CAN network.
You can use the new DCI‑CAN2 with the following ControlDesk
devices:
n CAN Bus Monitoring
n CCP
n XCP on CAN
For details on the new DCI‑CAN2, refer to the
Feature Reference.
CAN FD support
DCI-CAN2
The following devices now support CAN FD in connection with the
new DCI‑CAN2:
n CAN Bus Monitoring
n CCP
n XCP on CAN
The current version of the dSPACE CAN API does not
support CAN FD.
For details on the CAN FD‑specific device settings, refer to CAN
Settings Properties ( ControlDesk Next Generation Reference).
CAN Bus Monitoring device:
Support for FIBEX and
AUTOSAR system
description files
The CAN Bus Monitoring device now also supports the following
variable description file formats in addition to DBC:
n FIBEX:
n
Version 4.1.0, 4.1.1
n
Version 3.1.0, 3.1.1
n
Version 3.0.0
n AUTOSAR system description files according to the
AUTOSAR system template:
n
Version 4.2.1
n
Version 4.1.1 ... 4.1.3
n
Version 4.0.3
n
Version 3.2.1 ... 3.2.3
n
Version 3.1.4
New Features and Migration
November 2015
101
t
s ControlDesk Next Generation t
Keep the migration aspects in mind when you reuse an
experiment that was originally created with
ControlDesk 5.4 or earlier and contains a CAN Bus
Monitoring device. Refer to Migrating to ControlDesk
Next Generation (ControlDesk 5.5) on page 116.
FlexRay Bus Monitoring
device: Support for
AUTOSAR system
description files
The FlexRay Bus Monitoring device now also supports AUTOSAR
system description files according to the AUTOSAR system template:
n Version 4.2.1
n Version 4.1.1 ... 4.1.3
n Version 4.0.3
n Version 3.2.1 ... 3.2.3
n Version 3.1.4
Further platforms that
support automatic
reconnect
ControlDesk now also supports the automatic reconnect feature
(→ Automatic Reconnect ( ControlDesk Next Generation Basic
Practices Guide)) for the following platforms:
n DS1007 PPC Processor Board
n DS1202 MicroLabBox
n SCALEXIO
n XIL API MAPort
For details on the automatic reconnect feature, refer to Reconnecting
to Platform/Device Hardware Automatically ( ControlDesk Next
Generation Basic Practices Guide).
Specifying the master for a
simulation time group
You can now specify the master for a simulation time group
(→ Simulation time group ( ControlDesk Next Generation Basic
Practices Guide)). This is useful if one of the members of the
simulation time group has a low latency and high synchronization
accuracy.
Refer to Configure Simulation Time Group (
Generation Reference).
Viewing application process
information
You can now view information on the hardware that is assigned to
the members of multiprocessor/multicore systems, and state
information on the application process that is currently loaded to the
hardware.
Refer to Online Details Properties (
Reference).
102
s
ControlDesk Next
New Features and Migration
November 2015
ControlDesk Next Generation
s New Features of ControlDesk Next Generation (ControlDesk 5.5) t
Improvements to virtual
validation scenarios
Reloading variable descriptions for multiple platforms/devices
For virtual validation scenarios, ControlDesk offers a simplified way to
reload the active application and variable descriptions of all platforms
and devices that refer to a virtual validation scenario performed on
VEOS or SCALEXIO.
Refer to Reload System (
ControlDesk Next Generation Reference).
Automation: adding applications instead of variable
descriptions ControlDesk's automation interface now allows you to
add an application file instead of a variable description file to a VEOS
or SCALEXIO platform in the experiment. This can be useful if you
work with an application without an environment model.
Refer to Adding applications instead of variable descriptions
on page 111.
New Variable Management Features (ControlDesk 5.5)
New Variable Browser
The Variable Browser has been renewed.
Function buttons
Tree view
Variable list
Favorites list
For details, refer to Basics of the Variable Browser (
Next Generation Basic Practices Guide).
Support of structs and
struct arrays
ControlDesk
ControlDesk's Variable Browser now supports the display of structs
and struct arrays.
Icon Description
Struct
Struct array
A structured list of variables that can have
various data types
An array of homogeneous structs
New Features and Migration
November 2015
103
t
s ControlDesk Next Generation t
If you drag a struct onto a Variable Array, all the variables it contains
are connected, with exception to contained arrays and struct arrays. If
you want to connect the contained variables to different instruments,
you can customize the connection assignment. Refer to Customizing
the connection assignment of variables to instruments on page 105.
Display of the original
connection path
When you place a variable on an instrument, ControlDesk now also
displays the path of the variable that was originally connected to the
instrument. This lets you identify the originally connected variable if it
was replaced by the variable it references.
Referenced variables The icons of variables displayed under a
subnode in the variable list can have an additional symbol. The
arrow indicates that this variable is a reference to a variable residing
in another node of the variable description. For example, variables in
an A2L file always reside under the root node.
When you drag a reference to an instrument, the referenced variable
is connected, not the reference itself.
Path and origin connection path The path of the connected
variable and the origin connection path of the dragged variable are
displayed in the instrument properties.
For details, refer to Basics of Placing Variables on a Layout
( ControlDesk Next Generation Basic Practices Guide).
104
s
New Features and Migration
November 2015
s New Features of ControlDesk Next Generation (ControlDesk 5.5) t
New Visualization and Instrument Features
(ControlDesk 5.5)
Customizing the connection
assignment of variables to
instruments
ControlDesk now lets you customize the connection assignment. This
lets you create special variable-instrument connections, such as
connecting a group of variables to multiple instruments in one step,
for example.
The illustration below shows the connection of several variables in
different instruments in one go.
Connection assignment is especially useful for connecting the
individual members of struct variables. To let ControlDesk perform a
connection assignment, you have to specify a text string that lets
ControlDesk search for a matching variable in the struct.
New Features and Migration
November 2015
105
t
s ControlDesk Next Generation t
The following illustration shows the connection of the members of a
struct in different instruments in one go.
For instructions, refer to How to Customize the Connection
Assignment of Variables to Instruments ( ControlDesk Next
Generation Basic Practices Guide).
Time Plotter and Index
Plotter enhancements
Saving Time Plotter data as a new measurement (Time Plotter
only) You can now save the data of a Time Plotter to a new
measurement data file.
For instructions, refer to How to Save Plotter or Time Plotter Data as a
New Measurement ( ControlDesk Next Generation Basic Practices
Guide).
Legend enhancements The Time Plotter's legend now provides
some enhancements:
n New legend columns such as x Delta
n Support of multiple selection
n Searching and filtering in the legend
Synchronization of the x‑axis You can now synchronize the x‑axis
of the Time Plotter and the Index Plotter in continuous visualization
mode. In this case, all synchronized Time Plotters share the same time
range and all Index Plotters share the same index range. Zooming and
moving actions then affect all synchronized Plotters in the same way.
106
s
New Features and Migration
November 2015
s New Features of ControlDesk Next Generation (ControlDesk 5.5) t
For details, refer to Zooming and Moving the Chart (Time Plotter)
( ControlDesk Next Generation Basic Practices Guide) and Zooming
and Moving the Chart (Index Plotter) ( ControlDesk Next
Generation Basic Practices Guide).
New line styles The Index Plotter and the Time Plotter now also
support the following line styles:
Line Styles
Description
Area
Data points are connected by a direct area line. The
area between the base line and the area line is filled
with the signal color(s).
Data points are connected by a staircase area line.
The area between the base line and the area line is
filled with the signal color(s).
Data points are connected by a staircase line.
Area
Staircase
Staircase
For details, refer to Axes and Signal Properties (Time Plotter/Index
Plotter) ( ControlDesk Next Generation Reference).
Switchable label orientation You can now display the y-axes
labels horizontally or vertically.
For details, refer to View Properties (Time Plotter/Index Plotter)
( ControlDesk Next Generation Reference).
Multiswitch enhancement
You can now specify whether the currently selected element is
marked by a dotted frame.
For details, refer to Multiswitch Properties (
Generation Reference).
ControlDesk Next
New Measurement and Recording Features
(ControlDesk 5.5)
ASAM MDF 4.x new default
exchange format
The ASAM MDF 4.x file format now is ControlDesk's default format
for measurement data files.
DSSIGCONV tool: Support of the ASAM MDF 4.x file format
The DSSIGCONV tool, which lets you extract time sections or signals
from a measurement data file, now also supports the ASAM MDF 4.x
file format.
New Features and Migration
November 2015
107
t
s ControlDesk Next Generation t
If you want to decrease the amount of data in a measurement data
file, you can extract time sections or signals from it, or split the file
into parts.
For instructions, refer to How to Extract Data from a Measurement
Data File ( ControlDesk Next Generation Basic Practices Guide).
Handling a large number of
measurement rasters
In specific scenarios, such as bypassing or platform access via XIL API,
you might have to handle a large number of measurement rasters.
This might reduce system performance. By default, the number of
measurement rasters that are displayed in the Measurement
Configuration for a platform/device is limited to about 20 rasters.
You can change the number of displayed rasters according to your
needs, which might enhance system performance.
For details, refer to Handling a Large Number of Measurement Rasters
( ControlDesk Next Generation Basic Practices Guide).
Measurement Data API
enhancements
Support of look-up tables (maps and curves) and common
axes The Measurement Data API now supports look-up tables (maps
and curves) and common axes.
For details, refer to the
ControlDesk Next Generation
Measurement Data API Reference.
Specifying the variable type when creating new signals When
you create a new signal using the Measurement Data API, you can
now specify the signal's variable type.
Refer to VariableTypeConstants ( ControlDesk Next Generation
Measurement Data API Reference).
New Bus Navigator Features (ControlDesk 5.5)
Bus Instrument generation
for Bus Manager
configurations
ControlDesk's Bus Navigator now lets you generate Bus Instruments
based on EXPSWCFG configuration data files created by
ConfigurationDesk's Bus Manager for use with SCALEXIO.
Instrument generation is supported for the following communication
protocols:
n CAN
n CAN FD
n LIN
108
s
New Features and Migration
November 2015
s New Features of ControlDesk Next Generation (ControlDesk 5.5) t
CAN bus communication
replay via MicroLabBox
You can now replay CAN bus communication in connection with
MicroLabBox.
CAN FD support for
SCALEXIO and the
DCI‑CAN2
The Bus Navigator now supports CAN FD (CAN with Flexible Data
Rate) messages:
n On the SCALEXIO platform, if CAN bus communication is modeled
via the RTI CAN MultiMessage Blockset in the behavior model
n For the DCI‑CAN2
The replay of CAN FD messages on the SCALEXIO platform
and the DCI‑CAN2 is not supported yet.
Refer to Features of the Bus Navigator Specific for CAN
( ControlDesk Next Generation Advanced Practices Guide).
CAN Bus Monitoring device:
Support for FIBEX and
AUTOSAR system
description files
The Bus Navigator now also supports FIBEX and AUTOSAR system
description files as variable description file formats in connection with
the CAN Bus Monitoring device. Refer to CAN Bus Monitoring device:
Support for FIBEX and AUTOSAR system description files
on page 101.
FlexRay Bus Monitoring
device: Support for
AUTOSAR system
description files
The Bus Navigator now also supports AUTOSAR system description
files as variable description file formats in connection with the
FlexRay Bus Monitoring device. Refer to FlexRay Bus Monitoring
device: Support for AUTOSAR system description files on page 102.
New Data Set Management Features (ControlDesk 5.5)
CDFX new default
exchange format
The Calibration Data File (CDFX) ASAM file format (ASAM Calibration
Data Format V2.0) now is ControlDesk's default format for data sets.
New Signal Editor Features (ControlDesk 5.5)
Full support of the DS1007
ControlDesk's Signal Editor now fully supports stimulus generation on
the DS1007 PPC Processor Board platform: i.e., one signal generator
for a DS1007‑based MP/MC application can stimulate variables of
other application processes.
New Features and Migration
November 2015
109
t
s ControlDesk Next Generation t
Support of DS1202
MicroLabBox
ControlDesk's Signal Editor now also supports stimulus generation on
the DS1202 MicroLabBox platform.
New Electrical Error Simulation Features (ControlDesk 5.5)
New XIL API EESPort
graphical user interface
Project
Manager
EESPort
110
s
XIL API
EESPort ribbon
Error
configuration
To prepare electrical error simulation, ControlDesk now provides the
XIL API EESPort graphical user interface.
Error configuration
window
Error set in
an error
configuration
New Features and Migration
Working area
Errors in an
error set
November 2015
EESPort Configurations
controlbar
Properties controlbar
s New Features of ControlDesk Next Generation (ControlDesk 5.5) t
For details and instructions, refer to Simulating Electrical Errors via XIL
API EESPort ( ControlDesk Next Generation Advanced Practices
Guide).
ControlDesk's XIL API EESPort graphical user interface is
the successor to ControlDesk's Failure Simulation Module,
which is being delivered for the last time with dSPACE
Release 2016-A.
Keep in mind that electrical error configurations of
ControlDesk’s Failure Simulation Module are not
compatible with XIL API EESPort configurations.
For migration information, refer to Migrating to
ControlDesk Next Generation (ControlDesk 5.5)
on page 116.
New Automation Features (ControlDesk 5.5)
Measuring and recording
look-up tables (maps and
curves)
ControlDesk's automation interface now lets you measure and record
look-up tables (maps and curves).
Event when adding signals
to or removing signals from
the measurement signal list
ControlDesk's automation interface now supports the following
events when adding signals to or removing signals from the
measurement signal list:
n MeasurementSignalAdded
n MeasurementSignalRemoving
Refer to MeasurementDataManagementEvents /
IXaMeasurementDataManagementEvents <<Events>>
( ControlDesk Next Generation API Reference).
Adding applications instead
of variable descriptions
ControlDesk's automation interface now allows you to add an
application file instead of a variable description file to a VEOS or
SCALEXIO platform in the experiment. This can be useful if you work
with an application without an environment model.
Refer to VEOSPlatform / IPmVEOSPlatform <<Interface>>
( ControlDesk Next Generation API Reference) and
SCALEXIOPlatform / IPmSCALEXIOPlatform <<Interface>>
( ControlDesk Next Generation API Reference).
New Features and Migration
November 2015
111
t
s ControlDesk Next Generation t
Getting folder locations via
automation
You can extend the functionality of ControlDesk and customize
ControlDesk's ribbon by using Python extension scripts. Depending
on the location, an extension script is executed for a specific user or
for all users.
For example, as of ControlDesk 5.5, you can get the
<DocumentsFolder> location using the properties of the
ApplicationEnvironment / IAeApplicationEnvironment
<<Interface>> interface. Refer to ApplicationEnvironment /
IAeApplicationEnvironment <<Interface>> ( ControlDesk Next
Generation API Reference).
112
s
New Features and Migration
November 2015
s Migrating to ControlDesk Next Generation (ControlDesk 5.5) t
Migrating to ControlDesk Next Generation
(ControlDesk 5.5)
Where to go from here
Information in this section
Discontinuations in ControlDesk
113
Migrating to ControlDesk Next Generation
(ControlDesk 5.5)
116
Information in other sections
ControlDesk Next Generation Migration Guide
Explains migration from ControlDesk 3.x, CalDesk and prior versions of
ControlDesk Next Generation to ControlDesk 5.5.
ControlDesk Next Generation Migration of
ControlDesk 3.x Automation
Explains migration from ControlDesk 3.x automation to ControlDesk Next
Generation automation.
Discontinuations in ControlDesk
Information in this topic
Discontinuations for ControlDesk as of dSPACE Release 2016‑A
on page 113
Discontinuations for ControlDesk as of dSPACE Release 2016‑B
on page 114
Discontinuations for
ControlDesk as of dSPACE
Release 2016‑A
ControlDesk's ASAP3 interface ControlDesk's ASAM
ASAP3‑compatible interface is being delivered for the last time with
ControlDesk 5.5 (dSPACE Release 2015-B).
To automate calibration and measurement tasks, you can alternatively
use:
n ControlDesk's automation interface. Refer to Automating
ControlDesk (
Guide).
ControlDesk Next Generation Advanced Practices
n ControlDesk's ASAM MCD‑3‑compatible interface. Refer to the
ControlDesk Next Generation MCD-3 Automation Guide.
New Features and Migration
November 2015
113
t
s ControlDesk Next Generation t
CDF import/export The Calibration Data File (CDF) format used to
import/export data sets is being supported for the last time with
ControlDesk 5.5 (dSPACE Release 2015‑B).
To exchange calibration data, use one of the other file formats
supported by ControlDesk such as CDFX (ASAM Calibration Data
File 2.0), DCM, or DSV. The CDFX format is ControlDesk's default
exchange format for data sets.
Refer to Exporting and Converting Data Sets (
Generation Basic Practices Guide).
ControlDesk Next
User-defined databases (UDDBs) User-defined databases (UDDBs)
are being supported for the last time with ControlDesk 5.5 (dSPACE
Release 2015‑B).
As a consequence, you have to change the real-time model to
manipulate the communication of a CAN controller on dSPACE
real‑time hardware.
LDF (format version 1.2 and earlier) LDF files (format version 1.2
and earlier) are being supported by the LIN Bus Monitoring device for
the last time with ControlDesk 5.5 (dSPACE Release 2015‑B).
MAT file (version 6) export ControlDesk 5.5 and earlier creates
version 6 MAT files that can be loaded in MATLAB Versions 5 (R8) or
later.
As of dSPACE Release 2016‑A, ControlDesk creates version 7.3
MAT files that can be loaded in MATLAB Versions 7.3 (R2006b) or
later.
Discontinuations for
ControlDesk as of dSPACE
Release 2016‑B
ControlDesk Failure Simulation Module ControlDesk’s Failure
Simulation Module is being delivered for the last time with dSPACE
Release 2016-A.
n To prepare electrical error simulation via the graphical user
interface (GUI), use the ControlDesk XIL API EESPort GUI, which is
introduced with ControlDesk 5.5 (dSPACE Release 2015-B).
n To prepare electrical error simulation via automation, use the
dSPACE XIL API .NET implementation supporting the Electrical
Error Simulation Port (EESPort).
For migration aspects, refer to Migrating to ControlDesk
Next Generation (ControlDesk 5.5) on page 116.
Plotter The Plotter is being delivered for the last time with dSPACE
Release 2016‑A.
114
s
New Features and Migration
November 2015
s Migrating to ControlDesk Next Generation (ControlDesk 5.5) t
Use one of the following instruments instead:
n Index Plotter
n Time Plotter
n XY Plotter
For information on the differences between the different plotter
types, refer to Differences Between Plotter, Time Plotter, Index Plotter,
and XY Plotter ( ControlDesk Next Generation Basic Practices
Guide).
Table Editor The Table Editor is being delivered for the last time
with dSPACE Release 2016‑A.
It will be replaced by an enhanced Table Editor.
MDF (format versions 2.0 and 3.0) export The export of MDF
measurement data files (MDF file format versions 2.0 and 3.0) is
being supported for the last time with dSPACE Release 2016-A.
Support for importing MDF files (format versions 2.0 and
3.0) continues.
To export measurement data, use one of the other file formats
supported by ControlDesk. Refer to How to Configure the Storage
Settings for Recording ( ControlDesk Next Generation Basic
Practices Guide).
Migrating ControlDesk 3.x experiments The migration of
ControlDesk 3.x experiments for reuse in ControlDesk Next
Generation is being supported for the last time with dSPACE Release
2016‑A.
To reuse a ControlDesk 3.x experiment in ControlDesk
from dSPACE Release 2016‑B or later:
1. Migrate the ControlDesk 3.x experiment using
ControlDesk from dSPACE Release 2016‑A or earlier.
Refer to Migrating from ControlDesk 3.x to ControlDesk
Next Generation ( ControlDesk Next Generation
Migration Guide).
2. Migrate the project from ControlDesk from dSPACE
Release 2016‑A or earlier to ControlDesk from
dSPACE Release 2016‑B or later. Refer to Migrating
from Prior Versions of ControlDesk Next Generation
( ControlDesk Next Generation Migration Guide).
New Features and Migration
November 2015
115
t
s ControlDesk Next Generation t
Migrating CalDesk projects The migration of CalDesk projects for
reuse in ControlDesk Next Generation is being supported for the last
time with dSPACE Release 2016-A.
To reuse a CalDesk project in ControlDesk from
dSPACE Release 2016‑B or later:
1. Migrate the CalDesk project using ControlDesk from
dSPACE Release 2016‑A or earlier. Refer to Migrating
from CalDesk to ControlDesk Next Generation
( ControlDesk Next Generation Migration Guide).
2. Migrate the project from ControlDesk from dSPACE
Release 2016‑A or earlier to ControlDesk from
dSPACE Release 2016‑B or later. Refer to Migrating
from Prior Versions of ControlDesk Next Generation
( ControlDesk Next Generation Migration Guide).
Migrating to ControlDesk Next Generation
(ControlDesk 5.5)
To migrate from ControlDesk 5.4 to ControlDesk 5.5 and reuse
existing experiments, you might have to carry out the following
migration steps.
To migrate to ControlDesk 5.5 from versions earlier than
5.4, you might also have to perform the migration steps of
the intervening ControlDesk versions.
116
s
New Features and Migration
November 2015
s Migrating to ControlDesk Next Generation (ControlDesk 5.5) t
Information in this topic
Changed TRC file generation on page 117
Failure Simulation Module: Discontinuation and migration on page 117
CAN Bus Monitoring device: changed DBC import on page 118
Change to the default behavior when downloading an incompatible
SCALEXIO application on page 119
Change to the Path property on page 119
Change to the evaluation of recording triggers with multiscaling variables
on page 120
Changed handling of checked variables and label lists on page 121
Tool automation changes on page 121
Changes to variable management automation interfaces on page 121
Change to the VideoDisplayStyleConstants enumeration on page 121
Change to the storage of recorded multidimensional arrays on page 121
Changes to the Measurement Data API on page 122
Migrating from prior ControlDesk Next Generation versions on page 122
Changed TRC file
generation
You have to note some modifications on TRC file generation in
connection with MATLAB R2015b.
Refer to Migrating Changes in Software That Uses TRC Files
on page 42.
Failure Simulation Module:
Discontinuation and
migration
ControlDesk’s Failure Simulation Module is being delivered for the last
time with dSPACE Release 2016-A.
n To prepare electrical error simulation via the graphical user
interface (GUI), use the ControlDesk XIL API EESPort GUI, which is
introduced with ControlDesk 5.5 (dSPACE Release 2015-B).
To use the ControlDesk XIL API EESPort GUI, the Failure Simulation
Package is required, which is based on XIL API's EESPort. The
implementation is based on dSPACE XIL API .NET.
Keep in mind that electrical error configurations of ControlDesk’s
Failure Simulation Module are not compatible with XIL API EESPort
configurations.
For migration, you can use the FailureSimulationExportTool to
export information from an existing ControlDesk failure simulation
system (FSN) file to the following files:
n
A hardware-dependent port configuration (PORTCONFIG) file
You can use the file to create a new EESPort. For instructions,
refer to How to Create a New EESPort ( ControlDesk Next
Generation Advanced Practices Guide).
New Features and Migration
November 2015
117
t
s ControlDesk Next Generation t
n
One error configuration XML file for each failure pattern
You can use the files to create and configure electrical errors,
refer to How to Create and Configure an Electrical Error
( ControlDesk Next Generation Advanced Practices Guide).
The FailureSimulationExportTool version to use depends on the
installed version of ControlDesk and dSPACE XIL API .NET as
shown in the following table:
Installed
ControlDesk
Version
Installed
dSPACE XIL API .NET
Version
Required
FailureSimulationExportTool
Version
5.3
2.0
2014-B
5.4
2015-A
2015-A
5.5
2015-B
2015-B
You can download the FailureSimulationExportTool including a
ReadMe file containing user documentation from the ControlDesk
Next Generation Product Support Center at
http://www.dspace.com/cdngpsc.
n To prepare electrical error simulation via automation, use the
dSPACE XIL API .NET implementation supporting the Electrical
Error Simulation Port (EESPort).
CAN Bus Monitoring device:
changed DBC import
As of version 5.5, ControlDesk's DBC file import in connection with
the CAN Bus Monitoring device has been changed to support FIBEX
and AUTOSAR system description files. As a consequence, paths to
variables in a DBC file are different depending on whether you import
the DBC file in ControlDesk 5.4 (or earlier) and ControlDesk 5.5 (or
later).
When you reuse an experiment originally created with
ControlDesk 5.4 or earlier, you can continue working with the device
and layouts/instruments based on the originally imported DBC file as
usual.
The following limitations apply:
n Replacing and reloading the originally imported DBC file is
blocked.
n When you add a new version of the DBC file to the CAN Bus
Monitoring device, ControlDesk activates this DBC variable
description and tries to restore the original variable connections.
Due to the changed DBC file import, however, the paths to the
variables in the newly added DBC file are different, so ControlDesk
cannot restore any variable connection even if you added the
same DBC file.
118
s
New Features and Migration
November 2015
s Migrating to ControlDesk Next Generation (ControlDesk 5.5) t
Generate new layouts based on the variable paths of the newly
added DBC file after you add a new version of the DBC file to the
CAN Bus Monitoring device.
Change to the default
behavior when
downloading an
incompatible SCALEXIO
application
When you download a real‑time application to a SCALEXIO system,
ControlDesk detects incompatibilities such as differences between the
SCALEXIO system I/O and the I/O as required by the real‑time
application.
ControlDesk's default behavior on detecting such incompatibilities
has been changed:
n Up to and including ControlDesk 5.4, ControlDesk simulated the
access to the diverging I/O channels by default.
n As of ControlDesk 5.5, ControlDesk activates the access to the
diverging I/O channels by default.
To let ControlDesk simulate the access to the diverging
I/O channels, you have to deselect the default behavior explicitly.
The default behavior was changed for downloading an application via
ControlDesk's graphical user interface. It was not changed for
downloading an application via ControlDesk's automation interface.
Change to the Path
property
The Path property of visualized variables of multiprocessor and
multicore real‑time applications displayed in the Properties controlbar
has changed in ControlDesk 5.5.
The following illustration shows a SCALEXIO platform with a variable
description related to multicore application as an example:
n Path in ControlDesk 5.4 or earlier:
[PlatformName()://ModelRoot/...]
The following illustration shows the path to a variable from the
multicore application as displayed in the Properties controlbar
(ControlDesk 5.4 or earlier) as an example:
New Features and Migration
November 2015
119
t
s ControlDesk Next Generation t
n Path in ControlDesk 5.5 or later:
[MasterPlatform()://SubPlatform/ModelRoot/...]
The illustration below shows the path to the same variable as
displayed in the Properties controlbar (ControlDesk 5.5 or later) as
an example:
This change does not require any manual migration steps.
For reference information, refer to Variables Properties
( ControlDesk Next Generation Reference).
Change to the evaluation of
recording triggers with
multiscaling variables
120
s
As of ControlDesk 5.5, if a variable using a multiscaling table is used
within a recording trigger rule, the variable's source value is used for
trigger evaluation.
New Features and Migration
November 2015
s Migrating to ControlDesk Next Generation (ControlDesk 5.5) t
In ControlDesk 5.4, the variable's converted value was used for
trigger evaluation.
Changed handling of
checked variables and label
lists
The Variable Browser has been renewed in ControlDesk 5.5. The
Variable Browser's new Favorite list integrates the Checked variables
list and the Label list:
Function buttons
Tree view
Variable list
Favorites list
For an overview of the Variable Browser, refer to Basics of the
Variable Browser ( ControlDesk Next Generation Basic Practices
Guide). For details on the Favorite list, refer to Favorites List
( ControlDesk Next Generation Reference).
Tool automation changes
Changes to variable management automation interfaces As of
version 5.5, ControlDesk provides an enhanced Variable Browser.
As a consequence, the following properties of the
VariablesManagement / IXaVariablesManagement <<Interface>> are
no longer required and have been removed from the automation
interface:
n Application.VariablesManagement.OperationButtonsVisible
n Application.VariablesManagement.SubsystemFirstEnabled
Change to the VideoDisplayStyleConstants enumeration In
ControlDesk 5.5, the Strech value of the VideoDisplayStyleConstants
<<Enumeration>> ( ControlDesk Next Generation API Reference)
enumeration has been corrected to Stretch.
The numerical value of the Stretch enumeration value is unchanged.
Change to the storage of recorded multidimensional arrays Up
to and including ControlDesk 5.4, recorded multidimensional arrays
were not stored as arrays but as nested vectors.
New Features and Migration
November 2015
121
t
s ControlDesk Next Generation t
As of ControlDesk 5.5, recorded multidimensional arrays are stored as
arrays. As a consequence, you may have to adapt automation scripts
accordingly.
No script adaptation is required if you use Python to
automate ControlDesk.
Changes to the
Measurement Data API
n The data type of the Size attribute of the FileDescription
interface has been changed from Int to Float.
Refer to Class Description (FileDescription) ( ControlDesk Next
Generation Measurement Data API Reference).
n The BitOffset and NumberOfBits attributes of the Signal interface
can no longer be set. You can only get these attribute values.
Refer to Class Description (Signal) ( ControlDesk Next
Generation Measurement Data API Reference).
Migrating from prior
ControlDesk
Next Generation versions
122
s
To migrate from prior ControlDesk Next Generation versions and
reuse existing experiments, you might have to carry out additional
migration steps. For more details on the migration steps, refer to
Migrating to ControlDesk Next Generation ( ControlDesk Next
Generation Migration Guide).
New Features and Migration
November 2015
DCI Configuration Tool
New Features of the DCI Configuration Tool 3.5
Improved A2L file
adaptation
The DCI Configuration Tool comes with improvements related to the
adaptation of an existing A2L file for use with a DCI‑GSI2.
Refer to A2L File Page (
New Features and Migration
DCI Configuration).
November 2015
123
t
s DCI Configuration Tool t
124
s
New Features and Migration
November 2015
dSPACE FlexRay Configuration
Package
New Features of dSPACE FlexRay Configuration Package 3.6
FlexRay Configuration Tool
Support of AUTOSAR System Template 4.2.1 The FlexRay
Configuration Tool now supports the AUTOSAR System Template
based on AUTOSAR Release 4.2.1 for describing FlexRay networks.
Support of opaque byte order format The FlexRay Configuration
Tool now supports signals with opaque byte order, which can be
defined in an AUTOSAR system description file. Data of signal
instances with the opaque byte order format is interpreted as
dynamic uint8[n] arrays, where n depends on the signal length. The
data is transmitted without endianness conversion, and the start bits
must be byte‑aligned.
For more details, refer to Handling Configuration Projects (
Configuration Tool Guide).
New Features and Migration
November 2015
FlexRay
125
t
s dSPACE FlexRay Configuration Package t
Discontinuation of the
FlexRay Replay Script
Generator
The FlexRay Replay Script Generator is delivered for the last
time with dSPACE Release 2015-B.
The FlexRay Replay Script Generator supports you in
mapping logged FlexRay signals (stored in a MAT file) to
TX signals of the replay model (contained in a TRC file). A
Python script can be generated from the mapped signals.
The script can then be replayed in Real‑Time Testing via the
Python interpreter.
As of RLS2016‑A, it is still possible for you to integrate the
Python interpreter into a FlexRay timetable task. This lets
you still replay user‑created Python scripts
time‑synchronously to the FlexRay bus.
126
s
New Features and Migration
November 2015
dSPACE HIL API .NET
New Features of dSPACE HIL API .NET 2.0
Support of the enhanced
trace file generation
dSPACE HIL API .NET supports the new features coming with the
enhanced trace file generation, refer also to Changes to TRC File
Generation on page 35.
Variable paths in your test scripts might be invalid. For further
information, refer to Migrating Changes in Software That Uses TRC
Files on page 42.
The MAPort stimulus support for DS1007 has been enhanced. If you
use a DS1007 as a multicore or multiprocessor system, you can now
also stimulate variables that are contained in another subapplication
that the signal generator is running in.
Stimulus support
The MAPort stimulus now also supports MicroLabBox.
New default variable path
format
The MAPort property VariableNames now returns the variable paths in
ControlDesk Next Generation format. The ControlDesk 3.x format for
variable paths is still supported.
The table below shows some examples:
Type
ControlDesk 3.x Format of Variable Paths
ControlDesk Next Generation Format of Variable
Paths
Scalar
'[MP_SubApplicationName/]Model
Root/double/Subsystem/Gain1/Out1'
'Platform()://[MP_SubApplicationName/]Model
Root/double/Subsystem/Gain1/Out1'1)
Vector
'[MP_SubApplicationName/]Model
Root/double/Subsystem/Gain1x3/Out1[1,3]'
'Platform()://[MP_SubApplicationName/]Model
Root/double/Subsystem/Gain1x3/Out1[2]'2)
New Features and Migration
November 2015
127
t
s dSPACE HIL API .NET t
Type
ControlDesk 3.x Format of Variable Paths
ControlDesk Next Generation Format of Variable
Paths
Matrix
'[MP_SubApplicationName/]Model
Root/double/Subsystem/Gain2x3/Value[2,3]'
'Platform()://[MP_SubApplicationName/]Model
Root/double/Subsystem/Gain2x3/Value[1][2]'
Structure3)
–
'Platform()://[MP_SubApplicationName/]Model
Root/Structures/Struct.SubStruct.DoubleArray[0]'
1)
'Platform' is replaced by the relevant platform name, for example, 'ds1006'. The platform name has no effect on the model
path itself. If you are using a multiprocessor model, the names of the subapplications are available in the model path.
2) In ControlDesk Next Generation format, an array index starts with 0, in ControlDesk 3.x format, it starts with 1.
3) Introduced with dSPACE Release 2015‑B.
128
s
New Features and Migration
November 2015
dSPACE Python Extensions
New Features of dSPACE Python Extensions 2.0
Support of the enhanced
trace file generation
dSPACE HIL API Python and rtplib2 support the new features coming
with the enhanced trace file generation, refer also to Changes to TRC
File Generation on page 35.
Variable paths in your test scripts might be invalid. For further
information, refer to Migrating Changes in Software That Uses TRC
Files on page 42.
The MAPort stimulus support for DS1007 has been enhanced. If you
use a DS1007 as a multicore or multiprocessor system, you can now
also stimulate variables that are contained in another subapplication
that the signal generator is running in.
Stimulus support
The MAPort stimulus now also supports MicroLabBox.
New default variable path
format
The MAPort property VariableNames now returns the variable paths in
ControlDesk Next Generation format. The ControlDesk 3.x format for
variable paths is still supported.
The table below shows some examples:
Type
ControlDesk 3.x Format of Variable Paths
ControlDesk Next Generation Format of Variable
Paths
Scalar
'[MP_SubApplicationName/]Model
Root/double/Subsystem/Gain1/Out1'
'Platform()://[MP_SubApplicationName/]Model
Root/double/Subsystem/Gain1/Out1'1)
Vector
'[MP_SubApplicationName/]Model
Root/double/Subsystem/Gain1x3/Out1[1,3]'
'Platform()://[MP_SubApplicationName/]Model
Root/double/Subsystem/Gain1x3/Out1[2]'2)
New Features and Migration
November 2015
129
t
s dSPACE Python Extensions t
Type
ControlDesk 3.x Format of Variable Paths
ControlDesk Next Generation Format of Variable
Paths
Matrix
'[MP_SubApplicationName/]Model
Root/double/Subsystem/Gain2x3/Value[2,3]'
'Platform()://[MP_SubApplicationName/]Model
Root/double/Subsystem/Gain2x3/Value[1][2]'
Structure3)
–
'Platform()://[MP_SubApplicationName/]Model
Root/Structures/Struct.SubStruct.DoubleArray[0]'
1)
'Platform' is replaced by the relevant platform name, for example, 'ds1006'. The platform name has no effect on the model
path itself. If you are using a multiprocessor model, the names of the subapplications are available in the model path.
2) In ControlDesk Next Generation format, an array index starts with 0, in ControlDesk 3.x format, it starts with 1.
3) Introduced with dSPACE Release 2015‑B.
Test Automation Python
modules
The rtplib2 Python module comes with the following changed
method:
n The GetVarNames method now returns the variable paths in
ControlDesk Next Generation format. The ControlDesk 3.x format
for variable paths is still supported. For examples, see above.
The matlablib2 Python module comes with some new properties and
enhanced methods.
The new properties are:
n WatchdogMethod
To get or set the method for observing the MATLAB process.
n Visible
To get or set the visibility of the MATLAB user interface.
n ProcessArchitecture
To get the process architecture (32‑bit or 64‑bit) of the connected
MATLAB instance.
n ProcessID
To get the process ID of the connected MATLAB instance.
n ExecutablePath
To get the path to the executable of the connected MATLAB
instance.
n Version
To get the version of the connected MATLAB instance.
n IsMUMatlabOpen
130
s
New Features and Migration
November 2015
s New Features of dSPACE Python Extensions 2.0 t
To get the flag that shows whether the connected MATLAB
instance is opened for multiple use.
The new method is:
n MaximizeCommandWindow
To maximize the MATLAB Command Window.
The enhanced methods are:
n MATLAB instance: Open
With the new optional MLInstallDir parameter you can configure
to start the MATLAB instance from the specified installation
directory.
n MATLAB instance: Close
With the new optional DisconnectOnly parameter you can
configure whether the MATLAB instance is to be closed when you
disconnect your automation access from the instance.
n MATFile instance: Open
The Mode parameter now supports the w7.3 option to create a MAT
file in HDF5‑based format that lets you store objects greater than
2 GB.
New Features and Migration
November 2015
131
t
s dSPACE Python Extensions t
132
s
New Features and Migration
November 2015
dSPACE XIL API
New Features of dSPACE XIL API 2015‑B
Support of the enhanced
trace file generation
dSPACE XIL API supports the new features coming with the enhanced
trace file generation, refer also to Changes to TRC File Generation
on page 35.
Variable paths in your test scripts might be invalid. For further
information, refer to Migrating Changes in Software That Uses TRC
Files on page 42.
The MAPort stimulus support for DS1007 has been enhanced. If you
use a DS1007 as a multicore or multiprocessor system, you can now
also stimulate variables that are contained in another subapplication
that the signal generator is running in.
Stimulus support
The MAPort stimulus now also supports MicroLabBox.
New default variable path
format
The MAPort property VariableNames now returns the variable paths in
ControlDesk Next Generation format. The ControlDesk 3.x format for
variable paths is still supported.
The table below shows some examples:
Type
ControlDesk 3.x Format of Variable Paths
ControlDesk Next Generation Format of Variable
Paths
Scalar
'[MP_SubApplicationName/]Model
Root/double/Subsystem/Gain1/Out1'
'Platform()://[MP_SubApplicationName/]Model
Root/double/Subsystem/Gain1/Out1'1)
Vector
'[MP_SubApplicationName/]Model
Root/double/Subsystem/Gain1x3/Out1[1,3]'
'Platform()://[MP_SubApplicationName/]Model
Root/double/Subsystem/Gain1x3/Out1[2]'2)
New Features and Migration
November 2015
133
t
s dSPACE XIL API t
Type
ControlDesk 3.x Format of Variable Paths
ControlDesk Next Generation Format of Variable
Paths
Matrix
'[MP_SubApplicationName/]Model
Root/double/Subsystem/Gain2x3/Value[2,3]'
'Platform()://[MP_SubApplicationName/]Model
Root/double/Subsystem/Gain2x3/Value[1][2]'
Structure3)
–
'Platform()://[MP_SubApplicationName/]Model
Root/Structures/Struct.SubStruct.DoubleArray[0]'
1)
'Platform' is replaced by the relevant platform name, for example, 'ds1006'. The platform name has no effect on the model
path itself. If you are using a multiprocessor model, the names of the subapplications are available in the model path.
2) In ControlDesk Next Generation format, an array index starts with 0, in ControlDesk 3.x format, it starts with 1.
3) Introduced with dSPACE Release 2015‑B.
134
s
New Features and Migration
November 2015
ECU Interface Manager
Where to go from here
Information in this section
New Features of ECU Interface Manager 1.7
135
Migrating to ECU Interface Manager 1.7
136
New Features of ECU Interface Manager 1.7
Support of built-in dSPACE
Calibration and Bypassing
Service configured for
DPMEM POD
The ECU Interface Manager now also supports the dSPACE
Calibration and Bypassing Service if it is already integrated in an
ECU application and configured for use with a dSPACE DPMEM plugon device (POD). With the ECU Interface Manager, you can add
additional service function calls to such a built‑in dSPACE Calibration
and Bypassing Service, which allows you to prepare service-based
bypassing using a DPMEM POD.
Refer to Preparing Code Items for Bypassing (
Manager Guide).
Specifying the behavior
when execution control
insertion fails
ECU Interface
Inserting an execution control requires additional memory space.
If you try to insert an execution control for all the instances of a code
item, and if there is insufficient memory space for the insertion of at
New Features and Migration
November 2015
135
t
s ECU Interface Manager t
least one execution control, the ECU Interface Manager opens a
dialog for you to select one of the following behaviors:
n Skip the insertion of only the problematic instances
n Disable the execution of all instances permanently
n Skip the insertion for all instances
Refer to Basics on Disabling Code Items (
Guide).
ECU Interface Manager
Migrating to ECU Interface Manager 1.7
Migrating projects last
saved with a former version
of ECU Interface Manager
In ECU Interface Manager 1.7, you can reuse projects that were last
saved with a former version of the ECU Interface Manager.
When you open such a project for the first time, you are asked
whether to update it:
n When you start the update, you can continue working with the
project with ECU Interface Manager 1.7.
n When you postpone the update, actions are blocked except for
exporting the application. You can update the project later.
n When you save the project, you are asked whether to overwrite
the old project file:
n
n
New software module
description file schema
When you overwrite the old project, you can no longer use it
with a former version of the ECU Interface Manager.
When you do not overwrite the old project, you have to specify
another location and/or name for the project file. This lets you
keep a version of the project that you can work with in the
former version of ECU Interface Manager.
As of ECU Interface Manager 1.6, ECU suppliers can now use a
generic schema to create a software module description file
(→ Software module description file ( ECU Interface Manager
Guide)).
You can also import software module description files based on the
dSPACE-specific schema, which was originally introduced with
ECU Interface Manager 1.0.
136
s
New Features and Migration
November 2015
s Migrating to ECU Interface Manager 1.7 t
n The dSPACE-specific schema is supported for
downward compatibility reasons only. It will be replaced
by the generic schema in the next dSPACE releases.
n Multicore support and further developments are not
available with the dSPACE-specific schema.
Use the generic schema instead.
For details on the generic schema, refer to Generic Schema of
Software Module Description Files ( ECU Interface Manager
Reference).
New Features and Migration
November 2015
137
t
s ECU Interface Manager t
138
s
New Features and Migration
November 2015
Firmware Manager
New Features of Firmware Manager 2.0
Enhanced platform support
The Firmware Manager supports SCALEXIO systems.
The support is restricted to the firmware archive installed with
dSPACE Release 2015‑B. If you want to update the firmware version
on a SCALEXIO system to an earlier version, you have to use
ControlDesk Next Generation or ConfigurationDesk from an earlier
dSPACE release.
Usability improvements
The Firmware Management pane provides an additional pane that
lists the available firmware archive versions with some additional
information.
For more details, refer to Firmware Manager Reference (
Manager Document).
Changed Archive Format
Firmware
The archive format for DS1007 and MicroLabBox changed with
Firmware Archives 2.0 contained in dSPACE Release 2015‑B. Earlier
versions of these archives cannot be loaded with the Firmware
Manager 2.0.
New Features and Migration
November 2015
139
t
s Firmware Manager t
140
s
New Features and Migration
November 2015
Model Compare
Product use prohibited in United States
You are not licensed to use Model Compare in the United
States. You are not allowed to use or permit others to use
this product in the United States or in any way that violates
the laws of the United States.
Where to go from here
Information in this section
New Features of Model Compare 2.6
141
Migration to Model Compare 2.6
143
New Features of Model Compare 2.6
Dump file customization via
hooks
Model Compare provides a hook mechanism that allows you to
customize dump files. In detail, a hook defines which blocks and
which block details are dumped, and in which format. If a subsystem
contains other subsystems, you can omit the inner ones. You can
write your own hooks. A demo hook is available.
Related documentation
n Basics on XML Dump Files (
Model Compare Guide)
n How to Customize the XML Dump via Hooks (
Model Compare
Guide)
New Features and Migration
November 2015
141
t
s Model Compare t
Quicker highlighting of leaf
model elements
As a quicker alternative to the highlighting option in the context
menu of model elements in the Model Navigator, you can now simply
double-click a leaf model element to highlight it in Simulink.
Related documentation
n How to Visualize Model Differences in MATLAB (
Model
Compare Guide)
Enhanced search
With this version of Model Compare you can search strings in
property values. Furthermore, Model Compare provides advanced
find options such as regular expressions, for example.
Related documentation
Model Compare Reference)
n General Page (
n Find Bar (
Saving models
Model Compare Reference)
You can configure that all the backup files created when a model is
being saved are kept. Furthermore, you can now save a copy of the
model by using a different name and path.
Related documentation
n Merge Settings Page (
n Save Model Copy (
Copying property names
and values
Model Compare Reference)
Model Compare Reference)
By double-clicking a property in the Property Inspector, a separate
window opens which lets you copy the property name as well as the
property value.
Related documentation
n Property Inspector (
New quick guide and demo
models
Model Compare Reference)
Model Compare now provides the new Model Compare Quick Guide
which summarizes the most important features of Model Compare.
This document is accessible via the Help menu. Furthermore, Model
Compare is now delivered with demo models, which you can extract
to your current working folder.
Related documentation
Model Compare Reference)
n Quick Guide (
n Extract Demos (
142
s
Model Compare Reference)
New Features and Migration
November 2015
s Migration to Model Compare 2.6 t
Migration to Model Compare 2.6
No adaptation necessary
You can migrate from Model Compare 2.5 to Model Compare 2.6
without any adaptations.
New Features and Migration
November 2015
143
t
s Model Compare t
144
s
New Features and Migration
November 2015
ModelDesk
New Features of ModelDesk 4.2
New supported platform
ModelDesk supports new simulation platforms:
n DS1007 PPC Processor Board
n MicroLabBox
Processing
Automation You can automize the essential steps of processing via
tool automation:
n Creating and editing measurement types
n Creating and editing measurement data
n Accessing the processing properties of parameters
Automized mapping The mapping of the variables of raw data to
the variables of a measurement type is improved. When you use the
auto map function, all variables with the same name are mapped.
Plotting
Automation You can automize the plotting via tool automation:
n Managing the files for plotting the layouts, for example
n Adding and removing signals in the layouts
n Saving the values of the signals
n Starting and stopping plotting
Parameterizing
Automotive Simulation Models You can parameterize the
Automotive Simulation Models in this release. For details on the
Automotive Simulation Models, refer to Automotive Simulation
Models (ASM) on page 53.
New Features and Migration
November 2015
145
t
s ModelDesk t
146
s
New Features and Migration
November 2015
Model Interface Package for
Simulink
Features of the Model Interface Package for Simulink 3.1
Support of the enhanced
trace file generation
The Model Interface Package for Simulink supports the Simulink
Coder features concerning parameter handling introduced with
MATLAB R2014a for the generation of Simulink implementation
container files.
For more details, refer to Changes to TRC File Generation on page 35
Support of protected
Simulink models
The Model Interface Package for Simulink supports Simulink behavior
models and/or Simulink implementation containers that contain
protected referenced models. To create a protected referenced
model, you have to select the Use generated code checkbox in the
Simulink model's Create protected models dialog. The Model
Interface Package for Simulink supports the following options from
the Content type list (including password-protection):
n Obfuscated source code
n Readable source code
New Features and Migration
November 2015
147
t
s Model Interface Package for Simulink t
For details, refer to the Simulink® CoderTM documentation.
New access to Copy/Paste
with Identity commands
You can now select the Copy with Identity and Paste with Identity
commands from the context menu of a model port block.
Additionally, the Model Interface Package provides the following
keyboard shortcuts for the commands:
n Copy with Identity: Ctrl+Alt+C
n Paste with Identity: Ctrl+Alt+V
148
s
New Features and Migration
November 2015
MotionDesk
Where to go from here
Information in this section
New Features of MotionDesk 3.7
149
Migrating to MotionDesk 3.7
150
New Features of MotionDesk 3.7
New supported platform
MotionDesk supports a new simulation platform:
n MicroLabBox
Instruments
Instrument Panel MotionDesk provides the Instrument Panel, a
tool that groups several instruments to one panel so that you can
handle all the assigned instruments in common. This lets you
minimize/maximize them or connect them to one or more observers,
for example. You can use Instrument Panels to visualize a dash board
in the scene.
Instruments and observers You can assign instruments to several
observers by specifying an instrument property or via mouse
operation in the Scene Navigator. So the same instrument can be
displayed by different observers.
In the Scene Navigator, all the instruments are listed below the
observer to which they are assigned.
Copy & paste You can copy & paste instruments to/from the
Windows Clipboard to create duplicates of instruments.
New Features and Migration
November 2015
149
t
s MotionDesk t
Tool automation
MotionDesk tool automation is extended. Now you can handle
observers via tool automation:
n Create observers
n Delete observers
n Create default observers
n Configure observers
Migrating to MotionDesk 3.7
Migrating from MotionDesk
2.2.1 and earlier
In MotionDesk 2.2.1 and earlier, MotionDesk uses 3-D objects in
VRML format. To use the scenes and custom 3‑D objects used in
these MotionDesk versions, they must be migrated so that they can
be used in MotionDesk 3.7. For details, refer to Migrating from
MotionDesk 2.2.1 and Lower ( MotionDesk Guide).
Migrating from MotionDesk
experiments in MDX file
format
MotionDesk 3.7 cannot read old MotionDesk experiments in the MDX
file format any longer. It is therefore not possible to migrate from a
MotionDesk experiment with a version earlier than 2.2.
If you want to migrate such old experiments, you can migrate using
MotionDesk 3.0 up to MotionDesk 3.6.
150
s
New Features and Migration
November 2015
Real-Time Testing
New Features of Real-Time Testing 2.6
New supported platforms
Real-Time Testing supports MicroLabBox.
The following Real-Time Testing modules are not supported for
MicroLabBox:
n rttlib.rs232lib (sending and receiving data via an RS232 interface)
n rttlib.hostcall
DS1007 multiprocessor
systems
Now it is possible for RTT sequences running on a node to access TRC
variables of remote nodes in DS1007 multiprocessor systems.
MAT file for data replay
Real-Time Testing is now independent of installed MATLAB versions
because it can use MATLAB DLLs redistributed by dSPACE.
New class
The rttlib.utilities module has the SequenceProperties class
which you can use to read properties of an RTT sequence (name,
description, file name, priority) and to read/write the
SequenceChannel property.
New Features and Migration
November 2015
151
t
s Real-Time Testing t
152
s
New Features and Migration
November 2015
RTI/RTI-MP and RTLib
Where to go from here
Information in this section
New Features of RTI/RTI-MP and RTLib
153
Migration Aspects of RTI/RTI-MP and RTLib
156
New Features of RTI/RTI-MP and RTLib
Support of the enhanced
trace file generation
RTI and RTI‑MP support the Simulink Coder features concerning
parameter handling introduced with MATLAB R2014a.
For more details, refer to Changes to TRC File Generation on page 35
MicroLabBox
Enhanced software support The following features are now
supported:
n Nonvolatile data handling (NVDATA)
You can store data from your real‑time application to the board's
nonvolatile memory. This data is available again after a shutdown
of your hardware. You can manage up to 64 KB data via RTLib,
RTI, and also via the board's web interface.
For more details, refer to Nonvolatile Data Handling (NVDATA)
( MicroLabBox Features).
New Features and Migration
November 2015
153
t
s RTI/RTI-MP and RTLib t
n Enhanced RTI support
The FPGA I/O Type 1 library provides the new Extras library
containing the following new blocks:
n
LED_BLx
To control the customizable LEDs.
n
Buzzer
To control the board's buzzer.
For more details, refer to Basic Functions (
Reference).
MicroLabBox RTI
n Enhanced setting in the DAC_CL1_BLx block
You can configure the Termination mode for the specified
channels. If the setting is enabled, you can set the termination
value individually for each channel. If the setting is disabled, all the
specified channels are set to high impedance at termination.
For more details, refer to DAC_CLASS1_BLx (
Reference).
MicroLabBox RTI
n Enhanced support of electric motor control
For more details, refer to New Features of RTI Electric Motor
Control Blockset 1.2 on page 165.
n Real‑Time Testing support
The Enable real‑time testing option on the RTI simulation options
page is set by default and is not changeable.
For more details, on the board's features, refer to
Features.
DS1007
MicroLabBox
Enhanced software support The following features are now
supported:
n Nonvolatile data handling (NVDATA)
You can store data from your real‑time application to the board's
nonvolatile memory. This data is available again after a shutdown
of your hardware. You can manage up to 64 KB data via RTLib,
RTI, and also via the board's web interface.
For more details, refer to Nonvolatile Data Handling (NVDATA)
( DS1007 Features).
For more details, on the board's features, refer to
Features.
154
s
New Features and Migration
November 2015
DS1007
s New Features of RTI/RTI-MP and RTLib t
MicroAutoBox
Pulse width measurement MicroAutoBox II variants with a
DS1511 I/O Board or a DS1513 I/O Board support pulse width
measurement (PW2D) via RTLib and RTI. You can either measure the
high pulses or the low pulses of the connected signal in the range
3.3 µs … 53.6 s.
For more details, refer to Pulse Width Measurement (PW2D)
( MicroAutoBox Features).
Discontinuation of MicroAutoBox I/O boards The following
MicroAutoBox II variants will be available only until end of 2015:
n MicroAutoBox II 1401/1501
n MicroAutoBox II 1401/1504
n MicroAutoBox II 1401/1505/1507
The software support continues at least up to end of 2018. We
recommend that you use the successor variants of MicroAutoBox II
with the I/O boards DS1511, DS1512, DS1513 and DS1514. The
MicroAutoBox II variant 1401/1507 will still remain available.
For more details, on the board's features, refer to
Features.
MicroAutoBox
Unsupported new features
of MATLAB R2015b
If you use the Evenly spaced breakpoints option for look-up tables,
the parameters of the related block are not generated into the
variable description. Accessing these parameters during run time, for
example, via the Table Editor in ControlDesk Next Generation, is not
possible.
Limitations when using
MATLAB R2015b
Note the following limitation when you use RTI/RTI‑MP with
MATLAB R2015b:
n Absolute time support in triggered subsystems
The scaling of the absolute time might be incorrect. The reason for
this behavior is still unknown, but MathWorks is planning to
publish a patch for Simulink versions R2015a and R2015b.
Discontinued batch file
The build.bat batch file was an alternative to the rtimp_build
command for building a multiprocessor application. The build.bat
batch file has been discontinued now.
New Features and Migration
November 2015
155
t
s RTI/RTI-MP and RTLib t
Migration Aspects of RTI/RTI-MP and RTLib
Changes in TRC file
generation
You have to note some modifications on TRC file generation in RTI
and RTI‑MP. Refer to Changes to TRC File Generation on page 35.
Modified features in
MATLAB R2015b
The following changes were made in the Simulink Configuration
Parameters dialog:
n The settings on the Hardware Implementation page have been
changed. The production hardware has to be specified slightly
differently.
The related RTI settings were also adjusted. It is therefore
recommended to reset the Simulink Preferences in all MATLAB
installations, that were previously connected with an older RTI
version.
n On the Optimization - Signals and Parameters page, the Inline
parameters setting has been changed to the Default parameter
behavior setting.
Real‑time testing support
always enabled for DS1007
156
s
The Enable real‑time testing option on the RTI simulation options
page is now always enabled for the DS1007 PPC Processor Board.
This is the default behavior for the new dSPACE platforms DS1007
and MicroLabBox. Existing configurations are automatically updated
by RTI and RTI‑MP.
New Features and Migration
November 2015
RTI Bypass Blockset
Where to go from here
Information in this section
New Features of the RTI Bypass Blockset 3.5
157
Migrating to RTI Bypass Blockset 3.5
158
New Features of the RTI Bypass Blockset 3.5
RTI Bypass Blockset
Support of XCP 1.3 The RTI Bypass Blockset supports A2L files
containing XCP‑specific IF_DATA entries based on the XCP 1.3
standard.
Support of CAN FD Besides the classic CAN protocol, the RTI
Bypass Blockset now also supports CAN FD (CAN with Flexible Data
Rate) as XCP transport layer. This means that communication
between the ECU and the prototyping tool can be via CAN and/or
CAN FD. Compared with the classic CAN protocol, the CAN FD
protocol allows data rates higher than 1 MBit/s and payloads of up to
64 bytes per message.
Currently, there are two CAN FD protocols on the market, which are
not compatible with each other: the non‑ISO CAN FD protocol
(representing the original CAN FD protocol from Bosch) and the ISO
CAN FD protocol (representing the CAN FD protocol according to the
upcoming ISO 11898‑1:2015 standard, expected release in late
2015). The RTI Bypass Blockset supports both CAN FD protocols.
For service‑based bypassing via XCP on CAN FD, the RTI Bypass
Blockset uses the already established XCP on CAN bypass interface
New Features and Migration
November 2015
157
t
s RTI Bypass Blockset t
type. After importing a database file containing descriptions in the
CAN FD format, you must enable CAN FD support and make some
CAN FD‑specific settings in the Setup block.
Refer to Options Page (RTIBYPASS_SETUP_BLx for XCP on CAN)
( RTI Bypass Blockset Reference).
The blockset supports service‑based bypassing via XCP on CAN FD
only for dSPACE platforms equipped with DS4342 CAN FD Interface
Modules.
RTI Bypass Blockset
MATLAB API
Support of enhancements to RTI Bypass Blockset The RTI Bypass
Blockset MATLAB API supports the enhancements to the RTI Bypass
Blockset.
Refer to the
RTI Bypass Blockset MATLAB API Reference.
Migrating to RTI Bypass Blockset 3.5
Working with models from
earlier RTI Bypass Blockset
versions 3.x and 2.x
The current release contains RTI Bypass Blockset 3.5, which is
compatible with earlier blockset versions 3.x and 2.x. However, there
are some points to note:
n Working with models from RTI Bypass Blockset 2.5 or earlier
Data management was changed in comparison to the prior RTI
Bypass Blockset versions. If you have a Simulink model built with
RTI Bypass Blockset 2.5 or earlier and open it with RTI Bypass
Blockset 3.4, the old data dictionary file (with file name
extension .dd) is replaced by a new data dictionary file (.vdb) using
the information stored in the Setup block. This happens as soon as
you open and close the Setup block dialog via OK, or open the
Read, Write, Upload or Download block dialog and click the Fill
Variable Selector button on the Variables page.
If you have a model that was saved with RTI Bypass Blockset 3.4
and want to use it with RTI Bypass Blockset 2.5 or earlier, the
model's data dictionary file required for blockset version 2.5 or
earlier (file name extension .dd) is created. This happens as soon as
you update the A2L files in the Setup block or open the Read,
Write, Upload or Download block and click the Fill Variable
158
s
New Features and Migration
November 2015
s Migrating to RTI Bypass Blockset 3.5 t
Selector button on the Variables page. The data dictionary file
created under RTI Bypass Blockset 3.5 (*.vdb) remains on disk.
To make the RTI Bypass Blockset able to recreate the data
dictionary, the database files specified in the Setup block must be
accessible at the specified location and must be unchanged.
n Working with models from RTI Bypass Blockset 2.6 up to and
including RTI Bypass Blockset 3.4
If you have a Simulink model built with RTI Bypass Blockset 2.6 up
to RTI Bypass Blockset 3.4 and open it with RTI Bypass
Blockset 3.5, the old data dictionary file is replaced by a new data
dictionary file. However, the new data dictionary file cannot be
used in earlier RTI Bypass Blockset versions. If you want to reuse
the model with RTI Bypass Blockset 2.6 up to RTI Bypass
Blockset 3.4, you have to create a suitable database in the earlier
RTI Bypass Blockset version by reimporting the database files
(A2L files) specified in the Setup block.
New Features and Migration
November 2015
159
t
s RTI Bypass Blockset t
160
s
New Features and Migration
November 2015
RTI CAN MultiMessage Blockset
Where to go from here
Information in this section
New Features of the RTI CAN MultiMessage Blockset 4.2
161
Migrating to RTI CAN MultiMessage Blockset 4.2
162
New Features of the RTI CAN MultiMessage Blockset 4.2
Enhancements in
connection with CAN FD
The RTI CAN MultiMessage Blockset provides the following
enhancements in connection with working with CAN FD messages:
CAN FD support for SCALEXIO systems The blockset now
supports working with CAN FD messages for SCALEXIO systems with
a DS2671 Bus Board.
Refer to Basics on Working with CAN FD (
Blockset Reference).
RTI CAN MultiMessage
Support of ISO CAN FD protocol Besides the already supported
original CAN FD protocol from Bosch, the blockset also supports the
ISO CAN FD protocol (according to the upcoming ISO 11898‑1:2015
standard, expected release in late 2015). You can select the CAN FD
protocol to be used in the RTICANMM ControllerSetup block.
Refer to Basics on Working with CAN FD (
Blockset Reference).
RTI CAN MultiMessage
Sample points for arbitration phase and data phase If working
with CAN FD messages is enabled, you can specify the sample points
for the arbitration phase and the data phase of CAN FD message
New Features and Migration
November 2015
161
t
s RTI CAN MultiMessage Blockset t
transmission as a percentage of the CAN bit period. The sample
points are used for synchronization purposes.
Refer to Setup Page (RTICANMM ControllerSetup) (
MultiMessage Blockset Reference).
Support of opaque byte
order format
RTI CAN
The RTI CAN MultiMessage Blockset now also supports signals with
opaque byte order, which can be defined in an AUTOSAR system
description file.
Migrating to RTI CAN MultiMessage Blockset 4.2
Working with models from
earlier RTI CAN
MultiMessage Blockset
versions
To reuse a model created with an earlier RTI CAN MultiMessage
Blockset version, you must update the S‑functions for all the
RTICANMM blocks and save the model before modifying the CAN
configuration.
To create new S‑functions for all the RTICANMM blocks in your
model in one step, you can perform one of the following actions after
opening the model:
n In the MATLAB Command Window, enter
rtimmsu_update('System', gcs).
For more details on the command and its options, enter help
rtimmsu_update in the MATLAB Command Window.
n Select the Create S‑Function for all CAN Blocks command from the
Options menu of the RTICANMM GeneralSetup block.
For more details refer to Limitations with RTICANMM (
MultiMessage Blockset Reference).
RTI CAN
Compiler messages when
using code generated by an
RTI CAN MultiMessage
Blockset version < 4.0
If you use code that was generated by an RTI CAN MultiMessage
Blockset version < 4.0, several compiler warning messages containing
the phrase <<argument of type "can_tp1_canChannel *" is
incompatible with parameter of type "DsTCanCh">> will appear
during the build process of your simulation model. This is due to a
modified data type. These warnings can be ignored and will disappear
after you regenerate the RTICANMM code by using the current
blockset version.
Using existing checksum
algorithms
Checksum algorithms originally developed for an application
containing CAN messages cannot be reused for applications
containing CAN FD messages, because CAN FD includes new
162
s
New Features and Migration
November 2015
s Migrating to RTI CAN MultiMessage Blockset 4.2 t
message types and longer data fields. Existing checksum algorithms
can still be used for applications that just contain classic CAN
messages. For CAN FD applications, you must adapt the checksum
algorithms.
New Features and Migration
November 2015
163
t
s RTI CAN MultiMessage Blockset t
164
s
New Features and Migration
November 2015
RTI Electric Motor Control Blockset
New Features of RTI Electric Motor Control Blockset 1.2
New block
The RTI Electric Motor Control Blockset provides a new block:
n EMC_ENDAT_BLx to use an absolute encoder connected to an
EnDat interface as an input sensor for motor control.
For more details, refer to
Reference.
New Features and Migration
RTI Electric Motor Control Blockset
November 2015
165
t
s RTI Electric Motor Control Blockset t
166
s
New Features and Migration
November 2015
RTI FPGA Programming Blockset
Where to go from here
Information in this section
New Features of the RTI FPGA Programming Blockset 3.0
167
Migrating to RTI FPGA Programming Blockset 3.0
170
New Features of the RTI FPGA Programming Blockset 3.0
Xilinx® support
Supported dSPACE
platforms
The RTI FPGA Programming Blockset now supports the following
products and versions of the Xilinx design tools.
Xilinx Design Tools Operating System
Version
MATLAB Version
Vivado 2015.2
(64‑bit version)
64‑bit versions of:
n MATLAB R2014a
n MATLAB R2014b
n MATLAB R2015a
Windows 7 Business,
Ultimate, and
Enterprise SP1 (64-bit
version)
The following dSPACE platforms are supported by the RTI FPGA
Programming Blockset 3.0:
n MicroAutoBox (MicroAutoBox II 1401/1511/1514 and
MicroAutoBox II 1401/1513/1514)
n MicroLabBox
n Modular system (DS5203 (7K325) and DS5203 (7K410))
n SCALEXIO (DS2655)
New Features and Migration
November 2015
167
t
s RTI FPGA Programming Blockset t
The following hardware is not supported by Xilinx Vivado. The RTI
FPGA Programming Blockset 3.0 therefore supports only the building
of the processor interface for existing FPGA model INI files:
n DS5203 FPGA Board (SX95)
n DS5203 FPGA Board (LX50)
n MicroAutoBox II 1401/1511/1512
n MicroAutoBox II 1401/1512/1513
Only the RTI FPGA Programming Blockset up to version 2.9 supports
Xilinx ISE and the FPGA modeling for the DS5203 (SX95) and
DS5203 (LX50) boards, and the DS1512 I/O Board (MicroAutoBox II
1401/1511/1512 and MicroAutoBox II 1401/1512/1513). Due to the
introduction of Vivado, Xilinx no longer supports the Xilinx System
Generator for DSP in combination with the ISE Design Suite after
MATLAB Release R2013b.
Enhancements to the
DS2655 FPGA Base Board
framework
The framework for the DS2655 FPGA Base Board provides the
following enhancements.
Multiple clock periods You can use up to 10 individual clock
periods for modeling specific parts of your FPGA design. The clock
periods are in the range 1.6e-7 s ... 6.25e-10 s (6.25 MHz ...
1600 MHz).
The FPGA_SETUP_BL block provides the Subsystems Clocks page to
configure the clock period for subsystems with an individual clock
period.
Enhancements to the
DS2655M1 Multi‑I/O
Module framework
The framework for the DS2655M1 Multi-I/O Module provides the
following enhancement:
n The Digital In function of the FPGA_IO_READ_BLx block and the
Digital InOut function of the FPGA_IO_Write_BLx block have a
new port. The Threshold Ack port outputs a flag that indicates
whether the I/O channel currently updates its threshold voltage or
a new threshold configuration can be set.
Support of new DS2655M2
Digital I/O Module
The RTI FPGA Programming Blockset now provides the new
DS2655M2 I/O Module framework for the DS2655M2 Digital I/O
Module.
The DS2655M2 Digital I/O Module has 32 versatile digital I/O
channels that can handle bit-wise data or serial communication. The
main features of the framework are I/O functions that use one or
more digital channels to implement a specific I/O functionality.
168
s
New Features and Migration
November 2015
s New Features of the RTI FPGA Programming Blockset 3.0 t
The following I/O functions can be used:
n Digital In
Up to 32 digital input functions that provide bit-wise access.
n Digital Out
Up to 32 digital output functions that provide bit-wise access.
n Digital Out-Z
Up to 16 digital output functions that provide bit-wise access and
a high-impedance output state (tristate).
n RS232 Rx
Up to 8 serial functions that receive data values from RS232
networks.
n RS232 Tx
Up to 8 serial functions that transmit data values to RS232
networks.
n RS485 Rx
Up to 8 serial functions that receive data values from RS485
networks in simplex mode.
n RS485 Rx/Tx
Up to 8 serial functions that exchange data values with RS485
networks in half-duplex mode.
n RS485 Tx
Up to 8 serial functions that transmit data values to RS485
networks in simplex mode.
Enhancements to the
FPGA1401Tp1 with MultiI/O Frameworks
The frameworks for MicroAutoBox provide the following
enhancements.
Multiple clock periods You can use up to 10 individual clock
periods for modeling specific parts of your FPGA design. The clock
periods are in the range 1.6e-7 s ... 6.25e-10 s (6.25 MHz ...
1600 MHz).
The FPGA_SETUP_BL block provides the Subsystems Clocks page to
configure the clock period for subsystems with an individual clock
period.
Related topics
Basics
• Migrating to RTI FPGA Programming Blockset 3.0 on page 170
New Features and Migration
November 2015
169
t
s RTI FPGA Programming Blockset t
Migrating to RTI FPGA Programming Blockset 3.0
Objective
There are different ways to migrate an existing model, depending on
the blockset version used.
Migrating from RTI FPGA
Programming Blockset 1.0
to 3.0
Because the RTI FPGA Programming Blockset 1.0 (released with
dSPACE Release 6.4) was not fully implemented, a model that you
implemented with it must be migrated manually. You must replace
each block of the RTI FPGA Programming Blockset with a new one to
make the model compatible with the current dSPACE RTI
environment for modeling, building and executing.
The update function of the script interface does not
support RTI FPGA Programming Blockset 1.0.
Migrating from RTI FPGA
Programming Blockset 1.1
and higher to 3.0
If you have implemented your FPGA application using RTI FPGA
Programming Blockset Version 1.1 and later, and want to use it with
RTI FPGA Programming Blockset 3.0, you must update the FPGA
framework. You can use the script interface for this, refer to Updating
the FPGA framework using the script interface on page 170.
You also have to update the framework if you have updated from
MATLAB R2008b or earlier to MATLAB R2011b or later.
Updating the FPGA
framework using the script
interface
It is recommended to back up your model before starting
migration.
The script interface provides the FPGAFrameworkUpdate method to
update a framework. You can decide whether to set the block
parameters to their initial values or leave them unchanged.
To update the FPGA framework without changing the values
of the block parameters
rtifpga_scriptinterface('FPGAFrameworkUpdate',
<SimulinkHandle>)
The script handles all the subsystems in the model/subsystem that is
specified by the Simulink handle. The parameters of the blocks are
unchanged after updating to the current framework version.
Example: The following script updates the FPGA framework for any
FPGA subsystem in the processor model called MyProcModel. The
specified values of the block parameters are not changed.
170
s
New Features and Migration
November 2015
s Migrating to RTI FPGA Programming Blockset 3.0 t
ProcModelHandle = get_param('MyProcModel','handle')
rtifpga_scriptinterface('FPGAFrameworkUpdate',
ProcModelHandle)
To update the FPGA framework and reset the values of the
block parameters to their initial values
rtifpga_scriptinterface('FPGAFrameworkUpdate',
<SimulinkHandle>, 'ReInit')
The script handles all the subsystems in the model/subsystem that is
specified by the Simulink handle. The parameters of the blocks are
reset to their initial values after updating to the current framework
version.
ProcModelHandle = get_param('MyProcModel','handle')
rtifpga_scriptinterface('FPGAFrameworkUpdate',
ProcModelHandle,'ReInit')
ConfigurationDesk custom
functions incompatible with
dSPACE Release 2015‑B
Relevant for SCALEXIO systems with a DS2655 FPGA Base
Board and a DS2655M1 Multi‑I/O Module
A custom function generated by using RTI FPGA
Programming Blockset 2.5 from dSPACE Release 2013‑A
and the real‑time applications (*.rta) containing the custom
function are incompatible with dSPACE Release 2015‑B. To
produce a usable custom function you have to rebuild the
FPGA model by using RTI FPGA Blockset 3.0 from dSPACE
Release 2015-B.
New Features and Migration
November 2015
171
t
s RTI FPGA Programming Blockset t
172
s
New Features and Migration
November 2015
RTI LIN MultiMessage Blockset
Where to go from here
Information in this section
New Features of the RTI LIN MultiMessage Blockset 2.5.1
173
Migrating to RTI LIN MultiMessage Blockset 2.5.1
173
New Features of the RTI LIN MultiMessage Blockset 2.5.1
Support of opaque byte
order format
The RTI LIN MultiMessage Blockset now also supports signals with
opaque byte order, which can be defined in an AUTOSAR system
description file.
Migrating to RTI LIN MultiMessage Blockset 2.5.1
Working with models from
earlier RTI LIN
MultiMessage Blockset
versions
To reuse a model created with an earlier RTI LIN MultiMessage
Blockset version, you must update the S‑functions for all the
RTILINMM blocks and save the model before modifying the LIN
configuration.
To create new S‑functions for all the RTILINMM blocks in your model
in one step, you can perform one of the following actions after
opening the model:
n In the MATLAB Command Window, enter
rtimmsu_update('System', gcs).
New Features and Migration
November 2015
173
t
s RTI LIN MultiMessage Blockset t
For more details on the command and its options, enter help
rtimmsu_update in the MATLAB Command Window.
n Select the Create S‑Function for all LIN Blocks command from the
Options menu of the RTILINMM GeneralSetup block.
For more details refer to Limitations of RTI LIN MultiMessage Blockset
( RTI LIN MultiMessage Blockset Reference).
174
s
New Features and Migration
November 2015
SCALEXIO Firmware
New Features of the SCALEXIO Firmware 3.3
New supported hardware
The SCALEXIO firmware supports the new SCALEXIO hardware
module: DS2655M2 Digital I/O Module.
New Features and Migration
November 2015
175
t
s SCALEXIO Firmware t
176
s
New Features and Migration
November 2015
SystemDesk
Where to go from here
Information in this section
New Features of SystemDesk 4.5
178
Migrating to SystemDesk 4.5
190
New Features and Migration
November 2015
177
t
s SystemDesk t
New Features of SystemDesk 4.5
Where to go from here
Information in this section
New General Features
178
Modeling Software Architectures
179
Working with Diagrams
179
Configuring ECUs
181
Simulating Systems
187
Automating SystemDesk
187
Variation Binding
188
New General Features
Objective
SystemDesk 4.5 has the following new general features.
AUTOSAR Releases
supported by
SystemDesk 4.5
Modeling support for the AUTOSAR 4.2.1 Release
SystemDesk 4.5 supports the modeling of software and system
architectures according the AUTOSAR 4.2.1 Release.
Compatiblity to recent AUTOSAR Releases SystemDesk also
supports AUTOSAR Releases 4.1.3, 4.1.2, 4.1.1, and 4.0.3 for
exchanging AUTOSAR files.
Compatibility to the newest AUTOSAR Release SystemDesk
4.5 supports importing AUTOSAR files according to the newest
AUTOSAR 4.2.2 Release. However, elements that are introduced with
this AUTOSAR Release are not imported to SystemDesk.
You can export AUTOSAR files from SystemDesk acording to the
AUTOSAR 4.2.2 Release.
178
s
New Features and Migration
November 2015
s New Features of SystemDesk 4.5 t
Modeling Software Architectures
Improvements
With this version of SystemDesk, modeling software architectures
now contains the following improvements:
n SystemDesk now lets you specify the naming of automatically
created constants for initial values of communication
specifications.
For reference information on the naming, refer to General page
(preferences) ( SystemDesk 4.x Reference).
n SystemDesk now provides a Start Page that lets you quickly access
user documentation and additional SystemDesk material.
n You can now navigate in SystemDesk's controlbars such as the
Project Manager using Navigate back
and Navigate forward
commands from SystemDesk's menu.
For reference information on the commands, refer to Navigate
Forward ( SystemDesk 4.x Reference) and Navigate Backward
( SystemDesk 4.x Reference).
n The improved Project Manager search displays an element's
AUTOSAR type and ECU configuration if available. It provides
quick access to an element's Properties dialog.
For reference information on SystemDesk's Project Manager and
searching for elements, refer to Project Manager
( SystemDesk 4.x Reference).
n The improved import of AUTOSAR templates provides quick access
to templates for creating standardized SystemDesk projects with
standard AUTOSAR types and a standardized package structure.
For reference information on importing templates, refer to Import
AUTOSAR Templates ( SystemDesk 4.x Reference).
Working with Diagrams
Improving SystemDesk's
diagrams for graphical
modeling
With this version of SystemDesk, graphical modeling has been
improved. Improvements apply to all of SystemDesk's diagrams: i.e.,
composition diagrams for modeling and connecting software
components, component diagrams for modeling an atomic software
New Features and Migration
November 2015
179
t
s SystemDesk t
component's ports and interfaces, and service connection diagrams
for connecting basic software with aplication software.
Edit and Connection modes
With this version, SystemDesk introduces the Edit and Connection
modes for simplifying element handling and element connection in
composition and service connection diagrams.
In the Edit mode that is active when you open a diagram, you can
add and arrange elements.
When you switch to the Connection mode, which is indicated by a
special cursor ( ), you can connect software components. To do so,
you can connect software components via drag & drop. You can
connect two ports, a port and an SWC or two SWCs. SystemDesk
then adds ports and, where possible, interfaces to the connected
SWCs.
The illustration below shows an example where you connect a port
with an assigned interface to another software component.
SystemDesk adds a port to the targeted software component and
assigns the same interface to the added port as in the starting port.
The following additional
improvements have been
made:
Additional improvements comprise:
n Improved auto-layout of diagrams and connections
n Navigating between parent and child composition diagrams like in
Simulink
n Searching for software components, ports, and interfaces in
composition and service connection diagrams by name
n Displaying error messages for incompatible connections
180
s
New Features and Migration
November 2015
s New Features of SystemDesk 4.5 t
n Selecting elements to add to a diagram more conveniently
n Improved configuration of element visibility in diagrams: e.g., the
visibility of ports and connections in composition diagrams
n Specifying default appearances for software components,
connections, ports, and interfaces in SystemDesk's preferences
Further reading
For more details on working with SystemDesk's diagrams, refer to
Working with Diagrams ( SystemDesk 4.x Guide).
Configuring ECUs
NVRAM manager
SystemDesk now supports the NVRAM manager basic software
component.
Modeling software architectures You can comfortably model NV
block service needs of atomic SWCs for requesting read/write
operations of the NVRAM manager. Additionally, you can model an
NV block software component for managing the specified NV block
service needs.
New Features and Migration
November 2015
181
t
s SystemDesk t
The following illustration shows an example of specifying an NV block
service need.
Configuring ECUs You can add an NvM basic software module to
an ECU configuration.
SystemDesk provides the following commands to auto-configure and
generate the NVRAM manager:
n Updating the NvM module configuration according to the
specified service needs.
n Generating a basic software component for the NVRAM manager.
This includes automatically connecting the basic software
component with the application software components that
request services.
n Generating code to simulate the NVRAM manager for virtual
validation.
Simulating systems You can experiment using A2L variables that
are generated for the NVRAM manager.
For this, SystemDesk generates an array that describes the NVRAM for
monitoring it.
182
s
New Features and Migration
November 2015
s New Features of SystemDesk 4.5 t
The following illustration shows A2L variables that are generated for
an example NVRAM manager.
Basic software descriptions
SystemDesk now uses the basic software module description template
for the elements of basic software components according to
AUTOSAR. Therefore, configuring ECUs with SystemDesk is now fully
compatible with AUTOSAR. This lets you exchange basic software
modules with third-party tools according to AUTOSAR.
The following table explains elements in SystemDesk's ECU
Configuration Manager:
Type
Description
ECU configuration
The entire configuration of the basic software and the RTE of
a single ECU.
Contains prototypes of all the atomic software components
that are mapped to an ECU instance, and also software
components for the basic software and the RTE.
The ECU flat view is flat in the sense that the hierarchy that is
introduced by composition SW components in the
application software is resolved by removing the
compositions and connecting the atomic software
components directly. However, SystemDesk also shows the
delegation ports.
Prototype of an application or basic software component.
ECU flat view
SW component
prototype
...
Port
Interface
...
Delegation port of a composition SW component.
Interface that is assigned to a delegation port.
BSW
Descriptions
The elements below BSW Descriptions are managed
automatically by SystemDesk. Typically, a user only modifies
parameters of module configurations and the BSW
descriptions are automatically adapted to the configuration.
BSW description
SW component
type
Defines the AUTOSAR interface of the basic software module
to the application software.
New Features and Migration
November 2015
183
t
s SystemDesk t
Type
Description
BSW module
description
SWC-BSW
mapping
...
Module configuration
Defines the standardized interface of the basic software
module to other basic software modules.
Maps elements of the SW component type to elements of
the BSW module description.
Specifies configuration parameters of the basic software
component for generating the basic software module code
and the BSW description.
...
The following illustration shows an example ECU configuration in the
ECU Configuration Manager.
Changed runnable entity to
OS task mapping
With this version of SystemDesk, you can map runnable and BSW
schedulable entities according to AUTOSAR via their RTE events.
The Runnable Mapping Editor provides lists of all the relevant RTE
events that trigger executables, i.e., runnable entities and BSW
schedulable entities.
In the editor, you can create OS tasks and map executables to them
via their triggering events. For each OS task, you can specify the order
of executable activation.
184
s
New Features and Migration
November 2015
s New Features of SystemDesk 4.5 t
The following illustration shows the Runnable Mapping Editor for an
example ECU configuration.
Improved Generate
Mappings command
With this version, SystemDesk's feature for generating a mapping of
runnables to OS tasks has been improved.
The Generate Mappings command that is available via the Runnable
Mapping Editor now lets you generate a mapping for unmapped
events to OS tasks. The command maps the events either to existing
OS tasks or creates new OS tasks if required.
For reference information on the Generate Mappings command, refer
to Runnable Mapping Editor ( SystemDesk 4.x Reference).
Improved RTE generation
With this version of SystemDesk, RTE generation has been improved
for a more complete support of the RTE API.
Contact dSPACE support for detailed information on SystemDesk's
support of the RTE API.
Improved RTE interventions
RTE interventions for delegation ports You can now create RTE
interventions for read/write access to data elements of delegation
ports. This lets you test compostion software components in
simulations for virtual validation.
Configuring RTE interventions more easily The RTE intervention
editor now lets you configure RTE interventions more easily. It
provides the Select elements for DAP interventions points command
to create RTE interventions that can be accessed externally of the
V‑ECU. The Select elements for RTE service ports intervention points
command lets you create RTE interventions that can be accessed
internally of the V‑ECU via RTE service ports.
New Features and Migration
November 2015
185
t
s SystemDesk t
Quickly generating V-ECUs
with the V-ECU wizard
The V-ECU wizard replaces SystemDesk's System wizard and improves
the quick generation of a V-ECU for a given atomic software
component or composition software component.
The wizard lets you create a system, add or create an ECU instance,
create an ECU configuration, and automatically configure it. As a
result, SystemDesk generates a V-ECU implementation and lets you
build it for VEOS.
This way you can quickly simulate a software component on the
virtual functional bus (VfB) level. SystemDesk maps the selected SWC
to a single ECU, which acts as a virtual functional bus (VFB).
Improved editor for
configuring basic software
modules
The BSW Module Editor for configuring basic software module
configurations has been redesigned for improved clarity and usability.
Further reading
For more details on configuring ECUs and generating V‑ECU
implementation with SystemDesk, refer to Configuring ECUs and
Generating V-ECU Implementations ( SystemDesk 4.x Guide).
186
s
The illustration below shows the new layout.
New Features and Migration
November 2015
s New Features of SystemDesk 4.5 t
Simulating Systems
Improvement for
debugging V‑ECUs
You can now specify to build a V‑ECU either in Release or in Debug
configuration. Building a V‑ECU in Debug configuration allows you to
debug the V‑ECU as the required information is generated during the
V‑ECU build.
The availability of the Debug configuration depends on the selected
simulation target.
Further reading
For more details on debugging V‑ECUs, refer to Debugging and
Analyzing Simulations ( SystemDesk 4.x Guide).
Automating SystemDesk
Improvement for creating
lists of elements via
automation
SystemDesk's automation feature has been improved to enable
creating lists of elements via automation. For each automation
interface with an addNew method, the automation now provides an
additional addNewRange method. The newly introduced
addNewRange method provides improved performance for creating
large numbers of elements.
Consider the following example for creating package elements via
automation:
def AddNewPackages(rootPackage, amount):
packages = []
for i in range(0, amount):
package = rootPackage.ArPackages.AddNew()
package.ShortName = "package_" + str(i)
packages.append(package)
return packages
Using the newly introduced addNewRange method as in the
following listing provides improved performance:
def AddNewRangeOfPackages(rootPackage, amount):
shortNames = []
for i in range(0, amount):
shortName = "package_" + str(i)
shortNames.append(shortName)
packages = rootPackage.ArPackages.AddNewRange(shortNames)
return packages
New Features and Migration
November 2015
187
t
s SystemDesk t
Further reading
For more details on automating SystemDesk, refer to Programming
SystemDesk Automation ( SystemDesk 4.x Guide).
Variation Binding
Objective
SystemDesk lets you bind variant-rich models to work with a selected
variant of a variant-rich model.
Importing variant-rich
models
The illustration below shows the composition diagram of an imported
variant-rich model in SystemDesk. The illustrated Regulator
composition is modeled for different variants.
188
s
New Features and Migration
November 2015
s New Features of SystemDesk 4.5 t
Variation binding
SystemDesk lets you bind the imported variant-rich model. The
illustration below shows selecting the variant to bind to.
Working with the resulting
variant
As a result, SystemDesk binds the variant-rich model to the selected
variant. The following illustration shows the composition diagram of
the Regulator composition that is now bound to the Eco variant. You
can now start with working with the Eco variant in SystemDesk.
Further reading
For more details on variation binding with SystemDesk, refer to
Variation Binding ( SystemDesk 4.x Guide).
New Features and Migration
November 2015
189
t
s SystemDesk t
Migrating to SystemDesk 4.5
Migrating to SystemDesk 4.5
SystemDesk 4.5 automatically migrates SystemDesk 4.3 and 4.4 SDP
project files upon loading.
You are recommended to install the most recent patch for
SystemDesk 4.3 or 4.4. Then, save the SDP project files you
want to migrate before opening them in SystemDesk 4.5.
Migrating BSW modules
With this version, SystemDesk describes basic software using the basic
software module template according to AUTOSAR. Therefore,
SystemDesk migrates basic software to the new description when you
load SystemDesk 4.3 and 4.4 SDP project files in SystemDesk 4.5. To
export V‑ECU implementations or simulate V-ECUs of migrated SDP
files, you have to perform auto-configure and generate on the
respective ECU configurations and export the V‑ECU implementations
or build them as required.
However, if you want to migrate a SystemDesk project with basic
software that is not supported for dSPACE virtual validation, you have
to migrate that basic software manually. To do so, you have to export
them to the AUTOSAR format in SystemDesk 4.3 or 4.4, create
according modules in SystemDesk 4.5 and import the exported
AUTOSAR files.
190
s
New Features and Migration
November 2015
TargetLink
Where to go from here
Information in this section
New Features of TargetLink 4.1 and TargetLink Data
Dictionary 4.1
192
Migrating to TargetLink 4.1 and TargetLink Data
Dictionary 4.1
218
New Features and Migration
November 2015
191
t
s TargetLink t
New Features of TargetLink 4.1 and
TargetLink Data Dictionary 4.1
Where to go from here
Information in this section
Modeling in Simulink or Stateflow
192
Code Generation Core Functionality
195
Component-Based Development
199
AUTOSAR
200
Target Simulation (PIL)
203
Data Dictionary and Data Management
206
Code Generator Options
208
Tool Chain Integration
209
Other
211
API Functions and Hook Functions
215
Modeling in Simulink or Stateflow
Where to go from here
192
s
Information in this section
Newly Supported Simulink Blocks
193
Improvements to Custom Look-up Tables
193
Support of Simulink's Simplified Mode and IC Structures
194
Support of Structures in Stateflow Action Language
194
New Features and Migration
November 2015
s New Features of TargetLink 4.1 and TargetLink Data Dictionary 4.1 t
Newly Supported Simulink Blocks
Supported Simulink blocks
TargetLink now supports the following Simulink blocks:
n Signal Conversion block:
TargetLink supports the Simulink Signal Conversion block, which
can be used to rescale bus signals, for example.
n Bus Assignment block:
A supported Simulink block that simplifies modeling with Simulink
buses.
Related documentation
n Signal Conversion Block (
TargetLink Block and Object
Reference)
n Code-Relevant Simulink Blocks (
TargetLink Block and Object
Reference)
Improvements to Custom Look-up Tables
Variables inherit an input
signal's dimension
Variables specified via the tlscript command can inherit their
dimension from an input signal. This allows, for example, the
implementation of a last index state variable for the Local search table
search method.
Related documentation
n Basics on Using Custom Look-Up Functions (
TargetLink
Preparation and Simulation Guide)
Support of vectors and
matrices
In addition to scalar signals, the custom look-up script mechanism
now supports vector and matrix input signals.
Related documentation
n Obsolete Limitations on page 244
New demo model
The new demo model TABLE1D_USR_LOCAL shows how custom
look-up tables process vector and matrix input signals and how you
can implement a local search.
New Features and Migration
November 2015
193
t
s TargetLink t
Related documentation
n Lookup Tables, User-Written Lookup Functions (
TargetLink
Demo Models)
n TABLE1D_USR_LOCAL (
TargetLink Demo Models)
Support of Simulink's Simplified Mode and IC Structures
In order to determine initial values that are not specified in the model,
TargetLink supports Simulink's simplified initialization mode, which
you can select by setting Simulink's Underspecified initialization
detected parameter to Simplified.
Additionally, in this mode you can initialize bus-capable blocks by
using Simulink's initial condition (IC) structures. These structs are now
also supported by TargetLink 4.1.
Related documentation Initializing Buses Via Initial Condition
Structures ( TargetLink Customization and Optimization Guide)
Support of Structures in Stateflow Action Language
Bus signals at Stateflow
charts
TargetLink now supports Simulink data objects using the
Simulink.Bus data type for Stateflow variables, and Simulink buses at
the inputs and outputs of Stateflow charts and at Stateflow-internal
data. To access those signals, TargetLink supports structures in the
Stateflow action language. The associated data objects must
reference either a structured Typedef or a structured DD Variable
object.
Related documentation
n Basics on the Representation of Buses in the Production Code
(
TargetLink Customization and Optimization Guide)
n Basics on the Compatibility of Buses and Predefined Structs
(
194
s
TargetLink Customization and Optimization Guide)
New Features and Migration
November 2015
s New Features of TargetLink 4.1 and TargetLink Data Dictionary 4.1 t
Code Generation Core Functionality
Where to go from here
Information in this section
MISRA-C Compliance
195
Improved Code Efficiency
196
MISRA-C Compliance
Improvements to
TargetLink's Fixed-Point
Library
Several improvements were made to TargetLink's Fixed-Point Library
so it complies with MISRA-C. The improvements include the
following:
n The value of an expression of integer type shall not be implicitly
converted to a different underlying type if a) it is not a conversion
to a wider integer type of the same signedness, b) the expression
is complex, c) the expression is not constant and is a function
argument, d) the expression is not constant and is a return
expression.
n The unary minus operator shall not be applied to an operand
whose underlying type is unsigned.
n Before preprocessing, a null statement shall only occur on a line by
itself. It may be followed by a comment, provided that the first
character following the null statement is a white-space character.
n Removed superfluous division by zero protection: The code
protection handling division by zero operations is generated by the
Code Generator when needed and is not additionally contained in
TargetLink's Fixed-Point Library.
Code Generator
improvements
Code Generator improvements to comply with MISRA-C:
n TargetLink does not generate bit-wise XOR operations in look-up
table code anymore.
n TargetLink no longer converts subtractions with unsigned integer
results into additions using the compute-through-overflow (CTO)
calculation method. Instead, the subtraction is generated into the
production code, improving readability and leading to MISRA
compliance.
New Features and Migration
November 2015
195
t
s TargetLink t
≤ TargetLink 4.0
TargetLink 4.1
U8 = U8 + 255;
U8 = U8 - 1;
n Dereferences in logical operations are now written in parentheses.
≤ TargetLink 4.0
TargetLink 4.1
Sa1_OutPort1 = (Int16) (*In2 || *In1); Sa1_OutPort1 = (Int16) ((*In2) ||
(*In1));
n There are code changes regarding Assignments of Stateflow State
IDs and Assignments to bitfields. For details, refer to Assignments
to bitfields on page 237.
Further improvements
Further improvements to comply with MISRA-C:
n By default, TargetLink now generates the void data type instead of
the Void typedef.
Also refer to No Void typedef on page 229.
Improved Code Efficiency
Dimension downgrade
TargetLink can now replace accesses to the same index range of a
matrix variable by a scalar variable.
Additionally, elements of vector and matrix variables can now be
replaced if they are based on the same non-loop-variable expression:
TargetLink < 4.1
TargetLink 4.1
vector2[e-d] = c[e-d]*7;
g(&vector2[e-d]);
Aux_S16_a = c[e-d]*7;
g(&Aux_S16_a);
This also works for vectors and matrices as well as index access ranges
with relative offsets.
Related documentation
n Basics on Optimizing Variables (
TargetLink Customization and
Optimization Guide)
n Basics on Eliminating Temporary Variables (
TargetLink
Customization and Optimization Guide)
Copy propagation
196
s
TargetLink can now remove variables in more contexts.
≤ TargetLink 4.0
TargetLink 4.1
if (cond) {
b = a + 1;
}
a = b;
if (cond) {
a = a + 1;
}
New Features and Migration
November 2015
s New Features of TargetLink 4.1 and TargetLink Data Dictionary 4.1 t
≤ TargetLink 4.0
TargetLink 4.1
if (cond1) {
if (cond2) {
S = In1;
} else {
S = X;
}
} else {
S = In2;
}
X = S;
if (cond1) {
if (cond2) {
X = In1;
}
} else {
X = In2;
}
Related documentation
n ERASABLE (
TargetLink Customization and Optimization Guide)
Moving code into
conditionally executed
branches
TargetLink can now move more code into conditionally executed
branches. This is especially visible for vector or matrix code:
≤ TargetLink 4.0
TargetLink 4.1
if (Cond1[0]) {
S1[0] = Input1[0];
} else {
S1[0] = Input2;
}
/* Switch: CascSw/S2 [0]
CascSw/S2: Omitted comparison with constant. */
if (Cond2[0]) {
if (Cond1[0]) {
Output[0] = (Int16) (-Input1[0]);
} else {
Output[0] = (Int16) (-Input2);
}
} else {
/* # combined # TargetLink outport: CascSw/Output */
Output[0] = 1;
}
…
if (Cond1[3]) {
S1[3] = Input1[3];
} else {
S1[3] = Input2;
}
…
/* Switch: CascSw/S2
CascSw/S2: Omitted comparison with constant. */
if (Cond2[0]) {
Output[0] = (Int16) (-S1[0]);
} else {
Output[0] = 1;
}
…
if (Cond2[3]) {
Output[3] = (Int16) (-S1[3]);
} else {
Output[3] = 4;
}
/* Switch: CascSw/S2 [3]
CascSw/S2: Omitted comparison with constant. */
if (Cond2[3]) {
if (Cond1[3]) {
Output[3] = (Int16) (-Input1[3]);
} else {
Output[3] = (Int16) (-Input2);
}
} else {
Output[3] = 4;
}
Related documentation
n MOVABLE (
TargetLink Customization and Optimization Guide)
Better optimization of
Assignment blocks in
iterated subsystems
The production code generated for Assignment blocks that reside in
iterated subsystems and whose Omit dispensable initializations
checkbox is cleared was improved:
New Features and Migration
November 2015
197
t
s TargetLink t
≤ TargetLink 4.0
TargetLink 4.1
for (Sa3_For_Iterator_it = 0; Sa3_For_Iterator_it <= 9;
Sa3_For_Iterator_it++) {
if (Sa3_For_Iterator_it == 0) {
for (Aux_S32 = 0; Aux_S32 < 10; Aux_S32++) {
/* Assignment: … - output initialization */
Ass_For[Aux_S32] = X_UD_For[Aux_S32];
}
}
for (Aux_S32 = 0; Aux_S32 < 10; Aux_S32++) {
/* Assignment: … - output initialization */
Ass_For[Aux_S32] = X_UD_For[Aux_S32];
}
/* Assignment: … - output calculation
# combined # Product: … */
Ass_For[Sa3_For_Iterator_it] =
Op(Sa3_For_Iterator_it);
for (Aux_S32 = 0; Aux_S32 < 10; Aux_S32++) {
/* Unit delay: … */
X_UD_For[Aux_S32] = Ass_For[Aux_S32];
}
for (Sa3_For_Iterator_it = 0; Sa3_For_Iterator_it <= 9;
Sa3_For_Iterator_it++) {
/* Assignment: … - output calculation
# combined # Product: Direct_Init/For/Product */
Ass_For[Sa3_For_Iterator_it] =
Op(Sa3_For_Iterator_it);
for (Aux_S32 = 0; Aux_S32 < 10; Aux_S32++) {
/* Unit delay: …_For */
X_UD_For[Aux_S32] = Ass_For[Aux_S32];
}
}
}
for (Aux_S32 = 0; Aux_S32 < 10; Aux_S32++) {
/* TargetLink outport: … */
OutFor[Aux_S32] = Ass_For[Aux_S32];
}
for (Aux_S32 = 0; Aux_S32 < 10; Aux_S32++) {
/* TargetLink outport: … */
OutFor[Aux_S32] = Ass_For[Aux_S32];
}
Which can be simplified as follows:
for (Aux_S32 = 0; Aux_S32 < 10; Aux_S32++) {
/* TargetLink outport: …
# combined # Assignment: … - output calculation
# combined # Product: … */
OutFor[Aux_S32] = Op(Aux_S32);
}
Optimization of Rte_IRead()
pointer return variables
TargetLink no longer generates unnecessary return variables for
Rte_IRead() and Rte_IWriteRef():
≤ TargetLink 4.0
TargetLink 4.1
if (cond1) {
p_DE = Rte_IRead_Run_DE();
… /* Use p_DE */
p_DE = Rte_IRead_Run_DE();
if (cond1) {
… /* Use p_DE */
}
…
… /* Use p_DE */
}
…
p_DE_a = Rte_IRead_Run_DE();
… /* Use p_DE_a */
198
s
New Features and Migration
November 2015
s New Features of TargetLink 4.1 and TargetLink Data Dictionary 4.1 t
More algebraic
simplifications for auxiliary
variables used for code
patterns
TargetLink can now perform further optimizations for auxiliary
variables used for accumulation in code patterns for complex
operations:
≤ TargetLink 4.0
TargetLink 4.1
aux = 42;
aux = 42;
aux += 0;
aux -= 0;
aux *= 1;
aux /= 1;
Component-Based Development
Improvements to Function Reuse
Function reuse for
incremental subsystems
and referenced models
With this TargetLink version, function reuse is possible not only for
simple atomic subsystems but also for subsystems configured for
incremental code generation and referenced models (with multiple
instances).
Related documentation
n Basics on Function Reuse (
TargetLink Customization and
Optimization Guide)
n MULTIPLE_INSTANCES_REFMODEL (
Variable propagation for
function reuse
TargetLink Demo Models)
TargetLink now lets you reuse variables of predecessor and successor
blocks of the reusable system definition without generating additional
interface variables.
Related documentation
n Basics on Reusing Variables of Preceding and Subsequent Blocks
(
TargetLink Customization and Optimization Guide)
n FUNCTION_REUSE (
New Features and Migration
TargetLink Demo Models)
November 2015
199
t
s TargetLink t
AUTOSAR
Where to go from here
Information in this section
Supported AUTOSAR Releases
200
Support of NvData Communication
201
Data Transformation
201
Activation Reasons of Runnables
201
Port-Defined Argument Values
202
Miscellaneous AUTOSAR Features
202
Supported AUTOSAR Releases
Supported AUTOSAR
Releases
The following AUTOSAR Releases are supported:
AUTOSAR Release
Revision
4.2
4.2.11)
4.1
4.1.3
4.1.2
4.1.1
4.0
4.0.3
4.0.2
3.2
3.2.3
3.2.2
3.2.1
3.1
3.1.5
3.1.4
3.1.2
3.1.0
3.0
3.0.7
3.0.6
3.0.4
3.0.2
2.1
1)
200
s
2.1.4
New in TargetLink 4.1.
New Features and Migration
November 2015
s New Features of TargetLink 4.1 and TargetLink Data Dictionary 4.1 t
Support of NvData Communication
NvData communication
TargetLink supports implicit NvData communication as described by
AUTOSAR. This includes the support of provide-require ports.
You can model access to the NVRAM via port blocks, data store
memory blocks, and block parameters.
Via special modeling styles, TargetLink lets you reduce accesses to the
NVRAM.
Related documentation
n Modeling NvData Communication (
TargetLink AUTOSAR
Modeling Guide)
n AR_NVDATA_TRANSFORMER (
TargetLink Demo Models)
Data Transformation
Modeling and simulating
error logic
TargetLink lets you use data transformation as described by AUTOSAR
to model and simulate related error logic, e.g., for end-to-end
protection for safety-critical applications or for Automotive Ethernet
and SOME/IP.
Related documentation
n Basics on Data Transformation (
TargetLink AUTOSAR Modeling
Guide)
n How to Model and Simulate Transformation Error Logic in Sender-
Receiver Communication (
Guide)
n tlTransformerError (
TargetLink AUTOSAR Modeling
TargetLink API Reference)
n AR_NVDATA_TRANSFORMER (
TargetLink Demo Models)
Activation Reasons of Runnables
Activation reasons
TargetLink lets you use activation reasons for your runnables as
described by AUTOSAR:
TargetLink lets you specify DD ActivationReason objects in a
Runnable object's subtree.
New Features and Migration
November 2015
201
t
s TargetLink t
To model activation reasons, you use TargetLink InPort blocks.
Related documentation
n Basics on Activation Reasons (
TargetLink AUTOSAR Modeling
Guide)
n How To Model a Runnable's Activation Reasons (
TargetLink
AUTOSAR Modeling Guide)
n AR_POSCONTROL (
TargetLink Demo Models)
Port-Defined Argument Values
Port-defined argument
values
TargetLink supports port-defined argument values as described by
AUTOSAR.
In the model, you reference a DD PortDefinedArgument object at the
TargetLink InPort block that represents the port-defined argument
value.
In production code, TargetLink generates port-defined argument
values as formal arguments within the runnable function's signature.
Related documentation
n Basics on Port-Defined Argument Values (
TargetLink AUTOSAR
Modeling Guide)
n How to Model Port-Defined Argument Values (
TargetLink
AUTOSAR Modeling Guide)
Miscellaneous AUTOSAR Features
Support of Rte_IWriteRef
for NvData communication
TargetLink supports the Rte_IWriteRef API function for NvData
communication.
Transformation ComSpecs
TargetLink can import and export communication specifications for
data transformations and TRANSFORMER_HARD_ERROR_EVENT.
ImplementationPolicy of
parameter prototypes
TargetLink can import and export implementation policies for
parameter data prototypes.
The data is stored in the DD ImplementationPolicy property of
parameter prototypes.
202
s
New Features and Migration
November 2015
s New Features of TargetLink 4.1 and TargetLink Data Dictionary 4.1 t
StepSize property
TargetLink can import and export a step size specified for
measurement and calibration tools.
The data is stored in the StepSize property of primitive application
data types or data prototypes.
ConstrLevel property
TargetLink can import and export constraint levels specified for
measurement and calibration tools
The data is stored in the ConstrLevel property of primitive application
data types or data prototypes.
For implementation data types, it is stored in the Constraints subtree.
Scaling for LINEAR category
TargetLink can import and export default values of scalings whose
category is set to LINEAR
The data is stored in the DefaultValue property of DD Scaling objects.
Data status of
DataReceiverComSpec
objects
TargetLink supports the HandleDataStatus property at DD
DataReceiverComSpec objects.
Target Simulation (PIL)
Where to go from here
Information in this section
Changes in the Target Simulation Modules
203
Folder for TSM Extensions
205
Changes in the Target Simulation Modules
New and discontinued
compiler versions
The following table shows the compiler versions that are now
supported by TargetLink 4.1, refer to the New and No Changes
columns. Compiler versions that are no longer supported are listed in
the Discontinued column.
New Features and Migration
November 2015
203
t
s TargetLink t
Target
Compiler
New
No Changes
Discontinued
ARM CortexM3
C16x
HCS12
Keil
TASKING
Cosmic
Metrowerk
Gaio
Renesas
Metrowerk
Diab
GreenHill
GNU
Metrowerk
Diab
GreenHill
Metrowerk
Diab
GreenHill
Diab
GreenHill
GreenHill
Cosmic
Metrowerk
Renesas
Renesas
TASKING
GNU
TASKING
GNU
GreenHill
NEC
TASKING
5.1
—
—
—
—
—
—
—
—
—
—
—
—
—
5.9
2014
—
2014
2014
—
—
—
—
5.0
—
5.0
4.6
2014
—
—
—
8.6
—
—
—
—
—
—
—
—
—
—
—
—
—
—
5.9
2012
—
4.8
5.1
9.3
9.4
3.2
—
—
—
—
—
3.0
—
8.7
4.8
5.1
11, 9
5.1
8.3
5.9
2013
4.1
2.8
5.9
2013
2.8
—
—
—
2013
—
—
—
9.4
—
4.3
3.4
—
—
2013
3.40
—
M32R
MC56F83
MPC55xx
MPC55xxVLE
MPC57xxVLE
MPC560xVLE
RH850
S12X1)
SH2
SH2A-FPU
TriCore17xx
TriCore2xx
V850
XC22xx
1)
Freescale S12XEVB/S12XEVB_USB is replaced by the new Freescale EVB9S12XEP100.
For more details on the evaluation boards supported by TargetLink,
refer to
TargetLink Evaluation Board Hardware Reference.
For further PIL support combinations that are part of a valid
Software Maintenance Service (SMS) contract, refer to
dSPACE's TargetLink PIL Support website at the TargetLink
Product Support Center.
204
s
New Features and Migration
November 2015
s New Features of TargetLink 4.1 and TargetLink Data Dictionary 4.1 t
Discontinued boards
No longer supported, no longer distributed The following
boards are no longer supported by TargetLink and no longer
distributed by dSPACE:
n Freescale 56F83xx
n Freescale HCS12
n Freescale PowerPC MPC5500
n Freescale PowerPC MPC5500VLE
n NEC V850ES
n Renesas M32R
If you want to use the unsupported evaluation boards with
TargetLink 4.1, contact dSPACE Support.
Still supported, no longer distributed The following boards are
still supported by TargetLink but no longer distributed by dSPACE:
n Freescale S12XEVB/S12XEVB_USB is replaced by the new Freescale
EVB9S12XEP100
Folder for TSM Extensions
Specifying the folder via
the API
You can now specify the folder for TSM extensions not only via the
TargetLink Preferences Editor but also via the API, for example:
TlTsmManager.exe -SetTsmExtensionFolder -Folder:C:\exp
Related documentation
n How to Clone Target/Compiler Combinations to Outside the
TargetLink Installation ( TargetLink Customization and
Optimization Guide) (the Preconditions in particular)
New Features and Migration
November 2015
205
t
s TargetLink t
Data Dictionary and Data Management
Where to go from here
Information in this section
Improvements to the Data Dictionary
206
New DD MATLAB API Functions
207
Referencing DD CodegenOptions Objects at TargetLink
Main Dialog Block
208
Improvements to the Data Dictionary
Predefined filter rule sets
for different DD views
TargetLink comes with new predefined filter rule sets that can hide
specific objects and properties in the DD tree. This makes it easier to
view the relevant data. The filter rule sets are designed for typical user
groups.
The following predefined filter rule sets are available:
n Admin - A filter rule set for administrators.
n AR_User - A filter rule set for AUTOSAR users.
n NonAR_NonRTOS_User - A filter rule set for users that use neither
AUTOSAR nor RTOS.
For further information on the filter rule sets, refer to DD_FILTER
( TargetLink Demo Models).
You can change the filter rule set in the Filter list of the Data
Dictionary Manager's toolbar.
Related documentation
n Basics on Filter Rule Sets for the Data Model (
Dictionary Basic Concepts Guide)
n How to Create Filter Rule Sets via DD Files (
Dictionary Basic Concepts Guide)
206
s
New Features and Migration
November 2015
TargetLink Data
TargetLink Data
s New Features of TargetLink 4.1 and TargetLink Data Dictionary 4.1 t
Filter views for the Object
Comparison Navigator
You can use the Filter list in the Object Comparison Navigator to hide
specific objects and properties of no interest. This makes it easier to
compare a high number of DD objects. You can either select one of
the predefined filter rule sets or build your own.
Related documentation
n Basics on Filter Rule Sets for the Data Model (
TargetLink Data
Dictionary Basic Concepts Guide)
n Comparing and Merging Data Dictionary Objects (
TargetLink
Data Dictionary Basic Concepts Guide)
Message alerts
If the Message Browser pane is opened but hidden because of an
active Embedded Help pane, the tab of the Message Browser
indicates that there are new messages by changing color.
n A new Info message - blue tab
n A new Warning message - yellow tab
n A new Error message - red tab
Related documentation
n Overview of the User Interface (
TargetLink Data Dictionary
Basic Concepts Guide)
New DD MATLAB API Functions
New DD API functions
TargetLink provides several new DD MATLAB API functions that are
listed below. For more details, refer to the
TargetLink Data
Dictionary Reference.
GetAutosarVersion
[version, errorCode] = dsdd('GetAutosarVersion'[,<DD_identifier>]);
New Features and Migration
November 2015
207
t
s TargetLink t
retrieves the Autosar version as specified with
the /Pool/Autosar/Config.AutosarVersion property of the specified
DD.
GetRenameBaseType
[version, errorCode] = dsdd('GetAutosarVersion'[,<DD_identifier>]);
retrieves the Typedef object which specifies the rename rule for a
base data type.
Referencing DD CodegenOptions Objects at TargetLink
Main Dialog Block
Referencing DD
CodegenOptions options
For centralized handling and easier specification of consistent options,
TargetLink 4.1 lets you directly reference DD CodegenOptions objects
at the TargetLink Main Dialog block.
Related documentation Basics on Configuring the Code Generator
for Production Code Generation ( TargetLink Customization and
Optimization Guide)
Code Generator Options
New Code Generator Options
Overview of new Code
Generator options
The following new Code Generator options are available with
TargetLink 4.1.
n AvoidNestedVariablePropagationPointerAccess
Generates additional pointers in reuse structures if these reuse
structures access variables for which variable propagation is
specified. For details, refer to
AvoidNestedVariablePropagationPointerAccess ( TargetLink
Block and Object Reference).
208
s
New Features and Migration
November 2015
s New Features of TargetLink 4.1 and TargetLink Data Dictionary 4.1 t
n ReportFailedFunctionReuseVariablePropagation
Enables an optional report indicating problems that occurred in
function reused systems during variable propagation. For details,
refer to ReportFailedFunctionReuseVariablePropagation
( TargetLink Block and Object Reference).
n ReplaceUnrolledVectorsAndMatricesByScalar
Controls the replacement of unrolled vector and matrix accesses
by scalars. For details, refer to
ReplaceUnrolledVectorsAndMatricesByScalars ( TargetLink Block
and Object Reference).
For reference information on all Code Generator options, refer to
Alphabetical List of Code Generator Options ( TargetLink Block and
Object Reference).
Migration aspects of Code
Generator options
Migration aspects include:
n Removed Code Generator option
n Changed Code Generator options
n Recommended compatibility settings
n Basics on changed defaults
For details, refer to Migration Aspects Regarding Code Generator
Options on page 223.
Tool Chain Integration
Where to go from here
Information in this section
Exporting Functional Mock-up Units
210
Requirement Information in the Data Dictionary
210
New Features and Migration
November 2015
209
t
s TargetLink t
Exporting Functional Mock-up Units
Functional Mock-up Units
TargetLink lets you generate Functional Mock-up Units (FMUs) for
TargetLink subsystems. These FMUs are based on the FMI 2.0
standard in order to execute TargetLink code in FMI-compliant
simulation environments.
These include VEOS, SCALEXIO and a large range of third-party FMIcompliant tools (https://www.fmi-standard.org/tools).
Related documentation
n Definition of the FMI Standard and FMUs (
TargetLink
Interoperation and Exchange Guide)
n Basics on Exporting FMUs from TargetLink (
TargetLink
Interoperation and Exchange Guide)
Requirement Information in the Data Dictionary
Storing requirement
information as DD objects
TargetLink lets you store requirement information in the Data
Dictionary as RequirementInfo objects. These objects act as a proxy to
your requirements management system.
In the model, you can reference these objects at TargetLink blocks
and from Stateflow objects. This instructs TargetLink to add
requirement information as comments to the generated production
code and the generated documentation.
You can programmatically handle the block data for requirement
information via the tlRequirementInfo() API function, which is used
instead of tl_set() or tl_get() for this data.
Related documentation
n Basics on Requirement Information in the Generated Code
(
TargetLink Interoperation and Exchange Guide)
n Basics on Using DD Based Requirement Information (
Interoperation and Exchange Guide)
n tlRequirementInfo (
210
s
New Features and Migration
TargetLink API Reference)
November 2015
TargetLink
s New Features of TargetLink 4.1 and TargetLink Data Dictionary 4.1 t
Other
Where to go from here
Information in this section
General Enhancements and Changes
211
TargetLink Demos
213
General Enhancements and Changes
TargetLink context menu
The context menu of TargetLink blocks provides two new options:
n Create reference (incr. subsystem to ref. model)
n Disable reference (ref. model to incr. subsystem)
Before, these options were available only in the dialog of the
TargetLink Main block. You can use them to replace a subsystem
configured for incremental code generation with a referenced model,
and vice versa.
Related documentation
n Common TargetLink Context Menu Options (
TargetLink Block
and Object Reference)
Improved simulation
performance
TargetLink's simulation performance has been improved. The
following types of models are now simulated with better performance
in MIL simulation mode:
n Models that contain many scaling-invariant subsystems
n Models that use many workspace variables
To maximize simulation performance for TargetLink
models, it is best to use one of the following methods to
start the simulation:
n Via the tl_sim(model, parameters) (
TargetLink API
Reference) API function instead of Simlunk's own sim()
function
n Via the TargetLink Main Dialog block
n Via a TargetLink plot dialog
New Features and Migration
November 2015
211
t
s TargetLink t
Related documentation
n None
Improved synchronization
of function system
signatures
The following improvements apply to the specification and
synchronization of function system signatures:
n In addition to the DD Function object, now you can link a DD
Signature object in a TargetLink Function block. DD Signature
objects contain interface specifications (port data).
n You can perform consistency checks between the interface (port
data) specified in the DD Signature object and the modeled
interface of the Function system (Check ports).
n You can update/synchronize the interfaces in the model with the
specifications of the DD Signature object (DD to Model).
n The SyncSystemSignature object in the /Pool/ModelDesign/Config/
object tree no longer contains string properties. Instead, it
contains typed data types like Boolean or Enum. This makes it easier
to configure them in the Data Dictionary Manager.
n If you do not have any DD Signature object specifications but want
to transfer your modeled interface data to the Data Dictionary,
you can also synchronize the port data to the Data Dictionary
(Model to DD).
n An HTML report is generated whenever you check or synchronize
ports. The report contains detailed information about differences
in the specification of the DD Signature object and the interface of
the Function system.
Related documentation
n Centrally Specifying and Synchronizing Function System Signatures
(
Setting MEX and SIL
compilers independently
TargetLink Customization and Optimization Guide)
You can now set a SIL compiler for the production code DLL
independently of the MEX compiler for the simulation S-function. This
lets you use the free MSVC Express Edition for compiling the
production code and SIL debugging.
Related documentation
n How to Set or Change MEX and SIL Compilers (
TargetLink
Preparation and Simulation Guide)
n How to Debug in SIL Simulation Mode (
TargetLink Preparation
and Simulation Guide)
n tlProductionCodeSILCompiler (
212
s
New Features and Migration
November 2015
TargetLink API Reference)
s New Features of TargetLink 4.1 and TargetLink Data Dictionary 4.1 t
TargetLink Demos
New demos
The following new demos come with TargetLink 4.1
Ar_nvdata_transformer This new demo shows two features:
n Read and Write access to nonvolative RAM via NVData Interfaces
n Use of AUTOSAR transformers: e.g., to model end-to-end
communication protection for safety-critical applications
DD_filter The demo shows how to create XML filter rule sets based
on DD files with the required specification. The demo contains the
tl_example_CreateDDFilterBasedOnDDFile script and three generic DD
files with the specification for typical filter use cases. The script
generates an XML filter rule set.
This demo does not contain any model.
Related Documentation
TargetLink Demo Models)
n DD_FILTER (
n Basics on Filter Rule Sets for the Data Model (
TargetLink Data
Dictionary Basic Concepts Guide)
DD_ML_API This demo shows two examples of how to use the DD
MATLAB API:
n The simple.m script creates a DD variable object and a user-defined
generic DD object via dsdd commands.
n The findCalVariables.m script demonstrates how to find all
variable objects with STATIC_CAL class in a DD file.
Related Documentation
n DD_ML_API (
TargetLink Demo Models)
DD_ML_ImportExport This demo contains various M scripts that
show how to import objects to the Data Dictionary from XLS and
XML files.
Related Documentation
n DD_ML_IMPORTEXPORT (
TargetLink Demo Models)
Function_reuse This demo shows the function reuse feature that is
applied to subsystems with instance-specific initial parameter values
by defining mask parameters.
New Features and Migration
November 2015
213
t
s TargetLink t
Related Documentation
TargetLink Demo Models)
n FUNCTION_REUSE (
n Basics on Function Reuse (
TargetLink Customization and
Optimization Guide)
Multiple_instances_refmodel This demo shows the function reuse
feature that is applied to referenced models with instance-specific
initial parameter values by defining model arguments.
Related Documentation
n MULTIPLE_INSTANCES_REFMODEL (
n Basics on Function Reuse (
TargetLink Demo Models)
TargetLink Customization and
Optimization Guide)
Table1d_usr_local This demo shows how to replace TargetLink
look-up table code that uses a local search algorithm with nonscalar
inputs by custom look-up functions.
Related Documentation
n TABLE1D_USR_LOCAL (
TargetLink Demo Models)
n Basics on Using Custom Look-Up Functions (
TargetLink
Preparation and Simulation Guide)
Variable_vector_width This demo model shows how to work with
vectorized variables that have width variants. Using preprocessor
macros for vector widths, the same model and generated production
code can be used for all widths. The code of complete subsystems
can become width-varying at code compile time.
Related Documentation
n VARIABLE_VECTOR_WIDTH (
TargetLink Demo Models)
n Introduction to Variable Vector Widths (
TargetLink
Customization and Optimization Guide)
Improved demos
The following demos contain new feature demonstrations:
Ar_poscontrol This demo simulates activation reasons with a
Stateflow chart triggering various RTE events. Signals are
automatically adjusted to match the values specified in the DD.
Related Documentation
TargetLink Demo Models)
n AR_POSCONTROL (
n Basics on Activation Reasons (
TargetLink AUTOSAR Modeling
Guide)
Poscontrol The demo now shows the connection of TargetLink
function blocks with DD Function and DD Signature objects in the
Data Dictionary to ensure interface consistency between functions
and the modeled subsystems.
214
s
New Features and Migration
November 2015
s New Features of TargetLink 4.1 and TargetLink Data Dictionary 4.1 t
Related Documentation
TargetLink Demo Models)
n POSCONTROL (
n Centrally Specifying and Synchronizing Function System Signatures
(
TargetLink Customization and Optimization Guide)
API Functions and Hook Functions
Where to go from here
Information in this section
New API Functions
215
New Hook Functions
216
New API Functions
Exporting FMUs
The tl_generate_fmu(propertyName, propertyValue, ...) API
function lets you export functional mock-up units (FMUs) to use in
FMI-compliant tools.
Related documentation
n Definition of the FMI Standard and FMUs (
TargetLink
Interoperation and Exchange Guide)
n Basics on Exporting FMUs from TargetLink (
TargetLink
Interoperation and Exchange Guide)
n How to Generate an FMU to use in an FMI-Compliant Tool
(
TargetLink Interoperation and Exchange Guide)
n TargetLink FMU Export (
Switching SIL compilers
TargetLink Tool and Utility Reference)
The tlProductionCodeSILCompiler API function lets you set or
change SIL compilers.
Related documentation
n How to Set or Change MEX and SIL Compilers (
TargetLink
Preparation and Simulation Guide)
New Features and Migration
November 2015
215
t
s TargetLink t
Setting requirement
information at blocks
The tlRequirementInfo API function lets you manage DD-based
requirement information at TargetLink blocks and Stateflow objects.
tlRequirementInfo is used instead of tl_set() or tl_get() for this
data.
Related documentation
n Basics on Using DD Based Requirement Information (
TargetLink
Interoperation and Exchange Guide)
Preparing the simulation of
transformation error logic
The tlTransformerError API function helps you prepare AUTOSAR
models for simulation that contain transformation error logic.
Related documentation
n Basics on Data Transformation (
TargetLink AUTOSAR Modeling
Guide)
n How to Model and Simulate Transformation Error Logic in Sender-
Receiver Communication (
Guide)
TargetLink AUTOSAR Modeling
New Hook Functions
Generating and
synchronizing system
signatures
TargetLink provides the following new hook functions to customize
subsystem generation from the DD:
n tl_pre_add_ddsignatureport_hook This hook function is called
before a new DD SignaturePort object is added to the specified DD
Signature object.
n tl_post_add_ddsignatureport_hook This hook function is called
after a new DD SignaturePort object is added to the specified DD
Signature object.
n tl_pre_sync_systemsignatureport_hook This hook function is
called before an existing Port block is synchronized with the
corresponding DD Signature object.
n tl_post_sync_systemsignatureport_hook This hook function is
called after an existing Port block is synchronized with the
corresponding DD Signature object.
Related documentation Basics on Using Hook Functions
( TargetLink Customization and Optimization Guide)
Centrally Specifying and Synchronizing Function System Signatures
( TargetLink Customization and Optimization Guide)
216
s
New Features and Migration
November 2015
s New Features of TargetLink 4.1 and TargetLink Data Dictionary 4.1 t
Initializing buses via DD
Variable objects
TargetLink provides the following customization file to customize the
initialization of buses via Simulink IC structures:
n tlGetBusStructMapping This customization file gets the bus struct
mappings (DD Variable objects to Simulink.Bus objects).
This customization file lets you you to map DD-based struct variables
to Simulink.Bus objects.
Related documentation How to Manually Create a Mapping
Between a DD Variable and a Simulink Bus ( TargetLink
Customization and Optimization Guide)
New Features and Migration
November 2015
217
t
s TargetLink t
Migrating to TargetLink 4.1 and TargetLink
Data Dictionary 4.1
Upgrade process
To upgrade to a new TargetLink version you have to adjust the
following:
n Your data dictionaries
n Your models
n Your scripts and hook functions
To migrate libraries/models from TargetLink versions older than 4.0,
you also have to perform the migration steps of the TargetLink
versions in between. Refer to the previous TargetLink Migration
Guides available on your DVD.
You can launch an upgrade manually by using the tlUpgrade API
function. For detailed instructions, refer to How to Manually Upgrade
Libraries and Models Via the API on page 222.
Carefully read all of the following information and modify your tool
chain accordingly.
Where to go from here
218
s
Information in this section
Upgrade of Models, Libraries, and Data Dictionaries
219
Code Generator Options
223
API Functions and Hook Functions
226
AUTOSAR-Related Migration Aspects
226
Code Changes
227
Other
242
Obsolete
244
Changes in Future TargetLink Versions
245
New Features and Migration
November 2015
s Migrating to TargetLink 4.1 and TargetLink Data Dictionary 4.1 t
Upgrade of Models, Libraries, and Data Dictionaries
Where to go from here
Information in this section
Migrating to TargetLink 4.1
219
How to Upgrade a Data Dictionary with Included DD Files
220
How to Manually Upgrade Libraries and Models Via the
API
222
Migrating to TargetLink 4.1
Indirect upgrade from
TargetLink 2.x
Libraries, models, and DD files from TargetLink versions prior to
TargetLink 3.1 cannot be upgraded directly.
However, you can perform an indirect upgrade. First, migrate older
libraries, models, and DD files to TargetLink 3.5. Then you can
upgrade them to TargetLink 4.1.
Direct upgrade from
TargetLink 3.1 or higher
TargetLink 4.1 automatically upgrades models, libraries, and Data
Dictionaries created with TargetLink 3.1 or higher.
The following dialogs can appear during the upgrade process of the
Data Dictionary file:
New Features and Migration
November 2015
219
t
s TargetLink t
User interaction In the following cases, user interaction is required:
n Legacy libraries never prepared for TargetLink on page 220
n Migrating from TargetLink 32-bit to TargetLink 64-bit
on page 220
n DD files with included partial DD files on page 220
n How to Manually Upgrade Libraries and Models Via the API
on page 222
Legacy libraries never
prepared for TargetLink
Libraries created with TargetLink 3.x or 4.0 that were never prepared
using the tl_prepare_system(propertyName, propertyValue, ...)
( TargetLink API Reference) API function cannot be upgraded
automatically by TargetLink 4.1.
Solution
1. Open the library in the prior TargetLink version and prepare it for
the upgrade by using tl_prepare_system(propertyName,
propertyValue, ...) ( TargetLink API Reference).
2. Save the library.
3. Open the library with TargetLink 4.1.
Related documentation
n How to Make TargetLink User Libraries Upgrade-Capable
(
Migrating from TargetLink
32-bit to TargetLink 64-bit
TargetLink Orientation and Overview Guide)
Custom code S-functions built with 32-bit TargetLink versions do not
work with 64-bit versions of TargetLink and vice versa.
Solution Initiate a rebuild of all custom code S-functions using the
tlUpgrade('Model',<MyModel>,'CheckModel','FixIssues') (refer to
tlUpgrade(propertyName, propertyValue, ...) ( TargetLink API
Reference)) API function.
DD files with included
partial DD files
To upgrade DD files with included partial DD files, refer to How to
Upgrade a Data Dictionary with Included DD Files on page 220.
How to Upgrade a Data Dictionary with Included DD Files
Objective
220
s
If you open a TargetLink model with an old Data Dictionary file that
was not upgraded, you have to upgrade the Data Dictionary file.
New Features and Migration
November 2015
s Migrating to TargetLink 4.1 and TargetLink Data Dictionary 4.1 t
Method
To upgrade a Data Dictionary with included DD files
1 Open the model and the referenced TargetLink Data Dictionary, or
type dsdd('Open',<DDFile>) in the MATLAB Command Window.
The Data Dictionary needs upgrading dialog automatically opens if
an earlier DD version is involved.
2 Select No in the upgrade dialog.
3 Under /Config/DDIncludeFiles, set the AutoLoad and AutoSave
properties for each included DD file as shown in the following
screenshot.
This ensures that after the Data Dictionary and the included DD
files were upgraded, the upgraded included DD files are saved
when the Data Dictionary is saved. You can set these properties
for a large number of included DD files via the Object Explorer.
You can also use the Point of Inclusion dialog to set the
included DD file properties.
4 Start the Data Dictionary upgrade (with the included DD files) via
Tools – Upgrade current DD in the DD Manager, or enter
dsdd('Upgrade') in the MATLAB Command Window.
New Features and Migration
November 2015
221
t
s TargetLink t
5 Save the Data Dictionary (with write permission to the relevant DD
file). This completes the upgrade of the DD file and the included
partial DD files.
Result
When you open the DD file again, the upgrade dialog does not open,
because the DD file and the included partial DD files are up-to-date.
After the files were properly upgraded, you might want to restore the
old settings for the included DD files.
How to Manually Upgrade Libraries and Models Via the API
Objective
222
s
You can manually update libraries and models via the
tlUpgrade(propertyName, propertyValue, ...) ( TargetLink API
Reference) API function and save them afterwards, e.g., to prepare a
New Features and Migration
November 2015
s Migrating to TargetLink 4.1 and TargetLink Data Dictionary 4.1 t
central upgrade of libraries and models in a tool chain scenario with
several users.
When upgrading models and libraries, first upgrade models
or libraries that do not reference any other libraries, i.e.,
the blocks/subsystems they contain have no links to other
libraries. Start with the bottom library and then upgrade
the libraries above it in ascending order.
For details on libraries that were never prepared, refer to Legacy
libraries never prepared for TargetLink in Migrating to TargetLink 4.1
on page 219.
Method
To manually upgrade libraries and models via the API
1 In the MATLAB Command Window, type
dsdd_manage_project('Open','<name>.dd') to load the required
and already upgraded DD project file (one way to upgrade DD
project files is to use the dsdd('Upgrade'[,<DD_Identifier>])
command, refer to Upgrade ( TargetLink Data Dictionary
Reference)).
2 Type tlUpgrade('Model', '<Model|Library>.mdl',
'CheckModel','FixIssues') to upgrade single models or libraries.
3 Save the upgraded model or library files, e.g., Library.mdl.
4 Repeat steps 2 and 3 for all other models or libraries.
Result
You upgraded your models and libraries.
Code Generator Options
Migration Aspects Regarding Code Generator Options
Removed Code Generator
option
The MPC5xx-specific (TOM-specific)
EnableLogicalOperationOptimisation Code Generator option was
removed from TargetLink:
Removed Option
Replacement Option
Compatibility Setting
EnableLogicalOperationOptimisation
None
None
New Features and Migration
November 2015
223
t
s TargetLink t
With TargetLink 4.1, this option was removed together with MPC5xxsupport.
The following Code Generator options changed with TargetLink 4.1:
Changed Code Generator
options
n None
Recommended
compatibility settings
Make the following settings for new TargetLink 4.1 Code Generator
options to ensure best possible downward compatibility:
n None
Basics on changed defaults
The settings of the Code Generator options are stored with the model
(model-based option storage). In addition, you can store user-defined
sets of Code Generator options in DD CodegenOptions objects (DDbased option storage). You can use DD CodegenOptions-objects as a
central source for overwriting model-based option settings.
If a model-based option value equals the old default value, it is
automatically changed to the new default value during upgrade. If a
DD-based option value equals the old default value, it is not changed
to the new default value during upgrade but keeps the old value.
Option value = old default If Code Generator options equal
default values in the former TargetLink version and the new
TargetLink version uses modified default values, note the following
points:
n Model-based option:
If you want to keep the old default values, you must reset them
manually.
n DD-based option:
If you want to use the new default values, you must adjust them
manually.
The following table is an example describing the impact of a
TargetLink upgrade (TLOld to TLNew) on three arbitrary option values:
9, 11, and 13. The table illustrates two basic migration scenarios:
n Scenario #1: New default = old default
The default value of a Code Generator option has not changed in
the new TargetLink version, i.e., the default value remains 9.
None of the option values is changed.
n Scenario #2: New default ≠ old default
The default value of a Code Generator option changed with the
new TargetLink version, i.e., the default value changed to 11.
224
s
New Features and Migration
November 2015
s Migrating to TargetLink 4.1 and TargetLink Data Dictionary 4.1 t
Option
Storage
Model-based
DD-based
Option Value (TLOld)
Option Value (≤ TLNew)
Default = 9
Default = 9
(Scenario #1)
Default = 11
(Scenario #2)
91)
91)
112)
11
11
111)
13
13
13
9
9
93)
11
11
11
13
13
13
1)
Option value is not stored with the model because it equals the default.
Manual reset might be necessary.
3) Manual adjustment might be necessary.
2)
Option value = new default If Code Generator options did not
equal default values in the former TargetLink version (A) but do in the
new TargetLink version (B), TargetLink assumes that you intentionally
specified the default value in the new TargetLink version. The same
applies if the default changes again in the next TargetLink version (C).
Upgrading TLA ⇒ TLB ⇒ TLC and upgrading TLA ⇒ TLC can
cause different option values (see the following table).
Suppose the default values for TargetLink versions A, B, and C read 9,
11, and 13. If an option value equaled 11 in version A, an upgrade to
version C would change the option value as follows:
Upgrade
Strategy
Option Value TLA
Default = 9
Option Value TLB
Default = 11
A⇒B⇒C
11 (≠ default)
11 (= default)1)
13 (= default)1)
A⇒C
11 (≠ default)
—
11 (≠ default)
1)
Option Value TLC
Default = 13
Option value is not stored with the model, because it equals the default.
New Code Generator
options
For more details on new Code Generator options, refer to New Code
Generator Options on page 208.
Related topics
References
• Code Generator Options (
New Features and Migration
TargetLink Block and Object Reference)
November 2015
225
t
s TargetLink t
API Functions and Hook Functions
Changes in TargetLink and TargetLink Data Dictionary API
Functions
Custom look-up functions
For the tlscript API command, a new property is available which
relates to the dimension of input signals. This lets you implement a
last index state variable for the Local search table search method, for
example.
n InheritDimensionFromInput
Related documentation
n Permissible Properties for Variables (
TargetLink API Reference)
n Basics on Using Custom Look-Up Functions (
TargetLink
Preparation and Simulation Guide)
AUTOSAR-Related Migration Aspects
AUTOSAR-Related Migration Aspects
Name macros in name
templates of runnable
objects
With TargetLink 4.1, the NameTemplate property of Runnable
objects must not contain name macros other than $D.
Removed options in
import/export
The Merge and EnablePackageSupport options are obsolete.
226
s
The corresponding properties in /Pool/Autosar/Config/ImportExport
were removed.
New Features and Migration
November 2015
s Migrating to TargetLink 4.1 and TargetLink Data Dictionary 4.1 t
TargetLink now always does the following:
n Merges Data Dictionary elements that belong to one software
component but reside in different subsystems into one merged file
(Merge = On).
n Imports and exports the package information provided in
AUTOSAR files and the Data Dictionary (EnablePackageSupport =
On).
Modify your scripts accordingly.
RTE error code macros in
the Data Dictionary
The variables representing RTE error code macros in
the /Pool/Variables/AUTOSAR/Std_ReturnType variable group and the
predefined variable
class /Pool/VariableClasses/AUTOSAR/RTE/RTE_ERROR_CODE now have
their ModuleRef property set to Rte_Frame.
This is in accordance with the AUTOSAR standard, which requires
these macros to be defined in Rte.h.
The new value of each variables' ModuleRef property is set
automatically during a Data Dictionary upgrade.
This can result in an #include Rte.h in production code if one of
these variables is referenced at a block in your model.
Code Changes
Code Changes
Code generated from
Stateflow charts
In order to follow special Stateflow semantics more precisely (e.g., to
avoid MIL/SIL differences for certain modeling styles), code generated
from Stateflow charts might be less efficient in the following
Stateflow chart scenarios:
n Graphical functions imported from other charts are called.
n Function call output events occur.
As a result, constants might not be propagated, or unused code
fragments might not be removed.
New Features and Migration
November 2015
227
t
s TargetLink t
To change this, assign a function class whose SIDE_EFFECT_FREE
optimization flag is enabled to the imported graphical functions and
to the subsystems/charts that are triggered by function call output
events.
You must guarantee that the function is actually sideeffect-free. For example, side-effect-free functions do not:
n Modify global variables
n Call functions that are not side-effect-free
Assignment blocks in
iterated subsystems
If multiple Assignment blocks reside in an iterated subsystem, only
one first iteration flag is implemented, which increases code
efficiency. As a result, the name of such flags changes, for example:
TargetLink ≤ 4.0
TargetLink 4.1
{Subsystem_AssignmentBlock}_FirstIter
{Subsystem_IterationBlock}_FirstIter
The flag is explicitly initialized at the beginning of the iteration loop:
…_FirstIter = 1
The flag is reset at the end of the loop:
…_FirstIter = 0
Assignment blocks in nested subsystems If at least one
Assignment block resides in an atomic subsystem and this atomic
subsystems resides in an iterated subsystem, the following variable
scopes are assigned to the iteration variable:
n Global if the function of the atomic subsystem is not inlined.
n Local if the function of the atomic subsystem is inlined.
Code patterns for saturated
additions or subtractions
For TargetLink 4.1, compute-through-overflow (CTO) code patterns
are never used in saturation code of additions or subtractions, if the
ExploitComputeThroughOverflow Code Generator option is set to
NEVER. The following example shows an addition out = in + Const
with I16Out = I16In +1:
TargetLink ≤ 4.0
TargetLink 4.1
if (I16In > 32766) { /* Max(Result type) - Const */
I16Out = 32767; }
else {
I16Out = (Int16) (( /* CTO */ (UInt16) I16In) + 1);
if (I16In > 32766) { /* Max(Result type) - Const */
I16Out = 32767; }
else {
I16Out = (Int16) (I16In + ((Int16) 1)); }
}
If the ExploitComputeThroughOverflow Code Generator option is set
to Always or to Optimized, the production code remains unchanged
compared to previous versions.
228
s
New Features and Migration
November 2015
s Migrating to TargetLink 4.1 and TargetLink Data Dictionary 4.1 t
No Void typedef
For improved MISRA-C compliance, TargetLink by default no longer
generates the Void typedef within tl_basetypes.h. It uses the
standard C void data type instead.
You can change this back to the old behavior (using Void) by editing
the TargetConfig.xml file that belongs to your target-compiler
combination.
This file is located in
<TL_InstRoot>\Matlab\Tl\TargetConfiguration\<MicrocontrollerFam
ily>\<CompilerFamily> or similar in the TSM extension folder.
To instruct TargetLink, to generate the Void base type in
tl_basetypes.h again, do the following:
1. Open the TargetConfig.xml file that belongs to your targetcompiler combination.
2. Locate the ddObj XML element whose name attribute is set to
Void.
3. Locate the child ddProperty XML element whose name attribute is
set to CodedType.
4. Change its value from Use standard C void type to void.
5. Save the TargetConfig.xml file and generate code.
Additional default scaling
code comments
For readability, TargetLink now places additional code comments
concerning default scalings at variable definitions:
TargetLink ≤ 4.0
TargetLink 4.1
Int16 SX1_OutPort1_FR_Actual;
Int16 SX1_OutPort1_FR_Actual /* LSB: 2^0 OFF: 0 MIN/MAX: -32768 .. 32767 */;
Encapsulation of
preprocessor #IF statements
TargetLink now encapsulates preprocessor #include directives by #IF
directives only if all of the included file's definitions and declarations
are encapsulated by #IF directives.
As an example, consider the following FuncDefModule.h header file:
extern GLOBAL Int16 SEnc1_Out1;
#if FLAG
extern void Encapsulated(void);
#endif
New Features and Migration
November 2015
229
t
s TargetLink t
TargetLink's generated code changes as follows:
TargetLink ≤ 4.0
TargetLink 4.1
#if FLAG
#include "FuncDefModule.h"
#endif
#include "FuncDefModule.h"
…
void TL_Root(void)
{
#if FLAG
Encapulated(Sa1_InPort);
#endif
void TL_Root(void)
{
#if FLAG
Encapulated(Sa1_InPort);
#endif
SEnc1_Out1 = …
…
SEnc1_Out1 = …
}
}
Code comments at indices
of vector or matrix
variables
TargetLink ≤ 4.0
For improved readability, the code comments concerning the initial
values of vector or matrix variables have changed:
TargetLink 4.1
Vectors
Int16 MyVar[3] =
{
/*[0..2]*/ 61, 52, 43
};
Int16 MyVar[3] =
{
/* [0..2] */ 61, 52, 43
};
Matrices
Int16 MyVar[2][3] = {
{
/*[0..2]*/ 61, 52, 43
},
{
/*[0..2]*/ 34, 25, 16
}
};
Identifier of implicitly
generated struct types
Int16 MyVar[2][3] = {
{
/* [0][0..2] */ 61, 52, 43
},
{
/* [1][0..2] */ 34, 25, 16
}
};
TargetLink's identifiers for implicitly generated struct types now
comply with the AUTOSAR standard.They now comply with the
following regular expression:
[a-zA-Z]([a-zA-Z0-9]|_[a-zA-Z0-9])*_?
For typedef identifiers that you specified by using the $C, $R, or $S
name macros, TargetLink now does the following:
n Removes underscores at the beginning of the identifier of
implicitly generated typedefs
n Replaces double underscores by a single one
230
s
New Features and Migration
November 2015
s Migrating to TargetLink 4.1 and TargetLink Data Dictionary 4.1 t
TargetLink ≤ 4.0
TargetLink 4.1
/* update(s) for inport
Subsystem/Func/In1_with_super_long_name_to_break_limit */
Rte_Pim_ACP_a(instance)->Sa2_In1_with_s__to_break_limit =
(sint16) DataElement;
/* update(s) for inport
Subsystem/Func/In1_with_super_long_name_to_break_limit */
Rte_Pim_ACP_a(instance)->Sa2_In1_with_s_to_break_limit =
(sint16) DataElement;
Identifiers that consist only out of underscores or that begin with an
underscore immediately followed by a numeral are not changed.
These typedefs are not generated into an autogenerated per instance
memory (PIM):
TargetLink ≤ 4.0
TargetLink 4.1
/* update(s) for inport Subsystem/Func/In1 */
Rte_Pim_ACP_a(instance)->_1Var = (sint16) DataElement;
/* update(s) for inport Subsystem/Func/In1 */
_1Var = (sint16) DataElement;
IF-variable for outports of
conditionally executed
systems
To eliminate possible differences between MIL and SIL simulations,
TargetLink now generates an additional variable, IF_<Suffix>, for
unenhanced outports of conditionally executed subsystems if these
are preceded by one of the following blocks:
n Data Type Conversion
n (Matrix) Concatenate
n Permute Dimensions
n Reshape
n Selector
n Bus Assignment
n Zero Order Hold
n Rate Transition
Code comments for
optimization
For improved readability, TargetLink's code comments for
optimization changed. The chain A replaced by … replaced by … X is
now replaced by A replaced by X:
TargetLink ≤ 4.0
TargetLink 4.1
/* Gain: foo/Gain
Variable 'Sa1_Gain' replaced by 'Aux_f'
Variable 'Aux_f' replaced by 'Aux_F32_e' */
/* Gain: foo/Gain
Variable 'Sa1_Gain' replaced by 'Aux_F32_e' */
No access functions for
auxiliary variables
You can no longer define access function templates (AFTs) for
auxiliary variables that result from access functions. The former
behavior created more access functions than desired or even caused a
near-infinite loop during code generation.
New Features and Migration
November 2015
231
t
s TargetLink t
New CTO avoidance macros
for additions and
subtractions
To improve compliance with MISRA-C, TargetLink's Fixed-Point Library
provides new macros for additions and subtractions for operands ≤
16 bit. These macros are generated only when you suppress CTO
code patterns (via the ExploitComputeThroughOverflow Code
Generator option). The macro names always end with _PROT and
contain an I16 or U16.
TargetLink ≤ 4.0
TargetLink 4.1
C__I32ADDI32U32_PROT((Int32) Sa1_I16InPort, Sa1_U32InPort)
C__I32ADDI16U32_PROT(Sa1_I16InPort, Sa1_U32InPort)
Writing dereferences in
logical operations in
parentheses
Dereferences in logical operations are now written in parentheses to
comply with MISRA-C.
TargetLink ≤ 4.0
TargetLink 4.1
Sa1_OutPort1 = (Int16) (*In2 || *In1);
Sa1_OutPort1 = (Int16) ((*In2) || (*In1));
MinMax block code pattern
For MinMax blocks with more than two inputs or an input which has
more than two signals, the code pattern changes when the first two
inputs or signals do not fit in the output. This can mean one of the
following:
n The order of the comparison changes.
n The output is initialized with minimum or maximum values before
comparing it with each signal.
Status of RTE_Invalidate
TargetLink ≤ 4.0
TargetLink 4.1
if(InvalidateCondition) {
Rte_Invalidate_x_y();
status = 0;
}
else {
status = Rte_Write_x_y();
}
if(InvalidateCondition) {
status = Rte_Invalidate_x_y();
}
else {
status = Rte_Write_x_y();
}
Changed subsystem naming
for incremental code
generation
232
s
TargetLink can now evaluate the return value of the Rte_Invalidate
RTE API function. The following table shows a code sample of a
Rte_Invalidiate call for a SenderComSpec block with enabled
Invalidate and Status ports:
The code of subsystems configured for incremental code generation
that were converted from referenced models might now be stored at
a different location than in previous versions. For details, refer to
Various Migration Aspects on page 242.
New Features and Migration
November 2015
s Migrating to TargetLink 4.1 and TargetLink Data Dictionary 4.1 t
Base types for logging
variables
If an auxiliary variable is created for a Sink block for logging, it always
gets a TargetLink base type (in AUTOSAR: a platform type). However,
logging code is not production code.
Abs pattern changes
For better readability, condensed fixed-point Abs patterns are no
longer supported. Instead, if-else expressions are used (e.g., an
unscaled Int16 Abs with unscaled Int16 input).
TargetLink ≤ 4.0
TargetLink 4.1
Sa1_OutPort = Sa1_InPort;
if (Sa1_InPort < 0) {
Sa1_OutPort = -Sa1_OutPort;
}
if (Sa1_InPort >= 0) {
Sa1_OutPort = Sa1_InPort;
}
else {
Sa1_OutPort = (Int16) (-Sa1_InPort);
}
The following changes might apply:
n Subsequent code patterns might change because another (usually
better) range information is inherited: e.g., after the paragraph is
followed by a sign, its negative branch is omitted, because the
output of the Abs is always a positive value.
n With saturation, additional 64-bit operations are generated when
KeepSaturationStatements is set.
n In Stateflow expressions like FloatOutVar = abs (IntVar), another
code pattern is generated (with the ? operator).
Additional casts in
nonscalar AUTOSAR or
indirect function reuse
Whenever a pointer with indices on the left side is accessed, there
might be additional casts that now better conform with TargetLink's
general casting style:
TargetLink ≤ 4.0
TargetLink 4.1
pISV->pISV_SL1_0_tp->pSL1_ImplicitOut1[Aux_S32] = 0;
pISV->pISV_SL1_0_tp->pSL1_ImplicitOut1[Aux_S32] = (sint16) 0;
In this particular case, the cast is created because the
ground symbol was originally on the right side.
New Features and Migration
November 2015
233
t
s TargetLink t
Overflow-free, unary minus
The following example shows code for an Abs block with Int16 input
and UInt16 output:
TargetLink ≤ 4.0
TargetLink 4.1
if(I16In >= 0) {
…
} else {
U16Out = (UInt16)(-I16In)
}
This pattern is critical, because the value -32768 (INT16MIN) might cause an undefined
overflow. 32768 does not fit in a 16-bit-platform int and the minus is calculated in
int.
if(I16In >= 0) {
…
} else {
if (I16In == -32768) {
U16O7ut = 32768;
} else {
U16Out = (UInt16)(-I16In)
}
}
Now the smallest negative value is used.
The second if-else might be replaced by a ? operator.
… (I16In == -32768) ? 32768 : (UInt16)(-I16In)
This is always the case when the unary minus is not the last
operation on the right side of an assignment. A typical
example is an Abs block with a different input/output
scaling. The minus is then the operand of the rescaling
(shift/division). As a result, the ? operator is used.
The following expressions and blocks can be affected:
n Stateflow expressions with unary minus
n Abs blocks
n Gain blocks with negative gain values
n Product blocks with a negative constant default
n Sum blocks with the corresponding settings
Saturation macros:FIT
macro calls replace SAT
macro calls
There are two kinds of saturation macros in TargetLink's Fixed-Point
Library:
n FIT macros that perform saturation on range limits (implemented
range)
n SAT macros that perform saturation on user-defined limits (e.g., in
the Saturation block or in Stateflow)
Prior to TargetLink 4.1, in rare cases a SAT macro was called although
a saturation on range limits was performed. This is now changed for
consistency and for improved MISRA-C compliance.
The following example shows saturation in Stateflow with
UInt16 U16Out ; // LSB = 0.002 and checkmax = 1
U16Out = U16Out + I8In;
234
s
New Features and Migration
November 2015
s Migrating to TargetLink 4.1 and TargetLink Data Dictionary 4.1 t
TargetLink ≤ 4.0
TargetLink 4.1
Aux_I32 = …
U16Out = C__U16SATI32_SATb(Aux_I32, 65535 /* 131.07 */, 0)
Aux_I32 = …
U16Out = C__U16FITI32_SAT(Aux_I32, 65535 /* 131.07 */ )
Saturation macros
When calling SAT macros that are generated for the Saturation block
or Stateflow, the type of the limits (parameter 2,3) is adjusted to
match the type of the output if the limits have a variable class that is
different from the default.
TargetLink ≤ 4.0
TargetLink 4.1
GLOBAL Int32 Sb1_Saturation_lower = 0;
GLOBAL Int32 Sb1_Saturation_upper = 100;
GLOBAL Int32 Sb1_Saturation_lower = 0;
GLOBAL Int32 Sb1_Saturation_upper = 100;
Int16 Aux_S16;
Int16 Aux_S16_a;
UInt16 Aux_U16;
UInt16 Aux_U16_a;
Aux_S16 = (Int16) Sb1_Saturation_upper;
Aux_S16_a = (Int16) Sb1_Saturation_lower;
Sb1_OutPort = C__U16SATI16_SATb(Sb1_InPort, Aux_S16,
Aux_S16_a);
Accessing matrix variables
within loops
Aux_U16 = (UInt16) Sb1_Saturation_upper;
Aux_U16_a = (UInt16) Sb1_Saturation_lower;
Sb1_OutPort = C__U16SATI16_SATb(Sb1_InPort,Aux_U16,
Aux_U16_a);
For code efficiency, accessing matrix variables within loops can now
be replaced by scalar variables. In certain cases, matrix and vector
variables are replaced by one or more scalar variables, even if they are
accessed from outside the loops.
TargetLink ≤ 4.0
TargetLink 4.1
Int16 vec[…];
vec[0] = …
… = v[0];
Int16 scalar;
scalar = …
… = scalar;
loop (i = 1:n) {
v[i] = …
= v[i];
}
loop (i = 1:n) {
scalar = …
… = scalar;
}
Or, if more scalar variables are introduced:
Int16 scalar1;
Int16 scalar2;
scalar1 = …
… = scalar1;
loop (i = 1:n) {
scalar2 = …
… = scalar2;
}
Accessing matrix variables
outside of loops
Accessing matrix variables from outside the loops can now be
replaced by one or more scalar variables. The combination of accesses
within and outside of loops can also now be optimized. In addition,
New Features and Migration
November 2015
235
t
s TargetLink t
unknown accesses for indices can also be optimized if the index
expression accesses is built up identically.
During replacement by scalar variables, memory savings typically
emerge (in the aggregate). However, in some situations it is not
possible to reduce memory consumption: i.e., the new scalar variables
use as much memory as the initial multidimensional variable.
This takes place only for completely unrolled code, precisely if:
n (For a vector variable) Number of elements < LoopUnrollThreshold
n (For a matrix variable) Number of elements < LoopUnrollThreshold2
Accesses from …
TargetLink ≤ 4.0
TargetLink 4.1
Outside of loops, analog for vectors
M[0][0] = …;
…
… = M[0][0];
Aux = …;
…
… = Aux;
Within and outside (of partially unrolled)
loops, analog for vectors
M[0][0] = …;
loop {
M[1][i] = …
M[2][i] = …
…
… = M[1][i];
… = M[2][i];
}
Aux = …;
loop {
Aux_a = …
Aux_b = …
…
… = Aux_a;
… = Aux_b;
}
Outside of loops, analog for matrices
V[<expr>] = …;
…
… = V[<expr>];
Aux = …;
…
… = Aux;
Tangents code patterns
The tangents code pattern from within Stateflow and for the
TargetLink Trigonometric and Math blocks was modified.
Tangents within Stateflow Up to TargetLink 4.1, saturation was
erroneously omitted, especially for saturated expressions.
Now the following rules apply:
n If a tangent is used in an assignment such as out = tan(expr),
then the tangent is calculated in fixed-point when out has a fixedpoint type.
n In all other cases, e.g., complex expressions, TargetLink performs
tangent calculations in floating-point. If a pure fixed-point context
is detected during code generation, an error message occurs.
Tangents for the Trigonometric and Math blocks Now,
unnecessary saturations are omitted by default if the result is either
32-bit or 16-bit with LSB >= 2-14. Therefore, Omitted Saturation
comments are dropped in some cases.
236
s
New Features and Migration
November 2015
s Migrating to TargetLink 4.1 and TargetLink Data Dictionary 4.1 t
Assignments to bitfields
Assignment of Stateflow state IDs If Use bitfields in state
machines = On and there is a multi-valued state variable, casts to
unsigned int are now superfluous for Stateflow state IDs:
TargetLink ≤ 4.0
TargetLink 4.1
SIBFS_Chart_a.Ca1_Chart_ns = (unsigned int) Ca5_OFF_id;
SIBFS_Chart_a.Ca1_Chart_ns = Ca5_OFF_id;
In addition, the class default settings of Stateflow state IDs has
changed. Stateflow state IDs become global macros in the generated
code without the initial value being cast.
Bitfield semantic for genuine bitfields TargetLink evaluates
whether a bitfield is a Boolean bitfield (UseGlobalBitfieldsForBooleans
= On) or a genuine bitfield (Base type = Bitfield). For TargetLink
versions ≤ 4.0, a bool semantic is applied to both, Boolean bitfields
and genuine bitfields. If required, != 0 is added. As of TargetLink
version 4.1, a bitfield semantic is applied to genuine bitfields:
TargetLink ≤ 4.0
TargetLink 4.1
BooleanBitfield = (Int16Var != 0)
BooleanBitfield = (Int16Var != 0)
GenuineBitfield = (Int16Var != 0)
GenuineBitfield = (Int16Var & 1)
The bitfield semantic can bealso applied to constants, for example:
GenuineBitfield = 3 & 1
Code optimization is feasible only if a constant equals the values 0 or
1.
Immediate assignment to bitfields An immediate assignment to
a bitfield is generated if the right side is one of the following:
n A bitfield
n A bool expression
n A & 1 operation
n A Stateflow state ID macro
For the assignment of floating-point or scaled operands to
genuine bitfields, TargetLink no longer generates != 0 but
returns an error.
Better Z/N values for
rescaling
The algorithm for calculating the Z and N values has been improved.
This leads to code that is either more precise or more efficient with
calculations based on smaller bit widths:
TargetLink ≤ 4.0
TargetLink 4.1
Sb1_PRODUCT = (Int16) (((Int32) ((((Int32) Op1) * ((Int32)
Op2)) << 2)) / 39);
Sb1_PRODUCT = (Int16) (((Int32) ((((Int32) OP1) *
((Int32) Op2)) << 6)) / 625);
New Features and Migration
November 2015
237
t
s TargetLink t
Parameter tolerance is now more frequently used to
increase code efficiency. This means that a parameter
tolerance greater than 0 can result in code that is less
precise. If required, you can change this by reducing the
parameter tolerance.
Comparison of UInt32 and
Int32 variables
TargetLink now checks if the signed variable is negative and can avoid
64-bit macros when comparing UInt32 and Int32 variables:
TargetLink ≤ 4.0
TargetLink 4.1
C__I64COPYU32(U32Var, I64Var_hi, I64Var_lo);
C__I64COPYI32(I32Var, I64Var2_hi, I64Var2_lo);
if(C__LE64(I64Var_hi, I64Var_lo, I64Var2_hi, I64Var2_lo))
For <=, <, and !=:
if(I32Var < 0 || ((UInt32)I32Var <op> U32Var))
For >, >=, and
==:
if(I32Var >= 0 && ((UInt32)I32Var <op> U32Var))
As an effect, superfluous logical branches can be eliminated from the
generated code by subsequent optimization.
Comparison of 64-bit
variables
When comparing two 64-bit variables that both have an internally
calculated worst-case range of ≤ 32-bit, TargetLink now also
considers the upper 32 bits. For example, Int64Var could become
negative:
TargetLink ≤ 4.0
TargetLink 4.1
if(Int64Var_lo < Int64Var2_lo)
if(C__LT(Int64Var_hi, Int64Var_lo, Int64Var2_hi, Int64Var2_lo))
This change is particularly relevant for the Discrete-Time Integrator
block.
Elimination of intermediate
variables
TargetLink can now perform intermediate variable elimination in such
a way that a computation followed by an index selection is no longer
performed for the complete width, only for the desired element.
TargetLink ≤ 4.0
TargetLink 4.1
VectorVar[<iteration range>] = expression(<iteration range>)
… = VectorVar[cnst]
… = expression(cnst)
The following conditions must be met:
n VectorVar[cnst] is the only usage of
VectorVar[<iteration range>].
n Index cnst is a subset of the iteration range. This is
fulfilled if <iteration range> covers all elements.
Assignment blocks in For
Iterator subsystems
238
s
If an Assignment block resides in an atomic subsystem that resides in
a For Iterator subsystem, the following applies:
New Features and Migration
November 2015
s Migrating to TargetLink 4.1 and TargetLink Data Dictionary 4.1 t
If the block property Omit dispensable initializations is set to off, the
initialization via the Y0 signal is performed only during the first
sample step. This is in accordance with the Simulink behavior.
Division-by-zero check for
floating-points
TargetLink improves compliance with MISRA-C:
No superfluous rescaling TargetLink avoids irrelevant rescaling:
TargetLink ≤ 4.0
TargetLink 4.1
if ((((Float32) Sa1_ScaledDenom) * 0.25F) != 0) {
Sa1_OutPort1 = Sa1_F32Num_ / (((Float32) Sa1_ScaledDenom)
* 0.25F);
} else { …
if (Sa1_ScaledDenom != 0) {
Sa1_OutPort = Sa1_F32Num / (((Float32)
Sa1_ScaledDenom) * 0.25F);
} else { …
Auxiliary variables for offsets TargetLink uses auxiliary variables:
TargetLink ≤ 4.0
TargetLink 4.1
if (((((Float32) Sa1_ScaledDenomWithOffset) * 0.25F) +
42.F) != 0) {
Aux_F32 = (((Float32) Sa1_ScaledDenomWithOffset) *
0.25F) + 42.F;
Sa1_OutPort1 = Sa1_F32Num_ / ((((Float32)
Sa1_ScaledDenomWithOffset) * 0.25F) + 42.F);
if (Aux_F32 != 0.F) {
Sa1_OutPort1 = Sa1_F32Num_ / Aux_F32;
} else { …
} else { …
Subtractions with unsigned
result
For TargetLink ≤ 4.0, subtractions with an unsigned result were
turned into additions: e.g., U8Var = U8Var2 + 255;.
For improved readability with TargetLink 4.1, a subtraction remains a
subtraction if the constant fits the result type, U8Var = U8Var2 - 1;.
Calculations might be performed in smaller types.
TargetLink ≤ 4.0
TargetLink 4.1
U8Var = U8Var2 + 255;
U8Var = U8Var2 - 1;
Predefined AUTOSAR
variable classes
To suppress additional #include tl_defines.h directives, the
predefined AUTOSAR variables were changed: When updating
existing DD files, TargetLink sets the UseName property of predefined
AUTOSAR VariableClass objects to off if they reference a DD
AccessFunctionTemplate object.
This results in a different declaration or definition of variables that
have these variable classes:
TargetLink ≤ 4.0
TargetLink 4.1
extern EXPLICIT_IRV S16_LinPos Rte_Irv_Controller_LinPos
extern S16_LinPos Rte_Irv_Controller_LinPos
This might cause missing #include tl_defines.h directives.
New Features and Migration
November 2015
239
t
s TargetLink t
Code pattern for additions
and subtractions without
CTO
To increase efficiency and MISRA-C compliance, the code pattern of
additions and subtractions can change if all of the following
conditions are true:
n The ExploitComputeThroughOverflow Code Generator option is
set to never.
n The operands of the operation are unsigned.
n The operands of the operation have fewerl than 32 bits.
TargetLink ≤ 4.0
TargetLink 4.1
UInt8Var = (UInt8)((Int16)UInt8Var + (Int16)UInt8Var)
UInt8Var = (UInt8)(UInt8Var + UInt8Var)
UInt8Var = (UInt8)((Int16)UInt8Var - (Int16)UInt8Var)
UInt8Var = (UInt8)(UInt8Var - UInt8Var)
Definition of Data Store
Memory block variables
To increase consistency and user control, the definitions of
Data Store Memory block variables are now always made in the
module that the step function of the subsystem that contains the
Data Store Memory block is generated in.
Accordingly, the definitions of Data Store Memory block variables
might occur in a different header file if all of the following conditions
are true:
n The Data Store Memory block is placed in a subsystem that also
contains a nested subsystem.
n The nested subsystem contains a Data Store Read or
Data Store Write block that accesses the data store memory.
n The step functions of the subsystems are generated in different
modules:
n
n
The step function of the subsystem containing the
Data Store Memory block is generated into module A.
The step function of the subsystem containing the
Data Store Read or Data Store Write block is generated into
module B.
TargetLink ≤ 4.0
TargetLink 4.1
In certain modeling situations, TargetLink might have defined the
block variable of the Data Store Memory block in module B.
TargetLink now always defines the block variable of the
Data Store Memory block in module A.
Rounding of doubles in
Float32 comparisons
TargetLink's rounding behavior changed for literal values in Float32
comparison. This is due to the following reasons:
n Code is easier to understand because the value is used in the same
way as specified in the model.
240
s
New Features and Migration
November 2015
s Migrating to TargetLink 4.1 and TargetLink Data Dictionary 4.1 t
n More user control:
n
n
You can specify the rounded value in the model.
You can use C compiler options to control the rounding and
keep it consistent between TargetLink-generated production
code and legacy code.
In the following example, the value 0.1 is compared with a variable
whose data type is Float32:
0.1 > Float32Var
The following table shows TargetLink's rounding behavior:
TargetLink ≤ 4.0
TargetLink 4.1
Sa1_Relational_Operator = 0.1000000015F > Sa1_F32In;
Sa1_Relational_Operator = 0.1F > Sa1_F32In;
Double precision for Float32
values
For improved traceabilty between model and production code and
also because of the above stated rounding control, TargetLink now
generates literal values for Float32 with double precision and by
adding the F suffix. The following table shows an example of a
Float32 gain with GainValue = pi:
TargetLink ≤ 4.0
TargetLink 4.1
Sa1_OutPort = Sa1_InPort * 3.141592654F;
Sa1_OutPort = Sa1_InPort * 3.1415926535897931F;
This might cause more decimal places being printed in the generated
code if the value was not exactly given in float/single precision in the
model, as it was in TargetLink ≤ 4.0.
Improved code efficiency
With TargetLink 4.1, code efficiency has been improved. This might
also cause changes in the generated code, in comparison to older
TargetLink versions. For details, refer to Improved Code Efficiency
on page 196.
New Features and Migration
November 2015
241
t
s TargetLink t
Other
Various Migration Aspects
TargetLink Main Dialog
block
The Compare with reference command has been removed from the
context menu of the code generation units listed on the block's Code
Generation page.
Converting referenced
models
TargetLink's behavior when converting referenced models has
changed.
Referenced model to incremental subsystem When converting a
referenced model to a subsystem configured for incremental code
generation, the created subsystem is named as shown in following
table:
Referenced Model Reused?
< TargetLink 4.1
TargetLink 4.1
Yes
‑
Subsystem name = Model block name
No
Subsystem name = Model block name
Subsystem name = model name
Accordingly, there is a new storage location for the code that is
generated for the model configured for incremental code generation:
Referenced Model Before Conversion
(TL4.0 and TL4.1)
Converted Incremental Subsystem
(TL4.0)
Converted Incremental Subsystem
(TL4.1)
Generated code modules:
n <ModelName>.c1)
n <ModelName>.h1)
Name of the DD Subsystems object:
<ModelName>
Generated code modules:
n <ModelBlockName>.c1)
n <ModelBlockName>.h1)
Name of the DD Subsystems object:
<ModelBlockName>
Generated code modules:
n <ModelName>.c1)
n <ModelName>.h1)
Name of the DD Subsystems object:
<ModelName>
1)
242
s
If you did not directly specify a module name at the model's Function block.
New Features and Migration
November 2015
s Migrating to TargetLink 4.1 and TargetLink Data Dictionary 4.1 t
Incremental subsystem to referenced model TargetLink sets the
simulation mode of the referenced model as shown in the following
table:
< TargetLink 4.1
TargetLink 4.1
Accelerator
If the subsystem was converted from a
referenced model in TargetLink 4.1, the
simulation mode of the reconverted
referenced model is the same as the
simulation mode of the original referenced
model.
If the subsystem was converted with another
TargetLink version or was not converted at
all, the simulation mode of the referenced
model is set to Normal.
Related documentation
n tl_refmodel_to_subsystem(propertyName, propertyValue, ...)
( TargetLink API Reference)
n tl_subsystem_to_refmodel(propertyName, propertyValue, ...)
(
Explicitly modeled
saturation involving Float32
and fixed-point
TargetLink API Reference)
TargetLink cannot guess your intent if you model saturation involving
fixed-point or Float32 without using TargetLink's Saturation block
(e.g., by using the MinMax block instead). In such cases, keep in mind
to check the rounding effects of double values to single precision in
Float32 comparisons by the C compiler. If needed as an alternative,
either use the Saturation block or specify the correctly rounded single
precision value already in the model.
Note that TargetLink's block output code saturation is not affected,
because TargetLink internally calculates the correctly rounded single
precision value as needed. The changes relate to user-specified values.
Also refer to Rounding of doubles in Float32 comparisons
on page 240.
New Features and Migration
November 2015
243
t
s TargetLink t
Obsolete
Obsolete Limitations
With TargetLink 4.1, the following limitations of previous TargetLink
versions were removed:
General limitations
Initialization of buses1)
Bus signals can be initialized only if one of the following conditions is met:
n All the bus signals are enumerations of the same type.
n All the bus signals are non-enumerations.
Basically, the same scalar initial value has to be applied to all the bus signals.
1)
This limitation became obsolete because TargetLink 4.1 supports Simulink's simplified mode.
Block-specific limitations
Look-up tables (vectorized)
Table look-up functions are replaced by user-provided implementations if a matching custom look-up script is available. This
applies to look-up table blocks with a scalar output. The custom look-up script mechanism does not support vector/matrix input
signals or uniform elements.
Merge block
It is not possible to specify the initial value of bus signal elements by setting the initial output parameter of blocks that pass the
bus signal to a Simulink Initial Condition Structure.
OutPort block
It is not possible to specify the initial value of bus signal elements by setting the initial output parameter of blocks that pass the
bus signal to a Simulink Initial Condition Structure.
Rate Transition block
It is not possible to specify the initial value of bus signal elements by setting the initial output parameter of blocks that pass the
bus signal to a Simulink Initial Condition Structure.
Component-based
development limitations
Function reuse
TargetLink does not support multiple references to the same model inside one model hierarchy. Therefore, code generated for
referenced models cannot be reused.
244
s
New Features and Migration
November 2015
s Migrating to TargetLink 4.1 and TargetLink Data Dictionary 4.1 t
Simulink model arguments
TargetLink does not support Simulink model arguments for referenced models.
Code generation limitations
Incremental code generation
Incrementally generated subsystems or referenced models cannot be subject to function reuse and cannot reside in reused
functions.
Changes in Future TargetLink Versions
Where to go from here
Information in this section
Features to Be Discontinued
245
API Functions to Be Discontinued
246
Features to Be Discontinued
A2L import
It is planned to discontinue the A2L import in a future TargetLink
version.
Generation of RTF
documents
It is planned to discontinue the option to generate documentation in
rich text format (RTF) in a future TargetLink version.
MISRA-C:2004 Compliance
Documentation document
It is planned to discontinue the MISRA-C:2004 Compliance
Documentation document in a future TargetLink version. TargetLink
users will then be advised to use the MISRA-C:2012 Compliance
Documentation instead.
Simulink's classic
initialization mode
It is planned to discontinue support for Simulink's classic initialization
method (Underspecified initialization detection parameter set to
Classic) in a future TargetLink version.
Dynamic components
It is planned to discontinue support for specifying dynamic
components for DD Variable objects in a future TargetLink version.
New Features and Migration
November 2015
245
t
s TargetLink t
Code generation for special
OSEK versions
It is planned to discontinue the code generation for special OSEK
versions, such as OsCan in a future TargetLink version.
Signal logging format
It is planned to discontinue the support for Simulink's logging method
ModelDataLogs (Signal logging format parameter) in a future
TargetLink version.
Fully built V-ECUs as OSA
Future versions of TargetLink can no longer build V-ECUs as OSA files.
TargetLink will then only export the generated production code as VECU implementations (CTLGZ files) and leave the platform-specific
build process to VEOS for offline simulation and ConfigurationDesk
for real-time simulation.
API Functions to Be Discontinued
Discontinued API functions
The following API functions are deprecated and will be removed in a
future TargetLink version:
Function
Deprecated Since
Replacement Function
tl_adapt_dd_references
TargetLink 4.0
tlMoveDDObject
tl_extract_subsystem
TargetLink 4.0
tlExtractSubsystem
tl_find_dd_references
TargetLink 4.0
tlFindDDReferences
tl_get_blockset_mode
TargetLink 4.0
tlOperationMode
tl_sim_interface
TargetLink 4.0
tlSimInterface
tl_switch_blockset
TargetLink 4.0
tlOperationMode
tl_upgrade
TargetLink 4.0
tlUpgrade
See the help contents on the new API functions to adjust
your user scripts accordingly.
246
s
New Features and Migration
November 2015
VEOS
Where to go from here
Information in this section
New Features of VEOS 3.5
247
Migrating to VEOS 3.5
250
New Features of VEOS 3.5
Information in this topic
More intuitive user interface on page 247
Enabling/Disabling the generation of debug information (MSVC, GCC)
on page 249
Accessing call stack information in case of an exception on page 249
Build Output dialog on page 249
Loading an offline simulation application when an application is already
running on page 250
Unloading an offline simulation application on page 250
FMU import: Support of enumerations on page 250
More intuitive user
interface
The user interface of the VEOS Player is more intuitive: Its menu bar
and toolbar have been replaced by ribbons and the Backstage view
used in Microsoft Office, etc.
Ribbons VEOS Player's ribbons organize and group commands that
belong together. They are located at the top of the user interface.
Refer to the following illustration:
New Features and Migration
November 2015
247
t
s VEOS t
Ribbon
Each ribbon has ribbon groups, each of which provides a set of
related commands:
Ribbon group
Backstage view VEOS Player's Backstage view provides basic
commands, for example, for opening and saving OSA files. It also
provides quick access to the recently used OSA files.
The following illustration shows the Backstage view with the Info
ribbon group as an example:
Ribbon tab
Ribbon group
Backstage view
Context-sensitive help VEOS Player now provides context‑sensitive
help.
Press the F1 key or click the Help button in the VEOS Player to get
help on the currently active context.
For details, refer to Basics on Ribbons (
248
s
New Features and Migration
November 2015
VEOS Guide).
s New Features of VEOS 3.5 t
Enabling/Disabling the
generation of debug
information (MSVC, GCC)
Up to and including VEOS 3.4 Up to and including VEOS 3.4,
source code debugging:
n was always enabled when you imported items such as a
V‑ECU implementation together with the MSVC compiler, for
example.
n was always disabled when you imported items such as a
V‑ECU implementation together with the GCC compiler, for
example.
As of VEOS 3.5 As of VEOS 3.5, you can enable and disable source
code debugging together with both the MSVC and the
GCC compiler.
Refer to Basics on Debugging Source Code in an Offline Simulation
( VEOS Guide).
Accessing call stack
information in case of an
exception
When an exception of the model code of a specific VPU process
(based on an FMU or SIC) occurs during offline simulation, VEOS
outputs the following call stack information in an error message:
n The name of the function causing the exception
n The name and location of the source code file containing the
function
n The call stack related to the exception
VEOS provides the call stack only if both conditions apply:
n The MSVC compiler is selected
n Source code debugging was enabled for the VPU's build process
Build Output dialog
When you import and build, for example, a V‑ECU implementation,
the VEOS Player now provides the following information in the
separate Build Output dialog:
n Information on the build process, such as compiler and linker
messages
n A history of all the error and warning messages that occur during
the build process
The Build Output dialog is displayed also when you perform the
import and build via the automation interface of the VEOS Player.
For instructions, refer to How to Import VPUs, V-ECU
Implementations, Simulink Implementations, and FMUs (
Guide).
New Features and Migration
November 2015
VEOS
249
t
s VEOS t
Loading an offline
simulation application
when an application is
already running
When you load an offline simulation application to VEOS when an
offline simulation application is already running, VEOS now asks you
whether to:
n Connect to the running offline simulation application
n Replace the running offline simulation application
Refer to Load (
Unloading an offline
simulation application
VEOS Player Reference).
The VEOS Player now lets you unload an offline simulation application
from VEOS. This lets other products such as ControlDesk
Next Generation load another offline simulation application.
Refer to Unload (
FMU import: Support of
enumerations
VEOS Player Reference).
Enumeration data types of FMU inputs and outputs are now
supported. The VEOS Player now creates VPU ports for these
inputs/outputs.
Migrating to VEOS 3.5
Compatibility overview
VEOS and OSA The following table shows the compatibility
between VEOS 3.5 and OSA files:
OSA Files Created with Products of...
OSA Version
dSPACE Release 2014‑A
3.2
dSPACE Release 2014‑B
3.3
dSPACE Release 2015‑A
3.4
dSPACE Release 2015‑B
3.5
n An OSA file created or modified with VEOS 3.5 cannot
be loaded in earlier VEOS versions.
n There is a migration issue related to the simulation of
ASM models. Refer to Migrating ASM models (
Guide).
VEOS
VEOS and CTLGZ (V‑ECU implementation) The following table
shows the compatibility between VEOS 3.5 and CTLGZ files (V‑ECU
implementations):
250
s
V‑ECU Implementations Created with Products of...
V‑ECU Implementation Version
dSPACE Release 2013-B and earlier:
n SystemDesk 3.x
n TargetLink 3.5
1.0
New Features and Migration
November 2015
s Migrating to VEOS 3.5 t
V‑ECU Implementations Created with Products of...
V‑ECU Implementation Version
dSPACE Release 2014-A:
n SystemDesk 4.2
2.0
dSPACE Release 2014-B:
2.1
n SystemDesk 4.3
n TargetLink 4.0
dSPACE Release 2015-A:
2.2
n SystemDesk 4.4
dSPACE Release 2015-B:
2.3
n SystemDesk 4.5
n TargetLink 4.1
VEOS and SIC VEOS 3.5 is compatible with Simulink
implementation container (SIC) files created with Model Interface
Package for Simulink 3.1 from dSPACE Release 2015‑B (Simulink
Implementation Container Version 1.0.1).
There is a migration issue related to the simulation of
ASM models. Refer to Migrating ASM models ( VEOS
Guide).
VEOS and FMU FMUs must comply with the FMI 2.0 standards for
Co‑Simulation. FMUs complying with the FMI 1.0 standard are not
supported.
For an overview of dSPACE products and releases that support FMI,
refer to:
http://www.dspace.com/go/FMI-Compatibility.
Discontinuation of the
dSPACE Target for Offline
Simulation and migration
Model Interface Package for Simulink The dSPACE Target for
Offline Simulation was delivered for the last time with
dSPACE Release 2015-A. To prepare a Simulink® model for offline
simulation with VEOS, use the Model Interface Package for Simulink,
which was introduced with dSPACE Release 2015-A.
The Model Interface Package for Simulink provides the
dsrt.tlc system target file, which lets you generate a Simulink
implementation container (SIC) file from a Simulink® model. The
SIC file is independent of the simulation platform, so that you can
integrate the same SIC file in an offline simulation application for
VEOS and in a real‑time application for SCALEXIO.
For details on the differences in the workflows of dSPACE Target for
Offline Simulation and Model Interface Package for Simulink, refer to
Differences Between DsOffSim and the Model Interface Package for
Simulink ( Model Interface Package for Simulink - Modeling Guide).
New Features and Migration
November 2015
251
t
s VEOS t
New workflow The workflow that the Model Interface Package for
Simulink provides for preparing a Simulink® model for offline
simulation is different from the workflow provided by the dSPACE
Target for Offline Simulation.
To prepare the offline simulation of a Simulink® model, perform the
following steps:
1. In the Simulink® model, specify the dsrt.tlc system target file
provided by the Model Interface Package for Simulink.
2. Generate code for the Simulink® model.
Unlike the dSPACE Target for Offline Simulation, the Model
Interface Package for Simulink does not generate an application
for a specific simulation platform. Instead, it generates a Simulink
implementation container (SIC) file containing Simulink® model
code.
For instructions, refer to Generating Simulink Implementation
Containers ( Model Interface Package for Simulink - Modeling
Guide).
3. Import the SIC file to the VEOS Player to integrate the model in an
offline simulation application for VEOS.
The VEOS Player builds the SIC file for the VEOS simulation
platform.
For instructions, refer to How to Import VPUs, V-ECU
Implementations, Simulink Implementations, and FMUs (
Guide).
Changed automation
behavior when importing a
model implementation to
the VEOS Player
VEOS
In VEOS 3.5, there is an incompatible change of the Import method of
the IProject <<Interface>> interface of the VEOS Player API. The
method lets you import model implementations such as SIC and
CTLGZ files to a VEOS Player project:
n Up to and including VEOS 3.4, the Import method provides a list
of all compiler messages as a return parameter of the
<System.String[]> data type.
n As of VEOS 3.5, the Import method provides build information via
the IBuildResult <<Interface>>.
252
s
New Features and Migration
November 2015
Compatibility Information
Where to go from here
Information in this section
Supported MATLAB Releases
254
Operating System
255
Run-Time Compatibility of dSPACE Software
257
Limitations for 64-Bit Windows Operating Systems in
Combination with 32-Bit dSPACE Software
258
Products on the 64-Bit dSPACE DVD Set and Their
MATLAB Support
259
General Limitations for Windows 7
261
New Features and Migration
November 2015
253
t
s Compatibility Information t
Supported MATLAB Releases
Supported MATLAB
releases
AutomationDesk 5.1 1)
TargetLink 4.1
Model Compare 2.6
dSPACE Python Extensions 2.0 2)
R2015b (64-bit)
R2015b (32-bit)
R2015a (64-bit)
R2015a (32-bit)
R2014b (32-bit and
64-bit)
R2014a (32-bit and
64-bit)
...Is Supported by dSPACE Release 2015‑B
RCP and HIL Software
MATLAB Release...
✓3)
–
✓
–
✓3)
✓
–
✓
–
✓
✓
–
✓
–
✓
✓
–
✓
–
✓
✓
–
✓
–
✓
✓3)
✓
✓
✓
✓
1)
AutomationDesk's MATLAB Access library requires MATLAB.
matlablib2 of dSPACE Python Extensions requires MATLAB.
3) R2014a (32-bit), R2014b (32-bit), R2015b (32-bit) and R2015b (64-bit) are not supported by the RTI FPGA Programming
Blockset – FPGA Interface.
2)
For up-to-date information on additional MATLAB releases that can
be used in combination with dSPACE software, refer to
http://www.dspace.com/go/sw3rdparty.
254
s
New Features and Migration
November 2015
s Operating System t
Operating System
Operating system on
host PC
The following operating systems are supported by the dSPACE
products on Release 2015‑B:
32-Bit dSPACE Software
n
n
64-Bit dSPACE Software
Windows 7 Professional, Ultimate, and Enterprise with
Service Pack 1 (32-bit or 64-bit version)
Only the listed editions are supported. The Windows 7
Home and Starter editions are not supported.
ControlDesk Next Generation can also be installed on
the MicroAutoBox Embedded PC. The operating
system depends on the variant as follows:
®
TM
n MicroAutoBox Embedded PC with Intel Atom
Processor N270: Windows 7 Ultimate, 32-bit
version
®
TM
n MicroAutoBox Embedded PC with Intel Core
i7-3517UE Processor: Windows 7 Professional,
Ultimate, and Enterprise, 64-bit version
n
Windows 7 Professional, Ultimate,
and Enterprise with Service Pack 1
(64-bit version)
Only the listed editions are
supported. The Windows 7 Home
and Starter editions are not
supported.
Notes and Limitations
n
n
Refer to General Limitations for Windows 7
on page 261.
Support of 64-bit operating systems: 32-bit dSPACE
software supports only the 64-bit version of
Windows 7. Other 64-bit operating systems
(Windows XP and Windows Vista) are not supported.
32-bit dSPACE software runs under 64-bit Windows
operating systems in a WoW64 (Windows-onWindows 64-bit) subsystem. WoW64 is the x86
emulator of Windows that allows 32-bit Windowsbased applications to run seamlessly on 64-bit versions
of Windows. This lets you use up to 4 GB of virtual
memory for each 32‑bit process if the application is
prepared for using the large memory area. Otherwise,
the virtual address space of a process is limited to
2 GB.
Limitations apply when you use 32-bit dSPACE
software under a 64-bit Windows operating system.
Refer to Limitations for 64-Bit Windows Operating
Systems in Combination with 32-Bit dSPACE Software
on page 258.
New Features and Migration
n
Refer to General Limitations for
Windows 7 on page 261.
November 2015
255
t
s Compatibility Information t
For some complex tasks of the following products, you are required
or recommended to use the 64-bit version of Windows 7 as your
operating system:
n RTI FPGA Programming Blockset: If you use the FPGA interface of
this blockset, Windows 7 (64-bit) is required.
n Automotive Simulation Models: If you use the models for vehicle
dynamics, trailer, truck and traffic scenario simulations,
Windows 7 (64-bit) is recommended.
n ControlDesk Next Generation: If you use the video-capturing
device of ControlDesk Next Generation, Windows 7 (64-bit) is
recommended.
n ConfigurationDesk (Implementation Version): If you want to use
more than 1000 function blocks (or several function blocks with a
total of more than 1000 function ports) in your ConfigurationDesk
application, Windows 7 (64-bit) is required.
Allowing communication
via additional firewall rules
Additional Windows firewall rules are installed during the installation
of various dSPACE software products. For example, one rule allows
communication with a dSPACE expansion box such as AutoBox, and
another rule allows MotionDesk to receive motion data from a
network channel. These example rules are created by the following
commands:
n netsh advfirewall firewall add rule name="dSPACE Net
Service"
service=any dir=in action=allow profile=any
protocol=icmpv4:0, any description="Allow the dSPACE Net
Service to connect to a dSPACE expansion box via network."
n netsh advfirewall firewall add rule name="dSPACE MotionDesk"
program="%dspace_root%\MotionDesk\Bin\MotionDesk.exe"
dir=in action=allow profile=any description="Allow dSPACE
MotionDesk to receive motion data via network."
If you are running third-party firewall software on your host PC,
ensure that the TCP/IP communication of dSPACE software is not
blocked.
Operating system on
dSPACE License Server
256
s
If you purchased floating network licenses, you have to install and
configure one of the networked PCs as the dSPACE License Server.
New Features and Migration
November 2015
s Run-Time Compatibility of dSPACE Software t
The operating system of the dSPACE License Server must be one of
the following:
n Windows XP Professional (32-bit version) with Service Pack 3
n Windows Vista Business, Ultimate, or Enterprise (32-bit or 64-bit
version) with the latest Service Pack
n Windows 7 Professional, Ultimate, or Enterprise (32-bit or 64-bit
version) with the latest Service Pack
n Windows Server 2003 (32-bit or 64-bit version)
n Windows Server 2008 R2
n Windows Server 2012, Windows Server 2012 R2
The dSPACE License Server does not support non‑Windows
operating systems.
Run-Time Compatibility of dSPACE Software
Definition
Run-time compatibility means that:
n dSPACE products can be used in parallel after software
installation, even if they are installed in different folders.
n dSPACE products without interaction can run independently of
each other.
Compatibility of products in
dSPACE Release 2015‑B
dSPACE recommends using only software products from the same
dSPACE Release. This will provide maximum run-time compatibility.
Note that:
n Limitations regarding run-time compatibility in the dSPACE tool
chain might occur if products from different dSPACE Releases are
mixed.
If dSPACE products interact directly (through automation
interfaces) or indirectly (through common file types like A2L),
limitations might apply. For minor limitations, refer to the relevant
product documentation. The major limitations are described in the
following.
In rare cases, an additional patch must be installed for a product
to achieve run-time compatibility. For more details on the patch
and whether a patch is necessary, refer to
http://www.dspace.com/go/CompPatch.
New Features and Migration
November 2015
257
t
s Compatibility Information t
n RCP and HIL software products (on Release 2015‑B) cannot be
used in combination with RCP and HIL software products from
earlier dSPACE releases.
Major limitations for TargetLink and Model Compare The 64bit version of TargetLink cannot be used in combination with the 32bit version of Model Compare and vice versa, because you can work
only with a bit-compatible MATLAB version (32-bit or 64-bit).
Major limitation for working with a SCALEXIO system The
products for working with a SCALEXIO system must be compatible.
This is guaranteed only for products delivered with the same dSPACE
Release. Contact dSPACE for further information if you have any
questions.
Combining dSPACE
products from earlier
releases
For more details and notes on the combined use of different products
from and with earlier releases, refer to
http://www.dspace.com/go/ds_sw_combi.
Limitations for 64-Bit Windows Operating Systems in
Combination with 32-Bit dSPACE Software
Objective
Some additional limitations apply when you use 64-bit versions of
Windows 7 in combination with 32-bit dSPACE software.
Limitations of device drivers
Third-party bus interfaces (CAN, LIN, or FlexRay) are supported only if
they have 64-bit drivers from the manufacturers.
TargetLink: Limitations of
target compilers
For information on support for a specific target compiler, contact the
respective compiler manufacturer.
MATLAB
If you install a 32-bit variant of MATLAB under Windows 7 (64-bit),
the MATLAB installation program generates a message that a 64-bit
variant of MATLAB is available. To install the 32-bit variant of
MATLAB, click OK.
258
s
New Features and Migration
November 2015
s Products on the 64-Bit dSPACE DVD Set and Their MATLAB Support t
Products on the 64-Bit dSPACE DVD Set and Their MATLAB
Support
Objective
The 64-bit dSPACE DVD set contains the same product versions as the
32-bit dSPACE DVD set. However, the 64-bit DVD set contains the
32-bit variants of some products.
When using the 64-bit DVD set, you should note the limitations
described in the section below the table.
Products and their MATLAB
support
The following table lists in detail all dSPACE products on the 64-bit
dSPACE DVD set and their MATLAB support:
n All MATLAB-related dSPACE products which support 64-bit
MATLAB versions
n All 32-bit dSPACE products which also support 64-bit MATLAB
versions
n All 32-bit dSPACE products that do not relate to MATLAB
dSPACE Product
Product
Product
Product
Supports 64- Independent of Contained as
bit MATLAB MATLAB
32-Bit Variant
Architecture (32bit/64-bit)
ControlDesk Next Generation
SystemDesk
AutomationDesk
TargetLink
Model Compare
VEOS
Real-Time Testing
Platform API
dSPACE Python
Package
Extensions
HIL API .NET MAPort
XIL API .NET MAPort
Failure Simulation
XIL API .NET EESPort
API Package
–
–
✓
✓
✓
–
–
–1)
✓
✓
–
–
–
✓
–
✓
✓
✓
✓
–
–
✓
✓
✓
–
–3)
–
✓2)
✓3)
✓
✓
✓
✓
New Features and Migration
November 2015
259
t
s Compatibility Information t
dSPACE Product
RCP and HIL
software package
260
s
Product
Product
Product
Supports 64- Independent of Contained as
bit MATLAB MATLAB
32-Bit Variant
Architecture (32bit/64-bit)
RTI and RTI‑MP
RTI Gigalink Blockset
RTI CAN Blockset
RTI CAN MultiMessage
Blockset
RTI LIN MultiMessage
Blockset
RTI FlexRay Configuration
Blockset
RTI FPGA Programming
Blockset
RTI Electric Motor Control
Blockset
RTI Ethernet Blockset
RTI Ethernet UDP Blockset
RTI XCP on Ethernet
Blockset
RTI Watchdog Blockset
RTI RapidPro Control Unit
Blockset
RTI Bypass Blockset
RTI USB Flight Recorder
Blockset
ConfigurationDesk
FlexRay Configuration
Blockset
FlexRay Configuration
Tool
ModelDesk
Automotive Simulation
Models
MotionDesk
MotionDesk Blockset
Flight Rec Data Merger
✓
✓
✓
✓
–
–
–
–
–
–
–
–
✓
–
–
✓
–
–
✓
–
–
✓
–
–
✓
✓
✓
–
–
–
–
–
–
✓
✓
–
–
–
–
✓
✓
–
–
–
–
✓
✓
–
–
✓
–
–
✓
✓
✓
✓
–
–
✓
–
✓
✓
–
–
–
✓
✓
–
✓
New Features and Migration
November 2015
s General Limitations for Windows 7 t
dSPACE Product
Product
Product
Product
Supports 64- Independent of Contained as
bit MATLAB MATLAB
32-Bit Variant
Architecture (32bit/64-bit)
Model Interface Package ✓
for Simulink
Further products of RCP
–
and HIL software package
–
–
✓
✓
1)
dSPACE Python Extensions contain the matlablib2 Python library. This library supports remote control and access of 64-bit
MATLAB. matlablib2 itself is contained on the 64-bit DVD as 32-bit variant.
2) HIL API .NET MAPort can be used from 32-bit MATLAB via MATLAB Interface for .NET, but cannot be used from 64-bit
MATLAB.
3) XIL API .NET MAPort can be used from 32-bit and 64-bit MATLAB via MATLAB Interface for .NET.
For more details on the compatibility of dSPACE products with 64-bit
MATLAB versions, refer to http://www.dspace.com/go/matlab64bit.
Product-specific limitations
Restricted MAT file support ControlDesk Next Generation
(ControlDesk 5.5) only supports reading and writing MAT files of file
format version 5.0. MAT files of this version can be created in
MATLAB by using the save command with the option '-v6'.
RTI‑MP The rtimpdiag command is not functional. This command is
based on dSPACE HIL API .NET, which does not support 64-bit
MATLAB.
Limitations for the 64-bit
variant of TargetLink
Importing an A2L file It is not possible to import an A2L file into a
64-bit variant of TargetLink. However, you can use a workaround
described in Basics of Importing A2L Files ( TargetLink Data
Dictionary A2L Import and Export).
General Limitations for Windows 7
Objective
Some limitations apply when you use Windows 7 in combination with
dSPACE software.
MATLAB support
For system requirements of MathWorks® software, refer to
http://www.mathworks.com/support/sysreq/current_release.
Fast user switching not
supported
dSPACE software does not support the fast user switching feature of
Windows.
New Features and Migration
November 2015
261
t
s Compatibility Information t
Closing dSPACE software
before PC shutdown
The shutdown procedure of Windows operating systems might cause
some required processes to be aborted although they are still being
used by dSPACE software. To avoid data loss, it is recommended to
terminate the dSPACE software manually before performing a PC
shutdown.
User Account Control
It is recommended to disable Windows' User Account Control (UAC)
during the installation of dSPACE software. If you cannot disable
UAC, note the following Windows behavior: If UAC is enabled, the
setup programs run with the administrator account instead of the
user account. Therefore, it is important that the administrator account
has access to the required drives, particularly the required network
drives.
USB devices
The first time that dSPACE USB devices using cables with
optoisolation are connected to the PC, there might be a message that
the device driver software was not installed successfully. The dSPACE
device will nevertheless work properly later on.
262
s
New Features and Migration
November 2015
s Index t
Numerics
64-bit dSPACE DVD
limitations 259
A
ASM Base InCylinder Blockset
migrating 54
new features 54
ASM Diesel Engine Blockset
migrating 57
new features 55
ASM Diesel Exhaust Blockset
migrating 59
ASM Diesel InCylinder Blockset
migrating 61
new features 60
ASM Drivetrain Basic Blockset
migrating 62
new features 62
ASM Electric Components Blockset
migrating 64
new features 63
ASM Engine Gasoline Basic Blockset
migrating 68
new features 67
ASM Engine Gasoline Blockset
migrating 72
new features 70
ASM Environment Blockset
migrating 66
new features 66
ASM Gasoline InCylinder Blockset
migrating 75
new features 74
ASM Optimizer
new features 76
ASM Optimizer Blockset
migrating 77
ASM Traffic Blockset
migrating 79
new features 78
ASM Trailer Blockset
migrating 81
new features 80
ASM Truck Blockset
migrating 83
new features 82
ASM Turbocharger Blockset
migrating 85
new features 84
ASM Vehicle Dynamics Blockset
migrating 88
new features 87
AutomationDesk
new features 49
AUTOSAR
TargetLink-related
migration 226
C
Common Program Data folder 12
CommonProgramDataFolder 12
ControlDesk Next Generation
migration 113
new features 100
D
DCI Configuration Tool
new features 123
Documents folder 12
DocumentsFolder 12
DS1007
new features 154
dSPACE FlexRay Configuration Package
new features 125
dSPACE HIL API .NET
new features 127
dSPACE Python Extensions
new features 129
dSPACE XIL API
new features 133
DVD contents 16
E
ECU Interface Manager
migration 136
new features 135
F
Firmware Manager
new features 139
G
general enhancements and changes 15
N
H
host PC software
operating system 255
K
key features 24
L
Limitations
TargetLink
obsolete limitations 244
limitations for Windows 64-bit and
dSPACE 64-bit software 258
limitations for Windows 7 261
Local Program Data folder 12
LocalProgramDataFolder 12
M
MATLAB
supported releases 254
MicroAutoBox
new features 155
MicroLabBox
new features 153
New Features and Migration
migrating
ASM Base InCylinder Blockset 54
ASM Diesel Engine Blockset 57
ASM Diesel Exhaust Blockset 59
ASM Diesel InCylinder Blockset 61
ASM Drivetrain Basic Blockset 62
ASM Electric Components Blockset 64
ASM Engine Gasoline Basic Blockset
68
ASM Engine Gasoline Blockset 72
ASM Environment Blockset 66
ASM Gasoline InCylinder Blockset 75
ASM Optimizer Blockset 77
ASM Traffic Blockset 79
ASM Trailer Blockset 81
ASM Truck Blockset 83
ASM Turbocharger Blockset 85
ASM Vehicle Dynamics Blockset 88
migration
ControlDesk Next Generation 113
ECU Interface Manager 136
Model Compare 143
MotionDesk 150
RTI 156
RTI Bypass Blockset 158
RTI CAN MultiMessage Blockset 162
RTI FPGA Programming Blockset 170
RTI LIN MultiMessage Blockset 173
Model Compare
migration 143
new features 141
ModelDesk
new features 145
MotionDesk
migration 150
new features 149
new features
ASM Base InCylinder Blockset 54
ASM Diesel Engine Blockset 55
ASM Diesel InCylinder Blockset 60
ASM Drivetrain Basic Blockset 62
ASM Electric Components Blockset 63
ASM Engine Gasoline Basic Blockset
67
ASM Engine Gasoline Blockset 70
ASM Environment Blockset 66
ASM Gasoline InCylinder Blockset 74
ASM Optimizer 76
ASM Traffic Blockset 78
ASM Trailer Blockset 80
ASM Truck Blockset 82
ASM Turbocharger Blockset 84
ASM Vehicle Dynamics Blockset 87
AutomationDesk 49
ControlDesk Next Generation 100
DCI Configuration Tool 123
DS1007 154
dSPACE FlexRay Configuration
Package 125
dSPACE HIL API .NET 127
dSPACE Python Extensions 129
dSPACE XIL API 133
November 2015
263
t
s Index t
ECU Interface Manager 135
Firmware Manager 139
MicroAutoBox 155
MicroLabBox 153
Model Compare 141
ModelDesk 145
MotionDesk 149
Real-Time Testing 151
RTI Bypass Blockset 157
RTI CAN MultiMessage Blockset 161
RTI Electric Motor Control Blockset
165
RTI FPGA Programming Blockset 167
RTI LIN MultiMessage Blockset 173
RTI/RTI-MP 153
RTLib 153
SCALEXIO firmware 175
SystemDesk 178
VEOS 247
new hardware 15
not supported MATLAB features
(R2015a) 155
P
product overview 20
Products on 64-bit dSPACE DVD 259
R
RCP and HIL software
definition 16
Real-Time Testing
new features 151
requirements
host PC software
operating system 255
RTI Bypass Blockset
migration 158
new features 157
RTI CAN MultiMessage Blockset
migration 162
new features 161
RTI Electric Motor Control Blockset
new features 165
RTI FPGA Programming Blockset
migration 170
new features 167
RTI LIN MultiMessage Blockset
migration 173
new features 173
RTI/RTI-MP
new features 153
RTLib
new features 153
T
TargetLink
API commands
changes 226
AUTOSAR features, new
supported releases 200
code changes
migration 227
code efficiency, improved 196
code generator options
backward compatibility 223
changed default value 223
migrating to
new version 218
migration
AUTOSAR-related 226
code changes 227
obsolete limitations 244
various aspects 242
new API functions 215
new code generator options 208
new features 192
general changes 211
general enhancements 211
new version
migrating to 218
newly supported Simulink blocks 193
target support
discontinued compiler versions 203
discontinued evaluation boards 203
new compiler versions 203
new evaluation boards 203
supported targets 203
TargetLink Data Dictionary
API commands
changes 226
new commands 207
migrating to
new version 218
migration 219
discontinued documentation 219
manually upgrading libraries and
models 222
upgrading existing data dictionaries
220
new features 192
new version
migrating to 218
V
VEOS
new features 247
version history 20
S
W
SCALEXIO firmware
new features 175
supported MATLAB releases 254
system requirements
operating system 255
SystemDesk
new features 178
Windows 64-bit
limitations 258
Windows 7
limitations 261
264
s
New Features and Migration
November 2015
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement