Rapid Control Prototyping of Radar-based Active Safety Applications Using dspace MicroAutobox

Transcription

1 Rapid Control Prototyping of Radar-based Active Safety Applications Using dspace MicroAutobox Sebastian Mathew ABSTRACT Delphi Technical Center, India Many industries are under pressure to reduce development times when they produce unique and innovative products. Working efficiently is imperative for success in a globalized market, especially for high-tech industries such as automotive and aerospace, where electronic controls are a vital part of each new product. Model-based development processes have increasingly been adopted for the development of automotive embedded control software to help implement the complex systems and reduce the development time. This paper focuses on real-time verification of the control strategy for front Radar-based active safety feature functions such as Adaptive Cruise Control, Forward Collision Warning, Autonomous Emergency Braking, using dspace MicroAutobox (MABX) and ControlDesk Rapid Prototyping environment both on the test bench as well as on the actual vehicle. The paper also details the challenges faced in prototyping and testing such complex applications as well as how these challenges are overcome to make the dspace tools optimal for algorithm development and tuning. INTRODUCTION Delphi's multimode Electronically Scanning Radar (ESR) combines a wide field of view at mid-range with long-range coverage to provide two measurement modes simultaneously. While earlier forward looking radar systems used multiple beam radars with mechanical scanning or several fixed, overlapping beams to attain the view required for systems like adaptive cruise control, ESR provides wide coverage at mid-range and high-resolution long-range coverage using a single radar. Wide, mid-range coverage not only allows vehicles cutting in from adjacent lanes to be detected but also identifies vehicles and pedestrians across the width of the equipped vehicle. Long-range coverage provides accurate range and speed data with powerful object discrimination that can identify up to 64 targets in the vehicle's path. Figure 1. Multimode ESR

2 Delphi's technologically advanced Forward-looking ESR can be used to support Active Safety feature functions like Adaptive Cruise Control with Stop & Go (ACC S&G) Forward Collision Warning (FCW) Autonomous Emergency Braking (AEB) Headway Alert Adaptive Cruise Control is an extension of conventional cruise control which allows drivers to maintain a pre-set speed. The system automatically monitors the traffic patterns and adjusts the "closing" distance by using the throttle and the brakes to maintain a pre-set distance behind the vehicle ahead. Adaptive Cruise Control with Stop & Go extends the operation of Adaptive Cruise Control down to a stop. Once activated by the driver, ACC S&G will follow the vehicle ahead to a stop and keeps the vehicle stopped until the traffic ahead resumes movement and it is OK to go. Forward Collision Warning is a warning system that warns the driver of a potential threat imposed by a stationary or moving vehicle ahead of it in the same lane. Autonomous Emergency Braking provides additional braking support in the event of an imminent collision with a moving or stationary object. Headway Alert provides distance information and alerts the driver when the preset time-gap to vehicle ahead is violated. To speed up the product development for active safety systems, the control strategy for such complex safety critical feature functions are developed as Matlab/Simulink/Stateflow models which are validated on the test bench as well as on the vehicle using a Rapid Prototyping environment before the design is finalized for software implementation. Such complex systems require efficient standardized test processes including alternatives to test-track testing not only because test-track testing is expensive and time consuming, but also because it is potentially unsafe and critical to life. Furthermore, the reproducibility of the test scenarios in test-track testing is somewhat limited. CONTROL STRATERGY DEVELOPMENT AND VERIFICATION Frontal Radar-based feature functions including ACC, FCW, and AEB when activated perform supervisory control and behave like an autonomous driver who controls the vehicle by requesting the required acceleration and deceleration to the Engine and the Brakes based on the traffic input it receives from the radar sensor. Delphi s ESR can detect up to 64 targets in its field of view. In addition to this, the radar has internal algorithms that determine the Closest In Path Target (CIP) for each of these 3 feature functions from the 64 targets it tracks. All this traffic data along with the required host vehicle information is fed as input to the supervisory control algorithms which make an assessment based on the traffic ahead as well as the current vehicle state and generates the control signals to control the vehicle accordingly. Figure 2. Feedback Controller Model

3 These supervisory algorithms are closed loop control systems wherein the controller receives the inputs from various sensors (like Radar sensor, vehicle speed sensor, etc.) and generates control signals for the actuators which control the behavior of the plant. The output from the plant is fed back into the controller along with the inputs to form the closed loop as shown in Figure 2. In this case, the controller is the feature function supervisory control algorithms and the plant consists of the Radar Sensor and various other parts of the vehicle that the controller tries to control. Thus, we see that we are dealing with highly complex safety critical supervisory control strategies which should perform consistently under all kinds of input/traffic scenarios wherein there is no tolerance for failure. This requires the control algorithm to be validated and verified thoroughly before the design is finalized for software implementation. To reap the benefits of model based development (MBD), the control strategy for these feature functions are developed as executable specification using Matlab/Simulink/Stateflow which is verified on the host computer as well as on the actual vehicle using a Rapid Prototyping environment. Typical modern day control software for automotive applications undergoes four stages of verification as shown in Figure 3. Offline Simulation Rapid Control Prototyping Hardware In Loop Simulation ECU Validation Figure 3. Control Strategy Verification Stages The first two stages of verification are intended for verifying the functional performance of the control algorithm. It is performed on the control strategy model (specification/algorithm) before the production software is generated and is dealt with in detail in this paper. The last two stages of verification are performed on production software embedded in the final Electronic control unit (ECU).

4 OFFLINE SIMULATION This is the first stage of verification wherein we have the Controller and Plant models placed in the same Simulink model on the host computer so as to have a closed loop simulation. The plant model in this case consists of a Radar simulation model that simulates the behavior of the radar, basic engine model, brakes model, vehicle dynamics model, etc. as shown in Figure 4. The plant models are validated against actual data collected from the vehicles. These models can be configured for different types for powertrain and chassis combinations. Figure 4. ESR Virtual Test Bench The yellow block in Figure 4 is the controller model that contains the control strategy for ACC, FCW, and AEB, etc. The model acts as a virtual bench which can be used for the preliminary validation and verification of the control algorithm s performance under various input scenarios. Since this is an offline simulation performed on host computer, it does not represent the real-time behavior of the control strategy on the actual vehicle where it is eventually expected to perform. RAPID CONTROL PROTOTYPING As we have already mentioned, the real-time performance of the supervisory algorithm can be evaluated only by testing the algorithm on the real environment of the vehicle. The Active Safety Controller Module (ASCM/ECU) that hosts the supervisory control algorithms communicates with all other ECUs (nodes) in the vehicle through the vehicle CAN network. Delphi s ESR has its own dedicated CAN channel known as the Radar CAN/ ESR CAN through which the target parameters for each of 64 targets it tracks is made available to other ECUs in the vehicle network. Thus, the ASCM controller receives traffic inputs and all the other vehicle inputs required by the control algorithm from the CAN network. The control signals generated by the supervisory controller (ASCM) are sent to other control units (ECUs) in the vehicle over the same CAN network.

5 The dspace Microautobox (MABX) hardware with Control Desk software is selected as the Rapid prototyping environment for testing the real-time performance of control strategy on the vehicle as it highly reliable, fast, and compact, and has all the required I/O interfaces. The fact that CAN is the only medium of external interface for the Active safety controller module (ASCM) makes it ideal for rapid control prototyping using dspace Microautobox MABX_11/1401/1507 (variant) as it has two dedicated CAN controllers with a total of 4 CAN channels available. RTI CAN block set is used for incorporating the real-time interfaces required for configuring the MABX to communicate over the CAN. Figure 5. dspace Model Block Diagram The first step for Rapid Control Prototyping is to prepare a dspace version of the controller model by incorporating the dspace Real Time Interface (RTI) blocks for the corresponding model inputs and outputs. The block diagram representation of the dspace controller model is shown in Figure 5. The RTI CAN Controller Setup Block placed in the model is configured to communicate over two CAN channels, namely, the Radar CAN and the Vehicle CAN. The dspace Receive Block contains the RTI CAN receive blocks configured for receiving the Radar and Vehicle CAN messages (control strategy inputs) while the dspace Transmit Block contains the RTI CAN transmit blocks configured for transmitting the control signals from the controller over the vehicle CAN. In some cases, the Radar CAN may be used for logging internal model signals for instrumentation purposes. The next step is to compile the dspace model using the Real Time Workshop code generator. The Real Time Workshop is configured to compile the model for DS 1041 Hardware Platform (MABX) by selecting the rti1401.tlc target language complier provided by dspace. Upon successful completion of the build process, the following files are generated <model_name>.sdf :- System Description file for loading the executable from the ControlDesk <model_name>.ppc:- Executable file for the Power PC processor in the MABX <model_name>.trc :- Trace file for navigating through the model from the ControlDesk <model_name>.map:- Contains the memory address information

6 The dspace ControlDesk test and experiment software provide the user interface which connects MABX hardware to the host PC through an Ethernet (TCP/IP) high speed link as shown in Figure 6. The executable file (<model_name>.ppc) gets loaded automatically into the MABX using the TCP/IP high speed link at the end of the build process. Another option for the user is to load the executable file manually from the ControlDesk by choosing the corresponding System Description file (<model_name>.sdf). The Control Desk provides access to monitor and capture internal model variables as well as perform calibration of the algorithm at run time. MABX can be used in the following ways for real-time performance analysis and calibration of the control algorithm: Connect the MABX to the actual vehicle on which ESR is fitted. Connect the MABX to a test bench which simulates the behavior of the radar and the vehicle in real-time using the same plant models that were used for the offline simulation of the control strategy. RAPID PROTOTYPING USING MABX ON THE VEHICLE The most authentic and straightforward method to analyze the real-time performance of the control algorithm is to connect the MABX to the CAN network of the actual vehicle were it is finally expected to perform. The MABX is connected to the two CAN channels in the vehicle, namely, the Radar CAN and Vehicle CAN, as shown in Figure 6. The MABX behaves like any another ECU on the vehicle and generates the control signals for the other ECUs (Engine controller, brake controller, body computer, etc.) based on the traffic and host vehicle information it receives over the CAN. The performance analysis and the calibration of the algorithm are completed using the ControlDesk. Vehicles equipped with dspace MABX are used for test track testing as well as for real-world road tests over thousands of miles thereby validating the performance and robustness of the control algorithm against dynamic traffic scenarios. Figure 6. dspace MABX Vehicle Test Setup

7 Performance validation using MABX on the vehicle has the following advantages:- Algorithm validation happens in the real environment of the vehicle where it is eventually expected to perform. This is critical for calibrating the algorithm according to the powertrain and chassis characteristics of the particular vehicle platform for which it is designed. Algorithm is validated for performance in different kinds of real-world traffic scenarios, road profiles and weather conditions, all of which cannot be simulated on the test bench. This is vital in evaluating the performance robustness of the Radar sensor as well as that of the control strategy under all conditions. The standalone executable files for the MABX (<model_name>.ppc, <model_name>.sdf etc.) can be provided to the Original Equipment Manufacturer (OEM) for performance validation of the control strategy on a MABX equipped vehicle without the supplier exposing the confidential supervisory control models. This allows the OEM to perform black box testing of the control algorithm and the design can finalized for implementation once OEM is satisfied with the performance. The Radar and Vehicle CAN data logged during vehicle test drives can be used for offline performance analysis of the Radar sensor as well as that of the control strategy. Delphi uses an internally developed tool known as the DV tool for logging and analyzing the Radar sensor performance. Offline analysis of the DV logs is critical for root cause analysis and resolution of the algorithm failure scenarios encountered during the test drive. However, performance validation using MABX on the vehicle has the following shortcomings or disadvantages:- Test-track testing is expensive, time consuming and potentially unsafe yet critical to life. The reproducibility of the test scenarios in test-track testing is limited. Robustness and diagnostic testing of the algorithm such as ECU failure mode analysis, sensor or actuator failure, etc. is extremely difficult to perform on the actual vehicle. There is always the risk of the control algorithm not being evaluated for all possible traffic or road conditions such as those never encountered during the test-track or real-world driving. Availability of the vehicle (or it variants) to perform validation is always a concern, especially in the early stages of the control development when the OEM itself may not have built a vehicle reliable enough to be given to the supplier for performance evaluation. In addition, there may be situations where the person who develops the control strategy may not have access to the vehicle for which the algorithm is developed. All these factors necessitate the need to perform bench testing of control strategy using MABX. RAPID PROTOTYPING USING MABX ON THE TEST BENCH To perform validation of such safety critical, closed loop control systems on the bench, the bench test setup should be capable of simulating the behavior of the radar and vehicle in real time. Since the control strategy in the MABX communicates with the rest of the vehicle entirely through the CAN network, the test bench should be capable of transmitting all simulated radar and vehicle input signals expected by the control strategy over the Radar and Vehicle CAN respectively within the timing requirement of the respective CAN messages. In addition, the test bench should be capable of responding to the CAN vehicle control signals generated from the control algorithm and modifying the response of the simulated vehicle accordingly. The simplest approach to simulating the radar and vehicle behavior on the bench is to make use of the radar and vehicle simulation plant models which are already used for the offline simulation of the control strategy. In this scenario, the major

8 challenge for the developer is to design these plant models for offline simulation in the Matlab environment, simulating real-time transmission and receipt of the required CAN messages. This is achieved by simulating the Simulink plant models inside the Vector CANoe network simulation environment using the Matlab-CANoe Interface tool box shown in Figure 7. The plant models are modified to incorporate the Matlab CANoe interface I/O blocks for the model input and outputs as shown below. Figure 7. CANoe Network Simulation Plant Model To obtain real-time performance on the network simulation bench, the models are simulated from the Canoe environment in Hardware in Loop (HIL) mode. In this mode, each plant model is built using Real Time Workshop by selecting cn.tlc target language compiler provided by Vector to generate a Windows DLL which can be loaded into the CANoe environment. Each DLL generated acts as a node in the CANoe network simulation environment as shown in Figure 8. Figure 8. Vector CANoe Vehicle Network Simulation Setup Monitoring of the internal model signals and calibration /parameterization of the plant models can be performed from the CANoe environment in the HIL mode also.

9 Figure 9. CANoe Network Simulation Test Bench Trace Thus, by using the combination of CANoe network simulation, radar model and vehicle plant models, we are able to create real time simulation bench which can be used for the performance evaluation and calibration of the control strategy in the MABX. The MABX test bench setup is shown in Figure 10. Figure 10. dspace MABX Bench Test Setup The performance of the algorithm can be monitored either using the ControlDesk or by monitoring the control signal generated by the algorithm on the CAN bus using analysis tools like Vector CANalyzer as shown in Figure 11.

10 Figure 11. Vehicle Control Signals from MABX Performance validation using MABX on the test bench has the following advantages:- Ability to perform performance analysis and preliminary calibration of the algorithm even before the actual vehicle is available Ability to test the algorithm for traffic scenarios that may be difficult to produce in the test track or real-world driving Bench testing is much cheaper and safer than test track testing. Test Bench can be used to replay the problem scenario DV logs captured during real world driving on the MABX for root cause analysis and resolution. The bench setup can be easily modified to perform diagnostic and failure mode testing which may be difficult to perform on the actual vehicle. The plant models can be configured for various powertrain and chassis combinations thereby enabling the developer to calibrate the algorithm for different vehicle platforms. The same bench setup can be used for the performing preliminary Hardware in Loop (HIL) testing of production software embedded in the final Electronic control unit (ECU). CONCLUSION AND FUTURE IMPROVEMENTS Thus, we see that rapid control prototyping maximizes the benefits of model-based development and plays a very important role in the feature development of active safety systems. Performance analysis using dspace MABX is critical for early detection and removal of deficiencies in the control design which has a significant impact on the development cost as well as the time to market of the product. Prototyping using MABX increases the confidence in the robustness of the control algorithm which is absolutely vital for such safety critical feature functions that are expected to perform consistently in all dynamic input scenarios. By using a judicious mixture of the vehicle and bench level testing using MABX, the quality of the control strategy developed is increased greatly whereas the development time is reduced significantly.

11 One future improvement to current process would be to have an improved bench simulation test setup with dspace HIL simulator that has Automotive Simulation Models (ASM) running on it, replacing the current CANoe-based solution. This would improve the capability to simulate diverse traffic, road and weather conditions on the bench thereby reducing the amount of effort required for the vehicle testing. ACKNOWLEDGMENTS The author would like to acknowledge and thank the model development teams in Delphi Technical Centers in Bangalore, India; Auburn Hills, USA; and Wuppertal, Germany for all the contributions and guidance in development of the tools and processes described in the paper. REFERENCES Vector Application Note AN-IND Using MATLAB with CANoe 7. Simulink Modeling for Vehicle Simulator Design- Chandrakantha Ursu, Ramachandra Bhat K and Ramkumar Damodaran 2009 SAE International 8. Defect Identification with Model-Based Test Automation - Mark Blackburn, Aaron Nauman, Bob Busser, Bryan Stensvad 9. Rapid Prototyping and Hardware-in-the-Loop Simulation with xpctarget Mike Dickens, mdickens@mathworks.com 10. Engine Plant Model Development for HIL System and Application to On-Board Diagnostic Verification- Yixin Chen, Jeffrey Pfeiffer and Ken Simpson-Delphi Corp SAE International CONTACT Sebastian Mathew Technical Leader Active Safety Sebastian.Mathew@delphi.com