priori model of the network: what are the network topology (modeled as a directed graph), the transportation means (e.g., bus, tramways, metros), their itineraries, the infrastructure (e.g., kinds of roads), the scheduled departures, etc. The temporal one is made of the (huge) time series of data gathered from the many sensors available in the IPTS. The existing time series give the opportunity to not only provide a *model at run-time* [47], but also a full-fledged *digital twin* [9] of the IPTS to analyze, plan and manage the operations using machine learning techniques.

However these space and time parts of the supporting IT are most often not well integrated, making it hard in practice for network operators to leverage the avalanche of data gathered from the IPTS. For instance diverted lines (i.e., space modification) have no historical data to learn from, so even machine learning techniques that have successfully been applied on graph-based structures typical of an IPTS [29, 4, 62] cannot work out of the box.

Moreover, as for many other network problems (e.g., electricity or water networks), properties of interest (e.g., commercial speed of a bus along a line) are compositions of smaller independent parts (e.g. the speed on each bus inter-stops along the line). This enables the prediction on the behaviour of composite objects (a path in the graph), based on the predictions of their sub-parts (i.e. on edges) and relevant composition laws. This opens what-if analytics scenarios, where new objects never observed before can be predicted based on their simpler parts, and can then be used e.g., to optimize diversions in case of unforeseen events such as roadworks or floods.

A possible direction for integrating these models (spatial, temporal and predictive) would be to articulate them around the notion of digital twin and the concept of time, i.e., digital twins extending themselves towards Past, Present, and Future [38]. For that purpose, we propose a new framework, called *DATA TIME*, to implement models at run-time which capture the state of the system according to both time and space, here modeled as a directed graph. In this graph, both nodes and edges bear local and independent states (ie. values of properties of interest). *DATA TIME* offers a unifying interface to query the past, present and future (predicted) states of the system. This unifying interface provides i) an optimized structure of the time series that capture the past states of the system, possibly evolving over time, ii) the ability to get the last available value provided by the system's sensors, and iii) a continuous micro-learning over graph edges of a predictive model to make it possible to query future states, either locally or more globally, thanks to a composition law. We apply our framework in the context of an urban transportation
system, and concretely deploy and evaluate it on the IPTS of the city of Rennes (France),
that is operated by the Keolis company.

The rest of this chapter is organized as follows. We first introduce the DATETIME
framework (Section 2), and then we present its use in the context of an IPTS (Section
3). Then in Section 4 we describe how it was deployed at Keolis Rennes in the context
of the real bus network of the city of Rennes (France), and what lessons we have learned
from this experimentation. Section 5 discusses related work, before we conclude and raise
several perspectives in Section 6.

5.2 The DataTime Framework

<figure><img src="image_20.png" /><figcaption>Figure 5.1 – The DataTime framework (excerpt)</figcaption></figure>

Figure 5.1 shows a simplified class diagram of DATETIME. The objective of this frame-
work is to enable graph-based seamless space and time exploration, through the analysis
of historical data, real time data and predicted data. It is composed of two main parts:
i) the spatial model and predictors configuration (part II of Fig. 5.1) that is dedicated to
the designers who implement adaptations of I and II for the end-users and ii) the digital
twin/shadow to reason over time about the spatial model (part I of Fig. 5.1), thus the
digital twin built by the designers is the end-users' entry point to manipulate `DATETIME`.
A third component has been added in the part III of Fig. 5.1 to represent the required
endeavour to use `DATETIME` for the development of a particular IPTS (see Section 5.3).

5.2.1 Spatial model and prediction configuration

Graph

The spatial model is defined as a classical directed graph structure as seen in the part II of Fig. 5.1, focusing on the **graph** package: a set of vertices that are nodes with individual characteristics, and a set of edges that are one way connections between two vertices (a bidirectional edge is simply represented with two directed edges). Graphs have a built-in `time_frame` attribute that represents the time-frame for which corresponding referential and historical data exist. Hence it is to the discretion of the designer to consider that changes amongst a graph structure yield a new graph, or if it just changes its `time_frame` by expanding or reducing it, or leaving it unchanged (e.g. when minor changes occur).

Edge and vertex characteristics (features) are made abstract in order to use any
kind of data. The package data contains the different features and metrics definitions.
In order to make those generic, we separated their identification from their actual data
and type (following the type-object design pattern). This package contains three abstract
classes that have to be specialized for a specific system: Features, VolatileFeatures and
Metrics. Features represent characteristics of the edges and vertices. VolatileFeatures
are characteristics that are not represented in the data, but that can be computed on the
go (e.g bus line type extrapolated from its identifier, electrical cable resistance computed
from its length, etc.). Metrics are data that are not characteristics, such as measures
 speed, volume of water per hour, etc.) or time related information. Hence, data instances
that extend those classes must be able to query data from the Digital Shadow (cf. 5.2.2).

The package *path* represents the abstraction of a path through the graph, that is,
a sequence of at least one edge for the thinnest grain. *Paths* are abstract, hence one
can easily create a path hierarchy if relevant for the targeted application domain (e.g
transportation networks, supply chains, smart-grids, drinking water networks, ... ). Paths allow the building of hierarchical structures within the graphs while offering analysis and predictions scalability using micro-learning for the predictive aspects. Recently, micro-learning approaches have been successfully applied to graphs structures to provide what-if scenarios (e.g. in the context of power grid management [27]). In these approaches, specific models of local data are built instead of one large model on the overall data set. Micro-learning is typically useful for incremental predictive models, where one has to perform step-by-step decisions based on local properties, while yielding quality predictions. For instance for an IPTS, prediction of travel time or road reliability can be made using micro-learning over each edge and then aggregating the results using a specific composition law (sum for travel time, product for reliability, etc.).

In DATETIME, data analysis and predictions are made at the level od edges (provided
a predictive model has been configured for this purpose). For graphs on which data can be
aggregated from edge level to different implementations of parent paths, the prediction or
analysis at edge level will be automatically aggregated to higher levels with specific user
defined composition laws (e.g speed of a bus between two bus stops, aggregated to the
whole bus line, water leaks at single pipes sections, aggregated to the whole pipe, etc.).

Predictors

The prediction package contains the abstract class Predictor that embodies the predictive system of DataTime. It encapsulates predictive models and miscellaneous tools that define the expected behaviors of predictive models, from training to predicting. A specificity of this abstract class is that we included a way of managing the predictive models behavior through time. It proposes the following services:

- Choice of the predictive model, in order to choose the best suited predictive model depending on the prediction issue (using the strategy design pattern).

- Optimization of the model by searching for the best hyper-parameters. It embeds a grid search system that can either use a set of properties to seek from, or a random one (through the parameter `optimize` of `Predictor train()` in Fig. 5.1).

- Training of the model, by feeding it with a training dataset, hyper-parameters and choosing whether to optimize the predictive model using grid search (through the parameters of `Predictor train()` in Fig. 5.1).

- Saving and loading the predictors by transferring their data to the Digital Shadow interfaces (through the `Predictor train()` method in Fig. 5.1).
- Model's health monitoring, that takes care of the predictive model ability to predict in a satisfying manner depending on its age and a prediction error threshold over which a new model is trained. This service can be disabled if needed (using the attribute `Predictor.activete_healthcare` in Fig. 5.1).

- Features extraction for prediction, that explores the edges features to make predictions (`Predictor.extractFeatures()` in Fig. 5.1).

- Predictions, by returning a `PredictedRun` when called (`Predictor Predict()` in Fig. 5.1).

To configure a predictor, a designer has to extend `Predictor` and implement the `prepareDoctorData()` method, whose work is to prepare data for the health check-up of the predictive model and the training of a new one when needed. The `doctor` is called when one wants to predict something and that the predictive model is more than `obsolescence` days old compared to the current system date. The objective behind that is to keep predictors up to date and efficient. We achieve this by comparing the residuals obtained predicting from a sample of the last available data from now to `back_days` back in time with their base error (the deviation of the predictive model obtained during the training phase). If the predictive models yield an average residual that is over `error_trigger` times the base error, then a new model is trained with the data yielded by `prepareDoctorData()`. The `doctor` can be deactivated if needed (for example when the models are not subject to derivation because, e.g. the data is quite consistent through time), by setting `activete_healthcare` to false.

`Predictors` can use different predictive models thanks to the abstract class `PredictiveModel`. If one uses a single machine learning API in which predictive models are children of a single interface, then any model of such an API should be made available by encapsulating them in an extension of `PredictiveModel`, by tweaking the `error()` method for each model (because the error computation varies, and the result is not always kept into a trained model), that is necessary for the `doctor()`. Of course, if one wants to code her own predictive model, the simplest way is to extend `PredictiveModel` and override the relevant methods.

Predictors are referred by edges only, due to the fact that our system relies on compositional prediction. In order to make any prediction with any machine learning model, predictors should have their own set of features, and prediction targets. Hence the edges that call the predictors are responsible for giving them the right features by using their inner method `getFeaturesVector` that transforms their features into a vector of doubles for the predictor (with an ad hoc encoding for categorical data). Note that if some exter-
nal features that have not been designed in the model have to be passed to the predictor,
a container should be built to contain them. Predictors should then take the data they
need directly within this object.

The training of predictors is made by the **Edge** class, that calls the method `train(...)` of **Predictor**. This method has to be fed with a dataframe containing the appropriate training data (i.e. in accordance with the predictor feature set, thereby the predictive model formula), obtained by querying the digital shadow, and a set of hyper-parameters through the parameters **prop**. The parameter **optimize** triggers a randomized grid search algorithm when set to true in order to find the best configuration for the predictive models hyper-parameters. Thanks to this, any machine learning model with any features set and prediction target can be trained and used at any path level in the framework.

Finally, the class **Graph** is responsible for the manipulation in a single graph instance
such as seamless data analysis (through the method getMetric(...)), getting the corre-
sponding historical or real-time data from the Digital Shadow), what-if scenarii (creating
new edges, vertices, path and analysis against those new objects), and the orchestration
of the data between the different parts of the model such as instantiating and feeding
predictors with data when they need to be trained (through its edges). The main goal
of this class is to provide a way to obtain a set of **runs** when one calls the method
getMetric(...) by seamlessly returning historical or real time or predicted results from
historical runs or predicted runs over the given **path** and time period passed to the method
getMetric(...). Note that it does not matter if there is one or more instances of graphs
(e.g. a set of independent graphs distributed through time, with contiguous time-frames).
In both cases it is the getMetric(...) method of Digital Twin is used by the end-user
to explore data in time and space.

5.2.2 Digital twin/shadow description

The Digital Shadow is either the representation of an existing data environment on
which DATETIME can be plugged in a read-only manner in order not to have any side
effect on the existing information system, or an actual fully managed data environment
dedicated to DATETIME, making it responsible for the management of all the data flows
between the digital twin and the real system. The digital shadow should also be respon-
sible for the saving of the graphs instances and predictors instances. Moreover, it has
the responsibility of creating time-series used for data analysis while keeping them op-
timized and consistent through time. In short, any data that is yielded either by the
<figure><img src="image_21.png" /><figcaption>Figure 5.2 – Sequence diagram for `getMetric`</figcaption></figure>

Digital Twin of `DATETIME` or the real system sensors, etc. should transit and be governed by Digital Shadow. Fig. 5.2 shows an example of how data transits through the system when `getMetric(...)` is called.

The Digital Twin of `DATETIME` represents the set of `graph` instances of the model, over the time. It contains the time representation through the class `TimePeriod` that embeds two timestamps. This class helps the representation of time frames and instants (when `periodStart == periodEnd`), and time manipulation in the framework. The time periods are used to request the set of graphs that are part of the class Digital Twin, when calling the method `getMetric(...)` , that returns a set of `runs` which represent the result of the queries made by the Digital Twin over its set of `graphs`. In other words, `runs` model the action of traveling through a `path` at a given time frame, or a specific event on a `path` for a given time frame, e.g. a bus traveling along a bus line, an amount of water traveling through a section of a pipe network, the loss of electrical current between two poles, etc. Runs are built using historical data. Hence they consist of different measures & metrics made on the network represented by an instance of the `graph`. Runs should be atomic, hence they should be unique and they should be bound to `edges` only, with runs
of longer paths built by aggregating runs of their **edges**. Runs can be historical / pseudo
real-time (historical data) or predicted (using machine learning). Depending on the size
of the historical data, runs should be lazily loaded when analyzed. However, saving the
runs can be a bad idea if the historical data is huge: it would lead to storage starving
in addition to duplicated data. However, this decision depends on the **Digital Shadow**
structure. The **Digital Twin** class is also responsible for the building of graphs instances
by querying the **Digital Shadow** for referential data, yielding **Graph** instances. Hence the
**Digital Twin** is the end-user entry point on the framework.

5.3 Application to an Intelligent Public Transporta-
tion System

To assess the applicability of DateTime, we developed a SCALA implementation of the
framework adapted to urban bus networks.

IPTS such as modern urban bus networks are complex socio-technical systems made
of hundreds of stakeholders, including humans, sensors, vehicles, information system, etc.
Hence, a major concern with such an infrastructure is to gather, organize and normalize
data, analysis and decisions in integrated tools.

IPTS are slowly evolving networks, yet if an important part of the bus lines are non
changing for very long and continuous periods, there exists some variation within their
structure, such as the changes on bus lines when long-term roadworks are planned, the
creation of new bus lines, etc. Hence we considered that the *time_frame* of a single
instance of the bus network is corresponding to the period that was defined by the operator
(usually 1 to 2 weeks), during which there are no major modifications except for some
day to day bus line deviations.

In our applicative environment, the information systems were already provided, also
used by others. Hence, we plugged our framework on top of the existing Digital Shadow
in order to avoid any side effect on it. In our implementation, the Digital Twin is respon-
sible for the creation of as many graph instances corresponding to the different referential
files that exist in the data. Referential files contain actual definitions of the bus network
structure, as defined by the operator. i.e, if there are four sets of referential files, each of
them defining a bus network that is valid for a given period of time, four different graphs
instances will be created.
### 5.3.1 Graph and paths adaptation

We specialized `DATETIME` for bus networks issues as shown in the bottom part of Fig. 5.1. The bus network is an extension of the class **Graph**, for which the longest path within it are **BusLines**, made of **Sections** that are an ordered collection of **InterStations** (Edges). The class **Vertex** is representing the bus stops (stations) in this context. All of the elements of the graphs are immutable, in order to keep data consistency when one wants to make, e.g. an analysis over a line/section/inter-station that exists in all the members of a set of graphs.

### 5.3.2 Features adaptation

**InterStations** contain **Features** such as length of the inter-station (in meters), type of road (one-way, two ways, reserved for buses, etc.), number of traffic lights, number of pedestrian crossings, etc. All those features are physical features, extracted from Open-StreetMaps<fnref n="1" /> Section and line features are obtained by aggregating their respective sub-part features. In order to manage features in the bus network implementation, we created **data instances** that extend the abstract classes from the package **data** (following the type-object design pattern). We then created several data features classes (e.g. **Length**, **TrafficSignalsCount**, etc.), one **VolatileFeature** class, called **LineType** and as many **Metrics** classes as needed amongst which **Speed**, **TravelTime**, etc.

### 5.3.3 Runs adaptation

If we take a look at **Run**, the data they correspond to in the **Digital Shadow** is the data gathered from bus trips all over the network. We describe trips as follows:

- Trip in edges: Bus trips from bus stop **origin** to bus stop **destination**;

- Trip in sections: Bus trips **origin** to bus stop **destination** within its ordered collection of edges;

- Trip in line: Bus trips from **origin** to **destination** (terminals).

Trips contain metrics such as start time, arrival time, travel time, speed, dwell time (for sub paths only). One could easily add any external feature such as smart card data, weather, traffic, etc.

<footnote n="1">1. https://gitlab.inria.fr/glyan/osm_bus_extraction</footnote>
5.3.4 Data mass and lazy loading

Since an IPTS typically produces several GigaBytes of data per month, we soon end
up with more data than can be managed on a local file system. We thus need a kind
of lazy loading mechanism when querying trip data. Accordingly, runs are "built" on
demand when a call is made through the method getMetric() from the !DigitalTwin.
The resulting trips can be kept in memory up to a certain extent, but not saved. An
advantage of lazy loading is that this allows the ingestion of data in pseudo-real time (e.g.
when there is a need to observe what is going on in the bus network with a reasonable
delay).

5.4 Experimentation at Keolis Rennes

5.4.1 Evaluation of the Predictive Model

The first stage in the deployment of DATATIME at Keolis Rennes was to evaluate the
precision of the predictive model, in order to build confidence into the whole framework.
For that, we ran an experiment described as follows (outline of chapter 4):

1. We choose a set of 13 typical and different bus lines for which data could be gathered all along their path. This includes express, urban, inter-district and suburban bus lines;

2. We ran 13 experiments for each line, removing the respective line data from the training dataset that gathers data over year 2019;

3. We predicted the speed of each bus line using micro and macro-learning (i.e the training data consists of the set of full line trips data for macro-learning, while it is made of inter-station trips data for micro-learning);

4. We compared the aggregated micro-predictions and the macro-predictions to assess whether micro-learning is suitable for our model, and thus could be also used for unforeseen lines (e.g. in cases of traffic diversions).

Table 5.1 shows the averaged results of the experiments. It presents three prediction error measures for both macro and aggregated predictions. Those measures are the Root Mean Squared Error (RMSE) in km/h (eq. 5.1), Mean Absolute Error (MAE) in km/h (eq. 5.2) and Mean Absolute Percentage Error (MAPE) (eq. 5.3) in percent. All of these measures are the result of the comparison of the predictions with their actual counterparts,
hence, the lower the error, the better the prediction. Note that the RMSE is more sensitive to outliers than MAE and MAPE, which are not quadratic.

$$RMSE = \sqrt{\frac{1}{N} \sum_{1}^{N} (Y_t - \hat{Y}_t)^2} \qquad Y_t = actual, \hat{Y}_t = predicted \quad (5.1)$$

$$MAE = \frac{\sum_{1}^{N} (Y_t - \hat{Y}_t)}{N} \qquad Y_t = actual, \hat{Y}_t = predicted \quad (5.2)$$

$$MAPE = \frac{1}{N} \sum_{1}^{N} \left| \frac{Y_t - \hat{Y}_t}{Y_t} \right| * 100 \qquad Y_t = actual, \hat{Y}_t = predicted \quad (5.3)$$

For all measures, the precision obtained for the prediction is considered as good enough from the point of view of the bus operator (i.e Keolis Rennes). Further, the micro-learning approach is at least as good as macro learning approach<fnref n="2" /> in terms of accuracy and offers state of the art performance [berger-wolf_proceedings_2019]. The three micro-learning approach predictions error indicators are lower than those of the macro learning approach. Hence this experiment validated the use of micro-learning predictions for bus networks such as the ones operated by Keolis in Rennes. Finally, the utmost interest of micro-learning is the possibility to predict at the finest possible grain within the bus network, hence build what-if scenarios such as the prediction of bus travel time on new or diverted bus lines.

<table><caption>Table 5.1 – Prediction accuracy</caption><thead><tr><th colspan="3">Aggregated-micro</th><th colspan="3">Macro</th></tr><tr><th>RMSE</th><th>MAE</th><th>MAPE</th><th>RMSE</th><th>MAE</th><th>MAPE</th></tr></thead><tbody><tr><td>3.0</td><td>2.4</td><td>12.1%</td><td>3.2</td><td>2.9</td><td>12.2%</td></tr></tbody></table>

### 5.4.2 DataTime in Practice at Keolis

Our DATA TIME implementation was designed to be used by bus networks operators. Thanks to the framework we could develop the following features:

- The creation of new elements over the bus network, i.e. bus lines (or new bus lines sections), bus stops, inter-stations.

<footnote n="2">2. The full details of the validation experiments are available at: https://gitlab.inria.fr/glyan/compred</footnote>
- The analysis of any event on the network at any place and anytime in the bus network. For instance lines 1 to 20 in example 1 access past data using the method `getMetric()` with a time period located in the past

- The prediction of any metric on the network at any place and anytime in the bus network, e.g. Algorithm 1 lines 21 to 29 where the method `getMetric()` is call with a parameter meaning *now*

- Providing the operators hints on which detour should be applied on a bus line depending on, e.g. the expected speed of this detour. Even in a complex bus network with multiple possible paths between two bus stops, finding alternative possible routes is quite standard. It is typically solved with a search based greedy algorithm, parameterized with a maximum number of paths of a maximum length. The complex part is of course *evaluating* the suitability of the possible routes that the search algorithm would yield. Depending on the goal of the network operator (e.g. smallest travel time, best reliability, etc.), the system would then just have to pick the best path among the existing ones. As long as the system is able to predict a metric (speed, reliability) on any known or unknown edge, along any path, compositional prediction makes it possible to aggregate those predictions on any number of different paths allowing it to choose the best way to propose a detour, following one or more specific heuristics.

Algorithms 2 and 3 summarize the main steps of putting everything together to automatically apply a bus detour if the bus operator asks the system to. Algorithm 2 explains how to find all possible paths between two vertices in the graph, with some constraints on the number of iterations and paths found size. Algorithm 3 shows how to call algorithm 2 to yield an optimized deviation for a bus line, searching to maximize the speed of the deviation.

### 5.4.3 Lessons Learned

#### Performance and scalability

We fed our implementation of DATATIME using Apache Spark v3.1.1. It was behaving as a datasink, making it possible to query a datalake containing more than 2 years of data, totaling nearly 40GB. As an example, the primo-execution of a query like the one visible at lines 1-9 in Algo.1, which consists of querying over all the trips of a bus line for a 2 years period, takes around 40 seconds on a computer equipped with a middle end 8 cores
<caption>**Algorithm 1** Different call examples over the getMetric method</caption>

1: **val** busLine:Line = Graph.getLine("152", Direction.B)
2:
3: // TimePeriod for which historical data exists
4: **var** tp:TimePeriod = TimePeriod("2019-01-01 08:00:00", "2021-02-01 00:00:00")
5: **var** metric:Metric = Speed
6:
7: // Will return all the runs found for line 152 over tp
8: **var** runs:Set[Run] = getMetric(busLine, tp, metric)
9: runs.forEach.displayMetric()
10:
11: // TimePeriod for real time Data
12: val now:Long = System.currentTimeMillis
13: tp.setPeriodStart(now)
14: tp.setPeriodEnd(now)
15:
16: /** Will return runs corresponding to the last data available
17: * in the digitalshadow, comparing with now
18: */
19: runs:Set[Run] = getMetric(busLine.getSections head, tp, metric)
20: runs.forEach.displayMetric()
21:
22: // TimePeriod for future date
23: tp.setPeriodStart("2022-03-19 17:30:00")
24: tp.setPeriodEnd("2022-03-19 17:30:00")
25: metric = TravelTime
26:
27: // Will seamlessly return a predictedRun
28: runs:Set[Run] = getMetric(busLine.getInterStation(5), tp, metric)
29: runs.forEach.displayMetric()

x86 CPU. If one executes this query a second time, the result is almost instantaneous
provided the last request results were kept in memory. In a nutshell, the bigger the period
and the longer the path, the slower the querying will be. Hence, the performance and
design of the **Digital Shadow** services are paramount for querying to be efficient.

The predictors, that are able of continuous learning (by automatically training new
predictive models when needed), must be trained before being able to predict. The training
time depends on many factors but there are 3 of them that will have a significant impact.
Those are the size of the training dataset, the number of features and the hyper-parameters
tuning. The latter can be the worst one if, e.g. one uses grid search to find the best set of
hyper-parameters (using `optimize=true` in the method `train(...)`). We decided to train
models with a training dataset that contains 1 or 2 month of data, with a set of 8 features
and the default set of hyper-parameters. The training of such a model takes no longer
than 10 minutes on a middle end computer (8 cores, 16GB RAM). Hence, the continuous
training if the predictive models eventually turn dull would be in the same time range.
This is rather acceptable knowing that a single model is able to yield predictions for the
whole system.

Finally, our implementation is scalable in those ways:

1. The digital shadow can rely on scalable databases, hence the storage and querying can be distributed amongst different machines if needed.

2. The implementation of the framework can be used on any machine and does not need a tremendous amount of computing power to analyze data or predict data: The data collection for analysis relies on the digital shadow ability to scale, and the predictive models training time is short even on a single machine.

Impact at Keolis

If we recall what we saw in section 1.1.2 of chapter 1, Keolis Rennes is in need of
a tool to centralize data management, data analysis, and prospective/predictive models.
Thereby, a framework such as DATETIME favors the data centralizing with a focus on
scalability for data analysis, making it possible for domain experts to integrate past,
present and future within a traditional information system containing a priori models.
Moreover, DATETIME could be even more user friendly with the providing of future DSLs,
for, e.g. facilitating the integration of new data sources, the edition of line topologies
or make data analysis more fluid, etc.In addition, DATETIME allowed us to highlight
specificities of the bus networks that were yet not visible for the operator. Indeed, the use
of predictive models allowed the analysis of feature importance, hence to do sensitivity
tests for, e.g. speed and vehicle engine type. It appeared that the electrical buses that
were test running on the bus line 12 for a few months were systematically slower than
their combustion counterparts, which was later explained by their higher gravity center,
due to the presence of the traction batteries on the buses roofs.
## 5.5 Conclusion and Perspectives

In this chapter we propose a framework called DATETIME to implement models at run-time which capture the state of a socio-technical system according to the dimensions of both time and space. Space is modeled as a slowly evolving directed graph where both nodes and edges bear local and independent states (i.e, values of properties of interest). DATETIME provides a unifying interface to query the past, present and future (predicted) states of such socio-technical system, hiding the complexity and scalability issues of dealing with huge time series and machine learning. We applied our framework in the context of an urban transportation system, and concretely deployed and evaluated it on the IPTS of the city of Rennes (France).

DATETIME makes it possible for domain experts to integrate past, present and future within a traditional information system containing a priori models. Still up to now, using DATETIME requires experts to work at the level of the chosen programming language, here Scala, which is seldom known to the IT department of an IPTS operator such as Keolis. We thus plan to make it easier to use the DATETIME framework by providing a set of DSL embodying its main abstractions, thus facilitating the integration of new data sources, the edition of the network topology, or make data analysis more fluid.

As future work, we envision to apply our framework for other application domains that bear structural and temporal similarities with IPTS, such as smart grids, water abduction systems, or supply chains. As long as they fit the directed graph abstraction at the core of DATETIME, and as long as global properties of interest could be obtained by composing atomic values associated to edges, we do not foresee any issue in specializing DATETIME towards these systems.Thi
<caption>**Algorithm 2** Detours finding (Scala inspired pseudo-code)</caption>

1: /** Call function **/
2: def detours.orig, dest, maxLength, maxDetours:
3:   val detoursSet = new Set[Edge]()
4:   /** Get the edges starting from orig **/
5:   val possibleEdges: Set[Edge] = GRAPH edges filter (_ .orig == orig)
6:   val edgesSet = new Set[Edge]()
7:   for (e: Edge in possibleEdges) do
8:     _detours(e, dest, 1, maxLength, maxDetours, detoursSet)
9:   end for
10:  return detoursSet
11: end detours
12:
13: /** Recursive function **/
14: private def _detours(currentEdge, dest, order, maxLength, maxDetours, edgesSet, detoursSet):
15:   if (detoursSet.length < maxDetours and order < maxLength) then
16:     /** Non duplication check **/
17:     val vertexInSet: Boolean = if (edgesSet.isEmpty) false
18:     else edgesSet.map (_ .orig == currentEdge .dest) .reduce (_||_)
19:     if (currentEdge .dest == dest and not vertexInSet and edgesSet.add(currentEdge))
20:       then
21:         /** FINAL CASE **/
22:         detoursSet.add edgesSet
23:     else if (not edgesSet contains (currentEdge) and not vertexInSet) then
24:       /** GREEDY CASE **/
25:       val possibleEdges: Set[Edge] = GRAPH edges filter (_ .orig == currentEdge .dest)
26:       /** This loop should be parallel for better performance **/
27:       for (e: Edge in possibleEdges) do
28:         edgesSet.add (currentEdge)
29:     if (not edgesSet contains (e)) then
30:       _detours(e, dest, order +1, maxLength, maxDetours, edgesSet.clone, detoursSet)
31:   end for
32: end if
33: end if
34: end _detours
**Algorithm 3** Example of how to get the best detour on line A2 between A and B for the morning rush hour of Tuesdays during working periods (Scala inspired pseudo-code)

1: **val line:** Line = GRAPH.lines.A2
2: **val detourStart:** Vertex = A
3: **val detourEnd:** Vertex = B
4: **val originalRoute:** Set[Edge] = line
5: .getSubRoute detourStart, detourEnd
6: **val day:** Days.TUESDAY
7: **val holidays:** Holidays.NONE
8: **val period:** Periods.MORNING_RUSH_HOUR
9: **val metric:** Metrics.SPEED
10: **val possibleDetours:** Set[Set[Edge]] = 
11: detours detourStart, detourEnd, 20, 10
12: .except originalRoute
13: **val metrics:** Set[Doub] = possibleDetours
14: .map_.predict metric,TimePeriod holidays, day, period)
15: **val bestDetour:** (Set[Edge],Double) = possibleDetours
16: .zip metrics).sortBy_.2).last
17: GRAPH.enact (line,bestDetour)
# CONCLUSION AND FUTURE WORK

This chapter is a conclusion to this thesis. It summarizes the main contributions of this document and proposes some future work to tackle problems unsolved or raised by this work.

## 5.6 Conclusion

Urban Transportation Networks are going to get closer to data and computing tech-
nologies with time. Not only because the use of sensors becomes easier and cheaper thanks
to better communication technologies and hardware production methods, but also because
cities and operators are willing to optimize their transportation networks, keeping them
efficient and attractive in upcoming smart-cities. However, all this will yield growing and
tremendous amount of data, for the more the system is cyber-equipped, the more data is
generated. Hence, more domain expert and IT engineers and researchers will be needed
to manage, handle, analyze and produce interpretations of this huge heterogeneous data.
Therefore, the building of data management systems, or even digital twins is desirable
to help bus networks operators tackle the problem of integrating massive heterogeneous
data, extract information from this data to yield quality analysis or predictions, and fi-
nally have a continuously available virtual representation of the bus network that makes
it possible the exploration of data through space and time.

In the first contribution, we proposed to evaluate the data quality of the Automatic
Vehicle Location (AVL) system of the bus network of the city of Rennes, France. Our find-
ings are that this system is error prone, and that a specific data management and data
qualification environment is needed for both production and research purposes. However,
the data quality level must be bound to the specific need of the users of this data, in order
not to over cleanse it, yielding potential high cleansing cost for minor quality improve-
ments.

The second contribution makes use of massive heterogeneous data to assess the ex-
istence of factors that supposedly have an impact on bus commercial speed. We could
gather data for traffic, bicycles, ridership, weather and roads infrastructure. We inves-
tigated in depth traffic and ridership thanks to the lock-down period that was imposed
in France in spring 2020. We were able to assess the existence of impacting factors, but
the confirmation of the genericity of these factors could not be reached. However we were
able to raise a series of hypotheses that might be helpful for bus networks operators. Yet,
those hypotheses have yet to be validated on further works.

The third contribution makes use of the two previous ones. We use the data we ob-
tained using the processes described in the first contribution, and some of the factors
identified in the second contribution in order to make so called micro-predictions at the
inter-station level. We considered the bus network to be a directed graph, on which ver-
tices are bus stops and edges inter-stations. We rely our system on the fact that, e.g.
commercial speed over a given path is composed of the sum of edges lengths divided by
the sum of edges travel time. We targeted the prediction of bus commercial speed on both
known and unknown inter-stations in order to propose a system that seamlessly provides
predictions and what-if scenarii analysis (e.g. creation of a new bus routes and bus lines).
Finally, we have shown that micro-predictions are as good as predictions at terminal to
terminal (whole bus line) scale, while offering compositional properties making it way
more flexible for spatio-temporal predictions.

The fourth and final contribution proposes DATATIME, a framework to implement
models at runtime which capture the state of the system according to both time and space
modeled as a directed graph. It is the direct outcome of the three previous contributions,
using our findings as inputs. In DATATIME, a transportation network is modeled as a
slowly evolving directed graph where both nodes and edges bear local and independent
states (i.e., values of properties of interest). DATATIME provides a unifying interface to
query the past, present and future (predicted) states of such a socio-technical system,
hiding the complexity and scalability issues of dealing with huge time series and machine
learning. We applied our framework in the context of an urban transportation system, and
concretely deployed and evaluated it on the Public Transportation Information System
(PTIS) of the city of Rennes (France).

In the end, our contributions aim at providing domain experts with methods for the
integration of heterogeneous data, data analysis abilities and predictive models in mono-
lithic frameworks. In addition, this work starts the depreciating of the use of multi-tools
systems for data management.
## 5.7 Perspectives

### 5.7.1 Bus commercial speed impacting factors assertion and generalization

Our findings in Chapter 3 are a first step to formally identify factors that have an actual impact on the bus commercial speed by using real world data. However, the use of accurate and complete data is of need to strengthen the assumptions we raised. In particular, the importance of the different factors is probably city-dependant, hence factors that are prominent in Rennes can be minor in other cities. Hence a further work based on this one would be to lead this kind of survey in various cities over the world to discriminate factors that are global from those which are dependent of either a group of similar cities or a city in particular.

### 5.7.2 Prediction in graphs: compute minimum paths size over which micro-predictive models can be avoided

We saw in Chapter 4 that if micro-predictive models are as capable as predictive models that consider the longest paths of a given graph for inputs, there seems to be a path size threshold over which micro-predictive models should be avoided because of noise amplification yield by the aggregation rules. This can be considered as an operational research problem. For a given graph, a dedicated (greedy) algorithm should travel along all the available paths, and train a predictive model and compute residuals for every step in the paths. Doing this has at least two purposes. First it could be useful to assess whether micro-predictive models are indeed limited over a given path size, if we do not consider training data quality. Second, this could help to understand whether the so called threshold is to be shared amongst all the paths of the graph, or if there are many local thresholds, thereby enhancing the complexity of this issue.

### 5.7.3 DateTime domain specific language

The first shot of DATETIME proposed in Chapter 5 of this thesis can be completed by integrating a Domain Specific Language (DSL). This DSL would be plugged on top of the core of the framework and propose a seamless way to, e.g.

- create/modify either the whole or its subparts;
— query the graph for data (i.e a query sub-DSL);

— add/remove/modify data sources;

— manipulate the predictive components of the framework.

The adjunction of an integrated domain specific language to DATETIME would enhance
the end-user experience, while preserving the genericity of the framework.

5.7.4 Data collection expansion for the current Intelligent Pub-
lic Transportation System (IPTS) implementation of Data-
Time

Currently, our IPTS implementation of DATETIME can get data from OpenStreetMaps for any bus line that has been reproduced on the online OSM servers by the community. A limitation however is that if one wants to create a new bus line in our DATETIME IPTS implementation and get the road infrastructure data from online OSM, this new line has to be designed on OSM too. This is a problem because OSM is intended to be a virtual representation of the real world, thereby the design of non existing bus lines for experiment purpose on online OSM has to be avoided.

However, there might be a way to link DATETIME to a local OSM server using
osm2pgsql<fnref n="3" /> (tool that populates postgresql with dumps from OSM) and OSMosis<fnref n="4" /> (that
synchronizes postgresql databases and the local server). The harmonization of those tools
could make it possible to either modify bus lines directly from DATETIME or even the local
OSM server, the changes being automatically synchronized between one another. Further-
more, OSMosis could be used to continuously integrate new data from online OSM while
keeping changes of the local OSM server safe. However, this would need a lot of work
to minutely adapt the local OSM instance so that it keeps the modification one makes
among its current database, while it should be able to pull new information from world
wide OSM database without pushing anything to it nor failing because of data conflicts.

5.7.5 Meta-learning and extrapolation of aggregation rules from
data for micro-predictive models

In the current state, as described in Chapter 5, our encapsulation of predictive models
proposes a way to use any predictive model with integrated model health management.

<footnote n="3">3. https://osm2pgsql.org/</footnote>

<footnote n="4">4. https://wiki.openstreetmap.org/wiki/Osmosis</footnote>
The so called doctor is used to deprecate a predictive model and train a new one when it is not able to predict with a satisfying accuracy among the last data to date. This encapsulation could be further enhanced by adding meta-learning, as suggested in [28]. One other limitation of the micro-predictive model we proposed is that the pre-condition needed to use it is the existence of aggregation rules. Indeed, micro-predictive models are desirable to predict non-atomic models (that can be broken down into sub parts) only. However those aggregation rules used to re-conciliate predictions made at the lowest level to higher levels in the model have to be manually implemented in the tool that makes use of micro-predictive models. Finding a way to extrapolate the aggregation rules directly from the input data could help the integration of predictive models. Hence, the implemen- tation of meta-learning systems along with aggregation rules extrapolation would make it possible for the predictive components of DATATIME to become a fully autonomous system, thereby totally user friendly.
<figure><img src="image_22.png" /></figure>
LIST OF FIGURES

<table>
  <tbody>
    <tr>
      <td>2.1</td>
      <td>RMSE variation over 3119 inter-stations common to H0 and H1</td>
      <td>48</td>
    </tr>
    <tr>
      <td>2.2</td>
      <td>RMSE variation over 3119 inter-stations common to H2 and H3</td>
      <td>49</td>
    </tr>
    <tr>
      <td>2.3</td>
      <td>RMSE variation over 3119 inter-stations common to H0 and H2</td>
      <td>49</td>
    </tr>
    <tr>
      <td>2.4</td>
      <td>RMSE variation over 3119 inter-stations common to H1 and H3</td>
      <td>50</td>
    </tr>
    <tr>
      <td>2.5</td>
      <td>Prediction results comparison chart</td>
      <td>51</td>
    </tr>
    <tr>
      <td>3.1</td>
      <td>Correlation matrix of road infrastructure, weather and bus commercial speed</td>
      <td>61</td>
    </tr>
    <tr>
      <td>3.2</td>
      <td>Chart of bikes per 5 minutes vs bus commercial speed</td>
      <td>65</td>
    </tr>
    <tr>
      <td>3.3</td>
      <td>Correlation matrix of bus commercial speed and traffic for a nominal time period.</td>
      <td>66</td>
    </tr>
    <tr>
      <td>3.4</td>
      <td>Correlation matrix of bus commercial speed and traffic during the COVID19 1st lockdown in 2020 in France.</td>
      <td>67</td>
    </tr>
    <tr>
      <td>3.5</td>
      <td>Correlation matrix of bus commercial speed and ridership during nominal period.</td>
      <td>69</td>
    </tr>
    <tr>
      <td>3.6</td>
      <td>Correlation matrix of bus commercial speed and ridership during the COVID19 1st lockdown in 2020 in France.</td>
      <td>70</td>
    </tr>
    <tr>
      <td>4.1</td>
      <td>A bus network with featured edges (F: length of the road, type of line, etc.)</td>
      <td>75</td>
    </tr>
    <tr>
      <td>4.2</td>
      <td>What-if scenario: predict S0 – S10 while edges S0 – S5, S5 – S7 and S7 – S10 do not exist in the data set.</td>
      <td>76</td>
    </tr>
    <tr>
      <td>4.3</td>
      <td>Speed of urban bus line 858 at inter-stations using micro-learning (purple) vs true speed (dashed). Orange inter-stations where not used by any other bus, i.e. are absent from the training set.</td>
      <td>85</td>
    </tr>
    <tr>
      <td>5.1</td>
      <td>The DateTime framework (excerpt)</td>
      <td>97</td>
    </tr>
    <tr>
      <td>5.2</td>
      <td>Sequence diagram for getMetric</td>
      <td>102</td>
    </tr>
    <tr>
      <td>A.1</td>
      <td>micro-predictions of bus line 532 with and without OSM features</td>
      <td>124</td>
    </tr>
    <tr>
      <td>A.2</td>
      <td>micro-predictions of bus line 683 with and without OSM features</td>
      <td>125</td>
    </tr>
    <tr>
      <td>A.3</td>
      <td>micro-predictions of bus line 711 with and without OSM features</td>
      <td>126</td>
    </tr>
  </tbody>
</table>
<table><tr><td>A.4</td><td>micro-predictions of bus line 787 with and without OSM features</td><td>127</td></tr><tr><td>A.5</td><td>micro-predictions of bus line 849 with and without OSM features</td><td>128</td></tr><tr><td>A.6</td><td>Geographical view of the STAR bus network drawn from the data extracted out of OpenStreetMap database dump. Red portions represent part of the network for which traffic data could be matched</td><td>129</td></tr></table>
LIST OF TABLES

<table><tr><td>1.1</td><td>Public transportation network glossary</td><td>21</td></tr><tr><td>1.2</td><td>The thesis positioning in the predictive analytics of bus networks state of the art</td><td>35</td></tr><tr><td>2.1</td><td>H2 Creation process overview</td><td>44</td></tr><tr><td>2.2</td><td>data sets properties</td><td>45</td></tr><tr><td>2.3</td><td>inter-stations learning failures</td><td>48</td></tr><tr><td>2.4</td><td>NRMSE of H1</td><td>50</td></tr><tr><td>2.5</td><td>NRMSE of H3</td><td>50</td></tr><tr><td>3.1</td><td>Fig. 3.1 related data and characteristics</td><td>62</td></tr><tr><td>3.2</td><td>Bus hardware data summary</td><td>63</td></tr><tr><td>3.3</td><td>Traffic data summary for nominal period.</td><td>66</td></tr><tr><td>3.4</td><td>Traffic data summary for lockdown period.</td><td>68</td></tr><tr><td>3.5</td><td>Ridership data summary for nominal period.</td><td>68</td></tr><tr><td>3.6</td><td>Ridership data summary for lockdown period.</td><td>69</td></tr><tr><td>4.1</td><td>Variables of our equation used for data generation</td><td>80</td></tr><tr><td>4.2</td><td>Bus lines metadata</td><td>82</td></tr><tr><td>4.3</td><td>Sample of the historical data set</td><td>82</td></tr><tr><td>4.4</td><td>Sample of the training data set used for micro-learning</td><td>83</td></tr><tr><td>4.5</td><td>Prediction accuracy on a synthetic dataset for additive composition law (bus line duration)</td><td>84</td></tr><tr><td>4.6</td><td>Prediction accuracy on a synthetic dataset for multiplicative compositional law (product of probabilities)</td><td>84</td></tr><tr><td>4.7</td><td>Results table</td><td>87</td></tr><tr><td>4.8</td><td>Models's sensitivity to time features</td><td>88</td></tr><tr><td>4.9</td><td>Results table of models trained without OpenStreetMaps features</td><td>90</td></tr><tr><td>4.10</td><td>Micro-learning models's sensitivity to OSM features</td><td>91</td></tr></table>
# SUPPLEMENTARY MATERIAL

remove
final

## A.1 Micro predictions charts

Figures A.1, A.2, A.3, A.4 and A.5 show broader results of the predictions results of the experiments led in chapter 4.

## A.2 Miscellaneous
<figure><img src="image_23.png" /><figcaption>Figure A.1 – micro-predictions of bus line 532 with and without OSM features</figcaption></figure>
<figure><img src="image_24.png" /><figcaption>Figure A.2 – micro-predictions of bus line 683 with and without OSM features</figcaption></figure>
<figure><img src="image_25.png" /><figcaption>Figure A.3 – micro-predictions of bus line 711 with and without OSM features</figcaption></figure>
<figure><img src="image_26.png" /><figcaption>Figure A.4 – micro-predictions of bus line 787 with and without OSM features</figcaption></figure>
<figure><img src="image_27.png" /><figcaption>Figure A.5 – micro-predictions of bus line 849 with and without OSM features</figcaption></figure>
<figure><img src="image_28.png" /><figcaption>Figure A.6 – Geographical view of the STAR bus network drawn from the data extracted out of OpenStreetMap database dump. Red portions represent part of the network for which traffic data could be matched</figcaption></figure>
<figure><img src="image_29.png" /></figure>
BIBLIOGRAPHY

[1] Jeffrey L Adler and Victor J Blue, « Toward the design of intelligent traveler information systems », en, in: *Transportation Research Part C: Emerging Technologies* 6.3 (June 1998), pp. 157-172, ISSN: 0968090X, DOI: 10.1016/S0968-090X(98)00012-6.

[2] O. Aloquili, A. Elbanna, and A. Al-Azizi, « Automatic vehicle location tracking system based on GIS environment », en, in: *IET Software* 3.4 (2009), p. 255, ISSN: 17518806, DOI: 10.1049/iet-sen.2008.0048.

[3] Mehmet Altinkaya and Metin Zontul, « Urban Bus Arrival Time Prediction: A Review of Computational Models », en, in: 2.4 (2013), p. 7.

[4] H. Amirat et al., « MyRoute: A Graph-Dependency Based Model for Real-Time Route Prediction », in: *JCM* 12 (2017), p. 668.

[5] Jaume Barceló et al., « A methodological approach combining macro, meso and micro simulation models for transportation analysis », en, in: (2005), p. 24.

[6] Christopher Barron, Pascal Neis, and Alexander Zipf, « A Comprehensive Framework for Intrinsic OpenStreetMap Quality Analysis: A Comprehensive Framework for Intrinsic OpenStreetMap Quality Analysis », en, in: *Transactions in GIS* 18.6 (Dec. 2014), pp. 877-895, ISSN: 13611682, DOI: 10.1111/tgis.12073.

[7] Germà Bel and Maximilian Holst, « Evaluation of the impact of Bus Rapid Transit on air pollution in Mexico City », en, in: *Transport Policy* 63 (Apr. 2018), pp. 209-220, ISSN: 0967070X, DOI: 10.1016/j.tranpol.2018.01.001.

[8] Jean-Yves Blais, Jacques Lamont, and Marc Rousseau, « The HASTUS Vehicle and Manpower Scheduling System at the Société de transport de la Communauté urbaine de Montréal », en, in: *Interfaces* 20.1 (Feb. 1990), pp. 26-42, ISSN: 0092-2102, 1526-551X, DOI: 10.1287/inte.20.1.26.

[9] Francis Bordeleau et al., « Towards Model-Driven Digital Twin Engineering: Current Opportunities and Future Challenges », in: *ICSMM 2020 - International Conference on Systems Modelling and Management*, Bergen, Norway, June 2020.
[10] Oded Cats et al., « Mesoscopic Modeling of Bus Public Transportation », en, in: *Transportation Research Record: Journal of the Transportation Research Board* 2188.1 (Jan. 2010), pp. 9–18, ISSN: 0361-1981, 2169-4052, DOI: 10.3141/2188-02.

[11] Avishai Ceder and Nigel H.M. Wilson, « Bus network design », en, in: *Transportation Research Part B: Methodological* 20.4 (Aug. 1986), pp. 331–344, ISSN: 01912615, DOI: 10.1016/0191-2615(86)90047-0.

[12] Vítor Cerqueira et al., « Arbitrated Ensemble for Time Series Forecasting », in: *Machine Learning and Knowledge Discovery in Databases*, ed. by Michelangelo Ceci et al., Cham: Springer, 2017, pp. 478–494, ISBN: 978-3-319-71246-8.

[13] Benoit Combemale et al., « A Hitchhiker's Guide to Model-Driven Engineering for Data-Centric Systems », en, in: *IEEE Software* (2020), ISSN: 0740-7459, 1937-4194, DOI: 10.1109/MS.2020.2995125.

[14] Cristian E. Cortés et al., « Commercial bus speed diagnosis based on GPS-monitored data », en, in: *Transportation Research Part C: Emerging Technologies* 19.4 (Aug. 2011), pp. 695–707, ISSN: 0968090X, DOI: 10.1016/j.trc.2010.12.008.

[15] Xavier Courtois and Frédéric Dobruszkes, « L'(in)efficacité des trams et bus à Bruxelles, une analyse désagrégée », fr, in: *Brussels Studies. La revue scientifique électronique pour les recherches sur Bruxelles / Het elektronisch wetenschappelijk tijdschrift voor onderzoek over Brussel / The e-journal for academic research on Brussels* (June 2008), ISSN: 2031-0293, DOI: 10.4000/brussels.603.

[16] Teresa Cristóbal et al., « Bus Travel Time Prediction Model Based on Profile Similarity », en, in: *Sensors* 19.13 (June 2019), p. 2869, ISSN: 1424-8220, DOI: 10.3390/s19132869.

[17] J. Deng, H. Nie, and C. Chen, « Research on Bus Passenger Traffic Forecasting Model based on GPS and IC Card Data », in: *in Proceedings of the 3rd International Conference on Mechatronics Engineering and Information Technology (ICMEIT 2019)* (2019).

[18] Sabeur Elkosantini and Saber Darmoul, « Intelligent Public Transportation Systems: A review of architectures and enabling technologies », en, in: *2013 International Conference on Advanced Logistics and Transport*, Sousse, Tunisia: IEEE, May 2013, pp. 233–238, DOI: 10.1109/ICAdLT.2013.6568465.
[19] J. Esser and M. Schreckenberg, « Microscopic Simulation of Urban Traffic Based on Cellular Automata », en, in: *International Journal of Modern Physics C* 08.05 (Oct. 1997), pp. 1025-1036, ISSN: 0129-1831, 1793-6586, DOI: 10.1142/S0129183197000904.

[20] Reza Zanjirani Farahani, « A review of urban transportation network design problems », en, in: *European Journal of Operational Research* (2013), p. 22.

[21] Dan Feldman, Melanie Schmidt, and Christian Sohler, « Turning Big Data Into Tiny Data: Constant-Size Coresets for $k$-Means, PCA, and Projective Clustering », en, in: *SIAM Journal on Computing* 49.3 (Jan. 2020), pp. 601-657, ISSN: 0097-5397, 1095-7111, DOI: 10.1137/18M1209854.

[22] Martin Fellendorf, « VISSIM:A microscopic Simulation Tool to Evaluate Actuated Signal Control including Bus Priority », in: *64th Institute of Transportation Engineers Annual meeting* (Oct. 1994).

[23] R. Fernandez and E. Valenzuela, « A model to predict bus commercial speed », in: *Traffic Engineering & Control* 44.2 (Feb. 2003), ISSN: 0041-0683.

[24] Jean-François Girres and Guillaume Touya, « Quality Assessment of the French OpenStreetMap Dataset: Quality Assessment of the French OpenStreetMap Dataset », in: *Transactions in GIS* 14.4 (Aug. 2010), pp. 435-459, ISSN: 13611682, DOI: 10.1111/j.1467-9671.2010.01203.x.

[25] Tim Godfrey et al., « Modeling Smart Grid Applications with Co-Simulation », en, in: *2010 First IEEE International Conference on Smart Grid Communications*, Gaithersburg, MD, USA: IEEE, Oct. 2010, pp. 291-296, ISBN: 978-1-4244-6510-1, DOI: 10.1109/SMARTGRID.2010.5622057.

[26] Mehmet Akif Gormez, Ehsanul Haque, and Yilmaz Sozer, « Cost Optimization of an Opportunity Charging Bus Network », en, in: *IEEE Transactions on Industry Applications* (2021), pp. 1-1, ISSN: 0093-9994, 1939-9367, DOI: 10.1109/TIA.2021.3061031.

[27] Thomas Hartmann et al., « GreyCat: Efficient what-if analytics for data in motion at scale », en, in: *Information Systems* 83 (July 2019), pp. 101-117, ISSN: 03064379, DOI: 10.1016/j.is.2019.03.004.
[28] Thomas Hartmann et al., « Meta-Modelling Meta-Learning », en, in: 2019 ACM/IEEE 22nd International Conference on Model Driven Engineering Languages and Systems (MODELS), Munich, Germany: IEEE, Sept. 2019, pp. 300–305, ISBN: 978-1-72812-536-7, DOI: 10.1109/MODELS.2019.00014.

[29] Thomas Hartmann et al., « The Next Evolution of MDE: A Seamless Integration of Machine Learning into Domain Modeling », en, in: Software & Systems Modeling volume (2019), p. 17, DOI: 10.1007/s10270-017-0600-2.

[30] M. Hilbert and P. Lopez, « The World's Technological Capacity to Store, Communicate, and Compute Information », en, in: Science 332.6025 (Apr. 2011), pp. 60–65, ISSN: 0036-8075, 1095-9203, DOI: 10.1126/science.1200970.

[31] Odd André Hjelkrem et al., « A battery electric bus energy consumption model for strategic purposes: Validation of a proposed model structure with data from bus fleets in China and Norway », en, in: Transportation Research Part D: Transport and Environment 94 (May 2021), p. 102804, ISSN: 13619209, DOI: 10.1016/j.trd.2021.102804.

[32] Markus Hofmann and Margaret O'Mahony, « The Impact of Adverse Weather Conditions on Urban Bus Performance Measures – an Analysis Using ITS Technology », en, in: Intelligent Transportation Systems, IEEE, 2005, p. 7.

[33] Z.D. Huang et al., « A GIS-based framework for bus network optimization using genetic algorithm », en, in: Annals of GIS 16.3 (Nov. 2010), pp. 185–194, ISSN: 1947-5683, 1947-5691, DOI: 10.1080/19475683.2010.513152.

[34] O.J. Ibarra-Rojas et al., « Planning, operation, and control of bus transport systems: A literature review », en, in: Transportation Research Part B: Methodological 77 (July 2015), pp. 38–75, ISSN: 01912615, DOI: 10.1016/j.trb.2015.03.002.

[35] Sakari Jäppinen, Tuuli Toivonen, and Maria Salonen, « Modelling the potential effect of shared bicycles on public transport travel times in Greater Helsinki: An open data approach », en, in: Applied Geography 43 (Sept. 2013), pp. 13–24, ISSN: 01436228, DOI: 10.1016/j.apgeog.2013.05.010.

[36] Jerald Jariyasunant, « Improving Traveler Information and Collecting Behavior Data with Smartphones », En, PhD thesis, Berkeley University, 2012.
[37] Sami Kaivonen and Edith C.-H. Ngai, « Real-time air pollution monitoring with sensors on city bus », en, in: *Digital Communications and Networks* 6.1 (Feb. 2020), pp. 23–30, ISSN: 23528648, DOI: 10.1016/j.dcan.2019.03.003.

[38] Jörg Christian Kirchhof et al., « Model-driven Digital Twin Construction: Synthesizing the Integration of Cyber-Physical Systems with Their Information Systems », en, in: (2020), p. 12.

[39] Yashaswi Kotagiri and Srinivas S. Pulugurtha, « Modeling Bus Travel Delay and Travel Time for Improved Arrival Prediction », in: *International Conference on Transportation and Development 2016*, American Society of Civil Engineers, June 2016, DOI: 10.1061/9780784479926.052.

[40] Gauthier Lyan et al., *Impact of Data Cleansing for Urban Bus Commercial Speed Prediction*, Research Report, Université de Rennes ; IRISA ; Keolis Rennes, May 2021.

[41] Xiaolei Ma and Xi Chen, « Public Transportation Big Data Mining and Analysis », en, in: *Data-Driven Solutions to Transportation Problems*, Elsevier, 2019, pp. 175–200, ISBN: 978-0-12-817026-7, DOI: 10.1016/B978-0-12-817026-7.00007-2.

[42] RAPHAEL N MARKELLOS, « Evaluating public transport efficiency with neural network models », en, in: *Transportation Research Part C: Emerging Technologies* 5 (1996), p. 12.

[43] Takuya Matsumoto, Kazutoshi Sakakibara, and Hisashi Tamaki, « Bus line optimization using multi-agent simulation model of urban traffic behavior of inhabitants applying branch and bound techniques », en, in: *IEEE*, July 2015, pp. 234–239, ISBN: 978-4-907764-48-7, DOI: 10.1109/SICE.2015.7285551.

[44] Ehsan Mazloumi et al., « An Integrated Framework to Predict Bus Travel Time and Its Variability Using Traffic Flow Data », en, in: *Journal of Intelligent Transportation Systems* 15.2 (May 2011), pp. 75–90, ISSN: 1547-2450, 1547-2442, DOI: 10.1080/15472450.2011.570109.

[45] João Mendes-Moreira and Mitra Baratchi, « Reconciling Predictions in the Regression Setting: An Application to Bus Travel Time Prediction », en, in: *Advances in Intelligent Data Analysis XVIII*, ed. by Michael R. Berthold, Ad Feelders, and Georg Krempl, vol. 12080, Series Title: Lecture Notes in Computer Science, Cham:
Springer International Publishing, 2020, pp. 313–325, DOI: 10.1007/978-3-030-44584-3_25.

[46] Patrick Mikalef et al., « The human side of big data: Understanding the skills of the data scientist in education and industry », en, in: *2018 IEEE Global Engineering Education Conference (EDUCON)*, Tenerife: IEEE, Apr. 2018, pp. 503–512, ISBN: 978-1-5386-2957-4, DOI: 10.1109/EDUCON.2018.8363273.

[47] Brice Morin et al., « Models at Runtime to Support Dynamic Adaptation », in: *Computer* (2009), pp. 46–53.

[48] Madzlan Napiah and Ibrahim Kamaruddin, « ARIMA models for bus travel time prediction », en, in: 71 (2010), p. 10.

[49] Mauricio A Herna Ndez and Salvatore J Stolfo, « Real-world Data is Dirty: Data Cleansing and The Merge/Purge Problem », en, in: *Data mining and knowledge discovery* (1998), p. 29.

[50] Fátima Trindade Neves, Miguel de Castro Neto, and Manuela Aparicio, « The impacts of open data initiatives on smart cities: A framework for evaluation and monitoring », en, in: *Cities* 106 (Nov. 2020), p. 102860, ISSN: 02642751, DOI: 10.1016/j.cities.2020.102860.

[51] Maarten Ottens et al., « Modelling infrastructures as socio-technical systems », en, in: *International Journal of Critical Infrastructures* 2.2/3 (2006), p. 133, ISSN: 1475-3219, 1741-8038, DOI: 10.1504/IJCIS.2006.009433.

[52] S. B. Pattnaik, S. Mohan, and V. M. Tom, « Urban Bus Transit Route Network Design Using Genetic Algorithm », en, in: *Journal of Transportation Engineering* 124.4 (July 1998), pp. 368–375, ISSN: 0733-947X, 1943-5436, DOI: 10.1061/(ASCE)0733-947X(1998)124:4(368).

[53] Marie-Pier Pelletier, Martin Trépanier, and Catherine Morency, « Smart card data use in public transit: A literature review », en, in: *Transportation Research Part C: Emerging Technologies* 19.4 (Aug. 2011), pp. 557–568, ISSN: 0968090X, DOI: 10.1016/j.trc.2010.12.003.

[54] Robert Gilmore Pontius, Olufunmilayo Thontteh, and Hao Chen, « Components of information for multiple resolution comparison between maps that share a real variable », en, in: *Environmental and Ecological Statistics* 15.2 (June 2008), pp. 111–142, ISSN: 1352-8505, 1573-3009, DOI: 10.1007/s10651-007-0043-y.
[55] PPIAF and Wolrd Bank Group, *Factors Influencing Bus System Efficiency*, URL: https://ppiaf.org/sites/ppiaf.org/files/documents/toolkits/UrbanBusToolkit/assets/1/1d/1d.html.

[56] Stephen Riter and Jan McCoy, « Automatic Vehicle Location - An Overview », in: *IEEE Transactions on vehicular technology* (1977).

[57] Steve Robinson et al., « Methods for pre-processing smartcard data to improve data quality », en, in: *Transportation Research Part C: Emerging Technologies* 49 (Dec. 2014), pp. 43–58, ISSN: 0968090X, DOI: 10.1016/j.trc.2014.10.006.

[58] Günter Ropohl and Society for Philosophy and Technology, « Philosophy of Socio-Technical Systems », en, in: *Society for Philosophy and Technology Quarterly Electronic Journal* 4.3 (1999), pp. 186–194, ISSN: 1091-8264, DOI: 10.5840/techne19994311.

[59] Tobias Schoenherr and Cheri Speier-Pero, « Data Science, Predictive Analytics, and Big Data in Supply Chain Management: Current State and Future Potential », en, in: *Journal of Business Logistics* 36.1 (Mar. 2015), pp. 120–132, ISSN: 07353766, DOI: 10.1111/jbl.12082.

[60] Brian Smith, William Scherer, and James Conklin, « Exploring Imputation Techniques for Missing Data in Transportation Management Systems », en, in: *Transportation Research Record: Journal of the Transportation Research Board* 1836 (Jan. 2003), pp. 132–142, ISSN: 0361-1981, DOI: 10.3141/1836-17.

[61] Chuanwang Sun et al., « Urban public transport and air quality: Empirical study of China cities », en, in: *Energy Policy* 135 (Dec. 2019), p. 110998, ISSN: 03014215, DOI: 10.1016/j.enpol.2019.110998.

[62] Ben Taskar et al., « Link prediction in relational data », in: *Advances in neural information processing systems* 16 (2003), pp. 659–666.

[63] Telang, Samir et al., « Intelligent Transport System for a Smart City », en, in: *Security and Privacy Applications for Smart City Development*, 2021, pp. 171–187, DOI: 10.1007/978-3-030-53149-2_9.

[64] Paul R. Tétreault and Ahmed M. El-Geneidy, « Estimating bus run times for new limited-stop service using archived AVL and APC data », en, in: *Transportation Research Part A: Policy and Practice* 44.6 (July 2010), pp. 390–402, ISSN: 09658564, DOI: 10.1016/j.tra.2010.03.009.
[65] Alejandro Tirachini, « Bus dwell time: the effect of different fare collection systems, bus floor level and age of passengers », en, in: *Transportmetrica A: Transport Science* 9.1 (Jan. 2013), pp. 28–49, ISSN: 2324-9935, 2324-9943, DOI: 10.1080/18128602.2010.520277.

[66] Alejandro Tirachini, « Estimation of travel time and the benefits of upgrading the fare payment technology in urban bus services », en, in: *Transportation Research Part C: Emerging Technologies* 30 (May 2013), pp. 239–256, ISSN: 0968090X, DOI: 10.1016/j.trc.2011.11.007.

[67] Alejandro Tirachini and David A. Hensher, « Bus congestion, optimal infrastructure investment and the choice of a fare collection system in dedicated bus corridors », en, in: *Transportation Research Part B: Methodological* 45.5 (June 2011), pp. 828–844, ISSN: 01912615, DOI: 10.1016/j.trb.2011.02.006.

[68] Wichai Treethidtaphat, Pattara-Atikom Wasan, and Sippakorn Khaimook, « Bus Arrival Time Prediction at Any Distance of Bus Route Using Deep Neural Network Model », in: *International Conference On Intelligent Transportation* (2017).

[69] Alejandra Valencia and Rodrigo Fernandez, « A method to calculate commercial speed on bus corridors », en, in: *Traffic Engineering & Control* (June 2012), p. 8.

[70] Lidong Wang, « Heterogeneous Data and Big Data Analytics », en, in: *Automatic Control and Information Sciences* (2017), p. 8.

[71] Di Weng et al., « Towards Better Bus Networks: A Visual Analytics Approach », en, in: *arXiv:2008.10915 [cs]* (Sept. 2020), arXiv: 2008.10915.

[72] Sun Yidan et al., *Bus Travel Speed Prediction using Attention Network of Heterogeneous Correlation Features*, en, ed. by Tanya Berger-Wolf and Nitesh Chawla, Philadelphia, PA: Society for Industrial and Applied Mathematics, May 2019, ISBN: 978-1-61197-567-3, DOI: 10.1137/1.9781611975673.

[73] Bin Yu et al., « Optimizing bus transit network with parallel ant colony algorithm », en, in: *Proceedings of the Eastern Asia Society for Transportation Studies* 5 (2005), p. 16.

[74] Liu Yu et al., « Calibration of Vissim for Bus Rapid Transit Systems in Beijing Using GPS Data », en, in: *Journal of Public Transportation* 9.3 (July 2006), pp. 239–257, ISSN: 1077-291X, 2375-0901, DOI: 10.5038/2375-0901.9.3.13.
[75] M Zaki et al., « Online Bus Arrival Time Prediction Using Hybrid Neural Network and Kalman filter Techniques », en, in: 3.4 (2013), p. 7.
<figure><img src="image_30.png" /></figure>
<figure><img src="image_31.png" /></figure>
**Titre :** Mobilité urbaine : Apprentissage automatique pour la construction de simulateurs à l'aide de masses de données.

**Mot clés :** Systèmes Intelligents pour les Transports Publics, Science des données, Apprentissage automatique, Jumeaux digitaux

**Résumé :** L'ère des données dans laquelle nous sommes entrés s'accompagne d'une explosion de ces dernières, tant en variété qu'en quantité. Le transport public est un domaine qui génère des données en masse, et les systèmes d'information sont souvent soutenus par des technologies anciennes qui peinent à maintenir l' existant en place alors que la quantité de données augmente continuellement. Ceci pose deux problèmes. Premièrement, les données massives générées par le réseau de transport doivent être qualifiées et enrichies avec des sources de données externes afin d'être utilisées pour la prise de décision. Deuxièmement, afin de limiter le nombre d'outils et la complexité de maintenance, il est souhaitable d'intégrer la gouvernance des don-

nées avec les outils d'aide à la décision pour permettre aux opérateurs non experts de manipuler ces données. A travers quatre contributions aboutissant à la proposition d'un cadre technique qui intègre le passé, le présent et le futur dans un système d'information traditionnel contenant des modèles a priori, cette thèse défend que l'intégration de divers ensembles de données hautement qualifiés provenant du monde réel dans un modèle spatio-temporel unique offre un moyen qualitatif, efficace et peu coûteux de faire des analyses, des prédictions et d'aider à la prise de décisions stratégiques pour les réseau de bus tout en dépréciant par ailleurs l'utilisation de systèmes de gestion des données au format multi-outils non intégrés.

**Title:** Urban mobility: Leveraging machine learning and data masses for the building of simulators

**Keywords:** Intelligent Public Transportation Systems, Data Science, Machine Learning, Digital Twins

**Abstract:** The so called data era we have entered in is accompanied by an explosion of data, both in variety and quantity. Public transportation is a data-intensive field, and related information systems are often supported by old technologies that struggle to keep up as the amount of data continually increases. This poses two problems. First, the massive data generated by the transportation network must be qualified and enriched with external data sources in order to be used for decision making. Second, in order to limit the number of tools and the complexity of maintenance, it is desirable to integrate data governance with decision support tools to allow

non-expert operators to manipulate this data. Through four contributions leading to the proposal of a technical framework that integrates the past, present and future into a traditional information system containing a priori models, this thesis argues that the integration of various highly qualified datasets from the real world into a single spatio-temporal model provides a qualitative, efficient and low-cost mean of analysis, prediction and strategic decision support for bus networks while depreciating the use of data management systems in a non-integrated multi-tool data management systems?