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.
22
Embed
dSPACE Prototyping Systems - MIT CSAILgroups.csail.mit.edu/drl/wiki/images/7/70/dSPACEPrototypingSystems... · Catalog 2006 • dSPACE • Technologiepark 25 • 33100 Paderborn •
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
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.
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.
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.
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.