OTA Processes Compliant with WP.29 R156 Explained with Real-World Examples

Welcome to this fifth installment of our WP.29 blog series, in which we will explain how OTA processes achieve compliance for the new UNECE regulation R156. For those just joining, we began with Breaking Down WP.29 before moving on to cover key aspects such as WP.29 Requirements & OTA System Considerations and How Uptane Meets the Key WP.29 Cybersecurity Management System Requirements. We encourage you to refer to these if you feel the need to refresh your memory or get up to speed.  

R156 requires vehicle manufacturers to have a documented process for OTA (over the air) updates and make this process available to approval authorities on request. This means that every aspect of the OTA software update process must be recorded and executed in a way that satisfies the regulation, otherwise it will fail to receive certification.

The idea of undergoing verification at every step might feel overwhelming. That is why we brought in Florian Rohde to debunk these fears with real-world examples. Rohde is an original founding member of vehicle software validation at Tesla, former director of integration validation at NIO, and cofounder of iProcess, a consulting company that helps automotive players to deliver better software by assessing, implementing and improving their processes and strategies.

‍

‍

OTA Compliance Requirements

“In order to have an OTA process in place, you have three sub-processes which are working together: Creation, Transfer and Receiving,” explains Rohde. But before we dive into the different stages in detail, let’s break down Chapter 7.1.1. Processes to be verified at initial assessment of R.156 to get a better understanding of exactly what these WP.29 process requirements are.

7.1.1.1. Processes at the Manufacturer

This specifies that the manufacturer must have a process in place to undergo certification. All processes must be documented and made available to certifying authorities upon request.

7.1.1.2. Unique Identifiers

All software versions and updates must be differentiable by unique identifiers to ensure that updates within the vehicle are valid. This requirement ensures there is a failsafe to prevent unverified or unapproved updates from being sent and received.  

7.1.1.3. Vehicle Software Database

This requires the keeping of a thorough record of each vehicle and its software history. This includes records of update failures as well as updates pending installation.

7.1.1.4. Vehicle Manifest

At any given time, different vehicles might have a different combination of software and hardware. To satisfy this requirement OEMs must have a full vehicle manifest allowing the traceability of all software and hardware changes to every vehicle in the fleet.

7.1.1.5. Vehicle Integration

OTA software update processes must include an integration verification mechanism by which the OEM can identify interdependencies between the updated system and existing systems in the vehicle.

7.1.1.6. Vehicle Grouping

Vehicle groupings make it possible to send targeted updates, therefore software must include the ability to group vehicles by a specific feature or identifier. This has to be everything from vehicle age to location, color, drivetrain, or trim level. For example, if an OEM needs to send an update that is only applicable to automatic transmissions, they need to have a process that allows them to distribute the update exclusively to those vehicles.

7.1.1.7. Compatibility Validation

Since different updates are being sent to various vehicles a process must be in place to validate the specific hardware and software combinations in a particular vehicle grouping. This is vital for future update rollouts, as it allows the manufacturer to assess the compatibility of new updates with existing components.  

7.1.1.8. Change Impact Analysis

Before any update is sent, it must undergo a thorough analysis to identify the potential impact on the entire system. Will the software update create problems when integrated into the system? And will the update do what it was designed to do once installed in the vehicle?

7.1.1.9. Feature Update Analysis

The next level of analysis looks at potential changes to customer-facing features and vehicle performance and examines whether an update will modify any existing features outside of acceptable parameters.

7.1.1.10. Safety Impact Analysis

This requirement ensures that measures are in place to test whether an update will integrate safely or result in new hazards. For example, an update designed to repair a headlight fault that inadvertently creates a braking issue would fail to pass the safety impact analysis.

7.1.1.11. User Information

Updates that transpire while a vehicle is in use can create an unsafe environment for the user. To satisfy this requirement, there must be a process in place to notify the owner of new software installations and changes. The owner must be given the option to accept or postpone the change depending on when the vehicle will not be in use. They must also receive notification of failed updates and installation issues.

7.1.1.12. Update Documentation

The final portion of chapter 7.1.1. Processes to be verified at initial assessment requires that every single aspect listed above be thoroughly documented and available for review on request.  

All twelve of these requirements must be satisfied by the OTA software update processes to obtain WP.29 compliance certification.

Creation Process

Every software update is triggered by a requested change. “Either you have a new feature coming in, you have an improvement of an existing feature, or you have a bug fix on an existing feature or integration,” says Rohde.

Requested changes are directed to a control board where they undergo thorough analysis. Before approval, a change analysis determines the effort required to deploy the update, including manpower and cost. Then an impact analysis assesses the effect the update will have on other modules after installation. Finally, updates are reviewed and tested concerning their safety impact on the existing system.

Once an update receives approval from all three levels of analysis it is passed on to the development department. This is where changes and update packages are created. The integration department figures out how to integrate the change into the system before sending it to be validated.

Validation is the final step before releasing the update into the cloud. It requires a team to run the change through the entire system to look for discrepancies, faults, and hazards. If the team finds anything amiss the update is sent back to the drawing board for further modifications and assessment. If everything checks out, the update is released into the cloud, where it undergoes the transfer process.

Alone the creation process satisfies more than half of the R156 process requirements:

7.1.1.1. Processes at the Manufacturer

7.1.1.5. Vehicle Integration

7.1.1.7. Compatibility Validation

7.1.1.8. Change Impact Analysis

7.1.1.9. Feature Update Analysis

7.1.1.10. Safety Impact Analysis

7.1.1.12. Update Documentation

Transfer Process

The transfer process involves sending the update package from its storage place in the cloud to the specified vehicles.

The cloud itself contains a vast amount of information regarding both firmware and vehicle information. It possesses a list of unique identifiers and software configurations that enable authorities to verify firmware distribution within the fleet. The firmware information stored in the cloud also provides vehicles with a means to verify whether they are permitted to receive the updates sent to them.

The vehicle information available in the cloud includes an inventory of vehicles, details regarding the components in those vehicles, the health and location of the vehicles, and a complete history of software versions and updates performed.

“Software updates can be very targeted to certain locations, for example, for cold weather improvements, or regulatory settings regarding exterior lights,” says Rohde. Vehicle health also plays a key role in the transfer sub-process. A car might be unable to receive software updates after being damaged in an accident or collision. The cloud keeps a record of the last update performed and abstains from sending additional updates until the car’s receiving mechanisms have been repaired.

How the Transfer Process Works:

The transfer process begins when the cloud initializes communication with the receiver, in this case, the vehicle slated for updates. After verifying the health of the receiver, the cloud checks the manifest to make sure that nothing has changed since the last software update was performed. If it finds something unexpected, perhaps an ECU was altered during an unscheduled service, the system will need to verify whether the update is still compatible.

Once the health and current software versions are verified, the cloud checks the connection channel with the receiver. “This is optional,” says Rohde, “but some companies prefer to run the update only over Wi-Fi and reduce costs of cell phone connectivity.” If the connection is good the update package is transmitted to the vehicle in one of two ways. It is either broken into subsets of data or transferred in its entirety. This is largely dependent on the size of the package which can affect transmission speed and effectiveness.

At this point, the transfer process has accomplished most of its purpose. All that remains is to wait for the receiver to send installation feedback. This is checked against integration and compatibility requirements. In the event of a failure, the process is reinitialized from top to bottom, which we will discuss in greater detail in the next section. A pass results in the changes being documented and the closure of the transfer process.

Between the creation and transfer systems, eleven of the twelve R.156, chapter 7.1.1. Processes to be verified at initial assessment requirements are satisfied. Along with having a process at the manufacturer level (7.1.1.1) and providing full documentation (7.1.1.12), the transfer sub-process achieves compliance for the following:

7.1.1.2. Unique Identifiers

7.1.1.3. Vehicle Software Database

7.1.1.4. Vehicle Manifest

7.1.1.6. Vehicle Grouping

Receiving Process

The receiving process is located within the vehicle itself and is made up of multiple components. A connectivity device with 4G, 5G, or Wi-Fi is required to receive the update package. A user interface allows the driver to communicate with the system and acquire information regarding software update status, and vehicle health. For security purposes, this is accessed via a secure vehicle gateway or hub. The receiver also includes several embedded components such as the car body, chassis and powertrain controllers.

Much like the previous two processes, the receiving sub-process involves multiple levels of checks and verifications. It begins when the receiver or vehicle gets a communication from the transfer process requesting information regarding the vehicle’s health, location, and existing software components. The vehicle then creates and uploads a full manifest and waits for the transfer process to compare it to the data history stored within the cloud.

Once verification is sent by the transfer process, the vehicle downloads the specified package from the transport server. Update packages normally include several files and updates for various embedded and Linux components. Before these can be unpacked the package must undergo a validation check to ensure that both the update and source are correct. This step is vital from a cybersecurity standpoint as it prevents the installation of unauthorized or third-party updates that could jeopardize vehicle and driver safety.

Having passed all security checks, the package is stored, and the updates are assigned to their designated components. This is where customer communication comes in. Before installing the downloaded updates, the system notifies the user that an update is available and gives them the option to commence installation or wait for a more convenient time. It must also inform the driver that the vehicle will not be available for driving the installation process.

When the driver has given their approval, the updates undergo installation, followed by a full system check. The vehicle goes through every single component and verifies whether the installation was successful and relays this information to the transfer process. A failure requires the entire process to be reinitiated by either the receiver or via a request to the server. If the update installation was a success the vehicle does a full system reboot and sends a confirmation report back to the server for documentation.

The receiving process satisfies the final requirement in chapter 7.1.1. Processes to be verified at initial assessment, as well as five other requirements.

7.1.1.1. Processes at the Manufacturer

7.1.1.4. Vehicle Manifest

7.1.1.5. Vehicle Integration

7.1.1.7. Compatibility Validation

7.1.1.11. User Information

7.1.1.12. Update Documentation

Who is Responsible for These Three Processes?

Although the bulk of the responsibility appears to be placed on the OEM, achieving compliance approval is actually a joint effort. “There is a moderator in most companies,” Rohde explains, “and eventually everybody contributing is responsible to help make this process successful.” The OEM will be the point of contact for approval authorities, but they must work in conjunction with third-party suppliers to display the proof required to pass certification.

What Type of Effort is Required to Implement OTA Processes?

There is no definitive answer when it comes to building or buying OTA software. According to Rohde, it depends greatly on the individual company’s stage of development. Those who have been working towards a great product with a dedicated and diligent team are probably quite close to reaching the end goal of certification. In contrast, those who have just started will need to be willing to dedicate a large amount of time and resources to a cutting-edge development and validation team. With both scenarios, the sooner the OEM incorporates these processes into their system, the easier it will be to achieve compliance.

Where Should OEMs Focus Their Efforts?

“The truth is, it’s a chain, and the chain only works if all parts of the chain are in place,” Rohde insists. An exceptional creation process is worthless if the transfer process falls short. In turn, if the creation process is ineffective, updates will never even reach the transfer and receiving processes. If anything, the most effective route to success is to focus on incremental improvements across the board.

How Can Sibros Help?

Even with a thorough understanding of the new WP.29 regulations, preparing for the 2024 compliance deadline can be overwhelming. Fortunately, existing OTA software solutions such as the Sibros Deep Connectivity Platform provide easy integration and evidence-based compliance to all WP.29 requirements. Before you invest time and resources to tackle approval standards and compliance alone, consider contacting Sibros to schedule a demonstration or contact Florian Rohde of iProcess with regards to process definition and implementation support.

‍