Premium cars are increasingly becoming digital platforms that continue to be developed long after they have been sold. This is precisely why the Software-Defined Vehicle is changing the way modern vehicles are designed, implemented and kept up to date.
A modern premium car may have several dozen, and sometimes even over 100, ECUs. Each is responsible for a specific aspect of functionality – from the braking system, through infotainment, to ADAS systems and the management of the traction or auxiliary battery.
For years, this architecture served the needs of the vehicle well, which was understood primarily as a mechanical product. Today, however, a car must operate differently. After leaving the showroom, it will continue to receive OTA updates, new features, fixes and cybersecurity enhancements.
This means that the traditional approach to electronics and software design is no longer sufficient . The increasing complexity of systems, interdependencies and requirements means that manufacturers, Tier-1 suppliers and engineering service providers must think of the vehicle as a constantly evolving technology platform.
This is where the Software-Defined Vehicle comes in – a concept that is a game-changer for the automotive industry.
The Software-Defined Vehicle does not simply mean ‘more code in the car’. It signifies a change in the way the entire vehicle is designed: from the E/E architecture, through hardware selection, to the processes of validation, updating and maintaining functions once series production has begun.
In the traditional model, a vehicle’s functionality was closely tied to a specific controller. If a manufacturer wanted to add a new function, this often required changing a module, integrating a new ECU, or modifying the wiring harness. In the SDV approach, more and more logic is being moved to the software layer, whilst the hardware becomes a scalable computing platform. Functions can be activated, updated and developed throughout the vehicle’s lifecycle – provided, of course, that the architecture has been designed with this in mind from the outset.
This shift affects the entire value chain. OEMs no longer simply purchase a component, but a platform capable of long-term development. Tier-1 suppliers no longer simply supply a controller, but increasingly provide a complete functional domain. Engineering service providers, meanwhile, must understand not only automotive embedded software, but also system integration, cybersecurity, ASPICE and AUTOSAR processes, testing, and requirements relating to OTA/FOTA updates.
One of the most significant changes in SDV is the transition from a distributed architecture to a domain- and zone-based architecture. In a conventional vehicle, many functions were implemented using separate ECUs, which communicated mainly via CAN, LIN and, occasionally, FlexRay. In newer platforms, Automotive Ethernet, central compute, domain controllers and zone controllers are playing an increasingly important role.
In domain-based architecture, functions are grouped according to vehicle areas, such as powertrain, body, chassis or ADAS. Instead of many smaller controllers, a more powerful domain controller is used, which manages a wider range of functions. This reduces the number of ECUs, simplifies communication and improves software management.
For engineering teams, this means greater responsibility for integration. It is not enough simply to write a module that handles a single function. One must understand how a given function interacts with other components, what its timing requirements are, which interfaces it uses, and how it behaves in fault conditions.
The next step is zone-based architecture. In this model, the vehicle is divided into physical zones, and local controllers collect signals from sensors and actuators in specific parts of the car. The data is then sent to a central HPC controller, which performs higher-level functions.
This model helps to better meet the requirements for diagnostics and safety, whilst also reducing the length and weight of wiring harnesses. Automotive Ethernet, Time-Sensitive Networking, SOME/IP, DoIP, UDS, secure boot, HSM and function separation mechanisms are becoming part of the day-to-day work of design teams.
As used in the automotive sector, is becoming less and less like a set of independent functions embedded in individual ECUs. It is increasingly resembling a distributed system operating at multiple levels of abstraction: from MCAL and BSP, through middleware, to applications running on POSIX or Adaptive AUTOSAR platforms.
In practice, this entails several significant changes:
AUTOSAR Classic remains relevant in real-time controllers, such as body, chassis and powertrain controllers. AUTOSAR Adaptive is used where greater flexibility, service-oriented communication, support for more complex applications and integration with ADAS, infotainment or central compute systems are required. Both approaches will coexist for years to come, and their proper integration is becoming one of the key design competencies.
Today, an automotive engineering service provider is not merely an ‘external development team’. In SDV projects, it becomes a partner that helps translate business, regulatory and technical requirements into a functioning, testable and maintainable system.
In the older model, outsourcing often involved the implementation of clearly defined modules. Nowadays, key decisions are made earlier: at the level of system architecture, the distribution of functions amongst ECUs, the selection of middleware, communication strategies, cybersecurity and testing.
The engineering team must ask questions that affect the cost and longevity of the entire platform. Does a given function require real-time capability? Can it operate in an Adaptive environment? What data needs to be transmitted via Ethernet? Can an OTA update cover just the application, or does it require a bootloader change? How can a rollback be ensured if the update fails?
These are no longer merely implementation details. They are decisions that affect SOPs, type approval, functional safety and the vehicle’s maintenance over the years.
SDV increases the demand for interdisciplinary teams. An embedded developer alone cannot solve all the problems. We need system architects , AUTOSAR specialists, test engineers, cybersecurity experts, CI/CD integrators, diagnostics specialists and people who understand ASPICE processes.
In practice, the most important competencies on the supplier’s side include:
This is where the importance of teams that can operate not only quickly but also in a process-driven manner is growing. The automotive sector does not tolerate shortcuts: errors in requirements, undocumented interfaces or insufficient validation can resurface months later – often at a stage when the cost of rectification is at its highest.
One of the most practical consequences of SDV is the changing significance of the SOP milestone. In the traditional model, production start-up occurred at the end of the most intensive development phase. SDV, however, marks the beginning of a long cycle of updates, optimisation and maintenance.
OTA and FOTA enable manufacturers to fix bugs, update features, develop digital services and respond to new threats. However, every update must be secure, reproducible and compliant with regulatory requirements. Mechanisms for authorisation, encryption, version control, rollback, diagnostics and monitoring are required.
Cybersecurity is no longer a separate stage at the end of a project. ISO/SAE 21434 requires a risk-based approach from concept through development, production and operation, right through to product end-of-life. UNECE R155 and R156 further extend these requirements to the level of type-approval and update management. For engineering service providers, this means adopting a ‘security-by-design’ approach rather than a ‘security-as-fix’ one.
Endego operates at the intersection of automotive software, hardware, E/E architecture and the processes required by global OEMs and Tier-1 suppliers. Our experience in automotive software and hardware projects, embedded software, AUTOSAR Classic and Adaptive, ADAS, infotainment, cybersecurity, OTA/FOTA and E/E systems enables us to support clients not only during the implementation phase, but also during integration and validation.
Process infrastructure is also crucial. Projects carried out in accordance with ASPICE, with ISO 9001, ISO 27001 and TISAX certifications, require a different approach to that of typical application development . In SDV, the quality of documentation, requirements traceability, configuration management, regression testing and information security are just as important as the code itself. For OEM and Tier-1 customers, this means the ability to scale teams without relinquishing control over the process.
The biggest challenge will not be the sheer number of lines of code. It will be maintaining consistency between architecture, requirements, safety, cybersecurity and updates throughout the platform’s lifecycle. Vehicle manufacturers will be looking for partners who understand both the technical side and the realities of mass-production projects: SOP deadlines, validation, type-approval, changing requirements, hardware constraints and cost pressures.
Engineering service providers will increasingly take responsibility for entire functional areas, rather than just individual tasks. This requires organisational maturity, the ability to work in an international environment, and the skill to combine expertise in embedded systems, systems engineering, testing, cybersecurity and integration management.
The outlook is clear: vehicles will become increasingly reliant on software, but the success of SDVs does not depend solely on the code. It depends on whether the entire ecosystem – OEMs, Tier-1 suppliers , hardware suppliers and , and engineering service providers – is capable of designing systems that are safe, updatable, scalable and maintainable for 10–15 years.
Companies that are already planning new E/E platforms should treat SDV as a strategic decision rather than a marketing gimmick. This means that the teams responsible for software, hardware, safety, cybersecurity and testing must be involved at an early stage.
It is worth paying attention to several areas right at the start of the programme:
It is precisely these decisions that subsequently determine the pace of software development, the costs of any changes and the minimisation of the risk of delays . In the era of SDV, the competitive edge comes not only from the rapid delivery of features, but also from the ability to maintain them securely after deployment.
If you’re developing an SDV platform, an E/E system, automotive embedded software, ADAS features, infotainment, AUTOSAR, OTA/FOTA or cybersecurity solutions, it’s worth speaking to a team that understands the realities of projects for global OEMs and Tier-1 suppliers.
Get in touch with us and find out how we can support your project – from requirements and architecture analysis, through development, to integration, testing and validation.
The car headlamp is no longer just a lamp. Today, it is one of the most complex technological systems in a vehicle. It combines optics, mechanics, electronics, thermodynamics, sensors, software, type approval and design. It is designed to illuminate the road, assist the driver, react to the surroundings, work in conjunction with other vehicle systems and build brand recognition.
Read moreThe electrification of public transportation in Poland is now an integral part of urban mobility policy and emission reduction strategies. Electric bus procurement programs (EBP) typically focus on two budget items: battery capacity and charging infrastructure.
Read more
