Vehicle-mounted equipment control method and system

Abstract

This invention provides a method and system for controlling in-vehicle equipment. The method includes: acquiring a static configuration table for each in-vehicle device, the static configuration table including parameter information of the hardware interfaces adapted to the in-vehicle devices; pairing each in-vehicle device with each hardware interface of the vehicle-side controller based on the static configuration table; generating hardware peripheral configuration information based on the pairing results; determining the target hardware interface corresponding to the data access request based on the data access request and the hardware peripheral configuration information when a data access request is received from the client controller; and establishing an access service between the target hardware interface and the client controller. By combining static configuration and dynamic matching, a high degree of adaptation between the vehicle-side controller and the client controller is achieved, avoiding the need to re-decouple the functional software and hardware platform due to switching hardware platforms. This significantly improves data access efficiency while further reducing production costs.

Description

Technical Field

[0001] This invention relates to the field of engineering machinery, and specifically to a method and system for controlling vehicle-mounted equipment. Background Technology

[0002] The Poseidon computing platform is positioned as a domain controller for L2+ and above intelligent driving specifically for construction machinery. The software design goal of the Poseidon computing platform is Service-Oriented Architecture (SOA), with a single software package supporting the smooth evolution of L2+ and above functionalities. The Poseidon platform's hardware solution supports interface expansion; upper-layer software development needs to be unaware of the underlying hardware, and the platform's functional software needs to be adapted and generalized according to the usage scenarios of construction machinery vehicles.

[0003] Currently, there is no mature mass-production solution for L2+ intelligent driving domain controllers in the domestic construction machinery industry. There is no unified standard in the industry, and the functional software and hardware platform are not decoupled, resulting in the following problems:

[0004] Hardware platforms and functional software are typically provided by different vendors. Vendors of functional software need to spend considerable time familiarizing themselves with the hardware platform, and the resulting software cannot be directly migrated to other hardware platforms. If a hardware platform switch is necessary due to chip shortages or other reasons, the functional software needs to be adapted and redeveloped for the new platform, requiring renewed investment in time and cost. Summary of the Invention

[0005] Therefore, the technical problem to be solved by the present invention is to overcome the shortcomings of the prior art where the functional software and hardware platform are not sufficiently decoupled, which leads to the need for the functional software to be re-adapted and developed according to the new hardware platform when the hardware platform needs to be switched due to chip shortages or other reasons, which greatly increases the R&D cycle and cost investment. In this way, the present invention provides a vehicle equipment control method and system.

[0006] According to a first aspect, embodiments of the present invention provide a vehicle-mounted device control method, applied to a vehicle-side controller, the method comprising:

[0007] Obtain the static configuration table of each vehicle-mounted device, wherein the static configuration table includes parameter information of the hardware interface adapted to the vehicle-mounted device;

[0008] Based on the static configuration table, each on-board device is paired with each hardware interface of the vehicle controller.

[0009] Generate hardware peripheral configuration information based on the pairing results;

[0010] Upon receiving a data access request from the client controller, the target hardware interface corresponding to the data access request is determined based on the data access request and the hardware peripheral configuration information.

[0011] An access service is established between the target hardware interface and the client controller, so that the client controller can access data from the corresponding target vehicle device through the target hardware interface.

[0012] Optionally, determining the target hardware interface corresponding to the data access request based on the client controller request and the hardware peripheral configuration information includes:

[0013] Based on the data access request and the hardware peripheral configuration information, determine the alternative hardware interfaces corresponding to each alternative vehicle-mounted device.

[0014] Obtain the access mechanism table corresponding to each hardware interface, wherein the access mechanism table stores the client controller type requirements corresponding to each hardware interface;

[0015] Based on the client controller, a target hardware interface that conforms to the access mechanism table is determined from each candidate hardware interface.

[0016] Optionally, determining the target hardware interface corresponding to the data access request based on the client controller request and the hardware peripheral configuration information further includes:

[0017] Obtain the occupancy status of the vehicle-mounted devices corresponding to each target hardware interface;

[0018] Based on the occupancy status of each vehicle-mounted device, the vehicle-mounted device with the least occupancy is selected as the target vehicle-mounted device.

[0019] The target hardware interface corresponding to the target vehicle-mounted device is determined as the final target hardware interface.

[0020] Optionally, the method further includes:

[0021] The target hardware interface and its corresponding target vehicle device are sent to the client controller, so that the client controller sends a registration request for the target hardware interface to the vehicle controller based on the target hardware interface and the target vehicle device;

[0022] Upon receiving a registration request from the client controller, an access service is established between the target hardware interface and the client controller based on the registration request.

[0023] Optionally, determining the alternative hardware interfaces corresponding to each alternative vehicle-mounted device based on the data access request and the hardware peripheral configuration information includes:

[0024] Extract the target peripheral parameter requirements of the data access object from the data access request;

[0025] Determine whether the peripheral parameters of the current vehicle-mounted device are consistent with the target peripheral parameter requirements;

[0026] When the peripheral parameters of the current vehicle device are consistent with the target peripheral parameter requirements, the current vehicle device is determined as a candidate vehicle device, and the hardware interface corresponding to the current vehicle device is determined as the target hardware interface.

[0027] Optionally, after establishing the access service between the target hardware interface and the client controller, the method further includes:

[0028] The target hardware interface is locked to prevent other client controllers from accessing data through the target hardware interface.

[0029] According to a second aspect, embodiments of the present invention provide a vehicle-mounted device control method, applied to a client controller, the method comprising:

[0030] A data access request is sent to the vehicle controller, so that the vehicle controller determines the target hardware interface corresponding to the data access request based on the data access request and the hardware peripheral configuration information; an access service is established between the target hardware interface and the client controller, wherein the hardware peripheral configuration information is used to characterize the pairing result between each vehicle device and each hardware interface of the vehicle controller;

[0031] Data can be accessed from the corresponding target vehicle-mounted device through the target hardware interface.

[0032] Optionally, after sending a data access request to the vehicle-side controller, the method further includes:

[0033] Receive the target hardware interface and its corresponding target vehicle-mounted equipment sent by the vehicle-side controller;

[0034] Based on the target hardware interface and the target vehicle device, a registration request is sent to the vehicle controller, so that the vehicle controller can establish an access service between the target hardware interface and the client controller according to the registration request.

[0035] Optionally, sending a registration request to the vehicle controller based on the target hardware interface and the target vehicle-mounted device includes:

[0036] Based on the hardware peripheral configuration information corresponding to the target hardware interface, the address information of the vehicle-side controller is determined;

[0037] Based on the address information of the vehicle controller and the address information of the client controller, determine whether the vehicle controller and the client controller are located on the same chip;

[0038] When the vehicle-side controller and the client-side controller are located on the same chip, a registration request is sent to the vehicle-side controller using inter-core communication.

[0039] When the vehicle-side controller and the client-side controller are not located on the same chip, a registration request is sent to the vehicle-side controller using an external communication method.

[0040] According to a third aspect, embodiments of the present invention provide an in-vehicle equipment control system, the system comprising: a vehicle-side controller and a plurality of client-side controllers.

[0041] The vehicle-side controller is used to obtain the static configuration table of each vehicle-mounted device, which includes parameter information of the hardware interfaces adapted to the vehicle-mounted devices; based on the static configuration table, each vehicle-mounted device is paired with each hardware interface of the vehicle-side controller; and hardware peripheral configuration information is generated based on the pairing results.

[0042] The client controller is used to send data access requests to the vehicle controller;

[0043] When the vehicle-side controller receives a data access request from the client controller, it determines the target hardware interface corresponding to the data access request based on the data access request and the hardware peripheral configuration information; and establishes an access service between the target hardware interface and the client controller.

[0044] The client controller is used to access data from the corresponding vehicle-mounted equipment through the target hardware interface.

[0045] The technical solution of this invention has the following advantages:

[0046] 1. This invention provides a vehicle-mounted device control method applied to a vehicle-side controller. The method involves acquiring a static configuration table for each vehicle-mounted device, the static configuration table including parameter information of the hardware interfaces adapted to the vehicle-mounted devices; pairing each vehicle-mounted device with each hardware interface of the vehicle-side controller based on the static configuration table; generating hardware peripheral configuration information based on the pairing results; upon receiving a data access request from a client controller, determining the target hardware interface corresponding to the data access request based on the data access request and the hardware peripheral configuration information; and establishing an access service between the target hardware interface and the client controller, enabling the client controller to access data from the corresponding target vehicle-mounted device through the target hardware interface. By using a static configuration table, each vehicle-mounted device is paired with each hardware interface, generating hardware peripheral configuration information. When a data access request is received from the client controller, the corresponding target hardware interface is determined, and an access service is established between the target hardware interface and the client controller. This allows the client controller to access data from the corresponding target vehicle-mounted device through the target hardware interface. By combining static configuration and dynamic matching, a high degree of compatibility between the vehicle controller and the client controller is achieved. This avoids the need to decouple the functional software and hardware platform due to switching hardware platforms, significantly improving data access efficiency while further reducing production costs.

[0047] 2. This invention also provides a vehicle-mounted device control method applied to a client controller. By sending a data access request to the vehicle controller, the vehicle controller determines the target hardware interface corresponding to the data access request based on the data access request and hardware peripheral configuration information. An access service is established between the target hardware interface and the client controller. The hardware peripheral configuration information characterizes the pairing results between each vehicle-mounted device and each hardware interface of the vehicle controller. Data access is then performed on the corresponding target vehicle-mounted device through the target hardware interface. By determining the target hardware interface corresponding to the data access request based on the data access request and hardware peripheral configuration information, access services to the target vehicle-mounted device can be performed after the access service between the target hardware interface and the client controller is completed. This significantly shortens the decoupling time between the functional software and the hardware platform, improving data access efficiency while further reducing production costs.

[0048] 3. The present invention also provides an in-vehicle equipment control system, including a vehicle-side controller and several client controllers. The vehicle-side controller is used to acquire a static configuration table for each in-vehicle device, the static configuration table including parameter information of the hardware interfaces adapted to the in-vehicle devices; based on the static configuration table, it pairs each in-vehicle device with each hardware interface of the vehicle-side controller; and generates hardware peripheral configuration information based on the pairing results. The client controllers are used to send data access requests to the vehicle-side controller; when receiving a data access request from a client controller, the vehicle-side controller is used to determine the target hardware interface corresponding to the data access request based on the data access request and the hardware peripheral configuration information; and establish an access service between the target hardware interface and the client controllers; the client controllers are used to access data from the corresponding in-vehicle devices through the target hardware interface. The vehicle-side controller uses a static configuration table to pair each on-board device with each hardware interface and generates hardware peripheral configuration information. When it receives a data access request from the client controller, it determines the corresponding target hardware interface and establishes an access service between the target hardware interface and the client controller. The client controller, based on the data access request and the hardware peripheral configuration information, determines the target hardware interface corresponding to the data access request. After completing the access service between the target hardware interface and the client controller, it can then access the target on-board device. By combining static configuration and dynamic matching, a high degree of compatibility between the vehicle-side controller and the client controller is achieved, avoiding the need to decouple the functional software and hardware platform due to switching hardware platforms. This significantly improves data access efficiency while further reducing production costs. Attached Figure Description

[0049] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0050] Figure 1 This is a schematic diagram of the vehicle-mounted equipment control system according to an embodiment of the present invention;

[0051] Figure 2 This is a schematic diagram of the interaction process of the vehicle-mounted equipment control method according to an embodiment of the present invention;

[0052] Figure 3 This is a schematic diagram of the framework of the computing platform access mechanism table in an embodiment of the present invention;

[0053] Figure 4 This is a schematic diagram of the CPU hardware abstraction layer matching process according to an embodiment of the present invention. Detailed Implementation

[0054] The technical solution of the present invention will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0055] In the description of this invention, it should be noted that the terms "center", "upper", "lower", "left", "right", "vertical", "horizontal", "inner", "outer", etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are only for the convenience of describing this invention and simplifying the description, and do not indicate or imply that the system or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on this invention.

[0056] In the description of this invention, it should be noted that, unless otherwise explicitly specified and limited, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; they can also refer to the internal connection of two components; and they can refer to a wireless connection or a wired connection. Those skilled in the art can understand the specific meaning of the above terms in this invention based on the specific circumstances.

[0057] Furthermore, the technical features involved in the different embodiments of the present invention described below can be combined with each other as long as they do not conflict with each other.

[0058] The Poseidon computing platform is positioned as a domain controller for L2+ and above intelligent driving specifically for construction machinery. The software design goal of the Poseidon computing platform is Service-Oriented Architecture (SOA), with a single software package supporting the smooth evolution of L2+ and above functionalities. The Poseidon platform's hardware solution supports interface expansion; upper-layer software development needs to be unaware of the underlying hardware, and the platform's functional software needs to be adapted and generalized according to the usage scenarios of construction machinery vehicles.

[0059] Currently, there is no mature mass-production solution for L2+ intelligent driving domain controllers in the domestic construction machinery field, and there is no unified standard in the industry. The functional software and hardware platform are not decoupled, thus the following problems exist:

[0060] Hardware platforms and functional software are typically provided by different vendors. Vendors of functional software need to spend considerable time familiarizing themselves with the hardware platform, and the resulting software cannot be directly migrated to other hardware platforms. If a hardware platform switch is necessary due to chip shortages or other reasons, the functional software needs to be adapted and redeveloped for the new platform, requiring renewed investment in time and cost.

[0061] Outside of the engineering machinery field, while the AUTOSAR AP and QNX architectures also involve concepts related to hardware abstraction, their main drawbacks are: QNX adopts a UNIX-like concept, using a "everything is a file" hardware driver approach, without concrete encapsulation of various sensors. Sensor access is not redesigned for different hardware platforms, and it cannot be effectively replicated, transferred, or generalized. While AUTOSAR AP incorporates the concept of sensor abstraction, its application scenarios are too complex, and it lacks simplification and tailoring for specific engineering machinery scenarios.

[0062] To address the shortcomings of existing technologies, this invention proposes a vehicle-mounted device control method and system, which designs a hardware abstraction layer for a general-purpose multi-core heterogeneous SoC platform. The hardware abstraction layer design is divided into two phases: a configuration phase and a runtime phase. In the configuration phase, users can define their own interfaces, facilitating flexible and static parameter adjustments and interface design for corresponding peripherals. The configuration phase is uniformly scheduled by the abstraction layer manager within the hardware abstraction layer, and the parameters of hardware peripherals can be dynamically adjusted according to user needs. Furthermore, the abstraction layer manager can perform hardware virtualization of hardware peripherals based on a client / server architecture, enabling seamless user access across any operating system and kernel.

[0063] This invention provides a vehicle-mounted equipment control system, such as... Figure 1 As shown, the vehicle-mounted equipment control system includes: a vehicle-side controller 1 and several client-side controllers 2.

[0064] The vehicle-side controller 1 is used to obtain the static configuration table of each vehicle-mounted device. The static configuration table includes the parameter information of the hardware interface adapted to the vehicle-mounted device. Based on the static configuration table, each vehicle-mounted device is paired with each hardware interface of the vehicle-side controller 1. Based on the pairing results, hardware peripheral configuration information is generated.

[0065] Client controller 2 is used to send data access requests to vehicle controller 1;

[0066] When the vehicle-side controller 1 receives a data access request sent by the client controller 2, it determines the target hardware interface corresponding to the data access request based on the data access request and the hardware peripheral configuration information; and establishes an access service between the target hardware interface and the client controller 2.

[0067] Client controller 2 is used to access data from the corresponding vehicle-mounted equipment through the target hardware interface.

[0068] Specifically, in practical applications, this invention uses a multi-core heterogeneous system-on-chip (SoC) for a general hardware abstraction layer design, dividing the hardware abstraction layer into three sub-layers: an interface sub-layer, an abstraction layer management sub-layer, and a device service sub-layer. The interface sub-layer primarily shields the differences in device driver interfaces between different operating systems; the abstraction management sub-layer performs hardware encapsulation for different hardware peripherals; and the device service sub-layer provides the user interface. The specific execution strategy is as follows:

[0069] (1) Configuration phase

[0070] Configuration work is typically performed before the vehicle computing platform runs. This mainly involves defining and configuring the interfaces of the vehicle computing platform's hardware to determine the access relationship between the vehicle-side controller 1 and the SoC in each vehicle device. Each vehicle device can be located in a different SoC. The vehicle device includes sensors and actuators (i.e., vehicle-side controller 1). Sensors refer to cameras, lidar, millimeter-wave radar, ultrasonic radar, gyroscopes, wheel speed encoders, differential positioning devices, etc.; actuators refer to drive-by-wire devices, steering-by-wire devices, suspension-by-wire devices, brake-by-wire devices, etc.

[0071] Taking LiDAR as an example, the configuration phase mainly defines its transmission interface (which Ethernet port to use), IP address, port, and other hardware-related configurations. It also requires configuring the LiDAR to run on which CPU within which domain, and which CPUs can share access to it (i.e., creating an access mechanism table). By configuring the LiDAR hardware and completing the peripheral information, a preliminary data and hardware foundation is laid for subsequent registration of peripheral interfaces using different communication methods based on the location information of vehicle controller 1 and client controller 2. Vehicle controller 1 and client controller 2 can reside on different CPUs or on the same CPU.

[0072] (2) Operation phase

[0073] Typically, the vehicle computing platform starts up and runs, finds and adapts to different hardware interfaces (i.e. hardware peripherals), and registers the corresponding access services according to the pre-configured shared access mechanism to achieve shared access.

[0074] This invention achieves plug-and-play peripheral matching by configuring all hardware peripherals during the configuration phase, enabling hardware interface matching at system startup. Furthermore, a monitoring process resides within the system to monitor newly connected hardware peripherals.

[0075] For a further description of the above-described vehicle-mounted equipment control system, please refer to the relevant description of the following embodiments of the vehicle-mounted equipment control method, which will not be repeated here.

[0076] Through the collaborative operation of the aforementioned components, the vehicle-mounted equipment control system provided in this embodiment of the invention, via vehicle controller 1, pairs each vehicle-mounted device with each hardware interface according to a static configuration table and generates hardware peripheral configuration information. When a data access request is received from client controller 2, the corresponding target hardware interface is determined and an access service is established between the target hardware interface and client controller 2. Client controller 2, based on the data access request and hardware peripheral configuration information, determines the target hardware interface corresponding to the data access request. After completing the access service between the target hardware interface and client controller 2, it can then provide access services to the target vehicle-mounted device. By combining static configuration and dynamic matching, a high degree of compatibility is achieved between vehicle controller 1 and client controller 2, avoiding the need to re-decouple the functional software and hardware platform due to switching hardware platforms. This significantly improves data access efficiency while further reducing production costs.

[0077] This invention provides a method for controlling vehicle-mounted equipment, which is applied to, for example... Figure 1 The vehicle-side controller 1 shown herein, wherein, as Figure 2 As shown, the specific steps include the following:

[0078] Step S11: Obtain the static configuration table of each vehicle-mounted device. The static configuration table includes parameter information of the hardware interfaces adapted to the vehicle-mounted devices.

[0079] Step S12: Based on the static configuration table, pair each on-board device with each hardware interface of the vehicle controller.

[0080] Step S13: Generate hardware peripheral configuration information based on the pairing results.

[0081] Specifically, in practical applications, the hardware peripheral configuration information includes basic information about the LiDAR, such as which core of the SoC it is connected to, its IP address, and the access port. Establishing this hardware peripheral configuration information lays the foundation for subsequent access method selection. For example, if the program runs on the currently deployed kernel, the client controller can directly access it through the hardware interface; if it runs on a different kernel, the client controller can access the LiDAR through inter-core communication, ultimately achieving the acquisition of peripheral signals.

[0082] Step S14: Upon receiving a data access request from the client controller, determine the target hardware interface corresponding to the data access request based on the data access request and the hardware peripheral configuration information.

[0083] Step S15: Establish an access service between the target hardware interface and the client controller, so that the client controller can access data from the corresponding target vehicle device through the target hardware interface.

[0084] Taking LiDAR as an example, the static configuration table of LiDAR during the configuration phase is shown in Table 1. During the operation phase, the vehicle-side controller processes the following:

[0085] (1) After the main control CPU corresponding to the vehicle controller starts up, it first reads the static configuration table of the LiDAR and reads the hardware interface used by the LiDAR. Then, according to the hardware peripheral configuration information of the static configuration table, it matches the accessed LiDAR and finally identifies the corresponding model of LiDAR.

[0086] (2) After the main control CPU identifies the corresponding LiDAR model, it reads the access mechanism table, determines the client CPU corresponding to the client controller that can be accessed, and establishes an access service so that the client CPU can register the corresponding LiDAR peripheral and thus access it.

[0087] Specifically, in practical applications, the hardware interface can be ETH0, but the actual situation is not limited to this. The type of hardware interface can be changed according to actual needs.

[0088] Table 1 Static Configuration of LiDAR

[0089]

[0090]

[0091] By performing the above steps, the vehicle-mounted device control method provided in this embodiment of the invention pairs each vehicle-mounted device with each hardware interface through a static configuration table and generates hardware peripheral configuration information. When a data access request is received from the client controller, the corresponding target hardware interface is determined and an access service between the target hardware interface and the client controller is established, thereby enabling the client controller to access data from the corresponding target vehicle-mounted device through the target hardware interface. By combining static configuration and dynamic matching, a high degree of adaptation between the vehicle controller and the client controller is achieved, avoiding the need to re-decouple the functional software and hardware platform due to switching hardware platforms. This significantly improves data access efficiency while further reducing production costs.

[0092] Specifically, in one embodiment, after performing step S15 to establish the access service between the target hardware interface and the client controller, the following steps are further included:

[0093] Step S101: Lock the target hardware interface to prevent other client controllers from accessing data through the target hardware interface.

[0094] Specifically, in practical applications, if ETH0 has already been accessed, other CPUs will not be able to directly access the ETH0 interface.

[0095] Specifically, in one embodiment, step S14 above determines the target hardware interface corresponding to the data access request based on the client controller request and hardware peripheral configuration information, and specifically includes the following steps:

[0096] Step S111: Based on the data access request and hardware peripheral configuration information, determine the alternative hardware interface corresponding to each alternative vehicle-mounted device.

[0097] Step S112: Obtain the access mechanism table corresponding to each hardware interface. The access mechanism table stores the client controller type requirements corresponding to each hardware interface.

[0098] Step S113: Based on the client controller, determine the target hardware interface that conforms to the access mechanism table from the candidate hardware interfaces.

[0099] Specifically, in practical applications, to avoid a significant increase in chip development costs and time consumption due to the decoupling between functional software and hardware platforms, this embodiment of the invention establishes a shared data table called an access mechanism table. This allows the vehicle-side controller and the client-side controller to determine the target hardware interface by reading the same access mechanism table and to access data based on the target hardware interface, thereby significantly improving data access efficiency.

[0100] like Figure 3 As shown in the diagram, each node represents a minimal, independently executable program in the system, through which a relatively independent application can run. The access mechanism table indicates which kernel the current node is located on, and determines how to access it using common transmission protocols, such as PCIe / ETH.

[0101] Specifically, in one embodiment, step S111 above determines the target hardware interface corresponding to the data access request based on the client controller request and hardware peripheral configuration information, specifically including the following steps:

[0102] Step S121: Extract the target peripheral parameter requirements of the data access object from the data access request.

[0103] Step S122: Determine whether the peripheral parameters of the current vehicle device are consistent with the target peripheral parameter requirements.

[0104] Step S123: When the peripheral parameters of the current vehicle device are consistent with the requirements of the target peripheral parameters, the current vehicle device is determined as the candidate vehicle device, and the hardware interface corresponding to the current vehicle device is determined as the target hardware interface.

[0105] Specifically, in practical applications, embodiments of the present invention will determine the target peripheral parameters of the data access object based on the data access request. By judging whether the peripheral parameters of the current vehicle device are consistent with the target peripheral parameter requirements, when the peripheral parameters of the current vehicle device are consistent with the target peripheral parameter requirements, the current vehicle device is determined as a candidate vehicle device, and the hardware interface corresponding to the current vehicle device is determined as the target hardware interface, so that the data in the vehicle device meets the access requirements of the application program or other third-party programs corresponding to the client controller.

[0106] Specifically, in one embodiment, the method further includes the following steps:

[0107] Step S141: Obtain the occupancy status of the vehicle-mounted equipment corresponding to each target hardware interface.

[0108] Step S142: Based on the occupancy status of each vehicle-mounted device, select the vehicle-mounted device with the least occupancy as the target vehicle-mounted device.

[0109] Step S143: Determine the target hardware interface corresponding to the target vehicle device as the final target hardware interface.

[0110] Specifically, in practical applications, in response to the possibility of in-vehicle devices consuming excessive CPU memory, this embodiment of the invention will sort the in-vehicle devices according to their CPU memory usage, identify the in-vehicle device that occupies the least CPU as the target in-vehicle device, and identify its corresponding target hardware interface as the final target hardware interface, thereby further improving the data acquisition speed.

[0111] Specifically, in one embodiment, the method further includes the following steps:

[0112] Step S144: Send the target hardware interface and its corresponding target vehicle device to the client controller, so that the client controller sends a registration request for the target hardware interface to the vehicle controller based on the target hardware interface and the target vehicle device.

[0113] Step S145: Upon receiving a registration request from the client controller, establish an access service between the target hardware interface and the client controller based on the registration request.

[0114] Specifically, in practical applications, when the main control CPU identifies the corresponding LiDAR model, it will read the access mechanism table and determine the client CPU that can access it. Once the corresponding client CPU is determined, the access service will be established, allowing the client CPU to register the corresponding LiDAR peripheral and thus access the data.

[0115] This invention also provides a method for controlling vehicle-mounted equipment, which is applied to, for example... Figure 1 The client controller 2 shown is as follows, where, for example Figure 2 As shown, the specific steps include the following:

[0116] Step S21: Send a data access request to the vehicle controller so that the vehicle controller can determine the target hardware interface corresponding to the data access request based on the data access request and hardware peripheral configuration information; establish an access service between the target hardware interface and the client controller. The hardware peripheral configuration information is used to characterize the pairing results between each on-board device and each hardware interface of the vehicle controller. In practical applications, when the application initiates a data access request, the client controller will send a data access request to the vehicle controller.

[0117] Step S22: Access data from the corresponding target vehicle-mounted device through the target hardware interface. For details, please refer to the relevant descriptions in the above-described vehicle-mounted device control system embodiment, which will not be repeated here.

[0118] By performing the above steps, the vehicle-mounted device control method provided in this embodiment of the invention determines the target hardware interface corresponding to the data access request based on the data access request and hardware peripheral configuration information. After completing the access service between the target hardware interface and the client controller, the access service to the target vehicle-mounted device can be performed, which greatly shortens the decoupling time between the functional software and the hardware platform, improves data access efficiency, and further reduces production cost investment.

[0119] Specifically, in one embodiment, after performing step S21 to send a data access request to the vehicle controller, the following steps are further included:

[0120] Step S201: Receive the target hardware interface and its corresponding target vehicle device sent by the vehicle controller.

[0121] Step S202: Send a registration request to the vehicle controller based on the target hardware interface and the target vehicle device, so that the vehicle controller can establish an access service between the target hardware interface and the client controller according to the registration request.

[0122] Specifically, in practical applications, once the target hardware interface and the target vehicle-mounted device are determined, the client controller will initiate a registration request to the vehicle controller, laying the foundation for subsequent data access.

[0123] Specifically, in one embodiment, step S202, which involves sending a registration request to the vehicle controller based on the target hardware interface and the target vehicle device, further includes the following steps:

[0124] Step S211: Determine the address information of the vehicle-side controller based on the hardware peripheral configuration information corresponding to the target hardware interface.

[0125] Step S212: Based on the address information of the vehicle controller and the client controller, determine whether the vehicle controller and the client controller are located on the same chip.

[0126] Step S213: When the vehicle controller and the client controller are located on the same chip, a registration request is sent to the vehicle controller using inter-core communication.

[0127] Step S214: When the vehicle controller and the client controller are not located on the same chip, a registration request is sent to the vehicle controller using an external communication method.

[0128] Specifically, in practical applications, considering that the vehicle-side controller and the client-side controller may not be located on the same chip, i.e., there is a situation of heterogeneous core communication, the embodiments of the present invention will adopt different communication registration methods according to the location of the two, so as to successfully complete the peripheral interface registration request.

[0129] Specifically, when the peripheral device to be accessed and the client controller are within the same SoC, i.e., when there are multiple cores within a single SoC, inter-core communication is used, and subsequent data can be transmitted directly using methods such as shared memory; when the peripheral device and client controller to be accessed are not within the same SoC, inter-core communication is used, and subsequent data can be transmitted via methods such as Ethernet.

[0130] During the runtime phase, the specific processing procedure of the client CPU is as follows:

[0131] After the client CPU identifies the corresponding LiDAR model, it reads the access mechanism table and registers the corresponding LiDAR interface through inter-core communication / external core communication to access its data.

[0132] When a node accesses a specific device, it calls the corresponding interface. The interface reads the access mechanism table, which contains the basic configuration information of the hardware peripheral, such as which chip (SoC) the peripheral is on and which peripheral is being used. After all the information is read, the node calls the underlying communication protocol, such as TCP / IP (i.e., ETH communication), shared memory, and other related interfaces to access the corresponding peripheral, thus ultimately achieving peripheral access.

[0133] This invention can determine the access mechanism based on software requirements, including application characteristics and related customer needs. For example, such as... Figure 3 As shown, since CPU1 is under too high a load and cannot directly access the API in CPU1, SoC CPU2 is configured to access it indirectly by accessing the API in CPU2.

[0134] This invention, by fully considering specific application scenarios before operation, deploys hardware under different peripherals and statically writes this information into a static configuration table. Subsequently, when the client controller's peripherals access the corresponding peripherals after system operation, the node calls the relevant hardware abstraction layer interface. The interface reads the access mechanism table to determine a series of relevant parameters, such as the "location" of the hardware interface peripheral, and ultimately accesses the corresponding vehicle-mounted device data. This combination of static configuration and dynamic matching achieves efficient data access while significantly saving CPU time and space consumption, offering greater practicality compared to the dynamically set matching parameters of AUTOSAR AP. Furthermore, this invention establishes an access mechanism table and constructs a multi-CPU hardware peripheral sharing mechanism. Based on the locations of the vehicle controller and client controller, it uses inter-core / external core communication methods to complete peripheral interface registration, thereby freeing data transmission from location data limitations and significantly improving data transmission efficiency.

[0135] The following will provide a detailed description of the vehicle-mounted equipment control method provided in the embodiments of the present invention, with reference to specific application examples.

[0136] Combination Figures 1-4 As shown, after reading the access mechanism table, the first step is to determine whether the current CPU is the corresponding peripheral master CPU.

[0137] When it is the master CPU, it reads the hardware peripheral configuration information from the static configuration table and starts the corresponding hardware interface. After confirming that the registration request sent by the client controller has been accepted, it searches for the corresponding peripheral (i.e., the target hardware interface). When the peripheral is online, it further sets the peripheral parameters according to the access request of the client controller and starts the peripheral interface service based on the updated peripheral parameters. When the peripheral is offline, it needs to return to the peripheral judgment step until the configuration with the corresponding peripheral is successful.

[0138] When it is a client CPU, it sends a registration request to the host CPU to register the peripheral interface service. Then it checks whether the registration is successful. If the registration is successful, it can stop and data transmission and access will proceed. If the registration fails, it needs to send a registration request to the host CPU again.

[0139] To address the shortcomings of existing technologies, this invention divides the hardware abstraction layer into two phases: a configuration phase and an operation phase. In the configuration phase, users can define their own interfaces, allowing for convenient and flexible static parameter adjustments and interface design for corresponding peripherals. In the operation phase, the abstraction layer manager within the hardware abstraction layer handles unified scheduling and can dynamically adjust the parameters of hardware peripherals as needed. Furthermore, the abstraction layer manager can perform hardware virtualization of hardware peripherals based on a client / server architecture, enabling seamless user access across any operating system and kernel.

[0140] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The implemented program can be stored in a computer-readable storage medium. When the program is executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), random access memory (RAM), flash memory, hard disk drive (HDD), or solid-state drive (SSD), etc.; the storage medium can also include combinations of the above types of memory.

[0141] Obviously, the above embodiments are merely illustrative examples for clear explanation and are not intended to limit the implementation. Those skilled in the art will recognize that other variations or modifications can be made based on the above description. It is neither necessary nor possible to exhaustively list all possible implementations here. However, obvious variations or modifications derived therefrom are still within the scope of protection of this invention.

Claims

1. A method for controlling vehicle-mounted equipment, applied to a vehicle-side controller, characterized in that, include: Obtain the static configuration table of each vehicle-mounted device, wherein the static configuration table includes parameter information of the hardware interface adapted to the vehicle-mounted device; Based on the static configuration table, each on-board device is paired with each hardware interface of the vehicle controller. Based on the pairing results, hardware peripheral configuration information is generated, which includes: basic information of each vehicle device, including which core of which SoC the vehicle device is connected to, its IP address information, and the access port; Upon receiving a data access request from the client controller, the target hardware interface corresponding to the data access request is determined based on the data access request and the hardware peripheral configuration information. An access service is established between the target hardware interface and the client controller, so that the client controller can access data from the corresponding target vehicle device through the target hardware interface.

2. The method according to claim 1, characterized in that, The step of determining the target hardware interface corresponding to the data access request based on the client controller request and the hardware peripheral configuration information includes: Based on the data access request and the hardware peripheral configuration information, determine the alternative hardware interfaces corresponding to each alternative vehicle-mounted device. Obtain the access mechanism table corresponding to each hardware interface, wherein the access mechanism table stores the client controller type requirements corresponding to each hardware interface; Based on the client controller, a target hardware interface that conforms to the access mechanism table is determined from each candidate hardware interface.

3. The method according to claim 2, characterized in that, The step of determining the target hardware interface corresponding to the data access request based on the client controller request and the hardware peripheral configuration information further includes: Obtain the occupancy status of the vehicle-mounted devices corresponding to each target hardware interface; Based on the occupancy status of each vehicle-mounted device, the vehicle-mounted device with the least occupancy is selected as the target vehicle-mounted device. The target hardware interface corresponding to the target vehicle-mounted device is determined as the final target hardware interface.

4. The method according to claim 3, characterized in that, The method further includes: The target hardware interface and its corresponding target vehicle device are sent to the client controller, so that the client controller sends a registration request for the target hardware interface to the vehicle controller based on the target hardware interface and the target vehicle device; Upon receiving a registration request from the client controller, an access service is established between the target hardware interface and the client controller based on the registration request.

5. The method according to claim 2, characterized in that, The step of determining the alternative hardware interfaces corresponding to each alternative vehicle-mounted device based on the data access request and the hardware peripheral configuration information includes: Extract the target peripheral parameter requirements of the data access object from the data access request; Determine whether the peripheral parameters of the current vehicle-mounted device are consistent with the target peripheral parameter requirements; When the peripheral parameters of the current vehicle device are consistent with the target peripheral parameter requirements, the current vehicle device is determined as a candidate vehicle device, and the hardware interface corresponding to the current vehicle device is determined as the target hardware interface.

6. The method according to claim 1, characterized in that, After establishing the access service between the target hardware interface and the client controller, the method further includes: The target hardware interface is locked to prevent other client controllers from accessing data through the target hardware interface.

7. A method for controlling an on-board device, applied to a client controller, characterized in that, include: A data access request is sent to the vehicle controller, so that the vehicle controller determines the target hardware interface corresponding to the data access request based on the data access request and hardware peripheral configuration information; and an access service is established between the target hardware interface and the client controller. The hardware peripheral configuration information is obtained by the vehicle controller through the static configuration table of each vehicle device. The static configuration table includes the parameter information of the hardware interface adapted to the vehicle device. Based on the static configuration table, each on-board device is paired with each hardware interface of the vehicle controller. Hardware peripheral configuration information generated based on the pairing results; The hardware peripheral configuration information includes: basic information of each vehicle device, including which core of which SoC the vehicle device is connected to, its IP address information, and the port it accesses; Data can be accessed from the corresponding target vehicle-mounted device through the target hardware interface.

8. The method according to claim 7, characterized in that, After sending a data access request to the vehicle-side controller, the method further includes: Receive the target hardware interface and its corresponding target vehicle-mounted equipment sent by the vehicle-side controller; Based on the target hardware interface and the target vehicle device, a registration request is sent to the vehicle controller, so that the vehicle controller can establish an access service between the target hardware interface and the client controller according to the registration request.

9. The method according to claim 8, characterized in that, The step of sending a registration request to the vehicle controller based on the target hardware interface and the target vehicle device includes: Based on the hardware peripheral configuration information corresponding to the target hardware interface, the address information of the vehicle-side controller is determined; Based on the address information of the vehicle controller and the address information of the client controller, determine whether the vehicle controller and the client controller are located on the same chip; When the vehicle-side controller and the client-side controller are located on the same chip, a registration request is sent to the vehicle-side controller using inter-core communication. When the vehicle-side controller and the client-side controller are not located on the same chip, a registration request is sent to the vehicle-side controller using an external communication method.

10. A vehicle-mounted equipment control system, characterized in that, include: Vehicle-side controller and several client-side controllers, The vehicle-side controller is used to obtain the static configuration table of each vehicle-mounted device, which includes parameter information of the hardware interfaces adapted to the vehicle-mounted devices; based on the static configuration table, each vehicle-mounted device is paired with each hardware interface of the vehicle-side controller. Based on the pairing results, hardware peripheral configuration information is generated, which includes: basic information of each vehicle device, including which core of which SoC the vehicle device is connected to, its IP address information, and the access port; The client controller is used to send data access requests to the vehicle controller; When the vehicle-side controller receives a data access request from the client controller, it determines the target hardware interface corresponding to the data access request based on the data access request and the hardware peripheral configuration information; and establishes an access service between the target hardware interface and the client controller. The client controller is used to access data from the corresponding vehicle-mounted equipment through the target hardware interface.

Images