Smart, Distributed Cyber-physical Systems for Transportation K. Shankari December 18, 2013

1

Introduction

Station Station Status

Transportation systems are increasingly deployed with integrated sensors, effectively making them cyber-physical systems, with sensors and actuators. There has been a lot of work in the area of building real time systems to control motorized vehicles such as cars and planes. However, in an era where GreenHouse Gas (GHG) emissions are a growing concern, there is a need to consider what cyber-physical systems for nonmotorized transport would look like. In this case, since we are not aiming for the kind of real-time control that is required for motorized vehicles, techniques from general operating systems or distributed systems are sufficient. We could use the techniques for short-term control (on the timescale of minutes rather than microseconds), and for longer-term planning. To shed light on issues and potential solutions involved in building such systems, we would like to investigate the control of bikesharing systems. In bicycle sharing, bicycles are locked to fixed docks deployed at various locations. Patrons arrive at the dock and unlock bicycles which they can ride for 30 minutes without additional fees. Before the 30 minutes are up, they need to find an unused dock near their destination and return the bicycle. There are sensors in the docks which detect which bicycle(s) are stored in them. However, a persistent problem with bike sharing systems is that of imbalanced demand. This imbalanced demand leads to situations in which stations are empty and have no bikes, or are full and have no slots. This leads to frustration among users and hinders adoption of the system since it is perceived as unreliable. Bike share systems already implement an OLTP system to track bike and station status. A list of the relevant information tracked in the Boston Hubway bikeshare system is shown in Table 1. Note that the capacity is a property of the station status and

Trip

Latitude/Longitude Normal/locked/temporary Number of bikes Number of slots Capacity Origin Destination Start End Bike number

Table 1: Selected data tracked by Hubway

not the station, since it sometimes changes even after setup. Bike share operators typically use this status information to rebalance bicycles between stations. This is typically done using trucks equipped to carry large number of bicycles (20 - 62) [SHvH13, 19] [CMP+ 13, 2], although some systems are beginning to use trailers that are pulled by other bicycles. The rebalancing decisions are sometimes performed by the drivers based on their intuition, and are sometimes based on static routes determined by the bikeshare operator ahead of time [Fou12, 28-29]. Some bikeshare operators think of the static routes like a public transit route - the route is predetermined, and is too complex to leave to the discretion of the driver (Justin Ginsburgh, General Manager, NYC Bike Share, personal communication, Nov 5th, 2012). However, the route can be modified/augmented if necessary when special events occur.

2

Related work

We have three main contributions in this paper: 1. We map the bike sharing rebalancing problem into a resource load balancing problem, and identify the areas where the mapping is inexact. We 1

Citation [RTF13]

Rebal Type Static

Technique MIP (LP)

[SCL+ 13]

Static

MIP (LP)

[RHRHP13]

Static

[SHvH13]

Static

MIP (greedy, max flow, LP) MIP (CP)

[CMR12]

Dynamic

[CMP+ 13]

Dynamic

[PL13]

User-based

MIP (LP, column generation + benders decomposition) Heuristics, with and without forecast Game theoretic

Demand assumptions non-homogenous poisson processes for arrivals and departures at every station. poisson process for trips between pairs of stations. assume all rides can be completed within a single time period. problem is intractable if not. poisson process with demand based on 8 random time points. time-independent poisson processes. “while some users arrive simultaneously, we assume that this effect is negligible”. . . , assume that user behaviour during observation is stationary. . . exact MIPs for vehicle routing problems are intractable for realistic instances, so model a clustering problem as a MIP. randomly generated using a number generated between 1 and 5, scaled using station-specific constants.

poisson process for arrival rates, constant travel time between every pair of stations None - Motivates problem and proposes a graphical user interface (GUI) to display economic incentives to the user.

Table 2: Summary of prior work also define evaluation metrics that we propose to Our focus in this paper is on dynamic rebalancuse. ing, while most of the prior work has been on static rebalancing. More importantly, the related work fo2. We identify various solution components based cuses on the problem formulation and the algorithmic on the mapping and propose a system architec- techniques for rebalancing but does not discuss how ture. these algorithms could be integrated into a system that would gather the data, run the algorithms and 3. We implement a greedy bin-packing algorithm generate results. A summary of the prior algorithmic for dynamic load balancing, and use trace based work is shown in Table 2. simulation to evaluate it against the existing reThe closest work to our own is [CMP+ 13] which balancing from the Boston Hubway dataset. uses discrete event simulation to explore dynamic The bikeshare rebalancing problem is relatively rebalancing. The primary differences between their new and is only recently beginning to be studied in work and ours are: depth. The related work so far has focused on determining a mathematical representation, typically by extending an existing vehicle routing problem, and solving it using integer programming techniques. The demand is typically modelled as a pair of poisson processes for arrivals and departures. The related work also classifies the rebalancing problem into: • static rebalancing, which occurs during times where the user demand is negligible, and • dynamic rebalancing, which occurs during times when the user demand is high

1. we motivate an alternate formulation of the problem; 2. we propose a system architecture and provide initial implementations of most parts; 3. we use a trace based simulation to exercise this architecture instead of making assumptions about arrival rates; 4. we use high and low water marks, which avoids flip flopping around a single boundary; 5. our simulation runs for one month instead of three hours; 6. we adjust our algorithm to address real world 2

issues like varying capacities, and shortages in several adjacent stations; and 7. we are able to show that our algorithm is slightly better than the existing rebalancing technique. We include [PL13] to give a flavor of the other approaches possible, but do not plan to explore them in this paper.

3

Resource Allocation

Computer systems have a long history of providing resources to users, even in the face of imbalanced demand. While load balancing can be done at the time that the resources are initially requested, it can also be done later by using process migration. This leads us to a fairly natural mapping from the Figure 1: Taxonomy of the various approaches Bikeshare Rebalancing Problem to the Load Balanc- from [CK88] ing Problem. Rider 7→ Task checkpointing steps, the communication medium Bike 7→ Resource is assumed to be always available. In the bikeBike check out 7→ Resource allocation share case, however, although the migration is simple, it can only be performed when the comBike rebalancing 7→ Process migration munication medium, viz. the truck, is available. Rebalance cost 7→ Migration cost This needs to be factored into the migration cost. As we can see, although the current bikeshare literThere is large body of literature, accumulated over the course of several decades, on algorithms for dy- ature focuses on Mixed Integer Programming (MIP) namic load balancing. A taxonomy of the various solutions, it is possible to consider approaches other approaches, first formulated in [CK88], is shown in than mathematical programming. In addition, it is Fig. 1. As we can see, the dynamic bike share problem possible to have characteristics that can potentially needs a global, dynamic, physically distributed, be added on to any of the nodes in the taxonomy. These characteristics are: 1. adaptive; 2. load balco-operative algorithm. However, the mapping is not exact in the areas ancing; 3. bidding; 4. probablistic; and 5. one time shown below, so existing algorithms may need to be versus dynamic reassignment. For the bike share case, we need load balancing and modified to fit the new problem definition. 1. No pre-emption: We cannot interrupt ongoing dynamic reassignment, but adaptive, bidding/voting and probablistic variants can all be evaluated as well. trips and swap them for a different bike. 2. Migration steps are simple: We are not migrating resources that are actively in use - we 3.1 Evaluation Metrics are migrating resources that are currently unused. This means that a lot of the complexity of In order to evaluate the various potential algorithms, the migration can be simplified. we need to define evaluation metrics. Most of the ex3. Distributed initial assignment: Resource re- isting literature is based on poisson trip distributions, quests are not made to a central controller which and so defines the service level requirements in terms distributes them evenly across the available re- of the number of trips. For example,[SHvH13, 5] uses sources. Instead, the tasks allocate resources di- the ratio of satisfied pickups (or returns) to the total rectly to themselves. number of pickups (or returns). 4. Rebalancing resources are non uniform: However, this has two limitations: For classic process migration, it is possible to mi1. The metric is based on predicted rather than obgrate resources at any time from one host to anserved values, since the data collected by the sysother. While the migration may involve various 3

tem does not include the number of unsatisfied trips. 2. It gives imbalance at times of high demand greater weight than imbalance at times of low demand. However, in order to be an effective automobile substitute, bike shares need to be available at times of low demand as well. This is because the cost of a missed trip at night is likely to be higher than the cost of a missed trip during commute hours - during commute hours, riders can fall back to alternate modes of transportation, but after commute hours, when the other transport options are also unavailable, the lack of a bicycle is likely to be a severe disadvantage.

Figure 2: Number of bikes at ”Summer St/Arch St” from Sun Sep 2, 2012 19:00 to Mon 09:00 with and without rebalancing. Rebalancing gives higher availability by using higher rebalance overhead

4

System Architecture

The proposed system architecture to make the distributed scheduler available as a service is shown in Fig. 3, and the components are described here.

Therefore, we propose alternate metrics that are inspired by the service level requirements of computer systems - station and system availability. X stb0 = (time|number of bikes = 0) (1)

sts0 =

X

(time|number of empty slots = 0)

unavailstation =

stb0 + sts0 timetotal

(2) (3)

availstation = 1 − unavailstation

(4)

availsystem = min (availstation )

(5)

stations

Note that this is consistent with the terminology on the rider-maintained Villo site, with the slight difference that they declare that a station is unavailable if it has one bike (or slot), instead of zero. With rebalancing, higher availability is obtained by paying a rebalancing cost. Unfortunately, current bikeshare systems only track the number of bicycles rebalanced per day. This does not take into account the time or distance travelled for the rebalancing. Introducing either of those metrics would again introduce predicted values into the evaluation. Therefore, we report two metrics for rebalance overhead. rebalbike count =

X

Figure 3: Complete system architecture for the distributed scheduler. yellow = initial implementation, red = not implemented, green = implemented externally 1. Stations: The stations have sensors which can detect the presence or absence of bikes in slots. They also have controls that allow riders to unlock bikes, pay for temporary memberships, and request additional time to return. Riders interact with stations to pick up and drop off bikes. 2. Online Transaction Processing (OLTP): The station data is periodically sent to an OLTP system that publishes the number of full and empty slots, and matches up arrival and departure information for the same bike to generate trip information.

(number of bikes moved) (6)

rebal

rebaltime =

X

(tmove + tload + tunload )

(7)

rebal

A visual representation of these metrics in the real world data is shown in Fig. 2.

3. Recommendation Service: The bikeshare scheduler exposes a recommendation service for 4

use by the rebalancer. The service exposes two queries - getMoveReco and getBikeChangeReco, both of which return recommendations that the rebalancer should follow. This two stage process gives us the flexibility to base the bike change recommendation on the most recent state if that works better with our algorithm. 4. Analytics Service: This will be a service available to the bikeshare operator that will allow them to perform offline analysis on station capacity planning or alternate rebalancing schemes. Figure 5: Scheduler Components from [MDP+ 00, 250] Since the bike share service is one of our primary contributions, we now focus on the details of its implementation. A more detailed service diagram is are physical resources. In the cyber domain, we available in Fig. 4. can implement a route generator, and an estimator for the rebalance cost given the route. Since the rebaltime depends on the traffic if the rebalancing is done by a van, this can call out to traffic estimation services such as google maps. 3. Distributed Scheduling Policies: This is the most complex part of the system. It currently consists of modules that estimate the demand and that detect imbalance. In addition, we can reuse the rebalance cost estimator here, since we may not want to schedule a rebalance if we can predict that the rebalance time will be longer than the peak demand time.

5

Simulation and Results

Figure 4: Architecture for the distributed scheduler. [CP95] describes three main approaches to evaluate red = not implemented, green = implemented distributed schedulers: 1. building a prototype implementation; 2. performing an theoretical analysis Some of the key components in designing a disusing queuing models and Markov chain models; and tributed scheduler are described in Figure 5, which is 3. building a simulator. + reproduced from [MDP 00, 250]. Here, we elaborate [CP95] argue for using a simulator because the cost on how they are addressed in our system. of building a prototype implementation may be high, 1. Load Information Management: In our and the theoretical analysis may have to make a lot of case, the bike share OLTP system already col- simplifying assumptions to keep the models tractable. lects the data required. So we just implement a In our case, since we have a real world dataset from data collector component that periodically pulls Boston Hubway available, we chose to use trace based information from the OLTP system and dumps simulation, which does not require a lot of simplifying assumptions, and which allows us to make progress it into HDFS. towards a prototype implementation as well. We have implemented fairly simple versions of the 2. Migration mechanism: The migration mechanism for this system is largely in the physical various components, for use as a proof of concept. We domain since the resources that are being moved plan to extend these with more sophisticated versions 5

Given this distribution of trips, we may expect that in the future. We also present the motivation behind the initial implementation, and discuss some of the most imbalance occurs within a 3 mile radius, and most rebalancing also needs to occur within the same planned enhancements for each component. radius. For dynamic rebalances between stations that are less than 3 miles apart, it is not clear that we need 5.1 Current Implementations to calculate a route between the stations. Instead, we may be able to move directly between a pair of im5.1.1 Demand Estimator balanced stations and address the imbalance quickly. Most of the prior work assumes that the demand fol- We found that this point-to-point behavior was espelows a poisson distribution or distributions with a cially useful when stations were already unavailable stable inter-arrival time. However, as we can see from and needed to be handled quickly. Figure 6, the trip distribution, even at the same staFor this evaluation, we used k-means to cluster the tion, varies significantly with the time of the day. stations into 3 groups based on distance. We picked 3 groups because the real world Boston Hubway system appears to use 3 trucks[SHvH13, 19]. We then ran the rebalance algorithm separately on each group. It is very possible that this grouping could lead to cases in which all the stations in a given local group had similar imbalance profiles. In this case, we need to do hierarchical, crosscluster scheduling to rebalance across groups. This should definitely take routing into account, but the problem is much more tractable since we can assume that the number of groups will be small. This is similar in spirit to the Neighbourhood Search Figure 6: Probability distribution functions for the schemes in [RHRHP13] and the clustering scheme departures from station 22 (South Station) at various in [SHvH13]. times of the day 5.1.3 Therefore, we estimate the departure (or arrival) demand by using the PDF of the trips departing (or arriving) at that station in the past hour. Another option is to consider the historical demand of this station in prior weeks, or to consider the historical demand of stations with similar demand profiles. 5.1.2

Imbalance detection

We wanted an imbalance detector that would be: 1. stable across small variations in number of bikes; 2. able to deal with the fact that stations have different capacities; and 3. easy to implement. So we chose to use configurable high and low water marks, as a percentage of the total capacity. If a station has more bikes than its high water mark, it has an excess of bikes, and if it has fewer bikes than its low water mark, it has a shortage of bikes.

Route generator

Our original plan was to use jspirit to implement the unpaired Vehicle Routing Problem with Pickups and Dropoffs (VRPPD) for the imbalanced nodes. However, as seen in Figure 7, most of the trips are under 3 miles in length. This is intuitive, because bike shares are intended for short trips (the “last mile problem”) and the cost structure is structured accordingly.

5.1.4

Rebalance time estimator

The current rebalance time estimator simply asssumes that it is the time to cover the distance between the stations using the equirectangular approximation at a constant speed of 30 kmph (18 mph). We assume that the slower speed will help account for some of the traffic considerations. However, when we tested this, we found that the distances between stations that we were rebalancing Figure 7: Probability distribution function for the were so small that some rebalance times were only trip length 1 minute. So we add a constant time of 4 minutes 6

to every rebalance to cover the startup time, and the tor or rebalance cost estimator modules. However, bike drop off and pick up times. This is definitely an as we can see, the simple algorithm had be modified to fit the problem through the addition of a truck area that could use a much richer model. state, and through prioritizing the handling of full Input: S = set of stations in the system. Current state of and empty stations. every s ∈ S Output: algoState, which would be used to store the computed route, for example sn = the next station to move the rebalance vehicle to OR tbreak the time to take a break until the next rebalance shift starts

5.2

Simulator Considerations

Although we had large amounts of raw data available, and it covered both the station status information and the trip information, we still had to clean the data before it could be used for simulation. The main focus of the cleaning was during time periods where stations were unavailable in the data provided. This means that the record of the number of trips at that station is not accurate. We also simulated the application of trips, and the detection of rebalances in the real-world dataset.

if currT ime 6∈ ( config.rebalStart, config.rebalEnd) then tbreak ← time until config.rebalStart else calculate currEmpty, currFull, aboveHWM, belowLWM, balancedStations; if |aboveHWM| > 0 ∨ |belowLWM| > 0 then nextStation ← getNextStation; if ∃nextStation then sn ← nextStation else Too much local imbalance tbreak ← 15 ∗ M IN else Everything is balanced tbreak ← 15 ∗ M IN def getNextStation ( currEmpty, currFull, aboveHWM, belowLWM, balancedStations) is truckState ← getTruckState; Handle full and empty stations first; emptyFullResult = if |currEmpty| > 0 ∨ |currFull| > 0 then switch truckState do case balanced getStationWithMinDist (currEmpty + currFull, ∅); case pick up getStationWithMinDist (currFull, ∅); case drop off getStationWithMinDist (currEmpty, ∅); if ∃ emptyFullResult then return emptyFullResult else No unavailable bikes, so try to balance switch truckState do case balanced getStationWithMinDist (aboveHWM + belowLWM, balancedStations); case pick up getStationWithMinDist (aboveHWM, balancedStations); case drop off getStationWithMinDist (belowLWM, balancedStations); def getStationWithMinDist ( imbalancedStations, balancedStations) is if |imbalancedStations| > 0 then return closest imbalanced station else if |balancedStations| > 0 then return closest balanced station else e.g. truck is full, and all stations are above HWM return ∅

Figure 8: Sensitivity of the availability to changes in the probability that a rider will retry a missed/unreturnable trip (0/0.5/1.0)

5.2.1

Function getMoveReco(config, algoState, currStationState)

Inserting missing trips

Consider a scenario where the bike departure rate is fairly high (2/10 mins). This causes the number of bikes at station s1 to go to zero at time t1 , and to stay at zero until time t2 . Let us further assume that our 5.1.5 Rebalance algorithm algorithm generates the appropriate moves so that The rebalance algorithm is a simple greedy bin- s1 has 2 bikes at t1 . If we just use the trips that packing algorithm that was intended as a proof of were present in the dataset, we would assume that s1 concept to verify the end to end operation of the sys- had 2 bikes from t1 to t2 and so its availability was −t1 tem. It does not currently use the demand estima- increased by tt2total . 7

station in the same interval. If the two don’t match, then a rebalance occured. This gives us information about the times of day when rebalances occured, and the number of bikes in each rebalance. However, it does not give us information on how the rebalances are linked - we can see Figure 9: Number of stations within 300m of every that 5 bikes were dropped off at station 22, but we station don’t know that 3 of them came from station 35 and 2 of them came from station 46. This means that we are unable to calculate the rebaltime for real world However, the departure rate at time t1 is 2/10 rebalances. mins. So, barring additional rebalances, the inventory at station s1 will go to zero at t1 + 10 ∗ M IN IN 5.3 Results and the availability will only increase by 10∗M ttotal . In order to address this, we use the demand estima- We ran our simulation against the data for the month tor described in Section 5.1.1 to estimate the number of September 2012 from the Boston Hubway data. of missing trips and to insert fake trips into the miss- We compared 4 scenarios: ing regions to compensate. 1. No rebal: Apply cleaned trips to the initial status to obtain the predicted statuses without re5.2.2 Redirecting existing trips balancing. There is an additional consideration while inserting 2. Existing rebal: Calculate the real-world availtrips. Some of the trips in the real dataset in time t1 ability by looking at the station status informato t2 may be trips where the user wanted to start from tion in the input dataset. s1 , but moved to si because s1 had no bikes. Now that s1 does have bikes, instead of generating fake 3. Night rebal: Apply cleaned trips to the initial trips, we may sometimes want to redirect existing status. Also compute and apply rebalances betrips instead. tween 8pm and 4am. 5.2.3

4. Day rebal: Apply cleaned trips to the initial status. Also compute and apply rebalances between 9am and 9pm. The choice of rebalance hours was driven by the pdf of the rebalance times that we generated from the real data, shown in Fig. 12. As we can see, most of the existing rebalances occured between 8am and 11pm. There is also a small second round around 1am, which is probably static rebalancing overnight. Since we are focusing on dynamic rebalancing, we picked a range similar to the existing daytime rebalancing hours, but slightly more conservative.

Applying trips

One of the key elements of the simulator was the ability to start with a known station status, apply the effect of a set of trips, and determine the station status after the trips were taken. This is similar to rolling forward from a transaction log, so it is conceptually simple. However, redirecting complicates this aspect as well. For example, in the real world, a particular station may have had bikes available only because of an earlier rebalance. Since trip application does not include rebalancing, we will end up with trips that occured in the real world, but cannot occur in our simulation. In our simulated world, these trips might be redirected As we can see, both the day rebal and night rebal to adjacent stations, which means that we need to algorithms were slightly better than the real world rebalance, although we use a naive algorithm, and change the status at the new stations as well. our rebalance shifts are shorter than the real world. The availability metrics under these scenarios is 5.2.4 Detection of rebalances shown in Fig. 10. There is no rebalance overhead For the real world data, we are able to determine for the no rebal case, and we cannot compute the when bikes were dropped off or picked up from a sta- rebaltime metric for the real world, so we show the tion by comparing the changes in station status in rebalance overheads for the day rebal and night rebal a particular time interval to the trips to/from that scenarios in Fig. 13. 8

Figure 10: Station and System availability with various rebalancing schemes

Figure 13: Rebalance overhead with various rebalancing schemes

5.3.1

Sensitivity Analysis

As we saw earlier, we need to consider the impact of users retrying at adjacent stations, both while generating fake trips to fill the unavailable regions, and while applying a set of trips. However, we do not have a model of user behavior which predicts how Figure 11: Sensitivity of “Day rebal” to changes likely they are to use an adjacent station, as opposed in the probability that a user will retry a to abandoning the bikeshare system and choosing an alternate mode of transportation. missed/unreturnable trip (0/0.5/1.0) Therefore, we perform sensitivity analysis by varying two parameters: 1. retry probability, and 2. retry distance. Together, they represent the probability that a rider will retry stations that are within a certain radius. Figure 12: Probability distribution function of the Fig. 8 and 11 show the sensitivity of the availability hour at which rebalances occured for retry probabilities of (0, 0.5, 1.0) and retry dis9

tance = 300m. As we can see, the availability varies [CP95] by < 5% in both cases. We also considered running the same set of experiments with retry distance = 100m. However, it turns out that there are no stations that are 100m apart, so this would lead to no retries irrespective of the probability. As we can see from Fig. 9, even for retry distance = 300m, there are very few potential retry locations. [Fou12] We did not consider retry distances > 300m since most transportation studies assume that riders are willing to walk 1/4 mile (400m) to a transit stop. Bike share systems are targeted towards shorter trips than most transit (Fig. 7), so we posit that riders [MDP+ 00] would be even less willing to try long retry distances.

6

Future Work

[PL13] As discussed in length in Section 5.1, our primary focus for future work is to increase the fidelity of the various components. This includes trying out several distributed scheduling algorithms from the literature. In addition, we plan to implement the web API and rework the simulator so that it exercises the system through the public interfaces. [RHRHP13]

References [CK88]

[CMP+ 13]

[CMR12]

Thomas L. Casavant and Jon G. Kuhl. A taxonomy of scheduling in generalpurpose distributed computing systems. Software Engineering, IEEE Transac- [RTF13] tions on, 14(2):141154, 1988. Daniel Chemla, Frdric Meunier, Thomas Pradeau, Roberto Wolfler Calvo, and Houssame Yahiaoui. Self-service bike sharing systems: simu- [SCL+ 13] lation, repositioning, pricing. Technical report, Centre pour la Communication Scientifique Directe - UPS2275, 2013. . Contardo, Claudio, Morency, Catherine, and Rousseau, Louis-Martin. Balancing a dynamic public BikeSharing system. Technical Report CIRRELT- [SHvH13] 2012-09, CIRRELT - Interuniversity Research Centre on Enterprise Networks, Logistics and Transportation, March 2012. . 10

Jiannong Cao and M. Pole. The design of a simulation system for distributed task scheduling algorithms. In Algorithms and Architectures for Parallel Processing, 1995. ICAPP 95. IEEE First ICA/sup 3/PP., IEEE First International Conference on, volume 2, page 690698, 1995. Foursquare Integrated Transportation Planning. Arlington county capital bikeshare transit development plan FY20132018, November 2012. . Dejan S. Miloji\vci, Fred Douglis, Yves Paindaveine, Richard Wheeler, and Songnian Zhou. Process migration. ACM Computing Surveys (CSUR), 32(3):241299, 2000. Dimitris Papanikolaou and Kent Larson. Constructing intelligence in pointto-point mobility systems. In Intelligent Environments (IE), 2013 9th International Conference on, pages 51–56. IEEE, July 2013. . Gnther R. Raidl, Bin Hu, Marian Rainer-Harbach, and Petrina Papazek. Balancing bicycle sharing systems: Improving a VNS by efficiently determining optimal loading operations. In Hybrid Metaheuristics, page 130143. Springer, 2013. . Tal Raviv, Michal Tzur, and Iris A. Forma. Static repositioning in a bikesharing system: models and solution approaches. EURO Journal on Transportation and Logistics, 2(3):187–229, January 2013. . Jia Shu, Mabel C. Chou, Qizhang Liu, Chung-Piaw Teo, and I.-Lin Wang. Models for effective deployment and redistribution of bicycles within public bicycle-sharing systems. Technical report, National University of Singapore Business School, 2013. . Jasper Schuijbroek, Robert Hampshire, and Willem-Jan van Hoeve. Inventory rebalancing and vehicle routing in bike sharing systems. Technical report, Carnegie Mellon University, 2013. .