System architecture, communication method, vehicle, medium and chip for vehicle control

Through the connection of the vehicle central computing domain controller with the SOA service interface of the vehicle control device and actuator, the complexity of vehicle software development and bandwidth limitation problems are solved, and the support for vehicle software upgrades and autonomous driving is realized.

CN115334110BActive Publication Date: 2025-08-12XIAOMI EV TECH CO LTD
View PDF 1 Cites 0 Cited by

Patent Information

Application Number
CN202210946374.7
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2022-08-08
Publication Date
2025-08-12
Estimated Expiration
2042-08-08

AI Technical Summary

Technical Problem

In the prior art, vehicle software development is complex, it is difficult to support after-sales software function upgrades, and it is unable to adapt to the bandwidth limitations of the trend of autonomous driving.

Method used

The vehicle central computing domain controller is used to connect the vehicle control device and actuator through Ethernet and CAN bus, and the SOA service is configured to provide a call interface, generate CAN control signals to control the actuator, and block the differences between different operating systems and communication buses.

Benefits of technology

It simplifies the complexity of software development, supports the upgrade of the after-sales software function of the vehicle, avoids the bandwidth limitation of traditional CAN communication, and adapts to the needs of autonomous driving.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN115334110B_ABST
    Figure CN115334110B_ABST
Patent Text Reader

Abstract

The present disclosure relates to a system architecture, communication method, vehicle, medium, and chip for vehicle control, belonging to the field of vehicle communication. The system architecture includes: a central computing domain controller for the entire vehicle, multiple on-board control devices connected to the central computing domain controller via Ethernet, and multiple actuators connected to the central computing domain controller via the CAN bus; the central computing domain controller for the entire vehicle is configured with an SOA service, which provides a calling interface to the on-board control devices. The on-board control devices send SOA service calling parameters to the central computing domain controller of the entire vehicle via the calling interface to call the SOA service, so that the central computing domain controller of the entire vehicle generates CAN control signals based on the SOA service calling parameters to control the actuators. The SOA service can shield the differences between different operating systems and different communication buses, effectively simplifying the complexity of software development and avoiding problems such as the complex design of traditional CAN communication and the limitation of signal expansion.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present disclosure relates to the field of vehicle communications, and in particular to a system architecture, communication method, vehicle, medium, and chip for vehicle control. Background Art

[0002] In related technologies, vehicle software development typically uses CAN signals to achieve communication between vehicle function development and system software components. However, post-vehicle software upgrades require simultaneous OTA upgrades of the underlying, mid-layer, and application-layer software. This requires a significant amount of testing and diagnostic work, making it difficult to support post-vehicle software upgrades. Furthermore, the CAN-based model for implementing vehicle functions is limited by CAN bus bandwidth and cannot adapt to the current trend toward autonomous driving. Summary of the Invention

[0003] To overcome the problems existing in the related art, the present disclosure provides a system architecture, a communication method, a vehicle, a medium and a chip for vehicle control.

[0004] According to a first aspect of an embodiment of the present disclosure, a system architecture for vehicle control is provided, which is applied to a vehicle. The system architecture includes:

[0005] A vehicle central computing domain controller, multiple on-board control devices connected to the vehicle central computing domain controller via Ethernet, and multiple actuators connected to the vehicle central computing domain controller via a CAN bus;

[0006] The vehicle central computing domain controller is configured with an SOA service, which provides a calling interface to the vehicle-mounted control device. The vehicle-mounted control device sends SOA service calling parameters to the vehicle central computing domain controller through the calling interface to call the SOA service, so that the vehicle central computing domain controller generates a CAN control signal according to the SOA service calling parameters to control the actuator.

[0007] Optionally, the SOA service also provides a subscription interface to the vehicle-mounted control device, and the vehicle-mounted control device subscribes to the SOA service through the subscription interface, so that the vehicle central computing domain controller sends SOA service return parameters to the vehicle-mounted control device that subscribes to the SOA service.

[0008] Optionally, the vehicle central computing domain controller is a multi-core controller, including a first core, a second core and a third core. The first core is deployed with the SOA service, the second core is deployed with software components for realizing the atomic capabilities of the vehicle, and the third core is deployed with AutoSAR components.

[0009] Optionally, the software component includes a first software component and a plurality of second software components, the AutoSAR component is a traditional platform AutoSAR component, includes an RTE layer, and the RTE layer provides a virtual bus;

[0010] The first software component determines an RTE signal mapping rule corresponding to the SOA service based on the SOA service corresponding to the SOA service parameters, and converts the SOA service call parameters into a first CAN signal based on the RTE signal mapping rule and sends it to the virtual bus of the RTE layer, so that the second software component corresponding to the first CAN signal receives the first CAN signal through the virtual bus and generates the CAN control signal based on the first CAN signal.

[0011] Optionally, the second software component is used to generate a second CAN signal based on a CAN feedback signal sent by the actuator in response to the CAN control signal, the first software component receives the second CAN signal generated by the second software component through the virtual bus, and generates an SOA service return parameter based on the second CAN signal and sends it to the first core.

[0012] Optionally, the AutoSAR component further includes a BSW layer and an OS layer. After the CAN control signal passes through the BSW layer, it is sent to the CAN bus through the OS layer, so that the actuator corresponding to the CAN control signal is executed according to the CAN control signal.

[0013] Optionally, the vehicle-mounted control device communicates with the vehicle central computing domain controller via Ethernet based on the DDS protocol.

[0014] Optionally, the vehicle-mounted control device receives a control instruction sent by a remote device through wireless communication, and calls or subscribes to the SOA service according to the control instruction.

[0015] According to a second aspect of an embodiment of the present disclosure, a communication method for vehicle control is provided, which is applied to the vehicle central computing domain controller as described in the first aspect of the present disclosure, wherein the vehicle central computing domain controller is connected to multiple on-board control devices via Ethernet and to multiple actuators via a CAN bus. The method includes:

[0016] Receiving SOA service call parameters sent by the vehicle control device through a call interface provided by the SOA service;

[0017] A CAN control signal is generated according to the SOA service call parameter to control the actuator.

[0018] According to a third aspect of an embodiment of the present disclosure, a vehicle is provided, comprising a vehicle central computing domain controller, a plurality of vehicle-mounted control devices connected to the vehicle central computing domain controller via Ethernet, and a plurality of actuators connected to the vehicle central computing domain controller via a CAN bus.

[0019] Among them, the vehicle central computing domain controller is configured to execute the method described in the second aspect of this disclosure.

[0020] According to a fourth aspect of an embodiment of the present disclosure, a computer-readable storage medium is provided, on which computer program instructions are stored. When the program instructions are executed by a processor, the steps of the method described in the second aspect of the present disclosure are implemented.

[0021] According to a fifth aspect of an embodiment of the present disclosure, a chip is provided, comprising a processor and an interface; the processor is used to read instructions to execute the method described in the second aspect of the present disclosure.

[0022] The technical solution provided by the embodiments of the present disclosure may include the following beneficial effects: by encapsulating the different capabilities of the vehicle and publishing them as SOA services in the central computing domain controller of the whole vehicle for invocation by the vehicle's on-board control device to realize the control of various execution structures of the vehicle, the SOA service can shield the differences between different operating systems and different communication buses, and encapsulate the entire vehicle as a logical device, thereby effectively simplifying the complexity of software development. In addition, the central computing domain controller of the whole vehicle and the on-board control device transmit data via Ethernet, avoiding problems such as the complex design of traditional CAN communication and the limitation of signal expansion.

[0023] It is to be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present disclosure and, together with the description, serve to explain the principles of the present disclosure.

[0025] Figure 1 is a schematic flow chart showing a system architecture for vehicle control according to an exemplary embodiment.

[0026] Figure 2 The figure is a schematic diagram of a central computing domain controller of a vehicle according to an exemplary embodiment.

[0027] Figure 3 The figure is a data flow diagram of a system architecture for vehicle control according to an exemplary embodiment.

[0028] Figure 4The figure is a flow chart showing a communication method for vehicle control according to an exemplary embodiment.

[0029] Figure 5 is a block diagram of a vehicle according to an exemplary embodiment.

[0030] Figure 6 It is a schematic functional block diagram of a vehicle according to an exemplary embodiment.

[0031] Figure 7 The figure is a block diagram of a central computing domain controller of a vehicle according to an exemplary embodiment. DETAILED DESCRIPTION

[0032] Exemplary embodiments will be described in detail herein, with examples illustrated in the accompanying drawings. In the following description, when referring to the drawings, identical numerals in different figures represent identical or similar elements, unless otherwise indicated. The embodiments described in the following exemplary embodiments are not intended to represent all possible embodiments consistent with the present disclosure. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the present disclosure, as detailed in the appended claims.

[0033] Figure 1 is a schematic diagram of a system architecture for vehicle control according to an exemplary embodiment. The system architecture is applied to a vehicle, such as Figure 1 As shown, the system architecture includes:

[0034] A vehicle central computing domain controller 110, multiple vehicle-mounted control devices 120 connected to the vehicle central computing domain controller 110 via Ethernet, and multiple actuators 130 connected to the vehicle central computing domain controller 110 via a CAN bus.

[0035] The vehicle central computing domain controller 110 is configured with a SOA (Service-Oriented Architecture) service. The SOA service provides a calling interface to the vehicle-mounted control device 120. The vehicle-mounted control device 120 sends SOA service calling parameters to the vehicle central computing domain controller 110 through the calling interface to call the SOA service, so that the vehicle central computing domain controller 110 generates a CAN control signal according to the SOA service calling parameters to control the actuator 130.

[0036] Among them, SOA services can abstract a unified data and function call interface on heterogeneous distributed systems. There can be multiple SOA services deployed in the central computing domain controller 110 of the entire vehicle. Each SOA service is used to be called to realize the control of the vehicle's actuator 130. For example, by calling a certain SOA service to control the exterior lights and interior lights, the light show function corresponding to the SOA service is realized. SOA services can include atomic services and composite services. Each atomic service can correspond to the atomic capability of an actuator 130, and each composite service can correspond to multiple atomic capabilities of multiple actuators 130. The actuators 130 may include doors, windows, battery charging and discharging, interior lights, exterior lights, air conditioning systems, driving systems, etc.

[0037] Reference Figure 1 The vehicle-mounted control device 120 may include domain controllers such as an intelligent driving domain controller and a cockpit domain controller, and may also include vehicle-mounted control devices such as a TBOX (Telematics-BOX) and a central control display module, although this disclosure does not limit this. Some of the vehicle-mounted control devices 120 may also communicate with external electronic devices via wireless or wired means. For example, a TBOX may communicate with a user's mobile phone or an Internet of Vehicles server, receive control signals from the phone or server, and invoke SOA services deployed in the vehicle's central computing domain controller 110 based on the control signals.

[0038] It is worth noting that each actuator 130 may include an MCU (Microcontroller Unit) and an actuator that specifically executes MCU instructions. For example, the actuator 130 may include a window motor and an MCU for controlling the motor. The MCU can collect CAN signals through the CAN bus to control the working status of the motor.

[0039] In the disclosed embodiment, the different capabilities of the vehicle are encapsulated and published as SOA services in the vehicle's central computing domain controller 110 for invocation by the vehicle's onboard control device 120 to implement control of the vehicle's various execution structures. The SOA service can shield the differences between different operating systems and different communication buses, and encapsulate the entire vehicle as a logical device, effectively simplifying the complexity of software development. In addition, the vehicle's central computing domain controller 110 and the onboard control device 120 transmit data via Ethernet, avoiding problems such as the complex design of traditional CAN communication and signal expansion limitations.

[0040] Optionally, the vehicle-mounted control device 120 communicates with the vehicle central computing domain controller 110 via Ethernet based on the DDS protocol.

[0041] In some optional embodiments, the SOA service also provides a subscription interface to the on-board control device 120, and the on-board control device 120 subscribes to the SOA service through the subscription interface, so that the vehicle central computing domain controller 110 sends SOA service return parameters to the on-board control device 120 that subscribes to the SOA service.

[0042] Among them, the call of SOA service can be implemented based on the SOME / IP protocol, and the subscription of SOA service can be implemented based on the DDS protocol stack. That is to say, the on-board control device 120 can communicate with the central computing and controller 110 of the whole vehicle through Ethernet based on the DDS protocol, or it can communicate with the central computing and controller 110 of the whole vehicle through Ethernet based on the SOME / IP protocol.

[0043] Specifically, the vehicle control device 120 can subscribe to the service by subscribing to the topic corresponding to the return parameters of the service, thereby enabling the vehicle central computing domain controller 110 to send the SOA service return parameters to the vehicle control device 120 that subscribes to the topic. Alternatively, the invocation and subscription of the SOA service can both be implemented based on the SOME / IP protocol or the DDS protocol stack, which is not limited in this disclosure.

[0044] For example, the vehicle control device 120 can call the SOA service based on the SOME / IP protocol. After executing the SOA service, the vehicle central computing domain controller 110 obtains the service return parameters of the SOA service and broadcasts them to the Ethernet based on the DDS protocol, so that the vehicle control device 120 that subscribes to the SOA service can obtain the service return parameters. In other possible implementations, the vehicle control device 120 can subscribe to the SOA service while calling the SOA service based on the DDS protocol stack and unsubscribe after receiving the service return parameters.

[0045] It is understood that SOA services can run corresponding software components when invoked, or they can run automatically and periodically. For example, if an SOA service is used to periodically collect first data, the vehicle central computing domain controller 110 can broadcast the first data as a service return parameter to the Ethernet network, so that the vehicle control device 120 that subscribes to the SOA service can obtain the first data.

[0046] By adopting the above solution, a subscription service is provided to the vehicle-mounted control device 120 through the SOA service, so that the vehicle-mounted control device 120 can obtain the return parameters of the SOA service through subscription, and transmit data in a data-centric manner through publish / subscribe, which can effectively reduce the data delay of the distributed system and improve reliability.

[0047] Figure 2 is a schematic diagram of a vehicle central computing domain controller according to an exemplary embodiment. Figure 2 As shown, the vehicle central computing domain controller 110 is a multi-core controller, including a first core, a second core and a third core. The first core is deployed with the SOA service, the second core is deployed with software components for realizing the atomic capabilities of the vehicle, and the third core is deployed with AutoSAR (Automotive Open System Architecture) components.

[0048] Software components (SWCs) are composed of atomic components as the smallest logical units. These smallest logical units are divided into two types: applications and sensors / actuators. Applications implement algorithms and can be freely mapped to the MCUs in each actuator 130. Sensors / actuators provide I / O ports for applications and have a one-to-one correspondence with the MCUs in each execution structure.

[0049] The operating system deployed in the first core may be a Linux system, and the operating system deployed in the third core may be an OSEK operating system or a dedicated operating system of the AutoSAR component.

[0050] In some optional embodiments, referring to Figure 2 The software component includes a first software component and a plurality of second software components, the AutoSAR component is a traditional platform AutoSAR component, and includes an RTE (Runtime environment) layer, and the RTE layer provides a virtual bus;

[0051] The first software component determines an RTE signal mapping rule corresponding to the SOA service based on the SOA service corresponding to the SOA service parameters, and converts the SOA service call parameters into a first CAN signal based on the RTE signal mapping rule and sends it to the virtual bus of the RTE layer, so that the second software component corresponding to the first CAN signal receives the first CAN signal through the virtual bus and generates the CAN control signal based on the first CAN signal.

[0052] It is understood that each SOA service is configured with a signal mapping relationship, that is, the mapping rules between service call parameters and service return parameters and RTE signals. Among them, the first software component is used to convert the service into a signal, and each second software component is used to implement different capabilities of the vehicle.

[0053] It is worth noting that the first software component and multiple second software components are all connected to the virtual bus through ports and communicate on the virtual bus through signals to realize data exchange between software components. Each second software component is actually a description of the function of the actuator 130, and during the implementation process, code will be generated to be executed on the MCU in the actuator 130.

[0054] In addition, the second software component can be designed as a two-layer architecture consisting of a service layer (interface encapsulation) and an execution layer (specific logical implementation of window control). The service layer performs relevant prerequisite judgments, logic arbitration, and request cache management, etc.; the execution layer performs necessary prerequisite judgments (such as obtaining data released by other second software components through a virtual bus, such as obtaining rainfall status) and executes the corresponding executable entities in sequence.

[0055] By adopting the above solution, the virtual bus is realized through the RTE layer in the AutoSAR component of the traditional platform. The service parameters are converted into signals by the first software component in the software components and the signals are transmitted through the virtual bus to the second software component used to implement specific business, thereby realizing vehicle control based on SOA services. While adopting SOA services, the traditional CAN signal development method is retained to ensure the safety performance of vehicle control.

[0056] In some optional embodiments, the second software component is used to generate a second CAN signal based on a CAN feedback signal sent by the actuator 130 in response to the CAN control signal, the first software component receives the second CAN signal generated by the second software component through the virtual bus, and generates an SOA service return parameter based on the second CAN signal and sends it to the first core.

[0057] For example, if the CAN control signal is used to instruct the actuator 130 to close the window or obtain data, the execution structure can send an execution success signal or a corresponding data signal (i.e., a CAN feedback signal) to the second software component after executing the operation corresponding to the control signal (i.e., closing the window or obtaining data). The second software component can then generate a second CAN signal based on the signal and publish it through the virtual bus, so that the first software component can obtain the second CAN signal on the virtual bus, and convert the signal into an SOA service return parameter through the signal transfer service, so that the first core can obtain the feedback information of the actuator 130 running the service parameter, and then return the SOA service return parameter to the vehicle-mounted control device 120 that calls or subscribes to the SOA service.

[0058] By adopting the above solution, the feedback signal of the actuator 130 is received by the second software component and published to the virtual bus, so that the first software component receives the feedback signal and converts it into a service, and sends the service return parameter to the caller or subscriber through the first core, which can effectively realize the control feedback of the SOA service and ensure that the vehicle-mounted control device 120 that subscribes to or calls the SOA service can know whether its control is successful, or obtain the data corresponding to the SOA service.

[0059] Optionally, refer to Figure 2 The AutoSAR component also includes a BSW (Basic software) layer and an OS (operate system) layer. After the CAN control signal passes through the BSW layer, it is sent to the CAN bus through the OS layer, so that the actuator 130 corresponding to the CAN control signal is executed according to the CAN control signal.

[0060] Understandably, a vehicle contains a variety of ECUs (Electronic Control Units) with diverse functions. However, the fundamental services required to implement these functions—those distinct ECU functions—can be abstracted. Examples include I / O operations, diagnostics, CAN communication, and the operating system. The I / O operations performed can represent different meanings, the CAN signals received and sent can represent different meanings, and the task cycles scheduled by the operating system can have different priorities. These abstracted fundamental services are called basic software and constitute the BSW layer.

[0061] In other words, the AutoSAR component transmits the CAN signals sent by each second software component to each actuator 130 through the RTE layer. After processing by the BSW layer, the signals are then sent to the CAN bus via the AutoSAR component's corresponding operating system, thereby achieving signal transmission. Similarly, the feedback signals from each actuator 130 are received by the AutoSAR component's operating system (i.e., the OS layer), processed by the BSW layer, and then fed back to the respective software components via the RTE layer's virtual bus.

[0062] In some embodiments, the vehicle-mounted control device 120 receives a control instruction sent by a remote device via wireless communication, and calls or subscribes to the SOA service according to the control instruction.

[0063] For example, refer to Figure 3The TBOX in the vehicle-mounted control device 120 can communicate wirelessly with the user equipment in a wireless manner, that is, the TBOX can receive the control instructions sent by the user equipment through wireless communication, and subscribe to or call one or more SOA services published by the vehicle central computing domain controller 110 connected via Ethernet according to the control instructions.

[0064] By adopting the above solution, control commands sent by remote devices are received through wireless communication, and then SOA services are called or subscribed. This can realize remote calling and subscription of the vehicle's underlying capabilities, and can more richly support IoT (Internet of Things) and V2X (vehicle to X, vehicle wireless communication) application scenarios.

[0065] In order to make those skilled in the art better understand the technical solutions provided by the present disclosure, Figure 2 The central computing domain controller of the vehicle shown in the present disclosure also provides Figure 3 The data flow diagram of a system architecture for vehicle control according to an exemplary embodiment is shown in FIG. Figure 3 As shown:

[0066] The user equipment sends a control command to the vehicle TBOX. The user equipment may also send a control signal to the Internet of Vehicles server, which then forwards the control signal to the vehicle TBOX.

[0067] The TBOX generates service call parameters according to the control instructions and sends the service call parameters to the first core of the vehicle central computing domain controller 110 to call the corresponding SOA service.

[0068] The first core sends the service call parameters to the first software component in the second core, so that the service call parameters are converted into a first CAN signal and sent to the virtual bus of the RTE layer.

[0069] The second software component corresponding to the SOA service obtains the first CAN signal through the virtual bus and generates a CAN control signal. The CAN control signal passes through the BSW layer and the OS layer of the AutoSAR component and is sent to the corresponding actuator 130 via the CAN bus.

[0070] Figure 4 This is a flow chart illustrating a communication method for vehicle control according to an exemplary embodiment. The method is applied to a central computing domain controller of a vehicle. The central computing domain controller of the vehicle is connected to multiple on-board control devices via Ethernet and to multiple actuators via a CAN bus. The method includes:

[0071] S401, receiving SOA service call parameters sent by the vehicle control device through a call interface provided by the SOA service;

[0072] S402: Generate a CAN control signal according to the SOA service call parameter to control the actuator.

[0073] Optionally, the method further includes:

[0074] A subscription interface is provided to the vehicle-mounted control device through the SOA service, and the vehicle-mounted control device subscribes to the SOA service through the subscription interface, so that the vehicle central computing domain controller sends SOA service return parameters to the vehicle-mounted control device that subscribes to the SOA service.

[0075] Optionally, the vehicle central computing domain controller is a multi-core controller, including a first core, a second core and a third core. The first core is deployed with the SOA service, the second core is deployed with software components for realizing the atomic capabilities of the vehicle, and the third core is deployed with AutoSAR components.

[0076] Optionally, the software component includes a first software component and a plurality of second software components, the AutoSAR component is a traditional platform AutoSAR component, includes an RTE layer, and the RTE layer provides a virtual bus;

[0077] The method comprises:

[0078] The first software component determines an RTE signal mapping rule corresponding to the SOA service according to the SOA service corresponding to the SOA service parameters, and converts the SOA service call parameters into a first CAN signal according to the RTE signal mapping rule and sends it to the virtual bus of the RTE layer, so that the second software component corresponding to the first CAN signal receives the first CAN signal through the virtual bus and generates the CAN control signal according to the first CAN signal.

[0079] Optionally, the method further includes:

[0080] generating, by the second software component, a second CAN signal according to a CAN feedback signal sent by the actuator in response to the CAN control signal;

[0081] The first software component receives the second CAN signal generated by the second software component through the virtual bus, and generates an SOA service return parameter according to the second CAN signal and sends it to the first core.

[0082] Optionally, the AutoSAR component further includes a BSW layer and an OS layer. After the CAN control signal passes through the BSW layer, it is sent to the CAN bus through the OS layer, so that the actuator corresponding to the CAN control signal is executed according to the CAN control signal.

[0083] Optionally, the vehicle-mounted control device communicates with the vehicle central computing domain controller via Ethernet based on the DDS protocol.

[0084] Optionally, the vehicle-mounted control device receives a control instruction sent by a remote device through wireless communication, and calls or subscribes to the SOA service according to the control instruction.

[0085] Figure 5 is a schematic diagram of a vehicle according to an exemplary embodiment, as shown in FIG. Figure 5 As shown, the vehicle 500 includes a vehicle central computing domain controller 110, a plurality of vehicle-mounted control devices 120 connected to the vehicle central computing domain controller 110 via Ethernet, and a plurality of actuators 130 connected to the vehicle central computing domain controller 110 via a CAN bus; wherein, the vehicle central computing domain controller 110 is configured to execute the communication method for vehicle control provided by the present disclosure.

[0086] See Figure 6 , Figure 6 6 is a functional block diagram of another vehicle according to an exemplary embodiment. Vehicle 600 can be configured for either fully or partially autonomous driving. For example, vehicle 600 can obtain environmental information about its surroundings through perception system 620 and, based on analysis of the environmental information, develop an autonomous driving strategy to achieve fully autonomous driving, or present the analysis results to a user to achieve partially autonomous driving.

[0087] Vehicle 600 may include various subsystems, such as an infotainment system 610, a perception system 620, a decision control system 630, a drive system 640, and a computing platform 650. Alternatively, vehicle 600 may include more or fewer subsystems, and each subsystem may include multiple components. Furthermore, each subsystem and component of vehicle 600 may be interconnected via wired or wireless means.

[0088] In some embodiments, infotainment system 610 may include a communication system 611 , an entertainment system 612 , and a navigation system 613 .

[0089] The communication system 611 may include a wireless communication system that can communicate wirelessly with one or more devices directly or via a communication network. For example, the wireless communication system can use 3G cellular communication, such as CDMA, EVDO, GSM / GPRS, or 4G cellular communication, such as LTE. Or 5G cellular communication. The wireless communication system can use WiFi to communicate with a wireless local area network (WLAN). In some embodiments, the wireless communication system can use an infrared link, Bluetooth, or ZigBee to communicate directly with the device. Other wireless protocols, such as various vehicle communication systems, for example, the wireless communication system may include one or more dedicated short range communications (DSRC) devices, which may include public and / or private data communications between vehicles and / or roadside stations.

[0090] The entertainment system 612 may include a display device, a microphone and speakers. Users can listen to the radio and play music in the car based on the entertainment system; or connect the mobile phone to the vehicle and project the mobile phone screen on the display device. The display device can be touch-sensitive and the user can operate it by touching the screen.

[0091] In some cases, the user's voice signal can be obtained through a microphone, and based on the analysis of the user's voice signal, the user can control certain aspects of the vehicle 600, such as adjusting the temperature inside the vehicle, etc. In other cases, music can be played to the user through a speaker.

[0092] The navigation system 613 may include a map service provided by a map provider, thereby providing navigation for the vehicle 600. The navigation system 613 may be used in conjunction with the vehicle's global positioning system 621 and inertial measurement unit 622. The map service provided by the map provider may be a two-dimensional map or a high-precision map.

[0093] The perception system 620 may include several sensors that sense information about the environment surrounding the vehicle 600. For example, the perception system 620 may include a global positioning system 621 (the global positioning system may be a GPS system, or a BeiDou system or other positioning system), an inertial measurement unit (IMU) 622, a lidar 623, a millimeter wave radar 624, an ultrasonic radar 625, and a camera 626. The perception system 620 may also include sensors of the internal systems of the monitored vehicle 600 (for example, an in-vehicle air quality monitor, a fuel gauge, an oil temperature gauge, etc.). Sensor data from one or more of these sensors can be used to detect objects and their corresponding characteristics (position, shape, direction, speed, etc.). Such detection and recognition are key functions for the safe operation of the vehicle 600.

[0094] The global positioning system 621 is used to estimate the geographic location of the vehicle 600 .

[0095] The inertial measurement unit 622 is used to sense the posture change of the vehicle 600 based on inertial acceleration. In some embodiments, the inertial measurement unit 622 can be a combination of an accelerometer and a gyroscope.

[0096] LiDAR 623 utilizes laser light to sense objects in the environment in which vehicle 600 is located. In some embodiments, LiDAR 623 may include one or more laser sources, a laser scanner, and one or more detectors, among other system components.

[0097] The millimeter wave radar 624 uses radio signals to sense objects in the surrounding environment of the vehicle 600. In some embodiments, in addition to sensing objects, the millimeter wave radar 624 can also be used to sense the speed and / or heading of the objects.

[0098] The ultrasonic radar 625 may sense objects around the vehicle 600 using ultrasonic signals.

[0099] The camera device 626 is used to capture image information of the surrounding environment of the vehicle 600. The camera device 626 may include a monocular camera, a binocular camera, a structured light camera, a panoramic camera, etc. The image information obtained by the camera device 626 may include static images or video stream information.

[0100] The decision control system 630 includes a computing system 631 that analyzes and makes decisions based on the information obtained by the perception system 620. The decision control system 630 also includes a vehicle controller 632 that controls the power system of the vehicle 600, as well as a steering system 633, throttle 634 and braking system 635 for controlling the vehicle 600.

[0101] The computing system 631 can be operated to process and analyze various information obtained by the perception system 620 in order to identify targets, objects and / or features in the environment surrounding the vehicle 600. Targets may include pedestrians or animals, and objects and / or features may include traffic signals, road boundaries and obstacles. The computing system 631 may use object recognition algorithms, Structure from Motion (SFM) algorithms, video tracking and other technologies. In some embodiments, the computing system 631 can be used to map the environment, track objects, estimate the speed of objects, and so on. The computing system 631 can analyze the various information obtained and derive a control strategy for the vehicle.

[0102] The vehicle controller 632 can be used to coordinate and control the vehicle's power battery and engine 641 to improve the power performance of the vehicle 600.

[0103] The steering system 633 is operable to adjust the forward direction of the vehicle 600. For example, in one embodiment, it may be a steering wheel system.

[0104] The throttle 634 is used to control the operating speed of the engine 641 and thereby control the speed of the vehicle 600 .

[0105] Braking system 635 is used to control the deceleration of vehicle 600. Braking system 635 can use friction to slow down wheels 644. In some embodiments, braking system 635 can convert the kinetic energy of wheels 644 into electric current. Braking system 635 can also take other forms to slow the rotation speed of wheels 644 and thus control the speed of vehicle 600.

[0106] Drive system 640 may include components that provide powered motion for vehicle 600. In one embodiment, drive system 640 may include an engine 641, an energy source 642, a transmission system 643, and wheels 644. Engine 641 may be an internal combustion engine, an electric motor, an air compression engine, or another combination of engines, such as a hybrid engine consisting of a gasoline engine and an electric motor, or a hybrid engine consisting of an internal combustion engine and an air compression engine. Engine 641 converts energy source 642 into mechanical energy.

[0107] Examples of energy source 642 include gasoline, diesel, other petroleum-based fuels, propane, other compressed gas-based fuels, ethanol, solar panels, batteries, and other sources of electricity. Energy source 642 can also provide energy to other systems of vehicle 600.

[0108] The transmission system 643 can transmit mechanical power from the engine 641 to the wheels 644. The transmission system 643 may include a gearbox, a differential, and a drive shaft. In one embodiment, the transmission system 643 may also include other components, such as a clutch. The drive shaft may include one or more shafts that can be coupled to one or more wheels 644.

[0109] Some or all functions of vehicle 600 are controlled by a computing platform 650. Computing platform 650 may include at least one processor 651 that can execute instructions 653 stored in a non-transitory computer-readable medium such as memory 652. In some embodiments, computing platform 650 may also be a plurality of computing devices that control individual components or subsystems of vehicle 600 in a distributed manner.

[0110] The processor 651 may be any conventional processor, such as a commercially available CPU. Alternatively, the processor 651 may include a graphics processor (GPU), a field programmable gate array (FPGA), a system on chip (SOC), an application specific integrated circuit (ASIC), or a combination thereof. Figure 6 Functionally, processor, memory, and other elements of the computer in the same block are illustrated, but those of ordinary skill in the art will appreciate that the processor, computer, or memory may in fact comprise a plurality of processors, computers, or memories that may or may not be stored in the same physical housing. For example, the memory may be a hard drive or other storage medium that is positioned in a housing that is different from the computer. Therefore, reference to a processor or computer will be understood to include reference to a collection of processors or computers or memories that may or may not operate in parallel. Different from using a single processor to perform the steps described herein, some assemblies such as steering assembly and deceleration assembly may each have their own processor that only performs the calculations relevant to the functions specific to the assembly.

[0111] In an embodiment of the present disclosure, the processor 651 may execute the aforementioned communication method for vehicle control.

[0112] In various aspects described herein, the processor 651 can be located remotely from the vehicle and in wireless communication with the vehicle. In other aspects, some of the processes described herein are performed on a processor disposed within the vehicle while others are performed by a remote processor, including taking the necessary steps to perform a single maneuver.

[0113] In some embodiments, the memory 652 may include instructions 653 (e.g., program logic) that are executable by the processor 651 to perform various functions of the vehicle 600. The memory 652 may also include additional instructions, including instructions for sending data to, receiving data from, interacting with, and / or controlling one or more of the infotainment system 610, the perception system 620, the decision control system 630, and the drive system 640.

[0114] In addition to instructions 653, memory 652 may also store data such as road maps, route information, the vehicle's location, direction, speed, and other such vehicle data, as well as other information. This information may be used by vehicle 600 and computing platform 650 during operation of vehicle 600 in autonomous, semi-autonomous, and / or manual modes.

[0115] The computing platform 650 may control functions of the vehicle 600 based on input received from various subsystems, such as the drive system 640, the perception system 620, and the decision control system 630. For example, the computing platform 650 may utilize input from the decision control system 630 to control the steering system 633 to avoid an obstacle detected by the perception system 620. In some embodiments, the computing platform 650 may be operable to provide control over many aspects of the vehicle 600 and its subsystems.

[0116] Alternatively, one or more of the above components may be installed or associated separately from the vehicle 600. For example, the first memory 652 may be partially or completely separate from the vehicle 600. The above components may be communicatively coupled together in a wired and / or wireless manner.

[0117] Optionally, the above components are just an example. In actual applications, the components in the above modules may be added or deleted according to actual needs. Figure 6 It should not be understood as limiting the embodiments of the present disclosure.

[0118] An autonomous vehicle traveling on a road, such as vehicle 600 above, can identify objects in its surroundings to determine adjustments to its current speed. Objects can be other vehicles, traffic control devices, or other types of objects. In some examples, each identified object can be considered independently, and the speed adjustment to be made to the autonomous vehicle can be determined based on its respective characteristics, such as its current speed, acceleration, and distance from the vehicle.

[0119] Optionally, the vehicle 600 or a sensing and computing device associated with the vehicle 600 (e.g., computing system 631, computing platform 650) can predict the behavior of the identified objects based on the characteristics of the identified objects and the state of the surrounding environment (e.g., traffic, rain, ice on the road, etc.). Optionally, each identified object depends on the behavior of each other, so the behavior of all identified objects can also be considered together to predict the behavior of a single identified object. The vehicle 600 can adjust its speed based on the predicted behavior of the identified objects. In other words, the autonomous vehicle can determine what stable state the vehicle will need to adjust to (e.g., accelerate, decelerate, or stop) based on the predicted behavior of the objects. In this process, other factors can also be considered to determine the speed of the vehicle 600, such as the lateral position of the vehicle 600 in the road it is traveling on, the curvature of the road, the proximity of static and dynamic objects, etc.

[0120] In addition to providing instructions to adjust the speed of the autonomous vehicle, the computing device may also provide instructions to modify the steering angle of vehicle 600 so that the autonomous vehicle follows a given trajectory and / or maintains a safe lateral and longitudinal distance from objects near the autonomous vehicle (e.g., vehicles in adjacent lanes on the road).

[0121] The vehicle 600 may be any type of vehicle, such as a car, a truck, a motorcycle, a bus, a ship, an airplane, a helicopter, an RV, a train, etc., and the present disclosure does not impose any particular limitation thereto.

[0122] In another exemplary embodiment, a computer program product is also provided. The computer program product includes a computer program executable by a programmable device, and has a code portion for executing the above-mentioned communication method for vehicle control when executed by the programmable device.

[0123] Figure 7 This is a block diagram of a vehicle central computing domain controller according to an exemplary embodiment. Figure 7 The vehicle central computing domain controller 110 includes a processing component 722, which further includes one or more processors, and a memory resource represented by a second memory 732 for storing instructions executable by the processing component 722, such as application programs. The application programs stored in the second memory 732 may include one or more modules, each corresponding to a set of instructions. Furthermore, the processing component 722 is configured to execute the instructions to perform the aforementioned communication method for vehicle control.

[0124] The vehicle central computing domain controller 110 may further include a power supply component 726 configured to perform power management of the vehicle central computing domain controller 110, a wired or wireless network interface 750 configured to connect the vehicle central computing domain controller 110 to a network, and an input / output interface 758. The vehicle central computing domain controller 110 may operate based on an operating system stored in the second memory 732, such as Windows Server 2003. TM , Mac OS X TM , Unix TM , Linux TM , FreeBSD TM or similar.

[0125] In addition to being an independent electronic device, the above-mentioned vehicle central computing domain controller 110 can also be part of an independent electronic device. For example, in one embodiment, the vehicle central computing domain controller 110 can be an integrated circuit (IC) or a chip, wherein the integrated circuit can be a single IC or a collection of multiple ICs; the chip can include but is not limited to the following types: GPU (Graphics Processing Unit), CPU (Central Processing Unit), FPGA (Field Programmable Gate Array), DSP (Digital Signal Processor), ASIC (Application Specific Integrated Circuit), SOC (System on Chip, SoC, system on chip or system-level chip), etc. The above-mentioned integrated circuit or chip can be used to execute executable instructions (or codes) to implement the above-mentioned communication method for vehicle control. The executable instructions can be stored in the integrated circuit or chip, or can be obtained from other devices or equipment, for example, the integrated circuit or chip includes a processor, a memory, and an interface for communicating with other devices. The executable instruction can be stored in the memory, and when the executable instruction is executed by the processor, the above-mentioned communication method for vehicle control is implemented; alternatively, the integrated circuit or chip can receive the executable instruction through the interface and transmit it to the processor for execution to implement the above-mentioned communication method for vehicle control.

[0126] Other embodiments of the present disclosure will readily occur to those skilled in the art after considering the specification and practicing the present disclosure. This application is intended to cover any variations, uses, or adaptations of the present disclosure that follow the general principles of the present disclosure and include common knowledge or customary techniques in the art not disclosed herein. The description and examples are to be considered as exemplary only, with the true scope and spirit of the present disclosure being indicated by the following claims.

[0127] It should be understood that the present disclosure is not limited to the exact structures that have been described above and shown in the drawings, and that various modifications and changes can be made without departing from the scope thereof. The scope of the present disclosure is limited only by the appended claims.

Claims

1. A system architecture for vehicle control, characterized in that: Applied to a vehicle, the system architecture includes: A vehicle central computing domain controller, multiple on-board control devices connected to the vehicle central computing domain controller via Ethernet, and multiple actuators connected to the vehicle central computing domain controller via a CAN bus; The vehicle central computing domain controller is configured with an SOA service, and the SOA service provides a calling interface to the vehicle-mounted control device. The vehicle-mounted control device sends SOA service calling parameters to the vehicle central computing domain controller through the calling interface to call the SOA service, so that the vehicle central computing domain controller generates a CAN control signal according to the SOA service calling parameters to control the actuator; The vehicle central computing domain controller is a multi-core controller including a first core, a second core, and a third core. The first core is deployed with the SOA service, the second core is deployed with software components for implementing the atomic capabilities of the vehicle, and the third core is deployed with the AutoSAR component. The software component includes a first software component and a plurality of second software components, the AutoSAR component is a traditional platform AutoSAR component, and includes an RTE layer, and the RTE layer provides a virtual bus; The first software component determines an RTE signal mapping rule corresponding to the SOA service based on the SOA service corresponding to the SOA service parameters, and converts the SOA service call parameters into a first CAN signal based on the RTE signal mapping rule and sends it to the virtual bus of the RTE layer, so that the second software component corresponding to the first CAN signal receives the first CAN signal through the virtual bus and generates the CAN control signal based on the first CAN signal.

2. The system architecture according to claim 1, characterized in that: The SOA service also provides a subscription interface to the vehicle control device, and the vehicle control device subscribes to the SOA service through the subscription interface, so that the vehicle central computing domain controller sends SOA service return parameters to the vehicle control device that subscribes to the SOA service.

3. The system architecture according to claim 1, characterized in that: The second software component is used to generate a second CAN signal based on a CAN feedback signal sent by the actuator in response to the CAN control signal. The first software component receives the second CAN signal generated by the second software component through the virtual bus, and generates an SOA service return parameter based on the second CAN signal and sends it to the first core.

4. The system architecture according to claim 1, wherein: The AutoSAR component further includes a BSW layer and an OS layer. After the CAN control signal passes through the BSW layer, it is sent to the CAN bus through the OS layer, so that the actuator corresponding to the CAN control signal is executed according to the CAN control signal.

5. The system architecture according to any one of claims 1 to 4, characterized in that: The vehicle-mounted control device communicates with the vehicle central computing domain controller via Ethernet based on the DDS protocol.

6. The system architecture according to any one of claims 1 to 4, characterized in that: The vehicle-mounted control device receives a control instruction sent by a remote device through wireless communication, and calls or subscribes to the SOA service according to the control instruction.

7. A communication method for vehicle control, characterized in that: Applied to the vehicle central computing domain controller according to any one of claims 1 to 6, the vehicle central computing domain controller is connected to multiple vehicle-mounted control devices via Ethernet and is connected to multiple actuators via a CAN bus, the method comprising: Receiving SOA service call parameters sent by the vehicle control device through a call interface provided by the SOA service; Generate a CAN control signal according to the SOA service call parameter to control the actuator; The vehicle central computing domain controller is a multi-core controller including a first core, a second core, and a third core. The first core is deployed with the SOA service, the second core is deployed with software components for implementing the atomic capabilities of the vehicle, and the third core is deployed with the AutoSAR component. The software component includes a first software component and a plurality of second software components, the AutoSAR component is a traditional platform AutoSAR component, and includes an RTE layer, and the RTE layer provides a virtual bus; The method comprises: The first software component determines an RTE signal mapping rule corresponding to the SOA service according to the SOA service corresponding to the SOA service parameters, and converts the SOA service call parameters into a first CAN signal according to the RTE signal mapping rule and sends it to the virtual bus of the RTE layer, so that the second software component corresponding to the first CAN signal receives the first CAN signal through the virtual bus and generates the CAN control signal according to the first CAN signal.

8. A vehicle, characterized in that: It includes a vehicle central computing domain controller, multiple vehicle-mounted control devices connected to the vehicle central computing domain controller via Ethernet, and multiple actuators connected to the vehicle central computing domain controller via CAN bus; Wherein, the vehicle central computing domain controller is configured to execute the method described in claim 7.

9. A computer-readable storage medium having computer program instructions stored thereon, characterized in that: When the program instructions are executed by a processor, the steps of the method according to claim 7 are implemented.

10. A chip, characterized in that: The method comprises a processor and an interface; the processor is configured to read instructions to execute the method according to claim 7.

Citation Information

Patent Citations

  • SOA-based vehicle cloud cooperative control system and method, and readable storage medium

    CN114553873A