- Beginning of the page
Rapid Control Prototyping provides you with mechanisms for testing control algorithms quickly and efficiently without having to replace the entire ECU software. This approach can be applied with both physical and virtual ECUs.
Below you will find fundamental information on Rapid Prototyping as well as details on:
Bypassing means that parts of the control algorithm are computed outside the ECU in an additional real-time hardware component. The VN8900 family is used for these real-time hardware components.
A blue function block in which algorithm A runs is depicted in the ECU. In order to permit use of the revised version A‘ of the algorithm, the input data to algorithm A is read from the controller via XCP (DAQ). In the first step, the bypassing coordinator acquires the data and then passes it to algorithm A‘ in step 2. A‘ is executed on the bypassing hardware and the output data is passed back to the bypassing coordinator in step 3. This is then passed on to the controller via XCP (STIM) in step 4. This method is based on the XCP standard protocol and makes it possible to integrate the algorithms on the bypassing hardware with the ECU I/O and other software. An important prerequisite for this is a high-performance physical connection to the ECU like the VX1000 measurement and calibration hardware.
The model and application algorithms are checked and adapted using XCP.
In fullpassing, the entire code is taken from the ECU and is computed on a separate hardware component. This situation occurs frequently if the ECU hardware required for the computation is not yet available. It is possible to use various platforms depending on requirements, for example in terms of real-time computation and computing performance. From a PC with virtual ECUs through to a real-time platform based on the VN8900 family. Here again, integration with XCP helps to create a vendor-independent tool chain.
The connection between the computation hardware and ECU must offer sufficient performance in both directions in order to acquire the data, perform the computations and write the values back to the ECU. The maximum data rate is not achieved via bus interfaces such as CAN or FlexRay, but via microcontroller-specific data interfaces (JTAG, DAP, Nexus, and Aurora).
Control Algorithm Development
The control algorithms in the ECUs are developed either by means of manual code or using a model-based approach. The two possibilities differ at the level of the development environment and the associated approach.
In Simulink you develop your algorithm in a graphical modeling language, e.g. with function blocks from The MathWorks or dSpace. Using the Simulink Coder from MathWorks, you generate code for a predefined platform. With the "Vector MATLAB/Simulink MC Add-on" you can select the CANape/vSignalyzer target for code generation in your Simulink model. With this selection, an XCP driver is already integrated into the code in the generation step. After compiling and linking, a DLL is available that you can integrate directly in CANape as a device and measure and adjust via XCP.
If you develop your application directly in Visual Studio then the algorithm can also be integrated as a DLL directly in CANape. Consequently, you have a Visual Studio project with your algorithm embedded in it. After compiling and linking, you possess a DLL which you can include directly as a device in CANape and which is again equipped with XCP access.
Depending on the development phase, a control algorithm can be used in different environments, for example in a virtual scenario, in the laboratory, at a workstation or in the vehicle.
Vector's solutions are based on the use of standards such as XCP, A2L, CDF2.0 and MDF. As a result, you can access the same tool configurations across all the stages of development. The measurement data is always present in the same format and the files containing the parameter sets are interchangeable as required. Consequently, the time required for familiarization is extremely short and information and data can be exchanged without restriction.
Prototyping of virtual ECUs on the Computer
Prototyping solutions can be used even before the ECU hardware has been developed. At the same time, the model can be computed in Simulink or as executable code (DLL) in CANape.
A connection from CANape to the model in Simulink is realized via XCP on Ethernet.
All measurement and adjustment options of CANape are available to you, without the need for further instrumentation of the model. From measuring signals, characteristic curves and fields, to adjusting individual parameters and loading complete parameter sets into the MATLAB workspace.
Integrated S-Functions can also be measured and adjusted via XCP. You only need to integrate them into the Simulink XCP server via the associated A2L. This allows you to access functions that were created by a supplier, for example, and are not available as a model.
As input variables to the model, CANape accesses existing signals from measurement files and passes them to the model, so that no model adaptation is necessary for reading in input vectors. CANape adapts completely to the time behavior of the model. Regardless of whether the model is running much faster than real time or you are having the model calculate step by step.
The compiler can be used to generate DLLs from manual code or from Simulink models and these can then be seamlessly integrated in CANape. One special feature of the DLLs is that they possess XCP interfaces that make it possible to measure data or calibrate parameters directly from the DLL. When the DLL is integrated and used, it is no different from a ECU with XCP-on-Ethernet access.
CANape supplies the input data required for the DLL directly from connected data sources such as buses and ECUs or from existing measurement files.
The Vector Tool Platform is a system extension for the VN8900 product family.
This component improves latency and determinism of CANoe and CANape. To achieve this, the PC-based network interfaces of the VN8900 family are logically divided into two areas. In one area, the interface operates as usual. In another area, "Extended Real Time" (ERT) is available, in which predefined functions are executed under real-time conditions.
Developers of ECUS that contain sensors are confronted with two problems:
- Meaningful sensor data that reflects real situations is often only available in the vehicle since the required environment is not present in the laboratory.
- Reproducing in-vehicle sensor data is a time and cost-intensive exercise.
For these reasons, the stimulation of ECUs – whether they are real or virtual in nature – using previously recorded sensor data is an important part of development. One way to do this is to bypass the inputs and write the data directly to the ECU’s memory via XCP. Another way is to transport the data into the controller via the sensor inputs.
Products Available to Support You
|Uses the XCP interface to the model (as a DLL or in Simulink) in the same way as to an ECU. CANape fully adapts to the timing of the Simulink model.|
Products Available to Support You
Prototyping and series production software framework for the development of data fusion algorithms for driving functions, such as AEB, ACC and Highway Pilot. Supports the object fusion of radar, camera and LIDAR.
Remaining Bus Simulation
The remaining bus simulation is assigned an important task in developing ECUs. It ensures that the ECU has a functionally capable environment available to it, without which it would be practically impossible to conduct comprehensive tests. The challenge for developers is to quickly generate a realistic remaining bus simulation that considers specified constraints.
Environment simulation also plays an important role in ECU development. It ensures that, in addition to the ECU and the communications networks, the I/O interfaces are also connected. The VT System makes it very easy to control an ECU's inputs and outputs.
CANoe Execution Platform
A CANoe simulation can be executed on different platforms to cover various requirements related to performance, latency and throughput:
In the classic mode, the CANoe simulation is executed on one computer together with the network interface hardware. There are no special requirements related to performance, latency or throughput.
In RT mode, the CANoe simulation runs on separate computers. The GUI portion can be executed on a normal workplace computer. The simulation portion is executed on a dedicated real-time system. The following platforms are available for this real-time part.
The VN8900 network interface is interface hardware that is set up modularly with many different possible channel combinations for CAN, LIN, FlexRay, J1708 and K-Line. Simulation on VN8900 hardware can also be executed in a stand-alone setup, i.e. without a host PC.
- More information on the VN8900
You use VT System to build test systems for functional testing of ECUs and vehicle networks. CANoe is the test automation software that is used in these systems. The modular layout of the VT System lets you build solutions that range from simple testing tools to complex test systems.
- More information on the VT System
CANoe RT Rack
CANoe RT Rack is an industrial PC with an optimized real-time operating system. It can simply boost the overall performance of the system, and shorter latency times and more precise timers are possible.
- For more information see the Fact Sheet on CANoe RT Rack (PDF)
Various interfaces are available for integrating CANoe into a heterogeneous environment that consists of specialized tools from different manufacturers.
More information is available upon request.
Bypassing is a special form of Rapid Prototyping: In it, data is acquired from the ECU, processed outside of it and the result is then written back into the ECU. Mechanisms from the XCP protocol are used to do this (DAQ for measuring the data from the ECU and STIM for stimulating the data in the ECU).
To keep latencies as short as possible, the algorithm runs in the runtime environment on the VN8900. The highest-performance XCP connection between the VN8900 bypassing hardware and the ECU is provided by means of the VX1000 measurement and calibration hardware.
Products Available to Support You
You can perform PC-based bypassing using the XCP mechanisms DAQ/STIM in combination with CANape.
Bypassing computation with deterministic time response. The overall solution is configured and the signals and parameters are displayed in CANape. A product from the VN8900 family is used as the runtime environment.
To ensure short roundtrip times, the bypass is computed at the Vector network interface with integrated VN8900 real-time computer and measurement and stimulation access is performed using the VX1000 hardware.
Scalable measurement and calibration hardware for exceptionally short roundtrip times between the bypassing algorithm and the ECU.