Software is the heart of the modern car experience, making rides more comfortable, safer, less polluting, and adding new services over the lifetime of the vehicle. Executives in the automotive industry highlight that “Software will account for 90% of future innovations in the car” (Herbert Dies, Volkswagen Chairman).

The increasingly complex automotive software environment

Modern vehicles have over 100 ECUs (Electronic Control Units), altogether comprising 100 million lines of source code. Each new functionality for safety, comfort, infotainment, and personalization introduces additional electronics and components – and adds a large set of new software. This software requires extra development, integration, and quality assurance effort towards SOP (start of Production), and poses additional challenges to ensure software maintenance on a very long lifecycle and perform software updates.

But this is just part of the puzzle. Different regional regulatory requirements, increasing options to fit individual car owner preferences, and evolving models to cater to market demands lead to large variations of configurations, trims, and models, which add another dimension to the complexity. The explosion of combinations means that not every configuration can be tested and verified in practice.

Vehicle recall data for 2019 in the USA reveals that while the number of vehicle recalls has decreased, software-based defects are increasing. More software is needed to detect abnormalities, add reliability, and ensure quality and conformance to safety standards. On the positive side, software-based remedies have been used for many mechanical or electronic faults that would have required repair or replacement of vehicle components in the past.

Becoming software-centric requires as much brains as muscles

Over the years, Automotive OEMs have not been hands-on developing most of this software themselves. They have relied on tens of suppliers to provide the bulk of the software. Now, the situation is changing. OEMs are increasingly building their software engineering teams and practices – and driving further standardization either within their groups (e.g., CARIAD in the Volkswagen group), or through industry alliances such as AUTOSAR and COVESA (formerly GENIVI).

Software complexity in vehicles is rapidly outpacing the ability to both develop and maintain it, but software engineering productivity is not growing nearly as fast. Just like the Red Queen in Lewis Carrol’s Through the Looking Glass, the automotive industry has realized that “It takes all the running you can do, to keep in the same place”. Delivering on the software-defined vehicle requires the industry to run smarter rather than running harder.

We work with OEMs as a software engineering partner. Not only to scale their engineering, but also to adopt best practices in software development, DevOps, and Agile methods. Our experience in solving similar software complexity, scale, and re-use challenges also in other industries is instrumental to a successful transition to a software-centric automotive industry.

Tips to “run smarter” towards software-defined vehicles

• Centralize ECUs to reduce complexity: Consolidating Multiple ECUs into domain area ECUs reduces the amount of wiring, networked communication, and simplifies software development and upgrades.

• Use Closed-Loop SiL (Software in the Loop) for continuous integration and validation: Having the ability to test with software allows adding scale, frequency, and variation to the testing, complementing other testing techniques such as HiL (Hardware in the Loop), DiL (Drive in the Loop), and ViL (Vehicle in the Loop), which require physical elements that are harder to scale.

• Architect Over the Air updates (OTA) into the software lifecycle: Software updates to support variants, updates in security and defects, and adding new features and services are all very desirable, but they require rock-solid SW delivery, security, safety, rollback mechanisms and non-intrusive user experience (who wants to wait 10+ minutes for an update to be completed to be able to start the car?). This needs to be designed into the system-level software architecture as it spans both in-vehicle, vehicle to cloud, and cloud domains.

• Harmonize safety and security related development practices across the supply chain and use standardized quality metrics: while many standards for safety are commonplace in the automotive industry (such as ASPICE MISRA, ISO 26262) their adoption into engineering and DevOps practices varies greatly across the supply chain. In security, standards such as ISO/SAE 21434 (Road vehicles – Cybersecurity Engineering) and UNECE WP.29 (Regulation on Cybersecurity) don’t define details. This leaves room for different approaches in threat modelling, secure coding, secure design, DevSecOps practices – and degrees of quality across the software value chain.
  
  

Learn more about how we help automotive companies to "run smarter" towards software-defined vehicles.