Unlike fullpass approaches, where the ECU is completely replaced by the prototyping system, bypassing is used to develop only individual parts of the ECU software from scratch or modify them, e.g., single control functions. These parts run either on a prototyping system that is connected to an existing ECU (external bypassing) or directly on the ECU (on-target bypassing). dSPACE offers a comprehensive range of hardware and software that help prepare an existing ECU for bypassing and that support the different bypass methods.
Example of an external bypassing scenario with dSPACE tools
To use external and on-target bypassing, the existing ECU code has to be prepared. With service-based bypassing as supported by dSPACE, virtually any number of functions in the ECU code can be prepared for bypassing by integrating service calls, also known as bypass hooks. These service calls can be flexibly used in the MATLAB®/Simulink® modeling environment for the synchronous measurement and calibration of ECU variables and parameters, for ECU flash programming, and for bypassing. To help you prepare the ECU code for bypassing, dSPACE offers the ECU Interface Manager with the Binary Code Management Module as an easy-to-use tool with an intuitive, graphical view on the code structure of an ECU. It gives you a convenient and flexible way to implement bypass services directly and automatically in the binary code of the ECU. There is no need for the ECU supplier to modify the source code and run it through the whole production development process and tooling again. This approach saves time and money, and it also increases flexibility. Alternatively, services for bypassing can be manually integrated in the ECU source code. dSPACE offers its generically designed bypass services and service calls as C sources, so they can be compiled and linked with the existing ECU code. Using ConfigurationDesk or the RTI Bypass Blockset, you can conveniently develop new model-based bypass functions in Simulink.
This bypass method is an efficient way to develop new control functions and optimize existing controller strategies. ‘External’ means that a dedicated RCP system is attached to an ECU. The RCP system executes a new control function f(x)’ synchronously to the original code that runs on the target ECU. RCP systems have almost no resource constraints with regard to available RAM, ROM (flash) as well as processor performance, and they also provide additional I/O channels. Therefore, even complex Simulink models can be executed as external bypass functions. Real-time behavior is ensured by specific synchronization mechanisms of the ECU interface.
Example of an external bypassing scenario with dSPACE tools for a combustion engine.
In case of a vehicle-in-the-loop simulation, where an ECU is tested in a real vehicle but under (partly) virtual conditions (e.g., virtual traffic or camera object lists), the same method allows you to simulate a virtual environment on a dSPACE real-time system that can be fed into the ECU in real time (external environment bypassing).
In more complex hardware setups, you can also connect several ECUs to your RCP system. Using the bypassing approach, it is possible to inject values into one ECU, modify the controller algorithm on another ECU, and capture internal variables of a third ECU, all at the same time. Again, the synchronization mechanisms of the ECU interfaces ensure the real-time behavior of the setup as a whole. The number of ECUs that can be bypassed in parallel is only limited by the available data processing resources on the RCP system.
dSPACE supports numerous interfaces for connecting the prototyping system to the ECU. If the ECU has standard CAN, CAN FD, or Ethernet interfaces, a direct access via the XCP protocol without further hardware is possible. If such bus interfaces are not available for bypassing, and high real-time performance with a high bandwidth is required, you can use the Generic Serial Interface (DCI-GSI2), which is connected to the ECU’s on-chip debug interface, such as NEXUS or DAP. If using such an interface is not possible either, dSPACE also supports ECU-specific plug-on devices (PODs).
If an ECU provides all relevant I/O interfaces and has sufficient free resources, new functions can also be developed directly on the ECU. This reduces development costs, because no additional hardware and wiring harness is necessary. The new functions are executed directly on the target hardware, which means there are no communication latencies to external development hardware. Therefore, new functions can be integrated into very fast control loops. Using dSPACE TargetLink as a code generator allows for a seamless transition to production and a more efficient use of the limited ECU resources. Another benefit is that the additional resource consumption on the ECU can be determined early in the development phase. Furthermore, using the certified TargetLink code generator together with an ECU that was already cleared for production can improve the overall operational safety for the prototyping phase, e.g., during fleet tests.
Example of an on-target bypassing scenario with dSPACE tools for an efficient use of the limited ECU resources.