My first Connected Cars blog took a light-hearted look into a crystal ball of where car driving is going in the near (and far) future. In this post I’ll cover where we are now and highlight some of the technologies we are using already and will be using in customer solutions: AWS IoT Core, AWS IoT Analytics, AWS Greengrass Machine Learning all of which are backed up by some of the other technology behind the AWS Connected Cars framework.
Connected Car Reference Architecture
Specific customer details are beyond the scope of this blog. However, it is expected that every customer will have an adaptation of the AWS template solution which is publicly available on S3 as a starting reference. The following diagram is derived from this and slightly adapted to what we believe could be a very realistic target architecture today.
Connected Car AWS Reference Architecture
The left side of the diagram represents the connected vehicle and its connectivity into the AWS Cloud. This is based on the de facto standard protocol of Message Queue Telemetry Transport (MQTT), which was designed as an extremely lightweight Machine-to-machine communications protocol that has been adopted for Internet of Things (IoT).
The Device Gateway is the entry point into the AWS infrastructure; it provides IoT security through mutual SSL certificate authentication. Authorisation is enforced through standard AWS Policies, linked to the client certificate registered. The IoT Device is represented as a “Thing” in the AWS IoT core. It is attached to the policy and certificate.
The Lambda function labelled “Just in time Registration” has become the recommended common approach to do certificate activation provided that
- the certificate is related to a “Thing”
- it has been created with the AWS environment’s SSL Certificate Authority
For best practice, a specific intermediate “verification” certificate should be deployed. The intermediate certs are closely controlled by the manufacturers of devices to enhance the security.
Messaging Communications
MQTT is message-oriented, using standard Publish/Subscribe integration architectures to allow devices to send data or to subscribe to receive updates. A key part of AWS’s Connected Car vision is the IoT Rules Engine. This has the key role of routing incoming messages to different channels depending on the rules. This can be to store data on S3 storage, or a DynamoDB database directly or route via functions or Amazon Kinesis stream processes. The data stored in DynamoDB can be queried, interpreted and used for reporting or analytics. Kinesis Analytics can be deployed to detect problems (anomalies) and alert owners or the manufacturers.
Integration with Users using AWS Cognito
On the right of the architecture diagram, we can see a more standard Web Application architecture which is used to provide browser-based and mobile Applications to manufacturers, dealers and drivers. The human users log in using a more traditional username and password (or multi-factor authentication) which is developed using the Amazon Cognito Identity and Access Management service. This is a very flexible and configurable service, which includes the ability to define Role-based access control using Groups and Policies. The Amazon API Gateway then provides a standard RESTful API (you can upload your swagger definition or define a new API via the console). The APIs can link into IoT core, e.g. to return a Shadow content, or can be routed to expose data from the vehicle health report table or from historic diagnostics.
New AWS Technologies ideal for Connected Cars
AWS IoT Analytics
AWS IoT Analytics Components (future)
As well as linking with Kinesis Analytics, AWS recently made IoT Analytics generally available (GA). The concepts here are to define Channels, Pipelines and Data Stores, which tend to be time-series based on streams of inbound diagnostic trouble code (DTC) data from the connected devices.
The Data science challenge is then to build the Datasets that can be used in Machine Learning notebooks or simply visualised using a BI Tool such as Amazon Quicksight. These are all very exciting future possibilities.
Extending Technology to run functions on Connected Cars
AWS provides a number of device SDKs for developing and running the client software. They also provide a microcontroller-oriented operating systems (FreeRTOS) and the capability to run some services at the edge through AWS “Greengrass“.
AWS Greengrass ML Inference (future)
Greengrass can run Machine Learning (ML) inference locally and complete the loop to update the car for automated vehicle services with models developed and tested in the Cloud. Currently (June 2018) AWS Greengrass is only supported in the Frankfurt Region within Europe although it is expected to roll out to other regions at some point.
Where we are now with Connected Car Technology
The following diagram is an alternative view of the end to end application using other AWS services. The Console involves significant back-end logic and so it is logical to deploy an administration console on AWS Elastic Beanstalk to benefit from the auto-scaling, management and ease of use. We develop our front-end using Angular to carry out device and vehicle management.
Cognito, which is one of my favourite AWS services, can easily be extended to deal with federated sign-in and it also integrates with the core AWS IAM for authorisation. It can also be integrated with external identity providers including an enterprise Active Directory or a SAML 2 Identity Provider. Alerting via AWS Simple Notification Service, providing Email and SMS notifications, will be integrated in future.
A key central concept in IoT is the device “Shadow“. The shadow is a server-side data store of the current state of the IoT device. The shadow is updated via messages from the device containing “reported” attributes. The applications can, with appropriate authorisation, send “desired” updates to the device. A simple example, mentioned in our earlier blog, could be to set the air conditioning temperature.
In the simplified architecture view of the AWS solution (below) the various parts of the core AWS IoT service are highlighted, including the current state and device shadow.
Vehicle Communication and Applications
These services and the architecture are evolving and new AWS services like AWS IoT Device Defender are emerging. Device Defender makers it easier to secure and monitor devices within the eco-system. We are especially diligent about end-to-end security given the threat of cyber attacks on IoT and car telematics. We are even more interested in leveraging the Rules engine to integrate with AWS IoT Analytics and Deep Learning.
Ultimately, closing the loop and implementing local AI routines will help deliver the advanced vehicle solution we talked about in the previous blog.