What makes SDV architecture fundamentally different

An SDV leverages a centralized HPC to integrate and manage vehicle functionalities, including ADAS, infotainment, V2X communication, digital cockpit features, and connected vehicle capabilities. Where traditional vehicles spread control across dozens of independent Electronic Control Units (ECUs), an SDV runs these functions as software services on a single, powerful compute platform. Zonal or edge controllers manage specific physical zones such as safety-critical functions like steering, while the HPC serves as the centralised brain.

This architecture reduces wiring complexity and cost, enables real-time data processing from sensors and ECUs, and allows new features to be added or updated via OTA transmission throughout the vehicle's lifetime.

It also means that a bug in one service can cascade across unrelated functions, and an OTA update deployed simultaneously to thousands of vehicles needs to be provably safe before it leaves the server. The validation challenge is no longer just about testing software before launch. It is about building a validation process that keeps pace with a vehicle that never stops changing.

Seven challenges that make SDV validation uniquely hard

Hardware isn't ready when you need it.

SDV HPCs run on advanced System-on-Chip (SoC) components with long development lead times. Traditionally, hardware needed to be available first and software was tested on it. In SDV programs, the reverse is increasingly true. As software development outpaces hardware availability, there is a critical need for enabling early and efficient software validation without dependency on physical hardware.

Features don't live in isolation.

Multiple functions including ADAS, infotainment, V2X, and others run concurrently on the same HPC. Validating each feature independently is necessary but not sufficient. An update to Lane Departure Warning (LDW), for instance, could affect Intersection Collision Warning (ICW) behaviour if integration testing is not rigorous. The interdependencies multiply with every feature added.

Real-world conditions are impossible to fully replicate.

Rare weather events, unusual driver behaviour, edge-case road infrastructure, and unexpected traffic scenarios cannot all be tested physically. Yet these are precisely the conditions most likely to expose software vulnerabilities. Relying on real-world testing alone means critical scenarios will be missed.

Manual testing doesn't scale to OTA cadence.

Modern SDVs require thousands of test cases per feature, across multiple configurations, communication protocols, and vehicle variants. With AI-assisted code development accelerating release cycles and OTA updates arriving frequently, manual testing is simply not economically viable.

OTA updates are both a feature and an attack surface.

The same pipeline that delivers security patches is also a potential vulnerability. Tampered firmware, DDoS attacks on backend or HPC components, corrupted builds, and unauthorised access to safety-critical ECUs are all real risks. Compliance with UN R155 and UN R156 regulations adds further obligation to validate security throughout the OTA pipeline.

Every update must work across every variant of the same model.

Even within a single vehicle model, OTA updates must be validated across all variants: different trim levels, regional configurations, sensor sets, and hardware combinations that share the same base platform but differ in meaningful ways. An update that performs correctly on one variant may cause unexpected behaviour on another. The combinatorial scope of this cross-variant testing cannot be handled manually at scale.

Service-Oriented Architecture introduces its own validation layer.

SDVs are built on SOA principles, where vehicle functions operate as discrete services communicating with each other and with cloud infrastructure. Each new service must be validated at the individual service level, the integration level, and the full system level, without breaking existing services or degrading system performance.

How the AVENIR validation framework addresses each challenge

Tata Elxsi's AVENIR validation framework is built around a single organising principle: SDV validation must run in parallel with development, not after it. Each of the seven challenges outlined above has a corresponding solution within the framework.

1. Virtualisation: removing the hardware dependency

Rather than waiting for physical HPC hardware, AVENIR supports virtualised testing environments at multiple levels of abstraction, from individual application control models such as Simulink models or C++ code (Level 0) through to hardware emulation (up to Level 4). Each level represents a different stage of complexity in simulating hardware and software environments.

This enables software teams to begin validation immediately, detect bugs at the earliest and cheapest point in the development cycle, and left-shift the entire process. When physical hardware does become available, the same test procedures apply with slight modification. Continuity is built into the framework from the start.

2. Platform and feature testing: a structured four-stage sequence

AVENIR follows a structured sequence of platform testing, functional unit testing, integration testing, and HIL testing, where each stage builds on the last before any feature is declared deployment-ready.

Platform testing assesses whether the underlying environment is stable and ready to support higher-level software. This applies to all test assets: virtual ECU, cloud instance, and physical HPC. Sanity tests verify external and internal communication pathways, performance baselines, and overall stability. Issues caught here prevent platform-level failures from contaminating feature test results.

Functional unit testing adds individual feature applications including ADAS, V2X, infotainment, and others, one at a time. Each feature is tested independently to confirm it runs correctly on the target platform: inputs and outputs behave as expected, data loss and corruption are caught, resource allocation across memory, CPU, and time latency is within bounds, and functional behaviour meets requirements.

Integration testing validates what happens when multiple features run together. AVENIR automatically generates all possible feature combinations and runs them before any deployment, ensuring that subscribing to a V2X feature like ICW does not interfere with an existing ADAS feature like LDW. The framework also checks whether multiple application services create conflicts within the vehicle system.

HIL testing brings physical hardware into the loop once it is available. SDV features are tested on the actual HPC with real Controller Area Network (CAN) and Ethernet connections to zonal controllers, plant models simulating sensors and actuators, and fault injection to validate failure handling.

3. Scenario-based testing: lab coverage for real-world conditions

AVENIR uses a dedicated scenario creation and execution engine to simulate driving conditions that would be impractical or unsafe to replicate physically. Scenarios are modelled to cover different road types, traffic conditions, weather environments, accident situations, corner cases, and driver behaviour patterns. Warnings and system responses are verified through log monitoring and HMI alerts on infotainment clusters. This approach gives validation teams comprehensive coverage across the scenario space without the constraints of physical testing.

4. Keyword-based automation and continuous testing: scalable, tool-agnostic test execution

The automation framework uses keyword-based test scripting, where specific vehicle functions such as LDW, ICW, and EV State of Charge are defined as reusable keywords. Test engineers build automated scripts by assembling these keywords rather than writing new code for each test case. Tags within the framework allow efficient filtering and management of test cases across the full requirements set.

This is complemented by data-driven testing, which decouples test logic from input data. The same script can be executed across multiple vehicle configurations, feature variants, and parameter sets such as vehicle speed and turn indicator status, simply by changing the input dataset. Together, these methods support high reusability, minimal script duplication, and reduced maintenance overhead across the entire test library. The framework is tool-agnostic and works across both Software in Loop (SIL) and HIL environments without requiring changes to the underlying test scripts.

To illustrate: an automation test script for validating EV State of Charge (SoC) begins by initialising the test infrastructure including the vehicle simulator, the defined scenario, and the EV SoC and HMI components within the System Under Test. The script evaluates feature behaviour against predefined conditions and returns a pass or fail outcome. Swapping the configuration file or scenario reruns the same logic against a different set of inputs, with no changes to the script itself, delivering consistent and repeatable validation at scale.

Continuous Testing pipeline: validation built into development

One of AVENIR's most significant capabilities is its Continuous Testing (CT) pipeline, integrated directly with CI/CD processes to create an end-to-end DevOps workflow for SDV validation.

The CT pipeline is triggered automatically by every code change, or manually via a developer portal. No component progresses to the next development stage without being tested. Results are returned to developers immediately, enabling early bug identification when fixes are fastest and cheapest. The pipeline maintains full traceability from requirement to test outcome throughout the lifecycle.

What makes this particularly powerful is its flexibility across environments. The same CT pipeline executes tests on virtual ECUs, cloud instances, physical HPC hardware, or hybrid SIL-HIL setups, without requiring separate pipelines for each environment. Test results and reports are stored centrally, giving teams a unified view of software quality at every stage. This is what genuine left-shift looks like in practice: not a process change, but a structural one.

5. Feature compatibility for vehicle platform testing

Even after a feature passes validation, deploying it across a diverse vehicle portfolio introduces a new layer of risk. AVENIR addresses this through a structured compatibility testing process built around a comprehensive feature matrix that maps which features are enabled or disabled for each vehicle variant, enabling clear linear traceability and targeted functional testing.

Following the CT pipeline, validated software services are pushed to a dedicated deployment platform where a comprehensive sanity check is performed across all variants and models of the same vehicle. This catches compatibility issues that may only surface at the intersection of a specific trim level, regional hardware configuration, or sensor set before they reach the field. The result is a controlled, auditable path from validated software to deployed update, minimising integration risk across the full vehicle portfolio.

6. OTA security validation: from build to installation

AVENIR validates every phase of the OTA pipeline: secure build processes, encrypted and cryptographically signed firmware packaging, authenticated transport over TLS 1.3 channels, installation verification, and post-update behaviour. The framework actively simulates adversarial conditions including corrupted binaries, unauthorised feature activation attempts, communication interruptions, and DDoS-like load scenarios on HPC units, and verifies that the system can autonomously detect and reject unsafe or malicious updates. Secure boot verification and automatic rollback mechanisms are tested as part of standard validation runs, in alignment with UN R155 and UN R156 requirements.

7. SOA-compliant validation: service by service, then system-wide

Because SDV software is structured as interacting services, validation must happen at three levels: individual service behaviour, integration between services, and full system operation. AVENIR treats each vehicle application as an independent service, enabling it to be validated without hardware dependencies, followed by layered validation with other services and cloud infrastructure, allowing defects to be caught early at every stage, thereby improving performance and quality ahead of deployment.

This includes validating the registering, publishing, subscribing, and unsubscribing of services, triggered via mobile devices or the vehicle's infotainment system to simulate real user interactions and edge cases. Individual services are deployed within a custom SDV OS, managed by a subscription manager that orchestrates deployment, updates, and removal throughout the vehicle's operational lifetime. New services can be added and validated without disrupting existing ones.

How we think about this at Tata Elxsi

From our work with OEMs and Tier-1 suppliers on SDV programs, one pattern recurs: teams underestimate how much the validation problem changes when software becomes the vehicle. The instinct is to adapt existing testing processes by adding virtualisation here or an automation layer there. What actually works is designing validation as an architectural concern from the outset, applying the same rigour to the test infrastructure as to the product itself.

AVENIR was built from that starting point. Its portability across virtual, cloud, and physical environments, and its ability to operate at every stage of the development cycle, reflects how we believe SDV validation needs to work: not as a series of checkpoints, but as a continuous and parallel process embedded in development from day one.

What this means for SDV programs

Validation is no longer a phase that happens before launch. For SDVs, it is an ongoing operational requirement that must keep pace with OTA update cadence, scale across vehicle variants, and provide security guarantees that traditional automotive testing never had to consider.

Adopted together, AVENIR's framework enables OEMs, Tier-1, and Tier-2 suppliers to reduce time to market by 20-25% and achieve cost efficiencies of 25-30% through early defect detection and parallel development. The framework is portable and adaptable at any stage of the testing and validation cycle.

The frameworks and methodologies that address this well, including virtualisation, automation, scenario simulation, and continuous testing, are individually well understood. The meaningful work is integrating them into a coherent pipeline that works across the full development lifecycle. That integration is what determines whether a program delivers on time, and whether the vehicles in the field remain safe, updatable, and secure.

The question worth asking in any SDV program is not whether to adopt these approaches. It is how early in the cycle you can make them operational.