The Essentials of Body Electronics Validation in the SDV Landscape

The Essentials of Body Electronics Validation in the SDV Landscape

The automotive industry is undergoing a digital revolution with Software-Defined Vehicles (SDVs), which rely on software for functionality, allowing continuous updates and new features. This marks a significant shift from traditional vehicles, which primarily relied on hardware and mechanical components. Vehicle Electronic and Electrical (EE) architectures are evolving, with traditional architectures being replaced by centralized and zonal systems powered by High Performance Compute (HPC) processors. These new architectures support complex, software-driven functionalities, presenting both opportunities and challenges for Original Equipment Manufacturers (OEMs). This article explores the critical aspects of validating Body Electronics in the SDV era, focusing on the factors redefining vehicle architectures, the challenges in validation, and strategies to address these challenges effectively.

Fig 1: The Evolution of Vehicle Architecture: From Distributed to Centralized Systems

Challenges in Validation: Navigating the Complexity of SDVs

As the automotive industry transitions to SDVs, the Body Electronics domain faces significant challenges, requiring multiple levels of validation for both electronics and software. Traditionally, Body Electronics included numerous ECUs responsible for comfort, security, and safety functions, such as lighting, door locking, wipers, and seating.

The transition to SDVs introduces several new challenges, including:

Domain Consolidation : In a zonal architecture, multiple actuations may occur from a single domain. For example, braking could be triggered by an Advanced Driver Assistance System (ADAS), a human driver, or another system and indicated by Body domain under exterior lighting.

Hardware Software Partitioning : Software in SDVs must be agnostic of the specific hardware it runs on. This decoupling allows for greater flexibility in vehicle design and the ability to reuse software across different models and variants.

Time-Critical Operations : Body functions are cyclical or event-driven, with numerous states transitions. Certain functions, like automatic door unlocking during a crash, are safety critical. The software must process and execute these functions within strict time constraints.

Safety and Security Compliance : Adhering to functional safety standards like ISO 26262 and cybersecurity standards like ISO 21434 is critical. These standards ensure that the vehicle’s systems are robust and secure, protecting against both accidental failures, to ensure authorized vehicle access while providing convenience.

Digital Services : Continuous cloud connectivity is essential for SDVs, enabling over-the-air updates and keeping the vehicle’s software updated. This connectivity must be secure and reliable so that end consumer enjoys the features subscriptions in a comfort manner.

These challenges are compounded by the need to validate increasingly complex systems. The shift from traditional “Black Box” ECUs to more controlled “Grey-Box” and “White-Box” models requires OEMs to take a greater role in software development and validation.

Mitigating Validation Challenges: A Comprehensive Approach

To effectively address the challenges posed by the transition to SDVs, a robust validation strategy is essential. This strategy must encompass all stages of development, from system architecture design to software integration and testing.

Fig 2: Comprehensive Approach to meet Validation challenges

1. System Architecture: Mapping Features to Systems

The first step in development is translating user requirements into features, which are then mapped to various systems across domains. This requires understanding system interactions and ensuring they operate together. For example, in a Body Electronics system, access control (e.g., door locking) must interact with the powertrain to lock doors automatically at a certain speed. Early system-level testing is crucial to identify and address potential issues, ensuring all systems interact as intended and features are correctly implemented across domains.

2. Software Architecture: Ensuring Modularity and Scalability

After defining the system architecture, the next step is to develop the software architecture. This involves setting boundaries between software components to ensure modularity and scalability. Applying principles of cohesion and coupling creates optimal interfaces, making components easier to maintain and update. A modular architecture allows for easier updates and scalability, enabling new features to be added or modified without disrupting the entire system. For example, in Body Electronics, separating the software for lighting from door locking allows for independent updates and reduces the risk of unintended interactions.

3. Software Development: Adapting to Different Environments

The software development process varies based on the environment, such as Model-Based Design (MBD), Component-Based Design (CBD), or languages for Android and Linux. Each environment presents unique challenges that must be addressed in the validation strategy. For example, MBD is used for control algorithms, while CBD is preferred for signal processing. The validation strategy must be tailored to the specific environment, with MBD requiring rigorous model validation and Android/Linux-based systems needing extensive testing for third-party application integration.

4. Testing Stages: Ensuring Comprehensive Validation

Validation in the SDV context involves multiple stages of testing, each designed to address specific aspects of the software and system architecture.

 

Fig 3: Stages of testing

• Unit Testing: This initial stage focuses on validating the lowest level of software components, ensuring each one functions as intended according to its architectural specifications.
• Integration Testing: Once individual components are validated, they are integrated to form features. Integration testing ensures these features operate correctly when combined and meet the required specifications.
• Heterogeneous Software Integration: In an SDV, different software components may be developed using various programming languages and tools. Integrating these components into a cohesive system requires careful validation. For example, in a zonal architecture, integrating software developed in C++ with software developed using Model-Based Design (MBD) requires thorough testing to ensure compatibility and correct functionality.
• Software Qualification Testing: This stage involves developing integration test cases to find issues related to behavior, interface, and performance of the integrated software platform. System/software specifications are used to build the test cases. After this stage, system testing is performed, leveraging some test cases from integration testing for acceptance testing.
• System Testing: System testing validates the entire system, including all integrated features, to ensure they work together as intended. This stage is critical for identifying issues that may not be apparent during unit or integration testing.

Best Practices for Validation in the SDV Era

To ensure the success of validation efforts in the SDV era, OEMs should adopt the following best practices:

Develop a Comprehensive Test Strategy:

• Define Testing Levels: Plan for unit, integration, and system testing.
• Identify Inputs: Determine the necessary inputs for each testing level.
• Establish KPIs: Set key performance indicators like test coverage, traceability, and repeatability.

Ensure Traceability:

• Ensure that test cases are traceable to the original requirements. This helps identify gaps in testing and ensures all aspects of the system are validated.

Identify Use Cases for Coverage Improvement:

• Focus on boundary conditions and negative scenarios to improve test coverage. These edge cases are often the most challenging to validate but are critical for ensuring the system’s robustness.   

Employ a Variety of Testing Methods:

• Interface Testing: Validate attributes like naming conventions, data types, and consistency across interfaces.
• Open-Loop Testing: Test components without feedback to validate their individual functionality.
• Closed-Loop Testing: Incorporate feedback loops to test component interactions with their environment.
• Virtual Testing: Perform early validation using virtual environments to detect issues before hardware testing.
• HIL (Hardware-in-the-Loop) Testing: Test software in a real-time environment to validate performance under actual conditions.
• Vehicle Testing: Conduct final validation in the vehicle to ensure that all systems operate as expected in a real-world scenario.

Navigating the Future of Automotive Innovation

The shift to Software-Defined Vehicles (SDVs) is revolutionizing the automotive industry, presenting both opportunities and challenges. To ensure vehicle safety, security, and reliability, Original Equipment Manufacturers (OEMs) require robust validation strategies. By embracing these changes and investing in comprehensive validation, OEMs can position themselves as leaders in automotive innovation.

To address the evolving needs, KPIT offers several accelerators designed to improve both the schedule and quality of products. KPIT along with Technica support customers in speeding up their development processes. Additionally, KPIT provides global OEMs with comprehensive validation solutions across various domains, focusing on quality and cost-efficiency. At KPIT Body Electronics, technological advancements such as low-cost component test benches and AI-generated test cases are leveraged to meet quality and timeline requirements.

Author

Mr. Mahesh Ghivari
Associate Vice President (Body Practice)