Skip to contentUnited States Department of Transportation - Federal Highway Administration FHWA Home
Research Home
REPORT
This report is an archived publication and may contain dated technical, contact, and link information
Publication Number: FHWA-HRT-12-033
Date: December 2012

 

The Exploratory Advanced Research Program

Recent International Activity in Cooperative Vehicle–Highway Automation Systems

CURRENT EUROPEAN PROJECTS IN COOPERATIVE VEHICLE-HIGHWAY AUTOMATION

The European projects that are currently developing CVHAS, or their subsystems or precursors, are reviewed in this chapter. These reviews are based on in–person visits with the leaders of the projects and, where possible, participation in demonstrations of the target systems. The information reported here augments the information in the literature review that was prepared for this project and developed as a separate report. It also includes more subjective and unofficial information than the more formal published information cited in the literature review.

This review of the current and recent European CVHAS projects begins with the major integrated projects sponsored by the EC and then covers the most important national projects. The section concludes with a discussion of the major workshop that the EC sponsored in October 2011 to synthesize the results of the work performed until that time and to identify the next steps that need to be taken. The following sections in this chapter provide descriptions of the different CVHAS projects reviewed.

SARTRE

The SARTRE project (SAfe Road TRains for the Environment) is the most recent of the major EC–sponsored projects on vehicle automation, and its vision is the most ambitious in the level of automation to be implemented in a public mixed–traffic environment involving automated close–formation vehicle platoons. As the name implies, the main motivations are both environmental and safety–related, but the project is also interested in reducing congestion and enhancing driver convenience. SARTRE is led by the automotive consultants Ricardo from the United Kingdom and the major vehicle industry partners at Volvo, both automobile and trucking companies. The SARTRE project team is developing and testing a concept of a platoon led by a manually driven truck, with a mixture of fully automated trucks and cars following close behind to save fuel and emissions. The SARTRE project team plans to eventually operate these “road trains” on public highways in mixed traffic, with the shortest feasible gaps between vehicles.

SARTRE began in September 2009 and ended in September 2012 with a demonstration in Sweden. It is funded at a total level of €6.4 million ($8.2 million), with the EC funding 60 percent of the total and the seven project partners from four European countries funding the rest as cost share. The project sponsors held a media demonstration in December 2010 and a workshop and demonstration in September 2012, but no demonstrations were scheduled during the information–gathering stage of this international review project; thus, the information reported here was based on meetings with the primary project participants and their presentations at recent international meetings rather than on any direct experience of vehicle demonstrations.

Figure 1 shows the basic SARTRE operating concept in schematic form.(14) A truck driven by a specially trained driver would lead the platoon, and other trucks and cars could then perform fully automated vehicle–following behind the lead truck. The driver of the lead truck would be provided with technologies that would assist him to drive as safely, smoothly, and efficiently as possible. The steering systems of the following vehicles would be designed to follow the same trajectory as the leading truck, but this raises concerns about the safety of the followers if the lead truck runs off the road or is involved in another kind of unsafe scenario. The drivers of the following vehicles would be able to do whatever they want while following in the platoon and would not have any vehicle-control responsibilities, thus freeing up the drivers to perform other duties during their travel time.

The SARTRE project team has been trying to use available sensor technologies as much as possible in their test vehicles, because the Volvo production cars are now equipped with very comprehensive suites of sensors for collision warning and avoidance. SARTRE is using one 5.9 GHz dedicated short-range communication (DSRC) radio per vehicle for the V2V coordination, with 40–Hz updates of the vehicle data on these radios based on the control update cycles of the other elements of the system, but this is a faster update rate than what other DSRC applications have been assuming. The development work has been paying close attention to radio wave propagation challenges in this frequency band, particularly to avoid having cars shadowed by much taller trucks. The first test track experiments were conducted in late 2010, culminating in a high-profile media event that drew considerable attention. A second demonstration on a public motorway in Spain in May 2012 showed three passenger cars and a truck following the lead truck, as illustrated in figure 2.(14) A view from inside a car automatically following behind the lead truck from the first demonstration is shown in figure 3.(14)

SARTRE project members have been considering a variety of use cases for maneuvering, as shown in figure 4,(14) with vehicles of different types entering and leaving the platoon, to make sure that all cases are covered by the technological capabilities of the system. Information from the following vehicles will be communicated to the driver of the lead vehicle so that he can judge, for example, when there is enough space in an adjacent lane to accommodate a lane change by the entire platoon (relying on the blind spot sensor systems on those following vehicles). Vehicles entering and leaving the platoon would be steered manually by their drivers, but their longitudinal control would be automated.

The SARTRE operating concept assumes that no infrastructure cooperation will be needed and that the SARTRE platoons would be able to operate in any highway lane, without segregation from other vehicle traffic. The project team has not worked through the implications of all the hazard scenarios that could arise in this type of mixed traffic automation, but they are aware that there are serious challenges here. One of the project partners, ika Aachen, already had experience with cut–ins within their truck platoon in the KONVOI project several years ago (discussed later in this report), and cut–ins were also tested in SARTRE.

The lateral control of the following vehicles in a SARTRE platoon is performed by following the trajectory of the lead vehicle, more or less like tracking a sequence of “breadcrumbs” from that vehicle, without reference to any roadway markings. This was justified on the basis of avoiding the need to add more sensors to the vehicles, but it increases the risk to all of the followers when the lead vehicle driver does something wrong.

Graphic illustration of the SARTRE operating concept, which shows an overhead view of a truck (Lead Vehicle) leading a platoon of five cars (Following Vehicles) on a four-lane highway. The vehicles in the platoon are colored green; the other vehicles on the road (two) are gray.  The Following Vehicles are equipped with sensors that measure the distance, speed, and direction of the vehicle in front, allowing them to do other activities while they drive. Below each of the Following Vehicles is an orange graphic that shows the activities the drivers are engaged in: reading, talking on the phone, using a computer, eating, and listening to music.

Figure 1. Diagram. SARTRE operating concept.

 

Side view a platoon made up of a Lead Truck and three Following Vehicles driving on a highway. It is a bright sunny day with the view of a mountain in the distance. In front of the mountain is a small sandy slope dotted with evergreens and bushes on the far side of the highway. In the foreground is a row of lush, low, green bushes. The bushes appear blurry, giving the sense that the convoy is rushing past.

Figure 2. Photo. SARTRE demonstration of three automated cars and one automated truck following the lead truck in a platoon (May 2012).

 

Inside view of a vehicle that is part of a platoon. The photo shows the driver of the vehicle, as well as the Lead Truck in the platoon through the front windshield. The scene outside shows a snowy day, the narrow highway lined with evergreen trees. The driver is able to enjoy a cup of coffee and read the paper without having to steer the car; he is smiling.

Figure 3. Photo. Reading a newspaper while being driven automatically in the platoon behind the lead truck (December 2010).

 

SARTRE Overview Use-Cases Diagram, depicting seven scenarios in which vehicles join or leave a platoon according to the SARTRE model. The use-case diagrams all show overhead views of platoons being led by a Lead Truck. The first scenario shows a Following Vehicle joining the platoon from the rear and a new Lead Truck joining from the front. The second scenario shows a Following Vehicle leaving the platoon from the rear, and the Lead Truck leaving from the front. The third scenario shows a new Following Vehicle joining the platoon from the left lane just behind the Lead Truck; the fourth scenario shows the Following Vehicle leaving the platoon by switching into the left lane. The fifth scenario shows a truck joining the platoon just behind the Lead Truck; the sixth scenario shows the truck leaving the platoon by switching into the left lane. The seventh scenario shows a vehicle that is not part of the platoon trying to enter the platoon by switching from the left lane into a space just behind the Lead Truck. In all of these scenarios, the drivers of the Following and Lead Vehicles manually steer their vehicles when joining and leaving a platoon laterally, but longitudinal control of the vehicles is automated.

Figure 4. Diagram. SARTRE vehicle-maneuvering use cases. NOTE: FV = following vehicle, LV = lead vehicle, PFV/PLV = potential following vehicle/potential lead vehicle, OV = other vehicle (not part of the platoon).

HAVEit

The HAVEit project is another major Integrated Project of the EC, in this case sponsored by DG–CONNECT. The name HAVEit stands for Highly Automated Vehicles for Intelligent Transport, but in this context highly automated does not mean fully automated. Rather, this project concentrates on partially automated vehicles and has conducted some important experiments and prototype developments to explore how drivers interact with vehicles at different levels of automation, trying to avoid both underloading and overloading of drivers, as illustrated in figure 5.(15)

HAVEit began in February 2008 and ended in June 2011, with a final event held at a Volvo test track in Sweden. It was funded at a level of €27.5 million ($35 million), with €17 million ($22 million) funded by the EC and the rest funded in cost share from the 17 partner organizations led by the automotive supplier company Continental. The primary vehicle industry partners were Volkswagen for cars and Volvo Technology for trucks.

The central principle in the HAVEit project is the provision of four different modes of driver–vehicle interaction, with varying levels of automation, which can be engaged by the driver through a “mode selection and arbitration unit” as follows:

These different modes have been implemented on test vehicles primarily by using existing commercially available sensors and driving assistance systems, minimizing the amount of new purpose–built equipment and associated costs. An integrated driver–vehicle interface (DVI) was developed so that the driver could look in one place to determine which level of driving automation or assistance was being provided and to choose a different level. This concept is indicated schematically in figure 6,(15) and an example implementation on one of the test vehicles is shown in figure 7.(15) Despite the emphasis on re-use of existing sensors and systems, the overall system is still quite complex, as shown in figure 8.(15)

The HAVEit project team is well–supplied with human factors expertise and tools to develop a better understanding of driver limitations and drivers’ ability to interact safely with the different levels of automated driving assistance. They used driving simulators in the development, including a “theater technique,” in which an expert driver acted as the virtual copilot that the test subjects did not see at a second driving station, by which they could assess which of the copilot’s driving strategies worked well with the naive test subjects and which did not so that they could choose which to implement in the system software.

At the HAVEit final event, Dr. Juergen Leohold, the head of research for Volkswagen, confirmed that driving automation had been part of their corporate vision for a long time, motivated primarily by safety considerations. He identified the main challenges to deployment of these partially automated systems to be:

The current prototype vehicle implementation relies on a video camera mounted inside the instrument cluster, observing the driver’s face, as explained in figure 9.(15) If the driver’s head or eyes are turned away from the forward view of the road, a video image processing system detects this as inattention and issues an increasingly urgent audio alert to the driver. If the driver does not return eyes to the forward driving scene, the system then decelerates the vehicle to a stop. This is a very conservative system design approach, intended to deter the driver from non–driving tasks, such as texting, but at the same time it denies the driver one of the primary benefits of automated driving, which is the ability to do other things. Some of the European automotive marketing people believe that this is a lost opportunity, and that the real attraction to the public of automated driving will be the ability to do something else during the driving time. Of course, to be able to do this safely, the performance of the automated system will need to be much more advanced than the current state of the art.

The HAVEit operational concept was described as a “joint system,” with the driver assuming supervisory control responsibilities. An analogy was drawn to commercial aircraft automation, in which 95 percent of the time the airliner is flown by the autopilot under the pilot’s supervision, but the pilot remains responsible for strategic decisions and must be prepared to take full control at any time. The other metaphor that was used to describe the system was the horse and rider, with “dynamic task repartition” between the elements of a joint cognitive system. In this case, the vehicle system needs to maintain a continuous real–time understanding of both the driver’s capabilities (watching the road or not) and its own capabilities (uncertainties or conflicts in its sensors’ perceptions of the environment).

The highlights of the HAVEit final event were the demonstrations of the vehicles on the test track, which are discussed in the following sections.

The figure contains three diagrams depicting the HAVEit approach, explaining the causes of fatal car accidents as well as the ways that drivers interact with different levels of automation. The first diagram is labeled “Causes of Fatal Accidents”. It is a bar graph that describes the four general causes of fatal accidents: Psychological Factors, Miscalculation, Unexpected Behavior, and Technical Problems. These categories are further divided into sub-categories: Psychological Factors include Sleep, Inattention, and Medical Disorders; Miscalculation includes Vehicle in Front, Driving Dynamics, Weather, Keeping in Lane, and Stationary Car; Unexpected Behavior includes Pedestrian/Car/Occupant/Animal together as one category, Accident, and Other; under Technical Problems, only Technology is listed as a factor. Psychological Factors account for 38 percent of all fatal accidents; Sleep accounts for about 25 percent, Inattention about 10 percent, and Medical accounts for less than 5 percent. Forty-six percent of all accidents are caused by Miscalculation; within this category, just under 15 percent can be attributed to the Vehicle in Front, 10 percent to Weather, another 10 percent to Keeping in Lane, and less than 5 percent to a Stationary Car. In the Unexpected Behavior category, the Pedestrian/Car/Occupant/ Animal category accounts for 5 percent, and Accident and Other each account for less than 5 percent each. Technical Problems account for the remaining 5 percent of all accidents.

The second diagram is a graph showing two parabolas (a blue upward parabola intersecting with a yellow downward parabola). The blue parabola indicates driver performance, while the yellow parabola indicates need for assistance. The horizontal axis denotes increased activation; the vertical axis indicates increased driver performance: as driver performance increases, the need for assistance decreases, and vice versa.

The third diagram describes the four modes of driver-vehicle integration that are supported by the HAVEit project: 1) Driver-only (fully-manual control of the vehicle), 2) Assisted, 3) Semi-automated, and 4) Highly automated. The degree of driver control is depicted in yellow; the degree of automation is depicted in blue. The Driver-only field is fully yellow; the other fields become bluer as the level of automation increases. The fifth mode of driver-vehicle integration is fully-automated (completely blue in the diagram); the HAVEit project does not include fully-automated vehicles.

Figure 5. Diagram. Basic philosophy of multiple levels of driving automation in HAVEit.

 

At the top is a diagram that describes the four modes of driver-vehicle integration that are supported by the HAVEit project: 1) Driver-only (fully-manual control of the vehicle), 2) Assisted, 3) Semi-automated, and 4) Highly automated. The degree of driver control is depicted in green; the degree of automation is depicted in blue. The Driver-only field is fully green; the other fields become bluer as the level of automation increases. The fifth mode of driver-vehicle integration is Fully-automated (completely blue in the diagram); the HAVEit project does not include fully-automated vehicles. Orange arrows point out from the various modes of driver-vehicle integration to another diagram that describes the various levels of driver input (steering and braking) while driving in any of the four modes of driver-vehicle integration.  In the Driver-Only mode, only the driver has input; both Driver feedback and Driver Support are necessary in the Assisted-mode. The level of driver input is not labeled for the Semi-automated and Highly-automated modes.

To the right of the diagram is a photo of the steering wheel of a car equipped with driver-vehicle integration. The driver’s hand can be seen through the steering wheel making adjustments to the switch that controls the modes of driver-vehicle integration; the switch is mounted on the left side of the steering column and resembles a control switch for windshield wipers. 

Below the photo is a graphic depiction of a driver-vehicle integration control switch. The graphic shows the various positions of the control switch as it increases or decreases the level of automation (the closer the switch gets to the driver, the higher the automation level).

Figure 6. Diagram. Multiple automation levels through one driver–vehicle interface.

 

View of a digital car dashboard through a steering wheel. On the left side of the dashboard is a speedometer that only goes up to 40 km/hr; the current speed is zero. To the right of the speedometer is digital display of the driver-vehicle interface (DVI) for this car. The DVI mode icons are “Driver Assisted” (a stick figure in a driving position), “Semi-Automated” (a car and a speedometer with an arrow pointing at the speedometer), and Highly-Automated” (the HAVEit logo).  The Highly Automated icon is currently lit in blue, indicating that it is active.

Figure 7. Photo. Example of a human–machine interface, showing different control mode choices.

 

The process of HAVEit implementation involves four layers or segments of implementation that interact with each other in various ways. The function of the “driver interface components” segment is to assess the driver state and to integrate the driver in the automation loop. Second, the function of the “command layer” is to define maneuver, trajectory, and automation levels and to generate the safe motion control vector. The third layer is the “execution layer”, whose function is to perform the safe motion control vector. And finally, the “perception layer” functions to provide real-time scene recognition. This diagram that describes these layers of implementation points to another diagram that describes the various technologies necessary for HAVEit implementation to be realized.

Figure 8. Diagram. Complexity of HAVEit implementation.

 

A diagram and accompanying photo depicting the current prototype of implementation of driver-vehicle interface (DVI). On the left is a photo of a steering wheel and a driver’s side dashboard. The steering column is has a DVI control switch on the left. A camera is mounted on the center of dashboard just before the control panel. The camera has a lens in the middle and two small monitors or either side of the lens. To the right of the photo is a diagram depicting the HAVEit concept of driver monitoring. There are three boxes in the diagram: on the top left is a blue box that describes the Face Tracker Module: this takes an image of the driver’s face and monitors the driver’s facial position. Below this is a green box that describes the process of facial measurements: once the driver’s facial image has been captured by the face tracked module, the driver’s eye movements (including blinking), head position, and whether the driver is on or off the road are measured. This leads to the next box to the right, a yellow box marked Diagnostics: the facial measurement metrics are used to do either a drowsiness diagnostic (based on blink duration) or an inattentiveness diagnostic (based on whether the car is on or off the road). The drowsiness diagnostic determines the level of drowsiness, described as alert, slightly drowsy, drowsy, or sleepy. The inattentiveness diagnostic determines the level of distraction, described as attentive or inattentive. Above the yellow box and to the right of the blue box is an image of a female driver captured by the dashboard camera, with various diagnostics displayed; based on those diagnostics, this driver is drowsy.

Figure 9. Diagram. HAVEit concept of driver monitoring to ensure driver engagement, from Continental Automotive France.

Volkswagen’s Temporary AutoPilot

Volkswagen’s Temporary AutoPilot received the strongest media attention, because it left the impression of a close approach to truly automated driving, but some of the media coverage overlooked the fundamental requirement for the driver to continue watching the forward driving scene as a prerequisite for the system to continue to operate. The AutoPilot demonstration proceeded through the different levels of driver assistance up to the combination of lateral and longitudinal control. The different control levels were visible on the DVI display, as shown in figure 10.(16)

The vehicle demonstrated the ability to track a slower vehicle in the left adjacent lane and avoid overtaking it on the right, which is illegal in many European countries. The vehicle also performed an emergency braking maneuver behind a stopped fake vehicle in its lane (fake for safety, to avoid danger in event of a failure). After engaging the “highly automated” mode with automatic steering and speed control, the driver turned his head to look out the side window for an extended time. That caused the system to beep with increasing urgency to try to draw his attention back to the road. When he failed to respond to the system’s beeping, it brought the vehicle to a gradual stop, representing a risk-averse strategy in case the driver was incapacitated or asleep. This strategy also prevented drivers from abusing the system by trying to do something completely different while driving.

View of a digital display on a car dashboard. A driver and a passenger are in the front seat of the car; only the driver’s knee (with hand on it) and the passenger’s elbow can be seen. Between the driver and the passenger is the dashboard display for Volkswagen’s Temporary Auto Pilot. The Temporary Auto Pilot has the HAVEit logo on the top left hand corner of the screen. Below the HAVEit logo are green horizontal digital bars on the screen, with the letters “A,” “K,” “H,” “F,” and “G” written below. Below the green letters is the word “OK in white. In the middle of the screen is a digital representation of two cars: a red one in the left lane ahead of a blue car in the right lane. To the right of the cars it says “72 km/h” in white and “100 km/h” in yellow. Below the speeds are three white bars: the top one says “Pilot”; the middle one says “ACC”; the bottom one says “Driver.” Surrounding the Temporary Auto Pilot screen are the regular features of the dashboard of any modern car: a CD player is above the screen, as well as the indicator light for emergency lights; buttons for “Radio,” “Media,” “Phone,” “Tone” and the Volume button for the stereo are to the left of the screen; buttons labeled “Map,” “Nav,” and “Traffic” are to the right of the screen (the passenger’s elbow is blocking the fourth button).

Figure 10. Photo. Volkswagen’s Temporary Autopilot display, showing three levels of automation choices in lower right corner.

Automated Queue Assistance (AQuA)

The Automated Queue Assistance (AQuA) system for trucks by Volvo Technology provided a somewhat different view of highly automated driving aimed specifically at low–speed driving in heavily congested traffic, which could become monotonous for the driver. This system was demonstrated by following a lead car that went through a series of stop–and–go maneuvers, maintaining the truck at an appropriate following distance behind the car. Its driver interface is shown more closely in figures 11(16) and 12,(16) and figure 13(16) shows the view from the visitor seat in the back of the cab during the demonstration. The AQuA function can be engaged only at speeds below 30 km/h (19 mi/h) and when there is a target vehicle within a reasonably short forward range.

Close-up photo of the Automated Queue Assistance (AQuA) control panel buttons on a steering wheel. The control panel is made up of three buttons and a dial. The dial (on the left) shows the Adaptive Cruise Control (ACC) dashboard indicator symbol. To the right of the dial are the buttons that indicate the three levels of driver control: “AQuA,” “ACC”, and “O”. AQuA is designed for highly-automated driving in congested traffic.

Figure 11. Photo. Steering wheel controls for Volvo Automated Queue Assistance (AQuA) for heavy trucks.

 

Close-up view of the Automated Queue Assistance (AQuA) driver interface screen. The device is mounted on the dashboard, much like a GPS device would be. A sensor mounted on the inside the front window is attached to the device. The screen is too blurry to read, but most AQuA devices display the three levels of driver control: AQuA (highly-automated), ACC (adaptive cruise control; partial automation), and Manual (not automated). It appears that the AQuA level is activated because the highest indicator is lit.

Figure 12. Photo. Automated Queue Assistance (AQuA) driver interface for heavy trucks.

 

Photo inside the cab of a truck. The driver is cropped out of the photo, but his hands are visible on the steering wheel. On the dashboard is an Automated Queue Assistance (AQuA) device, indicating that the truck is using ACC (adaptive cruise control). A sensor attached to the AQuA device is attached inside the front windshield. The view through the windshield is of a four-lane highway, divided in the center by red and white traffic barriers. A red Volvo can be seen driving right in front of the truck through the windshield.

Figure 13. Photo. Automated Queue Assistance system demonstrationfor low–speed automation in a truck.

Automated Assistance in Roadworks and Congestion

Automated Assistance in Roadworks and Congestion was a demonstration intended to address assistance for drivers in a very high–workload–driving environment, in which the automation could help reduce the workload. This demonstration was implemented by the first-tier automotive supplier Continental on a passenger car, which had to drive through a road section where temporary pylons defined a path different from that represented by the normal lane markings. The vehicle had to stay within the pylons while following a lead vehicle that went through a variety of speed changes of the type one would expect when going through a work zone where traffic flow is impeded.

Figure 14(16) shows the additional complication introduced into this scenario, where a truck in the adjacent lane drove very close to the equipped car, actually straying over the lane boundary (this happened toward the right end of the scene in figure 14, after the pylons). In this case, the car’s side–mounted laser scanners detected the truck impinging on its lane so that it could adjust its trajectory off the lane center to avoid being hit by the truck. Figure 15(16) shows the DVI on this test vehicle when it was in manual control, using only its collision–warning functions (indicated by the stick figure icon illuminated in white). The touch–screen display could be used to choose the semi-automated mode or the “highly automated” mode, represented by the rectangles that are shown in blue in figure 15,(16) because they were not active when this photo was taken. Although the display in this vehicle and the other cars in the demonstrations were in the center console of the vehicle, it was noted that production systems would be more likely to have their displays located directly in front of the driver, in the primary instrument cluster, where they will be easier to see without diverting the driver’s eyes from the forward driving scene.

In figure 15,(16) rain can be seen on the car windshield. The day of the HAVEit demonstration had extremely variable weather, with conditions ranging from bright sun to heavy rain. The vehicle systems worked well under this full range of conditions, and none of the demonstrations had to be aborted because of adverse weather; however, at various times, phantom vehicle icons were observed on the display screens, indicating cases in which sensors were detecting other objects, such as guardrails, and not filtering all of them out.

Although the HAVEit systems that were developed and tested under the current project were entirely sensor–based rather than relying on communication for cooperation, the EC project officer for the project noted that in the follow–on work, cooperative capabilities will be added to provide additional data sources for the vehicle systems.

Daytime view of a four-lane highway, with pylons diverting traffic to create a new lane. Two oncoming cars are driving through the pylon-created lane. A truck in the lane to the left is driving closely to the pylon lane but has not entered it yet. Aside from the cars and the truck, there are no other cars on the highway.

Figure 14. Photo. An Automated Roadworks Assistant vehicle follows a lead vehicle between pylons and maintains separation from a truck.

 

. Photo of a car dashboard equipped with a Roadworks Assistant driver-vehicle interface (DVI). Rain is falling, making it difficult to see clearly through the front windshield; it looks like the car is driving on a tree-lined highway. The DVI screen is located on the dashboard just below the heating/AC vents to the left of the steering wheel.  The screen on the device shows a digital representation of a car on a highway. Red and green lines are emanating from the front of the digital car on to the digital highway. Red and yellow lights can be seen perpendicular to the digital car in the front; red lights are surrounding the digital car on the sides. To the left of the screen are five touch-screen buttons. The top button shows the HAVEit logo in a blue box (highly-automated mode); below that is another blue box with the dashboard icon that indicates the semi-automated mode. Below the semi-automated icon is a stick figure with a steering wheel, indicating the Driver Assisted mode; the icon is white, indicating that the car is being driven in this mode.

Figure 15. Photo. Roadworks Assistant driver–vehicle interface, showing three levels of automation on left side of screen.

CityMobil

The CityMobil project was sponsored by the EC, DG-RTD, from May 2006 through the end of 2011, at a total funding level of €40 million ($52 million), of which €11 million ($14 million) was provided by the EC (29 partner organizations provided the remaining funds, mainly to support their field demonstrations). This is the one project that has emphasized public transit applications of automated vehicles rather than automobile or trucking applications. It is the latest in a sequence of projects that have addressed the “CyberCar” concept, including CyberCars I and II, CyberMove, and City NetMobil.

CityMobil is promoting the development of new forms of public transportation to help reduce automobile usage in cities in support of environmental goals. It is based on the assumption that about one–third of the households in European cities cannot afford a car and one–third of households must have a car based on their housing and workplace situations, but one–third have a choice and can be influenced by the availability of better transit alternatives. CityMobil is targeting diverse niche markets for improved transit services, depending on urban area sizes, patterns of development, and existing transportation infrastructure. CityMobil is considering four classes of vehicles:

The definitions of CyberCars and advanced city vehicles remain somewhat imprecise at this stage of development, with considerable uncertainty about what levels of automation would be achievable in what kinds of operating environments (how much separation from pedestrians and other vehicular traffic). This is an important issue that became apparent with some of the other CVHAS projects as well and was indeed among the main areas of controversy during the NAHSC research in the United States in the 1990s.

Most of the information to be reported here was obtained during the CityMobil project’s final event in La Rochelle, France, in May 2011, which included a small public demonstration of a CyberCar and a 2–day technical conference with over a hundred attendees.

CityMobil La Rochelle Cyber Car Demonstration (May 2011)

The CyberCar demonstration used a single driverless vehicle with space for four passengers to stand while it drove at low speed (approximately a fast walking pace). It was operated in a low–density residential and light commercial area near the harbor in La Rochelle, mainly on a sidewalk adjoining a park and on an alley beside a row of buildings (figure 16).(16) This is a very low-density area, so interactions with other vehicles and pedestrians were infrequent. An attendant was required for passenger loading and unloading at the stations, and he walked or jogged alongside the vehicle while it was driving (figure 17).(16) When the driverless vehicle approached slower pedestrians, it slowed down behind them and then beeped at them to encourage them to get out of the way (which they generally did); however, if the pedestrians did not move, the vehicle would stop. In the aforementioned alley, the vehicle shared the space with the occasional automobile and had to cross a few other alleys where cars could be operated. In these locations, the driverless vehicle had to wait for the other vehicles to pass before it could proceed.

The demonstration vehicle identified its location based on a Simultaneous Localization and Mapping (SLAM) approach, using laser scanners at both ends of the vehicle to recognize the surrounding built–environment landmarks. The conference attendees were informed that when a large group of reporters and photographers surrounded the vehicle at the time of its media event, they occluded the surrounding buildings from the view of the laser scanners, and as a result, the vehicle lost its bearings (not unlikely in any reasonably dense pedestrian environment). The vehicle was not equipped with a global positioning system (GPS) for positioning because of concerns about interruption of satellite coverage in the alley, which was considered to be an “urban canyon” for GPS coverage. The vehicle was equipped with WiFi communication so that the demonstration operators could keep track of its location and status.

The vehicle demonstration was continued after the end of the CityMobil conference for 10 weeks, during which time it operated 3 hours per day, carrying a total of 900 passengers (an average of about 4.5 passengers per hour). Of these passengers, 200 were surveyed for their opinions about the system.

Even this limited demonstration required considerable political and institutional arrangements. Because the vehicle was driverless, the mayor of the city had to issue a special exemption from normal rules (an arrêté), taking on special responsibility for anything that may have gone wrong. The low density of vehicle and pedestrian traffic in the area, as well as the low building density, raised questions about whether the sites that would be technically feasible to use such a vehicle would actually have enough travel demand to produce benefits that exceed the costs. Would these vehicles be able to operate in locations where they are really needed (such as the much more crowded main marina of La Rochelle, only a few hundred meters away from the site that was used)?

. Daytime view of a pedestrian walkway in La Rochelle, France. A wide, paved pedestrian path is in the center of the photo; a yellow CyberCar is approaching on the path. To the left of the CyberCar is a public bike-sharing rack filled with yellow bikes. Behind the bike rack is row of four-story apartment buildings; the closest one has a garden on the roof. To the right of the pedestrian path is a tree-lined street; a woman pushing a baby carriage is walking on the path toward the street.

Figure 16. Photo. La Rochelle CyberCar demonstration site features a park sidewalk shared with pedestrians.

 

Daytime photo of a man opening the door of a CyberCar at a CityMobil pick-up point at the port in La Rochelle, France. The CyberCar is yellow and gray, with glass enclosing the passenger area. Four passengers (two facing forward, two facing back) can fit in this CyberCar, which currently has no passengers. The man is standing in the parking lot of the Maritime Museum (Musée Maritime) La Rochelle. In the background is a small red wooden building with “Musée Maritime de La Rochelle” written on it. Behind the building is a docked white cruise ship. A woman is walking away from the museum to the right. A couple can be seen looking at the ship.

Figure 17. Photo. A CyberCar at the station in La Rochelle, France, with an attendant who is required for passenger loading and unloading during the demonstration.

CityMobil La Rochelle Conference (May 2011)

The CityMobil conference was considerably more informative than was the vehicle demonstration, with a wide variety of presentations and discussions. Some of the key information brought forward during the conference is discussed below.

Low–Speed Urban CyberCar Plan, Rome, Italy

Although the CyberCar demonstration in La Rochelle was the most visible example of vehicle automation technology, the main field test implementations—where most of the resources were spent in the project—were conducted elsewhere. In the case of low–speed urban CyberCars, the main implementation was planned for Rome, Italy, where the demonstration site would have connected a remote parking lot with a large convention center. The vehicle that was intended to be tested in Rome is shown in figure 18.(16) A close–up view of the soft bumper that is designed to protect pedestrians who could be hit by the vehicle if its sensors did not detect them or if the vehicle did not stop in time is shown in figure 19.(16)

The intended CyberCar implementation in Rome is notable for the difficulties encountered when attempting to obtain the necessary certification for vehicle operation from government authorities. These authorities required that the vehicle only be operated on a right–of–way that was entirely fenced in to preclude interactions with other vehicles or pedestrians (obviating the need for the soft bumper). This obstacle showcased one of the institutional challenges in trying to implement a driverless vehicle in a public environment and raises questions about how it will be possible to put these vehicles into less-protected environments, where they would be easier and cheaper to place into service and would be accessible to more potential users.

Daytime view of an empty 22-passenger CyberCar. The CyberCar looks similar to a small shuttle bus. The CyberCar is enclosed in glass, with benches lining the walls for seating. A sliding glass door is open, revealing a metal step to allow passengers to get on. Large silver bumpers extend out the front and rear. Inside a large flat-screen TV is mounted on the right rear corner. A man is walking behind the CyberCar to the right.

Figure 18. Photo. Rome Exhibition Center vehicle.

 

The soft bumper of a 22-passenger CyberCar. A man is pressing his shin against the bumper of the CyberCar; the bumper is giving way to the pressure of the man’s leg and is squishing against it.

Figure 19. Photo. Soft bumper of the Rome Exhibition Center vehicle.

Vision–Guided Bus Technology

The advanced bus application in CityMobil is the use of the vision–guided bus technology developed by Siemens (originally Matra) for use on the CiViS BRT bus, in this case applied to a more conventional bus in Castellon, Spain.

This bus–guidance technology has been in commercial use in Rouen, France, for many years but was tested unsuccessfully in Las Vegas, NV, several years ago. It has not been made clear what was sufficiently special about the Castellon application that it should become the subject of study in a major research program.

For example, the Castellon operation has much less automation than does the Phileas bus that was developed in Eindhoven in the Netherlands several years ago. Phileas was a publicly funded project that developed a new automated bus rapid transit system that could be viewed as the equivalent of a rubber-tired tram. Phileas was funded by local and regional governments in the North Brabant region of the Netherlands, with the intention of strengthening the local industrial base and encouraging job growth through export sales of buses to other countries. (See reference 17 for more information about Phileas.)

The Phileas system was tested on a public busway in Eindhoven under fully automatic control (both speed and steering control with driver supervision), but the control system was removed from the buses before regular revenue service began. Although the complete story of the Phileas system has not been documented, unofficial information suggests that the safety certification of the automation system was not included in the planning or budget for the original development of the system. When it came time to obtain the safety certification, there was no budget to pay for it, and thus it was not obtained.

Personal Rapid Transit

The most ambitious project incorporated in CityMobil was the deployment of the ULTra PRT (Personal Rapid Transit) system at Heathrow Airport in London. This system is quite complicated—with extensive infrastructure development—but also has limited passenger capacity in this initial implementation.

The Heathrow PRT has entered public service recently, carrying passengers between Terminal 5 and a remote parking area. Its development and deployment has largely been funded by British Airports Authority, which bought a controlling interest in the company that developed the system and expects to expand it significantly at Heathrow and other airports if the initial experience is favorable. The PRT vehicles are captive to their special guideway, but their driving is automated, with automatic steering control to choose the correct route to follow at diverge points and when entering station loading docks (figures 20 and 21).(18) Their speed control is based on a moving block system comparable with most automated people movers and some advanced rail control systems. This system went through an extensive certification process, analogous to that for railroad control systems, before it could be put into public use.

PRT systems are less like the road vehicles featured in the rest of the project than they are like rail vehicles, even though they do not run on steel wheels. They are confined to a special guideway rather than being able to use the same road space as other vehicles, and they lack a manual driving mode for access to unequipped locations. Their control systems have strong infrastructure involvement and are also much more like moving block railroad signal control systems than like vehicle follower systems.

Two personal rapid transit vehicles (PRTs) approaching a station on a track at Heathrow Airport. The PRTs (known as pods at Heathrow) are both purple and white, and are approaching on a single-lane paved track. To the left of the track is an airport parking lot: cars are parked in the lot and location signs are posted indicating the Zone and Row that the cars are parked in. On the right is another pod track (presumably for pods travelling in the opposite direction), which is currently empty. A metallic overhang reflects the colors on the on-coming pods at the top of the photo.

Figure 20. Photo. ULTra Personal Rapid Transit (PRT) track at Heathrow Airport.

 

Two personal rapid transit vehicles (PRTs) parked at Station A in a parking lot at Heathrow Airport. The PRTs (known as pods at Heathrow) are purple and white and have the Heathrow logo written on the side windows. The pods are small, only carrying six passengers at a time. The pod station is a small glass enclosure; a sign reading “Station A” is partly visible around the top left hand side of the enclosure. Behind the station is long-term airport parking lot.

Figure 21. Photo. ULTra Personal Rapid Transit (PRT) vehicles and station at Heathrow Airport.

Advanced City Cars

The final category of vehicles in the CityMobil project, the advanced city cars, are less precisely specified than the other vehicle categories. These could be vehicles equipped with driver assistance systems for partial driving automation or vehicles that could be operated without drivers if they were being led in a platoon by a lead vehicle with a driver (e.g., for repositioning of vehicles in a carsharing operation). Another application that was discussed during the conference was vehicles that could provide enhanced mobility for elderly people who are no longer able to drive themselves. The most ambitious part of the presentation about this element of the project by Gianfranco Burzio of FIAT was the introduction of the FIAT Mio concept vehicle. This concept vehicle, developed for the 2010 Torino motor show, was based on inputs suggested from many online participants around the world. The features that they requested, and that were incorporated in the vehicle, included fully automated driving on dedicated highway lanes and in-motion recharging of the electric vehicle propulsion batteries. The Web site for this concept vehicle includes an elaborately staged video of the vehicle in operation (the video is in Portugese, because it was targeted to a Brazilian audience, but it has English subtitles). The video can be viewed by accessing the following link:

http://www.youtube.com/watch?v=aCPrg2TQui0&playnext=1&list=PL5FED4D80C03D0EA0.

Automated Vehicle Certification

One of the most challenging issues that CityMobil encountered was the certification process for obtaining approval for operation of the automated vehicles in a public environment. The CityMobil team is concerned that it will be necessary to have a common legal and certification framework for gaining approvals for deployment throughout Europe in order for the automated vehicle market to pose acceptable business risks to suppliers. As previously mentioned, certification issues forced the application planned for Rome to be changed significantly to eliminate all possible interactions between the automated vehicle and other vehicles and pedestrians. If these types of restrictions were to be encountered everywhere, the CyberCar concept would not be deployable. At the other end of the spectrum, the Heathrow PRT went through a railroad-level certification process, which is a well-established process but also extremely conservative in its assumptions and expensive to satisfy. TNO, the prime contractor for CityMobil, has a lot of experience with safety certification, and they use a rather traditional risk-based approach, in which the stakeholders determine what level of hazard they can accept, by analogy with comparable existing systems, and then design to that level.

For CityMobil, they assumed that the safety numbers for automated vehicles should be twice as high as that of existing road traffic based on road traffic safety statistics.  In the TNO process, the severity of outcomes and their frequency of occurrence were treated as two dimensions of a matrix, and hazard level values were assigned to each cell of that matrix. The combinations of severity and frequency that exceeded an acceptable threshold level of hazard were highlighted as unacceptable.

Questions were raised at the conference about how the TNO process can account for the complexity of software–intensive control systems for automated vehicles, with their multitude of possible outcomes. The answers to these questions were not satisfying, because they were based on assuming a process of documenting each stage of the development process, with failure mode effects and criticality analyses. Offline discussions with automotive industry participants who were attending the conference indicated that they recognized that this process is inadequate for addressing the safety of software systems, which remains an important unresolved problem.

Non-Technical Risks

Public agencies perceive significant non–technical risks associated with automated vehicle deployment, in addition to the technical risks. For example, the PRT systems have uniquely designed vehicles that must operate on uniquely designed guideways, so that once a locality commits to deploying a specific system, they are locked into a proprietary technology with only one supplier. This leaves the locality vulnerable to monopoly pricing for future expansions, as well as to the risk of premature obsolescence if that supplier goes out of business. Because the developers of most of the systems (not just the special guideway systems) are small companies, the risk of a supplier going out of business and not being able to provide future maintenance and support is very real.

Operating Costs

A discussion of operating costs of driverless vehicles revealed that the existing, relatively small fleets of driverless vehicles (e.g., the Rivium people-mover near Rotterdam) have operating costs comparable with those of conventional bus systems. This seemed surprising, because the dominant element of conventional bus operating costs is the driver labor, and no drivers are needed for driverless vehicles. The answer was that the maintenance labor costs compensated for the lack of driver labor costs. A certain minimum number of maintenance people are needed full time to handle any problems that may arise, and with a complicated system, one person cannot be expected to know how to fix all possible problems. When the number of vehicles is small, this fixed labor cost per vehicle can be high, but the cost will be reduced when it can be spread across a larger fleet of vehicles.

Challenges

There was considerable discussion of the challenges to widespread deployment of automated urban transit vehicles, and there seemed to be general agreement that there are multiple challenges, as follows:

These problems were identified, and strategies were suggested for finding solutions for some of them, but solutions do not appear to be imminent.

Public Attitudes

On the positive side, many people attending the conference thought that public attitudes in Europe were shifting in favor of innovative transit services and away from automobile use. The impression is that the public values mobility rather than car ownership. Marketing approaches were suggested to make transit options emotionally appealing to people. One person even noted that a recent opinion poll found that young people were more inclined to perceive cars as “Viagra™ in chrome.”

Public Operational Test

The EC is preparing to sponsor a public operational test of an automated transit system, representing a follow–on project to CityMobil. Several cities that would like to compete for the operational test made their pitches at the conference.

eLanes

One of the most important concepts developed in CityMobil is the “eLane,” which signifies a special subset of the roadway infrastructure in which the vehicle automation functions can be used. The publications on the subject of eLanes have been somewhat vague about the definition, leaving considerable uncertainty about how much physical separation would be needed between eLanes and other traffic. This uncertainty is real and continues to persist: Participants in this research confirmed in offline discussions that substantially more research is needed to determine what levels of vehicle automation can be applied with what degrees of physical protection from intrusion. This corresponds to the situation that the NAHSC researchers encountered in the United States in the 1990s, in which the question of dedicated and protected lanes was one of the most controversial issues. Despite more than a decade of effort since then, the issue remains unresolved, but there at least appears to be general agreement within CityMobil on the principle that fully automated vehicles cannot mix entirely with conventional traffic unless they are operated at very low (i.e., walking) speeds. Some degree of separation and protection is required.

2010 SMART-64

The EC, through DG–CONNECT, sponsored a small study in 2011 to investigate the impediments to deployment of vehicle automation systems and to determine what steps need to be taken to overcome them. This project, labeled SMART–64, was intended to define the framework for the next generation of EC work on automation. The project team was led by TNO from the Netherlands, with major subcontracts with the University of Southampton in the United Kingdom (UK), DLR (German Aerospace Research Laboratory), Frost and Sullivan and Tecnalia. Their final report summarizes the findings from their study, including stakeholder interactions in a European workshop.(19) The emphasis in this study was very heavily focused on private automobile applications, with limited attention paid to trucking and virtually no attention paid to public transport systems, reflecting the focus of the larger DG–CONNECT projects.

Figure 22(20) depicts the types of automation concepts that were considered in each of three different road environments in the SMART-64 study, and figure 23(20) shows estimates of the deployment time frames for applications clustered in functional groups. The blocks in gray in figure 22(20) were considered to be “pre automation” systems that could support automation rather than automation systems that take on vehicle control responsibilities. The applications that were assumed for the highway environment were largely partial automation rather than full automation, with the exception of a “safety pull over,” which is a system that would automatically take over full control of the vehicle and move it to the highway shoulder, where it would be automatically stopped if the driver were to become disabled. This appears to be an exceptionally challenging application. The applications selected for the urban environment were generally providing low levels of driver assistance, comparable with systems that are already commercially available on some cars. The applications defined for the dedicated lane environment are closer to an automated highway system, but in this scenario there is no reference to providing any physical protection against intrusion of debris or unauthorized vehicles, only a legal prohibition against use of the lane by unauthorized vehicles.

The SMART-64 project report created its own definitions of automated driving, cooperative driving, and autonomous driving, but these definitions are rather awkward and misleading. The project defined automated driving as a driver assistance system with partial automation of the driving functions and the driver being either in control or able to quickly resume manual control. The project defined cooperative driving as the use of ICT in conjunction with automated or non-automated driving vehicles, overlooking the fact that any level of automation or driving assistance will of course have to depend on ICT (e.g., sensors, computers, software, and communications). The definition then mentioned V2V and V2I communications, with the implication that somehow these represent the totality of ICT, even though there are many other elements of ICT. SMART-64 defined autonomous driving as fully automated driving, with no human intervention in the driving process, and declared this to be outside the scope of the project, which addresses a time horizon up to the year 2025 for private automotive vehicles.

SMART-64 also defined three institutional scenarios for the stimulation of automated driving, one led by government, one led by industry, and one based on “disruptive developments.” It is curious to note that there was no scenario involving coordination of government and industry activities, which would probably be the most likely to succeed. Subsequent discussion with one of the project leaders revealed that the absence of this scenario was intended to steer readers to draw that conclusion themselves by seeing the limitations of the strictly government–centered and industry–centered scenarios.

The focus of the government–led scenario was on gaining societal benefits, stimulated by infrastructure investments. Suggested government actions included:

The authors of the SMART-64 project report then concluded that public benefits would be limited compared with the benefits of cooperative systems, creating an artificial dichotomy between automation and cooperation.

The private–sector–focused scenario assumed that the vehicle industry would build on current products, with government playing only a passive role (although the report acknowledged in passing that ideally both public and private sectors would take active roles). The private sector was assumed to be involved in:

The main focus of the private-sector–focused scenario would be on making automated driving systems both reliable and affordable. The authors expressed their doubts that the private sector would develop automated driving systems that depend on road infrastructure changes.

The disruptive developments scenario was based on the dream that artificial intelligence technology would somehow provide the ability to drive fully automated vehicles in mixed traffic, most likely motivated by the publicity generated from Google’s “self-driving” car.

SMART-64 included a summary of driver assistance products that are already on the market, categorized as warning systems, assisting systems, and “toward CACC,” which is a rather odd classification scheme because this third category contains both warning and assisting systems. The review of the current state of the art made optimistic assumptions about the capabilities of these current systems relative to automated driving, which colored some of the conclusions and recommendations in the study. The review tabulated these in terms of the well-known “technology readiness level” (TRL) measure of technology maturity, without accounting for the higher levels of maturity and robustness that are needed when the driver’s role is reduced. The authors even claimed that “current technology is ready for autonomous (sic) driving on separate segregated lanes in a controlled environment,” citing the examples of automated people movers and the first generation PRT systems that are already in use, without recognizing the differences in costs and complexity when trying to apply this on a wider scale.  They also assumed, erroneously, that these exclusive guideway systems use the same obstacle detection and sensor systems as advanced driver assistance systems for cars.

The authors of the SMART-64 report contended that dedicated lanes are not feasible on cost grounds and that “automated vehicles will have to be mixed with manually driven vehicles, at least in the early days.” They then introduced the eLanes concept from the CityMobil project but interpreted it to involve coexistence of fully automated and manually driven vehicles rather than the separation envisioned by the creators of the concept. This perspective appears to ignore the extreme technical challenges that would have to be solved to enable safe coexistence of fully automated and manually driven vehicles.

The authors of the SMART-64 project report explored several aspects of automated driving in more detail, as presented in the following sections.

Depiction of the types of automation studied in various environments for the SMART-64 project. The vertical axis of the chart measures increased complexity in automation; the horizontal axis describes the three different road environments considered in the study. The different types of automation are either colored gray (indicating “pre-automation” systems) or white. The column on the left is colored green; this describes automation types studied in mixed traffic and highway settings. The levels of automation in this column, from lowest to highest, are: drowsiness warning (colored gray); forward collision warning (colored gray); automated lane keeping; automated steering assist; lane merge assist; safety pull over; and CACC (cooperative adaptive cruise control). The middle column is blue and describes a mixed traffic and urban environment. The levels of automation in this column, from lowest to highest, are automated parking, contextual speed limit, and emergency braking (none of these is colored gray). The right column is light blue and describes dedicated lanes; the automation levels from lowest to highest are: road pricing (gray), fuel use (gray), lane keeping, and CACC.

Figure 22. Chart. Automation concepts considered in the SMART-64 project. NOTE: CACC = cooperative adaptive cruise control.

 

A semi-circle divided in to three layers; the circle is further divided into eight segments. Each segment represents a group of automation applications (information/entertainment; warning; lateral driver assistance; longitudinal driver assistance; emergency; eco-driving; traffic management; and comfort. The layers represent the timescale of deployment for the various applications: now (the inner layer), 2020 (the middle layer), and 2025 (the outer layer). The various applications are listed as belonging to both a group (depending on which segment it is in) and a timescale (depending on whether it is the inner, middle, or outer layer). Most of the 29 applications are in the lateral driver assistance, longitudinal driver assistance, and traffic management groups, and most will deploy between now and 2020.

Figure 23. Chart. Automation applications and their deployment timescales assumed in SMART-64 project.

Vienna Convention on Road Traffic

This set of rules, adopted by most European countries, includes several provisions regarding drivers’ control of vehicles that weigh against full automation of driving, unless the driver can maintain control by overriding the automation system. The researchers for the study noted that there are loopholes and opportunities to amend the Vienna Convention rules so that they need not serve as a permanent obstacle to automation. The authors of the report concluded that there is no need to adopt a strategy for handling the Vienna Convention rules on road traffic until there is an agreed-upon deployment staging strategy for road vehicle automation.

Liability

It was noted that different countries in Europe still have substantially different legal systems; thus, there is no consistency in how liability is handled across the continent. A substantial in-depth study will be needed to sort out these differences in legal systems and the diverse operational concepts of vehicle automation systems to determine how such liability would be handled. This is an important issue for vehicle manufacturers because they need to be able to market their vehicles throughout the continent and would be reluctant to proceed with market introduction until they knew that there would be a consistent and predictable legal environment for handling liability. This might require European legislation.

Some additional issues to consider in terms of liability are as follows:

Reliability

Automated system reliability was explored in the context of the ability of the driver to recover control quickly enough to avoid a crash. This will require clear definition of the responsibilities of the driver versus the vehicle provider. It was also recognized that additional work will be needed on developing fail-safe mechanisms, in-vehicle and I2V health checks, HMI systems to alert drivers about problems and to manage the control transitions, and infrastructure features to augment system safety.

Recommendations in the report for EC actions included:

Controller Development

The report recognized the important challenges in software complexity and cost reduction before automation systems can be widely deployed, but it made unrealistically severe assumptions about the computational update rate that would be needed (assuming 1 millisecond).

Drive-by-Wire Technology

The authors of the report devoted disproportionate attention to the technical issues associated with “by wire” actuation, without recognizing that the required actuation for vehicle automation can be accomplished by using less risky technologies that are already widely used on electric and hybrid vehicles.

Sensor Systems

The authors of the report enumerated the types of sensor technologies that would be required in vehicles and the infrastructure to implement automated driving; wireless communication was included as one of the sensor technologies. The authors adopted an optimistic view of the maturity of the current sensor technologies, without considering the challenges associated with adverse environmental conditions.

Positioning Technology

The authors of the report also reviewed the types of positioning system performance that might be needed for automated driving but underestimated the update rates that would be needed for good vehicle control performance.

Cross–Border Driving

Because European countries have so many borders that road vehicles would be expected to cross frequently, a section of the report was devoted to the issues that need to be resolved to ensure smooth and safe cross–border operations of automated vehicles. These issues include the need to establish well–defined standards to ensure interoperability of vehicles and the cooperating infrastructure where that is needed.

Interactions with Human Drivers

The authors of the SMART-64 project report focused on scenarios with partial automation—rather than full automation of driving—and included the statement, “The driver is and must stay in control; responsibility remains with the driver.” Yet parts of the report also addressed issues that arise with fully automated vehicles. The driver interaction research questions were identified as:

Dutch Programs

The Netherlands has several relevant current activities that address partial vehicle automation and some potential precursors, all with a very strong emphasis on cooperative systems. These activities were all showcased during the “automotive week” activities in Eindhoven in mid–May 2011. It is notable that these activities are most strongly driven by regional economic development interests centered in the North Brabant province around Eindhoven, which sees itself as the “Brain Port” for the country and the center of automotive industry activity. The multitude of projects in the Netherlands is confusing to sort out, particularly because some of the names are quite similar even when the projects and their participants are different.

Strategic Platform for Intelligent Transport Systems

The Strategic Platform for Intelligent Transport Systems (SPITS) was a consortium of 13 companies and universities funded by the Dutch Ministry of Economic Affairs, from July 2009 to June 2011, to position the Netherlands for a strong role in future European projects and to encourage commercialization of the results of prior projects. The work of SPITS includes the development of a unique test site along the A270 highway between Eindhoven and Helmond. Along a 5-km (3-mi) stretch of this highway, 48 video cameras were mounted on poles, providing continuous and overlapping coverage of all vehicle movements. The real-time video images were fed back to a control center where image processing software produced continuous traces of the trajectories of all the vehicles traversing the section of roadway. This site provides an outstanding data recording capability that can be used in experiments that investigate traffic flow stability and countermeasures for improving stability. This same stretch has continuous coverage by 5.9 GHz DSRC, based on 11 DSRC transceivers installed along the roadside, providing an environment for testing V2I and I2V cooperative strategies.

Advisory Acceleration Control Field Test

The Advisory Acceleration Control (AAC) field test was an innovative experiment conducted by TNO under SPITS auspices in which drivers of 48 vehicles were provided with a display (implemented using TomTom hand–held navigators reprogrammed for the purpose) to advise them whether to accelerate, decelerate, or maintain their current speed, based on use of an algorithm designed to dampen traffic shock waves.

During a weekend period in February 2010 when the A270 highway was closed to the public, these drivers were lined up in one lane of the highway, while another 48 vehicles in an adjacent lane were unequipped with driving aids. The vehicles at the head of the two streams of vehicles followed a prescribed speed profile, with speed variations intended to promote shock waves among the followers. The dynamics of the two traffic streams were compared by using the trajectory data extracted from the roadside video systems, and the advisory display was shown to reduce the severity of the shock wave. An example of these results is shown in the distance–versus–time plots of figure 24.(21) in which the lighter color and higher slope of the plots on the right (representing higher traffic speeds) indicate how the shock wave was attenuated by use of the AAC guidance system. This was meant to demonstrate a potentially near-term application that could smooth out traffic flow in the same way that CACC would, but without requiring that vehicles be equipped with the relatively expensive ACC control system.

Dutch Integrated Testsite for Cooperative Mobility

The Dutch Integrated Testsite for Cooperative Mobility is a new initiative, created in May 2011, to bring together diverse Dutch interests as a successor to SPITS, with a particular emphasis on becoming the European test site of choice for all future cooperative ITS services. It will, of course, need to compete with other sites for specific project opportunities.

Connected Cruise Control

Connected Cruise Control is a project of the Ministry of Economic Affairs for providing individualized speed, lane selection, and gap advice to drivers to deter the formation of shock waves in traffic by smoothing out speed variations. This project is under development by a consortium of universities and companies, beginning in 2010 and aiming for commercialization of a product by 2013.

Connect and Drive

This project of TNO Mobility and Transport and the Technical Universities of Eindhoven and Twente has developed and tested a prototype cooperative ACC system, aimed at longer term implementation when there is a high market penetration of cooperative vehicles. Although it is expected that the first practical application will be for heavy truck platoons, Toyota Prius vehicles served as the demonstration platforms (figure 25)(22) and showed very good performance in the low-speed demonstration of four vehicles that was performed for visitors in May 2011. The parameters of the CACC system could be adjusted by using the vehicle’s touch–screen display, which was reprogrammed for this purpose (figure 26).(16) These vehicles accomplished their cooperation by using WiFi communication, because DSRC radios were not available to the project team at the time they integrated the vehicle systems, but they recognized the need to migrate to DSRC and did so in subsequent work, using IEEE 802.11p and the ETSI (European Telecommunications Standards Institute) protocol stack.

Photo of two distance-versus-time plots that compare traffic streams; recorded during the Advisory Acceleration Control field test of adaptive cruise control (ACC) vehicles. Distance in meters is represented on the vertical axis, going from 0 at the bottom to 1,200 at the top in increments of 200. Time in seconds is depicted on the horizontal axis, going from 0 to 150 left to right in increments of 50. Both photos show the plot in a spectral pattern that goes from the bottom left corner (0 for time and speed) to near the upper right corner (1,200 meters; between 100 and 150 seconds). The spectra go from shades of blue at the bottom, to yellow around the 800 meters/100 seconds mark, and then back to blue. The plot on the left (the unequipped vehicles) is more yellow (and even a little red) at the 800 meters/100 seconds mark than the plot on the right (ACC-equipped vehicles), representing the difference in shockwaves between ACC and non-ACC vehicles.

Figure 24. Photo. Distance–versus–time plot comparing a stream of 48 Advisory Acceleration Control vehicles (right photo) with 48 unequipped vehicles (left photo).

 

Daytime photo of a platoon of six cars. A black Toyota Prius leads a platoon made up of five silver Priuses. The oncoming cars are driving closely together (less than a car length apart) on a two-lane highway; there are no other cars on the road. It is daytime, but all of the cars have their headlights on. The cars all have Dutch license plates. 

Figure 25. Photo. Cooperative adaptive cruise control platoon of Toyota Prius vehicles developed as part of the Connect and Drive Project.

Grand Cooperative Driving Challenge

The Grand Cooperative Driving Challenge was an international competition that was inspired by the DARPA Challenges and organized by TNO and the High–Tech Automotive Systems program, with sponsorship from the local and regional governments around the competition site in Helmond, a suburb of Eindhoven. In contrast to the DARPA Challenges, this challenge depended heavily on V2V and I2V cooperation, requiring that the competing teams not only control their own vehicles well but also communicate good information to the vehicles from the other teams. This significantly raised the awareness of the competing research teams—11 university groups from throughout Europe—to the importance of cooperative systems and their advantages over autonomous systems.

The vehicles were staged through two scenarios, one representing urban traffic conditions (figure 27)(23) and the other representing highway traffic (figure 28).(23) The final competition was held in May 2011, in combination with several other cooperative system events, and was won by a team from the Karlsruhe Institute of Technology in Germany.

Photo of a cooperative adaptive cruise control (CACC) touch-screen control panel. The touch screen is divided in six areas, each with buttons controlling different aspects of CACC. The top area indicates type of vehicle (passenger vehicle or truck; the passenger vehicle indicator is lit) and roadside units (RSU) (merging RSU, roadworks RSU, and invisible); none of these buttons is lit. Below this area to the left are buttons regarding cruise speed (currently indicated as 75 km/h). To the right are buttons for user time headway (indicated as 0.7 seconds). The next area to the right indicates user control mode (the CACC indicator is lit). To the right of that is an area indicating MIO (most important object) data mode (the Wi-Fi and Radar indicators are both lit), as well as control mode (on standby). The bottom area of buttons indicates RSU status (received).

Figure 26. Photo. Touch-screen control panel for adjusting parameters of a cooperative adaptive cruise control (CACC) test. Note: RSU = roadside units, CC = cruise control, ACC = adaptive cruise control.

 

Shock Wave Mitigation with Mixed Equipped and Unequipped Vehicles

During the same period as the Grand Cooperative Driving Challenge, the SPITS A270 test site was used for another experiment, attempting to mitigate congestion shock waves by two alternative means: (a) giving some drivers detailed real-time in-vehicle advisories about their driving speeds; and (b) providing the same drivers with CACC speed control, with the set speeds commanded from the roadside. The advisory speeds for both of these strategies were determined in the same way, making use of the detailed real-time traffic data from the video monitoring of the 5–km (3–mi) test section of highway to identify potential shock waves being formed and then instructing the equipped vehicles what speed to travel for breaking up the shock waves. The people working on this project recognized that the intensive video monitoring infrastructure of this highway test section would not be replicable on normal roads, however this was being used to emulate the kind of data that could be available with widespread market penetration of probe vehicle monitoring.

The experiment was performed with a string of 70 vehicles, 8 of which were equipped for infrastructure-cooperative ACC and 12 of which had driver advisory displays, scattered at fairly uniform intervals along the string of vehicles. The shock waves were deliberately induced by the lead vehicle in the string, which slowed down so that the driver could look at a roadside incident (which also made it more likely that the other drivers would be tempted to slow down to take a look). The trajectories of all the vehicles were recorded to see what effects could be achieved with the advisory system (with specially trained drivers instructed about following the advice so that they would be more likely to follow it than would be drivers from the general public) and with the CACC system. The locations and trajectories of the vehicles were observed from a traffic management center.

Figure 29(24) shows one of the displays from the TMC, with the locations of the vehicles superimposed on an aerial photograph of the roadway, with red marks signifying equipped vehicles and green marks signifying unequipped vehicles. Note that a long sequence of unequipped vehicles was deliberately grouped at the start to get the shock wave triggered, and the increased density of the vehicles there is evident in the photo. The red marks and the green marks following them represent the mixture of equipped and unequipped vehicles, attenuating the shock wave by requiring the red vehicles to maintain appropriate gaps relative to their predecessors, which the drivers are not able to determine on their own without assistance. The blue camera icons along the side of the roadway in figure 29(24) show the locations of the video cameras that are used to monitor the trajectories of all the vehicles.

Figure 30(16) shows the monitors at the TMC, which display the distance–versus–time plots in real time during the experiment. To the right side of the right monitor in figure 30,(16) the white gaps represent the extra gaps in the traffic stream created by the equipped vehicles following the speed guidance, thereby breaking up the shock wave. The preliminary indications are that the CACC vehicles were somewhat more effective at dissipating the shock wave than were the vehicles with the guidance displays, which were more subject to the uncertainties of driver responses (even with specially trained drivers instructed to follow the guidance as well as they could).

In the urban scenario, participants competed against one another on a course that included traffic lights. Before the scenario starts, participants are randomly and evenly distributed over two lanes (Lane A and Lane B) at two intersections—one behind the other—with red stop lights at each intersection. A Lead Vehicle is located between Lane A and Lane B at the first stop light. There is a horizontal line that marks the mid-point between the first and second intersections. The light at the second intersection turns from red to green to signal the start of the scenario. Once the first vehicle crosses the central horizontal line, the light at the first intersection is triggered to also turn green. After all of the participants have gone through the second intersection, the challenge is finished.

Figure 27. Diagram. Urban scenario of the Grand Cooperative Driving Challenge.

 

The diagram is divided in to four illustrations. The first illustration shows the start of the highway scenario: participant vehicles are lined up in two lanes (Lane A and Lane B), with a Lead Vehicle located ahead of them between lanes A and B. Participants in Lane A are evenly spaced; the Lane B vehicles are spaced at varying intervals. The second illustration depicts the vehicles as they are driving on the course: disturbances are affecting the Lead Vehicle, which is causing a shock wave behind the participants. The third illustration shows the vehicles as they are crossing the finish line. The fourth illustration depicts the layout of the course: the finish line, the starting line, and five marked intervals along the course.

Figure 28. Diagram. Highway scenario of the Grand Cooperative Driving Challenge.

 

The photo shows the A270 highway—cleared of traffic for a congestion shock wave test. The aerial view shows a two-lane highway surrounded by green fields and trees. Superimposed on the photo are markers showing the locations of vehicles during the test. There are 23 markers visible (70 vehicles total were used in the test): five are red (indicating vehicles equipped with either cooperative adaptive cruise control (CACC) or driver advisory displays), and 18 are green (indicating unequipped vehicles). The markers appear to be evenly-spaced along the highway. Eight blue camera icons showing the locations of the video cameras—used to monitor the trajectories of the vehicles—are also evenly-spaced along the side of the highway.

Figure 29. Photo. Aerial view of A270 test site with vehicle locations superimposed.

 

Two computer monitors displaying real-time plots of distance-versus-time diagrams. The monitor on the left shows a graph with a shock wave pattern of yellow bleeding in to red that goes up and to the right. The monitor on the left shows blue and green streaks in a shock wave pattern, also going up and to the right. The upper right hand corner of the second pattern shows white gaps in a field of green.

Figure 30. Photo. Real–time plots of distance-versus-time diagrams during an attempt to mitigate congestion shock waves.

 

The chart is divided into five fields: Name of project, Topics, Funding, Start and End dates. Of the 16 projects, four are automation projects (highlighted in red) and four are cooperative systems projects (highlighted in green). The cooperative systems projects are INFRACALL, PARTAGE, PLATA, COPERCOM, and SCOREF. The automation projects are HAVEit, PARTAGE, ABV (Automatisation Basse Vitesse, a French project), and e-Future. The cooperative systems projects are the ones that are relevant to this report. The topic of the HAVEit project is co-piloting; the start date is 2007 and the end date is 2010. The PARTAGE topic is man-machine interaction; the project goes from 2009 to 2012. The topic for ABV is low-speed automation, and the project runs from 2009 to 2012. Finally, the e-Future topic is ADAS (advanced driver assistance system) for electric vehicles; it runs from 2010 to 2013.

Figure 31. Chart. Relevant current projects at France’s LIVIC laboratory. NOTE: ABV = Automatisation Basse Vitesse.

 

French Programs

Although the French Transport and Research ministries have been supporting research on ITS topics for many years, relatively little of that research within the past decade has been directed toward the longer term issues of vehicle automation. Interest in automation is being revived within the vehicle industry, and it has remained strong among researchers all along. Recent increased research activity related to vehicle automation has been evident within economic competition channels rather than within more traditional transportation or research channels. The increased research activity has been motivated by concerns about energy saving, mobility, and preserving accessibility for senior and disabled citizens.

The central group for research on automated driving of road vehicles is the LIVIC laboratory in Versailles, France, now a part of IFSTTAR. LIVIC developed a useful chart that lists their active projects on automation and cooperative systems, as can be seen in figure 31.(25) The project names that are highlighted in red boxes are the most relevant to this review. The LIVIC researchers have been influenced by working with researchers from other countries on European projects, such as HAVEit, and have adopted the concept of protected eLanes, for example. They are in the process of forming a larger vehicle automation research cluster with other leading French research labs, including INRIA and the research groups of the Ecole des Mines.

One unique national project listed in figure 31(25) is Automatisation Basse Vitesse, a €5.5 million ($7.2 million) project that is focused on low-speed vehicle automation (the meaning of the French words that are abbreviated in its acronym). This project intends to improve fuel economy for vehicles driving in congested traffic on urban and suburban freeways. The project was developed based on the concept of a “secured road,” meaning that there should be communication and cooperation between vehicles and roadway infrastructure. This could include sensing technology and special markings on the infrastructure to facilitate vehicle automation, but the infrastructure should still be capable of being shared to some extent with conventional traffic.

PARTAGE is a related project that is focused on sharing responsibilities between the driver and the automation system. This builds on the “co-pilot” concept in HAVEit, with a “decision unit” that shares responsibilities with the driver and could indeed override the driver’s decisions in some cases after warning him or her. The research is extending beyond the technical issues in sensor fusion, communication, and control in an effort to also deal with legal and standards compliance issues and assessments of impacts on traffic congestion and fuel consumption.

The French research institutes and automotive companies are also working on the development of vehicle automation capabilities that can be used in support of carsharing services, especially for electric vehicles with limited range. Within an office park or research campus, the shared vehicles could be deposited at locations that do not match well with the upcoming demand patterns. One employee manually driving a lead vehicle would collect the vehicles and act as their platoon leader, while the following vehicles would follow through electronic coupling with nobody onboard. This kind of operation could be performed on a special-purpose dedicated roadway infrastructure that minimizes the complexity of the driving environment and the interactions with pedestrians and other vehicles.

France is an active participant in European field operational tests, and in addition to the EC-funded projects, they have also established their own field operational test project for cooperative systems, called SCORE@F, in collaboration with the European Drive C2X initiative. This will include eco–driving at traffic signals and driver assistance systems for safety but will not include fully automated driving, because that is still viewed as being too futuristic to be ready for use by naive drivers.

German Programs

KONVOI Project

The KONVOI project was sponsored by Germany’s Federal Ministry of Economics and Technology (not transport) as an examination of the impacts that a truck–platooning system could have on traffic flow, fuel consumption, and the environment. Because researchers for the CHAUFFEUR project had already performed extensive truck-platoon technology development and testing between 1996 and 2004, KONVOI began with the assumption that any technological problems were close to being solved.

In this case, a research team from the RWTH Aachen University, the heavy vehicle and vehicle supply industry, and major trucking firms developed the project to evaluate how a truck platoon system could operate in practice on public roads. This project had about €4 million ($5.2 million) of government funding, plus industry contributions, which raised the total budget to approximately €5.5 million ($7 million; similar in scale to the newer SARTRE project). KONVOI was active from mid-2005 to mid-2009, and the work is now complete. There is no direct follow-on project.

The technical implementation of the KONVOI platooning system was based on the integration of components and subsystems that were already commercially available or getting close to commercial availability and did not depend on any exotic technologies because the project partners believed that the technology was already relatively mature and close to deployable. The control design approach is conceptually very similar to the approach that PATH has adopted in the United States but with some differences in specific sensing technology. KONVOI’s concept of operations for application of the truck platoons in public mixed traffic, coexisting with other vehicles and drivers, was constrained by the need to acquire authorization from government agencies and safety certification authorities before they could conduct their tests.

The target concept for KONVOI is of a platoon of up to four trucks that would drive in mixed traffic on the highway, with the driver of the first truck making the strategic maneuvering decisions for the platoon, using his own eyes combined with assistance systems to give warnings about potential hazards in the driving environment. The drivers of the following trucks would be in a passive mode, monitoring their trucks for problems and being prepared to intervene if necessary by taking over control in case of a failure or emergency. The goals of this truck platoon are to increase the capacity of the highway lane by enabling the trucks to use less space (running at shorter gaps) and reduce fuel consumption and greenhouse gas production by running them close enough together that they could save aerodynamic drag. 

The minimum allowable gap between trucks was set at 10 m (33 ft) based on analyses of the effects of cut–ins at highway entrance ramps, where hard braking of the following truck could be required. For the constant distance separation policy used here to support energy savings at all speeds, it is essential to have V2V communication to achieve string stability of the platoon. The researchers actually tested emergency braking maneuvers with two trucks on the test track, with the first truck decelerating at 0.7 g (7 m/s2 or 22.5 ft/s2) and the second truck responding to that. During this braking maneuver, the gap between the trucks was reduced from 10 m (33 ft) to 5 m (16 ft) before they stopped because of the finite delay time before the second truck could apply its brakes, but they were still able to avoid a crash. This test was one of project’s more important accomplishments.

The lateral control of the KONVOI trucks was based on use of a wide-angle, multi-beam laser sensor at the front of each truck, which detects the lane striping, measures the distance to the forward truck, and detects cut-in vehicles. With the wide field of view, the sensor can see the lane markings even at the shortest permitted gap between trucks of 10 m (33 ft; but that would not have been possible at the significantly shorter gaps of 3–5 m (10–16 ft) used by Energy ITS in Japan or PATH to achieve their drag reductions). In this way, each truck follows the lane markings directly rather than performing an “electronic towbar,” that is, following the lateral motions of the preceding truck as the CHAUFFEUR project was doing.

To change lanes, the planned operational concept was for the driver of the lead truck to look for a long enough gap in the adjacent lane for the entire platoon to make the lane change, to then activate his turn signal to alert all other drivers, and then for each driver to verify a safe gap next to his truck and press a button to confirm it. Although this was performed on the test track, the researchers were not authorized to test it on the public highway (and it does seem cumbersome and difficult to implement in practice). The drivers of the following trucks expressed a strong interest in having a live video feed of the forward view from the front truck so that they would know what was happening up ahead. It was not clear whether this would be useful in practice, but it would at least help the drivers feel more comfortable about their ability to make decisions. This concept would, however, impose a significant wireless communication burden.

After they performed an extensive set of tests on test tracks, the researchers tested the KONVOI trucks on public highways for 9 days, acquiring about 3,300 km (2,000 mi) of driving data. Of this, 2,100 km (1,250 mi) of driving data were collected by using the full four–truck platoon, as shown in figure 32.(26) During these tests, the platoons were followed by a police escort vehicle that had flashing lights and a sign that warned drivers approaching from behind that these trucks were special test vehicles. This police escort interfered with the testing goal of obtaining completely naturalistic driving data about the way drivers of other vehicles would interact with the truck platoon. The police escorts believed that drivers did not pay any special attention to them and that they behaved largely as they would have under normal conditions. With this caveat, there were still 13 cut–ins into the truck platoon by other drivers during the highway tests (an average of once per 250 km (155 mi) or once in approximately every 3 hours of driving), six of which occurred when the gaps between the trucks were only 10–15 m (33–49 ft). The platoon control system was designed to split the platoon as soon as a cut-in was detected by the wide–angle laser sensors on each truck, and these splits were performed correctly each time they were required.

Researchers claimed that the trucks on the test track achieved some fuel-consumption savings even when they were driving at the 10-m (33-ft) gap between trucks; however, there was no fuel-consumption savings in the tests on the public highway because the trucks had to vary their speeds to respond to traffic conditions and other vehicles on the road. The trucks’ control systems were designed to emphasize accuracy of gap control in vehicle-following (which is important for safety reasons, among other things). To achieve this accuracy, it was necessary to design the systems with a high bandwidth, which means that it makes frequent corrections and tends to be “busy,” which increases fuel consumption. This is a fundamental trade–off in the design of such systems and indicates the difficulty of saving energy and greenhouse gas emissions when the equipped vehicles have to share the road with unequipped vehicles that do unpredictable things.

There are only limited technical papers in English about KONVOI, and because the project was funded by the German government, the final reports are written in German.(27) As a result, there are few good reference documents available to cite; however, based on detailed discussions with several key people who worked on the project at RWTH Aachen, the following main observations are worth considering:

In sum, there are doubts as to whether the technical and non-technical issues facing the KONVOI system can be resolved successfully, because they are pulling the system design and operational concept in opposite directions (regarding the mixing of the truck platoons with general traffic).  The same conflicts might be found during U.S. attempts at automated truck platooning, and U.S. researchers will need to find ways of resolving these conflicts within their own environments.

An oncoming KONVOI platoon of four trucks driving on a highway in the right lane. The highway is lined with trees that do not have many leaves; it looks like it is the end of fall. The highway is divided by a narrow center median with grass and bare-looking shrubs growing there. A red van is behind the platoon in the left lane; directly behind the platoon is a white van.

Figure 32. Photo. Four–truck KONVOI platoon driving at 10-m (33-ft) gaps between trucks on a German autobahn.

 

German Study on Legal Aspects of Road Transport Automation

The German Federal Highway Research Institute, BASt (equivalent to FHWA’s Turner–Fairbank Highway Research Center), has been leading a study of the legal implications of road transport automation under German law, in collaboration with representatives of the German automotive industry. A BASt report (in German) was published early in 2012, and some informal presentations of its findings have been given in English at international meetings during the final quarter of 2011 and have attracted strong interest in Europe. This study is very significant because it combines technical factors, human factors, and legal expertise to make explicit determinations about what aspects of automation systems are clearly legal, clearly illegal, or in the gray area in between. For those aspects that fall within the gray area, BASt is currently identifying what research is required to resolve the ambiguities. The study is focused on automation in mixed traffic operations rather than in segregated or dedicated infrastructure, because this is where the issues are most complicated and where they are expected to first arise.

The most important initial contribution of this study appears to be a carefully developed definition of five different levels of vehicle automation, which was an essential prerequisite to addressing legal issues (figure 33).(28) These levels are:

Researchers for the BASt study found the first three levels of vehicle automation to be within the current legal requirements of the German road traffic codes, based on the driver’s duty to drive safely, to monitor the traffic and vehicle status, and to be prepared to override the vehicle automation in case of inappropriate system behavior. The two higher levels are not consistent with the current legal requirements because of the reduced driver role. It was also unclear whether a lane-keeping system that permits “hands–off” operation would be permissible, with more human factors research needed to determine whether this would adversely affect driver vigilance.

The BASt study group also thought that it would be important to conduct more research on both human factors and technical issues to determine the ability of drivers to recover control quickly enough to ensure safety at different driving speeds, as indicated in figure 34.(29) In this case, it would be important to compare the driver recovery times with the length of time during which the automation system could remain safe following a failure in each speed range.

The BASt group produced an effective set of Venn diagram graphs to illustrate the potential safety benefits and disbenefits of automation systems. The diagrams use a blue circle to represent present-day crashes associated with manual driving hazards, and a red circle to represent the changes in crashes that occur when the automation system is doing the driving. The BASt group’s general approach is illustrated schematically in figure 35,(16) where the overlaps between the circles represent the crashes that could potentially be eliminated by automation. The crescents outside the overlap area represent the crashes that would still occur after the introduction of automation. The relative sizes of the areas in the Venn diagram illustrate the net safety effects of automation in a way that can help facilitate outreach to the general public. Outreach to the general public was another important theme in the BASt study, because this was identified as the necessary mechanism for fostering the legal changes needed to authorize vehicle automation through the legislative process.

The BASt study also addressed the liability issues, identified separately as product liability and road traffic liability. In the product liability category, defectiveness was identified as the key concept, which depends on the instructions that are provided to the user to condition his or her expectations about system performance. These could be conveyed through the owner’s manual and by other means as well. This concept was used to distinguish reasonably foreseeable misuse from abuse by the driver. The manufacturer of the system would be responsible for consequences from the former but not the latter. Under current German law, the manufacturer would be liable for crashes that occur at the two higher levels of automation unless the crash could be determined to be solely the fault of the other vehicle or driver. The road traffic liability issue was identified to be particularly associated with platooned operations, in which each vehicle is no longer entirely self–sufficient, but its safety depends to some extent on the actions of the other vehicles in the platoon.

The identified research needs included:

 

BASt-Expert-Group definitions of vehicle automation-degrees. BASt is an acronym for BundesAnstalt für Strassenwesen, which is the Federal Highway Research Institute in Germany (the German equivalent to FHWA’s Turner-Fairbank Highway Research Center). The chart describes the various degrees of vehicle automation discussed in a BASt report published in 2012 on the legal implications of road transport automation in Germany. The degrees of automation are listed from highest to lowest. First is full automation: the system takes over longitudinal and lateral control completely and permanently. Next is high automation: the system takes over longitudinal and lateral control, and the driver must no longer permanently monitor the system. In case of a take-over request, the driver must take over with a certain time buffer. Below that is partial automation: the system takes over longitudinal and lateral control, the driver shall permanently monitor the system, and shall be prepared to take over control at any time. Below partial automation is driver assistance, in which the driver permanently controls either longitudinal or lateral control; the other task can be automated to a certain extent by the assistance system. And finally, there is driver only, where the human driver executes the manual driving task (no automation).

Figure 33. Chart. BASt definitions of levels of automation.

 

BASt chart that describes recommended vehicle automation systems at various speed ranges and automation levels. BASt is an acronym for BundesAnstalt für Strassenwesen, which is the Federal Highway Research Institute in Germany (the German equivalent to FHWA’s Turner-Fairbank Highway Research Center). The vertical axis compares speed ranges (low: parking, slow maneuvers; medium: congestion, city driving; and high: highways, express highways, motorways). The horizontal axis describes increasing levels of automation: assisting, partially-automated, highly-automated, and fully-automated. At low speeds, the recommended automation system at the assisting level of control is parking assistance with only automated lateral control; at the partially automated level, it is parking assistance with lateral and longitudinal control. At medium speeds, the automation system recommended for the assisting level is adaptive cruise control (ACC) with Stop and Go functionality; at the partially automated level it is congestion driving assistance. For high speeds, there are two recommended automation systems for the assisting level: lane-keeping assistance (LKAS) and ACC. For partially-automated vehicles, a motorway assistant (which includes both LKAS and ACC) is recommended. At the highly-automated level, motorway-chauffeur (which includes automatic longitudinal and lateral control that the driver does not need to permanently monitor) is recommended. And finally, at the fully automated level, motorway-pilot (which includes automatic longitudinal and lateral control that the driver does not need to monitor) is recommended.

Figure 34. Chart. BASt mapping of automation levels into operating speeds for safety. NOTE: Assist = assistance, ACC = adaptive cruise control.

 

Four Venn diagrams that illustrate the potential safety benefits and non-benefits based on the BASt study. BASt is an acronym for BundesAnstalt für Strassenwesen, which is the Federal Highway Research Institute in Germany (the German equivalent to FHWA’s Turner-Fairbank Highway Research Center). As described in the text, the diagrams use blue circles to represent present-day crashes associated with manual driving hazards, and red circles to represent the changes in crashes that occur when the automation system is doing the driving. The overlaps between the circles represent the crashes that could potentially be eliminated by automation (benefit); the crescents outside the outside the overlap areas represent the crashes that would still occur after the introduction of automation (non-benefit).

The first Venn diagram illustrates automation avoiding most current crashes but generating new ones, producing a net decrease in crashes. In this diagram, the overlap between the blue and red circles is slightly larger than the area of the outside crescents. The second diagram describes automation avoiding some current crashes, but creating enough new ones to produce a net increase in crashes (the overlap area is smaller than the outside crescents). The third diagram describes automation avoiding most current crashes, but generating no new crashes; the crescent area for this diagram is very small. Finally, the fourth Venn diagram describes automation avoiding some current crashes, but creating many more new crashes; the outside crescents are much larger than the overlap area.

Figure 35. Diagram. Venn diagram of automation safety benefits and non-benefits, inspired by the BASt study. Existing crashes that cannot be avoided by automation are represented by the blue circle, new crashes created by automation are represented by the red circle, and existing crashes that could be avoided by use of automation are represented by the overlap areas.

 

Private Automotive Industry Activities

The automotive industry in Europe has shown more interest in automated driving within the past few years than at any time since the completion of the PROMETHEUS program in 1994. Because the industry does not trust the infrastructure providers to be reliable providers of cooperative infrastructure, this interest has been shown unofficially rather than officially, through publicity demonstrations of autonomous partially automated driving. However, companies have been gaining practical experience with the operation of automated vehicles in specialized applications, such as robots driving test cars on test tracks or training race car drivers in “optimal” strategies for driving specific race tracks.  BMW even staged media demonstrations of automated driving for a test course in September 2011. Mercedes has presented videos at several public meetings of their test vehicles being driven by strap-on robotic vehicle controllers in precisely controlled close encounters, which would be unsafe and insufficiently repeatable if the vehicles were driven by humans.

European Commission Workshop on Automation in Road Transport

The EC organized a workshop in Brussels, Belgium, on October 26, 2011, to present and discuss the current state of the art and future needs in road transport automation. This was a rare opportunity to bring together the key people interested in the topic area throughout Europe, representing the vehicle industry and research institutions, as well as sponsors and participants in the projects associated with both DG–CONNECT and DG–RTD. The workshop was heavy on presentations, leaving very little time for question-and-answer sessions and interactive discussion, but it still revealed some contrasts that will have to be harmonized. At the most basic level, the DG–CONNECT work is strongly oriented toward the private automobile industry, whereas the DG–RTD work is multi-modal in its orientation, with an emphasis on public transit and trucking applications. This difference in perspectives colored the attitudes that were expressed about some of the key automation attributes, such as full versus partial automation and operations in dedicated lanes versus in mixed traffic. There were about a hundred attendees, who represented a broad cross-section of European ITS interests.

Juhani Jääskeläinen of DG-CONNECT (then still known as DG-INFSO) opened the workshop with a strong statement in support of the notion that “the time has come” for automation to be considered seriously as a means for improving Europe’s road traffic safety, mobility, and environmental impacts. The other options short of automation have been exhausted by now, but more gains are needed. Because there has already been a substantial amount of research on automation issues, Jääskeläinen is eager to find automation options that can be tested and deployed relatively soon. He wants to do what is good for the competitiveness of Europe’s automobile industry and for the health of its cities.

The bulk of the workshop contained a series of presentations about current European projects related to automation and cross-cutting issues associated with automation, with time for only a few questions after each presentation. The presentation slides are posted online at
http://ec.europa.eu/information_society/activities/esafety/2011/automation_workshop/index_en.htm.

Rather than reciting the details of all the presentations, which tended to cover many of the topics already reported in the preceding sections of this report, some of the highlights from the workshop and new insights are summarized as follows:

At the end of the workshop, there was a proposal to establish a European working group on automation, which would include representatives of the different parts of the EC, for developing a roadmap to define future work that will be needed under the next calls for proposals for EC research programs. There were no definitive answers to the various questions posed during the workshop, but a substantial number of topic areas were discussed and recorded.

The Working Group on Automation in Road Transport was established in response to this need for defining future work. The group began meeting in the spring of 2012 under the general structure of the European “iMobility Forum,” the stakeholder group that promotes deployment of ITS technologies. It is one of five parallel working groups that address specific ITS topics (the others being Clean and Efficient Mobility, Digital Maps, Vulnerable Road Users, and Nomadic Devices). The Working Group on Automation in Road Transport is considering a variety of automation functions that would be needed in four different operating environments for automated vehicles and identifying the cross-cutting issues that need to be resolved.

 

ResearchFHWA
FHWA
United States Department of Transportation - Federal Highway Administration