What are we talking about?
Compare current-generation vehicles with those manufactured 10-20 years ago and, aside from the instant torque of electrified drivetrains, there's one major difference: the overwhelming presence of software.
A modern connected car contains a network of 70-150 ECUs (electronic control units) and CPUs managing almost every aspect of the vehicle's functionality. The software flashed onto those ECUs addresses an increasingly complex set of requirements, and can reach 100 million lines of code — around 2,500 times the code required by Apollo 11's air-side systems.
This level of complexity requires a robust central system to track different software and hardware versions and monitor deployment. Until now, major OEMs have used their own initiatives to set up processes and connect data from different systems to make sense of the complexity. Fast-forward to now and the regulatory bodies previously focused on emissions and safety considerations are seeking to introduce detailed frameworks that OEMs need to adopt in order to achieve homologation (vehicle Type Approval).
In this article we specifically examine United Nations Economic Commission for Europe (UNECE) Regulations 155 (Cyber Security) and 156 (Software Update Management System — SUMS for short). These regulations have now been adopted by multiple regions and outline the specific requirements for a Configuration Management system embedded in the development and post-production lifecycle updates for vehicles on the road.
Why is software under the regulators' magnifiers?
- Vehicle mechanics — A modern connected car has ECUs controlling every aspect of vehicle mechanics and dynamics — from acceleration and braking to steering and reversing. From a cyber security perspective, software serving those requirements needs to be completely bullet-proof: any manipulation could result in tragedy and blurred lines of liability.
- Vehicle access — Apart from the now ubiquitous keyless start technology, many vehicles facilitate over-the-air access through mobile apps, key fobs, or NFC-enabled devices. That enables genuine convenience for consumers — but security concerns alarm many customers and can influence insurers' perception of risk.
- Over-the-air software updates (OTA) — A characteristic of connected cars is the ability to receive software updates over the air. Integrated cellular connections allow new software packages to install on the go without a visit to a service centre. This started with things like navigation updates, but now frequently covers core control and feature functionality. The challenge: software/hardware incompatibility or improper update installation can render the vehicle inoperable or create unpredictable malfunctions. Previously, an update applied by a service technician that caused an issue would only cost an apologetic phone call and some additional workshop time. Now, the best-case scenario is a recall of vehicles running the known problematic software version — and the worst case is directly attributable compromises of active or passive safety systems, resulting in accident or injury, with the associated bad press.
- Software complexity — Mandatory safety features like Advanced Emergency Braking Systems, and in-car infotainment systems, require complex packages of software. With that complexity comes the need for a rigorous update-management and deployment process. For every update issued, there has to be a chain of testing and configuration-compatibility assessments carried out to ensure no disruption to existing functionality — taking into account hardware differences across different market localisations, parallel suppliers, and possible build combinations.
- Change management — Software-controlled components and modules usually undergo more revisions in pre-production, production, and post-production than their purely mechanical or non-moving counterparts. That creates a unique challenge in managing change and understanding the impact of each change on other components. Lack of end-to-end data flow is the main cause of delays in change management — and opens the risk of improper change control.
Why should we care?
The establishment of a robust Configuration Management system has always been desirable to OEMs. But how integrated and central that system should be within broader PLM systems and processes has often been overlooked. The requirements set by UNECE for Cyber Security and the Software Update Management System are about to change this nice-to-have concept into a must — in order to secure homologation.
Configuration Management elements
The key ingredients of an effective Configuration Management system should include relationships between vehicles, their milestones (model and revision), hardware, software, and the features those components fulfil. The reason for this level of granularity is that the characteristics of a change can later be traced back to one or more of these elements:
- Vehicle Programs — A major product within a product line — allowing assignments of milestones, features, software, and hardware components.
- Milestones — The fixed points in a product lifecycle. That could be a pre-production prototype or a face-lift of an established product.
- Software components — A product description of features delivered by software — linked to the hardware they run on and the vehicle programmes they apply to.
- Hardware components — The physical parts on the vehicle that software runs on, and that must be known to assess update compatibility.
Baseline management and agile update management
A primary principle of Configuration Management is the establishment of a baseline. A baseline is an agreed description of the attributes of a product at a point in time — a logical basis for defining change. Generally, a baseline may be a single work product or a set of work products that can be used as a logical basis for comparison.
The elements introduced in the previous section are key in creating that baseline. Baselines are traditionally introduced as set points in time — but for software, due to its need for more frequent updates, a slightly different approach may be required.
Over-the-air software updates create a tendency to issue smaller, incremental updates rather than larger, less frequent feature releases. Those smaller changes introduced in the mid-cycle of the baseline aren't to be excluded from normal change control — the configuration manager needs to log all changes being made to the software or any other linked hardware or feature requirements. All changes should be carefully assessed and functions tested alongside any evidence, and recorded in compliance with the UNECE regulations.
Once an update is in effect, the current baseline is unfrozen, changes are applied to reflect the current status, and the current baseline is then pushed back to "freeze" to protect it from unwanted change and allow the next baseline draft to be built up.
Shaping an organisation's processes to facilitate agility in rolling out updates is a great asset. It can protect the end product against customer dissatisfaction, safety, or security risks — and help bring in new, frequent content to build loyalty through improved features and usability.
Change management process
Any change, small or large, needs to go through a change management process — first and foremost to avoid unwanted changes, and to meet the requirements of the SUMS regulation. For each change, the organisation needs to determine:
- That the change doesn't affect the certification criteria for the vehicle Type Approval (homologation).
- That the change is compatible with different baselines, including both software and hardware. Note that there could be vehicles on the road with older software versions.
- The change's impact on different systems, functions, usability, and safety.
- That the change meets the requirements for cyber security.
All evidence for the above — alongside the decision-makers involved in the process — needs to be recorded in case of audit by regulatory bodies.
Digital Twin
With the proliferation of software and an increasingly complex network of electronic components, vehicles in development, production, and on the road need to be identifiable by their manufacturer to maintain functionality. Keeping a digital record of the components of a physical object is known as a Digital Twin.
To perform over-the-air updates and carry out compatibility assessments before rolling out any updates, manufacturers need to know exactly which nodes in the fleet network are eligible to receive certain updates. That can also help identify vehicles that require a hardware upgrade or any additional work to maintain them on the latest published baseline.
A best practice when setting up digital twins against a vehicle fleet is to use the Vehicle Identification Number (VIN) and store all components fitted to the vehicle — plus the software identified on the electronic control units — so that every time the vehicle receives an update, records can be updated to reflect the latest specifications.
