Some blockchain startups are working on so-called “Mobility Operating Systems”. Various synonyms such as “Mobility networks” “Mobility ecosystems” or “Mobility Systems” exist, but they all center around the idea of building an open, standardized platform unifying multiple mobility providers to improve the interoperability between them. Mobility provider is a similarly vague term which includes all entities that provide any kind of mobility or mobility-related products and services along the automotive and mobility supply chain. Among other things, this includes:
- Providers of means of transportation: This includes the provision of public and private transportation, especially vehicle sharing companies but also vehicle manufacturers
- Payment processors: Refers to all parties that take care of financial transactions such as banks or payments apps
- (After sale) service providers: This refers to companies like mechanics, car parts dealers or insurances which take care of vehicles in circulation
- Mobility Infrastructure providers: This involves all entities that provide any kind of mobility infrastructure. Most prominently road agencies, parking lot providers and charging stations. In the future this might also include Proof of Location services for navigation, companies like XAIN for access control, or blockchain-based vehicle history databases.
- Regulatory bodies: Includes entities such as governments that govern and regulate the mobility sector in regards to mobility taxes or tolls.
More about (Blockchain in) the Automotive & Mobility industry here
Two such Mobility Systems are the Mobility Operating System (Mobility OS) and the Open Mobility System (OMOS). Mobility OS was started by Deon Digital, KI group, Daimler, and Achmea. OMOS by the MotionWerk GmbH, TÜV Rheinland and Fraunhofer FIT.
Both provide little details on their plans for building such Mobility Systems. Nevertheless, Mobility OS, for instance, explained that they want to improve collaboration between mobility providers through a common programming language, automated tests, and an API for access to services and smart contracts. Besides that, most of the information provided by these two Mobility Systems focuses on use cases and paradigms.
The following section deals with these use cases and paradigms in more detail.
Open and frictionless: Mobility paradigms enabled by Mobility Systems
In general, Mobility Systems should make mobility more open and frictionless. Frictionless centers around the idea of unifying all services and machines users need to get from A to into one app. For instance, when traveling abroad one app should unify all means of transportation (e.g. public transportation and shared cars), handle all financial transactions across the different payment processors, consider regulatory requirements such as tolls, and update insurance premiums dynamically (e.g. based on driving behavior). This also implies that machine-to-machine communication works as seamlessly. Examples include automatic exchange of traffic information between cars and autonomous toll payments.
Open centers around the idea of separating the application layer from the data layer (see below OMOS’s concept).
The data layer serves as a vehicle and mobility information storage. Examples for such vehicle and mobility information are:
- Vehicle information: E.g. vehicle location obtained through Proof of Location services
- Asset prices: For instance, electricity prices for electric vehicles
- Driving behavior: For instance, captured by startups like XAIN that integrate blockchains into cars)
- Service providers: E.g. a list of mechanics or parking spots curated through token-curated registries).
More information on blockchain-based vehicle information storage here.
Besides reducing friction, this separation gives users more data sovereignty and lowers the entry barriers for new competitors.
Increased data sovereignty for users
The resulting data sovereignty refers to a situation where users have more control over their mobility data. The applications are broad and vague but in essence, it allows users to migrate their data between providers, to manage data access rights and to delete data as they wish.
Lower entry barriers for new competitors and thus better products through increased competition
As the data layer is open to everyone, anybody can to build applications atop of with without the need to go through the arduous process of generating it first. This enables, for instance, the launch of new car sharing applications without bootstrapping a network of drivers and passengers because all drivers and passengers are already available through this open data layer. As a consequence, more competition is expected, and the expected consequence of more competition are better products for the possible use cases.
These possible uses cases and thus products are explained in the following section.
Exemplary use cases of mobility systems
Both, Mobility OS and OMOS have given exemplary use cases enabled by all-encompassing Mobility Systems. None of these use cases are new and many specialized solutions (i.e. solutions that work only on that particular use case) by other providers exist. Whereas such alternative solutions imply that these use case might become real one day, the same is possibly not true for all-encompassing Mobility Systems. This is mostly due to their broad range of use cases, the amount of competing specialized alternatives, and the lack of implementation details provided (or not provided) by Mobility OS and OMOS.
This does not, however, mean that mobility will stay fragmented, but rather that no single platform will be able to provide an all-encompassing system. A more plausible scenario is the unification of specialized applications through cross-chain solutions or similar.
Thus the use cases envisioned by Mobility Systems listed below should be seen more as an “inspiration” than potential use case of Mobility OS, OMOS, or other Mobility Systems for that matter.
Single Sign-ons (SSO) for unified access to services and machines
Mobility Systems enable Single Sign-ons (SSO) for unified access to all existing and new providers. These providers are services (e.g. car sharing company) or machines (e.g. the cars themselves). As such Mobility Systems can manage the access to services as well as machines (e.g. enabling temporary access to cars for trunk deliveries).
Machine-2-machine communication to enable cars to operate autonomous agents
If all relevant machines are connected over one network they can naturally communicate easily and exchange data between one another. For instance, this could turn cars into self-sustaining autonomous entities. Cars can be equipped with their own wallets and completely take care of themselves by earning and spending money autonomously. As such, they would autonomously earn money (e.g. through car sharing) and spend it on maintenance (e.g. charging themselves) or autonomous toll payments. An extension of such autonomous car, are crowdfunded cars where a group of people collectively finances and owns an autonomous car.
If all driving data is included in one system, traffic can be optimized more effectively than today where traffic data is siloed (e.g. Google Maps and Waze do not share their traffic data).
By storing location data on a trusted data layer a range of location-based services are possible. One are infrastructure-less fees. If vehicle locations are verifiable, fees such as taxes or tolls can safely be paid based on vehicle locations. However, because GPS-based location data can be spoofed, such use case are currently impossible. Proof of Location services try to fix that by bringing trusted geospatial data to blockchains. Besides infrastructure-less fees, a range of other applications such as location-based rewards are possible with trusted geospatial, enabled by such Proof of Location services.
More information on Proof of Location services here.
Blockchain-based vehicle history databases
By tracking vehicle data (e.g. mileage), a trusted source for vehicle information can be created. Such vehicle history databases help prevent fraud in the market for used cars, among other things.
There are already several startups building such vehicle history databases. This report covers these startups and vehicle history databases in more detail.
More information on blockchain-based vehicle history databases here.
All-encompassing driving behavior tracking
If people use Single Sign-ons (SSO) for all services, a more complete picture of their driving behavior can be created and to, for instance, calculate car insurances based on driving behavior. Also, the driving behavior data could be sold on data marketplaces.
Data marketplaces are online platforms that manage the exchange of data between publishers and subscribers. Publishers are people or devices that submit data. In the case of Mobility Systems publishers would be all the integrated mobility providers. As such Mobility Systems would provide a rich source of data.
Subscribers, which can be people or devices, use the submitted data. All kinds of data can be accessed through data marketplaces such as health data or social media data, and asset prices.
Data marketplaces are, for instance, useful for decentralized machine learning in the Automotive industry to exchange training data for autonomous cars.
More information on data marketplaces for decentralized machine learning here.
In theory, Mobility Systems sound great. They reduce friction in the mobility sector by unifying mobility providers, give consumers more data sovereignty and lower entry barriers for new competitors. Furthermore, a unified ecosystem of mobility providers would enable a range of interesting use case such as decentralized marketplaces, Single Sign-ons (SSO), or cars that operate as autonomous agents.
However, due to their complexity and the amount of competing specialized alternatives, the practicality of Mobility Systems is questionable. Moreover, the lack of implementation details provided (or not provided) by Mobility Systems such as Mobility OS and OMOS gives even less reason to believe in their practicality.
Nonetheless, the vision of Mobility Systems might become true.
However, their envisioned implementation – a single platform – probably not. A more likely scenario is the existence of specialized applications connected through cross-chain solutions or similar.