Body controller design based on SOA

[Abstract] As vehicle functions gradually increase and user needs are constantly updated, vehicle software needs rapid iteration to give users a better service experience and faster functional experience to truly meet the needs of thousands of people. From the perspective of distributed EE architecture Transform into the current architecture of central computing plus regional control, realize software and hardware decoupling in the form of SOA, concentrate more functions into the body controller (BCM) in the form of atomic service packages, and call different services based on dynamic configuration. This article describes the atomic service design of BCM from the perspective of vehicle architecture, BCM function definition, and atomic service division.

The automotive industry is currently facing a transformation revolution. With the introduction of the new four modernizations, software-defined cars have become an inevitable trend. The degree of decoupling of software and hardware determines the differentiation of enterprise products. For hardware, it needs to be compatible and scalable. For software, it needs to be upgraded quickly and have good portability. Therefore, from the architectural level, it needs to be developed based on SOA, and the traditional distributed architecture is transformed into a centralized architecture, which is composed of a central computing unit and regional control. Encapsulate different atomic services according to granularity and call them with standard service interfaces. During the functional interaction process, the interacting parties do not need to consider each other's protocols. Atomic service design is an important factor in determining the depth of coupling between software and hardware. A good atomic service The design can reduce the cost of the entire vehicle, shield heterogeneity, and service combinations can implement different functions to dynamically configure vehicle functions.

1 Design differences in automotive architecture

1.1 Traditional EE architecture development

The development process of the traditional EE architecture is shown in Figure 1. The market first positions the model, and searches for corresponding or higher-configured mainstream models for benchmarking, mainly benchmarking its appearance, interior, static functions and dynamic functions. Lead all employees to fill in the competitive product analysis table, integrate the analysis results and investigate user needs, sort out the output configuration table, and technically sort out the configuration table, find relevant items, convert them into technical solutions, decompose the configuration table into multiple functional logics, and then Allocate functional logic to multiple systems, output a network communication demand table, and output subsystem demand documents according to the demand table. The document states I/O, human-computer interaction interface, performance requirements, application scenarios, etc., and subsystems are allocated according to functions. own network interface and hardware interface, and finally complete the schematic diagram and network development of the system.

Figure 1 Development process of traditional EE architecture

1.2 EE architecture development under SOA

The EE architecture development process based on SOA is shown in Figure 2. Compared with the traditional one, the output configuration table and conversion function logic are consistent. The difference is that after the function logic conversion, the system is not directly allocated but the function logic is converted into atoms. Services, according to the granularity, define hardware abstract services and define the interfaces of atomic services. According to the architecture, the service interfaces are deployed in different modules. As the autonomous driving level of modern cars is getting higher and higher, the functional safety level has been increased accordingly. , so the functional safety levels required for different functions are inconsistent, and security engineers need to sort them out, and then design the software architecture and hardware architecture based on the assigned functional safety levels, atomic service design, and software modules.

Figure 2 EE architecture development process based on SOA

2 Function definition

In the form of a central computing unit plus regional control, the BCM integrates body functions, air conditioning functions, routing and other functions. It also has network management, signal detection and other functions. The body functions include rear defrost, exterior lighting, interior lighting, and headlight adjustment functions. , anti-theft, back door control, central control function, wiper washing, rearview mirror function, horn, sunroof function, RKE, PKE, glass lifting, seat adjustment, etc.; the air conditioning function is mainly for pumps, air conditioning boxes and other motors or electromagnetic Valve drive, including air conditioning water pump drive, motor water pump drive, condenser fan drive, air conditioning board drive, cooling pump drive, refrigerator function, air conditioning box function, blower drive, etc.; routing function is divided into signal routing and wire harness routing. Signal routing This is because the BCM also plays the role of a gateway. The BCM is connected to the central computing unit using 100 Mbit or Gigabit Ethernet, and is connected to other ECUs using CAN or 10 Mbit Ethernet. It needs to forward signals from other ECUs to the central computing unit to realize the signal. Routing, and wiring harness routing is to transfer the hard wire signals that need to be transferred through the BCM controller; because after the vehicle is powered off, it is necessary to ensure that the vehicle battery does not lose power within a certain period of time and to ensure that the vehicle functions can be awakened. Therefore, network management is particularly important. Network management includes defining wake-up mode and sleep mode, and sleep management needs to be carried out according to different communication methods; signal detection includes collision signal, door switch detection, door status detection, temperature detection, sunlight detection, and gear switch detection. , light switch detection, etc.

3 System block diagram

According to the architecture and function definition, the system block diagram of BCM is obtained (Figure 3). The power management module converts the external KL30 normal power into the system voltage required by the system chip and maintains stability. The MCU chip supports the input of digital signals and analog signals. Generally, switch signals are digital signals, such as door switches; sensors are generally analog signals, such as temperature sensors, position sensors, etc., or some switches are in PWM form and are also analog signals, such as light brightness adjustment, collision signals, etc. There is a CAN transceiver inside the BCM, which supports CAN or CANFD signals. The LIN signal is reserved as hardware. Products with low real-time requirements and non-safety products can use LIN communication. The MCU has a main MCU and an auxiliary MCU. The auxiliary MCU is mainly It is a redundant backup of functions. There are two forms of external lighting drivers, namely high-side driver HSD and low-side driver LSD. In most scenarios, HSD is used more and LSD is reserved as hardware, but HSD The driving current is generally less than 15A. For example, washing pumps and motor water pumps are often driven by half-bridge chips and MOS tubes. Different MOS tubes have different driving currents and can support current driving of nearly 400A. The BCM has a built-in Ethernet switch and PHY chip, supporting ten ECU communication via MB/100/Gigabit Ethernet.

Figure 3 System block diagram of BCM

4 Service API design

The software architecture of the service is shown in Figure 4, which is divided into hardware layer, basic software layer, functional software, hardware/device abstraction layer, atomic service layer, RTE operating environment and application layer. Because BCM does not have audio and video reception and picture reception, Therefore, there are no heterogeneous chips such as SOC, GPU or DSP. At the software layer, for hard real-time signals, classic autosar is used, and for soft real-time, adaptive autosar is used. Adaptive autosar is also the key to realizing atomic services. The hardware/device abstraction layer abstracts input interfaces, sensors/actuators and other hardware. The purpose It shields the impact of hardware differences on software. Atomic services provide a unified interface for the application layer through permutation and combination to improve development efficiency. RTE provides a running environment for APPs in the application layer. The application layer directly faces users with functional experience, forming product competition. force.

Figure 4 Software architecture of service

Atomic service design first lists all functions of BCM according to the function list, and then converts the functions into appropriate API descriptions according to the granularity. The service type is defined in the service API description, which can be a minimum service API or a combination. The latter API, the minimum service API is such as the left front door switch service, and the combined API can be the left front door service. This service includes door lock status, car handle status, car door status, door opening, child lock status, etc. Generally, the atomic services of BCM are defined as follows: door service, tailgate service, window service, sunroof service, sunshade service, car key service, exterior whistle service, low-speed alarm service, exterior rearview mirror service, seat service, Seat ventilation and heating service, steering wheel adjustment service, welcome service, wiper washing service, brake light service, turn signal service, warning light service, daytime running light service, fog light service, low beam service, high beam service, Position light service, reversing light service, laser light service, rear license plate light service, logo light service, headlight adjustment service, air purification service, dome light service, glove box service, defrosting and defogging service, etc. For equipment services, the definitions are as follows: door switches, door locks, tailgate switches, tailgate locks, tailgate motors, window switches, window motors, etc. The corresponding equipment is isolated based on input conditions and output control.

Taking the temperature detection service as an example, according to the message format of SOME/IP, it is necessary to define service ID/method ID, client ID, session ID, RPC type, return value, message cycle, call description, etc. The calling method of the service is method. , filed, fire and forget, event, where method is divided into RR and FF types, and filed is divided into setter/getter and notifier, then the provider in the service is BCM, and the consumer is the central computing unit. The service interface can be defined in several forms. When using RR-method, it detects the temperature sensor status. When using FF-method, it notifies the central computing unit that the temperature is too high. When using field, it detects the temperature value. When using event, it detects It will be reported after exceeding a certain threshold. Taking the field temperature value call as an example, the service server is BCM, the service client is the central computing unit, the service ID is 0x4003, the Instance ID is 0x0001, the server port is 30500, the client ID is 0X0003, the client port is 30500, and the service description is : This service mainly identifies the outdoor temperature value. The RPC type is field, the field attribute field is named Snsr_TemperOut, the field field data type is float ntfT (), the RPC Specific Type is getter, and the Method Name is OutSIdeTemp. The above ID and port are only examples. The details will be confirmed by the car company based on the actual situation.

5 Test setup

Traditional testing, whether it is software testing, hardware testing, or integration testing, cannot meet the current SOA-based controller design. Traditional software does not deeply use the AUTOSAR architecture and introduce functional safety concepts. Instead, it uses the supplier's own software architecture platform. , resulting in testing that cannot be unified and cannot meet the current design. Functional integration testing is more focused on the sending and receiving of signal related parties, verifying the correctness of the sending time, the correctness of the receiver's reception, and the sending interval, etc., but under the new architecture Functional integration testing needs to be re-established. In software testing, a new testing platform needs to be built. For example, in software unit testing, service interface testing, service scheduling testing, etc. need to be added. In software integration testing, after each component is spliced, the PCBA CPU resource testing, memory isolation testing, etc. need to be scheduled. Since the body controller is related to the vehicle digital key, a security chip needs to be added to the hardware to monitor the system internally with HSM and monitor external communications with SE. Therefore, during software security testing, It is necessary to add active and passive attack tests, chip timing, key security tests and digital key certificate tests, which are required to meet the national secret level.

6 Thoughts on Atomic Service Technology

The implementation of SOA is not only an independent event, but also involves the construction of EE architecture and the entire ecosystem. The existing software platform is mature and reliable. New software investment has brought significant increases in costs to both car companies and suppliers, and has required more skills for engineers. It is strict and requires mastering a complex knowledge system. SOA is implemented based on SOME/IP. SOME/IP has delays in data transmission and is soft real-time.

Each software layer and communication layer need to be coordinated and scheduled. The consistency of multiple layers will affect the real-time nature of the service response. Long scheduling time will lead to a poor experience. Different vehicle needs of users require higher deployment flexibility of the service, and then How to deploy a system that is both compatible with customization and flexible in configuration; traditional network testing is basically based on CAN or LIN. After the SOA concept is introduced, a new test platform for Ethernet needs to be built; atomic service design has evaluation indicators, good Evaluation indicators will guide the feasibility of subsequent designs, unify design concepts, and reduce differentiation; a traditional function will be split into multiple services, and the services may exist in different ECUs, increasing the complexity of the software and affecting performance; each Each service requires independent configuration, deployment, monitoring and collection, which increases costs; hardware redundancy and the use of functional safety ASIL certification and AUTOSAR also increase costs.

7 Conclusion

In view of the above overview, service prototypes with appropriate granularity can not only reduce costs and achieve product differentiation from the organizational level, architecture level, operation and maintenance level, design level, etc., truly meet the needs of thousands of users and adapt to the current situation. In the development of electronic and electrical architecture, there is no heterogeneous chip design and multi-operating system coexistence on the body controller. However, the smart cockpit or autonomous driving module will face greater challenges than the body controller, but the body controller also needs Think ahead. As architecture and development capabilities improve, it will gradually become possible to integrate body controllers with autonomous driving or smart cockpits in the future.

references

[1]China Association of Automobile Manufacturers Software Defined Automobile Working Group. Software Defined Automobile Service API API Version 2

[5] China Automotive Basic Software Ecology Committee (AUTOSEMO). Vehicle SOA Software Architecture Technical Specification 1.0[S].

[6] Ma Jianhui, Wang Zhixue, Hou Dongdong, et al. Design and implementation of an integrated automotive BCM [J]. Automotive Electrical Appliances, 2019 (2): 25-27.

[7] Tang Zining, Wu Jin, Wang Guanda, et al. Hardware design of tire pressure receiving module integrated in body controller [J]. Automotive Electrical Appliances, 2019 (6): 37-3

[8] Zhang Wenjie, Hong Yu, Sun Zongyao, et al. Application of automotive remote diagnosis system based on new architecture [J]. Automotive Digest, 2021 (5): 24-27.

[9] Zhuang Xia. API gateway architecture design example[J]. Automotive Digest, 2018 (5): 99-100.

[10] Xiang Jinsong, Jiang Hao, Deng Chenhui, et al. Design of body controller with integrated tire pressure monitoring [J]. Automotive Digest, 2017 (3): 49-53.

END

Add the letter below to join the automotive professional exchange group