Skip to main content

Processes for the Software Defined Vehicle

A happy person surrounded by multiple monitors
Blog Team
Software Intensive Systems
September 25, 2024 | 8:00 am CDT
A happy person surrounded by multiple monitors
Blog Team
Software Intensive Systems

UL Solutions Software Intensive Systems offers the automotive industry this look at how development processes are being impacted by the shift towards software-defined vehicles. A new mindset — and accompanying software-centric development approaches — makes innovation more rapid and affordable, while still maintaining a safety and security focused culture.

Here are some key takeaways:

  • The automotive industry is moving from a milestone-oriented or project-oriented delivery model to a continuous value creation model.
  • Development lifecycles become more iterative and incremental by utilizing software-centric delivery models.
  • Safety, security, and quality need to be woven into the engineering processes instead of being handled separately.

Describing software defined vehicles

The automotive industry has not yet reached consensus about what constitutes a software defined vehicle (SDV). In 2023, the World Economic Forum, in conjunction with Boston Consulting Group, developed a model for software defined vehicles that consists of six layers, starting with the mechanical vehicle platform and its components grouped in different computing zones as a foundation. A vehicle software platform acts as the main abstraction of the hardware, subsequent software layers contain common data-gathering and insights functions and the actual automotive applications like infotainment or propulsion and battery management. The top layer is formed by the “smart mobility ecosystem” in which the vehicle communicates with its surroundings, e.g. other vehicles and edge or cloud computing services.

Regardless of the actual definition, UL Software Intensive Systems recognizes that the automotive industry is moving away from historical models with complex vehicle architectures consisting of dozens of electrical control units (ECUs) from different suppliers towards simplified and centralized hardware architectures with mobility functionality and most of consumer value realized in software.

The end goal of the transition towards software defined vehicles remains to speed up innovation and shorten time to market by reducing complexity and eliminating redundancies and complications.

Introduction

The automotive industry has seen a lot of hype about the transformational power of software defined vehicles (SDV). A confluence of competing factors has toned down the sky-high expectations around SDV, but as the conversation becomes more practical, the automotive industry is poised to enjoy significant speedup of innovation and long-term cost reductions through software-defined smart mobility.

What’s impacting rapid SDV adoption?

  • Existing vehicle architectures are complex and require extensive redesign efforts. 
  • Electrification is another top priority — and both areas require significant funds and focus.
  • Executives are concerned about the quality of automotive software development and the inherent safety and security risks.
  • Software culture clashes with automotive safety culture, which makes software talent hard to find and retain.
  • Established development processes are too linear and heavyweight for continuous delivery through software.  

In 2024, Automotive IQ surveyed 600 automotive software leaders about the current state of industry software development. Concern for software quality surged ahead of safety, which topped previous reports.

Source: State of Automotive Software Development Report: 2024

Continuous development

Software can be continuously updated. Consumers expect this constant improvement in mobile phones and laptops, but the sheer complexity of vehicles and the rest of the smart mobility ecosystem makes this much harder to achieve in the automotive industry.

While a product delivery mindset used to be sufficient for recent vehicles, a continuous delivery model is most appropriate in the new reality wherein software in abstracted from the hardware layers. Some vendors have already made the shift by moving from multi-year gate-based development processes towards software-centric models like DevOps (development and operations). To be applicable in the automotive world, tightly including security and safety is paramount, e.g. by adopting more advanced models like DevSecOps (development, security, and operations) or Industrial DevOps. Development teams need to be able to continously work on software platforms instead of being dispersed to other projects after a product launch.

Shorter interaction cycles

The benefits of shorter iteration cycles

In legacy automotive software development, some processes may have been run once or or twice a year. Today — and going forth — processes and workflows must be repeatable, quicker and iterable.  

This is challenging, but certainly possible. Here’s how:

  • Reduced batch size: Instead of waiting for all requirements to be clarified, consider iterating with a more concise batch of requirements. Organizations must be able to iterate development processes dozens of times (if not more) without adding overhead. Consequently, highly frequented process steps need to be automated instead of being executed manually.
  • Use of simulation and cloud-native techniques: Instead of testing new software versions on target hardware or even vehicles, software defined architectures allow significant speedups by utilizing cloud-native techniques like continuous integration and deployment (CI/CD) combined with simulation. Risks and issues can be detected and addressed much earlier in the development process and at a significantly lower cost.
  • Integrated verification and validation: These critical tasks should never be left to the end — and in a continuous development mindset, there is no “end.” Verification and validation must be woven into the design and implementation processes. In a software intense world, much of this testing can be automated, using models and model-based engineering.
  • Growing need for interoperability testing: When software defined vehicles  communicate with other vehicles or infrastructure like parking facilities from multiple vendors, interoperability risks arise and testing needs to be performed. Challenges currently categorized as “connectivity problems” will more likely become interoperability problems. These issues will grow with the increased variety of SDVs on the road, which calls for 3rd party interoperability testing and potentially certification of software components.
  • Usage of Open Source: The sheer amount of required software makes the usage of Free/Libre Open Source Software (FLOSS) almost inevitable. Given the frequency of open source updates, e.g. to address cybersecurity issues, efficient management of software component versions and their dependencies becomes mandatory. The automotive industry might benefit from following other industries with standardizing exchanges of software bills of materials (SBOMs) in addition to proper testing and governance.

Safety, security and quality

The United Nations Economic Commission for Europe (UN ECE) foster harmonization of vehicle and automotive regulations and mandate the adherence to security and safety standards.

Addressing full stack security concerns

SDVs are not isolated products; they are a part of a mobility ecosystem, so cybersecurity is a major concern.

Security standards for road vehicles such as ISO 21434 must be applied throughout the complete software stack. To secure SDVs after vulnerabilities have been identified, the ISO 24089 standard is expected to be followed by OEMs to perform the necessary software updates securely and safely, regardless of the updates being performed over-the-air or at the distributors. Automotive suppliers are required to maintain proper RXSWIN identifications for their software deliveries to efficiently segment out vehicle populations needing software updates.

To protect the whole mobility ecosystem in its entirety, a sole focus on the vehicle level is not sufficient. TISAX, a security standard based on ISO 27001 and optimized for automotive companies, addresses IT security also on an enterprise level to address risks in the IT infrastructure and organizations that are part of the overall ecosystem. In addition, new models like SPICE for IT Systems can be used to assess the overall quality of those systems.

Validation of functional safety

As SDVs typically partition general compute from safety zones, validating functional safety can be limited to components in those respective zones, if freedom from interference between the different zones can be established. ISO 26262 (Functional safety) and ISO 21488 (Safety of the Intended Function – SOTIF) standards are still applicable to the components in those safety zones.

Updating Automotive SPICE, a longstanding quality standard

Safety and security can only be effectively addressed if development of systems and software fulfils certain quality criteria. To avoid inefficiencies, a holistic and consistent approach to safety, security and quality is advised and deeply integrated into the respective engineering processes.

For more than two decades, the automotive industry has used Automotive SPICE to increase quality of systems and software by requiring adherence to appropriate software and systems development processes. If implemented properly in engineering and not only being used as a checklist by quality managers, Automotive SPICE has been very effective to achieve high quality of results and consequently reduce rework.

The Automotive SPICE family of standards now features:

  • Automotive SPICE 4.0, which includes a new "Validation” process area 
  • Machine learning engineering process assessment model (MLE PAM) to help manage AI-enabled components 
  • Agile SPICE 1.3, for increased business agility and faster decision-making 
  • SPICE for IT Services for increased quality of edge and cloud service

Regulations

  • UN ECE WP.29 regulations
  • Security: ISO 21434, ISO 24089 (for OEMs) and TISAX throughout the whole ecosystem
  • Safety: ISO 26262 and ISO 21488 (SOTIF) required for software and hardware in safety zones
  • Quality: Automotive SPICE® 
    • New Process Areas “Validation” and “Machine Learning Engineering” in Automotive SPICE® 4.0
    • Agile SPICE 1.3
    • SPICE for IT Services

Next steps

Moving forward: Upgrade your processes 

UL Solutions Software Intensive Systems (SIS) provides end-to-end partnership for the automotive industry. SIS brings 20+ years of industry experience powered by more than 400 experts to offer insights, services and software that empowers SDV innovation.

We can help you advance SDV development through:

  • Preparing your processes to run continuously in support of incremental delivery.
  • Focus on the software lifecycle — but understand and address other dependencies.
  • Help to build in security, safety and quality into your engineering processes.
Download our eBook
MCS24CS1857309-SDV_SIS_Launch-ebook-R1c.pdf

MCS24CS1857309-SDV_SIS_Launch-ebook-R1c.pdf

11 MB

Within UL Solutions we provide a broad portfolio of offerings to many industries. This includes certification, testing, inspection, assessment, verification and consulting services. In order to protect and prevent any conflict of interest, perception of conflict of interest and protection of both our brand and our customers brands, UL Solutions has processes in place to identify and manage any potential conflicts of interest and maintain the impartiality of our conformity assessment services.