A camera-based driver assistance system at BMW will be the first production implementation in the motor vehicle to utilize IP and Ethernet as the system network in the vehicle . OEMs and suppliers will use the new BroadR-Reach physical layer to save on weight and costs compared to currently used LVDS technology , , . BroadR-Reach will be licensed by other producers .
An example of a camera system network is shown in Figure 1 together with potential measurement points. As an alternative, it would also be possible to connect all cameras directly via a switch. As in bus systems used so far in the motor vehicle, the data traffic must be observed, analyzed and compared time-synchronously at various points in the network. Therefore, the measurement hardware must initially support the current bus physics (e.g. BroadR-Reach), but must also be open to future physical layers.
Desirable are multi-channel taps via tee-couplers, which disturb the system network as little as possible in monitoring. The tee-coupler should also be capable of injecting errors to validate system functionality. Beyond analysis tasks, stimulation or even simulation of entire sections of the network is also required (remaining bus simulation). This poses certain challenges on the measurement hardware.
Figure 1: Reliable analysis of camera-based driver assistance systems requires monitoring the data traffic at multiple points of the Ethernet network, ideally via “tee-couplers” with as little time offset as possible and with a common time base.
In the camera application, there are heightened requirements related to time synchronization and Quality of Service (QoS) . They should be addressed by protocol extensions of the Audio Video Bridging standard (AVB) . Now that manufacturers have appeared to reach agreement on the bit transmission layer (OSI Layer 1), standardization is being sought in higher layers as well for cost and testing reasons.
If only because of the different protocols used in the camera application, there are new requirements for the measurement software, so that any desired signals from the payload of the various, some quite complex, protocols can be presented and manipulated according to the application. The “Audio/Video” and “Control Communication” columns of Table 1 (based on  and Vector) show the protocols used for AVB.
Table 1: IP protocols of automotive applications mapped to the OSI reference model (left-side columns) including administrative functions (right-side columns): Both new protocols (red) and those known from office communications (gray) are used. For full resolution click here.
There are also protocols for bandwidth reservation and other network management protocols (Table 1, four columns on the right). These and other protocols listed in the table were added based on the application cases considered below.
2. Diagnostic access
Using “Diagnostics over IP” (DoIP) technology, it is possible to centrally flash all ECUs connected to the various bus systems via high-performance Ethernet access (Figure 2).
Figure 2: In validation of DoIP at a gateway, it is important to represent the data traffic both on the DoIP side (to left of the gateway) and on all connected bus systems (to right of the gateway). Ideally, all messages of all networks are transmitted with a common time base.
System development at the OEM must validate this service. Since an ECU is used as the gateway, not only is there great interest in analyzing the transmission of diagnostic data in the various connected bus systems, but on the IP side as well. Relevant protocols are ISO 13400 and IPv4, and possibly IPv6 as represented in Table 1.