From a vehicle with electronics to a software platform
Until recently, a modern vehicle could be understood, from a diagnostic point of view, as a collection of many separate control units. The engine had its ECU, the transmission had its own control unit, the comfort system had another one, airbags had one, ABS had one, infotainment had one. Each control unit had its own task, its own fault memory, and its own communication logic. The technician connected the diagnostic tool, selected the system, read faults, checked measured values, and continued from there.
That world is gradually changing. Not overnight, not across all brands at the same time, but the direction is clear. The vehicle is changing from a hardware-distributed system into a software platform. Functions that used to live in a specific control unit are moving toward more centralised computers, domain controllers or zonal architectures. At the same time, vehicles increasingly rely on cloud communication, remote updates and services that can be activated or changed during the vehicle’s lifetime.
Bosch describes the Software Defined Vehicle as a vehicle whose functions can be continuously optimised and expanded through connectivity and over-the-air updates. It also mentions functions that can be individually activated according to driver needs, including temporary services, apps or features offered as a service.
For the customer, this sounds convenient. For the workshop, it means that the car standing in front of the technician today may not behave exactly as it did yesterday.
When the same model is not technically the same
Mechanics are used to working with model year, engine type, equipment level and engine code. With Software Defined Vehicles, they will increasingly also need to consider software version, activated functions, update status, regional configuration, service subscriptions and previous software interventions.
Two vehicles of the same model and model year may therefore no longer be identical from a diagnostic perspective. One may have received a newer OTA update; the other may not. One may have a feature activated; the other may not. One may have changed ADAS behaviour after a manufacturer software campaign; the other may still be running older software.
The difference matters. In a traditional fault, the workshop looks for a failed component, broken wire, bad sensor, power supply issue or communication fault. In a Software Defined Vehicle, the cause may also be an incompatible software version, an incomplete update, a changed configuration, an inactive online service, or a security restriction.
Zonal architecture: fewer control units, more complex relationships
One of the key technical steps toward the Software Defined Vehicle is the change in electrical and electronic architecture. The traditional model with many separate ECUs is becoming increasingly complex, expensive, and difficult to update. That is why centralised and zonal architectures are becoming more important.
In a traditional vehicle, systems are usually grouped by function. In a zonal architecture, part of the logic moves into more powerful central computers, while zonal controllers manage physical areas of the vehicle. In simple terms, instead of every function having its own dedicated control unit, more functions run as software on a shared computing platform.
Industry analyses from 2025 and 2026 describe zonal E/E architecture as a way to reduce wiring complexity and streamline communication between control units. S&P Global Mobility, for example, describes zonal architecture as reducing complexity by streamlining communication between ECUs, while current technical overviews for 2026 connect centralised and zonal architectures with software-defined vehicles, Ethernet, and virtualisation.
For the workshop, there is a difficult consequence. A fault may no longer be isolated inside one control unit. If a problem appears in the central computing platform, communication layer or software service, it may show up in multiple systems at once. Instead of one clear fault code pointing to one clear area, the technician may see a cluster of symptoms that do not immediately appear related.
For example, after an update a customer may report that lane assistance behaves differently, the infotainment system has changed, and the vehicle shows an online-service warning. In an older vehicle, the workshop might treat these as three separate faults. In an SDV, they may have one software or configuration-related cause.
OTA updates: repair without a workshop visit, but also faults without mechanical intervention
Over-the-air updates are one of the most visible elements of the Software Defined Vehicle. From the manufacturer’s perspective, they make a lot of sense. The vehicle does not need to visit a workshop for every software adjustment. A function can be improved, repaired, or added remotely. Elektrobit describes OTA update solutions as a complete chain that can include backend services, an OTA client and in-vehicle components for software and firmware updates.
For workshops, however, this creates a new reality. A vehicle can change without physically entering the workshop. The customer may arrive and say: “Since yesterday, it behaves differently.” The mechanic opens the bonnet and sees nothing unusual. Wiring is intact, connectors are seated, the sensor values look reasonable. And yet the vehicle behaves differently because the software has changed.
That does not mean OTA is bad. On the contrary, from a safety and repairability perspective, it can be very useful. Research on secure OTA updates points out that remote updates are becoming essential for mitigating software bugs and vulnerabilities in modern electrical and electronic vehicle architectures.
Without that information, a workshop may replace a part that is not faulty.
Diagnostics will no longer be just reading DTCs
In a classic vehicle, fault memory had a central role. A DTC was not always the complete answer, but it was usually a good starting point. It pointed the technician in a direction. In Software Defined Vehicles, reading faults will remain important, but it will no longer be sufficient.
Modern diagnostics will need to work much more with context. The question will not only be “which control unit reports a fault”, but also “which software version is the system running”, “which service was supposed to be active”, “which function is activated”, “whether synchronisation was completed”, “whether the function is blocked by authorisation” and “whether the problem may be outside the vehicle itself”.
This is an uncomfortable change for many workshops. Mechanics are used to the idea that when the vehicle is in the workshop, the problem is in the vehicle. With SDVs, that is not always true. The cause may be in the manufacturer’s backend, the customer’s account, a digital key, a licence, regional settings, an incompatible update or the vehicle’s security policy.
A typical example is a customer complaining that a comfort or online function no longer works. The vehicle communicates correctly from a hardware perspective. The diagnostic tool does not show a traditional fault. The real issue may be that the service is not active, the account has not synchronised, or the vehicle is waiting for an update to finish. This is not a job for a hammer or an immediate control-unit replacement. It is a job for diagnostic reasoning, technical support and understanding the OEM ecosystem.
Regular CAN bus diagnostics
Why this is connected to SGW, SFD and cybersecurity
The Software Defined Vehicle cannot be separated from cybersecurity. The more functions are software-based, remotely updateable and connected to cloud services, the more important it becomes to control who is allowed to change what. That is why security gateways, authorisations, certificates, protected diagnostic functions and access systems such as SGW and SFD are becoming more common.
In older vehicles, the impact of an unauthorised intervention was more limited. In a Software Defined Vehicle, a configuration change may affect not just one control unit, but the behaviour of a whole system. That is why manufacturers are tightening diagnostic access. It is not only a commercial battle over the repair market, although the economic dimension certainly exists. It is also a response to the real risk that unverified changes in a software-based system may affect safety.
A survey published in May 2026 describes SDVs as a major shift from hardware-centric systems to software-centric platforms with OTA updates, automation, connected services, cloud infrastructure, middleware and new challenges in cybersecurity, interoperability, and data management.
For the mechanic, the practical meaning is simple: as the vehicle becomes a software platform, a diagnostic intervention becomes more like an intervention in an IT system. And in an IT system, you never deal only with “a cable and a box”. You deal with permissions, versions, protocols, dependencies, and security policies.
What the future mechanic will need to understand
The mechanic of the future will not be a software developer in overalls. That would be an exaggeration and, for normal workshop work, unrealistic. But the technician will need to understand the basic logic of software systems.
They will need to know that an update can change vehicle behaviour. They will need to recognise when a fault looks like a hardware issue but is related to configuration. They will need to understand why functions that used to work are now blocked without the correct authorisation. They will need to work with logs, reports, software versions and online procedures.
This does not mean traditional mechanical work will disappear. Brakes, suspension, engines, air conditioning, bodywork and wiring will still be there. The difference is that repair will increasingly end with a software step. Replacing a component without adaptation will not be a finished job. Post-crash repair without ADAS calibration will not be a finished job. Replacing a control unit without online authorisation will not be a finished job. And diagnostics without understanding vehicle architecture will increasingly become blind.
What this means for diagnostic-tool customers
For customers buying diagnostics, the most important question will no longer be only how many brands the tool supports. The key question will be how well the tool helps in a real workshop situation. With Software Defined Vehicles, it is not enough to read the longest possible list of control units. The technician needs to understand what to do with the information.
This is where DevCom can act as a practical partner for workshops. Not only as a supplier of diagnostic equipment, but as a company that helps workshops navigate the new electronic reality of vehicles. In SGW/SFD topics, this means explaining when the problem is authorisation. In SDV topics, it means helping the technician distinguish whether they are dealing with hardware, software, configuration, an online service, or an OEM restriction.
In daily workshop practice, that is highly valuable. A technician who understands that the cause may be in the software layer does not replace parts unnecessarily. A workshop that understands updates and authorisation can explain repair time and cost to the customer more clearly. And a diagnostic-tool supplier that can explain this change becomes more than a seller of devices — it becomes an expert guide.
Diagnostics for the Software Defined Vehicle via authorized access to the Security Gateway
What workshops should start doing now
Independent workshops do not need to wait until every vehicle is fully software-defined. The change has already started. Several habits are worth introducing today.
For newer vehicles, workshops should save diagnostic reports before and after repair. They should record software versions where the diagnostic tool allows it. They should ask whether the problem appeared after an update, after component replacement, after an accident or after another workshop’s intervention. They should have stable internet access, a stabilised power supply and a clear process for online-authorised functions.
Training is equally important. This does not mean every technician must understand middleware architecture in detail. But technicians should understand that modern vehicles have software dependencies. They should know that a fault in one area may appear somewhere else. And they should know when it makes sense to call technical support before replacing parts.
The vehicle is changing, and the workshop must change with it
Software Defined Vehicle is not a marketing slogan for developers. It is a trend that will gradually appear in everyday workshop work. First in premium and electric vehicles, later in ordinary models. Just as diagnostics once became standard, working with software, versions, authorisations, and the vehicle’s online ecosystem will also become standard.
For mechanics, this is not a reason to panic. But it is a reason to change the way they think. A modern fault may not look like a failed sensor. It may look like an incomplete update, inactive service, changed configuration or blocked function.