The new round of technological revolution and industrial transformation is in full swing, and the automobile, as one of the best carriers for the integration and application of new technologies, is accelerating its transformation towards intelligence. Smart vehicles have become the strategic direction for the development of the global automotive industry.
The complexity of the electronic systems in vehicles is increasing exponentially, with the proportion of software continuing to grow. Data shows that in 2010, mainstream models contained approximately 10 million lines of source code, while in 2016, this number reached about 150 million lines. By 2018, software accounted for about 10% of the value of D-class vehicles or large passenger cars. According to Morgan Stanley, it is estimated that in the future, the value of software will account for about 60%. The core of vehicle technology and engineering is shifting from traditional hardware to software, with Volkswagen stating that software innovation will account for about 90% of future automotive innovation.
The architecture of vehicles is evolving towards a service-oriented architecture based on a general computing platform. In the future, differentiation among vehicles will increasingly manifest in the user interaction interface and experience empowered by software and advanced electronic technologies. Software will drive technological innovation in automobiles, leading product differentiation. Software defined vehicles (software defined vehicles, SDV) are an inevitable trend.
Software defined vehicles refer specifically to future automobiles where software technology, centered around artificial intelligence, determines the vehicle’s functions, supported by modular and generalized hardware platforms.
The increase and upgrade of functions in software defined vehicles can be achieved through remote deployment and updates of software, with vehicle hardware becoming a modular, generalized platform and resource pool that supports diverse software development and deployment.
Software defined vehicles have attracted widespread attention from both the industry and academia, but no literature has proposed a complete vehicle development process, physical structure, or information structure for software defined vehicles, nor is there a clear architecture for the software defined vehicle technology system. This article proposes the development process, physical structure, and information structure of software defined vehicles and summarizes the software defined vehicle technology system.
1 Vehicle Development
1.1 Vehicle Development Process
1.1.1 Traditional Vehicle Development Process
The vehicle development process defines the responsibilities and activities of various business departments throughout the entire process of a vehicle from concept design through product design, engineering design, manufacturing, and finally to commercialization. It is the core of building the automotive R&D system.
The traditional vehicle development process generally includes planning, concept design, engineering design, prototype testing, and mass production phases. Currently, international automotive manufacturers have established mature templates for R&D processes. Figure 1 shows General Motors’ global vehicle development process.
Figure 1 General Motors’ Global Vehicle Development Process
1.1.2 Software Defined Vehicle Development Process
The software defined vehicle development process still includes the aforementioned five phases overall, but with the following significant differences.
The proportion of software development will increase significantly. According to Morgan Stanley, it is estimated that the value of software may reach about 60% in the future. Additionally, Volkswagen has stated that by 2030, software development costs will account for about half of the total vehicle development costs.
Software and hardware development are decoupled but continue to collaborate, as shown in Figure 2. Software defined vehicles enable effective decoupling and continuous collaboration of software and hardware development, allowing software development, validation, and delivery to be independent of the hardware development schedule, enabling immediate release of software products at all stages of development.
Figure 2 Decoupling of Software and Hardware, Continuous Collaboration
Hardware development is trending towards structured, modular, and toolbox strategies, as shown in Figure 3. Currently, major domestic and international automotive companies focus on platform development in vehicle development, generalizing subsystems and components of different products. The concepts of structuring and modularization are based on platformization; when the number of platforms becomes excessive, it leads to redundancy and waste. By studying the relationships between platforms, a unified architecture can be formed to integrate various platforms. The concept of platformization focuses on the physical sharing of parts, while the concept of structuring emphasizes the same methods in the design process and modularization in the manufacturing process. The toolbox strategy refers to the ability to assemble various vehicle models using modules from an existing vehicle development toolbox, regardless of vehicle size and performance.
Figure 3 Volkswagen’s Platform Modular Strategy (Image from Volkswagen)
From the perspective of the relationship between development strategies and vehicle levels, platformization is a synergy and efficiency enhancement for a single vehicle level, while strategies like shared chassis components are only applicable to specific vehicle level developments. Structuring and modularization are suitable for the development of multiple vehicle levels, and the toolbox strategy covers the development needs of all vehicle levels.
Customization driven by user needs. Software defined vehicles will transform from a single mode of transportation to a user’s third living space, and vehicle development will pay more attention to user needs, guided by those needs.
Overall, the software defined vehicle development process is a dual closed-loop development process, involving both vehicle development and software iteration, as shown in Figure 4. Vehicle development mainly refers to the new car development phase, generally including planning, concept design, engineering design, prototype testing, mass production, etc.; software iteration mainly refers to the user usage phase, where interaction evaluation data collection and user profiling guide software development, utilizing technologies such as OTA remote upgrades for software remote updates and iterations.
Figure 4 Dual Closed-Loop Vehicle Development Process for Software Defined Vehicles
The software defined vehicle development process forms a dual closed-loop. The first closed-loop refers to guiding new car development through interaction evaluation data collection and user profiling, while the second closed-loop refers to the user usage phase, where OTA technology enables continuous software updates and iterations.
Throughout the vehicle’s entire lifecycle, the software iteration process continues, thus making vehicle development a vibrant and ongoing process until the vehicle is scrapped.
1.2 Vehicle Development Models
1.2.1 Traditional Vehicle Development Model
The traditional vehicle development model is a V-shaped development model, as shown in Figure 5. The left side of the V encompasses requirement analysis, while the right side corresponds to module testing, allowing integration testing plan design to be completed before the complete construction of software and hardware models, effectively ensuring compatibility between testing methods and corresponding modules, and efficiently locating testing issues. However, the development design order of “vehicle-system-subsystem-software and hardware” in the traditional V-shaped development model is limited to vehicle development with clearly defined requirements, making it difficult to adapt to the rapid iteration needs of software defined vehicle functions.
1.2.2 Software Defined Vehicle Development Model
Figure 5 Traditional Vehicle Development Model
Software development plays a crucial role in constructing the development model for software defined vehicles. In the traditional iterative software development model, each iteration traverses processes such as requirement analysis, design analysis, and testing, producing a subset of the final product. Continuous iterations make the product more adaptable to changing needs. Additionally, agile development, spiral development, and other software development models can also enhance the efficiency of software product development.
The software defined vehicle development model, as shown in Figure 6, will combine the advantages of traditional software development and the V-shaped vehicle development model, characterized by rapid iterations, continuous integration, parallel development, multi-platform applicability, and user personalization.
In the software defined vehicle development model, system decoupling analysis is first conducted to break down the vehicle into subsystems for requirement analysis, then it enters the continuous integration development phase, following a cycle of “design-development-testing-release”, continuously integrating software and hardware into the system backbone, ultimately completing the release. During the continuous integration development phase, the applicability of various development tool platforms such as CarSim, PreScan, CARLA, etc., can significantly enhance the efficiency of vehicle development.
Figure 6 Software Defined Vehicle Development Model
After the vehicle is put into use, rapid iterations are conducted based on user feedback, re-traversing the “system requirement analysis – continuous integration” process and completing feature releases through OTA technology.
The software defined vehicle development model inherits the advantages of traditional software development models, significantly improving the development and testing efficiency of vehicle systems through parallel development and continuous integration, while maximizing the satisfaction of user personalization needs, ensuring that vehicle development spans the entire product usage cycle.
2 Vehicle Physical Structure
The vehicle physical structure specifically refers to the physical hardware and mechanical structure within the vehicle, including the power system hardware, chassis hardware, sensors, controllers, actuators, body, and cockpit.
2.1 Traditional Vehicle Physical Structure
The traditional vehicle physical structure mainly consists of four parts: engine, chassis, electrical equipment, and body, as shown in Figure 7.
Figure 7 Composition of Traditional Vehicle Hardware Architecture
The engine is the heart of traditional vehicles, providing power. The chassis supports and houses the engine and its components, forming the overall shape of the vehicle, bearing the engine’s power, and ensuring normal driving. The electrical equipment is responsible for starting control, ignition control, lighting and signaling systems, electric auxiliary control, etc., mainly including batteries, generators, starting systems, lighting and signaling systems, information display systems, auxiliary electrical systems, and electronic control systems. The body includes windows, doors, cockpit, passenger compartment, engine compartment, luggage compartment, etc.
2.2 Software Defined Vehicle Physical Structure
The physical structure of software defined vehicles mainly includes power systems, environmental perception systems, decision-making and planning systems, control systems, and intelligent cockpits.
It is worth noting that the physical structure of software defined vehicles has definability and definable levels. As a generalized hardware resource pool, the physical structure of software defined vehicles supports the realization of various software functions. The definability levels vary according to the types and complexities of software functions, thereby imposing different requirements on the physical structure of the vehicle; thus, the physical structure can be defined by software. The higher the definability level of the physical structure, the more complex software functions the vehicle can support. From the perspective of vehicle development, the definability level of the physical structure will become a development option, enabling specialized development for different user groups’ needs and promoting customization in vehicle hardware development.
Below is a brief overview of the main components of the physical structure of software defined vehicles.
(1) Power System
In recent years, many countries have successively introduced policies banning the sale of fuel vehicles or supporting new energy vehicles. Electrification, with its advantages of promoting energy diversification, improving energy conversion efficiency, and having greater emission reduction potential, is the future development trend of automotive power systems. In China, new energy vehicles include pure electric vehicles, plug-in hybrid vehicles, and fuel cell vehicles. Compared to traditional vehicles with engine-based power systems, future software defined vehicles will primarily utilize the aforementioned electrified power systems.
(2) Environmental Perception System
Autonomous driving technology is the core embodiment of vehicle intelligence, primarily consisting of environmental perception, decision-making and planning, and vehicle control. The physical structure of software defined vehicles will encompass environmental perception systems, decision-making and planning systems, and control systems.
The environmental perception system mainly includes body state perception, traffic state perception, and vehicle-to-everything (vehicle to everything, V2X) network communication.
Body state perception includes vehicle speed, angle sensors, combined navigation systems, etc., which obtain real-time operational status of the vehicle and provide input information for subsequent modules.
Traffic state perception mainly includes various environmental perception sensors, such as cameras, LiDAR, millimeter-wave radar, ultrasonic radar, etc. Multiple sensors can overcome the shortcomings of a single sensor through data fusion technology, enhancing overall perception performance.
V2X network communication allows the vehicle to communicate with external vehicles (vehicle to vehicle, V2V), road infrastructure (vehicle to infrastructure, V2I), pedestrians (vehicle to pedestrian, V2P), etc. V2X network communication emphasizes the connection between vehicles, roads, and users, enhancing safety and efficiency through real-time traffic information acquisition.
(3) Decision-Making and Planning System
The hardware of the decision-making and planning system mainly consists of high-performance computing units, such as CPUs, GPUs, FPGAs, and ASICs. During vehicle operation, the computing unit is responsible for real-time processing of data collected by sensors.
In the initial research phase of autonomous driving algorithms, industrial control computers can be used for centralized computing. This centralized computing architecture is beneficial for initial algorithm development; however, its large size, high power consumption, and unsuitability for mass production limit further applications.
Embedded domain controllers are suitable for autonomous driving computing solutions after algorithms mature. The internal computing of software defined vehicles significantly increases, dividing the vehicle into functional domains, each containing a domain controller responsible for calculations in that domain, reducing interference between modules and functions, and enhancing safety.
Additionally, creating dedicated chips with integrated algorithms can effectively combine sensors and algorithms, directly processing raw data, thereby reducing the computational load on the backend computing platform and lowering chip power consumption.
(4) Control System
The control system is responsible for controlling vehicle speed and steering, ensuring that the vehicle follows the pre-planned speed curve and desired path. Traditional control methods include PID control, sliding mode control, fuzzy control, model predictive control, adaptive control, robust control, etc.
Compared to traditional vehicles, drive-by-wire technology will be used more for controlling vehicle steering, braking, and acceleration. Its main feature is that the actuators and control mechanisms have no direct mechanical connection; the driver’s intentions are directly converted into corresponding electrical signals to drive the precise movement of the actuators. The drive-by-wire system technology requires retrofitting the chassis for drive-by-wire, and vehicles currently equipped with adaptive cruise control, emergency braking, and automatic parking capabilities can utilize the existing systems without extensive modifications, achieving control via the onboard network.
(5) Intelligent Cockpit
The future vehicle cockpit has great potential to become the user’s third living space. Advances in next-generation communication technology, artificial intelligence, big data, human-computer interaction, automotive chips, and operating systems will drive the continuous development of intelligent cockpits, making them an important component of the physical structure of software defined vehicles.
3 Vehicle Information Structure
The vehicle information structure specifically refers to the structure involving information communication inside and outside the vehicle, software functions, etc., including the vehicle’s electronic electrical architecture, onboard network, software architecture, and vehicle networking.
The information structure of software defined vehicles can be divided into three layers from the bottom up: vehicle electronic electrical architecture and onboard network, software architecture, and vehicle networking, as shown in Figure 8. The vehicle electronic electrical architecture and onboard network support information communication within the vehicle, the software architecture realizes specific software functions, and vehicle networking integrates in-vehicle networks, inter-vehicle networks, and onboard mobile internet.
Figure 8 Three-Layer Architecture of Software Defined Vehicle Information Structure
3.1 Vehicle Electronic Electrical Architecture and Onboard Network
3.1.1 Traditional Vehicle Electronic Electrical Architecture and Onboard Network
The development of traditional vehicle electronic electrical architecture has gone through three main stages, as shown in Figure 9.
Figure 9 Development History of Traditional Vehicle Electronic Electrical Architecture
The first generation of distributed electronic electrical architecture uses point-to-point linking, the second generation achieves functional modularization, and the third generation adds a central gateway to enable communication between different functional subsystems, as shown in Figure 10.
Figure 10 Third Generation of Distributed Electronic Electrical Architecture
The onboard network is closely related to the development of electronic electrical architecture, and the main types of existing onboard networks are shown in Table 1.
Table 1 Main Onboard Networks
The Controller Area Network (controller area network, CAN) is a bus standard specifically for automobiles, mainly used for control data transmission, and is currently the most widely used standard in the automotive industry. The Local Interconnect Network (local interconnect network, LIN) is a low-cost general-purpose serial bus mainly used for controlling doors, sunroofs, etc. The Media Oriented System Transport (media oriented system transport, MOST) is primarily used for multimedia streaming data transmission. The FlexRay onboard network is mainly used for chassis systems applications such as drive-by-wire in fault-tolerant environments.
The distributed electronic electrical architecture has brought about significant changes in the automotive industry, but the current shortcomings and limitations of this architecture are becoming increasingly apparent, such as poor compatibility of ECU low-level code, code redundancy, poor code reusability, and difficulties in maintenance and updates. Additionally, the demand for high bandwidth and low latency in software defined vehicles is significantly increasing, and the current bus networks can no longer meet this demand.
3.1.2 Software Defined Vehicle Electronic Electrical Architecture and Onboard Network
The new generation of electronic electrical architecture currently under development is based on domain controllers and Ethernet communication networks, as shown in Figure 11. This architecture can improve the problems of traditional electronic electrical architecture and onboard networks, adapting to the needs of software defined vehicles.
Figure 11 Centralized Electronic Electrical Architecture
The centralized electronic electrical architecture still divides functional domains, with each functional domain containing powerful domain controllers (domain control unit, DCU), which integrate complex and relatively centralized functions and also include gateway functions. The core advantage of domain controllers is the significant enhancement of their chip computing power, allowing them to take over the information computation and processing functions of ECUs within the domain, consolidating and uniformly processing the data information of ECUs, and sending the processed data back to the ECUs for execution, which will also promote the integration of ECUs.
The centralized electronic electrical architecture based on domain controllers uses Ethernet as the main communication network, while retaining traditional onboard networks like CAN and LIN below the domain controllers to save costs.
Ethernet has high bandwidth, adopting a flexible star connection topology, with each link capable of enjoying bandwidth of 100 Mb/s or more. The Ethernet standard is open and simple, adapting to the future trend of extensive communication and network connections between automobiles and the outside world. Ethernet’s flexibility and scalable bandwidth are suitable for connecting various subsystems, facilitating the networked operation and management of onboard systems. Ethernet can reduce time, production, and service costs, promoting industry implementation.
The centralized electronic electrical architecture based on domain controllers and the onboard network based on vehicle Ethernet can meet the new demands for information processing capability and network bandwidth in software defined vehicles, achieving high computing power, supporting continuous upgrades of software applications, and enhancing distributed computing capabilities in conjunction with the cloud. Therefore, the centralized electronic electrical architecture based on domain controllers and the onboard network based on vehicle Ethernet are well suited to become the electronic electrical architecture and onboard network of software defined vehicles.
3.2 Software Architecture
3.2.1 Traditional Vehicle Software Architecture and Development Trends
The software of traditional vehicle electronic systems is coupled with hardware, and the development and testing of ECU software depend on hardware, leading to significant difficulties and poor flexibility in development and testing.
Based on this, the AUTOSAR Classic standard was proposed to meet the increasingly complex automotive software needs, allowing similar software solutions to be used across different hardware platforms and enabling software component sharing.
AUTOSAR Classic adopts a layered architecture, dividing the microcontroller layer into three layers: application software layer, middleware RTE, and basic software, as shown in Figure 12.
Figure 12 AUTOSAR Classic Architecture
The AUTOSAR layered architecture realizes the independence of software and hardware modules. The middleware RTE effectively isolates the upper and lower layers of software and hardware, improving the efficiency of software development and testing.
The electronic electrical architecture required for autonomous driving technology must be equipped with controllers with high-performance computing capabilities, and the computing power and communication bandwidth of current controllers need significant upgrades. High-performance computing capability (high throughput, high communication bandwidth) requires support not only from hardware architectures such as heterogeneous multi-core processors and GPU acceleration but also from new software architectures to support cross-platform computing capabilities, high-performance microcontroller computations, and remote diagnostics. Furthermore, V2X communication applications involve dynamic communication and the effective distribution of large amounts of data, requiring software architectures that can support cloud interaction and the integration of non-AUTOSAR systems.
AUTOSAR Classic cannot meet these new demands, leading to the emergence of AUTOSAR Adaptive, whose basic architecture consists of an application layer, operating layer, and basic service layer, as shown in Figure 13.
Figure 13 AUTOSAR Adaptive Architecture
AUTOSAR Adaptive is oriented towards high-performance computing processor architectures, with higher computing power at the hardware layer, achieving higher throughput. While ensuring safety levels and reducing some real-time requirements, it can meet the needs of non-real-time architecture system software and significantly improve high-performance computing capabilities, supporting parallel processing of big data and intelligent interconnected application functions.
AUTOSAR Classic and AUTOSAR Adaptive architectures can coexist and collaborate in different application scenarios, and future vehicles are likely to adopt a heterogeneous software architecture that includes both AUTOSAR Classic and AUTOSAR Adaptive.
3.2.2 Software Defined Vehicle Software Architecture
The software architecture of software defined vehicles, as shown in Figure 14, will inherit the advantages of AUTOSAR Classic and AUTOSAR Adaptive, supporting both high safety and high real-time application scenarios, as well as big data parallel processing and high-performance computing application scenarios. Structurally, it continues the software layered architecture, setting different conceptual layers according to solution settings and software development needs.
Figure 14 Software Architecture of Software Defined Vehicles
The middleware of software defined vehicles will facilitate the separation of applications from hardware, enabling vehicle restructuring and software installation and upgrades, promoting software abstraction and virtualization, and driving the transition of vehicles to service-oriented architectures.
The underlying operating system of software defined vehicles holds significant strategic importance for automakers; in the future, automakers lacking their own operating systems may only become contract manufacturers.
3.3 Vehicle Networking
Software defined vehicles will develop towards fully autonomous intelligent connected vehicles, as shown in Figure 15. Intelligent connected vehicles belong to the intersection of smart vehicles and vehicle networking; thus, vehicle networking will become an important part of the information structure of software defined vehicles.
Figure 15 Relationship Between Intelligent Vehicles, Intelligent Connected Vehicles, and Vehicle Networking
Vehicle networking refers to the Internet of Vehicles, a product of applying Internet of Things technology in the field of intelligent transportation. Vehicle networking enables full-scale network connections between vehicles, roads, people, and service platforms, significantly enhancing the intelligence level of vehicles.
4 Software Defined Vehicle Technology System
This section proposes the software defined vehicle technology system, as shown in Figure 16. The software defined vehicle technology system generally includes the physical structure of the vehicle, information structure, functional layer, software development, hardware development, and evaluation system.
The physical structure layer primarily includes electronic hardware, vehicle hardware, etc. As a modular and generalized platform and resource pool, the physical structure layer supports the information structure and functional layer of the vehicle. The software development process emphasizes user analysis, agile development, customized development, etc., mainly utilizing technologies like OTA for remote deployment and updates of software. The information structure of the vehicle includes vehicle networking, software architecture, vehicle electronic electrical architecture, and onboard networks. The software architecture is a layered architecture, including application software layer, middleware, and basic software layer. The functional layer of the vehicle includes specific vehicle functions like infotainment, intelligent human-computer interaction, autonomous driving functions, system updates, and upgrades. During user usage, the evaluation system can assess the vehicle functions, including subjective and objective evaluations. Through user analysis and feedback from evaluation data, combined with technologies like artificial intelligence and big data analysis, user profiling can be constructed to further guide software development.
Software and hardware have effectively decoupled both structurally and in development. Throughout this process, the definition and realization of vehicle functions are primarily driven by software, with the physical structure of the vehicle no longer bound to a specific function set but abstracted into a resource pool that can be shared by software and services, allowing the vehicle to be defined by software.
Figure 16 Software Defined Vehicle Technology System
Overall, the software defined vehicle technology system possesses the following key characteristics: the decoupling of vehicle software and hardware, the generalized support of vehicle physical structure, the definability of vehicle physical structure, the software-defined nature of vehicle functions, the remote iterative upgrade capability of vehicle software, and the data collection capability of interaction and evaluation.
The decoupling of vehicle software and hardware refers to the realization of decoupling in structure and development, thereby liberating software and improving software development efficiency.
The generalized support of vehicle physical structure means that the physical structure becomes a modular and generalized platform and resource pool, capable of supporting diverse software development and deployment.
The definability of vehicle physical structure allows the physical structure to differ according to its degree of software definition, making the definability level a development option that provides flexibility and customization for the physical structure to meet diverse needs.
The software-defined nature of vehicle functions indicates that vehicle functions will primarily be defined and realized by software, which is the basic meaning and goal of software defined vehicles.
The remote iterative upgrade capability of vehicle software means that software can achieve remote iterative upgrades through technologies like OTA, changing the product usage mode and the vehicle development model, giving the vehicle a lifecycle vitality.
The data collection capability of interaction and evaluation refers to the ability to collect user interaction and evaluation system data, enabling user analysis to meet personalized customization needs.
Software defined vehicles are an inevitable trend. This article analyzes and proposes the vehicle development process, physical structure, and information structure of software defined vehicles and summarizes the software defined vehicle technology system.
In the software defined vehicle technology system, the dual closed-loop development process and parallel development model of software defined vehicles deeply infiltrate software and hardware development, making the vehicle a vibrant product, allowing vehicle development to continue iterating throughout the vehicle’s lifecycle, effectively decoupling the physical structure and information structure of the vehicle, with the definition and realization of vehicle functions primarily driven by software. The physical structure of the vehicle is no longer bound to specific functions but is abstracted into a resource pool that can be shared by software and services, supporting diverse software development and deployment, thereby achieving vehicle definition by software.
As the trend of software defined vehicles intensifies, companies are increasingly transitioning to software-driven enterprises. Currently, there are three main models for this transition: Model one, establishing software subsidiaries; Model two, collaborating with other companies for development; Model three, internally establishing software departments.
Model One: Establishing Software Subsidiaries
Representative Company: Toyota
In July 2020, Toyota announced the reorganization of its Advanced R&D company TRI-AD and the improvement of its business, officially establishing a new holding company and two operating subsidiaries. The new holding company is named Woven Planet Holdings, which will manage the other two operating subsidiaries, Woven CORE and Woven Alpha, and began operations in January 2021.
TRI-AD was established in March 2018 in Japan as a joint venture funded by Toyota, Denso, and Aisin, with Toyota holding 90% of the shares.
Woven Planet Holdings has three subsidiaries: Woven Core and Woven Alpha, with Woven Core focusing on autonomous driving; Woven Alpha creating new businesses in connectivity, in-vehicle software, and high-definition maps, incubating innovative projects; and Woven Capital mainly investing in autonomous driving and smart city sectors to prepare for Toyota’s future cities.
Woven Alpha launched a new open automotive operating system called Arene, which includes essential elements and APIs required for vehicle safety, supporting rapid development from concept to deployment, allowing developers and OEMs to continuously update software in an agile manner while maintaining a high level of safety.
Arene is a vehicle software development platform equipped with state-of-the-art tools, vehicle application programming interfaces (APIs), and security modules, supporting rapid iterations to shorten the time from concept to deployment. The goal is to create the most programmable vehicle on the planet.
Through Arene, developers will be able to deploy the same code to any vehicle running the Arene OS, including middleware and hardware abstraction layers (HAL). Developers can use Toyota’s integrated development environment (IDE) to develop applications, with the IDE providing tools and services, including:
-
Application Software Development Kit (SDK): Tools and APIs for developing, testing, and deploying applications in simulated and real vehicles. Applications can access specific vehicle functions, including user interfaces, sensors, and actuators;
-
Simulation and Testing: Creating virtual scenarios using various vehicle models, and executing software-in-the-loop and hardware-in-the-loop simulations (SILS and HILS) using Arene’s continuous integration and testing pipeline;
-
Infrastructure Services: Processing and indexing data using Toyota’s cloud-based data pipeline through Ansible and Terraform templates, which can automatically create AWS sandboxes;
Specific Plan:
In response to the new demands of intelligent connectivity, Toyota has designed an electronic architecture based on the Central + Zone (Central & Zone Concept) concept, which mainly includes three parts: the vehicle brain or central control ECUs, onboard Ethernet, and cross-zone controllers.
Model Two: Collaborating with Other Companies for Development
Representative Company: BMW
In October 2018, BMW Group successfully established a joint venture with CRITICAL Software, named Critical TechWorks. This joint venture will combine both parties’ expertise in high-quality mobility and automotive software engineering to develop groundbreaking in-vehicle and out-of-vehicle applications.
According to the plan, Critical TechWorks will primarily develop and operate high-end software solutions across various domains, with a product range that includes in-vehicle entertainment information solutions and digital services, mass production autonomous driving transport systems, digital sales and after-sales platforms, and high-end integrated solutions for product data management, ensuring expertise and skills in this field.
Specific Plan:
BMW achieves a seamless layered electronic electrical architecture in the automotive field through an integrated platform. In this architecture, each type of controller has specific system requirements and its classification is based on core demands, replacing localized development methods with a unified development approach.
BMW’s Layered Electronic Electrical Architecture
Characteristics:
-
Controller classification is based on demand;
-
Adjusting to a unified development approach replaces localized development methods;
-
Each type of controller has specific system requirements;
-
System-level optimization will become the main focus, driven by system architects.
Model Three: Internally Establishing Software Departments
Representative Company 1: Volkswagen
Compared to domestic companies, Volkswagen, as a global leader, is more sensitive to the software transformation and moves faster. In June last year, Volkswagen announced the establishment of an independent software development department—Car.Software—to promote the group’s digital transformation, officially separating software and hardware businesses through organizational changes, with a greater degree of transformation compared to domestic companies. The “Car.Software” department brings together over 5,000 digital experts, fully responsible for in-vehicle software business, while also developing more in-vehicle software and vehicle-related services.
Volkswagen Group aims to increase the proportion of self-developed software from less than 10% currently to at least 60% by 2025, with all models equipped with a unified software platform that has all basic functions. The “vw.os” vehicle operating system will become the standard operating system for all Volkswagen brands. The Volkswagen cloud will provide technical support for the “vw.os” system, with the first model equipped being the ID.3 electric vehicle.
Specific Plan:
Compared to the distributed electronic electrical architecture used in the MQB platform, the MEB architecture gradually transitions to a domain-integrated architecture, containing three central computers: ICAS1, ICAS2, and ICAS3, responsible for in-vehicle application services, advanced autonomous driving, and entertainment; communication between the three central computers occurs at a rate of 1000 Mbit/Sec, with most calculations performed by ICAS1.
Upgrade of Volkswagen’s Electronic Electrical Architecture
Volkswagen’s MEB Electronic Electrical Architecture
Representative Company 2: Bosch
In July 2020, automotive parts giant Bosch announced the establishment of a smart driving and control division. As a tier-one supplier, Bosch is redefining its role, transitioning from merely supplying parts to OEMs to becoming a provider of software and electronic solutions.
Previously, Bosch proposed a roadmap for the development of vehicle electronic electrical architecture, dividing the development into six stages: modularization, functional integration, central domain controller, cross-domain integration, onboard central computing, and cloud computing stages. Currently, most manufacturers are beginning to transition from modularization to the functional integration stage.
Bosch believes that the “future ecological software architecture” should include middleware solutions, system software technology stacks, Bosch software packages, Bosch AOS that accelerates autonomous driving development, and an open-source community where Bosch AOS software can be downloaded.
Among these, middleware solutions can support the decoupling of software and hardware, allowing vehicle manufacturers to collaborate on standards while fully competing on application and service levels.
Future Ecological Software Architecture—Middleware Solutions
The system software technology stack enables applications to be ported to either the vehicle terminal or the cloud without affecting functionality.
Future Ecological Software Architecture—System Software Technology Stack
The Bosch software package integrates application software and services, supporting the diverse needs of software applications, promoting collaborative development through standard support, reducing software development workload through mainstream software modules, and tailoring for actual products. The Bosch software package follows a layered architecture, providing portability, maintainability, and problem separation.
Future Ecological Software Architecture—Software Package
Bosch AOS is a middleware and tool that empowers the development, validation, and safe execution of autonomous driving functions, characterized by speed, safety, and low cost.
Future Ecological Software Architecture—AOS
There is a consensus across the automotive industry regarding the importance of software capabilities, but in the process of truly transitioning to software-driven enterprises, everyone is still in the “feeling their way” phase. The transition to software defined vehicles is fundamentally rooted in changes in organizational forms and technological capabilities.
Welcome to all angel round and A round companies in the entire automotive industry chain (including the electrification industry chain) to join the group (friendly connections with 500 automotive investment institutions, including top-tier institutions; a selection of high-quality projects will be presented to existing institutions by theme); there are communication groups for leaders of science and technology innovation companies, groups for the entire automotive industry, automotive semiconductors, key components, new energy vehicles, intelligent connected vehicles, aftermarket, automotive investment, autonomous driving, vehicle networking, and dozens of other groups. To join the group, please scan the administrator’s WeChat (please indicate your company name).
