By Anna Buttaboni, Manager at Storm Reply
By Sidrit Cela, BU Manager at Storm Reply
With so much experience in the fast-developing world of web and smartphones, end consumers are expecting more advanced connectivity with their vehicles.
At the same time, car manufacturers use telemetry data gathered from the vehicles to improve processes and offer new services. Thus, the connected car is becoming the “state of the art” in automotive for all car manufacturers.
Developing innovative and accessible software and services around the cars opens up new revenue streams, creates a direct connection with end users, and places brands in a leadership position within the market.
Introducing new touch points, such as Amazon Alexa for voice user interface, allows car manufacturers to design new user experiences offboard and open new business models.
Reply, an AWS Premier Consulting Partner, works closely with several players in the automotive industry. One of our most important customers is an original equipment manufacturer (OEM) whose strategy already includes connectivity services as key enablers.
Over the past few years, this customer built the foundation of a connected vehicle platform capable of collecting information from onboard units. They decided to partner with Reply thanks to our deep expertise on connected vehicles and Amazon Web Services (AWS).
Together, our goal was to evolve the platform towards more advanced features that change the way users and businesses interact with vehicles powered by AWS. This effort allowed the customer to unlock the return on investment (ROI) of the overall platform.
This post shows how the OEM, in partnership with Reply, has extended its connected vehicle platform with a set of features that enable new business logics corresponding to new remote functionalities for car management provided to drivers.
Among these features:
- Car remote control such as electric/hybrid vehicle charge status management, vehicle climate scheduling.
- Residual vehicle autonomy management.
- Send “point of interests” to the vehicle navigator.
All of the aforementioned functionalities are provided in a multi-channel fashion including mobile application and voice integration (home to vehicle) via Amazon Alexa.
The overall solution needs to enable the integration and interaction of three essential components:
- The car
- End user of the car
- Third-parties providing business services around the car
At Reply, we want to provide value-added services to end users, regardless of the complexity sitting in the interaction between components.
The customer’s preexisting connected vehicle platform manages low-level connectivity with the vehicles, and takes care of end-to-end encryption. Built by a third party, it’s also based on AWS technologies though its description is beyond the objectives of this post.
Vehicle-related data is exchanged via MQTT protocol, which provides bi-directional communication between the AWS Cloud and vehicles.
The end user may interact with the system through different touch points. As part of the project, users are provided with different interfaces with the car:
- Mobile app
- Voice assistants
All of them leverage standard APIs implemented using Amazon API Gateway.
AWS IoT Core is used under the “touch points” implementation to provide real-time notifications to end users, including feedback on command sent by users in the mobile application, or events sent by the mobile app, such as stolen vehicle notification.
Lastly, the solution provisions business services to end users by integrating third parties (insurance companies, payment apps, road map services) into the connected vehicle platform.
The entire backend solution is on AWS and fully serverless, using AWS Lambda functions and AWS Step Functions. This empowers the solution with native scalability, high availability, and speed while lowering the overall cost.
Figure 1 – End-to-end solution architecture.
In this section, we’ll walk through specific technical solutions that make the architecture modular, scalable, cost efficient, and innovative. The high-level architecture is composed of several components that connect vehicles to end-user touch points.
The solution is designed to scale to a large number of vehicles, and all flows are asynchronous according to the decoupling principle. This allows the solution to handle high request and vehicle volumes.
Data coming from vehicles are ingested by the platform and stored on AWS, while commands sent from AWS to vehicles are managed via queues and MQTT topics.
User interactions via mobile, web, and voice are driven via REST API and managed asynchronously by the backend logic (AWS Lambda) that’s in charge of query data stored on AWS. It interacts with vehicles by sending commands and receiving command outputs.
End users are notified of results via mobile app notifications using MQTT for in-app notification.
Voice interaction uses a dedicated component on AWS that’s in charge of handling voice-specific flows, such as authentication and voice interaction model. This creates the bridge between connected vehicle and voice services.
Finally, we describe the CI/CD pipeline to handle multiple microservices, testing, and delivery in compliance with company policies.
Figure 2 – Architecture and network details of flows from and to the vehicle.
Mobile App Touch Points: MQTT for In-App Notification
Mobile applications, both for iOS and Android, represent two of the main touch points provided to end users to interact with vehicles. Apps are crucial to deliver quick notifications, send commands to the vehicle, and receive immediate feedback.
In this case, speed and reliability are the two main challenges.
The solution that’s adopted to comply with these requirements leverages MQTT protocol to support real-time notifications to the apps because it’s simple, light, and easy to implement.
In addition, MQTT is designed to work on low-power devices as a lightweight protocol and has been used in many Internet of Things (IoT) devices and instant messaging systems.
The MQTT client and server handles the complexities of delivering messages reliably so the application is leaner and the effort of developers is kept under control. This enables them to concentrate on business logic development.
With this technical solution, Reply also addressed the need of having a mechanism for the mobile application to receive updates without the need to poll for information.
In all MQTT implementations, common security standards like SSL/TLS for transport security are used. For this reason, we can state that the data sent through MQTT is protected. Moreover, this choice is platform independent and both iOS and Android Apps can use it.
Mobile applications subscribe to a set of MQTT topics where an AWS-based IoT broker publishes notifications coming from the vehicle backend.
Finally, the usage of properly-designed MQTT topics as a channel to communicate with mobile applications can send messages for specific users, but also broadcast or multi-cast messages to a set of specific applications.
Voice Assistant Touch Points
In order to achieve home-to-vehicle integration, Amazon Alexa was a fundamental part of the solution.
There are two sides to building an Alexa custom skill. The first is the Voice Interaction Model where the skill name, invocation name, and all the intents and utterances are defined (developer.amazon.com). The other is the Programming Logic represented by the separated backend, where the logic that lives besides each intent is implemented.
Figure 3 – Architecture and workflow of home-to-vehicle.
The diagram above represents the overall architecture of how the custom skill on Amazon Alexa works. It all starts with the user’s statement; for example “Alexa, ask Connected Vehicle to close the doors of my car.”
That sentence spoken by the user is recognized by the device thanks to the wake word “Alexa.” At the same time, the device sends all of the information to the Alexa service in the cloud. The information is converted into text (Automatic Speech Recognition), and thanks to Natural Language Understanding the text is translated to what the user wants to achieve.
In the example above, Alexa recognizes the user would like to open a skill called Connected Vehicle, with the intent of closing the doors of the vehicle.
The backend contains all of the logic that manages the individual intents and controls user information and vehicle data, as well as its status and active services. If all checks are successful, the command is executed through a REST API towards the customer managed solution, which finally sends a signal to the vehicle to close the doors through an MQTT channel.
The flow then returns back to the Alexa backend with a response on the status of the remote operation execution, positive or negative. Finally, if everything goes well, the device responds to the user giving an indication on the status of their command: “The doors of your car have been closed.”
The developed backend is open to integration with more voice assistants and acts as a router for requests towards the connected vehicle platform.
For this reason, the end-to-end architecture to support voice assistant touch points includes two blocks:
- Frontend portion that is a technology-specific interface.
- Voice assistant backend that is a common component for all voice assistants.
The latter interacts with the connected vehicle platform that hosts the common logic for all touch points. It sends and receives information from the IoT block, which is the component that interacts directly with vehicles.
Such a common AWS backend receives the payload of the request from the frontend, identifies the function that has to be invoked from the connected vehicle platform, and manages the API requests and responses.
For all voice assistants, the frontend part that manages the dialogue flow and voice recognition is hosted on the specific platform. All cloud functions interact with the voice assistant backend via a REST API over HTTPS, securing communications using the OAuth2 protocol and specific API Keys.
This infrastructure allows developers to modularly add voice assistants as touch points without the need to reimplement the same backend logic multiple times.
In this way, we have a faster time to market for new voice assistants. Also, a unified backend leads to cost savings related to the infrastructure costs.
CI/CD allows for a multi-region platform (North America and EMEA) with automations for deployments and tests on mobile apps (Device Farm), APIs, and web portals (ECS on demand for Jenkins slaves).
The connected vehicle platform is used to manage vehicles in several geographic areas, so it has a multi-region deployment pattern. This strategy allows developers to minimize latency for requests coming from vehicles and from end users’ touch points.
Moreover, in order to minimize code management and deployment effort, all architecture configuration and code changes are applied through a CI/CD pipeline that integrates test automations.
As recommended by the AWS Well-Architected Framework, the entire architecture is defined as code using AWS CloudFormation. Changes can be tracked for each deployment, evaluated, and automatically applied. This allows developers to roll back easily and recover from any non-working configuration.
With this strategy, the customer is able to update all components frequently. In the same CI/CD pipeline, both architecture and code releases are integrated and go through several testing steps: automated unit testing, non-regression testing, and load testing.
At the end of each build and deployment, Reply’s DevOps process automatically notifies you about the outcomes and gives details of each testing phase. This allows developers and testers to identify issues on the code or the infrastructure in early stages (before production) for each release.
In this post, we introduced the journey of an automotive customer that wanted to extend their existing IoT connected vehicle platform.
The challenge faced and solved was to define a strategy to support the modular addition of components to implement new functionalities required by the evolution of connected services.
We described how Reply, together with the customer, was able to cooperatively design a global, scalable IoT architecture and implement it while managing operations and evolution of functionalities.
We also showed how Reply was able to develop the platform with an end-to-end view, from touch points (mobile applications, web portals, and voice assistants) to the backend architecture and logic.
The content and opinions in this blog are those of the third-party author and AWS is not responsible for the content or accuracy of this post.
Reply – AWS Partner Spotlight
Reply is an AWS Premier Consulting Partner that specializes in the design and implementation of solutions based on new communication channels and digital media.
*Already worked with Reply? Rate the Partner
*To review an AWS Partner, you must be a customer that has worked with them directly on a project.