When developing new control algorithms, every user reaches the point where they have to test their function together with the real production hardware. All pre-tests of the function in the simulation may have been successful, but with the integration into the actual ECU, new boundary conditions are added, such as real-time requirements and hardware dependencies. Especially in mobile applications, where ECUs with fixed interfaces are used, this leads to challenges, as ECUs of the current series are often no longer sufficient and future ECUs are not yet available. In addition, the developer often has no access to the previous production code or the tool chain in order to work directly with the production code.
They now have two options for further action: fullpassing and bypassing
What is fullpassing?
During fullpassing, the complete control unit is replaced by a dSPACE real-time platform. The existing code is ported to the real-time platform and all interfaces are implemented on the prototype system. A dSPACE MicroAutoBox or a SCALEXIO AutoBox can be used here, for example. They can be used directly in the vehicle to test new functions in action. Compared to the production control unit, the prototype systems offer very high computing power and extensive storage space so these aspects do not have to be taken into account at the beginning of the development phase.
Fullpassing is suitable for applications where porting to the real-time platform is easy to implement and the interfaces are manageable.
What is bypassing?
In the case of bypassing, the current series ECU can be used and only the newly developed function is outsourced to a prototyping system. For this, a small service is patched into the binary of the ECU software, so that no further access is required to the source code of the production control unit or to the tool chain used to create a new software version.
The dSPACE DCI-GSI2 connects to the ECU at the test and development interfaces and communicates with the dSPACE prototyping system via XCP on Ethernet. The function on the ECU is bypassed and the newly developed function is executed on a dSPACE real-time platform. The output data is then written on the ECU.
Everything in Real Time
What sounds so simple actually requires a very exact and precisely synchronized read-out and read-in of the data. To do this, access to the control unit must be synchronized with the functional execution so that the data is consistent, and the calculations are done at the right time and can be written back accordingly. The cycle times of the calculations must be so short that bypassing does not affect the function of the algorithm. This is called real-time coupling and is a key feature of the design. Therefore, the DCI-GSI2 is fully focused on real-time capability and minimal latency in data exchange.
How do the tools work together?
The DCI-GSI2, which stands for dSPACE Communication Interface – Generic Serial Interface, is inserted between the control unit and, for example, a dSPACE MicroAutoBox. The DCI-GSI2 now retrieves the input values and sensor values from the control unit and passes them on to the MicroAutoBox. There the new function is executed and the calculated values are written back to the control unit through the DCI-GSI2. In the control sequence of the control unit, the function that is to be newly developed is precisely synchronized. This is called function bypassing.
The real-time system can directly connect to the ECU, if an XCP service is available in the ECU. However, XCP access must be commissioned at the initial creation of the control unit software since a subsequent addition is very expensive or sometimes even impossible. With the dSPACE solution through dSPACE DCI-GSI2, access to the control unit functions is also possible without XCP access, so connecting with the dSPACE tool chain is possible without access to the production code of the control unit. This is made possible by artifacts that are already compiled in binary form, which are patched into the control unit software. This procedure works without changing the source code.
The MicroAutoBox has almost no limitations in computing power compared to the standard production control unit. This allows the developer to focus entirely on function development without having to worry about code optimization. In addition, the dSPACE experiment software ControlDesk can be used to measure and visualize all signals of the new function at run time, which greatly simplifies debugging. Likewise, controller parameters can be adapted during operation to optimize the controller behavior directly in the test vehicle without having to rebuild the software. Iterative development is thus easily possible.
Info Box: XCP Service
XCP stands for "Universal Measurement and Calibration Protocol". The protocol was defined by ASAM (Association for Standardization of Automation and Measuring Systems) for various bus and network media (e.g., XCP on Ethernet, XCP on CAN) and is used for reading and writing data and parameters in the control unit.
Tim Förster
Product Manager, Real-Time Test & Development Solutions, dSPACE GmbH
Martin Teiner
Product Manager, Real-Time Test & Development Solutions, dSPACE
