What does a fully SOA-based electronic and electrical architecture look like?

In the process of the automotive industry's transformation towards intelligence, the development model of automobiles, consumers' perception of automobiles, and the business model of automobile sales are all undergoing disruptive changes. Traditional electronic and electrical architectures are increasingly unable to adapt to today's consumer requirements for automobile intelligence.

When engineers develop new functions on traditional electronic and electrical architectures, it takes a long time and iteration is difficult. In addition, engineers need to consider various constraints during development and customize development for different models.

△Pain points of traditional electronic and electrical architecture

To avoid the above problems, more and more car companies tend to choose the SOA architecture of regional access + central computing. The iDVP intelligent digital base released by Huawei on the eve of the Shanghai Auto Show is such an SOA architecture that meets the regional access + central computing standards.

1. Structure and expected functions of Huawei iDVP intelligent vehicle digital base

In addition to mechanical hardware such as the chassis, Huawei divides the entire vehicle into several levels, from bottom to top: hardware platform, software platform, application ecosystem, and car cloud.

iDVP consists of two parts: hardware platform and software platform. The hardware platform refers to the basic hardware platform of computing and communication architecture, and the software platform is divided into operating system, basic management framework and SOA software framework. To facilitate users to develop software on iDVP, Huawei has also developed a supporting tool chain, as shown in the following figure:

△iDVP structure diagram

1.1 Computing and Communication Architecture Hardware Platform

The computing and communication architecture platform is responsible for designing the computing and communication methods of the vehicle, which currently mainly includes star networking and Ethernet ring networking, as shown in the following figure:

△ Schematic diagram of communication architecture

VDC stands for Intelligent Vehicle Control Domain Controller, MDC stands for Intelligent Driving Domain Controller, and CDC stands for Intelligent Cockpit Domain Controller. The domain controller can be connected to sensors and actuators through VIU.

In a star network, the VDC is connected to the VIU distributed on the vehicle body through Ethernet to control the sensors and actuators on the vehicle body. The MDC and CDC control the sensors and actuators by connecting to the VDC.

In an Ethernet ring network, each domain controller and VIU are directly connected via Ethernet, and VIU can form a ring network. When a certain section of the network is disconnected, there is a backup route, and the reliability and security of communication can be better guaranteed.

1.2 Operating System

The operating systems include VOS and AOS.

VOS: Intelligent vehicle control operating system, which can support the smooth migration of existing applications from CP to AP, and can ensure that applications are unaware of multi-core while deploying multiple cores. It also supports digital twins and whole-vehicle OTA.

AOS: An intelligent driving operating system that supports automotive-grade safety and has a rich AI native development library to improve the efficiency of model-based simulation, verification, and intelligent driving development.

1.3 SOA Software Framework

The SOA software framework includes the device abstraction layer and the atomic service layer, which makes it easier for users to develop software on iDVP.

According to the information released at Huawei's intelligent automotive solution conference on April 16, Huawei's SOA architecture covers the body domain, power domain, chassis domain, intelligent driving domain, and thermal management domain, and related applications can be implemented under the SOA architecture.

1.3.1 Device Abstraction Layer

According to Huawei's design concept, the device abstraction layer abstracts hardware resources such as sensors, actuators, and legacy ECUs, provides device access interfaces to services through APIs, shields differences in device function implementation (hardware differences & manufacturer differences), and reduces customization and duplication of work. When developing related functions, engineers do not need to consider the differences in electrical parameters of hardware devices, and can directly call the corresponding interfaces.

For example, when an engineer needs to call a motor, he only needs to enter the parameters of "rotation direction" and "speed", and then call the motor interface to control the motor without having to understand and consider the differences in the motor's control electrical signals.

According to the information released at Huawei's smart car solution conference on April 16, Huawei has developed more than 300 device abstraction APIs that meet the China Automobile Association SDV standard. Device abstraction services cover the body domain, thermal management domain, power domain, chassis domain, etc., and the devices that can provide abstract services include various actuators and sensors such as motors, pushbutton switches, relays, lights, and temperature sensors.

△SDV device abstraction API

1.3.2 Atomic Service

Atomic services encapsulate the basic actions of hardware devices into APIs, thus providing the most basic operation units for upper-layer applications. In this way, hardware devices and software ports can be decoupled. For example, adjusting the window opening, opening the window, closing the window, stopping opening or closing the window, etc. are all encapsulated into interfaces according to basic operations in atomic services.

According to the information released at Huawei's intelligent vehicle solution conference on April 16, Huawei has currently developed more than 400 atomic service APIs that meet the China Association of Automobile Manufacturers' SDV standards. The services cover various aspects such as body control, interactive domain, motion control, energy management, and intelligent driving domain. They include door services, fog light services, ventilation services, cabin temperature control, and other services, which are convenient for engineers to call when developing software.

△SDV Atomic Service

1.4 Basic Management Framework

The basic management framework is mainly responsible for basic functions such as distributed communication, vehicle OTA, functional safety, and diagnosis.

1.5 Toolchain

The tool chain can provide tools in the vehicle software development process to match the software development workflow.

According to the workflow, tool chain products can be divided into: vehicle-level architecture design tools - including iDVP API service definition library, iDVP SWC engineering library, iDVP network topology library, etc., which are mainly used for vehicle-level service-oriented design; then model-based development tools - including iDVP bottom soft configuration toolkit, iDVP behavior model library, etc., which are mainly used for model-based development and configuration; finally, digital base simulators - including timing analysis tools, etc., which are mainly used for vehicle-level service-oriented verification.

△iDVP tool chain

2. Advantages of iDVP

At the Huawei Intelligent Vehicle Solution Conference on April 16, iDVP was called the "black soil" of software-defined cars. In the era of software-defined cars, iDVP can greatly improve the efficiency of software development and balance the basic consistency and personalization of user experience. So, what are the advantages of iDVP?

2.1 Regional access + central control architecture to improve architecture flexibility

iDVP adopts the architecture of regional access + central control. Under this architecture, the number of ECUs in the whole vehicle can be reduced by 20 to 30, saving about 50w of power consumption.

△iDVP typical architecture

As shown in the figure above, VIU is generally deployed on vehicles, and the sensors and actuators on the vehicle are connected to the VIU. Then the domain controller can uniformly control the sensors and actuators through the VIU.

Under the regional access + central control architecture, OTA is relatively simple. Compared with the decentralized ECU architecture, the iDVP architecture can save about 50% of the time for vehicle OTA.

Moreover, after the central control, the air quality, temperature and other information in the car can be transmitted to the body domain controller through sensors, and then centrally controlled. The advantage of centralized control is that cross-domain applications will become very easy. If an application includes both the thermal management system and the body domain, we will not be troubled by cross-domain calls.

In addition, iDVP adopts the method of local access and secondary intelligent power distribution for actuators and sensors, which can save 20-30% of wiring harnesses and help reduce the weight of the vehicle body.

At the same time, iDVP introduces a high-speed Ethernet ring network, which can upgrade the 100M network to the 1G network and improve data transmission efficiency.

In addition, with a reasonable layering method and SOA service-oriented standard interface, the complexity of the vehicle software is greatly reduced, the development module units of each software can divide the work and collaborate, the software iteration speed is fast, and the quality is easier to ensure.

2.2 Decoupling of software and hardware, convenient expansion and improved development efficiency

iDVP classifies the electronic and electrical architecture of the car into layers, decoupling software and hardware and improving development efficiency.