KPIT featured on HANSER automotive Cover Story “Transforming Automotive Software Validation for Software-defined Vehicles!”

Factors Increasing Complexity of SDV Development and Validation Process

SDV architecture is complex to decide and far more complex to validate. The increase in software applications with complex and dynamic deployment makes software validation exceedingly difficult. Validation of future software updates adds to the burden. Let us analyze the factors that increase the complexity. Firstly, the presence of multiple heterogeneous software and hardware components in a vehicle increases the overall test scenarios by more than 3 times. Multiple domains such as AD/ADAS, Infotainment and Connected Solutions with high software complexity are integrated into a single High-performance chipset (HPC) which in turn consists of different middleware, operating systems, and network components. Each of these should also be validated independently in the context of architectural constraints, compatibility, and integration.

Secondly, analysis & isolation of issues is even harder and even more time consuming due to increased interaction & integration points within the diverse components. The North to South (N2S) and South to South (S2S) communication between the HPC and the multiple zonal ECUs (electronic control units) comes with unprecedented architectural/ network constraints and scenarios.

Thirdly, the test strategy has been tightly defined around Real ECU. Test setup being available only very near-to-finalized architecture for SDVs is too late given the presence of heterogeneous components and increased interactions between them. Also, OEMs (Original Equipment Manufacturers) are getting into supplier contracts for hardware with a substantial amount of uncertainty unlike when software development happened for traditional architecture.

Challenges faced by OEMs due to the Traditional Validation Approach

Thus, with the traditional V cycle approach the OEMs are faced with the following challenges which are pushing the SOP timelines by more than 2 years.

• Feature/function compatibility & integration issues surface only a few months before the SOP. This should ideally be identified continuously from the start of the development phase and should surface well before the SOP timeline.
• The vehicle development process is heavily dependent on realECU (electronic control units). It needs to be decoupled from supplier and real ECU.
• It takes more than four to six weeks to complete system V-cycle and report the issue back to the development team. This needs to be closed in a matter of days.
• The isolation of issues and identification of the root cause is difficult and takes more than a month’s time.

Redefining SDV Validation Process

OEMs need to build a comprehensive test strategy covering all available technology options from Virtual, Reference hardware to Real ECU. Below is a potential list of components that need to be considered to build such a strategy

1. Virtual validation: The existing test strategy is tightly linked with real ECUs. The focus is on stopping the issues from escaping to production. While this still needs to remain the focus, the SDV SOP timeline pressure has increased manyfold due to the reasons stated earlier for SDV. We must think beyond traditional physical validation environments if we must keep pace with the increased volume and complexity of test coverage. Hence, it is necessary to make available a reusable virtual platform and increase its use for test coverage across programs. The usage of cloud-native environments and virtual platforms to complement and left-shift validation across V cycle. Automotive OEMs are spending millions of dollars to create a virtual platform for development and validation. However, investing without a transformational change within their organizations will be a recipe for disaster. Dedicated teams need to own and drive this new process within the existing V cycle rhythm.
2. SDV Reference Architecture Setup: It is crucial to validate the architecture definition, platform & domain hardware constraints an early stage of architecture definition. The architecture design concept should be clear from the start despite the agile approaches. The process and scope of integration are often massively underestimated. To prove the concepts, integration must be started as soon as possible with the right eco-system and not only after real hardware is available. Moreover, the communication system/network is complex and must be viewed in a differentiated manner since not all traffic ((Ethernet
   <-> CAN) is the same. Also, the safety and security aspects must be considered from the beginning. The availability of a reference hardware setup/prototype with SDV architecture can help in the validation of network specifications, architecture decisions, and assumptions during the PoC (proof of concept) phase. This will help OEMs reduce risks by developing hardware prototypes during the architectural PoC (proof of concept) phase and advance the pre-SOP to SOP development cycle by 1 to 2 years.
3. Integrated multi-domain HILs (Hardware in Loop) systems with different manifestations (NW validation, Architecture validation., Integration validation) will be crucial to test interdependencies across various domain functions in the context of SDV. Individual domain HILs will not be sufficient to test the interdependent behavior of different domain functions. Integrated HIL (Hardware in Loop) replicates real- world scenarios by testing all components in an integrated environment and ensures seamless interoperability with real-world network conditions. It also helps accelerate development by enabling parallel testing in a centralized system. They also seamlessly accommodate and test new feature releases ensuring up-to-date system validation. These HILs are further enhanced by advanced analytics that predict system behavior and potential cascading failures.
4. Common instrumentation for all validation steps across V-cycle to Vehicle level.
5. 100% regression automation

How is KPIT helping its clients address the challenges in SDV Validation?

KPIT innovations will help OEMs make their validation strategy SDV ready by creating an integrated test coverage across E/E architecture, vehicle network, platform, multiple domains, and the vehicle. KPIT provides the complete spectrum of platforms and accelerators in the SDV validation process including the components mentioned earlier in virtual engineering, multi-domain system validation, Reference SDV architecture and network testing in the pre-SOP phase. Moreover, we help OEMs focus on seamless orchestration of tools and infrastructure (physical and virtual), formulating an integrated Strategy from CI/CD to Virtual to Physical Validation and creating an early roadmap for program-level implementation.
 

Author