State of the Art of Mobility as a Service (MaaS) Ecosystems and Architectures—An Overview of, and a Definition, Ecosystem and System Architecture for Electric Mobility as a Service (eMaaS)

Abstract

Mobility as a Service (MaaS) is a concept that aligns with both current and future mobility demands of users, namely intermodal, personalized, on-demand and seamless. Although the number of shared mobility, electric mobility and multimodal passenger transport users is rapidly growing, until now, the list of MaaS and electric Mobility as Service (eMaaS) providers is quite short. This could partly be explained by the lack of a common architecture that facilitates the complex integration of all actors involved in the (e)MaaS ecosystem. The goal of this publication is to give an overview of the state of the art regarding (e)MaaS’ ecosystems and architectures. Moreover, it aims to support the further development of eMaaS by proposing a definition and a novel system architecture for eMaaS. Firstly, the state of the art of the MaaS ecosystem is reviewed. Secondly, the eMaaS ecosystem that builds upon our definition of eMaaS is described and the MaaS system- and technical- architectures found in literature are reviewed. Finally, an eMaaS architecture that focuses on the integration of MaaS and electric mobility systems is presented. With the definition, ecosystem and system architecture presented in this work, the aim is to support the further development of the eMaaS concept.

1. Introduction

In recent years, the concept of Mobility as a Service (MaaS) has been gaining popularity within the field of passenger transport systems. MaaS is an innovative mobility concept that combines different transport modes to offer consumers the possibility to get from A to B in a flexible, personalized, on-demand and seamless way, through a single interface [1,2].

Likewise, an increasing number of organizations, companies, policy makers and the public are focusing their attention on the subject of electric mobility. Moreover, several cities and nations are adopting regulations that encourage the usage of electric modes of transport. For example, in the medium-term future, the Netherlands (by 2030), Norway (by 2035) and France & Great Britain (by 2040), intend to apply bans to sales of passenger cars with internal combustion engines [3].

With both the growing adoption of electric mobility and the expanding development of MaaS, electric Mobility as a Service (eMaaS) has the perfect opportunity to become one of the foremost solutions for today’s mobility challenges. eMaaS expands on the MaaS concept having as a complementary goal to provide users the possibility to go from A to B not only in a multimodal and seamless way but also in an even more eco-friendly way than just reducing car ownership as intended by MaaS.

In this context, with the aim of increasing the adoption of electric vehicles (EVs) by combining highly innovative technology and new business models, the “eMaaS project” was started in the beginning of 2018. The research presented in this work is situated within the context of this project. The project is an initiative of a group of European mobility SME’s which are already working towards making eco-friendly mobility more accessible [4] and are supported by the University of Twente.

The eMaaS concept is built upon the MaaS model. Its proposition is that to achieve multimodal, seamless and eco-friendly mobility, MaaS should be combined with Electric Mobility Systems (EMS) and Shared Electric Mobility Services (SEMS). Connecting these three concepts leads to our working definition of eMaaS:

electric Mobility as a Service (eMaaS) refers to the integration of multiple forms of eco-friendly transportation modes—including human-powered vehicles and electric public transport—and shared electric mobility services (e.g., e-car sharing, e-bike sharing, e-scooter sharing, e-bus, e-taxi) into a single mobility service that allows travellers to plan and go from A to B (and/or from B to C and/or vice versa) in an eco-friendly and seamless way. The service is offered through a single customer-centred interface and it also involves the prearrangement of electric mobility technologies and infrastructure (e.g., charging stations, energy contracts).

Table 1. Main differences and similarities between the Mobility as a Service (MaaS) and the electric Mobility as a Service (eMaaS) Models.

Characteristics		MaaS	eMaaS
Differences	Goal with respect to car usage	Reduce car ownership in a convenient (and more sustainable) way [6].	Reduce car ownership in a sustainable (and convenient) way while promoting and facilitating (shared) electric mobility and its infrastructure.
	Transport modes	Any type of transport mode.	Only eco-friendly transport modes.
	Main mobility solution	Public Transport usually seen as the backbone of MaaS.	Shared electric mobility as the backbone of eMaaS.
	Energy management	Charging infrastructure and its management are not strictly necessary.	Charging infrastructure and its management are needed.
Similarities	Design approach	Both models have a user-centred approach.
	Mobility model	Both models strive for multimodal and seamless mobility.
	Operational model	Both models rely on data sharing between Mobility Service Providers and can operate under Business to Consumer or Business to Business models.
	Travel functionalities	Both models have the same core travel functionalities—planning, booking, payment, trip execution support.
	Data sharing	Both models rely on the data sharing from Mobility Service Providers.

offers an overview of the main differences and similarities between the MaaS and the eMaaS models. As mentioned before, the eMaaS model relies on the MaaS model itself, therefore any other key characteristics of MaaS that are not mentioned in the table should be considered to be equal for both models. Moreover, with the increasing electrification of most transportation means and also the increasing offer of shared mobility services, a differentiation between both models will most likely not be needed in the mid-term future. Most of the MaaS characteristics presented in Table 1 are based on the definitions of MaaS by various authors as presented in the work by Sochor et al. [5].

Goal and Research Questions

The goal of this publication is to give an overview of the state of the art regarding (e)MaaS’ ecosystems and architectures. Moreover, it aims to support the further development of eMaaS by proposing a definition and a novel system architecture. The research questions that lead this publication are:

• What are existing (e)MaaS ecosystems and architectures?
• What elements and functions should an eMaaS architecture include to facilitate the integration and interaction of all actors within the eMaaS ecosystem?
• How does a system architecture support the further development of eMaaS?

2. Materials and Methods

The work presented in this article is the result of a thorough literature review and analysis of the MaaS ecosystem and published system architectures for such a concept. The objective of the literature review is twofold—(1) to provide a theoretical foundation for the definition and system architecture for eMaaS proposed in this article and (2) it aims to give an overview of the state of the art of the MaaS ecosystem and architectures and at creating a solid starting point for future work in the same area. The literature review was conducted following a systematic approach. For the literature research, the following criteria were followed.

• Database selection—In order to give the research presented in this paper a good scientific foundation, the literature research was conducted mainly in peer-reviewed general databases (such as Scopus or the Web of Science). However, due to the novelty and practical-oriented nature of the topic under investigation, it was decided to expand the scope of the literature search and take account of other search engines that include grey literature sources as well.
• Keywords specification—The literature research was specified (within title, abstract and keywords) for the combination of the following keywords—“mobility as a service,” “mobility-as-a-service,” “electric mobility as a service,” “electric-mobility-as-a-service,” “intermodal mobility,” “inter-modal mobility,” “multimodal mobility,” “multi-modal mobility,” “ecosystem,” “architecture,” “technical architecture” and “system architecture.” The search-string used was: (“mobility as a service” OR “mobility-as-a-service” OR “intermodal mobility” OR “inter-modal mobility” OR “multi-modal mobility” OR “multimodal mobility”) AND (“architecture” OR “ecosystem” OR “system architecture” OR “technical architecture”).
• Selection criteria—For each query a selection of sources was done based on, firstly, the subject addressed in the publication (or website); secondly, on the date of publication; and thirdly, on accessibility. For the first criterion, only sources that are related to either the transportation or mobility sectors were selected. For the second criterion, only sources from 2013 onwards were selected. Thirdly, only open access sources were reviewed. Additionally, the literature research was limited to sources in English language and, since the research is situated within the context of the eMaaS project, to sources focused mainly on the European setting.

Finally, the filtered literature research resulted in a list of 78 sources. Sixty sources from peer-review publications and the rest from grey literature sources. Each of these sources was individually reviewed and an analysis focused on finding clear examples of MaaS architectures and ecosystems was conducted. During the literature review process, some other sources were found and also reviewed. Lastly, the state of the art of MaaS architectures and ecosystems was synthesized in the results presented in the next section and all utilized sources are referenced in the list of references.

3. Results

3.1. State of the Art of the MaaS Ecosystem

The MaaS ecosystem has already been described by some transport specialists, researchers and MaaS developers. However, most of the first (e)MaaS ventures are still under development or at a pilot phase. On a high-level, the MaaS ecosystem consists of—transport infrastructure, transportation services, transport information and payment services [1]. Within the ecosystem, all different modes of transport and actors share the common objective of delivering a seamless mobility experience [6] and aim at improving the transportation network by exploiting the benefits of each service. Moreover, other actors such as local authorities or data management companies can also cooperate to enable the operation of the services and improve their efficiency [7,8].

An example of the MaaS ecosystem is presented by the Siemens Mobility Division in Reference [9]. There, the authors describe an ecosystem composed of four main elements—(1) service providers; (2) a business-to-business (B2B) platform; (3) mobility retailers; and (4) the travellers. This ecosystem was presented in the context of a MaaS project for the region of Tampere, Finland in 2016. The goal of the project was to integrate the existing and upcoming transport services with the operations of the local paratransit services [9].

Another example of the MaaS ecosystem, also at a general high-level, is presented by König et al. [10] in the context of the ‘Mobility As A Service for Linking Europe’ (MAASiFiE) project. The authors argue that MaaS ecosystems consists of four different levels—(1) the public and regulatory level, (2) the transport and logistics service providers level, (3) the mobility service level and (4) the end-user level. In the ecosystem, the transport and logistics service providers’ level corresponds to the supply side whereas the user interface corresponds to the demand side. On the other hand, the mobility service level and the public and regulatory level bring into play the most relevant actors in the ecosystem, that is, the local and national authorities (e.g., transport ministries and agencies, city planning department, safety and road agencies) and the MaaS operator, transport service providers.

Also depicting the MaaS ecosystem, Figure 1 shows one of the most used (and probably the first) examples of the MaaS framework [11]. The framework was presented by the Finish Ministry of Transport and Communications in December 2014 as an overview of the envisioned scenario for MaaS operators. A remarkable observation given by the MaaS-Alliance on the MaaS framework is that, although the framework includes the main services of the MaaS ecosystem, in a mature ecosystem some of the services could and most probably will be, non-mobility related [6].

An additional perspective of the MaaS ecosystem is the MaaS “business” ecosystem. The business ecosystem of MaaS is explained by Kamargianni and Matyas as “the wider network of firms that influences how a focal firm, in this case the MaaS provider, creates and capture value” [12] (p. 6). The business ecosystem proposed by Kamargianni et al. [12] is composed of several layers. It starts from the core business layer, which includes the MaaS provider as the focal firm. Then, the extended enterprise layer, which widens the view of the business supply chain to include the complementors and second-layer suppliers. Lastly, the outermost layer corresponds to the business ecosystem and adds regulators, unions, universities and other research bodies, investors and stakeholders to the business ecosystem [12]. Figure 2 shows the layers of which the business ecosystem is composed.

An addition to the MaaS business ecosystem could be the inclusion of blockchain-based smart contracts, as proposed by Karinsalo and Halunen [13]. With their model, the authors expect easy, quick and trusted transactions between the stakeholders in the ecosystem. According to the authors, the benefits are that all travel data can be stored in one ticket, information stays unaltered in blockchain and value-share as well as compensations in case of delays will be automatic [13] (p. 135). The blockchain-enabled MaaS business ecosystem proposed by Karinsalo et al. [13] is depicted in Figure A1 in the Appendix A.

3.2. The eMaaS Ecosystem

All in all, the MaaS ecosystems found in the literature seem to consider all relevant factors to guarantee the mobility of users from A to B in a seamless way. However, as explained before, the proposition of eMaaS is to offer users the possibility to travel in an eco-friendly way. Therefore, the eMaaS ecosystem is composed of the combination of Mobility as a Service (MaaS), Electric Mobility Systems (EMS) and Shared Electric Mobility Services (SEMS) as shown in Figure 3.

Within the eMaaS ecosystem, all three modules (MaaS, EMS and SEMS) are complementary. This means that, even when each of the modules offer mobility options for the user, eMaaS cannot be achieved by means of only one or two modules. An important reminder here is that eMaaS is built upon the MaaS model; therefore, the actors taking place in the MaaS ecosystem are also playing a role in the eMaaS ecosystem.

Firstly, the MaaS module is represented by the main mobility characteristics offered by MaaS namely multimodal, seamless, user-centred, data-driven, on-demand and with a single interface. This module also includes all the components involved in the MaaS ecosystem as described in the previous section. The main difference is now that the focal business within the eMaaS ecosystem is, evidently, the eMaaS provider. Moreover, in this case the transport operators and transport service providers must offer electric mobility solutions and the infrastructure is focused on electric mobility as well. Besides, regulations and policies should also be adapted to electric mobility.

Secondly, the Electric Mobility Systems’ (EMS) module brings the first part of the eco-friendly component of eMaaS. EMS “denote the interaction of actors, technologies and infrastructures that aims to achieve sustainable transportation by means of electricity” [14] (p. 4). Thus, the three main elements of the EMS module are (1) Technologies, (2) Actors and (3) Infrastructure. On the one hand, technologies play a central role in achieving electric mobility and therefore in reaching eMaaS. Technologies that take part in the EMS module are, for example, batteries, charging technologies, drivetrains and of course electric vehicles (EVs). On the other hand, eMaaS highly depends on how actors deal with the challenges of enabling, developing, using and boosting the usage of electric mobility. The main actors involved in the EMS module are manufacturers, suppliers, customers/users, service providers, governments and substitutes [14] (p. 7). Finally, infrastructure refers to the basic physical and organizational structure that enables the use of technologies by actors and makes electric mobility possible. The electric mobility infrastructure builds upon existing infrastructure in the sectors of transportation and energy. Examples of electric mobility infrastructure are charging stations, electricity grid, information and communication technology (ICT) and (electrified) roads.

Lastly, the Shared Electric Mobility Services’ (SEMS) module brings the second part of the eco-friendly component of eMaaS. Shared mobility is an innovative transportation strategy that enables users to gain short-term access to transportation modes on an as-needed basis [15], is characterised by the sharing of a vehicle instead of ownership and the use of technology to connect users and providers [16]. SEMS refers to the utilisation of EVs when providing shared mobility. SEMS adds up to the environmental, social, financial and transportation-related benefits that had already been associated to the usage of electric mobility and shared mobility simply by combining both. Examples of SEMS are e-car sharing, e-bike sharing and e-scooter sharing. Within the eMaaS ecosystem, SEMS can be classified in different models as presented by References [15] or [16]. In this article, the five models as proposed in Reference [15] were adopted, namely (1) Membership-based (e.g., e-bike sharing, e-car sharing, e-ridesharing, e-ride hailing, e-scooter sharing, e-bus sharing); (2) Peer-to-Peer (e.g., e-car sharing, e-bike sharing, e-scooter sharing); (3) Non-membership-based (e.g., e-car rental, e-limousine rental); (4) For-hire (e.g., e-car/bike/scooter sharing, e-ridesharing e-carpooling); and (5) Mass transit systems (e.g., e-Public Transport, airport autonomous shuttles). Therefore, by offering these models in combination with the previous two modules (i.e., MaaS and EMS), users will be enabled to travel in a way that not only reduces CO2 emissions and traffic congestion but also gives them multiple possibilities of transportation and allows them to save money by not owning a vehicle.

With the eMaaS ecosystem presented in this section all elements playing a role in the enablement of eco-friendly mobility are presumably covered, though the achievement of eMaaS is only possible if accompanied by a well-designed system architecture. Such an architecture must ensure the smooth integration of all elements in the ecosystem and should allow for effective interaction between them. In the next section, the state of the art of MaaS architectures is presented followed by our proposal of a system architecture that aims to support the development of eMaaS.

3.3. State of the Art of MaaS Architectures

As with MaaS ecosystems, MaaS practitioners and researchers have already proposed some MaaS architectures. A system architecture “defines the parts constituting a system and allocates the system’s functions and performance over its parts, its user, its super system and the environment in order to meet system requirements” [17] (p. 5). MaaS system architectures such as the ones presented by Siemens [8], König et al. [18], Datson [19], García Hernández (Ed.) [20], Ambrosino et al. [21], Pflügler et al. [22], Beutel et al. [23] or Callegati et al. [24] are useful conceptual references to describe the requirements, functions and capabilities of the components within the MaaS ecosystem. In the remainder of this section, a few examples of MaaS’ system architectures found in the literature will be briefly described.

One of the most common examples referred to in literature of a successful MaaS pilot is the SMILE project run in Austria. The goal of the project was to create a mobility platform that not only allowed users to be informed about all available means of transport but to let them book, pay and use them [25]. For this project, an architecture blueprint for a MaaS solution was developed. The goal of this architecture was to provide standardized and easy to integrate connectors that enable even smaller partners to use the full range of high quality services offered in the MaaS environment [26]. For the users, the data was selected and combined to provide the most suitable options for the requested trip (including the actual price) and then users had the chance to choose an option to book the entire trip—even with several mobility providers—without changing between different apps [25].

Even before the MaaS concept became a trend topic in the mobility sector, Beutel et al. [23] proposed a system architecture as an approach for the integration of heterogeneous mobility modes. Their approach was called “Mobility broker” and, in essence, is the same as MaaS. The “Mobility broker” architecture allows the collaboration of companies offering various means of transportation to offer a joint service to customers. Mobility Broker combines heterogeneous mobility service data, like time tables and car sharing places, using standardized open interfaces and well-known methods of data integration [23] (p. 1529). The conceptual Mobility broker architecture is depicted in Figure 4.

On a more technical level, König et al. introduced a technical MaaS system architecture in Reference [18]. The focus of this architecture is based on the use of web technologies, as those technologies show a profound basis for establishing new combined and integrated digital mobility services [18] (p. 20). The architecture is composed of four main levels, namely (1) the data provider level, (2) the individual service level, (3) the common MaaS service level and (4) the MaaS interface level. Moreover, processes and technologies required for final MaaS service provision are highlighted in this system architecture, whereas the roles and responsibilities are assigned to the business and operation models as depicted in the MaaS ecosystem developed by the same authors.

Another example of a conceptual system architecture for MaaS is presented by Pflügler et al. [22] in the context of digital mobility services for the smart city. The main objective of their work was to design a concept for the architecture of an open mobility services’ platform. The platform consists of four main layers, namely (1) data sources, (2) modular services, (3) integration layer and (4) solutions layer. The driving idea behind this platform was to make data available that already exists in many smart cities and create a mobility ecosystem that fosters the development of innovative mobility solutions based on the offered modular services. The concept for the architecture of an open platform for modular mobility services is depicted in Figure 5.

Based on the concept of federated Cloud Computing, Callegati et al. [24] describe an overview of MaaS and present its architecture as a stack of multiple tiers. The first tier comprises the eMobility Operators which are entities that “own, administrate and expose software functionalities regarding mobility, provided in a machine-readable form” [24] (p. 278). The second tier is composed of business intelligence services which are meant for e-mobility operators and provide insight on their performances [24] (p. 290). The third tier of the MaaS stack is that of MaaS Operators which are eMobility Operators that federate and integrate their services with those of other eMobility Operators and provided to their users information and transit services of other operators as their own [24] (p. 290). An overview of the MaaS stack architecture proposed by the authors is shown in Figure 6.

In a more specific context, S. Tuchen [27] proposed the Seamless Mobility Information Sharing (SMIS) architecture, which is an initial concept for integrating aviation, both commercial and urban, into MaaS. The architecture is built upon the System Wide Information Management (SWIM) program, which is a service-oriented architecture (SOA) that allows many different users to subscribe to the data at once. The goal of the SWIM program is to support information sharing among National Airspace System stakeholders by providing a communications infrastructure and architectural solutions for identifying, developing, provisioning and operating shareable re-usable services [27] (p. 2). An overview of the SMIS architecture and its layers is shown in Figure 7.

Although the existing conceptual architecture references offer an overview of the elements in a system architecture, there is not yet an open architecture that can be used as a base for the further development of (e)MaaS [6,28,29]. Considering this, in the coming section an innovative system architecture that aims to be a supporting pillar for the further development of (e)MaaS is presented.

3.4. The eMaaS Architecture

In this section a system architecture for electric Mobility as a Service (eMaaS) is presented. This architecture is composed of functional blocks and components that cover all the elements within the eMaaS ecosystem. One of the distinctive characteristics of this architecture is that it is more extensive than the ones intended for MaaS systems. It not only covers electric mobility requirements such as charging points’ management and EV fleet management but also combines elements that not all architectures take into account.

For example, while the inclusion of electric powered vehicles is acknowledged in some existing MaaS architectures, the explicit inclusion of the related smart infrastructure (i.e., smart chargers, which are becoming the standard in EV charging) is minimal. However, in the context of seamless travel, this clearly needs to be accounted for when planning a trip (i.e., to make sure that the assets have enough charge and/or that users will have enough chargers along their way).

In addition, the architectural approach proposed in this work includes a vertical (cross cutting) block dedicated to the use of data and analytics. Many MaaS architectures do not include data as a primary foundation and consider MaaS as the brokering or allocation of transportation services to users. However, in the current era where data is acknowledged as one of the most valuable resources, an eMaaS platform inherently has access to numerous data sources (e.g., user preferences (GDPR compliant), booking transactions, unusual events during journeys, contextual data (e.g., weather), vehicle data from telematics in fleet vehicles) and all these data can be used to support new services, both for mobility service providers (e.g., offering ways of optimized planning of assets) and for other interested stakeholders (e.g., policy makers, local power utilities, insurance companies).

As previously mentioned, one of the main differences between the MaaS model and eMaaS model concerns the type of transport modes offered. While many MaaS architectures and platforms emphasize (or exclusively focus on) public transportation systems with dedicated Application Programming Interfaces (APIs) focused on fixed schedules and stations, the eMaaS system architecture focuses on the more challenging shared mobility with potentially free floating assets and on-demand mobility services (as also emphasized earlier in Section 3.2 and in Figure 3).

To highlight the similarities and differences between the (MaaS) architectures found in literature and the system architecture proposed in this work,

Table 2. Comparison between elements covered by MaaS system architectures found in literature and the eMaaS architecture proposed in this paper.

System Architectures for (electric) Mobility as a Service	Type *	Functions				Stakeholders				Infrastructure
	Conceptual/Technical	Travel Functions **	Data Sharing	Data Analytics	Fleet Management	Users	Mobility ServiceProviders (MSPs)	3rd Party Systems	Policy Makers	Road and/or Charging	Information & Communication Technologies (ICT)
Siemens [8]	C	✔	✔	✘	✘	✔	✔	✔	✘	✘	✔
König et al. [17]	T	✔	✔	✘	✘	✔	✔	✔	✔	✔	✔
Datson [18]	C	✔	✔	✔	✔	✔	✔	✔	✔	✘	✔
García Hernández (Ed.) [19]	T	✔	✔	✔	✘	✔	✔	✔	✘	✔	✔
Ambrosino et al. [20]	C	✔	✔	✘	✘	✔	✔	✘	✘	✘	✔
Pflügler et al. [21]	C	✘	✔	✘	✘	✔	✔	✘	✘	✘	✔
Beutel et al. [22]	C	✔	✔	✘	✘	✔	✔	✔	✘	✘	✔
eMaaS architecture	C	✔	✔	✔	✔	✔	✔	✔	✔	✔	✔

* Type of architecture: C = Conceptual architecture; T = Technical architecture. ** Travel functions are: Planning, Booking, Payment and Trip Execution support.

offers an overview of the main elements covered by each of these architectures. For an easier comparison and overview of the components, four categories have been taken into account—(1) Type of architecture, (2) Functions covered by the architecture; (3) Stakeholders considered within the architecture and (4) Type of infrastructure covered by the architecture.

The eMaaS system architecture is presented in Figure 8. For a better understanding of the architecture, it can be divided in three main blocks, namely (1) Shared e-mobility, (2) Data & Analytics extension and (3) Other mobility & 3rd Party Systems. In the following subsections each of the blocks presented in the eMaaS system architecture and their components are explained.

3.4.1. Shared e-Mobility

eMaaS enables the transition from vehicle ownership to vehicle usage. Shared mobility facilitates this transition and electrifying all transportation modes supports sustainability. In this context, the eMaaS architecture needs to enable the sharing of a variety of electric transportation vehicles (cars, bikes, shuttles, scooters) both in standard car sharing as well as in ride sharing approaches.

Furthermore, the integration of these different services into a single, seamless trip-planning, -booking, -execution and -payment service, needs to be supported. In addition, as most of personal and private vehicle ownership is replaced by fleet ownership, these fleets need to be monitored (via telematics), managed and maintained by the service provider. Similarly, the specific charging infrastructure required for EVs also needs to be monitored and managed. In both cases, the architecture needs to be flexible enough to accommodate multiple vendors, systems and technologies. All those elements, as presented in the shared e-mobility block in the middle of the eMaaS system architecture depicted in Figure 8, are further explained in

Table 3. Elements of the Shared e-Mobility block in the eMaaS system architecture.

Element	Description
Mobility Providers	Owners of the vehicles.
Personal EV	Private EVs used in shared schemes such as peer-to-peer or ride sharing.
EV Fleets	Fleets (i.e., non-personal vehicles) include Fleet Management Systems (FMS), covering functions like maintenance and cleaning.
Telemetry	EV (and e-shuttle/bike/scooter) fleets include telemetry hardware; personal EVs have optional telemetry hardware.
Virtual Fleet	For vehicles, this is the pooling of multiple physical fleets into one virtual fleet for use by operators.
Charge Point	Owners of the charge points.
Private Charger	Own (and optionally operated) charging infrastructure—public or private (e.g., home, building).
Public Charger	Public infrastructure includes Charge Point Management System (CPMS) with telemetry (charger related data).
Telemetry	Private chargers include optional telemetry.
Aggregation	Facilitates seamless (vendor independent) charging (potentially with a single “charge card”) and future Virtual Power Plants (VPP) or Vehicle-to-Grid (V2G) scenarios.
Common Blocks	Functional blocks that are common across all (or almost all) shared mobility solutions.
Booking	Handling of user reservations (including user preferences).
User Management	Includes enrolment, access to user preferences, user data management, incentive programs, optional gaming.
Remote Access	Based on hardware installed in vehicles to enable smart phone lock/unlock access (may be managed by third party telemetry operator). Telemetry hardware also enables collection of vehicle (or charger) data.
Payment Management	All billing related functions; based on mileage, time or combination; including services such as repeating fees, insurance or roadside assistance.
Matching	Assignment and scheduling of vehicles based on reservations and availability. Optionally based on advanced optimization and advanced analytics.
Advanced Functionality	Functional blocks that enhance baseline shared mobility solutions.
Trip Planning	Navigation. Time estimate and optional advanced analytics based features (e.g., real time congestion, low pollution route choices.
Multileg Support	Enabling (and scheduling) multisegment trip with multiple vehicles—for example, first leg with e-bike, second leg with shared car.
Ride Sharing (RS) Support	Enabling trips with multiple riders—public shuttles (with dynamic route changes) and private, ad hoc carpooling.
Multimodal (MM) Support	Interfaces and inclusion of additional transportation and mobility modes—public transit, taxis and so forth.
User Preferences	Per user preferences including fixed and changing.
Fixed	Long-term (rarely changing) preferences possibly entered during enrolment.
Adaptive	Automatically changing preferences (e.g., based on season).
Historic	Enabling predictive capabilities based on past choices.
Per Trip	At a minimum, preferences on time, range/distance and price.
User Smart Device App	Single app to all user eMaaS features and capabilities. Including all preferences, bills, real-time status. Optionally, data sharing (GDPR compliant) for enhanced capabilities based on advanced analytics (e.g., preference learning).

.

3.4.2. Data & Analytics Extension

eMaaS, like many other domains, is data rich and data driven. Data originating from vehicles, chargers, operational systems (e.g., car sharing platforms) and users who opt in, give the ability to enhance and improve the services offered to users. The architecture therefore requires the capability to collect, process and manage the data (both real time and offline batch based) from all data producing parts at all levels of the overall system. Adding advanced analytics opens paths to prediction, optimization, recommendations and so forth. All data-driven functionalities, as presented in the Data & Analytics Extension block in the eMaaS system architecture depicted in Figure 8, are further explained in

Table 4. Elements of the Data & Analytics Extension block in the eMaaS system architecture.

Element	Description
Smart Data Broker	Brokering between data sources using “adapters” (per data source type).
Analytics	Multiple advanced analytics “engines” that can facilitate enhanced functionalities for baseline systems.
Preference Learning	Future functionality (Optional). Learning user behaviour, trends, patterns and using for enhanced predictive capabilities.
Dashboard and Visualization	Simple visualization tools both for operators and for (app) users on various data (raw or processed).
Optimization Engines	Optimizers underlying a variety of tasks such as vehicle assignment and scheduling, route planning accounting for charging during trip and so forth.
Advanced Routing	Dynamic routing based on multiple constraints and adapting to (near) real time changes.
Complex Event Processing	Processing of streaming (real time) data by applying rules/filters/etc.
External Data Sources	External data feeds to the Data Broker and Analytics blocks for delivering advanced data services and enhanced features.
External Databases	Any third-party database with relevant data (mostly relational).
Smart City Data	Available Open Data both historic and near real time; city proprietary data.
Other IoT Data	Third party, accessible Internet of Things (IoT) devices data (mostly streaming and real time).
GDPR CompliantUser Data	Data that can be shared considering both GDPR and user settings, including through app usage.
Policy Makers/Law Regulators	Data analytics outcomes allows for more efficient decision-making practices and better policy design based on evidence and up-to-date insights.

.

3.4.3. Other e-Mobility Providers & 3rd Party Systems

The long-term goal of eMaaS is a converged solution that also includes additional e-mobility such as public transport (e-buses, electrified light rail), taxis, transportation network companies (e.g., Uber, Lyft) and fleets of autonomous vehicles. Ultimately, the user needs to get from point A to B within some given timeframe and subject to some constraints (i.e., user preferences) with a seamless single payment method and accessible through a single mobile app. The architecture is therefore required to be sufficiently extensible and “future proof.” Moreover, complementary services such as roadside assistance or a 24/7 call centre ought to be inherently included in the offer for the users but would most likely be integrated by 3rd party systems. This kind of capabilities, as well as more mobility providers, are represented in the right-side part of the eMaaS system architecture depicted in Figure 8.

4. Discussion & Conclusions

In this paper, we have presented an analysis of the current state of the art regarding MaaS ecosystems and systems architectures. Although the literature is fairly limited, it already offers some examples that are useful conceptual references for the understanding of the MaaS model and its context. Moreover, some MaaS architectures have already been used in practice and have brought the first examples of functional MaaS models (e.g., SMILE).

An important remark of the research presented in this work is that it focuses on the European setting and the MaaS and eMaaS concepts themselves. Therefore, system architectures derived from concepts such as “Mobility on Demand” or the “Internet of Mobility,” which are terms more commonly used in North American contexts, have not been explored.

eMaaS is a concept that builds upon the MaaS model. As such, the MaaS ecosystem and MaaS system architectures serve as a foundation for the development of eMaaS and its system architecture. The addition of the eMaaS concept over MaaS is that the former guarantees eco-friendly mobility while offering the same benefits as the latter. Furthermore, by only offering shared mobility services, eMaaS contributes to further mitigate the underutilisation of public transport and motivates for abandoning car ownership. As previously stated in §1, although MaaS and eMaaS are not the same concepts (yet), due to the increasing electrification of the most common transportation means (i.e., cars, buses, scooters) and also the increasing offer of shared mobility services, a differentiation between both models will most likely not be needed in the mid-term future.

With the system architecture proposed in this work, all the required capabilities of MaaS and eMaaS are covered. Having a clear overview of the elements in the MaaS and eMaaS ecosystems and in their system architectures, helps in the development of the eMaaS approach by identifying the requirements, functions, stakeholders and interfaces that need to be covered when deploying the desired (eMaaS) services.

The eMaaS system architecture takes into account the additional elements of electric mobility systems (such as EV fleets and charging points) and shared electric mobility services (such as e-car sharing, e-bike sharing or e-scooter sharing and even extra mobility modes such as e-public transport or demand responsive transport). Moreover, it also supports the connection to (and from) multiple smart data sources (e.g., smart city data or Internet of Things (IoT) data). This connection enables the use of advanced data analytics (e.g., machine learning-based AI) to support new services both for mobility service providers (e.g., optimization of assets’ management) and for other interested stakeholders (e.g., policy makers and law regulators). In this way, data and its exploitation (subject to data protection and usage regulations and policies) are an integral part of the eMaaS architecture.

As previously stated in this paper, one of the propositions of eMaaS is that to reach eco-friendly mobility MaaS should be combined with electric mobility systems. However, the transition from MaaS to eMaaS is not simply replacing internal combustion engine vehicles (ICEVs) with electric vehicles (EVs) but a coupling to an adjacent domain (i.e., smart energy) via smart infrastructure. The connection to energy infrastructure is actually one of the strengths of the eMaaS system architecture proposed in this work.

An example of such (smart energy) infrastructure is e-mobility hubs, which are spaces where (shared) electric mobility assets (e.g., e-cars, e-bikes, e-scooters) and charging infrastructure are made available for rent on a single spot. Enabling a connection with e-mobility hubs is not only a strength of the eMaaS system architecture but also a great benefit for the further development of both, e-mobility hubs and eMaaS itself. The benefit comes from the fact that both share some goals in common (e.g., the promotion of electric mobility and the inclusion of charging infrastructure). Therefore, the faster the adoption of eMaaS, the faster the deployment of e-mobility hubs.

MaaS and electric mobility are, however, currently treated as separate things. While on the one hand, MaaS aims to reduce car ownership and focuses on achieving multimodal and seamless mobility. On the other hand, e-mobility focuses on electrification of transportation, its infrastructure and does not look (explicitly) at car ownership. Yet, both approaches can build upon each other more intensively. MaaS can be used as a way to get to know e-mobility and the other way around, e-mobility can be used as a means to achieve MaaS. Therefore, since eMaaS brings these two approaches together, by supporting the further development of eMaaS and the implementation of its system architecture, both MaaS and electric mobility are directly being supported as well.

A limitation of the architecture proposed in this work is that it has not yet been evaluated. This will be the subject of near-term future research. This work therefore serves as stepping stone towards a validated architecture design for eMaaS, as is the objective of the eMaaS project [4]. For the development phase a technical integration plan has already been designed (Phase 1). This plan is focused on an initial integration between project’s partners existing technologies that supports limited key requirements and enables a minimal viable product. The first step is planned to be around an integration with an initial one-way-flow of information and then to be used for analytics and visualizations, with future phases extending this state and becoming much more sophisticated (e.g., possibly doing some multimodal calculations and sending the result back for reservations’ planning). The integration phase is based on use cases that are concretely around fleet sharing (initially). Additional integration as well as the joint development of new capabilities (currently not part of the partners’ product) will take place later (in Phase 2).