Keywords

1 Introduction

In less than 50 years, the global urban population increased from 33 to 54%Footnote 1, making the economy of several countries concentrate in cities instead of being uniformly distributed. This drastically influenced the activity inside of the urban area, which highly impacts congestion, accidents and air pollution [1]. The most important source of exposure to pollution for humans is created by road vehicles and there already have been some attempts to estimate the impact of the pollution by changing from car to bicycle journeys [2]. Moreover, because of the high density of cities and the limited space that is available to parking, cars become an unsustainable mode of transportation [3] even if it can be more convenient in term of flexibility, celerity and comfort. In [4], it was showed that during the peak commuting hours, travel delays increased by 41%, making people more stressed in their life. Moreover, correlation was for example found between depression and traffic noise by analyzing a part of the population of Frankfurt international airport [5].

Cities are changing and urban planning became a new challenge for the world. In response to this, different tools like CityScope [6] developed by the CityScience group at MIT Media Lab were created in order to assist novel urban processes and help to visualize and understand complex urban data and interact with it by simulating modifications within the urban scenario. This type of tools help us to understand the urban impact of new technologies in our lives.

Modern cities attempt to flexibly integrate transportation options for residents and visitors to use buses, trains, taxis, bicycles and cars. They play an important role in the economy of the city and the quality of life of its residents. The inadequacy of traditional transportation models is proven by the growth of alternative and social initiatives aiming at a more flexible, customized and collective way of transport. To be collective, a mobility service should offer a way to organize teams of citizens that need to reach equal or closed destinations starting from different locations. In this context, new kinds of transportation are proposed to citizens like Mobility-on-Demand and ride-sharing transportation [7]. By using shared mobility, the notion of owning a car, using it for personal transportation and leaving it in a parking disappears and gives way to the notion of requesting and splitting a service only when it’s needed. A lot of different studies aimed to quantify the impact of car sharing on car ownership and \(CO_{2}\) emission [8, 9], proving that this mobility actually decreases the congestion and those emissions.

In order to go even further in the congestion reduction and the mobility paradigm change, new technologies like Autonomous Vehicles (AV) were proposed because they have the potential to impact on vehicle safety, travel behavior and flow distribution [10]. These vehicles are not totally accepted yet in urban areas because some modifications in the legislation are still needed [11], but new methods are currently investigated and developed to make these vehicles more efficient in data analyzing and decision making [12]. While the National Highway Traffic Safety Administration (NHTSA) statistics tell us that human error is the main reason of road crashes, AVs allows users to enjoy their mobility by reducing the time that they have to monitor the dangers of the road [13]. In an ideal world, it seems that this technology only needs time to be accepted as a regular mode of transportation as well as bus, tram or subway. However, despite all these advantages, some barriers still remain and are the major drag for citizens and users.

Despite the fact that personalized services can be proposed to users by analyzing their personal information, the question of data privacy is becoming more and more relevant with new technologies [14]. According to the literature, 20% of the world’s data was collected during this last couple of years [15] and people are starting to understand that these data actually have a real economic value [16]. Nowadays, the most common way to store and access this data is to use centralized databases [17]. However, this centralization encounters more and more issues. First, since the server is the entity that can provide the service, if it stops, the entire system will paralyze. The users will thus not be able to access to the service during the failure time. Second, there is the problem of data privacy. In most cases, all data remain unencrypted, therefore, the entity who has it in its possession can breach the privacy of users [18]. Finally, these databases can be easily modified at the server side, which means that the producers (i.e., users) of the data don’t have any control over it and don’t know how it is being used [19, 20].

One of the most promising technologies to tackle both problems of data centralization and privacy is blockchain. More than a mean for exchanging cryptocurrencies without intermediaries, blockchain technology is starting to introduce different methods in order to achieve a secure and accountable way to share data. For instance, [21] outlined a framework for sharing machine learning models between hospitals, [22] described a method to manage byzantine agents in a swarms of robots, [23] introduced a secure architecture for Internet of things (IoT), and [24] proposed a scoring protocol for autonomous systems to increase their reputation. Complementarily, the urban mobility and smart cities fields are also paying an increasing amount of attention to this evolution. In fact, in order to achieve efficient urban mobility models and smarter cities data needs to be collected and processed to improve urban processes. This concern has driven recent works where the problem of communication among AVs was explored [25], by using a blockchain-based solution.

In response to these concerns, this work addresses the use of blockchain in the urban mobility and smart cities fields by proposing a data-sharing framework among different agents based on smart contracts. BASIC (Blockchained Agent-based SImulator for Cities) aims to combine an agent-based simulator with blockchain technology in order to conduct research on urban scenarios where data are involved and needs to securely shared. The potential of this framework is illustrated in a car-sharing service where a non-negligible number of personal data is usually collected about users with the current proposed applications. The following sections are structured as follow. Section 2 describes background notions of the simulator and the blockchain technologies used in the framework proposed. Section 3 presents the architecture of the framework and the different parts involved in it and how they interact together. Section 4 describes the results of using the proposed tool in a car-sharing scenario. Finally, Sect. 5 concludes this paper with the discussion and the future work of this simulator.

2 Background

2.1 Car-Sharing Scenario

Today, a new kind of mobility is emerging, with the aim of making our city smarter and more connected. Congestion control, autonomy of users, environmental impact and reduction of accidents are several reasons that motivate the use of Autonomous Vehicles (AVs) in urban areas. However, this new kind of mobility needs to be protected, controlled, and managed. For this purpose, we tested BASIC in a car-sharing scenario in the city of Cambridge (MA, USA), where simulated users and AVs interact. When users need to move around the city, they can request an AV, then, the system forms a group, sends the correspondent AV to users’ pick-up points and finally drops them off. BASIC adds a blockchain component to achieve a secure data-sharing approach between users and AVs. BASIC should thus be able to support that kind of infrastructure and should also be stable when the number of AVs and users increase. Finally, all AVs and users have to be connected in order to avoid desynchronization issues.

2.2 Agent-Based Simulation

BASIC is based on a generic existing ABM model [26] design to be easily customized for more specific applications [27]. The ABM model is developed using Gama Platform [28]Footnote 2. GAMA allows to model and simulate spatially explicit agent-based simulations where real-world maps, streets, buildings, etc. are integrated by using GIS data. Moreover, different types of agents can be programmed each one with their own behavior and attributes. The behavior of each agent is supported by functions, which can represent reflexes (automatically called every step) or actions (executed when another part of the code calls it). To realize the motivating scenario, two agent species were coded. First, users were developed in order to recreate the daily activity of citizens moving from one starting location to a certain destination. Second, AVs were developed in order to wander around the urban area and fulfill the car-sharing application. The behavior of both species is explained with more details in Sect. 3.1.

2.3 Blockchain and Smart Contracts

The most famous application of blockchain is BitcoinFootnote 3. Bitcoin is a cryptocurrency introduced in 2008 and the idea behind it is to create a new way to make transactions between peers without a third party in a transparent and secure way. In order to send a transaction from one user to another, a peer-to-peer network is used, which allows to delete the central unit from the process.

The blockchain can be seen as a incorruptible ledger of transactions that is decentralized since the information held on it is duplicated in each one of the different computers (nodes) of the peer-to-peer network. In order to add transactions in the blockchain, every nodes must verify and validate the content of the block. This technology allows thus to create trust between agents who don’t trust in each other. Each block is composed by transactions. In each transaction, we can find the sender, the receiver, the amount but also additional information can be added. Transactions are made from one address to another. Only nodes with access to the private key of the corresponding address can make a transaction from this address (in other words, if you don’t have the secret key of the address A, you will not be able to send a transaction from address A). In addition to transactions, each block contains information about previous blocks. Blocks are thus linked in a chain. Therefore, if the content of the previous block changes (for example, if someone tries to attack the system by modifying a block), the value of this information will also change and will create an inconsistency in the blockchain. For this reason, when something is written in the blockchain, it is very difficult to modify it.

A genesis blockFootnote 4 is created as the starting point of the configuration of the chain. With this block for instance, it is possible to initialize accounts with some amount of cryptocurrency inside. This method is useful to generate tokens in the system, and can only be used when the blockchain system is in the design phase. A second way to generate tokens in the system is mining. In order to validate blocks in the blockchain, the content of the block must be first verified. This is the role of miners. Miners are nodes of the network. The goal of them, as we just said previously, is to verify and add blocks at the end of the blockchain. To do so, they have to compete with each other. In fact, in order to validate a block, a computational problem needs first to be solved by miners. The first miner who solves it is considered the winner and can add his block at the end of the blockchain. When a miner succeeds, he is rewarded with a certain amount of cryptocurrency (EtherFootnote 5 in case of using the Ethereum blockchain).

Fig. 1.
figure 1

Smart contract used when a user needs an AV.

Full size image

In our approach, the EthereumFootnote 6 blockchain is used. The ethereum platform provides the additional capability of deploying smart contractsFootnote 7 in the blockchain. The advantage of smart contracts is that Turing-complete code can be added to the blockchain. Due to this functionality, more elaborated and autonomous operations beyond sending and receiving transactions are possible. A smart contract can be seen as a digital contract with rules and conditions. This code is thus composed by variables and functions and is deployed within a certain address in the blockchain. Each node of the network has the possibility to interact with the smart contract in a peer-to-peer way. First, interacting with the contract implies to call one of its functions. However, such operation is costly since the user needs to register a transaction in the blockchain. Second, when interacting with the smart contract the content of this interaction stays secret and it is held by the smart contract, however, the proof that this interaction took place is stored in the blockchain and remains public to its participants. Figure 1 shows a portion of a smart contract, implemented in each AV. It is composed by two main functions: addTransactionInfo, used to add info related to the user that needs an AV, and addEndHour, used to add the end hour of the journey when the user reaches her/his destination.

In this research, the ethereum network was simulated by using DockerFootnote 8. Docker provides container-based virtualization and allows to build networks of agents running specific software in an easy way. The code used to build the containers and the simulations described in this research is publicly available in the following github repositoryFootnote 9.

Fig. 2.
figure 2

Multilayer decomposition of BASIC (from bottom to top). First, the data layer represents the actual data used in order to simulate a realistic urban scenario (population information, GIS files, etc). With these data, we were able to build the second layer; the simulation layer was implemented using GAMA which provided different agents such as AVs and users. Third, the blockchain layer creates the infrastructure for the data management in the system. Four, the planner layer aims to guide the system by helping the routing and decision making processes. Finally, the analysis layer sheds some light about the feasibility of the proposed approach.

Full size image

3 The BASIC Architecture

In order to provide a modular framework that can be customized for different urban applications, BASIC’s architecture has been specified and is composed by different layers, defined one above the other. A graphical representation of this stack is shown in Fig. 2. In the following sections we give a description of each layer with the aim of giving details on how the BASIC framework works.

3.1 Data and Simulation Layers

The Data Layer of the BASIC architecture has the objective of creating a virtual environment that replicates a realistic urban scenario.

Fig. 3.
figure 3

Simulation of AVs (green triangles) and users (blue dots) in the Kendall urban area, in Cambridge (MA, USA). Two zones are depicted: the residential zone (A) where users live and the working zone (B) where users work. The number of users and AVs were adjusted in the image in order to increase readability. (Color figure online)

Full size image

The Simulation Layer is an extension of the CityScope framework proposed in [26] where buildings, roads and citizens have been already modeled and formed the starting point of our simulations. GIS files have been used in order to replicate the environment and allow us to have a representation of the Kendall area in Cambridge (MA, USA). On top of this, two types of agents have been specified:

Users. These agents represent citizens of the Kendall area. In this simulation, a simple behavior was implemented (see the User Model in Fig. 5). Each user is assigned to a residential (A) and a working (B) zone (see Fig. 3). The only possibility for the user to go between these two zones is to use an AV. All users are located in zone A when the simulation starts. Then, during the morning hours (i.e., 6–9 AM), at a random point in time, they go to work. After this, during the afternoon hours (i.e., 5–8 PM), at a random point in time, all users leave the working zone to return to the residential zone.

Fig. 4.
figure 4

Process flow of a request of a AV from a user. The starting point is the agent-based simulation. When a user needs an AVs, a transaction is created and sent to the Docker container trough a Python interface. Finally, the container will interact with the blockchain in order to add the transaction in it.

Full size image
Fig. 5.
figure 5

User model.

Full size image

Autonomous Vehicles (AVs). The second class of agents of this system are autonomous vehicles. The unique role of them is to respond to the request of users around the city. Initially, they wander around the map performing a random walk until they receive a user request (see the AV Model in Fig. 6).

As mentioned previously, two types of zones are represented in the simulation. First, we can identify a residential zone (zone [A] in Fig. 3). This zone is composed by houses and apartments. In contrast, the working zone (zone [B] Fig. 3) is composed of company offices and educational institutions.

Fig. 6.
figure 6

Autonomous Vehicle (AV) model.

Full size image

3.2 Blockchain Layer

This section explains how the blockchain layer is built and how it interacts with its previous layer. Figure 4 represents this connection that we describe in the following steps:

  1. 1

    Agent-based simulation. This simulation is composed by AVs and users. Each AV is associated to a mining node in the network and deploys its own smart contract (as shown in Fig. 1). Each user is associated to a wallet in the blockchain with a certain amount of ether pre-filled.

  2. 2

    Order of an AV. When it’s time to move from home to work (or vice-versa), the user needs to order a AV. Due to the interaction with the car-sharing algorithm explained in the next section, a AV is assigned to the user.

  3. 3

    Sending request to the Python server. First, a TCP connection is made between GAMA and a Python script. Each user is connected to this code which acts as a client interface. This script acts as an interface between the simulation internals and an external system such as the blockchain. Finally, when an AV is assigned to the user (output of step 2), the same user sends a message through this interface with the address of the smart contract to query (i.e., the one of the requested AV).

  4. 4

    Connection to the Docker Container. To connect with docker, a Docker APIFootnote 10 is used for the Python language. By using this API, we developed a Python client connected to Docker. Due to this connection, it is possible to enter inside the container and launch code (i.e. script for deploying or querying a contract). For the purpose of this work, we deployed a private blockchain composed of a network docker nodes. Each nodes is associated to one AV and runs geth inside.

  5. 5

    Adding the transaction in the Blockchain. The last step of the workflow is to add the transaction in the blockchain. To this end, the web3-eth JavaScript APIFootnote 11 is used. This API allows to run gethFootnote 12 commands inside of a JavaScript script, which is useful in order to interface with ethereum nodes inside the Docker container (as explained at step 4). By using the Javascript API and a network of interconnected geth nodes, the transaction can thus be sent and added to the network.

Fig. 7.
figure 7

Workflow of the planner layer. Step 1 consists to change the internal state of the user. By changing this variable, the system knows that this specific user needs an AV. Step 2 is the grouping phase. A car-sharing algorithm will take into account all users that need an AV in order to make groups. Finally, step 3 is route operation phase. Now that a group is formed, the assigned AV is sent to this group in order to pick users up and drop them off.

Full size image

3.3 Planner Layer

As mentioned before, the planner layer aims to coordinate the fleet of AVs in order to pick up and drop off users. For this purpose, a simple car-sharing model that aggregates users into groups is depicted in Fig. 7.

This algorithm is composed of 3 main steps:

  1. 1

    Modification of the internal state of users. In the simulation, each user has a variable which is modified when he/she needs to move. Thus, when a user needs an AV, he/she will change the value of this variable first. This change of internal state takes place at a random point in time during the morning/afternoon shifts explained in Sect. 3.1.

    figure a
  2. 2

    Formation of a group. The next step is the creation of groups. This process is described in Algorithm 1. In line 1, we can see that this algorithm is executed for each user with a changed state (the state is changed when a user needs an AV). A group will be assigned to this user and the idea is to add other users in this group. To do so, the block (from line 5 to 12) is executed. However, there are two conditions for the execution of this part. First, a limit of time is expressed in line 5. In fact, if a user is looking for a group but no one fits in this group, he will be able to take an AV. Second, when the group is composed of more than one user (the initial one), there is no need to execute again this loop.

    Inside this block, the formation of a group is done as follows: Every other users will be taken into account (as shown in line 6), and if he meets some condition, he is added to the group. These users need to be within a threshold distance (ThresholdStart) from each other. Moreover, these user’s destinations need to be in a place within a certain distance (ThresholdStop) from each other. This is represented in line 7.

  3. 3

    Route Operation. If the conditions are met, a group is formed and the closest AV is assigned to the group. This AV picks up and drops off users by always going to the closest stop. If it is not possible to form a group, a maximum waiting time (line 5) was included to prevent lockout periods. If, after this time, the algorithm doesn’t find any group, an AV is assigned to a single user as it was explained before.

4 Experiment, Results and Analysis

This section describes the last layer of the BASIC system architecture: the Analysis Layer. As described previously, during the experimental phase of this framework, the feasibility of the integration of blockchain in urban scenario was tested by implementing a car-sharing model. This model focused on the population that uses car and ride-sharing to go work. Some parameters were fixed during the experiments and are explained below:

  • Number of AVs. In our system, the number of vehicles available in the city was fixed at ten. Because each car is a node of the blockchain network, we have thus ten mining nodes in the system. The first idea was to test the tool and its feasibility with a small amount of AVs. After doing that, extrapolations will be used to draw conclusions about the scalability of the system.

  • Period of time. During these experiments, we analyze the behaviour of the simulation representing seven days (one week). Each day is the same and the agents have the same behaviour (i.e., go to work and go back home).

  • Distance thresholds for the grouping phase. During the grouping phase, the distance between starting points of users was fixed to one kilometer. The exact same value was fixed for the ending points of users.

  • Maximum waiting time. During the grouping phase, it was decided to put a limit on the time that a user can spend for finding a group. This limit was fixed at 15 min.

  • Difficulty of the blockchain. The difficulty fixes the time needed to mine a block and therefore include new transactions. A too high difficulty value could provoke a slow-down of the system while a too low difficulty value might impact the security of the system. Therefore, in the experiments conducted in the research, we decided to fix the difficulty level.

  • Gas used. When a transaction is made in the blockchain, it implies to pay a fee for the miner. Each user can choose the fee he/she would like to pay for the transaction by tuning the gas parameter. If the user selects a high value for the gas, the transaction will be mined faster. On the contrary, when the value of gas is low, it might take more time for the transaction to be mined. In this case, the gas was fixed at 25000000 for all transactions. This value remained fixed throughout the experiments.

  • Genesis block. In order to initialize the blockchain, a genesis block was created. This genesis block contains accounts that were pre-filled with Ether. For the experiments described in this work, ten accounts were initially created and filled up with twenty Ether.

Fig. 8.
figure 8

Amount of memory needed for one AV (node) after seven days of operation in relation to the number of users in the simulation.

Full size image

By using a blockchain solution for storing data, we know that a full copy of the ledger is kept in all nodes (AVs). It is important to note that, even though, recent literature suggests that storing data directly into the blockchain might impact the scalability of the system leading to bloat [29], the aim of our experiments is to analyze how much memory is needed in each AV according to the number of users in the simulation and whether a realistic projection of these requirements might exceed current state-of-the-art specifications in the AV field.

Figure 8 shows the amount of memory needed per node (AV) in relation to the number of users active in the simulation. During this test, the number of users was increased from one to twenty. This allowed us to see the evolution of the memory needed per AV. Let’s remember that, each day, users need an AV to go to work in the morning, and to come back home during the afternoon. The AV is thus requested two times per day per user. The maximum number of users in an AV is fixed at five, which also correlated to the maximum capacity for user groups introduced in the previous section. According to Fig. 8, when the number of users increase, the size of the blockchain also increases. This phenomenon can be explained by the fact that the size of the blockchain is proportional to the number of transactions. If more users are present in the system, more users will need to travel and thus, more transactions will be created. Let’s remember that the only way for users to move, is to use car-sharing. Everyday, each user needs two AVs. However, each request for having an AV corresponds to two transactions. The first transaction represents the request itself. Each user queries the AV by providing all the needed information like the starting and destination points, user address (public key), hour, etc. When the drive is completed, there is the second transaction. The second transaction aims to validate the drive by adding the ending hour when the user finally arrived at his destination point. In conclusion, because users need to travel two times each day, four transactions are added per user per day.

Let’s now analyze the memory needed for such a system. As we can see in Fig. 9, after seven days, the size of the blockchain for this system when there is 20 users is 5.1 MB. This amount of data will be stored in each AV. By using this information, we can extrapolate what will be the size of the blockchain after a year. After 52  weeks, by making the assumption that this growth will be linear, the size will be around 265 MB. Due to previous research [6], the population in the Kendall area was roughly estimated to 10.000 people. Moreover, in 2016, 3.5% of the population in Cambridge (where Kendall belongs to) used carpooling as method of travelFootnote 13. By using this, we can estimate the number of carpoolers to 350. By making the same linear assumption than before and by considering these 350 citizens, the amount of needed memory is thus 4641 MB (4.641 GB). Today, storing that amount of data in an AV is feasible according to current AV specifications.

5 Discussion and Future Work

During this work, we tested the feasibility of the combination between blockchain, agent-based modelling, and urban mobility by proposing a tool named BASIC. This tool was validated by implementing a car-sharing simulation within the city of Cambridge (MA, USA). The blockchain component was introduced in our work to store and share data among a distributed system of AVs and users in order to avoid a centralized controlling entity. First, this study suggests that the memory needed for each AV increased when the number of users increased. However, the simulation process was feasible and fully operational with 30 agents (20 users and 10 cars).

Fig. 9.
figure 9

Extrapolation of the memory needed for one AV (node) with 20 users.

Full size image

Today, mobility in urban areas is still a big challenge and it remains complicated to test new infrastructures in real life. Due to BASIC, it is now possible to simulate different kinds of urban scenarios where agents interact with a blockchain layer. In the future, other implementation works are possible in order to increase the performance of the system. Improving the car-sharing algorithm is a first idea and will allow to have less cars in the city. The impact on the traffic will also be an interesting feature to analyze in this case. Since this research suggests that storing the data in a decentralized way is feasible, continuing with the idea of data privacy is an interesting direction to make citizens control their own data. Along those lines, people are realizing the real economic value of their data. Allowing them (by using the smart contract technology for example) to choose who can see this information, for how long, and for what purposes, can be another interesting next step that can be implemented by using BASIC. Finally, since a modern city needs to flexibly integrate transportation options including different means (i.e., cars, buses, trains, taxis, and bicycles), the combinatorial complexity of all these possibilities negates the options of a single monolithic control system. How would a grouping, or ensemble of hierarchies perform in this situation? In the near future, we want to extend our approach to deal with Collective Adaptive Systems (CAS) [30]Footnote 14 able to emerge and continuous adapt in a changing environment.