A sensor management method, device, vehicle and storage medium

Abstract

This application discloses a sensor management method, apparatus, vehicle, and storage medium, relating to the field of vehicle technology. The sensor management method is applied to a vehicle equipped with a data abstraction framework (DAB). The method includes: calling the DAB to read vehicle configuration information, which includes information about target sensors configured on the vehicle; traversing a plugin registry maintained by the DAB based on the target sensor information to determine target plugin information matching the target sensor; wherein the plugin registry includes information about multiple sensor plugins already registered with the DAB; and running the target plugin information to process the sensor data reported by the target sensor. In this application embodiment, each vehicle's DAB selects and runs the appropriate target sensor plugin information based on the vehicle configuration information, effectively avoiding configuration errors and achieving unified management of sensors.

Description

Technical Field

[0001] This application relates to the field of vehicle technology, specifically to a sensor management method, device, vehicle, and storage medium. Background Technology

[0002] With the iterative updates of intelligent driving technology, more and more vehicles are equipped with driver assistance systems. These systems typically rely on sensor data to make driving decisions, so intelligent driving vehicles usually need to deploy a variety of sensors.

[0003] When deploying multiple sensors on an intelligent driving vehicle, it is necessary to install sensor hardware components and configure operating programs for the sensor hardware components. The sensor data collected by the sensor hardware components is processed by running the corresponding operating programs.

[0004] With the diversification of intelligent driving vehicle platforms and models, as well as the diversification of sensors, traditional sensor management methods are no longer applicable. Summary of the Invention

[0005] This application provides a sensor management method, device, vehicle, and storage medium that can manage multiple sensors in a unified manner, avoiding the problem of chaotic sensor configuration.

[0006] The technical solution of this application is implemented as follows: In a first aspect, embodiments of this application provide a sensor management method applied to a vehicle, wherein the vehicle is equipped with a data abstraction framework, the method comprising: The data abstraction framework is invoked to read vehicle configuration information, which includes information about the target sensors configured on the vehicle. Based on the information of the target sensor, the plugin registry maintained by the data abstraction framework is traversed to determine the target plugin information that matches the target sensor; the plugin registry includes information on multiple sensor plugins that have already been registered with the data abstraction framework. The target plugin processes the sensor data reported by the target sensor.

[0007] In one embodiment, the method further includes: Obtain the sensor configuration file, which includes sensor plugins for different platforms and vehicle models; Obtain the plugin identifier and factory class information from each sensor plugin; Each sensor plugin is registered in the plugin registry within the data abstraction framework based on its plugin identifier and factory class information.

[0008] In one embodiment, the method further includes: Receive updated sensor profiles; Retrieve new sensor plugins from the updated sensor configuration file and register them in the plugin registry.

[0009] In one embodiment, the method further includes: Obtain a vehicle configuration information change request, which includes information about newly configured sensors on the vehicle; The plugin registry is traversed based on the information of the newly configured sensors; If the sensor plugin information corresponding to the newly configured sensor exists in the plugin registry, generate a request for license information; If the sensor plugin information corresponding to the newly configured sensor does not exist in the plugin registry, a message prohibiting changes will be generated.

[0010] In one embodiment, the method further includes: If the sensor plugin information corresponding to the newly configured sensor does not exist in the plugin registry, a sensor plugin request is sent to the cloud; the sensor plugin request includes the information of the newly configured sensor. Receive feedback messages from the cloud. If the feedback message contains sensor plugin information corresponding to the newly configured sensor, generate a request for permission. If the feedback message does not contain sensor plugin information corresponding to the newly configured sensor, generate a prohibition on change message.

[0011] In one embodiment, the method further includes: Obtain the first management instruction, which includes information about the first sensor plugin, which is the sensor plugin to be deleted; In response to the first management command, the first sensor plugin is removed from memory and its registration information is removed from the plugin registry.

[0012] In one embodiment, the plugin registry includes a first registry and a second registry, wherein the plugin identifier in the first registry is the plugin name, and the plugin identifier in the second registry is the plugin identification code.

[0013] Secondly, embodiments of this application provide a sensor management device applied to a vehicle, the vehicle being equipped with a data abstraction framework, the device comprising: The reading module is used to call the data abstraction framework to read vehicle configuration information, which includes information about the target sensors configured on the vehicle. The processing module is used to traverse the plugin registry maintained by the data abstraction framework based on the information of the target sensor to determine the target plugin information that matches the target sensor. The plugin registry includes information on multiple sensor plugins that have been registered with the data abstraction framework. The module then processes the sensor data reported by the target sensor using the target plugin information.

[0014] Thirdly, embodiments of this application provide a vehicle including a processor and a memory, the memory storing a program or instructions that can run on the processor, the program or instructions being executed by the processor to implement the steps of the sensor management method as described in any of the first aspects above.

[0015] Fourthly, embodiments of this application provide a computer-readable storage medium, characterized in that a computer program or computer-executable instructions are stored on the computer-readable storage medium, and when the computer program or computer-executable instructions are executed by a processor, the steps of the sensor management method as described in any of the first aspects above are implemented.

[0016] It should be understood that the above general description and the following detailed description are illustrative and explanatory only, and are not intended to limit the technical solutions of this application. Attached Figure Description

[0017] Figure 1 This is a schematic diagram of a data abstraction framework provided in an embodiment of this application; Figure 2 This is a flowchart illustrating a sensor management method provided in an embodiment of this application. Figure 1 ; Figure 3 This is a flowchart illustrating a sensor management method provided in an embodiment of this application. Figure 2 ; Figure 4 This is a flowchart illustrating a sensor management method provided in an embodiment of this application. Figure 3 ; Figure 5 This is a flowchart illustrating a sensor management method provided in an embodiment of this application. Figure 4 ; Figure 6 This is a flowchart illustrating a sensor management method provided in an embodiment of this application. Figure 5 ; Figure 7 This is a logic block diagram of a sensor management device provided in an embodiment of this application; Figure 8 This is a schematic diagram of the hardware structure of a vehicle provided in an embodiment of this application. Detailed Implementation

[0018] In order to gain a more detailed understanding of the features and technical content of the embodiments of this application, the implementation of the embodiments of this application will be described in detail below with reference to the accompanying drawings. The accompanying drawings are for reference and illustration only and are not intended to limit the embodiments of this application.

[0019] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0020] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0021] It should also be noted that the terms "first, second, and third" used in the embodiments of this application are only used to distinguish similar objects and do not represent a specific order of objects. It is understood that "first, second, and third" can be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0022] Furthermore, the reference to "embodiment" herein means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0023] With the iterative updates of intelligent driving technology, more and more vehicles are equipped with driver assistance systems. These systems typically rely on sensor data to make driving decisions, so intelligent driving vehicles usually need to deploy a variety of sensors.

[0024] When deploying multiple sensors on an intelligent driving vehicle, it is necessary to install sensor hardware components and configure operating programs for the sensor hardware components. The sensor data collected by the sensor hardware components is processed by running the corresponding operating programs.

[0025] Currently, there are many platforms for intelligent driving vehicles, each platform supporting various vehicle models. Furthermore, each vehicle model requires a variety of sensors, and the types of sensors used differ between platforms and vehicle models. In other words, the types of sensors used vary across platforms and vehicle models. Additionally, with the diversity of sensors, the same type of sensor may have multiple models or specifications, making it difficult to deploy a wide range of sensors on intelligent driving vehicles.

[0026] In the relevant scheme, for a certain vehicle, the types of sensors configured on the vehicle are determined according to the vehicle's platform and model. Then, the model is selected according to the type of sensor, thereby determining the operating program corresponding to the final sensor hardware component.

[0027] The relevant solutions require the development and maintenance of corresponding code programs for sensor hardware components for each platform and vehicle model, which involves a huge workload. Furthermore, during centralized release, it is necessary to repeatedly check whether they match, which can easily lead to configuration confusion.

[0028] Furthermore, in the relevant solutions, the sensors installed on the vehicle are fixed at the factory and cannot be upgraded or updated. For example, as sensor technology continues to develop and innovate, when new sensors become available, it is not possible to upgrade or replace the sensors on existing vehicles.

[0029] To address this issue, this application provides a sensor management method applied to a vehicle equipped with a data abstraction framework. The method includes: calling the data abstraction framework to read vehicle configuration information, which includes information about target sensors configured on the vehicle; traversing a plugin registry maintained by the data abstraction framework based on the target sensor information to determine target plugin information matching the target sensor; wherein the plugin registry includes information about multiple sensor plugins already registered with the data abstraction framework; and running the target plugin information to process the sensor data reported by the target sensor. In this application embodiment, during the sensor configuration phase, multiple platforms and vehicle models can configure the same sensor configuration file, eliminating the need for platform / vehicle differentiation. This allows for batch processing, significantly reducing workload and effectively preventing configuration errors. During the usage phase, each vehicle's data abstraction framework selects and runs the appropriate target sensor plugin information based on its own platform and vehicle model, effectively preventing configuration errors.

[0030] The main technical concept of this solution is: for multiple sensors, the operating program of each sensor is abstractly designed as a plug-in, and different sensors are registered and loaded onto the data abstraction framework in the form of dynamic libraries, which are then uniformly managed and scheduled by the data abstraction framework.

[0031] The various embodiments of this application will now be described in detail with reference to the accompanying drawings.

[0032] The sensor management method provided in this application can be executed by a vehicle or control devices, processing devices, etc., configured in a vehicle. In this application embodiment, a data abstraction framework is configured in the vehicle, and the sensor management method provided in this application embodiment is implemented by running this data abstraction framework.

[0033] Please refer to Figure 1 , Figure 1 This is a schematic diagram of a data abstraction framework provided in an embodiment of this application. The data abstraction framework is connected to multiple target sensors on a vehicle. Figure 1 The example shown includes lidar, forward-facing millimeter-wave radar, lateral millimeter-wave radar, and ultrasonic radar. The vehicle may also have more or fewer radars, and the types of radars installed on the vehicle may also be other types.

[0034] In this embodiment, the data abstraction framework can be adapted to various types of sensors from various manufacturers, including but not limited to temperature sensors, vehicle information sensors, millimeter-wave radar, ultrasonic radar, lidar, surround-view cameras, panoramic cameras, rear-view cameras, front-view cameras, inertial navigation systems, etc. It should be noted that in this embodiment, the data abstraction framework comprehensively covers the types and models of target sensors on the vehicle.

[0035] In some embodiments, the data abstraction framework can acquire sensor plugins of various types and manufacturers, and register these sensor plugins with the data abstraction framework, enabling the data abstraction framework to manage the sensors corresponding to these sensor plugins.

[0036] In some embodiments, the data abstraction framework supports various communication interfaces to acquire sensing data from the target sensor. These communication interfaces include, but are not limited to, MIPI, LVDS, RGB, SPI, UART, CAN / CAN_FD, I2C, UDP, TCP, SomeIP, MQTT, DDS, and so on. Thus, the data abstraction framework can meet the data transmission needs of various sensors.

[0037] In this embodiment, each target sensor sends the detected sensing data to the data abstraction framework. The data abstraction framework calls the sensor plugin corresponding to the target sensor to process the corresponding sensing data. Then, the data abstraction framework can also send the processed sensor data to the vehicle control system according to a predetermined communication protocol, so that the vehicle control system can perform data fusion, environment reconstruction, prediction and planning, and issue lateral and longitudinal vehicle control commands based on the sensing data.

[0038] The embodiments of this application use a data abstraction framework to isolate the target sensors configured on the vehicle from the vehicle control system, which is beneficial for the reuse of sensor data.

[0039] Please refer to Figure 2 , Figure 2 This is a flowchart illustrating a sensor management method provided in an embodiment of this application. Figure 1 This sensor management method can be applied to sensor management systems, which include a management terminal and various vehicles. The management terminal is typically located on the vehicle manufacturer's backend equipment, which can communicate with each vehicle. Each vehicle is equipped with a data abstraction framework.

[0040] Figure 2 The example illustrates various vehicles, including an A1 model based on platform A, an A2 model based on platform A, a B0 model based on platform B, a C8 model based on platform C, and so on. The target sensors installed on these vehicles of different platforms and models are often different.

[0041] In this embodiment, the sensor management system can generate sensor configuration files through a management terminal and send these configuration files to each vehicle. The sensor configuration file includes a set of sensor plugins, which includes sensor plugins from different platforms and vehicle models.

[0042] When the same sensor is applied to different platforms and vehicle models, the sensor plugin may need to be adapted to fit the platform and vehicle model. Therefore, in this embodiment, developers can flexibly develop various sensor plugins on different vehicle models to obtain a set of sensor plugins.

[0043] In some embodiments, the sensor profile includes a set of sensor plugins, which comprises different types and specifications of sensor plugins from different manufacturers. These different types and specifications of sensor plugins from different manufacturers may be developed by the developer or obtained from the manufacturer.

[0044] It should be noted that in this embodiment, the sensor configuration files received by vehicles on different platforms and of different models are the same. In other words, during the sensor configuration phase, multiple platforms and vehicle models can be configured with the same sensor configuration file, eliminating the need for differentiation based on platform or model. This allows for batch processing, significantly reducing workload and effectively preventing configuration errors.

[0045] Among them, vehicles of different models on different platforms can register multiple sensor plugins in the sensor configuration file to the data abstraction framework after receiving the sensor configuration file.

[0046] In this embodiment, the vehicle can call the data abstraction framework to parse the sensor configuration file (such as a YAML or JSON file), read the sensor plugin's plugin identifier, factory class information, loading path, etc., and store the parsed information in the data abstraction framework's management module. Each sensor plugin is abstracted into an independent module and can be compiled into an independent dynamic library.

[0047] In this embodiment of the application, the -fPIC parameter can be used during the compilation of the dynamic library to enable the generated code to be loaded and executed at any location in memory, ensuring that the library code can run at any location in memory, thereby meeting the requirements for dynamically pluggable loading of sensors.

[0048] In this embodiment, the data abstraction framework can load the dynamic libraries compiled from sensor plugins, register the plugin identifiers and factory class information of each sensor plugin in the plugin registry within the management module, and complete the sensor plugin registration. In some embodiments, dlopen can be used to load the dynamic library into the data abstraction framework, and dlclose can be used to unload the dynamic library from the data abstraction framework.

[0049] In some embodiments, the plugin registry also includes the loading paths for each sensor plugin.

[0050] In this embodiment, the plugin registry includes a first registry and a second registry. The first registry is used to register sensor plugins by their names; therefore, the plugin identifier in the first registry is the plugin name, and the first registry includes the plugin name and factory class information. As an example, registering a sensor plugin to the first registry `module_name_map` according to its name can be represented as `std::unordered_map`.<std::string,ModuleAbstractFactoryPtr> .

[0051] The second registry is registered based on the sensor plugin's identification code (ID). Therefore, the plugin identifier in the second registry is the plugin ID, and the second registry includes the plugin ID and factory class information. As an example, registering a sensor plugin to the module_id_map according to its plugin ID can be represented as: std::unordered_map<uint32_t, ModuleAbstractFactoryPtr> .

[0052] The plugin registry map stores the ID or name of each sensor plugin, as well as sensor-related creation interfaces, such as factory class information. In this embodiment, plugin registration can be achieved regardless of whether the developer uses an ID or name to identify the sensor, without having to use a unique identifier, thus providing convenience for developers.

[0053] In this embodiment, during the sensor configuration stage, multiple platforms and vehicle models are configured with the same sensor configuration file, eliminating the need to differentiate between platforms and vehicle models. This can be done in batches, greatly reducing workload and effectively avoiding configuration errors.

[0054] In this embodiment of the application, the management terminal can also update the sensor configuration file, for example, it can delete some outdated sensor plugins, or it can add new sensor plugins.

[0055] The management system can send updated sensor configuration files in batches to vehicles across various platforms and models. Upon receiving the updated sensor configuration files, each vehicle can retrieve the newly added sensor plugins from the updated configuration files and then register the new sensor plugins in the plugin registry.

[0056] The data abstraction framework can obtain sensor identifiers, factory class information, and loading paths from newly added sensor plugins, and record these information in the plugin registry.

[0057] In this embodiment, the management terminal can send updated sensor configuration files to each vehicle based on the communication module of the backend device, enabling online modification of the sensor communication interface and expanding the communication interface. It can also change the number and type of instantiated sensors on the vehicle side; and change the topic content published and subscribed to by the sensor instances, achieving flexible and diverse configurations.

[0058] In this embodiment, when a new sensor plugin is added to the platform and / or vehicle model, it is only necessary to register the new sensor plugin in the plugin registry and modify the sensor information in the vehicle configuration information to complete the sensor plugin configuration. When the vehicle starts, the data abstraction framework can call the new sensor plugin to complete the sensor's receiving, parsing, packet assembly, and transmission processes. This achieves the effect of quickly adapting to new sensors.

[0059] Please refer to Figure 3 , Figure 3 This is a flowchart illustrating a sensor management method provided in an embodiment of this application. Figure 2 The method includes: Step 301: Call the data abstraction framework to read the vehicle configuration information.

[0060] In this embodiment of the application, when the vehicle is powered on, the data abstraction framework can be initialized. At this time, the vehicle can call the data abstraction framework to read the vehicle configuration information.

[0061] The vehicle configuration information includes information about the target sensors installed on the vehicle, including the name or ID of the target sensor.

[0062] In this embodiment, the sensors configured on the vehicle are defined as target sensors, and there are typically multiple target sensors. The vehicle configuration information includes information about the target sensors configured on the vehicle. Target sensors typically include various types of sensors, such as ultrasonic radar, lidar, and surround-view cameras. Furthermore, the vehicle may also be configured with multiple sensors of the same type but different specifications, such as 200-line lidar and 800-line lidar.

[0063] In some embodiments, vehicle configuration information may also include the vehicle platform and model. Please refer to Table 1, which exemplarily illustrates one type of vehicle configuration information.

[0064] Table 1

[0065] Table 1 shows that the a model of platform A can load and start sensor plugins for sensor1 and sensor2.

[0066] Step 302: Based on the information of the target sensor, traverse the plugin registry maintained by the data abstraction framework to determine the target plugin information that matches the target sensor.

[0067] The plugin registry includes information on multiple sensor plugins that have already been registered with the data abstraction framework.

[0068] In this embodiment, the vehicle can invoke a data abstraction framework to traverse the plugin registry in order to find the target plugin information that matches the target sensor in the plugin registry.

[0069] As mentioned above, the data abstraction framework registers plugin information for sensors corresponding to different platforms and vehicle models. In this embodiment, the vehicle can invoke the data abstraction framework to traverse the plugin registry based on the ID or name of the target sensor, thereby obtaining factory class information, loading path, etc., related to the target sensor plugin.

[0070] Step 303: Run the target plugin information processing to process the sensor data reported by the target sensor.

[0071] In this embodiment of the application, the vehicle can call the data abstraction framework to create a factory class according to the factory class information in the target plug-in information, and then create the target sensor's Recviver class, Publisher class, Decoder class, Packager class, and Message class from the factory class information.

[0072] Then, the vehicle can call the data abstraction framework to load the target sensor plugin based on the loading path, and call the control target sensor plugin to process the sensing data reported by the target sensor based on the factory class information.

[0073] The sensor management method provided in this application obtains the target sensor information from the vehicle configuration information, then determines the target plug-in information of the target sensor from the plug-in registry of the pre-registered number of the target sensor information, and processes the sensor data using the target plug-in information. In this process, each vehicle's data abstraction framework selects and runs the appropriate target plug-in information based on the target sensor configured on its own platform and vehicle model, which can effectively avoid configuration errors.

[0074] The sensor management method provided in this application allows for the flexible development and registration of various sensors and other functional plugins on different vehicle platforms. To achieve adaptability and rapid expansion across different platforms and diverse sensors, the sensor configuration file in this application includes sensor plugins designed for different platforms or vehicle models. Different sensor plugins are identified using different names or IDs. A data abstraction framework manages the sensor configuration files, registering and recording sensors based on them, thereby enabling the management of target sensors on the vehicle.

[0075] The sensor plugins in the sensor configuration file can be developed according to the architecture of different vehicle models or platforms, enabling independent development, compilation and operation of multiple sensors and functional modules. This effectively decouples the dependencies between system components and significantly improves the system's flexibility and maintainability.

[0076] In practical applications, there may be situations where users wish to upgrade the vehicle's hardware, such as upgrading the specifications of the vehicle's sensors or adding new sensors. To meet these user needs, this application also provides a sensor management method, please refer to... Figure 4 , Figure 4 This is a flowchart illustrating a sensor management method provided in an embodiment of this application. Figure 3 The method includes the following steps: Step 401: Obtain a vehicle configuration information change request.

[0077] In this embodiment of the application, when the sensors on the vehicle are changed, the information of the target sensor in the vehicle configuration information can be changed accordingly to maintain the consistency between the vehicle hardware and the vehicle configuration information.

[0078] In this embodiment, when changing vehicle configuration information, a vehicle configuration information change request can be generated. This request is used to request the vehicle to verify the legality of the change. The vehicle configuration information change request includes information about newly configured sensors on the vehicle. This information may include, for example, the name or ID of the newly configured sensor.

[0079] The newly configured sensor can either replace the existing sensor on the vehicle or be a newly installed sensor on the vehicle.

[0080] Step 402: Traverse the plugin registry based on the information of the newly configured sensors.

[0081] Step 403: If the sensor plugin information corresponding to the newly configured sensor exists in the plugin registry, generate a request for license information.

[0082] Step 404: If the sensor plugin information corresponding to the newly configured sensor does not exist in the plugin registry, generate a message prohibiting changes.

[0083] In this embodiment, the vehicle can call the data abstraction framework to obtain information about the newly configured sensors, and then search the plugin registry for a sensor plugin that matches the newly configured sensors based on the information about the newly configured sensors.

[0084] If the iteration is successful, it means that the sensor plugin information corresponding to the newly configured sensor exists in the plugin registry. In other words, the current data abstraction framework supports the newly configured sensor, and the sensor plugin corresponding to the newly configured sensor can be successfully called to process the sensor data based on the existing plugin registry. Therefore, a permission request can be generated. The permission request is used to indicate that the vehicle configuration information can be changed.

[0085] In this way, after receiving the permission request, the user can make changes such as replacing or adding sensors on the vehicle.

[0086] If the iteration fails, it means that the sensor plugin information corresponding to the newly configured sensor does not exist in the plugin registry. In other words, the current data abstraction framework does not support the newly configured sensor and cannot process the sensor data reported by the newly configured sensor. Therefore, a "prohibit change" message is generated. The "prohibit change" message is used to indicate that the vehicle does not support changes to vehicle configuration information.

[0087] After receiving a message prohibiting changes, users can determine that the newly configured sensor is not supported and then make other adjustments.

[0088] In this embodiment, the user can determine whether the newly configured sensor is supported by sending a vehicle configuration information change request. If supported, the actual change operation is then performed. If not supported, no change operation is performed. Compared to the traditional approach of changing the sensor first, then verifying its usability, and removing it if unusable, this approach improves efficiency and reduces unnecessary workload.

[0089] In practical applications, with technological advancements, some sensors may become obsolete. In such cases, if vehicle modules for these obsolete sensors are retained for an extended period, it will consume the vehicle's limited memory resources. To address this technical problem, this application also provides a sensor management method, please refer to... Figure 5 , Figure 5 This is a flowchart illustrating a sensor management method provided in an embodiment of this application. Figure 4 The method includes: Step 501: Obtain the first management instruction.

[0090] The first management instruction includes information about the first sensor plugin, which is the sensor plugin to be deleted.

[0091] In this embodiment, the first management command can be sent in batches from the management terminal in the sensor management system to vehicles on various platforms or vehicle models. The first management command is used to achieve batch management.

[0092] Step 502: In response to the first management instruction, remove the first sensor plugin from memory and remove the registration information of the first sensor plugin from the plugin registry.

[0093] After receiving the first management command, the vehicle can parse the first management command to obtain the information of the first sensor plug-in indicated by the first management command. The information of the first sensor plug-in is, for example, the name or ID of the first sensor plug-in.

[0094] The vehicle can then invoke the data abstraction framework to remove the registration information of the first sensor plugin from the plugin registry. This registration information includes the first sensor plugin's name or ID, factory class information, loading path, etc. Furthermore, the vehicle can also invoke the data abstraction framework to delete the first sensor plugin's plugin data package from memory, thus freeing up memory.

[0095] In this embodiment of the application, by removing the sensor plugins of the obsolete sensors, memory resource waste can be reduced, and the traversal time can be reduced and the response speed can be improved when the vehicle calls the data abstraction framework to traverse the plugin registry.

[0096] Based on the above embodiments, this application also provides a sensor management method, please refer to... Figure 6 , Figure 6 This is a flowchart illustrating a sensor management method provided in an embodiment of this application. Figure 5 The method includes: Step 601: Obtain a vehicle configuration information change request.

[0097] The vehicle configuration information change request includes information on newly configured sensors on the vehicle.

[0098] Step 602: Traverse the plugin registry based on the information of the newly configured sensors.

[0099] Step 603: If the sensor plugin information corresponding to the newly configured sensor exists in the plugin registry, generate a request for license information.

[0100] Step 604: If the sensor plugin information corresponding to the newly configured sensor does not exist in the plugin registry, send a sensor plugin request to the cloud.

[0101] In this embodiment, if the sensor plugin information corresponding to the newly configured sensor does not exist in the plugin registry, a sensor plugin request can be sent to the cloud. This sensor plugin request includes information about the newly configured sensor. The sensor plugin request is used to request the cloud to obtain the sensor plugin information corresponding to the newly configured sensor.

[0102] Step 605: Receive feedback messages sent from the cloud. If the feedback message contains sensor plugin information corresponding to the newly configured sensor, generate permission request information. If the feedback message does not contain sensor plugin information corresponding to the newly configured sensor, generate change prohibition information.

[0103] After receiving a sensor plugin request, the cloud can search for the sensor plugin information corresponding to the newly configured sensor in the backend database. If found, the information will be included in the feedback message; otherwise, it will indicate that the sensor plugin was not found.

[0104] The vehicle can call the data abstraction framework to parse the feedback message. If the feedback message contains sensor plugin information corresponding to the newly configured sensor, it generates a request for permission information. If the feedback message does not contain sensor plugin information corresponding to the newly configured sensor, it generates a prohibition on change information.

[0105] In cases where the feedback message contains sensor plugin information corresponding to the newly configured sensor, the vehicle also calls the data abstraction framework to register the sensor plugin information corresponding to the newly configured sensor into the plugin registry.

[0106] In this embodiment, when the vehicle calls the data abstraction framework to process the vehicle configuration information change request, if the local device does not contain the sensor plugin information corresponding to the sensor with the new configuration, the vehicle can obtain the plugin information by communicating with the manufacturer's backend. This can more flexibly and reliably meet the user's configuration update needs and expand the range of sensors supported by the vehicle.

[0107] It should be noted that although the steps of the method in this application are described in a specific order in the accompanying drawings, this does not require or imply that the steps must be performed in that specific order, or that all the steps shown must be performed to achieve the desired result. Additional or alternative steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps; or steps from different embodiments may be combined into a new technical solution.

[0108] In another embodiment of this application, a sensor management device is provided, please refer to... Figure 7 , Figure 7 This is a logical block diagram of a sensor management device provided in an embodiment of this application. The sensor management device 700 is applied to a vehicle, which is equipped with a data abstraction framework and may include: a reading module 701 and a processing module 702. Wherein: The reading module 701 is used to call the data abstraction framework to read vehicle configuration information, which includes information about the target sensors configured on the vehicle. The processing module 702 is used to traverse the plugin registry maintained by the data abstraction framework based on the information of the target sensor to determine the target plugin information that matches the target sensor; wherein, the plugin registry includes the information of multiple sensor plugins that have been registered in the data abstraction framework; and to process the sensing data reported by the target sensor using the target plugin information.

[0109] In one embodiment, the processing module 702 is further configured to: Obtain the sensor configuration file, which includes sensor plugins for different platforms and vehicle models; Obtain the plugin identifier and factory class information from each sensor plugin; Each sensor plugin is registered in the plugin registry within the data abstraction framework based on its plugin identifier and factory class information.

[0110] In one embodiment, the processing module 702 is further configured to: Receive updated sensor profiles; Retrieve new sensor plugins from the updated sensor configuration file and register them in the plugin registry.

[0111] In one embodiment, the processing module 702 is further configured to: Obtain a vehicle configuration information change request, which includes information about newly configured sensors on the vehicle; The plugin registry is traversed based on the information of the newly configured sensors; If the sensor plugin information corresponding to the newly configured sensor exists in the plugin registry, generate a request for license information; If the sensor plugin information corresponding to the newly configured sensor does not exist in the plugin registry, a message prohibiting changes will be generated.

[0112] In one embodiment, the processing module 702 is further configured to: If the sensor plugin information corresponding to the newly configured sensor does not exist in the plugin registry, a sensor plugin request is sent to the cloud; the sensor plugin request includes the information of the newly configured sensor. Receive feedback messages from the cloud. If the feedback message contains sensor plugin information corresponding to the newly configured sensor, generate a request for permission. If the feedback message does not contain sensor plugin information corresponding to the newly configured sensor, generate a prohibition on change message.

[0113] In one embodiment, the processing module 702 is further configured to: Obtain the first management instruction, which includes information about the first sensor plugin, which is the sensor plugin to be deleted; In response to the first management command, the first sensor plugin is removed from memory and its registration information is removed from the plugin registry.

[0114] In one embodiment, the plugin registry includes a first registry and a second registry, wherein the plugin identifier in the first registry is the plugin name, and the plugin identifier in the second registry is the plugin identification code.

[0115] Each module in the aforementioned sensor management device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the vehicle's processor in hardware form or independent of it, or stored in the vehicle's memory in software form, so that the processor can call and execute the corresponding operations of each module.

[0116] Please refer to Figure 8 , Figure 8 This is a schematic diagram of the hardware structure of a vehicle provided in an embodiment of this application. The vehicle may include a communication interface 801, a memory 802, and a processor 803; the various components are coupled together through a bus system 804. It is understood that the bus system 804 is used to realize the connection and communication between these components. In addition to a data bus, the bus system 804 also includes a power bus, a control bus, and a status signal bus. However, for clarity, in... Figure 8 The general labeled all buses as Bus System 804.

[0117] In this embodiment, the communication interface 801 is used to send and receive information with other external devices; the memory 802 is used to store a computer program that can run on the processor 803; the processor 803 is used to execute the steps of the sensor management method described in any of the foregoing embodiments when running the computer program.

[0118] It is understood that the memory 802 in this embodiment can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate Synchronous DRAM (DDRSDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchronous Link DRAM (SLDRAM), and Direct Rambus RAM (DRRAM). The memory 802 of the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0119] The processor 803 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of the processor 803 or by instructions in software form. The processor 803 can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly manifested as execution by a hardware decoding processor, or execution by a combination of hardware and software modules in the decoding processor. The software modules can be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory 802, and the processor 803 reads the information in memory 802 and, in conjunction with its hardware, completes the steps of the above method.

[0120] It is also understood that the embodiments described herein can be implemented in hardware, software, firmware, middleware, microcode, or a combination thereof. For hardware implementation, the processing unit can be implemented in one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), general-purpose processors, controllers, microcontrollers, microprocessors, other electronic units for performing the functions described herein, or combinations thereof.

[0121] For software implementation, the techniques described herein can be implemented through modules (e.g., procedures, functions, etc.) that perform the functions described herein. Software code can be stored in memory and executed by a processor. The memory can be implemented in the processor or externally. Wherein, if implemented as a software functional module and not sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute all or part of the steps of the methods described in the embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0122] In another embodiment of this application, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, implements the steps of the sensor management method described in the foregoing embodiments.

[0123] In another embodiment of this application, a computer program product is also provided, including a computer program or instructions that, when executed by a processor, implement the steps of the sensor management method as described in the foregoing embodiments.

[0124] Those skilled in the art will understand that embodiments of this application can be provided as methods, apparatus, devices, or computer program products. Therefore, this application can take the form of hardware embodiments, software embodiments, or embodiments combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage and optical storage) containing computer-usable program code.

[0125] It should be noted that, in this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0126] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0127] The features disclosed in the several product embodiments provided in this application can be arbitrarily combined to obtain new product embodiments without conflict. Similarly, the features disclosed in the several method or device embodiments provided in this application can be arbitrarily combined to obtain new method or device embodiments without conflict. The above descriptions are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

Claims

1. A sensor management method, characterized in that, Applied to vehicles equipped with a data abstraction framework, the method includes: The data abstraction framework is invoked to read vehicle configuration information, which includes information about the target sensors configured on the vehicle. Based on the information of the target sensor, the plugin registry maintained by the data abstraction framework is traversed to determine the target plugin information that matches the target sensor; wherein, the plugin registry includes multiple sensor plugin information that have been registered in the data abstraction framework; The target plugin is used to process the sensor data reported by the target sensor.

2. The method according to claim 1, characterized in that, The method further includes: Obtain sensor configuration files, which include sensor plugins for different platforms and vehicle models; Obtain the plug-in identifier and factory class information from each of the aforementioned sensor plug-ins; Each sensor plugin is registered in the plugin registry within the data abstraction framework based on its plugin identifier and factory class information.

3. The method according to claim 2, characterized in that, The method further includes: Receive updated sensor profiles; The newly added sensor plugins are obtained from the updated sensor configuration file, and the newly added sensor plugins are registered in the plugin registry.

4. The method according to claim 1, characterized in that, The method further includes: Obtain a vehicle configuration information change request, wherein the vehicle configuration information change request includes information on newly configured sensors on the vehicle; The plugin registry is traversed based on the information of the newly configured sensors; If the sensor plugin information corresponding to the newly configured sensor exists in the plugin registry, a license request is generated. If the sensor plugin information corresponding to the newly configured sensor does not exist in the plugin registry, a message prohibiting changes will be generated.

5. The method according to claim 4, characterized in that, The method further includes: If the sensor plugin information corresponding to the newly configured sensor does not exist in the plugin registry, a sensor plugin request is sent to the cloud; wherein, the sensor plugin request includes the information of the newly configured sensor; Upon receiving a feedback message from the cloud, if the feedback message contains sensor plugin information corresponding to the newly configured sensor, a request for permission is generated; if the feedback message does not contain sensor plugin information corresponding to the newly configured sensor, a prohibition on change is generated.

6. The method according to claim 1, characterized in that, The method further includes: Obtain a first management instruction, the first management instruction including information about a first sensor plug-in, the first sensor plug-in being a sensor plug-in to be deleted; In response to the first management instruction, the first sensor plugin is removed from memory, and the registration information of the first sensor plugin is removed from the plugin registry.

7. The method according to claim 1, characterized in that, The plugin registry includes a first registry and a second registry. The plugin identifier in the first registry is the plugin name, and the plugin identifier in the second registry is the plugin identity code.

8. A sensor management device, characterized in that, Applied to vehicles, the vehicles being equipped with a data abstraction framework, the device includes: The reading module is used to call the data abstraction framework to read vehicle configuration information, which includes information about the target sensors configured on the vehicle. The processing module is used to traverse the plugin registry maintained by the data abstraction framework based on the information of the target sensor to determine the target plugin information that matches the target sensor; wherein, the plugin registry includes multiple sensor plugin information that has been registered in the data abstraction framework; and to process the sensing data reported by the target sensor using the target plugin information.

9. A vehicle, characterized in that, It includes a processor and a memory, the memory storing programs or instructions that can run on the processor, the programs or instructions being executed by the processor to implement the steps of the sensor management method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program or computer-executable instructions, which, when executed by a processor, implement the steps of the sensor management method as described in any one of claims 1 to 7.

Images