Consumers want more transparency and better access to tests and research, according to an Audi study that captures customers’ readiness and trust levels towards connected cars. This sentiment is also expressed by the authors of the report Software Transparency as a Key Requirement for Self-Driving Cars. The report notes, “Self-driving cars that demonstrate transparency in their operations will increase consumer trust which is pivotal to its acceptance and will pave the way for its commercialization and daily use.”
To fulfill the promise of greater transparency, we must all understand the level at which software impacts modern vehicles. Here are the software behavior activities throughout the vehicle lifecycle that automotive manufacturers must understand to promote performance integrity and secure consumer trust:
There can be over a hundred million lines of software code in a car, so having transparency in understanding what software is installed is paramount. Code sources are various, including software developed by the automotive manufacturer, supplier code, open source code, and legacy code. The challenge is finding a solution that can clearly map the installed software and work with many different types of hardware and operating systems. A modern vehicle can also contain over 100 electronic control units (ECUs). Each of them may come from a different supplier and run a different operating system, confirming that modern vehicles are complex systems that are constantly in movement.
Software considerations
It’s important to note that not all of the software installed on the vehicle is being used in run time. While full software stacks may be installed on the ECU, it is important to have transparency to know that only some libraries are being used. For example, software taken from the open source community or device driver packs may be redundant with legacy code and, although installed, it may not in fact be running.
Over-the-air automotive software updates have been accepted as a required process to keep cars safe, secure and offer consumers new functions, strengthening the automotive manufacturers’ brands. Therefore, automotive manufacturers must have visibility into what code has changed based on the software update and understand how that update affects other systems within the vehicle (this could include having the ability to roll-back to a previous version if the update is faulty).
Changing a line of code on one ECU can also affect code on other ECUs within the vehicle. The stronger the dependency between the components, the higher the probability of change. It is important to have insight into the software relationships at the code level in order to map these dependencies and understand the probability of change throughout the car.
The Institute of Electrical and Electronics Engineers expects that for every 10,000 lines-of-code written, there are 15 bugs (remember, there are over one hundred million lines-of-code in modern vehicles). While many problems can be caught in the testing stages, manufacturers still must account for ‘software drifting,’ a process in which code (the software itself) changes or alters its behavior and use of hardware resources over time. Failures resulting from software drifting can only be found as they occur – which is likely when the vehicle is already in the field. Automotive manufacturers need transparency to analyze a vehicle’s errors while it is under operation and that can predict the probability of a downtime event.
Software analysis for safety
Automotive software is tested and certified in the factory. However, automotive manufacturers need to be able to analyze the ECU software while the car is on the road to make sure the software running is the same as the software that was tested and certified. During the lifecycle of the car there can be malfunctions, cyber-security breaches, tampering and software behavior deviations which can cause system failures and jeopardize the safety of the vehicle.
The United Nations Economic Commission for Europe (UNECE) adopted new regulations concerning software updates on the 24th of June, 2020. New vehicle models are Type Approved before they are considered roadworthy and ready to ship to the users. The new UN regulations will require that the software update management system and every new functionality being deployed to a vehicle with and OTA update must also be approved, something that will happen many times throughout the lifecycle of the vehicle.
All software updates need to be certified unless the update is only fixing bugs or applying a security patch, and not introducing new functionality. Furthermore, the regulations state that if only a limited portion of the vehicle is affected by the update – then the only that portion needs to be re-certified, therefore limiting the tests that are required to obtain certification. Clear visibility and proof into what code is being changed and what functionality is being fixed will help minimize the time and costs for automotive manufacturers to obtain and maintain homologation certification.
Fixes and Updates
Lastly, in order to know what to update (and how that update will perform), it is important to have visibility into what needs to be fixed and what effect a bug fix or feature update will have on the entire car. Having transparency into the software functionality and behavior will enable the car manufacturers to detect software malfunctions and identify their source before they cause critical vehicle failures.
The ultimate goal of software transparency is to create a safer and better experience for consumers. This starts with helping the industry (OEMS, Tier 1s and regulators) understand the software in order to work smarter and more efficiently. From there, they can define how this new technology will affect our society and ultimately shape the way consumers think about the future of connected vehicles.