WP.29 Requirements & OTA System Considerations

Welcome to our third blog post in our series explaining the importance of the UNECE WP.29 regulations. If you are just catching up, we have already laid the groundwork for understanding the regulations in Breaking Down WP.29 and discussed the specifics of the WP.29 Regulation Structure. 

The 2024 compliance deadline for the new WP.29 automotive regulations is fast approaching, forcing OEMs and OTA (Over-the-Air) software providers alike to implement changes and novel processes to assure compliance. Failure to do so could result in massive financial losses, including vehicle approval delays, trade restrictions, and legal responsibilities. 

To fully adhere to regulation requirements, manufacturers must understand what they are, what they mean, and how to provide adherence evidence to approval authorities. This article will address the main WP.29 requirements for the second regulation R156, which pertains to Software Update Management Systems (SUMS). We will cover key processes as well as specific requirements at both the system and software level. 

Information Security Best Practices

Under the new WP.29 regulations, OEMs are responsible for utilizing best practices for their information security systems. In other words, the vehicle manufacturer must be able to provide evidence that all relevant documentation will be securely stored and appropriate security controls are in place to protect that information. Employees must undergo intensive training concerning security procedures, documentation practices, and quality assurance.

For data protection purposes, all servers must remain secure and have regulated and monitored access. Data must also be made readily available to approval authorities in countries where the vehicle is slated for distribution. Failure to comply could result in production or distribution delays. This portion of the WP.29 regulation is not entirely novel in the automotive industry, as similar procedures have been required by other compliances such as ISO 27001 and SOC Type 2.  

OEMs have an additional layer of responsibility in that they must assure and verify that their OTA provider is following these best practices and the OTA software and data storage practices are in adherence with regional regulations. This can quickly become a pain point for OEMs that distribute products across multiple markets where regulations and requirements may vary. For example, products sold in Europe must also comply with TISAX (Trusted Information Security Assessment Exchange).

The Sibros solution complies with multiple international compliance standards for safety, security, and data privacy. Our quality management systems have been constructed to assure that all information is access controlled on secure servers with configuration controls in place. The benefit here is access to a single system that manages software updates while also handling various safety, security and data privacy regulations and standards required to operate in each country.

Version Check

This next requirement demands that software and system versions have unique identifiers and this unique identifier should only change when there is a change to the software of that component.  Moreover, as stated in the WP.29 paper, this unique identifier must also be easily readable via the use of an electronic communication or standard diagnostics interface. An individual component such as Body Control Module (BCM) can contain multiple firmware images such as a bootloader, calibration, and an application for which all should have a proper version to be able to uniquely identify their respective software component. A vehicle level package is a compilation of all in-vehicle ECU packages that can range from 20 to 80 or more ECUs, depending on the complexity of the vehicle network architecture.

Before an update is performed, the software version must undergo a validation cycle that checks the requirements at the system level, the software level and the hardware level. This is extremely important when it comes to thwarting and identifying potential security hacks during a vehicle update. 

Having a version check in place not only mitigates risk and helps track the progress during software development lifecycle, but allows regulation authorities to verify that the software versions running on the component matches what the OEM has defined. Evidence that this requirement has been met can be accomplished by providing details regarding the specific processes and verification tools.

Sibros’ Deep Connectivity Platform streamlines this requirement by verifying that firmware images on components are updated with the correct images and also by sending out requests to vehicles to receive all version identifiers.  The system executes the entire process by first creating the vehicle version manifest, which is part of the firmware package and is a collection of the ECU versions along with the metadata. This information is also used to determine whether the vehicle needs updating on a per-ECU basis. In the event of failure, Sibros’ Deep Updater identifies errors, retries and rechecks the versions to assure that the updates were successful. If there is a failure at any point during the software update process, the in-vehicle firmware uploads detailed deployment logs with information about the current software version to the OEM to further troubleshoot the issue. 

Target Identification Processes

Often times a software update will only apply to a subset of vehicles in a given model fleet. Take for example Ford’s 2020 LED headlight recall of 217,185 F150 trucks for lights being too bright representing roughly 28% of that model year fleet (Ford sold 787,000 F150’s in 2020). This part of the WP.29 requirements state that OEMs must have a process in place whereby they can identify target vehicles for a software update. 

The ability to rollout targeted software updates is arguably one of the most important capabilities for an OEM as it allows for creating specific target groups based on different vehicle attributes. These can be static attributes such as color, make, model, or transmission type, or based on variable and data specific attributes such as in the F150 headlight recall example. Sibros differentiates itself from other OTA providers with its Deep Logger product that dynamically analyzes incoming vehicle data, and alerts the OEM when software updates are required. 

Going back to the F150 headlight example, Sibros’ Deep Logger system can log data from all vehicles and identify only those vehicles experiencing the fault. It then uses diagnostic data from the affected vehicles to create a target group that requires the appropriate software package update in order to fix the defect. Once the OEM has developed, refined, and tested the software and has received proper approval, the Deep Updater system will send the software update exclusively to vehicles in the target group. 

As with all aspects of the WP.29 SUMS regulation, the OEM must show evidence to approval authorities of adherence to this requirement. Sibros OTA solutions cover all these requirements and allow the OEM to go above and beyond static target groupings to dynamically assess and fix software issues as they arise. 

Safety Assurance Mechanism 

Unlike a cellphone that can be updated anywhere and at anytime, vehicle updates come with a huge safety risk if performed inappropriately. An update that happens while the vehicle is on the road can jeopardize the safety of the driver, the passengers, and other innocent bystanders. This has already been seen in the automotive industry when a premature OTA update left one driver stranded for hours on a busy motorway. Moreover, as mentioned in WP.29, OEMs must determine what a safe state should be to manage failed updates based on their Hazard Analysis and Risk Assessment or HARA (for more information on HARA, refer to Section 6 of ISO 26262, Chapter 3: Concept Phase). A safe state should be implemented when it is not possible or desirable to roll-back to a previous version, even if it means that the vehicle will have reduced capability or functionality. 

It comes as no surprise that part of the WP.29 SUMS regulation requires a failsafe preventing software updates from occurring when the vehicle is in an unsafe state. This includes everything from recognizing when the vehicle is in use to accounting for insufficient power to ensuring the vehicle’s technology is able to accept the update. Anything related to a functional safety requirement must follow the recommendations from various chapters of ISO 26262, and must undergo safety analysis. In the context of a Software Update Management System (SUMS), an example of this functional safety requirement could be that the vehicle shall be stationary before a software update is executed. 

The OTA system must be able to establish that specific conditions are met before rolling out the update and must also restore vehicle function in the event of an update failure. Sibros’ software undergoes rigorous safety checks, including failure analysis, to provide validation that all technical safety needs as outlined in ISO 26262 are met. 

Sibros Solutions to Software Update Management Systems

Understanding the WP.29 Software Update Management Systems requirements is the first step towards a successful product launch. When partnering with Sibros, our Deep Connectivity Platform provides your company with evidence-based adherence to all WP.29 requirements. 

With Sibros solutions, OEMs not only get a compliant-ready OTA platform but also training and guidance in best practices for performing safe and secure rollouts. This includes how to implement phased rollouts, test for safety-related conditions, understand testing responsibilities, and establish safety assumptions.

Interested in learning more? Contact us for a demonstration of the Deep Connectivity Platform and understand how Sibros help your organization navigate the WP.29 system requirements for automotive Software Update Management Systems.