Keywords

1 Introduction

There are several technologies applied for automated vehicles. Within the scope of automated driving, different scenarios and trends are currently considered within this technological framework (Wang et al., 2020; Zhang et al., 2018). Areas such as the localization and positioning of vehicles in certain traffic environments are associated with GPS, GNSS and RTK,Footnote 1 fusion of sensor technologies, and transmission of data required to ensure the implementation of automated driving (Englund et al., 2018).With the transmission of measurement data from sensors, estimates of the vehicle’s relative position can be calculated. Although this approach has a certain error sensitivity, the precision of the localization can be incrementally improved by integrating additional sensor types (Toledo et al., 2018). For increasing the localization accuracy from the meter range in lower centimetre ranges (Englund et al., 2018), several approaches are available. Above all, the use of artificial intelligence and Internet of Things (Iot) holds a high significance, with which ideally complex systems are to be dynamically controlled in public transport (Kappel et al., 2019; Kuo et al., 2023). There is likewise the potential to improve the ability of an automated vehicle to perceive objects in its environment (Gupta et al., 2021; Netter, 2017).

Despite the application of different technologies, there are still technical limitations impacting the trajectory and the operation of automated vehicles (Benmimoun, 2017; Muzahid et al., 2023; Tengilimoglu et al., 2023). Obstacles can among others be identified in automated shuttle capabilities, environment, and human involvement. Achieving level 4 autonomy to eliminate the need for an on-board driver carries, e.g. significant implications for AV service costs and is closely connected to regulatory requirements regarding safety demonstrations of AV operation.

The research question guiding this study is as follows: What technical obstacles impact the implementation of automated minibuses for public transport, and what ongoing advancements aim to address these challenges in the field of automated driving? In order to examine the technical obstacles and their relevance within the AVENUE project, several experts from the respective consortium were interviewed. Furthermore, the technical developments in the project were investigated. Based on the project progress, several evaluation criteria were identified to frame this study.

2 Assessment Taxonomy

The taxonomy for the technical assessment comprises three major areas of consideration. The first one is “automated shuttle capabilities”, which underlines the technical capabilities of the applied automated vehicle. The second area is “automated shuttle environment”. This aspect includes diverse criteria concerning the external limits that influence the operation and trajectory of the vehicle. The superordinated criteria “human involvement” refers to the need of an on-board supervisor. Besides these three groups of criteria, additional technical findings were identified, which are addressed in Subchapter 4.2. “Remaining Technical Obstacles”. The applied assessment taxonomy based on (Bürkle, 2019) is shown in Table 11.1.

Table 11.1 Taxonomy for assessing automated minibuses

3 Methodology

3.1 Assessment of Technical Obstacles

The initial situation is based on previously examined technical obstacles to the implementation and use of automated shuttles from various pilot projects (Bürkle, 2019). For re-evaluation purposes, a summary of the technical obstacles that refer to the first examination and reporting was distributed to selected experts from the public transport operators within the AVENUE consortium. The aim was to receive feedback on the current technical obstacles. Existing changes and newly identified obstacles are listed and described in a summary. With the provided summary, the experts were asked to assess the relevance of the described technical obstacles for the implementation of AVENUE. The applied rating scale is equal to the previous report conducted to identify and describe potential changes coherently. By asking the experts to rate the relevance of the technical barriers in addition to their description, two steps of the method were covered. The experts were asked to rate the technical obstacles (existing and new ones) from 1 (not relevant) to 5 (very relevant). The average ratings were calculated based on the experts’ contributions. The assessment results formed the basis for further expert interviews (Table 11.2).

Table 11.2 Rating scale for the evaluation of technical obstacles

3.2 Expert Interviews

As mentioned in the previous section, the results from the first step of the method formed the basis for expert interviews. The subsequent phase encompasses interviews conducted with diverse experts from the AVENUE consortium, in which more specific attention is devoted to the obstacles and technical advancements achieved through the AVENUE project. With the gathered results, the questions for the expert interviews were prepared accordingly. Additionally, as the subject of technical obstacles and advancements constitutes a considerable complexity, the semi-structured interview approach was applied (Galletta, 2012). This approach was chosen in order to have a reliable basis to address this complexity and to benefit from the experts’ knowledge for the interpretation of the results (Galletta, 2012). The expert interviews were conducted in two separate parts. The first part relates to obtaining new information on technical obstacles as well as on the technical developments within AVENUE. Regarding the implementation of an on-demand service, the second part includes the challenges and obstacles that occur with the deployment of the application programming interface. Based on this separation, the public transport operators (PTOs) were considered in the first part of the interviews. In the second part, representatives of the vehicle manufacturer and provider of the fleet orchestration platform were interviewed. For preparation reasons, a guideline including questions and consent was provided to each expert. Two guidelines with different questions were created due to the separation of the interviews.

3.3 Expert Selection

For the first part of the interviews, public transport operators were taken into consideration as they had in-depth knowledge of the progress of the AVENUE project. This aspect justified the selection of the experts in the sense that they were also interviewed in the first examination or later started participating in AVENUE. Hence, they can show technical advancements as well as existing and potential new obstacles for the deployment of automated minibuses in public transport. The experts were from Keolis Lyon, Transport Public Genevois (TPG), Sales-Lentz, and Autonomous Mobility (AM) respectively Holo and Bestmile.

3.4 Data Analysis

The consolidation and analysis of the data were based on expert evaluations and interviews (Part One) and expert interviews regarding API-specific barriers (Part Two).

Analysis of Part One: Obstacles Related to Vehicle Operation

As mentioned in, providing a summary of the technical barriers from the last examination provided a basis for obtaining an update on technical obstacles. With the PTO’s evaluation of already known and new technical obstacles, a profile emerged regarding their relevance. Through subsequent expert interviews, this topic was dealt with in more detail. The results of the expert interviews included technical obstacles and technical advances achieved at each demonstration site.

Analysis of Part Two: Obstacles Related to API

With regard to API-specific obstacles, the results from the associated expert interviews in part two are outlined. The elaborations of the experts were linked in such a manner that the current obstacles to enabling an overall on-demand driving system are concisely described. Overall, the analysis comprised two parts, each addressing the results of the expert interviews. For better understanding, the methodology is presented in Fig. 11.1.

Fig. 11.1
A chart presents a methodological procedure in 2 parts. Part 1 has inputs and outputs for actualization, followed by assessment and expert interviews for technological developments and obstacles. Part 2 includes expert interviews, followed by the results for A P I-specific obstacles.

Methodological procedure

4 Technical Assessment of Automated Vehicles in AVENUE

The first subchapter (4.1) describes the initial capabilities of automated vehicles in AVENUE, which were derived from an earlier project phase. In order to present the latest findings of the examination, the remaining technical obstacles (4.2) and the remaining specific obstacles and developments related to the API (4.3) are then described.

4.1 Initial Capabilities of Automated Vehicles in AVENUE

The initial capabilities of the applied automated vehicles are based on a previous examination from an earlier project phase (Bürkle, 2019). Several technical circumstances influenced the operation of automated minibuses during the initial stages of the AVENUE project. In particular, manoeuvres involving left turns and driving in difficult and blind intersections could only be performed using predefined stops implemented in virtual maps of the minibuses. Furthermore, an investigation of technical obstacles revealed that the vehicles had no capability to overtake low-velocity or static objects. Referring to the perception abilities of the automated vehicles, it was identified that the distinction between diverse participants on the road constituted a great limitation and challenge to overcome, as the minibuses were not able to differentiate between multiple road participants. Evident from the earlier investigation was that the automated vehicle did not possess the ability to drive under certain weather conditions. In the case of wind, rain, or snowfall, vehicles stopped driving. This problem was justified by the fact that the LiDAR sensors—at the time of investigation—were not equipped with filtering systems enabling the differentiation between real objects and condensation. Although GPS and GNSS signals were transmitted via audio waves without latency, it was identified that the determination of the vehicle position was considerably inaccurate as deviations of 2–3 m meters occurred. The inaccuracy of the position determination is justified by the existence of different layers in the atmosphere. In addition, the number of available satellites was stated as a crucial factor in the localization process. The first report showed that the transmission and reception of GPS correction data poses a significant obstacle. Occasionally, virtual reference points had to be used in order to improve the localization of the automated minibus. The driving strategy of the vehicle was also strongly dependent on how the sensors were interplayed, and the disseminated data were processed. Despite enhancements in the braking, acceleration, and driving performance of the vehicle, harsh braking still occurred under certain circumstances. Another decisive issue was human involvement in vehicle operation. In an earlier project phase, the vehicles could not perform all driving tasks. Thus, their operations had to be completed by an attendant on board. In particular, the observance of blind spots was conducted by an on-board attendant, as there were still technical limitations regarding the sensors. Because the vehicle could not independently monitor dead angles, the intervention of the operator onboard was necessary for safety reasons.

4.2 Remaining Technical Obstacles

In Fig. 11.2, the remaining technical obstacles and their evaluated relevance are consolidated.

Fig. 11.2
A 7 by 4 table presents the evaluated relevancy of technical obstacles with criteria, Keolis, T P G, S L A, A M, phi, and how relevant as the column headers. Factors are grouped into automated shuttle capabilities and environment, human involvement, and additional technical findings criteria.

Evaluation of technical obstacles

The assessment showed that the implementation of automated minibuses in public transport is dependent on numerous technical obstacles and success factors that need to be addressed and overcome. The deployment of automated driving in various settings, both urban and rural, requires that the technology is capable of handling all safety-related scenarios and that it is effective, intelligent, connected, and fully integrated into the digital traffic infrastructure.

In terms of automated shuttle capabilities and environment, LiDAR and camera technologies in particular have been classified as key drivers for the implementation of automated vehicles. The importance of these technologies lies mainly in the fact that they detect and avoid obstacles and are ultimately decisive for the trajectory of the vehicle. The use of machine learning algorithms and AI technologies will also play an important role in enabling vehicle positioning in diverse traffic patterns and infrastructures. The perception and determination capabilities of automated vehicles will also be considered here as object differentiation in traffic becomes increasingly important, according to experts. The combination of the various technologies and a high processing performance in terms of sensor data is the determining factor in this context in order to achieve safety-relevant functions (e.g. braking) and thus make the vehicle more reliable and safer in its driving behaviour. All sensors should be functional under all conditions. Currently, heavy rain and snow cause disturbances to the sensors and lead to many impairments of the operation. GNNS and the ability to locate the vehicle with precise measurements also need continuous improvement. However, through the use of an Ntrip real-time kinematic (RTK) service, with which differential GNSS data is disseminated via the Internet, the localization and the positioning of the vehicle could be enhanced and therefore supported the smooth operation of the vehicle. The urban infrastructure is another key factor for the implementation of automated minibuses and should be considered in local land use planning. Moreover, cybersecurity measures are imperative to safeguard automated vehicles against potential threats, necessitating the evolution of laws and standards to address emerging challenges that come with increased processing power and complex sensory signal streams.

Additionally, human involvement remains crucial in the operation of automated minibuses, as safety operator had to intervene in various situations, including blind spots or when overtaking parked vehicles. However, a safety operator is generally required, due to legal considerations. For the future the transition from an on-board safety driver to remotely working supervisors has to be developed and tested accordingly.

4.3 Remaining Specific Obstacle-Related API

The Manufacturer’s API

Based on the elaboration of the experts, the so-called Navya API is an interface that enables the communication between Navya vehicles and external systems. This API makes the link between the Navya drive software and the items that are necessary to share with the fleet management system. With this linkage, the fleet management system is able to monitor and command shuttles and missions. Regarding the on-demand features, the expert stated that Navya proposes a specific mode that allows an external partner to send punctual on-demand missions to the vehicles. Those missions are executed among other missions that are automatically created by manufacturer’s system itself. Nevertheless, there is now a new mode (called partner mode) available within the latest software version. According to the experts, this new mode enables the fleet management system to not consider predefined missions but only those sent by the operator. Hence there are two options with which a partner can send missions to the automated minibus:

  1. 1.

    The certain partner can be the only mission provider and have control over the fleet.

  2. 2.

    The partner can be a provider of punctual missions that complete a predefined service with on-demand missions.

These missions are then stacked in a queue. The operator can modify this queue (e.g. by removing them). Nevertheless, it was stated that the overriding of an on-going mission is not possible once a mission is assigned to a vehicle. Within the AVENUE project, the assignment of missions through the Navya API is possible. A conducted update of API to the vehicles in 2021 was released, enabling some basic on-demand functionalities. However, the maturity of the technologies is still a considerable aspect to stabilize and make on-demand a fully functional product for all PTO’s applying Navya vehicles. Since now, multiple operators (such as AM and TPG) within AVENUE have been trying to use the automatic assigning missions features and received important learnings to prepare and organize for this future way of orchestrating vehicle start and end destinations.

On-Demand Challenges

With the reference to on-demand services, several challenges are existing for its full deployment. Hereby it was outlined that overwriting of ongoing missions is not possible. This limitation encompasses the cancelling of ongoing missions and dynamic mission changes which are currently not implementable. According to the experts, this aspect is the key limitation for enabling shared rides as it has significant operational impact and is the most critical feature for the purpose of on-demand mobility services. Especially when a mission is already executed, no other mission can be inserted to modify the vehicle’s plan regarding its current route. Besides these aspects, there are additional challenges restricting the implementation of on-demand transportation services. Currently it is not possible for the fleet management platform to control the routing of the vehicle. Additionally, it is conductible to detect that the person entering the vehicle actually booked his or her place. The start of the missions is also currently restricted as the vehicle cannot automatically recognize when a passenger enters. Consequently, the automated minibus was not able to detect when it has to close the doors and start the underlying mission. Furthermore, recognizing that the right persons exit the vehicle—before starting a new mission (or going back to its garage)—is also a functionality that is currently not enabled. However, it was stated that there will be a new software set-up enabling to override an ongoing mission. Regarding this set-up, it is being worked on providing more accurate information of a mission, as a prerequisite to override an ongoing mission.

5 Technical Improvements Through AVENUE

Proven by this study, technical advances have been made in the use of automated minibuses within the scope of the AVENUE project. These advances are concisely summarized in Table 11.3.

Table 11.3 Technical improvements through AVENUE

The AVENUE project demonstrates notable advancements in the capabilities of automated minibuses, enhancing their functionality and reliability within the public transport domain. Among these advancements is the integration of on-demand features, facilitating a more flexible assignment of missions within the project framework. This development allowed for greater adaptability to changing passenger demand and traffic conditions, ultimately improving the efficiency of the minibus service. Moreover, significant progress has been made in object recognition technology, enabling minibuses to detect overtaking vehicles on the road with greater accuracy and precision. This enhancement enhances passenger safety and contributes to a smoother and more efficient flow of traffic. In addition to improved object recognition, software enhancements have enabled the differentiation of objects based on their speed vectors. This capability enhances the minibuses’ ability to navigate complex traffic scenarios by providing more nuanced and context-sensitive responses to their surroundings. Another noteworthy development in the AVENUE project is the establishment of bidirectional communication between minibuses and traffic light sections. This communication enables real-time coordination between minibuses and traffic signals, optimizing traffic flow and reducing congestion on roadways. Furthermore, advancements in system stability have been achieved, resulting in higher operational stability and a reduced system downtime rate. These improvements enhance the overall reliability of the minibus service, ensuring a more consistent transportation experience for passengers.

6 Conclusion and Outlook

The Vienna Convention on Road Traffic composed by the United Nations in 1968 is an international treaty aimed at increasing safety in international road traffic, primarily through uniform regulations (United Nations, 1968). As of 2021, this road transport convention has so far been ratified by 84 countries (United Nations, 2021). Since 2014, it is permitted to use automated and assistance systems (UN Economic and Social Council, 2014). This change was enacted in 2016 (United Nations, 2015). Even if it is allowed to use such automated systems, which influence the driving of vehicles, it must still be able to be switched off and controlled by the driver (UN Economic and Social Council, 2014). In terms of this convention and the related need for monitoring and possible control of these systems by the driver, the application of automated vehicles is still limited to a level 3 autonomy. This underlying research has indicated that, above all, the demonstration of safe driving in road traffic is a success-critical factor for automated driving. All experts rated this aspect as significant for convincing the authorities on the safety of automated vehicles in public transport and thus fully validating their deployment. The safety of automated driving nevertheless depends strongly on the maturity of the technologies applied to enable overall reliable navigation of the vehicle. Accordingly, it was also pointed out that public transport operators act as customers throughout the ecosystem, specifying requirements for their use cases to the automated minibuses manufacturers. Due to the limitations of the technologies used, their optimized use by the automated driving software was thus recommended. With an increasing reinforcement of the software-hardware interaction, cybersecurity issues may be of higher importance, even if no hacking incidents are known within the AVENUE project yet. It was demonstrated that there have been technical developments that have advanced AVENUE. Nevertheless, technical obstacles to the use of the automated minibuses remain: in certain situations the intervention of the safety operator is still required. Demonstrating the safety of the vehicles is highly important not only from a regulatory perspective but also potentially for public perception, which may influence the acceptance of automated minibuses. For the course of possible further similar projects, it thus remains to continuously review what technical developments are made and what obstacles exist to the full implementation of automated minibuses in public transport.

The study showed that the demonstration of safe vehicle operation is important in terms of local authority regulations. The principle of safe automated driving is closely related to the extent to which a safety driver must intervene. Due to technical limitations (e.g. sensors), there are still interruptions in operation that require the vehicle to be controlled manually. Another recommendation in relation to this challenge is the integration of further sensors, although this task would depend on the manufacturer. Despite positive developments in the localization and navigation of the automated minibuses with the Ntrip RTK correction data service, operational interruptions and system failures still occur. It is important to document and analyse these cases in detail. This may facilitate the identification of potential sources of error and the development of solutions. However, there is a risk that some solutions may be limited to the technical capabilities of the hardware. Another important aspect, which was also outlined by the experts, is the access to the automated minibuses for elderly people or people with a restricted mobility. Associated with the vehicle, it is a significant task for the PTOs and also for the manufacturer to ensure that these people are capable of accessing the transportation service without any inconveniences.

There are additional limitations to the full implementation of an on-demand transport service, mainly related to the API and fleet orchestration platform. It is important to focus on the extension of on-demand functionalities because dynamic cancellation and overwriting of started vehicle missions were not possible. In order to provide a flexible minibus service to potential passengers, the routing must be made more flexible. Here, too, the exchange of information between the vehicle manufacturer and the mobility platform provider is of enormous importance. The exact description of the API problem, starting from the booking of the vehicle by a customer and the provision of the minibus is therefore necessary. As the objective is to deploy and integrate automated minibuses in public transport, the respective service has to be provided in a way that is flexible for potential clients and that it is connectable to other transport means in the multi- and intermodal mobility environment. Due to this aspect, it is suggested focus on enabling the flexible route planning and dynamic control of the vehicle based on passenger bookings. This may include new software configurations to provide the full compatibility to the fleet orchestration platform. Ultimately, the availability and effective utilization of data will be essential in overcoming these challenges and realizing the full potential of automated minibus services by integrating them into extended systems such as mobility-as-a-service, which incorporates different travel modes in one application (Arias-Molinares & García-Palomares, 2020; Narayanan & Antoniou, 2023). The integration of automated minibuses in an intelligent transport system (ITS) would enable further advantages for the stakeholders like self-learning systems but also raise new technical challenges which will have to be addressed (see Chap. 18).