Designing Mobility Systems-of-Systems

Mobility as a service (MaaS) has emerged as a core component of smart city development. There are a number of definitions circulating around the smart city of the future, but basically it is about having a holistic perspective in the construction of a city that is economically, socially and ecologically sustainable with the help of technology.

An important part of the smart city will be smart mobility and transport solutions. In recent years, a vast array of new mobility services have been introduced. For instance, cities have been flooded with electric scooters and a large number of different car-sharing services have been introduced. Despite this, there are no city-wide services that allow residents to easily book a trip from A to B with a combination of several services. Rather, what we see on our streets is a hodgepodge of services that often do not survive for very long, while the interconnected system of transport services that would constitute real system innovation is missing. One reason for this is the lack of language with which to formulate a systems of system mobility solution. Although there are many initiatives around smart cities worldwide that deal with transportation, and many research activities in the area, they are usually carried out as isolated projects.

MaaS is also a popular research topic that involves the integration of various mobility services [1, 2]. There is a need to take account of different regulatory frameworks, infrastructures, and user preferences when implementing such systems [3]. There are many different actors involved in MaaS, such as vehicle operators, brokers that connect users to vehicle operators, users, and municipal and regional authorities.

Current approaches to MaaS are based in transport systems engineering and mostly consider them as integrated systems, i.e., they envision a system that is tightly integrated and controlled by a central orchestrator. This means that the technical architecture for a MaaS solution must integrate the different transport services tightly into a single digital platform [4]. There are obstacles in the form of data sharing and ownership issues as well as how to avoid silo solutions that lock-in the user to specific companies. From the perspective of companies involved in MaaS solutions, there is an understandable reluctance to cooperate too closely with competitors. But in order for the MaaS to be useful and gain enough market share to make a difference, there must be such cooperation.

Prompted by these possibilities to combine SoS and MaaS, we undertook a project (Maus) that investigated a systems of systems (SoS) [5] approach to mobility as a service by considering a scenario in a semi-rural area near a major Swedish metropolitan. In this paper, we describe some of the results of this project. Main results include a design method for SoS [6], a business model evaluation method, SoS architecture patterns [6‐9], and processes and methods for governance and management of the SoS, as well as a survey of existing SoS design patterns [10].

The main scientific contribution of this paper is to take a first step towards applying SoS concepts to MaaS.

This paper is outlined as follows. Section 2 introduces key SoS concepts, both standard ones and results of the Maus project. Section 3 illustrates the mobility SoS. We conclude with a summary and discussion in Sect. 4.

An SoS is a set of independent systems (CS – Constituent Systems) that interact to create capabilities that none of the constituent systems can achieve on their own. A CS can be part of several SoS at the same time. The independence of the constituent systems is a central ingredient in an SoS. An important question when studying and designing SoS is what entities should be considered as the CS. For a mobility SoS, this boils down to the deciding if the CS should be the individual vehicles that carry out the transports or the transport companies that own the vehicles. For mobility SoS, it is usually the vehicles that should be considered CS, but this can vary depending on which aspects of the SoS that are studied. In addition to the vehicles, a mobility SoS will also need to have support services of various kinds, such as travel planners and payment intermediaries. Such support services are CS of a special kind called mediators. Figure 1 shows this general structure of an SoS. A mediator can be seen as a special case of CS and is something that provides services necessary to organize the collaboration, but does not have the same degree of independence as a CS. In a mobility SoS, someone who manages an intangible service, for example for information sharing, payment transfer or developing proposals for constellations whose combined abilities solve the transport assignments, is a journey planner. An example of a mediator could be to ensure that the trip can be booked and payment can be made.

Bild vergrößern

In earlier work, different types of SoS have been defined [5, 11], for example depending on how much central control there is in the SoS. In a Directed or Acknowledged SoS, each CS is subordinated to a central control, while in Collaborative SoS the CS retain their control and choose when to collaborate. Here we will focus on Collaborative SoS that are also open and co-opetitive. An open SoS is an SoS which new actors can join. A co-opetitive SoS is an SoS whose constituents simultaneously both collaborate and compete.

What might an SoS solution for mobility look like? In the Maus movie (available at sos-4-mobility.​se or https://​www.​youtube.​com/​watch?​v=​e-DdHS5o6yk) we show this for parts of the scenario described here. The Maus project used the area around Harestad, north of Gothenburg, as a concrete case to work with. At the start of the project, a list of specific user stories and use cases was developed.

How would the people solve their transport needs today? Many of them would routinely choose their own car, because “all other ways are so hard”. Some would check out the possibilities of using public transport. Someone would call different taxi companies to get prices. Some would ride bikes. What these solutions have in common is that the people focus on the means of transport instead of the transport itself. If you want to make an optimal choice of transport, you need to contact several different transport companies and compare their offers. Many people will then choose to travel with their own car because it is the easiest. The purpose of the Maus project was to show how you can choose transport instead of choosing a means of transport. In the next section, we show what such a solution could look like.

Bild vergrößern

What is required for an SoS solution to be realized? There is a need for a robust payment service that enables the user to pay only once, and then distributes the money to all involved parties in a fair manner. This is one of the necessary mediators in the mobility SoS. Agreements are needed that regulate service levels and services that collect data on the quality of travel and goal achievement [9]. It is also important that all actors who are part of the SoS trust each other and that agreements are in place that regulate, for example, compensation levels and the consequences of delays and other problems.

Solutions are also needed to enable the users of the SoS to formulate their travel needs and for the SoS to match these with possible solutions. Here, it is important to specify what are acceptable waiting times and investigate the balance between cost and goal achievement. The major optimization problem posed by matching can not be solved exactly, which makes it important to study which trade-offs are acceptable. These services are best divided into two different mediators. One is the travel planner service. This mediator takes requests for transports and matches them to the available transport capabilities of the SoS. We have earlier [8] described how this could work. The other needed mediator is a user interface mediator. This service provides the interface between the users and the SoS.

Figure 2 displays the SoS structure that could be implemented. While we here include only one of each type of mediator, it is important to note that a SoS should be open for innovation and competition also for its mediators. If a new company develops a better travel planning service, it should be free to join the SoS and provide its service as a mediator that competes with the existing mediators.

In conclusion, we discussed some of the results of the Maus project and how SoS concepts could be applied to mobility and MaaS applications. We introduced some standard SoS concepts as well as new concepts developed within Maus.

The main contributions of this paper are to start the discussion on how to use SoS concepts to overcome some of the barriers currently preventing MaaS solutions and to present a first example of how a MaaS based on SoS concepts could be designed. The focus on the different perspectives that different roles in an SoS entail can contribute to better understanding of the roles and responsibilities within MaaS. By abandoning the idea of MaaS as a single system and embracing the co-opetitive SoS concept, it becomes easier to design solutions that both satisfy the needs of users and municipalities while still allowing the competition between actors that drives innovation.

There are ample opportunities for further research in this area. There is a need to further explore the usefulness of SoS concepts in transport and mobility research and implementing the ideas in demonstrations and pilots. Before this, however, it would be useful to perform large-scale simulations based on realistic travel patterns, to be able to quantify both the costs and the benefits of SoS mobility solutions.