A Framework for Automated Driving System Testable

each other. This situation has economic, social and environmental impacts. Indeed, besides the important ecological impacts, rural areas are caught in economic vicious circles : rural inhabitants have less access to public transport, therefore they can not go to places where the salaries are higher, they have less money to invest and thus so does the local government, there is no more investments in transportation services and touristic attractions, and therefore the area is a little more secluded and so on.

However, this vicious circle can be turned into a virtuous circle, by investing in project that improve mobility in rural areas. I did my internship at the Institutes of Land and Maritime Traffic of the Technical University of Berlin, under the tutorship of Alexander EGOLDT. The Department is lead Pr. Dr. Ing. Thomas RICHTER.

This internship is part of a wider project called Autonomer Öffentlicher Nahverkehr im ländlichen Raum (Landkreis Ostprignitz-Ruppin) (Autonomous public transport in rural areas (district Ostprignitz-Ruppin)). This project is funded by the Federal Ministry of Transport and Digital Infrastructure (BMVI) and was assigned to the Institutes for Land and Sea Transport (Institut für Land- und Seeverkehr) of the Technical University of Berlin, the Chair of Traffic Psychology of the Dresden University of Technology, the Ostprignitz-Ruppiner Local Transport Company (ORP) and the Northwest Brandenburg Regional Development Corporation (REG). The project is investigating the implementation of autonomous shuttles in public streets in rural areas. In the context of this project, the user acceptance has to be measured and the conditions for the use of automated vehicles have to be determined [13].

My tutor, M. Sc. Alexander EGOLDT and M. Ing. Arne HOLST are in charge of the project in the Institutes. 4 Sophie CHAUDONNERET/TU Berlin Non-confidential and internet publishable report Automated Driving to Connect Smallest Villages The objective of my internship was to create a graph of the existing drivable roads for an autonomous shuttle in a rural area in Ostprignitz-Ruppin and create an itinerary for the shuttle service that meets the criteria previously determined for such vehicles. Nevertheless, I completed this task before the end of my internship, I therefore have found other things to do in relation to the project, such as creating a graphical user interface to simulate the circulation and use of the shuttle or trying to determine the occupancy and the frequency of the shuttles.

To complete this task, I had access to all the resources of the Institute, I had a desk and a computer designated to me to be able to download programs and modules as I needed some. Sophie CHAUDONNERET/TU Berlin Non-confidential and internet publishable report 5 Automated Driving to Connect Smallest Villages Contents

Creation of the shuttle itinerary.

1.1 Defining the criteria for the implementation of an autonomous shuttle. The first step in my research project was to learn everything about the autonomous shuttles and their implementations. I found a lot of documentations on autonomous driving and its impact on the population.

Some reports on previous projects were also very useful for mine. Unfortunately, I found little to none documentation on the implementation of autonomous shuttle in rural areas. Therefore, I tried to adapt the projects that had already been implemented in urban areas to the rural area I had to work on.

Indeed, numerous projects were carried out in the last few years. Most of them took place in European countries, such as in France, with the examples of Navya in Confluence (Lyon) or EasyMile at the Oncopole (Toulouse). An autonomous shuttle is made to adapt to its environment, it is thus equipped with many different sensors (LIDAR, cameras, radars, GPS, Inertial Measurement Unit, odometry, …)[6] .

Nevertheless, driving in rural areas is even more challenging as the roads and side roads are not of uniform quality and can be quite damaged by different factors : exposition to climatic hazard, varied users (agricultural vehicle, herd) and less frequent maintenance of the roads.

Therefore, tracks that are not well maintained or gravel path are not suited to an autonomous shuttle. Unfortunately the shuttle adaptability is also limited by the sensors sensitivity. Previous experiments conducted across Europe as part of a bigger project called Citymobil2 concluded that some weather conditions represented an issue for the shuttle [1]. Indeed, the LIDAR and LASER sensors used to detect obstacles tend to malfunction during heavy rain and hail, as they detected these as obstacles and thus made the shuttle stop or slow down.

The same issue was noticed during hot dry days with the dust lifted from the ground by the vehicles. This particular issue can imply that road made of dirt are not suitable for autonomous vehicles.

The model EZ10 from EasyMile can also work in temperature from 15oC to 45oC, the shuttle wouldn’t be able to drive during cold seasons [7]. Sophie CHAUDONNERET/TU Berlin Non-confidential and internet publishable report 7 Automated Driving to Connect Smallest Villages An experiment conducted in Appelscha, a village in the Netherlands, raised an other issue : the sensors of the shuttle, which was driving on the cycle lane, detected obstacles on the side of the roads such as low branches or high grass.

In rural areas, this issue can be frequent as the roads are most the time lined with high grass, trees and bushes. The report of the case of Appelscha concluded that a 20 cm side distance of ’virtual space’ was recommended to avoid any issue of that kind [3]. Finally, the report of the first autonomous bus line in Germany advise to put up new signs to draw awareness to other drivers [4].

1.2 Creating the network To represent the network, I use the structure of a graph, which is composed of nodes linked together by edges. Those nodes and edges can have attributes. The graph can be directed (the edges have a direction, it can go from node 1 to node 2, but not from 2 to 1) or undirected.

I can also be weighted : a value (weight) is assigned to each edge. A network is usually represented as a weighted graph (directed or undirected). To represent transport networks, roads are usually taken as edges and their intersection or their end (for cul-de-sacs) as nodes. Their weight is the distance between two nodes. One simple solution would have been to make the graph \”by hand\” : select on Google Maps (or a substitute) the area, and measure each distance between two intersections in order to build the graph section of road by section of road.

Clearly, this would have been extremely fastidious and not very accurate. Moreover, I wanted my project to be able to be implemented on other areas, to compare my results or maybe for future projects. Finally, such a solution for a urban area would have been impossible to implement.

Consequently, I searched and found an open data bank for geographical study : OpenStreetMap. OpenStreetMap is a collaborative mapping project which goal is to create a map of the world [12]. The data are free and easily accessible. In OpenStreetMap, edges have attributes, that can describe the length of the edge (weight), the type of road (Highway,) the speed limit (max_speed), the name of the street, etc…

The presence of attribute depends on the user contributions. Afterwards, I found a module that extracted the data from OpenStreetMap and created a graph of a specified area and can be drawn with perspective. The module is called osm-graph and was released in 2018 by Saito Tsutomu [14].

This module was only a sample, so I had to modify the code in order to be able to run it on my computer and to adapt it to my project. Indeed, I was limited by the version of python and the software programs available on my computer. osm-graph creates a class containing different functions, the main function creates a graph with every attributes given in OSM.

To create the graph, one just need to give the coordinates of the center of the area that needs to be studied. The dimension of the area can be modified. This module uses another module widely used in graph-computing : Networkx. Networkx is used to create, navigate and 8 Sophie CHAUDONNERET/TU Berlin Non-confidential and internet publishable report Automated Driving to Connect Smallest Villages modify graphs, it has a lot of state-of-the-art functions to best operate on graphs [2].

Therefore, I was able to obtain a very precise and detailed graph of the studied area thanks to this module. Figure 1.1 – Studied area on OpenStreetMap Figure 1.2 – Graph of the studied area on OpenStreetMap However, this program takes a long time to compute, especially for cities or areas with lots of nodes and edges.

For the studied areas it is not really a problem as rural areas have fewer roads than urban areas, the program creates the graph in only a couple of seconds. To create a graph of Berlin for example (with the same box dimensions), it can take up to 3 minutes.

The difference of road density can be seen in the graph below. Therefore, I would recommend this program for smaller area.s However, it works fine for the mission I have to complete, and avoid installing other modules that take more memory or that requires a newer version of Python. I decided to work on a non-directed graph as roads are always two-ways in Germany, especially in rural areas.

A directed graph would be recommended for big cities in other countries, as, for example, in France the use of one-way streets is quite frequent. Using a directed graph won’t change much to the process, provided Sophie CHAUDONNERET/TU Berlin Non-confidential and internet publishable report 9 Automated Driving to Connect Smallest Villages Figure 1.3 – Graph of Berlin that is mentioned on OpenStreetMap.

1.2.1 Applying criteria on the graph As explained in the previous section, the itinerary has to meet some criteria for the shuttle to be able to drive easily.

While there is nothing much to do about the weather, some roads can be eliminated from the graph due to their composition and maintenance condition. Indeed, the recommendations and information found in the reports suggest that for the shuttle to drive efficiently, the roads must be wide and preferably paved.

The key Surface in OSM gives the composite of which the road is made. Unfortunately, only a few edge have this attribute specified. The key Highway identifies the kind of road an edge refers to , its importance and its condition, almost every edge has this attribute specified. I checked the attribute \”highway\” of each edge and eliminate the ones that were classified as residential or as special such as pedestrian or track (mostly agricultural and forestry use).

1.3 Generating the itinerary The first step of generating the itinerary was to select the villages the shuttle would serve and to determine where exactly it will stop. I decided to work on the “ring” that can be seen in the center of the graph. It is composed of 9 villages or hamlets. The shuttle would stop at everyone of them and at Barsikow, the hamlet in the center.

This “ring” is connected to Wusterhausen, the big village of the area. To determine the position of the stops, I chose bus stops if existing and place in the center of the hamlet if not. The shuttle line is therefore composed of 11 stops, one of the hamlets being served by 2 stops. 10 Sophie CHAUDONNERET/TU Berlin Non-confidential and internet publishable report Automated Driving to Connect Smallest Villages.

1.4 – Shuttle line

1.3.1 Selecting the best path-finding algorithm Once the stops have been determined, I needed my algorithm to find the shortest path possible to go from one node to the other. However, there is different existing methods to find the shortest path in a graph. In the module Networkx there are different functions available to find paths.

Algorithm Description Time complexity Space complexity dijkstra_path Dijkstra method O(|E|+|N|log|N|) O(|N|) bellman_ford_path Bellman Ford method O(|E||N|) O(|NE) astar_path A* method O(|E|) O(NE) To compare the different algorithms, I measured the time it takes for the different methods to find the shortest path between two nodes chosen randomly. In figure 1.5, is drawn this time and the length of the path found for 100 pairs of nodes in the center of Berlin (figure 1.3).

It is clear that the Bellman-Ford shortest-path algorithm is not suited for my program, as Bellman Ford search for shortest paths from a single source to all the other nodes at the same time, and then returns the one to the targeted node.

Therefore, Bellman Ford is more suited if one want to find at once many paths from a single source and then keep it in memory, but not in this case. A* algorithm, is always quicker or equal in time to Dijkstra algorithm (figure 1.6). A* algorithm is therefore more suited to find shortest paths in a minimum of time. However, for the studied area and the number of path I had to find, using Dijkstra’s algorithm or A* algorithm didn’t make much difference. I would recommend A* over Dijkstra for dense graph with many paths to find. Let us compare the methods of each algorithm. Sophie CHAUDONNERET/TU Berlin Non-confidential and internet publishable report 11 Automated Driving to Connect Smallest Villages Figure

1.5 – Method comparison with Bellman Ford Figure

1.6 – Method comparison without Bellman Ford 12 Sophie CHAUDONNERET/TU Berlin Non-confidential and internet publishable report Automated Driving to Connect Smallest Villages Dijkstra’s Algorithm Dijkstra’s algorithm was developed by the computer scientist E. W. Dijkstra in 1956 [5].

It is the base of many path-finding algorithm. Its principle is quite simple : the algorithm starts with the source node and gives the distance value +1 to all the other nodes. Then, it picks the unvisited node with the lowest distance (weight of the edge connecting the two nodes) and evaluates the distance to its neighbors via this node and changes the distance value if it is smaller than before. Dijkstra’s algorithm is a breadth-first search (BFS) algorithm. It explores all the nodes in the graph.

The complexity is therefore polynomial in space O(jNj + jEj) and in time O(jNj), with N the number of nodes and E the number of edges. The simplified algorithm can be written as follows : Algorithm 1 Initialization for all n 2 S do s(n) 1 s(0) 0 N S E ; end for Algorithm 2 Processing while N 6= ; do find n 2 N with s(n) = min N remove n E add n for all 2 V+(n) \\ N do if s(m) > s(n) + e(n,m) then s(m) s(n) + e(n,m) p(m) n end if end for end while A* algorithm A* is a very popular and used algorithm to find shortest path. It is an extension of Dijkstra’s algorithm, and was published shortly after the later (1968) by Peter Hart, Nils Nilsson and Bertram Raphael [11].

It has the same principle as Dijkstra, but instead of giving the value s(n) (the cost between the starting node and the current node n), it calculate f (n) = s(n) + h(n). h is a heuristic function : it estimates the cost between the current node n and the final node. Therefore, it doesn’t have to go through every node as he prioritizes the estimated shortest path. Sophie CHAUDONNERET/TU Berlin Non-confidential and internet publishable report 13 Automated Driving to Connect Smallest Villages.

There are different usual heuristic functions : – Uniform Cost Search : h = 0, therefore the algorithm operates as Dijkstra’s algorithm as f (n) = s(n). Nevertheless, UCS is faster than Dijkstra’s algorithm as Dijkstra adds every nodes of the graph to the waiting list at the start, while UCS adds nodes to the waiting list as it discovers them, which makes UCS much more efficient [9]. – Manhattan distance : h = jxn x f j + j yn yf j with n the current node and f the final node. This function is best suited for cases where it is only allowed to move in 4 direction. – Euclidean distance : h = Æ (xn x f )2 + ( yn yf )2. It is best suited for cases where it is allowed to move in any direction.

1.7 – A* method with different heuristics As we can see in figure 1.7, A* algorithm with heuristic function *Manhattanis the fastest method, followed by the euclidean function. However, the Manhattan function doesn’t computes the shortest paths possible : the length of the paths is always slightly superior(or equal) to the paths found in by the UCS or the euclidean functions.

Therefore, I used the A* algorithm with the euclidean heuristic function to determine the paths between the different shuttle stations. k 1.3.2 Result and possibility of road rehabilitation Figure 1.8 shows the itinerary for the autonomous shuttle. The shuttle takes 1h 21min 52s to serve all stops. And it takes on average 7min26s between two stops. While finding the shortest path, we can see that there is no direct road to connect Barsikow and Segeletz, Dorfmitte (the 2nd and 3rd stops).

Therefore, it can 14 Sophie CHAUDONNERET/TU Berlin Non-confidential and internet publishable report Automated Driving to Connect Smallest Villages Figure.

1.8 – Graph with itinerary interesting to see if rehabilitating a track connecting directly the center of Barsikow to Segeletz can reduce the length or the itinerary and also the time it takes.

1.9 – Itinerary with rehabilitated road I hence changed the attribute \”Highway\” of this edges from track to secondary (figure 1.9). Track describes roads for agricultural or forestry uses.

It is most of the time unpaved and not fit for autonomous shuttle circulation. The shuttles now takes 1h14min54s to complete the itinerary, that is 6min58s less than before. The time for the shuttle to go from Barsikow to Segeletz went down from more than 12min to 5min30s. Rehabilitating this road for shuttle use could be beneficial for the project, and would reduce the time of the itinerary.

Sophie CHAUDONNERET/TU Berlin Non-confidential and internet publishable report 15 Automated Driving to Connect Smallest Villages.

2 Simulation of the shuttle implementation. Once I had determined the criteria for the implementation of the autonomous shuttle and I had created an itinerary, I had completed the objective of mt internship.

I had to find something else to do as part of the project. I decided to try implementing a simulation of the shuttle driving the itinerary, which lead me to create a graphical user interface that could later on be useful to the project.

2.1 Simulation of the shuttle traffic The German Road Traffic Licensing Regulations states that an autonomous vehicle should drive at an maximum speed of 25km.h1 [8]. To make it easier to simulate the shuttle traffic, I changed the weight of each edge of the graph from the distance between the two nodes to the time the shuttle would take travel this distance. As the legal maximum speed for a shuttle is only 25km.h1, it was never over the speed limit of any road in the area.

If the shuttle could drive much faster, it could change the path. To simulate the movement and the evolution of the shuttle, the program is composed of an infinite loop while. Each time it goes back into the loop, one second has passed and the program checks if the time corresponds to a new stop.

The program knows at any moment where the shuttle is, the number of passenger in it and the time until the next stop. At each stop, a random function give a number of passenger coming in, that will get out of the shuttle at a random station. This number of new passengers is checked to see if the number of passenger swill not exceed the capacity of the shuttle at any moment.

If someone is getting in or out, the shuttle waits one minute. At first, I had determined path that could skip a station if nobody was getting in nor out. However, the paths were very similar to the original itinerary, the detours to go to the skipped station were negligible if not nonexistent.

This was the case for all of the path, except the one between Buckwitz and Segeletz (figure 2.2 in blue). Therefore, I decided to implement this protocol only for this stop. But the struc- 16 Sophie CHAUDONNERET/TU Berlin Non-confidential and internet publishable report Automated Driving to Connect Smallest Villages ture of the my program wasn’t fit for this protocol, the passengers would have to tel before the shuttle arrives if they want to get in. F

2.1 – Shuttle traffic program flow chart Figure. 2.2 – Direct and indirect itineraries Sophie CHAUDONNERET/TU Berlin Non-confidential and internet publishable report 17 Automated Driving to Connect Smallest Villages

2.2 Creation of a graphical user interface In the global project, the shuttle would have a user interface to be able to use the shuttle.

Therefore, I decided to create a GUI (graphical user interface) that could be a first draft of this user interface, and that could also present the project. Therefore, I used the python module Tkinter to create the graphical user interface. This GUI is composed of three tabs. The first tab is the user interface, where one can enter the information for a new ride : number of passengers, starting station, destination station. The second tab display the graph and the itinerary obtained previously.

The last tab gives information on the status of the shuttle : its position and the number of passengers it is carrying. The users can also get more information on the project as there is a link redirecting them to the presentation web page and on the shuttle with its technical properties.

2.3 Simulation of the use of the shuttle The final step of this process was to combine the two programs. The GUI needs to contribute to the shuttle traffic simulation and vice versa. Unfortunately, the simulation that process and update continuously the data concerning the shuttle and its location can not do it while the Tkinter window is open, and the other way around.

The solution is to have two threads running at the same time and exchanging data : it is called Threading. What is a thread? A thread is flow of execution : the program take one operation at a time from the beginning to the end of the program.

Python cannot execute multiple things at the same time. If one needs to execute multiples operation simultaneously, one would need to use the module threading. Actually, the module threading only gives the impression of running the two threads separately and at the same time; it only divides the time in little portions to be able to execute thread 1 then thread 2 in a fraction of second of difference.

It is different from multiprocessing, which runs the different threads on different processors. Nevertheless, threading allowed me to process the evolution of the shuttles and the update and take new passenger’s demands on the GUI at the same time, as there were only two threads and that those threads spent most of their time waiting for something to happen (waiting for a second to go by for the simulation and for a new passenger demand for the GUI). My program displays in the GUI the position of the shuttle and the number of passengers in it in real time.

It can also skip the stop at Barsikow if no one want to get in or out of the shuttle at this hamlet to save time. I added another shuttle that goes counterclockwise, and other shuttles can be implemented if need be.

When a passenger enters a new trip, a window pops up telling him how many people can do this trip and give an estimation of the time of the arrival of the shuttle (it can determine which shuttle to take) at the starting stop and the time of the arrival to 18 Sophie CHAUDONNERET/TU Berlin Non-confidential and internet publishable report Automated Driving to Connect Smallest Villages.

2.3 – Threading for the simulation of the use of the shuttle destination. The program then waits for the user to validate or to cancel this trip before processing it (that is to say update the data). The screen shots of all the windows and tabs of the GUI can be found in the appendices. Sophie CHAUDONNERET/TU Berlin Non-confidential and internet publishable report 19 Automated Driving to Connect Smallest Villages.

3. Study of the shuttle use. I therefore succeeded in creating a simulation of the shuttle, but while computing this simulation, I realised that it would be interesting to try and estimate the number of shuttles needed to transport all the users. Therefore, I decided to lead a study on the occupancy of the shuttle, and to see, considering the criteria determined previously, if the autonomous shuttle can be a reliable alternative to individual vehicles.

3.1 Shuttle traffic condition

3.1.1 Climate conditions As explained in section 1.1, the shuttle can not drive under some weather conditions. Indeed, heavy rain, hail and dust lifted from the ground during hot days are sometimes detected as obstacles by the LIDAR sensors. Moreover heavy rain and storms are not suitable for autonomous driving. Data provided by WorldWeatherOnline. com that show the average rainfall, rain days and snow fall in Neurippin can be found in the appendices. It shows that rain days are mainly gathered in July and August, where heavy rainfalls occurs for short period of time. However, the area is not particularly inclined on heavy rains.

On the other hand, snowfalls occur mainly in January, between 5cm and 10cm on average for the month, depending on the year. Again, the area is not victim of heavy snowfall in general. The shuttle would therefore have to stop working for few hours or maybe some days in winter or summer due to climate conditions, but it would only occur exceptionally. EasyMile also mentions that one of its shuttle can only drive under quite high temperatures : 15oC – 45oC [7].

3.1 displays the average minimum and maximum temperatures in Brandenburg over the year. We can see that this criteria is much more strict, as the average temperature between October and May is below 15oC, which means the shuttle will not be able to work most of the year !

This also means that, if the shuttle only works for 4 months a year, and within this period is likely to stop working if it rains heavily during summer, user will not 20 Sophie CHAUDONNERET/TU Berlin Non-confidential and internet publishable report Automated Driving to Connect Smallest Villages be able to get used to using the shuttle and thus shared autonomous driving will not become a relevant alternative for their daily trips. Figure 3.1 – Average temperature in Brandenburg ; Data provided by weather-and-climate.com.

3.1.2 Population Let’s suppose the shuttle would drive under low temperatures. The main goal of this project is to propose a convenient alternative to individual cars or to improve mobility to people who can not use individual cars. To be able to predict the use of the shuttle and to implement a better schedule, we need to estimate the number of people who would be using it.

I did a low and a high estimation : the low estimation is that 5% of the population in the area will use the shuttle, this estimation is mainly for the beginning of the project. The high estimation is that 20% of the inhabitants will use the shuttle. This high estimation depicts the use of the shuttle in the long term, if people adopt it as a new way of traveling. Village (or hamlet) Population Estimation 5% Estimation 20% Buckwitz 170 9 34 Barsikow 183 9 37 Segeletz 170 9 34 Nackel (2 stops) 277 14 55 Vichel* 200 10 40 Garz* 200 10 40 Rohrlack* 250 13 50 Wildberg* 250 13 50 Ganzer 176 9 35 Metzelthin 124 6 25 Total 2000 102 400 * estimation based on the total population of municipality Temnitztal (1460 inhabitants) [10][16] According to my estimations, between 100 and 400 passengers would be using the shuttle every day.

Sophie CHAUDONNERET/TU Berlin Non-confidential and internet publishable report 21 Automated Driving to Connect Smallest Villages.

3.2 Attendance estimation Once the total number of possible passenger has been estimated, ew need to find a model of the use of the transport service during a day.

Afterwards, we will be able to give an estimation of the number of autonomous shuttles needed and their frequencies. Therefore, I tried to creates models, based on the use of public transports in cities and its suburbs, giving the number of passenger by time slots.

3.2 – Hourly profile per typical day of ticket validation on surface network ; Data provided by opendata.stif.info The graph above was created from the open data provided by Île-de-France Mobilité. It depicts the percentage of ticket validation on the \”surface network\” (trains, RER, …) for a typical day during the 2nd semester of 2018.

Different day profiles were distinguished :

– Working day outside school holidays

– Saturday outside school holidays

– Working day during school holidays

– Saturday during school holidays

– Sunday and public holiday In black is also drawn the weighted average use of this network.

Three peaks can be noticed :

– In the morning, between 7h and 9h, where the use of the public transports is high and dense (the peak is quite narrow)

– At noon, between 12h and 13h, where the use is much lower 22 Sophie CHAUDONNERET/TU Berlin Non-confidential and internet publishable report Automated Driving to Connect Smallest Villages

– In the evening, between 16h and 19h, where the use is high but more spread across the time slot.

From those data, we can make out 2 scenarios :

– Working people commuting : they go to work at the same hour and back to home in the same, broader time slot,

– Non-working people, using public transport during the whole days for leisure or other activities.

I therefore divided my study into two models : commuting, corresponding to the two higher peaks (the first and the last), and leisure, corresponding to the lower, more spread middle peak. To model each peak, I used the Gaussian function ga,,(x) = a.e1 2 ( (x) )2 .

3.3 – Models identified for the use of public transports

3.2.1 First model : Commuting The commuting model is composed of 2 peaks, it would then be f (x) = gpeak1(x)+ gpeak2(x). I supposed that every passenger that used the network in the morning would use it in the afternoon. Therefore, Z +1 1 gpeak1(t) d t = Z +1 1 gpeak2(t) d t Sophie CHAUDONNERET/TU Berlin Non-confidential and internet publishable report 23 Automated Driving to Connect Smallest Villages As f (x) is a probability density function, R +1 1 f (t) d t = 1, then : Z +1 1 gpeak1(t) + gpeak2(t) d t = 1 Z +1 1 gpeak(t) d t = 0.5 Since R +1 1 ga,,(t) d t = a p 2, we have : a1 1 p 2 = a2 2 p 2 = 0.5 To determine 1 and 2, I took the hour the occupancy peaked on the date provided by Ile-de-France Mobilité. For 1 and 2, I measured the FWHM (full width at half maximum) as FWHM = 2 p 2 ln(2) 2.3548 .

Then, I calculated a1 = 0.5 1 p 2ln(2) and a2 = 0.5 2 p 2ln(2) . This model would mean that the passengers would use the autonomous shuttle to go to work. Therefore, the trips would mainly be directed to the biggest city. That is to say, they would go in the morning to Buckwitz, which has a direct connection to Wurterhausen (Dosse), a city with more than 5 800 inhabitants. In the evening, it will be the opposite, most of the passengers would take the shuttle from Buckwitz to their residences.

Therefore, there would be many passengers between (7h-9h) and (15h-18h). 3.2.2 Second model : Leisure The second model would be to consider that passenger would use the shuttle service to travel for other activities and for leisure, the use would therefore be more spread out through the day, centered around midday. The soft peak is also modeled by a gaussian function.

Unlike the first model, the rides would not be directed to one station, passengers would go from anywhere to anywhere.

3.3 Determination of shuttle frequency From those models, we an try to implement different shuttles, at different frequencies in order to optimize the traffic. Figure 3.4 shows the models compared with the data provided by Iles de France Mobilité, and a combination of the two models that fits the most the data: 23 of the passenger would follow the commuting model, 1 3 would follow the other.

3.13 in the appendix shows the estimated number of passengers based on this final model. We can see that even with the low estimation, the number of passengers exceed the capacity of the shuttle (6 passengers) for some time slots. A shuttle takes approx. one hour to serve every station. Therefore, for every time slots, a shuttle can only serve a station one time. For the time slot 7h-8h, the number of passengers for the high estimation would need 10 to 11 shuttles, which is obviously 24 Sophie CHAUDONNERET/TU Berlin Non-confidential and internet publishable report Automated Driving to Connect Smallest Villages.

3.4 – Models compared to the data of a working week day (black) not feasible. However, one solution to reduce the number of shuttles while having the maximum number of users would be to have some shuttles only serving the stops near Buckwitz, for example doing only half the stops of the itinerary. I

ndeed, as explained before, the rides in the peak hours can be specified due to their purpose : passengers are going to work in the morning and going home in the evening; their work surely being at Wuterhausen, connected to Buckwitz. With this solution, the shuttle would serve half the station twice as fast.

3.5 – Shuttle line with two itineraries Sophie CHAUDONNERET/TU Berlin Non-confidential and internet publishable report 25 Automated Driving to Connect Smallest Villages We could implement 2 shuttles for the main itinerary, one going clockwise, the other counterclockwise, and 2 shuttles for the small itinerary. This way, the shuttle service could drive around 36 people in one hour.

This won’t be sufficient for the high estimation in the morning (65 passengers between 7 a.m and 8 a.m), but this estimation is set for when the shuttle will be fully adopted by the inhabitants, so not at the beginning of the project. Shuttles could always be added later.

However, 2 or 3 shuttles would be sufficient for the low estimation. As the number of passengers varies greatly throughout the day, the number of shuttles in service could be reduced during off-peaked hours, allowing the shuttles to recharge if need be. The model EZ10 by EasyMile has a battery of 16 hours, while the shuttles needs to drive from 6 a.m to 8 p.m (according to the model) : they would need to recharge during the day. Half the shuttles could charge at mid-day as the others drive and the other way around afterwards. 26 Sophie CHAUDONNERET/TU Berlin Non-confidential and internet publishable report Automated Driving to Connect Smallest Villages Sophie CHAUDONNERET/TU Berlin 27 Schedule of the Internship of Sophie Chaudonneret Calendar Week 20 21 22 23 24 25 26 27 28 29 30 31 Arrival and Induction Literature Research Developement of Criteria Creating the network and itinerary Programming the shuttle simulation Field study and attendance estimation Conclusions Report Univ.-Prof. Dr.-Ing.

Thomas Richter Alexander Egoldt Head of Chair Supervisor Automated Driving to Connect Smallest Villages Conclusion As part of the project \”Autonomer Öffentlicher Nahverkehr im ländlichen Raum (Landkreis Ostprignitz-Ruppin)\” lead by the Faculty of TU-Berlin I worked for and in association with other entities, I carried out a study on the implementation of an autonomous shuttle service in a rural area located the region Ostprignitz-Ruppin.

To do so, I identified, from previous similar projects, the geographical and climatic criteria to enable the autonomous shuttles to drive. I then created a graph of this area thanks to modules on python, selecting the suitable roads from the geographical criteria. I lead a comparison of path-finding algorithm to determine that the A* path finding algorithm was the fastest, while being as efficient as the others. I then selected bus stops and I found the shortest suitable path for the shuttle to link the bus stops. Another part of my project was to create a simulation of the circulation of the shuttle, with a graphical user interface that could be used by future potential users. In this simulation, two shuttles are driving in opposite direction.

Finally, I tired to determine the occupancy of the shuttles. I first compared the climatic criteria to the climate in this area to see if a autonomous shuttle would be appropriate : heavy rains and snowfalls would prevent the shuttles to drive, but only for a few days during the year.

The main issue is the temperature : easymile model EZ10 can only drive under high temperatures : the shuttle could only drive from May to September. Besides those considerations, I estimated the number of potential passengers.

To know the occupancy of the transport service throughout the day, I created a model based on the data provided from the transport network in Iles de France (France). I draw two behaviours : working people commuting and people using the shuttle for other activities.

Thanks to this model, I was able to determine the number of shuttles needed (from 2 to 4 depending on the estimation) and their charging schedule Unfortunately,the temperature criteria are too strict and those autonomous shuttles could represents a reliable alternative to individual vehicles only if this problem was solved.. The next step would be to run a pilot with one shuttle to see if it can drive easily on the itinerary found and to see how it integrates in the environment and with other vehicles.