Edited from: https://www.dongchedi.com/article/7068164617842721284
Today, smart cars have become the strategic development direction of the global automotive industry. The core of automotive technology and engineering has gradually shifted from the traditional hardware level to the software level. Software-defined cars have become an important trend in future automotive development. In this paper, by comparing and analyzing traditional cars and software-defined cars, the software-defined car vehicle development, vehicle physical structure, vehicle information structure, and technical system are proposed.
Foreword: A new round of scientific and technological revolution and industrial transformation is in the ascendant. As one of the best carriers for new technology integration and application, automobiles are accelerating their transformation to intelligence. Smart cars have become the strategic direction of the development of the global automobile industry.
The functional complexity of vehicle electronic systems is increasing exponentially, and the proportion of software continues to increase. Statistics show that in 2010, mainstream models contained about 10 million source code lines, and in 2016 it reached about 150 million lines. In 2018, software accounted for about 10% of the value of D-class cars or large passenger cars. According to Morgan Stanley estimates, software will account for about 60% of the value in the future. The core of vehicle technology and engineering is shifting from traditional hardware to software. According to Volkswagen, software innovation will account for about 90% of future automotive innovation.
Vehicle architectures are moving towards service-oriented architectures based on general-purpose computing platforms. In the future, vehicle differentiation will be more reflected in the user interaction interface and experience level enabled by software and advanced electronic technology. Software will drive automotive technology innovation and lead product differentiation. Software defined vehicles (software defined vehicles, SDV) is the general trend.
Software-defined cars specifically refer to future cars in which software technology with artificial intelligence as the core determines the functions of the entire vehicle under the support of modular and generalized hardware platforms.
The addition and upgrade of software-defined vehicle functions can be realized through remote deployment and update of software. Automotive hardware will become a modular and generalized platform and resource pool to support diversified development and deployment of vehicle software.
Software-defined vehicles have attracted widespread attention inside and outside the industry, but no literature has yet proposed the vehicle development, vehicle physical structure, and vehicle information structure of software-defined vehicles, and there is no clear framework for software-defined vehicle technology systems. In this paper, software-defined vehicle development, vehicle physical structure and vehicle information structure are proposed, and a software-defined vehicle technology system is summarized.
The content structure of this paper is as follows: Chapter 1 discusses the development of software-defined vehicles; Chapter 2 discusses the physical structure of software-defined vehicles; Chapter 3 discusses the information structure of software-defined vehicles; Chapter 4 proposes a software-defined vehicle technology system; Chapter 5 concludes.
1 Vehicle development
1.1 Vehicle development process
1.1.1 Traditional vehicle development process
The whole vehicle development process defines the responsibilities and activities of each business department in the whole process of a car from conceptual design through product design, engineering design, manufacturing, and finally into a commodity, which is the core of building an automobile R&D system.
The traditional automobile development process generally includes planning stage, conceptual design stage, engineering design stage, prototype test stage and mass production stage. At present, the R&D process of international automakers has a mature template. Figure 1 shows the global vehicle development process of General Motors.
[External link picture transfer failed, the source site may have an anti-theft link mechanism, it is recommended to save the picture and upload it directly (img-2376y4a9-1682909742475)(https://p9-dcd-sign.byteimg.com/tos-cn-i -qvj2lq49k0/f7e23beb93f44fdb86545a2aac5fc319~noop.webp?x-expires=1685454912&x-signature=dT7lcZgikQfPbCX36Hp9%2BVHpQ%2BU%3D)]
Figure 1 GM's global vehicle development process
1.1.2 Software-defined vehicle development process
The software-defined vehicle development process still includes the above five stages as a whole, but has the following significant differences.
The proportion of software development will increase significantly. According to Morgan Stanley estimates, the value of software in the future may account for about 60%. In addition, Volkswagen said that software development costs will account for about half of vehicle development costs by 2030.
The development of software and hardware is decoupled, but continuous coordination is shown in Figure 2. Through the effective decoupling and continuous collaboration of software and hardware development, software-defined vehicles make software development, verification, and delivery independent of the progress of vehicle hardware development, and software products can be released immediately at all stages of development.
[External link picture transfer failed, the source site may have an anti-theft link mechanism, it is recommended to save the picture and upload it directly (img-jwuf4Dhp-1682909742476)(https://p9-dcd-sign.byteimg.com/tos-cn-i -qvj2lq49k0/8bc465e475254c40a3cb55b9f805a83f~noop.webp?x-expires=1685454912&x-signature=k6y7wvUEH3rdPu9UwkRYm6B3gcI%3D)]
Figure 2 Software and hardware decoupling and continuous collaboration
Hardware development is developing toward architecture, modularization, and toolbox strategies, as shown in Figure 3. At present, major car companies at home and abroad are focusing on the development of platforms in the development of complete vehicles, and the commonization of subsystems and parts of different products. The concept of architecture and modularization is based on platformization. When there are too many platforms, it will lead to redundancy and waste. By studying the relationship between platforms, a unified architecture is formed to integrate all platforms. The concept of platforming focuses on physical common parts, while the concept of architecture focuses on the same method in the design process and modularization in the manufacturing process. The toolbox strategy means that regardless of vehicle size and performance, various models can be assembled through the integration of modules in the existing vehicle development toolbox.
[External link picture transfer failed, the source site may have an anti-theft link mechanism, it is recommended to save the picture and upload it directly (img-E65ZsYFZ-1682909742476)(https://p6-dcd-sign.byteimg.com/tos-cn-i -qvj2lq49k0/0d8a6cbb24d747998766ddf4af44b399~noop.webp?x-expires=1685454912&x-signature=9Ob9Ff%2F63FV83w6aXLBXziJwrZ8%3D)]
Figure 3 Volkswagen platform modular strategy (picture from Volkswagen)
From the perspective of the relationship between development strategies and vehicle grades, platformization is the synergy of a single vehicle grade, and strategies such as chassis parts sharing are only applicable to the development of specific vehicle grades, while architecture and modularization are suitable for the development of multiple vehicle grades , the toolbox strategy covers the development needs of all automotive classes.
User-oriented customized development. Software-defined cars will transform from a single means of transportation to the third living space for users, and the development of complete vehicles will pay more attention to user needs and be user-oriented.
In general, the software-defined vehicle development process is a double-closed-loop development process, including two levels of vehicle development and software iteration, as shown in Figure 4. Vehicle development mainly refers to the development stage of a new car, which generally includes the planning stage, conceptual design stage, engineering design stage, prototype test stage, mass production stage, etc.; software iteration mainly refers to the stage of user use, through interactive evaluation data collection, User portrait construction guides software development, and OTA remote upgrade and other technologies are used to carry out remote software update iterations.
[External link picture transfer failed, the source site may have an anti-theft link mechanism, it is recommended to save the picture and upload it directly (img-eFvHW9ZS-1682909742476)(https://p3-dcd-sign.byteimg.com/tos-cn-i -qvj2lq49k0/fa2586a219c24f9dbfa2ceb2a319abc6~noop.webp?x-expires=1685454912&x-signature=3C1%2B4%2FzNsopm%2BAH5YWHMLUar6Zo%3D)]
Figure 4 Software-defined automotive double-closed-loop vehicle development process
The software-defined vehicle development process forms a double closed loop. The first closed loop refers to the interactive evaluation data collection and user portrait construction that can guide the development of new vehicles. The other closed loop refers to the continuous software update and iteration through OTA technology during the user use stage.
In the whole life cycle of the vehicle, the software iteration process continues, so the development of the whole vehicle has become a continuous development process with vitality until the vehicle is scrapped.
1.2 Vehicle development model
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-shape covers requirement analysis, and the right side corresponds to module testing, which can complete the design of integrated test schemes before the complete construction of software and hardware models, effectively ensure the compatibility of test methods and corresponding modules, and efficiently locate test problems. However, the development and design sequence of "vehicle-system-subsystem-software-hardware" in the traditional V-shaped development model is limited to the development of a complete vehicle with a clear demand orientation, and it is difficult to adapt to the rapid iteration of software-defined vehicle functions.
1.2.2 Software-defined vehicle development model
[External link picture transfer failed, the source site may have an anti-theft link mechanism, it is recommended to save the picture and upload it directly (img-VgqIy5Vl-1682909742477)(https://p6-dcd-sign.byteimg.com/tos-cn-i -qvj2lq49k0/e03837888acf4ae1b4602d4611e529a9~noop.webp?x-expires=1685454912&x-signature=ZiGhslFNhlIMIoD8OV3%2Bb9NQQQg%3D)]
Figure 5 Traditional vehicle development model
Software development plays an important role in the construction of software-defined vehicle development model. In the traditional iterative software development mode, each iteration traverses the requirements analysis, analysis design and testing processes, and produces a subset of the final product. Multiple uninterrupted iterations make products more adaptable to changing needs. In addition, software development models such as agile development and spiral development can also improve the development efficiency of software products.
The software-defined vehicle development model is shown in Figure 6. It will combine the advantages of traditional software development and vehicle V-shaped development model, and has the characteristics of rapid iteration, continuous integration, parallel development, multi-platform application and user personalization.
In the software-defined vehicle development model, the system decoupling analysis is first performed, and the entire vehicle is decoupled into subsystems for requirement analysis, and then enters the continuous integration development stage, which is carried out repeatedly in accordance with the "design-development-test-release" cycle, and the software is continuously integrated. The hardware is integrated into the system backbone and finally released. In the stage of continuous integration development, the applicability of various development tool platforms such as CarSim, PreScan, CARLA, etc. can greatly improve the efficiency of vehicle development.
[External link picture transfer failed, the source site may have an anti-leeching mechanism, it is recommended to save the picture and upload it directly (img-IIfRLIWj-1682909742477)(https://p6-dcd-sign.byteimg.com/tos-cn-i -qvj2lq49k0/375f7560c8bf4c87b985ee98352ebb3c~noop.webp?x-expires=1685454912&x-signature=dF4dIZVB%2FAs4oWwdE4vxY0QKnT4%3D)]
Figure 6 Software-defined vehicle development model
After the whole vehicle is put into use, rapid iterations are carried out according to user feedback, and the process of "system requirements analysis-continuous integration" is traversed again and the function release is completed through OTA technology.
The software-defined automotive vehicle development model inherits the advantages of the traditional software development model. Through parallel development, continuous integration, and efficient use of the advantages of multiple development tool platforms, it can greatly improve the development and testing efficiency of the vehicle system. At the same time, using the fast iterative software development model can satisfy the individual needs of users to the greatest extent, enabling vehicle development to run through the entire product life cycle.
2 The physical structure of the vehicle
The physical structure of the vehicle specifically refers to the physical hardware and mechanical structure in the vehicle, including power system hardware, chassis hardware, sensors, controllers, actuators, body and cockpit, etc.
2.1 The physical structure of traditional automobiles
The physical structure of a traditional car is mainly composed of four parts: engine, chassis, electrical equipment, and body, as shown in Figure 7.
[External link picture transfer failed, the source site may have an anti-leeching mechanism, it is recommended to save the picture and upload it directly (img-7LgI71ns-1682909742477)(https://p9-dcd-sign.byteimg.com/tos-cn-i -qvj2lq49k0/1e3fa064b1d34779b6768d314b35e21d~noop.webp?x-expires=1685454912&x-signature=vrm%2BKfhLf0C8L%2FydTag2UePQppw%3D)]
Figure 7 Traditional automobile hardware architecture composition
The engine is the heart of a traditional car, powering the car. The chassis is responsible for supporting and installing the engine and its components and assemblies, forming the overall shape of the car, bearing the power of the engine, and ensuring normal driving. Electrical equipment is responsible for starting control, ignition control, lighting and signal system, electric auxiliary control, etc., mainly including battery, generator, starting system, lighting and signal system, information display system, auxiliary electrical system, electronic control system, etc. The body includes windows, doors, cockpit, passenger compartment, engine compartment, luggage compartment, etc.
2.2 Software-defined vehicle physical structure
The software-defined vehicle physical structure mainly includes power system, environment perception system, decision-making planning system, control system, intelligent cockpit, etc.
It is worth noting that the software-defined vehicle physical structure has definability and definable level. The software-defined vehicle physical structure serves as a generalized hardware resource pool that supports the realization of various software functions. Software definition has different levels according to the type and complexity of software functions, and then has different requirements for the physical structure of the vehicle, so the physical structure of the vehicle can be defined by software. The higher the level at which the physical structure of the vehicle can be defined, the more and more complex software functions the vehicle can support. From the perspective of vehicle development, the definable level of vehicle physical structure will become a development option, which can be specially developed for user groups with different needs and promote the customization of vehicle hardware development.
The following briefly summarizes the main components of the software-defined vehicle physical structure.
(1) Power system
In recent years, many countries have introduced policies to ban the sale of fuel vehicles or support new energy vehicles. Electrification has the advantages of promoting energy diversification, improving energy conversion efficiency, and having greater potential for emission reduction. It is the future development trend of automotive power systems. In my country, new energy vehicles include pure electric vehicles, plug-in hybrid vehicles and fuel cell vehicles. Compared with the engine-based power system of traditional cars, the future software-defined car will be based on the above-mentioned electrified power system.
(2) Environmental perception system
Autonomous driving technology is the core embodiment of vehicle intelligence, mainly including three parts: environment perception, decision-making planning and vehicle control. The software-defined vehicle physical structure will cover environment perception system, decision-making planning system and control system.
The environmental perception system mainly includes vehicle body state perception, traffic state perception, vehicle to everything (V2X) network communication, etc.
Vehicle body state perception mainly includes vehicle speed, angle sensors, integrated navigation system, etc. The real-time running state of the vehicle is obtained through sensors and provided to subsequent modules as input information.
Traffic status perception mainly includes various environmental perception sensors, such as cameras, lidar, millimeter wave radar, ultrasonic radar, etc. A variety of sensors can overcome the defects of a single sensor through data fusion technology and improve the comprehensive performance of perception.
V2X network communication enables the vehicle to communicate with external vehicles (vehicle to vehicle, V2V), road facilities (vehicle to infrastructure, V2I), pedestrians (vehicle to pedestrian communication, V2P), etc. communication. V2X network communication emphasizes the connection between vehicles, roads and users, and improves safety and efficiency by obtaining traffic information in real time.
(3) Decision planning system
The hardware of the decision planning system is mainly a high-performance computing unit, such as CPU, GPU, FPGA, ASIC, etc. When the vehicle is running, the computing unit is responsible for processing the data collected by the sensor in real time.
In the preliminary research stage of the automatic driving algorithm, the industrial computer can be used for centralized calculation. Its centralized computing architecture is conducive to the initial algorithm development, but the disadvantages of large size, high power consumption, and unsuitability for mass production also limit further applications.
Embedded domain controllers are suitable for autonomous driving computing solutions with mature algorithms. The amount of internal calculations in a software-defined car has increased significantly. By dividing the car into functional domains, each domain includes a domain controller responsible for the calculation of the domain, which can reduce the mutual interference between modules and functions and improve safety.
In addition, the fusion of solidified algorithms to produce dedicated chips can effectively integrate sensors and algorithms, and directly process raw data, thereby reducing the computing load on the back-end computing platform and reducing chip power consumption.
(4) Control system
The control system is responsible for controlling the speed and steering of the vehicle so 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 with traditional vehicles, wire control technology will be used more to control vehicle steering, braking, accelerator, etc. Its main feature is that there is no direct mechanical connection between the actuator and the control mechanism, and the driver's driving intention will be directly converted into The corresponding electrical signal drives the precise movement of the actuator. The technology of the control-by-wire system requires the modification of the chassis by wire control. At present, vehicles with functions such as adaptive cruise control, emergency braking, and automatic parking can borrow the original system without excessive modification, and can realize control through the vehicle network.
(5) Smart cockpit
The car cockpit of the future has great potential to become the user's third living space. Technological advancements such as new-generation communication technology, artificial intelligence, big data, human-computer interaction, automotive chips and operating systems will promote the continuous development of smart cockpits and become an important part of the physical structure of software-defined vehicles.
3 vehicle information structure
The vehicle information structure specifically refers to the structure of the vehicle involving information communication inside and outside the vehicle, software functions, etc., including the vehicle electrical and electronic architecture, vehicle network, software architecture, and Internet of Vehicles, etc.
The software-defined vehicle information structure can be divided into three layers from bottom to top: the vehicle electrical and electronic architecture, vehicle network, software architecture, and Internet of Vehicles, as shown in Figure 8. The electronic and electrical architecture of the vehicle and the in-vehicle network support in-vehicle information communication, the software architecture realizes specific software functions, and the Internet of Vehicles realizes the integration of the intra-vehicle network, the inter-vehicle network and the in-vehicle mobile Internet.
[External link picture transfer failed, the source site may have an anti-theft link mechanism, it is recommended to save the picture and upload it directly (img-P2i3ydh5-1682909742478)(https://p9-dcd-sign.byteimg.com/tos-cn-i -qvj2lq49k0/7b0e207af1764418a50c41ac62c376c1~noop.webp?x-expires=1685454912&x-signature=qiJ7z8ca1Jf7qHqciArZF3qomO0%3D)]
Figure 8 Software-defined automobile vehicle information structure 3-layer architecture
3.1 Vehicle electrical and electronic architecture and vehicle network
3.1.1 Traditional automotive electrical and electronic architecture and vehicle network
The development of traditional automotive electronic and electrical architecture has mainly gone through three stages, as shown in Figure 9.
[External link picture transfer failed, the source site may have an anti-leeching mechanism, it is recommended to save the picture and upload it directly (img-db38LRHf-1682909742478)(https://p3-dcd-sign.byteimg.com/tos-cn-i -qvj2lq49k0/8495403f4e4640e39dcbf9e64dde6735~noop.webp?x-expires=1685454912&x-signature=A0KPbiJr%2B7n9b%2F1rsjMelv0frT0%3D)]
Figure 9 The development history of traditional automotive electrical and electronic architecture
The first-generation distributed electronic and electrical architecture adopts a point-to-point link, the second-generation distributed electronic and electrical architecture realizes functional modularization, and the third-generation distributed electronic and electrical architecture adds a central gateway to realize a wider range of different functional subsystems. The communication between them is shown in Figure 10.
[External link picture transfer failed, the source site may have an anti-theft link mechanism, it is recommended to save the picture and upload it directly (img-D4mX3UXP-1682909742478)(https://p6-dcd-sign.byteimg.com/tos-cn-i -qvj2lq49k0/0c3f2ee1010247dfb94bf44943bfa0f5~noop.webp?x-expires=1685454912&x-signature=ytt4A4Q%2FyYPGn7zXOGiORqh9KvY%3D)]
Figure 10 3rd generation distributed electrical and electronic architecture
In-vehicle networks are closely related to the development of electrical and electronic architectures. The main types of existing in-vehicle networks are shown in Table 1.
Table 1 Main in-vehicle networks
[External link picture transfer failed, the source site may have an anti-theft link mechanism, it is recommended to save the picture and upload it directly (img-HC4whtIJ-1682909742478)(https://p6-dcd-sign.byteimg.com/tos-cn-i -qvj2lq49k0/b89639a3c10b40e899e6df82c0136414~noop.webp?x-expires=1685454912&x-signature=x2f85wrGzXnazTOL20lbKskoBkg%3D)]
Controller area network (CAN) is an automotive-specific bus standard, mainly used for control data transmission, and is currently the most widely used standard in the automotive industry. The local interconnect network (LIN) is a low-cost universal serial bus, mainly used for the control of doors, sunroofs, etc. The media-oriented system transport bus (media oriented system transport, MOST) is mainly used for multimedia streaming data transmission. FlexRay in-vehicle networking is primarily used in chassis system applications such as brake-by-wire in a fault-tolerant environment.
The distributed electronic and electrical architecture has brought about tremendous changes in the automotive industry, but the shortcomings and limitations of this architecture are becoming more and more obvious, such as poor ECU underlying code compatibility, code redundancy, poor code reusability, and difficulty in maintenance and updating. , the demand for high bandwidth and low latency in software-defined vehicles has increased significantly, and the current bus network can no longer meet the demand.
3.1.2 Software-defined automotive electronic and electrical architecture and vehicle network
The new generation of electrical and electronic architecture currently under development is a centralized electrical and electronic architecture based on domain controllers and Ethernet communication networks, as shown in Figure 11. This architecture can improve the problems of traditional electrical and electronic architecture and vehicle networks, and adapt to Define automotive requirements.
[External link picture transfer failed, the source site may have an anti-leeching mechanism, it is recommended to save the picture and upload it directly (img-gkNY6rNE-1682909742478)(https://p9-dcd-sign.byteimg.com/tos-cn-i -qvj2lq49k0/7cbb15fe6c084651a65887d5cc9c88ac~noop.webp?x-expires=1685454912&x-signature=iht3YcFqCF23yTaj%2BcGQrMAFddM%3D)]
Figure 11 Centralized electrical and electronic architecture
The centralized electronic and electrical architecture is still divided into functional domains. Each functional domain includes a powerful domain control unit (DCU), which integrates complex and relatively centralized functions and integrates gateway functions. The core advantage of the domain controller is the substantial improvement of its chip computing power. The powerful computing power enables the domain controller to take over the information computing and processing functions of the ECUs in the domain, centrally summarize and uniformly process the data information of the computing ECUs, and convert the processed data The information is sent back to the ECU for execution, which will also promote the integration of the ECU.
The centralized electronic and electrical architecture based on the domain controller uses Ethernet as the backbone communication network, and traditional vehicle network Ethernet such as CAN and LIN can be reserved under the domain controller to save costs.
Ethernet has high bandwidth and adopts a flexible star connection topology, and each link can have a dedicated bandwidth of 100 Mb/s and above. The Ethernet standard is open and simple, and adapts to the future development trend of a large number of communications and network connections between automobiles and the outside world. Ethernet is flexible and scalable in bandwidth, suitable for connecting various subsystems and promoting networked operation and management of in-vehicle systems. Ethernet can reduce time, production and service costs, and promote industrial implementation.
The centralized electronic and electrical architecture based on domain controllers and the vehicle network based on vehicle Ethernet can meet the new requirements of software-defined vehicles for information processing computing power and network bandwidth, achieve high computing power, support continuous upgrading of software applications, and enhance communication with the cloud Coordinated distributed computing capabilities. Therefore, the domain controller-based centralized electrical and electronic architecture and the vehicle-mounted Ethernet-based vehicle network are very suitable to become the electrical and electronic architecture and vehicle network of software-defined vehicles.
3.2 Software Architecture
3.2.1 Architecture and Development Trend of Traditional Automotive Software
The software and hardware of traditional automotive electronic systems are coupled together, and the development and testing of ECU software depends on the hardware, which makes development and testing difficult and poor in flexibility.
Based on this, the AUTOSAR Classic standard was proposed to meet the increasingly complex automotive software requirements, use similar software solutions on different hardware platforms, and share software components.
AUTOSAR Classic adopts a layered architecture, which is divided into three layers on the microcontroller layer, namely the application software layer, middleware RTE, and basic software, as shown in Figure 12.
[External link picture transfer failed, the source site may have an anti-theft link mechanism, it is recommended to save the picture and upload it directly (img-vLqQbzs5-1682909742479)(https://p6-dcd-sign.byteimg.com/tos-cn-i -qvj2lq49k0/b0371fbf17e241048d5dcab88f484de3~noop.webp?x-expires=1685454912&x-signature=M%2BIDYQ9Fv9ZukE%2FIlm1A8UDFdkI%3D)]
Figure 12 AUTOSAR Classic architecture
The AUTOSAR layered architecture realizes the independence of software and hardware modules. The intermediate operating environment RTE effectively isolates the upper and lower layers of software and hardware, improving the efficiency of software development and testing.
The electronic and electrical architecture for autonomous driving technology requires a controller with high-performance computing capabilities. The computing power and communication bandwidth of the current controller need to be greatly upgraded. High-performance computing capabilities (high throughput, high communication bandwidth) not only require hardware architecture such as heterogeneous multi-core processors, GPU acceleration, etc., but also need to adapt new software architectures to support cross-platform computing and processing capabilities, high-performance micro Controller calculation and remote diagnosis, etc. In addition, V2X communication applications involve dynamic communication and the effective distribution of large amounts of data, requiring software architectures that can support cloud interaction and integration of non-AUTOSAR systems.
AUTOSAR Classic cannot adapt to these new requirements, so AUTOSAR Adaptive appears on the basis of it. The basic architecture is shown in Figure 13, mainly including application layer, operation layer, and basic service layer.
[External link picture transfer failed, the source site may have an anti-theft link mechanism, it is recommended to save the picture and upload it directly (img-XcayCQ7s-1682909742479)(https://p6-dcd-sign.byteimg.com/tos-cn-i -qvj2lq49k0/603ef0ef0cdb46a196234bf86b705315~noop.webp?x-expires=1685454912&x-signature=043k65QIyisLODmYdhHy%2Bvegnvk%3D)]
Figure 13 AUTOSAR Adaptive architecture
AUTOSAR Adaptive is oriented to the high-performance computing processor architecture, and its hardware layer has higher computing power and higher throughput. In the case of ensuring the security level and reducing a small part of real-time performance, it can meet the requirements of non-real-time architecture system software, greatly improve the processing capacity of high-performance computing, and support parallel processing of big data and intelligent interconnection application functions.
The AUTOSAR Classic and AUTOSAR Adaptive architectures can achieve coexistence and collaboration for different application scenarios. Future cars are likely to adopt heterogeneous software architectures including AUTOSAR Classic and AUTOSAR Adaptive.
3.2.2 Software-Defined Automotive Software Architecture
The software-defined automotive software architecture is shown in Figure 14. The software-defined automotive software architecture will inherit the advantages of AUTOSAR Classic and AUTOSAR Adaptive. It not only supports high-security and high-real-time application scenarios, but also supports big data parallel processing and high-performance computing application scenarios. In terms of structure, the software layered architecture is continued, and different conceptual layers are set according to different solution settings and software development requirements.
[External link picture transfer failed, the source site may have an anti-leeching mechanism, it is recommended to save the picture and upload it directly (img-0MMBwX3a-1682909742479)(https://p6-dcd-sign.byteimg.com/tos-cn-i -qvj2lq49k0/89fd7f76e3964621be4cac8655dc58fd~noop.webp?x-expires=1685454912&x-signature=qOoUY1da0PEJlfdvNpo4YPNfFhU%3D)]
Figure 14 Software-defined automotive software architecture
The middleware of the software-defined car will promote the separation of applications and hardware, undertake the functions of vehicle reconfiguration, software installation and upgrade, promote software abstraction and virtualization, and promote the transformation of the car to a service-oriented architecture.
The software-defined automotive underlying operating system has an important strategic position for car companies. In the future, car companies that lack their own operating systems may only become OEM companies.
3.3 Internet of Vehicles
The software-defined car will develop towards the fully self-driving intelligent networked vehicle on the vehicle side. As shown in Figure 15, the intelligent networked vehicle belongs to the intersection of the intelligent vehicle and the Internet of Vehicles, so the Internet of Vehicles will become the software-defined vehicle vehicle information important part of the structure.
[External link picture transfer failed, the source site may have an anti-leeching mechanism, it is recommended to save the picture and upload it directly (img-3EXzzNRN-1682909742479)(https://p3-dcd-sign.byteimg.com/tos-cn-i -qvj2lq49k0/6fe5454326b04e60badba773f0ca78a6~noop.webp?x-expires=1685454912&x-signature=8yrPsEQ8WaL5dd3uaj19UQUeMxM%3D)]
Figure 15 Relationship between smart cars, smart connected cars, and Internet of Vehicles
The Internet of Vehicles refers to the Internet of Vehicles, which is the product of the application of Internet of Things technology in the field of intelligent transportation. The Internet of Vehicles can realize all-round network connections between cars and cars, cars and roads, cars and people, cars and service platforms, and comprehensively improve the level of car intelligence.
4 Software-defined vehicle technology system
This section proposes a software-defined vehicle technology system. As shown in Figure 16, the software-defined vehicle technology system generally includes the physical structure of the vehicle, the information structure of the vehicle, the functional layer of the vehicle, software development, hardware development, and evaluation system.
The vehicle physical structure layer mainly includes electronic hardware, vehicle hardware, etc. The vehicle physical structure layer serves as a modular and generalized platform and resource pool, providing underlying support for the vehicle information structure and vehicle function layer. The software development process focuses on user analysis, agile development, customized development, etc., and mainly uses technologies such as OTA for remote deployment and update of software. The vehicle information structure includes the Internet of Vehicles, software architecture, vehicle electrical and electronic architecture and vehicle network. The software architecture is a layered architecture, including application software layer, middleware, and basic software layer. The vehicle function layer includes specific vehicle functions, such as infotainment functions, intelligent human-computer interaction, automatic driving functions, system updates and upgrades, etc. During the user's use, the vehicle functions can be evaluated through the evaluation system, including subjective evaluation and objective evaluation. Through user analysis and evaluation data feedback, combined with technologies such as artificial intelligence and big data analysis, user portraits are constructed to further guide software development.
The hardware and software are effectively decoupled in terms of structure and development. Throughout the process, the definition and realization of vehicle functions are mainly driven by software. The physical structure of the vehicle is no longer integrated and bound to a specific function, but is abstracted into a resource pool that can be shared by software and services, so that the vehicle Defined by software.
[External link picture transfer failed, the source site may have an anti-theft link mechanism, it is recommended to save the picture and upload it directly (img-vtKhzNR2-1682909742480)(https://p3-dcd-sign.byteimg.com/tos-cn-i -qvj2lq49k0/e21babdb779d44a0a1100e1a185d34e9~noop.webp?x-expires=1685454912&x-signature=G3eHoxEsWU%2BEqLohwzeLvAMq%2B3U%3D)]
Figure 16 Software-defined vehicle technology system
In general, the software-defined vehicle technology system has the following key features: the decoupling of vehicle hardware and software, the general support of the vehicle physical structure, the definability of the vehicle physical structure, the software definition of the vehicle function, the The remote iterative upgrade of vehicle software and the data availability of interaction and evaluation.
The decoupling of the software and hardware of the vehicle refers to the decoupling of the software and hardware at the structure and development levels, thereby liberating the software and improving the efficiency of software development.
The universal support of the vehicle's physical structure means that the vehicle's physical structure has become a modular and generalized platform and resource pool, which has the ability to support the diversified development and deployment of vehicle software.
The definability of the physical structure of the vehicle makes the physical structure of the vehicle different according to the degree of software definition. The definable level becomes a development option, which makes the physical structure of the vehicle flexible and customizable to meet diverse needs. .
The software definition of vehicle functions means that the functions of the vehicle will be mainly defined and realized by software, that is, the basic meaning and goal of software-defined vehicles.
The remote iterative upgradeability of the vehicle software means that the software can be remotely iteratively upgraded through OTA and other technologies, thereby changing the product usage mode and the vehicle development mode, so that the vehicle has full-cycle vitality.
The data collectability of interaction and evaluation refers to the ability to collect user interaction and evaluation system data, realize user analysis, and meet the needs of personalized customization.
5 Conclusion
Software-defined vehicles are the general trend. This paper analyzes and proposes software-defined vehicle development, vehicle physical structure and vehicle information structure, and summarizes the software-defined vehicle technology system.
In the software-defined vehicle technology system, the software-defined vehicle double-closed-loop development process and the parallel development model penetrate deeply into the development of software and hardware, making the vehicle a viable product, enabling the continuous iterative development of the entire vehicle throughout the vehicle's life cycle, and the physical structure of the vehicle Effective decoupling from the vehicle information structure is achieved. The definition and realization of vehicle functions are mainly 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. Diverse software development and deployment, so that the car is defined by software.