Deliverable D54.3 Active Green Driving: 1 System Functionality

Transcription

Highly automated vehicles for intelligent transport
7th Framework programme
ICT-2007.6.1
ICT for intelligent vehicles and mobility services
Grant agreement no.: 212154
The future of driving.
Deliverable D54.3
Active Green Driving:
st
1 System Functionality
Version number
Dissemination level
Lead contractor
Version 0.4
CO, PU
Continental Automotive GmbH
Due date
31.10.2010
Date of preparation
22.08.2011
HAVEit
22.08.2011
Authors
Name
Company
Martin Sanfridson
VTEC
Astrid Lundgren
VTEC
Johan Jarlengrip
VTEC
Grant Grubb
VTEC
Lei Feng
VTEC
Maria Bruce
VTEC
Project Managers
Prof. Dr. Alfred Hoess
Siemensstrasse 12
93055 Regensburg, Germany
Phone +49 941 790-5786
Telefax +49 941 790 99 5786
E-mail: [email protected]
Holger Zeng
Siemensstrasse 12
Phone +49 941 790 92330
Fax. +49 941 790 99 92330
E-mail: [email protected]
Project Co-ordinator
Dr. Reiner Hoeger
Siemensstrasse 12
Phone +49 941 790 3673
Fax
+49 941 790 13 3673
E-mail [email protected]
Copyright: HAVEit Consortium 2010
D54.3 Active Green Driving
1st System Functionality
2
HAVEit
22.08.2011
Revision and History Chart
Version
Date
Reason
0.1
01.10.2010 First version, a compilation and read through
(Martin Sanfridson)
0.2
22.10.2010 Revision at internal review (Martin Sanfridson)
0.3
13.11.2010 Final editing and submission
0.4
22.08.2011 Rewording of sentence according to reviewers
comments
06.10.2011 Final editing and preparation of final version for
submission to EC; generation of reduced
deliverable version intended for publication
3
HAVEit
22.08.2011
Executive Summary
The overall objective of the HAVEit project is to develop technical systems to improve automotive safety and efficiency. In WP5400, Volvo Technology contributes to the overall objective by
developing a fuel efficiency focused Active Green Driving (AGD) application.
This document reports on the first results of the AGD application. In all parts of the application,
simulation on desktop PC and on more elaborated driving simulators with drivers in the loop,
have been planned steps in the development.
In the AGD application, information obtained by sensors installed on the demonstration vehicle
to monitor the external traffic environment, are used to predict the future driving horizon. By predicting near future changes (within the horizon), as for example speed and elevation, the, in the
best case optimal, use of the demonstration vehicle‟s hybrid powertrain can be found and executed automatically without intervention from the driver. The key difference to a conventional
powertrain is the brake regeneration and temporary storage of electrical energy. Furthermore,
without restrictions to the kind of powertrain deployed, information within the prediction horizon is
also used in a Driver Coaching System to help the driver handle the vehicle in a more fuel
efficient manner by advice via graphical display and haptic accelerator pedal. These are the
functionalities that are evaluated in this report.
The AGD demonstration vehicle is up and running as a test bench for speed and load prediction
and subsequent optimal control of the powertrain and for driver coaching. The prediction is
based both on static route information taken from the in-vehicle database, using GPS to acquire
the vehicle‟s position such as maximum likely speed and bus stops, but it is also based on
dynamic traffic ahead taken from the front mounted laser scanners. The first vehicle tests show
that the estimation of future vehicle speed works well.
Currently, there is work in progress to make the prediction more robust. The Energy Management works well in simulation and shows that fuel actually can be saved. The functionality is
currently deployed in the vehicle, but the installation has not been completely debugged. The
Driver Coaching System has been installed in the vehicle, including screens and haptic pedal,
and tests finalized within one month. To complement the previous report [6], additional results
from the sensor installation and integration will be described.
4
HAVEit
22.08.2011
Table of Contents
Executive Summary....................................................................................................................................... 4
Table of Contents .......................................................................................................................................... 5
List of Figures ................................................................................................................................................ 6
List of Tables ................................................................................................................................................. 7
1 Introduction ............................................................................................................................................. 8
2 Active Green Driving ............................................................................................................................ 10
2.1
Functionalities ............................................................................................................................... 10
2.1.1
Speed and load prediction ..................................................................................................... 10
2.1.2
Energy Management ............................................................................................................. 13
2.1.3
Driver coaching ...................................................................................................................... 14
2.2
Architecture ................................................................................................................................... 16
2.2.1
Architecture and bus structure ............................................................................................... 16
2.2.2
Adaptation of the generic HAVEit architecture and deployment ........................................... 17
2.2.3
AGD specific architecture modifications ................................................................................ 20
3 Demonstrator configuration .................................................................................................................. 21
3.1
Perception layer: Sensors ............................................................................................................. 21
3.1.1
Laser Scanners ...................................................................................................................... 21
3.1.2
V2V ........................................................................................................................................ 23
3.1.3
Sensor Data Fusion (SDF) .................................................................................................... 26
3.2
Command layer: Joint System ...................................................................................................... 28
3.3
Execution layer: actuators ............................................................................................................. 30
3.4
Driver interface .............................................................................................................................. 32
3.4.1
Driver‟s display....................................................................................................................... 33
3.4.2
Demonstration passengers‟ display ....................................................................................... 36
3.4.3
Haptic gas pedal .................................................................................................................... 37
3.5
System integration ........................................................................................................................ 37
4 Preliminary AGD system validation ...................................................................................................... 39
4.1
Relevant use cases and scenarios ............................................................................................... 39
4.1.1
AGD use case 1: Predicted deceleration and acceleration ................................................... 39
4.1.2
AGD use case 3: Predicted downhill (uphill) driving .............................................................. 40
4.1.3
DCS use case 1: Speeding .................................................................................................... 40
4.1.4
DCS use case 5: DCS Report – Post trip feedback .............................................................. 42
4.2
Scenario 1: AGD use case 1 ......................................................................................................... 43
4.3
Scenario 2: AGD use case 3 ......................................................................................................... 44
4.4
Scenario 3: DCS use case 1 – Speeding ..................................................................................... 45
4.5
Scenario 4: DCS use case 5 – Post trip feedback ........................................................................ 48
5 Conclusions .......................................................................................................................................... 49
References .................................................................................................................................................. 50
Annex 1: Keywords ...................................................................................................................................... 51
5
HAVEit
22.08.2011
List of Figures
Figure 1: Sensor location overview of the WP5400 demonstration vehicle .................................................. 9
Figure 2: Schematic flow diagram of the AGD Speed and Load prediction. ............................................... 11
Figure 3: Schematic flow diagram for the Energy Management (using maps). .......................................... 13
Figure 4: Schematic flow diagram for the Driver Coaching System. ........................................................... 15
Figure 5: Network topology.......................................................................................................................... 16
Figure 6: Top view of installed sensors and control units on the demonstrator vehicle .............................. 17
Figure 7: Architecture overview of the HAVEit AGD system ....................................................................... 18
Figure 8: AGD deployment diagram, with functional modules and layers .................................................. 19
Figure 9: Top view laser scanner visualization, with accompanying video ................................................. 22
Figure 10 Object distance measurements for the scene in Figure 9 .......................................................... 23
Figure 11: The vehicles used for V2V system verification .......................................................................... 24
Figure 12: Test route driven during part of the V2V communications testing ............................................. 25
Figure 13: Graphs indicating the transmission of CAN messages transmitted in V2V testing ................... 25
Figure 14: Sensor data fusion architecture ................................................................................................. 26
Figure 15: Example SDF visualization for tracked objects .......................................................................... 27
Figure 16: Speed prediction as a function of distance. Blue line is predicted and red is actual. ................ 29
Figure 17: Speed prediction as a function of time. Blue line is predicted and red is actual. ....................... 29
Figure 18: Torque prediction as a function of distance. .............................................................................. 30
Figure 19: Vehicle speed (left axis, blue line) and gas pedal (right axis, fat green line). ............................ 31
Figure 20: Generated torque by combustion engine (left, yellow) and mass flow of fuel (right, green). ..... 31
Figure 21: Electrical machine torque (left, yellow) and state of charge (right, green). ................................ 32
Figure 22: Examples of GUI‟s of the second version. ................................................................................. 33
Figure 23: Example of the popup strategies. ............................................................................................... 34
Figure 24: Example of the GUI for the post trip feedback screen. .............................................................. 35
Figure 25: Hybrid driveline and prediction horizon view. ............................................................................. 36
Figure 26: Drivers view GUI and prediction horizon view. .......................................................................... 36
Figure 27: Haptic gas pedal installation ...................................................................................................... 37
Figure 28: Predicted deceleration followed by acceleration. ....................................................................... 39
Figure 29: Uphill (downhill) driving. ............................................................................................................. 40
Figure 30: DCS use case 1 actor events ..................................................................................................... 41
Figure 31: DCS use case 5 actor events ..................................................................................................... 42
Figure 32: Energy optimization during a start and stop drive cycle ............................................................ 44
Figure 33: Energy optimization during a single hill drive cycle .................................................................... 45
Figure 34: Driving simulator......................................................................................................................... 46
Figure 35: Driving simulator interior setup ................................................................................................... 46
6
HAVEit
22.08.2011
List of Tables
Table 1: Summary of installed sensors and their capabilities ....................................................................... 9
Table 2: Summary of output data from the SDF system ............................................................................. 27
Table 3: DCS user comments ..................................................................................................................... 47
7
HAVEit
1
22.08.2011
Introduction
The intention of this document is to report intermediate results of the AGD application and from
the demonstration vehicle. After this brief introduction, the functional architecture and deployment structure will be described (section 2). In the following section 3 the turn comes to
subsystem verification (i.e. comparing with requirements) and the results from the first field test.
In section 4 the intermediate validation will be presented following the sample use cases set up
prior to the work. Requirements and specifications for the AGD application and the demonstration vehicle are found in [1] and [2]. Previous documents have reported on sensor installation
[5], and the functional architecture [6].
The main goal of the Active Green Driving is to reduce the fuel consumption and potentially
emissions in a heavy hybrid demonstrator vehicle by using an e-Horizon system enhanced with
environment sensors. This is accomplished by two quite different strategies, both relying on the
continuous prediction of vehicle speed:
1. A fuel optimal powertrain strategy, where the overall control objectives are, for any moment in time, to decide:
the power-split between the electrical machine and the internal combustion engine,
temporary switching on and off the internal combustion engine, and
gear shifts by considering powertrain efficiency at selected revolution speed and
torque.
2. A driver support interface to give driving recommendations, in certain defined situations,
using both graphical and textual information and by haptic feedback in the accelerator
pedal. The objective is of course to minimize fuel consumption.
None of these strategies offers automated driving – the driver is in charge of acceleration and
deceleration in the traditional way. The first strategy simply accepts the driver‟s behaviour and
adjusts the powertrain accordingly, and the second strategy tries to influence the driver by giving
advice. The two strategies work independent of each other.
To accelerate the hybrid vehicle, the driver effectively requests a torque to the wheels. The
requested torque has to be realized by the powertrain actuators. In a hybrid vehicle, there is
more flexibility, compared to a conventional vehicle, to realize this torque. The demonstrator
vehicle has a parallel powertrain which means the power to the wheels can at any moment be a
mix of power from the combustion engine and power from the electrical machine. When the
driver brakes, kinetic energy is recuperated by operating the electrical machine as a generator
and store the electrical energy in the high voltage battery.
The e-Horizon system provides information about future driving conditions several minutes
ahead of the vehicle. The information from this system is of static nature, which means that it
does not change from time to time during the same route. Typical information provided is speed
limits of the road and the location of, for instance, traffic lights, roundabouts and altitude. The
other three sensor systems, the laser scanner, the camera and the V2V communication, give
environmental information about future driving conditions a few seconds ahead of the vehicle. All
sensors combined will provide the demonstration vehicle, a Volvo city bus, with information on
the long term static road conditions as well as short term dynamic traffic environment in front of
the bus.
8
HAVEit
22.08.2011
Electronic horizon
Color camera
IR-V2V
communication
Laser scanners
Figure 1: Sensor location overview of the WP5400 demonstration vehicle
The environment sensors in Table 1 are described in detail in [5]; see also Figure 1 for an
overview.
Sensor
Measured Quantities
Range
Field of View
Laser scanners
Frontal objects, road
data
150 m
150 degrees
Colour camera
Traffic light data,
objects (if possible)
50 m
60 degrees
IR-V2V (vehicle to vehicle)
communication
Data received from
the preceding vehicle
15/50 m (two
modes used
simultaneously)
25/10 degrees
(two modes used
simultaneously)
Electronic horizon
Coordinates & map
data
-
-
Table 1: Summary of installed sensors and their capabilities
9
HAVEit
2
22.08.2011
Active Green Driving
In this section we will dive into AGD application to explain how it works internally and how it is
structured according to the HAVEit architecture.
2.1 Functionalities
The two main functionalities in AGD are
Energy management, and
Driver coaching.
The quality they deliver relies heavily on input from two important auxiliary functions:
Sensor fusion, and
Speed and load prediction.
The speed and load prediction gets its input in an array that represents preview information
assembled by sensor fusion of the external sensors, but also some vehicle internal signals, such
as the vehicle speed.
A good description of sensor fusion can be found in [6]. In this section speed and load prediction, energy management and driver coaching will be treated. These functionalities are executed
mainly on the hardware unit called AGD-ECU. For an overview of the hardware installed in the
demonstration vehicle for the AGD project see Figure 5.
2.1.1
Speed and load prediction
The main functions and interfaces of the speed and load prediction are presented in the signal
flow diagram in Figure 2. Different shapes and colours are used in the flow diagram to denote
internal process (light blue), external process (dark blue), data signals and database (turquoise).
Yellow boxes are used to label the conveyed signals which are symbolized by the arrows.
The rough order of processing according to Figure 2 is to first read and handle the external input
and to continue with vehicle internal status and driver behaviour. The speed and load prediction
takes the vehicle‟s coordinates from the navigation device, based on GPS. To get a more
reliable vehicle position filtering is necessary. There is an option, especially in situations with
poor reception, to activate a Kalman filter which utilises speed, yaw rate and inclination of the
vehicle to calculate an enhanced prediction of the current position, [8].
The map matching translates the position from the coordinate system used by the GPS into a
new coordinate system that is more suitable when later extracting data from the eHorizon route
database which holds stored routes. First of all the application needs to know which of the
stored routes the user has planned to drive. This can be set via the driver‟s HMI or from the
AGD-ECU, but it is also possible to search for the closest stored route. It is assumed that a route
exists.
10
HAVEit
22.08.2011
GPS
Signals from Vehicle CAN
Vehicle speed
Yaw rate
Inclination
Position coordinates
Filtering
Map matching
eHorizon
Route
Database
Route identifier
Route distance
Sensor Fusion
eHorizon provider
Road slope position and angle
Speed limit position and value
Event position and type
Curvature position and magnitude
Current vehicle position
Preceding vehicle data
Preceding fixed object data
Traffic light state
Signals from
Vehicle CAN
Vehicle Speed
Speed Plan
Road slope position (m) and angle (%)
Speed position (m) amd Speed plan (m/s)
Speed plan limit attribute (numeral)
Current vehicle position
Signals from Vehicle CAN
Vehicle Speed
Vehicle acceleration
Vehicle mass
Speed and Torque prediction
with driver model
Predicted vehicle speed array
Predicted required torque array
Energy Management
Driver
Coaching
System
Display of
prediction and
powertrain status
Figure 2: Schematic flow diagram of the AGD Speed and Load prediction.
11
HAVEit
22.08.2011
When a set of data points within a predefined maximum distance from the current filtered position is found in the database, the search for the closest data point will be performed along those
points. The distance from the current position to a point on the route is defined as the orthogonal
projection from the current position point to the road. The travelled distance from the start of the
route will be the new position coordinate which is the lookup key to the database: Route
distance. The eHorizon data function uses this information to extract a horizon of road attributes.
The eHorizon route database has the following main attributes:
Speed limit position [m]
Speed limit [m/s]
Number of speed limit pairs
Event position [m]
Event type
o
speed bump
o
give way sign
o
pedestrian crossing
o
roundabout
o
traffic light
o
bus stop
o
stop sign
Number of event pairs
Curve position [m]
Curvature value [1/m]
Number of curvature pairs
Slope position [m]
Slope value [ ]
Number of slope pairs
From the sensor fusion an array of preview information is constructed and continuously updated.
This is derived from the laser scanners and the colour camera and consists primarily of the
speed of and distance to any vehicle in front, the distance to the nearest fixed object in front and
the state of the nearest traffic light ahead.
Next, information from the database and from the sensor fusion are combined in the process
called speed plan. The output from the speed plan will be an expected upper limit of the vehicle
speed over a distance horizon. Thereafter the speed plan is converted to a time vector and
driver behaviour is taken into account. The torque necessary to propel the vehicle is also calculated based on known physical properties using Newton‟s second law. The result is later used by
the Energy Management and the Driver Coaching System.
12
HAVEit
2.1.2
22.08.2011
Energy Management
Speed and load
prediction
Predicted vehicle speed array
Predicted required torque array
State of Charge
Equivalence factor
calculation module
Equivalence
factor
Electric Motor torque
Diesel engine torque
Hybrid powertrain
Maps module
Suggested gear
Gear shift cost
Suggested Mode
Mode cost
Current gear
Desired torque
Current speed
Current Mode
Cost evaluation module
Requested gear
Requested mode
Figure 3: Schematic flow diagram for the Energy Management (using maps).
An overview of the architecture of the Energy Management, allocated to the AGD-ECU, is shown
in the flow diagram of Figure 3. As in the previous section, the blue boxes represent modules /
functions and the yellow boxes label the interconnecting signals. The Energy Management
receives signals from the speed and load prediction and also communicates with the Hybrid
powertrain via Vehicle CAN bus HLP-1 and HLP-7. The Energy management consists of three
parts: an Equivalence factor calculation module, a Maps module and a Cost evaluation module.
The control signals, i.e. the output from the Energy Management, are: the torque of the electric
motor (in units of Nm), the gear selection (number 1 to 12) and the powertrain mode (i.e. electric
only, hybrid or Diesel only drives). The demanded torque is satisfied firstly by the electrical motor
up to its current limits and secondly by the combustion engine to satisfy the remaining demanded torque, [9].
The currently deployed energy management algorithm in the AGD demonstration vehicle is an
equivalent consumption minimization strategy (ECMS), commonly found in the academic literaD54.3 Active Green Driving
13
HAVEit
22.08.2011
ture see e.g. [12] that introduces an optimization criterion in order to choose the best combination of control signals. The equivalence factor calculated in the equivalence factor module
might be explained as the price of the electricity stored in the battery, compared to the Diesel
fuel. There are losses in the transformation of energy that mainly cause heat which means that
efficiency is decreased. The high voltage battery allows recuperation of energy originating in the
Diesel fuel, but the chain of transformation has a lower efficiency than Diesel only mode.
Generally, it pays off to recuperate electric energy by regenerative braking – this is preferably
done at low speed. However, since auxiliary equipment is attached to the high voltage system,
this is not always sufficient but has to be complemented by regeneration of electric energy when
the Diesel engine is leaving additional torque. This is all taken care of in the Energy Management controller.
The optimization is computationally intensive. To enable real time execution of the optimization,
intermediate results are pre-computed off-line and stored in arrays (look-up tables), handled by
the Maps module. The static maps are functions of the desired torque, the current speed of the
vehicle, the current gear and the equivalence factor. They are used for the hybrid drive mode.
If a shift in gear or powertrain mode is suggested, this is first evaluated in the cost evaluation
module to determine which energy gain can be made in pursuing with the shift, before the demand is sent to the hybrid powertrain.
2.1.3
Driver coaching
The flow diagram in Figure 4 gives an overview of the functional modules of the Driver Coaching
System (DCS). As before, different shapes and colours are used in the diagram to denote
internal functional module (light blue), external functional module (dark blue), data signals
(yellow).
First, the maximum recommended speed is calculated by monitoring the continuously updated
incoming speed plan array (see Figure 4), from the AGD Speed and Load Prediction, and the
current vehicle speed. The KPI events detection monitors driver actions to detect misbehaviour
in one of the Key Performance Index (KPI): Upcoming object, speeding, harsh braking and
downhill. The Eco points are, for each KPI, increased and decreased to reflect driver behaviour.
There is a module to monitor the KPIs, prioritize and trigger DCS tips and DCS feedback, and
control pop-up timing of this information on the driver‟s display. The priority order for the pop-ups
is as follows, from highest to lowest priority:
1. Upcoming Object
2. Bad planning
3. Speeding
4. Downhill
An overall instant eco value is calculated based on the individual eco points for each KPI; see
section 4.1.3 for more details. When the driver stops the vehicle and requests information, the
summary module generates a comprehensive summary of eco points and events. The haptic
pedal control generates the necessary data to provide tactile feedback in order to instruct the
driver on better driving practices. The driver can enable the DCS with a switch (called DCS
switch logic in the figure), see [7] for more details. The driver coaching switch has three
positions: “off”, “on” and “summary”. The post drive summary can be reset to stop accumulating
to previous summary.
14
HAVEit
22.08.2011
Speed and load
prediction
Vehicle CAN
Vechicle speed
Predicted
vehicle speed
array
Find recommended
speed
Max recommended
speed
Vehicle CAN
Vechicle speed
Brake pedal
Acc pedal
KPI events detection
Haptic pedal
KPI Events
Generate and display
Feedback/Tips
Calculate KPI Eco
points
KPI eco points
Compute Eco value
Tips/
Feedback
Instant Eco
value
Summary module
Driver‟s Display
Driver
DCS switch logic
Figure 4: Schematic flow diagram for the Driver Coaching System.
15
HAVEit
22.08.2011
2.2 Architecture
This section is devoted to the HAVEit architecture and hardware structure specific for the AGD.
2.2.1
Architecture and bus structure
Laser Scanner
GPS Receiver
Laser Scanner
USB
Ethernet
RS232
Ethernet
LS Switch box
USB
RS232
Front Cam.
CAN 3
CAN 1
HMI PC
HMI PC
CAN 4
Sensor Fusion CAN
V2V
CAN 3
CAN 1
V2V
CAN 2
LS ECU
Sensor
Fusion
xPC
ECU (xPC)
AGD ECU
Auto Box
(microautobox)
CAN 4
1
Ethernet
CAN 1
Ethernet
DACU
CAN 2
Vehicle CAN HLP1
Vehicle CAN HLP7
Pedal
Figure 5: Network topology.
Figure 5 shows the hardware structure with processing units and communication channels [11].
The Vehicle CAN bus HLP1 and HLP7 connect the AGD specific units to the already existing
ECUs. On these CAN buses the AGD ECU can communicate with the Transmission ECU and
the Engine ECU and listen to the messages sent from the rest of the ECUs in the vehicle. The
AGD ECU (a Micro Autobox), Sensor Fusion ECU (an xPC) and HMI PC (running a recent
version of Windows NT) are able to communicate with each other and exchange information on
a private bus in the figure called Sensor fusion CAN. To connect external sensors etc. there are
additional Ethernet, CAN, USB and RS232 communication standards.
The Sensor fusion ECU is connected to two laser scanners (LS) via a switch and an additional
processing ECU, a front looking colour camera (FrontCam), a front vehicle to vehicle (V2V) comD54.3 Active Green Driving
16
HAVEit
22.08.2011
munication device, a back V2V communication device and a yaw rate sensor (DACU). The
information from the different sensors is processed and passed on to the rest of the AGD
system. The yaw rate sensor is needed by the camera to compensate for the yawing motion that
represents panning. Besides the communication with the AGD nodes the Sensor Fusion ECU is
also able to listen to CAN messages sent on CAN HLP1. The display for the driver is connected
to the HMI PC. Engineering stations for development and tuning of the AGD system are primarily
connected to the Sensor Fusion ECU and AGD ECU for development purpose.
The approximate physical location of the sensors, ECUs and wiring are shown in the top view of
the demonstration bus in Figure 6, see [6] and [11]. Existing platform units are not displayed.
Ethernet
Power
supply
CAN
USB
RS232
V2V
V2V
Driver
LS
switch
LS
ECU
DACU
xPC
AGD
ECU
HMI
PC
GPS
receiver
Power station
&
panels
Laser scanner
Acc. Pedal
Driver‟s display
Camera/ECU
Laser scanner
Figure 6: Top view of installed sensors and control units on the demonstrator vehicle
2.2.2
Adaptation of the generic HAVEit architecture and deployment
This section will give an overview of the AGD specific adaptation of the generic HAVEit architecture and its deployment.
A diagram of the AGD specific functional architecture (Figure 7) is also found in [6], where it is
derived from the generic HAVEit architecture, see the HAVEit specification deliverable [2] or [10]
for details. There are some differences due to the fact that in AGD the driver is not monitored to
select e.g. an automatic driving mode.
The architecture consists of four layers:
1. Perception layer (component C1, colour code blue),
2. Command layer (component C2, colour code yellow),
3. Execution layer (component C3, colour code green), and
4. Driver interface components layer (component C4, colour code red).
To avoid confusion, it should be pointed out that the use of the term “layer” in this diagram differs from that in traditional computer engineering terminology.
17
HAVEit
Driver
interface
components
22.08.2011
Environment sensors
Vehicle sensors
Driver
Perception
layer
Sensor data fusion
HMI
Command
layer
Co-pilot
Prediction
system
Command generation and plausiblization
Vehicle speed and torque demand vector
Execution
layer
Drivetrain control
Braking
actuator
Electric motor
actuator
Combustion
engine actuator
Gearbox
actuator
Figure 7: Architecture overview of the HAVEit AGD system
The generic function block diagram, including processing units and communication channels, for
the HAVEit architecture allocation to hardware units in [3], with the purpose to find a feasible and
practical allocation of tasks and messages, has to a large extent been followed in the AGD version.
Figure 8 shows the allocation of the various software modules found in previous figures onto the
three main processing units used in AGD: Sensor Fusion ECU, AGD ECU and HMI PC. The
layers of the architecture including its layer components have been depicted in the cases a
software module is inside any of the three processing units. The figure is focused on showing
what is inside the processing units, not the relation between modules or layers for which the
other views in Figure 2, Figure 3, Figure 4, and Figure 7 serve the purpose better.
The AGD ECU hosts the Energy Management functionality in the Drive train control. The Copilot in the AGD system handles the prediction of the maximum vehicle speed and torque
demand trajectories for the nearest future, knowing that the vehicle will drive on a defined route
[6]. The prediction in the Command Generation and Plausibilization module handles the dynamic
parts in the prediction of the vehicle speed and torque trajectories. The main task for the Command Generation and Plausibilization module is to derive predicted vehicle speed and torque
demand trajectories based on vehicle dynamics and a driver model. In this module also driver
coaching instructions are derived based on the driver‟s driving behaviour and upcoming traffic
situations.
The HMI PC handles the eHorizon positioning system and is connected to a GPS receiver,
which provides information about the current position of the vehicle. The vehicle position is processed in the HMI PC and then passed on to the AGD ECU, where a map database with GPS
positioned corresponding objects are stored. The database information forms the eHorizon
system outputs, which are used by the speed and load prediction. The HMI PC also runs the
graphics for the driver‟s display.
The sensor fusion of external sensors is run on the Sensor Fusion ECU [6]. The eHorizon route
data base has an instance in the HMI PC and also in the AGD ECU to minimize the communication need. The HMI-PC supplies information on the active route identifier and position along
that route to the AGD-ECU where road attributes are stored locally.
18
HAVEit
22.08.2011
Sensor Fusion ECU
HMI PC
eHorizon
Route
Database
Co-pilot
Filtering
Sensor data fusion
HMI
Map
matching
Sensor
Fusion
Driver‟s
Display
AGD ECU
Co-pilot
eHorizon provider
Speed plan
Driver
interface
components
Command generation and
plausiblization
Speed and torque
prediction with driver
model
Find recommended
speed
Perception
layer
eHorizon
Route
Database
Command
layer
Execution
layer
KPI Events detection
Calculate KPI Eco
points
Drive train control
Cost evaluation module
Equivalence factor
calculation module
Maps module
Compute eco value
Generate and display
feedback/tips
Summary module
Haptic pedal
Figure 8: AGD deployment diagram, with functional modules and layers
19
HAVEit
2.2.3
22.08.2011
AGD specific architecture modifications
To have a common and generic architecture in the HAVEit project is an advantage, but the aims
and requirements of the AGD subproject are in the deployment reflected in another set of sensors, actuators and other hardware components necessary for the implementation.
These units and components are omitted from the generic architecture [3]:
Driver State Assessment is not needed since there are no active automation functions.
Active steering is not needed
Active braking is not needed
Mode Selection and Arbitration Unit (MSU) is not needed. The AGD Driver Coaching
System is enabled by the driver with a switch on the dash board.
Instead, the focus is on the AGD ECU with its speed and load prediction and Energy Management.
20
HAVEit
5
22.08.2011
Conclusions
The preliminary validation of the AGD functionality by use of test scenarios relies on the use of
simulation. Due to technical problems with the powertrain of the demonstration vehicle, it has so
far not been possible to carry out all validation scenarios in the vehicle. However, simulators are
often a good substitute for early validation of ideas and for verification of algorithms. A full range
of scenarios will be presented in a later report at the end of the project.
The Speed and Load prediction, a prerequisite for the AGD functionality of saving fuel, has had
a first test in the demonstrator vehicle. The estimated speed profile horizon ahead of the vehicle
is very similar to the actual speed profile when comparing the logged data files. It shows that the
prediction works as intended. However, the traffic light detection has not been taken in full service yet. New hardware was installed in late September 2010 and a new version of software was
delivered first week of October. The vehicle to vehicle infra red communication sensor has been
tested but it will not be used by the speed and load prediction algorithm.
The Energy Management controller of a hybrid vehicle can be made more fuel efficient by using
information about future driving conditions. The value of additional information is however difficult to assess, since the possibility of taking advantage of the information depends on the capability of the vehicle, i.e. constraints in the transformation and storage of energy. This is what the
simulation of the demonstrator vehicle above shows. The implemented Energy Management
control works as expected in simulation. Testing of the Energy Management in-vehicle has not
been done yet. In real world applications, information about future driving conditions needs to be
estimated from e.g. map data and measurements from sensors, which will not be fully accurate.
It is therefore very important that the Energy Management is robust against errors in the Speed
and Load Prediction. The robustness against both estimation errors and different prediction
horizons has to be evaluated in the future.
Some of the main challenges with developing a Driver Coaching System involve how to present
the information to the driver to keep him motivated. The information and advice need to be
intuitively understood and easy to ignore by the driver if focus is needed elsewhere. In order to
gain acceptance the system also needs to manage the trade-off between fuel-economical
driving and performance in such a way that it is possible to follow the recommendations of the
system without unreasonably affecting the performance or traffic flow. There are Eco KPIs (Key
performance indices) that the driver can affect (e.g. speeding, hard braking) and there are
aspects (possibly Eco KPIs) that the driver cannot affect, e.g. vehicle load and route planning. In
order to develop a fair Eco driving functionality, e.g. for back-office use, this second type of
aspect must also be taken into consideration.
The preliminary studies in the driving simulator, although not by professional drivers, show the
difficulties in getting immediate acceptance, maybe since it challenges the driver‟s idea of fuel
economic driving. The Eco KPIs must be related to certain threshold values and the driver needs
to be able to relate his performance to a threshold value. The reference value should preferably
be the optimum value, the best value that a driver can score within a certain KPI. An initial set of
these tuning parameters can preferably be found in the driving simulator, where the scenario is
easy to repeat. The driver‟s HMI, i.e. display of DCS related information and advice and the
haptic pedal, has also been tested with good result, but more on-road tests is needed.
49
HAVEit
22.08.2011
References
[1]
HAVEit deliverable D11.1 “Requirements“, September 2008
[2]
HAVEit deliverable D11.2 “Specification”, February 2009
[3]
HAVEit deliverable D12.1 “Architecture“, February 2009
[4]
HAVEit internal document “HAVEit V2V CAN Specification”, August 2010
[5]
HAVEit deliverable D54.1 “AGD: Sensors installed in vehicle (1st SW version), May 2009
[6]
HAVEit deliverable D54.2 “AGD: Components installed, working and tested”, May 2010
[7]
Internal report ER-540261 “Eco Driver Coaching – HAVEit”, work in progress
[8]
Internal report on Speed and load prediction, work in progress
[9]
Internal report, “Energy management for the AGD project”, work in progress
[10]
Internal report ER 59251, “HAVEit WP 5400, Active Green Driving – Software interface
and architecture, July 2010.
[11]
Internal report ER 59252, “HAVEit WP 5400, Active Green Driving – Hardware
installations”, 2010.
[12]
Sciarretta, A. Back, M. Guzzella, L. „Control Strategy of Parallel Hybrid Electric Vehicle„,
IEEE Transactions on control systems technology, Vol. 12 No. 3, may 2004, p 352-363
50
HAVEit
22.08.2011
Annex 1: Keywords
Abbreviation
Description
AGD
Active Green Driving
AQuA
Automated Queue Assistance
CAN
Controller Area Network
DACU
Gyro sensor ECU at Volvo
DCS
Driver Coaching System
ECMS
Equivalent Fuel Consumption Minimization Strategy
ECU
Electronic Control Unit
eHorizon
A system where GPS is used in combination with a digital map
EM
Electrical Machine (high voltage)
GPS
Global Positioning System
HAVEit
Highly Automated Vehicles for intelligent transport
HLP
Higher Level Protocol
HMI
Human-Machine Interface
ICE
Internal Combustion Engine
KPI
Key Performance Index
MAB
dSpace‟s Micro Autobox for rapid prototyping with special h/w
PC
Personal Computer
SF, SDF
Sensor Fusion, Sensor Data Fusion
SoC
State of Charge (of the high voltage battery)
V2V / I2V
Vehicle to vehicle communication / Infrastructure to Vehicle
WP
Work Package
xPC
Mathwork‟s rapid prototyping using PC hardware
51

Deliverable D54.3 Active Green Driving: 1 System Functionality

Transcription

Similar documents

Hyundai iLoad 2.5L.ai

42011-AK007 Navara

Nate Bryer

FM-Web

Mercedes-Benz 280 SE 3.5 Cabriolet (W111)

Selling and Demonstrating In

Print - Brabus

Mercedes-Benz 280 SL Pagode (W113)

Mercedes-Benz 280 SL Pagode (W 113)

at Talladega Superspeedway Register at www.Vettes4Vets.org A