Ana Peleteiro*, Juan C. Burguillo and Marcelo Armendáriz. Gérald Arnould and Djamel Khadraoui

Transcription

1 Int. J. Space-Based and Situated Computing, Vol. 2, No. 4, Modelling and simulating a dynamic carpooling system for improving citizens mobility Ana Peleteiro*, Juan C. Burguillo and Marcelo Armendáriz Department of Telematic Engineering, University of Vigo, Vigo, Spain apeleteiro@gti.uvigo.es J.C.Burguillo@det.uvigo.es marmendariz@uvigo.es *Corresponding author Gérald Arnould and Djamel Khadraoui CRP Henri Tudor, 29, Avenue John F. Kennedy, L-1855 Kirchberg, Luxembourg Gerald.Arnould@tudor.lu djamel.khadraoui@tudor.lu Abstract: The wireless traffic safety network between cars (WiSafeCar) project aims at increasing the performance and reliability of the wireless transport and to provide traffic safety improvements. Within the context of this project, we have designed a dynamic carpooling system that will optimise the transport utilisation by the ride sharing among people who usually cover the same route. An initial and quick prototype of the system has been developed by using NetLogo. The information obtained from this simulator will be used to study the functioning of the clearing services, the current business models and to propose new ones. The first results seem encouraging in the sense that traffic decreases substantially, and the users have many economical advantages thanks to the sharing of costs which allows the individuals to retrench expenses and to contribute to the use of green technologies. Keywords: carpooling; mobility; simulation; mobile communications. Reference to this paper should be made as follows: Peleteiro, A., Burguillo, J.C., Armendáriz, M., Arnould, G. and Khadraoui, D. (2012) Modelling and simulating a dynamic carpooling system for improving citizens mobility, Int. J. Space-Based and Situated Computing, Vol. 2, No. 4, pp Biographical notes: Ana Peleteiro received her MSc in Telecommunication Engineering in 2009, and MSc in Telematics in 2010; both at the University of Vigo, Spain. She is currently a PhD Researcher at the Department of Telematic Engineering at the same university. Her research interests include multi-agent systems, game theory, self-organisation, reputation and trust. Juan C. Burguillo received his MSc in Telecommunication Engineering in 1995, and PhD in Telematics in 2001; both at the University of Vigo, Spain. He is currently an Associate Professor at the same university. He has participated in several R&D projects, and has published more than 100 papers in journals and conference proceedings. His research interests include game theory, web services and multi-agent systems. Marcelo Armendáriz received his MSc in Telecommunication Engineering in 2010 at the University of Vigo, Spain, and MSc in Telemedicine and Bioengineering at the Polytechnic University of Madrid. His research interests include neural networks, telematic services, multi-agent systems and biomedical imaging together with medical decision support systems. Gérald Arnould received his PhD in Microelectronics in 2006 at the University of Metz, France. He is currently a Postdoctoral Researcher and Project Manager at the CRP Henri Tudor, Luxembourg. He has six years experience in the fields of mobile ad hoc and hybrid networks resulting in several international publications. He has been working on EU and national research projects (WISAFECAR, CLAIRVOYANT) in the fields of context aware and intelligent mobility. Copyright 2012 Inderscience Enterprises Ltd.

2 210 A. Peleteiro et al. Djamel Khadraoui is a Lead R&D Manager coordinating several European projects in ICT for sustainable mobility, intelligent systems and software engineering. He is a DC COST member in the domain of ICT and transport. He is involved in many conferences and workshops. He published a book in coordination with IDEA Group Publishing. He mainly participated and coordinated several previous and current EU projects: MICIE, LINKALL, as the Project Manager, CARLINK, WISAFECAR, RED, and STIMULATE as technical project coordinator. 1 Introduction In the past few years, governments, industry and academia have been more and more interested in exploring road safety and other type of vehicular applications by connecting car-to-infrastructure (C2I) and car-to-car (C2C) with several wireless broadband technologies, such as 2G/3G, mobile WiMAX and WiFi. So far, a variety of safety related and other vehicular applications have been developed and wireless technologies for mobility have been studied in several research projects. The main target areas of those activities are/have been: 1 wireless technology research for high-speed vehiculars 2 in-vehicle control device and sensing technology research 3 real-time vehicular application research. For example, the CELTIC s CARLINK project ( developed an intelligent traffic service platform based on hybrid wireless networking targeted at vehicular networking research for seamless C2I and C2C communications, and several intelligent multi-modal transport services based on real-time measurements from smart car sensors. The Car2Car Communication Consortium ( is working on extensive standardisation of vehicle networking systems. However, some critical issues which lay between wireless technologies and services have not been solved nor addressed by any of those activities, that is how data (content) should be handled in the most efficient and reliable manner for such unique services (often by taking advantage of multicasting) in a high-speed vehicular environment where a frequently-changing topology makes the real deployment more challenging. The CRP Henri Tudor from Luxembourg and several institutions from Europe and Asia have been involved into a new initiative called wireless traffic safety network between cars (WiSafeCar, as a continuation of the CARLINK project. WiSafeCar ( is a Eureka- Celtic project involving partners from Luxembourg, Finland, France, Turkey and Spain. The overall aim of this project is to develop a reliable wireless traffic service platform to improve traffic safety, avoid traffic accidents and provide variety of new type of services to vehicles. This objective will be achieved by means of secure data collection from vehicles and fixed stations, secure dissemination of data between vehicles, and make use of such data for real-time transport service applications. The motivation of this project proposal came from Celtic s earlier project, CARLINK. The core members of WiSafeCar consortium have been working together in CARLINK, where intelligent way of creating wireless traffic platform for public transport services was researched and developed based on hybrid networking (mobile WiMAX, WiFi, 2G/3G) and several innovative vehicular applications. In this paper, we present the dynamic carpooling system, integrated within WiSafeCar that will optimise the transport utilisation among people who usually cover the same route. We use Netlogo to build a quick prototype to validate our dynamic carpooling system and to present some results. Carpooling is a simple way for individuals to take part in the climate change challenge while saving money, reducing congestion and conserving energy along the way. This system, very useful for commuters that live near each other and share a common destination, can be very advantageous for occasional travellers too. The idea is to share a car depending on the destination of the s, so they can save costs, and it also helps to reduce pollution and traffic jams. Classical initiatives for carpooling did not succeed due to the lack of flexibility for the user who demands a fast and safe service anytime and anywhere. Usually, classical approaches were only suitable for static situations where the travel time and the destination have been planned before (Keenan and Brodiey, 2000; Psannis et al., 1996; Kelley, 2007; Yew et al., 2008; Ferreira et al., 2009). This is why there is a lot of effort to try to provide these services in a fast changing mobile environment (Correia and Viegas, 2009). The lack of incentive for the drivers, s and also the inexistence of reliable business models for the service providers is also a strong constraint on the deployment of a dynamic carpooling service and finding and validating viable business models has been one of the main focus of every attempt at proposing a carpooling solution (Massaro et al., 2009). In order to deploying dynamic services, it is actually mandatory to solve new business issues. Basically, a customer may subscribe to a carpooling service or he might pay through the use of a credit card or even via his/her telephone bill. However, all of these payment concepts have drawbacks for the user: higher costs, difficulty of use, necessity to register before use, security issues, etc. They also create complex problems for the service provider as this requires handling a lot of contracts to be able to serve all possible mobile users. Our basic argument relies on the need for a clearing mechanism to harmonise the services offered by different

3 Modelling and simulating a dynamic carpooling system for improving citizens mobility 211 carpooling providers. The benefit of such a clearing system is that it considerably simplifies the situation by introducing the role of a trusted party, who secures the interchange among parties without each of them having to setup prior bilateral agreements. In the context of dynamic carpooling, considering navigational services, we identified the role to be played by clearing activities at two distinct levels, namely financial clearing, transport information and other clearing services. Besides the basic payment and billing functionalities, it should be noted that some added value services can be offered by the clearing system such as archiving financial and transport transaction data, the aggregation of this data for deriving information, specific security services, etc. Information clearing corresponds with a clearing activity that is based on the matching of requests expressed by end-users for information with some specific location- and possibly time-data. The rest of the paper is organised as follows. First, we present some related work, and an introduction to the dynamic carpooling transport mode. Then we present the tool Netlogo and the previous urban traffic models used to build our prototype. Then we introduce the dynamic carpooling simulator. Afterwards, we describe the results obtained by the simulator, and finally, we present the conclusions and future work. 2 Related work The intelligent transportation systems (ITSs) ( are a set of technical solutions to improve the operation, security and efficiency of transportation systems. The main goals are the reduction of fatalities and financial losses due to traffic accidents, and also the reduction of expenses caused by traffic congestion (in 2007, the extra costs caused by time lost and fuel in 439 urban areas in the US where 87.2 billion dollars, 10,600 litters of wasted fuel and a yearly delay for the average peak-period traveller of 36 hours 1 ). Besides the services mentioned above, there is also a motivation to provide private services, as web access, file sharing, and many others. There is a huge economic interest in this area to improve traffic safety and save lives on road. Besides, vehicle-to-vehicle (V2V) communication allows the sharing of the wireless channel to improve route planning and traffic congestion (Martinez et al., 2008). In Europe, C2C Communications Consortium 2 is one of the main driving force in the field. Besides the main critical service, which goal is improving safety, they also deal with comfort, transport efficiency and entertainment applications. In 1999, the US Federal Communications Commission allocated 75 MHz of licensed spectrum of dedicated short range communications, from 5.8 to GHz, to be used in the ITSs. This band is used exclusively for V2V and vehicle-to-infrastructure communications. V2V technology, which is akin to mobile ad hoc networks, provides communications among nearby vehicles and between vehicles and nearby fixed equipment, usually described as roadside equipment. A new family of standards is being developed to ensure these communications. The wireless access in vehicular environments (WAVE) 3 communications standards, developed for the US Department of Transportation (DOT), describes the architecture and protocols for C2C communications. Also, IEEE is developing a family of standards, IEEE The first of them, IEEE , treats methods for securing WAVE messages against eavesdropping, spoofing, and other attacks. The second one, IEEE , deals with managing multiple simultaneous data streams, memory, and other system resources. A third one, IEEE , primarily covers how multiple channels including control and service channels should operate. Finally, the IEEE standard, which touches WAVE networking services and protocols. These draft standards cover the five upper layers of the OSI protocol stack. The two lower layers (data link and physical) are implanted by the dedicated short range communications (DSCR) at 5.9 GHz. It is standardised in the draft IEEE p 5, a variant of a adjusted for low overhead operations and it uses the extension IEEE e 6 enhanced distributed channel access (EDCA) for quality of service (QoS). These wireless access standards allow data exchange between high-speed vehicles and between the vehicles and the roadside infrastructure. Within non-safety applications, we find commercial services and applications, where the objective is to improve comfort and traffic efficiency: providing information about the cars position, route planning, weather information, instant messaging, file transfer, P2P services and even electronic payments. Within this non-safety category, we find traffic information systems (TIS) (Wischoff et al., 2003; Rybicki et al., 2009), which aim at providing vehicles with information on the current traffic conditions along its planned route. 3 Dynamic carpooling transport Carpooling consists in sharing a personal vehicle with one or several s sharing part or an entire trip in common. While traditional carpooling requires a prior agreement among the persons that will share a ride, the dynamic carpooling transport mode aims at offering a planning solution able to react in real-time to any additional driver or joining or living the pool of carpoolers. Dynamic carpooling will be able to generate on the fly-or within reasonable bounds-new planning and to provide them to the affected carpoolers. Also, any event that could have an impact on the planning should be taken into account, such as any significant traffic congestion, incident or road-works requiring either a re-routing or purely and simply a whole new planning computation. The dynamic carpooling will also be included in a step by step recommendation service, guiding each carpooler for the whole duration of their trip and providing up to date information concerning the shortest path to reach their destination. That is why the WiSafeCar communication and

4 212 A. Peleteiro et al. services platform is of utmost importance, since it maintains a seamless link between the mobile users and the service backend. The overall platform is described in Arnould et al. (2011). 3.1 Flexible, real-time planning solution for carpooling Since there is no need for any in-advance planning, the dynamic carpooling transport solution relies on each user owning a mobile terminal such as a smart-phone running the ad hoc carpooling client application, which in turns relies on the WiSafeCar communication and service platform to provide the actual planning and recommendation service. Each user enters on his mobile terminal his requirements, such as departure and arrival time and locations. This data alongside up to date information on traffic conditions for instance, is continuously processed using a flow algorithm. Any context change traffic jam or accident is immediately taken into account and a new planning is provided to the affected users directly on their terminal. 3.2 Data collection and position tracing The WiSafeCar project is developed in Luxembourg, among other cities. There, the location tracing service collects positional data directly from the users using a multi-agent system (MAS), allowing a quick detection of any abnormal user position resulting in a new itinerary computation. This tracing service is tightly disconnected from the rest of the system and is subject to the user through the application running on its mobile phone voluntarily sending position updates when it detects an event possibly impacting his planning. This ensures that our application invades as little privacy as possible. Moreover, third party transport provider services maintain up-to-date timetables and the road administration provides data concerning road-works, accidents, etc.; mainly through standard web services connected to the main application platform as shown on Figure 1. Figure 1 3rd Party Services 3rd Party Transport Providers (802.11p - 3G networks -...) WiSafeCar services platform (see online version for colours) External Road Traffic Information Service Security Service Clearing Service MULE Enterprise Service Bus - SOAP messages WiSafeCar Services Platform Location Tracing Service Dynamic Carpooling Service Planning Service WiSafeCar Networking Layer Other Services Driver 1 Driver 2 Driver n Passenger 1 Passenger 2 Passenger n 3.3 Travel transactions and compensation For the purpose of modelling and clearly defining how the various actors participating in the dynamic carpooling service will interact with each other, we introduce two formalisms borrowed from the finance and business domain: transaction and clearing (Khadraoui, 2003; Feltus et al., 2004). A transaction is the digital counterpart of the planned ride to be shared by a driver and a, while clearing consists in compensating the changes in the actual trip, which may not be setup as planned, but as a result of intangibles events (traffic congestion, snow, etc.) Transaction-based system The value exchange procedures in WiSafeCar for the transport scenario rely on the existence of so called transactions, which are generated each time a driver and a agree on travelling together during a carpooling trip. The content of one transaction depends on the business model but in general they contain the same type of data. For instance, in the case of the dynamic carpooling transport mode, one transaction could contain information such as the amount of kilometres in one trip, the duration of the trip, a unique identifier for the driver and another one for the. The above parameters are gathered from all the participants to the transaction: drivers, s, etc.; and there are dual transactions associated with each trip: one for the driver and one for the. If the driver has to drive four s, there will be in turn eight transactions produced: two for each pair of driver/. Clearing service The clearing service plays three main roles in our application. The first one consists in allowing several actors to interact seamlessly within the dynamic carpooling transport mode: drivers, s, the carpooling service and the communication platform providers among others. The clearing house who is hosting the clearing service is also one of the considered actors. All the aforementioned actors exchange value when a carpooling trip is agreed upon or during the trip itself: the carpooling service provider gives an added value to both the drivers and the s through the real time planning service; the driver provide the (s) with a transport; the communication platform provider allows relaying positional and traffic information as well as planning updates to and from the carpoolers. These exchanges are assessed thanks to the clearing service: it allows proper compensation for the service rendered by each actors according to the business model agreed upon. Secondly, it assesses the validity of the transaction data. To that extend, it ensures that the dual transactions generated once a carpooling trip is agreed upon by all the parties are valid and homogeneous. It simply means that the transaction generated for the driver and its counterpart should contain the same information. Any significant difference would mean a tentative of fraud or that some kind of data corruption

5 Modelling and simulating a dynamic carpooling system for improving citizens mobility 213 did happen during the processing of the transaction data. The third role of the clearing service follows from one the main characteristics of the dynamic carpooling system that needs to react to unforeseen events in real time: any kind of event having an impact on the trip of one carpooler will also change the distance or time spent on a trip or both. The clearing service must take into account these changes since they have an impact on the value exchanged between the involved parties. An additional transaction, called compensation transaction is produced as a result of the unforeseen event. In specific cases, for instance when the new planning generated as a result of the event includes changing the organisation of a car (a driver has to take or leave a or a has to change car), new transactions reflecting these new trips will be necessary. Several implementation and in depth studies of service clearing on a more general basis are for instance available in Khadraoui (2003) and Feltus et al. (2004). Transaction and clearing services implementation The transaction and clearing services are implemented in a mostly distributed way as shown on Figure 1. The high level services rely on an enterprise service bus to communicate with each other using standard SOAP 7 based messages. In our implementation, the mule ESB is used as well as the Saddle layer 8 for workflow designing. This approach allows the seamless integration of several third party developed services into our architecture and as such offers good opportunities for future evolutions. The second half of the transaction service is distributed among the carpoolers terminal: each one runs a client application keeping track of several parameters such as the amount of kilometres spent with one driver, possible deviation from the initial planning, etc. These parameters are sent to the clearing system at the end of the trip by all the parties. Detailed implementation information for the whole platform is available in Arnould et al. (2011). 4 Urban traffic simulation in Netlogo A quick prototype, the dynamic carpooling simulator, within WiSafeCar, was implemented in NetLogo ( a multi-agent programming language and modelling environment for simulating natural and social phenomena. Urban traffic simulation starts in Netlogo with the gridlock model by Wilensky and Stroup (1999). Several enhancements have been done based on this initial model included in NetLogo distribution. In Gershenson (2005), we have an extended version of the Gridlock model that consists in an abstract traffic grid with intersections between cyclic single-lane arteries of two types: vertical or horizontal. Cars only flow in a straight line, either eastbound or southbound. Each crossroad has traffic lights which allow traffic to flow in only one of the arteries, which intersect it with a green light. Yellow or red lights stop the traffic. The light sequence for a given artery is green-yellow-red-green. Based on this enhanced version of the gridlock model, the GTI group from the University of Vigo has carried out new extensions improving the MAS simulator in order to make it more realistic (Burguillo-Rial et al., 2009). This simulator developed by GTI removed the torus and improved the car movements in order to let them drive in four directions: north, east, south and west. We created a by-pass road to improve traffic, which is the outermost in the scenario. Regarding the structure of the map and the roads, this new version has the possibility of bidirectional roads and roads with two lanes in the same direction, controlled with a slider in the NetLogo interface. Besides, an algorithm to avoid deadlocks at the intersections was implemented. Finally, this GTI simulator also included a new functionality where some drivers could be considered as commuters. A commuter car drives in the city and stops whenever it has arrived to its destination. Afterwards, it drives back home. In this way, the origin and destination are exchanged at each stage. 5 The dynamic carpooling simulator A new version of the simulator has been developed in a collaboration between the GTI group from the University of Vigo and SSI of the CRP Henri Tudor in Luxembourg. As the simulator already developed by the GTI was able to manage an urban traffic area, modelling the cars as agents, and implementing several traffic lights mechanisms; in the new version presented in this paper (see Figure 2) we mainly add the dynamic carpooling functionality. But, we also enhance some of the previous functionalities of the MAS in order to get a more realistic scenario. Since the dynamic carpooling system design had been previously carried out, the goal of the simulator was to evaluate how it works with different parameter settings and to gather information related to the trips in order to analyse current business models and/or to develop new ones. The dynamic carpooling simulator includes a set of new features, which are described next. 5.1 Car creation improvements With this new approach, cars have new attributes and targets to follow. Cars have an identification number, driverid, which distinguish them from the other cars, in terms of s association, in order to do the corresponding compensation at the end of each trip. Each car keeps a count of the distance covered during the itinerary, and the time spent from the moment it was started until the destination was reached.

6 214 A. Peleteiro et al. Figure 2 Snapshot of the dynamic carpooling service simulator (see online version for colours) The simulator interface provides the user with a slider, with values between 0% and 100%, to choose the probability that a car belongs to a carpooling provider. In case a car is part of a carpooling system, they must belong to a specific provider (A, B or C) which is also determined according to the corresponding parameters. The system will try to match these carpoolers with the users who have requested the service and thus a new itinerary will be set to them. The fact that a car is part of a carpooling system does not guarantee that it will perform a service giving a ride to one or more s. In the previous versions, the drivers had an origin and a destination, and those values were definitely unchanged. Now, depending on the number of s associated to it, the car has a list of intermediate stops where it picks up or drop clients, before arriving to the destination. The number of s inside each car can be selected using a slider. The minimum value is 0 and the maximum is 4. When a is assigned to a car, his identification is stored in the s-list of the car, and when the maximum number of s in the car is reached, the vehicle will not be available. 5.2 User creation improvements We have created a new breed called users with several attributes. Users also have an identification number, userid, with which the driver is be able to authenticate himself in the carpooling system. In order to identify if a user has been served or not, a happy or sad face appears on his location. After a random period of time, these users disappear and new ones are created at the city. The number of carpooling potential users is easily adjusted by using the corresponding slider. As the users are actually clients, they must belong to a carpooling provider, and the system will try to match them with the most suitable driver from such provider. Once a gets into a car, his userid is added to the list of present-s. Each keeps count of the distance covered, and the time spent to do the trip. Insomuch we are talking about services and providers, we also talk about business. A compensation method for a may depend on the number of s he is sharing with. For this reason, each user keeps count of the time and distance covered sharing with one, two or three s, or travelling alone. 5.3 Matching algorithm An interesting functionality included in the carpooling simulation is the matching algorithm, which is in charge of finding a suitable driver for the carpooling s. First of all, when a trip is requested by a user, the system seeks the drivers that are travelling in the same direction as the wants to follow. Once it has the list of possible drivers, the matching algorithm compares the origin and destination of the to the drivers paths. If a driver whose itinerary contains the client s trip is found, the matching algorithm checks if the car has available places and if so, the user will be labelled as matched. The

7 Modelling and simulating a dynamic carpooling system for improving citizens mobility 215 driver assigned to this user has to add two more intermediate stops in his destinations-list, the pickup location and the drop point. Likewise, he adds the userid of the to the s-list. If there is no driver who fits the request, the user will show a sad face and disappear after a period of time. A new one will be created afterwards in another city point. Figure 4 Snapshot with a high level concentration area (see online version for colours) 5.4 High populated areas Thinking about a normal situation in a city, it is quite often to find places more populated than others, and also destinations more demanded, as the people are not evenly distributed. For instance, most of the people tend to concentrate in the centre of a city rather than the outskirts. It is also very common that there are certain areas where most of the people go to work, such as business, commercial or industrial zones. For this reason, and aiming to simulate a more realistic situation, we have developed a new functionality where we can choose the area of the map were the population density is higher by entering the coordinates of the central point of this overpopulated region. The radius of this area and the level of concentration depend on the number of people belonging to the city and the percentage of the people who live in such area. Figure 3 Controllers for managing the concentration of the population (see online version for colours) Likewise, we can simulate the business area of the city were the majority of the people demand to go. The mechanism is the same, we select the central point by entering the coordinates, and the s will request to go that place with a certain probability. By adjusting the slider shown in Figure 3, we can decide what percentage of the population belongs to these zones. In the input boxes labelled as xop and yop we enter the coordinates of the patch which is the central point of the most populated area. With the boxes labelled as xdp and ydp we can set the coordinates of the central point of the most demanded zone. Finally, in the box named concentration, the level of concentration of the population is shown. Figure 4 shows a situation where the 80% of the people is located in the same region. Given the central patch of the map as the coordinate (0, 0), we can see how the bluish cars are concentrated in the southwest of the city, all of them distributed around the patch ( 40, 40). 5.5 Accident avoidance Another typical event regarding the urban traffic are the traffic jams caused by accidents. As usual, accidents can block the streets and do not allow the movement of cars. In order to avoid this situation, we make the car to choose an alternative route. As it was implemented in the previous versions of the simulator, a crash can happen when two cars meet in the same point. In this version, the accident can only happen at an intersection, and we add the possibility that a street can get blocked. In case of an accident, and with a given probability, the street may get blocked during a period of time. Since the accidents happen at a concrete intersection, which involves two streets, the stretches of roads leading from such intersection to the adjacent intersections will not be available to drive through them. Since we assumed that the drivers have updated information of the incidents on the road, they are able to change their paths in order to avoid the blocked streets. The cars, which were in those streets when the accident happened, remain stopped, waiting until the end of the blocking period. We can determine in advance the blocking probability in case of accident by using a slider with values ranging from 0% to 100%. Besides, we can also enter the time a street can be blocked by using an input box. 5.6 Data storage The goal of the simulation is to store all the information related to the itineraries such as the distance covered, the time spent, the number of people who share the car during the trip, etc. At the end of each trip, a new file named with the user identifier, is created. We consider a trip as every route covered by one since he gets into the car until he

8 216 A. Peleteiro et al. gets out. Therefore, the itinerary of one driver can contain several single trips. As we stated before, users gather data at every step of the simulation by keeping count of the distance they have already covered. In the same way, they count the time spent during their itineraries bearing in mind the s they are sharing with. The mentioned log file contains all the information that is necessary to proceed with the corresponding compensation method. The contents of the file are described in Table 1. Table 1 Log output Data Description UserID User identifier UserProvider User provider DriverID Driver identifier DriverProvider Driver provider TripStartTime Start time of the trip TripDuration Duration of the trip DistanceSharedBy1 Distance covered by the car with 1 DistanceSharedBy2 Distance covered by the car with 2 DistanceSharedBy3 Distance covered by the car with 3 DistanceSharedBy4 Distance covered by the car with 4 TimeSharedBy1 Time covered by the car with 1 TimeSharedBy2 Time covered by the car with 2 TimeSharedBy3 Time covered by the car with 3 TimeSharedBy4 Time covered by the car with System outputs Apart from the files provided by the simulator and the plots implemented before, the system produces some extra data. We have several output boxes with log information that can be displayed depending on whether the switch is on or off (see Figure 5). In the num-car-carpoolers box, it is shown the number of cars that are labelled as carpoolers, which means they are able to provide the service. The box cars-carpooling keeps count of the number of cars that are currently giving a ride to, at least, one. The monitor box labelled as num-user-carpoolers shows the number of users who have requested the service. Finally, the monitor called users-carpooling displays the number of users who have been already matched with a driver, they can be travelling or waiting for the car to pick them up. During the simulation, we can see several data displayed in the log window. Once a is matched, his identification number and the identifier of the driver who will provide him the service will be shown. Then when the driver pick him up, another notification will be written in this log, and the same happens when the reaches his destination. In case of an accident, the coordinates of the patch involved will be displayed on the screen and will turn orange in the map. In the same way, the blocked streets will become pink. Figure 5 Monitor boxes and switch (see online version for colours) If a user cannot be matched, a red sad face will appear on his location, and instead; if the user has been served, a green smiley face will be shown at the destination. 6 Scenarios, models and results Since we assumed that the first step in providing the carpooling service to a client is to ensure that he can afford the trip cost, we need to calculate the amount of credit the user must have in his account. With the aim of evaluating the clearing service, proposed for the dynamic carpooling system, in order to get a fair estimate of the cost of the trips, we have adapted the simulator to obtain data related to the ideal route a driver could cover in terms of traffic and accidents. Using these results we will be able to compare a normal trip, where traffic jams are common, with an ideal one by comparing the time spent during the route and the distance covered in both situations. The simulation of the transaction starts when both the and the driver arrange a trip. The simulator runs the ideal situation in which the itinerary calculated by the route planner system is carried out without problems such as traffic jams, accidents or any inconvenient situation. In this simulation, the data of the trip is gathered and the value of the route is calculated according to the business model. Then, once the system has checked the users are able to satisfy the agreement the transaction is generated. The second step is to run a simulation with several random events that can cause alterations on the trip giving rise to variations on the value of the route calculated previously. In this case, when the trip is finished, a compensation transaction would be done in order to ensure a correct clearing between the two parties.

9 Modelling and simulating a dynamic carpooling system for improving citizens mobility Clearing scenario: case study The considered clearing scenario relies on the following hypothesis and unfolding of events: Alice needs to go from Metz to Luxembourg Wednesday and she wants to arrive before 8am, Bob and Charlie want to go from Bettembourg to Arlon, Dave wants to go from Nancy to Brussels and must arrive before noon. A, B, C and D uses the WiSafeCar platform for the planning of their travels. The recommendation system suggests the following planning: D takes B and C on his way to Brussels; D also takes A and makes a detour by Luxembourg for her. The system subsequently generates several transactions: from Alice s point of view, A was in D s car for 60 kms. From Bob s point of view, B was in D s car for 40 kms. From Charlie s point of view, C was in D s car for 40 kms. Lastly from the driver s point of view, D drove A for 60 kms, D drove B for 40 kms and D drove C for 40 kms. The recommendation system computes the optimum itinerary for all participants, and the number of kilometres they will spend in Dave s car is also computed. The overall cost of the trip is split in proportion of the number of kilometres done, the number of s in the car, each participant is informed of the planned cost and once everyone agrees the trip can start. During the trip, if something occurs that has a significant impact on any parameter of the trip (traffic jam, roadwork...), the recommendation service computes a new planning to be submitted again to the carpooler and compensation transactions are issued to reflect those changes. Once the trip is finished, the clearing service checks that the transactions obtained from all point of views are corroborating. Also the possible compensation transactions are subsequently applied. Finally, all participants are credited or debited according to their role in the trip. The most interesting part to consider in this sort of planning is that it may contain both urban and non-urban portions, especially in the case of a cross-border scenario. However, the most challenging part consists in the urban portions due to the density of the road network, which is much higher and as such the probability of the replanning to occur. Moreover, in the urban context, a carpooling trip tend to become similar to a shared taxi trip, since the distance travelled during each transaction is smaller, but the number of transactions per trip can on the contrary be much higher. This puts a lot more stress on the clearing service, and this is the reason why the simulation described in the previous sections focuses on the urban scenario. An interesting future extension that we plan to do is to consider a realistic road network including both urban, rural and highway areas. 6.2 Business models In general, business models and value chains in the transport sector involve several business service layers, consisting mainly in traffic services, transport services and activities depending on these two services. The traffic market and the transport market materialise the values exchanged between these service layers. Since in this paper we consider a dynamic carpooling transport system that should seamlessly combine with other transport modes, it is mandatory to design and implement a third party integration layer in order to facilitate the planning, and the booking of the overall trip for the consumer. This integration layer will play two main roles: firstly, it will be a clearing house between the various transport service providers and the other service providers. Secondly, it will ensure the good connection between the dynamic carpooling transport mode and the other transport modes. In traditional multi modal travel scenario, the behaves as the transport service integrator, since he has to buy by himself separately all the transport services that form the overall trip. In an automated system like the one we are describing here, the traveller only has one contact point with the system: the transport service integrator. As such, the system must ensure that all the intermediate transport service providers are compensated according to the value of the services they respectively provide. The resulting service architecture is presented on Figure 6. Figure 6 Transport service Layered structure of multi-modal transport services (see online version for colours) Transport related activities Transport service integrator Transport service provider A Transport service provider A Traffic & Infrastructure related services Service Clearing Provider... Dynamic Carpooling service provider The actors involved in a transport service are of five main types: transport service provider, vehicle driver,, clearing house operator and infrastructure provider. The transport service provider interacts with the s, and the infrastructure provider, but also with the clearing service and the transport integrator. It operates the vehicles required to provide the service, but may also provision several peripheral services such as ticket booths, information terminals, etc. For instance, a bus company uses the road network managed by the public road administration, which is the infrastructure provider, but it also offers information and timetables to its clients. The vehicle drivers provide the actual transport service. They are managed by the transport service provider, or employed by it, if the provider is a company. In the latter case, the vehicle itself is provided by such company. The s are the consumers of the transport service and they pay for it. The dynamic carpooling transport service has several specificities. Firstly, the various actors involved in a

10 218 A. Peleteiro et al. carpooling trip often play several of these roles at once: drivers and s are interchangeable and most vehicles are privately owned. Each driver is by itself a transport service provider and the service integrator plays an even more valuable role here, since it has the responsibility to match the s requests with the drivers availabilities and profiles. Secondly, the overall value of the trip depends on several parameters such has the vehicle fuel consumption, the amount of kilometres and the duration of the trip, etc. But contrarily to conventional transport modes where you know the cost of one trip in advance, the cost of a carpool run also depends on external events. It is possible to compute an estimation of the cost by computing the shortest path between the source and the destination and using an average speed for the vehicle, but if during the trip there is a traffic jam, or the highway is no more available for instance, the cost could be higher than what was initial planned. That is why the clearing house service must, on the one hand, implement a way to compensate such slight cost differences, and on the other hand, allocate gains and payment to the various actors of the system. The complexity of the task lies mainly in the fact that for the carpooling service to work, all the actors must find a way to subsidise and be fairly rewarded for the service provided. But since the value exchanged for a carpooling trip depends on a large number of parameters as described in the previous paragraph, there is no easy way to ensure that a specific business model will yield a sustainable revenue for each actor. One solution would be to define several value chain scenarios, considering several business model implementations, including flat rate fees or percentage based fee for instance, and evaluate those in the frame of a realistic simulation. The purpose of these scenarios would be two-fold. Firstly, they aim at demonstrating the good functioning of the system based on the previously mentioned actors while considering several value chain use cases. Secondly, they are used to prove that dynamic carpooling is a viable transport mode able to improve the quality of the road traffic in an urban context. To that extend, the improved NetLogo simulation tool allows testing some or all of the possible resulting business models by changing the parameters provided by each transaction, the threshold above which the compensation mechanism is triggered, etc. Thus, the simulation platform will have two different usages: one the one hand, it will help demonstrating the efficiency of the dynamic carpooling system and on the other hand, it will be a decision helping tool to facilitate negotiations between the actors involved in the resulting value chain. 6.3 Simulation results We established 15 scenarios with several parameters and we simulated them in both normal and ideal ways. Regarding the ideal trip, we have assumed no other cars in the map, and the absence of accidents. The rest of the conditions remained unchanged. In this context, we fixed the value of the amount of cars that belong to the system as the 50% of the total number of cars for each scenario. The maximum number of s inside a car was 3 and the probability of accident established was 1%. The size of the map and the distribution of the lanes was the same for all the simulations as well as the origin and destination of each car and. We consider the centre of a city, as a Manhattan-like scenario, with 2 km 2 km = 4 km 2. The main numbers obtained as results from the simulations are shown in Table 2. In the following figures, we present results of 15 experiments (represented in the x-axis) we have performed. Table 2 Simulation results for several combinations of input data (see online version for colours) N Number of cars Users Users served Users not served Ideal distance Normal distance Ideal time Normal time , , ,000 1,

11 Modelling and simulating a dynamic carpooling system for improving citizens mobility 219 In Figure 7, we can see a comparison among the users that are served and not served in each experiment. We see that when the proportion of the users vs. the number of cars increases, the number of not served users is increased too. It is important to note that, in the conditions we have evaluated the system, the number of users served never exceeds the 55%. This maximum is reached when the number of drivers is five times greater than the number of users waiting to be served, and when the 50% of cars belong to the carpooling system. Besides, the performance improves with the increasing of the population. In Figure 8, we present the ideal and normal time spent by the users to arrive to their destinations. We see that as we increase the number of cars in the city, the ideal and normal time differ more. The time spent during a trip by the user in normal conditions is increased on average a 6.6% with respect to the ideal situation, when the number of cars change from 300 to 500. When the number of cars is fixed as 1,000, the duration of the trip is increased a 43%. Figure 7 Figure 8 Users served and users not served (see online version for colours) Ideal and normal time (see online version for colours) In Figure 9, we present the ideal distance and the normal distance the cars cover. We see that as we increase the number of cars, the difference between the normal and ideal distance increases. This is because if there are more cars, there will be more accidents and traffic jams, so drivers will have to change their routes, which may not be the optimal ones. The distance covered during a trip by the user in normal conditions is increased on average an 8.4% with respect to the ideal situation, when the number of cars change from 300 to 500. When the number of cars is fixed as 1,000, the distance covered is increased a 4.5%. Figure 9 Ideal and normal distance (see online version for colours) Speaking about Figure 8 and Figure 9, the ideal estimation of the distance covered, and the time spent during the route are mostly the same, in normal conditions than in the ideal ones, for a low number of cars. The values start to differ when the number of cars is increased. If we think of a normal situation, the same thing occurs if we compare the traffic during the rush hour and during the night, so we have to estimate the suitable cost of the trip depending on the time of the day. The amount of users served in the scenario considered in this paper, despite never reaching a full coverage of all the possible carpooling demands, is quite high and demonstrates that our approach is a viable complement to conventional public transportation systems. Even this solution allows a fair number of user access to the carpooling system, it is not enough to allow such transport mode to be sufficient on its own, considering the conditions described here. However, our approach improves other existing carpooling frameworks (described in Section 2) where users are required to declare their trip long time in advance. Some steps remain to be taken to ensure the practical feasability of the dynamic carpooling system. The first one is that a base of confirmed planning should exist before the first dynamic request is answered: if no existing route or request is available at the time a dynamic request is received, there will not be any possibility to find a match for this request, so the waiting time of the requester will be unknown. Of course, the traveller has the possibility to take his own vehicle and consequently to become a driver being able to take s with him. This also implies that most of the first requesters will be assigned the driver role and then, as time goes by, more and more possible matches for s will be available. Moreover, we have plans to build a preliminary database of possible available rides by considering recurrent travellers, such as commuters, to get more fairness by balancing the usage of the car among frequent carpoolers. A second step is the inclusion of our dynamic carpooling system into a larger scale, considering a multimodal transport system as shown on Figure 7 in order to offer alternative solutions if no carpooling trip is found. Defining the precise conditions required for reaching an almost full coverage is however out of scope for this article,