A kind of computing power adaptive vehicle CAN signal acquisition method and system

Abstract

The application relates to a computing power adaptive vehicle CAN signal collection method and system, computer equipment and a computer readable storage medium. A full-quantity signal description file is loaded on a vehicle-mounted local edge computing node, a required signal set is derived from a data analysis task, and a dynamic white list with a version number is generated. The dynamic white list is pushed down to a CAN decoding link. When a stream processing receives a message, the identification is compared with the dynamic white list. Decoding is only performed on signals contained in the white list. Messages not contained in the white list are skipped. When a task is changed, a cache mapping is reconstructed according to the version number. The problems that a cut signal description file needs to be issued according to a vehicle type, vehicle-mounted computing power is limited, full-quantity decoding efficiency is low, and a static configuration cannot be adaptively adjusted in the related art are solved. The technical effects that the decoding and collection computing power dynamically expand with the actual required signal set, the decoding computing power is saved at the source, and the collection range is adaptively adjusted according to upper-layer requirements.

Description

Technical Field

[0001] This application relates to the field of vehicle information acquisition, and in particular to a computing power-adaptive method, system, computer device, and computer-readable storage medium for acquiring vehicle CAN signals. Background Technology

[0002] With the development of vehicle-to-everything (V2X) and intelligent driving, vehicles continuously broadcast massive amounts of signal data via the Controller Area Network (CAN) bus. Onboard information terminals or gateways need to collect these signals locally, process them as necessary, and then report them to the cloud or use them for local analysis. The semantics of CAN signals are defined by a signal description file, which describes the identifier, start bit, length, endianness, scaling factor, and multiplexer structure of each signal in each message.

[0003] In related technologies, the CAN signal definitions vary greatly among different manufacturers and vehicle models. Typically, a server generates a trimmed description file based on the data acquisition item or vehicle model before sending it to the terminal. Each time a new vehicle model is added or the data acquisition item is adjusted, the file must be regenerated and sent, resulting in delayed adaptation and high maintenance costs. Onboard computing power is limited. If the terminal resident with full description files covering multiple vehicle models to adapt to all models, decoding operations are often performed on all messages and signals during frame-by-frame processing. The decoding computation load is proportional to the file size, consuming significant processor and memory resources, making it difficult to guarantee real-time processing of high-throughput data streams. Furthermore, the signals to be acquired are often pre-configured manually. When upper-layer analysis tasks change, the actual range of decoded and acquired signals cannot be automatically adjusted, and configuration filtering usually occurs during transmission, failing to save terminal decoding computing power at the source.

[0004] Currently, no effective solution has been proposed to address the low efficiency of vehicle CAN signal acquisition methods in related technologies. Summary of the Invention

[0005] This application provides a computing power-adaptive vehicle CAN signal acquisition method, system, computer device, and computer-readable storage medium to at least solve the problem of low efficiency in related technologies for vehicle CAN signal acquisition.

[0006] In a first aspect, embodiments of this application provide a vehicle CAN signal acquisition method with adaptive computing power, the method being applied to an on-board local edge computing node, the method comprising: The on-board local edge computing node loads a full signal description file covering the target vehicle model, wherein the full signal description file contains the parsing rules for all messages and signals of the target vehicle model; The system acquires the data analysis task running on the vehicle-mounted local edge computing node, derives the required signal set from the signals actually referenced by the data analysis task, and generates a dynamic whitelist with version numbers. The dynamic whitelist is pushed down to the CAN decoding stage. When the received CAN messages are processed in a time-sequential streaming manner, the CAN message identifier is compared with the dynamic whitelist. If the message contains signals from the dynamic whitelist, then according to the parsing rules in the full signal description file, the signals from the dynamic whitelist are decoded and the acquisition results are generated; if the message does not contain signals from the dynamic whitelist, then decoding is skipped. When the data analysis task changes, causing the version number of the dynamic whitelist to change, the old cache mapping is invalidated, and the decoding mapping is reconstructed according to the changed dynamic whitelist.

[0007] In some embodiments, if the message contains signals from the dynamic whitelist, then performing decoding operations on the signals from the dynamic whitelist includes: Determine whether the CAN message containing signals from the dynamic whitelist is a message containing a multiplexer; If so, the multiplexer selector in the CAN message is decoded to obtain the current multiplexing value; The current multiplexing value is matched with the preset multiplexing conditions of the multiplexed signal, the multiplexed signal that matches the current multiplexing value and is included in the dynamic whitelist is decoded, and the decoding of other multiplexed signals that do not match or are not in the whitelist is skipped.

[0008] In some embodiments, comparing the CAN message identifier with the dynamic whitelist, and skipping decoding if the message does not contain a signal in the dynamic whitelist, includes: When pushing down the dynamic whitelist, a first-level filter bitmap is dynamically constructed in memory for standard CAN frames, and a second-level filter structure is constructed for extended CAN frames. When streaming the received CAN message, the CAN message identifier is directly used as the physical offset in memory; The CAN message identifier is checked by bitwise operations to see if it is matched in the first-level filter bitmap or the second-level filter structure. If it is not matched, it is determined that the message does not contain the signal in the dynamic whitelist, and the decoding process of the full message of the frame is skipped at the memory level.

[0009] In some embodiments, the step of acquiring the data analysis task running on the vehicle-mounted local edge computing node, deriving the required signal set from the signals actually referenced by the data analysis task, and generating a dynamic whitelist with version numbers includes: Perform a plan analysis on the data analysis task, and iterate through the signal names referenced in the data analysis task; When there are multiple data analysis tasks, the union of the signals required by each data analysis task is extracted as the set of required signals; The required signal set is bound to the currently generated version number to generate the dynamic whitelist.

[0010] In some embodiments, performing decoding operations on the signals within the dynamic whitelist and generating acquisition results further includes: Establish the mapping relationship between signals and output slots in the full signal description file; The physical values ​​are extracted based on the start bit, length, byte order and scaling factor of the signals in the dynamic whitelist, and the decoded physical values ​​are written into the corresponding output slots according to the mapping relationship. Generate a narrow row output with a row width equal to the width of the union of the required signal sets in the dynamic whitelist.

[0011] In some embodiments, the step of streaming the received CAN messages in a time-sequential manner further includes: In the mode of batch collection with a preset collection window, record the multiple occurrences of the same message or the same message combined with a multiplexed value within the collection window; The messages that appear repeatedly within the acquisition window are traversed in reverse order of their reception time, and the latest received message frame is decoded.

[0012] In some embodiments, when the data analysis task changes, causing a version number change in the dynamic whitelist, invalidating the old cache mapping and reconstructing the decoding mapping according to the changed dynamic whitelist includes: When streaming the next frame of the CAN message, check whether the version number of the currently derived dynamic whitelist is consistent with the version number cached in the CAN decoding stage; If there is a discrepancy, invalidate the cache mapping from the old local whitelist to the structure required for decoding; The column mask and output slot mapping table of the required signals are recalculated based on the revised dynamic whitelist, and the new mapping relationship and the corresponding version number are rewritten into the cache.

[0013] Secondly, embodiments of this application provide a vehicle CAN signal acquisition system with adaptive computing power, the system comprising: The loading module is used to load a full signal description file covering the target vehicle model on the vehicle-mounted local edge computing node, wherein the full signal description file contains the parsing rules for all messages and signals of the target vehicle model; The acquisition module is used to acquire the data analysis task running on the vehicle-mounted local edge computing node, deduce the required signal set from the signals actually referenced by the data analysis task, and generate a dynamic whitelist with a version number. The message processing module is used to push the dynamic whitelist down to the CAN decoding stage. When processing the received CAN messages in a time-sequential streaming manner, the CAN message identifier is compared with the dynamic whitelist. If the message contains signals in the dynamic whitelist, the decoding operation is performed on the signals in the dynamic whitelist according to the corresponding parsing rules in the full signal description file and the acquisition result is generated. If the message does not contain signals in the dynamic whitelist, the decoding is skipped. The optimization module is used to invalidate the old cache mapping and reconstruct the decoding mapping according to the changed dynamic whitelist when the data analysis task changes and the version number of the dynamic whitelist changes.

[0014] Thirdly, embodiments of this application provide a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the method described in the first aspect above.

[0015] Fourthly, embodiments of this application provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method described in the first aspect above.

[0016] Compared to related technologies, the vehicle CAN signal acquisition method, system, computer device, and computer-readable storage medium with adaptive computing power provided in this application load a full signal description file on the vehicle's local edge computing node, derives the required signal set from the data analysis task, generates a dynamic whitelist with version numbers, and pushes the dynamic whitelist down to the CAN decoding stage. During streaming message reception, the identifier is compared with the dynamic whitelist, and decoding is performed only on signals included in the whitelist; messages not included in the whitelist are skipped. Furthermore, the cache mapping is reconstructed according to the version number when the task changes. This solves the problems in related technologies, such as the need to distribute trimmed signal description files according to vehicle model, low full decoding efficiency due to limited vehicle computing power, and the inability to adaptively adjust static configurations. This application enables the decoding computation of the underlying CAN messages to dynamically scale according to the actual required signal set, thereby significantly saving the decoding computing power of the vehicle's edge computing node at the source. Simultaneously, the system's acquisition range can adaptively adjust to changes in the needs of the upper-layer data analysis task, avoiding wasted computing power and the transmission of invalid data. Attached Figure Description

[0017] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 This is a flowchart of a vehicle CAN signal acquisition method with adaptive computing power according to an embodiment of this application; Figure 2 This is a structural block diagram of a computing power adaptive vehicle CAN signal acquisition system according to an embodiment of this application; Figure 3 This is a schematic diagram of the operation flow of a vehicle CAN signal acquisition system with adaptive computing power according to an embodiment of this application; Figure 4 This is a schematic diagram of the internal structure of a computer device according to an embodiment of this application. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of this application clearer, the application is described and illustrated below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application. All other embodiments obtained by those skilled in the art based on the embodiments provided in this application without inventive effort are within the scope of protection of this application.

[0019] Obviously, the accompanying drawings described below are merely some examples or embodiments of this application. Those skilled in the art can apply this application to other similar scenarios based on these drawings without any creative effort. Furthermore, it is understood that although the efforts made in this development process may be complex and lengthy, for those skilled in the art related to the content disclosed in this application, any changes to design, manufacturing, or production based on the technical content disclosed in this application are merely conventional technical means and should not be construed as insufficient disclosure of this application.

[0020] In this application, the reference to "embodiment" means that a specific 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 in the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment that is mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described in this application may be combined with other embodiments without conflict.

[0021] Unless otherwise defined, the technical or scientific terms used in this application shall have the ordinary meaning understood by one of ordinary skill in the art to which this application pertains. The terms “a,” “an,” “an,” “the,” and similar words used in this application do not indicate quantity limitation and may indicate singular or plural. The terms “comprising,” “including,” “having,” and any variations thereof used in this application are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or device that includes a series of steps or modules (units) is not limited to the listed steps or units, but may also include steps or units not listed, or may include other steps or units inherent to these processes, methods, products, or devices. The terms “connected,” “linked,” “coupled,” and similar words used in this application are not limited to physical or mechanical connections, but may include electrical connections, whether direct or indirect. “Multiple” used in this application refers to two or more. “And / or” describes the relationship between related objects, indicating that three relationships may exist; for example, “A and / or B” can represent: A alone, A and B simultaneously, and B alone. The character " / " generally indicates that the preceding and following objects are in an "or" relationship. The terms "first," "second," and "third" used in this application are merely to distinguish similar objects and do not represent a specific ordering of the objects.

[0022] In order to better understand the technical essence of this application, the defects existing in the prior art will be specifically analyzed.

[0023] In a common vehicle-to-everything (V2X) data collection scheme, a cloud server typically pre-generates tailored signal description files based on specific collection items or vehicle models and then distributes them to the in-vehicle terminal. In this scheme, the terminal primarily determines whether a signal is uploaded based on manually configured flags (such as upload suffixes), and the data filtering mechanism actually occurs at the "data transmission layer." This means that regardless of whether certain signals ultimately need to be reported, the in-vehicle edge node will still perform decoding operations on all received messages, discarding unnecessary data only during the final transmission stage. This approach not only fails to save the terminal's decoding computing power at the source but also significantly consumes the limited processor and memory resources of the in-vehicle system. Furthermore, because the collection scope is highly dependent on manual static configuration, once the upper-layer vehicle data analysis tasks change, a new configuration file must be regenerated and distributed from the cloud, resulting in severe response delays and high maintenance costs.

[0024] In another existing vehicle data acquisition architecture, the system mainly collects data based on predefined static rules. It does not establish a linkage mechanism for the upper-layer business logic (such as specific streaming queries or statistical tasks) to automatically deduce the underlying signal acquisition set, nor does it introduce a dynamic whitelist in the underlying decoding stage to skip invalid decoding.

[0025] Furthermore, even if some existing solutions achieve dynamic processing and distribution of heterogeneous vehicle messages, their processing rules are mostly limited to the upper message distribution layer and do not delve into the underlying decoding stage of the CAN bus. They lack the technical means to drive the automatic reconstruction of the underlying decoding mapping through a dynamic whitelist with version control mechanism, thereby achieving adaptive scaling of computing power.

[0026] In summary, existing technologies generally face technical bottlenecks such as high costs for adapting to multiple vehicle models, significant waste of computing power due to full vehicle decoding, and the inability of static acquisition configurations to adaptively adjust to upper-layer business needs. To overcome these shortcomings, this application proposes a technical architecture that can save computing power at the decoding source and automatically scale according to upper-layer task requirements.

[0027] The various technologies described in this application can be used in vehicle-to-everything (V2X) data acquisition and in-vehicle edge computing systems. The system provided in this embodiment can be integrated into a high-performance electronic control unit, a dedicated in-vehicle gateway, or an in-vehicle information terminal, on which a local streaming computing engine runs, responsible for performing analysis tasks and driving CAN signal acquisition.

[0028] This embodiment provides a vehicle CAN signal acquisition method with adaptive computing power. Figure 1 This is a flowchart of a vehicle CAN signal acquisition method with adaptive computing power according to an embodiment of this application. Figure 1 As shown, the process includes the following steps: S101, Load the full signal description file covering the target vehicle model on the vehicle local edge computing node. The full signal description file contains the parsing rules for all messages and signals of the target vehicle model.

[0029] Specifically, after the software starts, it loads one or more signal description files covering the target vehicle model from local storage as a full signal description. The description file defines the message and its data length, sending node, and other information such as the signal's start bit, length, byte order and sign, scaling factor and offset, value range, and unit using specific fields. For example, the description file may contain a message with an identifier of 256 and a data length of 8 bytes, as well as an engine speed signal with a start bit of 7, a length of 16 bits, big-endian byte order, unsigned, and a scaling factor of 0.25.

[0030] For example, the content of a DBC file is as follows: VERSION "" BU_ ECU1 ECU2 GW BO_256 EngineData: 8 ECU1 SG_ EngineRPM: 7|16@0+ (0.25,0) [0|16383.75] "rpm" GW SG_ EngineTemp : 23|8@0+ (1,-40) [-40|215] "degC" GW BO_ 512 VehicleStatus: 8 ECU2 SG_ VehicleSpeed: 7|16@0+ (0.01,0) [0|655.35] "km / h" GW SG_ GearPosition : 23|4@0+ (1,0) [0|15] "" GW BO_768 BatteryInfo: 8 ECU2 SG_ MuxSelector M : 7|8@0+ (1,0) [0|255] "" GW SG_ CellVoltage m0 : 15|16@0+ (0.001,0) [0|65.535] "V" GW SG_ CellTemp m1 : 15|8@0+ (1,-40) [-40|215] "degC" GW Where BO_256 represents the EngineData message with CAN ID 256 (0x100), and a data length of 8 bytes; SG_EngineRPM: 7|16@0+ (0.25,0) indicates that the EngineRPM signal has a start bit of 7, a length of 16 bits, @0 for big-endian (Motorola) byte order, + for unsigned, a scaling factor of 0.25, and an offset of 0. The BatteryInfo message contains a multiplexer: MuxSelector M is the multiplexer selector, and CellVoltage m0 and CellTemp m1 are the multiplexed signals that are only valid when the multiplexing value is 0 and 1, respectively.

[0031] It is understandable that this message set may also include messages with multiplexers, including multiplexer selectors and multiplexed signals that are valid under specific multiplexing values. Adapting to the target vehicle model can be achieved by deploying and loading the above files once. Differences between vehicle models and the data collection project are resolved locally through subsequent dynamic whitelisting, avoiding the need to distribute trimmed files based on vehicle models.

[0032] S102: Obtain the data analysis task running on the vehicle-mounted local edge computing node, deduce the required signal set from the signals actually referenced by the data analysis task, and generate a dynamic whitelist with version numbers.

[0033] Specifically, it retrieves one or more data analysis tasks running on a local streaming computing engine, where the tasks include streaming queries, statistics, or collection rules.

[0034] Analysis tasks reference the signals they actually need using signal names. For example, a streaming query rule would look like this: SELECT VehicleSpeed, EngineRPM FROM can_stream WHERE VehicleSpeed>60 The data analysis task is planned and analyzed, traversing the referenced columns and signal names to automatically collect the signal set actually needed for the task. When multiple data analysis tasks exist, the union of the signals required by each task is extracted as the required signal set. The required signal set is bound to the currently generated version number to generate a dynamic whitelist containing an internal version identifier and an array of required signal column names. In this embodiment, one internal representation of the whitelist is "required signal set + version number", for example: { "version": 7, "columns": ["EngineRPM", "VehicleSpeed"]} It is understood that in this embodiment, the content of the whitelist is automatically derived and generated as the analysis task changes, rather than relying on manual configuration for each signal. Its content changes with the analysis task, and the version number is used to identify the current content. When multiple analysis tasks exist, the whitelist is the union of the signals required by each task.

[0035] S103 pushes the dynamic whitelist down to the CAN decoding stage. When the received CAN messages are processed in a time-sequential streaming manner, the CAN message identifier is compared with the dynamic whitelist.

[0036] Specifically, the whitelist is pushed down to the CAN decoding stage, and the column masks of the required signals, output slot mapping tables, and other decoding structures are cached using the version number as the key. The system connects to the CAN bus and streams received messages in chronological order.

[0037] When implementing a push-state whitelist, a first-level filtering bitmap is dynamically constructed in memory for standard CAN frames, and a second-level filtering structure, such as a Bloom filter or hash bitset, is constructed for extended CAN frames. During streaming processing, the CAN message identifier is directly read and used as a physical offset in memory. Bitwise operations are then used to check whether the identifier matches in the first-level filtering bitmap or the second-level filtering structure. This process transforms the logical-level comparison into a single bit operation based on hardware memory address offsets, eliminating the processor overhead caused by loop traversal and conditional branches. Simultaneously, when parsing the outer packet, the frame position is recorded with the identifier, offset, and length, and the frame is referenced back to the original buffer, providing zero-copy message references to avoid frame-by-frame data copying.

[0038] If the message contains signals from the dynamic whitelist, the decoding operation is performed on the signals in the dynamic whitelist according to the corresponding parsing rules in the full signal description file, and the acquisition result is generated. If the message does not contain signals from the dynamic whitelist, decoding is skipped. Specifically, when a bitwise operation detects a miss, it is determined that all signals in the message are not in the whitelist, indicating that the acquisition task does not need the message signals. The full message decoding process is skipped directly at the memory level, and no decoding operation is performed to save terminal computing power at the source. When a hit occurs, it is determined whether the message contains a multiplexer. If it is a message containing a multiplexer, the multiplexer selector is decoded to obtain the current multiplexing value. The current multiplexing value is matched with the preset multiplexing conditions of the multiplexed signals. Only the multiplexed signals that match the current multiplexing value and are included in the dynamic whitelist are decoded. Other multiplexed signals that do not match or are not in the whitelist are left empty and not decoded.

[0039] For ordinary messages, physical values ​​are extracted from the data payload based on the signal start bit, length, byte order, and scaling factor. Signals not in the whitelist within the same message are not decoded. A mapping relationship is established between signals in the full signal description file and output slots. The decoded physical values ​​are written into the corresponding output slots according to the mapping relationship, generating narrow-line output results with a line width equal to the width of the union of the required signal sets. This is used for local analysis or reporting to the cloud, reducing memory usage and uplink bandwidth.

[0040] In addition, in the mode of batch acquisition with a preset acquisition window, the system records the multiple occurrences of the same message or the same message combined with the multiplexing value within the acquisition window. The system traverses the duplicate messages within the window in reverse order of reception time, and performs decoding operations only on the latest received frame according to the valid semantics of the latest frame, thus avoiding unnecessary decoding of the overwritten old frames.

[0041] S104: When changes in the data analysis task lead to a change in the version number of the dynamic whitelist, the old cache mapping is invalidated, and the decoding mapping is reconstructed according to the changed dynamic whitelist.

[0042] Specifically, when local analysis tasks change, such as adding or deleting query rules, requiring a re-derived set of signals, changes to the whitelist content trigger version number increments. During streaming processing of the next CAN message frame, the system checks if the currently derived version number matches the cached version number. If they don't match, the cached mapping from the old local whitelist to the required decoding structure is invalidated. Based on the changed dynamic whitelist, the column mask and output slot mapping table for the required signals are recalculated, and the new mapping relationship and corresponding version number are rewritten to the cache. This allows the actual decoding range to dynamically scale as needed, without requiring a restart of data acquisition or a re-deployment of the description file.

[0043] Through steps S101 to S104 above, compared to conventional technologies that rely on servers to generate trimmed files, distribute them to terminals, and filter them at the transport layer, this embodiment uses a resident full description file, pushes filtering down to the decoding calculation layer, completely avoids decoding outside the whitelist, and adaptively reconstructs the file at runtime using a version number mechanism when analyzing task changes, thus solving the technical bottlenecks of resource consumption and adaptation lag. Furthermore, compared to existing methods that only use predefined static acquisition configurations or focus solely on message distribution layer rules for heterogeneous vehicle messages, this embodiment establishes an automatic signal set derivation, bitwise-level skip decoding, and narrow-line output mechanism, meeting the high-throughput data stream processing requirements with limited computing power. Moreover, if new vehicle model signals need to be included, the loaded full signal description file can be updated via OTA (Over-The-Air) updates. After the update, the whitelist mechanism automatically takes effect, and local dynamic trimming will automatically match the required subset for the target vehicle model based on the task, exhibiting high compatibility and scalability.

[0044] This embodiment also provides a vehicle CAN signal acquisition system with adaptive computing power. Figure 2 This is a structural block diagram of a computing power-adaptive vehicle CAN signal acquisition system according to an embodiment of this application, as shown below. Figure 2 As shown, the system includes: The loading module 20 is used to load a full signal description file covering the target vehicle model on the vehicle local edge computing node. The full signal description file contains the parsing rules for all messages and signals of the target vehicle model. The acquisition module 21 is used to acquire data analysis tasks running on the vehicle-mounted local edge computing node, deduce the required signal set from the signals actually referenced by the data analysis tasks, and generate a dynamic whitelist with version numbers. The message processing module 22 is used to push the dynamic whitelist down to the CAN decoding stage. When the received CAN messages are processed in a time-sequential streaming manner, the CAN message identifier is compared with the dynamic whitelist. If the message contains signals in the dynamic whitelist, the decoding operation is performed on the signals in the dynamic whitelist according to the corresponding parsing rules in the full signal description file and the acquisition result is generated. If the message does not contain signals in the dynamic whitelist, the decoding is skipped. Optimization module 23 is used to invalidate the old cache mapping and reconstruct the decoding mapping according to the changed dynamic whitelist when the version number of the dynamic whitelist changes due to changes in the data analysis task.

[0045] also, Figure 3 This is a schematic diagram of the operation flow of a computing power adaptive vehicle CAN signal acquisition system according to an embodiment of this application.

[0046] This system addresses the issues in related technologies, such as the need to distribute tailored signal description files based on vehicle models, low full-scale decoding efficiency due to limited onboard computing power, and the inability to adaptively adjust static configurations. It enables the computational load of decoding and acquisition to dynamically scale according to the actual required signal set, saving decoding computing power at the source and adaptively adjusting the acquisition range according to upper-level requirements.

[0047] Furthermore, in conjunction with the methods described in the above embodiments, this application embodiment can provide a computer device for implementation. This device may include a processor and a memory storing computer program instructions. The processor may include a central processing unit or a specific integrated circuit. The memory may include a mass storage device. The processor reads and executes the program instructions stored in the memory to implement the computing power adaptive vehicle CAN signal acquisition method described in the above embodiments.

[0048] In one embodiment, Figure 4 This is a schematic diagram of the internal structure of a computer device according to an embodiment of this application, such as... Figure 4 As shown, a computer device is provided, which may be a server, and its internal structure diagram may be as follows. Figure 4 As shown, the computer device includes a processor, a network interface, internal memory, and non-volatile memory connected via an internal bus. The non-volatile memory stores the operating system, computer programs, and a database. The processor provides computing and control capabilities, the network interface communicates with external terminals via a network connection, the internal memory provides an environment for the operating system and computer programs to run, the computer programs are executed by the processor to implement a computing power-adaptive vehicle CAN signal acquisition method, and the database stores data.

[0049] Those skilled in the art will understand that Figure 4 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0050] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0051] The technical features of the embodiments described above can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification. The embodiments described above only illustrate several implementation methods of this application, and their descriptions are relatively specific and detailed, but they should not be construed as limiting the scope of the invention patent.

[0052] It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the scope of protection of this application. Therefore, the scope of protection of this patent application shall be determined by the appended claims.

Claims

1. A vehicle CAN signal acquisition method with adaptive computing power, characterized in that, The method is applied to an on-board local edge computing node, and the method includes: The on-board local edge computing node loads a full signal description file covering the target vehicle model, wherein the full signal description file contains the parsing rules for all messages and signals of the target vehicle model; The system acquires the data analysis task running on the vehicle-mounted local edge computing node, derives the required signal set from the signals actually referenced by the data analysis task, and generates a dynamic whitelist with version numbers. The dynamic whitelist is pushed down to the CAN decoding stage. When the received CAN messages are processed in a time-sequential streaming manner, the CAN message identifier is compared with the dynamic whitelist. If the message contains signals from the dynamic whitelist, then according to the parsing rules in the full signal description file, the signals from the dynamic whitelist are decoded and the acquisition results are generated; if the message does not contain signals from the dynamic whitelist, then decoding is skipped. When the data analysis task changes, causing the version number of the dynamic whitelist to change, the old cache mapping is invalidated, and the decoding mapping is reconstructed according to the changed dynamic whitelist.

2. The method according to claim 1, characterized in that, The decoding operation on the signals in the dynamic whitelist includes: Determine whether the CAN message containing signals from the dynamic whitelist is a message containing a multiplexer; If so, the multiplexer selector in the CAN message is decoded to obtain the current multiplexing value; The current multiplexing value is matched with the preset multiplexing conditions of the multiplexed signal, the multiplexed signal that matches the current multiplexing value and is included in the dynamic whitelist is decoded, and the decoding of other multiplexed signals that do not match or are not in the whitelist is skipped.

3. The method according to claim 2, characterized in that, The step of comparing the CAN message identifier with the dynamic whitelist includes: When pushing down the dynamic whitelist, a first-level filter bitmap is dynamically constructed in memory for standard CAN frames, and a second-level filter structure is constructed for extended CAN frames. When streaming the received CAN message, the CAN message identifier is directly used as the physical offset in memory; The CAN message identifier is checked by bitwise operations to see if it is matched in the first-level filter bitmap or the second-level filter structure. If it is not matched, it is determined that the message does not contain the signal in the dynamic whitelist, and the decoding process of the full message of the frame is skipped at the memory level.

4. The method according to claim 1, characterized in that, The process of acquiring the data analysis task running on the vehicle-mounted local edge computing node, deriving the required signal set from the signals actually referenced by the data analysis task, and generating a dynamic whitelist with version numbers includes: Perform a plan analysis on the data analysis task, and iterate through the signal names referenced in the data analysis task; When there are multiple data analysis tasks, the union of the signals required by each data analysis task is extracted as the set of required signals; The required signal set is bound to the currently generated version number to generate the dynamic whitelist.

5. The method according to claim 4, characterized in that, The step of performing decoding operations on signals within the dynamic whitelist and generating acquisition results also includes: Establish the mapping relationship between signals and output slots in the full signal description file; The physical values ​​are extracted based on the start bit, length, byte order and scaling factor of the signals in the dynamic whitelist, and the decoded physical values ​​are written into the corresponding output slots according to the mapping relationship. Generate a narrow row output with a row width equal to the width of the union of the required signal sets in the dynamic whitelist.

6. The method according to claim 1, characterized in that, The process of streaming the received CAN messages in chronological order also includes: In the mode of batch collection with a preset collection window, record the multiple occurrences of the same message or the same message combined with a multiplexed value within the collection window; The messages that appear repeatedly within the acquisition window are traversed in reverse order of their reception time, and the decoding operation is performed only on the most recently received message frame.

7. The method according to claim 1, characterized in that, When the data analysis task changes, causing a version number change in the dynamic whitelist, the old cache mapping is invalidated, and the decoding mapping is reconstructed according to the changed dynamic whitelist, including: When streaming the next frame of the CAN message, check whether the version number of the currently derived dynamic whitelist is consistent with the version number cached in the CAN decoding stage; If there is a discrepancy, invalidate the cache mapping from the old local whitelist to the structure required for decoding; The column mask and output slot mapping table of the required signals are recalculated based on the revised dynamic whitelist, and the new mapping relationship and the corresponding version number are rewritten into the cache.

8. A vehicle CAN signal acquisition system with adaptive computing power, characterized in that, The system includes: The loading module is used to load a full signal description file covering the target vehicle model on the vehicle-mounted local edge computing node, wherein the full signal description file contains the parsing rules for all messages and signals of the target vehicle model; The acquisition module is used to acquire data analysis tasks running on the vehicle-mounted local edge computing node, deduce the required signal set from the signals actually referenced by the data analysis tasks, and generate a dynamic whitelist with version numbers. The message processing module is used to push the dynamic whitelist down to the CAN decoding stage. When processing the received CAN messages in a time-sequential streaming manner, the CAN message identifier is compared with the dynamic whitelist. If the message contains signals in the dynamic whitelist, the decoding operation is performed on the signals in the dynamic whitelist according to the corresponding parsing rules in the full signal description file and the acquisition result is generated. If the message does not contain signals in the dynamic whitelist, the decoding is skipped. The optimization module is used to invalidate the old cache mapping and reconstruct the decoding mapping according to the changed dynamic whitelist when the data analysis task changes and the version number of the dynamic whitelist changes.

9. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1 to 7.

Images