{'fraction_non_alphanumeric': 0.031075787253277084, 'fraction_numerical': 0.006403495555220733, 'mean_word_length': 4.5669951771859925, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
Energy Consumption Prediction of a Vehicle along a User-Specified Real-World Trip

Standard cycles provide an easy way to evaluate the energy consumption of vehicles, but it is the energy consumption that occurs on real-world trips that really matters to the driver and, to a larger extent, society. This study shows how digital maps and vehicle simulation tools can be used to estimate energy consumption on a real-world trip. The user (1) selects a trip in the mapping service ADAS-RP (Advanced Driver Assistance Systems Research Platform), (2) defines a vehicle model in the vehicle powertrain simulation tool Autonomie, and (3) runs and analyzes the simulation in that same tool. For each section of the trip, ADAS-RP provides various information that can include speed limits, historic data on traffic pattern speeds, the slopes of the routes, and the positions of stop signs and traffic lights. The first stage of processing this information is to schedule the stops and to create an intermediate speed target that takes those stops into account. The final driver demand speed includes transitions – accelerations and decelerations – between sections with different intermediate speed targets, or around stops. The ADASRP/Autonomie process is then used to compute the energy consumption of a hybrid electric vehicle and a conventional vehicle on 10 trips defined across the United States and Germany. The hybrid vehicle is more fuel efficient, especially on congested routes and routes with downhill slopes, the effect of which is analyzed in further detail.


Introduction
Most research on vehicle energy efficiency relies on predefined drive cycles as benchmark tests. Although this approach provides repeatable results and allows for easy comparisons, it ignores the relationships between the driver, the vehicle controller, and the environment. This paper illustrates an approach that links the mapping and navigation service ADAS RP [1] and the advanced vehicle simulation tool Autonomie [2]. The goal is to predict the amount of energy consumed on a user-specified route. An added benefit is that the approach creates an innovative framework for various research topics that rely on real-world trips: "green" routing, hybrid control optimization, fleet management, etc.
Applications of the approach could be especially significant in the case of hybrid electric vehicles (HEVs). The added degree of freedom from a second source of power allows for greater flexibility in the design of the controller. For example, several studies show that the reduction in fuel consumption by HEVs can be higher on roads with slopes if future road information is made available to the controller. The main challenge in this study is to create a speed and grade profile for a trip when those data are limited. The challenge is very similar to the online future-trip prediction problem. Future route prediction is a promising research topic because such data are essential input for optimal controllers for advanced powertrains like HEVs. Dynamic programming ( [3], [4]) and the Pontryagin minimization principle ( [5], [6]) are the two main control theory techniques used for advanced powertrains. Both require full knowledge of the trip profile ahead to compute the optimal control law. Some heuristically optimized controls also rely on trip prediction [7]. There have been several real-world implementations of road prediction with energy efficiency in mind ( [8]- [11]). One example is an experiment by Nissan on a hybrid Tino [8]. Its controller uses a combination of road classification, grade, congestion level, and historic data to reduce the overall fuel consumption of the vehicle. Road prediction has also been explored for heavy-duty applications, mainly line-haul trucks ( [10], [11]). Adaptive cruise control uses the knowledge of the slopes ahead to adapt the target speed and gear, thus leading to non-negligible fuel savings. The full long-term horizon, however, is not fully computed; for example, speed is predicted for a very short time-frame, if at all. Predicting future driving is possible and can be done in various ways. One is to predict a future trip based on past trips of the same driver ([12]- [14]). After several trips are logged and their patterns analyzed, it is possible to find out which trip the user is going to make. This approach was developed by Krumm (Microsoft) and Froelich (University of Washington) ([13]- [14]). Another technique relies on digital maps and knowledge of the destination. A very simple approach can rely on known speed limits and topographic maps [15] to, for example, compute an electric car range. In a more complex approach, a navigation engine can compute the most probable path to the destination; then with the content-rich digital map, the speed on each subsection of the road can be estimated. In [16], Minett et al. used ADAS-RP, developed by NAVTEQ, to compute an estimated speed trace and fuel consumption by using a backwardlooking vehicle model. We use a similar approach in our study, but we added to the trip prediction details that have a major impact on energy consumption, such as stop signs, traffic lights, and grade. We also made it a process within Autonomie, a licensable, forward-looking simulation tool. The user can simulate any type of vehicle defined in Autonomie on any type of trip defined in ADAS-RP. This paper first presents the tools that we linked together: ADAS-RP and Autonomie. It then explains the two stages behind the final speed target computation. Finally, it illustrates how this process can be used to benchmark a hybrid vehicle against a conventional one.

Autonomie
The vehicles are simulated in Autonomie, which was developed by Argonne National Laboratory ( Figure 1) [2]. It is the main vehicle simulation tool used in the U.S. Department of Energy's FreedomCAR and Vehicle Technologies Program. It has been used in numerous studies to give the U.S. government guidance for future research. More than 140 companies and research entities, including major automotive companies and suppliers, also use Autonomie to support advanced vehicle development programs. Autonomie is a software package with a userfriendly interface that allows fast selection of powertrain configurations and component models, initialization data and processing files. It includes a wide range of pre-defined vehicles, both light and heavy-duty. All models and calculations are based on Matlab and Simulink: a vehicle is built in Simulink based on the selections made in the interface, and it is similarly initialized. The resulting vehicle model is a forward-looking model: a driver model sends a pedal signal to the supervisory control of the vehicle, which in turn sends a torque demand to the engine and other power sources. The components use an effort/flow topology, inspired by the Bond graph theory: an effort (e.g. torque) is propagated forward until it is integrated to compute a flow (e.g. speed) which is itself propagated backwards.
The plant models (engine, transmission, etc.) are generally map-based, combining accuracy and short execution time. Vehicles and individual components were validated based on test data.

ADAS RP
ADAS RP (Advanced Driver Assistance Systems Research Platform) is a software framework developed by NAVTEQ [1]. It is used to develop prototypes of applications that use positioning and maps for a wide range of applications, from eco-routing to headlamp orientation in turns. Thanks to the multiple plug-ins, these data can be used for the specific needs of the application. NAVTEQ maps provide a highly accurate representation of the detailed road network. Numerous attributes are recorded by geographic analysts who continuously drive on the road network, ensuring a verified and up-to-date database. The road network is segmented in small sections, or links, which can have up to 260 attributes, including vehicle speed limits, slopes, and number of lanes. NAVTEQ maps also include the positions and types of road signs, particularly stop signs and traffic lights. NAVTEQ is also a major provider of traffic information, thanks to its extensive network of proprietary probes and data processing capabilities. ADAS RP leverages this expertise by including traffic patterns on major roads. In a typical utilization, the user can select a starting point and destination on a map integrated in the graphical user interface (GUI). The internal map engine then computes the most likely route, and it is possible to see the attributes of each link.

Trip definition to vehicle simulation
From a user point of view, simulating a vehicle in Autonomie on a trip defined in ADAS RP is done in four steps ( Figure 3). The user first defines the trip by selecting the origin and destination. This is done by using a visual map that is easy to navigate and zoom in and out on. An Autonomie plug-in for ADAS RP was created and is displayed as a tab in the ADAS RP GUI. From that tab, the user can export the cycle, which saves relevant data in a Comma-Separated file (CSV). The user then switches to the Autonomie GUI. After defining the vehicle to simulate, he chooses an "ADAS RP" process, and selects the CSV file corresponding to the trip he wants to simulate. As with any other cycle, the user can launch the simulation and then analyze the results. When the CSV file containing the road data is being selected in Autonomie, several algorithms process the raw ADAS data into a usable form. First, the processing of the road information per se occurs: the Road Data Processing (RDP). This is followed by running the off-line part of the distance-based driver model, in which the vehicle speed target is computed. Both processes are described in Sections 3 and 4, respectively.

Relevant road attributes
The data produced by ADAS RP contain a lot of useful information about the road travelled. The most important is speed, which comes from various signals, depending on the level of details contained in the map. The list below ranks them by increasing level of fidelity (i.e., how well they compare to the actual real-world speed on the link): -Expected speed: typical speed on links of the same category; -Speed limit: self-explanatory; -Special speed limit: applies only at particular times (e.g., school days); and -Traffic pattern speed: average traffic speed that is based on historical data and depends on the time and day of the week. The approximate speed is computed from aggregating the speed signals and keeping the value from the most accurate available attribute. NAVTEQ maps also contain a spline representation of the road, so the high-fidelity slope value is generally available at a higher space resolution than are most attributes. To accurately model real-world driving, it is necessary to include stops. There are several reasons a vehicle stops, but we identified two major ones: stop signs and traffic lights. The raw data from ADAS RP include the positions of these two types of road signs.

Rationale for processing raw data
There are several limitations to the raw data that makes it not directly usable for a realistic vehicle simulation. First of all, attributes of interest are not available on all links. Secondly, there is no information on the stopping time, but simply location of road signs. Finally the traffic pattern speed, when available, is an average traffic speed, and as such already takes into account any stops along the way. The goal of the processing is to create a target speed for each of the links as well as the location and duration of stops. This information will then be processed to generate the driver demand speed, which is described in Section 4. To create this information, some basic assumptions about how the vehicle is actually driven are made. In a first approximation, it is assumed that the trip is composed of a continuous succession of constant accelerations, constant speeds, and constant decelerations (Figure 4).  The output of the RDP, the target speed, will actually be simpler than the profile shown in Figure 4. The acceleration and deceleration parts, while taken into account for average speed adjustments, will not be part of the output. The target speed will be composed of constant speed sections ("stairs"), while the transitions will be added when generating the driver demand speed. The RDP has several steps: -Data normalization/formatting, -Stop scheduling, -Division into subsections, and -Target speed computation.

Stop schedule
Two types of traffic signals lead to stopping: stop signs and traffic lights. The total stopping time depends on the signal (green/red time for lights, 4-way or 2-way stops, etc.) and also on the level of congestion, or level of service (LOS). In this study, we use a simple model, in which the total stopping time depends on LOS (Table 1). To do so we identify three levels of service -free flow, congestion, and heavy-congestion -based on the difference between the speed limit and the traffic pattern speed. For stops signs, there is a longer stopping time with higher congestion.

Division in sections and subsections
Not all road links have the same number of attributes. In particular, the traffic pattern speed is available only on the major roads. The processing of a section with or without a traffic pattern speed is different, so the first task is to separate the sections depending on whether they have that attribute or not. This is shown in Figure 5. Each section with traffic (which can be made up of several links) is itself divided into constant speed sections; each of these sections and subsections has a defined set of attributes; they are defined by using structure arrays in Matlab.

Computation of intermediate speed target
Traffic pattern speed is an average speed, in which any stops are already incorporated. To reconstruct the real-world pattern, we assume a simple speed profile. In the simple case of a section with a constant speed, a constant deceleration, and a stop period, it is possible to compute the target speed . When this is the case, the section with no solution is combined with an adjacent one; the lengths and times are respectively added together; and equation (2) is applied to that bigger section. That process is continued until a section is big enough to have solutions to the problem. Figure 7 shows RDP inputs (traffic pattern speed, stop positions) and outputs (target speed, stop durations) for a trip defined in ADAS RP.

Computation of driver demand speed
The next step in the process is to transform the target speed that was computed previously into a usable form for the Autonomie driver, the demand speed. The Autonomie driver model computes a torque demand from three terms: -Baseline torque demand corresponding to the rolling and aerodynamic losses, -Acceleration/deceleration torque using the derivative of the demand speed, and -Corrective torque from the comparison of demand speed and current speed in a proportional-integral control. If a major discontinuity occurs, the corrective torque will jump suddenly, akin to sudden full throttle acceleration or full braking. In most realworld situations, the human driver anticipates such increases and decreases in speed target and uses his experience to apply accelerator or brake commands moderately. The "stairs" coming from the previous step therefore need to smoothed out and incorporate the transition between the various speed levels.

Division in sections
The trip is again divided into sections, so that stops and major discontinuities in speed are located at their extremities ( Figure 8). In other words, there is no stop or sudden speed difference in the middle of a section.  Figure 9 illustrates intermediate target speed and final demand speed after inclusion of transitions. The schematic trip is divided into four sections, 1 -4 . If there is a sudden increase in target speed (here at d 1 ), demand and target speeds will be the same in the section ( 1 ) before the increase:

Computation of speed profiles for each section
( 1 ) = ( 1 ). In the section ( 2 ) after the target speed increase, will continuously increase from ( 1 ) to ( 2 ), until the target speed of 2 , ( 2 ), is reached. If there is a sudden target speed decrease (here at d 2 ), the demand speed after the decrease, in section 3 , will already be at the new lower target speed: ( 2 ) = ( 3 ). In 2 , before 2 , the demand speed will start to continuously decrease from ( 2 ) so that it reaches ( 3 ) at the end of 2 . Another example of transition is around 3 : a deceleration is added just before the stop at 3 and an acceleration occurs right after it. After such processing, the demand speed, the grade, and the stop schedule can be fed into the Autonomie distance-based driver. In that driver model, the speed demand is updated on the basis of the actual distance achieved and not the time. Also there is a stop schedule that gives the positions and durations of stops as a function of distance. Whenever the vehicle reaches the position of a stop, the speed demand zeroes out, and the vehicle has to wait for the duration of the stop before a positive target speed is requested again. Figure 9: Computation of demand speed from target speed (schematic) To evaluate the process, 10 sample cycles were defined in ADAS-RP and used in the following studies. They are within or around major urban centers in the United States and Germany: Boston, San Francisco, Los Angeles, Chicago, Washington D.C., Detroit, and Munich. Those cycles are described in Table 2.

Trip model
An example of simulated trip is shown in Figure  10. The "Traffic" signal is the traffic pattern speed directly extracted from ADAS RP. The "Target" signal is the result of the RDP: it does not include any stops, but it does into account for the extra time needed for accelerations and decelerations and stops; hence, its value is higher than that of the target speed. The "Simulated" signal is the actual vehicle speed from Autonomie simulation. Simulated and target speeds differ by the numerous stops in the simulated speed.  Figure 11 is a close-up of that same trip, and it highlights the way transitions occur. One example of transition, at t = 65 s, is a speed reduction. The target speed decreases ahead of the change, so that it is never higher than the target speed. The simulated speed follows it closely. At t = 73 s, there is a stop that lasts for 15 s. It is anticipated with a deceleration from the target speed to zero. After the stop time has elapsed, the target speed rises back to a strictly positive value (4 km/h). The discontinuity is necessary to make the vehicle start moving. During the acceleration, the vehicle follows the target speed, and the discrepancies are due to the natural lag of the controller (reaction time) as well as powertrain dynamics, such as gear shifts.  When the traffic pattern speed is available, the target speed is derived from it by adjusting it upward in order to account for the stops generated by the algorithm. Doing so ensures that the time needed to cover the sections is constant. For example, traffic pattern speed is available on the whole extent of the Chicago2 and Chicago3 trips; as a result, the ADAS RP trip time and simulation time are almost equal. On the other hand, when no traffic pattern data are available, the target speed is simply the raw ADAS RP speed -either the speed limit or "expected" speed. The assumptions are that the driving condition is close to free-flow and that the driver will target the speed limit outside of stop signs and traffic lights. Since the stop time can still be added, there may be a significant discrepancy between the "raw" estimated time and actual simulation time.
In particular, this is the case for the LA trip, for which the traffic pattern speed was not available. Due to the numerous stop signs and traffic lights along the way, travel time almost doubles. Table 3 compiles other quantities of interest for each trip.

Energy consumption prediction
One of the key applications of this newly developed process is to predict the energy consumption of vehicles driven along a real-world trip. To illustrate this capability, we chose to use the process to compare two vehicles with different powertrain architectures. The two vehicles evaluated on those cycles are: -A conventional midsize car powered by an internal combustion engine (ICE) with a five-speed manual transmission and -A 2004 Toyota Prius (a power-split HEV). The mass of both vehicles is set to 1400 kg. The electric accessory load is set to 600 W. Both vehicles are available in the public version of Autonomie. The Prius model was validated by using Argonne chassis dynamometer tests [17]. The control of the HEV is also the default one (no future road prediction). Fuel consumption reported for the HEV is "charge-balanced" (i.e., the net battery energy is less than 1% of the fuel energy used). Figure 13 shows the fuel consumption (F.C.) of both vehicles on the real-world trips defined previously. The cycles were sorted by ascending average speed. For comparison purposes, Figure  13 also shows F.C. on selected certification cycles, the European ECE and NEDC, as well as U.S. EPA urban (UDDS) and highway cycles (HWFET). The conventional car has a much higher F.C. than the HEV, ranging from almost 14 to 5.1 L/100 km; these seem like reasonable values for that type of car, and are comparable to F.C. on standard cycles. On the other hand, there is less variance in the HEV F.C., which stays between 2.8 L/100 km and 4.7 L/100 km. The F.C. for both vehicles tend to decrease with higher average speeds. This is true to real-world observations: as the average speed increases, the engine operates more efficiently, but at very high speeds, those gains are overcome by prevailing aerodynamic losses. The HEV gets the best F.C. reduction on trips where there are numerous opportunities to recuperate kinetic energy or with long idling periods. Chicago2, WashDC2 and LA are routes in which there are a large number of stops (more than 2.8 stops per km) and stop time, (up to 60% for the LA trip). The conventional gets its worst F.C. and the HEV achieves the highest decrease in F.C. on those cycles. The HEV also gets a very low F.C. on SF, which combines moderate speed highway driving with grades.

Analysis of HEV operations in a hilly terrain
Grades often pose a different set of challenges for powertrain and controller designers, especially when it comes to hybrid vehicles. A long ascent is a challenge because the limited battery energy cannot overcome the engine power lost to engine downsizing. A descent, on the other hand, is beneficial, as regenerative braking can be used to recharge the battery. All standard cycles used for certification are "flat" (i.e., they do not include any grades). Real-world driving routes need to be used instead. One of the powerful features this new process offers is the prediction of grade for any trip on main roads. In this study, we can use that feature for a short analysis of hybrid operations.
The SF trip between San Francisco's northern shore and San Rafael, 26 km to the north, in the northwest Bay area, includes several ascents and descents. It starts in urban San Francisco, crosses the Golden Gate Bridge, and turns into a three-lane highway. As shown in Figure 14, there is one major hill, between D = 2.2 km and D = 13 km and two smaller ones at 17.5 km and 22.5 km. The battery operations are shown in Figure 15 and Figure 16. In Figure 15, the battery ΔSOC (which is the state-of-charge minus the initial SOC) evolution is shown over the entire trip. The first part of the trip is in an urban environment and generally at low speed. That type of driving is often associated with electric-only mode. At t = 800 s, a combination of positive grade and acceleration further depletes the battery. The long downhill grade that starts at t = 1200 s is the opportunity to fully recharge the battery. As shown in Figure 16, the battery gets about 9 kW of electricity recharging it during the whole grade, leading the SOC to increase by almost 30 percentage points. That energy is then used throughout the cycle to displace fuel energy, leading to very good fuel consumption.

Future Work
Some key improvements to this method will be made in the future. More road information will be factored in the computation of the speed target (e.g., slower speed targets when a turning manoeuvre is identified).
Another major improvement will be the introduction of more variance to currently constant speed sections, in order to more accurately mimic stop-and-go traffic, natural speed oscillations, obstacles, etc. We will also emphasize validating the modeled speed profiles with real-world driving data.

Summary
A process was created to easily predict the energy consumption of a vehicle on a user-specified realworld trip. The user can define a trip by its starting and end points, in ADAS RP through a map interface. The saved trip is processed to create speed, stop, and grade profiles when it is loaded in Autonomie. The user-defined vehicle is then simulated over those profiles, and energy consumption is computed. The processing algorithm is robust enough to deal with road links having varying levels of detail in the digital map. For example, the algorithm accounts for traffic pattern speed when it is available and on other information otherwise. The inclusion of stops in the target speed generation also creates realistic speed profiles, essential for estimating energy consumption. We demonstrated that this process can be used not only to predict energy consumption but also to analyze the operation of any vehicle on a userdefined, real-world trip. We compared the fuel consumption of a Toyota Prius to that of a conventional car of the same class on 10 realworld trips and showed a significant benefit of the hybrid car. We also analyzed how the battery energy is managed on a trip with long grades. This process opens new horizons, combining intelligent transportation systems (ITS) and transportation energy efficiency research. In particular, this tool is critical for intelligent tripbased control of electrified powertrains, battery EVs, HEVs, and plug-in HEVs. It provides a "proving ground" to test new smart controls. All the theories and methods of trip prediction can also be applied to an online, in-vehicle energy consumption horizon, which is indispensable for intelligent energy management.