Serverless Architecture for Connected Mobility Solutions

The automotive industry is in the midst of a transformation to CASE (Connected, Autonomous, Shared, and Electric) as a mainstream strategy of every OEM (Original Equipment Manufacturer) and tier-one supplier. Connectivity is the foundation to deliver next-generation Autonomous, Shared, and Electric mobility. By 2030, about 95% of new vehicles sold globally will be connected, up from around 50% today [McKinsey, 2021]. Without connectivity, other initiatives in CASE are unachievable.

In this blog we will discuss:

• Challenges with server-based architecture (hosted solutions)
• Serverless architecture and benefits
• Solving CV (Connected Vehicle) Challenges Through Serverless Architecture
• Retrofitting Current CV Solutions

Challenges with server-based architecture

Early versions of connected vehicle platforms worked well on fixed infrastructure because mobility services were considered an add-on to the existing experience and supported a limited feature set. Legacy telemetry platforms are not easily extensible and cannot scale on-demand. Therefore, excess capacity gets deployed in advance to support vehicles during peak.

Traffic volumes increases during the day and decrease at night as observed in US Department of Transportation Federal Highway Administration Traffic Monitoring Guide (Page-26).

Time-Of-Day Variation

Based on the Time-Of-Day Variation graph above, it is evident the data generated by the vehicle would also be spiky. OEMs produce millions of vehicles per year, most of which are now equipped with embedded modems enabling connected applications. Let’s consider the spiky demand and do some quick math based on assumptions (column B) to understand scaling challenges faced by OEMs.

Connected vehicle data calculation

Depending upon OEM production volume, each OEM will produce 100,000 to 1M+ vehicles every year.  For this discussion, let’s assume 100,000 vehicles per year, which is fair for a mid-luxury to luxury-class EV with connectivity.

Data Ingestion: Ingesting and processing real-time streaming data requires scalability and low latency. Assume that 70% of the fleet is on the road during the peak hour. The fleet is publishing data to the connected platform every 10 seconds, resulting in 7000 messages per second ingested by the gateway for processing. Some of the CV use cases require data at higher frequencies (1-2 per second), e.g., geofencing and Usage-Based Insurance (UBI).  During off-peak times, only 1000 messages per second (10% of 100K fleet publishing every 10 seconds) are sent to the gateway. Managing infrastructure at scale requires continuously dynamic scaling by the CV IoT and cloud services. It puts the load on messaging gateways, rules engines, security policies, and the data pipelines to process data, detect events, and store the data for access through APIs. It’s not easy for all components to scale on-demand to optimize the use of infrastructure.

Storage: An OEM has vehicles with rich features that will generate a large amount of data – for example, 6.68 TB (100K x 70 MB) per month. This data compounds monthly, depending upon how it’s managed. If top OEMs plan to sell 1M vehicles a year, this means they would have to collect 66 TB of data per month. A connected vehicle has a capability to generate MBs of data per hour although we have assumed only 70 MB per month of data from each vehicle. In traditional server-based architectures, storage challenges are solved by purging data as necessary, sometimes on a monthly/quarterly basis. Most of the current CV solutions use NoSQL or RDBMS to store telemetry data. Storing massive data, for example, within three months, 19 TB in NoSQL or RDBMS, presents further data management challenges in availability, backup, recovery, patching, and monitoring.

Cost: The hosted infrastructure for legacy CV solutions requires fleets of servers for load balancers, brokers, and stream processors to support data ingestion, in addition to the storage challenges discussed above. Redundant servers are needed to achieve high availability and reliability, adding further costs. The database is a significant cost contributor for the CV platform—the server-based architecture uses multi-node RDBMS or NoSQL database clusters to store telemetry data. For example, over three months, 19TB of telemetry data stored in a managed NoSQL database would be a significant part of the total solution cost. The license costs and operational overhead for the underlying infrastructure should also part of the calculation of the overall cost.

Operations: Traditional CV platform infrastructure incurs high operational overhead. The cloud provides the infrastructure on demand but still needs effort and time spent into managing servers, operating systems, patch management, scaling, load balancing, availability, fault tolerance, provisioning, antivirus, anti-malware, vulnerability scanning, continuous monitoring, access control, rightsizing, server tuning, intrusion detection all of which incur costs.

Slow time to market for new features: Legacy OEM CV platforms support limited use cases. CV data on these platforms is underutilized. OEMs considering the vehicle as a digital space are planning features On-Demand Instance via continuous updates. The future in-vehicle experience will rely heavily on AI/ML, and it will require ongoing ML model training and deployment. The connected mobility architectures are evolving to support continuous feedback loops and updates needed for the software-defined vehicles.

Serverless Architecture and Benefits

Cloud services that scale linearly as demand increases remove the undifferentiated heavy lifting required to stand up a connected vehicle platform. We can leverage AWS serverless services to build a next-generation CV platform and focus more on differentiating and delivering features for end users. What is “serverless”? A serverless architecture is a way to build and run applications and services without having to deploy and manage your own infrastructure.

Benefit of AWS serverless:

• Serverless infrastructure automatically scale from zero to peak demands.
• Reduced operation overhead significantly because no servers to provision, administer or patch, scaling, right sizing, antivirus scan, etc.  This allows you to build and run applications without thinking about servers.
• Serverless applications take advantage of the concurrency model, and tradeoffs at the design level are evaluated based on concurrency.
• Serverless functions (for example AWS Lambda) are concise, short, single purpose and their environment may live up to their request lifecycle. Transactions are efficiently cost aware and thus faster executions are preferred.
• Serverless architectures are easier to manage in terms of correct resource allocation. Due to its pay-per-value pricing model and scale based on demand, serverless effectively reduces the capacity planning effort.

Solving Connected Vehicle Challenges Through Serverless Architecture

It is evident that a hosted solution is not easy to maintain using current server-based architectures because the costs will explode over a period of time due to the compounding nature. The average age of a car in the US has risen to 11.8 years [IHS Markit, 2019], plus OEMs planning to sell 100K to 1M+ vehicles per year means the number of connected vehicles on the road will be compounded every year. New use cases like remote diagnostics or event-based video streaming will drive GBs of data generated per vehicle, which is difficult to handle with a traditional server-based architecture.

Let’s see how AWS serverless services can solve the challenges highlighted in the server-based solution without continuously adding costly excess capacity.

Data Ingestion and Processing: One CV requirement is to have a secure, high throughput, dynamically scalable gateway, and ingestion infrastructure. AWS IoT allows devices to connect to the AWS Cloud securely, with low latency and low overhead. It can scale from zero to peak demands without any manual intervention. AWS IoT has a rich feature set such as device management, gateway, shadow, rule-engine, among others. IoT Rules allow your solution to act on messages in real-time. AWS IoT supports both HTTP and MQTT, so legacy and new vehicles can connect to a single service without the pain of managing separate infrastructures. Using AWS Lambda and Amazon Kinesis, a serverless stream can process data that automatically scales without provisioning or managing servers. Amazon Kinesis Data Analytics has built-in functions to filter, aggregate, and transform streaming data for advanced analytics. It processes streaming data with subsecond latencies, enabling it to analyze and respond to incoming data and events in real-time. Data ingestion and processing can be done without thinking of servers and deploying complex software.

Storage Requirement: Large volumes of data are ingested on a continuous basis from connected vehicles. AWS has purpose-built databases; one size doesn’t fit all. Amazon S3 can store all telemetry, image, and video data so it can be further accessed, analyzed and used for AI/ML. All transformed and raw data can then again be stored on Amazon S3. Any dataset which expects access via a web/mobile app, with a user experience expectation of milliseconds latency, should be stored in respective microservices database for e.g.; trip summary, notifications, fuel data, etc. can be stored in respective Amazon DynamoDB tables. The Amazon Athena interactive query service can be used to analyze data in Amazon S3 using standard SQL. Eliminating the need to provision compute to support a massive amount of data, AWS Analytics services bring right-sized compute to storage, on demand.

Cost: Serverless services use a “pay-per-value” pricing model, which means if a vehicle is switched on and generating data, costs would be incurred for message ingestion, processing, and storage. Raw data is stored in Amazon S3 open-source file formats, while derived/calculated data elements like the trip summary and driver score are stored in a database owned by the microservice. It reduces the storage costs significantly for large volumes of raw data since  Amazon S3 is less costly than managed database services for the derived/calculated data. Message costs are lowered by using AWS IoT Core basic ingest reserved topics. Usage of AWS IoT Core X.509 certificates are free, as a fundamental security capability included with the service. AWS Lambda pricing is metered and charged by per-millisecond (ms) execution duration. With serverless architectures, costs are typically reduced compared to traditional server-based infrastructure, because the solution is not incurring additional costs of managing servers, VM licensing, OS licensing, antivirus licensing, etc. AWS serverless services are priced based on actual usage, so you no longer have to waste money due to underutilization/excess capacity – or worse, unexpectedly hitting the capacity limits of your fixed infrastructure.

Operations:The true benefit of AWS Serverless services are heavy lifting of underlying infrastructure and services by AWS. Refer the AWS serverless benefits section above in the context of a CV platform. Serverless technologies are built on top of fault-tolerant infrastructure in multiple-availability-zones – in other words, multiple redundant AWS data centers within a larger AWS geographical region (AWS Regions), enabling you to build reliable services for critical workloads. By removing the burden of infrastructure management tasks from developers, businesses free up their teams to focus on applications, fostering greater innovation.

New Feature Roll-Out: Once data ingestion and the processing pipeline are set up on a serverless architecture, it is simple to add/change features or services without disrupting existing setup or going through complex deployment processes. For example, as diagnostic trouble codes (DTC) are sent from the vehicle to AWS IoT Core, a notification is sent. In this example, the notification is sent along with the vehicle trip history to an after sales system to improve the user’s service experience, or to support a fleet manager’s efficient operation to avoid an unplanned/controlled service event. This new feature can be implemented by adding a new AWS IoT Topic and/or a new action in AWS IoT Rules. All vehicle data is stored to a data lake on Amazon S3, so it can be consumed directly by data scientists for exploration using Athena. ML training jobs can also consume data directly from Amazon S3. You can also implement location-based services (routing, geofences, location-based marketing, etc.) quickly using Amazon Location Service. Reducing operational requirements allows your team to focus on developing new features to enhance in-vehicle user experiences.

Retrofitting Current CV Solutions

Existing IP or business logic can be reused by retrofitting the existing platform into a serverless architecture. For example, there is a driver score algorithm that is running on a container. It can be migrated to an AWS Fargate container with minimal or no change. You’d replace the existing hardware load balancer(s), MQTT stack, and certificate-based authentication with AWS IoT Core. AWS IoT Rules can be used to move messages into a Kinesis Data Stream or send it to respective business microservices. Existing solutions, to an extent, can be retrofitted onto a serverless architecture without a major re-write. Fundamentally, the idea is to replace the underlying software platform with AWS Serverless services, e.g., replace the existing MQTT broker with AWS IoT Core, or stream processing with Amazon Kinesis, etc. with minimal impact on existing core business logic. You can retrofit an existing solution based on the AWS Connected Mobility Solution reference architecture.

Conclusion

CASE is a mainstream strategy for OEMs, and a Connected Vehicle is the foundation of CASE. A connected platform should be reliable, cost effective, and free you up to focus on innovation and the best user experiences. AWS serverless services are deployed on multi-AZ architecture, redundant by default. Serverless infrastructure automatically scales from zero to peak demands, reducing operational overhead. Serverless uses a pay-per-value pricing model: if a vehicle is switched-on and generating data, only then do you incur cost for message ingestion, processing, and storage. All vehicle data gets stored in an S3 bucket and queried using familiar SQL. This allows data scientists or data analysts to access data quickly and correlate it with other datasets, for example.; creating a predictive warranty service for improved after-sales service. This guidance will allow you to look into your existing platform with the opportunity and benefits provided by re-architecting based on the AWS Connected Mobility Solution reference architecture. By examining your current metrics, e.g.; number of connected vehicles, message frequency, message request/sec, peak request per sec, data storage, etc., and current costs, you should see a business case for this re-architecture and migration. Our AWS Professional Services team is available to help you with re-architecting and business case justification for the move to AWS Serverless. We recommend you review: Honda Builds Serverless Connected Car Platform for Millions of Cars on AWS, highlighting how Honda has adopted AWS Managed Services, and AWS Serverless technologies, to reduce workloads for infrastructure management, reducing costs and expanding revenue streams.