The real test of a modern vehicle often begins after the launch event, photo opportunities, and long after the final program review has been closed. A vehicle is already in the customer’s hands when a fault surfaces in one market, but cannot be reproduced reliably in validation. The diagnostic code points to one controller, while the logs suggest something else. Validation cannot reproduce the issue with confidence, and the supplier maintains that its Electronic Control Unit (ECU) is operating to specification. The cloud team has data, but lacks sufficient context. The dealership replaces a part, the issue returns, and another warranty claim is filed as ‘no trouble found.’ After-sales seeks answers, program leadership demands timelines, and the customer expects only one outcome – the vehicle should work.This is no longer a corner case, but the operating reality of the industry today. For years, Start of Production (SOP) marked the point at which the primary engineering effort was considered complete, with subsequent changes limited to service actions, field fixes, or the next model year, rather than continuous product evolution.
That logic is breaking down fast. A connected vehicle is not a finished product when it rolls off the line. It is a platform waiting to be evolved. It must be secured, updated, diagnosed, monitored, and improved for years after purchase. The metal may be assembled at the plant, but the engineering life of the product is just getting started.That is why Start of Production (SOP) is now day zero.The industry often talks about software-defined vehicles (SDVs) as a product shift. It is that, but the bigger shift is in how the business has to operate around the vehicle. Many OEMs are still attempting to manage continuous software evolution using rigid, hardware-era stage gates. This gap is increasingly visible in slower issue resolution, field quality challenges, rising warranty costs, and longer timelines for root cause closure. The product has evolved faster than the enterprise built to support it.
Software is no longer just another part
The old automotive model was built to handle physical complexity and it did well. The challenge now is different. A growing share of vehicle complexity lies in software behaviour, timing dependencies, backend interactions and cross-domain conditions that do not stay neatly within one component or team’s scope. That is why a battery drain complaint is not always about the battery, and a telematics dropout is not always about the telematics unit. What appears as a single malfunction may result from a combination of software state handling, network latency, backend handshakes, calibration dependencies and operating conditions that align only intermittently. These issues are rarely clean or contained.
What follows is often predictable and part of the problem. The issue gets split across teams: one reviews software, another checks logs, validation attempts reproduction and suppliers stay within their boundaries. Meanwhile, dealerships interpret software-driven behaviour using tools designed primarily for hardware diagnosis. By the time the full picture emerges, valuable time has been lost.This is one reason field issues now take so long to understand and even longer to close. The problem is not a lack of capable engineers, but that software-driven failures behave like system events, while many organisations still respond as if they were isolated component issues. The gap is costly visible in delayed root cause analysis, rising ‘no trouble found’ claims, repeated workshop visits and weak feedback loops between the field and engineering. More fundamentally, it reflects an inability to quickly determine what actually happened in the vehicle and why. The SDV is exposing a reality the industry can no longer ignore. A continuous product cannot be managed through disconnected engineering systems.
OTA is far bigger than an Update Mechanism
Nothing illustrates this more clearly than the industry’s continued use of the term ‘over-the-air (OTA) capability.’ Too often, OTA is treated as a delivery mechanism almost like a glorified wireless USB stick, which underestimates what it has become. OTA is not just about pushing patches to the vehicle, it is a two-way lifecycle capability.It allows manufacturers to deploy improvements, calibrations and new features without requiring workshop visits. More importantly, a mature OTA pipeline does not just push software into the fleet, it pulls targeted diagnostic data back to inform the next engineering cycle.This fundamentally changes OTA’s role. It becomes the means by which manufacturers retain engineering control after launch, enabling product behaviour to be corrected, refined, governed and understood in the field, while addressing cybersecurity and sustaining software quality beyond SOP.
The complexity of OTA lies not in package transfer, but in the discipline surrounding it – dependency control, variant management, campaign logic, rollback strategy, software provenance, validation evidence, cybersecurity assurance and regulatory traceability. Many organisations are still building this capability. Sending software is straightforward compared to understanding what is changing, where, what it depends on and how field behaviour diverges from lab assumptions.In the SDV era, OTA is not merely a connectivity feature, it is the operating system of post-production engineering.
Edge Intelligence is no longer optional
The same blunt reality applies to data.Modern vehicles generate enormous amounts of data. The industry’s first instinct was to collect more, ship more, store more and analyze more in the cloud. That model has limits and those limits are now becoming evident. The cloud is too slow, too expensive and too distant to handle the full volume of raw vehicle data in a meaningful way. Without intelligence at the edge, OEMs are not building smart fleets, they are building expensive telemetry warehouses. This is why edge intelligence matters. Its role is practical. It acts as a filter by separating normal from abnormal behaviour, preserving context around meaningful anomalies and sending signal rather than noise. By the time raw data reaches the cloud, a brief glitch may have already lost its meaning. A local model at the edge can detect patterns, capture context and escalate actionable insights. This shortens diagnostic cycles, reduces bandwidth use, lowers cloud costs and improves the quality of engineering analysis.Raw telemetry is easy to generate but difficult to interpret. Edge intelligence helps determine what matters before the enterprise is overwhelmed by what does not. This is not a future concept, but a cost, speed and supportability issue today.
AI is the Multiplier, not the Engineer
AI is another area where the market is saying too much and understanding too little. There is a tendency to present AI as a solution that can fix bad software, processes and architecture on its own. It cannot. In connected vehicle engineering, AI is most effective when it acts less like a magician and more like a high-speed filter for human expertise, particularly in diagnostics, prognostics and root cause analysis.A good engineer can reason through a complex failure; the challenge is scale. Across fleets of hundreds of thousands or millions of vehicles, the relationships between software versions, usage conditions, environmental triggers, ECU interactions and backend behaviour quickly exceed what teams can process manually. This is where AI earns its place.It can detect weak digital signatures that precede physical failures such as small voltage drifts over time or patterns across the fleet that local investigations would miss. By narrowing the search space and prioritising what matters, it accelerates root cause analysis.However, engineering judgment remains essential. The final call rests with the engineer who understands system behaviour, safety implications, validation evidence, and real-world impact. AI should not replace that judgment, it should make it faster, sharper and better informed. It is not a standalone solution, but a means to shorten the path to the truth.
Software Factories are the Foundation of Scale
If OTA is the lifecycle mechanism, and edge intelligence and AI make the vehicle more diagnosable and supportable, software factories are what make the system scalable. The automotive industry can no longer integrate software like a craft activity. n this context, a software factory means industrialising code production in the same way the industry once industrialised vehicle manufacturing moving beyond manual, artisanal integration. It includes automated CI/CD pipelines, virtualised ECUs in the cloud, automated hardware-in-the-loop (HIL) testing, built-in traceability and tighter integration across development, validation, compliance and deployment.OEMs need this now for a simple reason that software scale has outgrown spreadsheet governance. Cybersecurity updates across vehicle variants cannot be managed manually, and regulations such as UNECE R156 cannot be addressed through fragmented toolchains or email-driven processes. Continuous software evolution is not feasible when release, validation and compliance systems remain disjointed.
A software factory is not just about speed. It is about controlled scale, discipline and repeatability. The focus is no longer on adding isolated digital capabilities, but on helping OEMs connect embedded engineering, cloud architecture, AI pipelines, validation and field operations into a continuous loop – one that will define future competitiveness.
The Winners will Build the Loop
The most important change in automotive is no longer confined to vehicle architecture. It is happening in the relationship between the vehicle and the enterprise responsible for it—and that is where the next decade will be won or lost. The companies that succeed will stop treating software as another item on the BOM and start treating it as the living logic of the product. They will recognise that SOP is not the end of engineering responsibility, but the point at which it becomes continuous. They will connect what others still manage in silos – embedded software, cloud platforms, OTA, AI, diagnostics, validation, cybersecurity and field operations, because that is what the SDV demands. Not better slogans. Not more dashboards. Not another layer of disconnected tools, but a continuous engineering loop. The companies that build that loop first will not just update vehicles more effectively, they will run the automotive business differently.
Nitin Kamble is Associate Vice President and Expert Delivery - Connected Vehicles, Tata Technologies. Views expressed are the author's personal.