Evaluation Framework for MOST Based Driver Assistance Systems Based on Virtual Prototypes
The number of Advanced Driver Assistance Systems (ADAS) in a vehicle is continually increasing. These systems process the information from multiple sensors such as radar sensors, cameras or the Global Positioning System (GPS) for driver assistance. Because these sensors are distributed all over the vehicle, an efficient data communication network is needed to share the information between the different ADAS. Additionally, these systems often demand commonly used, complex processing algorithms like Fast Fourier Transformation or a Hough-Transformation. It could be beneficial to have dedicated pre-processing nodes for this common task, maybe with optimized hardware architectures. This increases the requirements for the distributed ADAS network. By providing an optimized communication network, the amount of wiring can be reduced. The MOST communication network offers many features that are required for such a task.
The MOST network technology offers a variety of configuration alternatives. They have to be assessed to find the optimal solution, preferably in an early design phase. To support the assessment, this article proposes an evaluation framework based on virtual prototyping. It reduces the evaluation complexity of such distributed, network-based applications.
Evaluation Framework – Use Case ADAS
The presented evaluation framework enables the functional and timing verification, performance and reliability analysis and supports design space exploration. One of the main focuses of the framework is modularity and a generic approach to enable the analysis of a variety of different system alternatives. Therefore, the virtual prototype-based framework is structured in a multitude of basic modules. These modules are aggregated to form the desired system, e.g., the ADAS use case scenario is assembled from around 150 module instances. An extract is shown in figure 1. This allows an easy alteration of the system, such as changing the communication channel, by just replacing or extending the existing system using the appropriate modules. With this approach, it is possible to easily integrate new applications using already existing IP components. The virtual system is configured using an .xml file, which allows easy assembling and configuration of the modules during runtime.
Figure 1: Modular structure of the virtual prototype
The distributed ADAS use case consists of two camera devices, a preprocessing module, a circle detection module, a speed sign classification module, a stereo depth map calculation module and a Human Machine Interface (HMI). The system contains two ADAS functionalities: the Stereo Depth Maps (SDM) and the Traffic Sign Recognition (TSR). The two systems share a common camera device and the image preprocessing module. The communication network has to forward the diverse image streams; the original camera images, the preprocessed images, clippings of the detected circles, the stereo depth map or the classified speed values. As per the role of a module, the demand on the underlying communication network differs. E.g. the pre-processing model requires a 1-to-n communication association to address multiple receivers. The camera image streams provide a continuous data stream; on the other hand, the clipped traffic signs appear in a burst-like manner. To reveal the impact of the communication technology, the camera streams of the stereo depth map application are analyzed in detail.
Influence of Communication Technology on Application
The stereo depth map calculation needs the synchronous delivery of the two preprocessed camera images. If the images are not associated with additional information like a sequence number, it is necessary that the receive buffers contain continuously synchronized camera images. Therefore, the communication network has to ensure that the left and right camera images are always transmitted in pairs between two subsequent read accesses. Different aspects of the communication network can affect this behavior. There could be permutations because of, e.g., a shared communication channel with nondeterministic access behavior. Different channel types or channel utilizations could result in varying delays, causing old image instances to be used.
Figure 2: Stereo depth map with displacement between left and right camera image (a) no displacement (b) one frame (c) two frames (d) three frames displacement
In figure 2 a stereo depth map with different displacements between the left and right camera image are shown. The nearby objects appear with warm colors, starting from red, and the distant objects appear in cold colors, like blue. The nearer the object, the warmer its color is, and vice a versa. In the upper left corner, the resulting image is shown with synchronous left and right images. It can be seen that the tree in the front (at the right corner of the image) is well detected. In the top right image, a displacement of one frame between the left and right camera is introduced. The depth information does not cover the complete tree. In the bottom right image, a displacement of three frames is inserted. It can be seen that the tree is almost undetected and that the information about the distance differs.
The isochronous channel of MOST is the best suited channel for this task. It offers a non-shared channel with a deterministic delay. Because of the continuous image stream, no bandwidth will be allocated unnecessarily. A huge benefit of this channel is that it allows a 1-to-n communication, enabling the reception of the camera image by the preprocessing device and the HMI, which calculates an overlay with depth information.
Optimization of System Parameters
Virtual prototyping can be used to determine optimal configuration parameters according to use case scenarios. The most crucial buffers in the ADAS scenario are located between the MOST device and the applications, as shown in figure 1. The buffers are divided into receive and transmit buffers. The receive buffer utilization is used as an example. The MOST data handler, which models the rudimentary behavior of the INIC, extracts / writes the data from / to the MOST frame. The data read is stored in the receive buffer every 20.833 us. On the application side, the buffer is read with the application interrupt rate. These read and write accesses have to be balanced to avoid buffer overflow and consequent data loss or retransmissions. In virtual prototypes, it is easily possible to monitor the buffer utilization e.g. with different application interrupt rates or with various traffic scenarios that influence the frame utilization.
Evaluation of Packet Channel Sharing Applications
A huge potential of virtual prototyping is the analysis of data traffic that depends on a variety of parameters. The evaluation framework allows capturing, monitoring, comparing and analyzing the data at the different junctions e.g. the data sent and received by applications, the data handlers, the different types of buffers or the data on the MOST bus itself. The data access points can be easily defined by the user in the configuration file. This allows the user to analyze the entire system behavior.
In the following use case, the behavior of two applications sharing the packet channel is analyzed. In the TSR scenario, the clipped images are transferred over the packet channel because no constant bandwidth allocation is necessary. In this scenario the influence of additional connections is evaluated. The first connection is based on the MOST High Protocol (MHP) while the second one is based on TCP/IP over the MOST Ethernet Protocol (MEP). The MHP is implemented by encapsulating the protocol from the NetServices and the TCP/IP protocol is implemented by encapsulating the open source lwIP – Lightweight TCP/IP stack.
Figure 3: Evaluation of a TCP/IP and MHP data connection with different tools
In figure 3, an extract of the generated tracing data is shown for a one sender and one receiver scenario. The lowermost graph shows four buffer overflows in the shared receive buffer. The second last graph shows the buffer utilization in bytes. The two graphs in the middle show the data sent, e.g. by the Circle Detection, (MHPOutNode01) and the data received, e.g. by the receiver HMI (MHPInNode00) respectively. It can be seen that two messages are lost, marked with the red circles, due to buffer overflow, and MHP retransmits the data at the end of the block. To verify the correctness of the behavior, MHP traffic trace can additionally be viewed with the OptoLyzer tool suit. As shown, MHP sends a MultipleFrameRequest for retransmission of frames 0x02 and 0x09.
The top two graphs show the data exchange from the MEP communication. To analyze these communications, the open-source packet analyzer Wireshark is used. In the presented use case scenario it is shown that the TCP/IP retransmission timeout, which was triggered by a frame loss due to the third buffer overflow, is long enough to allow the MHP connection to transmit one complete data set. This short example has shown how the evaluation framework can be used to give a detailed insight into system behavior. With the link to already existing analysis tools, a complete integration of the virtual prototyping approach is accomplished.
Conclusions
The above example of ADAS shows that during the system design, a variety of system parameters have to be determined. The different examples discussed above confirm how virtual prototyping can support the various decisions by providing a simulation-based analysis to assess different alternatives. The virtual prototypes allow a detailed insight into the system behavior. With the help of the already existing analysis tools, the behavior of the system can be analyzed with different system constraints. During the analysis of the TSR and SDM scenario, different benefits of the MOST bus have been utilized, such as the ability to transmit data simultaneously over the exclusive, isochronous channel and over the shared, packet channel, the possibility of addressing multiple receivers with one transmission or the integration of additional communication protocols such as TCP/IP.
About the Authors
Prof Dr. Oliver Bringmann
is Professor of the Wilhelm Schickard Institute at the University Tuebingen and Director at the FZI (Forschungszentrum Informatik) in Karlsruhe (Germany). bringman@informatik.uni-tuebingen.de
M. Sc. Jyoti Joshi
works as Research Scientist in the research division Microelectronic System Design (SiM) at the FZI (Forschungszentrum Informatik) in Karlsruhe (Germany). joshi@fzi.de
Sebastian Reiter
works as Scientific Employee in the research division Microelectronic System Design (SiM) at the FZI (Forschungszentrum Informatik) in Karlsruhe (Germany). sreiter@fzi.de
Prof. Dr. Wolfgang Rosenstiel
is Professor of the Wilhelm Schickard Institute at the University Tuebingen and Director at the FZI (Forschungszentrum Informatik) in Karlsruhe (Germany). rosenstiel@informatik.uni-tuebingen.de
Dr. rer. nat. Alexander Viehl
is Head of Department of the research division Microelectronic System Design (SiM) at the FZI (Forschungszentrum Informatik) in Karlsruhe (Germany).
viehl@fzi.de
Article previously published in Elektronik automotive, MOST Special Edition, April 2013, www.elektroniknet.de
If you enjoyed this article, you will like the following ones: don't miss them by subscribing to :
