Power-up your Self-Driving Vehicle: enabling ADAS through AWS

Welcome to the world of Autonomous Driving and Advanced Driver-Assistance Systems (ADAS), where cutting-edge technology and cloud-based solutions converge to shape the future of transportation. This article will explore how Amazon Web Services (AWS) plays a pivotal role in enabling self-driving capabilities for connected vehicles. From the vehicle basics to the elaboration of high-definition maps and the incorporation of real-time events, we will dive into the architecture that powers ADAS and HDM systems, showcasing the seamless integration of cloud services to enhance autonomous driving.

Vehicle basics

Let’s start with the basic principles governing an autonomous driving vehicle, which can be considered a specific case of a more general Internet-connected vehicle. An Internet-connected vehicle contains a telematics unit capable of sending and receiving data through a wireless network, typically using a real or virtual SIM card associated with a mobile Internet provider. In essence, it uses the same technology that powers our smartphones.

While there might be variations between automotive Original Equipment Manufacturers (OEMs), nowadays, most components are standardized in the industry, and some of their technical implementations can be mandatory. For example, the European On-Board Diagnostics (EOBD) regulation is obligatory in the European Union, and its architecture is described by the On-Board Diagnostic-II (OBD-II) standard. Interestingly, the diagnostic connector used to retrieve OBD information is also called OBD, and it is the same connector your mechanic uses to check for failures in your car’s electronics.

In a connected vehicle, the Electronic Control Units (ECUs) are the embedded systems responsible for monitoring and controlling the onboard electronics. ECUs consist of both hardware and software, and they can be updated via Over-The-Air (OTA) updates: one of the possible approaches to manage the update is to separate firmware and application management with FOTA and AOTA.

To enable communication between ECUs, Controller Area Networks (CAN) bus protocol is used, dating back to the early 90s. Any vehicle electronics issues are signaled through Diagnostic Trouble Codes (DTCs), including standard and manufacturer-specified codes.

Periodically, the vehicle performs a self-discovery of its ECUs.

ADAS: Advanced Driver-Assistance Systems

Now that we have covered the basics, let’s delve into the concepts of Autonomous Driving (AD) and Advanced Driver-Assistance Systems (ADAS).

An ADAS system encompasses any technology that assists drivers in various driving and parking functions. It can be managed by its own Electronic Control Unit (ECU) or be part of a larger subsystem.

Autonomous Driving is made possible by a sophisticated set of ADAS features that enable different levels of driving automation, ranging from Level 1 to Level 5, plus an “extra” Level 0, which provides no sustained vehicle control and only alerts the user. Most commercial models, such as everyday utility cars, fall into this category currently.

1. Level 1 (“hands-on driving”): In this level, the driver and ADAS share control. Examples include Cruise Control (where the vehicle manages the speed) or Forward Collision Emergency Braking. Many higher-level, commonly-used vehicles already have Level 1 capabilities.
2. Level 2 (“hands-off driving”): ADAS takes full control of the vehicle, but the driver must monitor the driving and be prepared to intervene immediately if the automated system fails to respond properly (hence, it is currently required to keep hands on the steering wheel, despite the level name). Unofficially, actual hands-off driving at this level is sometimes referred to as L2+.
3. Level 3 (“eyes off”): At this level, the driver is not required to pay attention to the driving status and may engage in other activities, but they must be prepared to intervene if needed. The ADAS functions as a copilot and can notify the driver to take back control if necessary.
4. Level 4 (“mind off”): The driver is not required to take any action, even in critical situations, and they may even sleep while the ADAS handles all driving tasks.
5. Level 5 (“steering wheel optional”): No driver interaction is needed, and the vehicle can handle any situation autonomously. Level 5 systems are so advanced that they may not even include a steering wheel and human intervention may be discouraged.

Currently, Level 4 and Level 5 autonomy is mostly theoretical, with most manufacturers focusing on developing Level 2+ and Level 3 ADAS capabilities.

Despite the different meanings, we will use the terms ADAS and AD interchangeably for this discussion.

Enabling the Autonomous Driving through AWS

Alright, now that we have covered the basics, you might wonder about the role of the cloud in all of this. How does AWS fit into the picture? Well, there are several essential backend operations that are crucial in enabling and disabling AD.

Connected vehicles require various services, but three, in particular, are highly specific to ADAS-equipped vehicles:

1. Verification of the vehicle’s eligibility for AD: Before enabling AD, the cloud system must verify whether the vehicle meets the necessary criteria and requirements to operate autonomously.
2. Elaboration and availability of high-definition maps: AD relies on detailed and up-to-date high-definition maps to navigate safely and efficiently. The cloud infrastructure plays a vital role in processing and providing these maps to the connected vehicles.
3. Elaboration of events that may turn off remote AD: Certain events or conditions may require turning off AD remotely for safety reasons or to comply with regulations. The cloud system is responsible for processing these events and issuing appropriate instructions to the vehicle.

Let’s dive into each of these aspects to gain a deeper understanding.

Part I: vehicle eligibility

In the vehicle basics section, we learned that a vehicle contains multiple Advanced Driver-Assistance Systems (ADAS); each ADAS is composed of one or more Electronic Control Units (ECUs), which are defined by their hardware and software versions. The vehicle should be able to self-disable AD if any of its ADAS components are faulty. However, there are two important reasons to have a backend system for this purpose.

Firstly, specific hardware or software bugs may exist that the vehicle cannot self-discover. In such cases, a backend service is needed to compare each ECU’s hardware and software version to ensure that the combination is compatible and can run safely.

Secondly, this operation cannot be a single event where the vehicle receives an OK/NOT OK answer and is enabled or disabled accordingly only once in the vehicle's lifetime. ECUs can be updated through Over-The-Air (OTA) updates, which each vehicle may receive at different times. Therefore, it’s important to continuously verify the vehicle’s capabilities, ideally each time it is started and at least once daily. The vehicle (through its provider) can call the backend system with a list of its ECUs along with their hardware and software versions.

The backend system, specifically a Lambda function, can verify for each ECU whether there are any entries in DynamoDB indicating defective combinations of hardware and software versions. If no defective combinations are found, it can be assumed that the vehicle can have AD enabled. By leveraging AWS services, we can ensure a highly available, scalable, and reliable service to perform these verifications.

To complement this service, a web portal built using AWS Amplify can be created. This portal allows engineers to manage rules through simple CRUD (Create, Read, Update, Delete) API operations. This way, engineers can easily create, update, and delete rules to fine-tune the behavior of the ADAS system and ensure safety and reliability.

With this architecture, we can build a straightforward yet robust system to enable and disable AD based on the vehicle’s ADAS health and capabilities.

Part 2: elaboration of HD maps

While point 1 described the “disabler” of the AD capability, let’s now explore the actual enabler: the elaboration of the high-definition maps (HDM).

Classic maps available from usual providers enable you to compute a route among streets to reach a destination. However, a High Definition Map goes far beyond this functionality. It is not only accurate to the centimeter but also includes various layers of detailed information, such as street shapes, exact lane definitions, positions and meanings of traffic signs, and even the location of light poles.

Numerous providers offer HD maps, including Here Maps, TomTom, and Google HD Maps. Each provider may have its own unique map composition, but in general, an HD map is composed of tiles (i.e., well-defined geographical polygons), that contain layers of data and are versioned.

The architecture operates as follows:

1. EventBridge Scheduler: The scheduler contains a rule that invokes the Lambda function in a repeating fashion, such as once a day.
2. Lambda Function: When triggered, the Lambda function calls the appropriate API to retrieve the versions for the layers and then checks DynamoDB for any updates. If updates are found, Lambda can trigger another event to initiate the batch job.
3. Batch Job: The batch job is responsible for the actual elaboration of the high-definition map. It downloads only the delta (the changes) for the current version, performs any necessary data transformation based on the vehicle’s requirements, and subsequently uploads the updated versions to Amazon S3.
4. CloudFront: Amazon CloudFront ensures that the elaborated map data is available on edge locations, optimizing content delivery and reducing latency for the connected vehicles.

This architecture facilitates an efficient and automated process to keep the high-definition maps up to date, enabling accurate and safe navigation for autonomous driving vehicles.

In conclusion, high-definition maps are crucial in enabling autonomous driving by providing detailed and accurate data for safe and efficient navigation. Different providers offer such maps, and they are structured in a way that allows for easy retrieval and updating of map data.

Part 3: Events

Finally, we need a mechanism to update the map information with events that could impact Autonomous Driving (AD) but might not be known at the map level. Examples include atmospheric events or construction yards that span multiple roads. Such events can be defined by a third-party provider or manually inserted by a user through a web portal.

Luckily, only a slight modification of the previous architecture is needed to accommodate these updates. When an event is received, it is processed by a Lambda function that extracts and computes all the roads and tiles affected by the event from DynamoDB. The Lambda function then updates the records in the S3 files, ensuring that the data is in a format suitable for consumption by the connected vehicles at a later time.

With this modification, the architecture becomes more robust and capable of dynamically incorporating real-time events into the high-definition map. This ensures that the AD system is aware of the latest changes and can adapt to evolving road conditions, enhancing the safety and efficiency of autonomous driving.

Conclusions

In conclusion, AWS is a powerful enabler of Autonomous Driving, revolutionizing the automotive industry with advanced ADAS and high-definition maps. Through the seamless integration of cloud-based solutions, vehicles can self-discover their ADAS components, access up-to-date and accurate high-definition maps, and adapt to real-time events efficiently. AWS's scalable and reliable infrastructure ensures safety, efficiency, and innovation as we journey toward a future of autonomous and interconnected transportation networks. As technology evolves, AWS will undoubtedly remain at the forefront, empowering self-driving vehicles with the intelligence and capabilities to revolutionize how we travel.