by Omid Hosseinitabar, Engineering Management champion and Product Manager for the continuous improvement product, ERis, within QR_'s GAia suite.
What are we talking about?
Comparing current-generation vehicles with those manufactured 10-20 years ago, aside from the instant torque of electrified drivetrains, there is one major difference: the overwhelming presence of software.
A modern “connected car” contains a network of 70-150 ECUs (electronic control units) and CPUs (central processing units) managing almost every aspect of the vehicle’s functionality. The software that is flashed onto these ECUs are addressing an increasingly complex set of requirements and can reach 100 million lines of code; around 2,500 times that required by all Apollo 11 air-side systems.
This level of complexity requires a robust central system to track different software and hardware versions and monitor deployment. Up until this point, major OEMs have used their own initiatives to set up processes and connect data from different systems to make sense of this complexity, but fast-forward to now and 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 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 these requirements needs to be completely bullet-proof as 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. Whilst this enables the consumers to benefit from extra convenience, security concerns alarm many customers and can influence insurer’s perception of risk. You can read about an example of such incidents, here.
Over-the-air software updates (OTA):
A characteristic of connected cars is their ability to receive software updates over the air. Integrated cellular connections allow new software packages to install on the go without having to visit a service centre to perform this task. This started with things like navigation updates, but now frequently covers core control and feature functionality.
The challenge here is that software/hardware incompatibility or improper update installation can render the vehicle inoperable or create unpredictable malfunctions. Previously, updates applied by service technicians resulting in an issue would only cost an apologetic phone call and some additional workshop time. Now however, the best-case scenario is a recall of vehicles running the known problematic software version, and the worst-case being directly attributable compromises of active or passive safety systems resulting in accident or injury, with the associated bad press.
Software complexity:
Mandatory safety features such as “Advanced Emergency Braking Systems” or in-car infotainment systems require complex packages of software, and with this complexity comes the need for a rigorous update management and deployment process. For every update issued, there needs to be a chain of testing and configuration compatibility assessments carried out to ensure there will be no disruptions to existing functionalities, 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. This 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 for change management and opens the risk of improper change control.
Why should we care?
Establishment of a robust Configuration Management system has always been desirable by OEMs. However, how integrated and central this 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 to a must have in order to secure homologation.
Major considerations when developing a Configuration Management framework
Configuration Management elements
The key ingredients of an effective Configuration Management system should include relationships between vehicles, their milestone (model and revision), hardware, software and the features that they are fulfilling. The reason behind this level of granularity is that the characteristics of a change can be later traced back to one or more of these elements.
- Vehicle Programs refers to a major product within a product line to allow assignments of milestones, features, software and hardware components.
- Milestones refers to the fixed points in a product lifecycle. This can be a pre-production prototype or a face-lift of an established product.
- Feature requirements is the granular description of features that are aimed to be delivered on a program defined alongside any dependencies and options a customer can choose from. The feature requirements can also be linked to design verification, FMEAs and testing events.
- Software components are the packages of code that are flashed onto hardware components or their control modules. They are version controlled and specify any compatibility and dependency they have with respect to the hardware and other software packages.
- Hardware consists of physical electronic components fitted to the vehicle. Just like the other elements, software, milestones and vehicles are interlinked with the hardware network. Different revisions of hardware are also recorded to track compatibility with other electronic components.
Once these data points are created, they should be carefully maintained and any change introduced clearly record the changes to the item itself and any relationships impacted as a result of that change.
The benefits of such a system are multiplied when centrally embedded into PLM systems, enabling unique identifiers for each data point to integrate with other systems. For example, when a hardware component is updated, the records on the Bill of Material are modified to reflect this update.
This emphasis on centralisation of data is because SUMS (R156) requires all these data points to be securely captured and stored to allow a full change history of electronic components within a vehicle.
Baseline Management and Agile Update Management System
A primary principle of Configuration Management is establishment of a baseline. A baseline is an agreed description of the attributes of a product at a point in time, serving as a basis for defining change. Generally, a baseline may be a single work product, or 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 this baseline. Baselines are traditionally introduced as set points in time, but for software - due to its need for more frequent updates - we may require a slightly different approach.
Over-the-air software updates can create a tendency to issue smaller, incremental updates rather than larger, less frequent feature releases. These small changes introduced in the mid-cycle of the baseline are not to be excluded from normal change control process, and 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 decisions alongside any evidence should be recorded in compliance with the UNECE regulations.
Once an update is in effect, the current baseline is unfrozen, and changes applied to reflect the current status. The current baseline is then pushed back to “frozen” to protect it from unwanted change and allow the next baseline draft to be updated.
Shaping an organisation’s processes to facilitate agility in rolling out updates is a great asset and can protect the end product against customer dissatisfaction, safety or security risks and help bring in new and frequent content to loyalise users through improved features and usability.
Change management process
Any changes, small or large, need to go through a change management process to first and foremost avoid unwanted changes and meet the requirements of the SUMS regulation.
For each change the organisation needs to determine the:change does not affect the certification criteria for the vehicle type approval (homologation)
- change is compatible with different baselines including software and hardware (note that there could be vehicles on the road with older software versions)
- change impact on different systems, functions and usability
- change meets the requirements for cyber security
All evidence for the above needs to be recorded alongside the decision makers in the process 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.
In order 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. This can also help with identifying vehicles that require a hardware upgrade or any additional work to maintain the vehicle 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 software flashed onto the electronic units, so that in the future every time the vehicle receives an update, records can be updated to reflect the latest specifications.