Rapid Prototyping
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:
Fundamentals
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.
Development Approach
In Simulink, the algorithm is developed in a graphical modeling language, typically with function blocks taken from MathWorks or dSpace. You then generate code for a predefined platform via the MathWorks Simulink coder. With the “Vector MATLAB/Simulink MC Add-on”, you can choose “CANape” as the target platform in the Simulink coder. When you select this option, an XCP driver is integrated in the code during the generation step. After compiling and linking, you possess a DLL which you can integrate directly as a device in CANape and measure and calibrate 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.
Application Environment
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.
Execution Platforms
Prototyping of virtual ECUs on the PC
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 is established from CANape to the model in Simulink via XCP on Ethernet. For this to be possible, the CANape option “Simulink XCP Server” is required. The XCP server is integrated in the model generates an A2L file of the model, creates a CANape project and starts CANape.
As a result, users possess all the measurement and calibration capabilities of CANape without requiring any further instrumentation of the model. From the measurement of signals, characteristic curves and maps through the calibration of individual parameters and the loading of complete parameter sets in the MATLAB Workspace.
Integrated S-Functions can also be measured and calibrated via XCP. You simply have to integrate these in the Simulink XCP server via the associated A2L. In this way, you access functions that, for example, have been developed by a supplier and are not available as a model.
As input values for the model, CANape accesses existing signals from measurement files and passes them to the model, with the result that no adaptations need to be made to the model in order to read the input vectors. CANape adapts fully to the time response of the model whether the model runs faster than real-time or you compute the model 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 PC-based Vector network interfaces:
This component improves the latency and determinism of CANoe and CANape. To make this possible, the PC-based network interfaces of the VN8900 family are logically subdivided into two areas. In one of these, the interface functions as normal. The other area provides the “Extended Real Time” (ERT) component in which predefined functions can be executed under real-time conditions.
Products Available to Support You
Runtime environments for algorithms created using different development environments. | CANape |
CANape uses the Simulink XCP Server option to connect to the model in Simulink. Via this connection, it is possible to modify parameters in the model, enter real data as stimulations in the model and acquire any required measured values from the model. | |
A VN8900 network interface can be used as the execution platform for MATLAB/Simulink models that are used in CANape in order to achieve better real-time response. The Vector Tool Platform makes it possible to improve properties that are important for the execution of models, such as latency and determinism. | VN8900 and Vector Tool Platform |
Stimulation
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 in the same way as an interface to a ECU. CANape adapts fully to the time response of the Simulink model. | |
Provides the XCP interface between CANape and the model. It also generates the A2L of the model and creates a CANape project at the touch of a button. |
Data Fusion
Various sensors are used in parallel to improve the quality of detection of objects in the vehicle's environment. The data from multiple sensors is fused into as complete a picture as possible of the environment.
Products Available to Support You
End-to-end solution from multisensor data capture through algorithm development and on to stimulation and the rapid visual display of the results. | |
Prototype software framework for the rapid development of complex data fusion algorithms. Includes support for 360° solutions for autonomous driving (levels 1 to 5). |
Simulation
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
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.
VN8900
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
VT System
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.
Examples:
- MATLAB/Simulink
- FMI/FMU
- FDX
- LabVIEW
- XiLAPI
More information is available upon request.
Bypassing
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. | 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. |