The Architecture of Mobility as a Service (MaaS): How AWS Modules Transform OEM Offerings

Published in

Storm Reply

8 min readOct 4, 2023

Introduction

Welcome to the ever-evolving realm of Mobility as a Service (MaaS), where the convergence of innovative technology and cloud computing is reshaping the dynamics of transportation. This article aims to dissect how Amazon Web Services (AWS) has become the backbone for enabling MaaS solutions tailored for Original Equipment Manufacturers (OEMs). From the foundations of shared mobility and connected car platforms to the integration of real-time notifications and anomaly detection, we will delve deeply into the AWS architecture that powers these transformative solutions.

The MaaS Landscape and OEMs
Connected Vehicles: A Key Enabler in MaaS
The Challenge: Building a MaaS Demonstrator
The AWS Solution Architecture
Future Scope & Conclusions

1. The MaaS Landscape and OEMs

Mobility as a Service (MaaS) is a novel concept that is garnering attention from various stakeholders, especially from OEMs driven to explore cutting-edge technologies to shape future mobility. An effective MaaS service can act as a potent instrument, encouraging a transition towards more sustainable transportation methods.
One viable approach for OEMs to embrace the MaaS concept involves offering shared mobility services. This enables vehicle owners to share their vehicles with other registered users through a cloud platform and a mobile application.

2. Connected Vehicles: A Key Enabler in MaaS

In the context of MaaS, connected vehicles are not merely an option but a necessity. As reported here, a connected vehicle is equipped with Internet access, allowing it to share internet access and data with devices both inside as well as outside the vehicle. This range of functionalities includes basic data communication systems like GPS as well as more advanced features like telematics and Vehicle-to-Everything (V2X) communication.

The Role of a Cloud-Based Connected Car Platform

A Cloud-Based Connected Car Platform, often run on leading cloud providers (a.k.a AWS), serves as an ideal data hub for managing connected vehicles for several reasons:

It centralizes data, simplifying service offerings.
It enables near real-time decision-making.
It ensures robust security.
It scales easily with growing data.
It supports integration with other services.
It is cost-efficient, reducing upfront expenses.

For vehicle owners, a Cloud-Based Connected Car Platform offers unprecedented control and flexibility over how their vehicles are used in a MaaS context. Through a user-friendly mobile app interface, they can opt into sharing services, set conditions like geofencing or speed limits, and receive real-time updates and notifications. The vehicle data sent to the cloud can also be used for anomaly detection, adding an extra layer of security for the service.

3. The Challenge: Building a MaaS Demonstrator

Creating a MaaS demonstrator requires an OEM connectivity platform that enables data extraction through streaming and integrates with external user management systems. This setup gathers data on owners, drivers, and vehicles. The OEM’s app interfaces with our solution for vehicle sharing and notifications.

Availability of a connected vehicle platform that can dispatch data sent from the vehicle, including streaming via Amazon Kinesis Data Stream service, for querying as the data source of our system;
Availability of a mobile app for presenting the service to users;
Availability of an OEM-managed API to obtain information about Users and vehicles;

The MaaS Demonstrator consists of the following interconnected components:

A backend comprising an API that exposes the booking functionality to the mobile app, and a relational database using MySQL to manage the following three tables: RentableItems, Rental, and Ratings. The backend is powered by step functions to manage reservation expirations and by an SNS Application Platform for Firebase Cloud Messaging (FCM) integration.
A Streaming Anomaly Detection module integrated with the previous components and the OEM’s connected car platform.

Target Functionalities

To provide a comprehensive understanding of the system’s capabilities, let’s explore the range of functionalities that the MaaS demonstrator aims to achieve:

Set sharing settings: Owners can limit speed and set geofences.
Vehicle search: Users filter vehicles by location, time, and sort order.
View available cars: App shows vehicles ready for sharing based on preferences.
Booking requests: Users send requests to vehicle owners.
Owner reviews request: Considers user’s star rating before decision.
Booking notifications: Users notified when request is accepted or rejected.
Track vehicle: Accepted bookings allow real-time tracking.
Digital key access: Users unlock cars through the app.
End-of-sharing alerts: Owners get location updates and digital key is revoked.
Owner rates user: Optional comment and star rating.

By focusing on these functionalities, the MaaS demonstrator aims to offer a comprehensive and user-friendly platform for vehicle sharing. The demonstrator will leverage various services, thereby ensuring a robust and efficient system that is capable of scaling to meet future demands.

4. The AWS Solution Architecture

In a Mobility as a Service (MaaS) project, the effective management of rentals and reviews requires a robust data model. The system is architecturally divided into three main functional entities, which correspond to tables: RentableItems, Rentals, and Ratings:

RentableItems: Here, vehicle owners (“Owners”) list time slot items that can be rented. Essential details like vehicle ID, geographic coordinates, time slots for availability, and various optional features like fuel type and maximum speed are stored.
Rentals: This is the transactional heart of the system. Users who wish to rent (“Renters”) create an instance of this class. Rentals link back to RentableItems through a ForeignKey, establishing a clear relationship between what is offered and what is being used.
Ratings: After the rental period, both parties can review each other. This class captures who is reviewing whom, along with the rating score and any optional comments.

Indexed fields in each class are optimized for quick database look-ups, enabling efficient real-time operations. Overall, the data model serves not merely as a repository but as a functional overview of how different actors (Owners, Renters) interact within this MaaS ecosystem.

The following Flow Chart summarizes the state transitions of the RentableItems and Rentals entities.

On the left branch, the owner can move a bookable slot from DRAFT (0) to PUBLISHED (1) or REVOKED (2). Step Functions manage transiction to the EXPIRED state (3). On the right branch, a Renter can go from PENDING (0) to either REVOKED (2) or ACCEPTED (1). The state becomes RUNNING (4) during the rental and ends in EXPIRED (3).

Backend API for Booking Functionalities

Now that we have a comprehensive understanding of the functionalities and data model, let’s delve into the AWS architectural elements that bring our MaaS demonstrator to life.

Network Architecture

We start by setting up a Virtual Private Cloud (VPC) in a specific AWS region to provide an isolated and secure environment for our MaaS system. The VPC includes both public and private subnets:

Public Subnet: This subnet hosts a Network Address Translation (NAT) Gateway, which serves as a conduit for outbound Internet traffic from resources in the private subnet.
Private Subnet: This subnet houses our RDS (Relational Database Service) instance, which manages MySQL databases for RentableItems, Rentals, and Ratings. It also houses our Lambda functions responsible for business logic like Booking.

API and Data Flow

The API Gateway serves as the entry point for the OEM mobile application. When a request arrives, it routes through the VPC’s Internet Gateway and then passes through the NAT Gateway, finally triggering the appropriate Lambda function located in the private subnet.

API Gateway: Handles incoming requests, supporting throttling, caching, and API composition.
Internet Gateway: Enables communication between resources in our VPC and the Internet.
NAT Gateway: This routes traffic from the private subnet to the Internet and forwards the responses back, ensuring high availability and bandwidth.

Event-Driven and Notification Components

The solution uses Amazon Simple Notification Service (SNS) to integrate with Firebase, enabling the sending of real-time notifications to the Android mobile application:

SNS: A pub/sub messaging service that integrates with Firebase, making it possible to send notifications to the Android platform application.
Firebase: Acts as the receiving end for the Android mobile application, requiring a Firebase project and valid FCM project API key for the setup.

The Step Functions begin at WaitingState, where they wait for the time specified by $.expirationdate . After this period, they transition to ExpirationState, where a specified Lambda function is invoked to send notifications and update the database item.

Infrastructure as Code

To ensure repeatability and version control, we use AWS CloudFormation along with the Serverless Application Model (SAM) to define our infrastructure as code.

In this AWS CloudFormation template, the architecture is designed to deploy backend services for a Mobility as a Service (MaaS) application. The stack is modular and makes use of nested stacks (AWS::Serverless::Application):

MaasDatabase to define the database and related resources (i.e. secrets)
MaasLambdas to define the API Gateway, Lambda functions, and Step Functions
MaasNetwork to define VPC, subnets, security groups, NAT, and other networking components
MaasStreaming to define the Glue database and Kinesis resources

Anomaly Detection

If you are expecting machine learning or rocket science, I am sorry to disappoint you. The anomalies we look for in our solution refer to the data sent in real time and processed in near real time by our components to indicate that the renter has exceeded the limits imposed by the owner in terms of speed and distance from the starting point. We could not trigger the notification for every sample that exceeded the thresholds, so we used time aggregations in Kinesis Data Analytics with Apache Flink SQL.

Adding a bit of complexity, let’s imagine we need to deliver the service in a region other than the one where the connectivity architecture is deployed. The data therefore arrives on the Kinesis Stream in one region and is replicated by a Lambda Consumer and Producer in a cross-region Kinesis, this adds a little latency but allows us to clean up the raw data and enrich it with other information at our disposal.
The data then arrives on an enriched-vehicle-data-streaming and is processed by an Apache Flink SQL application which, using the Glue Database and two Glue tables “vehicle_input_stream” and “vehicle_output_stream” created in the notebook with ‘connector=kinesis’, performs temporal aggregations via SQL commands (such as those represented by the code below) defined in a zeppelin notebook saved on Amazon S3.

The output is then sent to an output Kinesis stream that triggers the Anomaly Detection lambda to perform checks on the aggregated data and eventually sends notifications to the owner or renter.

Trying to put the pieces together, here is the complete architecture for our demonstrator.

5. Future Scope & Conclusions

The architecture outlined holds significant potential as MaaS evolves. OEMs can harness AWS to both scale and release new features. Future upgrades could integrate predictive maintenance, advanced anomaly detection, and urban infrastructure. It would be intriguing to integrate this kind of private sharing within multi-modal mobility services.

In summary, AWS and Storm Reply equip OEMs with the tools and know-how to innovate in the rapidly evolving MaaS landscape, combining connected vehicles, cloud computing, and user-focused design to shape the future of mobility.