Talk about the trends and changes in automotive electronics

This article discusses possible changes from the aspects of E/E architecture, communication methods, software cooperation models, automotive buses, software architecture and process standards. The understanding is relatively shallow and the content will be very long. Comments are welcome.

1. Automotive E/E architecture: distributed -> domain centralized -> central computer

Current cars have dozens or even hundreds of electronic control units connected to a variety of buses. On average, current cars use about 25 ECUs, but some high-end models have more than 100 ECUs. In the past, automotive electronic and electrical architecture has always followed the distributed architecture model of "one function, one box". For example, the transmission control is handled by the TCU, and the engine control is handled by the EMS. Although these two are also in the power domain, suppliers provide their own hardware and software. In such an automotive electronics and electrical architecture, each additional function requires a corresponding controller, which involves communication and maintenance costs for multiple parties, further increasing the complexity and cost of the system. It will eventually lead to a larger and more complex vehicle network and wiring, which will also affect the lightweight of the entire vehicle.

Facing the increase in automotive functions and software complexity, it is necessary to reconstruct the automotive E/E architecture and establish a more flexible system architecture. Domain controllers have only become popular in recent years. The so-called domain is to divide the entire vehicle into different areas, such as power domain, body domain, chassis domain, entertainment domain, etc. Each domain only mounts a single controller. Responsible for the functions of the domain, reducing the complex wiring and integration of the previous distributed E/E architecture of one function and one "box": In fact, it is to combine the software of multiple controllers into one controller, such as for pure electric vehicles, power domain There are BMS, MCU, VCU, DCDC and other controllers. Putting all the functions of these controllers in one controller and handing it over to one party not only saves money on the hardware cost of other controllers, but also switches from connecting multiple parties to It's nice to think about connecting with one party.

Domain controllers can greatly reduce the number of controllers and vehicle wiring, and technologies such as multi-core heterogeneous chips and hypervisors provide support for the development and application of domain control in terms of software and hardware. At present, suppliers such as BOSCH have corresponding domain controller products, but it still takes a long time to realize a truly domain-centralized E/E architecture. After all, this cannot be achieved by oneself and requires vigorous cooperation from OEMs, suppliers, etc. and advancement can be achieved. For example, the software in the same domain controller may be provided by multiple suppliers. In addition to being responsible for the upgrade of their own software, each supplier is also involved in the integration and testing of complex and different types of software. This makes the integration and upgrade work relatively easy. It's just a question. Another example is that domain controllers in different domains are developed by different suppliers in cooperation with OEMs, which will bring many new problems.

The ultimate goal of the domain controller is the central computer architecture. The central computer is composed of heterogeneous multi-core processors and integrates the functions of the entire vehicle.

2. Introduce service-oriented (SOA) communication based on signal communication and integrate the advantages of both

A communication method based on signals, that is, the sender of information does not care who receives it but is only responsible for sending the signal, and the receiver does not care who sent it but is only responsible for receiving what he wants. Signal-based communication can transmit certain information from a node to other nodes that need the information through the bus. The information is mainly some physical state values ​​and some control values, such as transmitter speed, vehicle speed, etc. The signals have periodic, event or mixed triggers Way.

Signal-based communication is currently commonly used in vehicle buses, such as information transmission between controllers through the CAN bus. We focus on the frames on the communication matrix, the signals, cycles and interactive nodes contained in the frames and other information.

SOA is a software architecture, as well as a software design method and concept, with decades of application experience in the IT field. SOA has the characteristics of "loose coupling", "accessible interface standards" and "easy to expand", allowing developers to respond to iterative and changing customer needs with minimal software changes. So far, there is no generally accepted definition of Service-Oriented Architecture (SOA). Many organizations have described SOA from different perspectives. The following three are typical:

(1) W3C definition: SOA is an application architecture in which all functions are defined as independent services with well-defined callable interfaces that can be called in a defined order. to form business processes.

(2) Definition of Service-architecture.com: A service is a function that is precisely defined, well-encapsulated, and independent of the environment and status of other services. SOA is essentially a collection of services that communicate with each other. This communication may be simple data transfer, or it may be two or more services coordinating certain activities. Services need some way to connect between them.

(3) Gartner’s definition: SOA is a C/S architecture software design method. Applications are composed of services and service users. SOA is different from most common C/S architecture models in that it emphasizes the components Loosely coupled and using independent standard interfaces.

So how to understand SOA? To understand SOA, you must first understand the three concepts of service, service interface and service-related roles using the following example:

Service refers to a function or method of a certain function. For example, the above Weather Service and Map Service can provide weather and map information respectively, which is a kind of service. The service interface is the window through which the service communicates with the outside world, and the API that serves as a service module to interact with the outside world.

Commonly used service interfaces include method Method, event Event and field Feild (please refer to the two articles on vehicle Ethernet in this official account), as follows:

The service-related roles we often come into contact with include server-side Server, client-side Client, service registration and agency. First, service registration and agency implement service registration/subscription/publishing, etc.; the client is used to use the service interface to call and use services, while the server The end is used to implement services.

Why should cars introduce SOA? First of all, the communication method based on SOA has the following advantages:

1. The service is highly cohesive and the software is easy to reuse: A service often only focuses on one thing and does it well. The content (function) of this thing needs to be sorted out from a business perspective.

2. Flexible deployment of services: Through the service discovery mechanism, the location and provider of the service can be obtained when the controller is running, and the deployment location of the service role can be adjusted during the vehicle life cycle to make function allocation more flexible.

3. Software updates and upgrades are faster: A function change may only require upgrading and updating a service, and the service is an independent executable unit that can be installed and upgraded separately, so software maintenance and expansion are easier.

Therefore, based on the above advantages, with the trend of intelligent, networked and shared cars, end-user expectations for vehicle functions are also quietly changing. While cars are realizing high-level autonomous driving/assisted driving functions, they are also more It tends to improve user experience, such as meeting rapid function updates and upgrades, and providing personalized, humanized, and differentiated functions and services. Service-Oriented Architecture is providing good solutions for future vehicle software services. Different from the signal-oriented architecture in traditional automotive electronic and electrical architecture, service-oriented software architecture (SOA) adopts standardized service interfaces, loosely coupled service mechanisms and composable and scalable service features.

Based on the above introduction, signal-based communication only supports sending and receiving modes. The supported data types are simple and have poor scalability, and are suitable for application scenarios of limited-size data interaction. After advanced application scenarios such as autonomous driving are added, the dynamic interaction of large amounts of data must adopt a service-oriented communication method to improve communication efficiency and reduce load. In this method, the receiver, as a client, only needs to find and subscribe to services and wait to receive them. Information is enough, and the sender, as a service provider, only needs to provide services and information to subscribers. Because SOA-based communication supports the request/response model, is highly scalable and supports the transmission of complex data, they should give full play to their respective advantages. .

3. Software cooperation model: flexible and rich cooperative development model

Following the rise of Tesla, which pioneered "software-defined cars", "software-defined cars" became a trend. After Volkswagen established an independent software development department, Toyota also officially established a software subsidiary - Woven Planet Holdings, focusing on Develop software businesses such as autonomous driving, new automotive operating systems, and high-definition maps. Domestic OEMs such as SAIC have also set up their own software centers, such as SAIC's Zero-Shu, all wanting to take the initiative in software development during this change.

The traditional development model is that the OEM provides the demand, and the supplier is responsible for realizing the software and hardware. Multinational Fortune 500 companies such as BOSCH and Continental have rich experience in the development of software and hardware for these parts. The products have been iterated for dozens of generations, regardless of cost. Or stability. Compared with the software developed by the OEM itself, it can be said to be overwhelming. Moreover, it is backed by patents. It can be said that the transformation of the OEM software is difficult. Take the ESP body stability system as an example. It was developed by a Japanese manufacturer. It has the same function, but due to patent restrictions, it can't even be called ESP. It was renamed VSC. You can imagine how many detours it took in the development stage to avoid patent risks. These are the same for OEMs that want to transform into software development. Industry barriers are not so easy to break. Then there is the real ability to attract high-end software talents. Cars are a typical heavy-asset industry. To build a car, you need to buy land, build a factory, buy equipment and build a production line. In the current hot software development IT industry, people’s wages are the highest. To put it bluntly, companies with software practitioners in the automotive industry cannot compare with the Internet on the same competitive stage. Therefore, there is an overall lack of high-end software talents. This has caused the current transformation dilemma of software development for OEMs. .

Based on the above points, OEMs have discovered that software development is no longer just a traditional single factory material, but will soon become the core competitiveness of their own companies, so they have begun to make great efforts to establish software R&D teams to develop core software. Especially under the current trend of intelligence, networking and electrification, everyone is on the same starting line to the greatest extent. Therefore, OEMs want to start developing and producing their own software and hardware from the previous "assembly factory" model, and Carry out product improvement and value creation yourself. Therefore, under this trend, the previous all-inclusive supplier model will gradually weaken, and will instead be developed in cooperation with OEMs. For example, the supplier only provides hardware and the OEM develops the software.

First of all, we need to admit that it is right for OEMs to seize the initiative and improve their own software and hardware capabilities, and the software cooperative development model will become a mainstream in the future, but there is still a long way to go to really do it well. Why?

The first priority for software running on cars is to be stable and reliable, and under the conditions of high vibration, complex electromagnetic environment, and large temperature differences, it can ensure that serious software bugs do not occur in millions of mass-produced cars. Each car has dozens of software bugs. Even with hundreds of controllers, to ensure the stability of hundreds of millions of products, this is still the basics. You can look at the famous historical events caused by software bugs. Toyota's brake door, mobile phones and computers can crash. Let alone a car crash, even a small bit inversion may cause loss of life. Automotive electronic software engineering itself is complex and complex. A collection of high reliability requirements.

With the development of automotive electronics software today, a complete industry standard process and functional safety level verification have been formed, which can be implemented with reference to some laws. It not only requires correct results, but also requires procedural justice. In this industry, it can be said that it is not only required that the developed software meet the required functions and requirements, as well as functional safety and network security requirements, but also that the development process must comply with ASPICE, have complete process documentation and traceability, and even be as detailed as meeting reviews. If there is any confusion in the record document, it means that our software is very good. Regardless of your process or requirements, just put it on the car and run it. For this kind of thing, there is no qualification to be used, let alone used in mass-produced cars. Therefore, the software running on cars at this stage is not developed by individual small workshops from the source. It can only be completed by the company's regular team after a long time.

4. The demand for automotive buses based on SOA will gradually adopt Ethernet as the backbone network, and multiple buses will coexist.

Bus technologies in automobiles include: LIN, CAN, CAN FD, FlexRay, MOST and Ethernet. As far as the current application situation in automobiles is concerned, Lin and CAN communications are low-cost, high-reliability and widely used. CAN FD has only been gradually applied in recent years. CAN FD is an expansion and transition of the traditional CAN bus. The purpose is to make CAN Fast. First of all, it will not bring major changes to the original vehicle network, has good compatibility and has a considerable transmission rate. Considering the amount of development migration, time cost, hardware cost, etc., CAN FD is a good transition solution at the current stage.

However, with the increasing complexity of automotive electronic and electrical architectures, especially the rapid development of current assisted driving systems and driverless technologies, traditional LIN and CAN buses have been overwhelmed and cannot meet future high-bandwidth requirements. For example, driverless technology involves cameras. , LiDAR and other sensors and the collection, transmission and processing of large amounts of data between different controllers. When considering X-By-Wire application scenarios and higher bandwidth requirements at the same time, CAN FD may not be able to meet the requirements. Therefore, for wire control application scenarios, FlexRay is a good solution because FlexRay is specially designed for in-vehicle LANs. A high-speed deterministic vehicle bus system with fault tolerance, which adopts a time-triggered mechanism and has the characteristics of high bandwidth and good fault tolerance. It has great advantages in real-time, reliability and flexibility. It is very It is suitable for wire control situations with high safety requirements and situations with high bandwidth requirements. However, FlexRay applications have much higher requirements for OEM capabilities than CAN. At the same time, all upgrades to FlexRay will bring about simultaneous increases in development migration volume, time costs, hardware costs, etc. (all nodes must be upgraded to FlexRay nodes). In addition, from my personal point of view, the possibility of FlexRay being widely used in the future is not very high. First of all, the cost is similar to that of automotive Ethernet and the communication speed is much lower than it. However, the possibility of automotive Ethernet being promoted in the future is much higher than that of automotive Ethernet. FlexRay is much higher. It should be noted that CAN FD has not been promoted and implemented in the market for a few years. The third generation CAN bus - CAN XL is about to debut. The CAN T1), from this point we can also see the rapid development of in-vehicle communications and the increasingly higher requirements for communication bandwidth.

Of course, all bus applications are divided into different domains and scenarios. For example, for occasions with high security requirements, FlexRay based on the time trigger mechanism may be more suitable because of its higher real-time and deterministic properties. For example, in the subsequent SOA-based For high-bandwidth data transmission application scenarios, automotive Ethernet is more suitable. For some power domain controllers that can already meet the needs through CAN, why bother to spend energy and extra costs to replace them with other bus technologies. Therefore, rather than replacing, I think it should coexist. Each bus technology has its own value. Under the premise of meeting the requirements, the use of low-cost, mature bus technology is definitely the first choice.

5. Multi-core heterogeneous processor applications will become mainstream

Why multi-core processors are needed? I will explain the reasons mainly based on four points:

1. The automotive electronics and electrical architecture and vehicle functions are becoming more and more complex, requiring hardware with more powerful computing capabilities to support increasingly complex software functions. With the addition of application scenarios such as ADAS and autonomous driving, and future domain centralization and even central computers, With the changes in E/E architecture, the demand for multi-core systems will become more obvious.

2. Parallel computing requirements: For example, the output calculation of some functions requires multiple input elements to be executed in the same time slice and input to the functional module at the same time.

3. Serial computing requirements for multiple tasks within the same time slice: For example, multiple functions need to be executed serially at the same time.

4. System responsiveness requirements: For example, interrupt processing that has particularly high time requirements needs to be run on a separate core, while periodic tasks are run on another core, thereby improving the responsiveness of the entire system.

Of course, compared with single-core software development and integration for multi-core systems, the project time, complexity, cost, and additional workload brought to Siege Lion are doubled. The application of multi-core processors will also bring many challenges, such as the challenge of meeting ISO26262 functional safety, reasonable distribution of computing load on each core, multi-core system data consistency challenges, etc.

6. Pay more attention to the design of software architecture

In the software architecture part, we put aside some closed source software such as Tesla's and talk about Classic Autosar and Adaptive Autosar that everyone is commonly exposed to. The controllers on our entire vehicle include controllers in the power domain, such as engine control EMS, TCU, etc., as well as controllers in the infotainment domain, such as vehicle display lights. The real-time requirements of different controllers are different. . For example, the engine controller ECU or the vehicle controller VCU has higher real-time and functional safety requirements than other functional or infotainment controllers. The power domain is basically developed based on the Autosar classic platform because it has the following characteristics:

1. Hard real-time, real-time processing of events can be completed within us time. Hard real-time tasks must meet deadline constraints to ensure reliable operation of the system.
2. High functional safety level, which can reach ASIL-D safety level.
3. It has a low utilization rate of resources such as CPU, RAM or Flash.
4. Software functions are usually fixed and cannot be dynamically changed.
The infotainment controller is just the opposite. It generally takes up a large amount of hardware resources and generally has relatively low real-time requirements because it generally runs on an embedded PC, such as LINUX, rather than an automotive-grade operating system. Therefore, even if it fails, it will not cause serious safety accidents. ApdativeAutosar is the bridge connecting the two. It has the following characteristics:
1. Soft real-time, with deadlines within milliseconds, and occasional missed deadlines will not cause catastrophic consequences.
2. It has certain functional safety requirements and can reach ASIL-B or higher.
3. Different from the classic platform, it is more suitable for high-resource environments of multi-core dynamic operating systems, such as QNX.

Compared with Classic Autosar, Adaptive Autosar has lower real-time requirements, but on the basis of ensuring a certain functional safety level, it greatly improves its support for high-performance processing capabilities to support the development of intelligent interconnected application functions. Therefore, C++ will Becomes the main development language of the AdaptiveAutosar platform.

The emergence of Adaptive Autosar is not to replace the ClassicAutosar platform, but to achieve coexistence and collaboration between the two for different application scenarios. The Classic Autosar platform supports high security and high real-time application scenarios, so deeply embedded software functions require The deployment runs on the classic platform, while Adaptive Autosar supports parallel processing and requires high-performance computing functions to run on the Adaptive platform.

Of course, there are various software architectures. Which one to adopt depends on the OEM’s considerations and capabilities. Multiple software architectures, such as Autosar, Adaptive Autosar, ROS, etc., will be coupled and integrated.

7. Standards and procedures

In order to meet the high quality standards of automotive software development, the ASPICE process model was established. ASPICE is the basis for safety and security. The author believes that this is an important aspect to ensure the quality of software development in the future. Both suppliers and major OEMs should gradually apply it. stand up.

The ISO26262 standard defines the impact of functional safety in system development in terms of process and methodology. For software architecture, functional safety is a very critical factor. How to design in-vehicle systems so that they can meet the requirements of functional safety standards is a huge challenge, especially This is under the dual pressure of increasing application complexity and the urgency of product time-to-market. The challenge with electronic systems is to build systems that can prevent dangerous failures from occurring or at least provide effective control when a failure occurs. Functional safety standards have been applied to vehicle safety systems such as airbags or ADAS. ISO26262 is derived from the IEC61508 standard and targets electrical/electronic systems within road passenger cars. The standard addresses architectural, functional and procedural aspects, including the automotive safety lifecycle, to avoid and control system errors and random hardware failures. ISO 26262 specifies four ASIL levels (A to D) to determine the necessary requirements of the standard and the safety measures used to avoid unreasonable residual risks, where D represents the most stringent safety level and A represents the most relaxed safety level. By considering the part of the mission data that system failure may cause injury (i.e., probability of occurrence); the driver's ability to cope with system failure and avoid injury (i.e., controllability); and the personal consequences of controllable operation failure (i.e., serious Degree) These three points, carry out hazard analysis and risk assessment at the vehicle level to determine the appropriate ASIL level.

— END —

Video recommendation: How to improve R&D efficiency in the era of smart cars