Software Defined Vehicle

The use of microprocessors in motor vehicles comes from requirements of exhaust aftertreatment with catalytic converters and injury prevention with airbags which became commonplace in the US by 1974. In the following years the sensors and controllers were increasingly attached to bus systems, with the CAN bus taking over as standard by 1986. This enabled further integration of electronic components allowing new driver assistance systems in the 1990s. The OBD access (standardised OBD-II DLC since 1996) started to allow chip tuning as a software update (including Remapping). The software functions of the car were originally distributed across multiple components from several suppliers. The automaker Tesla started to centralize the functions coining the term "software-defined" for that in 2012 (borrowed from SDR). The characteristics of a software-defined vehicle were defined differently in the next years. In 2024, the European Commission started the SDVoF initiative (software-defined vehicle of the future) and the Verband der Automobilindustrie (VDA) started the S-CORE project (Eclipse Safe Open Vehicle Core){{cite web|url=https://www.electrive.net/2025/06/25/autobranche-startet-buendnis-fuer-softwareentwicklung/|title=Autobranche startet Bündnis für Softwareentwicklung The shift to software-defined vehicles correlates with the mass production of electric cars. It is triggered by electric cars having fewer mechanical parts that contribute to the value, and their large batteries supporting the energy consumption of computer technology required for self-driving vehicles, which adds a new practical value. The connection is technically not necessary, but it results from a relative shift in product development to higher investments in IT which increases its impact on corporate decisions. This includes productivity paradoxes seen earlier in other areas. == SDV Level ==

The readiness levels of software-defined vehicles are defined as • SDV Level 0: Mechanically Controlled Vehicle • the majority of vehicle functions are performed mechanically; only individual components such as the engine control unit contain electronics. • SDV Level 1: E/E Controlled Vehicle • several ECUs (Electronic Control Units) are installed, providing E/E functions, i.e. being based on electrical and electronic connections. The used microcontrollers run specialized embedded software. • SDV Level 2: Software Controlled Vehicle • the components are connected to one or more control buses (CANopen) which can connect sensors and actuators at several megabits/sec. The software updates are still performed in workshops, with the exception of non-safety-critical areas such as infotainment systems. • SDV Level 3: Partial Software Defined Vehicle • an operating system for the car is defined that allows to integrate multiple functions on a highly integrated System on a chip (SoC) using a module concept and APIs. These software modules can be updated with bug fixes and improved features via over-the-air updates. • SDV Level 4: Full Software Defined Vehicle • the components are connected via a multi-gigabit/s network, enabling the decoupling of software and hardware. The processor for the software is independent from the controls and the software can be switched to a different chip. The update capability allows new functions to be installed in a vehicle that has already been sold. • SDV Level 5: Software Defined Ecosystem • the computing power of the electronic components allows for the use of AI control (SAE J3016 automation). The vehicle's software cano connect to additional plugged-in components and smartphones via standard protocols. The further development of the software functionality follows product cycles and versioning schemes as defined in software development processes. From level 3 onwards, a vehicle is considered an SDV, being a software-defined vehicle. == Features ==

During the transition to software-defined vehicles, features emerged that can be frequently found in newer vehicle models. • Over-the-air-Updates (OTA) is the most frequently cited feature required for SDV. It is based on a wireless interface (typically Wi-Fi or radio network) to perform software updates without workshop assistance. To improve the frequency of updates, software components become increasingly modularized. The availibity of an wireless interface and the required variant management lead to increased use of telemetry. • Cybersecurity and security architectures become of high importance. For infotainment systems, users shall be granted access to an app store, but this should not compromise the driving functions (for example when initiated via voice control). For security-critical subsystems, rigorous signature verification is required, leading to the creation of a seamless update process chain early in the product design stage. Technically, different security zones have emerged within the vehicle, connected via gateways, as well as the isolation of software modules with different priorities. • Gigabit network in combination with a centralized architecture. One or more high-performance processing cores are installed in the vehicle, executing multiple software modules in parallel. Instead of using dedicated I/O ports on the CPU's circuit board, sensors and actuators are connected via the network. • Automated driving becomes a standard feature of newer vehicle generations. The powerful processing units allow even small vehicle models to get many advanced driver assistance systems (ADAS), sometimes with over twenty functions. These can be combined to create self-driving vehicles for which AI systems are regularly needed for environmental perception. • Telemetry and personalization are part of standardized data collection in vehicles. Transferring the data to a fleet management system can increase efficiency and vehicle longevity. Car sharing and Mobility-as-a-Service allow multiple people to use a pool of vehicles. A driver's personal settings can be transferred to other vehicles. Automated feedback to the vehicle manufacturer allows for faster impules on product design. Data protection and privacy requirements lead to a high degree of complexity. == References ==