A couple of weeks ago, I posted an article about a United Nations Economic Commission for Europe (UNECE) directive, titled UNECE R-155 "Uniform Provisions Concerning the Approval of Vehicles with Regards to Cyber Security and Cyber Security Management Systems." R-155 suggests a radical departure from how the automotive OEMs have previously done business. But it isn't the only new mandate that they will need to address; the other one is UNECE Regulation No. R-156.
As the numbering implies, R-156 is a companion piece to R-155 and it will be enforced in the same way, meaning through audited certification of compliance. The key point, and one I keep repeating because it appears that 52 countries are seriously thinking about implementing it, is that all future automotive type approvals will hinge on certified proof of compliance with both regulations. I could get sidetracked on all of the good reasons why that ought to be the case. But suffice it to say that the critical issue for U.S. automakers is, simply put, it appears that R-155 and R-156 must be complied with or you will not be able to sell your cars in the EU.
R-156 prescribes a uniform set of requirements for managing in-vehicle software updates (ECE/TRANS/WP.29/2020/80). It instructs the approval authorities of the UNECE signatories to confirm the presence of a R-156 conformant software update management system (SUMS) prior to granting type approval. That applies to any vehicle requiring software updates, which is basically every car manufactured today. Hence, anybody planning to do business in Europe after July of 2024 (July 2022 for new vehicle types) needs to decide how they will implement an R-156 conformant SUMS.
R-156 and the type approval process
Manufacturers apply to local approval authorities for certification of their vehicles. That application is accompanied by evidence that a R-156 conformant SUMS exists for that vehicle and that the SUMS embodies practices conformant with the best practice for software update management as specified by R-156. It should be noted that those practices are not explicitly described in ISO/SAE 21434. So, conformance with R-155 does not imply compliance with R-156. Conformance with R-156 requires a different set of practices as specified in the regulation.
Once the approval authority has successfully audited each manufacturer's SUMS, a certificate of compliance is granted. That certificate is valid for a maximum of three years. However, the approval authority may at any time verify continued compliance and the vehicle type approval can be withdrawn if the requirements that are laid down in R-156 are not complied with. If approval is withdrawn, then the interested parties are informed as such and regulatory consequences apply.
By the terms of UNECE R-156, every subsequent modification of the software in a vehicle type that affects its technical performance and/or documentation requires the manufacturer to notify the authority granting the original approval. The authority may then either decide that whatever modifications occurred continue to comply with the requirements of the prior type approval. Or it may require a further test report from the technical service responsible for conducting its tests.
In addition, the approval authority that has granted type approval may at any time verify the conformity of the control methods that are applied in each production facility. Typical frequency of these verifications is once every three years. But the approval authority may also periodically validate that the update processes used by the vehicle manufacturer are compliant.
What does compliance involve?
Vehicle type approvals will require documented proof of compliance with the requirements of R-156. Essentially, that requires the creation of a documented baseline of software and hardware configuration items (SWCI/HWCI) for every applicable initial and updated software version utilized in a vehicle type. The items in this baseline must be uniquely identified and labeled and the baseline must contain all necessary validation data for an approved type. The process requirements are as follows:
Vehicle System Configuration Management – Every individual SWCI/HWCI baseline will be given a unique RXSWIN vehicle type label. This label will enable the vehicle manufacturer to manage all configurations of every baseline that is associated with an individual RXSWIN. In order to do this, a RXSWIN is created, assigned, and maintained for the configuration baseline for a vehicle type. If an update adds, alters, or enables any functionality that was not present, or enabled, by the original approval, or alters or disables parameters or functions that are defined by the regulation, then the correctness and compatibility of the updated software must be validated, verified, and recorded prior to release. Then configuration management will identify and record any changes to the existing software baseline. Both individual RXSWIN labels and associated unique baseline identifier labels must be updated as applicable.
Compliance – In addition, there must be a process that will enable the vehicle manufacturer to make all relevant compliance information available to the responsible authorities or their technical services upon request. This may be for the purpose of initial type approval, or for conformity of production, market surveillance, recalls, and Periodic Technical Inspection (PTI) requirements. That includes documentation that describes the configuration baseline of any associated type approved system both prior to (archive) and after (current baseline) an update. That also includes the unique identification information for the type approved system's hardware and software (including associated version baselines) and any relevant vehicle or system parameters.
Documentation of the Update – Specifically identifies and documents the vehicle baselines that will be updated for the vehicle type. Documentation will describe: the purpose of the update; what systems or functions of the vehicle the update may impact; which of these are type approved (if any); whether an update impacts requirements of the type approved system; how the update will be executed and the steps that will be taken to verify that the update was conducted safely and securely and that the update change has not been manipulated prior to initiation of the update process.
Over-the-Air Updating – For what should be obvious reasons, over-the-air (OTA) updates are a particular target for R-156 assurance. Thus, vehicle manufacturers must document the presence of appropriate and effective assurance controls for updates that are remotely delivered. In any situation where the execution of an update while driving may not be safe, the vehicle manufacturer must demonstrate how they will ensure that the vehicle cannot be driven during update and that the driver is not able to use any functionality of the vehicle that would affect safety or the successful execution of the update.
What does this all mean?
It should be evident that the R-155 and R-156 mandates will introduce time-consuming and expensive new wrinkles into the automotive business. So, the obvious question is why do it? If this were 1957, or even 1997, there would be credible argument for not wasting your time. But the ubiquity of programmed logic in every aspect of vehicle systems—from software defined radio (SDR) to the CANbus and its network of vehicle ECUs—has created a complex digital ecosystem where failure in any onboard device, or an unauthorized OBD, or RFICD access can spell trouble for the occupants. And that isn't even to mention the prospective world of self-driving vehicles. Thus, there must be a well-defined and highly organized approach to managing complexity in vehicle systems. Cybersecurity Management Systems (CSMS) and Software Update Management Systems (SUMS) might seem like royal pains in the neck to the OEMs. But that is the price an industry that relies on digital technology must pay in order to offer the many miracles of the modern automobile.
