Transition to the SDV supported by GenAI

Background

The automotive industry is undergoing a significant transformation with the advent of the Software Defined Vehicle (SDV). This shift is driven by the need for increased flexibility, scalability, and innovation in vehicle design and functionality. The transition from legacy vehicle E/E hardware and software architectures to software-defined architectures applies both to passenger cars and commercial vehicles. The SDV architecture enables automakers to provide a platform for software updates, new feature introductions, and improved overall ownership experience and business models.

The transition to an SDV is challenging for traditional automotive OEMs because of the simultaneous shift to electric and hydrogen powertrains. The introduction of SDV architecture require the review, refactoring and re-allocation of existing software assets.

In this document we first outline the characteristics of SDVs, the required hardware and software and communication changes and then we propose a first idea how to support the transition to a SDV based on a feature-oriented approach and how to address the challenges in refactoring the existing software through the help of genAI and other techniques.

SDV Architecture

An SDV architecture is characterized by several key features:

• Separation of hardware and software: This allows for greater flexibility and scalability in vehicle design and functionality. The separation of hardware and software enables automakers to update and upgrade software independently of hardware, reducing the need for physical recalls and improving the overall ownership experience.
• Updateable and upgradeable: SDVs can be updated and upgraded remotely, reducing the need for physical recalls and improving the overall ownership experience. This feature enables automakers to introduce new features after production, fix software bugs, and improve the overall vehicle performance in the field.
• Learning and AI: SDVs can learn and adapt to driver behavior, traffic patterns, and other environmental factors, enabling advanced safety and convenience features. The use of artificial intelligence (AI) and machine learning (ML) enables SDVs to predict and respond to various scenarios, improving overall safety and convenience.
• Always connected: SDVs are constantly connected to the cloud, enabling real-time data exchange and analytics. The connection to the cloud enables automakers to collect data, analyze it, and provide insights that improve vehicle performance, safety, and convenience.
• Interacts with its environment: SDVs can communicate with other vehicles, infrastructure, and pedestrians, enabling advanced safety and efficiency features (V2X). The interaction with the environment enables SDVs to predict and respond to various scenarios, improving overall safety and efficiency.
• Supports service-based business models: SDVs enable new business models, such as subscription-based services and data-driven revenue streams. The SDV architecture enables automakers to provide services that improve the overall ownership experience, such as vehicle monitoring, predictive maintenance, and personalized recommendations.

Hardware Changes

The transition to an SDV architecture requires significant changes to vehicle hardware:

• Introduction of HPC and zonal architectures. The E/E architecture changes from distributed or domain E/E architecture to zonal architecture with high performance compute units (HPC). This involves consolidating electronic control units (ECUs) and software re-allocation to HPCs. Zonal architecture requires a redesign of signal processing and consolidation of sensors and actors.
• Introduction of high-performance compute units (HPC): HPCs enable the processing of large amounts of data and support advanced AI and machine learning applications. The use of HPCs enables SDVs to perform complex tasks, such as machine learning, computer vision. HPCs can be leveraged to perform work of several ECUs even from different vehicle domains by utilizing virtualization, multiple operating systems with mixed criticality and introduction of new technologies like containers for easier software updates and upgrades.
• Fast Ethernet: Gigabit Ethernet enables high-speed data transfer between ECUs and HPCs. The use of fast Ethernet reduces the weight for wires and complexity of wiring and enables improved communication between different components, reducing latency and improving overall system performance.
• ECU consolidation and reduction: The number of ECUs is reduced, and their functionality is consolidated into HPCs. The consolidation of ECUs reduces cost and enables improved scalability, flexibility, and performance.

Communication Changes

With the introduction of in-vehicle Gigabit Ethernet and the connection of zonal ECUs with HPC, the in-vehicle communication will change. Signal-oriented communication (CAN, Flexray, LIN) needs to be transformed into to service-oriented communication. Service oriented communication is widely used in the IT industry but needs to be adopted to automotive specific standards like SOME/IP. Service oriented communication enables more flexible, efficient and scalable data exchange between ECUs and HPCs.

Software Changes

The transition to an SDV architecture requires significant changes to software:

• Decoupling of software from underlying hardware: Software is decoupled from hardware, enabling greater flexibility and scalability. The decoupling of software enables improved portability, maintainability, and upgradability.
• From monolithic software to microservices. In traditional architectures, AUTOSAR classic is widely used. With the introduction of high speed ethernet and communication protocols like SOME/IP a transition to AUTOSAR Adaptive and other service-oriented middleware is required. With the introduction of service-oriented communication, the software can be broken down into smaller, more manageable microservices. The use of microservices enables improved scalability, flexibility, and maintainability. On the other hand, microservices need careful orchestration and management.
• Use of virtualization and containers: Virtualization and containers enable greater flexibility and scalability in software deployment. The use of virtualization and containers provides isolation of processes and enables improved portability, maintainability, and upgradability. With virtualization and containerization, software from multiple domains and ECUs can be executed on a shared HPC.
• Use of Android Automotive for infotainment. In the infotainment domain, Android Automotive provides a standardized platform for infotainment systems. The use of Android Automotive enables improved scalability, flexibility, and maintainability.
• Use of Linux for non-critical software: Linux is used for non-critical software applications (up to ASIL B). The use of Linux enables improved scalability, flexibility, and maintainability.

• Re-allocation of microcontroller code to HPC: Microcontroller code is re-allocated to HPCs to take advantage of their processing power. The re-allocation of microcontroller code enables improved performance, scalability, and flexibility. Based on the functional safety level (FuSa), some real-time software needs to remain on microcontrollers.

Transition challenges

The transition to an SDV architecture poses several challenges:

• Brownfield: Missing specification, documentation, and traceability: Existing systems often lack proper documentation and traceability, making it difficult to migrate to an SDV architecture. The lack of documentation and traceability makes it challenging to understand the existing system, identify potential issues, and develop a migration strategy.
• Systems engineering is multi-dimensional: Systems engineering involves multiple disciplines, including E/E hardware architecture, network design, and software development. The complexity of systems engineering makes it challenging to develop a comprehensive migration strategy that addresses all aspects of the SDV architecture.
• Running microcontroller code on HPC: The decomposition of monolithic applications and redeployment to HPCs is challenging. A reallocation of the feature may require a complete reimplementation to address service-orientation and changed hardware architecture etc. Based on in-depth analysis of features, a complete rewrite may be necessary for entire ECUs or modules.

Additionally, we see some tool specific challenges

• Traceability across different engineering tools is difficult: The systems engineering process comprises different tools like requirements management, product lifecycle management tools (PLM), model-based systems engineering tools (e.g. Matlab/Simulink), coding (e.g. C/C++) and testing and verifications. Additionally, the hardware and wiring specific tooling needs to be considered. The main challenge is the traceability of features and requirements across all these systems. The lack of traceability makes it difficult to understand the existing system, identify potential issues, and develop a migration strategy.

• Some tools us proprietary formats: For example, Matlab/Simulink uses proprietary formats. The proprietary formats make it challenging to analyze and understand Matlab/Simulink models, especially by using genAI. Best suited for working with genAI are text based, human readable formats. A conversion of proprietary formats to text based formats is necessary to apply genAI on these artifacts.

Recommended Approach to support the SDV transition

We propose to perform the transition using a feature-oriented migration approach. The basic idea is to identify the different vehicle features. For example, a anti blocking system (ABS)  is considered a feature. Features can be seen as an abstract representation of the vehicle functions. Functional and non-functional requirements are assigned to features. The SDV migration is done top-down, based on domains and their features. The top-down approach enables a comprehensive understanding of the existing system and the development of a migration strategy that addresses all aspects of the SDV architecture. These are the top-level activities for the transition:

• Identify features in engineering applications: Features are identified in engineering applications, such as Doors, Windchill, and Matlab/Simulink. The identification of features enables a comprehensive understanding of the existing system and the development of a migration strategy that addresses all aspects of the SDV architecture.
• Define reallocation criteria: Criteria are defined for reallocating features to new E/E architecture. The definition of reallocation criteria enables a comprehensive understanding of the existing system and the development of a migration strategy that addresses all aspects of the SDV architecture. Reallocation criteria are functional safety level (FuSa), hard- or soft real-time requirements, startup time and availability requirements, required computational resources, amount of processed data, frequence of changes / updates, upgrade requirements and many more.
• Create a feature inventory: Gather available information about existing features based on available engineering information systems and other information sources. Collect all “as is” reallocation criteria information. Document dependencies between features and basic software like middleware, operating systems and libraries etc. The inventory may be implemented as a knowledge graph.
• Decomposition of existing code into microservices: Existing code is broken down into smaller microservices. The decomposition of existing code from monolithic applications enables improved scalability, flexibility, and maintainability.
• Reallocation of features to new E/E architecture: Features are reallocated to new E/E architecture. This represents the “to be architecture”. Based on the re-allocation criteria, some feature will be deployed on HPC, zone controllers or will remain on microcontrollers. For some features even cloud deployments can be useful.

Use of GenAI in the SDV transition

The transition to a SDV architecture requires a comprehensive understanding of the existing software applications, modules, dependencies and communication partners. The knowledge of the related engineering artifacts is distributed across multiple information sources like Doors, PLM Systems, Matlab/Simulink, Source Code etc.

GenAI can be used to support the transition to an SDV architecture. The following lists some examples for the usage of genAI:

• Chat with your code: GenAI can be used to explain and understand code. The use of GenAI enables improved code understanding, maintainability, and upgradability. It can also help with refactoring and porting existing code to a new SDV platform.
• Chat with your requirements: GenAI can be used to understand and analyze Doors requirements. The use of GenAI enables improved requirements understanding, validation, and verification.
• Matlab/Simulink: GenAI can be used to analyze and understand Matlab/Simulink models. The use of GenAI enables improved model understanding, validation, and verification.
• Autosar ARXML: GenAI can be used to analyze and understand Autosar ARXML files. The use of GenAI enables improved file understanding, validation, and verification.

Furthermore, a retrieval augmented generation (RAG) approach can be used to make multiple information sources accessible to a large language model (LLM), which can be used connect the information and support the feature identification and the migration process.

Figure 1: RAG – Conceptional Architecture

Recommended approach to support the GenAI implementation

As a starting point IBM Consulting advantage (ICA) can be used to provide genAI based assistants for the different job roles in an automotive engineering project. To protect the client’s data privacy, ICA can be hosted in the client’s cloud environment. IBM trained LLMs can be used to provide code generation without the risk of open-source infringement risks. IBM can provide multiple assistants and integrations to external tools.

For code related tasks, github CoPilot is the current market leader. Automotive OEMs need to decide if they take the risk of exposing their code to Microsoft.  As alternative to CoPilot WatsonX Code Assistant (WCA) can be used leveraging the IBM granite family of LLMs.

The proposed RAG solution for feature identification and relocation is a custom development for the automotive OEM. The RAG solution needs connectors and interfaces to the specific engineering tools of the automotive OEM. As a starting point we recommend a workshop with the client to learn which information sources are available and needed for the SDV transition. Missing traceability needs to be identified and if possible, alternatives evaluated.  First proof of concepts showed that the quality of simple RAG solutions is not sufficient.  A solution based on a RAG approach has limitations about the context size, hallucinations which may reduce the quality of the results (completions). During our first investigation with a RAG and a small LLM (codellama:7b-instruct) GenAI referred to ASC as the “Active Safety System”. In fact, ASC is documented in the source code as “Anti-Slip-Control “. Another problem with RAG based solutions is the chunking of information into not related pieces. This can lead to results not including the whole necessary information. More sophisticated approaches with knowledge graphs or fine tuning of models might be necessary for high quality results. For finetuning, InstructLab might be used.

Share