Automotive CI/CD Is a Different Engineering Discipline. Build It That Way.

The engineering teams building this software need an Automotive CI/CD platform that does not exist in a standard DevOps toolkit. A software-defined vehicle runs on 100 to 150 million lines of code. It must satisfy functional safety standards (ISO 26262), cybersecurity requirements (ISO 21434, AIS 189 in India), and regulatory type approval while shipping OTA updates to vehicles in the field every 6 to 8 weeks. The engineering teams building this software need a CI/CD platform that does not exist in a standard DevOps toolkit.

An automotive engineering services firm in Pune managing embedded software delivery for a German OEM’s body control and ADAS module programs learned this the hard way. Their initial approach adapting a Jenkins and GitHub Actions pipeline from a prior cloud software project collapsed at the hardware-in-the-loop testing stage. Build validation times ran 14 hours. Safety certification traceability was manual. OTA staging had no rollback automation.

The problem was not their engineers. The problem was a web DevOps mental model applied to an automotive software problem.

Why Standard DevOps Fails in SDV Programs

SDV development has three properties that break standard web DevOps toolchains.

Safety lifecycle integration. ISO 26262 requires traceable links from system requirements through software design, implementation, unit test, integration test, and verification for every safety-critical function. This traceability cannot be an after-the-fact audit activity it must be captured as part of the build pipeline. Standard CI tools have no native concept of functional safety classification or ASIL (Automotive Safety Integrity Level) tagging.

Compilation and build complexity. An ECU software stack built on Classic AUTOSAR or Adaptive AUTOSAR compiles against hardware-specific tool chains (usually from Vector, ETAS, or Green Hills Software). These tool chains are not containerized, are often Windows-only, require hardware dongles for licensing, and take 30 to 90 minutes per full rebuild. Treating them like a Node.js or Python build system produces pipelines with 8 to 14-hour cycle times.

Hardware-in-the-loop (HIL) testing. Software validation in automotive requires running code on physical hardware rigs or certified simulation environments. HIL rigs cannot be spun up on demand like cloud VMs. They are physical assets, expensive to procure, and shared across teams. Managing HIL rig scheduling, utilization, and queuing is a platform engineering problem as important as the CI pipeline itself.

Automotive CI/CD is not web CI/CD with ISO 26262 annotations added at the end. The safety lifecycle has to be embedded in the pipeline, not bolted onto it.

Automotive CI/CD Maturity Model (SDMS)

SDMS is a five-level maturity model for automotive software CI/CD programs. Each level adds a specific capability that the previous level’s infrastructure supports. Moving from Level 1 to Level 5 typically takes 18 to 30 months for a program with 30 to 100 embedded software engineers.

Level 1: Version Control and Build Reproducibility

Automotive CI/CD enables automated safety traceability, OTA package creation, and rollback validation. Every software component lives in a version control system (Git with large-file storage for binary artifacts). Every build is reproducible from a pinned toolchain version and dependency lockfile. AUTOSAR tool chain versions are managed as team assets, not as individual developer installations.

Many automotive programs in India are still at this level or below. Individual engineers maintain tool chain installations on local Windows machines. Build reproducibility depends on which machine the build ran on. This is not a DevOps problem it is a configuration management problem that blocks all subsequent automation.

Level 2: Automated Build and Static Analysis

At this stage, Automotive CI/CD automates builds, static analysis, and artifact management for safety-critical software. At Level 2: automated builds trigger on every commit; static analysis tools (MISRA C compliance, Polyspace, QAC) run in the build pipeline against every changed component; build artifacts are stored in a binary artifact repository (Artifactory or Nexus) with ASIL classification tags.

The safety classification tagging at Level 2 is the investment that pays dividends at Level 4 and 5. Teams that skip it discover at certification time that they cannot produce the required tool qualification evidence for their CI system. Add it now.

Level 3: HIL Scheduling and Software-in-the-Loop Integration

At Level 3: software-in-the-loop (SIL) testing runs automatically in the CI pipeline using simulation environments (dSPACE HIL simulators, MATLAB/Simulink test automation, or CARLA for ADAS); HIL rigs are inventory-managed with a rig scheduling system that queues test jobs and reports utilization; test results flow into a test management system (qTest, TestRail, or custom) with links to requirements.

The build time problem in automotive is not a Jenkins configuration problem. It is a hardware-in-the-loop test farm scaling problem. Level 3 forces the program to treat HIL rigs as shared infrastructure with SLA commitments, not as lab equipment that someone books via email.

Level 4: Safety Traceability Automation and OTA Pipeline

At Level 4: requirements traceability is automated CI pipeline links every build artifact to the requirements it covers, the tests that verified it, and the ASIL level it satisfies; OTA update packages are generated, signed, and staged automatically from successful CI builds; rollback capability is tested as part of every OTA pipeline execution.

An OEM that cannot do OTA rollback in under 15 minutes does not have a software-defined vehicle program it has a very expensive field-service liability. Level 4 makes rollback a tested, documented capability, not an emergency procedure.

Level 5: Continuous Deployment to Vehicles and Telemetry Loop

At Level 5: validated updates flow automatically to a shadow fleet of instrumented test vehicles; vehicle telemetry feeds back into the CI system, triggering regression builds when anomalous behavior patterns are detected in the field; deployment ring management (alpha vehicles, beta fleet, general release) is automated with automatic hold triggers based on error rate thresholds.

Level 5 is the operational definition of software-defined. Most programs reach it at month 24 to 30 of a sustained SDMS improvement program.

The Adaptive AUTOSAR Transition Makes This Urgent

Classic AUTOSAR the dominant ECU software architecture for the past 15 years runs on microcontrollers with fixed scheduling and no operating system abstraction. Adaptive AUTOSAR, introduced for high-compute ADAS and infotainment domains, runs on Linux/QNX with a service-oriented architecture, dynamic service discovery, and containerized components.

The DevOps implications are significant. Adaptive AUTOSAR components can be containerized, which means they can be built and tested in standard CI infrastructure, not just on proprietary hardware-specific tool chains. This is the architectural change that makes automotive CI/CD tractable with modern DevOps tooling.

Programs still on Classic AUTOSAR should plan the SDMS progression as described above. Programs migrating to Adaptive AUTOSAR have an opportunity to build the CI infrastructure on a more modern foundation but they still need HIL rig management and safety traceability; the architecture change does not eliminate those requirements.

India’s SDV Engineering Opportunity

India has the strongest embedded software engineering pool for SDV outside of Germany. Tata Elxsi, Tata Technologies (with the recent WHIS partnership), and Tech Mahindra are building SDV engineering practices that compete with traditional Tier-1 suppliers. The constraint is not engineering talent it is DevOps tooling maturity.

Programs that build SDMS Level 3 and 4 capabilities now will win the SDV outsourcing contracts that are moving out of German and Japanese OEM in-house teams over the next 3 years. OEMs evaluating Indian engineering services partners will audit CI/CD maturity as a qualification criterion before awarding embedded software programs.

The SDV Summit in Bangalore this October will be the most important automotive engineering event in India in 2026. The firms presenting SDV DevOps capabilities at Level 4 or above will win the conversations that follow.

What This Means for Automotive Engineering Leaders

If you are running an embedded software program whether inside an OEM or as an Tier-1 or Tier-2 engineering services supplier assess your current SDMS level before committing to new program bids. The assessment takes one day and produces a concrete gap list.

Three decisions to make this month: identify your current tool chain installation management practice and determine whether it can support Level 1 reproducible builds; confirm whether your HIL rigs are scheduled via a management system or via ad hoc team coordination; and determine whether your OTA pipeline has automated rollback tested on a representative vehicle configuration.

If any of the three answers are “no” or “we don’t have that,” your program has SDMS Level 1 or 2 gaps. Closing them before the next OEM program review is worth more than any tooling investment you make elsewhere.

More Blog: Bima Sugam Phase 2 (2026): 7 Best Modernization Steps