An article discussing the five key elements for the implementation of software-defined cars

1 Architecture upgrade

##1.1 Software architecture: layered decoupling, servitization, API interface standardization

As enterprises transition to software-defined automobile development methods, software architecture also needs to be upgraded simultaneously, introducing the Service-Oriented Architecture (SOA) methodology. Automotive SOA organizes the underlying capabilities of vehicle intelligence. The hardware capabilities and various functions of the car are turned into services. These services are designed with interfaces based on SOA standards and communicate based on SOA standard protocols. In this way, each service component can access each other, thereby expanding the service combination form.

Figure 1 Schematic diagram of SOA service architecture

The introduction of SOA The traditional closed and solidified software system of automobiles has gradually become an open and reusable software ecosystem. In the new round of software architecture upgrades, based on the layered decoupling SOA service-oriented architecture, device abstraction and atomic services are used to realize full serviceization of hardware capabilities. Specific objects include sensors, actuators, and traditional bus communications around the controller. , as well as the controller's own diagnostic and storage devices. At the same time, based on the design idea of ​​"logical semantic conversion", the interface standardization is completed and the interface reusability goals for different platforms and different models are achieved.

Figure 2 Example of basic services under SOA architecture

With Changes in infrastructure and development methods, "software-defined cars" will subvert the entire car development process, and SOA-based software architecture solutions provide important service abstractions for smart car systems. The rigorous encapsulation and layered structure supports the use of agile development methods and interface testing, and reduces the complexity of the system, which will greatly simplify the reuse of software components when vehicles are updated.

Figure 3 Schematic diagram of software layered architecture

Architecture standardization:

Layered architecture introduces the atomic service layer and device abstraction layer into the original vehicle architecture.

• The device abstraction layer is responsible for encapsulating the underlying hardware differences and providing interfaces with the characteristics of the hardware layer in the form of services for the atomic service layer to call. Hardware adjustments should not This leads to changes in the interfaces provided by the system software to the outside world, freeing the application logic from the constraints of the underlying hardware platform;
• The atomic service layer serves as the middle layer, decoupled from the platform and responsible for undertaking application services. Call, access the device abstraction, reflect vehicle model differences, and configure adaptation to enable the reuse of upper-layer applications across vehicle models;
• Application/combination layer services are mainly responsible for user needs The implementation of logic combines ever-changing scenario-based applications by calling the interface provided by the atomic service layer.

Interface standardization:

Cross-model and cross-parts suppliers maximize reuse and reduce software-defined automotive software and hardware Development complexity.

On the basis of architectural standardization, how can the software be used across car companies? It is necessary to standardize the interfaces between layers. Different OEMs, Tier1s, and platform suppliers define the same set of service interfaces, so that software between different OEMs and Tier1s can call each other, greatly increasing the number of software The reusability shortens the vehicle development cycle.

In terms of promoting interface standardization, the China Association of Automobile Manufacturers has released the third edition of the "Software-Defined Automotive Atomic Service API Interface and Device Abstraction API Interface Reference Specification", which contains more than 700 APIs. , covering multiple functional domains such as body control, thermal management, energy management, motion control, intelligent driving domain, power domain, chassis domain, etc. Members participating in the definition of interface standardization include OEMs, parts, basic platform suppliers, and software suppliers business and more than 100 companies.

1.2 Communication architecture: technology application based on in-vehicle Ethernet

With the increasing number of vehicle functions, especially autonomous driving and smart cockpits With the continuous development of automobiles, the signals that need to be transmitted have exploded. Vehicle functions are constantly upgraded and updated. Users have higher requirements for OTA upgrade experience. The traditional CAN bus communication method can no longer meet the growth rate of vehicle functions. Ethernet-based The communication method of network service can realize the flexible reorganization of functions and effectively solve the problem in the traditional signal-oriented communication architecture that due to the addition, deletion/change of individual signals, all systems related to the function will be changed.

Vehicle Ethernet and its supported upper-layer protocol architecture are shown in the figure below. Vehicle Ethernet mainly involves OSI layer 1 and 2 technologies. Vehicle Ethernet supports both AVB and TCP/IP. , DoIP, SOME/IP, DDS and other protocols or application forms.

##Figure 4 Vehicle Ethernet and its supported upper layer protocol architecture

SOME/IP stands for: Scalable service-Oriented Middleware over IP, a scalable service-oriented middleware based on IP, which was incorporated into the AUTOSAR 4.1 specification in 2013.

Figure 5 Supporting service-oriented SOME/IP middleware

Changes brought about after the communication architecture upgrade:

• More flexible communication mechanism: The CAN bus is a broadcast communication, and the multi-master mode makes the information sent by each node May occupy all communication media, but the receiving node can choose whether to receive the information. Ethernet communicates in two ways: one-to-one or one-to-many. In the one-to-one way, the sending node's message covers the address of itself and a receiving node; in the one-to-many way, the sending node's message covers the addresses of itself and a receiving node. The addresses of itself and multiple receiving nodes. Neither affects the communication of other nodes.
• Higher bandwidth, lower latency: The total amount of in-car data transmission and the requirements for transmission speed continue to increase, and driven by the demand for cross-industry standard protocols, It has become inevitable to support more application scenarios and replace traditional automotive in-car communication networks such as CAN/LIN with higher-speed Ethernet.
• More application scenarios, easy interconnection and easy expansion: In-vehicle Ethernet and the off-vehicle network are based on the same protocol. When communicating with the off-vehicle network, the interface transition is smoother. Traditional in-vehicle communication networks are based on unique network protocols and have poor interface standardization; when interacting with off-vehicle networks, protocols of different systems need to be converted. Under the trend of networking, the protocol conversion cost of automotive Ethernet is even smaller.
• Faster OTA upgrade speed, easier-to-use experience: Using Ethernet for OTA upgrade, the communication speed is more than 10 times higher than traditional CAN upgrade, greatly reducing user waiting time. The use of service-based communication SOME/IP can realize flexible reorganization of functions, effectively solving the problem of the increase or decrease/change of individual functions in the traditional architecture with functional requirements as the core, resulting in the need to change function-related systems, and reducing the need for system OTA upgrades. complexity.

1.3 Hardware architecture: Centralized regional access computing power

The electronic and electrical architecture of the vehicle is The cornerstone of realizing software-defined cars. Most of the traditional cars currently sold on the market are distributed electronic and electrical architectures, as shown in the figure below.

Figure 6 Schematic diagram of traditional distributed electronic and electrical architecture

In distribution In the electronic and electrical architecture, car functions are first divided into different modules, such as power control, chassis control, active safety, passive safety, intelligent driving, infotainment and body, etc. Then the functions of each module are further subdivided. For example, the body functions are subdivided into functions such as light control, door control, and seat control. Different electronic control functions are implemented using independent electronic control units (ECUs), and different ECUs communicate through CAN/CAN FD.

Because each ECU is developed by a different supplier and has different embedded software and underlying code, the distributed electronic and electrical architecture causes a lot of redundancy and BOM costs at the vehicle level. In addition, because the in-vehicle software is distributed on various ECUs, and the ECUs are independently completed by each supplier, their software and hardware are tightly coupled, and the OEM does not have the authority to maintain and update the software on the ECU.

Quickly meeting user needs is the key for OEMs to seize market share, and the distributed electronic and electrical architecture severely restricts the speed at which OEMs can respond to market demand. Suppose that after the design of a certain car model is completed, the user proposes to add a driver position memory function, that is, after the driver adjusts the vehicle's seats, steering wheel, exterior mirrors and other related systems to a comfortable position, he can set them as memory positions. Convenient for subsequent quick adjustments. Software changes need to be made to multiple components such as door controllers, seat controllers, steering wheel controllers, and gateways. Only after each component supplier completes the changes and the OEM completes integration testing and vehicle testing can the software be changed. New features are put on the market, which will cause problems such as long development and change cycles and high costs.

To this end, various automobile manufacturers have already begun to reserve new electronic and electrical architecture solutions to promote the rapid realization of software-defined cars. The distinctive features of the new electronic and electrical architecture are centralization of functions (software) and standardization of hardware. Unified management of control functions through a central computing platform/domain controller reduces hardware redundancy and BOM costs, reducing the OEM's dependence on numerous suppliers. New electronic and electrical architectures are mainly divided into three types according to the degree of functional concentration.

The first type: Domain centralized electronic and electrical architecture

In the domain centralized electronic and electrical architecture, The electronic and electrical control functions of the vehicle are divided into N functional domains. Each functional domain is designed with a domain controller. The remaining controllers are intra-domain controllers. The controllers in each domain are generally smart sensors, actuators and traditional controllers.

The schematic diagram of domain centralized electronic and electrical architecture is shown in the figure below. In the example, the electronic and electrical control functions of the vehicle are divided into five functional domains: power domain, chassis safety domain, intelligent driving domain, Infotainment domain and body comfort domain.

Figure 7 Schematic diagram of domain centralized electronic and electrical architecture

Second: Cross-domain centralized electronic and electrical architecture

In the domain centralized electronic and electrical architecture, the domain controller is only responsible for the centralized control of functions in one domain; In the cross-domain centralized electronic and electrical architecture, some domain controllers are responsible for the centralized control of functions of two or more domains, further improving the system functional integration. The more common cross-domain centralized electronic and electrical architecture is the three-domain architecture. The schematic diagram of the cross-domain centralized electronic and electrical architecture is shown in the figure below.

Figure 8 Schematic diagram of cross-domain centralized electronic and electrical architecture

3 The domain architecture is divided into vehicle control domain, intelligent driving domain and intelligent cockpit domain. The original power domain, chassis safety domain and body comfort domain are integrated into the vehicle control domain. The intelligent driving domain and intelligent cockpit domain focus on realizing vehicle intelligence and network connection. change.

The three-domain architecture has 3 domain controllers:

The vehicle domain controller is responsible for vehicle control and has real-time and security requirements. High;

The intelligent driving domain controller is responsible for the realization of functions related to autonomous driving perception, planning, and decision-making;

The intelligent cockpit domain controller is responsible for Implementation of HMI interaction and cockpit related functions.

The third type: regional access centralized electronic and electrical architecture

The centralized electronic and electrical architecture no longer deploys the electronic and electrical systems in the vehicle according to function, but concentrates the control logic of all functional areas of the vehicle on the central computing platform, further improving the system functional integration. The control/computing functions of ECUs in the original distributed and domain-centralized architectures are absorbed by the central computing platform and transformed into simpler sensors or actuators.

In order to reduce the length of the wire harness, simplify communication, provide nearby access and power supply, under the centralized architecture, areas can be divided according to physical locations and regional controllers can be deployed within the areas to form a central computing The architecture of the platform and multiple regional controllers, and the schematic diagram of the centralized electronic and electrical architecture is shown in the figure below.

Figure 9 Schematic diagram of centralized electronic and electrical architecture

Hardware architecture Upgrading requires consideration of the integration of cross-domain functions, layering of software functions under SOA architecture, real-time control after service-oriented, functional safety design, complex hardware design and integration, etc.

2 Security upgrade: Build a multi-layered vehicle-in-depth defense system

2.1 Functional safety

With the continuous upgrading of electronic and electrical architecture technology, more and more systems and components of the vehicle have an impact on functional safety. For this reason, functional safety has also been developed from some key systems to all aspects of the vehicle. Comprehensive development and expansion of the system.

At the same time, due to the emergence of new architecture technologies such as domain controllers and central computing platforms, new technical challenges have been posed to functional safety. Functional safety must establish measures for these complex systems and software. Development and evaluation tools.

Functional safety technology also affects the development of electronic and electrical architecture technology, evolving from traditional fail-safe (Fail-Safe) to fail-operational (Fail-Operational). In the design of electronic and electrical architecture More redundancy (such as communication redundancy, redundant controllers, etc.) and security measures have been introduced.

In the future, the formation of an intelligent vehicle ecosystem will promote functional safety technology to go beyond bicycles and extend to the entire link, achieving the overall safety of the entire intelligent ecosystem.

2.2 Expected functional safety

The expected functional safety related to electronic and electrical architecture refers to the avoidance of insufficient functions, or reasonably foreseeable personal hazards resulting from misuse by personnel. Functional safety technology is expected to be part of automotive technology and the corresponding standard is ISO 21448. Based on the autonomous driving function and its operation design domain, analyze the system configuration scheme that meets the expected functional safety requirements, and determine or select the appropriate electronic and electrical architecture scheme based on the system configuration scheme. Key technical points of expected functional safety:

(1) Autonomous driving safety criterion formulation technology: Develop objective quantification criteria and scientifically determine the safety performance of autonomous driving in known and unknown scenarios Safety level of autonomous driving;

(2) Safety analysis technology: Through safety analysis methods such as STPA, identify the insufficient performance limitations and hazard triggering conditions of autonomous driving safety-related functions, and formulate targeted Measures to carry out functional updates;

(3) Multi-pillar testing technology: an autonomous driving expected functional safety testing system consisting of simulation testing, set scenario testing and real road testing;

(4) Safety demonstration technology: Based on the results of safety development, analysis, testing, etc., formulate expected functional safety archive strategies, evaluate autonomous driving safety risks through GSN and other demonstration methods, and complete expected functional safety Release;

(5) Safety monitoring technology: Monitor the safety performance during autonomous driving operation through in-vehicle and remote means, identify safety risks and carry out necessary risk control measures to ensure Autonomous driving operates safely.

2.3 Network Security

Smart car vehicle terminals, communication pipelines, cloud platforms and mobile applications all face a series of information security threats. Starting from the dimension of automotive cyberspace, through multiple technical collaborations, different means complementation, and multi-level deployment of security defense lines from the outside to the inside, the requirements for depth, balance, and integrity of vehicle information security protection are met. It is necessary to implement and deploy corresponding protective measures based on the new generation vehicle electronic and electrical architecture from the perspectives of network security, intranet security, and ECU security.

Figure 10 Comprehensive network security defense for smart cars

NetLinkSecurity

NetLink access layer mainly resists network attacks such as DOS, PING type, malformed packets, scanning blasting, spoofing, and Trojan horses targeting Ethernet. It is necessary to have the active security protection capability of the car-cloud linkage mechanism, and the protection strategy can be configured in real time through the cloud system, which mainly includes access authentication mechanism, communication protection mechanism, Ethernet firewall mechanism and intrusion detection and prevention (IDPS) mechanism.

In-vehicle network security

In-vehicle network security mainly resists vehicle CAN/CAN FD and vehicle Ethernet Attacks and intrusions include packet monitoring, error injection, packet replay and other attacks. Protection strategies include: bus intrusion detection mechanism, intranet firewall mechanism, functional domain isolation mechanism, bus communication protection mechanism and diagnostic security protection mechanism.

Key ECU security

#In order to ensure that the vehicle system or key data is not destroyed, it is necessary to It has the security capabilities of secure startup, secure storage of key data, and safe system operation, and can provide permission management capabilities for application operation.

Service Security

The SOA security framework needs to follow five basic principles: confidentiality, integrity, authenticity , authorization and availability, network security is achieved through information encryption, digital signatures, password authentication, access control list ACL design, DOS attack monitoring and other solutions and products, while ensuring that these network information can be discovered, accessed, communicated and being monitored.

##Figure 11 Vehicle SOA service network security principles

• In terms of service discovery, set the information security group isolation mechanism so that service broadcast messages are only sent to service users in need;
• In terms of service access, set it for the service provider Information security access control mechanism authenticates and authorizes service requests initiated by service users;
• In terms of service communication, the information security that SOA messages should adopt is determined based on the actual business application scenarios of SOA services. Transmission mechanism;
• In terms of service monitoring, set up a service security monitoring mechanism to discover abnormal events related to SOA services and a security response processing mechanism.

3 Process change: agile development, iterative release

The functions on cars are changing with each passing day, the amount of software code is increasing, and traditional V The waterfall development model has been overwhelmed. In order to quickly deliver the functions that customers most urgently need, it is crucial to transform the software development process. Currently, more and more automotive parts suppliers are turning to agile development. Based on the system architecture to realize software and hardware decoupling and hierarchical architecture of system software, middleware and application software, rapid iteration and release of software functions are achieved, allowing OEMs to quickly occupy the market.

The core of the agile development process is to cultivate the collaboration awareness, responsibility awareness, quality awareness, learning awareness, and innovation awareness of R&D personnel, thereby improving the R&D capabilities of the entire software R&D team and efficiently developing high-quality software products. Feature development adopts an iterative development model with a monthly development cycle, which is further divided into detailed design and review, feature development and code reading, code quality inspection and evaluation, test case design and writing, feature function joint debugging, feature integration review, etc. subprocess. Each sub-process has specific outputs (design documents, source code, review reports, test cases, test reports, etc.) and a quantitative evaluation system (completeness of design document chapters, incremental code measurement report, review opinion density, test case coverage) , defect density, etc.), ensure that each sub-process is achieved in accordance with software development quality requirements, and archive all documents to support software quality traceability.

The version release adopts the rapid iteration mode of software version with weekly release cycle. Versions are released from stable branches every week to fully verify the basic functions and new features of the software, and to solve the problems that have been solved. Conduct regression testing on all issues and release the version after all pass. The business value of agile development:

• #User experience can be released in monthly units.
• Vulnerabilities and patches are released quickly on a weekly basis.
• The software version is iterated on an hourly basis, with components and the vehicle being synchronously integrated and verified automatically (7*24h unattended).

4 Tool chain upgrade: vehicle service development based on SOA

The overall idea of ​​SOA is to design a service model and Different basic services are extracted, hierarchical decoupling is used to define appropriate API interfaces, and the application calls the service API interface to implement business logic. The API interface definition is independent of the hardware platform, operating system and programming language that implements the service, ensuring that services built in different systems can interact in a unified and universal way.

For the automotive industry, SOA is a newly introduced technology that requires an effective set of processes, methods and tool chains. The three complement each other. Currently, the industry does not have a set of very Mature methodology and tool chain, most OEMs and Tier1/Tier2 are in the exploratory stage. The figure below shows a service-based function development process method.

##Figure 12 Service-based function development process method

First The function conducts demand analysis, outputs scenario definition and feature design, as well as the corresponding physical topology and module function definition, and then continues with system design, including service architecture design, service design and communication design. The service definition must be based on the China Association of Automobile Manufacturers software to define automotive work. API interface reference specification published by the group.

5 Upgrading of Industrial Division of Labor: Reasonable Division of Labor, Open Collaboration

Facing the future era of smart cars, as the original industrial value chain begins to be Breaking through, traditional car companies are transforming one after another, new forces are struggling to rise, technological progress is changing with each passing day, cross-border players are all entering the industry, and the elements and forms of industrial competition are quietly changing. On the one hand, it is driving the formation of a new industrial pattern, and on the other hand, it is also giving birth to new industries. The emergence of industrial ecology. The smart car industry is developing in a more diversified and complex direction, with many new technology fields that have never been involved before. Only open cooperation can achieve win-win results, and complementary advantages can form synergy.

5.1 Overall Suggestions

As mentioned above, the automobile industry is evolving toward electrification and intelligence, and technology , user experience, etc. drive the rapid growth of the automotive industry. With the gradual advancement of smart cars, the complexity of vehicle software and hardware is also continuing to increase. The industry's transformation to software-defined cars has become an industry consensus. However, software-defined cars are still in their infancy. The large-scale introduction of software has challenged the automotive industry from design and development. , integration, testing, release and maintenance all bring a series of challenges. Only by properly managing the complexity of the software and hardware combination can we continue to meet consumers' experience needs and form market competitiveness.

Hierarchical decoupling is a key means to improve software reusability and reduce the complexity of software and hardware development. It is also the only way to move towards software-defined cars. Through layered decoupling, software and hardware can be separated, and applications can be separated from the basic platform. However, how to implement it has become a key challenge and will directly affect the strategic goals and value of software-defined cars. From a technical perspective, how to layer the architecture and how to divide services to maximize reuse, simplify development, maintenance and long-term evolution are key challenges. Only reasonable, stable, and unified service division can ensure that the value of software-defined cars is maximized. From the perspective of the industrial chain, how all parties position, divide labor, and collaborate to ensure the maximum interests of all parties is the key difficulty. Openness, cooperation, and win-win are the basis for the rapid implementation of software-defined cars.

Overall recommendations:

Strengthen cooperation and collaboration between upstream and downstream enterprises in the automotive industry chain from the aspects of uniformity of technical specifications and reasonable division of labor in the industry, and jointly Promote the standardization of smart car software and hardware interfaces, build atomic service and device abstraction layers, and achieve hierarchical decoupling of applications, basic platforms, and hardware; establish SOA service architecture and interface standardization and unification to maximize cross-model and cross-parts suppliers. Reuse, reduce customization, accelerate innovation, and improve the collaborative efficiency of the smart car industry. At the same time, combined with the demands and advantages of all parties in the industry chain, based on the hierarchical structure, a reasonable division of labor is formed to achieve full cooperation.

Specific suggestions:

• # At the device abstraction layer, realize the decoupling of devices and ports, and shield differences in hardware functions and manufacturers. , and this layer is jointly defined by the industry and standardized;
• In the basic platform layer, basic software and hardware are decoupled, and differences in devices and drivers are shielded;
• In the atomic service layer, the service and platform are decoupled to improve software reusability, and this layer is jointly defined and standardized by the industry;
• In application/combination The service layer realizes the decoupling of applications and services, reuses applications across vehicle models, and focuses on experience. It is recommended that this layer be led by OEMs.

##Figure 13 Overall recommendations for software-defined automotive industry cooperation

# #At the same time, API standardization does not mean homogenization of industry competition, openness in standards and competition in products. OEMs and parts suppliers can hierarchically build core competitiveness in key technologies, build management capabilities in collaboration to improve efficiency and scale, and build protection mechanisms in business models to ensure exclusive/first-mover advantages, thereby ultimately facing users Provide unique, evolveable, and higher value-added products.

At the same time, hardware, software, and platforms from different manufacturers are interoperable, that is, different models and components can use the same language to complete cross-domain calls, exchanges and sharing of information. capabilities, benefiting every enterprise in the industry chain.

For OEMs:

Easier to manage: Transition to object-oriented software management model, software Onetrack, easier to manage and more complex vehicle software systems and suppliers, and can focus on integration capabilities to build competitiveness;
Faster time to market: Efficient software development based on SOA, and can pre-integrate service APIs to accelerate model launches speed.

For parts suppliers:

Reduce customization: Reduce the complicated work that does not add value and reduce the cost of oriented to different models Development and maintenance costs;
Accelerate innovation: release talents to focus on innovation and build differentiated technologies and products.

For software development companies/developers:

Easier to get started: easy to understand, integrate development resources, and develop quickly ;
More opportunities: Bring new thinking from cross-border talents into the automotive industry, continue to tap into post-market value, and bring more room for realization.

5.2 OEM

Original vehicle manufacturers directly face end users, provide automotive products that meet user needs, integrate software and hardware, application functions, and ecological services to complete the delivery of complete vehicle manufacturing to long-term travel services.

Original vehicle manufacturers are not only manufacturers of automobiles, but also provide mobile travel-related services to consumers. Through software development, configuration, and iterative upgrades, they can satisfy the diverse needs of users. car demand. Users can set different functions of automobile products through the software, and can even edit travel scenes or download specific scene functions according to personal preferences. To this end, OEMs need to complete the construction and development of the following platforms:

1) Hardware platform integration

Hardware platforms are the foundation of software-defined cars. Currently, there are three main electronic and electrical architectures planned by various OEMs: centralized functional domains, cross-domain integration, and central computing domain regional access. In order to meet the needs of intelligent cars and software-defined cars, central computing domain and regional access will be the mainstream electronic and electrical architecture in the future. OEMs need to reasonably allocate the functions of each domain and the interfaces for regional access hardware according to their own conditions.

2) Software integration

Original vehicle manufacturers need to have software integration capabilities and build a "software center" or " User Experience Center" and establish a corresponding organizational structure to improve vehicle software development capabilities.

The first stage: focus on vehicle control application layer software and software strongly related to user experience to form brand characteristics and improve user stickiness. Build a software development environment and follow the software development process, such as importing AUTOSAR specifications, etc., to achieve decoupling of application layer software and supplier hardware at the development level. The application layer software is encapsulated and handed over to the supplier for integration and configuration without the need to open it for application. layer, several hardware vendors can be specified. At the same time, we can cooperate with ecological service providers to embed third-party software into the application layer. After the application layer is independently controlled, it can be quickly transplanted, improve development efficiency, and provide a basis for continuous iteration of functions and frequent updates for users. OTA is the core channel, and the first phase of implementation is the first step towards software-defined cars.

The second stage: Gradually realize the integration of the application layer and the bottom layer by purchasing configuration tools. The hardware supplier provides a "white box" for integration and flashing at the OEM. Realize the true decoupling of software and hardware, expand the scope of hardware procurement, and reduce procurement costs. However, the underlying configuration functions require a large amount of investment from the OEM, and the OEM will consider whether to enter the game based on its own capabilities.

The third stage: Gradually enter the independent development of hardware and underlying layers. Reduce vehicle costs through hardware, independently select core chips, break the limitations of hardware platforms, and carry out software modular transplantation based on vehicle configuration and functional requirements based on cost and customer experience.

3) Construction of an open platform

Traditional automobile development relies entirely on the engineering philosophy of the car factory, which is an overriding A development model that puts customers first. Based on the new model of win-win, symbiosis and co-creation, the open platform can solve the relationship between suppliers, vehicles and users under the new situation.

The open platform can provide vehicle development engineers, third parties, and users with vehicle capabilities. These capabilities include some underlying hardware capabilities, software capabilities, data, and information. Based on these capabilities, Usage scenarios allow the development of diversified software to provide users with customized, personalized, and subscription-based services, thereby creating value for users and OEMs and also gaining their own benefits. Enable users to participate in the development of vehicle software and truly realize software-defined cars.

Through the open platform, hundreds of thousands of hardware modules in the car can be used, which can provide stronger perception capabilities than mobile phones, more application scenarios, greater coverage, and longer life cycle, so the automotive ecosystem is broader than the mobile phone ecosystem, more open than mobile phones, and closer to users.

5.3 Parts Supplier

For traditional parts suppliers, under the development trend of software-defined automobiles, OEMs have an increasing say in the development of system functions. With the help of software and hardware decoupling and the implementation of SOA architecture, the entire Car manufacturers will also gradually assume the development of application functions for some parts suppliers. Therefore, Tier 1, which is traditionally hardware-based, urgently needs to transform and find new solutions.

At present, the creation of full-stack capabilities of software and hardware is the key to seizing the next commanding heights of market share. Many Tier1s with very comprehensive capabilities are building "hardware underlying software middleware applications" The full-stack technical capabilities of "software algorithm system integration" can provide customers with both hardware and software, as well as integrated software and hardware solutions. However, such a layout requires Tier1 to invest a lot of manpower and capital, which not all Tier1s can afford.

In this regard, parts suppliers should further open hardware ports and abstract hardware capabilities. In order to reduce the cost of customization for different OEMs and improve delivery efficiency, it is necessary to The interface is opened according to unified standards, thereby reducing matching complexity, reducing software and hardware coupling, and enhancing flexibility and reuse. We also proactively work with OEMs, software suppliers and other parties to jointly build a parts ecosystem to attract and create more diverse and richer profit scenarios. Under the premise of standard interfaces, performance differences will bring competition to parts suppliers. At the same time, it will also promote parts suppliers to innovate and make progress. Parts suppliers should focus on internal core algorithms and achieve differentiation and continuous evolution of performance and experience through optimization and upgrade of internal algorithms and codes. And by cooperating with IT companies in the fields of automobile manufacturers, artificial intelligence, software and other fields, we can understand the latest needs and development directions, adjust our own R&D direction and capabilities, base ourselves on hardware, and use accumulated industry know-how advantages to build application function software capabilities. , which feeds back and drives differentiated hardware sales, is the choice of many parts suppliers.

5.4 Basic platform provider

Facing the era of software-defined cars, the goal of basic platform manufacturers is to use their own ICT Technology accumulation and advantages help OEMs create differentiated next-generation electronic and electrical architectures suitable for their own planning on the entire vehicle, reduce the complexity of smart car research and development, improve efficiency, and accelerate smart car development and implementation.

But the current supply chain model from OEMs to first-tier suppliers, second-tier suppliers and third-tier suppliers is becoming more and more blurred, and car companies are increasingly The hope of being able to dominate more content forces basic platform providers to break boundaries with a more open attitude, focus on their own advantageous products, provide open API interfaces for upper and lower hardware and application software, and provide a safe and trustworthy operating environment for functional software. and easy-to-use service development and verification toolchains.

It is recommended that basic platform providers provide OEMs with an architecture for the sustainable evolution of smart cars. The design concept should be people-oriented and continue to innovate around user experience and OEM commercial success. .

5.5 Software supplier/software developer

With the autonomy of OEMs and software self-research capabilities With the continuous strengthening of technology, vehicle manufacturers are beginning to seek direct cooperation with software suppliers. For example, vehicle manufacturers will first seek to take back the cockpit HMI interactive system functions, UI/UX design tools, speech recognition modules, sound effects modules, face recognition modules, etc. Application software purchases software licenses directly from software suppliers, thereby bypassing traditional Tier 1 and achieving independent development.

With the advancement of software-defined cars, automotive hardware systems are gradually becoming standardized, and software is the part of the car that iterates the fastest and is easiest to personalize and differentiate. Software will also drive hardware innovation, and the two will complement each other. For software suppliers, the more software IP product portfolios they can provide, the more likely they are to obtain higher vehicle value.

At the same time, software vendors are also seeking to enter the hardware design and manufacturing aspects controlled by traditional Tier1, such as domain controllers, T-BOX, etc., to provide diversified solutions. For smart car APP application development, developing application software based on the atomic service standard API will become very convenient and easy to use. For applications, there is no need to pay too much attention to the underlying implementation and reduce the dependencies of different levels and modules, similar to the Android-based development model. For different groups of people, different cars, and different life scenarios, different application developers will make applications with different functions, different graphics, and different experiences.

The threshold for application development has become lower, and more software suppliers/developers can participate in the development of automotive application APPs. As a result, the competition in software development has become greater. Software suppliers should analyze the preferences of different groups of people based on some survey data, and develop differentiated applications suitable for the public for different car models. Users can selectively install some functions and feature applications based on their actual conditions. Through different applications and services, they can define some characteristics of their own vehicles to achieve functional upgrades or personalized customization through software.

In the process of competition, not only will very popular application software appear, but it will also increase the initiative and accuracy of application software suppliers to improve services and improve their ability to innovate products, thus Prosper the smart car application ecosystem.

5.6 Industry Organization

The government should help the entire automotive industry establish a reasonable An efficient management system supervises the orderly and smooth operation of the entire industry, continues to grow bigger and stronger, and ensures fair competition in the entire industry.

Policies encourage enterprises to develop new technologies. For example, enterprises that have contributed to the automotive industry or have made breakthroughs in certain technologies can be rewarded to share and display innovative results and realize technological innovation. In-depth integration of policies and technological innovation, and continuous improvement of policies and feedback systems, giving full play to the driving force of policies on the development of new technologies, creating a good automotive software ecosystem, and driving the construction of smart transportation and smart cities with intelligent connected cars develop.

Establish common interfaces and other specifications to solve common problems based on standards, realize the interconnection and interoperability of automotive software and hardware products, avoid each enterprise fighting independently at the level of universal standardized interfaces, and advocate all enterprises in Under the unified interface, we should do a good job in innovation and research and development of our own products, avoid duplication and fragmented investment, improve research and development efficiency, and promote the development of intelligent connected vehicles in our country.

The above is the detailed content of An article discussing the five key elements for the implementation of software-defined cars. For more information, please follow other related articles on the PHP Chinese website!