D SPACESimulator Mid Size Features

dSPACE Simulator Mid-Size
Features
Release 2018-A – May 2018
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: info@dspace.de
Web: http://www.dspace.com
How to Contact dSPACE Support

If you encounter a problem when using dSPACE products, contact your local dSPACE
representative:
§ Local dSPACE companies and distributors: http://www.dspace.com/go/locations
§ For countries not listed, contact dSPACE GmbH in Paderborn, Germany.
Tel.: +49 5251 1638-941 or mailto: support@dspace.de.
You can also use the support request form:

http://www.dspace.com/go/supportrequest. If you are logged on to mydSPACE, you
are automatically identified and do not need to add your contact details manually.
If possible, always provide the relevant dSPACE License ID or the serial number of the
CmContainer in your support request.
Software Updates and Patches

dSPACE strongly recommends that you download and install the most recent patches
for your current dSPACE installation. Visit 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 - 2018 by:

dSPACE GmbH
Rathenaustraße 26
33102 Paderborn
Germany
This publication and the contents hereof are subject to change without notice.
ConfigurationDesk, ControlDesk, MicroAutoBox, MicroLabBox, 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
Contents
About This Document 9

Conventions Used in dSPACE User Documentation................................ .............. 9
Accessing dSPACE Help and PDF Files................................................................. 10
Related Documents............................................................................................ 12
Introduction to the Features of dSPACE Simulator Mid-Size 13

Overview of dSPACE Simulator Mid-Size................................................ ............ 13
System Overview of DS1005 PPC Board............................................................. 16
Features Overview the DS1005 PPC Board.......................................................... 16
System Overview of DS2210 HIL I/O Board......................................................... 17
Features Overview of DS2210 HIL I/O Board....................................................... 19
Features of the Processor Board 23

General Information.................................................................................................... 24
Physical Characteristics and Requirements.......................................................... 24
Processor........................................................................................................... 25
Memory............................................................................................................. 25
Timers and Time Base Counters.................................................................................. 27

Overview of Timers and Time Base Counters...................................................... 27
Decrementer...................................................................................................... 27
Timer A................................................................................................. ............ 28
Timer B.............................................................................................................. 28
Time Base Counter................................................................................ ............ 29
Interrupt Controller..................................................................................................... 30
Basics of the Interrupt Controller........................................................................ 30
Interrupt Handling............................................................................................. 30
Available Interrupts............................................................................................ 31
External Interrupt............................................................................................... 31
Interfaces.................................................................................................................... 32
PHS Bus Interface............................................................................................... 32
Serial Interface of the DS1005............................................................................ 35
Specifying the Baud Rate of the Serial Interface.................................................. 36
Host Interface.................................................................................................... 37
3
May 2018 dSPACE Simulator Mid-Size Features
Contents
Monitoring..................................................................................................... ............ 39
Watchdog.......................................................................................................... 39
Force Reset........................................................................................................ 39
Flight Recorder............................................................................................................ 40
Basics of the Flight Recorder.................................................................. ............ 40
Nonvolatile Data Handling..................................................................... ............ 41
Basics on Flight Recorder.................................................................................... 42
Using the Flight Recorder................................................................................... 43
MAT File Format for the Flight Recorder............................................................. 44
Sensor and Actuator Interface 47

ADC Unit........................................................................................................... 48
DAC Unit........................................................................................................... 50
D/R Converter.................................................................................................... 52
Bit I/O Unit......................................................................................................... 54
PWM Signal Measurement................................................................................. 56
PWM Signal Generation..................................................................................... 59
Frequency Measurement.................................................................................... 63
Square-Wave Signal Generation......................................................................... 65
Serial Interface (DS2210).................................................................................... 67
Angular Processing Unit 69

APU Basics.................................................................................................................. 70
APU Overview.................................................................................................... 71
Engine Position Phase Accumulator.................................................................... 72
Cascading I/O Boards......................................................................................... 73
Crankshaft Signal Generator.............................................................................. 75
Camshaft Signal Generator................................................................................ 76
Spark Event Capture Unit................................................................................... 77
Injection Event Capture Unit.................................................................. ............ 78
Event Capture Windows........................................................................ ............ 81
Continuous Value Capturing.............................................................................. 83
APU Reference............................................................................................................ 85
Crankshaft Sensor Signal Generation................................................................. 86
Camshaft Sensor Signal Generation................................................................... 87
Wave Table Basics.............................................................................................. 88
Generating Wave Tables..................................................................................... 89
Spark Event Capture.......................................................................................... 90
Injection Pulse Position and Fuel Amount Measurement..................................... 91
4
dSPACE Simulator Mid-Size Features May 2018
Contents
Features Served by the Slave DSP 95

Slave DSP TMS320C31 Basics............................................................................. 95
Knock Sensor Simulation.................................................................................... 96
Wheel Speed Sensor Simulation......................................................................... 99
CAN Support 101

Setting Up a CAN Controller..................................................................................... 102
Initializing the CAN Controller.......................................................................... 103
CAN Transceiver Types........................................................................... .......... 104
DS2211: Selecting the CAN Controller Frequency............................................. 108
Defining CAN Messages................................................................................... 109
Implementing a CAN Interrupt......................................................................... 110
Using RX Service Support................................................................................. 110
Removing a CAN Controller (Go Bus Off)......................................................... 112
Getting CAN Status Information............................................................ .......... 113
I/O Mapping of the CAN Bus Interfaces............................................................ 114
Using the RTI CAN MultiMessage Blockset................................................................ 116

Basics on the RTI CAN MultiMessage Blockset.................................................. 116
Basics on Working with CAN FD............................................................ .......... 121
Basics on Working with a J1939-Compliant DBC File........................................ 126
Transmitting and Receiving CAN Messages....................................................... 132
Manipulating Signals to be Transmitted............................................................ 135
Interrupts of the DS2210 139

DS2210 Interrupts............................................................................................ 139
DS1005 Multiprocessor Systems 141

Basics of DS1005 Multiprocessor Systems.................................................................. 143
Basics of DS1005 Multiprocessor Systems.............................................. .......... 143
DS910 Gigalink Module............................................................................................ 144

Basics of the DS910 Gigalink Module............................................................... 144
Data Transmission............................................................................................ 147
Virtual Shared Memory Mode.......................................................................... 148
Swinging Buffer Mode..................................................................................... 148
Interrupt Transmission...................................................................................... 151
Synchronizing Data Input and Output.............................................................. 155
5
Contents
Synchronization........................................................................................................ 156
Synchronized Timer Tasks................................................................................. 156
Global Time Base in an MP System................................................................... 157
Tracing Signals in an MP System....................................................................... 158
Working with Subsets of a Multiprocessor Topology.................................................. 159

Basics of Working with Optional CPUs............................................................. 159
Basics of Topological Subsets............................................................................ 160
How to Specify Optional CPUs in RTI-MP.......................................................... 162
Application Start 165

Boot Firmware................................................................................................. 166
Running an Application from the Global Memory.................................. .......... 166
Running an Application from the Flash Memory............................................... 167
Autobooting Real-Time Applications on dSPACE Hardware.............................. 168
Power Supply Unit 169

Characteristics and I/O Mapping of the Power Supply Unit............................... 169
Controlling the Battery Voltage........................................................................ 171
Example of Controlling the Battery Voltage...................................................... 172
Controlling the High Rails...................................................................... .......... 173
How to Control the High Rails.......................................................................... 174
Load Simulation 177

Load Simulation With the dSPACE Simulator Mid-Size...................................... 177
Failure Simulation 181

Basics on Failure Simulation................................................................... .......... 181
Failure Types.......................................................................................... .......... 183
Simulating Failures at ECU Inputs..................................................................... 184
Diagnostics 187
Diagnostic Connector...................................................................................... 187
Expandability 189
Processing Power Is Not Sufficient.................................................................... 190
Expanding the I/O Hardware............................................................................ 190
Simulating a Specific Signal.............................................................................. 191
6
Contents
I/O Mapping 193

ECU Connectors.............................................................................................. 193
I/O Mapping to the ECU 1 Connector.................................................... .......... 194
I/O Mapping to the ECU 2 Connector.................................................... .......... 197
Limitations 199
Quantization Effects......................................................................................... 200
DS2210 Board Revision.................................................................................... 201
Conflicting I/O Features.................................................................................... 201
Limited Number of CAN Messages................................................................... 210
Limitations with RTICANMM............................................................................ 212
Limitations with J1939-Support........................................................................ 214
Index 215
7
Contents
8
About This Document
About This Document
Contents The dSPACE Simulator Mid-Size Features document provides feature-oriented

access to the information you need to implement your models on dSPACE
Simulator Mid-Size.
Where to go from here Information in this section
Conventions Used in dSPACE User Documentation .................................. 9
Accessing dSPACE Help and PDF Files .................................................... 10
Related Documents ............................................................................... 12
Conventions Used in dSPACE User Documentation
Symbols dSPACE user documentation uses the following symbols:
Symbol Description
Indicates a hazardous situation that, if not avoided,
V DANGER will result in death or serious injury.
V WARNING could result in death or serious injury.
V CAUTION could result in minor or moderate injury.
Indicates a hazard that, if not avoided, could result in
NOTICE
property damage.
Indicates important information that you should take
Note
into account to avoid malfunctions.
Indicates tips that can make your work easier.
Tip
9
About This Document
Symbol Description
Indicates a link that refers to a definition in the
glossary, which you can find at the end of the
document unless stated otherwise.
Precedes the document title in a link that refers to
another document.
Naming conventions dSPACE user documentation uses the following naming conventions:
%name% Names enclosed in percent signs refer to environment variables for

file and path names.
<> Angle brackets contain wildcard characters or placeholders for variable

file and path names, etc.
Special folders Some software products use the following special folders:
Common Program Data folder A standard folder for application-specific

configuration data that is used by all users.
%PROGRAMDATA%\dSPACE\<InstallationGUID>\<ProductName>
or
%PROGRAMDATA%\dSPACE\<ProductName>\<VersionNumber>
Documents folder A standard folder for user-specific documents.

%USERPROFILE%\My Documents\dSPACE\<ProductName>\
<VersionNumber>
Local Program Data folder A standard folder for application-specific

configuration data that is used by the current, non-roaming user.
%USERPROFILE%\AppData\Local\dSPACE\<InstallationGUID>\
<ProductName>
Accessing dSPACE Help and PDF Files
Introduction After you install and decrypt your dSPACE software, the documentation for the
installed products is available as online help in dSPACE Help and as Adobe® PDF
files.
10
Accessing dSPACE Help and PDF Files
Online help There are various ways to open dSPACE Help.
Note
Not all the ways to open dSPACE Help are available for all dSPACE software
products.
Opening from Windows You can open dSPACE Help on its home page:
§ Via Windows Start Menu
Opening from dSPACE software with menu bar You can open dSPACE
Help on a product's start page:
§ Via the menu bar in a dSPACE product
Opening from dSPACE software with ribbons If you use dSPACE software
with ribbons, you can open dSPACE Help:
§ Via the Start page in dSPACE software
§ Via the Backstage view in dSPACE software (leftmost ribbon tab)
§ Via the button
Opening context-sensitive help dSPACE Help provides context-sensitive

help. You can open help on the currently active context in dSPACE software:
§ Via F1
§ Via the Help button
PDF files You can open the PDF files as follows:
Opening from a topic in dSPACE Help You can access the PDF file with the
current topic via the button at the topic's top right. The following illustration
shows an example:
The PDF document opens on its first page.
Opening from dSPACE software with ribbons If your dSPACE software

has a user interface with ribbons, you can open a folder that contains the user
documentation in PDF format via the button in the Backstage view (leftmost
ribbon tab).
11
About This Document
Related Documents
Objective The following provides a list of documents that you are recommended to read
when working with dSPACE Simulator Mid‑Size.
Information in other documents
DS2210 RTI Reference

Provides concise information on the board’s RTI library.
DS2210 RTI Reference

Provides concise information on the board’s RTI library.
DS1005 RTLib Reference

Provides detailed descriptions of the C functions needed to program RTI-
specific Simulink S‑functions or implement your real-time models
manually via C programs (handcoding).
DS2210 RTLib Reference

Provides detailed descriptions of the C functions needed to program RTI-
specific Simulink S‑functions or implement your real-time models
manually via C programs (handcoding).
PHS Bus System Hardware Reference

Provides hardware‑related reference information on your PHS-bus-based
system and all the relevant information on signal connections to external
devices.
RTI and RTI-MP Implementation Guide

Gives detailed information and instructions on using Real-Time Interface
(RTI and RTI‑MP) to implement your real-time models.
RTI and RTI-MP Implementation Reference

Provides reference information on the various dialogs, files, options, etc.
of Real‑Time Interface (RTI and RTI-MP) for dSPACE systems. It also
describes the blocks introduced by RTI-MP.
12
Introduction to the Features of dSPACE Simulator Mid-Size
Introduction to the Features of dSPACE Simulator

Mid-Size
Overview of dSPACE Simulator Mid-Size ................................................ 13

Provides an overview of dSPACE Simulator Mid-Size.
System Overview of DS1005 PPC Board ................................................. 16

Provides an overview of the functional units of a DS1005.
Features Overview the DS1005 PPC Board ............................................. 16

Provides an overview of the features of a DS1005.
System Overview of DS2210 HIL I/O Board ............................................. 17

Provides an overview of the functional units of a DS2210.
Features Overview of DS2210 HIL I/O Board ........................................... 19

Provides an overview of the features of a DS2210.
Overview of dSPACE Simulator Mid-Size
Introduction To get an overview of dSPACE Simulator Mid-Size.
13
Components dSPACE Simulator Mid-Size consists of several components, see the following
illustration.
The following illustration shows the connections of the components.

ECU 1
Connector
DS2210 HIL ECU
Load Cards/
I/O Board ECU 2
Failure Inser!on
Connector
Units
PHS Bus
CARB Tester
Power Supply
Connector Device
DS1005 PPC
Board
ISA Bus
PC Interface
PC
dSPACE Simulator Mid-Size is mounted in a 19’’/6U desktop rack. It contains all

necessary components for hardware-in-the-loop (HIL) simulation:
§ DS1005 PPC Board
§ DS2210 HIL I/O Board
§ PC interface
§ Power supply
§ Load cards
§ Failure Insertion Unit (FIU)
14
Overview of dSPACE Simulator Mid-Size
DS1005 PPC Board The DS1005 PPC Board calculates the real‑time application. For more information
on the DS1005 PPC Boards, refer to System Overview of DS1005 PPC Board
on page 16 and Features Overview the DS1005 PPC Board on page 16.
DS2210 HIL I/O Board The DS2210 HIL I/O Board is tailored to generate and measure automotive
signals. It combines a variety of typical HIL I/O functions on one board. The board
also contains signal conditioning for typical signal levels of 12 V/14 V automotive
systems. For more information on the DS2210 HIL I/O Board, refer to System
Overview of DS2210 HIL I/O Board on page 17 and Features Overview of
DS2210 HIL I/O Board on page 19.
PC interface All dSPACE software for experiment setup and control runs on your PC or laptop,
which is connected to dSPACE Simulator Mid-Size via a PC interface. dSPACE
Simulator Mid-Size is equipped with the DS814 PC Interface board. The host PC
has to be equipped with an interface board depending on its slot type:
Slot Type Required Interface Board

PCI slot DS817 plug-in card
PCMCIA slot DS815 type 2 PCMCIA card
Power supply unit The power supply unit is remote-controlled by dSPACE Simulator Mid-Size. It is
used to simulate the battery voltage. The battery voltage is available at four
battery rails, three of them are switchable (see Power Supply Unit on page 169).
Load cards The load cards are used to connect substituted or real loads to the ECU outputs
(see Load Simulation on page 177).
Failure Insertion Units The Failure Insertion Units emulate electrical failures in the wiring of an ECU
output, for example, short to ground or cable break (see Failure Simulation
on page 181).
Connectors The following connectors are available on the front:

§ Two 90-pin connectors for the ECU
§ One standard 16-pin CARB connector for diagnostic tools, see Diagnostics
on page 187
§ Jacks for the battery voltage for external devices
The following connectors are available on the rear:

§ Mains connector
§ PC interface connector
§ RS232-FIU connector
15
System Overview of DS1005 PPC Board
Introduction The DS1005 PPC Board is based on the PowerPC 750 Processor. This real-time
processor (RTP) forms the main processing unit. Via its PHS bus it has access to
the DS2210 HIL I/O Board and to other modular I/O boards if they are necessary.
Via Gigalink it can be connected to other DS1005, which makes it capable of
multiprocessing in a DS1005‑MP environment. The following illustration gives an
overview of the functional units of the DS1005:
Further DS910 Gigalink PHS Bus

DS1005s Module I/O Boards
1 MB Level 2 PowerPC 16 MB Boot

Cache 750 Flash
PHS-Bus
64 MB Interface Supervisor
Global Bus
Local Bus
Global RAM
Peripheral Bus
64 MB
Global RAM Global Bus
Serial Interrupt External
Interface Controller Timers
Host
Interface
DS1005
PC
ISA Bus
Features Overview the DS1005 PPC Board
Introduction The DS1005 PPC Board provides the following features.
Processor § providing the computing power of the board (see Processor on page 25)
Memory § comprising RAM, flash, and cache (see Memory on page 25)
Timers and time base § (see Timers and Time Base Counters on page 27) comprising:
counters § RTP Built‑In Decrementer: Sample rate timer with interrupt function
providing very fast interrupts
§ Timer A: Sample rate timer with interrupt function
16
System Overview of DS2210 HIL I/O Board
§ Timer B: Interval timer with interrupt function

§ RTP Built-In Time Base Counter: Time base for single-processor systems
§ Synchronized Time Base Unit: Time base for multiprocessor systems
Interrupt control § providing various hardware and software interrupts (see Interrupt Controller
on page 30)
PHS bus § allowing access to the I/O boards (see PHS Bus Interface on page 32)
Gigalink module (optional) § for setting up multiprocessor systems (see DS910 Gigalink Module
on page 144)
Synchronization § (see Synchronization on page 156) comprising:

§ synchronized timer tasks: Timer A for MP systems
§ global time base in an MP system
§ tracing signals in an MP system
Supervision § allowing to supervise program execution and host access (see Monitoring
on page 39):
§ watchdog to supervise program execution
§ force reset to supervise host access
Serial interface § for setting up a user‑specific communication or for debugging, etc. (see Serial
Interface ( PHS Bus System Hardware Reference))
Host interface § for setting up the DS1005, downloading programs and transferring runtime
data to or from the host PC (see Host Interface on page 37)
System Overview of DS2210 HIL I/O Board
Introduction The DS2210 includes the several functional units.
DS2210 HIL I/O Board The DS2210 HIL I/O Board is tailored to generate and measure automotive
signals. It combines a variety of typical HIL I/O functions on one board. The board
also contains signal conditioning for typical signal levels of 12 V automotive
systems.
17
While the DS2210 measures and generates the signals required, the DS1005 PPC
Board takes over the calculation of the real-time model. That is, applications
using DS2210 I/O features are implemented on the DS1005 PPC Board.
Sensor and actuator interface The DS2210 has a sensor and actuator interface, which provides a typical set of
automotive I/O functions, including A/D conversion, digital I/O, and wheel speed
sensor signal generation, for example.
Angular processing unit The core feature of the DS2210 is the angular processing unit (APU), which
provides the HIL core functions of the engine:
§ Crankshaft/camshaft signal generation
§ Spark event measurement
§ Injection pulse position and fuel amount measurement
§ Knock sensor simulation
Cascading DS2210 boards Several DS2210 boards can be cascaded to

expand from 6-cylinder simulation to 12-cylinder simulation, or even more. For
more information on cascading, refer to Cascading I/O Boards on page 73.
DSP subsystem The DSP subsystem is based on the TMS320C31. It includes ready-to-use
applications that allow you to generate knock sensor signals or wheel speed
sensor signals. As an alternative, you can program the DSP to generate user-
specific signals. The serial port of the slave DSP allows you to connect a DS2302,
for example, for generating further angular signals.
Communication interfaces In addition to a standard serial interface (RS232, RS422 based on a Texas
Instruments TL 16C550 UART), the DS2210 includes a CAN subsystem that is
based on the Siemens SAB 80C167 microcontroller. It provides connections to
two CAN buses.
Master and slaves The processor board has access to both the DSP and the CAN subsystems. In
terms of interprocessor communication, the processor board is the master,
whereas the DS2210 microcontrollers are slaves.
18
Features Overview of DS2210 HIL I/O Board
Functional units The illustration shows the functional units of the DS2210.
Abbreviations used:
ADC: Analog/digital converter
CAN: Controller area network
DAC: Digital/analog converter
D/R: Digital/resistance (converter)
DSP: Digital signal processor
PWM: Pulse width modulation
Introduction The DS2210 provides the following features – summarized in alphabetical order:
Note
Several features are available only with extended functionality. To check

whether or not your board supports extended functionality, refer to DS2210
Board Revision on page 201.
19
A/D conversion The ADC unit provides 16 unipolar A/D channels with 12-bit resolution and 1.1
µs conversion time for each channel. Refer to ADC Unit on page 48.
Note
Three A/D channels are already used by dSPACE Simulator Mid-Size and may
not be used within the real-time application (see Power Supply Unit
on page 169).
Bit I/O The bit I/O unit provides 16 discrete input lines and 16 discrete outputs. Refer to
Bit I/O Unit on page 54.
CAN support The CAN support serves two CAN controllers that meet the CAN 2.0A (11-bit
identifier) and CAN 2.0B (29-bit identifier) specifications. Refer to CAN Support
on page 101.
D/A conversion The DAC unit provides 12 unipolar D/A channels (for user output) with 12-bit
resolution and 20 µs full-scale settling time to 1 LSB. Refer to DAC Unit
on page 50.
Note
§ One D/A channel is already used by dSPACE Simulator Mid-Size and may
not be used within the real-time application (see Power Supply Unit
on page 169).
§ The reference voltage is internally connected to 10 V and cannot be
changed.
D/R conversion The D/R converter provides 6 independent resistance outputs with 16-bit
resolution covering a resistance range of 15 Ω … infinity. Refer to D/R Converter
on page 52.
Engine HIL simulation The angular processing unit provides the following features:
§ Simulation of engine core functions is based on a 13-bit engine position
(angle) for an engine cycle of 0 … 720° and a resolution of 0.088°. The engine
position is updated every 1 µs. Refer to Engine Position Phase Accumulator
on page 72.
§ Crankshaft sensor simulation provides one crankshaft waveform output with
eight selectable waveforms. Refer to Crankshaft Signal Generator on page 75
and Crankshaft Sensor Signal Generation on page 86.
20
§ Camshaft sensor simulation provides 2 camshaft waveform outputs with 8

selectable waveforms for each output. Refer to Camshaft Signal Generator
on page 76 and Camshaft Sensor Signal Generation on page 87.
§ Six different interrupts can be generated depending on the engine position.
Refer to APU Overview on page 71 and Interrupt Controller on page 30.
Event capture The angular processing unit includes two event capture units with the following
functions:
§ For spark event capture, 8 digital ignition inputs (6 ignition and 2 auxiliary
channels) for up to 8-cylinder engines are available. The two auxiliary channels
can be individually configured either for various position measurement or for
ignition capture. Refer to Spark Event Capture Unit on page 77 and Spark
Event Capture on page 90. As a whole, 8 channels are available for spark
event capture.
§ For injection pulse position and fuel amount measurement, 6 digital injection
inputs are available. Refer to Injection Event Capture Unit on page 78 and
Injection Pulse Position and Fuel Amount Measurement on page 91.
Note
If you do not use the ignition capture channels for spark event capture,
you can use them additionally for injection capture (only for boards with
extended functionality, refer to DS2210 Board Revision on page 201).
Frequency measurement For frequency measurement, 8 channels are available with a resolution of 21 bit.
Refer to Frequency Measurement on page 63.
Square-wave signal For square-wave signal generation, 6 channels are available with a resolution of
generation 20 bit. Refer to Square-Wave Signal Generation on page 65.
Interrupt control The DS2210 PHS-bus interrupt controller provides eight hardware interrupts for
the serial interface, CAN subsystem, and angular processing unit. Refer to
DS2210 Interrupts on page 139.
Knock processor A ready-to-use application of the slave DSP provides 4 knock sensor signal
outputs. Each output simulates a knock sensor signal for engines with up to 8
cylinders. Refer to Knock Sensor Simulation on page 96.
Knock sensor simulation and wheel speed sensor simulation cannot be used at
the same time.
Pulse generation For PWM signal generation 6 independent outputs with run-time adjustable
frequencies and duty cycles are available. Refer to PWM Signal Generation
on page 59.
21
Pulse measurement For PWM signal measurement 8 independent input channels are available. Refer
to PWM Signal Measurement on page 56.
Serial interface The serial interface is based on the standard UART TL16C550C from Texas
Instruments, which can be configured as an RS232 or RS422 interface. Refer to
Serial Interface (DS2210) on page 67.
User-specific slave DSP You can program your own slave DSP applications to generate specific signals.
applications Refer to Slave DSP TMS320C31 Basics on page 95.
Wheel speed sensor A ready-to-use application of the slave DSP provides 4 independent wheel speed
simulation sensor outputs. Each output simulates one wheel speed sensor signal. Refer to
Wheel Speed Sensor Simulation on page 99.
Knock sensor simulation and wheel speed sensor simulation cannot be used at
the same time.
22
Features of the Processor Board
Introduction The processor board calculates the real‑time application in the simulator. The
following topics give information on its features that are common to single-
processor as well as multiprocessor operation.
General Information .............................................................................. 24
Timers and Time Base Counters ............................................................. 27
Interrupt Controller ................................................................................ 30
Interfaces .............................................................................................. 32
Monitoring ............................................................................................ 39
The DS1005 provides a Watchdog and monitors the host access.
Flight Recorder ...................................................................................... 40
Information in other sections
DS1005 Multiprocessor Systems .......................................................... 141

Several DS1005 boards can be connected to a multiprocessor system to
increase the computing power.
23
General Information
Physical Characteristics and Requirements .............................................. 24

Provides information on the physical characteristics and requirements of
the DS1005.
Processor ............................................................................................... 25
Provides information on the real-time processor of the DS1005.
Memory ................................................................................................ 25
Provides information on the DS1005's memory.
Physical Characteristics and Requirements
Introduction The DS1005 has the following physical characteristics and requirements:
§ Power supply: 5 V, 4 A
§ Single slot, passive cooling
§ Connection to the host PC via two kind of connections:
§ Bus connection (distances of up to 200 m possible, depending on the bus
connection used).
§ Net connection (arbitrary distance).
§ ISA bus host interface (16 bit)
§ Arbitrated host access to global memory
Tip
In the dSPACE experiment software, you can find information on the

DS1005's bus clock in the Properties dialog of the platform/device. In the
dialog, select the DS1005 Properties page. In this reference the bus clock is
referred to as BCLK.
24
General Information
Processor
Characteristics The DS1005 uses the PowerPC 750 microprocessor as the real‑time processor
(RTP). The RTP calculates your real-time models and accesses the I/O boards via
the PHS bus. This processor has the following characteristics:
§ Up to four parallel instructions
§ 32 KByte L1 data cache
§ 32 KByte L1 instruction cache
For detailed information on the PowerPC 750 microprocessor, refer to the IBM
web site at http://www.ibm.com and search for "PowerPC 750".
Memory
Characteristics The DS1005 is equipped with:

§ 1 MByte level 2 cache
§ 16 MByte flash memory
§ Consists of 64 blocks of 256 KByte each
§ At least 100,000 erase cycles possible
§ 15 MByte can be used for a user‑specific application
§ 1 MByte reserved for the boot firmware
§ 128 MByte SDRAM global main memory
§ Mapped twice in the RTP’s address space: The first mapping in the range of
0x00000000 … 0x07FFFFFF is fully cached (for RTP access). The second
mapping in the range of 0x20000000 … 0x27FFFFFF is uncached (for
communication between the host PC and RTP).
§ Consists of two 64 MByte blocks. Both the host PC and RTP can access
either memory block. Both memory blocks are arbitrated separately.
Therefore, the RTP can access one block at full speed while the host PC
accesses the other. If the RTP and the host PC access the same block
simultaneously, the RTP’s memory access becomes slightly slower than
normal.
§ By default, the processor‑related software and data is held in the first block,
whereas the host‑related software and data is held in the second block.
Memory map The memory and I/O of the DS1005 are mapped to the DS1005’s memory
address range as shown in the following table:
Address Range A[31 … 0] Function

0000 0000H … 07FF FFFFH 128 MB cached global memory area (also
mirrored as uncached global memory area)
0800 0000H … 1200 000FH I/O
25
Address Range A[31 … 0] Function

1400 0000H … 151F FFFFH DS910 Gigalink Module
1800 0000H … 18FF FFFFH 16 MB Flash
18F0 0000H boot vector
2000 0000H … 27FF FFFFH 128 MB uncached global memory area (also
mirrored as cached global memory area)
26
Timers and Time Base Counters

Overview of Timers and Time Base Counters .......................................... 27

Several timers and time base counters are aviable with the DS1005.
Decrementer .......................................................................................... 27
The decrementer can be used as a sample rate timer.
Timer A ................................................................................................. 28
Timer A is usually used for periodic timer events such as the timer‑driven
tasks of an application.
Timer B .................................................................................................. 28
Timer B can be used for periodic or asynchronous events.
Time Base Counter ................................................................................ 29

The Time Base Counter is used for time interval measurement and time
stamping.
Overview of Timers and Time Base Counters
Timers The following timers are available with the DS1005:

§ Decrementer
§ Timer A
§ Timer B
Time base counters The following time base counters are available with the DS1005:
§ Time Base Counter (for single-processor systems)
§ Synchronous Time Base Unit (for multiprocessor systems). Refer to Global Time
Base in an MP System on page 157
Decrementer
Introduction The RTP Built‑In 32-bit Decrementer can be used as a sample rate timer, which
generates an interrupt whenever it reaches -1. After generating an interrupt it is
reloaded automatically. The Decremeter is driven by BCLK/4 and features a fast
access time.
27
Note
The Decrementer is not suitable for multiprocessor‑specific purposes

because its interrupts cannot be forwarded to other DS1005 boards. You
should use Timer A on page 28 instead.
Related topics Basics
Timer A .................................................................................................................................. 28
Timer B ................................................................................................................................... 28
Timer A
Introduction Timer A is usually used for periodic timer events such as the timer‑driven tasks of
an application. The 32-bit down counter generates an interrupt whenever it
reaches zero. After generating an interrupt the down counter is reloaded
automatically. The interrupts can be forwarded to other DS1005 boards, which
makes it suitable for multiprocessing (see Synchronized Timer Tasks
on page 156). Timer A can be used together with the SYNCIN and SYNCOUT
lines of the PHS bus to achieve synchronized I/O access across several I/O boards.
Timer A is driven by BCLK/2.
Decrementer ........................................................................................................................... 27
PHS Bus Interface .................................................................................................................... 32
Timer B ................................................................................................................................... 28
Timer B
Introduction Timer B can be used for periodic or asynchronous events. It is a 32-bit up counter
with a scalable prescaler and programmable compare value that generates an
interrupt when it reaches its compare value. After generating an interrupt, the
counter continues counting (to generate the next interrupt, the compare value
has to be set to the next desired time). The interrupts can be forwarded to other
DS1005 boards, which makes it suitable for multiprocessing. Timer B can be
used together with the SYNCIN and SYNCOUT lines of the PHS bus to achieve
synchronized I/O access across several I/O boards. The prescaler is scalable in
28
power‑of‑two steps (4 … 256) so that Timer B can be driven by

BCLK/256 … BCLK/4.
Decrementer ........................................................................................................................... 27
PHS Bus Interface .................................................................................................................... 32
Timer A .................................................................................................................................. 28
Time Base Counter
Introduction The RTP Built‑In Time Base Counter is a 64‑bit up counter with a fast access time
and is driven by BCLK/4. It is used for time interval measurement and time
stamping.
Time interval measurement The Time Base Counter can be used to measure relative as well as absolute
execution times in handcoded models. For details, refer to Time Interval
Measurement ( DS1005 RTLib Reference).
Time stamping In single-processor systems the Time Base Counter provides the time base for
time stamping. Time stamping supplements data points with their time values.
This means that the plots are not distorted even if data points are sampled at
irregular intervals, for example, when simulating asynchronous tasks.
Since the Time Base Counter is not suitable for multiprocessor systems, the
DS1005 is equipped with the Synchronous Time Base Unit, which provides the
time base for a multiprocessor system. Refer to Global Time Base in an MP
System on page 157.
Tip
You can always use the RTLib’s Time Stamping module to read the current
system time, regardless of whether you run a single‑processor or a
multiprocessor system. The Time Stamping module will automatically access
the correct time base. For details on the Time Stamping module, refer to
Time-Stamping ( DS1005 RTLib Reference).
29
Interrupt Controller
Basics of the Interrupt Controller ........................................................... 30

The interrupt controller handles the DS1005’s various interrupts (level or
edge triggered).
Interrupt Handling ................................................................................. 30

You can handle interrupts using RTI blocks and RTLib functions.
Available Interrupts ................................................................................ 31

A table lists the interrupts that are available on the DS1005.
External Interrupt ................................................................................... 31

To generate an interrupt request (IRQ) via an I/O board.
Basics of the Interrupt Controller
Basics The interrupt controller handles the DS1005’s various interrupts (level or edge
triggered), for example, timer, PHS bus, Gigalink (for multiprocessor systems),
Watchdog, host, and I/O error interrupt. The interrupts can be masked. A global
interrupt enable/disable is also available. The interrupts are prioritized. The I/O
error line and the PHS‑bus interrupt lines are filtered by a digital noise filter,
which suppresses short spikes.
Interrupt Handling
Interrupt handling You can handle interrupts using RTI blocks and RTLib functions.
RTI With RTI you can easily implement interrupt‑driven subsystems by means
of specific interrupt blocks provided in the RTI library. You can use these blocks
to receive interrupts from I/O boards.
RTLib If you create a handcoded model, you can use RTLib functions to
handle interrupts. Refer to Interrupt Handling ( DS1005 RTLib Reference).
Interrupt handling in For multiprocessor‑specific details on interrupt handling, refer to Interrupt

multiprocessor systems Transmission on page 151.
30
Interrupt Controller
Available Interrupts
Introduction The following table lists the interrupts that are available on the DS1005. They are
ordered in descending priority (a smaller vector corresponds to a higher priority):
Vector Description
0 PHSBUS I/O error
1 Watchdog
2 PHSBUS interrupt line 0
10 Timer A
11 Timer B
12 Gigalink 0
13 Gigalink 1
14 Gigalink 2
15 Gigalink 3
16 UART
17 Host interrupt
18 STBU synchronization (Macrotick)
External Interrupt
Introduction To generate an interrupt request (IRQ) via a PHS‑bus I/O board the input signal to
this I/O board should be low level for at least 100 ns. The following illustration
shows the required signal shape:
>100ns
IRQ
31
Interfaces
PHS Bus Interface .................................................................................. 32

To connect the processor board to the I/O boards.
Serial Interface of the DS1005 ............................................................... 35

To communicate with standard RS232 devices.
Specifying the Baud Rate of the Serial Interface ..................................... 36

Provides information on the baud rate that you can specify for the
board's serial interface.
Host Interface ........................................................................................ 37

To exchange data with the host PC.
PHS Bus Interface
PHS bus The processor controls the modular I/O boards via the PHS bus, which is a 32‑bit
I/O bus.
The PHS bus fully supports all PHS‑bus I/O boards, including those that support
the improved PHS++ bus standard.
Control lines In addition to the standard control lines for reading and writing, the PHS bus
provides the following special control lines:
IOERROR This line can be activated by any of the connected I/O boards to
indicate that an error occurred. The I/O boards that support the IOERROR line can
react individually to errors: For example, a DAC board could hold its output
voltage or set it to zero. The DS1005 can set or read this line.
Note
Whenever the DS1005 is reset, it always activates the IOERROR line.
SYNCIN, SYNCOUT These lines allow a synchronized reading (SYNCIN) or

writing (SYNCOUT) of I/O data across several I/O boards. It is also possible to
trigger the lines individually via Timer A or Timer B. To use SYNCIN and
SYNCOUT, the involved I/O boards need to be configured accordingly.
32
Interfaces
Characteristics The PHS bus interface provides:

§ Peak transfer rate: 20 MByte/s, even higher for the improved PHS++ bus
standard
§ Eight interrupts per I/O board
§ Up to 64 I/O interrupts total
Partitioning the PHS bus Usually the processor board and the I/O boards of a PHS-bus-based system are
installed in a single expansion box. With the DS802 PHS Link Board, you can
spatially partition the PHS bus by arranging the I/O boards in several expansion
boxes.
Use scenarios You can use the DS802, for example, in the following
scenarios:
§ According to your development stage, you can easily extend the PHS-bus-
based system with new I/O boards by connecting a separate preconfigured
expansion box to the existing expansion box.
§ Components of the PHS-bus-based system (installed in a separate expansion
box) can easily be replaced and reused, for example, in other projects, without
additional configuration work.
§ If the devices of a test bench are spread out over a large area, you can shorten
the cabling between dSPACE hardware and external devices
(sensors/actuators) by installing I/O boards in a separate expansion box which
is near the external devices.
§ In a few cases the components of your PHS-bus-based system might require
more power than the maximum that a single expansion box supplies. In this
case, you can distribute the I/O boards on several boxes via DS802. This avoids
power limitations in your system caused by single expansion boxes.
Note
The DS802 does not increase the number of usable I/O boards in a PHS-bus-
based system. Note that the PHS bus provides 16 PHS-bus base addresses.
Each I/O board in a PHS-bus-based system and each DS802 installed in a
master box require a unique PHS-bus address. So, up to 15 I/O boards can
be used in a PHS-bus-based system with one DS802.
33
System overview The following illustration shows a typical system

architecture of a partitioned PHS-bus-based system.
Slave box 1
Master box PHS bus

I/O board
PHS link
PHS bus
DS802 DS802
DS1005/
DS1006/ I/O board
DS1007
I/O board
Slave box 2
PHS bus
DS802 I/O board
Max. 100 m
Slave box 3
PHS bus
DS802 I/O board
The box which contains the processor board is called the master box. Boxes
which contain only I/O boards are called slave boxes. One DS802 must be
installed in the master box and one in every slave box.
The DS802 boards provide the necessary link between the boxes via fiber-optic
cable (up to 100 m). As shown above, the link must be a direct connection
between the communication ports of a master box and a slave box. It does not
matter which ports you use to connect a master box to a slave box. All ports
provide the same functionality. DS802 boards installed in a slave box can use
only one communication port. You cannot connect one slave box to several
master boxes at the same time.
You can use the DS802 in multiprocessor systems, for example, where several
processor boards are connected via Gigalink modules.
Behavior of real-time application The logical behavior of the real-time

application (for example, building or executing) when used with a partitioned
PHS-bus-based system is the same as when used with a non-partitioned PHS-
bus-based system.
There is one difference. Partitioning results in additional latencies. This means
that the execution times for C functions of I/O boards installed in a slave box
increase with the number of PHS-bus accesses.
The execution times increase by a factor in a range of approx. 3 … 7. You can
use this range, to estimate the function execution time for an I/O board installed
in a slave box.
34
Interfaces
Tip
The function execution times for boards used in a non-partitioned PHS-bus-

based system are documented in the RTLib References of the respective I/O
board. The function execution times for I/O boards installed in a slave box
are not documented. Use the above mentioned factor to get comparable
values.
Compatibility with processor boards The DS802 can be used in the

simulator. Newer versions of the processor boards are fully compatible with the
DS802. There are older versions which are compatible after an update done by
dSPACE. However, some older DS1005 board versions cannot be used with the
DS802.
For a complete list of compatible processor board versions, refer to DS802 Data
Sheet ( PHS Bus System Hardware Reference).
Supported I/O boards The DS802 can be used in combination with many
types of available dSPACE I/O boards. However, some I/O boards and some
functionalities of specific I/O boards are not supported.
The I/O board support depends on the dSPACE software release which you use.
For a list of supported I/O boards, refer to DS802 Data Sheet ( PHS Bus System
Hardware Reference).
Further information For examples on the usage of the DS802, and notes on
installation and configuration, refer to Partitioning a PHS-Bus-Based System with
the DS802 PHS Link Board ( dSPACE Simulator Mid-Size Based on DS2211
Hardware Installation and Configuration).
Related topics References
PHS-Bus Handling ( DS1005 RTLib Reference)
Serial Interface of the DS1005
Introduction The DS1005 is equipped with a serial interface (UART) to communicate with
standard RS232 devices. The UART is driven by a 14.7456 MHz oscillator, which
allows default transfer rates of up to 115.2 kBaud. For details, see Specifying the
Baud Rate of the Serial Interface on page 36.
Pinouts The RS232 connector is a 9-pin male SUB-D connector and is located on the
DS1005’s bracket. The following illustration shows the pinouts (viewed from
outside).
35
1 5
6 9
The following table shows the pinouts of the RS232 connector.
Pin Signal Description

1 DCR Carrier detect (Input of the DS1005)
2 RXD Receive data (Input of the DS1005)
3 TXD Transmit data (Output of the DS1005)
4 DTR Data terminal ready (Output of the DS1005)
5 GND Ground
6 DSR Data set ready (Input of the DS1005)
7 RTS Request to send (Output of the DS1005)
8 CTS Clear to send (Input of the DS1005)
9 - Not connected
Serial Interface ( DS1005 RTI Reference)

Serial Interface Communication ( DS1005 RTLib Reference)
Specifying the Baud Rate of the Serial Interface
Oscillator frequency The serial interface of the DS2211 is driven by an oscillator with a frequency
fosc = 16 MHz.
Baud rate range Depending on the selected transceiver mode, you can specify the baud rate for
serial communication with the DS2211 in the following range:
Mode Baud Rate Range

RS232 300 … 115,200 baud
RS422 300 … 1,000,000 baud
Available baud rates You can specify any baud rate in the range listed above using RTI and RTLib.
However, the baud rate used by the board is a fraction of the oscillator frequency
fosc. The available baud rates can be calculated according to
f = fosc / (16 · n),
36
Interfaces
where n is a positive integer within the range 1 … 65535.
When you specify a baud rate in RTI or RTLib, the closest available baud rate is
actually used for serial communication. For example, if you specify 70,000 baud
as the baud rate, the baud rate used is 71,429 baud.
Host Interface
Introduction The host interface of the DS1005 consists of eight 16‑bit I/O ports. It serves the
setup of the DS1005, program downloads and runtime data transfers to/from
the host PC. Only 16‑bit I/O instructions are valid.
The host interface provides a bidirectional interrupt line: Via this line the host PC
can send interrupt requests to the RTP and vice versa. Both processors can
monitor the state of the interrupt line to detect when the corresponding
interrupt service is finished.
The host interface also features a supervision circuit, which is described in Force
Reset on page 39.
Memory and I/O access Big endian and little endian The endian modes define the byte sequence
within data types containing several bytes. If the highest byte is the first you see
when you look at the memory byte‑by‑byte, this is big endian. If you see the
lowest byte first, this is little endian.
Access mode of the DS1005 The DS1005’s RTP always works in big endian
mode, whereas the DS1005 offers the memory and I/O access in
Access‑Width‑Dependent little endian format. Therefore, the DS1005 features
automatic conversion to exchange data between the DS1005 and the host PC,
which changes the byte sequence according to the following pattern.
DS1005
Address 000 010 100 110
Data 1112 1314 1516 1718
16-bit access
PC
Address 110 100 010 000
Data 1718 1516 1314 1112
DS1005
Address 000 010 100 110
Data 1112 1314 1516 1718
32-bit access
PC
Address 110 100 010 000
Data 1516 1718 1112 1314
37
DS1005
Address 000 010 100 110
Data 1112 1314 1516 1718
64-bit access
PC
Address 110 100 010 000
Data 1112 1314 1516 1718
Note
You have to use the correct data width for access to the variables. For
example, short integers have to be read with 16‑bit accesses. Be careful
when using block transfers to a data structure with mixed data types.
38
Monitoring
Monitoring
Introduction The DS1005 provides a Watchdog and monitors the host access.
Watchdog ............................................................................................. 39
A Watchdog is used to monitor program execution.
Force Reset ............................................................................................ 39

The DS1005 monitors the host access and force a reset if a DS1005
might block the host PC.
Watchdog
Introduction The Watchdog can be used to monitor program execution. It consists of a timer
that has to be strobed before the timer period expires. If strobed, the timer is
restarted with its period. If the timer period expires, the Watchdog carries out
one of the actions listed below (depending on the Watchdog’s operation mode):
Normal mode The Watchdog generates an interrupt and stops the timer.
When strobed, it restarts the timer.
Reset mode The Watchdog generates an interrupt, reloads, and restarts the
timer. If this period expires, it resets the RTP. If strobed, however, it restarts the
timer.
If the RTP is reset via the Watchdog, it reboots from the flash memory.
Force Reset
Introduction In some very rare cases the DS1005 might block the host PC. This situation can
result from a too long PHS-bus WAIT assertion while the host tries to access the
DS1005’s memory. Due to the arbitrated memory the host has to wait until the
RTP finishes the I/O access. To prevent this situation, the DS1005 measures the
duration of the host access and resets the RTP if the access exceeds 15.2 µs.
39
Flight Recorder
Basics of the Flight Recorder .................................................................. 40

The nonvolatile flash memory can be used to store one application for
stand-alone booting, flight recorder data, and nonvolatile data handling.
Nonvolatile Data Handling ..................................................................... 41

You can use the nonvolatile data feature to store data you may want to
use again when restarting the application.
Basics on Flight Recorder ....................................................................... 42

The flight recorder is used to store time histories of real-time variables in
nonvolatile memory.
Using the Flight Recorder ....................................................................... 43

You can use the flight recorder to write data to the flash memory.
MAT File Format for the Flight Recorder ................................................. 44

Flight Recorder uses the MAT file format.
Basics of the Flight Recorder
Characteristics The flash memory (16 MB) of the DS1005 consists of 64 blocks, each 256 KB in
size. This nonvolatile flash memory can be used to store one application for
stand-alone booting and flight recorder data. Additionally, it can be used for the
Nonvolatile Data Handling. Each data set requires a complete 256-KB flash
memory block, which has to be allocated and registered in the flash module. You
can configure how much memory space you want to use for the application, the
nonvolatile data, and for flight recording. For further information, refer to How
to Upload Flight Recorder Data Written to the Internal Flash Memory
( ControlDesk Measurement and Recording).
40
Flight Recorder
Tip
You can store calibrated parameter values to the flash memory of the
DS1005 and MicroAutoBox. Using the Store Calibration Parameter to Flash
solution, you can let a flash application store calibrated parameter values
during the regular shutdown process or when you switch the SimState from
RUN to STOP in ControlDesk.
When the application restarts from the DS1005/MicroAutoBox’s flash

memory, the application starts with the parameter values recently
calibrated. Without the solution, the application would start with the
original parameter values as defined in the Simulink® model.
For detailed information on the solution, install it from the dSPACE

Solutions DVD and read the user guide. For information on installing it, refer
to the ReadMe.txt file.
Nonvolatile Data Handling
Introduction You can use the nonvolatile data feature to store data you may want to use
again when restarting the application, for example, if you want to resume a
simulation with the last mileage or the settings for an air conditioner.
The nonvolatile data to be stored is collected in a temporary buffer until the

application is reset. Then data is transferred with a specified data label to the
flash memory.
When the application is started again, the nonvolatile data is read out from the
flash memory to the temporary buffer. If no data is stored in the flash or the data
is corrupt, default data values are restored.
Note
If the DS1005 is switched off or reset without termination no data is written

to the flash memory. The data is only transferred to the flash memory, if the
application is stopped via simulation control. The simState parameter has
to be switched from Run to Stop else data is lost.
Flash Memory Access ( DS1005 RTI Reference)

Nonvolatile Data Handling ( DS1005 RTLib Reference)
41
Basics on Flight Recorder
Characteristics The flight recorder is used to store time histories of real-time variables in
nonvolatile memory. During the real-time simulation, the values of real-time
variables are written to the 16 MB flash memory of the DS1005 Board. Up to
15.25 MB (with the nonvolatile feature) or 15.5 MB (without the nonvolatile
feature) of the flash memory can be used for flight recording. The great capacity
of the flight recorder permits long-term data acquisition.
The flight recorder section of the flash memory is organized as FIFO storage. A
maximum of 250 different real-time variables can be recorded.
After the simulation has finished, the acquired data can be read out by the host
PC. On the host PC, the flight recorder data is stored in binary or reference data
(MAT file) format. Because the DS1005 has no real‑time clock, old and new flight
recorder data cannot related to each other. Each time you start the application, a
new MAT file is generated to avoid data overlaying. The files are indexed by
numbering the filename. If you switch off the system without stopping the
application, data is lost.
For detailed information on using the flight recorder, refer to Using the Flight
Recorder on page 43.
Note
If the DS1005 is switched off without resetting, the board data can be lost.
Flash partitioning The flash memory stores various information:

§ Internal data, for example, the boot firmware
§ Data section for the nonvolatile data handling
§ Application data (one application for stand-alone booting)
§ Flight recorder data
According to your settings, these data are used as a memory configuration to

partition the flash memory. If the size of a new application exceeds the specified
size of the application data section, you must clear the complete flash to allow a
new partitioning. For instructions how to clear the flash, refer to How to Clear
an Application from the Flash Memory of dSPACE Real-Time Hardware
( ControlDesk Platform Management).
42
Flight Recorder
The default memory configuration is shown in the following illustration.
0.5
0.25
0 16 MB
Reserved Application Flight recorder

≤ (15.25 – Application_size) MB
NV data feature
Time stamps In the flight recorder, data captures are stored together with time stamps. Time
stamps are measured in seconds with a resolution of 10.24 µs relative to the
time base 1970‑01‑01. Time stamps are interpreted appropriately by MATLAB or
dSPACE experiment software. You can change the time base using M-program
code. For an example, refer to MAT File Format for the Flight Recorder
on page 44.
Flash Memory Access ( DS1005 RTI Reference)

Flight Recorder (Flash Memory) ( DS1005 RTLib Reference)
Using the Flight Recorder
Introduction You can use RTI’s library rtiflashlib or RTLib functions to write flight recorder
data to the flash memory.
Memory overwrite mode You can choose via RTI or RTLib functions how data will be handled when the
memory block for flight recording is full:
Discard new data (blocked mode) When the memory block for flight
recording is full, no further data will be recorded.
Replace old data (overwrite mode) When the memory block for flight
recording is full, the oldest entries will be replaced.
Note
To avoid the loss of data you should save the data to the PC and delete the
data from the flash memory in regular intervals. The application must be
stopped before.
43
Loading data to the host PC After the simulation has finished, the acquired data can be read out by the host
PC. Reading out the data does not delete the data from the flash memory. To
avoid signal overlaying, for each time the flight recorder is started, a separate
MAT file is generated during the upload of the data. The files are indexed by
numbering the file name.
Tip
Reading the data in MAT format requires more resources on the host PC
(processor and memory). In the vehicle, you can upload a binary file to the
host PC and convert the data to a MAT file later on. In the laboratory, you
can upload the data directly to a MAT file (refer to MAT File Format for the
Flight Recorder on page 44).
To handle flight recorder data with ControlDesk, refer to Uploading Flight

Recorder Data ( ControlDesk Measurement and Recording).
Basics on Flight Recorder ........................................................................................................ 42
MAT File Format for the Flight Recorder
Introduction Flight Recorder uses the MAT file format.
MAT file format MAT files generated by the flight recorder contain a separate x-axis (timestamp
vector) for each y-axis. To find the correct x‑axis, the XIndex element of the y-axis
data struct must be evaluated. For an example, see the code below.
For instructions on how to access the data of a MAT file, see Postprocessing
Recorded Data With MATLAB ( ControlDesk Measurement and Recording). For
details on the MAT file structure, see Structure of MAT Files Generated by
Exporting Recorded Data ( ControlDesk Measurement and Recording).
44
Flight Recorder
Plotting flight recorder data The following program code shows you how to plot flight recorder data. You
have to change <MATFILENAME> and <VARNAME> with your own names.
load <MATFILENAME>.mat
varValues = <MATFILENAME>;
n = 1;
figure;
use_XIndex = varValues.Y(n).XIndex;
plot(varValues.X(use_XIndex).Data, varValues.Y(n).Data);
xlabel('Time/sec');
ylabel(varValues.Y(n).Name);
Let the index n increase to display all the recorded data.
Basics on Flight Recorder ........................................................................................................ 42

Using the Flight Recorder ........................................................................................................ 43
45
46
Sensor and Actuator Interface
Introduction The sensor and actuator interface (SAI) has several units for signal generation
and signal measurement. The following topics provide information on the
components.
ADC Unit ............................................................................................... 48

The DS2210 has an analog digital converter (DAC) unit providing 16
inputs.
DAC Unit ............................................................................................... 50

The DS2210 has a digital analog converter (DAC) unit for user output.
D/R Converter ........................................................................................ 52

The DS2210 has a digital resistance (D/R) converter to simulate sensors
that have a resistance output.
Bit I/O Unit ............................................................................................ 54

The bit I/O unit contains one 16-bit port for input that provides 16
discrete digital input lines, and one 16-bit port for output that provides
16 discrete digital outputs.
PWM Signal Measurement ..................................................................... 56

In hardware-in-the-loop applications, PWM signal measurement is used
to capture digital signals. For evaluation of frequencies and duty cycles,
digital pulses have to be recorded with high speed and transferred to a
processor that performs the analysis.
PWM Signal Generation ........................................................................ 59

Six independent PWM outputs are available for the generation of
nonnegative square-wave signals.
Frequency Measurement ........................................................................ 63

Eight independent channels are available to measure the frequency of
square-wave signals.
47
Square-Wave Signal Generation ............................................................. 65

Six independent channels are available to generate square-wave signals
with variable frequencies.
Serial Interface (DS2210) ....................................................................... 67

The DS2210 contains a standard UART that can be configured as an
RS232 or RS422 interface.
Features Served by the Slave DSP ........................................................... 95

Wheel speed sensor simulation and knock sensor simulation are
performed by a ready-to-use application implemented on the slave DSP.
ADC Unit
Characteristics The ADC unit consists of a 12-bit successive approximation register (SAR) A/D
converter with a 16:1 input multiplexer that provides 16 inputs (ADC1 …
ADC16), with 12‑bit resolution each, 1.1 μs conversion time, and one integrated
sample/hold for all inputs. All inputs are differential unipolar inputs with 0 … 20
V input span, lowpass input filters (1st order/–3 dB at 240 kHz), 27 kΩ input
impedance to system ground, and continuous ±50 V DC overvoltage protection.
The input channels can be read individually or blockwise. The control logic allows
starting conversion for the first 4, 8, 12 or 16 channels (starting from channel 1).
48
ADC Unit
The illustration shows a simplified block diagram of the ADC unit.
ADC1
ADC1 Offs et & Gain

Calibration
16:1
...
Input 12-bit 16 x 12-bit
Multiplexer S AR R egis ters
ADC16
ADC16
Note
§ ADC inputs ADC1 to ADC12 are internally connected to the FIU and load
cards. For more information, refer to Load Simulation on page 177.
§ ADC inputs ADC1 to ADC12 are differential inputs but their ground sense
line (ADCx) are internally connected to GNDBAT at the load side. The
ADCs measure the voltage across the load.
§ ADC13 is not connected to the FIU and load card. It has an ground sense
line (ADC13). The ADC measures the voltage difference of (ADC13 –
ADC13).
§ The ADC14, ADC15, and ADC16 inputs are used for remote-controlling
the power supply.
Execution times The execution times required by the RTLib functions have been measured. For
details on the results and the corresponding measurement setup, refer to
Function Execution Times ( DS2210 RTLib Reference).
I/O mapping The following table shows the mapping of the A/D channel numbers to the
related I/O pins of the ECU connectors, as used in RTI and RTLib.
A/D Channel Signal ECU Connector Pin Description Voltage Range / Remark
1 ADC1 2 CF 12‑bit ADC (ADC1 – GND) = 0 … 20 V
2 ADC2 2 CH 12‑bit ADC (ADC2 – GND) = 0 … 20 V
49
A/D Channel Signal ECU Connector Pin Description Voltage Range / Remark
3 ADC3 2 CJ 12‑bit ADC (ADC3 – GND) = 0 … 20 V
4 ADC4 2 CK 12‑bit ADC (ADC4 – GND) = 0 … 20 V
5 ADC5 2 CL 12‑bit ADC (ADC5 – GND) = 0 … 20 V
6 ADC6 2 CM 12‑bit ADC (ADC6 – GND) = 0 … 20 V
7 ADC7 2 CN 12‑bit ADC (ADC7 – GND) = 0 … 20 V
8 ADC8 2 CP 12‑bit ADC (ADC8 – GND) = 0 … 20 V
9 ADC9 2 CR 12‑bit ADC (ADC9 – GND) = 0 … 20 V
10 ADC10 2 CS 12‑bit ADC (ADC10 – GND) = 0 … 20 V
11 ADC11 2 CT 12‑bit ADC (ADC11 – GND) = 0 … 20 V
12 ADC12 2 CU 12‑bit ADC (ADC12 – GND) = 0 … 20 V
13 ADC13 1 E 12‑bit ADC (ADC13 – ADC13) = 0 … 20 V
ADC13 1 D
14 ADC14 – – 12‑bit ADC Used by the simulator, see Controlling the Battery Voltage
on page 171
on page 171
on page 171
ADC Unit ( DS2210 RTI Reference)

ADC Unit ( DS2210 RTLib Reference)
Analog Inputs ( PHS Bus System Hardware Reference)
DS2210MUX_ADC_Bx ( DS2210 RTI Reference)
DAC Unit
Characteristics The DAC unit contains three quad D/A converters for user output that provide 12
unipolar analog outputs (DAC1 … DAC12) with 12‑bit resolution (fully
monotonic) and 20 μs full-scale settling time to 1 LSB.
Note
The DAC12 output is used for remote-controlling the power supply by

dSPACE Simulator Mid-Size.
50
DAC Unit
The DAC unit works with an internal reference of VREF = 10 V.
Note
DAC outputs are differential outputs within the range of 0 … 10 V. Each

output has an individual ground sense line (DACx), which must be
connected to the ground (signal ground) pin of the ECU, for all DAC
channels used. The DAC controls the voltage difference of (DACx – DACx).
Tip
The DACx pins can be switched to the signal ground inside the simulator,
see Sensor Ground Switches ( dSPACE Simulator Mid-Size Hardware
Installation and Configuration).
The outputs have lowpass output filters (1st order/–3 dB at 130 kHz). The
maximum sink/source current of the DAC outputs is ±5 mA.
I/O mapping The following table shows the mapping of the D/A channel numbers to the
related I/O pins of the ECU connector, as used in RTI and RTLib.
D/A Channel Signal ECU Connector Pin Description Voltage Range/Output Current
1 DAC1 1 B 12-bit DAC/20 µs (DAC1 – DAC1) = 0 … 10 V; ±5 mA
DAC1 1 C
2 DAC2 1 F 12-bit DAC/20 µs (DAC2 – DAC2) = 0 … 10 V; ±5 mA
DAC2 1 H
3 DAC3 1 J 12-bit DAC/20 µs (DAC3 – DAC3) = 0 … 10 V; ±5 mA
DAC3 1 K
4 DAC4 1 L 12-bit DAC/20 µs (DAC4 – DAC4) = 0 … 10 V; ±5 mA
DAC4 1 M
5 DAC5 1 N 12-bit DAC/20 µs (DAC5 – DAC5) = 0 … 10 V; ±5 mA
DAC5 1 P
6 DAC6 1 R 12-bit DAC/20 µs (DAC6 – DAC6) = 0 … 10 V; ±5 mA
DAC6 1 S
7 DAC7 1 T 12-bit DAC/20 µs (DAC7 – DAC7) = 0 … 10 V; ±5 mA
DAC7 1 U
8 DAC8 1 V 12-bit DAC/20 µs (DAC8 – DAC8) = 0 … 10 V; ±5 mA
DAC8 1 W
9 DAC9 1 X 12-bit DAC/20 µs (DAC9 – DAC9) = 0 … 10 V; ±5 mA
DAC9 1 Y
51
D/A Channel Signal ECU Connector Pin Description Voltage Range/Output Current
10 DAC10 1 Z 12-bit DAC/20 µs (DAC10 – DAC10) = 0 … 10 V; ±5 mA
DAC10 1 AA
11 DAC11 1 AD 12-bit DAC/20 µs (DAC11 – DAC11) = 0 … 10 V; ±5 mA
DAC11 1 AC
12 DAC12 – – 12-bit DAC/20 µs Used by the simulator, see Controlling the Battery Voltage
DAC12 – – on page 171
DAC Unit ( DS2210 RTI Reference)

DAC Unit ( DS2210 RTLib Reference)
D/R Converter
Introduction The D/R converter provides the possibility to simulate sensors that have a
resistance output, for example, thermistors or RTDs for temperature
measurements. You can also use the D/R converter to simulate loose
connections. To generate the desired resistance your application writes a value to
the D/R converter, which simulates the resistance electronically between the two
output pins (RESx+, RESx–) of the specified resistor channel.
Characteristics The D/R converter provides six independent resistance outputs with 16‑bit
resolution, covering a resistance range of 15 Ω … ∞. You can set the resistance
value to 1 MΩ / x (with x within the range of 0 … 65535).
The maximum output power per channel is Pmax = 250 mW. The maximum
output current per channel is Imax = ±80 mA.
52
D/R Converter
The illustration shows a simplified block diagram of one resistor channel.

RESx+
1nF 1 MΩ 500 kΩ 250 kΩ ... 30.5 Ω
RESx-
100nF
Several resistor channels can be connected in parallel to increase Imax and Pmax, or
connected in series to increase Rmax and the resolution in higher resistance
ranges.
Note
Resistors are not grounded. Terminals must stay within the range of ±10 V
to the ground (signal ground) of the ECU for operation. For simulating a
resistor with one terminal grounded, it is recommended that you use RESx–
as the grounded terminal. Taking RESx– outside ±5 V from system GND
results in extra resistance error (typically 2 Ω) due to the on-resistance of the
solid state switches.
Tip
The RESx– pins can be switched to the signal ground inside the simulator,
see Sensor Ground Switches ( dSPACE Simulator Mid-Size Hardware
53
I/O mapping The following table shows the mapping of the resistor channel numbers to the
related I/O pins of the ECU connector, as used in RTI and RTLib.
Channel Number Signal ECU Connector Pin Description Power/Output Current

1 RES1+ 1 AF Resistance output Pmax = 250 mW; Imax = ±80 mA
RES1– 1 AH
2 RES2+ 1 AJ Resistance output Pmax = 250 mW; Imax = ±80 mA
RES2– 1 AB
3 RES3+ 1 AL Resistance output Pmax = 250 mW; Imax = ±80 mA
RES3– 1 AM
4 RES4+ 1 AN Resistance output Pmax = 250 mW; Imax = ±80 mA
RES4– 1 AP
5 RES5+ 1 AU Resistance output Pmax = 250 mW; Imax = ±80 mA
RES5– 1 AT
6 RES6+ 1 AK Resistance output Pmax = 250 mW; Imax = ±80 mA
RES6– 1 AR
D/R Converter ( DS2210 RTI Reference)

DS2210RES_Bx_Cy ( DS2210 RTI Reference)
Bit I/O Unit
Characteristics The bit I/O unit contains one 16-bit port for input that provides 16 discrete digital
input lines, and one 16-bit port for output that provides 16 discrete digital
outputs.
The inputs are 12 V compatible (fully operational up to 18 V). They are protected
against overvoltage higher than 18 V. After software initialization, the input
threshold is set to 2.5 V. Using RTI/RTLib functions, you can set the input
threshold within the range of 1 … 7 V.
The outputs have push-pull drivers running from an external source (VBAT within
the range of 8 … 18 V). They are protected against overvoltage higher than 18
V. The maximum output current per channel is ±50 mA. Short circuit proof to
GND and VBAT is implemented. The outputs are in their high impedance states
after reset.
54
Bit I/O Unit
Using RTI/RTLib functions, you can enable or disable all outputs.
Note
Before operating the digital outputs of the bit I/O unit, an external power
supply (VBat) must be connected.
I/O mapping The following table shows the mapping of the channel numbers to the related
I/O pins of the ECU connector, as used in RTI and RTLib.
Channel Number Signal ECU Pin Description Voltage Range

Connector
1 DIG_IN1 2 AM Digital input 12 V compatible
2 DIG_IN2 2 AN Digital input 12 V compatible
3 DIG_IN3 2 AP Digital input 12 V compatible
4 DIG_IN4 2 AR Digital input 12 V compatible
5 DIG_IN5 2 AS Digital input 12 V compatible
6 DIG_IN6 2 AT Digital input 12 V compatible
7 DIG_IN7 2 AU Digital input 12 V compatible
8 DIG_IN8 2 AV Digital input 12 V compatible
9 DIG_IN9 2 AW Digital input 12 V compatible
10 DIG_IN10 2 AX Digital input 12 V compatible
11 DIG_IN11 2 AY Digital input 12 V compatible
12 DIG_IN12 2 AZ Digital input 12 V compatible
13 DIG_IN13 2 BA Digital input 12 V compatible
14 DIG_IN14 2 BB Digital input 12 V compatible
15 DIG_IN15 2 BC Digital input 12 V compatible
16 DIG_IN16 2 BD Digital input 12 V compatible
1 DIG_OUT1 1 AW Digital output 0.4 V … (VBAT – 2 V); ±50 mA
2 DIG_OUT2 1 AY Digital output 0.4 V … (VBAT – 2 V); ±50 mA
3 DIG_OUT3 1 AZ Digital output 0.4 V … (VBAT – 2 V); ±50 mA
4 DIG_OUT4 1 BA Digital output 0.4 V … (VBAT – 2 V); ±50 mA
5 DIG_OUT5 1 AX Digital output 0.4 V … (VBAT – 2 V); ±50 mA
6 DIG_OUT6 1 BC Digital output 0.4 V … (VBAT – 2 V); ±50 mA
7 DIG_OUT7 1 BD Digital output 0.4 V … (VBAT – 2 V); ±50 mA
8 DIG_OUT8 1 BE Digital output 0.4 V … (VBAT – 2 V); ±50 mA
9 DIG_OUT9 1 BB Digital output 0.4 V … (VBAT – 2 V); ±50 mA
10 DIG_OUT10 1 BH Digital output 0.4 V … (VBAT – 2 V); ±50 mA
55
Channel Number Signal ECU Pin Description Voltage Range

Connector
11 DIG_OUT11 1 BJ Digital output 0.4 V … (VBAT – 2 V); ±50 mA
12 DIG_OUT12 1 BK Digital output 0.4 V … (VBAT – 2 V); ±50 mA
13 DIG_OUT13 1 BL Digital output 0.4 V … (VBAT – 2 V); ±50 mA
14 DIG_OUT14 1 BM Digital output 0.4 V … (VBAT – 2 V); ±50 mA
15 DIG_OUT15 1 BN Digital output 0.4 V … (VBAT – 2 V); ±50 mA
16 DIG_OUT16 1 BF Digital output 0.4 V … (VBAT – 2 V); ±50 mA
Digital Inputs ( PHS Bus System Hardware Reference)

Digital Outputs ( PHS Bus System Hardware Reference)
DS2210DIO_SETUP_Bx ( DS2210 RTI Reference)
PWM Signal Measurement
Introduction In hardware-in-the-loop applications, PWM signal measurement is used to

capture digital signals. For evaluation of frequencies and duty cycles, digital
pulses have to be recorded with high speed and transferred to a processor that
performs the analysis.
Note
§ For boards with extended functionality, the resolution of PWM signal

measurement is 16 bit. Else the resolution is 14 bit. To check whether
your board supports 16 bit, refer to DS2210 Board Revision on page 201.
§ The channels can be used either for frequency measurement or PWM
signal measurement (supported only for boards with extended
functionality).
§ Due to quantization effects, you will encounter considerable deviations
between the input PWM period TP and the measured PWM period,
especially for higher PWM frequencies. To avoid a poor frequency
resolution, you should therefore select the frequency range with the
highest resolution (resolution values as small as possible), refer to
Quantization Effects on page 200.
Characteristics For analysis of the duty cycle, frequency, and low and high periods of PWM type
signals, eight independent PWM channels are available.
56
PWM Signal Measurement
The inputs are 12 V compatible (fully operational up to 18 V). After software

initialization, the input threshold is set to 2.5 V. Using RTI/RTLib functions, you
can set the input threshold for all digital inputs within the range of 1 V … 7 V.
Frequency and duty cycle 16-bit resolution boards Based on a 16-bit resolution, you measure the duty
cycle within 0 … 100% for PWM frequencies within the range of
0.01 Hz … 20 kHz.
14-bit resolution boards Based on a 14-bit resolution, you measure the duty
0.04 Hz … 20 kHz.
PWM signal
high
low
t
Thigh Tlow
Thigh + Tlow T
The measurements of the Tlow and Thigh periods are used to calculate
§ frequency = 1 / (Tlow + Thigh)
§ duty cycle = Thigh / (Tlow + Thigh)
For exact measurements, you have to select the expected period range of the
PWM type signal to be measured.
Measurement range 16-bit resolution boards Based on a 16-bit resolution and depending on the
prescaler setting, the periods can be measured within the following limits and
resolutions:
Range Minimum Period Maximum Period Resolution

Theoretical Practical
1 200 ns 50 µs 3.27 ms 50 ns
2 400 ns 50 µs 6.55 ms 100 ns
3 800 ns 50 µs 13.1 ms 200 ns
4 1.6 µs 50 µs 26.2 ms 400 ns
5 3.2 µs 50 µs 52.4 ms 800 ns
6 6.4 µs 50 µs 104 ms 1.6 µs
7 12.8 µs 50 µs 209 ms 3.2 µs
8 25.6 µs 50 µs 419 ms 6.4 µs
9 51.2 µs 51.2 µs 838 ms 12.8 µs
10 103 µs 103 µs 1.67 s 25.6 µs
11 205 µs 205 µs 3.35 s 51.2 µs
57

12 410 µs 410 µs 6.71 s 103 µs
13 820 µs 820 µs 13.4 s 205 µs
14 1.64 ms 1.64 ms 26.8 s 410 µs
15 3.28 ms 3.28 ms 53.6 s 820 µs
16 6.55 ms 6.55 ms 107.3 s 1.64 ms
14-bit resolution boards Based on a 14-bit resolution and depending on the

prescaler setting, the periods can be measured within the following limits and
resolutions:

1 200 ns 50 µs 819 µs 50 ns
2 400 ns 50 µs 1.64 ms 100 ns
3 800 ns 50 µs 3.28 ms 200 ns
4 1.6 µs 50 µs 6.55 ms 400 ns
5 3.2 µs 50 µs 13.1 ms 800 ns
6 6.4 µs 50 µs 26.2 ms 1.6 µs
7 12.8 µs 50 µs 52.4 ms 3.2 µs
8 25.6 µs 50 µs 105 ms 6.4 µs
9 51.2 µs 51.2 µs 210 ms 12.8 µs
10 102 µs 102 µs 419 ms 25.6 µs
11 205 µs 205 µs 839 ms 51.2 µs
12 410 µs 410 µs 1.68 s 102 µs
13 819 µs 819 µs 3.36 s 205 µs
14 1.64 ms 1.64 µs 6.71 s 410 µs
15 3.28 ms 3.28 ms 13.4 s 819 µs
16 6.55 ms 6.55 ms 26.8 s 1.64 ms
The maximum period applies for 0% < duty cycle < 100%. At 50% of the duty
cycle, the maximum period values double.
If these ranges are exceeded, the measurement will be faulty. For values outside
the practical period range, you have to consider the following restrictions:
Range Restriction
PWM period < theoretical minimum period No precise measurement (undersampling). Some high or low periods
may not be recognized.
PWM period < 50 µs, Thigh or Tlow < 10 µs Input noise filter may remove pulses that you want to measure.
Max. period < PWM period < 2 · max. period Frequency measurement with restricted duty cycle.
PWM period > 2 · maximum period Frequency measurement with duty cycle alternating between 0 and
1.
58
PWM Signal Generation
The duty cycle values 0 (input constant low) and 1 (input constant high) are
measured properly.
Note
Signal periods and resolution
Each high period and each low period of the measured signal must be
longer (not equal) than the resolution to avoid missing pulses.
I/O mapping The following table shows the mapping of the PWM channel numbers to the
related I/O pins of the ECU connector, as used in RTI and RTLib. The I/O features
of the DS2210 conflict with each other. Refer to Conflicting I/O Features
on page 201.
PWM Channel Signal ECU Connector Pin Description Voltage

1 PWM_IN1 2 BE PWM signal measurement 12 V compatible
2 PWM_IN2 2 BF PWM signal measurement 12 V compatible
3 PWM_IN3 2 BH PWM signal measurement 12 V compatible
4 PWM_IN4 2 BJ PWM signal measurement 12 V compatible
5 PWM_IN5 2 BK PWM signal measurement 12 V compatible
6 PWM_IN6 2 BL PWM signal measurement 12 V compatible
7 PWM_IN7 2 BM PWM signal measurement 12 V compatible
8 PWM_IN8 2 BN PWM signal measurement 12 V compatible

DS2210PWM2D_Bx_Cy ( DS2210 RTI Reference)
PWM Signal Measurement ( DS2210 RTLib Reference)
Characteristics Six independent PWM outputs are available for the generation of nonnegative
square-wave signals with a run-time adjustable frequency and run-time
adjustable duty cycle. New values for Thigh and Tlow are updated immediately. An
59
update can happen anywhere during the PWM period. So it is possible, that a
high or low pulse is cut off. This occurs when the new Thigh or Tlow value is
shorter than the current one, and exceeds the time which has elapsed in the
current Thigh or Tlow period, respectively. This can result in a non-constant PWM
period during update (i.e. actual Thigh + Tlow).
Note
§ Before operating the digital outputs of PWM signal generation, an

external power supply (VBat) must be connected.
§ For boards with extended functionality, the resolution of PWM signal
generation is 16 bit. Else the resolution is 14 bit. To check whether your
board supports 16 bit, refer to DS2210 Board Revision on page 201.
§ The channels can be either used for square-wave signal generation or
PWM signal generation (supported only for boards with extended
functionality).
§ Due to quantization effects, you will encounter considerable deviations
between the input PWM period TP and the generated PWM period,
especially for higher PWM frequencies. To avoid a poor frequency
resolution, you should therefore select the frequency range with the
highest resolution (resolution values as small as possible).
Duty cycle 16-bit resolution boards Based on a 16-bit resolution, you can set the duty
0.01 Hz … 20 kHz.
14-bit resolution boards Based on a 14-bit resolution, you can set the duty
0.04 Hz … 20 kHz.
The duty cycle values 0 and 1 yield a constant low or constant high output
signal. The following illustration shows how the duty cycle = (Thigh / (Tlow + Thigh))
is defined.
PWM signal
high
low
t
Thigh Tlow
Thigh + Tlow T
60
Limits and resolutions 16-bit resolution boards Depending on the prescaler setting, the signals can
be generated within the following limits and resolutions:

1 100 ns 50 µs 3.27 ms 50 ns
2 200 ns 50 µs 6.55 ms 100 ns
3 400 ns 50 µs 13.1 ms 200 ns
4 800 ns 50 µs 26.2 ms 400 ns
5 1.6 µs 50 µs 52.4 ms 800 ns
6 3.2 µs 50 µs 104 ms 1.6 µs
7 6.4 µs 50 µs 209 ms 3.2 µs
8 12.8 µs 50 µs 419 ms 6.4 µs
9 25.6 µs 50 µs 838 ms 12.8 µs
10 51.2 µs 51.2 µs 1.67 s 25.6 µs
11 103 µs 103 µs 3.35 s 51.2 µs
12 205 µs 205 µs 6.71 s 103 µs
13 410 µs 410 µs 13.4 s 205 µs
14 820 µs 820 µs 26.8 s 410 µs
15 1.64 ms 1.64 ms 53.6 s 820 µs
16 3.28 ms 3.28 ms 107.3 s 1.64 ms
14-bit resolution boards Depending on the prescaler setting, you can

generate PWM signals within the following limits and resolutions:

1 100 ns 50 µs 819 µs 50 ns
2 200 ns 50 µs 1.64 ms 100 ns
3 400 ns 50 µs 3.28 ms 200 ns
4 800 ns 50 µs 6.55 ms 400 ns
5 1.6 µs 50 µs 13.1 ms 800 ns
6 3.2 µs 50 µs 26.2 ms 1.6 µs
7 6.4 µs 50 µs 52.4 ms 3.2 µs
8 12.8 µs 50 µs 105 ms 6.4 µs
9 25.6 µs 50 µs 210 ms 12.8 µs
10 51.2 µs 51.2 µs 419 ms 25.6 µs
11 102 µs 102 µs 839 ms 51.2 µs
12 205 µs 205 µs 1.68 s 102 µs
13 410 µs 410 µs 3.36 s 205 µs
14 819 µs 819 µs 6.71 s 410 µs
15 1.64 ms 1.64 ms 13.4 s 819 µs
16 3.28 ms 3.28 ms 26.8 s 1.64 ms
61
Maximum period The maximum period applies for generating signals with a
0 … 100% duty cycle. At 50%, the maximum period values double. If these
ranges are exceeded, the PWM signal generation will be faulty. For values
outside the practical period range, you have to consider the following
restrictions:
Range Restriction
PWM period < theoretical minimum period No PWM signal generation. Signal is constantly high or low.
Theoretical min. period < PWM PWM signal will be distorted due to limited switching speed of the
period < 50 µs output circuits.
Max. period < PWM period < 2 · max. period PWM signal with restricted duty cycle.
Outputs The outputs have push-pull drivers running from an external source (VBAT within
the range of 8 … 18 V). They are protected against overvoltage higher than
18 V. The maximum output current per channel is ±50 mA. Short circuit proof to
GND and VBAT is implemented. The outputs are in their high impedance states
after reset.
Using RTI/RTLib functions, you can enable or disable the outputs.
I/O mapping The following table shows the mapping of the logical PWM channel numbers to
the related I/O pins of the ECU connector, as used in RTI and RTLib. The I/O
features of the DS2210 conflict with each other. Refer to Conflicting I/O Features
on page 201.

1 PWM_OUT1 1 BR PWM signal generation 0.4 V … (VBat – 2 V); ±50 mA
2 PWM_OUT2 1 BS PWM signal generation 0.4 V … (VBat – 2 V); ±50 mA
3 PWM_OUT3 1 BT PWM signal generation 0.4 V … (VBat – 2 V); ±50 mA
4 PWM_OUT4 1 BU PWM signal generation 0.4 V … (VBat – 2 V); ±50 mA
5 PWM_OUT5 1 BX PWM signal generation 0.4 V … (VBat – 2 V); ±50 mA
6 PWM_OUT6 1 BW PWM signal generation 0.4 V … (VBat – 2 V); ±50 mA

DS2210PWM_Bx_Cy ( DS2210 RTI Reference)
PWM Signal Generation ( DS2210 RTLib Reference)
62
Frequency Measurement
Frequency Measurement
Characteristics 8 independent channels are available to measure the frequency of square-wave

signals.
Note
§ Frequency measurement and generation is supported only for boards with

extended functionality. To check whether your board supports extended
functionality, refer to DS2210 Board Revision on page 201.
§ The channels can be used either for frequency measurement or PWM
signal measurement.
Based on a 21-bit resolution, you can measure frequencies within the range of
0.3 mHz … 20 kHz.
The inputs are 12-V compatible (fully operational up to 18 V). The input
threshold can be set within the range of 1 … 7 V. The default value is 2.5 V.
Using RTI/RTLib functions, you can set the input threshold for all digital inputs
within the range of 1 … 7 V.
Measurement range To get the best resolution of the measured square-wave signal, you should
always use the frequency range with the lowest possible range number. You can
measure frequencies within the following ranges:
Range Minimum Maximum Resolution

Frequency Frequency
1 9.54 Hz 20 kHz 50 ns
2 4.77 Hz 20 kHz 100 ns
3 2.39 Hz 20 kHz 200 ns
4 1.20 Hz 20 kHz 400 ns
5 0.60 Hz 20 kHz 800 ns
6 0.30 Hz 20 kHz 1.6 µs
7 0.15 Hz 20 kHz 3.2 µs
8 75 mHz 20 kHz 6.4 µs
9 38 mHz 19.53 kHz 12.8 µs
10 19 mHz 9.76 kHz 25.6 µs
11 10 mHz 4.88 kHz 51.2 µs
12 5.0 mHz 2.44 kHz 103 µs
13 2.5 mHz 1.22 kHz 205 µs
14 1.2 mHz 610.35 Hz 410 µs
15 0.6 mHz 305.17 Hz 820 µs
16 0.3 mHz 152.59 Hz 1.64 ms
63
If these ranges are exceeded, the measurement will be faulty. For values outside
the frequency ranges, you have to consider the following restrictions:
Range Restriction
Frequency < fmin The measured frequency is measured as 0 Hz
signal.
Frequency > fmax Faulty measurement because of quantization
problems, refer to Quantization Effects
on page 200.
Note
Signal periods and resolution
Each high period and each low period of the measured signal must be
longer (not equal) than the resolution to avoid missing pulses.
I/O mapping The following table shows the mapping of the PWM channel numbers to the
of the DS2210 conflict with each other. For details, see Conflicting I/O Features
on page 201.

1 PWM_IN1 2 BE Frequency measurement 12 V compatible
2 PWM_IN2 2 BF Frequency measurement 12 V compatible
3 PWM_IN3 2 BH Frequency measurement 12 V compatible
4 PWM_IN4 2 BJ Frequency measurement 12 V compatible
5 PWM_IN5 2 BK Frequency measurement 12 V compatible
6 PWM_IN6 2 BL Frequency measurement 12 V compatible
7 PWM_IN7 2 BM Frequency measurement 12 V compatible
8 PWM_IN8 2 BN Frequency measurement 12 V compatible

ds2210_f2d ( DS2210 RTLib Reference)
DS2210F2D_Bx_Cy ( DS2210 RTI Reference)
64
Square-Wave Signal Generation
Square-Wave Signal Generation
Characteristics 6 independent channels are available to generate square-wave signals with

variable frequencies.
Note
§ Square-wave signal generation is supported only for boards with

extended functionality. To check whether your board supports extended
functionality, refer to DS2210 Board Revision on page 201.
§ Before operating the digital outputs of the unit, an external power supply
(VBat) must be connected.
§ The channels can be used either for square-wave signal generation or
PWM signal generation.
Resolution and frequency ranges Based on a 20-bit resolution of the

board, you can generate square-wave signal within the frequency range of
0.3 mHz … 20 kHz.
To get the best resolution of the square-wave signal to be generated, you should
always use the frequency range with the lowest possible range number. You can
generate square-wave signals within the following frequency ranges:
Range Minimum Frequency Maximum Frequency Resolution

1 9.54 Hz 20 kHz 50 ns
2 4.77 Hz 20 kHz 100 ns
3 2.39 Hz 20 kHz 200 ns
4 1.20 Hz 20 kHz 400 ns
5 0.60 Hz 20 kHz 800 ns
6 0.30 Hz 20 kHz 1.6 µs
7 0.15 Hz 20 kHz 3.2 µs
8 75 mHz 20 kHz 6.4 µs
9 38 mHz 20 kHz 12.8 µs
10 19 mHz 19.53 kHz 25.6 µs
11 10 mHz 9.76 kHz 51.2 µs
12 5.0 mHz 4.88 kHz 103 µs
13 2.5 mHz 2.44 kHz 205 µs
14 1.2 mHz 1.22 kHz 410 µs
15 0.6 mHz 610.35 Hz 820 µs
16 0.3 mHz 305.17 Hz 1.64 ms
If these ranges are exceeded, the square-wave signal generation will be faulty.
65
Outside frequency range For values outside the frequency ranges, you have
to consider the following restrictions:
Range Restriction
Frequency < fmin The frequency is set to 0 Hz.
Frequency > fmax The frequency saturates to fmax.
Outputs The outputs have push-pull drivers running from an external source (VBAT within
the range of 8 V… 18 V). The maximum output current per channel is ±50 mA.
Short circuit proof to GND and VBAT is implemented. The outputs are in their
high impedance states after reset.
I/O mapping The following table shows the mapping of the logical PWM channel numbers to
the related I/O pins of the ECU connector, as used in RTI and RTLib. The I/O
features of the DS2210 conflict with each other. Refer to Conflicting I/O Features
on page 201.

1 PWM_OUT1 1 BR Square-wave signal generation 0.4 V … (VBat – 2 V); ±50 mA
2 PWM_OUT2 1 BS Square-wave signal generation 0.4 V … (VBat – 2 V); ±50 mA
3 PWM_OUT3 1 BT Square-wave signal generation 0.4 V … (VBat – 2 V); ±50 mA
4 PWM_OUT4 1 BU Square-wave signal generation 0.4 V … (VBat – 2 V); ±50 mA
5 PWM_OUT5 1 BX Square-wave signal generation 0.4 V … (VBat – 2 V); ±50 mA
6 PWM_OUT6 1 BW Square-wave signal generation 0.4 V … (VBat – 2 V); ±50 mA

Square-Wave Signal Generation ( DS2210 RTI Reference)
Square-Wave Signal Generation ( DS2210 RTLib Reference)
66
Serial Interface (DS2210)
Serial Interface (DS2210)
Characteristics The DS2210 contains a standard UART that can be configured as an RS232 or
RS422 interface. The interface is based on the Texas Instruments TL16C550C
asynchronous communication element.
For more information on the TL16C550C, refer to the Texas Instruments web site
at http://www.ti.com.
Modes In RS232 mode, the signals RXD and TXD are available. You can generate baud
rates up to 115 kbit/s. In RS422 mode, the signals RXD, /RXD, TXD and /TXD are
available. You can generate baud rates up to 1 Mbit/s.
Interrupt The serial interface allocates one hardware interrupt. A subinterrupt handler
allows you to specify different subinterrupts that support sending and receiving.
I/O mapping The following table shows the I/O mapping of the serial interface to the related
I/O pins of the ECU connector.
V WARNING
Do not rely on the numbers written on Sub‑D connectors. For the pin
numbering used, refer to DS2210 Components ( PHS Bus System
Signal ECU Pin Description Voltage Range/ Output

Connector Current
TXD 1 CA RS232/RS422 transmit RS232/RS422
/TXD 1 CB RS422 transmit RS422
RXD 1 CE RS232/RS422 receive RS232/RS422
/RXD 1 BV RS422 receive RS422
67
68
Angular Processing Unit
Introduction The following topics provide information on the angular processing unit, which is
designed to simulate engine processing core functions (crankshaft signal
generation, for example).
APU Basics ............................................................................................. 70

You can find basic information on how simulation of engine core
functions works. The most important terms when working with RTI and
RTLib are explained.
APU Reference ....................................................................................... 85

You can find the reference data required to implement the APU
functions. This includes restrictions and limitations as well as the I/O
mappings.
69
APU Basics
APU Overview ....................................................................................... 71

Presenting the functional units of the APU and their interconnections.
Engine Position Phase Accumulator ....................................................... 72

Explaining the unit that supplies the engine position.
Cascading I/O Boards ............................................................................. 73

To get the same time base on several I/O boards, for example, to simulate
an engine with more than eight cylinders.
Crankshaft Signal Generator .................................................................. 75

Explaining how the crankshaft signal is generated and what wave tables
are good for.
Camshaft Signal Generator .................................................................... 76

Explaining how the camshaft signals are generated and what wave tables
are good for.
Spark Event Capture Unit ....................................................................... 77

Explaining how ignition pulses are captured.
Injection Event Capture Unit .................................................................. 78

Explaining how injection pulses are captured and how the fuel amount is
evaluated.
Event Capture Windows ........................................................................ 81

Giving information on the definition of event capture windows.
Continuous Value Capturing .................................................................. 83

Explaining how you can determine ignition position, engine position and
duration values continuously.

Angular Processing Unit ( DS2210 RTI Reference)

The angular processing unit provides RTI blocks fo accessing the APU of a
DS2210.
Angular Processing Unit (APU) ( DS2210 RTLib Reference)

The angular processing unit provides RTLib functions for accessing the
APU of a DS2210.
70
APU Basics
APU Overview
Introduction The illustration shows the functional units of the angular processing unit, their
interconnections, their most important input parameters and I/O signals.
Engine position bus All APU components are interconnected by the engine position bus (engine
position bus). The engine position phase accumulator supplies the engine
position according to the Speed input parameter. Based on the engine position,
§ Crankshaft, camshaft, and knock signals can be generated, and
§ Capturing of spark events and injection signals can be triggered.
Using the engine position bus, you can connect the APU components of the
following I/O boards (the engine position bus is equal to the time-base bus of the
DS4002 and DS5001 boards):
§ DS2210
§ DS2211
§ DS4002 (starting with board revision DS4002-04)
§ DS5001 (starting with board revision DS5001-06)
§ DS5203
71
The boards are connected via the time-base connector. Refer to Board Overview
( PHS Bus System Hardware Reference).
PHS bus In single-processor and multiprocessor PHS-bus-based systems, the Peripheral

High Speed Bus (PHS bus) connects the I/O boards – a DS2210, for example – to
the processor board that executes the real-time application.
Angle position interrupt Depending on the engine position (angle), the angular processing unit can
generate angle position interrupts for up to 8 cylinders. You can use these lines
to request interrupts when the cylinder has passed the top dead center (TDC),
for example. Any interrupt position can be chosen while several interrupt
positions are possible for each cylinder.
Cascading DS2210 boards The angular processing unit is designed for simulating of engines with up to
eight cylinders. To simulate an engine with more than eight cylinders, several
DS2210 boards can be cascaded by connecting their engine position buses with
the time-base connector.
You have to set one of the DS2210 boards to master mode, the others to slave
mode. On DS2210 slave boards, the engine position phase accumulator is
disabled and the engine position is supplied by the DS2210 master board. All
other functions including initialization are not affected by the master/slave
setting and must be performed for each DS2210 board individually.
APU Reference ........................................................................................................................ 85
References
DS2210 HIL I/O Board ( PHS Bus System Hardware Reference)
Engine Position Phase Accumulator
Introduction The engine position phase accumulator converts the run‑time adjustable 16-bit
Speed input parameter to engine position information and supplies a 13-bit
position information to the engine position bus. Corresponding to one cycle of a
four-stroke engine, the engine cycle is 0 … 720° (4π). The resulting resolution is
0.088° or 0.0015 rad. The engine position is calculated every 1 μs, that is,
changes of engine speed take effect after 1 μs at the latest.
72
APU Basics
Speed
(AVR) (APR)
Phase
Accumu- Engine Position Bus
lator
+
The internal resolution for position accumulation is 27 bit. The angle velocity
register (AVR) provides a 16bit signed engine speed value. This value is extended
to 27 bit and added to the internal 27bit angle position register (APR) every 1 μs.
The most significant 13 bit are supplied to the engine position bus that provides
the information to the other components of the APU and to the time-base
connector.
The relation of engine speed given in revolutions per minute (RPM) and the AVR
value is defined as follows:
RPM = 60 · 2 / (1 µs · 227) · AVR
This results in a maximum velocity of ±29297 rpm (±3068 rad/s) with a speed
resolution of 0.9 rpm (0.094 rad/s).
The engine speed is converted into engine position values within the range of
0 … 719.91° (periodically). The values mirror the current position of the APU
which is related to the crankshaft position. These absolute position values can be
converted into position values related to the TDC or another specified reference
position. Refer to DS2210APU_ANG_REL_Bx ( DS2210 RTI Reference).
APU Reference ........................................................................................................................ 85
Cascading I/O Boards
Introduction You can cascade a DS2210 board with other I/O boards (DS2210, DS2211,
DS2302, DS4002, DS5001, DS5203). When I/O boards are cascaded their
angular processing units (APUs) or timing I/O units are given the same time base
for their RTI blocks or RTLib functions. This is necessary, for example, if you want
to simulate an engine with more than 8 cylinders, because one DS2210 supports
only 8 cylinders.
Functionality All I/O boards to be synchronized must be connected to a network via the time-
base connector. One of the I/O boards must be configured as the time-base
73
master. This board supplies the time base or engine position for all other
connected I/O boards. The I/O boards which read the time base must be
configured as time-base slaves.
Usable I/O boards You can connect the time-base bus (engine position bus) of the following I/O
boards (the engine position bus of the DS2210 and DS2211 boards is the same
as the time-base bus of the DS2302, DS4002, DS5001, and DS5203 boards):
§ DS2210
§ DS2211
§ DS2302 (as of board revision DS2302-04)
Note
The DS2302 board cannot be used as the bus master.
Limitation DS2211 boards can also be cascaded with DS2210 boards. Because the DS2210
has a slower APU cycle time, a DS2210 must be the time‑base master to avoid
overrun.
Hardware settings To set up the network, you have to connect the I/O boards physically. For this
purpose, these boards are equipped with a time-base connector. Use a standard
26-pin ribbon cable to set up the network. You can set up a network of two or
more I/O boards.
For the location of the time-base connector on an I/O board, refer to Board
Overview ( PHS Bus System Hardware Reference).
Software settings Using RTI, you configure the time-base master/slave settings via the
DS2210APU_CRANK_Bx block.
Using RTLib, you configure the time-base master/slave settings via the
ds2210_mode_set function.
You have to set one of the I/O boards to master mode, the others to slave mode.
On the time-base slave, the engine position phase accumulator is disabled, and
the engine position is supplied by the time-base master. All other functions,
including initialization, are not affected by the master/slave setting and must be
performed for each DS2210 board individually.
74
APU Basics
ds2210_mode_set ( DS2210 RTLib Reference)

DS2210APU_CRANK_Bx ( DS2210 RTI Reference)
Crankshaft Signal Generator
Introduction The crankshaft signal generator converts the engine position input to a
crankshaft signal with analog and digital outputs. Conversion is done by using a
wave table lookup mechanism. The analog output is fed through output
transformers. The level of the analog output can be adapted during run time to
your application using a Gain parameter. The digital output generates pulse
patterns that represent the sign of the analog waveform.
Gain
Digital
Crankshaft
Output
Lowpass
8K x 8-bit
Engine
Angular
Position DAC
Bus Wave Table
(select 1 of Analog
8 tables) Crankshaft
Output
For each 0.088° engine position, the angular wave table defines a signal level.
The resolution is 8-bit signed (–128 … +127). Due to the output transformers,
the wave table data must be without a mean value. Through it, the waveform is
defined. The illustration shows the analog crankshaft output of a typical
waveform that simulates a "60 teeth minus 2 missing teeth" crankshaft timing
wheel.
75
The crankshaft to be simulated is defined by the waveform allocated in the

angular wave table. Through it, the waveform is defined. For more details on
wave tables, refer to Generating Wave Tables on page 89.
For reference information, including the I/O mapping, refer to Crankshaft Sensor
Signal Generation on page 86.
APU Reference ........................................................................................................................ 85
Camshaft Signal Generator
Introduction The camshaft signal generator converts the engine position and camshaft phase
input to up to two camshaft signals with analog and digital outputs each.
Conversion is done by using a wave table lookup mechanism. The analog
outputs are fed through output transformers. The level of the analog output can
be adapted during run time to your application using a Gain parameter. The
digital outputs generate pulse patterns that represent the sign of the
corresponding analog waveforms.
Engine
Position
Bus Lowpass
+
8K x 8-bit
Adder Angular DAC
Cam- Wave Table
shaft (select 1 of Analog
Phases 8 tables) Camshaft
Output
Gain
Digital
Camshaft
Output
Lowpass
+
8K x 8-bit
Adder Angular DAC
Cam- Wave Table
shaft (select 1 of Analog
Phases 8 tables) Camshaft
Output
Gain
Digital
Camshaft
Output
For each engine position, the angular wave table defines a signal level. The signal
level resolution is 8-bit signed (–128 … +127). Due to the output transformers,
the wave table data must be without a mean value. Through it, the waveform is
defined. For more details on wave tables, refer to Generating Wave Tables
on page 89.
The phases between crankshaft signals and camshaft signals are defined by a 13-
bit offset for each camshaft signal (camshaft phases). The phase offsets can be
changed during run time.
76
APU Basics
For reference information, including the I/O mapping, refer to Camshaft Sensor
Signal Generation on page 87.
APU Reference ........................................................................................................................ 85
Spark Event Capture Unit
Introduction The spark event capture unit is designed for ignition position measurement with
definable event capture windows for up to 8 cylinders. Ignition pulses can be
captured from the input lines IGN1 … IGN6, AUXCAP1 and AUXCAP2. You can
choose between active high or active low pulses.
Continuous reading of the spark event data is available within each sample hit.
Up to 32 events per channel can be read continuously out of the capture FIFO.
In addition, the spark event capture unit provides two independent auxiliary
capture channels (AUXCAP1, AUXCAP2) that can be individually configured and
also used for various position measurements.
Note
§ If you do not use the channels for ignition capture, you can use them for
injection capture. This is available only for boards with extended
functionality. To check whether your board has extended functionality,
refer to DS2210 Board Revision on page 201.
§ The channels of the spark event capture unit can be read simultaneously
in the event capture mode and the continuos mode by using RTLib
functions. Refer to Continuous Value Capturing on page 83.
Event capture windows can be defined according to the 13-bit engine position
resolution (0.088°) provided by the engine position bus (refer also to Event
Capture Windows on page 81).
Capture modes Two capture modes are available.
Single event capture mode Within each event capture window, the
position of the leading edge of the first input pulse is evaluated. Further pulses
within the same event capture window are ignored.
77
Ignition
input
Event capture
window
Engine
Pulse Pulse Pulse Pulse position
ignored ignored captured ignored
Multiple event capture mode Within each event capture window, the
position values of all leading and trailing edges of up to 8 input pulses are
evaluated. You can specify the number of expected pulses to minimize execution
time.
Ignition
input
Event capture
window
Engine
Position Position Position Position Position Position position
ignored ignored captured captured captured ignored
For reference information, including the I/O mapping, refer to Spark Event
Capture on page 90.
APU Reference ........................................................................................................................ 85
Injection Event Capture Unit
Introduction The injection event capture unit is designed for injection position and fuel
amount measurements with definable event capture windows for up to 16
channels. You can choose between active high or active low pulses. For fuel
78
APU Basics
amount measurement (duration), two resolutions are available, 1 μs and 4 μs. Up

to 8 channels per group can be captured:
§ Group 1 uses the input lines INJ1 … INJ6 on P2 and PWM_IN7 and PWM_IN8
on connector P1.
§ Group 2 uses the input lines IGN1 … IGN6 on P2 and AUXCAP1 and
AUXCAP2 on connector P2.
Note
The following features are supported only for boards with extended
functionality:
§ The use of group 2 for injection capture
§ Channel 7 and channel 8 of group 1
§ 1 μs resolution for the duration mode
To check whether your board has extended functionality, refer to DS2210

Board Revision on page 201.
Note
§ If you use the input lines of group 2 for injection capture, ignition capture
is not possible.
§ The channels of the injection event capture unit can be read
simultaneously in the event capture mode and the continuos mode by
using RTLib functions. Refer to Continuous Value Capturing on page 83.
Event capture windows can be defined according to the 13-bit engine position
resolution (0.088°) provided by the engine position bus (refer also to Event
Capture Windows on page 81).
Capture modes Two capture modes are available.
Start position/fuel amount capture mode (duration mode) Within each

event capture window, the position values of up to 8 leading edges and the
durations of up to 8 input pulses are evaluated (the duration is proportional to
the fuel amount). Further pulses within the same event capture window are
ignored. You can specify the number of expected pulses to minimize execution
time.
79
Injection
input
Event capture
window
Engine
Pulse Position Position Position Position position
ignored ignored captured captured captured
If either the leading or the trailing edge of a pulse is not in the event capture
window, it is assumed that the pulse starts/ends at the corresponding border of
the event capture window.
If no leading and trailing edges of the pulse are captured (permanent injection)
the duration is assumed to be the duration of the whole event capture window.
If the event capture window covers the whole engine cycle (0 … 719.8242°) an
input pulse that overlaps the border of the event capture window is detected as
two separate pulses.
Start/end position capture mode (position mode) Within each event

capture window, the position values of up to 8 leading and trailing edges of up
to 8 input pulses are evaluated. You can specify the number of expected pulses
to minimize execution time.
Injection Duration Duration Duration

input captured captured captured
Event capture
window
Engine
Pulse Position Position Position Position position
ignored ignored captured captured captured
If either the leading or the trailing edge of a pulse is not in the event capture
window, the position value of the corresponding event capture window border is
counted as an edge.
If no leading and trailing edges of the pulse are captured (permanent injection)
the borders of the event capture window are counted as edges.
If the leading edge of a pulse is in one event capture window and the trailing
edge in the event window of the next engine cycle, two pulses will be captured.
For reference information including the I/O mapping, refer to Injection Pulse
Position and Fuel Amount Measurement on page 91.
80
APU Basics
APU Basics .............................................................................................................................. 70

APU Reference ........................................................................................................................ 85
Event Capture Windows
Introduction You can define event capture windows for spark event and injection event
capturing. These windows allow you to capture different signals or situations on
the cylinders of an engine. Only pulses that occur within the range of the event
capture window will be recognized. You can specify the number of expected
pulses to minimize the execution time.
Capture modes For a spark event capture, you can use the single event capture mode or the
multiple event capture mode (refer to Spark Event Capture Unit on page 77).
For an injection event capture, you can use the start position/fuel amount
capture mode (duration mode) or the start/end position capture mode (position
mode): refer to Injection Event Capture Unit on page 78.
Continuous value capture For spark event and injection event capture, you can continuously measure up to
32 events per channel via the capture FIFO buffer. Using this mode, the event
capture window can cover the whole engine cycle of 0 … 720° (refer to
Continuous Value Capturing on page 83).
Setting event capture You can use RTI (DS2210APU_IGN_Bx, DS2210APU_INJ_Bx_Gy,

windows DS2210APU_AUXCAP_Bx_Cy, DS2210APU_IGNCONT_Bx,
DS2210APU_INJCONT_Bx_Gy and DS2210APU_AUXCAP_Bx_Cy) or RTLib
(ds2210_event_window_set) functions to define event capture windows.
Restrictions For event capture windows the following restrictions apply:

§ An event window must not cover the whole engine cycle of 0 … 720°. The
maximum width of an event window is 719.824° (= 12.5631 rad).
§ The minimum width of an event window is 0.176° (= 0.003 rad).
§ If you specify the same value for the start and the end position no event
capture window will be set and an error message is issued when using RTI.
§ The minimum distance between two event windows is two engine position
steps (2 · 4π/8192).
81
Example Double spark ignition There are 2 ignition pulses per coil but only 1 signal
for the 2 cylinders. The cylinder is identified by its engine angle. With event
capture windows you can specify possible ignition pulse positions.
Ignition
pulses
Cylinder 1 Cylinder 2
Event capture Event capture

Pulses window for window for
captured cylinder 1 cylinder 2
Cylinder 1 Cylinder 2
Common rail injection For several injection pulses the start positions of the
pulses and the pulse durations can be captured. Additional charge pulses can be
ignored with the appropriate length of the event capture window.
Injection
pulses
Pre Main Post Charge
Pulses Event capture

captured window
No events
captured
Pre Main Post
82
APU Basics
Permanent injection For a permanent injection signal the width of the event
capture window will be captured.
Permanent Event capture

injection window
signal
Pulse
captured
Event Capture Windows ( DS2210 RTLib Reference)
Continuous Value Capturing
Introduction Several engine models need a continuous determination of ignition position,

engine position and duration values. For example, in common rail engines you
need the current rail pressure continuously. The values can be read out of the
capture FIFO. You can define capture windows for the whole engine cycle of
0 … 720°. Continuous capturing uses the same input lines as the corresponding
"normal" capturing.
Spark event capture In single event mode, up to 32 position values per channel of the leading edge
of the first input pulse within the capture window is read. In multiple event
capture mode, up to 32 position values per channel of trailing and leading edges
can be read.
83
Injection pulse position and In position mode, the position values of all trailing and leading edges of up to 32
duration events per channel can be read within one sample hit. In duration mode, the
position values of all leading edges and the duration of up to 32 events per
channel within one sample hit can be read (refer to Injection Event Capture Unit
on page 78).
Auxiliary event capture 2 channels are available to measure various positions. In single event mode, up
to 32 position values of the leading edge of the first input pulse are evaluated. In
multiple event mode, up to 32 position values of leading and trailing edges can
be captured. Auxiliary event capture is similar to the spark event capture (refer to
Spark Event Capture Unit on page 77).
Sample hit The sample hit is defined by the sample time of your model, for example, 1 ms.
Note
The channels of the spark event capture unit or the injection event capture
unit can be read simultaneously in the event window mode and the
continuos mode by using RTLib functions. Refer to Angular Processing Unit
(APU) ( DS2210 RTLib Reference).
Event Capture Windows ......................................................................................................... 81

Injection Event Capture Unit ................................................................................................... 78
Injection Pulse Position and Fuel Amount Measurement .......................................................... 91
Spark Event Capture ............................................................................................................... 90
Spark Event Capture Unit ........................................................................................................ 77
84
APU Reference
APU Reference
Introduction The following topics provide the reference information you need to implement
your real‑time model with engine simulation functions provided by the angular
processing unit.
Crankshaft Sensor Signal Generation ..................................................... 86

The crankshaft signal generator provides one analog crankshaft output
and one digital crankshaft output.
Camshaft Sensor Signal Generation ....................................................... 87

The camshaft signal generator provides two analog camshaft outputs
and two corresponding digital outputs. The digital outputs generate
pulse patterns that represent the sign of the corresponding analog
waveforms.
Wave Table Basics .................................................................................. 88

Using wave tables, you can define specific crankshaft waveforms to
simulate different signal types.
Generating Wave Tables ........................................................................ 89

Wave tables must be supplied as MAT files. In MATLAB, you can create
waveforms by using standard functions or you can import data measured
at a real engine.
Spark Event Capture .............................................................................. 90

The spark event capture unit provides 6 digital ignition inputs and 2
digital auxiliary capture inputs.
Injection Pulse Position and Fuel Amount Measurement ......................... 91

The injection event capture unit provides 16 digital injection inputs are
split into 2 groups for injection pulse position and fuel amount
measurement.
APU Basics ............................................................................................. 70

You can find basic information on how simulation of engine core
functions works. The most important terms when working with RTI and
RTLib are explained.

85
Crankshaft Sensor Signal Generation
Characteristics The crankshaft signal generator provides one analog crankshaft output and one
digital crankshaft output. Both the analog and the digital output carry out the
same crankshaft information. The digital output generates pulse patterns that
represent the sign of the analog waveform.
For basic information on how the crankshaft sensor signal generation works,
refer to Crankshaft Signal Generator on page 75.
Using wave tables, you can define specific crankshaft waveforms to simulate
different crankshaft types. The DS2210 can load 8 different wave tables for
crankshaft sensor signal generation. The waveform to be generated can be
switched during run time by using RTI or RTLib functions. For detailed
information on wave tables, refer to Wave Table Basics on page 88.
The digital output has a push-pull driver running from an external source (VBAT
within the range of 8 … 18 V). It is protected against overvoltage higher than
18 V. The maximum output current is ±50 mA. Short circuit proof to GND and
VBAT is implemented. The digital outputs are in their high impedance states after
reset. Using RTI, the output is enabled if the block is part of the model. Using
RTLib functions, you can enable or disable the output.
The analog output signal is fed through an output transformer with a maximum
physical signal level of 40 Vpp. Within this range, you can change the amplitude
of the whole waveform at run time. The analog output can be enabled or
disabled.
Note
Transformers do not transmit a DC voltage. In the frequency range below

500 Hz, the maximum output voltage is proportional to the frequency. The
nominal operating range of the transformers is 500 Hz … 20 kHz.
I/O mapping The following table shows the mapping of the crankshaft output (digital and
analog) to the related I/O pins of the ECU connector.
Channel Signal ECU Connector Pin Description Voltage Range/Output Current

Digital CRANK_DIG 1 BP Digital crankshaft output 0.4 V … (VBAT – 2 V); ±50 mA
Analog CRANK+ 1 CW Crankshaft waveform output (CRANK+ – CRANK–) = ±20 V
CRANK– 1 CX
86
APU Reference
Crankshaft Sensor Signal Generation ( DS2210 RTLib Reference)

Power Supply Outputs ( PHS Bus System Hardware Reference)
Transformer Outputs (APU and Slave DSP) ( PHS Bus System Hardware
Reference)
Camshaft Sensor Signal Generation
Characteristics The camshaft signal generator provides two analog camshaft outputs and two
corresponding digital outputs. The digital outputs generate pulse patterns that
represent the sign of the corresponding analog waveforms.
For basic information on how camshaft sensor signal generation works, refer to
Camshaft Signal Generator on page 76.
Using wave tables you can define specific camshaft waveforms to simulate
different camshaft types. The DS2210 is capable of loading eight different wave
tables for each camshaft output. The waveform to be generated can be switched
during run time. For detailed information on wave tables, refer to Wave Table
Basics on page 88.
The digital outputs have push-pull drivers running from an external source (VBAT
within the range of 8 … 18 V). They are protected against overvoltage higher
than 18 V. The maximum output current per channel is ±50 mA. Short circuit
proof to GND and VBAT is implemented. The outputs are in their high
impedance states after reset.
The analog output signals are fed through output transformers with a maximum
physical amplitude of 40 Vpp. Within this range, you can change the amplitude
of the whole waveform at run time. The analog outputs can be enabled or
disabled.
Note
Transformers do not transmit a DC voltage. In the frequency range below

500 Hz, the maximum output voltage is proportional to the frequency. The
nominal operating range of the transformers is 500 Hz … 20 kHz with full
output voltage.
87
I/O mapping The following table shows the mapping of the camshaft outputs (analog and
digital) to the related I/O pins of the ECU connector.
Channel ECU Connector Pin Signal Description Voltage Range/Output Current

1 (A) Digital 1 BY CAM1_DIG Digital camshaft output 0.4 V … (VBAT – 2 V); ±50 mA
Analog 1 DB CAM1+ Camshaft waveform output (CAM1+ – CAM1–) = ±20 V
1 CT CAM1–
2 (B) Digital 1 BZ CAM2_DIG Digital camshaft output 0.4 V … (VBAT – 2 V); ±50 mA
Analog 1 CZ CAM2+ Camshaft waveform output (CAM2+ – CAM2–) = ±20 V
1 DA CAM2–
Crankshaft Sensor Signal Generation ( DS2210 RTLib Reference)

Power Supply Outputs ( PHS Bus System Hardware Reference)
Reference)
Wave Table Basics
Wave table structure According to the 13-bit resolution of the engine position, each wave table
defines the signal waveform for 213 = 8192 consecutive engine positions within
the range of 0 … 720° (4π). The signal level resolution is 8-bit signed (–
128 … +127). Due to the output transformers, the mean value of the wave table
data must be zero. The assignment of signal levels to engine positions results in a
waveform.
Look-up mechanism Wave tables are downloaded to the processor board together with the real-time
application. The real-time processor transfers the wave tables to the DS2210
where they are stored in the memories of the Crankshaft Signal Generator and
Camshaft Signal Generator.
88
APU Reference
At run time, the wave table look-up mechanism outputs the signal value, which
is defined for the current engine position (every 1 μs).
APU Basics .............................................................................................................................. 70

Camshaft Signal Generator ..................................................................................................... 76
Crankshaft Signal Generator ................................................................................................... 75
Generating Wave Tables ......................................................................................................... 89
Generating Wave Tables
Introduction Wave tables must be supplied as MAT files. Other formats are not supported. In
MATLAB, you can create waveforms by using standard functions or you can
import data measured at a real engine.
You find example wave tables in the

<RCP_HIL_InstallationPath>\Demos\DS100x\IOBoards\Ds2210\APU\Wav
etables folder of your dSPACE installation.
Using MATLAB In the folder <RCP_HIL_InstallationPath>matlab\rtlib100x\tools of

your dSPACE installation, you also find the M-file Mat2asm2210.m. It collects the
specified wave table MAT files into a common MAT file, and converts it to an
assembly source file. For each board, up to 24 wave tables can be loaded (8 for
each signal generation). Use the RTLib functions ds2210_crank_table_load or
ds2210_cam_table_load to load wave tables to the real-time hardware.
Using RTI The Simulink RTI blocks for crankshaft sensor signal generation and camshaft
sensor signal generation allow you to select up to eight wave table MAT files for
each output channel. RTI generates a common MAT file and converts it to an
assembly source file that is downloaded to the real-time hardware together with
your real-time application.
DS2210APU_CAM_Bx_Cy ( DS2210 RTI Reference)

89
Spark Event Capture
Characteristics The spark event capture unit provides

§ 6 digital ignition inputs (IGN1 … IGN6) for ignition position measurement
§ 2 digital auxiliary capture inputs (AUXCAP1, AUXCAP2) for various position
measurements
For detailed information on capture modes and event capture windows, refer to
Spark Event Capture Unit on page 77 and Event Capture Windows on page 81.
You can choose between active high and active low pulses.
To minimize execution time you have to specify the number of expected pulses
for each event capture window. Up to 8 pulses are allowed.
You can read up to 32 events out of the capture FIFO continuously within one
sample hit. You can use the whole event capture window within the range of
0 … 720°.
The inputs are 12 V compatible. They are protected against overvoltage higher
than 18 V. After software initialization, the input threshold is set to 2.5 V. Using
RTI/RTLib functions, you can set the input threshold within the range of 1 … 7 V.
Note
RTLib functions and the DS2210APU_AUXCAP_Bx_Cy and

DS2210APU_AUXCAPCONT_Bx_Cy blocks refer to the absolute engine
position.
The DS2210APU_IGN_Bx and DS2210APU_IGNCONT_Bx blocks relate to

the top dead center (TDC).
I/O mapping The following table shows the mapping of the cylinder/channel numbers to the
of the DS2210 conflict with each other. For details, see Conflicting I/O Features
on page 201.
RTI Cylinder/ Channel RTLib Channel Signal ECU Connector Pin Description Voltage Range
1 1 IGN1 2 BW Ignition capture 12 V compatible
2 2 IGN2 2 BX Ignition capture 12 V compatible
3 3 IGN3 2 BY Ignition capture 12 V compatible
4 4 IGN4 2 BZ Ignition capture 12 V compatible
5 5 IGN5 2 CA Ignition capture 12 V compatible
90
APU Reference
RTI Cylinder/ Channel RTLib Channel Signal ECU Connector Pin Description Voltage Range
6 6 IGN6 2 CB Ignition capture 12 V compatible
1 7 AUXCAP1 2 CC Auxiliary capture 12 V compatible
2 8 AUXCAP2 2 CD Auxiliary capture 12 V compatible
References

DS2210APU_AUXCAP_Bx_Cy ( DS2210 RTI Reference)
DS2210APU_AUXCAPCONT_Bx_Cy ( DS2210 RTI Reference)
DS2210APU_CAM_Bx_Cy ( DS2210 RTI Reference)
DS2210APU_IGN_Bx ( DS2210 RTI Reference)
DS2210APU_IGNCONT_Bx ( DS2210 RTI Reference)
Spark Event Capture ( DS2210 RTLib Reference)
Injection Pulse Position and Fuel Amount Measurement
Introduction The injection event capture unit provides 16 digital injection inputs are split into
2 groups for injection pulse position and fuel amount measurement. For detailed
information on event capture windows and capture modes, refer to Event
Capture Windows on page 81 and Injection Event Capture Unit on page 78.
You can choose between active high and active low pulses.
To minimize execution time you have to specify the number of expected pulses
for each event capture window. Up to 8 pulses are allowed.
You can read up to 32 events out of the capture FIFO continuously within one
sample hit. You can use the whole event capture window within the range of
0 … 720°.
91
Note
The following features are supported only for boards with extended
functionality:
§ The use of group 2 for injection capture
§ Channel 7 and channel 8 of group 1
§ 1 μs resolution for the duration mode
To check which revision your board is, refer to DS2210 Board Revision
on page 201.
The digital inputs are 12 V compatible (operational up to 18 V). After software

initialization, the input threshold is set to 2.5 V. Using RTI/RTLib functions, you
can set the input threshold within the range of 1 … 7 V.
Note
RTLib functions refer to the absolute engine position. The

DS2210APU_INJ_Bx_Gy and DS2210APU_INJCONT_Bx_Gy blocks relate
to the top dead center (TDC).
I/O mapping The following table shows the mapping of the cylinder/channel numbers to the
of the DS2210 conflict with each other. Refer to Conflicting I/O Features
on page 201.
The following table shows the I/O pins for group 1:
RTI Cylinder/ RTLib Channel ECU Connector Pin Signal Description Voltage Range
Channel
1 1 2 BP INJ1 Injection capture 12 V compatible
2 2 2 BR INJ2 Injection capture 12 V compatible
3 3 2 BS INJ3 Injection capture 12 V compatible
4 4 2 BT INJ4 Injection capture 12 V compatible
5 5 2 BU INJ5 Injection capture 12 V compatible
6 6 2 BV INJ6 Injection capture 12 V compatible
7 7 2 BM INJ7 (PWM_IN7) Injection capture 12 V compatible
8 8 2 BN INJ8 (PWM_IN8) Injection capture 12 V compatible
The following table shows the I/O pins for group 2:
RTI Cylinder/ Channel RTLib Channel ECU Connector Pin Signal Description Voltage Range
1 1 2 BP INJ1 Injection capture 12 V compatible
2 2 2 BR INJ2 Injection capture 12 V compatible
3 3 2 BS INJ3 Injection capture 12 V compatible
4 4 2 BT INJ4 Injection capture 12 V compatible
5 5 2 BU INJ5 Injection capture 12 V compatible
92
APU Reference
RTI Cylinder/ Channel RTLib Channel ECU Connector Pin Signal Description Voltage Range
6 6 2 BV INJ6 Injection capture 12 V compatible
7 7 2 CC AUXCAP1 Auxiliary capture 12 V compatible
8 8 2 CD AUXCAP2 Auxiliary capture 12 V compatible
References

DS2210APU_INJ_Bx_Gy ( DS2210 RTI Reference)
Injection Pulse Position and Fuel Amount Measurement ( DS2210 RTLib
Reference)
93
94
Features Served by the Slave DSP
Introduction The following topics provide information on the features served by the slave DSP
of the DS2210.
Slave DSP TMS320C31 Basics ................................................................ 95

Providing general information on the slave DSP.
Knock Sensor Simulation ....................................................................... 96

Providing information on the ready-to-use application (knock processor)
implemented on the slave DSP. This application is regarded as part of the
angular processing unit.
Wheel Speed Sensor Simulation ............................................................. 99

Providing information on the ready-to-use application implemented on
the slave DSP. This application is regarded as part of the sensor and
actuator interface.
Slave DSP TMS320C31 Basics
Characteristics The slave DSP is used to generate knock sensor signals on 4 analog outputs or
wheel speed sensor signals on 4 analog outputs. Both functions are performed
by ready-to-use applications that are controlled by slave DSP access functions
running on the master processor board.
Output circuits The resolution of the four analog outputs is 12 bit. For information on the I/O
circuits, refer to Digital Outputs ( PHS Bus System Hardware Reference).
95
User applications As an alternative, you can program your own applications to generate user-
defined signals. The available functions and macros for slave DSP programming
are explained in the DS2210 RTLib Reference.
Download slave applications The slave DSP applications are downloaded to the master processor board
together with the master application, and then transferred to the DS2210 slave
DSP’s memory.
Engine position bus The slave DSP is connected to the engine position bus of the angular processing
unit and receives an interrupt when the engine position has been updated (every
1 μs). The master processor board can interrupt the slave DSP by writing to a
predefined location of the slave DSP’s dual-port memory (DPMEM).
Emulation/debug port The emulation/debug port connector P6 can be used for slave DSP debugging.
This requires additional software and hardware.
Serial interface In addition to the analog outputs, the slave DSP provides a serial interface
(DS2210 connector P5) that can be used for connecting a DDS board (DS2302).
For the location of the connector, refer to Serial Interface ( PHS Bus System
TMS320C31 For detailed information on the TMS320C31, refer to the Texas Instruments web
site at http://www.ti.com and search for TMS320C31.
DS2210APU_INT_Bx_Iy ( DS2210 RTI Reference)

DS2210SL_KNSG_Bx_Cy ( DS2210 RTI Reference)
DS2210SL_WSSG_Bx_Cy ( DS2210 RTI Reference)
Interrupts ( DS2210 RTLib Reference)
Slave DSP Access Functions ( DS2210 RTLib Reference)
Slave DSP Functions and Macros ( DS2210 RTLib Reference)
Knock Sensor Simulation
Introduction Knock sensor simulation is performed by a ready-to-use application implemented

on the slave DSP. The slave DSP provides 4 analog outputs to simulate 4
independent knock sensors.
96
Knock Sensor Simulation
Knock sensor simulation is triggered by the engine position, which is supplied by

the engine position bus (see APU Overview on page 71). Like a knock sensor in a
real engine measures several cylinders, multiple knock signals can be generated
for up to 8 cylinders in one engine cycle (0° … 720°). Knock sensor signals are
generated as cosine wave signals plus Gaussian noise. All parameters can be
changed at run time by using RTI or RTLib functions.
Note
You cannot use wheel speed sensor simulation and knock sensor simulation
at the same time.
Knock signal calculation The parameters are passed to the slave DSP for knock sensor simulation and the
knock signal u(t) is generated according to the formula
u(t) = a · e–d 2π f t · cos(2π f t) + Noise

Where
a is the amplitude
e–d·2π·f·t is the envelope
d is the damping
f is the frequency
t is the time
Knock signal parameters For the knock signals to be generated you have to specify the following
parameters for each cylinder:
Start angle Specifies the start position of the cosine signal in degrees. For RTI
blocks the angle relates to the top dead center (TDC), for RTLib functions the
angle relates to the absolute engine position.
Knock length Specifies the end of signal generation. The signal generation
ends after this length (given in degrees).
Amplitude Specifies the amplitude a of the cosine signal in Vpp.
Frequency Specifies the frequency f of the cosine signal in Hz.
Damping Specifies the damping factor of the cosine signal.
Knock number Specifies the maximum number of knock signals which are
generated for each cylinder while the application is running. When the limit is
reached, no further pulses are generated. To specify an infinity number of knock
signals, set Knock number = 0 and Knock rate = 1.
Knock rate Specifies after how many engine cycles the knock signal
generation will start again for the given cylinder.
Noise Specifies the amplitude of the noise in Vpp. The additional noise signal
can be selected independently for knock sensor 1 and 2.
97
The following illustration shows the most important parameters of a knock signal
with the optional Gaussian noise.
Outputs The output signals are fed through output transformers with a maximum
physical amplitude of 40 Vpp. The outputs can be enabled or disabled.
I/O pins of the ECU connector, as used in RTI and RTLib. The I/O features of the
DS2210 conflict with each other. Refer to Conflicting I/O Features ( DS2210
Features).
Channel ECU Pin Signal Description Voltage Range/Output Current

Number Connector
1 1 CK C31‑Waveform 0+ Knock sensor or wheel speed (C31‑Waveform 0+ –
1 CL C31‑Waveform 0– sensor signal C31‑Waveform 0–) = ±20 V
2 1 CN C31‑Waveform 1+ Knock sensor or wheel speed (C31‑Waveform 1+ –

1 CP C31‑Waveform 1– sensor signal C31‑Waveform 1–) = ±20 V
3 1 CU C31‑Waveform 2+ Knock sensor or wheel speed (C31‑Waveform 2+ –

1 CV C31‑Waveform 2– sensor signal C31‑Waveform 2–) = ±20 V
4 1 CR C31‑Waveform 3+ Knock sensor or wheel speed (C31‑Waveform 3+ –

1 CS C31‑Waveform 3– sensor signal C31‑Waveform 3–) = ±20 V
98
Wheel Speed Sensor Simulation
DS2210SL_KNSG_Bx_Cy ( DS2210 RTI Reference)

Reference)
Wheel Speed Sensor Simulation
Characteristics Wheel speed sensor simulation is performed by a ready-to-use application

implemented on the slave DSP. You can use the 4 analog slave DSP outputs to
generate up to 4 independent wheel speed sensor signals at the same time, one
for each of the four wheels.
Wheel speed sensor signals are generated as sine wave signals plus an optional
Gaussian noise. You can specify wheel speed, periods per revolution, sine
amplitude, and noise amplitude.
Note
You cannot use wheel speed sensor simulation and Knock Sensor
Simulation at the same time.
Wheel speed signal The parameters are passed to the slave DSP for wheel speed simulation and the
calculation wheel speed signal u(t) is generated according to the formula
Where
a is the amplitude
fWheel is the wheel speed signal frequency which is calculated as follows:
fWheel = speed · teeth · (1[min]/60[s])
t is the time
99
Outputs The output signals are fed through output transformers with a maximum
physical amplitude of 40 Vpp. The outputs can be enabled or disabled.
Note
§ Transformers do not transmit a DC voltage.

§ In the frequency range below 500 Hz, the maximum output voltage is
proportional to the frequency.
§ The nominal operating range of the transformers is 500 Hz … 20 kHz.
I/O pins of the ECU connector, as used in RTI and RTLib. The I/O features of the
DS2210 conflict with each other. Refer to Conflicting I/O Features ( DS2210
Features).
Channel ECU Pin Signal Description Voltage Range/Output Current

Number Connector
1 1 CK C31‑Waveform 0+ Knock sensor or wheel speed (C31‑Waveform 0+ –
1 CL C31‑Waveform 0– sensor signal C31‑Waveform 0–) = ±20 V
2 1 CN C31‑Waveform 1+ Knock sensor or wheel speed (C31‑Waveform 1+ –

1 CP C31‑Waveform 1– sensor signal C31‑Waveform 1–) = ±20 V
3 1 CU C31‑Waveform 2+ Knock sensor or wheel speed (C31‑Waveform 2+ –

1 CV C31‑Waveform 2– sensor signal C31‑Waveform 2–) = ±20 V
4 1 CR C31‑Waveform 3+ Knock sensor or wheel speed (C31‑Waveform 3+ –

1 CS C31‑Waveform 3– sensor signal C31‑Waveform 3–) = ±20 V
DS2210SL_WSSG_Bx_Cy ( DS2210 RTI Reference)

Slave DSP Access Functions ( DS2210 RTLib Reference)
100
CAN Support
CAN Support
Introduction The following topics provide all the information required for working with
dSPACE CAN boards.
Setting Up a CAN Controller ................................................................ 102

Explains how to set up a CAN controller to use a dSPACE board with
CAN bus interface.
Using the RTI CAN MultiMessage Blockset ........................................... 116

Provides information on using the RTI CAN MultiMessage Blockset.
Limited Number of CAN Messages ...................................................... 210

When you implement CAN communication with RTI CAN Blockset or
with RTLib's CAN access functions, the number of CAN messages in an
application is limited.
101
CAN Support
Setting Up a CAN Controller

Introduction To use a dSPACE board with CAN bus interface, you have to set up the CAN
controller.
Initializing the CAN Controller ............................................................. 103

The CAN controller performs serial communication according to the CAN
protocol. You must configure the CAN controller according to the
application.
CAN Transceiver Types ......................................................................... 104

The way in which CAN messages are transmitted on a CAN bus depends
on the CAN transceiver used.
DS2211: Selecting the CAN Controller Frequency ................................ 108

The board’s CAN controller supports the several maximum clock
frequency.
Defining CAN Messages ...................................................................... 109

The dSPACE CAN software lets you easily define CAN messages to be
transmitted or received.
Implementing a CAN Interrupt ............................................................. 110

The CAN controller is responsible for generating interrupts to the master
processor. You can specify the events on which these interrupts are
generated.
Using RX Service Support ..................................................................... 110

RTI CAN Blockset provides two concepts for receiving CAN messages.
Removing a CAN Controller (Go Bus Off) ............................................. 112

You can remove the CAN controller that is being used from the bus
when you use several CAN controllers.
Getting CAN Status Information .......................................................... 113

You can use the Error Management Logic (EML) of a CAN controller to
get error and status information on the CAN bus and the controller.
I/O Mapping of the CAN Bus Interfaces ............................................... 114

The CAN subsystem of the DS2210 provides two independent CAN bus
interfaces that meet the ISO/DIS 11898 specifications.
102
Initializing the CAN Controller
Introduction The CAN controller performs serial communication according to the CAN
protocol. You can take control of or communicate with other members of a CAN
bus via the controller. This means you must configure the CAN controller —
called the CAN channel — according to the application.
Standard configuration You must specify the baud rate for the CAN application and the sample mode:
Sample Mode Description

1‑sample mode (supported by all dSPACE CAN boards)
The controller samples a bit once to determine if it is
dominant or recessive.
3‑sample mode (supported by the DS4302 only)
The controller samples a bit three times and uses the majority
to determine if it is dominant or recessive.
The required bit timing parameters are automatically calculated by the dSPACE
CAN software.
Advanced configuration (bit The bits of a CAN message are transmitted in consecutive bit times. According to
timing parameters) the CAN specification, a bit time consists of two programmable time segments
and a synchronization segment:
TSeg1 Timing segment 1. The time before the sample point.
TSeg2 Timing segment 2. The time after the sample point.
SyncSeg Used to synchronize the various bus members (nodes).
1 bit time
Sync-
Seg TSeg1 TSeg2
1 time quantum Sample point
The following parameters are also part of the advanced configuration:
SP Sample point. Defines the point in time at which the bus voltage level
(CAN-H, CAN-L) is read and interpreted as a bit value.
SJW Synchronization jump width. Defines how far the CAN controller can
shift the location of the sample point to synchronize itself to the other bus
members.
BRP Baud rate prescaler value. The BRP defines the length of one time
quantum.
103
CAN Support
SMPL Sample mode. Either 1-sample or 3‑sample mode. Applicable to the

DS4302 only.
Except for the SyncSeg parameter, you must define all these parameters via the
values of the bit timing registers (BTR0, BTR1), located on the CAN controller.
Note
Setting up bit timing parameters requires advanced knowledge of the CAN

controller hardware and the CAN bus hardware.
RTI support You initialize a CAN controller with the RTICAN CONTROLLER SETUP block.
Refer to RTICAN CONTROLLER SETUP ( RTI CAN Blockset Reference).
RTICAN CONTROLLER SETUP ( RTI CAN Blockset Reference)
CAN Transceiver Types
Introduction To communicate with other bus members in a CAN bus, each bus member is
equipped with a CAN transceiver. The transceiver defines the type of wire used
for the bus (coaxial, two-wire line, or fiber-optic cables), the voltage level, and
the pulse forms used for 0‑bit and 1‑bit values. The way in which CAN messages
are transmitted on a CAN bus therefore significantly depends on the CAN
transceiver used.
Note
Make sure that the CAN transceiver type used on the CAN bus matches the
type on the dSPACE board you use to connect to the bus.
Terminating the CAN bus Depending on the CAN transceiver type, you must terminate each CAN bus with
resistors at both ends of the bus.
Note
Failure to terminate the bus will cause bit errors due to reflections. These
reflections can be detected with an oscilloscope.
104
Where to go from here Information in this topic
Supported transceivers .......................................................................................................... 105

ISO11898 transceiver ............................................................................................................ 105
ISO11898‑6 transceiver ......................................................................................................... 106
RS485 transceiver ................................................................................................................. 107
C252 fault-tolerant transceiver ............................................................................................. 107
Custom transceivers .............................................................................................................. 107
Supported transceivers The following table lists dSPACE hardware and the supported transceivers:
dSPACE Hardware Transceiver Type

§ DS1103 ISO11898
§ DS2202
§ DS2210
§ DS2211
DS4302 The following transceiver types are supported:
§ ISO11898
§ RS485
§ C252
§ Piggyback1)
Note
The RTI CAN Blockset does not support transceiver

types with different modes, for example single-wire
and two-wire operation. Nevertheless, such
transceiver types can be applied to the DS4302, but
additional user-written S-functions are required to
implement the communication between the
piggyback module and the CAN controller.
MicroAutoBox The following transceiver types are supported:

§ ISO11898
§ ISO11898‑62), 3)
MicroLabBox The following transceiver types are supported:
§ ISO11898
§ ISO11898‑62)
1) If none of the above transceivers matches your application or if a TJA1041 transceiver
is used, “piggyback” must be selected as the transceiver type.
2) Selecting the ISO11898‑6 transceiver type is required to perform partial networking.
3) Supported only by MicroAutoBox with DS1513 I/O board
ISO11898 transceiver ISO11898 defines a high-speed CAN bus that supports baud rates of up to
1 MBd. This is the most commonly used transceiver, especially for the engine
management electronics in automobiles.
105
CAN Support
CAN‑H, CAN‑L ISO11898 defines two voltage levels:
Level Description
CAN-H High if the bit is dominant (3.5 V), floating (2.5 V) if the
bit is recessive.
CAN-L Low if the bit is dominant (1.0 V), floating (2.5 V) if the
bit is recessive.
Termination To terminate the CAN bus lines, ISO11898 requires a 120‑Ω

resistor at both ends of the bus.
ISO11898‑6 transceiver High-speed transceiver that supports partial networking.
Termination To terminate the CAN bus lines, ISO11898‑6 requires a 120‑Ω

resistor at both ends of the bus.
Note
There are some limitations when you use the optional ISO11898‑6
transceiver:
§ No wake-up interrupt is implemented.
§ Partial networking is supported only for the following baud rates:
§ 125 kbit/s
§ 250 kbit/s
§ 500 kbit/s
§ 1000 kbit/s
Other baud rates can be used for normal CAN operation, but detecting
wake-up messages for partial networking is supported only for the baud
rates listed above.
§ You have to enable Automatic Wake Up on the Parameters Page
(RTI<xxxx>_ISO11898_6_SST) before you build the model. You cannot
enable automatic wake‑up during run time.
§ If the transceiver is in power on / listen only mode, the CAN controller
does not send an acknowledge message to the transmitter. The
transmitter therefore continues to send the message until it receives the
acknowledge signal. This might result in a task overrun if an RX interrupt
is configured for the CAN controller.
§ If the transceiver is in power on / listen only mode, it is not able to send
CAN messages. Automatic wake‑up is not possible if the transceiver is in
power on / listen only mode. Because no message is sent on the CAN bus
by the transceiver in power on / listen only mode, CAN arbitration fails.
The CAN controller changes to the BUS OFF state. It is not possible to set
the BUS state automatically to BUS ON via an interrupt, because the
reason for the BUS OFF state still remains. You must set the CAN
controller to BUS ON after you have switched the transceiver state to
normal, standby, or sleep mode.
106
RS485 transceiver The RS485 transceiver supports baud rates of up to 500 kBd. It is often used in
the automotive industry. A CAN bus using this transceiver can connect up to 25
CAN nodes.
Termination To terminate the CAN bus lines, a 120-Ω resistor must be used
at both ends of the CAN bus.
C252 fault-tolerant The C252 fault-tolerant transceiver supports baud rates of up to 125 kBd. Its
transceiver main feature is on-chip error management, which allows the CAN bus to
continue operating even if errors such as short circuits between the bus lines
occur.
When this transceiver is used, the CAN bus can interconnect nodes that are
widely distributed. You can switch the C252 transceiver between sleep and
normal (awake) mode.
Termination There are two ways to terminate the CAN bus lines: Use a 10
kΩ resistor for many connected bus members, or a 1.6 kΩ resistor if the number
of bus members is equal to or less than five. The termination resistors are located
between CAN‑L and RTL and CAN‑H and RTH (refer also to the "PCA82C252
Fault-tolerant Transceiver Data Sheet" issued by Philips Semiconductors).
Note
The TJA1054 transceiver is pin and downward compatible with the C252
transceiver. If the TJA1054 transceiver is on board the DS4302 and you
want to use the fault‑tolerant transceiver functionality, select “C252” in the
RTI CAN CONTROLLER SETUP block. Refer to Unit Page (RTICAN
CONTROLLER SETUP) ( RTI CAN Blockset Reference).
Custom transceivers The DS4302 allows you to mount up to four customization modules to use
transceivers that are not on the DS4302.
Connecting customization modules For instructions on connecting

customization modules, refer to Customization Modules ( PHS Bus System
Optional TJA1041 transceiver dSPACE provides the optional TJA1041 that

you can use as a custom transceiver for the DS4302. For a detailed description of
the transceiver and the available transceiver modes, refer to the data sheet of the
TJA1041 transceiver.
107
CAN Support
For details on the RTI support for the TJA1041 transceiver, refer to TJA1041
Support Blocks ( RTI CAN Blockset Reference).
Note
There are some limitations when you use the optional TJA1041 transceiver:
§ No wake-up interrupt is implemented.
§ You have to enable Automatic Wake Up in the DS4302_TJA1041_SST
( RTI CAN Blockset Reference) block before you build the model. You
cannot enable automatic wake‑up during run time.
§ If the transceiver is in power on / listen only mode, the CAN controller
does not send an acknowledge message to the transmitter. The
transmitter therefore continues to send the message until it receives the
acknowledge signal. This might cause a task overrun if an RX interrupt is
configured for the CAN controller.
§ If the transceiver is in power on / listen only mode, it is not able to send
CAN messages. Automatic wake‑up is not possible if the transceiver is in
power on / listen only mode. Because no message is sent on the CAN bus
by the transceiver in power on / listen only mode, CAN arbitration fails.
The CAN controller changes to the BUS OFF state. It is not possible to set
the BUS state automatically to BUS ON via an interrupt, because the
reason for the BUS OFF state still remains. You must set the CAN
controller to BUS ON after you have switched the transceiver state to
normal, standby, or sleep mode.
DS2211: Selecting the CAN Controller Frequency
Introduction Depending on the version of your DS2211, the board’s CAN controller supports
the following maximum clock frequency:
Board Version Frequency

Up to 4.10 24 MHz
4.10 and higher 36 MHz
To get the board version of your DS2211, open the board’s Properties dialog in
the dSPACE experiment software.
Highest possible frequency The real‑time application built with RTI CAN Blockset is compatible with both
automatically selected board versions and frequencies: During board initialization, the highest frequency
that is available for the controller is automatically selected, together with the
corresponding bit timing values. This applies regardless of the frequency you
select in the Advanced Configuration dialog. Refer to Advanced Configuration
Dialog (RTICAN CONTROLLER SETUP) ( RTI CAN Blockset Reference).
108
Defining CAN Messages
Introduction The dSPACE CAN software lets you easily define CAN messages to be
transmitted or received.
Message types You can define a message as a TX, RX, RQ, or RM message:
Message Type Description

Transmit (TX) This message is transmitted with a specific identifier. A TX message contains up to 8 bytes of data.
Receive (RX) This message is not transmitted over the bus. An RX message is used only to define how the CAN
controller processes a received message. An RX message transfers the incoming data from the CAN
controller to the master processor.
Request (RQ) First part of a remote transmission request1). An RQ message is transmitted with a specific identifier
to request data. An RQ message does not contain data.
Remote (RM) Second part of a remote transmission request1). An RM message is a TX message that is sent only if
the CAN controller has received a corresponding RQ message. The RM message contains the data
requested by the RQ message.
1) With RTI CAN Blockset, the remote transmission request is divided into an RQ message and an RM message. The meanings of
the words “remote” and “request” used in this document do not correspond to those used in CAN specifications.
Message configuration With RTI CAN Blockset, you have to implement one message block for each
message. To define a message to be transmitted, for example, you must
implement an RTICAN Transmit (TX) block.
Message configuration by hand You can perform message configuration

by hand. In this case, you must specify the message identifier and identifier
format (STD, XTD), the length of the data field, and the signals for each
message. You also have to specify the start bit and length of each signal.
Message configuration from data file (data file support) You can load a
data file containing the configuration of one or more messages. Then you can
assign a message defined in the data file to a message block. Refer to
Configuring CAN Messages via Data Files ( RTI CAN Blockset Reference).
Multiple message access Multiple message access allows you to place several RX or TX blocks with the
same identifier and identifier format in one model. You can decode the signals of
an RX message in several ways, or place TX blocks in several enabled subsystems
to send data in various ways.
Delay time for message To distribute messages over time and avoid message bursts, you can specify delay
transmission times. A message is sent after the delay time. The delay time is a multiple of the
time needed to send a CAN message at a given baud rate and identifier format.
You can only enter a factor to increase or decrease the delay time.
109
CAN Support
RTI support With RTI CAN Blockset, you have to implement one message block for each
message. Refer to:
Message Type RTI Block

Transmit (TX) RTICAN Transmit (TX) ( RTI CAN Blockset Reference)
Receive (RX) RTICAN Receive (RX) ( RTI CAN Blockset Reference)
Request (RQ) RTICAN Request (RQ) ( RTI CAN Blockset Reference)
Remote (RM) RTICAN Remote (RM) ( RTI CAN Blockset Reference)
Configuring CAN Messages via Data Files ( RTI CAN Blockset Reference)
Implementing a CAN Interrupt
Introduction The CAN controller transmits and receives messages and handles error
management. It is also responsible for generating interrupts to the master
processor. You can specify the events on which these interrupts are generated.
A special Bus Failure interrupt and a wake-up interrupt are available for the
DS4302.
RTI support You can implement a CAN interrupt with the RTICAN Interrupt block. Refer to
RTICAN Interrupt ( RTI CAN Blockset Reference).
RTICAN Interrupt ( RTI CAN Blockset Reference)
Using RX Service Support
Concepts for receiving CAN When CAN messages are received, RX blocks access the DPMEM between the
messages master processor and the slave processor.
110
RTI CAN Blockset provides two concepts for receiving CAN messages:
§ Common receive concept
§ RX service receive concept
Common receive concept According to the common receive concept, one data object is created in the
DPMEM for each received CAN message. Due to the limited DPMEM size, the
number of RX blocks you can use in a model is limited to 100 (200 for the
DS4302).
RX service receive concept When you enable RX service support, one data object is created in the DPMEM
for all received CAN messages, and memory on the master processor is used to
receive CAN messages. The RX service fills this memory with new CAN data. This
concept improves run‑time performance.
Tip
In contrast to the common receive concept, the number of RX blocks for

which RX service support is enabled is unlimited.
Specifying a message filter When you use RX service, you have to specify a
filter to select the messages to receive via RX service. To define the filter, you
have to set up a bitmap that represents the message. Each bit position can be
assigned 0 (must be matched), 1 (must be matched), or X (don't care). A
message is received via RX service only if it matches the bitmap.
You can define the message filter on the RX Service Page (RTICAN
Specifying the queue size When you use RX service, you have to specify the
maximum number of CAN messages that you expect to receive in a sample step.
The memory allocated on the master processor used to queue CAN messages is
calculated from the specified maximum number of CAN messages.
Note
If more CAN messages than the specified Queue size are received in a
sample step, the oldest CAN messages are lost. You should therefore specify
the queue size so that no CAN messages are lost.
Example:
A CAN controller is configured to use the baud rate 500 kBd. The slowest
RX block assigned to this CAN controller is sampled every 10 ms. At the
specified baud rate, a maximum of about 46 CAN messages (STD format)
might be received during two consecutive sample steps. To ensure that no
CAN message is lost, set the queue size to 46.
111
CAN Support
Triggering an interrupt when a message is received via RX service You

can let an interrupt be triggered when a message is received via RX service.
Note
You cannot let an interrupt be triggered when a message with a specific ID

is received. An interrupt is triggered each time a message is received via
RX service.
You can define the interrupt on the Unit Page (RTI CAN Interrupt) ( RTI
CAN Blockset Reference).
Precondition for gatewaying messages Enabling the RX service is a

precondition for gatewaying messages between CAN controllers.
Refer to Gatewaying Messages Between CAN Buses ( RTI CAN Blockset
Reference).
Precondition for the TX loop back feature RX service allows you to use
the TX loop back feature. The feature lets you observe whether message transfer
over the bus was successful.
You can enable TX loop back on the Options Page (RTICAN Transmit (TX))
( RTI CAN Blockset Reference).
Enabling RX service support You have to enable RX service support for each CAN controller and for each RX
block.
RTI support § For a CAN controller, you enable the RX service on the RX Service page of the
RTICAN CONTROLLER SETUP block. Refer to RX Service Page (RTICAN
§ For an RX block, you enable the RX service on the Options page of the
RTICAN Receive (RX) block of the RTICAN CONTROLLER. Refer to Options
Page (RTICAN Receive (RX)) ( RTI CAN Blockset Reference).
Gatewaying Messages Between CAN Buses ( RTI CAN Blockset Reference)
Removing a CAN Controller (Go Bus Off)
Introduction If you use several CAN controllers, you can remove the one currently in use from
the bus. Data transfer from the master to the slave processor is then stopped.
You can select the CAN controller you want to remove from the bus via the
RTICAN Go Bus Off block.
112
You can restart data transfer with another CAN controller or the same one with
the RTICAN Bus Off Recovery block.
RTI support § To remove a CAN controller from the bus, use the RTICAN Go Bus Off block.
Refer to RTICAN Go Bus Off ( RTI CAN Blockset Reference).
§ To restart data transfer, use the RTICAN Bus Off Recovery block. Refer to
RTICAN Bus Off Recovery ( RTI CAN Blockset Reference).
RTICAN Bus Off Recovery ( RTI CAN Blockset Reference)

RTICAN Go Bus Off ( RTI CAN Blockset Reference)
Getting CAN Status Information
Introduction You can use the Error Management Logic (EML) of a CAN controller to get error
and status information on the CAN bus and the controller. Errors occur, for
example, if a CAN controller fails to transmit a message successfully.
CAN controller status The controller’s EML has two counters: the Receive Error counter and the
information Transmit Error counter. According to their values, the EML can set the CAN
controller to one of the following states:
Counter Value Error State Description

Each counter value < 128 Error active The CAN controller is active. Before turning to the error passive state, the
controller sets an error warn (EWRN) bit if one of the counter values is ≥
96.
At least one counter Error passive The CAN controller is still active. The CAN controller can recover from this
value ≥ 128 state itself.
Transmit Error counter Bus off The CAN controller disconnects itself from the bus. To recover, an external
value ≥ 256 action is required (bus off recovery).
CAN bus status information You can get the following CAN bus status information:
Number of … Description
Stuff bit errors Each time more than 5 equal bits in a sequence occurred in a part of a received message
where this is not allowed, the appropriate counter is incremented.
Form errors Each time the format of a received message deviates from the fixed format, the
appropriate counter is incremented.
113
CAN Support
Number of … Description
Acknowledge errors Each time a message sent by the CAN controller is not acknowledged, the appropriate
counter is incremented.
Bit 0 errors Each time the CAN controller tries to send a dominant bit level and a recessive bus level
is detected instead, the appropriate counter is incremented. During bus off recovery, the
counter is incremented each time a sequence of 11 recessive bits is detected. This
enables the controller to monitor the bus off recovery sequence, indicating that the bus
is not permanently disturbed.
Bit 1 errors Each time the CAN controller tries to send a recessive bit level and a dominant bus level
is detected instead, the appropriate counter is incremented.
Cyclic redundancy check Each time the CRC checksum of the received message is incorrect, the appropriate
(CRC) errors counter is incremented. The EML also checks the CRC checksum of each message (see
Message fields ( RTI CAN Blockset Reference)).
Lost RX messages Each time a message cannot be stored in the buffer of the CAN controller, the message
is lost and an RX lost error is detected.
Successfully received RX Each time an RX message is received successfully, the appropriate counter is
messages incremented.
Successfully sent TX Each time a TX message is sent successfully, the appropriate counter is incremented.
messages
(DS4302 only) Status of The error state of the fault tolerant receiver is reported.
fault tolerant receiver
(DS4302 only) Fault The value of the output is increased if a CAN bus events occurs.
tolerant transceiver
RTI support To get status information, use the RTICAN Status block. Refer to RTICAN Status
( RTI CAN Blockset Reference).
CAN Service Functions ( DS2211 RTLib Reference)

RTICAN Status ( RTI CAN Blockset Reference)
I/O Mapping of the CAN Bus Interfaces
Introduction The CAN subsystem of the DS2210 provides two independent CAN bus
interfaces that meet the ISO/DIS 11898 specifications.
114
I/O mapping The table below shows the mapping of the channel numbers to the
corresponding I/O pins of ECU connector, as used in RTI and RTLib.
Channel Number ECU Connector Pin Signal Description I/O Characteristics

CAN1 1 CC CAN1H CAN bus interface 1 high ISO 11898
1 CD CAN1L CAN bus interface 1 low ISO 11898
CAN2 1 CF CAN2H CAN bus interface 2 high ISO 11898
1 CH CAN2L CAN bus interface 2 low ISO 11898
Setting Up a CAN Controller ................................................................................................. 102
References
I/O Mapping to the ECU 1 Connector ................................................................................... 194
115
CAN Support
Using the RTI CAN MultiMessage Blockset

Introduction The RTI CAN MultiMessage Blockset is a Simulink blockset for efficient and
dynamic handling of complex CAN setups in hardware-in-the-loop (HIL)
applications.
Basics on the RTI CAN MultiMessage Blockset ..................................... 116

Gives you an overview of the features of the RTI CAN MultiMessage
Blockset.
Basics on Working with CAN FD .......................................................... 121

Using the CAN FD protocol allows data rates higher than 1 Mbit/s and
payloads longer than 8 bytes per message.
Basics on Working with a J1939-Compliant DBC File ........................... 126

J1939 is a vehicle CAN bus standard defined by the Society of
Automotive Engineers (SAE). It is used for communication in heavy-duty
vehicles, for example, for communication between a tractor and its
trailer.
Transmitting and Receiving CAN Messages .......................................... 132

Large CAN message bundles can be managed by a single Simulink block
provided by the RTI CAN MultiMessage Blockset.
Manipulating Signals to be Transmitted ............................................... 135

You can analyze signals of RX messages or change the values of signals
of TX messages in the experiment software.
Basics on the RTI CAN MultiMessage Blockset
Introduction The RTI CAN MultiMessage Blockset is a Simulink blockset for efficient and
dynamic handling of complex CAN setups in hardware-in-the-loop (HIL)
applications. All the incoming RX messages and outgoing TX messages of an
entire CAN controller can be controlled by a single Simulink block. CAN
communication is configured via database files (DBC file format, FIBEX file
format, MAT file format, or AUTOSAR XML file format).
Supporting dSPACE platforms ............................................................................................... 117

Managing large CAN message bundles ................................................................................. 117
116
Support of CAN FD protocol ................................................................................................. 117

Manipulating signals to be transmitted ................................................................................. 118
Updating a model ................................................................................................................. 118
Modifying model parameters during run time ....................................................................... 118
User‑defined variables ........................................................................................................... 118
Working with variants of CAN communication ..................................................................... 118
Gatewaying messages between CAN buses .......................................................................... 119
Online modification of gateway exclude list .......................................................................... 119
Dynamic message triggering ................................................................................................. 119
Defining free raw messages .................................................................................................. 119
Capturing messages ............................................................................................................. 119
CAN partial networking ........................................................................................................ 119
TRC file entries with initial data ............................................................................................. 120
Visualization with the Bus Navigator ..................................................................................... 120
RTI CAN Blockset and RTI CAN MultiMessage Blockset ......................................................... 120
Further information on the RTI CAN MultiMessage Blockset .................................................. 121
Supporting dSPACE platforms The RTI CAN MultiMessage Blockset is supported by the following dSPACE
platforms:
§ SCALEXIO systems with a DS2671 Bus Board, DS2672 Bus Module, DS6301
CAN/LIN Board, and/or DS6341 CAN Board
§ DS1103 PPC Controller Board
§ MicroAutoBox
§ MicroLabBox
§ PHS-bus-based systems (DS1005, DS1006, or DS1007 modular systems)
containing one of the following I/O boards:
§ DS4302 CAN Interface Board
§ DS4505 Interface Board, if the DS4505 is equipped with DS4342 CAN FD
Interface Modules
The dSPACE platforms provide 1 ... 4 CAN controllers. A CAN controller performs
serial communication according to the CAN protocol. To use a dSPACE board
with CAN bus interface, you must configure the CAN controller – called the CAN
channel – according to the application.
Managing large CAN message With the RTI CAN MultiMessage Blockset, you can configure and control a large
bundles number of CAN messages (more than 200) from a single Simulink block. This
reduces the size of model files and the time required for the build process.
Support of CAN FD protocol The RTI CAN MultiMessage Blockset supports the classic CAN protocol, the
non‑ISO CAN FD protocol (which is the original CAN FD protocol from Bosch)
and the ISO CAN FD protocol (according to the ISO 11898‑1:2015 standard). The
CAN FD protocols allow data rates higher than 1 Mbit/s and payloads of up to
64 bytes per message.
117
CAN Support
Keep in mind that the CAN FD protocols are supported only by

dSPACE platforms equipped with a CAN FD-capable CAN controller.
For further information, refer to Basics on Working with CAN FD on page 121.
Manipulating signals to be The RTI CAN MultiMessage Blockset provides several options to manipulate the
transmitted values of signals before they are transmitted. You can switch between them with
the Bus Navigator in ControlDesk via entries in the generated TRC file. In
addition, you can calculate checksum, parity, toggle, counter, and mode counter
values.
Updating a model The RTI CAN MultiMessage Blockset creates an S-function for the specified
database file. You can easily update the CAN configuration of a model by
replacing the database file and updating the S‑function.
Tip
You do not have to recreate the S-function for the RTI CAN MultiMessage
Blockset if you switch from one processor board to another, e.g., from a
DS1005 to a DS1007, and vice versa.
When you switch to or from a DS1103, MicroAutoBox, or MicroLabBox, you

only have to recreate the ControllerSetup block. You also have to recreate
the ControllerSetup block if you change the controller name.
Modifying model parameters Model parameters such as messages or signal values can be modified during run
during run time time either via model input or via the Bus Navigator in ControlDesk. For
modifying model parameters via ControlDesk, a variable description file (TRC) is
automatically generated each time you create an S-function for the RTICANMM
MainBlock. The entries of the TRC file let you analyze received signals, change
the values of signals to be transmitted, etc. In ControlDesk, you can access the
settings specified in the TRC file via the model's system description file (SDF). The
SDF file bundles all the TRC files and additional information for the application.
(Relevant only for SCALEXIO systems with a DS2671 Bus Board, DS2672 Bus
Module, DS6301 CAN/LIN Board, and/or DS6341 CAN Board) For information on
where to find the signals of the CAN bus in the TRC file, refer to Available TRC
File Variable Entries and Their Locations in the TRC File ( ConfigurationDesk
Real-Time Implementation Guide).
User‑defined variables You can include user‑defined variables in a TRC file in addition to the parameters
of the RTI CAN MultiMessage Blockset.
Working with variants of CAN You can work with different CAN communication variants on one CAN
communication controller, and switch between them during run time. Only one variant for each
118
CAN controller can be active at a time. In the Bus Navigator, the active variant
is labeled when an application is running on the real-time hardware. An
inactive variant is labeled . If you open layouts of an inactive variant, the
headers of all the RX and TX layouts are red.
Gatewaying messages You can easily exchange messages between different CAN buses. In addition,
between CAN buses you can use the gatewaying feature to modify messages in gateway mode
during run time.
Online modification of You can modify the exclude list of RTICANMM Gateways during run time, i.e.,
gateway exclude list specify messages not to be gatewayed.
Dynamic message triggering You can modify the cycle times and initiate a spontaneous transmission
(interactive or model-based) during run time.
Defining free raw messages You can define free raw messages as additional messages that are independent
of the database file. Once they are defined, you can use them like standard
database messages and specify various options, for example:
§ Trigger options
§ Ports and displays
§ Message ID and length adjustable during run time
The following features are not supported:

§ Checksum generation
§ Custom signal manipulation
Capturing messages You can process the raw data of messages whose IDs match a given filter via the
capture messages feature. This can be a specific ID, a range of IDs, or even all
IDs. Optionally, you can exclude the messages contained in the database file.
The captured messages can be made available as outports of the MainBlock or in

the TRC file.
CAN partial networking With CAN partial networking, you can set selected ECUs in a network to sleep
mode or shut them down if they do not have to run continuously. Wake‑up
messages then activate specific ECUs as and when required, and for as long as
required.
119
CAN Support
Note
Partial networking is possible for the following dSPACE real-time hardware:

§ MicroAutoBox II equipped with the DS1513 I/O Board
§ MicroLabBox
§ dSPACE hardware that supports working with CAN FD messages and that
is equipped with DS4342 CAN FD Interface Modules, such as:
§ PHS-bus-based systems (DS1005, DS1006, or DS1007 modular systems)
with DS4505 Interface Board
§ MicroAutoBox II variants with DS1507
The RTI CAN MultiMessage Blockset lets you specify the CAN partial networking
wake‑up messages by filtering message IDs and message data.
The CAN transceiver of the dSPACE real-time hardware is switched to sleep

mode via the real‑time application. You can use partial networking messages to
wake up dSPACE real-time hardware after its CAN transceiver is switched to
sleep mode.
(Relevant for MicroAutoBox only) If MicroAutoBox's CAN transceiver is woken up

via a partial networking message, MicroAutoBox behaves as if it was powered up
manually. Depending on where the real‑time application is loaded (flash memory
or RAM), MicroAutoBox starts the application or waits for further input.
For further information, refer to Partial Networking Page (RTICANMM

ControllerSetup) ( RTI CAN MultiMessage Blockset Reference).
TRC file entries with initial TRC/SDF files generated for Simulink models including blocks from the RTI CAN
data MultiMessage Blockset contain initial data. The RTI CAN MultiMessage Blockset
supplies all variables with initial values when they are included in the TRC file.
TRC files with initial data lets you to perform offline calibration with
ControlDesk.
Visualization with the Bus The RTI CAN MultiMessage Blockset supports visualization with the Bus
Navigator Navigator. Layouts/instruments are generated on demand and provide access to
all CAN signals and all switches required to configure CAN communication
during run time. You do not have to preconfigure layouts by hand.
RTI CAN Blockset and RTI CAN (Not relevant for SCALEXIO systems with a DS2671 Bus Board, DS2672 Bus
MultiMessage Blockset Module, DS6301 CAN/LIN Board, and/or DS6341 CAN Board) You can use the
RTI CAN Blockset and the RTI CAN MultiMessage Blockset in parallel for different
CAN controllers. However, you cannot use the RTI CAN MultiMessage Blockset
and the RTI CAN Blockset for the same CAN controller.
120
Further information on the The following documents provide further information on the RTI CAN
RTI CAN MultiMessage MultiMessage Blockset:
Blockset § RTI CAN MultiMessage Blockset Reference
This RTI reference provides a full description of the RTI CAN MultiMessage
Blockset.
§ RTI CAN MultiMessage Blockset Tutorial
This tutorial guides you through your first steps with the RTI CAN
MultiMessage Blockset.
Basics on Working with CAN FD
Introduction Using the CAN FD protocol allows data rates higher than 1 Mbit/s and payloads
longer than 8 bytes per message.
Basics on CAN FD ................................................................................................................. 121

CAN FD protocols ................................................................................................................. 122
CAN FD message characteristics ............................................................................................ 122
Activating CAN FD mode in the RTI CAN MultiMessage Blockset .......................................... 125
Supported database file types ............................................................................................... 125
Supported dSPACE platforms ................................................................................................ 125
Working with CAN messages and CAN FD messages ............................................................ 126
Basics on CAN FD CAN FD stands for CAN with Flexible Data Rate. The CAN FD protocol is based
on the CAN protocol as specified in ISO 11898‑1. Compared with the classic
CAN protocol, CAN FD comes with an increased bandwidth for the serial
communication. The improvement is based on two factors:
§ The CAN FD protocol allows you to use CAN messages with longer data fields
(up to 64 bytes).
§ The CAN FD protocol allows you to use a higher bit rate (typically higher by a
factor of 8). It is possible to switch inside the message to the faster bit rate.
Arbitration phase and data phase CAN FD messages consist of two

phases: a data phase and an arbitration phase. The data phase spans the phase
where the data bits, CRC and length information are transferred. The rest of the
frame, outside the data phase, is the arbitration phase. The data phase can be
configured to have a higher bit rate than the arbitration phase.
CAN FD still uses the CAN bus arbitration method. During the arbitration
process, the standard data rate is used. After CAN bus arbitration is decided, the
data rate can be increased. The data bits are transferred with the preconfigured
higher bit rate. At the end of the data phase, CAN FD returns to the standard
data rate.
121
CAN Support
The following illustration shows a classic CAN message, a CAN FD message using
a higher bit rate during the data phase, and a CAN FD message with longer
payload using a higher bit rate. You can see the implications of the CAN FD
features: The arbitration phases are identical in all cases, because the standard
bit rate is always used. The lengths of the data phases differ depending on the
payload length and bit rate used.
Classic CAN message
Arbitration Data phase Arbitration

phase phase
CAN FD message using a higher bit rate
Arbitration Arbitration
phase Data phase phase
CAN FD message with longer payload using a higher bit rate
Arbitration Data phase .................... Arbitration

phase phase
CAN FD protocols Currently, there are two CAN FD protocols on the market, which are not
compatible with each other.
§ The non‑ISO CAN FD protocol represents the original CAN FD protocol from
Bosch.
§ The ISO CAN FD protocol represents the CAN FD protocol according to the
ISO 11898‑1:2015 standard.
Compared to the non‑ISO CAN FD protocol, the ISO CAN FD protocol comes
with an improved failure detection capability.
The RTI CAN MultiMessage Blockset supports both CAN FD protocols.
CAN FD message In principle, CAN FD messages and CAN messages consist of the same elements
characteristics and have the same message structure.
122
For an overview of the fields of a CAN FD message and the message

components for each of the two CAN FD protocols, refer to the following
illustration:
§ Non‑ISO CAN FD protocol:

End of
Frame
Start of Interframe
Frame Arbitration Control Data CRC ACK Space
Field Field Field Field Field
ACK delimiter
CRC delimiter
SOF Identifier r1 IDE EDL r0 BRS ESI DLC Data CRC ACK EOF IFS
Arbitration phase Data phase Arbitration phase

(standard bit rate) (optional high bit rate) (standard bit rate)
§ ISO CAN FD protocol:

End of
Frame
Start of Interframe
Frame Arbitration Control Data CRC ACK Space
Field Field Field Field Field
ACK delimiter
CRC delimiter
SOF Identifier RRS IDE FDF res BRS ESI DLC Data Stuff CRC ACK EOF IFS
count
Arbitration phase Data phase Arbitration phase

(standard bit rate) (optional high bit rate) (standard bit rate)
There are some differences between CAN FD messages and CAN messages:
§ The Data field and the CRC field of CAN FD messages can be longer. The
maximum payload length of a CAN FD message is 64 bytes.
§ The Control fields are different:
§ A classic CAN message always has a dominant (= 0) reserved bit
immediately before the data length code.
In a CAN FD message, this bit is always transmitted with a recessive level
(= 1) and is called EDL (Extended Data Length) or FDF (FD Format),
depending on the CAN FD protocol you are working with. So CAN
messages and CAN FD messages are always distinguishable by looking at
the EDL/FDF bit. A recessive EDL/FDF bit indicates a CAN FD message, a
dominant EDL/FDF bit indicates a CAN message.
123
CAN Support
In CAN FD messages, the EDL/FDF bit is always followed by a dominant

reserved bit (r0/res), which is reserved for future use.
§ A CAN FD message has the additional BRS (Bit Rate Switching) bit, which
allows you to switch the bit rate for the data phase. A recessive BRS bit
switches from the standard bit rate to the preconfigured alternate bit rate. A
dominant BRS bit means that the bit rate is not switched and the standard
bit rate is used.
§ A CAN FD message has the additional ESI (Error State Indicator) bit. The ESI
bit is used to identify the error status of a CAN FD node. A recessive ESI bit
indicates a transmitting node in the 'error active' state. A dominant ESI bit
indicates a transmitting node in the 'error passive' state.
§ Since CAN FD messages can contain up to 64 data bytes, the coding of the
DLC (data length code) has been expanded. The following table shows the
possible data field lengths of CAN FD messages and the corresponding DLC
values.
DLC Number of Data Bytes

0000 0
0001 1
0010 2
0011 3
0100 4
0101 5
0110 6
0111 7
1000 8
1001 12
1010 16
1011 20
1100 24
1101 32
1110 48
1111 64
If necessary, padding bytes are used to fill the data field of a CAN FD message
to the next greater possible DLC value.
For classic CAN messages, the DLC values 1000 ... 1111 are interpreted as
8 data bytes.
§ (Valid for the ISO CAN FD protocol only) The CRC fields are different:
§ The CRC field of a CAN FD message was extended by a stuff count before
the actual CRC sequence. The stuff count consists of a 3‑bit stuff bit counter
(reflects the number of the data‑dependent dynamic stuff bits (modulo 8)),
and an additional parity bit to secure the counter.
§ The start value for the CRC calculation was changed from '0...0' to '10...0'.
124
Activating CAN FD mode in To ensure that CAN FD messages are properly transmitted and received during
the RTI CAN MultiMessage run time, the CAN FD mode must be enabled at two places in the RTI CAN
Blockset MultiMessage Blockset: in the MainBlock and at the CAN controller selected in
the MainBlock. To do so, perform the following steps:
§ In the ControllerSetup block, select the CAN FD protocol to be used. Refer to
Setup Page (RTICANMM ControllerSetup) ( RTI CAN MultiMessage Blockset
Reference).
§ In the MainBlock, select the CAN FD support checkbox. Refer to General
Settings Page (RTICANMM MainBlock) ( RTI CAN MultiMessage Blockset
Reference).
To monitor CAN FD messages, it is sufficient to enable CAN FD support in the

ControllerSetup block.
Supported database file types To work with CAN FD messages, you need a suitable database file containing
descriptions in the CAN FD format. The RTI CAN MultiMessage Blockset supports
CAN FD for the following database file types:
§ DBC file
§ AUTOSAR system description file
Supported dSPACE platforms The RTI CAN MultiMessage Blockset supports working with CAN FD messages
for the following dSPACE hardware:
§ SCALEXIO systems with a DS2671 Bus Board, DS2672 Bus Module, DS6301
CAN/LIN Board, or DS6341 CAN Board
§ The following dSPACE platforms if they are equipped with DS4342 CAN FD
Interface Modules:
§ DS1005 modular system with DS4505 Interface Board
§ MicroAutoBox II in the following variants:
§ 1401/1505/1507
§ 1401/1507
§ 1401/1511/1512
§ 1401/1511/1514
§ 1401/1512/1513
§ 1401/1513/1514
When you connect a DS4342 CAN FD Module to a CAN bus, you must note
some specific aspects (such as bus termination and using feed‑through bus lines).
For further information, refer to:
§ PHS-bus-based system with DS4505: DS4342 Connections in Different
Topologies ( PHS Bus System Hardware Reference)
§ MicroAutoBox: DS4342 Connections in Different Topologies ( MicroAutoBox
II Hardware Installation and Configuration)
125
CAN Support
Working with CAN messages Both messages in CAN format and in CAN FD format can be transmitted and
and CAN FD messages received via the same network.
Setup Page (RTICANMM ControllerSetup) ( RTI CAN MultiMessage Blockset

Reference)
Basics on Working with a J1939-Compliant DBC File
Introduction J1939 is a vehicle CAN bus standard defined by the Society of Automotive
Engineers (SAE). It is used for communication in heavy-duty vehicles, for
example, for communication between a tractor and its trailer.
The RTI CAN MultiMessage Blockset supports you in working with J1939-
compliant DBC files.
Broadcast and peer‑to‑peer CAN message identifier for J1939 Standard CAN messages use an 11-bit
communication message identifier (CAN 2.0 A). J1939 messages use an extended 29-bit
message identifier (CAN 2.0 B).
The 29-bit message identifier is split into different parts (according to SAE
J1939/21 Data Link Layer):
Reserved Data page

1 bit 1 bit
Priority PGN Source address

PDU_F PDU_S
3 bits 8 bits 8 bits 8 bits
29-bit CAN message ID
§ The 3-bit priority is used during the arbitration process. A value of 0 represents
the highest priority, a value of 7 represents the lowest priority.
§ The 1-bit reserved is reserved for future purposes.
§ The 1-bit data page is a selector for the PDU_F in the PGN. It can be taken as
an extension of the PGN. The RTI CAN MultiMessage Blockset uses the data
page bit in this way.
§ The 16-bit PGN is the parameter group number. It is described in this section.
§ The 8-bit source address is the address of the transmitting network node.
Parameter group number (PGN) A 16-bit number in the 29-bit message

identifier of a CAN message defined in a J1939-compliant DBC file. Each PGN
references a parameter group that groups parameters and assigns them to the 8-
126
byte data field of the message. A parameter group can be the engine
temperature including the engine coolant temperature, the fuel temperature,
etc. PGNs and parameter groups are defined by the SAE (see SAE J1939/71
Vehicle Application Layer).
The first 8 bits of the PGN represent the PDU_F (Protocol Data Unit format). The
PDU_F value specifies the communication mode of the message (peer-to-peer or
broadcast). The interpretation of the PDU_S value (PDU-specific) depends on the
PDU_F value. For messages with a PDU_F < 240 (peer-to-peer communication,
also called PDU1 messages), PDU_S is not relevant for the PGN, but contains the
destination address of the network node that receives the message. For
messages with a PDU_F ≥ 240 (broadcast messages, also called PDU2 messages),
PDU_S specifies the second 8 bits of the PGN and represents the group
extension. A group extension is used to increase the number of messages that
can be broadcast in the network.
PDU_F (first 8 bits) PDU_S (second 8 bits) Communication Mode

< 240 Destination address Peer-to-peer (message is transmitted to one destination network
node)
≥ 240 Group extension Broadcast (message is transmitted to any network node connected
to the network)
Message attributes in J1939- A message described in a J1939-compliant DBC file is described by the ID
compliant DBC files attribute and others.
DBC files created with CANalyzer 5.1 or earlier In a DBC file created with
CANalyzer 5.1 or earlier, the ID attribute describing a message actually is the
message PGN. Thus, the ID provides no information on the source and
destination of the message. The source and destination can be specified by the
J1939PGSrc and J1939PGDest attributes.
DBC files created with CANalyzer 5.2 or later In a DBC file created with
CANalyzer 5.2 or later, the ID attribute describing a message actually is the CAN
message ID, which consists of the priority, PGN, and source address. Thus, the ID
provides information on the source and destination of the message. Further
senders can be specified for a message in Vector Informatik’s CANdb++ Editor
(_BO_TX_BU attribute). When a DBC file is read in, RTICANMM automatically
creates new instances of the message for its other senders.
Source/destination mapping Messages in a J1939-compliant DBC file that are described only by the PGN have
no source/destination mapping. Messages that are described by the CAN
message ID (consisting of the priority, PGN, and source address) have
source/destination mapping.
127
CAN Support
Tip
The RTI CAN MultiMessage Blockset lets you specify source/destination

mapping for messages that are described only by the PGN. The mapping
can be specified in the RTICANMM MainBlock or in the DBC file using the
J1939Mapping attribute.
Container and instance The RTI CAN MultiMessage Blockset distinguishes between container and
messages instance messages when you work with a J1939-compliant DBC file:
Container message A J1939 message defined by its PGN (and Data Page
bit). A container can receive all the messages with its PGN in general. If several
messages are received in one sampling step, only the last received message is
held in the container. Container messages can be useful, for example, when you
configure a gateway with message manipulation.
Instance message A J1939 message defined by its PGN (and Data Page bit),
for which the source (transmitting) network node and the destination (receiving)
network node (only for peer-to-peer communication) are defined.
Note
The RTI CAN MultiMessage Blockset only imports instances for which valid
source node and destination node specifications are defined in the DBC file.
In contrast to instances, containers are imported regardless of whether or
not valid source node and destination node specifications are known for
them during the import. This lets you configure instances in the RTI CAN
MultiMessage Blockset.
There is one container for each PGN (except for proprietary PGNs). If you work
with DBC files created with CANalyzer 5.1 or earlier, the container can be clearly
derived from the DBC file according to its name. With DBC files created with
CANalyzer 5.2 or later, several messages with the same PGN might be defined. In
this case, either the message with the shortest name or an additionally created
message (named CONT_<shortest_message_name>) is used as the container
for the PGN. The RTI CAN MultiMessage Blockset lets you specify the container
type in the RTICANMM MainBlock. If several messages fulfill the condition of the
shortest name, the one that is listed first in the DBC file is used. For messages
with proprietary PGNs, each message is its own container (because proprietary
PGNs can have different contents according to their source and destination
nodes).
Network management The J1939 CAN standard defines a multimaster communication system with
decentralized network management. J1939 network management defines the
automatic assignment of network node addresses via address claiming, and
provides identification for each network node and its primary function.
Each network node must hold exactly one 64‑bit name and one associated
address for identification.
128
Address The 8-bit network node address defines the source or destination
for J1939 messages in the network. The address of a network node must be
unique. If there is an address conflict, the network nodes try to perform dynamic
network node addressing (address claiming) to ensure unique addresses, if this is
enabled for the network nodes.
The J1939 standard reserves the following addresses:
§ Address 0xFE (254) is reserved as the 'null address' that is used as the source
address by network nodes that have not yet claimed an address or have failed
to claim an address.
§ Address 0xFF (255) is reserved as the 'global address' and is exclusively used as
a destination address in order to support message broadcasting (for example,
for address claims).
The RTI CAN MultiMessage Blockset does not allow J1939 messages to be sent
from the null or global addresses.
Note
The RTI CAN MultiMessage Blockset interprets attributes in the DBC file like
this:
§ In a DBC file created with CANalyzer 5.1 or earlier, the name network
node attributes and the J1939PGSrc and J1939PGDest message attributes
are read in. The J1939PGSrc attribute is interpreted as the address of the
node that sends the message, the J1939PGDest attribute is interpreted as
the address of the node that receives the message.
§ In a DBC file created with CANalyzer 5.2 or later, the name and
NMStationAddress network node attributes are read in. The
NMStationAddress attribute is interpreted as the network node address.
Name The J1939 standard defines a 64-bit name to identify each network
node. The name indicates the main function of the network node with the
associated address and provides information on the manufacturer.
Arbitrary Industry Vehicle Vehicle Reserved Function Function ECU Manufacturer Identity
Address Group System System Instance Instance Code Number
Capable Instance
1 bit 3 bit 4 bit 7 bit 1 bit 8 bit 5 bit 3 bit 11 bit 21 bit
Address claiming The J1939 standard defines an address claiming process in

which addresses are autonomously assigned to network nodes during network
initialization. The process ensures that each address is unique.
Each network node sends an address claim to the CAN bus. The nodes receiving
an address claim verify the claimed address. If there is an address conflict, the
network node with the lowest 64‑bit name value (highest priority) gets the
claimed address. The other network nodes must claim different addresses.
The following illustration shows the address claiming process with two network
nodes claiming the same address. Network node A has a 64‑bit name of higher
priority.
129
CAN Support
Network node A Network node B (self-configurable)
Initialization
(POST)
Addr
Sour ess c
ce addr laim
ess = Initialization
X, Na (POST)
me =A
laim
ess c me =
B
Addr
s = X, Na
e s
addr
S ource
Addr
Sour ess c
ce ad laim
dress
= X,
Nam
e =A
laim
ess c e=B
Addr , Nam
= Y
ess
addr
S ource
t t
The following steps are performed in the address claiming procedure:
§ Node A starts initialization and the power‑on self‑test (POST).
§ While node B performs initialization and POST, node A sends its address claim
message.
§ After performing initialization and POST, node B sends its address claim
message, trying to claim the same source address as node A.
§ In response to the address claim message of node B, the 64‑bit names of the
network nodes are compared. Because the name of network node A has a
higher priority, network node A succeeds and can use the claimed address.
Node A sends its address claim message again.
§ Network node B receives the address claim message and determines that node
A’s name has higher priority. Node B claims a different address by sending
another address claim message.
The RTI CAN MultiMessage Blockset supports J1939 network management

including address claiming for self‑configurable address network nodes. This
allows network nodes simulated by the RTI CAN MultiMessage Blockset to
change their addresses, if necessary, and to update their internal address
assignments if addresses of external network nodes are changed.
130
Note
The RTI CAN MultiMessage Blockset supports network management only

for network nodes for which network addresses are contained in the DBC
file and that have unique 64‑bit name identifiers. The node configuration is
taken directly from the DBC file and can be adapted on the RTI CAN
MultiMessage Blockset dialog pages.
Messages > 8 bytes (message Standard CAN messages have a data field of variable length (0 ... 8 bytes). The
packaging) J1939 protocol defines transport protocol functions which allow the transfer of
up to 1785 bytes in one message.
A multipacket message contains up to 255 data fields, each of which has a

length of 8 bytes. Each data field is addressed by the 1-byte sequence number,
and contains 7 bytes of data. This yields a maximum of 1785 (= 255 · 7) bytes in
one message.
Sequence Data Sequence Data Sequence Data

number 1 number 2 ... number n
Byte 1 Byte 2 ... 8 Byte 1 Byte 2 ... 8 Byte 1 Byte 2 ... 8
Data field 1 Data field 2 Data field n
Broadcasting multipacket messages via BAM To broadcast a multipacket

message, the sending network node first sends a Broadcast Announce Message
(BAM). It contains the PGN and size of the multipacket message, and the
number of packages. The BAM allows all receiving network nodes to prepare for
the reception. The sender then starts the actual data transfer.
Peer-to-peer communication of multipacket messages via RTS/CTS To

transfer a multipacket message to a specific destination in the network, the
sending network node sends a request to send (RTS). The receiving network
node responds with either a clear to send (CTS) message or a connection abort
message if the connection cannot be established. When the sending network
node receives the CTS message, it starts the actual data transfer.
The RTI CAN MultiMessage Blockset supports J1939 message packaging via BAM
and RTS/CTS.
Lesson 13 (Advanced): Working with a J1939-Compliant DBC File ( RTI CAN

MultiMessage Blockset Tutorial)
131
CAN Support
Transmitting and Receiving CAN Messages
Introduction Large CAN message bundles (> 200 messages) can be managed by a single
Simulink block provided by the RTI CAN MultiMessage Blockset.
Defining CAN communication To define the CAN communication of a CAN controller, you can specify a DBC,
MAT, FIBEX, or AUTOSAR system description file as the database file on the
General Settings Page (RTICANMM MainBlock) ( RTI CAN MultiMessage
Blockset Reference). You can also define CAN communication without using a
database file.
DBC file as the database The Data Base Container (DBC) file format was
developed by Vector Informatik GmbH, Stuttgart, Germany. For the RTI CAN
MultiMessage Blockset, you can use all the DBC files that pass the consistency
check of Vector Informatik’s CANdb++ Editor.
FIBEX file as the database The Field Bus Exchange (FIBEX) format is an XML
exchange file format. It is used for data exchange between different tools that
work with message-oriented bus communication. A FIBEX file usually describes
more than one bus system. You therefore have to select one of the available bus
systems if you work with a FIBEX file as the database.
AUTOSAR system description file as the database You can use an

AUTOSAR system description file as the database for CAN communication.
AUTOSAR (AUTomotive Open System ARchitecture) is an industry partnership
that aims to develop and establish an open standard for automotive
electric/electronic (E/E) architectures.
AUTOSAR system description files are files of AUTOSAR XML file type that
describe a system according to AUTOSAR. A system is a combination of a
hardware topology, a software architecture, a network communication, and
information on the mappings between these elements. AUTOSAR system
description files are instances of the AUTOSAR System Template.
An AUTOSAR system description file usually describes more than one bus system.
You therefore have to select one of the available bus systems if you work with an
AUTOSAR XML file as the database.
MAT file as the database You can also use the MAT file format as the
database for CAN communication, or specify other database file formats as the
database. You must convert your specific database files into the MAT file format
for this purpose. Because the MAT file requires a particular structure, it must be
generated by M‑script.
Working without a database file If you want to work without a database

file, you can use free raw messages and/or capture messages. These messages
are independent of DBC and MAT files.
132
Changing database defaults When you work with a database file, you can
change its default settings via the following dialog pages of the RTICANMM
MainBlock:
§ Cycle Time Defaults Page (RTICANMM MainBlock)
§ Base/Update Time Page (RTICANMM MainBlock)
§ TX Message Length Page (RTICANMM MainBlock)
§ Message Defaults Page (RTICANMM MainBlock)
§ Signal Defaults Page (RTICANMM MainBlock)
§ Signal Ranges Page (RTICANMM MainBlock)
§ Signal Errors Page (RTICANMM MainBlock)
Defining RX messages and TX You can receive and/or transmit each message defined in the database file that
messages you specify for CAN communication.
Defining RX messages You can define RX messages on the RX Messages

Page (RTICANMM MainBlock).
Defining TX messages You can define TX messages on the TX Messages

Page (RTICANMM MainBlock).
Triggering TX message You can specify different options to trigger the transmission of TX messages. For
transmission example, message transmission can be triggered cyclically or by an event.
For details, refer to Triggering Options Page (RTICANMM MainBlock) ( RTI

CAN MultiMessage Blockset Reference).
Triggering reactions to the You can specify the reactions to receiving a specific RX message. One example of
reception of RX messages a reaction is the immediate transmission of a TX message.
For details, refer to Raw Data Page (RTICANMM MainBlock) ( RTI CAN
MultiMessage Blockset Reference).
Working with raw data The RTI CAN MultiMessage Blockset lets you to work with the raw data of
messages. You have to select the messages for this purpose. The RTICANMM
MainBlock then provides the raw data of these messages to the model byte‑wise
for further manipulation. You can easily access the raw data of RX messages via
a Simulink Bus Selector block.
For details, refer to Raw Data Page (RTICANMM MainBlock) ( RTI CAN
MultiMessage Blockset Reference).
Implementing checksum You can implement checksum algorithms for the checksum calculation of
algorithms TX messages and checksum verification of RX messages.
133
CAN Support
Checksum header file You have to specify the checksum algorithms in a

checksum header file. This needs to have a C-coded switch-case directive to
switch between algorithms.
Checksum calculation for TX messages You can assign a checksum

algorithm to each TX message. A checksum is calculated according to the
algorithm and assigned to the TX message. Then the message is transmitted
together with the calculated checksum.
Checksum check for RX messages You can assign a checksum algorithm to

each RX message. A checksum is calculated for the message and compared to
the checksum in the received message. If they differ, this is indicated at the error
ports for RX messages if these ports are enabled.
Checksum algorithms based on end‑to‑end communication

protection The RTI CAN MultiMessage Blockset supports run‑time access to
E2E protection parameters from AUTOSAR communication matrices and DBC
files. This means that you can implement checksum algorithms based on
end‑to‑end communication (E2E protection) parameters. E2E protection
checksum algorithms are implemented in the same checksum header file as the
checksum algorithms without E2E protection data.
For details, refer to Checksum Definition Page (RTICANMM MainBlock) ( RTI

Gatewaying messages Gatewaying means exchanging CAN messages between two CAN buses.
Gatewaying also applies to messages that are not specified in the database file.
You can also exclude individual messages specified in the database file from
being exchanged.
You can gateway CAN messages in two ways:
Controller gateway This is a gateway between two CAN controllers. The

gateway is between two RTICANMM ControllerSetup blocks and is
independent of the active CAN controller variant.
MainBlocks gateway This is a gateway between different variants of two

CAN controllers. The gateway is between two RTICANMM MainBlocks. The
MainBlocks gateway is active only if the variants of both CAN controllers are
active at the same time.
For details, refer to RTICANMM Gateway ( RTI CAN MultiMessage Blockset
Reference).
General Settings Page (RTICANMM MainBlock) ( RTI CAN MultiMessage

Blockset Reference)
134
Manipulating Signals to be Transmitted
Introduction All the signals of all the RX and TX messages (see Defining RX messages and TX
messages on page 133) automatically get corresponding entries in the generated
TRC file. This allows you to analyze them (signals of RX messages) or change
their values (signals of TX messages) with the Bus Navigator in ControlDesk.
Manipulating signals to be The RTI CAN MultiMessage Blockset provides several options to manipulate the
transmitted values of signals before they are transmitted. You can switch between the
options you have specified via entries in the generated TRC file.
The illustration below visualizes the options.
HF
2
HF
Gateway Gateway
Gateway signal switch
switch AND
HF
1
Model Switch
signal 0
NOT
1
Constant
Cyclic 2
5
Parity
6
NOT
7
Error value
8
Dynamic value
9
You can switch between these options in ControlDesk.
TX model signal A signal of a TX message whose value can be changed

from within the model. By default, the values of TX model signals cannot be
changed in ControlDesk. If you also want to manipulate TX model signals from
ControlDesk, you have to select them on the Input Manipulation Page
(RTICANMM MainBlock) ( RTI CAN MultiMessage Blockset Reference).
Because additional code has to be generated, TX model signals reduce
performance. For optimum performance, you should specify as few TX model
signals as possible.
You can specify TX model signals on the Model Signals (TX) Page (RTICANMM
MainBlock) ( RTI CAN MultiMessage Blockset Reference).
Gateway signal A signal to be manipulated before it is exchanged between

two CAN buses. Gateway signals have to be gatewayed via two RTICANMM
MainBlocks. You have to specify gateway signals for the receiving MainBlock.
135
CAN Support
Triggering
Triggering
to RTICANMM
MainBlock 1 RX Data MainBlock 2
TX Data Gateway
Gatewaying Main Block (CAN bus 1) Receiving Main Block (CAN bus 2)
MainBlock1 gateways messages and their signals to MainBlock2. Specifying
gateway signals for MainBlock2 adds a TX Data Gateway inport to it. The
specified gateway signals are transmitted via CAN bus 2 with the signal values
received from MainBlock1 when triggered by the messages received from
MainBlock1. You therefore have to specify triggered message transmission for
the messages of the gateway signals on the Message Cyclic Page (RTICANMM
MainBlock) ( RTI CAN MultiMessage Blockset Reference). In addition, you can
enable signal value switching for gateway signals during run time, for example,
to transmit the signal constant value instead of the gateway value.
Note
Implementing gateway signals at least doubles the number of block inports

and therefore reduces performance. If you want to exchange messages
between CAN controllers and do not want to perform signal manipulation,
you should use the RTICANMM Gateway block instead.
You can specify gateway signals on the pages located in the Gateway Page
Toggle signal A 1-bit signal that can be used, for example, to indicate
whether CAN messages are transmitted. If a CAN message is transmitted, the
toggle signal value alternates between 0 and 1. Otherwise, the toggle signal
value remains constant.
You can specify toggle signals on the Toggle Page (RTICANMM MainBlock)
( RTI CAN MultiMessage Blockset Reference).
Parity signal A signal that a parity bit is appended to. You can specify one or
more signals of a TX message as parity signals. A parity bit is calculated for the
specified signals according to whether even or odd parity is selected. The bit is
appended to the signal and the TX message is transmitted with the parity signal.
You can specify parity signals on the Parity Page (RTICANMM MainBlock) ( RTI
Counter signal A signal of a TX message that is used to check for correct

message transmission or to trigger the transmission of signals in a message.
§ Behavior of counter signals
The value of a counter signal changes with every message transmission. You
can specify the counter start, step, and stop values, etc. Each time the counter
reaches the stop value, it turns around to the counter start value.
§ Use of counter signals
You can specify counter signals to check for correct transmission of a message
or trigger the transmission of signals in a message.
§ Checking correct message transmission: The receiver of a message expects a
certain counter signal value. For example, if the transmission of a message
136
was stopped for two transmissions, the expected counter signal value and
the real counter signal value can differ, which indicates an error. Counter
signals used in this way are often called alive counters.
§ Triggering the transmission of signals: You can trigger the transmission of
signals if you specify a mode signal as a counter signal. The signal value of
the mode signal triggers the transmission of mode-dependent signals.
Because the counter signal value changes with every message transmission,
this triggers the transmission of the mode-dependent signals. By using
counter signals in this way, you can work with signals which use the same
bytes of a message. Counter signals used in this way are often called mode
counters.
§ Using counter signals in ControlDesk
In ControlDesk, you can transmit the signal's constant, counter, or increment
counter value. The increment counter value is the counter value incremented
by the signal's constant value.
You can specify counter signals on the Counter Page (RTICANMM MainBlock)
Error value A static signal value that indicates an error. You can specify an
error value for each signal to be transmitted. Alternatively, error values can be
defined in a database file. In ControlDesk, you can switch to transmit the signal's
error value, constant value, etc. However, you cannot change the error value
during run time. In ControlDesk, you can use a Variable Array (MultiState LED
value cell type) to indicate if the error value is transmitted.
You can specify error values on the Signal Errors Page (RTICANMM MainBlock)
Dynamic value A signal value that is transmitted for a defined number of

times.
§ Behavior of dynamic values: You can specify to use a dynamic value for each
signal to be transmitted. In ControlDesk, you can specify to transmit the
signal's constant value or dynamic value. If you switch to the dynamic value, it
is transmitted for a defined number of times (countdown value). Then signal
manipulation automatically switches back to the signal manipulation option
used before the dynamic value.
§ Example of using dynamic values: Suppose you specify a dynamic value of 8
and a countdown value of 3. If you switch to the dynamic value of the signal,
the signal value 8 is sent the next 3 times the TX message is transmitted. Then
the signal manipulation option is reset.
You can specify dynamic values on the pages located in the Dynamic Signal Page
137
CAN Support
138
Interrupts of the DS2210
DS2210 Interrupts
Introduction The DS2210 provides different interrupt types.
PHS bus interrupt The PHS bus provides several interrupt lines for communication between I/O
boards and processor board (one for each I/O board). The PHS bus interrupt
controller of the DS2210 I/O board provides 8 interrupts that can be requested
by the serial interface, the angular processing unit (angle position interrupts),
and the slave CAN. These interrupts can be masked. A global interrupt
enable/disable is available. Only enabled interrupt sources generate interrupts.
Serial interface interrupt The serial interface allocates one hardware interrupt. A subinterrupt handler
allows you to specify different subinterrupts that support sending (Tx register
empty) and receiving, for example.
Angle position interrupts Depending on the engine position (angle), the angular processing unit can
generate angle position interrupts for up to 6 cylinders. You can generate
interrupts when the cylinder has passed the top dead center (TDC), for example.
Any interrupt position can be chosen while several interrupt positions are
possible for each cylinder. Use RTI (DS2210APU_INT_Bx_Iy) or RTLib
(ds2210_int_position_set) functions to define the interrupt positions.
Slave CAN MC interrupt The slave CAN MC can request an interrupt by writing to a predefined location in
its dual-ported memory (DPMEM). You can define subinterrupts for different
message events or CAN bus events.
Slave DSP interrupts The slave DSP receives two different interrupts. One is issued by the angle
processing unit when the engine position has been updated (every 1 μs). You can
139
use this interrupt to synchronize the slave DSP and angular processing unit.
Second, the master processor can request slave DSP interrupts by writing to a
predefined location of the DPMEM. The interrupt is acknowledged by the slave
by reading this value.
Interrupt sources The following interrupt sources are available:
Interrupt Line Interrupt Source

IRQ0 … IRQ5 Angle position interrupts for up to 6 cylinders
IRQ6 Interrupt from the CAN controller
IRQ7 Interrupt from the serial interface (UART)
Interrupt handling For information on the interrupt handling, refer to Interrupt Controller
on page 30.
ds2210_int_position_set ( DS2210 RTLib Reference)

DS2210APU_INT_Bx_Iy ( DS2210 RTI Reference)
140
DS1005 Multiprocessor Systems
Introduction One DS1005 PPC Board might not offer sufficient computing power for
simulating rather large real-time models in real time. Therefore, you might want
to implement such a large real-time model on a multiprocessor system.
Basics of DS1005 Multiprocessor Systems ............................................ 143
DS910 Gigalink Module ....................................................................... 144

The optional DS910 Gigalink Module represents the bridgehead to
multiprocessing. With this module you can connect several DS1005.
Synchronization ................................................................................... 156

When running a real‑time application on a multiprocessor system it is
important to have an absolute time on all CPUs and to trigger the
timer‑driven tasks of all CPUs by means of the same timer interrupt.
Working with Subsets of a Multiprocessor Topology ............................ 159

You can specify certain CPUs – and the corresponding real‑time
applications – as optional in RTI‑MP, and work with topological subsets of
the currently registered multiprocessor system. This allows you to
download a real‑time application either to the entire multiprocessor
system or to a topological subset of this system without having to rebuild
the application.
Setting Up a Multiprocessor System ( DS1005 Hardware

Installation and Configuration Guide)
A multiprocessor system is based on two or more processor boards.
141
Basics of Handling Platforms ( ControlDesk Platform

Management)
ControlDesk can access platforms only if they are configured correctly.
Distributing the Model for MP Systems ( RTI and RTI-MP

Implementation Guide)
142
Basics of DS1005 Multiprocessor Systems
DS1005 in MP systems The DS1005 PPC Board is well equipped to set up multiprocessor systems that
provide massive computing power:
§ You can run up to twenty DS1005 as a multiprocessor system (limited by the
current device driver).
§ Arbitrary net topologies are possible.
§ All DS1005 provide full trace support.
§ Time Stamping provides an absolute time base for all DS1005.
143
DS910 Gigalink Module

Introduction The optional DS910 Gigalink Module represents the bridgehead to
multiprocessing. With this module you can connect several DS1005.
Basics of the DS910 Gigalink Module .................................................. 144

The optional DS910 Gigalink Module is used to connect several DS1005
boards. It provides a high‑speed serial data transmission via optical fiber.
Data Transmission ................................................................................ 147

DS1005 boards in a multiprocssor system exchange data via Gigalink
modules.
Virtual Shared Memory Mode .............................................................. 148

Data can be transmitted in the virtual memory mode which is based on a
single receiver buffer for each channel.
Swinging Buffer Mode ......................................................................... 148

Data can be transmitted in the swinging buffer mode which is based on
three receiver buffers for each channel, which all appear at the same
memory location so that the sender and the receiver see only one buffer
at a time.
Interrupt Transmission .......................................................................... 151

The hardware and software interrupts can be forwarded to the DS910
Gigalink Module, which makes them available to connected DS1005.
Synchronizing Data Input and Output .................................................. 155

The PHS bus has a SYNCIN and SYNCOUT line to synchronize data
acquisition and output of the I/O Boards.
Basics of the DS910 Gigalink Module
Introduction The optional DS910 Gigalink Module is used to connect several DS1005 boards.
It provides a high‑speed serial data transmission via optical fiber.
Note
If you order a multiprocessor system, the DS1005 are already equipped with
the DS910 Gigalink Modules. If you want to make your single‑processor
DS1005 capable for multiprocessing, inquire at dSPACE.
144
Characteristics The DS910 Gigalink Module has the following characteristics:

§ Four optical high‑speed communication ports (Gigalinks), each providing:
§ 16 bidirectional interrupt lines (including the PHS bus’ SYNCIN, SYNCOUT
and IOERROR lines)
§ 16 bidirectional data channels (8 channels in the virtual shared memory
mode, 8 channels in the swinging buffer mode; width of each channel:
2 KW. Refer to Data Transmission on page 147.)
Three interrupt lines and one shared memory channel are used by the
simulation environment.
§ I/O access speed of send operations adapted to the Gigalinks’ capabilities: data
is sent directly without a FIFO buffer
§ Total transfer rate: 1.25 GBit/s. See below for an example of how much time
certain Gigalink operations might take.
§ 32‑bit or 64‑bit read/write operations allowed:
§ 32‑bit access for single 32‑bit (or shorter) data words
§ Fast 64‑bit access for block transfer functions as far as possible
§ Possible distance: up to 100 m
Functional units Each Gigalink consists of a full‑duplex bidirectional interface. Before the
transmission the sender serializes the number of the pending interrupt with the
highest priority, the data and address. The receiver stores this data into an
arbitrated memory. Incoming interrupt requests are handed over to the interrupt
controller. The following illustration shows the functional units of the Gigalinks:

Gigalink 0
Data
Serializer
32
Address
16 1
Interrupts
15
optical
fiber
Data
Deserializer
Arbitrated 32
Address Memory
16 1
Interrupts
15
Gigalink 1
Since there is only one optical fiber per Gigalink and direction, the number of the
highest‑priority pending interrupt, addresses and data have to be transferred
serially. This is done via the protocol shown in the following illustration. A single
frame of this protocol can hold one interrupt request and the address and data
of one data word.
Header Interrupt Addresses Data Hea
145
If only interrupts need to be transmitted, the Gigalink module uses a simplified

protocol as shown below:
Header Interrupt Hea
Gigalink access times The maximum time (tmax) for data transfer from the main memory of the sender
DS1005 to the main memory of the receiver DS1005 can be estimated via the
formula
tmax = twrite + loptical fiber · 5 ns/m + 80 ns + tswitch + tread

Where
loptical fiber is the length of the optical fiber
twrite, tread are the write/read access times
tswitch is the read buffer switch time (block read operations in the swinging
buffer mode only)
The following tables list a few access times of the required Gigalink operations
(twrite, tread, tswitch) for a particular configuration with two DS1005 (board
revision: 3.0.3, CPU clock: 480 MHz, transfer rate: 1 GBit/s).
Write operation The following table shows the values of write operations
(twrite):
Action Size Total Access Time Transfer Rate

Single 32-bit word 32 bit 90 ns 43 MB/s
Block 32 bit 90 ns 43 MB/s
2048 · 32 bit 179,200 ns 43 MB/s
Read operation The following table shows the values of read operations
(tread):

Block 32 bit 300 ns 12 MB/s
2048 · 32 bit 289,130 ns 27 MB/s
Switch time The following table shows the values of read buffer switch time
(tswitch):

– – 230 ns –
146
Note
§ The times given in the tables denote 32‑bit aligned operations (meaning
that the address is a multiple of 4). Other addresses lead to reduced
performance.
§ The DS910 Gigalink Module is organized in 2 groups: Gigalink 0 and
Gigalink 1 are one group, Gigalink 2 and Gigalink 3 are another. If one or
both Gigalinks of a group receive data during a read access, the read
access times decrease by 15% … 20%.
Data Transmission
Introduction The following illustration shows the data path across the Gigalink between two
DS1005 boards:
DS1005 DS1005_1
Gigalink 0, Channel 0 Gigalink 2, Channel 0
write write
receiver receiver
read read
buffer buffer
Operation modes The DS910 Gigalink Module provides two operation modes for data
transmission:
§ Channels 0 … 7 operate in the swinging buffer mode. Refer to Swinging
Buffer Mode on page 148.
§ Channels 8 … 15 operate in the virtual shared memory mode (channel 8 is
reserved). Refer to Virtual Shared Memory Mode on page 148.
With RTI‑MP you simply have to select the desired protocol in the
Communication Channel Setup dialog. Refer to Interprocessor
Communication Using IPC Blocks ( RTI and RTI-MP Implementation Guide).
If you use RTLib, you can use identical read and write operations because both
modes are implemented in hardware and their operation is fully transparent to
the application. Refer to Gigalink Communication ( DS1005 RTLib Reference).
The DS1005 uses the same address for read and write operations. Write
operations send the data directly to the connected receiver. Therefore, it is not
possible to read back the data that was sent to a Gigalink, you will always read
the data that was received from the Gigalink channel in the opposite direction.
147
DS910 Gigalink Module ........................................................................................................ 144
Virtual Shared Memory Mode
Introduction This mode is based on a single receiver buffer for each channel, which the sender
and the receiver access simultaneously. The receiver buffer is arbitrated between
the sender and the receiver, and can be accessed with 32‑bit and 64‑bit
operations.
Note
If you require block consistency (meaning that all the elements of a

vector/array are consistent), you have to use the swinging buffer mode.
Writing data The sender writes its data to the buffer regardless of whether
the receiver is currently reading the buffer or not.
Reading data The receiver reads the content of the buffer regardless of
whether the sender is currently writing the buffer.
Virtual Shared Memory Protocol ( RTI and RTI-MP Implementation Guide)
Swinging Buffer Mode
Introduction This mode is based on three receiver buffers for each channel, which all appear
at the same memory location so that the sender and the receiver see only one
buffer at a time. Consider the following illustration:
148
Channel 0
Buffer 0
write
Buffer 1
read
Buffer 2
X
write update read

S R
switch switch
Description There are three pointers, each pointing to one buffer. The write pointer marks
the current write buffer, the read pointer marks the current read buffer, and the
X pointer marks the buffer that is currently neither a write nor a read buffer. The
sender and the receiver access these buffers according to the following rules:
Writing data After the sender has written data to the current write buffer, it
sends a write buffer switch command. On receipt of this signal, the write pointer
and the X pointer are swapped, and the update flag (“new data”). The X buffer
therefore now contains a complete block of consistent data. The illustration
below shows the resulting configuration:
Channel 0
Buffer 0
X
Buffer 1
read
Buffer 2
write
write update read

S "1" R
switch switch
Reading data Before the receiver reads data, it sends a read switch signal.
On receipt of this signal, the update flag is evaluated:
§ If it is set (the X pointer marks new data), the read pointer and the X pointer
are swapped.
§ If it is not set (the X pointer marks old data), the read pointer remains in its old
position.
149
Then the update flag is reset and the receiver gets the data from the current read
buffer. Starting from the first configuration, one of the following two
configurations can result next.
§ If the update flag was ”1” (“new data”) beforehand, the following
configuration results:
Channel 0
Buffer 0
write
Buffer 1
X
Buffer 2
read
write update read

S "0" R
switch switch
§ If the update flag was “0” (“no new data”) beforehand, the following
configuration results:
Channel 0
Buffer 0
write
Buffer 1
read
Buffer 2
X
write update read

S "0" R
switch switch
This behavior corresponds to RTI‑MP’s unsynchronized swinging buffer protocol.

As an alternative, the software can make the receiver wait for new data, which
corresponds to RTI‑MP’s synchronized swinging buffer protocol.
Swinging Buffer Protocol ( RTI and RTI-MP Implementation Guide)
150
Interrupt Transmission
Introduction The hardware and software interrupts can be forwarded to the DS910 Gigalink
Module, which makes them available to connected DS1005.
This section describes only the multiprocessor‑related aspects of interrupt

handling. For general information on the DS1005’s interrupt capabilities, refer to
Interrupt Controller on page 30.
Interrupt bus The DS910 Gigalink Module provides an interrupt bus with a separate line for
each interrupt. This bus allows the transmission of interrupts between the four
Gigalinks, which means that an incoming interrupt is forwarded to other
DS1005. This feature is required to synchronize the timer driven tasks on the
various DS1005, for example.
Each line of the interrupt bus can be driven by the corresponding incoming
interrupt lines of each Gigalink, which are OR combined. The incoming interrupt
lines can also be masked. Therefore, a specific line on the interrupt bus carries an
interrupt whenever one of the corresponding incoming interrupt lines of the four
Gigalinks carries an interrupt – provided that this line is not masked.
Outgoing interrupts The Gigalink Module’s outgoing interrupt lines can be driven by hardware
interrupts, software interrupts and the interrupt bus. These three sources are OR
combined and can be masked (except for the software interrupts). This is also
shown in the following illustration, which is a simplified block diagram of the
DS910 Gigalink Module’s interrupt lines (the serializer, optical fiber and
deserializer have been left out for clarity):
151
Interrupt Inputs Interrupt Outputs
... ...
Gigalink 0 ... Gigalink 3
... ≥1 ... ≥1
Gigalink 0
ICU
DS910
Gigalink Module
Int GL Int HW Int

Mask Mask Mask
... ... ... ...
Interrupt bus
...
...
... ...
Hardware
Software
STBU Sync.
Interrupts
Interrupts
Soft I/O Error

GL0 IRQ
(to DS1005 ICU)
DS1005
PPC Board
Below you can find descriptions of the terms in this illustration:

Gigalink x Communication port
Gigalink x ICU Interrupt control unit of the Gigalink x
GLx IRQ Interrupts of the Gigalink x to the DS1005
Int Mask Interrupt mask register for incoming interrupts
GL Int Mask Interrupt mask register for the Gigalink interrupt bus
HW Int Mask Interrupt mask register for hardware interrupts from the
DS1005
Hardware Interrupt Hardware interrupt from the DS1005
Software Interrupt Software interrupt from the DS1005
Soft I/O Error Forward of the PHS bus IOERROR line
STBU Sync. Interrupt of the Synchronous Time Base Unit (Macrotick)
Since all interrupts have to be transmitted via a single optical fiber, they are
transmitted serially using a subinterrupt mechanism that is implemented in the
hardware.
152
The following table lists the outgoing interrupt lines together with their interrupt
sources. These interrupt lines are implemented as hardware dispatched
subinterrupts.
Outgoing Hardware Source Software Source Interrupt Bus

Interrupt Source
0 Timer A Software 0 Interrupt In 0
1 Timer B Software 1 Interrupt In 1
2 SYNCIN Software 2 Interrupt In 2
3 SYNCOUT Software 3 Interrupt In 3
4 Watchdog Software 4 Interrupt In 4
5 Debug Software 5 Interrupt In 5
6 Software 6 Interrupt In 6
13 (reserved) Software interrupt
dispatching
14 (reserved) Soft I/O Error
15 (reserved) STBU synchronization
16 Subinterrupts are dispatched via the hardware interrupt 13 and
… the shared memory channel 0.
527
Note
Subinterrupts 13 … 15 are used by the simulation environment.
Tip
If you do not require all of the hardware interrupt sources 0 … 5, the

corresponding subinterrupt lines can be used like the subinterrupt lines
6 … 12.
Software dispatched In addition to the hardware dispatched subinterrupts, you can use up to 512
subinterrupts software dispatched subinterrupts, which are provided by RTLib. The following
table lists the available hardware and software dispatched subinterrupts as seen
by RTI and RTLib:
Outgoing Interrupt Interrupt Source

0…5 Hardware interrupt, software interrupt, interrupt bus
6 … 12 Software interrupt, interrupt bus
153
Outgoing Interrupt Interrupt Source

13 … 15 (reserved)
16 … 47 Software dispatched subinterrupts (available by default)
48 … 527 Additional software dispatched subinterrupts (available if
specified)
Note
§ The software dispatched subinterrupts (the outgoing interrupts

16 … 527) cannot be enabled or disabled individually.
§ If you want to use more than 32 software dispatched subinterrupts (the
interrupts 48 … 527), you have to specifically set the desired number in
the User‑Code files of the involved CPUs (if you use RTI‑MP) or in your
handwritten program. Refer to Interprocessor Interrupts ( DS1005
RTLib Reference).
Tip
The transmission of subinterrupts takes longer, the more subinterrupts are

used. To reduce this transmission time, make the available maximum
number of subinterrupts as low as possible.
Subinterrupt transmission The following illustration shows how the transmission time of a software
times dispatched subinterrupt depends on the specified maximum number of software
dispatched subinterrupts. This example is for a particular configuration with two
DS1005 (board revision: 3.0.3, CPU clock: 480 MHz, transfer rate: 1 GBit/s,
length of optical fiber: 5 m). You can also see that the transmission time for a
hardware dispatched subinterrupt does not depend on the specified maximum
number of software dispatched subinterrupts. It is always about 1.2 µs.
The diagram shows the transmission time for a single subinterrupt. If there are a
several subinterrupts pending, the transmission times have to be added up.
154
hardware
dispatched
16
14 software
dispatched
12
Time [µs]
10 Specified maximum
number of software
8 dispatched subinterrupts
32 (Default)
6
64
4 128
256
2
512
0
0 100 200 300 400 500
Subinterrupt number
Interprocessor Interrupts ( RTI and RTI-MP Implementation Guide)

Synchronizing Data Input and Output ................................................................................... 155
Synchronizing Data Input and Output
Introduction In a single-processor system the PHS bus features a SYNCIN and SYNCOUT line
to synchronize data acquisition and output of the I/O Boards. Refer to PHS Bus
Interface on page 32. In an multiprocessor system the DS910 Gigalink Module
can be used to distribute the SYNCIN and SYNCOUT signals from the master
processor to the slave processors. The CPU with ID 0 is the master processor for
sending the SYNCIN and SYNCOUT signals.
The slave processors receive the SYNCIN and SYNCOUT signals and forward
them to the other linked slave processors, see the following illustration.
Slave
Receive SYNC signal Forward SYNC signal
Send SYNC signal Receive SYNC signal

Master
Slave
(CPU ID 0)
155
Synchronization
Introduction When running a real‑time application on a multiprocessor system it is important
to have an absolute time on all CPUs and to trigger the timer‑driven tasks of all
CPUs by means of the same timer interrupt. These synchronization aspects are
described in the following sections.
Synchronized Timer Tasks .................................................................... 156

The timer‑driven tasks calculated on the different CPUs have to be driven
by the same timer interrupt.
Global Time Base in an MP System ...................................................... 157

The global time base in a multiprocessor system is achieved by the
Synchronous Time Base Unit (STBU).
Tracing Signals in an MP System .......................................................... 158

The Synchronous Time Base Unit is used to achieve a global time base in
a multiprocessor system. This time base is used for time stamping that
improves the tracing of signals in a multiprocessor system.
Synchronized Timer Tasks
Introduction The timer‑driven tasks calculated on the different CPUs have to be driven by the
same timer interrupt. To achieve this, the interrupt of the master’s Timer A is
forwarded to all slave boards. This forwarding causes a small time overhead so
that the start of the corresponding interrupt service routine (ISR) is slightly
delayed, as shown in the following illustration (with l = length of the optical
fiber):
ISR ISR
Master Slave
500 ns 700 ns
270 ns + l · 5ns/m
Example If you have three DS1005 connected in a series (Master – Slave 1 – Slave 2) using
5 m Gigalink connections, the interrupt service routines are delayed as follows:
156
Synchronization
Board Approx. ISR Delay

Master 0.5 µs
Slave 1 1.0 µs
Slave 2 1.3 µs
Timer A .................................................................................................................................. 28
References
Global Sample Rate Timer in an MP System ( DS1005 RTLib Reference)
Global Time Base in an MP System
Introduction The global time base in a multiprocessor system is achieved by the Synchronous
Time Base Unit (STBU). It consists of two 32‑bit counters and is driven by BCLK/2.
Basics Due to manufacturing tolerances, which lead to clock drifts, the local clocks in a
multiprocessor system have to be synchronized periodically. To keep the
communication effort low, synchronization does not take place at every tick of
the local clocks (microtick), but at a selected tick of a timing master. This selected
tick is called macrotick. Upon the occurrence of a macrotick, the number of
microticks is set to zero, and the number of macroticks is increased by 1 at each
processor. Starting from this point in time, the absolute time is calculated by
multiplying the macrotick and microtick period with its counter values and
adding the products. The absolute time is used for time stamping. At the
recommended STBU synchronization period (macrotick period) of 10 ms the
absolute time has a maximal deviation of ±1 µs.
Tip
You can always use the RTLib’s Time Stamping module to read the current
system time, regardless of whether you run a single‑processor or a
multiprocessor system. The Time Stamping module will automatically access
the correct time base. For details on the Time Stamping module, refer to
Time-Stamping ( DS1005 RTLib Reference).
157
Time‑Stamping and Data Acquisition ( RTI and RTI-MP Implementation Guide)
Tracing Signals in an MP System
Introduction The Synchronous Time Base Unit (STBU) is used to achieve a global time base in a
multiprocessor system. This time base is used for time stamping that improves
the tracing of signals in a multiprocessor system.
Master-slave tracing In the master-slave tracing method, data is copied from all processor boards to a
master processor board, which writes it in the master’s trace buffer. The copy
operation causes a time overhead.
Distributed tracing The distributed tracing method traces the signals locally at each processor board.
The host PC accesses them separately and puts the plots into relation based on
their time stamps. This means that ControlDesk can display the plot as if it
originated from one processor board. In a multiprocessor system only the
distributed tracing method is used.
Global Time Base in an MP System ....................................................................................... 157

Timers and Time Base Counters .............................................................................................. 27
Time‑Stamping and Data Acquisition ( RTI and RTI-MP Implementation Guide)
158
Working with Subsets of a Multiprocessor Topology

Introduction You can specify certain CPUs as optional and work with topological subsets of
the currently registered MP system. This allows you to download a real‑time
application either to the entire MP system or to a topological subset of this
system without having to rebuild the application.
Basics of Working with Optional CPUs ................................................. 159

Optional CPUs allow to modify the topology of a multiprocessor system
whithout having to rebuild the real-time application.
Basics of Topological Subsets ............................................................... 160

In hardware‑in‑the‑loop (HIL) simulations, you can test virtually any
number of electronic control units (ECUs) under realistic conditions with
HIL test benches based on dSPACE simulator.
How to Specify Optional CPUs in RTI-MP ............................................. 162

RTI‑MP allows you to specify certain DS1005 boards as optional.
Basics of Working with Optional CPUs
Introduction dSPACE’s RTI‑MP and ControlDesk provide two features that allow you to modify
the topology of a dSPACE multiprocessor system. Without these features, you
would have to rebuild the real‑time application with RTI‑MP and register the
modified multiprocessor system with ControlDesk.
Specifying optional CPUs in To avoid having to rebuild the real‑time application, RTI‑MP allows you to specify
RTI-MP certain DS1005 processor boards as optional CPUs.
Each CPU in a multiprocessor system corresponds to a specific real‑time

application. Therefore, specifying optional CPUs implicitly specifies optional
real‑time applications. When you build the real‑time application for the entire
multiprocessor system, it is therefore possible to run it on different topological
subsets of the system.
For details on the CPUs that can be specified as optional in an MP system, and
instructions that apply to the corresponding RTI‑MP model, see How to Specify
Optional CPUs in RTI-MP on page 162.
159
Working with topological To avoid having to re-register a multiprocessor system each time you modify it, ’s
subsets of an MP system the Platform/Device Manager of ControlDesk allows you to handle topological
subsets of a multiprocessor system containing one or more optional CPUs. This
means that ControlDesk works properly even if one or more optional CPUs are
currently disconnected or switched off.
For details, refer to Working with Multiprocessor Systems with Optional

Processors ( ControlDesk Platform Management).
Related topics HowTos
How to Specify Optional CPUs in RTI-MP .............................................................................. 162
Basics of Topological Subsets
Introduction In hardware‑in‑the‑loop (HIL) simulations, you can test virtually any number of
electronic control units (ECUs) under realistic conditions with HIL test benches
based on dSPACE simulator.
dSPACE
Simulator
ECU ECU ECU
Testing networked ECUs In many cases, it is desirable to first test each ECU separately with different
dSPACE simulators. However, the overall function of many ECUs can be tested
only when networked.
You can also setup a multiprocessor system from the different dSPACE simulators
and perform integration tests of the networked ECUs. Each dSPACE simulator is
connected to a master unit, which performs the simulation control and allows
the different ECUs to be switched easily.
Possible multiprocessor system setup The following illustration shows a

possible setup of this multiprocessor system. Since RTI‑MP and ControlDesk allow
optional CPUs and topological subsets, this setup can be used for putting ECUs
connected to the dSPACE simulators into operation step‑by‑step.
160
Master unit
DS1005 DS1005 DS1005
Simulation Simulation Simulation

of ECU 1 of ECU 2 of ECU 3
Host PC
dSPACE
dSPACE Simulator
dSPACE Simulator (I/O unit)
Simulator (I/O unit)
(I/O unit)
Gigalink connection
Link Board connection
ECU ECU ECU
CAN connection 1 2 3
Components of the multiprocessor system setup In this topology, the

multiprocessor system consists of the following components:
§ Host PC, used to
§ build the real‑time application and download it to the multiprocessor
system. Since no dSPACE hardware needs to be connected to the host PC
during the build process, you may also use another PC for the build: see
How to Create an Application Without a Connected dSPACE System ( RTI
and RTI-MP Implementation Guide).
§ control and monitor ControlDesk experiments and scripts running on the
connected multiprocessor system.
§ Master unit, containing one or more DS1005 boards.
§ The master unit performs the communication to the connected dSPACE
simulators (I/O units) via Gigalinks.
§ If one or more I/O units are currently disconnected, the master unit can
perform the model calculation for the corresponding I/O submodel(s).
During operation, the master unit must not be turned off.
§ dSPACE simulators (I/O units), each containing one DS1005. They perform the
communication between the connected ECUs and the master unit. Each of the
I/O units may be turned on/off individually.
§ ECU 1 … 3. These ECUs are connected to the dSPACE hardware via CAN.
§ Simulation of ECU 1 … 3. If one or more I/O units are currently disconnected
from the master unit, the signals coming from the connected ECU can be
calculated in (simplified) subsystems running on the DS1005 boards of the
master unit.
161
How to Specify Optional CPUs in RTI-MP
Objective For DS1005‑based multiprocessor systems, RTI‑MP allows you to specify certain
DS1005 boards as optional. This is possible for boards that do not forward
simulation control information to further DS1005 boards. For example, only the
CPUs "SLAVE_B", "SLAVE_C" and "SLAVE_D" can be specified as optional in
the multiprocessor system displayed below. The CPU "SLAVE" cannot be
specified as optional since it provides simulation control information to
"SLAVE_C".
DS1005
(SLAVE_B )
DS1005 DS1005 DS1005

(MASTER) (SLAVE) (SLAVE_C )
DS1005
(SLAVE_D )
Tip
Since each DS1005 can be connected to up to four different DS1005

boards, one free Gigalink remains on the "MASTER" of the multiprocessor
system displayed above. If you connect the "MASTER" directly to
"SLAVE_C", the DS1005 named "SLAVE" can also be removed from this
topology.
The following instructions apply to the corresponding RTI‑MP model.
Method To specify CPUs as optional

1 In the Multiprocessor Setup dialog, mark the Treat as optional CPU
checkbox on the CPU's page of the corresponding DS1005. By default, all the
DS1005 are specified as non-optional.
Note
Only end nodes can be specified as optional. The MASTER cannot be

specified as optional.
Next steps § After you specify all the Gigalink connections in the Multiprocessor
Topology Setup dialog, you can build the real‑time application for the entire
multiprocessor system. Refer to Multiprocessor Topology Setup Dialog ( RTI
and RTI-MP Implementation Reference) and Building and Downloading the
Model ( RTI and RTI-MP Implementation Guide).
162
Note
The interprocessor communication between different CPUs is established

via IPC blocks. During a running real‑time application, all the inputs from
unconnected CPUs are 0. In some cases, however, it is necessary to
provide more meaningful values, for example, by simulating the
application of optional CPUs. You should implement this simulation on a
non‑optional CPU.
§ You can use ControlDesk to change the topological subset on which you want
to download the real‑time application. For instructions, refer to Working with
Multiprocessor Systems with Optional Processors ( ControlDesk Platform
Management).
The Variable Browser of ControlDesk displays only the variables that belong to
enabled CPUs.
You can recognize data connections between variables that belong to disabled
CPUs and instruments by the no-value view.
Basics of Topological Subsets ................................................................................................ 160
163
164
Application Start
Application Start
Introduction After power‑up, the DS1005 boots automatically and the RTP executes the boot
firmware located in the on‑board flash memory.
There are two ways to run an application.
Boot Firmware ..................................................................................... 166

After power‑up the DS1005 boots from the flash memory, which holds
the pre‑installed boot firmware.
Running an Application from the Global Memory ................................ 166

In general, you download the application from the host PC to the
DS1005’s global memory. After the download, the application is started.
Running an Application from the Flash Memory ................................... 167

If you want an application to be started automatically after power‑up,
you have to load it to the DS1005’s flash memory.
Autobooting Real-Time Applications on dSPACE Hardware .................. 168

Some dSPACE real-time systems support autobooting a real-time
application. Autobooting allows you to use such a system as a stand-
alone system without a connection to the host PC.
Handling Real-Time Applications with ControlDesk ( First

Work Steps with a dSPACE System)
Learn how to handle applications on real-time processors (RTP).
165
Application Start
Boot Firmware
Introduction After power‑up the DS1005 boots from the flash memory, which holds the
pre‑installed boot firmware.
Characteristics of the boot The boot firmware carries out the following steps:
firmware § It determines the I/O boards connected to the DS1005's PHS bus.
§ It determines whether a user‑specific application exists in the global memory
or the flash memory. If this is the case, the application is started. An
application in the global memory takes precedence over an application in the
flash memory.
§ If neither the global nor the flash memory contains an application, the boot
firmware collects information about the connected DS1005 boards. This
information is passed to the Platform/Device Manager of ControlDesk,
which displays the multiprocessor system topology.
Note
If you switch off the DS1005, the contents of the global memory will be
lost. If you download/reload an application, the previous contents of the
global memory will be overwritten.
Running an Application from the Global Memory
Introduction In general, you download the application from the host PC to the DS1005’s
global memory. After the download, the application is started. This is the default
behavior for both the dSPACE experiment software and RTI.
To stop and restart the application you have to reload it again, for example, via
ControlDesk's Real-Time Application - Reload command.
Note
If you switch off the simulator, the contents of the global memory will be
lost. If you download/reload an application, the previous contents of the
global memory will be overwritten.
For information on handling real-time applications, refer to Handling Real-Time

Applications with ControlDesk ( First Work Steps with a dSPACE System).
166
Running an Application from the Flash Memory
Real-Time Application - Reload ( ControlDesk Platform Management)
Running an Application from the Flash Memory
Introduction If you want an application to be started automatically after power‑up, you have
to load it to the DS1005’s flash memory. This is possible via RTI, RTI‑MP and the
dSPACE experiment software. Autobooting allows you to use DS1005 as a stand-
alone system without a connection to the host PC.
Basics You can use up to 15 MByte of the flash memory for your application. After the
download has finished, the application will be copied to the global memory,
overwriting any existing application, and started automatically.
Whenever you switch on the DS1005, the boot firmware will copy the
application from the flash memory to the global memory and start it afterwards,
regardless of whether the board is connected to the host PC or not.
You can stop and restart the application by resetting the DS1005, for example,
by switching off the power and turning it on again. If you use the dSPACE
experiment software to stop and reload the application, it will first be reloaded
from the host PC to the flash memory, and then from the flash memory to the
global memory. Then the application will be started.
You can clear an application from the flash memory via the dSPACE experiment
software. Flash operations can be very time consuming: clearing or
reprogramming usually takes longer than 45 seconds.
Note
If you switch off the DS1005, the contents of the global memory will be
lost. If you switch on the power again, the contents of the flash memory
will be copied to the global memory and started.
For information on the flash memory’s characteristics, refer to Memory

on page 25.
For information on handling real-time application using ControlDesk, refer to

Handling Real-Time Applications with ControlDesk ( First Work Steps with a
dSPACE System).
167
Application Start
Autobooting Real-Time Applications on dSPACE Hardware
Introduction Some dSPACE real-time systems support autobooting a real-time application.

Autobooting allows you to use such a system as a stand-alone system without a
connection to the host PC.
Basics on autobooting You can enable dSPACE hardware to start an application from flash memory or
dSPACE hardware from a USB mass storage device, for example. On power-up or restart of the
hardware, this application is automatically downloaded to the hardware and
started on it.
After a real-time application autoboots on dSPACE hardware, you can connect

ControlDesk to the hardware. ControlDesk then detects the running real-time
application. ControlDesk therefore does not unload the application when online
calibration is started.
168
Power Supply Unit
Power Supply Unit
Introduction To simulate the battery voltage, dSPACE Simulator Mid-Size is equipped with a
remote-controlled power supply unit.
Characteristics and I/O Mapping of the Power Supply Unit ................... 169
To generate the battery voltage, dSPACE Simulator Mid-Size is equipped
with a remote-controlled power supply unit.
Controlling the Battery Voltage ............................................................ 171

The battery voltage is controlled remotely by dSPACE Simulator Mid‑Size.
Example of Controlling the Battery Voltage .......................................... 172

The example shows how you can control the battery voltage manually
with the voltage knob or automatically within the real-time application.
Controlling the High Rails .................................................................... 173

Three high rails are connected to relays, so they can be switched on or
off.
How to Control the High Rails ............................................................. 174

The high rails can be controlled by the ECU or by the simulator.
Characteristics and I/O Mapping of the Power Supply Unit
Introduction To generate the battery voltage, dSPACE Simulator Mid-Size is equipped with a
remote-controlled power supply unit. It contains a switched-mode power supply
with four high rails (one direct high rail and three switchable high rails).
169
Power Supply Unit
Characteristics The switched-mode power supply has the following characteristics:

§ Output voltage
§ 0 … 20 V DC
§ Controlled by the real-time system. For more information, refer to
Controlling the Battery Voltage on page 171
§ Output current
§ 50 A maximum
§ Measured by the DS2210 HIL I/O Board
§ Current limit knob
Characteristics of the high rails

§ One direct high rail
§ Three switchable high rails. For more information on switching the high rails,
refer to Controlling the High Rails on page 173
§ Each high rail has a maximum current of 16 A RMS (total 50 A RMS)
§ Each high rail is protected by self-resetting fuses
Note
The real-time system controls the output voltage. The necessary parameters
are measured or set via the channels ADC14, ADC15, ADC16 and DAC12.
Therefore, these channels are reserved and cannot be used for interfacing to
the ECU.
I/O mapping The following table shows the mapping of the power supply input and output
related to the I/O pins of the ECU 2 connector:
Signal ECU 2 Connector Description

Pin
VBAT X, AE Direct high rail output
VSW1 Y, AF Switchable high rail 1 output
VSW2 Z, AH Switchable high rail 2 output
VSW3 AA, AJ Switchable high rail 3 output
GNDBAT AB, AC, AD, AK, AL Ground
SWREL1- R Control switchable high rail 1
SWREL1+ S Control switchable high rail 1
SWREL2- T Control switchable high rail 2
SWREL2+ U Control switchable high rail 2
SWREL3- V Control switchable high rail 3
SWREL3+ W Control switchable high rail 3
170
Controlling the Battery Voltage
Controlling the Battery Voltage
Introduction The battery voltage is controlled remotely by dSPACE Simulator Mid‑Size. The
battery voltage can be varied from 0 V… 20 V. This range is large enough to
simulate all battery voltages that can occur in a typical passenger car.
Example The following table shows some examples of battery voltages.
For testing … Set the battery voltage to …

undervoltage under 9 V
engine cranking 8 V … 11 V
engine running 13.8 V … 14 V
overvoltage over 17 V
Controlling the voltage The following illustration shows how the battery voltage is controlled via
simulator.
ADC 15
+ Current
R Shunt limit
knob
ADC 16 Power Supply
Voltage
ADC 14
knob
-
DAC 12
The following table provides information about signals and their functions.
Signal Function
DAC12 To set the set value of the battery voltage.
ADC14 To read the position of the voltage knob.
ADC15 To measure the current.
ADC16 To measure the actual value of the battery voltage.
171
Power Supply Unit
Power Supply Unit ................................................................................................................ 169
Examples
Example of Controlling the Battery Voltage ........................................................................... 172
References
Characteristics and I/O Mapping of the Power Supply Unit .................................................... 169
Example of Controlling the Battery Voltage
Introduction This example shows how you can control the battery voltage manually with the
voltage knob or automatically within the real-time application. If you program
your real-time application in C, use the related C functions.
Note
Take care when controlling the output voltage. It is possible to set the
output voltage up to 20 V.
The following illustration shows a Simulink model for controlling the battery
voltage. Using this model, you can control the battery voltage manually with the
voltage knob or set the battery voltage via the model parameter VBat. The
select signal switches from manual control to “model” control.
Control from within the To control the battery voltage within the real‑time application, channel 12 of the
real‑time application DS2210DAC_Bx_C12 block is connected to a signal representing the set value.
Method 1 To control the battery voltage within the real-time application

1 Set the select signal of the model to 1.
2 Set the VBat signal of the model to the battery voltage.
172
Controlling the High Rails
Control manually To control the battery voltage manually, the voltage knob is integrated into the
real‑time application. The position of the manual voltage knob is read and the
analog output is set accordingly.
Method 2 To control the battery voltage manually

1 Set the select signal of the model to 0.
2 Turn the voltage knob to set the battery voltage.
References
Controlling the Battery Voltage ............................................................................................. 171
Controlling the High Rails
High rails Three high rails are connected to relays, so they can be switched on or off. The
following illustration shows the principle schematics of the power supply unit.
ECU 2 connector
Pin:
Multifuse
VBAT X, AE
VSW1 Y, AF
VSW2 Z, AH
VSW3 AA, AJ
Relay
SWREL1– R
Power supply SWREL1+ S
SWREL2– T
SWREL2+ U
SWREL3– V
SWREL3+ W
GNDBAT AB, AC, AD,

AK, AL
173
Power Supply Unit
Description All the high rails and the control lines for the switchable high rails are connected
to the ECU 2 connector (see the I/O mapping in Power Supply Unit on page 169
or the pin labeling given in the illustration above). The control lines are
differential inputs, which are connected to the relays. The relays switch on at a
voltage above 8 V. You can control the rails with the ECU or with the simulator,
see below.
HowTos
How to Control the High Rails .............................................................................................. 174
References
How to Control the High Rails
Possible methods The high rails can be controlled by the ECU or by the simulator.
§ To control the high rails by the ECU, refer to Method 1
§ If you want to control a switchable high rail with the simulator, for example, to
simulate the ignition key, use a digital output block in your application. Refer
to Method 2
Method 1 To control a high rail with the ECU

1 Connect the ECU outputs which control the high rail to the corresponding
pins SWRELx+ and SWRELx-.
For more information, refer to Configuring the Hardware ( dSPACE
Simulator Mid-Size Hardware Installation and Configuration).
Method 2 To control a high rail with the simulator

1 In the real-time application place a DS2210BIT_OUT_Bx_Cy block into your
real‑time application, and select an unused channel.
2 Connect the block input to the signal which controls the high rail.
In addition two bridges have to be installed in the ECU connectors:
174
How to Control the High Rails
3 Install a bridge between the output signal of the block (pin at the ECU 1
connector) and the SWRELx+ pin at the ECU 2 connector.
4 Install a bridge between a ground pin and the SWRELx- pin at the ECU 2
connector.
Controlling the High Rails ..................................................................................................... 173
175
Power Supply Unit
176
Load Simulation
Load Simulation
Load Simulation With the dSPACE Simulator Mid-Size .......................... 177

ECUs monitor the current of the actuators, for example, to ensure that
they work properly. Therefore, in a hardware‑in‑the‑loop simulation loads
must be connected to ECU outputs to obtain the necessary current.
Failure Simulation ................................................................................ 181

Using the Failure Insertion Units, you can simulate failures in the wiring
of an ECU.
Load Simulation With the dSPACE Simulator Mid-Size
Introduction ECUs monitor the current of the actuators, for example, to ensure that they work
properly. Therefore, in a hardware‑in‑the‑loop simulation loads must be
connected to ECU outputs to obtain the necessary current.
In dSPACE Simulator Mid-Size, all the ECU’s outputs are connected to load cards,
which means you can integrate substitute loads, for example, resistive or
inductive loads. If substitute loads do not fulfill your load requirements, you can
connect real loads to the simulator instead.
Characteristics dSPACE Simulator Mid-Size has 5 load cards. Each load card supports:
§ 10 single-ended loads or
§ 5 double-ended loads by using two channels for each load or
§ A mixture of single-ended and double-ended loads
177
Load Simulation
§ Maximum load current of:

§ 8 A RMS per load,
§ 16 A RMS per load card,
§ 40 A total
§ Maximum continuous power dissipation 2 W per load
§ Connecting loads between one ECU output and ground or one of the high
rails (see Power Supply Unit on page 169)
§ Each load channel is connected to a Failure Insertion Unit (see Failure
Simulation on page 181)
§ Each load channel can be disconnected from the DS2210 via a jumper.
Example This example shows an installed single-ended load.
VBAT
VSW1
VSW2
VSW3
GND
Status LED
External
Load Connector VBAT GND
Load
From To
FIU DS2210
The load cards have front panels with status LEDs and external connectors.
§ Each load card has the following status LEDs.
§ 4 rows with yellow LEDs indicating the status of the high rails
§ 10 rows with red LEDs indicating the load states
178
Load Simulation With the dSPACE Simulator Mid-Size
§ Each load card has the following external connectors

§ to the ground and high rails
§ to external loads, for example, real loads
Status LEDs Load Connectors
Ground
VSW2 VSW2 VSW2 VSW2 VSW2
High VSW1 VSW1 VSW1 VSW1 VSW1
Rails VBAT VBAT VBAT VBAT VBAT
VSW3 VSW3 VSW3 VSW3 VSW3
ADC12 ADC11 ADC10 ADC9 ADC8
ADC7 ADC6 ADC5 ADC4 ADC3
ADC2 ADC1 DIN16 DIN15 DIN14
DIN13 DIN12 DIN11 DIN10 DIN9
DS2210 DIN8 DIN7 DIN6 DIN5 DIN4
Inputs DIN3 PWMIN8 PWMIN7 PWMIN6 PWMIN5
DIN2 PWMIN4 PWMIN3 PWMIN2 PWMIN1
DIN1 FUEL6 FUEL3 IGN6 IGN3
AUXIN2 FUEL5 FUEL2 IGN5 IGN2
AUXIN1 FUEL4 FUEL1 IGN4 IGN1
Load Card #1 Load Card #2 Load Card #3 Load Card #4 Load Card #5
179
Load Simulation
180
Failure Simulation
Failure Simulation
Introduction Using the Failure Insertion Units, you can simulate failures in the wiring of an
ECU.
Basics on Failure Simulation ................................................................. 181

Using the Failure Insertion Units, you can simulate failures in the wiring
of an ECU.
Failure Types ........................................................................................ 183

dSPACE Simulator Mid-Size can simulate three different failure types.
Simulating Failures at ECU Inputs ......................................................... 184

Normally, ECU inputs are not connected to a failure insertion unit but it is
possible to simulate failures at ECU inputs.
Load Simulation ................................................................................... 177

Some ECUs monitor the current of actuators. You can connect loads to
the ECU outputs to obtain the required current.
Basics on Failure Simulation
Introduction Using the Failure Insertion Units, you can simulate failures in the wiring of an
ECU. Three types of failure can be simulated:
§ ECU output is shorted to the battery voltage,
§ ECU output is shorted to ground,
§ Cable break in an ECU output.
181
Failure Simulation
Characteristics dSPACE Simulator Mid-Size has five Failure Insertion Units (FIU) that are directly
connected to load cards. Each FIU supports:
§ 10 FIU channels for 10 ECU outputs
§ Maximum load current of:
§ 8 A RMS per channel,
§ 16 A RMS per unit
§ Loads are disconnected during short circuit simulation
§ All channels individually overload-protected by self-resetting fuses
§ Controlled by one standard PC RS232 port
§ Independent FIU channels for multiple synchronized failure simulation
The FIUs are only connected to the ECU outputs. For information on how to
simulate a failure at an ECU input, refer to How to Generate Failures for an ECU
Input ( dSPACE Simulator Mid-Size Hardware Installation and Configuration).
Safety precautions for failure Failure simulation simulates electrical failures in the wiring of an ECU, for
simulation example, a short circuit of a signal to the battery voltage. To simulate the failures,
the wires are electrical connected to the failure potential. Note the following
points for failure simulation:
§ Currents can be higher than during normal operation.
§ High voltages can occur at pins where they are not expected.
§ If the circuit which is failure-simulated contains an inductance, a high voltage
can be induced (see Safety Precautions When Using Inductive Loads
( dSPACE Simulator Mid-Size Based on DS2211 Hardware Installation and
Configuration)).
§ Overvoltage pulses in relays can cause electric arcs at the contacts of the
relays. The electric arcs can weld the relay's contacts so that the contacts are
permanently short-circuited. A permanent short-circuit can cause further
damages, for example, overheating.
Failure simulation ControlDesk has an optional component for failure simulation. For information
on the component, refer to Overview of the Graphical User Interface in
ControlDesk ( ControlDesk Electrical Error Simulation via XIL API EESPort).
Load Simulation .................................................................................................................... 177
182
Failure Types
Failure Types
Introduction dSPACE Simulator Mid-Size can simulate three different failure types:
§ ECU output shorted to the battery voltage
§ ECU output shorted to ground
§ A cable break in an ECU output
The following illustration shows when no failure is simulated. This is the default
after power-up.
FIU Channel
VBAT
Multifuse
From To Load
ECU
GND
RS232 Control
Signal short to battery A pin is connected to the battery voltage. Thus, the signal of the corresponding
voltage ECU output is set to the level of the battery voltage. The following illustration
shows the wiring.
FIU Channel
VBAT
Multifuse
From To Load
ECU
GND
RS232 Control
When the pin is connected to the battery voltage, the load is disconnected
automatically. This avoids damages to the load, however, the ECU signal cannot
be measured at the load pins any more.
183
Failure Simulation
Signal short to ground A pin is connected to ground. Thus, the signal of the corresponding ECU output
is set to ground. The following illustration shows the wiring.
FIU Channel
VBAT
Multifuse
From To Load
ECU
GND
RS232 Control
When the pin is connected to ground, the load is disconnected automatically.

This avoids damages to the load, however, the ECU signal cannot be measured
at the load pins any more.
Cable break The connection from the ECU to the load is opened. Thus, the ECU cannot
actuate the corresponding actuator. No current flows through the ECU output.
The following illustration shows the wiring.
FIU Channel
VBAT
Multifuse
From To Load
ECU
GND
RS232 Control
Simulating Failures at ECU Inputs
Introduction Normally, ECU inputs are not connected to failure insertion units but it is possible
to simulate failures at ECU inputs.
Simulating failures Only the pins of the ECU 2 connector are connected to FIUs. As the ECU 2
connector is the connector for the ECU outputs, failures at the ECU outputs can
be simulated easily. The ECU inputs are connected to the ECU 1 connector,
184
Simulating Failures at ECU Inputs
which is not connected to an FIU. If you want to simulate failures at an ECU

input, you have two possibilities:
§ Simulate the failure within your model.
§ Connect the signal to the ECU 2 connector. For information on how to
connect a signal to the ECU 2 connector for failure simulation, refer to How to
Generate Failures for an ECU Input ( dSPACE Simulator Mid-Size Hardware
185
Failure Simulation
186
Diagnostics
Diagnostics
Introduction On the front of dSPACE Simulator Mid-Size is a CARB diagnostic connector that
can be used to connect an external tester.
Diagnostic Connector
Introduction The simulator has a CARB diagnostic connector that can be used to connect an
external tester.
CARB connector The CARB (California Air Resources Board) diagnostic connector is the standard
connector for the onboard diagnostic standard OBD II. The CARB diagnostic
connector is internally connected to the ECU 2 connector. When wiring the cable
harness, the ECU can be connected to the ECU 2 connector and consequently it
is also connected to the CARB connector. Additionally, the CARB connector
contains a connection to the CAN bus.
If your tester device requires the battery voltage, you can tap the battery voltage
at the Vbat jacks on the front of the simulator.
The following illustration shows the data flow from the ECU to an external tester
device via the ECU and CARB connectors and vice versa.
ECU 2
ECU
Connector
CARB Tester
Connector Device
CAN
187
Diagnostics
Note
According to the CARB standard the CAN bus is connected to the CARB
connector (pin 6 and pin 14). If the connected diagnostic device uses these
pins for other signals, the communication on the CAN bus is destroyed.
For information on the CARB connector pinouts, refer to CARB Connector Pinout
( dSPACE Simulator Mid-Size Hardware Installation and Configuration).
For more information on the onboard diagnostic, refer to the OBD II Homepage
at http://www.obdii.com.
Connecting the ECU ( dSPACE Simulator Mid-Size Hardware Installation and

Configuration)
188
Expandability
Expandability
Introduction If a standard dSPACE Simulator Mid-Size does not fulfill your requirements, it can
be expanded.
Processing Power Is Not Sufficient ........................................................ 190

The model is too large to run on the DS1005 processor board and it is
not possible to increment the sample rate.
Expanding the I/O Hardware ................................................................ 190

The engine to be simulated has 8, 10 or 12 cylinders but there are not
enough I/O channels.
Simulating a Specific Signal .................................................................. 191

A specific crankshaft signal or a signal with a wide frequency range must
be generated.
Setting Up a Multiprocessor System ( DS1005 Hardware

Installation and Configuration Guide)
A multiprocessor system is based on two or more processor boards.
Additional Signal Conditioning ( dSPACE Simulator Mid-Size

Hardware Installation and Configuration)
Setting Up and Installing Further I/O Boards ( dSPACE

Simulator Mid-Size Hardware Installation and Configuration)
189
Expandability
Processing Power Is Not Sufficient
Problem The model is too large to run on the DS1005 processor board and it is not
possible to increment the sample rate.
Solution Use an additional DS1005 processor board. DS1005 processor boards can be
linked together to a multiprocessor system (refer to DS1005 Multiprocessor
Systems on page 141). The number of additional DS1005 processor boards is
limited by the number of spare slots, which in turns depends on the number and
types of the I/O boards.
Expanding the I/O Hardware
Problem The engine to be simulated has 8, 10 or 12 cylinders but there are not enough
I/O channels.
Solution § Connect two DS2210 via the engine position bus so that the angular
processing units run synchronously. If not all of the Load/FIU channels of the
first DS2210 are used, the remaining channels can be used for the second
DS2210. If a second Load/FIU unit is necessary, it can be included.
§ If you simulate a diesel engine and ignition does not have to be captured, the
ignition channels can be used for measuring the additional injection.
Problem A few ECU pins are remaining, but the matching DS2210 channels are already in
use.
Solution Map those ECU pins to alternative DS2210 pins. For example,
§ use analog inputs instead of digital inputs and detect threshold crossing by the
model
§ use digital outputs instead of PWM outputs
§ use analog outputs instead of digital outputs (if the amplitude range matches
the requirements)
§ refer to the DS2210 RTLib Reference to see how the hardware can be
accessed.
190
Simulating a Specific Signal
Simulating a Specific Signal
Problem A special crankshaft signal simulation is required, which cannot be realized by

using waveform tables with the DS2210 crank signal output.
Solution Use the slave DSP on the DS2210, see Features Served by the Slave DSP
on page 95.
Problem A frequency signal with a wide frequency range and a constant frequency
resolution over the wide frequency range has to be generated.
Solution Use the slave DSP on the DSP2210, see Features Served by the Slave DSP
on page 95.
191
Expandability
192
I/O Mapping
I/O Mapping
Introduction The I/O Mapping describes the data flow between the real-time application
running on the processor board and the ECU.
ECU Connectors .................................................................................. 193

The ECU connectors connect the ECU to the I/O hardware of the
simulator.
I/O Mapping to the ECU 1 Connector .................................................. 194

Shows the mapping between the RTI blocks and the ECU 1 connector.
I/O Mapping to the ECU 2 Connector .................................................. 197

Shows the mapping between the RTI blocks and the ECU 2 connector.
ECU Connectors
Introduction The ECU connectors connect the ECU to the I/O hardware of the simulator.
193
I/O Mapping
Data flow The data flow between the real-time application running on the processor board
and the ECU is displayed in the following illustration.
Connector
ECU 1
Real-Time
Electronic
Processor
Control
and
Unit
I/O Hardware
Connector
ECU 2
Load Cards
FIU
The real-time application running on the processor board exchanges their input
and output data with the I/O hardware via special RTI blocks. The I/O hardware
for the simulator outputs is directly connected to the ECU 1 connector, which is
the connector for the ECU inputs. For the I/O mapping from the RTI blocks to the
ECU 1 connector, refer to I/O Mapping to the ECU 1 Connector on page 194.
The I/O hardware for the simulator inputs is connected to the ECU 2 connector
via the load boards and failure insertion units (FIU) respectively. ECU 2 is the
connector for the ECU outputs. For the I/O mapping from the RTI blocks to the
ECU 2 connector and the assignments of the load boards and FIU, refer to I/O
Mapping to the ECU 2 Connector on page 197.
I/O Mapping to the ECU 1 Connector
Introduction The following table shows the connection between the RTI blocks and the ECU 1
connector (ECU inputs). For a description of the signals and their voltage range
or output current, refer to ECU 1 Connector Pinout ( dSPACE Simulator Mid-
Size Hardware Installation and Configuration).
Signal RTI Block ECU 1 Connector Pin

ADC13 DS2210MUX_ADC_Bx (Channel 13) D
ADC13 DS2210MUX_ADC_Bx (Channel 13) E
CRANK- DS2210APU_CRANK_Bx CX
CRANK+ DS2210APU_CRANK_Bx CW
CAM1- DS2210APU_CAM_Bx_C1 CT
CAM1+ DS2210APU_CAM_Bx_C1 DB
CAM2- DS2210APU_CAM_Bx_C2 DA
CAM2+ DS2210APU_CAM_Bx_C2 CZ
DIGCAM1 DS2210APU_CAM_Bx_C1 BY
194

DIGCAM2 DS2210APU_CAM_Bx_C2 BZ
DIGCRANK DS2210APU_CRANK_Bx BP
CAN1H CC
CAN1L CD
CAN2H CF
CAN2L CH
DAC1 DS2210DAC_Bx_C1 C
DAC1 DS2210DAC_Bx_C1 B
DAC2 DS2210DAC_Bx_C2 H
DAC2 DS2210DAC_Bx_C2 F
DAC3 DS2210DAC_Bx_C3 K
DAC3 DS2210DAC_Bx_C3 J
DAC4 DS2210DAC_Bx_C4 M
DAC4 DS2210DAC_Bx_C4 L
DAC5 DS2210DAC_Bx_C5 P
DAC5 DS2210DAC_Bx_C5 N
DAC6 DS2210DAC_Bx_C6 S
DAC6 DS2210DAC_Bx_C6 R
DAC7 DS2210DAC_Bx_C7 U
DAC7 DS2210DAC_Bx_C7 T
DAC8 DS2210DAC_Bx_C8 W
DAC8 DS2210DAC_Bx_C8 V
DAC9 DS2210DAC_Bx_C9 Y
DAC9 DS2210DAC_Bx_C9 X
DAC10 DS2210DAC_Bx_C10 AA
DAC10 DS2210DAC_Bx_C10 Z
DAC11 DS2210DAC_Bx_C11 AC
DAC11 DS2210DAC_Bx_C11 AD
DIGOUT1 DS2210BIT_OUT_Bx_C1 AW
DIGOUT2 DS2210BIT_OUT_Bx_C2 AY
DIGOUT3 DS2210BIT_OUT_Bx_C3 AZ
DIGOUT4 DS2210BIT_OUT_Bx_C4 BA
DIGOUT5 DS2210BIT_OUT_Bx_C5 AX
DIGOUT6 DS2210BIT_OUT_Bx_C6 BC
DIGOUT7 DS2210BIT_OUT_Bx_C7 BD
DIGOUT8 DS2210BIT_OUT_Bx_C8 BE
DIGOUT9 DS2210BIT_OUT_Bx_C9 BB
DIGOUT10 DS2210BIT_OUT_Bx_C10 BH
DIGOUT11 DS2210BIT_OUT_Bx_C11 BJ
DIGOUT12 DS2210BIT_OUT_Bx_C12 BK
DIGOUT13 DS2210BIT_OUT_Bx_C13 BL
195
I/O Mapping

DIGOUT14 DS2210BIT_OUT_Bx_C14 BM
DIGOUT15 DS2210BIT_OUT_Bx_C15 BN
DIGOUT16 DS2210BIT_OUT_Bx_C16 BF
PWMOUT1 DS2210PWM_Bx_C1 BR
PWMOUT2 DS2210PWM_Bx_C2 BS
PWMOUT3 DS2210PWM_Bx_C3 BT
PWMOUT4 DS2210PWM_Bx_C4 BU
PWMOUT5 DS2210PWM_Bx_C5 BX
PWMOUT6 DS2210PWM_Bx_C6 BW
RES1- DS2210RES_Bx_C1 AH
RES1+ DS2210RES_Bx_C1 AF
RES2- DS2210RES_Bx_C2 AB
RES2+ DS2210RES_Bx_C2 AJ
RES3- DS2210RES_Bx_C3 AM
RES3+ DS2210RES_Bx_C3 AL
RES4- DS2210RES_Bx_C4 AP
RES4+ DS2210RES_Bx_C4 AN
RES5- DS2210RES_Bx_C5 AT
RES5+ DS2210RES_Bx_C5 AU
RES6- DS2210RES_Bx_C6 AR
RES6+ DS2210RES_Bx_C6 AK
RXD BV
RXD CE
TXD CB
TXD CA
WAVE0- DS2210SL_WSSG_Bx_C1 CL
WAVE0+ DS2210SL_WSSG_Bx_C1 CK
WAVE1- DS2210SL_WSSG_Bx_C2 CP
WAVE1+ DS2210SL_WSSG_Bx_C2 CN
WAVE2- DS2210SL_WSSG_Bx_C3 CV
WAVE2+ DS2210SL_WSSG_Bx_C3 CU
WAVE3- DS2210SL_WSSG_Bx_C4 CS
WAVE3+ DS2210SL_WSSG_Bx_C4 CR
ECU 1 Connector Pinout ( dSPACE Simulator Mid-Size Hardware Installation and

Configuration)
196
Introduction The following table shows the connection between the RTI blocks and the ECU 2
connector (ECU outputs). Additionally, the load board’s number and channel are
listed, which are connected to the ECU’s outputs. For a description of the signals
and their voltage range or output current, refer to ECU 2 Connector Pinout
( dSPACE Simulator Mid-Size Hardware Installation and Configuration).
Signal Block Load Board ECU 2

Connector
Pin
ADC1 DS2210MUX_ADC_Bx (Channel 1) 2 (Channel 3) CF
ADC2 DS2210MUX_ADC_Bx (Channel 2) 1 (Channel 3) CH
ADC3 DS2210MUX_ADC_Bx (Channel 3) 5 (Channel 2) CJ
ADC4 DS2210MUX_ADC_Bx (Channel 4) 4 (Channel 2) CK
ADC5 DS2210MUX_ADC_Bx (Channel 5) 3 (Channel 2) CL
ADC6 DS2210MUX_ADC_Bx (Channel 6) 2 (Channel 2) CM
ADC7 DS2210MUX_ADC_Bx (Channel 7) 1 (Channel 2) CN
ADC8 DS2210MUX_ADC_Bx (Channel 8) 5 (Channel 1) CP
ADC9 DS2210MUX_ADC_Bx (Channel 9) 4 (Channel 1) CR
ADC10 DS2210MUX_ADC_Bx (Channel 10) 3 (Channel 1) CS
ADC11 DS2210MUX_ADC_Bx (Channel 11) 2 (Channel 1) CT
ADC12 DS2210MUX_ADC_Bx (Channel 12) 1 (Channel 1) CU
AUXCAP1 DS2210APU_AUXCAP_Bx_C1 1 (Channel 10) CC
AUXCAP2 DS2210APU_AUXCAP_Bx_C2 1 (Channel 9) CD
DIGIN1 DS2210BIT_IN_Bx_C1 1 (Channel 8) AM
DIGIN2 DS2210BIT_IN_Bx_C2 1 (Channel 7) AN
DIGIN3 DS2210BIT_IN_Bx_C3 1 (Channel 6) AP
DIGIN4 DS2210BIT_IN_Bx_C4 5 (Channel 5) AR
DIGIN5 DS2210BIT_IN_Bx_C5 4 (Channel 5) AS
DIGIN6 DS2210BIT_IN_Bx_C6 3 (Channel 5) AT
DIGIN7 DS2210BIT_IN_Bx_C7 2 (Channel 5) AU
DIGIN8 DS2210BIT_IN_Bx_C8 1 (Channel 5) AV
DIGIN9 DS2210BIT_IN_Bx_C9 5 (Channel 4) AW
DIGIN10 DS2210BIT_IN_Bx_C10 4 (Channel 4) AX
DIGIN11 DS2210BIT_IN_Bx_C11 3 (Channel 4) AY
DIGIN12 DS2210BIT_IN_Bx_C12 2 (Channel 4) AZ
DIGIN13 DS2210BIT_IN_Bx_C13 1 (Channel 4) BA
DIGIN14 DS2210BIT_IN_Bx_C14 5 (Channel 3) BB
DIGIN15 DS2210BIT_IN_Bx_C15 4 (Channel 3) BC
DIGIN16 DS2210BIT_IN_Bx_C16 3 (Channel 3) BD
FUEL1 DS2210APU_INJ_Bx (Channel 1) 3 (Channel 10) BP
FUEL2 DS2210APU_INJ_Bx (Channel 2) 3 (Channel 9) BR
197
I/O Mapping
Signal Block Load Board ECU 2

Connector
Pin
FUEL3 DS2210APU_INJ_Bx (Channel 3) 3 (Channel 8) BS
FUEL4 DS2210APU_INJ_Bx (Channel 4) 2 (Channel 10) BT
FUEL5 DS2210APU_INJ_Bx (Channel 5) 2 (Channel 9) BU
FUEL6 DS2210APU_INJ_Bx (Channel 6) 2 (Channel 8) BV
IGN1 DS2210APU_IGN_Bx (Channel 1) 5 (Channel 10) BW
IGN2 DS2210APU_IGN_Bx (Channel 2) 5 (Channel 9) BX
IGN3 DS2210APU_IGN_Bx (Channel 3) 5 (Channel 8) BY
IGN4 DS2210APU_IGN_Bx (Channel 4) 4 (Channel 10) BZ
IGN5 DS2210APU_IGN_Bx (Channel 5) 4 (Channel 9) CA
IGN6 DS2210APU_IGN_Bx (Channel 6) 4 (Channel 8) CB
PWMIN1 DS2210PWM2D_Bx_C1 5 (Channel 7) BE
PWMIN2 DS2210PWM2D_Bx_C2 4 (Channel 7) BF
PWMIN3 DS2210PWM2D_Bx_C3 3 (Channel 7) BH
PWMIN4 DS2210PWM2D_Bx_C4 2 (Channel 7) BJ
PWMIN5 DS2210PWM2D_Bx_C5 5 (Channel 6) BK
PWMIN6 DS2210PWM2D_Bx_C6 4 (Channel 6) BL
PWMIN7 DS2210PWM2D_Bx_C7 3 (Channel 6) BM
PWMIN8 DS2210PWM2D_Bx_C8 2 (Channel 6) BN
ECU 2 Connector Pinout ( dSPACE Simulator Mid-Size Hardware Installation and

Configuration)
Load Card/FIU Pinout ( dSPACE Simulator Mid-Size Hardware Installation and
Configuration)
198
Limitations
Limitations
Introduction There are some limitations you have to take into account when working with
dSPACE Simulator Mid-Size.
Quantization Effects ............................................................................ 200

Quantization effects occur in signal generation or measurement.
DS2210 Board Revision ........................................................................ 201

Some features are only available for DS2210 boards with higher board
revision.
Conflicting I/O Features ....................................................................... 201

There are I/O features that share the same board resources.
Limited Number of CAN Messages ...................................................... 210

When you implement CAN communication with RTI CAN Blockset or
with RTLib's CAN access functions, the number of CAN messages in an
application is limited.
Limitations with RTICANMM ................................................................ 212

There are a number of general limitations with RTICANMM.
Limitations with J1939-Support ........................................................... 214

There are a number of limitations regarding the J1939 support of
RTICANMM.
199
Limitations
Quantization Effects
Introduction Signal generation and measurement are only feasible within the limits of the
resolution of the timing I/O unit. The limited resolution causes quantization errors
that increase with increasing frequencies.
When performing square‑wave signal generation (D2F), for example, you will
encounter considerable deviations between the desired frequency and the
generated frequency, especially for higher frequencies. The (quantized)
generated signal frequencies can be calculated according to the following
equation:
f = 1/(n · R)
where R is the resolution (in s), and n is a positive integer.
Example For example, if you select range 16 (0.3 mHz ... 305.17 Hz) and 130 Hz is
specified as the desired frequency for D2F, a frequency of 152.59 Hz is actually
generated.
The following illustration shows the increasing quantization effects for increasing
desired frequencies:
Generated frequency
Desired frequency
You should therefore select the range with the best possible resolution.
200
DS2210 Board Revision
DS2210 Board Revision
Introduction Several features are supported only for DS2210 boards with specific revisions and
higher, for example, if you want to use the ignition capture unit for injection
capture. The following boards are extended in functionality:
§ DS2210 boards with board revision 4 or higher.
§ DS2210 boards with board revision 3 and FPGA revision 3 or higher (FPGA =
field programmable gate array).
Revision numbers The revision numbers are displayed with the following syntax: <board>.
0.<FPGA>.
3.0.3 means you have a DS2210 board with the revision 3 and a FPGA revision
number of 3 installed.
The revision number is printed on the board. You can also read out the number
with ControlDesk, refer to Board Details Properties ( ControlDesk Platform
Management).
Conflicting I/O Features
Types of I/O conflicts There are I/O features that share the same board resources.
Conflicts concerning single I/O channels There are conflicts that concern
single channels of an I/O feature. The dSPACE board provides only a limited
number of I/O pins. The same pins can be shared by different I/O features.
However, a pin can serve as the I/O channel for only one feature at a time.
Conflicts concerning an I/O feature as a whole There are conflicts that

concern the use of an I/O feature as a whole. Suppose two I/O features of the
dSPACE board use the same on‑board timer device. In this case, only one of the
two I/O features can be used at a time. The other feature is completely blocked.
Conflicts concerning signal inputs If an I/O pin of a signal input is shared,

this pin can serve more than one feature at a time. For example, you can use a
DIG_INx pin to get the status of a signal and to measure the duty cycle or period.
Conflicts for the DS2210 The following tables list the I/O features of the DS2210 that conflict with other
I/O features, and the related RTI blocks/RTLib functions.
§ Conflicts for the sensor and actuator interface
§ Conflicts for PWM Signal Generation on page 202
§ Conflicts for Square‑Wave Signal Generation (D2F) on page 202
§ Conflicts for PWM Signal Measurement (PWM2D) on page 203
201
Limitations
§ Conflicts for Square‑Wave Signal Measurement (F2D) on page 203

§ Conflicts for Wheel Speed Sensor Simulation on page 204
§ Conflicts for the angular processing unit (APU)
§ Conflicts for Spark Event Capture (Last Event Window Read) on page 205
§ Conflicts for Spark Event Capture (Last Event Window Read) on page 205
§ Conflicts for Injection Pulse Position and Fuel Amount Measurement (Last
Event Window Read) on page 208
§ Conflicts for Injection Pulse Position and Fuel Amount Measurement
(Continuous Read) on page 209
§ Conflicts for Knock Sensor Simulation on page 205
§ Conflicts for the serial interface
§ Conflicts for the Serial Interface on page 210
Conflicts for PWM Signal The following I/O features of the DS2210 conflict with PWM signal generation
Generation provided by the sensor and actuator interface:
PWM Signal Generation *) Signal Conflicting I/O Feature **)

Ch (RTI) Ch (RTLib) Ch (RTI) Ch (RTLib)
Conflicts Concerning Single Channels

Ch 1 Ch 1 PWM_OUT1 Square‑wave signal generation (D2F) Ch 1 Ch 1
*) Related RTI blocks and RTLib **) Related RTI blocks and RTLib functions:
functions: § DS2210D2F_Bx_Cy
§ DS2210PWM_Bx_Cy § Square-Wave Signal Generation ( DS2210 RTLib Reference)
§ PWM Signal Generation ( DS2210
RTLib Reference)
Conflicts for Square‑Wave The following I/O features of the DS2210 conflict with square‑wave signal
Signal Generation (D2F) generation provided by the sensor and actuator interface:
Square‑Wave Signal Generation *) Signal Conflicting I/O Feature **)


Ch 1 Ch 1 PWM_OUT1 PWM signal generation Ch 1 Ch 1
202
Square‑Wave Signal Generation *) Signal Conflicting I/O Feature **)

functions: § DS2210PWM_Bx_Cy
§ DS2210D2F_Bx_Cy § PWM Signal Generation ( DS2210 RTLib Reference)
§ Square-Wave Signal Generation
( DS2210 RTLib Reference)
Conflicts for PWM Signal The following I/O features of the DS2210 conflict with PWM signal measurement
Measurement (PWM2D) provided by the sensor and actuator interface:
PWM Signal Measurement *) Signal Conflicting I/O Feature **)


Ch 1 Ch 1 PWM_IN1 Square‑wave signal measurement (F2D) Ch 1 Ch 1
(INJ7) Injection pulse position and fuel Group 1, ch 7 Group 1, ch 7
amount measurement
amount measurement
functions: § Square‑wave signal measurement (F2D):
§ DS2210PWM2D_Bx_Cy § DS2210F2D_Bx_Cy
§ PWM Signal Measurement § Frequency Measurement ( DS2210 RTLib Reference)
( DS2210 RTLib Reference) § Injection pulse position and fuel amount measurement:
§ DS2210APU_INJ_Bx_Gy
DS2210APU_INJCONT_Bx_Gy
§ Injection Pulse Position and Fuel Amount Measurement ( DS2210
RTLib Reference)
Conflicts for Square‑Wave The following I/O features of the DS2210 conflict with square‑wave signal
Signal Measurement (F2D) measurement provided by the sensor and actuator interface:
Square‑Wave Signal Signal Conflicting I/O Feature **)

Measurement *)

Ch 1 Ch 1 PWM_IN1 PWM signal measurement (PWM2D) Ch 1 Ch 1
203
Limitations
Square‑Wave Signal Signal Conflicting I/O Feature **)

Measurement *)
amount measurement
amount measurement
functions: § PWM signal measurement (PWM2D)
§ DS2210F2D_Bx_Cy § DS2210PWM2D_Bx_Cy
§ Frequency Measurement ( DS2210 § PWM Signal Measurement ( DS2210 RTLib Reference)
RTLib Reference) § Injection Pulse Position and Fuel Amount Measurement:
DS2210APU_INJCONT_Bx_Gy
RTLib Reference)
Conflicts for Wheel Speed The following I/O features of the DS2210 conflict with wheel speed sensor
Sensor Simulation simulation provided by the sensor and actuator interface:
Wheel Speed Sensor Simulation *) Signal Conflicting I/O Feature **)

Conflicts Concerning Wheel Speed Sensor Simulation as a Whole

If you perform wheel speed sensor simulation, you cannot perform knock sensor simulation at the same time.
functions: § DS2210SL_KNSG_Bx_Cy
§ DS2210SL_WSSG_Bx_Cy § Knock Sensor Simulation ( DS2210 RTLib Reference)
§ Wheel Speed Sensor Simulation
204
Conflicts for Knock Sensor The following I/O features of the DS2210 conflict with knock sensor simulation
Simulation provided by the angular processing unit:
Knock Sensor Simulation *) Signal Conflicting I/O Feature **)

Conflicts Concerning Knock Sensor Simulation as a Whole

If you perform knock sensor simulation, you cannot perform wheel speed sensor simulation at the same time.
functions: § DS2210SL_WSSG_Bx_Cy
§ DS2210SL_KNSG_Bx_Cy § Wheel Speed Sensor Simulation ( DS2210 RTLib Reference)
§ Knock Sensor Simulation
Conflicts for Spark Event The following I/O features of the DS2210 conflict with spark event capture
Capture (Last Event Window provided by the angular processing unit:
Read)
Spark Event Capture Signal Conflicting I/O Feature **)

(Last Event Window Read) *)
Conflicts Concerning Blocks/Functions for All Channels

All channels All channels IGN1 … 6, § Spark event capture (continuous § All channels
AUXCAP1, read)
AUXCAP2 § Injection pulse position and fuel § Group 2 § Ch 1 … 8
amount measurement (last event (all channels) (all
window and continuous read) channels)
§ Spark event capture, auxiliary input § Aux. ch 1/
(continuous read) Aux. ch 2
Ch 7 Ch 7 AUXCAP1 Spark event capture, auxiliary input Aux. ch 1
(continuous read)
Ch 8 Ch 8 AUXCAP2 Spark event capture, auxiliary input Aux. ch 2
(continuous read)
functions: § Spark event capture (continuous read):
§ DS2210APU_IGN_Bx § DS2210APU_IGNCONT_Bx
§ Spark Event Capture ( DS2210 § Injection pulse position and fuel amount measurement (last event window
RTLib Reference) and continuous read):
DS2210APU_INJCONT_Bx_Gy(group 2)
RTLib Reference)
§ Spark event capture, auxiliary input (continuous read):
§ DS2210APU_AUXCAPCONT_Bx_Cy
205
Limitations

Conflicts Concerning Blocks/Functions for Auxiliary Inputs Only

Aux. ch 1 Aux. ch 1 AUXCAP1 § Spark event capture § All channels
(continuous read)
§ Injection pulse position and fuel § Group 2 § Ch 1 … 8
amount measurement (continuous (all channels) (all
read) channels)
§ Spark event capture (last event § Ch 7
window read)
§ Injection pulse position and fuel § Group 2, § Ch 7
amount measurement (last event ch 7
window read)
Aux. ch 2 Aux. ch 2 AUXCAP2 § Spark event capture § All channels
(continuous read)
§ Injection pulse position and fuel § Group 2 § Ch 1 … 8
amount measurement (continuous (all channels) (all
read) channels)
§ Spark event capture (last event § Ch 8
window read)
§ Injection pulse position and fuel § Group 2, § Ch 8
amount measurement (last event ch 8
window read)
functions: § Spark event capture (continuous read):
§ DS2210APU_AUXCAP_Bx_Cy § DS2210APU_IGNCONT_Bx
§ Spark Event Capture ( DS2210 § Spark event capture, auxiliary input (continuous read):
RTLib Reference) § DS2210APU_AUXCAPCONT_Bx_Cy
§ Injection pulse position and fuel amount measurement (continuous read):
§ DS2210APU_INJCONT_Bx_Gy(group 2)
RTLib Reference)
§ Spark event capture (last event window read):
§ DS2210APU_IGN_Bx
§ Injection pulse position and fuel amount measurement (last event
window read):
RTLib Reference)
206
Conflicts for Spark Event The following I/O features of the DS2210 conflict with spark event capture
Capture (Continuous Read) provided by the angular processing unit:

(Continuous Read) *)
Conflicts Concerning Blocks/Functions for All Channels

All channels All channels IGN1 … 6, § Spark event capture (last event § All channels
AUXCAP1, window read)
AUXCAP2 § Injection pulse position and fuel § Group 2 § Ch 1 … 8
amount measurement (last event (all channels) (all channels)
window and continuous read)
(last event window read) Aux. ch 2
Ch 7 Ch 7 AUXCAP1 Spark event capture, auxiliary input (last Aux. ch 1
event window read)
Ch 8 Ch 8 AUXCAP2 Spark event capture, auxiliary input (last Aux. ch 2
event window read)
functions: § Spark event capture (last event window read):
§ DS2210APU_IGNCONT_Bx § DS2210APU_IGN_Bx
§ Spark Event Capture § Injection pulse position and fuel amount measurement (last event window
( DS2210 RTLib Reference) and continuous read):
RTLib Reference)
§ Spark event capture, auxiliary input (last event window read):
§ DS2210APU_AUXCAP_Bx_Cy
Conflicts Concerning Blocks/Functions for Auxiliary Inputs Only

Aux. ch 1 Aux. ch 1 AUXCAP1 § Spark event capture (last event § All channels
window read)
§ Spark event capture § Ch 7
(continuous read)
§ Injection pulse position and fuel § Ch 7 § Ch 7
amount measurement (last event
Aux. ch 2 Aux. ch 2 AUXCAP2 § Spark event capture (last event § All channels
window read)
§ Spark event capture § Ch 8
(continuous read)
§ Injection pulse position and fuel § Ch 8 § Ch 8
amount measurement (last event
207
Limitations

functions: § Spark event capture (last event window read):
§ DS2210APU_AUXCAPCONT_B § DS2210APU_IGN_Bx
x_Cy § Spark event capture, auxiliary input (last event window read):
§ Spark Event Capture § DS2210APU_AUXCAP_Bx_Cy
( DS2210 RTLib Reference) § Spark event capture (continuous read):
§ DS2210APU_IGNCONT_Bx
§ Injection pulse position and fuel amount measurement (last event
window and continuous read):
RTLib Reference)
Conflicts for Injection Pulse The following I/O features of the DS2210 conflict with injection pulse position
Position and Fuel Amount and fuel amount measurement provided by the angular processing unit:
Measurement (Last Event
Window Read)
Injection Pulse Position and Signal Conflicting I/O Feature **)

Fuel Amount Measurement
Group (RTI) Ch (RTLib) Group (RTI) Ch (RTLib)
Conflicts Concerning Group 1

Group 1 Ch 1 … 8 INJ1 … 8 Injection pulse position and fuel Group 1
(all channels) (all channels) amount measurement (continuous read) (all channels)
Group 1, Ch 7 INJ7 Square‑wave signal measurement (F2D)/ Ch 7 Ch 7
ch 7 PWM signal measurement (PWM2D)
functions: § Injection pulse position and fuel amount measurement (continuous read)
§ DS2210APU_INJ_Bx_Gy(group § DS2210APU_INJCONT_Bx_Gy(group 1)
1) § PWM2D/F2D:
§ Injection Pulse Position and § DS2210PWM2D_Bx_Cy
Fuel Amount Measurement DS2210F2D_Bx_Cy
( DS2210 RTLib Reference) § PWM Signal Measurement ( DS2210 RTLib Reference)
Frequency Measurement ( DS2210 RTLib Reference)

Group 2 Ch 1 … 8 IGN1 … 6, § Spark event capture (last event § All channels § All channels
(all channels) (all channels) AUXCAP1, window and continuous read)
AUXCAP2 § Injection pulse position and fuel § Group 2
amount measurement (all channels)
(continuous read)
208

Group 2, Ch 7 AUXCAP1 Spark event capture, auxiliary input (last Aux. ch 1 Aux. ch 1
ch 7 event window and continuous read)
functions: § Spark event capture (last event window and continuous read):
§ DS2210APU_INJ_Bx_Gy(group § DS2210APU_IGN_Bx
2) DS2210APU_IGNCONT_Bx
§ Injection Pulse Position and § Spark Event Capture ( DS2210 RTLib Reference)
Fuel Amount Measurement § Injection pulse position and fuel amount measurement (continuous read):
( DS2210 RTLib Reference) § DS2210APU_INJCONT_Bx_Gy(group 2)
§ Spark event capture, auxiliary input (last event window and continuous
read):
DS2210APU_AUXCAPCONT_Bx_Cy
§ Spark Event Capture ( DS2210 RTLib Reference)
Conflicts for Injection Pulse The following I/O features of the DS2210 conflict with injection pulse position
Position and Fuel Amount and fuel amount measurement provided by the angular processing unit:
Measurement (Continuous
Read)


Group 1 Ch 1 … 8 INJ1 … 8 Injection pulse position and fuel Group 1
(all channels) (all channels) amount measurement (last event (all channels)
window read)
functions: § Injection pulse position and fuel amount measurement (last event window
§ DS2210APU_INJCONT_Bx_Gy(g read):
roup 1) § DS2210APU_INJ_Bx_Gy(group 1)
§ Injection Pulse Position and Fuel § PWM2D/F2D:
Amount Measurement § DS2210PWM2D_Bx_Cy
( DS2210 RTLib Reference) DS2210F2D_Bx_Cy
§ PWM Signal Measurement ( DS2210 RTLib Reference)
Frequency Measurement ( DS2210 RTLib Reference)
209
Limitations


Group 2 Ch 1 … 8 IGN1 … 6, § Spark event capture (last event § All channels § All channels
(all channels) (all channels) AUXCAP1, window and continuous read)
AUXCAP2 § Injection pulse position and fuel § Group 2
amount measurement (last event (all channels)
window read)
functions: § Spark event capture (last event window and continuous read)
§ DS2210APU_INJ_Bx_Gy(group § DS2210APU_IGN_Bx
2) DS2210APU_IGNCONT_Bx
§ Injection Pulse Position and Fuel § Spark Event Capture ( DS2210 RTLib Reference)
Amount Measurement § Injection pulse position and fuel amount measurement (continuous read)
( DS2210 RTLib Reference) § DS2210APU_INJCONT_Bx_Gy(group 2)
§ Spark event capture, auxiliary input (last event window and continuous
read):
DS2210APU_AUXCAPCONT_Bx_Cy
§ Spark Event Capture ( DS2210 RTLib Reference)
Conflicts for the Serial The DS2210 supports only one serial interface. It can be configured as either
Interface RS232 or RS422 mode.
Limited Number of CAN Messages
Limitation When you implement CAN communication with RTI CAN Blockset or with
RTLib's CAN access functions, the number of CAN messages in an application is
limited.
This applies to the following message types:

§ Transmit (TX) messages
§ Receive (RX) messages
§ Request (RQ) messages
An RQ message and the corresponding RX message are interpreted as a single
(RQ) message. You cannot enable RX service support for the corresponding RX
message.
§ Remote (RM) messages
210
Limited Number of CAN Messages
The sum of these messages is nsum:
nsum = nTX + nRX + nRQ + nRM
Maximum number of CAN The sum of the above messages nsum in one application must always be smaller
messages than or equal to the maximum number of CAN messages nmax:
nsum ≤ nmax ; nRM ≤ 10
nmax in one application depends on:

§ Whether you implement CAN communication with RTI CAN Blockset or with
RTLib's CAN access functions.
§ Whether you use RX service support.
The maximum number of CAN messages nmax is listed in the table below:
Platform nmax with nmax with RTI CAN Blockset

RTLib
RX Service Support Disabled RX Service Support Enabled
1 1) 2 1) 3 1) 4 1) 1 1) 2 1) 3 1) 4 1)
DS1103 (1 CAN 100 98 – – – 96 2) – – –
controller)
DS2202 (2 CAN 100 98 96 – – 96 2) 92 2) – –
controllers)
DS2210 (2 CAN 100 98 96 – – 96 2) 92 2) – –
controllers)
DS2211 (2 CAN 100 98 96 – – 96 2) 92 2) – –
controllers)
MicroAutoBox 3) 100 98 96 – – 96 2) 92 2) – –
(2 CAN controllers
per CAN_Type1)
MicroLabBox (2 CAN 100 98 96 – – 96 2) 92 2) – –
controllers)
DS4302 (4 CAN 200 198 196 194 192 196 2) 192 2) 188 2) 184 2)
controllers)
1) Number of CAN controllers used in the application
2) It is assumed that RX service support is enabled for all the CAN controllers used, and that both CAN message identifier formats
(STD, XTD) are used.
3) Depending on the variant, MicroAutoBox contains up to three CAN_Type1 modules, each with 2 CAN controllers. The values in
the list apply to a single CAN_Type1 module.
Ways to implement more There are two ways to implement more CAN messages in an application.
CAN messages
Using RX service support If you use RTI CAN Blockset’s RX service support,
the number of receive (RX) messages nRX in the equations above applies only to
RTICAN Receive (RX) blocks for which RX service support is not enabled.
The number of RTICAN Receive (RX) blocks for which RX service support is
enabled is unlimited. Refer to Using RX Service Support on page 110.
211
Limitations
Using the RTI CAN MultiMessage Blockset To implement more CAN

messages in an application, you can also use the RTI CAN MultiMessage
Blockset. Refer to the RTI CAN MultiMessage Blockset Tutorial.
Maximum number of CAN The number of available CAN subinterrupts you can implement in an application
subinterrupts is limited:
Platform Available CAN Subinterrupts

DS1103 (1 CAN controller) 15
DS2202 (2 CAN controllers) 15
MicroAutoBox 1) (2 CAN controllers per 15
CAN_Type1)
MicroLabBox (2 CAN controllers) 15
1) Depending on the variant, MicroAutoBox contains up to 3 CAN_Type1 modules, each
with 2 CAN controllers. The values in the list apply to a single CAN_Type1 module.
Limitations with RTICANMM
RTI CAN MultiMessage The following limitations apply to the RTI CAN MultiMessage Blockset:
Blockset § The configuration file supports only messages whose name does not begin
with an underscore.
§ Do not use the RTI CAN MultiMessage Blockset and the RTI CAN Blockset for
the same CAN controller.
§ Do not use the RTI CAN MultiMessage Blockset in enabled subsystems,
triggered subsystems, configurable subsystems, or function‑call subsystems. As
an alternative, you can disable the entire RTI CAN MultiMessage Blockset by
switching the CAN controller variant, or by setting the GlobalEnable
triggering option. This option is available on the Triggering Options Page
§ Do not run the RTI CAN MultiMessage Blockset in a separate task.
§ Do not copy blocks of the RTI CAN MultiMessage Blockset. To add further
blocks of the RTI CAN MultiMessage Blockset to a model, always take them
directly from the rticanmmlib library. To transfer settings between two
MainBlocks or between two Gateway blocks, invoke the Save Settings and
Load Settings commands from the Settings menu (refer to RTICANMM
MainBlock or RTICANMM Gateway ( RTI CAN MultiMessage Blockset
Reference)).
§ The RTI CAN MultiMessage Blockset is not included in the RTI update
mechanism and is not updated when you open a model with an older version.
To update the RTI CAN MultiMessage Blockset, invoke Create S-Function for
212
Limitations with RTICANMM
All RTICANMM Blocks from the Options menu of the RTICANMM

GeneralSetup ( RTI CAN MultiMessage Blockset Reference).
As an alternative, you can create new S-functions for all RTICANMM blocks
manually (use the following order):
1. RTICANMM GeneralSetup ( RTI CAN MultiMessage Blockset Reference)
2. RTICANMM ControllerSetup ( RTI CAN MultiMessage Blockset
Reference)
3. RTICANMM MainBlock ( RTI CAN MultiMessage Blockset Reference)
4. RTICANMM Gateway ( RTI CAN MultiMessage Blockset Reference)
§ Model path names with multi-byte character encodings are not supported.
§ Mode signals with opaque byte order format that are longer than 8 bits are
not supported.
§ The RTI CAN MultiMessage Blockset generates data structures on the basis of
the relevant element names specified in the database file. The length of an
element name is limited to 56 characters. If an element name exceeds this
limit, the RTI CAN MultiMessage Blockset shortens the name to 56 characters,
using a checksum to ensure name uniqueness, and makes an entry in the log
file.
The following list shows the element types whose maximum name length
must not exceed 56 characters:
§ Messages
§ Signals
§ UpdateBit signals
§ Mode signals
§ Nodes
FIBEX 3.1, FIBEX 4.1, or The RTI CAN MultiMessage Blockset does not support multiple computation
FIBEX 4.1.1 file as the methods for signals. If several CompuMethods are defined for a signal in the
database FIBEX file, the RTI CAN MultiMessage Blockset uses the first linear computation
method it finds for the signal.
MAT file as the database In the RTI CAN MultiMessage Blockset, the length of signal names is restricted to
32 characters. However, MATLAB allows longer signal names. When MATLAB
entries are mapped to the signals in RTICANMM, the signal names are truncated
at the end and supplemented by a consecutive number, if necessary. To ensure
that unchanged signal names are used in the RTI CAN MultiMessage Blockset,
the signal names in the Simulink model must not exceed 32 characters.
AUTOSAR system description The RTI CAN MultiMessage Blockset does not support the following features that
file as the database can be defined in an AUTOSAR 3.2.2, 4.0.3, 4.1.1, 4.1.2, 4.2.1, 4.2.2, or 4.3.0
system description file:
§ Partial networking (There are some exceptions: Partial networking is supported
for MicroAutoBox equipped with a DS1513 I/O Board, MicroLabBox, and
dSPACE hardware that is equipped with DS4342 CAN FD Interface Modules.)
213
Limitations
§ Unit groups
§ Segment positions for MultiplexedIPdus
§ ContainerIPdus
§ SecuredIPdus
§ End‑to‑end protection for ISignalGroups
§ Global time synchronization
Visualization with the Bus The current version of the RTI CAN MultiMessage Blockset supports visualization
Navigator with the Bus Navigator in ControlDesk 4.2.1 or later. You cannot work with
earlier versions of ControlDesk in connection with applications created with the
current version of the RTI CAN MultiMessage Blockset.
Limitations with J1939-Support
Limitations The following limitations apply to the J1939 support of the RTI CAN
MultiMessage Blockset:
§ The J1939 support for the RTI CAN MultiMessage Blockset requires a separate
license.
§ To use J1939, you must provide a J1939-compliant DBC file.
§ Though most messages are already defined in the J1939 standard, you must
specify the required messages in your DBC file.
§ When you gateway messages, J1939 network management (address claiming)
is not supported. This limitation applies to gatewaying via RTICANMM
MainBlocks and via RTICANMM Gateway block.
§ When you gateway J1939 messages via an RTICANMM Gateway block,
multipacket messages cannot be added to the filter list. This means that J1939
messages longer than 8 bytes cannot be excluded from being gatewayed.
§ For J1939 messages, the CRC option is limited to the first eight bytes.
§ For J1939 messages, the custom code option is limited to the first eight bytes.
§ Peer‑to‑peer communication for J1939 messages longer than 8 bytes via
RTS/CTS is supported only for receiving network nodes whose simulation type
is set to 'simulated' or 'external'.
§ CAN messages with extended identifier format and also J1939 messages use a
29‑bit message identifier. Because the RTI CAN MultiMessage Blockset cannot
differentiate between the two message types on the CAN bus, working with
extended CAN messages and J1939 messages on the same bus is not
supported.
214
Index
crankshaft sensor signal generation 86 frequency measurement 63

A I/O mapping 86 fuel amount measurement 78
crankshaft signal generator 75 I/O mapping 92
A/D conversion 20
functional units
absolute time 157
D DS910 145
ADC unit 48
characteristics 48 D/A channel 51
feature summary 20 D/A conversion 20 G
I/O mapping 49 D/R converter 52 Gigalink access times 146
overview 19 I/O mapping 54 Gigalink Module 144
analog output circuits 95 DAC unit 50 global memory 25
angle position interrupt 72 feature summary 20 application 166
angular processing unit I/O mapping 51 global time base 157
overview 71 overview 19
application data file support 109 H
flash memory 167 data transmission 147
handling interrupts 30
global memory 166 swinging buffer mode 148
high rails 169
APU overview 71 virtual shared memory mode 148
controlling 173
Decrementer 27
host interface 37
B defining CAN messages 109
diagnostic 187
battery voltage I
distributed tracing 158
controlling 171
Documents folder 10 I/O boards
BCLK 24
DocumentsFolder 10 cascading 73
big endian mode 37
DS2210 17 I/O mapping
bit I/O unit 54
analog output circuits 95 ADC unit 49
feature summary 20
cascading 72 bit I/O unit 55
I/O mapping 55
interrupts 139 camshaft sensor signal generation 88
boot firmware 166
master board 72, 74 crankshaft sensor signal generation 86
bus clock 24
slave board 72, 74 D/R converter 54
DS2210 board revision 201 DAC unit 51
C DS802 ECU 1 connector 194
cable break 184 partitioning PHS bus 33 ECU 2 connector 197
cache memory 25 DS910 Gigalink Module 144 frequency measurement 64
camshaft phase 76 DSP subsystem 18 fuel amount measurement 92
camshaft sensor signal generation 87 duty cycle 57 knock sensor simulation 98
I/O mapping 88 PWM signal generation 62
camshaft signal generator 76 E PWM signal measurement 59
CAN serial interface 67
ECU 1 connector
channel 103 spark event measurement 90
I/O mapping 194
fault-tolerant transceiver 107 square-wave signal generation 66
ECU 2 connector
I/O mapping 115 wheel speed sensor simulation 100
I/O mapping 197
interrupts 110 injection event capture unit 78
endian modes 37
physical layer 104 injection pulse position measurement 91
engine position bus 71
service 113 continuous capture 84
engine position interrupt 72
setup 102 I/O mapping 92
engine position phase accumulator 72
status information 113 interface
event capture window 77
CAN FD 121 Gigalink Module 144
event capture windows 81
CAN subsystem 18 host 37
expanding the simulator 189
CAN support 101 PHS bus 32
feature summary 20 interrupt
car battery 169 F handling 30
CARB connector 187 failure insertion 181 transmission 151
cascading DS2210 boards 72 failure types 183 interrupt control 21
cascading I/O boards 73 firmware 166 IOERROR line 32
Common Program Data folder 10 FIU 182 Gigalink 145
CommonProgramDataFolder 10 flash memory 25 PHS bus 32
communication port 144 application 167 ISO11898 105
continuous capture 81 flight recorder 40, 42 ISO11898‑6 106
controlling time stamps 43
battery voltage 171, 172 using 43
high rails 173 force reset 39
215
Index
J PHS bus interface 32 square-wave signal generation 65

physical characteristics I/O mapping 66
J1939
DS1005 24 start position/fuel amount capture mode 79
broadcast/peer-to-peer messages 126
piggyback support 107 STBU 157
limitations 214
power supply unit 169 substitute load 177
working with J1939-compliant DBC files 126
processor 25 supervision 39
pulse generation 21 swinging buffer mode 148
K pulse measurement 22 switching
knock sensor simulation 96 PWM analysis 56 high rails 173
I/O mapping 98 PWM period 57 Synchronous Time Base Unit 157
PWM signal generation 59 SYNCIN/SYNCOUT lines
I/O mapping 62 Gigalink 145
L
PWM signal measurement 56 PHS bus 32
limitations I/O mapping 59 synchronizing in MP system 155
J1939 214 system overview
RTI CAN MultiMessage Blockset 212 DS910 145
little endian mode 37
Q
load quantization effects 200
real 177
T
substitute 177 R Time Base Counter 29
load simulation 177 time stamping 157
real load 177
Local Program Data folder 10 in single-processor systems 29
real-time processor 25
LocalProgramDataFolder 10 time stamps
requirements
flight recorder 43
DS1005 24
time-base bus 71
M resistor channel 54
timer 27
main memory 25 I/O mapping 54
Decrementer 27
master DS2210 72, 74 resistor output circuits 52
Timer A 28
master-slave tracing 158 RS232 35
Timer B 28
memory 25 RS485 107
TJA1041
memory map 25 RTI CAN MultiMessage Blockset
limitations 107
messages limitations 212
TJA1054
defining CAN messages 109 RTICANMM
transceiver 107
delay time 109 J1939 214
topological subsets
multiple 109 RTP 25
basics 160
monitoring RX service support 110
tracing
host access 39 distributed 158
program execution 39 S master-slave 158
multiple data files 109 transceiver
sample hit 84
multiple event capture mode 78 TJA1054 107
serial interface 35
multiple message support 109 transmission
baud rates 36
multiprocessor system data 147
I/O mapping 67
optional CPUs 159 interrupts 151
oscillator frequency 36
short to
O battery voltage 183 U
optional CPUs 159 ground 184
UART 35
basics 160 simulate
using
multiprocessor system 159 car battery 169
flight recorder 43
specifying in RTI-MP 162 loads 177
overview simulating
DS1005 PPC Board 16 failures 181 V
DS2210 HIL I/O Board 17 single event capture mode 77 virtual shared memory mode 148
dSPACE Simulator Mid-Size 13 slave CAN MC 19
slave DS2210 72, 74 W
slave DSP
P Watchdog 39
analog output circuits 95
partitioning PHS bus wave table
slave DSP TMS320C31 95
DS802 33 basics 88
spark event
system overview 34 generating 89
continuous capture 83
PC interface 15 wheel speed sensor simulation 99
spark event capture unit 77
phase accumulator 72 I/O mapping 100
spark event measurement 90
PHS bus 32 working with CAN FD 121
I/O mapping 90
216

D SPACESimulator Mid Size Features

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

D SPACESimulator Mid Size Features

Uploaded by

Copyright:

Available Formats

dSPACE Simulator Mid-Size

How to Contact dSPACE Support

You can also use the support request form:

Software Updates and Patches

© 2000 - 2018 by:

ConfigurationDesk, ControlDesk, MicroAutoBox, MicroLabBox, SCALEXIO, SYNECT,

About This Document 9

Introduction to the Features of dSPACE Simulator Mid-Size 13

Features of the Processor Board 23

Timers and Time Base Counters.................................................................................. 27

Sensor and Actuator Interface 47

Angular Processing Unit 69

Features Served by the Slave DSP 95

CAN Support 101

Using the RTI CAN MultiMessage Blockset................................................................ 116

Interrupts of the DS2210 139

DS1005 Multiprocessor Systems 141

DS910 Gigalink Module............................................................................................ 144

Working with Subsets of a Multiprocessor Topology.................................................. 159

Application Start 165

Power Supply Unit 169

Load Simulation 177

Failure Simulation 181

I/O Mapping 193

About This Document

Contents The dSPACE Simulator Mid-Size Features document provides feature-oriented

Where to go from here Information in this section

Conventions Used in dSPACE User Documentation .................................. 9

Accessing dSPACE Help and PDF Files .................................................... 10

Related Documents ............................................................................... 12

Conventions Used in dSPACE User Documentation

Symbols dSPACE user documentation uses the following symbols:

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

<> Angle brackets contain wildcard characters or placeholders for variable

Common Program Data folder A standard folder for application-specific

Documents folder A standard folder for user-specific documents.

Local Program Data folder A standard folder for application-specific

Accessing dSPACE Help and PDF Files

Online help There are various ways to open dSPACE Help.

Opening context-sensitive help dSPACE Help provides context-sensitive

PDF files You can open the PDF files as follows:

The PDF document opens on its first page.

Opening from dSPACE software with ribbons If your dSPACE software

Information in other documents

DS2210 RTI Reference

DS2210 RTI Reference

DS1005 RTLib Reference

DS2210 RTLib Reference

PHS Bus System Hardware Reference

RTI and RTI-MP Implementation Guide

RTI and RTI-MP Implementation Reference

Introduction to the Features of dSPACE Simulator

Where to go from here Information in this section

Overview of dSPACE Simulator Mid-Size ................................................ 13

System Overview of DS1005 PPC Board ................................................. 16

Features Overview the DS1005 PPC Board ............................................. 16

System Overview of DS2210 HIL I/O Board ............................................. 17

Features Overview of DS2210 HIL I/O Board ........................................... 19

Overview of dSPACE Simulator Mid-Size

Introduction To get an overview of dSPACE Simulator Mid-Size.

The following illustration shows the connections of the components.

dSPACE Simulator Mid-Size is mounted in a 19’’/6U desktop rack. It contains all

Slot Type Required Interface Board