dSPACE Prototyping Systems - MIT...

Catalog 2006 • dSPACE • Technologiepark 25 • 33100 Paderborn • Germany • [email protected] • www.dspace.com

48

Function Prototyping

2006

dSPACE Prototyping Systems

Accelerated function prototyping for controller development

Control design development and optimization without manual programming

Optimum scalability and flexibility of dSPACE hardware with high performance and extensive I/O

MATLAB®/Simulink® models implemented on dSPACE hardware automatically with dSPACE Real-Time Interface

Whole controller replaced by a dSPACE prototyping system, or new functions developed via bypassing

Flexible adaptation of sensor and actuator signals with RapidPro Hardware

Key Features

Introduction dSPACE prototyping systems are flexible development systems that let you develop

and optimize your control designs for the real plant without manual programming.

Design faults are found immediately and corrections can be carried out on-the-spot.

No special expertise is necessary for implementation on the prototyping system.

We offer numerous input/output interfaces to connect the prototyping system to

sensors and actuators. These can be configured graphically in the block diagram,

without any programming.

dSPACE has a wide range of software and hardware components for building your

own tailored prototyping system. You can also take advantage of our engineering

service to make customer-specific extensions.

Two Ways of Function Prototyping

There are two basic approaches to rapid control prototyping (RCP): fullpass and bypass.

With fullpass, the prototyping system completely replaces the production ECU.

All sensors and actuators are connected to this real-time hardware, and it has full

authority to control the plant.

In bypassing (see also p.50), the prototyping system may be connected to some extra

sensors and actuators, and parts of the control task are done by a production controller.

For example, specific software functions that are under development are offloaded

from the production controller to the controller prototyping unit connected to it.

Catalog 2006 • dSPACE • Technologiepark 25 • 33100 Paderborn • Germany • [email protected] • www.dspace.com 2006

49


Application Areas

Automotive IndustryThe flexible development systems let you go on optimizing your function designs

in the vehicle until you have them just right. Design faults are found immediately,

and corrections can be carried out on the spot. Whatever the ECU will be used for –

engine, transmission, vehicle dynamics, airbags, comfort systems or any other type

of application – the prototyping system handles it.

Aerospace IndustryThe prototyping systems provide all you need for

prototyping the software for your production con-

trollers and can be used for applications such as:

Helicopter blade control for noise reduction

Realistic simulation of flight maneuvers

Control of combustion pressure oscillations

Turbine development

Other IndustriesThe prototyping systems have been used for

many different applications, such as:

Control of a modular rail system

for passenger and freight transport

Control of a telescope

Control system for a wrist simulator

Control of the dragline cycle in open

cut mining


50


2006

Technology Issues

Bypassing in General Integrating New Functions in Existing ControllersIn contrast to fullpass applications, where the ECU is completely replaced by the

prototyping system, with the external bypass approach only individual parts of the

controller code are shifted to the prototyping system, and the calibration load is

limited. The bypass method is an efficient approach, especially to developing new

functions and optimizing existing controller strategies. The original controller executes

all functions that remain unchanged, while new algorithms are executed on the

prototyping hardware. Using the external bypass approach gives you great flexibility,

since you are scarcely limited during the design phase by resource constraints such

as RAM, ROM, processor performance, or I/O channels.

Real-time behavior is guaranteed even with complex bypass functions. In addition,

autoboot options of the prototyping systems allow you to validate the behavior of

the new function in realistic scenarios, for example, during test drives.

��

��

��

��

��

��

��

��

��

External bypassing: New functions run on the prototyping system, while existing code stays on the ECU.


51


External Bypass Methods and Interfaces MatrixTo divert the flow of data from the ECU to the prototyping system and back,

dSPACE supports several methods and interfaces.

Bypass Interfaces DPMEM Plug-On Device (POD)

On-Chip Debugging Interfaces (e.g., Nexus, NBD, AUD, JTAG/OCDS)

XCP on CAN

Bypassing methods available

Address-based bypassing (code patch)

Address-based bypassing (code patch)

–

Service-based bypassing (dSPACE Calibration and Bypassing Service

Service-based bypassing (dSPACE Calibration and Bypassing Service

Service-based bypassing (dSPACE XCP Service)

ECU hardware requirements

Access to microcontroller bus, mechanical integration in or on controller

Debug connector (e.g., DCI-GSI1, p.430), mechanical integration in or on controller

One (exclusively) available CAN channel

Synchronization between controller and prototyping system

Address-based bypassing: via 16 interrupts

Address-based bypassing: via 128 interrupts

–

Service-based bypassing: via 128 interrupts



Max. number of service calls (bypass hooks) in controller code

255 255 255

Max. number of functions to be bypassed concurrently

Address-based bypassing: 16 Address-based bypassing: 128 –

Service-based bypassing: 128 Service-based bypassing: 128 Service-based bypassing: 128

��

��

��

��

��

��

��

��

��

��

��

�

Bypassing Interfaces.


52


2006

Address-Based Bypassing Address-based bypassing is one method of transmitting specific sections of ECU

code to a prototyping system for function optimization and development. It can be

applied in combination with a dual-port memory (DPMEM) or an on-chip debug

interface. The method involves integrating customer-specific code patches into the

ECU code. If the input and output variables of functions change, the ECU code

typically also needs to be modified. Address-based bypassing provides very fast

execution times and minimum latencies in data transmission. For example, using

a dSPACE address-based bypass system with a DPMEM plug-on device (POD), the

latency for 20 bytes to be sent from the ECU to the prototyping system and back

again is only 2 x 8.5 µsec.

A typical address-based bypass scenario via DPMEM:

Dual-Port Memory (DPMEM)

A dual-port memory allows read and write access by two systems (processors)

independently of one another, so that they can exchange data. Each of the two ports

has its own address, control and data channels. DPMEMs are used in bypassing to

transmit data between the ECU and the prototyping system via their shared memory

with the smallest possible latencies.

Plug-on Device (POD) Plug-on devices are additional components mounted on an ECU to connect it to the

prototyping hardware (for example, the DS4121 ECU Interface Board). PODs contain

a dual-port memory (DPMEM) which is connected directly to the address and data

bus of the microcontroller, and signal-conditioning tailored to the specific ECU.

On-Chip Debug Interface To provide cost-efficient and powerful interfaces for modern 32-bit microcontrollers,

manufacturers are integrating on-chip debug controllers directly into processors.

On-chip debug controllers allow actions such as reading and writing memory cells

at run time. These options are particularly important in measurement, calibration,

and bypassing if serial interfaces such as CAN do not provide enough bandwidth or

if an external data/address bus is not (exclusively) available. Interfaces in widespread

use include AUD, NBD, JTAG/SDI, JTAG/OCDS, and Nexus.

��

The input data U‘ for the new function is written to the DPMEM. When all the values have been written, the ECU generates an interrupt to the prototyping system, which reads the data from the DPMEM and executes the new function Y‘=f‘(U‘). The result values Y‘ are written back to the DPMEM, and the ECU reads them for further processing.


53


Service-Based Bypassing

Debug Interface Description

AUD Advanced User Debugger interface (for example, for SH2 processors from Renesas)

NBD Non-Break Debug (debug interface, for example, for NEC V85x or Renesas M32R processors)

JTAG/SDI Scalable Debug Interface (debug interface, for example, for Renesas M32R processors)

JTAG/OCDS Debug interface for Infineon TriCore processors

Nexus The Nexus 5001™ Forum standard IEEE-ISTO 5001™-1999 is an open standard for a multipurpose interface for software development and is particularly suited to debugging onembedded processors. The Freescale MPC56x and MPC55xx processors are examples.

Normally, preparation of the ECU code for bypassing is carried out only once by the

ECU supplier. With service-based bypassing as supported by dSPACE, more than

100 functions in the ECU code can be prepared for bypassing by means of ser-

vice calls (bypass hooks). Afterwards, there is no need to modify the ECU code

again. Service calls in the ECU code can be described in a variable description file

(ASAP2 file) and evaluated by the RTI Bypass Blockset, so you can flexibly select the

functions to be bypassed later on in the model environment. Moreover, service-based

bypassing is a generic solution which can be applied independently of the proces-

sor type, the coding method (direct or indirect variable access), and the compiler.

The function interfaces can be adjusted with respect to a guaranteed interrupt be-

havior. dSPACE provides ECU services for DPMEM PODs, for XCP on CAN, and for

the DCI-GSI (p. 430). These services can be used for measurement, for calibration,

and for bypassing. They are available in C code and have to be compiled and linked

to the ECU code only once.

A typical service-based bypass scenario via DPMEM or via XCP on CAN:

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

The new function is executed by the prototyping system, and the results are written back for further processing by the ECU.


54


2006

Via DPMEM Via XCP on CAN

The address tables and the data buffer are located in the DPMEM of the plug-on device (POD). The connection between the ECU and the prototyping system is implemented via LVDS.

The address tables and the data buffer are located in the ECU RAM.The connection between the ECU and the prototyping system is implemented via the CAN bus.

Examples of Service Configuration Options

Double buffer mechanism To transfer consistent data blocks from the prototyping system to the ECU and vice versa

Wait mechanism Used in the read service call to wait for a valid response from the prototyping system, when the double buffer mechanism is enabled

Failure checking mechanism Checks for valid communication between the prototyping system and the ECU and switches to ECU internal default values if the failure counter has exceeded a given limit.

Alive and version information mechanism Checks if the prototyping system is connected to the ECU and running.

Subinterrupt handling mechanism Synchronizes the execution of functions on the ECU and on the prototyping system.

XCP on CAN XCP, the Universal Measurement and Calibration Protocol, is standardized by

ASAM e.V. (Association for Standardisation of Automation- and Measuring Systems).

XCP technology is independent of the transport layer, so XCP can be used with

different physical layers, such as CAN and USB. XCP on CAN is a member of the

XCP protocol family, and the successor to the CAN Calibration Protocol (CCP)

Version 2.1. dSPACE provides an XCP on CAN service implementation fully compatible

with the ASAM standard for various processor platforms. Apart from basic features

such as measurement, calibration, page switching, and ECU flash programming,

the dSPACE XCP implementation also supports function bypassing.


55


System Components

��

��

��

��

��

��

��

��

��

��

��

��

Implementation SoftwareOnce you have created your function models, you can automatically implement them

on the prototyping hardware with the help of Real-Time Interface – without any

programming effort at all. You can even configure complex I/O interfaces directly

in the block diagram. And you can immediately try out new ideas as soon as you

insert them in your model design – all without writing a single line of code. It is also

no problem to implement C-coded models.

Implementation Software (p. 120)

Overview


56


2006

Real-Time Hardware Typically, prototyping hardware is several times more powerful with regard

to processor performance and RAM/ROM resources than the controller itself,

to keep you free of hardware restrictions in the design phase. The hard-

ware of dSPACE prototyping systems consists of high-performance pro-

cessors which can calculate your controller models in microseconds. Con-

nection to the outside world is established by a broad range of I/O inter-

faces. There are numerous hardware options for the prototyping system:

single-board hardware, MicroAutoBox hardware, RapidPro hardware, and modular

hardware.

Single-Board HardwareWith single-board hardware, you have

everything on one card. The boards contain a

comprehensive selection of I/O interfaces that

meet the requirements typical of the prototyp-

ing field. Our single-board hardware typically

runs diretcly in the PC and is ideally suited to

cost-sensitive applications, from rapid control

prototyping to applications that place high

demands on performance and I/O.

Single-Board Hardware (p. 248)

Modular HardwareModular hardware gives you opti-

mum scalability and flexibility. You

can choose from our wide range of

boards to put together exactly the

prototyping hardware you need for

your project.

Modular Hardware (p. 266)

MicroAutoBox HardwareThe MicroAutoBox hardware is the ideal prototyping hardware if you have fixed

requirements for your I/O interfaces. The special strength of the MicroAutoBox

hardware is its unique combination of high-performance, comprehensive automotive

I/O, and an extremely compact and robust design. It is specifically designed for in-

vehicle usage and makes for easy integration of all major

automotive bus systems – CAN, LIN and FlexRay – into

in-vehicle function prototyping. Since a MicroAu-

toBox is hardly larger than an electronic control

unit, it can be placed virtually anywhere in

the vehicle.

MicroAutoBox Hardware (p. 378)


57


RapidPro HardwareThe RapidPro hardware consists of three dif-

ferent unit types: the RapidPro SC Unit (signal

conditioning unit), the RapidPro

Power Unit (power stage unit),

and the RapidPro Control Units

(intelligent I/O subsystem for

dSPACE prototyping systems

as well as stand-alone pro-

totyping ECU). Off-the-

shelf signal conditioning

and power stage modules

can be mounted on the RapidPro units to set up individual systems that optimally

fit the needs of a particular application. Customer-specific modules are available on

request. The modular concept, using modules that are hardware- and software-

configurable, means that all components can be reused, reconfigured, or extended,

for example in later projects or if requirements change with a minimum of effort.

RapidPro can be used for various use cases, such as:

Signal conditioning and power stages

Intelligent I/O subsystem

Stand-alone prototyping ECU

RapidPro Hardware (p. 388)

Test and Experiment Software

To guide you through your function development process, we offer you a sophis-

ticated experiment tool: ControlDesk. For access to the prototyping software from

within MATLAB, we offer you MLIB/MTRACE.

ControlDeskControlDesk is a comprehensive, virtual instrument-oriented experiment environment

that lets you intuitively manage, control, and automate your experiments. It is ideally

suited to simulating your controller models offline, for rapid control prototyping,

and for hardware-in-the-loop simulation (HIL). ControlDesk is your convenient user

interface for changing parameters online during an experiment, loading look-up

tables, and recording data.

ControlDesk (p. 140)


58


2006

CalDeskCalDesk is a universal tool for measurement, calibration, and diagnostics. It is ideal for

rapid prototyping, ECU calibration, and data analysis tasks. It is possible to interface

dSPACE prototyping systems, various kinds of ECUs, measurement modules,and the

vehicle bus in parallel and to correlate all measurement data.

CalDesk can be operated completely via keyboard shortcuts. A high-contrast mode

for visualization and audible signals for trigger and threshold conditions help to

make in-vehicle work easier.

A COM interface allows CalDesk to be remote-controlled, for example, by MATLAB,

in order to automate parameter optimization and measurement tasks.

CalDesk (p. 208)

MLIB/MTRACEMLIB/MTRACE, the MATLAB-dSPACE Interface Library, gives you access to the

prototyping hardware from within MATLAB.

MLIB/MTRACE (p. 178)

Engineering Services for Function Prototyping

dSPACE offers numerous services to assist you with your function prototyping activi-

ties. Whatever you would like to do with dSPACE prototyping systems, you can be

sure that we are ready to support you with:

Consulting and engineering for special bypassing, signal conditioning,

and power stage issues

Engineering for RCP tool introduction and process adaption

(application scenarios, consulting,pilot projects, specific training and coaching)

Customer-specific

hardware development

and integration of third-

party products

Maintenance services

(extension of interfaces,

hardware modification)

Engineering Services

(p. 442)

Measurement and Calibration Software


59


Configuration Example: Stationary Single-Board Solution

DescriptionThis example shows how even a cost-efficient prototyping system based on our sin-

gle-board hardware – in this case the DS1103 PPC Controller Board – can form a

powerful, multipurpose prototyping system. The versatile DS1103, which is installed

in a PX4 Expansion Box in our example, is suitable for demanding tasks in rapid con-

trol prototyping such as robotics applications, servohydraulics, drives applications,

and automotive controllers (for example, ABS or steering). The DS1103 is fully

programmable from the Simulink block diagram environment, which makes it possible

to implement control functions fast and easily. For easy access to all the signals, you can

combine the board with an off-the-shelf connector panel or a connector/LED combi

panel. The sophisticated experiment software ControlDesk offers a comprehensive, virtual

instrument oriented environment that lets you intuitively manage, control, and automate

your experiments.

��

��

��

��

��

��

��

��

Required Components (Example)

Third-Party Components Further Details

PC –

Modeling software MATLAB/Simulink/Stateflow from The MathWorks

p. 41

Real-time code generation from Simulink block diagrams and Stateflow systems

Real-Time Workshop and Stateflow Coder from The MathWorks

p. 41

Software Components Further Details

Implementation software Real-Time Interface (RTI) p. 120

RTI CAN Blockset p. 128

PowerPC Compiler p. 139

Test and Experiment software

ControlDesk p. 140

MLIB/MTRACE p. 178

Hardware Components Further Details

Single-board hardware DS1103 PPC Controller Board p. 250

Accessories PX4 Expansion Box with PCMCIA Link p. 368

CLP1103 Connector Panel p. 260


60


2006

Configuration Example: Stationary Modular Solution

Description This prototyping system is a typical example of a laboratory or test-bench-based, auto-

motive fullpass application. In stationary test environments, a local area network (LAN)

is often used to exchange data between a host PC and (prototyping) systems – here

we used an Ethernet TCP/IP link for this purpose. To enable the Ethernet connection,

the prototyping system (a DS1005 system in a PX10 Expansion Box) is equipped with

a slot-CPU board including an Ethernet interface. The PX10 also contains a choice

of modular hardware boards. The ideal choice depends on the specific application,

so the boards shown here are only examples. An option in many applications is to

use the RapidPro hardware for signal conditioning and power stages.

��

��

��

��

��

��

��

��

��

��

��

��


61




PC with Ethernet interface –


p. 41



p. 41






ControlDesk p. 140

MLIB/MTRACE p. 178


Modular hardware DS1005 PPC Board p. 268

DS2003 Multi-Channel A/D Board p. 278

DS2103 Multi-Channel D/A Board p. 287

DS4002 Timing and Digital I/O Board p. 318

DS4302 CAN Interface Board p. 332

RapidPro hardware RapidPro Hardware p. 388

Accessories PX10 Expansion Box with Ethernet interface (via slot-CPU board)

p. 368


62


2006

Configuration Example: Distributed In-Vehicle Solution

Description A dSPACE prototyping system is not limited to only one prototyping unit. This pro-

totyping system (containing one AutoBox and two MicroAutoBoxes – all three are

perfectly suited to in-vehicle use) shows how separate application components

(each for single-processing) can work within a network and be controlled with one

notebook as the host. All the prototyping units can be connected to the notebook

via the DS830 MultiLink Panel. They communicate with the notebook via a high-

speed serial link. The AutoBox used here contains a choice of modular hardware

boards. The ideal choice depends on the specific application, so the boards shown

here are only examples. In some applications,it might be necessary to establish an

additional bus connection so that the prototyping units can communicate with each

other directly. This has been realized with a CAN bus here. For signal conditioning

and power stages, an option in many applications is to use the RapidPro hard-

ware. Basic signal conditioning is included in the MicroAutoBox. Configurations like

the system shown in this example are applicable to many automotive prototyping

applications.

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��


63




PC –


p. 41



p. 41






ControlDesk p. 140

MLIB/MTRACE p. 178


MicroAutoBox hardware MicroAutoBox p. 378



DS4002 Timing and Digital I/O Board p. 318

DS4302 CAN Interface Board p. 332

RapidPro hardware RapidPro Hardware p. 388

Accessories AutoBox with PCMCIA Link

p. 372

DS830 MultiLink Panel p. 376


64


2006

Configuration Example: Bypass Solution

Description Bypassing (p. 50) means that new functions are moved to the prototyping system,

while existing code continues to run on the ECU. An example of service-based by-

passing via the ECU‘s on-chip debug port is shown here. It is possible to read from

and to write to any ECU memory address synchronously to ECU code execution at

run time by this method. You can use the DCI-GSI1 (p. 430), which supports a range

of debug ports, as an interface between MicroAutoBox and the ECU. The debug

interface actually used for service-based bypassing depends on the ECU’s proces-

sor type. Here it is a JTAG/Nexus debug interface, which is suited to processors of

the Freescale MPC55xx family. The RTI Bypass Blockset allows you to configure the

bypass interface and the bypass functions.

��

��

��

��

��

��

��

��

��

��

��

��


65




PC –


p. 41



p. 41



RTI Bypass Blockset (add-on installation for DCI-GSI1)

p. 136



ControlDesk p. 140

MLIB/MTRACE p. 178

Measurement and Calibration software

CalDesk p. 208

Bypassing services dSPACE Calibration & Bypassing Service

p. 231(service-based bypassing)


MicroAutoBox hardware MicroAutoBox with PCMCIA Link

p. 378

Calibration hardware DCI-GSI1 p. 430


66


2006

Configuration Example: Bypass Solution with Additional I/O

Description If bypassed functions require additional I/O functionalities, these can also be provided

by a dSPACE prototyping system, as shown in this example. The prototyping system

itself is an AutoBox containing a choice of modular hardware boards. A processor

board and the ECU interface board are essential for bypassing, and you can equip the

AutoBox with the necessary I/O boards if additional I/O functionalities are needed. The

signal conditioning and power stages can be provided by our new RapidPro hardware.

With the prototyping system shown, you can perform address-based bypassing via

DPMEM. Bypassing methods and interfaces are described on p. 50 – p. 54.

��

��

��

��

��

��

��

��

��

��

��

��

��

��


67




PC –


p. 41



p. 41

Code patches for bypassing Customer-specific code patches p. 52(address-based bypassing)Please inquire.





ControlDesk p. 140

MLIB/MTRACE p. 178


CalDesk p. 208




DS4121 ECU Interface Board p. 324

DS4302CAN Interface Board p. 332

RapidPro hardware RapidPro hardware p. 388

Accessories AutoBox with PCMCIA Link

p. 372

ECU-specific plug-on device (POD) Please inquire.


68


2006

��

��

��

��

��

��

��

��

��

��

Configuration Example: Bypass Solution via XCP on CAN

Description A prime objective in function development using the external bypass approach is

often to employ existing ECU-network interfaces, such as CAN. Against the back-

ground of cost savings and long-term investment protection, this requires standard-

ized protocols like XCP – tailored not only to today’s but also to future in-vehicle

communication standards.

Apart from basic features such as measurement, calibration, and ECU flash pro-

gramming, the dSPACE XCP service (p. 230) also supports function bypassing.

In connection with a dSPACE prototyping system, the XCP service guarantees minimal

communication latencies via the CAN bus and real-time behavior even with complex

bypass models. Flexible configuration options make it possible to tailor the imple-

mentation of the service with regard to functionality and resource consumption in

the ECU. The XCP service implementation can be used simultaneously for bypass,

measurement, and calibration tasks.

In this example of service-based bypassing, the MicroAutoBox (p. 378) is used as a

real-time prototyping platform calculating the bypass model. Bypass communica-

tion with the ECU runs via the CAN bus using the XCP protocol. The dSPACE XCP

service is implemented on the ECU itself. CalDesk (p. 208) serves as an experiment

environment for the MicroAutoBox and – optionally – for measuring and calibrating

ECU variables via the USB-to-CAN converter DCI-CAN1 (p. 424). Measurement data

from the MicroAutoBox and the ECU can be correlated and parameters on both

platforms tuned in parallel in CalDesk.


69




RTI Bypass Blockset p. 136



MLIB/MTRACE p. 178


CalDesk p. 208

Bypassing services dSPACE XCP Service p. 230 (service-based bypassing)


MicroAutoBox hardware MicroAutoBox p. 378

Calibration hardware DCI-CAN1 p. 424


Notebook –


p. 41



p. 41

dSPACE Prototyping Systems - MIT...

Documents

Transcript of dSPACE Prototyping Systems - MIT...