Automation is pivotal to navigating the architectural and data challenges of the software-defined vehicle. By Megan Lampinen
The modern vehicle has evolved from a hardware-led machine into a software-first platform, fundamentally changing design and development strategies. Historically, vehicles relied on dozens of distributed electronic control units (ECUs), each managing a small, isolated function. That world is disappearing. In its place is a centralised architecture built around high-performance computers (HPCs) running millions of lines of code. In this paradigm, traditional ways of designing, developing, managing, and shipping software across the entire vehicle lifecycle are no longer fit for purpose. Instead of building systems that are updated once every model year, teams now support continuous feature delivery, performance optimisation, and safety updates through over-the-air (OTA) pipelines. It’s arguably an unprecedented shift for established automotive engineering teams.
Perforce Software is just one of several companies offering software development and data management solutions targeted at the evolving needs of the software-defined vehicle (SDV). It has a front-row seat to the challenges and opportunities this evolution offers to players across the automotive ecosystem. And according to Kamal Khan, Perforce’s Vice President of North America Automotive/Semiconductor, the right toolkit can offer “tremendous transformation potential.”
Why is the SDV such a big shift for automotive engineering?
This evolution isn’t just a technical change; it’s also an organisational one. The SDV combines the velocity of consumer electronics with the rigour of automotive safety engineering. Teams must integrate simulation workflows, HMI design, drivetrain logic, sensor fusion, infotainment systems, cloud-based services, and algorithms for advanced driver assistance systems (ADAS) around a unified development foundation. And because much of the vehicle’s value is now delivered through software—including predictive maintenance, ADAS, personalised cockpit experiences, and energy optimisation—software becomes the new ‘digital chassis’ that defines the car.
What’s the biggest technical challenge teams face when developing SDVs?
Scale. SDV design and development produces huge volumes of data: from massive codebases spread across global engineering teams to gigabyte-sized HMI assets, including photorealistic 3D instrument clusters and animated visualisation layers. Traditional version control and data management systems, built for text files and smaller repos, simply can’t keep up. As an example, real-time HMI iteration for in-vehicle displays creates enormous asset libraries. Developers working on digital cockpits, often built using game engines such as Unity or Unreal, regularly handle high-resolution textures, 3D vehicle renderings, and sophisticated animation sequences. Each revision might be hundreds of megabytes. Multiply that by daily iterations, and the traditional infrastructure buckles.
What’s needed to solve the issue of scale?
OEMs and suppliers need a high-performance data management system built specifically for SDV-scale development. It needs to sync massive binary files quickly and reliably; support millions of transactions per minute; keep every engineer on the team—often spread across continents—on a single, current, validated source of truth; handle petabyte-scale repositories without sacrificing performance; and integrate smoothly into CI/CD pipelines, simulation platforms, and HMI toolchains.
Without this backbone, development slows to a crawl. Teams wait minutes or even hours for the files and assets they need, merges break, and feature integration becomes unpredictable. Deadlines are missed and project schedules slip.
Why do so many SDV projects struggle with design-to-engineering handoffs?
Designers and engineers operate in fundamentally different worlds. Designers iterate visually and creatively, exploring animations, colours, and UI flows. Engineers work within structured, version-controlled environments governed by compilers, safety constraints, and deterministic build systems. Their tools rarely align. As a result, teams frequently encounter late-stage integration issues, like the wrong asset version being integrated into an infotainment build or design approvals happening in email threads rather than traceable systems. There might be security gaps around proprietary visual assets or visual inconsistencies between variants or model years. These issues are amplified in teams building regional feature variants, where multiple HMI layouts, languages, or regional compliance indicators must coexist. One misplaced asset can break a cockpit experience for an entire market.
How can teams solve this disconnect?
They need a centralised Digital Asset Management (DAM) system integrated directly into the version control platform. A proper DAM solution provides visual previews of every design asset, ensuring non-engineering stakeholders—design, marketing, product—can validate without touching code. It also offers automated enforcement, ensuring the build system pulls only approved versions, along with governance controls protecting brand-critical UI elements and 3D assets from unauthorised access. This transforms the chaotic, manual handoff process into a clean, traceable workflow.
You mentioned regional variants. How can OEMs better manage these, as well as model variants and different software versions?
For that they need to abandon simple branching models and adopt structured stream management. The days of supporting a single vehicle platform for seven to ten years are gone. Modern OEMs must simultaneously manage multiple vehicle lines, various trims, regional variants for Europe, North America, China, etc., model-year refreshes, and OTA updates for vehicles already on the road. This complexity overwhelms linear branching strategies. Structured stream management solves the problem by organising development into stable, validated mainlines, feature streams for in-progress development, and variant streams for trim-specific or region-specific variations.
This approach enables a clear separation of validated versus in-progress work; faster propagation of critical fixes across all product lines; easy handling of regional variants without breaking global builds; and sparse sync, so developers only pull what they actually need. Sparse sync is especially important for teams working with large asset libraries or specialised features. For example, an engineer working on the electric drivetrain module for the Asia market should only have to download the code relevant to that specific task, not the entire graphic assets library for the European infotainment system. This intelligent data provisioning is essential for maintaining high productivity across vast, global teams.
This system also supports continuous OTA deployment pipelines. OTA teams can pull from validated mainlines, ensure no unapproved assets or code slips into builds, and deliver the right updates to in-market vehicles.
In this new world of OTA updates, where software is updated continuously, how can teams ensure—and prove—functional safety compliance?
They need a development system with a comprehensive and immutable audit trail that captures every element included in a build. As OTA updates become the norm, functional safety compliance transforms from a one-time event to a continuous process. Auditors and safety engineers must be able to track requirements and specifications; source code and configuration files; toolchains, compilers, and build environments; test scripts and validation results; and final binaries deployed to vehicles.
A fully traceable system allows teams to instantly generate an ‘audit-ready baseline’, proving that any shipped version of software was built according to functional safety standards and processes—critical for ISO 26262 compliance.
Fine-grained access control also plays a key role here, because safety-critical and non-critical software now live on the same hardware. Strict permissions prevent unauthorised changes to high-criticality code, protecting both high-value IP and vehicle safety. This is essential not only for compliance but also for operational efficiency. OTA pipelines cannot pause while teams manually gather compliance data. Automation is the only sustainable path.
Looking ahead, where do you see the next opportunity for innovation in SDV design and development?
As we move past the architectural challenges of the SDV and more data flows safely and securely across platforms, I think the next wave of innovation will be predictive in-vehicle intelligence driving even smarter safety features, dynamic and immersive HMIs, and more personalised driving experiences.