Implementation of an Automated Mobility-on-Demand System

Abstract

There is currently much discussion, development and research, both in expert circles and in the public sphere, concerning automated (or often “autonomous”) vehicles. Within this discourse, personally used vehicles assume a central position, that is to say, focus is geared toward increasing vehicle automation on city streets and highways.

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

1 Introduction

There is currently much discussion, development and research, both in expert circles and in the public sphere, concerning automated (or often “autonomous”) vehicles. Within this discourse, personally used vehicles assume a central position, that is to say, focus is geared toward increasing vehicle automation on city streets and highways. While the vision of automated passenger vehicles operating with no human intervention still seems a long way off, there are already examples where, either today or in the very near future, self-driving vehicles are or will be deployed in public transportation. The past few decades have given rise to successful railroad systems requiring no operating staff, and now the rail as a guidance medium is being replaced on our streets by satellite navigation and obstacle detection systems, which allow for an automated journey to the user’s destination of choice.

A wealth of experience can already be derived from such automated transportation systems to be applied in the future to the development of highly automated passenger vehicles, even if these transportation systems are frequently only operated in limited areas, such as downtown centers. The operational, user-specific, insurance-related or liability-based concerns for slow-moving, geographically limited vehicles are in many cases similar to those for the vehicles driven on highways. As such, there is a hope that the automated mobility-on-demand (AMOD) systems described here can, despite diverging objectives when set against highly automated sedans or SUVs, highlight a number of synergies, thus pointing the way forward for the deployment of the latter on public roads. This contribution will report on the implementation of such a transportation system at Stanford University in California. The goal of this report is to detail the findings and assist in future implementation of other automated vehicles.

2 Definition and Scope

This contribution primarily deals with “automated mobility on-demand systems”, or AMOD for short, and the respective vehicles that make up these systems. The term “automated” should be understood here in the context of vehicle automation, whereby computer systems are integrated into road vehicles in such a way that persons are relieved from the task of driving the vehicle. In the example dealt with in this report, driving tasks, which comprises “navigation”, “lane keeping” and “stabilization”, are performed in their entirety by computer systems. A driver is thus no longer necessary. In some cases even, no persons (i.e. passengers) are present in the vehicle at all. A vehicle may, for example, undertake an unladen journey for logistical purposes. This automation level is also termed “full automation”, in accordance with the definition provided by SAE J3016 [1].

The term “on-demand” denotes a transportation system that can be scheduled by the user for individual use (compare Chap. 2). This can be done via smartphone app, for example, whereby the user can summon the vehicle to his current location. This works in much the same way a taxi does, but with the notable difference that these vehicles do not require drivers. The term “transportation system” here denotes the aggregate system comprising several vehicles and a central infrastructure, which coordinates the vehicles for customer use.

The considerations presented in the following report relate to a mobility system in a urban area, i.e. a developed area with a high population density. This consists of roads, parking lots, bike lanes, sidewalks, pedestrian zones and buildings, where the transportation system will operate for the purposes of passenger transportation. The size of the urban area is less important here than the urban-structural characteristics—in other words, it is not of particular significance whether the area in question is a so-called “megacity” or simply a central area of a mid- or even small-size city. The transportation systems discussed here are considered as a general service in places where public transportation or personal automobiles do not represent an optimal solution for user mobility needs.

3 Description of an AMOD System

This contribution describes a concrete example of an AMOD system, namely the Navia, a vehicle produced by the French company Induct [2]. Between July 2013 and February 2014, this vehicle was made available to researchers at Stanford University for assessment purposes, meaning that from 2013 onwards, an operating design could be created for a transportation service with this vehicle. The empirical findings were documented and are the subject of the report that follows. Vehicles such as the Navia are highly indicative of general industry trends in automated system design [3–6]. But it is important to clearly emphasize, that the particular attention paid to the Navia here in no way represents a preference for, or endorsement of, that system over others. The company Induct also had no influence on the descriptions or findings discussed in this report. This means that while the following information is based on experiential knowledge derived from an analysis of the Induct Navia at Stanford University, it is also generally applicable in scientific and transportation-planning terms, as relates to AMOD systems. The information can thus provide a point of reference for the implementation of future systems.

3.1 Technical Design

The AMOD system discussed in this contribution makes use of vehicles equipped with satellite navigation systems, lasers, cameras, ultrasound and steering-angle and wheel-angle sensors. These sensors and systems determine and monitor the vehicle’s position and environment. While satellite navigation already allows for a high precision localization of the vehicle (even on a centimeter level, in cases where additional corrective methods are used), the vehicles considered here in addition utilize a process known as “Simultaneous Localization and Mapping” (SLAM).

For this process, the vehicle is guided by operating personnel within a planned operating area, while the coordinates from the satellite navigation system and the data retrieved from the laser, camera and (if necessary) ultrasound systems are recorded. A digital map of the operating area, which unlike conventional maps is a three-dimensional representation, is created from this data. This representation describes the stationary situation in the operating area. In other words, all variations, as measured against the saved data in subsequent vehicle operation, are classified as movable or “new” obstacles. Such variations warrant special attention and may necessitate a deviation from the pre-programmed route.

SLAM technology here represents a “virtual railway line”, whereby physical tracks are replaced by satellite navigation, which, in connection with environment perception, is used as a reference system. Deviations between the saved representation and the continuously updated environment perception data are classified as obstacles, which may necessitate a change of route or road. Here, the laser sensors serve mainly as a means of detecting objects (e.g. persons, vehicles, buildings, obstacles) at medium-to-long-range distances ranging from approximately 1 up to 200 m from the vehicle. The ultrasound sensors are used for object detection at close range (less than 2 m from the vehicle). In addition, the camera systems provide extra information about the shape and type of detected object (e.g. person or plant), to provide the most detailed possible image based on object type, distance, direction and, in some cases, speed.

Variations from the reference system, i.e. obstacles on the planned route, are acknowledged by the vehicle’s control unit and the actual route can be updated in line with a series of assessment criteria. In other words, an optimal route and pathway is calculated and created in accordance with the specified destination and the given traffic situation and environment. Even if no path seems accessible at a given moment—for example if the vehicle sensors detect that an obstacle cannot be bypassed and there is no alternative route—the vehicle interrupts its journey until the obstacle is removed.

Driving commands are sent from the path-planning unit to the electrified steering, braking, and drive systems and are then executed. The vehicle features electronic interfaces for these components, so that the central control unit can relay steering, braking and drive commands, with the result that the vehicle executes the journey independently, depending on the combination of environmental perception, information processing and destination input (see Fig. 14.1). In doing so, each axle is powered by a brushless 48 V/8 kW electric motor. The vehicle features independent steering on the front and rear axles. The vehicle’s maximum speed is 40 km/h but is limited to 20 km/h for initial operation and can, if necessary, be further reduced via parameterization. The turning diameter is 3.5 m.

Fig. 14.1

Block diagram of an automated vehicle (schematic, simplified)

The vehicle user has several options in terms of influencing vehicle operation. The vehicle can be requested via an input screen at a fixed station whereby for typical operation the command will be sent using a smartphone app. Once the vehicle arrives at the requested pick-up location, it stops at which point the parking brake is activated and the door (in this case an open steel frame structure) is opened so that the passenger or passengers can safely enter the vehicle. The user then enters the desired destination via the installed input screen. The vehicle door closes and the parking brake is released so that the vehicle can start the journey. At all times, passengers have the possibility of stopping the vehicle immediately using an emergency switch. In such instances, the vehicle occupants can also contact operating personnel using a vehicle communication system in order to request help or to communicate other concerns. Because the connection is radio-based, the operating personnel can be situated at a location completely independent of the operating area.

As shown in Fig. 14.2, the vehicle is characterized by its extremely open design. There are no body panels above waist-height (of the passenger) but rather four support pillar for the canopy roof. In addition, there are no seats in the vehicle. Passengers instead lean against upholstered supports. The vehicle has space for up to 8 persons and can carry a maximum weight of 800 kg. It measures 3.5 m × 2.0 m × 2.5 m (length × breadth × height).

Fig. 14.2

Open design of the Induct Navia [2]

The power supply has an estimated operating time of 8 h using a chemical battery, or of 20 min using a supercapacitor. The vehicle can be charged either outside its operating hours by means of a cable connection or during short breaks by means of a wireless charging station. The wireless charging option is particularly advantageous for the driverless operating model since the vehicles are then capable of driving to the charging station themselves without the need for personnel who would otherwise need to plug in a charging cable. In case of the operations at Stanford University, the cable-charging process has been used as an initial solution because of its simplicity for test operation with on-site operating personnel.

3.2 Operation

Despite the largely independent operating characteristics of an AMOD system, there are several special conditions that warrant consideration. Firstly, operating personnel are required to safeguard operation. While it is not necessary for staff to oversee every individual steering, braking or drive command, but they must ensure safety of general operation within the established operating area (with its geographical limits) and specified parameters (e.g. speed or position). To achieve this, operation centers are established similar to those used for driverless trains or for logistics systems. Those centers are staffed with comparatively small numbers of personnel who monitor a large number of vehicles. The operating center is connected via radio to the individual vehicles and is capable of monitoring vehicle operating data, halting the vehicle in an emergency and communicating with passengers.

A communication system must always be installed in these vehicles for operational monitoring purposes. This can involve various communication standards, for example a cellular or WiFi network. It is essential in both cases that the latency and availability for the data transfer are up to the necessary requirements.

It should be mentioned at this point that, due to continued radio monitoring and the ever-present vehicle take-over function, the system is not fully-automated in the strictest sense of the definition according to SAE J3016 [1]. This standard specifies that there be no human monitoring or control-takeover, even in exceptional circumstances. Nevertheless, one must consider, in the case of transportation systems such as the Navia, that no operating personnel is in the immediate vicinity of the vehicle, which means that these vehicles must be able to deal with an emergency situation independently. This, in turn, corresponds to full automation as per SAE J3016, while also demonstrating the limitations of this definition.

Furthermore, a route network and operating times must be established for system operation. This entails defining which routes (detailed bounds) can be traveled in which area (general bounds). A specific area is chosen after first defining which general location will be best served by the transportation system on the basis of user needs, monitoring requirements, driving performance, legislation, economic efficiency and any other relevant considerations. In the case of the AMOD systems discussed here, this area could be limited to a pedestrian zone, a downtown area, or an entire city. In doing so, there must always be a detailed consideration, which roads or lanes the vehicles are permitted to travel on.

For flexible operation of the transportation systems described here, it is necessary to consider that motorized vehicles are not permitted in some areas, for example pedestrian zones, and that in such cases an appropriate permit must be obtained for these special, automated, motorized vehicles. Furthermore, if the vehicles are operating in normal road traffic, it is likely that a special permission for operating an automated vehicle will be necessary in most jurisdictions. In some legislative territories, for example a number of states in the USA, relevant legislation is already being developed and implemented.

In terms of operating times, it is important to consider whether the mobility service should be provided 24 h a day. This would be a logical and advantageous approach thanks to the minimal personnel requirements and it is likely to satisfy customers. Nevertheless, there may be a number of limitations, above all financial, that make limited operating hours a more viable option. One possibility is to park the vehicles in a depot overnight so as to protect them from vandalism. Another would be to offer the mobility service only when buses or other public transportation services are not running (e.g. at night) so that the vehicles are parked in a depot during daytime hours.

In all these cases, the geographical and timeframe limitations applied to vehicle operation are comparatively straightforward and can be implemented by specifying limits with corresponding operating parameters. This means using digital mapping and also a restricted schedule to limit operation in accordance with the operator’s specifications.

In order to ensure that the AMOD system is operated in accordance to the manufacturer’s specifications, there are certain requirements that must be met prior to commissioning, namely system installation, personnel training and personnel certification. This means, more specifically, that the transportation system must first be installed in accordance with the specified operating parameters. This generally requires an initial period of manual operation, which has been described in this report. This allows for the creation of a digital map, which ensures accurate positioning of vehicles during a later stage of automated operation.

In terms of training, operating personnel must receive training regarding the vehicle’s general characteristics and specific operational dynamics, which is to say the system characteristics, operating conditions, limitations and other relevant characteristics. Personnel must learn and understand these aspects of the system. In addition, vehicle operating safety must be checked—in a way similar to airplanes—before every new operating stage, e.g. at the beginning of a new day of service. Out-of-the-ordinary incidents during operation, for example a deviation from the defined route, must be investigated and recorded in the system operating log.

These factors demonstrate that although the vehicles in question are automated, a substantial amount of preparation is necessary before the system can be operated. This preparation cannot be carried out automatically and requires operating personnel. Nevertheless, it should be assumed that for the purposes of overall operation of the transportation system, considerably fewer staff are required in comparison to systems where each vehicle requires a driver.

3.3 Business Model

One of the main reasons for the deployment of AMOD systems is the considerably lower staffing requirements when compared to operating models with conventional vehicles. This has an effect on the business model. The manufacturer of the Navia system claims that the operating costs for public transportation can be reduced by 50 % [7] using its system. The business model for these systems thus allows for a considerably cheaper mobility solution when compared to, a taxi service for example, whereby savings are generated through smaller staff. In comparison, such systems have the advantage over passenger cars in that the user, relieved of vehicle control duties, can spend the journey time working or relaxing.

Beyond that, there is no concrete evidence of additional economic advantages, since on-demand operating models are also possible with conventional human-controlled vehicles. However, automated vehicles can also run at hours that are generally less attractive, for example at night when there is maybe only need for one 10-min journey per hour. In this case, a driver would wait 50 min without revenue generated. In contrast, if an automated vehicle is inactive for 50 min, the waiting period is unimportant as long as overall revenue in this period is sufficient.

Up to now these systems have only been run in pilot operation, for example during restricted hours on university campuses or in shopping centers [3–5]. Because these types of operation were primarily intended to showcase the systems, the business model cannot yet be fully evaluated. It is estimated that commercial operation will commence in 2015, when the first evaluations of the business models and revenue targets of operators and manufacturers will be possible.

4 Lessons Learned from the Implementation of the Transportation System

The following section aims to provide an overview of the results of implementing Induct’s “Navia” AMOD system at Stanford University. Due to the fact that, up until mid-2014, the vehicles in question were only sporadically in operation, the following stands as an interim report that is to be continued elsewhere, at a later date. Nevertheless, it is still possible to communicate the findings of the implementation approach used, with the aim of helping other researchers and transportation planners in the implementation of similar systems.

4.1 Differentiation Between Evaluation, Testing and Public Operation

A range of operating phases was considered for the vehicles in this report, in accordance with the data in Table 14.1. The aim was first to classify the transportation system in an evaluation phase, then to optimize it in a test phase and finally, to provide public operation.

Table 14.1 Differentiation and characteristics of the three operating phases

To begin with, the study is reliant on general experiential data which must be gathered from the vehicles themselves, since such a transportation system is still largely uncharted territory, making a risk assessment difficult. A range of other important questions informs the research. Importantly, the system described here allows for a highly flexible operating model to accommodate the applicable requirements. For the initial evaluation, it is beneficial to have a basic calibration of the vehicle to the desired operating area to allow for monitoring by on-site staff. To simplify this process, the vehicle should not require a special infrastructure, but should operate on a largely independent basis once it has been calibrated.

The test operation phase that follows seeks, in accordance with the objectives of the Autonomous Systems Laboratory [8], to optimize the geographical and timeframe distribution of automated, on-demand vehicles. This phase should be as realistic as possible, whereby system users, despite the test status, should be allowed to behave in a manner that reflects their actual mobility needs. For example their actions should be able to demonstrate a preference for the shortest possible waiting time and journey time from one location to another. This phase of operation must also be designed as highly-flexible yet target-oriented as it pertains to the transportation system discussed here, since the provided routes and schedules are comparatively easy to program, allowing for efficient implementation of requirements.

Test operation should then ultimately lead to public system operation, as long as no further research testing or optimization works are planned. The operational system is thus implemented in accordance with the results of the test operation. The transportation system allows for this step-by-step approach for implementation because the operating area and operating times are very easily set and, since the vehicle speed and overall distance are minimal, operational monitoring should pose if at all only few problems.

4.2 Choosing a Vehicle Concept

In order to fulfill the requirements of the test phase operation, a fully-automated vehicle—that is to say, a driverless vehicle—is necessary. The vehicle must be able to propel itself within specified boundaries, while having on-demand functionality for the user. In addition, open operating system architecture is required for making alterations to the deployment and distribution of vehicles. It is not essential here for the vehicles themselves to have an open architectural design: Neither the operating system for the vehicle control unit nor the environment perception system are part of these research efforts and, as such, they do not need to be altered.

The “Navia” vehicles provided by Induct and their associated operating system architecture fulfill the applicable requirements. In addition, experiential data was already available from other projects that implemented this mobility concept [3, 7], which means test operation was likely to run smoothly. Furthermore, Induct’s trademark rights relate primarily to the field of environment perception and reference system creation for vehicle automation. This means that the research presented here does not conflict with Induct’s work but rather complements it because it focuses on the area of general vehicle operation in order to best fulfill mobility demands. It is for these reasons that the Induct Navia concept was chosen and evaluated for test operation, in accordance with the criteria described in the sections that follow, as part of the research work of the Autonomous Systems Laboratory at Stanford University [8].

4.3 Risk Assessment and Legal Classification

Placing this project into the context of the existing legal system is a step-by-step process. Because the vehicles do not initially run in publicly accessible areas (for evaluation purposes), a number of special rules apply in terms of vehicle operation and operating liability. These rules were formulated at Stanford University in consultation with the department for risk assessment and the university legal department. Legal liability is assigned, for the most part, to the operator of the vehicles in question which, depending on the operating mode, is the operating personnel in, directly outside or remotely connected (via radio) to the vehicle. The operation of the vehicles at the university has been approved but with certain restrictions applied by the internal (i.e. Stanford University) staff for risk assessment.

The risk assessment for the vehicle operation detailed here is considerably easier to plan than for equivalent operation in public traffic, primarily because the vehicle speed and the operating area are greatly limited. That means that, in contrast to conventional passenger vehicles, which are considerably faster and can, in theory, travel anywhere, a speed limit of 20 km/h and a significantly confined area represent a comparatively small operating risk. To begin with, system operation in this area was only permitted without public access and under the direct supervision of operating personnel, directly outside, or directly inside, the vehicle. These restrictions placed on the first stages of operation mean that all project partners gain an understanding of the capabilities, limitations and any other characteristics associated with the system. This allows for a step-by-step risk analysis and legal classification process as the test phase operation itself is gradually widened in scope. This also means that the risk assessment and legal classification process cannot be accurately determined in advance and they are instead based on the practical data of vehicle behavior as it arises.

With the gradual expansion of the operating model in test and then public operation (see Table 14.1), public legislation comes increasingly to the fore as the dominant regulating feature, as long as vehicles are operating on public streets. For this research, respective regulation in California, USA was applicable. This regulation was still in the final legislative phase during the first half of 2014. It is important to note here that, as of September 2014, only vehicle manufacturers were permitted to perform tests with “autonomous” (automated or fully-automated) vehicles [9]. Because the definition of “vehicle manufacturer” includes a person who modifies a vehicle so it become an “autonomous” vehicle, it remains to be seen, which roads the vehicles at Stanford will travel on and who the “manufacturer” is in the sense of the California law. It is assumed, under this law, that the vehicle manufacturer corresponds to the actual producer from whom Stanford University procured the vehicles and not the university’s researchers, as long as said vehicles are not modified by Stanford University in a way that facilitates their automation but, rather, their data are assessed and optimized as pertains to position, temporal behavior and user requirements.

Admittedly the legal situation is currently difficult to predict since it is still in transition. It is likely, however, that changes will be made on a number of legislative levels (state, municipal and national) and that measures will have to be taken to comply. But in the context of the operating area dealt with here, which is to say an innovative university in California, the fundamental attitude of the responsible authorities and the public toward automated vehicles seems to be a very positive one. The relevant legal bodies also seem to be taking a supportive and favorable attitude. There is also a sense of confidence that, in individual cases, special regulation can be agreed to allow for system operation that may not be explicitly provided for by law. This type of attitude has also been observed in other parts of the USA. As such, US legislation does not seem to represent a key barrier to the introduction of automated vehicles but is more likely to act as an additional reviewing body.

4.4 Contractual Structure

For the purposes of an AMOD, a contract is required that outlines the fundamental legal relationship between the owner of the vehicle (for the test operation described here: the manufacturer) and the user (here: Stanford University as the research facility). This entails rights and obligations pertaining to general use, information and communication, maintenance, liability and other provisions for test operation.

In the example dealt with here, a loan agreement for one automated vehicle was agreed between the manufacturer-owner and the user of the vehicle that, at the outset, was only applicable for the purposes of the evaluation phase that would potentially lead to a research project. As soon as a definite project with an AMOD system is pursued, a new or possibly supplementary contract would be necessary which would then govern all circumstances for effective use. Such a contract could also potentially include the possibility of altering environment perception and route planning technology for research purposes, which are not included in the evaluation phase.

In the contract between the manufacturer-owner and the user of the vehicles deployed in this evaluation phase, liability is assigned to the operator. As such, the operator is the legal entity that initiates and monitors vehicle operation, whereby this could be either the operating personnel inside or directly outside the vehicle, or the operating personnel remotely connected via radio.

4.5 Selection of the Operating Area and Operating Scenarios

To begin with, the operating area for the AMOD system must be geographically limited. For the initial evaluation and subsequent test operation phases, the size of the operating area is not as a much a point of focus as the range of users, use cases and operating situations. These factors can be proactively represented for evaluation and test purposes in trial form—in other words, the project parties envision and design a range of suitable situations in which vehicle behavior can be observed and assessed. As such, a small operating area is sufficient for assessing a wide range of situations and operating conditions.

Because the concept of an AMOD system is a new one and, accordingly, a risk assessment of the system on the basis of experiential data is somewhat limited, an operating area must initially be found that ensures realistic operation but also complete control. This means that users must be in a position to request vehicles within the operating area, specify a destination and then give vehicle commands—all without the direct involvement of operating personnel. At the same time, the operating personnel must be able to monitor the vehicles. They should also have control of, or at least knowledge of, the persons and vehicles located in the operating area that could potentially interfere with the vehicles during this initial test operation.

An overview of the number of persons in the operating area is important to allow the operating personnel to recognize and prevent collisions and other disturbances. For example, at the beginning of the test phase there should be no person within the vehicle’s operating area who is not familiar with the transportation system or who would behave in a way that deviates from any stipulated regulations (e.g. stepping in front of a vehicle). It must be ensured that all persons involved are familiar with the characteristics and risks of the transportation system but that these persons also behave in the way a real user would, in that they request vehicles and set destinations realistically. One possibility here is to have persons who interact with the vehicle sign a release form, which states that they are acquainted with the system’s characteristics and limitations and they will adapt their behavior accordingly.

The operating area is thus heavily limited initially and may, for the reasons described previously, need to be fenced in and made accessible only with special permission. Moving forward, operation should then be expanded to an area that is monitored but also public so that a large number of real users are targeted. This involves bringing in users who have no prior understanding of the system and who do not sign a special release form—instead they should seek to use the vehicles as they would a taxi or bus. For this purpose, it is important that the operating area features users with mobility needs that can be solved by the vehicles in question, as relates to distance, speed and transport capacity.

A university such as Stanford is capable of implementing such a system and fulfilling the envisioned requirements. The university campus has grounds large enough to accommodate the Navia. Demand for passenger and goods transportation is high. Also, traffic issues are dealt with as effectively as possible by the responsible university department (Parking and Transportation Services). This allows for a suitable area for the introductory evaluation phase to which only test participants have access. In the following phase, pedestrian zones and streets can be incorporated. In all cases, the necessary communication systems for personnel monitoring must be in place, with personnel access to the vehicles where necessary.

After it became know that Navia vehicles were being used at Stanford University, a string of university departments registered their interest in using the transportation system. One query came from the operator of the local bus service, which was looking for a flexible expansion of its services at certain points. Another interested party was the university’s utilities and repairs departments, which was looking for a flexible and unmanned system to transport items around the campus. An additional research facility also voiced its interest in establishing a passenger transportation system on its research campus.

Taking into account the enquiries that were received and the system’s capabilities, operation began on an access-controlled parking lot, with a range of operating scenarios simulated. A subsequent more realistic trial is planned to take place on the grounds of the separate research facility, where both a large number of real users are expected and full monitoring of operations can be ensured.

To begin the evaluation phase, a set of special scenarios must be created that allow for risk assessment and related safety tests. Here, vehicles can be confronted with obstacles and other objects. These should be genuine, safety-relevant scenarios in which vehicles behave in the desired manner, without faults that could lead to critical operating conditions. The objects that stand in the vehicles’ way are pedestrians, cyclists, vehicles of all kinds, animals and everyday objects that can be found in a normal operating area, such as trash bins, packages, cartons, working materials, plants, buildings, etc.

Here, a distinction must be made between stationary and movable objects, since the former can be clearly defined in the digital map of the environment, which allows for the course of the vehicles to be determined accordingly. Movable objects—in this case objects that are seldom moved and only as a result of outside interference (e.g. a debris container)—must be fully captured by the environmental sensors in order to avoid a collision. Depending on the type of object, operating scenarios should be drawn up along with a corresponding mode of behavior for the purposes of risk assessments and safety tests: Persons and vehicles should be able to move in front of the vehicle suddenly—trash bins and packages should of course, be somewhat slower. When these objects emerge, vehicle behavior should be designed in such way that it is prompt and reliable enough—on the basis of its detection processes—to avoid a collision.

4.6 Setting up the Transportation System and Certification of Personnel

The vehicle manufacturer specifies how the transportation system and its automated vehicles should be implemented. The first step is to establish the route. This route is then traveled by one of the vehicles in a special operating mode, which allows for a digital map of the operating area to be created. The operating data is then edited so that stationary and moving obstacles can be categorized. Finally, the manufacturer creates a document detailing the mode of use and the operating area. This should detail parameters and zonal limits, thereby specifying what is permissible within a certain type of operation, taking into account potential legal liability issues. These guidelines are then documented in a certificate produced by the manufacturer.

For the purposes of issuing operating personnel with certification, the manufacturer provides training pertaining to operating requirements, functional characteristics, operating modes, technical details, limitations, risks, etc. Personnel should acquire an understanding of the system based on practical interaction and this understanding should be tested. The manufacturer documents this certification process, thereby certifying those persons who have successfully completed their training with a detailed knowledge of the system. There are also three task levels: “supervisor”, “operator” and “technician” which designate whether operating staff are to only monitor, generally operate, or carry out maintenance on or modifications to the system.

The vehicle manufacturer must first define these processes and task scopes, since the manufacturer is the party with the best knowledge of the system and the risks associated with the vehicles. So as to be able to incorporate potential peculiarities of the operating environment into the organization, the operator of the system (which is to say, not the manufacturer but the responsible monitoring person, either on-site or connected via radio) should make changes or upgrades in terms of system testing, maintenance and certification, since it is here that unique situations become most evident. As time progresses, similar AMOD systems will be the subject of further upgrades and greater expansion, providing legislators with more experiential data. This means that, ultimately, the relevant processes and scopes for the certification of vehicles and personnel will likely be created either by legislative authorities or from commissioned institutions.

4.7 System Start-up and Operational Monitoring

For live vehicle operation, the manufacturer specifies a system start-up and a corresponding system inspection. This involves a check of the vehicle and environmental parameters before approval can be granted for live operation. This process represents a good compromise between detailed precision and manageability, so that before the initiation of each operating period there is total certainty that both the transportation system and the operational environment meet safety and functional requirements in accordance with the standards for certified operation.

For vehicle operation with radio monitoring (which involves no operating personnel in the vicinity of the vehicle) the manufacturer provides a communication system. This involves the implementation of two independent, wireless communication systems, for example a cellular and WiFi link or two independent cellular networks. The operating personnel can use this systems to access vehicle data and, if necessary, execute an emergency stop or communicate with the passengers in the vehicle. The exact scope of monitoring, e.g. vehicle position, speed, direction of travel, passenger numbers and door locking, in addition to full video surveillance of the environment, will be established on an individual basis and is currently (as of June 2014) not specified.

Up to now, the vehicles at Stanford University have only been run with operating personnel in or in the direct vicinity of the vehicle with direct access to an emergency stop switch. For this reason there is currently no further experiential data available on operation with a radio monitoring connection. Nevertheless, it has been established, from this limited experience, that it is more likely that collisions can be traced back to other road users (pedestrians, cyclists, other vehicles) than to the automated vehicle itself. The combination of environment perception, object classification and route planning is adequate—particularly given the minimal vehicle speed and the familiar and limited operation area—to allow the vehicle to be operated safely and without disruptions.

For future operation with radio monitoring there will need to be an assessment of the response time necessary for operating personnel to arrive at the location of the disruption. For example, road construction or illegally parked vehicles could block the route. In such situations, vehicles would automatically interrupt their journey and inform the operating station of the disturbance. Then, depending on the working location of local operating personnel, a time period will elapse that could amount to minutes or considerably longer, before personnel are on location to solve the fault. The frame of reference here is elevator support, whereby activating an emergency button also initiates immediate contact to an operations center although it can take substantial time until staff reaches the site. It is then a task within public operation to ascertain how passengers in AMOD systems deal with such a scenario and whether the waiting time represents a problem for them. It should be noted that, in contrast to an elevator system, the passengers of this transportation system have direct contact to the outside environment at all times, thanks to the open structure of the system (see Fig. 14.2) and they can, in an emergency, leave the vehicle relatively easily.

4.8 Information for Users and Pedestrians

Due to the fact that this AMOD system constitutes a new innovation in the field of personal mobility, users must be informed of the risks and possibilities associated with it. To begin with, the particulars of normal operation need to be made clear: This means, the actual control process itself should be explained. This requires a minimum of detail since this transportation system will allow for usage similar to a taxi or bus service—and those services are already completely familiar to future users. Instead, the risks and special attributes of test operation should be the subject of focus. This includes an explanation of the system’s limitations and dangers, for example the risk that it does not recognize an obstacle fast enough or, in some case, vehicle behavior that may be out of the ordinary.

The users for the evaluation and test operation phases are provided with written information on vehicle characteristics and associated risks. This includes information explaining whom users should turn to as the person legally liable in the event of damage. Similarly, once in public operation, users should have the option of giving feedback and forwarding queries to the operator of the system. And because this is a new transportation system, user evaluations are of great importance. Therefore it is important that users know who they can contact to voice their opinions.

Just as with the users of the automated system, it is important that pedestrians and other road users are provided with information on the operation of the vehicles. Thereby, it is not absolutely essential to provide them with knowledge on vehicle usage itself. However, given the level of interaction between vehicles and other road users, the latter must be informed about the associated eventualities and risks. This particularly includes right-of-way regulations and other special provisions. Pedestrians and other road users should know how they could in case of an emergency stop a vehicle from outside using the emergency stop function. Pedestrians should also be aware of the identity of the official system operator, who they can turn to and provide feedback or make queries.

4.9 Public Response

Even if, up to now, the AMOD system has only been witnessed in public operation on a confined scale at Stanford University (and this was only the case when the vehicle was transferred, controlled by operating personnel, from one operating area to another), one can still make several assertions about the reaction of the public. These observations are derived from the aforementioned transfers and from visits during the evaluation phase. Observations could also be made at the vehicle’s depot location. It is important to emphasize here that the following descriptions do not constitute a methodical study, but rather incidental observations that aim to provide an impetus for future study. As a general rule, the public—which is to say, those persons who were exposed to but not involved in the project—reacted very positively to the vehicle. There are two probable reasons for this:

Firstly, non-participating pedestrians and observers generally seemed to be very interested and curious in relation to automated vehicles as a concept. This may be because such technologies are currently a major theme in both general media and popular science as well as in scientific publications. It is above all the general media that frequently reports, in positive, sometimes even euphoric terms, about “autonomous” vehicles in which drivers hand over total control to a computer so that they are free to perform other tasks during their journey. When people encounter this type of vehicle for the first time after being exposed to such media coverage, curiosity, receptiveness and a level of trust are likely responses.

Secondly, the characteristics of the vehicle in question haven been seen to bring about spontaneous and positive reactions from pedestrians and observers. The open structure (see Fig. 14.2) is one of the influencing factors: The vehicle has open, only low-rise side panels and an open railing system instead of a closed door. Thanks to this structure, the vehicle’s passengers are clearly visible to passers-by and this open visibility makes a positive impression. More specifically, this means that the visual impression left by the vehicle is very different to that of a vehicle e.g. with tinted windows and closed doors, in which case passers-by have no idea who is in the vehicle. This would be comparable to the differing impressions one would have, in normal public traffic, from a limousine with tinted windows on the one hand, or an open convertible on the other. In addition, the vehicle described here features a design concept taken from the boating industry, whereby epoxy is used for the body, the passenger seats are covered in beige leather, the floor is bright teak and the roof is sail-like in shape. Comments from the public ranged from “land yacht” to “a whirlpool on wheels”—all positive associations that form an initial impression of the technology.

In addition, the vehicle is comparatively slow and operates at a speed that is barely above walking pace. This gives passers-by the impression of safety. Pedestrians feel that they can quickly move to the side if need be. Drivers of automobiles at the same time likely feel “superior” to the vehicle, which may also be due to the fact that the visible structure is largely plastic. As a result of these characteristics—which is to say the open and positive appearance, in addition to the slow speed—observers seem to attribute an almost personal character to the vehicle, similar to the characters in motion pictures such as “Short Circuit”, “The Matrix” or “Star Wars”. These movies show that robots are assigned different characters depending on their appearance, performance and aggressiveness. These characteristics and mechanisms should be carefully considered when an automated vehicle is put into public operation. It seems that the “character” of a vehicle is an important factor in provoking a positive public reaction towards vehicle automation. That is to say that an automated vehicle, using a certain mechanism, can be seen either as a “subordinate servant” or a “ruthless mercenary” (see also the article by Kröger in this volume Chap. 3).

These interactions with pedestrians and observers have produced a host of questions about the AMOD system. The most common question is when and where these vehicles will be useful in the public realm. Other pertinent questions relate to the technical specifications of the vehicles. Among these issues is the question of if and how vehicles will react to objects, very specifically pedestrians, pets, and stationary objects. Questions relating to monitoring and legal liability for vehicles have also been raised. These questions illustrate the general level of public interest in the vehicles and that the public has put much thought into the issues surrounding the operation and limitations of automated vehicles. This also underlines the importance of public awareness and information both before and during system operation.

5 Summary and Outlook

This article describes the first steps in implementing an automated mobility-on-demand, or AMOD, system. This transportation system comprises vehicles that can be summoned via smartphone app. They serve the purpose of transporting persons within a specified area, for example a downtown city area, without either the possibility of directly intervening in the vehicle’s operation and with no rails or tracks. This mobility concept is operated at Stanford University for the purposes of a scientific study in the field of innovative mobility solutions using automated transportation systems, with a view to examining the initial suitability of the vehicles for this purpose.

The first stages of the project involved risk assessment and legal classification processes. The system operating area and a range of operating scenarios were then established. The results showed that the system can be built on the basis of existing regulations and provisions but that, because of its automated nature, the system entails a number of requirements that clearly also exceed existing parameters. As such, it is expedient for the vehicles to drive slowly (a 20 km/h limit) and within a limited operating area.

In addition, operating personnel should be either in the vehicle, directly outside the vehicle, or remotely connected to the vehicle via radio, so as to facilitate a smooth first implementation of the system. In the context of the necessary internal coordination requirements and the necessary regulations, it has proved extremely important to demonstrate the system in real operation to the concerned parties and decision makers, so as to be able to realistically evaluate the level of operating risk and vehicle capabilities and limitations. The open and appealing appearance of the vehicles, combined with a great level of public interest and curiosity, mean that they provoke a positive response among the public. Consumers also expect that automated vehicles, at some point in the near future, will relieve them of the often burdensome task of driving in the city.

There are, however, a number of uncertainties surrounding the implementation of automated vehicles. These include associated infrastructural, economic and business-strategic variables but also an applicable legal framework. In the example detailed here, the implementation of the transportation system at Stanford University (which represents a legislative area within the US State of California), or more specifically, on the university’s own grounds, has proven advantageous, as the university itself can directly stipulate regulations. California legislation is currently being processed for the operation of automated vehicles, which would then provide legislative boundaries for system operation in thoroughfares on the periphery of the campus. One will soon see how legislation for automated vehicles is to be handled and the system’s operation and design will need to be structured accordingly.

In conclusion, the current outlook is very much positive on the basis of these initial system trials and the positive public stance on the implementation of automated vehicles, which is being promoted and encouraged. It is important to note, however, that these initial impressions do not constitute a representative study—further efforts are required for implementing and promoting acceptance of automated vehicles. But in summary, there is hope that automated mobility-on-demand systems will make an important contribution to the improvement of urban mobility for individuals.