Vehicle-mounted sensor unified perception adaptation interface construction method, device, equipment, medium, vehicle and system

Abstract

The application provides a vehicle-mounted sensor unified perception adaptation interface construction method and device, electronic equipment, a computer readable storage medium, a vehicle and a system. The method identifies a hardware interrupt trigger source connected to a vehicle-mounted sensor, extracts a hardware identification code, allocates a memory mapping descriptor and constructs a structured topology mapping space, separates a time sequence alignment identifier and payload data, writes a feature address node according to a conversion instruction sequence, generates a unified addressing virtual pointer and distributes the payload data to an automatic driving service process in real time.

Description

Technical Field

[0001] This application relates to the fields of vehicle networking, autonomous driving and vehicle edge computing technology, and more specifically, to a method, apparatus, electronic device, computer-readable storage medium, vehicle and system for constructing a unified perception adaptation interface for vehicle sensors. Background Technology

[0002] With the continuous increase in sensing components such as cameras, millimeter-wave radar, lidar, ultrasonic sensors, and inertial measurement units in autonomous vehicles, the vehicle interior needs to complete the reception of multi-source sensing data, time relationship processing, format conversion, and data supply to upper-level driving functions within a short period of time. Different onboard sensing components differ in transmission cycle time, data bit width, interface format, and buffer organization. If a relatively unified data access and distribution channel cannot be formed on the vehicle side, it can easily affect the real-time operation of subsequent environmental perception, target recognition, path planning, and other services.

[0003] In existing vehicle perception data access solutions, a common approach is for an upper-layer middleware to uniformly receive data packets reported by various sensor drivers. The middleware then calls the corresponding parsing program based on the sensor type, writes the parsed data into a message queue, and forwards it to autonomous driving-related business processes via a publish-subscribe mechanism. This solution first configures independent driver interfaces for different types of sensors; then, the middleware layer converts different data formats; finally, the business processes read the required perception data from the message queue according to their subscribed topics.

[0004] However, the aforementioned middleware message queue-based processing method still has technical shortcomings. Due to the lack of a continuous underlying connection between sensor-triggered events, device identity, memory storage areas, and business process subscription relationships, perceived data often requires multiple parsing, copying, and queue forwarding processes, resulting in a long data migration chain. Simultaneously, the correspondence between different sensor data in terms of time ticks and cache locations is not direct enough, making it susceptible to cache switching, format conversion, and kernel-to-user space transmission overhead when business processes read data. This leads to low real-time performance, uniformity, and resource utilization efficiency in the access of multi-source perception data in vehicles. Summary of the Invention

[0005] This application provides a method, apparatus, electronic device, computer-readable storage medium, vehicle, and system for constructing a unified sensing adaptation interface for vehicle sensors, in order to at least alleviate the aforementioned technical problems.

[0006] A method for constructing a unified perception adaptation interface for vehicle sensors includes: Identify the hardware interrupt trigger source of the connected vehicle sensor and extract the hardware identification code from the continuous sensing data stream generated by the vehicle sensor. Based on the hardware interrupt trigger source and the hardware identifier, a corresponding memory mapping descriptor is allocated, and a structured topology mapping space is constructed in the system physical memory of the underlying controller according to the memory mapping descriptor. Separate the timing alignment identifier and payload data from the continuous sensing data stream; The translation instruction sequence associated with the memory mapping descriptor is parsed, and the payload data is written into the specified feature address node in the topology mapping space according to the translation instruction sequence and the timing alignment identifier. In the system kernel of the underlying controller, a unified addressing virtual pointer is generated pointing to the topology mapping space, and the effective payload data in the feature address node is allocated to the autonomous driving business process in real time according to the unified addressing virtual pointer.

[0007] Optionally, the step of identifying the hardware interrupt trigger source of the accessed vehicle sensor and extracting the hardware identifier code from the continuous sensing data stream generated by the vehicle sensor includes: Monitor the bus pin level transition events corresponding to the vehicle sensor in the underlying controller; When the bus pin level transition event is captured, the timestamp of the level transition edge is recorded as the hardware interrupt trigger source of the vehicle sensor; The starting data frame of the continuous sensing data stream is parsed, the physical address device number recorded in the frame header area of ​​the starting data frame is read, and the physical address device number is determined as the hardware identification code.

[0008] Optionally, the step of allocating a corresponding memory mapping descriptor based on the hardware interrupt triggering source and the hardware identifier code includes: Based on the hardware identification code, the corresponding device data bit width is retrieved from the pre-configured hardware configuration registry, which records the correspondence between the hardware identification code and the device data bit width. Based on the retrieved device data bit width, a physical memory block matching the device data bit width is allocated in the reserved isolated memory area of ​​the underlying controller; Based on the starting address of the physical memory block, the storage boundary length, and the hardware interrupt trigger source, a formatted data record is generated, and the formatted data record is identified as the memory mapping descriptor corresponding to the hardware interrupt trigger source and the hardware identifier.

[0009] Optionally, the step of constructing a structured topology mapping space in the system physical memory of the underlying controller according to the memory mapping descriptor includes: Read the starting address and the storage boundary length recorded in the memory mapping descriptor; A continuous physical address range is determined in the system physical memory of the underlying controller by the starting address and the storage boundary length, and a multidimensional circular buffer is established within this continuous physical address range; An incremental local index label is assigned to each buffer slot in the multidimensional circular buffer, thereby forming the structured topology mapping space corresponding to the memory mapping descriptor.

[0010] Optionally, the step of separating the timing alignment identifier and payload data from the continuous sensing data stream includes: Based on the preset data frame structure definition, the current data packet in the continuous sensing data stream is parsed. The data frame structure definition is used to identify the message header, payload field and checksum tail of the current data packet. According to the data frame structure definition, the global timestamp field in the header of the current data packet is extracted, and the global timestamp field is determined as the timing alignment identifier; The header and checksum of the current data packet are stripped, and the remaining payload fields are extracted as the payload data.

[0011] Optionally, the step of parsing the translation instruction sequence associated with the memory mapping descriptor and writing the payload data into the specified feature address node within the topology mapping space based on the translation instruction sequence and the timing alignment identifier includes: Load data sorting instructions from the sequence of translation instructions associated with the memory-mapped descriptor; According to the data arrangement order adjustment instruction, the byte sequence in the payload data is reversed and reassembled to obtain the reassembled payload data; The corresponding target local index label is obtained by looking up the table based on the time alignment identifier, and the specified feature address node is determined in the structured topology mapping space according to the target local index label. The recombined payload data is then transferred to the feature address node.

[0012] Optionally, the step of obtaining the corresponding target local index label by looking up the table based on the time alignment identifier includes: The timing alignment identifier is input into a local time reference lookup table hard-coded in the underlying controller. The local time reference lookup table records the binding relationship between the reference clock cycle sequence and the target local index label. The system clock cycle count value contained in the timing alignment identifier is compared with the reference clock cycle sequence in the local time base lookup table to determine the matching reference clock cycle node. Read the target local index label bound to the matching reference clock cycle node as the lookup result.

[0013] Optionally, the step of generating a unified addressing virtual pointer to the topology mapping space in the system kernel of the underlying controller includes: Invoke the memory management unit device driver of the underlying controller; The hardware physical base address of the topology mapping space is obtained through the memory management unit device driver; The memory management unit device driver is controlled to establish a page mapping relationship from the hardware physical base address to the user-mode logical address space, and the page table entry access entry corresponding to the page mapping relationship is used as the unified addressing virtual pointer pointing to the topology mapping space.

[0014] Optionally, the step of allocating the payload data in the feature address node to the autonomous driving service process in real time based on the unified addressing virtual pointer includes: Receive a data subscription request message carrying a target data type identifier sent by the autonomous driving service process; Parse the target data type identifier in the data subscription request message, and address the feature address node in the topology mapping space that stores the payload data according to the unified addressing virtual pointer; A zero-copy transfer from kernel mode to user mode is triggered, and the payload data in the feature address node is directly pushed to the independent application receive cache of the autonomous driving business process to complete the real-time allocation of the payload data to the autonomous driving business process.

[0015] A device for constructing a unified sensing adaptation interface for vehicle sensors, comprising: The interrupt identification module is used to identify the hardware interrupt trigger source of the connected vehicle sensor and extract the hardware identification code from the continuous sensing data stream generated by the vehicle sensor. The mapping construction module is used to allocate corresponding memory mapping descriptors based on the hardware interrupt triggering source and the hardware identifier code, and to construct a structured topology mapping space in the system physical memory of the underlying controller according to the memory mapping descriptors; The data separation module is used to separate the timing alignment identifier and payload data from the continuous sensing data stream; The data writing module is used to parse the translation instruction sequence associated in the memory mapping descriptor, and write the payload data into the specified feature address node in the topology mapping space according to the translation instruction sequence and the timing alignment identifier. The data allocation module is used to generate a unified addressing virtual pointer pointing to the topology mapping space in the system kernel of the underlying controller, and to allocate the effective payload data in the feature address node to the autonomous driving business process in real time according to the unified addressing virtual pointer.

[0016] An electronic device includes a processor and a memory, the memory storing a computer program executable by the processor, wherein the processor executes the computer program to implement the above-described method for constructing a unified perception adaptation interface for vehicle sensors.

[0017] A computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method for constructing a unified perception adaptation interface for vehicle sensors.

[0018] A vehicle includes on-board sensors, a low-level controller, and a device for constructing a unified perception adaptation interface for the on-board sensors. The on-board sensors are used to generate a continuous sensing data stream; The underlying controller is used to provide system physical memory and system kernel for the vehicle sensor unified perception adaptation interface construction device; The unified perception adaptation interface construction device for vehicle sensors is used to identify the hardware interrupt trigger source of the connected vehicle sensors, extract the hardware identifier code from the continuous perception data stream, allocate the corresponding memory mapping descriptor based on the hardware interrupt trigger source and the hardware identifier code, construct a structured topology mapping space in the system physical memory of the underlying controller according to the memory mapping descriptor, separate the timing alignment identifier and payload data from the continuous perception data stream, parse the conversion instruction sequence associated in the memory mapping descriptor, and write the payload data into the specified feature address node in the topology mapping space according to the conversion instruction sequence and the timing alignment identifier. A unified addressing virtual pointer pointing to the topology mapping space is generated in the system kernel of the underlying controller, and the payload data in the feature address node is allocated to the autonomous driving business process in real time according to the unified addressing virtual pointer.

[0019] A unified perception adaptation interface construction system for vehicle sensors includes vehicle sensors, underlying controllers, and autonomous driving business processes. The on-board sensors are used to generate a continuous sensing data stream; The underlying controller is used to identify the hardware interrupt trigger source of the connected vehicle sensor, extract the hardware identifier code from the continuous sensing data stream, allocate the corresponding memory mapping descriptor based on the hardware interrupt trigger source and the hardware identifier code, construct a structured topology mapping space in the system physical memory of the underlying controller according to the memory mapping descriptor, separate the timing alignment identifier and the payload data from the continuous sensing data stream, parse the conversion instruction sequence associated in the memory mapping descriptor, and write the payload data into the specified feature address node in the topology mapping space according to the conversion instruction sequence and the timing alignment identifier, and generate a unified addressing virtual pointer pointing to the topology mapping space in the system kernel of the underlying controller. The autonomous driving service process is used to receive the payload data from the feature address nodes allocated in real time by the underlying controller based on the unified addressing virtual pointer.

[0020] The technical advantages of the technical solution provided in this application are: This application's method for constructing a unified sensing adaptation interface for vehicle-mounted sensors addresses the technical shortcomings of existing middleware message queue-based processing methods. These shortcomings stem from the lack of a low-level, continuous association between sensor trigger events, device identity, memory storage areas, and business process subscription relationships, resulting in long data migration chains and low real-time performance. The method first identifies the hardware interrupt trigger source of the connected vehicle-mounted sensor and extracts the hardware identifier code from the continuous sensing data stream generated by the sensor. This ensures that the sensor access event and sensor identity are associated at the beginning of the data processing chain. Compared to traditional solutions where upper-layer middleware receives data packets separately according to sensor type, this application uses the hardware trigger source and hardware identifier code as the basis for subsequent memory allocation and data writing. This provides a clearer low-level distinction between data entry points from different vehicle-mounted sensors, reducing the processing overhead of repeatedly identifying data sources using software topics or queue tags.

[0021] This application allocates corresponding memory mapping descriptors based on hardware interrupt trigger sources and hardware identifier codes, and constructs a structured topology mapping space in the system physical memory of the underlying controller according to the memory mapping descriptors. This solves the problem in traditional solutions where sensor data is usually scattered into different software caches, and business processes cannot directly read data according to a unified address structure. Compared to the traditional method of moving data through driver cache, middleware cache, and business cache in a step-by-step manner, this application establishes a correspondence between sensor access information and the structured carrying space in the system physical memory. This allows continuous sensing data streams to fall into a storage area with a unified organizational relationship after entering the vehicle-side processing link, making it easier to address and manage the cache locations of different vehicle sensor data, and reducing the latency caused by repeated switching of multi-source sensing data between cache layers.

[0022] This application separates the timing alignment identifier and payload data from a continuous sensing data stream, and parses the associated conversion instruction sequence in the memory-mapped descriptor. Based on the conversion instruction sequence and the timing alignment identifier, the payload data is written to the specified feature address node within the topology mapping space. This solves the problem of insufficient direct correspondence caused by the data format conversion and timing timing adjustment being performed in multiple software stages in traditional solutions. Compared to the traditional approach of first entering the message queue and then having the business process or middleware attach the timing relationship, this application separates the timing alignment identifier and payload data before writing to the storage space, and uses the conversion instruction sequence to constrain the writing position of the payload data. This creates a direct connection between the data content, timing relationship, and feature address node, facilitating the subsequent on-demand reading of sensing data under the same timing relationship by the autonomous driving business process.

[0023] This application generates a unified addressing virtual pointer pointing to the topology mapping space in the system kernel of the underlying controller, and allocates the effective payload data in the feature address nodes to the autonomous driving business process in real time based on the unified addressing virtual pointer. This solves the problem of high kernel-to-user space transmission overhead caused by the fact that business processes usually need to indirectly obtain data through message queues or upper-layer middleware in traditional solutions. Compared with the traditional approach of requiring multiple levels of copying, encapsulation, and subscription forwarding before the business process can use the data, this application directly points the data reading entry of the business process to the topology mapping space through the unified addressing virtual pointer. This allows the effective payload data in the feature address nodes to be allocated to the autonomous driving business process with a shorter path, which helps to improve the real-time performance and interface uniformity of vehicle perception data access, and reduces the data distribution load when multiple sensors are accessed. Attached Figure Description

[0024] Figure 1 This application provides a scenario for constructing a unified perception adaptation interface for vehicle sensors. Figure 2 This application provides a method for constructing a unified sensing adaptation interface for vehicle sensors. Figure 3 This application provides an embodiment of a unified sensing adaptation interface construction device for vehicle sensors. Figure 4 An electronic device is described in an embodiment of this application; Figure 5 This application provides an embodiment of a computer-readable storage medium. Figure 6 This application describes a vehicle as an example of its embodiments. Figure 7 This application provides a unified sensing adaptation interface construction system for vehicle sensors. Detailed Implementation

[0025] This application provides a method for constructing a unified perception adaptation interface for vehicle-mounted sensors, which can be applied to a low-level controller. The low-level controller handles hardware access for vehicle-mounted sensors, system physical memory management, system kernel mapping, and data allocation for autonomous driving business processes. Vehicle-mounted sensors, as the generators of continuous perception data streams, can include vehicle perception components such as cameras, millimeter-wave radar, lidar, ultrasonic sensors, and inertial measurement units. Technically, the continuous perception data stream is a set of data frames or data packets continuously output by the vehicle-mounted sensors according to a sampling cycle. This data stream includes fields describing control attributes such as source, time, and verification, as well as payload fields carrying the perceived content.

[0026] In vehicle-mounted multi-source perception scenarios, different vehicle sensors typically have different hardware triggering methods, device identities, data bit widths, data frame structures, and cache usage characteristics. If sensor data is only uniformly forwarded through message queues in the upper-layer software, there is a lack of underlying continuous association between sensor triggering events, device identities, memory storage areas, and business process subscription relationships. Sensor source identification, data format conversion, cache copying, and user-space distribution are often completed in multiple processing stages, which can easily lead to long data migration links and low real-time performance. To improve the above problems, this application embodiment constructs an association between the hardware triggering source, hardware identity, structured storage space in the system's physical memory, time alignment relationships, and business process access entry points of vehicle sensors on the underlying controller side. This allows the continuous perception data stream to fall into a storage area with a unified organizational relationship after entering the processing link and to be provided to the autonomous driving business process according to a shorter data allocation path.

[0027] Figure 1 This application illustrates the construction of a unified perception adaptation interface for vehicle sensors provided in an embodiment of the present application; Figure 2 This document illustrates a flowchart of a method for constructing a unified sensing adaptation interface for vehicle sensors, as provided in an embodiment of this application. The method includes: Step S11: Identify the hardware interrupt trigger source of the connected vehicle sensor and extract the hardware identification code from the continuous sensing data stream generated by the vehicle sensor.

[0028] The connected vehicle sensors can be sensing components that have already established a communication connection with the underlying controller through the vehicle bus, controller interface, or sensor connection port. In this embodiment, the hardware interrupt trigger source is used to characterize the source of data arrival or state change triggered by the vehicle sensor at the hardware level. Its technical essence can be characterized by the level transition edge of the bus pin corresponding to the sensor and the corresponding time information. The hardware identifier code is used to characterize the sensor hardware identity corresponding to the current continuous sensing data stream. Its technical essence can be carried by the physical address device number recorded in the frame header area of ​​the starting data frame.

[0029] Specifically, after an onboard sensor connects, the underlying controller monitors the voltage level of the bus pin corresponding to that sensor. When the onboard sensor begins transmitting a continuous sensing data stream or generates a data arrival event, a voltage level transition occurs on the corresponding bus pin. The underlying controller captures this voltage level transition edge, records its timestamp, and uses this timestamp as the hardware interrupt trigger source for the onboard sensor. Through this process, the sensor connection event is recorded as a hardware trigger at the beginning of the data entry processing chain. Subsequent memory allocation, data writing, and timing organization can all be correlated with this hardware trigger, thereby reducing the overhead of repeatedly identifying the data trigger source using software themes or queue tags.

[0030] Simultaneously, the underlying controller parses the starting data frame in the continuous sensing data stream. The starting data frame serves as a source identifier for the beginning of the sensor data stream, and its header area carries control information such as the device number, data source, or data format. The underlying controller reads the physical address device number from the header area according to the field layout of the starting data frame and identifies this physical address device number as the hardware identifier. Through this processing, the hardware interrupt trigger source is used to characterize the triggering time of the vehicle sensor, and the hardware identifier is used to characterize the hardware identity of the vehicle sensor. Together, they provide the foundation for subsequent physical memory allocation and the construction of a unified sensing adaptation interface, enabling a clear distinction between the data entry points of different vehicle sensors at the underlying level.

[0031] Step S12: Allocate a corresponding memory mapping descriptor based on the hardware interrupt trigger source and the hardware identifier code, and construct a structured topology mapping space in the system physical memory of the underlying controller according to the memory mapping descriptor.

[0032] In this embodiment, the memory mapping descriptor is a formatted data record that stores the physical memory carrying information and hardware trigger information corresponding to the vehicle sensors. Its technical essence lies in organizing the hardware interrupt trigger source, hardware identifier code, starting address of the physical memory block, and storage boundary length into descriptive information that can be read and invoked by the underlying controller. The system physical memory is the physical storage space that the underlying controller can directly manage and address. The structured topology mapping space is an address organization region established in the system physical memory. It forms an addressable data carrying structure through continuous physical address ranges, multi-dimensional circular buffers, buffer slots, and local index tags. Through this structure, sensor access information can be correlated with the structured carrying space in the system physical memory, avoiding the problem of sensor data being scattered into different software caches, which would make it difficult for business processes to read data according to a unified address structure.

[0033] In some embodiments, a hardware configuration registry can be pre-configured in the underlying controller. This registry can be generated and written to a storage area readable by the underlying controller during vehicle factory configuration, controller initialization, sensor adaptation configuration, or firmware burning. The registry records the correspondence between hardware identifiers and device data bit widths. The device data bit width characterizes the bit width required for a single data storage or transmission by the corresponding vehicle sensor, directly affecting the size of the physical memory block allocated to that sensor. By pre-determining the hardware configuration registry, the underlying controller can quickly retrieve the corresponding device data bit width after obtaining the hardware identifier, thus providing a basis for physical memory block allocation and establishing a low-level correspondence between memory capacity specifications and sensor hardware identity.

[0034] Specifically, the underlying controller searches the pre-configured hardware configuration registry based on the hardware identifier to obtain the corresponding device data bit width. The search process uses the hardware identifier as an index field to find the device data bit width bound to it in the hardware configuration registry. This search action establishes a correspondence between hardware identity and memory carrying specifications, serving as a pre-processing step for subsequent allocation of memory mapping descriptors and providing a basis for data bit width to ensure that continuously flowing data falls into a uniformly organized storage area.

[0035] After retrieving the device data bit width, the underlying controller allocates a physical memory block within a reserved isolated memory area that matches the device's data bit width. This reserved isolated memory area can be pre-allocated from the system's physical memory during system startup or memory initialization to carry the continuous sensing data stream from the vehicle-mounted sensors. This reserved isolated memory area is distinct from the ordinary application memory area, facilitating centralized management of the physical storage area for the sensing data by the underlying controller. The physical memory block is a storage area partitioned from the reserved isolated memory area, with its storage capacity and boundary range matching the device data bit width. This ensures that the data output by the vehicle-mounted sensor has a corresponding physical carrying space, thereby reducing the dependency on the step-by-step movement of sensor data between driver cache, middleware cache, and business cache.

[0036] After delineating a physical memory block, the underlying controller obtains its starting address and storage boundary length. The starting address represents the initial position of the physical memory block in the system's physical memory, and the storage boundary length represents the address range that the physical memory block can cover. The underlying controller writes the starting address, storage boundary length, and hardware interrupt trigger source of the physical memory block into the same formatted data record according to a predetermined field order, and identifies this formatted data record as a memory mapping descriptor corresponding to the hardware interrupt trigger source and hardware identifier. Through this process, subsequent data writing, topology mapping space construction, and loading of translation instruction sequences can all be executed around the same descriptor, enabling a continuous underlying association between hardware trigger events, device identity, and memory-bearing regions.

[0037] When constructing the structured topology mapping space, the underlying controller reads the starting address and storage boundary length recorded in the memory-mapped descriptor. Technically, this reading action involves obtaining the starting address field value and storage boundary length field value from the corresponding fields of the memory-mapped descriptor. Subsequently, the underlying controller uses the starting address as the starting point and the storage boundary length as the range boundary to determine a continuous range of physical addresses in the system's physical memory. This continuous range of physical addresses provides the physical address basis for subsequently establishing a multi-dimensional circular buffer, ensuring that the continuous sensing data stream falls within a defined range of system physical memory after entering the vehicle-side processing link.

[0038] Multidimensional circular buffers can organize continuous physical address ranges according to dimensions such as time order, data type, or cache slots. The circular buffer structure can adapt to the continuous arrival of sensing data streams; after the buffer slots are written sequentially to the end, they can return to the starting slot according to a circular rule to continue writing. As the basic data-carrying unit in the multidimensional circular buffer, each buffer slot can individually correspond to a writable or readable address location. Through this buffer organization method, the cache locations of different vehicle sensor data are easier to address and manage, reducing the latency caused by repeated switching of multi-source sensing data between multiple software cache layers.

[0039] The underlying controller assigns an incrementing local index label to each buffer slot in the multidimensional circular buffer. The local index label identifies the location of the buffer slot within the topology mapping space, and the incrementing assignment reflects the arrangement order of the buffer slots. Through this process, a continuous range of physical addresses not only possesses physical address continuity but also a structured addressing relationship based on local index labels, thus forming a structured topology mapping space corresponding to the memory mapping descriptor. Therefore, when the autonomous driving process subsequently reads data, it can locate characteristic address nodes based on a unified address structure, without relying on scattered storage locations in different software caches.

[0040] Step S13: Separate the timing alignment identifier and payload data from the continuous sensing data stream.

[0041] In this embodiment, the timing alignment identifier indicates the corresponding position of the current sensing data on the timeline, and its technical essence can be carried by the global timestamp field in the header of the current data packet. The payload data is the data portion carrying the actual sensing content in the continuous sensing data stream, and it is distinguished from control fields such as the packet header and checksum tail. The separation process is used to split the time-related fields and payload-related fields into different processing objects, allowing the timing alignment identifier to be used to locate feature address nodes, and the payload data to be used to write to the corresponding address nodes. By performing this separation process before writing to the storage space, the temporal relationship and data content of the data can participate in positioning and writing separately before entering the topology mapping space, reducing the need for additional temporal relationship processing on the message queue or business process side.

[0042] In some embodiments, the underlying controller can pre-define the data frame structure. This data frame structure definition can be determined by the sensor data format before sensor protocol adaptation, controller initialization, or interface construction, and is written into a configuration area readable by the underlying controller. The data frame structure definition is used to identify the header, payload field, and checksum tail of the current data packet, and may specifically include the start position, field length, and arrangement order of each field. By pre-determining the data frame structure definition, the underlying controller can extract timing alignment identifiers and extract payload data from the continuous sensing data stream according to fixed field boundaries, thus forming a clear processing link for data format conversion and timing adjustment on the underlying controller side.

[0043] The current data packet is the transmission unit currently entering the parsing process in the continuous sensing data stream. The packet header carries time, source, or control information; the payload field carries the actual sensed content; and the checksum tail carries information such as checksum verification, integrity judgment, or end markers. The underlying controller parses the current data packet based on a preset data frame structure definition, determining the boundaries of the packet header, payload field, and checksum tail. Through this parsing process, the underlying controller can complete field boundary identification before the data enters the message queue or business process, thereby reducing the need for multiple software components to repeatedly parse the same data packet.

[0044] Specifically, the underlying controller extracts the global timestamp field from the header of the current data packet according to the data frame structure definition, and uses this global timestamp field as a timing alignment identifier. The extraction can be accomplished using field offset and field length. The global timestamp field enables data from different vehicle sensors to have a time correspondence when written into the topology mapping space, and this timing alignment identifier can be used to locate feature address nodes with the same time relationship.

[0045] Subsequently, the underlying controller strips the header and checksum of the current data packet, extracting the remaining payload fields as the payload data. Technically, this stripping process means that the header and checksum are no longer considered as the perceived payload to be written; only the payload fields are retained as the payload data. Through this processing, the underlying controller can use the timing alignment identifier and payload data for node location and data writing respectively, ensuring a clear division of processing tasks between data content and time when entering the topology mapping space.

[0046] Step S14: Parse the translation instruction sequence associated with the memory mapping descriptor, and write the payload data into the specified feature address node in the topology mapping space according to the translation instruction sequence and the timing alignment identifier.

[0047] The conversion instruction sequence is a set of instructions associated with a memory-mapped descriptor, used to indicate the data arrangement and processing method of the payload data before it is written. The conversion instruction sequence can be established when the memory-mapped descriptor is generated, or it can be pointed to by a pre-configured instruction record from the instruction index field in the memory-mapped descriptor. This conversion instruction sequence enables the payload data output from different vehicle-mounted sensors to complete the corresponding arrangement processing before being written to the topology mapping space. Because the conversion instruction sequence is associated with the memory-mapped descriptor, the data format conversion processing can be synchronously determined with the physical memory write location, reducing the problem of insufficient direct correspondence caused by data format conversion and timing adjustments being performed in multiple software stages.

[0048] Feature address nodes are address nodes in the topology mapping space used to carry effective payload data. Technically, they can be represented as buffer slots located by target local index tags within a multi-dimensional circular buffer, or specific address locations within those buffer slots. The designated feature address nodes are not randomly determined, but rather further located using target local index tags obtained through a lookup table based on temporal alignment identifiers. This positioning method allows for a direct connection between data content, temporal relationships, and feature address nodes, facilitating the subsequent on-demand reading of perception data within the same temporal relationship during the autonomous driving process.

[0049] In some embodiments, the underlying controller loads data sorting order adjustment instructions from a sequence of conversion instructions associated with a memory-mapped descriptor. These instructions specify the orientation or order of bytes in the payload data. Loading can be accomplished by reading the associated field or instruction index from the memory-mapped descriptor. After loading the instructions, the underlying controller can determine the byte sorting processing required before writing the payload data, eliminating the need for separate post-read processing by the business process or upper-layer middleware.

[0050] The underlying controller, following the data arrangement order adjustment instructions, performs a reverse and reordering operation on the byte sequence in the payload data to obtain the reordered payload data. The byte sequence consists of multiple bytes arranged in the transmission order within the payload data. The reverse and reordering operation reorganizes this byte sequence in the reverse order of the original arrangement. The reordered payload data serves as the final data content written to the feature address node, and its arrangement is adapted to the storage requirements of the topology mapping space, thus ensuring that the data entering the feature address node can meet the requirements of unified addressing and subsequent allocation.

[0051] Subsequently, the underlying controller retrieves the corresponding target local index label by looking up a table based on the timing alignment identifier. The target local index label is used to locate the feature address node in the structured topology mapping space. The table lookup process can use the timing alignment identifier as an input parameter to search for the corresponding index label in a pre-fixed or pre-established time reference correspondence. After obtaining the target local index label, the underlying controller determines the specified feature address node in the structured topology mapping space based on the target local index label and transfers the reassembled payload data to that feature address node. After the transfer is completed, a direct association is formed between the payload data, the timing correspondence, and the feature address node. The autonomous driving process can subsequently access the corresponding feature address node using a unified addressing virtual pointer, without needing to reassemble the timing relationship and payload data through a message queue.

[0052] In some embodiments, obtaining the corresponding target local index label by looking up a table based on the timing alignment identifier specifically includes: inputting the timing alignment identifier into a local time reference lookup table hard-coded in the underlying controller. The local time reference lookup table can be pre-embedded in the underlying controller during controller firmware compilation, program burning, or underlying initialization. This local time reference lookup table records the binding relationship between the reference clock cycle sequence and the target local index label, used to convert time information into address node indices within the topology mapping space. Because the local time reference lookup table is hard-coded in the underlying controller, the correspondence between the timing alignment identifier and the local index label can be quickly matched at the underlying level, reducing the need for secondary processing of timing clock cycles by upper-layer middleware.

[0053] The reference clock cycle sequence consists of multiple reference clock cycle nodes formed by the local clock of the underlying controller. The system clock cycle count value is the count information in the timing alignment identifier used to characterize the system clock cycle corresponding to the current data packet. The underlying controller compares the system clock cycle count value contained in the timing alignment identifier with the reference clock cycle sequence in the local time base lookup table to determine the matching reference clock cycle node. The comparison process is used to determine the position of the current payload data in the local time base, so that data generated by different on-board sensors under similar time relationships can fall into the corresponding topological mapping space position.

[0054] After identifying the matching reference clock cycle node, the underlying controller reads the target local index tag bound to that matching reference clock cycle node and uses it as the lookup result. Thus, the underlying controller can obtain the write location in the topology mapping space from the time identifier, enabling payload data with corresponding time relationships to be written to the corresponding feature address node. This allows subsequent service processes to directly utilize the address node relationship to obtain the sensing data under the same time relationship.

[0055] Step S15: Generate a unified addressing virtual pointer pointing to the topology mapping space in the system kernel of the underlying controller, and allocate the effective payload data in the feature address node to the autonomous driving business process in real time according to the unified addressing virtual pointer.

[0056] In this embodiment, the system kernel is responsible for managing the memory, drivers, and user-mode access relationships of the underlying controller. A unified addressing virtual pointer provides a unified entry point for autonomous driving business processes to access the topology mapping space; its technical essence can be carried by the page table entry entry corresponding to the page mapping relationship. Autonomous driving business processes are those within the vehicle control system that need to use perception data to perform autonomous driving-related processing. Real-time allocation processing is used to provide the payload data to the autonomous driving business processes according to subscription requests and addressing results after the payload data is written to the feature address node. By generating a unified addressing virtual pointer in the system kernel, the data reading entry point of the business process can directly point to the topology mapping space, reducing the kernel-to-user-mode transmission overhead caused by indirectly obtaining data through message queues or upper-layer middleware.

[0057] In some embodiments, the underlying controller invokes the Memory Management Unit (MMU) device driver. The MMU device driver is a driver program in the system kernel responsible for establishing the mapping relationship between physical and logical addresses. The invocation action can trigger the MMU device driver to perform address mapping operations through the driver access interface provided by the system kernel. The driver's role is to map the hardware physical base address of the topology mapping space to the user-space logical address space, enabling autonomous driving business processes to access the corresponding data areas through unified addressing virtual pointers, thereby reducing redundant data copying between kernel cache, message queue cache, and business process cache.

[0058] The underlying controller obtains the hardware physical base address of the topology mapping space through the memory management unit device driver. The hardware physical base address represents the starting physical location of the topology mapping space in the system's physical memory and is the physical basis for establishing page mapping relationships. Subsequently, the underlying controller controls the memory management unit device driver to establish page mapping relationships from the hardware physical base address to the user-mode logical address space. The user-mode logical address space is the range of logical addresses accessible to the autonomous driving service process. The page mapping relationship is used to establish the correspondence between physical memory pages and user-mode logical address pages, enabling the autonomous driving service process to access characteristic address nodes in the system's physical memory through a unified logical entry point.

[0059] After the page mapping relationship is established, the underlying controller uses the page table entry access point corresponding to the page mapping relationship as a unified addressing virtual pointer to the topology mapping space. The page table entry access point enables user-mode logical addresses to access the corresponding physical address regions via the page table mapping. Through this process, the autonomous driving business process does not need to perceive the physical memory start address and storage boundary length of different vehicle sensors separately, but can access the feature address nodes in the topology mapping space through the unified addressing virtual pointer, thereby improving the interface uniformity of vehicle perception data access.

[0060] In some embodiments, the underlying controller allocates payload data from feature address nodes to the autonomous driving service process in real time based on a unified addressing virtual pointer. Specifically, this includes receiving a data subscription request message carrying a target data type identifier sent by the autonomous driving service process. The data subscription request message is a data acquisition request sent by the autonomous driving service process to the underlying controller. The target data type identifier indicates the perception data type currently requested by the autonomous driving service process. The independent application receive cache is a cache area within the autonomous driving service process used to receive data pushed by the underlying controller. Through the target data type identifier, the subscription relationship of the autonomous driving service process can be linked to the access relationship of feature address nodes in the topology mapping space.

[0061] After receiving a data subscription request message, the underlying controller parses the target data type identifier within the message. This parsing process reads the target data type identifier field and determines the data type requested by the autonomous driving business process. Subsequently, the underlying controller uses the unified addressing virtual pointer to locate the characteristic address node storing the payload data in the topology mapping space. This addressing action is accomplished through the unified addressing virtual pointer and its corresponding page mapping relationship, used to locate the address node where the payload data resides. Through this process, a direct access path is established between the business process subscription relationship and the underlying physical storage node, reducing the path length required to obtain data after multiple levels of encapsulation and subscription forwarding.

[0062] After locating the feature address node, the underlying controller triggers a zero-copy transfer from kernel mode to user mode, directly pushing the payload data from the feature address node to the independent application receive cache of the autonomous driving business process, thus completing the real-time allocation of payload data to the autonomous driving business process. The kernel-to-user mode transfer process involves data delivery between the address space managed by the system kernel and the address space accessible to the autonomous driving business process. Zero-copy transfer reduces the processing of copying payload data to intermediate caches before forwarding, enabling the autonomous driving business process to receive or access the payload data in the feature address node through the access entry corresponding to the page mapping relationship. In this way, the payload data in the feature address node can be allocated to the autonomous driving business process with a shorter path, helping to improve the real-time performance of vehicle perception data access and reduce the data distribution load when multiple sensors are accessed.

[0063] In this embodiment, by identifying the hardware interrupt trigger source and hardware identifier, a correspondence between the hardware trigger source and the device identity can be established at the initial stage when sensor data enters the processing link, reducing the processing overhead of repeatedly identifying the data source by relying on software topics or queue tags. By allocating memory mapping descriptors based on the hardware interrupt trigger source and hardware identifier and constructing a structured topology mapping space, a correspondence can be established between sensor access information and the structured carrying space in the system's physical memory, allowing continuous sensing data streams to fall into a storage area with a unified organization, thereby reducing the latency caused by repeated switching of multi-source sensing data between cache layers. By separating the timing alignment identifier and payload data from the continuous sensing data stream, and writing the payload data to the specified feature address node according to the conversion instruction sequence and timing alignment identifier, a direct connection can be formed between the data content, timing relationship, and feature address node. This facilitates the autonomous driving business process to read sensing data under the same timing relationship on demand. By allocating payload data to the autonomous driving business process in real time through a unified addressing virtual pointer, the data reading entry point of the business process can be directly pointed to the topology mapping space, reducing the transmission overhead caused by multi-level copying, encapsulation, and subscription forwarding, thereby improving the real-time performance and interface uniformity of vehicle sensing data access.

[0064] In some embodiments, to further illustrate the identification process of hardware interrupt trigger sources and hardware identifier codes, the identification of hardware interrupt trigger sources of the connected vehicle sensors and the extraction of hardware identifier codes from the continuous sensing data stream generated by the vehicle sensors specifically include: The system monitors the level transition events of bus pins corresponding to the vehicle sensors in the underlying controller. These level transition events are characterized by a change in the voltage level of the bus pin connecting the underlying controller to the vehicle sensor, from one voltage state to another. Monitoring can be performed through periodic readings or interrupt-driven listening to acquire these voltage level changes. Through this monitoring process, the underlying controller can perceive data triggers from the vehicle sensors at the hardware level, ensuring that sensor trigger events are recorded at the lower level, rather than relying solely on upper-layer middleware to infer the data source after receiving data packets.

[0065] Upon capturing a bus pin level transition event, the timestamp of the transition edge is recorded as the hardware interrupt trigger source for the onboard sensor. The level transition edge can be either a rising edge or a falling edge. The timestamp of the level transition edge is recorded by the underlying controller upon capturing the rising or falling edge. The capture action can be accomplished through hardware interrupt listening or pin state change detection. After recording this timestamp as the hardware interrupt trigger source, subsequent memory-mapped descriptors can carry information associated with the hardware trigger moment, enabling the hardware trigger source to participate in determining the physical memory area and organizing the data write order.

[0066] The process involves parsing the initial data frame of the continuous sensing data stream, reading the physical address device number recorded in the frame header region of the initial data frame, and identifying the physical address device number as the hardware identifier. The parsing operation is completed according to the field layout of the initial data frame; the reading operation retrieves the value of the physical address device number field from the frame header region; after identifying the physical address device number as the hardware identifier, this hardware identifier can be used as the basis for subsequent retrieval of the hardware configuration registry and allocation of memory mapping descriptors, thus enabling device identification to no longer rely solely on software-level topic tag recognition.

[0067] In some embodiments, to further illustrate the memory mapping descriptor allocation process, a corresponding memory mapping descriptor is allocated based on the hardware interrupt trigger source and the hardware identifier code, specifically including: Based on the hardware identification code, the corresponding device data bit width is retrieved from the pre-configured hardware configuration registry. The hardware configuration registry records the correspondence between hardware identification codes and device data bit widths. This pre-configured hardware configuration registry can be generated in advance based on the vehicle's supported onboard sensor types, sensor physical address device number, and corresponding data bit width. This table can be loaded during the underlying controller's startup phase or permanently stored in a configuration storage area readable by the underlying controller. Through this hardware configuration registry, the underlying controller can determine the required memory capacity of the onboard sensor based on the hardware identification code, thus establishing a correspondence between the sensor device identity and the system's physical memory capacity requirements.

[0068] Based on the retrieved device data bit width, a physical memory block matching the device data bit width is allocated within the reserved isolated memory area of ​​the underlying controller. This allocation process involves selecting a physical memory region from the reserved isolated memory area that meets the storage requirements corresponding to the device data bit width, and marking this region as the data carrying area for the vehicle sensor corresponding to that hardware identifier. Matching the device data bit width means that the storage capacity of this physical memory block can adapt to the bit width characteristics of the corresponding vehicle sensor output data, ensuring that the sensor data has a relatively fixed physical carrying area at the underlying level, reducing the need for data aggregation after entering multiple software caches.

[0069] Based on the starting address of the physical memory block, the storage boundary length, and the hardware interrupt trigger source, a formatted data record is generated, and this formatted data record is identified as a memory mapping descriptor corresponding to the hardware interrupt trigger source and the hardware identifier code. The generation process can write the starting address, storage boundary length, and hardware interrupt trigger source into the same record according to a preset field order. Once this formatted data record is identified as the memory mapping descriptor, it can serve as the basis for subsequent topology mapping space establishment, loading conversion instruction sequences, and data writing, enabling sensor trigger events, device identity, and memory-bearing regions to form a continuous association within the same underlying descriptive information.

[0070] In some embodiments, to further illustrate the construction process of the structured topology mapping space, the structured topology mapping space is constructed in the system physical memory of the underlying controller according to the memory mapping descriptor, specifically including: The system reads the starting address and storage boundary length recorded in the memory-mapped descriptor. The starting address determines the starting position of the topology mapping space in the system's physical memory, and the storage boundary length determines the maximum range that the topology mapping space can cover. The read operation can convert the descriptive information in the memory-mapped descriptor into specific physical address construction basis, enabling the underlying controller to directly determine the data carrying area based on the descriptor.

[0071] A contiguous range of physical addresses is determined in the system's physical memory by the starting address and the storage boundary length, and a multi-dimensional circular buffer is established within this range. The process of determining the contiguous physical address range starts from the starting address and ends with the storage boundary length as the range boundary. The process of establishing the multi-dimensional circular buffer divides this physical address range into multiple reusable buffer slots, allowing continuously arriving sensing data to be written sequentially and reused according to a circular rule. Through this process, continuous sensing data streams can enter a storage area with a unified organizational structure, reducing the latency caused by moving data step-by-step between driver cache, middleware cache, and business cache.

[0072] Each buffer slot in the multidimensional circular buffer is assigned an incrementing local index label, forming a structured topological mapping space corresponding to the memory mapping descriptor. The allocation operation assigns a local index label to each buffer slot according to their arrangement. The incrementing local index labels establish an order among the buffer slots that can be accessed through lookup table results. Through this structured processing, buffer slots within the physical address range can be located using the target local index label, making it easier to uniformly address and manage the cache locations of different vehicle sensor data.

[0073] In some embodiments, to further illustrate the separation process of the timing alignment identifier and the payload data, separating the timing alignment identifier and the payload data from the continuous sensing data stream specifically includes: Based on a pre-defined data frame structure, the current data packet in the continuous sensing data stream is parsed. This data frame structure definition identifies the header, payload field, and checksum trailer of the current data packet. The pre-defined data frame structure can be determined in advance when adapting to the vehicle-mounted sensor data format and is loaded and used by the underlying controller. This data frame structure definition provides field boundaries for the underlying controller, enabling it to read the header, payload field, and checksum trailer from the corresponding positions in the current data packet. By parsing field boundaries at the underlying controller side, the processing time required for data to be parsed separately by multiple software components after entering the upper-layer message queue can be reduced.

[0074] Based on the data frame structure definition, the global timestamp field in the header of the current data packet is extracted and used as the timing alignment identifier. This extraction can be performed based on the field offset and field length defined in the data frame structure definition. Once the global timestamp field is identified as the timing alignment identifier, it can be used as input for subsequent table lookups to obtain the target local index label, enabling time tick adjustment to directly participate in address node location within the topology mapping space.

[0075] The header and checksum of the current data packet are stripped, and the remaining payload fields are extracted as the payload data. The stripping process removes data portions from the current data packet that are not written as the sensing payload; the extraction process uses the payload fields as the data content for subsequent byte sequence reassembly and writing to the characteristic address node. Through this process, the payload data is separated from the timing alignment identifier before writing, facilitating the separate entry of data content and timing relationships into the corresponding processing flows.

[0076] In some embodiments, to further illustrate the process of writing payload data to a feature address node, the process involves parsing the translation instruction sequence associated with the memory-mapped descriptor and, based on the translation instruction sequence and timing alignment identifier, writing the payload data to a specified feature address node within the topology mapping space. Specifically, this includes: Data sorting instructions are loaded from the sequence of translation instructions associated with the memory-mapped descriptor. This association can be established through the instruction index field or association field in the memory-mapped descriptor, enabling the underlying controller to find the corresponding sequence of translation instructions based on the memory-mapped descriptor. After loading the data sorting instructions, the underlying controller obtains the data sorting process that the payload data must follow before writing, thus associating the data format conversion process with the physical write area corresponding to the memory-mapped descriptor.

[0077] Following the data arrangement order adjustment instructions, a reverse order reassembly operation is performed on the byte sequence in the payload data to obtain the reassembled payload data. This reassembly operation rearranges multiple bytes in the payload data in the reverse order of their original arrangement. The reassembled payload data becomes the target data content written to the characteristic address node, thus ensuring that the data written to the topology mapping space has already undergone the appropriate format processing, reducing the burden on the business process to read and then convert it.

[0078] The corresponding target local index label is obtained by looking up the table based on the time alignment identifier. Then, the specified feature address node is determined in the structured topology mapping space based on the target local index label. The reassembled payload data is then transferred to this feature address node. The specified feature address node is determined by looking up the target local index label from the time alignment identifier. Through this process, payload data with corresponding time relationships can be written to the buffer slot corresponding to that time relationship, creating a direct connection between data content, time relationships, and feature address nodes.

[0079] In some embodiments, to further illustrate the process of obtaining the target local index label, the corresponding target local index label is obtained by looking up a table based on the time alignment identifier, specifically including: Timing alignment identifiers are input into a local time reference lookup table hard-coded in the underlying controller. This lookup table records the binding relationship between the reference clock cycle sequence and the target local index label. The local time reference lookup table hard-coded in the underlying controller can be pre-installed in the controller's firmware or underlying program. This local time reference lookup table is used to establish the correspondence between the time reference and the local index labels within the topology mapping space, enabling the time relationship to be directly converted into address node indexes at the underlying level.

[0080] The system clock cycle count value contained in the timing alignment identifier is compared with the reference clock cycle sequence in the local time base lookup table to determine the matching reference clock cycle node. The system clock cycle count value is the count information of the system clock cycle corresponding to the current data packet. The comparison process searches for the reference clock cycle node corresponding to this count information in the reference clock cycle sequence. This matching result is used to determine which target local index label's buffer slot the current payload data should fall into.

[0081] The target local index label bound to the matched reference clock cycle node is read as the lookup result. The read process obtains the target local index label bound to the reference clock cycle node from the local time base lookup table. This lookup result is used to locate the feature address node in the structured topology mapping space, enabling the business process to subsequently read the sensing data under the same time relationship as needed.

[0082] In some embodiments, to further illustrate the generation process of the unified addressing virtual pointer, a unified addressing virtual pointer pointing to the topology mapping space is generated in the system kernel of the underlying controller, specifically including: The underlying controller's memory management unit (MMU) device driver is invoked. The call processing can initiate the address mapping function of the MMU device driver through the driver interface in the system kernel. The MMU device driver is responsible for establishing the page mapping relationship between the hardware physical base address and the user-mode logical address space, enabling the topology mapping space in the system's physical memory to form a unified logical entry point accessible to business processes.

[0083] The hardware physical base address of the topology mapping space is obtained through the memory management unit device driver. This hardware physical base address represents the actual starting address of the topology mapping space in the system's physical memory and serves as the physical input for establishing page mapping relationships. Through this acquisition process, the underlying controller obtains the physical address basis that needs to be mapped to the user-mode logical address space, enabling subsequent page mapping relationships to directly point to the topology mapping space storing the effective payload data.

[0084] The control memory management unit (CMMU) device driver establishes a page mapping relationship from the hardware physical base address to the user-mode logical address space, and uses the page table entry access point corresponding to the page mapping relationship as a unified addressing virtual pointer to the topology mapping space. Control processing can involve the underlying controller issuing a mapping establishment command to the CMMU device driver. After the page mapping relationship is established, the page table entry access point can serve as a unified entry point for autonomous driving business processes to access the topology mapping space, eliminating the need for autonomous driving business processes to separately process the underlying physical addresses corresponding to different onboard sensors, and also eliminating the need to indirectly obtain data solely through upper-layer message queues.

[0085] In some embodiments, to further illustrate the real-time allocation process of payload data, payload data in feature address nodes is allocated to the autonomous driving service process in real time based on the unified addressing virtual pointer, specifically including: The system receives data subscription request messages from autonomous driving service processes, carrying a target data type identifier. The receiving and processing mechanism can obtain the data requests from the autonomous driving service processes through the system kernel or inter-process communication entry point. The target data type identifier characterizes the payload data type currently requested by the autonomous driving service process. Through this target data type identifier, the service process's subscription request can be mapped to a characteristic address node in the topology mapping space.

[0086] The target data type identifier in the data subscription request message is parsed, and the addressing process uses the unified addressing virtual pointer to locate the feature address node in the topology mapping space where the payload data is stored. The parsing process determines the data object requested by the autonomous driving service process, and the addressing process locates the feature address node containing that data object. Since the unified addressing virtual pointer already points to the topology mapping space, the underlying controller can direct the access path to the location of the corresponding payload data based on the storage relationship between the target data type identifier and the feature address node, thereby reducing the path length caused by multi-level encapsulation, subscription forwarding, and queue caching.

[0087] This triggers a zero-copy transfer from kernel mode to user mode, directly pushing the payload data from the feature address node to the independent application receive buffer of the autonomous driving service process, thus completing the real-time allocation of payload data to the autonomous driving service process. The trigger process initiates data transmission or address mapping delivery after locating the feature address node. The independent application receive buffer is used to receive the data subscribed to by the autonomous driving service process. Through zero-copy transfer from kernel mode to user mode, the underlying controller can reduce the generation of intermediate copies, enabling payload data to reach the receive buffer of the autonomous driving service process via a shorter path, thereby reducing the data distribution load when multiple sensors are accessed.

[0088] like Figure 3 As shown, this application provides an embodiment of a unified sensing adaptation interface construction device for vehicle sensors, which includes: The interrupt identification module is used to identify the hardware interrupt trigger source of the connected vehicle sensor and extract the hardware identification code from the continuous sensing data stream generated by the vehicle sensor. The mapping construction module is used to allocate corresponding memory mapping descriptors based on the hardware interrupt triggering source and the hardware identifier code, and to construct a structured topology mapping space in the system physical memory of the underlying controller according to the memory mapping descriptors; The data separation module is used to separate the timing alignment identifier and payload data from the continuous sensing data stream; The data writing module is used to parse the translation instruction sequence associated in the memory mapping descriptor, and write the payload data into the specified feature address node in the topology mapping space according to the translation instruction sequence and the timing alignment identifier. The data allocation module is used to generate a unified addressing virtual pointer pointing to the topology mapping space in the system kernel of the underlying controller, and to allocate the effective payload data in the feature address node to the autonomous driving business process in real time according to the unified addressing virtual pointer.

[0089] like Figure 4As shown, an electronic device according to an embodiment of this application includes a processor and a memory. The memory stores a computer program that can be executed by the processor. When the processor executes the computer program, it implements the vehicle sensor unified perception adaptation interface construction method according to any one of the claims of this application.

[0090] like Figure 5 As shown, a computer-readable storage medium is provided in an embodiment of this application. The computer-readable storage medium stores a computer program, which, when executed by a processor, implements the vehicle sensor unified perception adaptation interface construction method described in any one of the claims of this application.

[0091] like Figure 6 As shown, this is a vehicle according to an embodiment of the present application, which includes an on-board sensor, a low-level controller, and the on-board sensor unified perception adaptation interface construction device as described in claim 10. The on-board sensors are used to generate a continuous sensing data stream; The underlying controller is used to provide system physical memory and system kernel for the vehicle sensor unified perception adaptation interface construction device; The unified perception adaptation interface construction device for vehicle sensors is used to identify the hardware interrupt trigger source of the connected vehicle sensors, extract the hardware identifier code from the continuous perception data stream, allocate the corresponding memory mapping descriptor based on the hardware interrupt trigger source and the hardware identifier code, construct a structured topology mapping space in the system physical memory of the underlying controller according to the memory mapping descriptor, separate the timing alignment identifier and payload data from the continuous perception data stream, parse the conversion instruction sequence associated in the memory mapping descriptor, and write the payload data into the specified feature address node in the topology mapping space according to the conversion instruction sequence and the timing alignment identifier. A unified addressing virtual pointer pointing to the topology mapping space is generated in the system kernel of the underlying controller, and the payload data in the feature address node is allocated to the autonomous driving business process in real time according to the unified addressing virtual pointer.

[0092] like Figure 7 As shown, this is an embodiment of a unified perception adaptation interface construction system for vehicle sensors, which includes vehicle sensors, a low-level controller, and an autonomous driving business process. The on-board sensors are used to generate a continuous sensing data stream; The underlying controller is used to identify the hardware interrupt trigger source of the connected vehicle sensor, extract the hardware identifier code from the continuous sensing data stream, allocate the corresponding memory mapping descriptor based on the hardware interrupt trigger source and the hardware identifier code, construct a structured topology mapping space in the system physical memory of the underlying controller according to the memory mapping descriptor, separate the timing alignment identifier and the payload data from the continuous sensing data stream, parse the conversion instruction sequence associated in the memory mapping descriptor, and write the payload data into the specified feature address node in the topology mapping space according to the conversion instruction sequence and the timing alignment identifier, and generate a unified addressing virtual pointer pointing to the topology mapping space in the system kernel of the underlying controller. The autonomous driving service process is used to receive the payload data from the feature address nodes allocated in real time by the underlying controller based on the unified addressing virtual pointer.

[0093] The above Figures 3-7 For an exemplary description, please refer to the above. Figure 1 This will not be elaborated upon here.

Claims

1. A method for constructing a unified sensing adaptation interface for vehicle-mounted sensors, characterized in that, include: Identify the hardware interrupt trigger source of the connected vehicle sensor and extract the hardware identification code from the continuous sensing data stream generated by the vehicle sensor. Based on the hardware interrupt trigger source and the hardware identifier, a corresponding memory mapping descriptor is allocated, and a structured topology mapping space is constructed in the system physical memory of the underlying controller according to the memory mapping descriptor. Separate the timing alignment identifier and payload data from the continuous sensing data stream; The translation instruction sequence associated with the memory mapping descriptor is parsed, and the payload data is written into the specified feature address node in the topology mapping space according to the translation instruction sequence and the timing alignment identifier. In the system kernel of the underlying controller, a unified addressing virtual pointer is generated pointing to the topology mapping space, and the effective payload data in the feature address node is allocated to the autonomous driving business process in real time according to the unified addressing virtual pointer.

2. The method according to claim 1, characterized in that, The steps of identifying the hardware interrupt trigger source of the connected vehicle sensor and extracting the hardware identifier code from the continuous sensing data stream generated by the vehicle sensor include: Monitor the bus pin level transition events corresponding to the vehicle sensor in the underlying controller; When the bus pin level transition event is captured, the timestamp of the level transition edge is recorded as the hardware interrupt trigger source of the vehicle sensor; The starting data frame of the continuous sensing data stream is parsed, the physical address device number recorded in the frame header area of ​​the starting data frame is read, and the physical address device number is determined as the hardware identification code.

3. The method according to claim 2, characterized in that, The step of allocating a corresponding memory mapping descriptor based on the hardware interrupt trigger source and the hardware identifier code includes: Based on the hardware identification code, the corresponding device data bit width is retrieved from the pre-configured hardware configuration registry, which records the correspondence between the hardware identification code and the device data bit width. Based on the retrieved device data bit width, a physical memory block matching the device data bit width is allocated in the reserved isolated memory area of ​​the underlying controller; Based on the starting address of the physical memory block, the storage boundary length, and the hardware interrupt trigger source, a formatted data record is generated, and the formatted data record is identified as the memory mapping descriptor corresponding to the hardware interrupt trigger source and the hardware identifier.

4. The method according to claim 3, characterized in that, The step of constructing a structured topology mapping space in the system physical memory of the underlying controller according to the memory mapping descriptor includes: Read the starting address and the storage boundary length recorded in the memory mapping descriptor; A continuous physical address range is determined in the system physical memory of the underlying controller by the starting address and the storage boundary length, and a multidimensional circular buffer is established within this continuous physical address range; An incremental local index label is assigned to each buffer slot in the multidimensional circular buffer, thereby forming the structured topology mapping space corresponding to the memory mapping descriptor.

5. The method according to claim 1, characterized in that, The step of separating the timing alignment identifier and payload data from the continuous sensing data stream includes: Based on the preset data frame structure definition, the current data packet in the continuous sensing data stream is parsed. The data frame structure definition is used to identify the message header, payload field and checksum tail of the current data packet. According to the data frame structure definition, the global timestamp field in the header of the current data packet is extracted, and the global timestamp field is determined as the timing alignment identifier; The header and checksum of the current data packet are stripped, and the remaining payload fields are extracted as the payload data.

6. A device for constructing a unified sensing adaptation interface for vehicle-mounted sensors, characterized in that, include: The interrupt identification module is used to identify the hardware interrupt trigger source of the connected vehicle sensor and extract the hardware identification code from the continuous sensing data stream generated by the vehicle sensor. The mapping construction module is used to allocate corresponding memory mapping descriptors based on the hardware interrupt triggering source and the hardware identifier code, and to construct a structured topology mapping space in the system physical memory of the underlying controller according to the memory mapping descriptors; The data separation module is used to separate the timing alignment identifier and the payload data from the continuous sensing data stream; The data writing module is used to parse the translation instruction sequence associated in the memory mapping descriptor, and write the payload data into the specified feature address node in the topology mapping space according to the translation instruction sequence and the timing alignment identifier. The data allocation module is used to generate a unified addressing virtual pointer pointing to the topology mapping space in the system kernel of the underlying controller, and to allocate the effective payload data in the feature address node to the autonomous driving business process in real time according to the unified addressing virtual pointer.

7. An electronic device, characterized in that, It includes a processor and a memory, the memory storing a computer program that can be executed by the processor, and the processor executing the computer program implements the vehicle sensor unified perception adaptation interface construction method according to any one of claims 1 to 5.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the vehicle sensor unified perception adaptation interface construction method according to any one of claims 1 to 5.

9. A vehicle, characterized in that, It includes on-board sensors, a low-level controller, and the on-board sensor unified perception adaptation interface construction device as described in claim 10; The on-board sensors are used to generate a continuous sensing data stream; The underlying controller is used to provide system physical memory and system kernel for the vehicle sensor unified perception adaptation interface construction device; The unified perception adaptation interface construction device for vehicle sensors is used to identify the hardware interrupt trigger source of the connected vehicle sensors, extract the hardware identifier code from the continuous perception data stream, allocate the corresponding memory mapping descriptor based on the hardware interrupt trigger source and the hardware identifier code, construct a structured topology mapping space in the system physical memory of the underlying controller according to the memory mapping descriptor, separate the timing alignment identifier and payload data from the continuous perception data stream, parse the conversion instruction sequence associated in the memory mapping descriptor, and write the payload data into the specified feature address node in the topology mapping space according to the conversion instruction sequence and the timing alignment identifier. A unified addressing virtual pointer pointing to the topology mapping space is generated in the system kernel of the underlying controller, and the payload data in the feature address node is allocated to the autonomous driving business process in real time according to the unified addressing virtual pointer.

10. A unified sensing adaptation interface construction system for vehicle-mounted sensors, characterized in that, This includes onboard sensors, underlying controllers, and autonomous driving business processes. The on-board sensors are used to generate a continuous sensing data stream; The underlying controller is used to identify the hardware interrupt trigger source of the connected vehicle sensor, extract the hardware identifier code from the continuous sensing data stream, allocate the corresponding memory mapping descriptor based on the hardware interrupt trigger source and the hardware identifier code, construct a structured topology mapping space in the system physical memory of the underlying controller according to the memory mapping descriptor, separate the timing alignment identifier and the payload data from the continuous sensing data stream, parse the conversion instruction sequence associated in the memory mapping descriptor, and write the payload data into the specified feature address node in the topology mapping space according to the conversion instruction sequence and the timing alignment identifier, and generate a unified addressing virtual pointer pointing to the topology mapping space in the system kernel of the underlying controller. The autonomous driving service process is used to receive the payload data from the feature address nodes allocated in real time by the underlying controller based on the unified addressing virtual pointer.

Images