Smart Charging goes far beyond simply plugging into a household electrical outlet. The electric vehicle to be charged is connected to the electrical grid via a charging station. Charging processes do not simply start up; first, the need to charge is communicated. Delaying individual charging processes by fractions of a minute can avoid overloads of the grid. The connected vehicles can also be used as storage media, and electrical provider billing can be automated.
This is made possible by communication between the vehicle and charging station over Ethernet on IP based protocols, in standardization defined in the ISO 15118 standard. The charging station communicates with the grid and the vehicle here. For the systems manager at the automotive OEM, communication between the car and the charging station is quite important. A detailed analysis and validation of the protocols is absolutely essential to safeguard the charging process. The development tool must also support these protocols (Table 1, “Smart Charge” column).
4. Calibration, debugging, flashing
For many years now, Ethernet has been used with the XCP measurement and calibration protocol to calibrate, debug and flash ECUs in development. However, Ethernet access is no longer provided in the production vehicle for cost reasons. Therefore, calibration and reprogramming are currently performed using the existing working protocol (e.g. CCP or XCP on CAN). However, if Ethernet makes its way into the vehicle in the near future, measurement and calibration over XCP on Ethernet would also be very attractive in production vehicles due to its significantly higher measurement data rates.
5. WLAN and Car2x
Car2x is understood as the external communication between vehicles and the infrastructure. Applications range from convenience functions to traffic flow optimization and heightened traffic safety (driver assistance systems). The technology is already in pre-production development, and standardization is quite advanced. It is IP-based, and the IEEE 802.11p standard is used as the physical layer.
From the perspective of the systems manager measurement technology interest in Car2x applications extends to beyond the boundary of the individual vehicle to a number of other vehicles and RSUs (Roadside Units) in the near environment. The ECU to be evaluated not only communicates with bus systems located in the vehicle, but also over the air interface with other traffic participants. The development tool must therefore support these IP-based standards as well. In addition, other requirements arise in the high-frequency range (WLAN in the 5 GHz band).
New variety of protocols for applications and measurement tool
Table 1 summarizes, by examples, the various application-dependent transmission layers and protocols, which the development tool must support simply based on cases occurring so far. Some of the protocols used in the area of office communications are found here, while many others may be omitted, and certain others are added. The table shows in gray those protocols that can be adopted from office communications. Those added due to the new automotive application are shown in red.
The measurement system has the task of resolving all relevant protocols and placing all network events in a causal relationship (correct sequence). Here it is desirable to be able to represent all bus domains with a common time base and with sufficient precision.
Validation of IP production projects
As the evaluation of the above application cases demonstrates, causality or even time analysis extending over multiple bus systems make it difficult to impossible to utilize standard Ethernet tools from office communications for multi-bus applications in the vehicle. Ethernet in the office field is not the same as Ethernet in the automotive field.
The same applies to the specific Internet protocols that are used. They differ in type and complexity, depending on the application – as significantly as the requirements of the physical layer differ.
A suitable engineering format is important in representing the signal structure of the protocols in the development tool and in generating the embedded code. DBC format is the commonly used engineering format for CAN, while FIBEX is commonly used for FlexRay. However, the DBC format is no longer adequate as a database format for the new Ethernet and IP-based system network.
From the perspective of tool suppliers, it would be helpful if OEMs could agree on a common engineering format. Suitable candidates would be FIBEX 4.0 and AUTOSAR System Description formats. Experience from other industrial fields indicates that tool producers would provide suitable development tools for analysis and code generation soon thereafter.