This is how an effective software update management system works

A Software Update Management System (SUMS) has the aim to ensure software updates are carried out in a safe, functional, traceable and compliant manner. Compliant manner means, that the software on a vehicle is and stays compliant with the respective vehicle type approval. This is the objective of the R156.

• Software updates for target vehicles are identified: you need to know which cars need an update. Documentation of the vehicle configuration is key here.
• There is a check of the compatibility of software updates with the overall vehicle configuration. You need to know what the effects on vehicle systems and vehicle parameters are.
• Software updates and their influence on the scope of type approval and the overall vehicle is identified. An update as it is a change, can have an influence on the valid type approval.
• It ensures that you meet the security, safety and documentation requirements for software updates in the workshop or over-the-air (OTA).
• And of course, the management system shall ensure that the software is available and implemented safely and that the integrity and authenticity of the software and the software update is ensured.

So the SUMS ensures every vehicle can be reliably supplied with required updates. That’s easier said than done, since you have to deal with different configurations of one vehicle type.

A SUMS deals with connected vehicles as if they’re part of an overall system – with vehicles defined by their software, aside from vehicle architecture that includes the backend servers. You can see that in the following diagram.

Of course, at the center of the overall system is the software-defined vehicle. The different control units for the car body, the chassis, safety aspects, and the gateways have interfaces, through which they’re connected to backend servers.

As I said, configuration management is key. To ensure that the current software-configuration status of the vehicle including the respective components can be determined, we need identifier. Here comes the RXSWIN into the game. The RXSWIN, which stands for Regulatory Software Identification Number is a dedicated identifier, required by the authorities and defined by the vehicle manufacturer. It represents information about the type approval relevant software and its characteristics. The RXSWIN can be read out from the vehicle and allows the determination of the homologation status of individual functions and the related control units that are subject to a UNECE regulation.

For example, let's say a vehicle manufacturer is creating an RXSWIN for the steering system software in a vehicle that falls under UNECE Regulation No. 79. The manufacturer would use "RX79" as the first part of the RXSWIN to indicate the UNECE Regulation number. The second part would be a software identification number for a specific version of the steering system software at the manufacturer.

It's important to note that the RXSWIN should be unique for each software version in each vehicle type, and it should be assigned by the vehicle manufacturer.

The need to follow a systematic structure is also underscored by the fact that routines must be defined, just in case an update fails. What can you do if an update fails or it’s interrupted? Make sure that the previous state can be restored again. Moreover, you have to ensure the most important protection goals of cybersecurity are adhered to: the confidentiality, integrity, availability of the update.

If a SUMS offers you a systematic method for carrying out reliable vehicle updates, then the focus lies in processes and procedures.

The processes you need for this revolve around the following

• How should you log or record different versions of the hardware and software you’ll require for the vehicle type for different systems and functions?
• Which software is important for type approval and needs a RXSWIN including defining and updating this identifier?
• Are there any interdependencies, especially when it comes to software updates?
• Which components are affected by updates, and what’s with their compatibility?
• To what extent does a software update affect type approval or other aspects defined by legislators?
• To what extent does an update affect functional safety or driving safety?
• How will vehicle owners be informed of updates?
• How will the update process itself be protected from a cybersecurity perspective?
• How should all of these points be documented?

This list raises a key issue: Aside from cybersecurity for vehicle stakeholders, the primary concern for vehicle manufacturers is legal certainty. Is everything being done to keep the vehicle safe? How will you deal with the complexity of the connected vehicle with different configurations changing over time?

If, despite all, a hacker should at some point find a way to get into a system, manufacturers must provide evidence that they made every reasonable effort to protect vehicles and worked according to the standards.

While we’re on this topic, the UNECE regulations also stipulate that you will be obligated to report attacks in the future.

Another challenge is, that the ISO standard for software update management systems, which provides more guidance for a SUMS, was only published in early 2023. The name of this new standard is ISO 24089 Road Vehicles – Software update engineering. In UNECE Regulation R.156 you can see which activities are required. It’s important to know that regulation R.156 only names requirements. How you implement those requirements in practical terms is explained in the new ISO 24089. To a certain extent, this regulation defines the destination, while ISO 24089 gives guidance for getting there.

• How should you log or record different versions of the hardware and software you’ll require for the vehicle type for different systems and functions?
• Which software is important for type approval and needs a RXSWIN including defining and updating this identifier?
• Are there any interdependencies, especially when it comes to software updates?
• Which components are affected by updates, and what’s with their compatibility?
• To what extent does a software update affect type approval or other aspects defined by legislators?
• To what extent does an update affect functional safety or driving safety?
• How will vehicle owners be informed of updates?
• How will the update process itself be protected from a cybersecurity perspective?
• How should all of these points be documented?

This list raises a key issue: Aside from cybersecurity for vehicle stakeholders, the primary concern for vehicle manufacturers is legal certainty. Is everything being done to keep the vehicle safe? How will you deal with the complexity of the connected vehicle with different configurations changing over time?

If, despite all, a hacker should at some point find a way to get into a system, manufacturers must provide evidence that they made every reasonable effort to protect vehicles and worked according to the standards.

While we’re on this topic, the UNECE regulations also stipulate that you will be obligated to report attacks in the future.

Another challenge is, that the ISO standard for software update management systems, which provides more guidance for a SUMS, was only published in early 2023. The name of this new standard is ISO 24089 Road Vehicles – Software update engineering. In UNECE Regulation R.156 you can see which activities are required. It’s important to know that regulation R.156 only names requirements. How you implement those requirements in practical terms is explained in the new ISO 24089. To a certain extent, this regulation defines the destination, while ISO 24089 gives guidance for getting there.

This diagram shows that organizational processes are a prerequisite for providing quick and secure updates to the vehicle fleet in the field. All requirements such as the infrastructure, access to configuration databases, as well as the RXSWIN must be planned, developed, and provided to coincide with the timing of vehicle development. This is also part of security by design. If a decision is indeed made that a risk will have to be averted by releasing an update, the software update processes must already be in place. Only then the software update campaign can be carried out on the basis of a methodical approach and clear structures.

And don’t forget: A management system should follow a PDCA process – Plan > Do > Check > Act. Processes should be regularly evaluated for effectiveness and efficiency. This includes audits by independent inspection bodies.

The reason this is such a delicate issue is that the UNECE regulation lays down explicit requirements, but it still leaves it up to manufacturers how they want to meet those requirements. SUMS is an important aspect of approval processes and homologation and needs to be certified. Like a CSMS, this SUMS must be audited and certified by a neutral body, otherwise the vehicle will not be granted type approval.

I’ll use this diagram to explain how the process works.

Here you see that a SUMS need to be established, for example based on ISO 24089.

An auditor from a UNECE listed certification body and examines whether the SUMS and the actual activities which we discussed before are carried out by your company and are suitable to meet the regulatory requirements of UNECE R.156.  If they are, you receive a certificate for your company, which is valid for three years.

But for bringing the vehicles into the market, that is not enough. All components identified as critical must also be certified by an independent person. Manufacturers also receive a certificate for this in the form of a system validation report for each release candidate. From an approval perspective, this is where a SUMS is different from a cybersecurity management system, because only the SUMS includes the additional aspect of component certification.

As a manufacturer, you need type approval from the national approvals administration before production starts. The authorities will check that all necessary certificates are in place and see if they have been audited by an independent body.

So for type approval you need

1. A certificate for your cybersecurity management system
2. A certificate for your software update management system
3. Numerous certificates for relevant components

Once all requirements have been met, your vehicle will receive its type approval and homologation. Then and only then is it permissible for you to sell the vehicle.