Development of Driver Assistance Systems with CANape Version

Transcription

1 Development of Driver Assistance Systems with CANape Version

2 Table of Contents 1.0 Introduction Fundamental Requirements Synchronous Data Logging Calculating Virtual Signals Automated Data Evaluation Sensor-Based Systems Video Sensor Based Systems Optimizing the Algorithm in the ECU Developing Image Processing Algorithms for CANape Stimulation of Video Sensors Overview of Graphic Objects in the Multimedia Window D Objects D Objects Park Control Object Working with GPS Coordinates Outlook on Driver Assistance Development with Ethernet in the Vehicle Vector Informatik GmbH 2

3 1.0 Introduction CANape is a measurement, calibration, diagnostic and flash tool which is used for all tasks related to ECU optimization. To fulfill the special requirements of developing driver assistance systems, CANape can be extended with Option Driver Assistance. This option adds a verification solution for driver assistance systems and a test environment for optimizing image processing algorithms. Key elements of driver assistance systems include various sensors such as radar, laser, LED, sonic and videobased systems. CANape visualizes the sensor information from the different sources, so that users always have a clear understanding of the information in viewing, evaluating and tuning the parameters of their assistance systems. Fundamental requirements of a tool supporting development are: Synchronous acquisition of measurement data from different sources (e.g. CAN bus, ECUs, GPS, Video, analog and digital values, etc.), Calculation of virtual parameters from sensor data, and Automated evaluation of large amounts of data. Sensor-based systems supply data, e.g. distance values, which the user must verify to check the algorithm. A major problem here lies in checking the signal values, because the user does not know how the value was acquired. This results in requirements for: Displaying sensor data, and Visualizing video data from cameras to detect the surroundings. Video sensor based systems work with video data within the ECU. Depending on the video resolution and number of frames per second, the data volume of a video signal may be on the order of many megabytes per second. In optimizing image processing algorithms, the calibrator may need to obtain access to the video data in order to monitor the algorithm. This necessity leads to the following difficulties: How is the video data from the ECU measured? How is the video data from the ECU visualized? How is the image processing algorithm measured and calibrated? Another challenge for video sensor based systems relates to stimulation of the video sensor. It is nearly impossible to repeat the same stimulation of the video sensor on a test drive. In optimizing the image processing algorithms, CANape offers the ability to compute the algorithm directly as a DLL on the PC. This eliminates the tedious tasks of creating and flashing the binary file in the ECU. Therefore, it is necessary to stimulate the ECU or the DLL on the PC with logged video data. This document shows how these requirements can be fulfilled using the measurement and calibration tool CANape. Vector Informatik GmbH 3

4 2.0 Fundamental Requirements 2.1 Synchronous Data Logging The measurement data needed for development work generally comes from a number of different sources. This generally involves bus data (e.g. CAN or FlexRay) and data from the ECU. For meaningful analysis of the data, the time synchronism between the data must be assured. In data logging, CANape synchronizes the various sources and saves the measurement and video data in MDF or AVI format. All logged signals are saved to the MDF file, and the audio and video data is saved to the AVI file. Figure 1: Synchronous logging of different signal sources This assures that the display always shows synchronized data during the measurement. This synchronism is also preserved for later viewing and evaluation of the data. The various CANape display windows (e. g. time response in the Graphic window or numeric value display) are available to visualize the measurement data. However, it is difficult to verify the data supplied by the sensor if it is not known what the sensor actually detected. 2.2 Calculating Virtual Signals Often, interrelationships need to be created from data that comes from different types of sources. Examples include the relationship between the distance to the vehicle ahead and the relative speed between the vehicles. For example, if the distance to the vehicle ahead is 20 m, it is impossible to assess the probability of an accident in the specific situation based on this value alone. Not until the vehicle s own speed and the relative speed between the vehicles are known can it be determined whether or not a critical situation exists. Under some circumstances, this might result in actions by the brake assistant, seat belt tensioner and airbag. The measurement data originates from different systems. The distance is measured with the help of a radar system, and bus information from another ECU communicates the vehicle s speed to the radar system. From these values, the relative speed and time until a crash are calculated. Vector Informatik GmbH 4

5 You can also perform calculations like these external to the ECU. An extensive functional language is available in CANape; it can be used to obtain data during the measurement. Figure 2: Calculation of virtual signals in CANape CANape has an extensive internal functional library. You can extend the library with your own C programs or Simulink models. The functions are simply loaded in CANape as supplemental DLLs and made available. The DLL interface is described in detail and is easy to use. 2.3 Automated Data Evaluation Fully automated data evaluation is available, based on the ability to execute computations in CANape. The functional language in CANape can also be used to automate sequences in CANape. CANape offers you a special data mining functionality for automated data evaluation. Any desired search criteria may be defined in data mining. CANape searches through the selected measurement files based on these criteria and generates a report which gives you an easy way to access those measurement files that satisfy the search criterion. 3.0 Sensor-Based Systems These systems do not use video sensors to detect the surroundings, rather sensor types such as radar or ultrasonic sensors are used, as in ACC (Adaptive Cruise Control) or parking assistants. Challenge: Recognizing what the sensor really detected The sensor values generally cannot be checked by a person by pure observation. For example, if a vehicle ahead is detected by radar in an ACC system and the distance is indicated as 30 m, the calibrator working in the vehicle cannot really verify this value during the drive. It is also not always possible to determine whether the radar reflection originates from the vehicle ahead or from a guard rail on the side of the road. Solution: Log surroundings by video and show detected objects in the video image CANape enables logging and display of the surroundings by video cameras. Synchronous to this, the sensor signals are logged and shown overlaid in the video image as graphic objects, see Figure 3. Colored objects, such as red rectangles and blue triangles, show detected objects at the locations where they were detected. Therefore, users get direct visual feedback on what their sensors detected. Vector Informatik GmbH 5

6 Figure 3: Display of a video image with graphic objects (example: ACC) The Multimedia window is subdivided into three parts: the legend on the far left shows the object names and object type, the middle window section with blue background shows the objects on a distance grid, and the video image on the far right shows the video image from the camera with superimposed objects. In this example, the measurement data that leads to positioning of the objects was transmitted over CAN and looks like this: Figure 4: Each object acquired by radar is provided with x and y coordinates For one, a link must be produced between the measurement data and the graphic elements (e. g. object 1 of the sensor corresponds to the red rectangle). For another, it is necessary to establish a relationship between the distance and the pixel representation in the Multimedia window (e. g. distance to vehicle ahead is 50 m. Which position in the Multimedia window matches this distance?). The GFX Editor which is supplied with CANape can be used to produce the link between the measurement data and the graphic elements in the window. In this editor, the user assigns signals to: A graphic object type (see chapter 5.0 Overview of Graphic Objects in the Multimedia window), and Properties of the objects (color and line weight can also be modified as a function of measurement values; e.g. an object changes color from green to red if the distance drops below a minimum distance). Vector Informatik GmbH 6

7 Figure 5: Object definition and assignment to signal values in the GFX Editor All attributes of the object, such as its color, object type and line weight, can be conveniently edited in the GFX Editor. The link between the object and the measurement data is also made here. Synchronization of the display windows not only lets users model the parking process as a sequence; they can also select any time point using the measurement cursor. Figure 6: Window contents are synchronized to one another by the global measurement cursor The relationship between distance and pixel representation is defined by calibration of the Multimedia window. After the video camera has been installed in the vehicle, CANape offers the option of calibrating the Multimedia windows to the image data. With just a few clicks, the user defines how spatial coordinates should be converted to a pixel mapping. Vector Informatik GmbH 7

8 4.0 Video Sensor Based Systems Video sensors have direct connections to the ECU, and an image processing algorithm analyzes the video data. As a result, the Video data exists in the ECU. Challenge: Get access to the video data in the ECU Solution: Measurement equipment with sufficient bandwidth for data acquisition A high-performance measurement equipment solution enables measurement of the video data from the ECU. The video data is defined as an array in the ECU s memory and is transferred as an XCP data stream. Figure 7: Acquiring video data from the ECU with XCP The necessary performance is achieved using Vector VX1000 measurement and calibration hardware. Up to approx. 30 MB/s can be measured from the ECU, depending on its controller. The video data can be displayed, analyzed and edited in CANape exactly as data from a USB camera. Figure 8: Regardless of the source, the video data can be displayed, analyzed and processed Vector Informatik GmbH 8

9 4.1 Optimizing the Algorithm in the ECU The algorithm flow in the ECU is optimized by the same mechanisms as for all other ECUs. In CANape, the user uses the XCP standard and associated description file in A2L format to obtain read and write access to data in the ECU s internal memory. This lets users modify parameters and the necessary measurements, so that they can check the algorithm s functionality. 4.2 Developing Image Processing Algorithms for CANape Vector also supplies Visual Studio projects for different compiler versions with CANape, which can be used for development with manually created code. Users only need to integrate their functions in the project, and this makes it very easy to generate a DLL suitable for CANape. Measuring and calibrating the DLL The Vector project contains an XCP slave that lets you calibrate the DLL at runtime and measure values from the DLL. All you need is an A2L file for your algorithm. The solution with CANape offers you full support for generating an A2L. In the case of manual code development, you can simply generate an empty A2L in CANape, load the linker-map file for your code and conveniently copy the desired parameters from the linker-map file to the A2L file. In model-based code development, you use the CANape Target as the target platform. An A2L is automatically generated from the model. CANape provides a comprehensive package of library functions for model-based development with the MATLAB Integration Package. Figure 9: Library overview of the general data exchange between CANape and DLL Figure 10: Input and output functions for video data between CANape and DLL Figure 11: Example of display showing a Simulink model in CANape Vector Informatik GmbH 9

10 In Figure 11, the IP Input block serves as an interface that lets CANape feed a video signal into the DLL. The link is made in CANape, and the data source may be either camera data during a measurement or logged video files. The same algorithm is applied to video data from the different sources. 4.3 Stimulation of Video Sensors Test drives are necessary to optimize the algorithms in the ECU, but they are also complicated. One problem of outdoor test drives is that it is practically impossible to stimulate the video sensor in the same way multiple times in sequence. One reason is that lighting conditions are constantly changing due to changes in sunshine, clouds and other effects. Challenge: Minimize the number of test drives needed and stimulate the video sensor in a specific way Solution: Stimulate the sensor by video files If it is possible to connect to a VGA port on the ECU rather than to a video sensor, then CANape can output existing video files to the ECU over the PC. Figure 12: Stimulation with video file and CAN bus data This eliminates the need for costly and complicated test drives, and work is performed in the laboratory. The ability to keep reusing the same stimulation permits comparisons of the ECU s behavior as a function of the parameter values that are set. For example, in optimizing an adaptive cornering light, CANape sends video and CAN data to the ECU. Parameters are optimized and relevant variables are measured over XCP. Of course, the same approach also works if the algorithm is running as a DLL on the PC. Figure 13: Stimulation and parameter optimization with DLL Vector Informatik GmbH 10

11 5.0 Overview of Graphic Objects in the Multimedia Window This overview is based on CANape version 11.0, and no claims are made regarding its completeness D Objects Two-dimensional objects that are available are the checkmark, rectangle, triangle, text, bitmap and lines. Examples: Attributes of objects include: Color, size, line weight x, y, z position and offset Info string (value, format, etc.) Vertical and horizontal 2D line Cartesian and polar coordinates 5.2 3D Objects The following 3D objects are available: Lines and polynomials are used, especially in the development of lane detection assistants. 5.3 Park Control Object CANape offers the park control object specifically for the development of park assistants. It lets users represent the vehicle during parking phases, and it calculates and displays additional values such as the distance and/or angle to a reference point. The measurement data needed for this might be acquired by ultrasonic sensors and highly precise GPS measurements, for example. Vector Informatik GmbH 11

12 Figure 14: Description of the park control object Figure 15: Park control object in the Multimedia window The calculations of angle and distance shown here are not limited to the use of the park control object. They can essentially be applied to any object. 6.0 Working with GPS Coordinates You can acquire GPS positional data over the CAN bus as well as via a connected GPS mouse. The GPS coordinates can be visualized in a standard CANape window or in the special GPS window. This makes the relationship between the measurement data and vehicle position clearly discernible. Data interpretation of a rainlight sensor is easier if one knows, based on the GPS window, whether or not the vehicle was located in a dark and damp forest at that point in time. Vector Informatik GmbH 12

13 Figure 16: Different maps are available for the GPS window 7.0 Outlook on Driver Assistance Development with Ethernet in the Vehicle Current development projects involve the transfer of videos over Ethernet in the vehicle. One model that is being studied utilizes four 180 cameras to give drivers a full view of their own vehicles from a bird s eye perspective. The four videos are transmitted over Ethernet to a central ECU that combines the four images into one overall view. Ethernet in office communications relies on high-quality four- to eight-conductor cables (at least Cat-5 cable). In automotive applications, efforts are being made to avoid new components in the vehicle s wire harness. BroadR-Reach is an Ethernet physical layer that has been specially modified for automotive needs. Its special feature is that it implements high bandwidth with a simple unshielded twisted pair line conforming to the physical properties of a CAN line. Data is transmitted in full-duplex mode over a single twisted pair connection. Figure 17: IP protocols of automotive applications mapped to the OSI reference model; both new protocols (red) and protocols familiar from office communications (gray) are used Vector can support you here with professional tools, embedded software and services: Simulation, analysis and testing of embedded systems with Ethernet Basic software for communication over the Internet Protocol Diagnostic testing and flashing via DoIP (Diagnostics over IP) Services such as seminars and workshops, technical consultation and project support Vector Informatik GmbH 13

14 More information! Visit our website for: > News > Products > Demo software > Support > Training and workshops > Contact addresses Vector Informatik GmbH 14