Scalable Mobility Markets Building Open MaaS Ecosystem

Transcription

1 Scalable Mobility Markets Building Open MaaS Ecosystem 1st International Conference on Mobility as a Service Tampere Taina Haapamäki FLOU

2 About us FLOU is an independent Helsinki-based research and consultancy company. We offer expertise in planning and integrating traditional and new mobility services as a part of transportation and land use systems. We are dedicated to provide smart city solutions for a better future. Modelling and analytics Demand modelling Traffic forecasts Simulation and routing Impact assessment tools Accessibility analysis Intelligent transport systems Mobility-as-a-Service concepts Systems architecture New technologies Automated vehicles Transport systems planning Feasibility studies Cost-benefit analysis Transit planning Urban economics Policy packaging

3 Contents 1. Project background 2. Transport market principles 3. Mobility-as-a-Service as a market solution 4. Approach to APIs 5. BOMaaS architecture 6. Conclusions and next steps BOMaaS - ICOMaaS 3

4 1. PROJECT BACKGROUND

5 In November 2016 Tekes, the Finnish Funding Agency for Innovation, together with FLOU Solutions Ltd. and the University of Tampere initiated a collaborative R&D project to define and develop an open, platform-independent API specification for new mobility services. A public-private partnership was formed to conduct the project, named Building an Open Mobility-as-a-Service Ecosystem with a Finnish Swedish approach (BOMaaS) BOMaaS - ICOMaaS 5

6 Project background MaaS is about cooperation. MaaS is about creating an open marketplace that will benefit the whole field by giving different stakeholders the possibility to thrive. The lack of common API standards is restricting the service variety and availability. We need to have all the partners at the same table to create a common mindset and standards. Where there s a will, there s a way. Creating a mindset for enabling MaaS by deepening the understanding of impacts Exchange frame definition and MaaS API standardization 1. FEASIBILITY ANALYSIS Costs and benefits of an open transport marketplace need to be clarified. Especially the socio-economic impacts of MaaS have not been discussed. 2. INFORMATION ONTOLOGY Before API standardization we need to agree on what we re actually exchanging in the market. 3. INTEGRATION Creating a common mindset requires bringing the partners at the same table. Integration starts with different stakeholders adapting the same standards. 1. COSTS AND BENEFITS OF MAAS Economic and social impacts of transport systems and added-value of open MaaS ecosystems will be clarified and presented in plain language. 2. REQUIREMENTS SPECIFICATION Specifying the exchange frame and API requirements will make it easy for players to enter the market. 3. PARTICIPATION Understanding the benefits and being part of the movement will create a will to take part in the marketplace BOMaaS - ICOMaaS 6

7 2. MARKET PRINCIPLES

8 Market principles related to transport The market is essentially a market of access. Transport itself is a cost that the player is willing to pay in order to access an activity 3 elements in transport system problems: Transport system, T Activity system, A Flow pattern, F Source: Manheim, M. Fundamentals of Transportation Systems Analysis, 1979 Mobility as a Service Access as a Service? BOMaaS - ICOMaaS 8

9 The price of anarchy If people make decisions based on internal costs, the outcome is less than system-optimal. By distributing travel differently, a jointly better outcome is possible Price of anarchy is the difference between user-optimised equilibrium and system-optimized equilibrium. It forms the reason for disrupting transport markets with e.g. public transport subsidies and congestion pricing Society benefits from a balanced transport system - value of accessibility realizes in land value This makes a great incentive for the cities to promote space-efficient and environmentally friendly transport systems

10 3. MOBILITY-AS-A-SERVICE AS A MARKET SOLUTION

11 Value of a private car IN TRAFFIC 5% of the time USE VALUE - Enables access to activities PARKED 95% of the time OPTION VALUE - Enables spontaneous access - 90 % of yearly travel budget is spent on costs related to private car. - In Helsinki region, a private car provides an average value of 4000 euros a year compared to second best mode option BOMaaS - ICOMaaS 11

12 Is it possible to create an attractive alternative to private car? BOMaaS - ICOMaaS 12

13 Core ingredients of Mobility-as-a-Service Information i MC2<MC1 Consumer democracy Decreasing marginal costs Accelerating service development BOMaaS - ICOMaaS 13

14 What does this mean to consumer? I can get where I want I get matched with others with similar needs and save money There is a great variety of transport services from which to choose from BOMaaS - ICOMaaS 14

15 MAAS BOMaaS - ICOMaaS 15

16 It s essential to build a joint offering but against the law to organize a cartel COMMON USER-INTERFACE MOBILITY AS A SERVICE CROSS-PLATFORM MARKET STRUCTURES BOMaaS - ICOMaaS 16

17 What happens if we don t adapt to the new world? Lack of options for consumers In an agile environment, companies can tailor their product better for customers needs Stagnation of markets As new companies do not enter the market, old ones have little incentive in developing their product Winner takes it all situation Monopoly market for the first service if new ones are not allowed to emerge Worse traffic problems With urbanization, we need innovative ways of handling the emerging traffic Price of anarchy is too big to be paid BOMaaS - ICOMaaS 17

18 4. APPROACH TO APIs

19 API Alternative market structures BOMAAS APPROACH MAAS OPERATORS MAAS OPERATORS MAAS OPERATORS UNIFIED MARKETS 1 COMMON PLATFORM Harmonized open APIs TRANSPORT SERVICES TRANSPORT SERVICES TRANSPORT SERVICES BOMaaS - ICOMaaS 19

20 5. BOMaaS ARCHITECTURE

21 MaaS actors Grouping of actors that was used in the background work. Any actor can have multiple roles. Mobility service provider A provider of a mobility service and supporting services Transport service provider Actors which provide a transport service Payment service Location provider Fleet provider Identification service A broker of payments between the user and the mobility service provider Collects and offers location information of users and vehicles A provider of trip chains and other service ensembles A service provider that identifies and confirms the identity of a customer or another service provider Broker of trip information Travel information provider Service registry An actor that provides information about trips and travellers An actor which has information about upcoming trips and provides it to the brokers A registry to which service providers can register their service and search for other services? Other actors providing services BOMaaS - ICOMaaS 21

22 BOMaaS reference architecture Sharing of location information Service specific API Standardised API Location provider Creation of user Conveying rides Validating tickets Conveying rides Certifying Certifying services Maksupalvelu Payment service Conveying payments Mobility service provider Conveying payments Combining rides Registration Search services Search mobility providers Transport service provider Service registry Sharing of location information Registration The ride Identification of user Fleet provider BOMaaS - ICOMaaS 22

23 Service layers User layer End users MaaS operators Publishes services Registers services Publisher layer Service layer Transport services Service registries Fleet services National Access Point Rental services Mobility services Uses services Audits and certifies Audits and certifies Agreement layer Identification services Auditing Agreement networks Certifying BOMaaS - ICOMaaS 23

24 Suggestions for solutions Trust chains Trust chains and network Few bilateral agreements Auditing of services through local actors Multistandard architecture Open for new service concepts Convenient integration of current services Possibility for step by step introduction Possibility for several parallel service channels De facto standards of the best solutions Decentralised structure No system critical actors Expandable to new areas No gatekeepers Everyone has the possibility to choose their own trust network BOMaaS - ICOMaaS 24

25 API Specifications BOMaaS - ICOMaaS 25

26 6. CONCLUSIONS AND NEXT STEPS

27 Conclusions and next steps In the long run it is crucial for the systems to be based on trust chains, multi-standard architecture and decentralized systems Without global trust chains, the markets will stay one-to-one and will eventually stagnate Decentralized systems will move the market from controlled to marketoriented According to market research, cities are the ones with greatest incentives for open mobility markets and should act accordingly. Nudges towards an open market are needed from them, but API management is not a civil service Service providers are a crucial input group In multi-standard architecture, API specifications will stay up-to-date but need continuous management (that should be as light as possible) Looking for contributors for API management! BOMaaS - ICOMaaS 27

28 Thanks. Taina Haapamäki Tel Sami Mäkinen Tel FLOU Pohjoisranta Helsinki Finland