Can signal stream processing method and system based on cloud and zero-copy shared memory

Abstract

The application discloses a CAN signal stream processing method and system based on cloud and zero-copy shared memory, belongs to the technical field of CAN bus signal processing, and solves the problems of high processing delay, large CPU consumption and the inability of a decoder to be independently hot-updated caused by serialization and multiple memory copying of an existing scheme. A cloud compiling platform generates decoder code, shared memory layout definition and stream processing mode definition based on a unified data model definition file and distributes the decoder code, the shared memory layout definition and the stream processing mode definition to a vehicle terminal device. The vehicle terminal loads the decoder into a process by using anonymous memory, realizes shared memory lock-free concurrent access by using a ring buffer and atomic operation, stores CAN data decoded by the decoder into shared memory, and a stream processing process reads shared memory data in a cross-language zero-copy mode. The application replaces a message queue middleware with shared memory, eliminates serialization and data copying, reduces end-to-end delay and CPU consumption, realizes decoder hot-updating, and is suitable for intelligent automobile CAN signal real-time stream processing.

Description

Technical Field

[0001] This invention relates to the field of CAN bus signal processing technology in intelligent connected vehicle data closed-loop platform, specifically to a CAN signal streaming processing method, system, and storage medium based on cloud and zero-copy shared memory. Background Technology

[0002] In the data closed-loop platform of intelligent connected vehicles, the CAN bus signal is one of the most critical data sources. The CAN bus carries real-time communication data between various electronic control units (ECUs) in the vehicle, covering key operating parameters such as vehicle speed, engine speed, steering angle, battery status, and fault diagnostic codes. Efficient decoding and real-time streaming processing of CAN signals are fundamental to realizing higher-level applications such as vehicle status monitoring, fault warning, and rule triggering.

[0003] Currently, a typical CAN signal processing scheme employs the following architecture: CAN bus data is acquired via the SocketCAN interface; a decoder written in C / C++ parses CAN frames based on the DBC (CAN Database Configuration) file, extracting the physical values ​​of each signal; the decoded signal values ​​are serialized into formats such as Protobuf or JSON; the serialized data is published to the corresponding topic via message middleware such as MQTT; a streaming processing engine (such as Kuiper) subscribes to this topic, deserializes the received data, and performs streaming processing based on preset SQL rules. In this scheme, the CAN decoder code is typically pre-compiled as part of the firmware or application before system release. The signal structure defined in the DBC file is converted into fixed decoding code during the compilation phase, and the decoding logic cannot be independently updated after deployment on the vehicle side. When vehicle models are iterated, signal definitions change, or new CAN channels are added, the entire application must be recompiled and a complete firmware upgrade process must be executed, resulting in long change cycles and poor flexibility. However, the above scheme exhibits significant performance bottlenecks in actual automotive edge computing scenarios. The CAN signal processing chain, from acquisition to streaming, involves a complete process: C++ object to Protobuf serialization, MQTT transmission, Go deserialization, and finally streaming. This chain requires at least two serialization and deserialization operations. The CAN acquisition process and the streaming engine (such as Kuiper, implemented in Go) are independent processes. When data is forwarded via MQTT on the local socket, context switching between user mode and kernel mode is involved, along with at least three memory copies, including those to the send buffer, socket buffer, and receive buffer. The streaming engine must dynamically parse the message structure using Go reflection when processing Protobuf format data, resulting in significant CPU and memory resource consumption. In the complete CAN signal processing chain, the cumulative effect of multiple memory copies—including copying the raw CAN data, writing the decoded result to the Protobuf object, serializing to the byte stream, copying the MQTT send buffer, and copying the receiver-side deserialization buffer—is particularly pronounced in multi-channel CAN concurrent scenarios, exacerbating memory bandwidth pressure. Furthermore, the pre-compiled deployment method requires a complete compilation, testing, release, and firmware upgrade process when DBC files are changed. Large-scale fleet upgrades also pose a risk of version fragmentation, as some vehicles may use older decoder versions for extended periods, causing the cloud to be unable to correctly parse their reported data. Additionally, the decentralized management of DBC file definitions, Protobuf schema, and Go struct definitions, lacking a unified data model, makes it difficult to guarantee version consistency.

[0004] Existing technologies have shortcomings in the end-to-end link of CAN signal acquisition and streaming processing, such as high processing latency, high CPU resource consumption, poor decoder update flexibility, and difficulty in ensuring data model consistency. These shortcomings make it difficult to meet the real-time processing requirements of vehicle edge computing nodes in high-frequency CAN data throughput scenarios. Summary of the Invention

[0005] This invention aims to at least solve the aforementioned technical problems existing in the prior art. To this end, the first aspect of this invention proposes a CAN signal streaming processing method based on cloud and zero-copy shared memory, comprising:

[0006] In the cloud-based compilation platform, based on the unified data model definition file, the target platform decoder code, shared memory layout definition, and streaming processing mode definition are generated; the unified data model definition file describes the signal name, signal type, and signal number contained in each CAN frame.

[0007] The generated target platform decoder code, shared memory layout definition, and streaming processing mode definition are distributed to the vehicle-end device;

[0008] On the vehicle-side device, in response to a configuration change event, the target platform decoder code is loaded into memory in an anonymous memory manner to form a decoder process;

[0009] Based on the shared memory layout definition, a shared memory region is created; the shared memory region adopts a circular buffer structure, and lock-free concurrent access is achieved through atomic operations;

[0010] The decoder process acquires raw CAN data and decodes the raw CAN data, storing the decoded signal data into the shared memory area.

[0011] Based on the defined streaming processing mode, the streaming processing process is started;

[0012] The streaming process reads the shared memory region through a cross-language calling mechanism and constructs the read data into a data structure in the form of local language references.

[0013] The above-mentioned CAN signal streaming processing method based on cloud and zero-copy shared memory has the following beneficial effects:

[0014] Processing latency is significantly reduced. By replacing the data transmission channel of message queue middleware (such as MQTT) with shared memory, the intermediate links of serialization, deserialization, and network forwarding are eliminated, and the end-to-end latency of CAN signals from decoding to streaming readiness is greatly reduced.

[0015] CPU resource consumption is significantly reduced. On the one hand, the zero-copy shared memory access method reduces the number of memory copy operations for the same frame of data from more than five to zero, reducing memory bandwidth pressure; on the other hand, the reference counting mechanism drives on-demand decoding, performing decoding only on signals referenced by streaming rules, avoiding the waste of CPU resources caused by invalid decoding.

[0016] Decoder updates are flexible and provide uninterrupted service. The cloud-based compilation platform automatically generates multi-target platform decoder code based on a unified data model definition file, and the vehicle-side achieves hot updates through an anonymous memory loading mechanism. CAN data acquisition remains uninterrupted during decoder switching, and the update cycle is shortened from the minute-level of traditional solutions to the second-level.

[0017] Data definition consistency is guaranteed. Using a unified data model definition file (such as a protocol buffer definition file) as a single data source, the cloud compilation platform automatically generates decoder code, shared memory layout definition, and streaming processing mode definition, eliminating the risk of inconsistency between multiple sets of data definitions due to decentralized management.

[0018] Multi-hardware platform coverage and compilation repeatability. A containerized compilation environment is used to build independent compilation containers for each target processor architecture, ensuring that the same source code compiles into identical binary products at different times and on different servers. It also supports multiple target processor architectures such as ARM64, ARM32, and x86_64. When adding a new target platform, only the corresponding compilation container needs to be built.

[0019] Optionally, before decoding, a preset hash table is queried to obtain the reference count value corresponding to the target signal. When the reference count value is greater than zero, decoding is performed on the target signal. The key of the hash table is the signal identifier, and the value is the number of streaming rules referencing that signal. The signal identifier is composed of a channel number and a CAN identifier. When a streaming rule is added, the reference count value of each signal referenced by that rule is incremented. When a streaming rule is deleted, the reference count value of each signal referenced by that rule is decremented. The increment and decrement operations of the reference count value are bound to the configuration change event.

[0020] The aforementioned reference counting mechanism ensures that the decoder only decodes signals referenced by streaming rules, avoiding the waste of CPU resources caused by invalid decoding, and deleting a single rule will not accidentally stop decoding when multiple rules share the same signal.

[0021] Optionally, generating the target platform decoder code includes: using a containerized compilation environment to build an independent compilation container for each target processor architecture, and generating target platform decoder code adapted to the target processor architecture based on the unified data model definition file within the compilation container; the target processor architecture includes at least one of ARM64, ARM32, and x86_64.

[0022] The containerized compilation method described above enables the same source code to be compiled into identical binary products at different times and on different servers. When adding a new target processor architecture, only the corresponding compilation container needs to be built, ensuring the consistency and repeatability of compilation across multiple platforms.

[0023] Optionally, the target platform decoder code is loaded into memory in an anonymous memory manner, including: loading the shared library file corresponding to the target platform decoder code into anonymous memory through a system call to create a memory file; if an old version decoder instance already exists, the new version shared library file overwrites the old version file, and the old version decoder instance continues to run in memory until it is replaced; wherein, the replacement of the old version decoder instance includes: after the old version decoder instance finishes processing the currently decoded CAN frame, performing an atomic replacement of the instance pointer before the next frame arrives, and the newly arrived CAN frame after replacement is processed by the new version decoder instance; or, the new version decoder first processes a preset number of consecutive frames in parallel observation mode and performs a consistency comparison with the old version results, and switches to the new version as the primary decoder after the comparison is successful.

[0024] The aforementioned anonymous memory loading method avoids the exposure of the decoder code in the file system. The replacement of old and new versions is performed atomically at the frame boundary or after parallel observation and verification, so as to achieve uninterrupted CAN data acquisition during the hot update of the decoder.

[0025] Optionally, the unified data model definition file is a protocol buffer definition file; the generation of target platform decoder code includes: based on a template engine, converting the signal structure information in the protocol buffer definition file into code output corresponding to the target platform.

[0026] The above method, which uses the protocol buffer definition file as a single data source and generates decoder code through a template engine, eliminates the risk of version inconsistency caused by the scattered management of DBC files, Protobuf schema, and code structure.

[0027] Optionally, the streaming process is a streaming engine that integrates a custom memory data source plugin; the custom memory data source plugin reads data through the shared memory region.

[0028] The aforementioned custom memory data source plugin enables the streaming engine to read data directly from shared memory, replacing the serialization-transmission-deserialization chain via message queue middleware, thus eliminating the overhead of multiple data copies and context switching.

[0029] Optionally, the target platform decoder code is a shared library file, and the shared memory layout is defined as a structure declared using compact attribute annotations; the streaming process reads the shared memory region through a cross-language call interface, and constructs the starting address and length information of the structure array stored in the shared memory region into a data structure in the native language reference form of the streaming process according to the shared memory layout definition.

[0030] The combination of the aforementioned compact attribute annotations and cross-language calling interfaces enables cross-language inter-process data alignment, allowing shared memory data to be directly constructed as local language references, achieving zero-copy reading.

[0031] Secondly, the present invention provides a CAN signal streaming processing system based on cloud and zero-copy shared memory, including a cloud compilation platform and vehicle-side processing equipment;

[0032] The cloud-based compilation platform includes:

[0033] The compilation module is used to generate target platform decoder code, shared memory layout definition, and streaming processing mode definition based on the unified data model definition file; the unified data model definition file describes the signal name, signal type, and signal number contained in each CAN frame;

[0034] The distribution module is used to distribute the generated target platform decoder code, the shared memory layout definition, and the streaming processing mode definition to the vehicle-side processing device;

[0035] The vehicle-side processing equipment includes:

[0036] The code loading module is used to load the target platform decoder code into memory in an anonymous memory manner in response to configuration change events, so as to form a decoder process;

[0037] The shared memory management module is used to create a shared memory region based on the shared memory layout definition; the shared memory region adopts a circular buffer structure and achieves lock-free concurrent access through atomic operations;

[0038] The decoder module is used to acquire raw CAN data, decode the raw CAN data, and store the decoded signal data into the shared memory area.

[0039] The process management module is used to start the streaming processing process based on the defined streaming processing mode.

[0040] The streaming module is used to read the shared memory region through a cross-language calling mechanism and construct the read data into a data structure in the form of local language references.

[0041] Optionally, the compilation module includes a containerization management unit for building independent compilation containers for each target processor architecture; the target processor architecture includes at least one of ARM64, ARM32, and x86_64.

[0042] The containerized management unit described above isolates the compilation environment for each target processor architecture from each other. The same source code produces the same binary product in different compilation environments. When adding a new target processor architecture, only the corresponding compilation container needs to be registered, without modifying the core compilation module.

[0043] Optionally, the decoder module is further configured to query a preset hash table before performing signal decoding to obtain a reference count value corresponding to the target signal. When the reference count value is greater than zero, decoding is performed on the target signal. The key of the hash table is a signal identifier, and the value is the number of streaming rules referencing that signal. The signal identifier is composed of a channel number and a CAN identifier. When a streaming rule is added, the reference count value of each signal referenced by that rule is incremented. When a streaming rule is deleted, the reference count value of each signal referenced by that rule is decremented. The increment and decrement operations of the reference count value are bound to the configuration change event.

[0044] The reference counting mechanism in the decoder module ensures that decoding is only performed on signals referenced by streaming rules, avoiding CPU resource waste caused by invalid decoding, and deleting a single rule will not accidentally stop decoding when multiple rules share the same signal.

[0045] Thirdly, the present invention provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the method described in the first aspect or any optional implementation thereof. Attached Figure Description

[0046] Figure 1 This is a schematic diagram of the system architecture and data flow provided for an embodiment of the present invention.

[0047] Figure 2 The above is an overall flowchart of the method provided in the embodiments of the present invention. Detailed Implementation

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

[0049] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of embodiments of this disclosure, unless otherwise stated, "a plurality of" means two or more. Furthermore, the use of "based on" or "according to" implies openness and inclusiveness, because processes, steps, calculations, or other actions "based on" or "according to" one or more of the stated conditions or values ​​may in practice be based on additional conditions or beyond the stated values.

[0050] This invention provides a CAN signal streaming processing system based on cloud and zero-copy shared memory, such as... Figure 1 As shown, it includes a cloud-based compilation platform and vehicle-side processing equipment. The cloud-based compilation platform is deployed on a cloud server, and the vehicle-side processing equipment is deployed on an in-vehicle edge computing node.

[0051] The cloud-based compilation platform includes a compilation module and a distribution module. The compilation module generates the target platform decoder code, shared memory layout definition, and streaming processing mode definition based on a unified data model definition file. The distribution module distributes the generated compilation artifacts to the vehicle-mounted processing equipment.

[0052] In one possible implementation, the compilation module includes a containerization management unit for building independent compilation containers for each target processor architecture. The target processor architectures include at least one of ARM64, ARM32, and x86_64. The containerization management unit utilizes Docker containerization technology to build compilation container images pre-installed with the corresponding cross-compilation toolchain for each target processor architecture, with each compilation container isolated from the others.

[0053] The vehicle-side processing equipment includes a code loading module, a process management module, a shared memory management module, a decoder module, and a streaming processing module. The code loading module, in response to configuration change events, loads the target platform decoder code into memory anonymously to form a decoder process. The process management module starts the streaming processing process based on the streaming processing mode definition. The shared memory management module creates and manages shared memory regions, which employ a circular buffer structure and achieve lock-free concurrent access through atomic operations. The decoder module acquires raw CAN data, decodes it, and stores the decoded signal data into the shared memory region. Before performing signal decoding, the decoder module also determines whether the target signal is referenced by at least one streaming processing rule based on the reference count value; decoding is performed when the reference count value of the target signal is greater than zero. The streaming processing module reads the shared memory region through a cross-language calling mechanism and constructs the read data into a data structure in the local language reference form.

[0054] The following section, in conjunction with the above system architecture, states that... Figure 2 As shown, the CAN signal streaming processing method of the present invention will be described in detail in the order of steps S1 to S7. Among them, steps S1 and S2 are cloud compilation stages, and steps S3 to S7 are vehicle-side operation stages.

[0055] Step S1: Generate multi-target compilation artifacts based on the unified data model definition file

[0056] In the cloud-based compilation platform, based on the unified data model definition file, the target platform decoder code, shared memory layout definition, and streaming processing mode definition are generated. This step is executed within the compilation module of the cloud-based compilation platform.

[0057] Step S101: Obtain the unified data model definition file.

[0058] The Unified Data Model Definition File (UDF) describes the signal name, signal type, and signal number contained in each CAN frame and is the sole data source for all compiled products of the system. The UDF can be manually written by engineers based on the vehicle's CAN bus design document, or it can be automatically generated from a DBC file using a conversion tool. DBC files are typically generated by DBC editing tools (such as Vector CANdb++ Editor), while the tool for converting DBC files to UDFs is an internally developed conversion tool.

[0059] In one possible implementation, the unified data model definition file is a protocol buffer definition file (.proto file). The protocol buffer definition file describes the signal name, signal type, and signal number of each CAN frame in a structured manner. For example, the protocol buffer definition file defines a CAN frame as containing a vehicle speed signal (signal name "VehicleSpeed", type "float", number "0x01") and an engine speed signal (signal name "EngineRPM", type "int32", number "0x02"). Using the protocol buffer definition file as a single data model source ensures consistency at the data structure level for subsequently generated decoder code, shared memory layout definitions, and streaming mode definitions.

[0060] Step S102: Generate the target platform decoder code.

[0061] Based on the name, type, and number of each signal described in the unified data model definition file, decoder code adapted to the target processor architecture is generated. The decoder code contains decoding logic that converts the raw CAN byte stream into the physical values ​​of each signal.

[0062] In one possible implementation, the decoder code is a C language shared library file (.so format). The cloud-based compilation platform, based on a template engine, converts the signal structure information in the protocol buffer definition file into C language decoding functions. For example, using the Jinja2 template engine, the input is the protocol buffer definition file, and the output is the C language decoding function source code. The template engine automatically generates the corresponding signal extraction function and the mapping relationship between signals and shared memory layout fields based on parameters such as bit offset, bit length, scaling factor, and offset for each signal in the protocol buffer definition file. The generated decoding function source code is then compiled by the cross-compilation toolchain within the compilation container into a shared library file corresponding to the target processor architecture.

[0063] Specifically, the template engine uses the native Python Jinja2 library. The Jinja2 template defines the code framework of the decoding function. After reading the signal structure information in the protocol buffer definition file, the template engine fills the corresponding placeholder area in the template to generate the decoder C++ source code containing the signal bit extraction logic.

[0064] In one possible implementation, a containerized compilation environment is used when generating the target platform decoder code in step S102. Specifically, an independent compilation container is built for each target processor architecture, and decoder code adapted to that target processor architecture is generated within the compilation container based on a unified data model definition file. Target processor architectures include at least one of ARM64, ARM32, and x86_64. For example, the compilation container for ARM64 architecture pre-installs the aarch64-linux-gnu-gcc cross-compilation toolchain, the compilation container for ARM32 architecture pre-installs the arm-linux-gnueabihf-gcc cross-compilation toolchain, and the compilation container for x86_64 architecture pre-installs the gcc compilation toolchain. The compilation containers are isolated from each other to avoid dependency conflicts between compilation toolchains of different target architectures. The same unified data model definition file input and the same compilation container image ensure that identical binary artifacts are compiled at different times and on different servers.

[0065] Specifically, the container image is built using a multi-stage Docker build process: the first stage installs the cross-compilation environment and builds the ARM64 target dependency library within the Ubuntu 22.04 (jammy) base image; the second stage replicates the artifacts from the previous stage, installs protoc and build tools, and executes the C++ decoder compilation after template rendering. The build pipeline uses CI to produce images using the same Dockerfile and pushes them to the artifact repository, where compilation is completed within this fixed image at runtime. Regarding the build toolchain, the base image is ubuntu:jammy (22.04 LTS), the Protobuf source code build version is v5.29.3, and the protoc version is 29.3.

[0066] When adding a new target processor architecture (such as RISC-V), only the corresponding compilation container image needs to be built and registered to the compilation container pool. There is no need to modify the core compilation logic, and the expansion cycle can be shortened to within one day.

[0067] Step S103: Generate a shared memory layout definition.

[0068] Based on the unified data model definition file, a shared memory layout definition is generated. The shared memory layout definition specifies the unified data structure used by the decoder process when writing to shared memory and by the streaming process when reading from shared memory. The shared memory layout definition contains the physical value field for each signal in the CAN frame, and the data type of each field corresponds one-to-one with the signal type in the unified data model definition file.

[0069] In one possible implementation, the shared memory layout is defined as C structs declared using the compact attribute annotation. The compact attribute annotation (e.g., __attribute__((packed))) ensures that the C struct does not contain any compiler-inserted padding bytes in memory, guaranteeing that the decoder process (implemented in C) and the streaming process (possibly implemented in Go or another programming language) interpret signal fields in the same memory region with the same byte offset, avoiding data misalignment due to differences in struct alignment rules.

[0070] Step S104: Generate streaming processing mode definition.

[0071] Based on the unified data model definition file, a streaming processing mode definition is generated. The streaming processing mode definition describes the data source access method, data field structure, and processing rule configuration of the streaming processing process.

[0072] In one possible implementation, the streaming mode is defined in a schema definition file (such as JSON format) of the streaming engine, declaring the names and types of streaming data fields that the streaming engine can recognize, as well as configuration parameters for custom in-memory data source plugins. An example streaming engine is Kuiper.

[0073] Step S2: Distribute the compiled output to the vehicle-mounted equipment.

[0074] The target platform decoder code, shared memory layout definition, and streaming processing mode definition generated in step S1 are distributed to the vehicle-side devices. This step is performed by the distribution module of the cloud-based compilation platform.

[0075] Specifically, the distribution module categorizes and stores the compiled artifacts according to the target processor architecture in an object storage service (OSS). The object storage service is an S3-compatible object storage service (such as Huawei OBS). For example, the decoder storage path for the ARM64 architecture is "bus / can / 1 / libcan_decoder_arm64.so", the decoder storage path for the ARM32 architecture is "bus / can / 1 / libcan_decoder_armhf.so", and the decoder storage path for the x86_64 architecture is "bus / can / 1 / libcan_decoder_x86_64.so". The compiled artifact filenames include an architecture suffix (e.g., .arm64.so), allowing the vehicle-mounted device to download the matching compiled artifact from the corresponding path based on its own processor architecture.

[0076] In one possible implementation, the distribution triggering mechanism adopts a hybrid mode of "cloud-initiated push of change notifications + vehicle-side data / file retrieval": After EdgeDevice resources change, the cloud publishes a revision message to the topic cloud / edge / v1 / {hostname} / edge_device via MQTT; the vehicle-side EdgeHub subscribes to this topic, receives the revision, calls the cloud incremental interface to retrieve the change information, and then downloads the corresponding proto / so compilation artifacts from the object storage service. Shared memory layout definition and streaming processing mode are defined as architecture-independent files, which can be uniformly stored and distributed to each vehicle-side device.

[0077] Step S3: Load the decoder code into anonymous memory to form the decoder process.

[0078] On the vehicle-side device, in response to a configuration change event, the target platform decoder code is loaded into memory anonymously to form a decoder process. This step is executed by the code loading module of the vehicle-side processing device.

[0079] Step S301: Detect configuration change events.

[0080] The vehicle-mounted processing equipment monitors configuration change events through a configuration awareness mechanism. When a new version of decoder code distributed by the cloud compilation platform is detected, the decoder loading process is triggered.

[0081] In one possible implementation, the vehicle-side processing device detects configuration changes to EdgeDevice resources through Kubernetes' Informer mechanism. The core fields of EdgeDevice resources include name, type, channel, interface, protocol, comm_matrices, comm_proto, comm_plugin, comm_frame_map, status, error_message, tags, enable, and group_id. The complete transmission chain of configuration changes from the cloud to the vehicle is as follows: After the cloud completes the EdgeDevice resource change, the Cloud API publishes the revision to the MQTT topic cloud / edge / v1 / {hostname} / edge_device (retain message); after the vehicle's EdgeHub subscribes to the revision, it calls the cloud incremental interface / edge / {edgeId} / edge_device?revision=... to pull the changed data; ConvertToLocalDevice downloads the compilation artifacts corresponding to comm_proto / comm_plugin from the object storage service to the local path and writes them back to the local metadata; the local metadata then publishes a CloudEvent to edge / v1 / edge_device / {name} (subject is add / update / delete); each Informer consumes this event and updates its local cache or database. The decoder loading point is in CANFDDevice::setup_decoder(), dynamically loading shared libraries according to comm_plugin.

[0082] Step S302: Load decoder code by creating a system call from a memory file.

[0083] The code loading module creates system calls via memory files to load the shared library files corresponding to the target platform's decoder code into anonymous memory. Anonymous memory means the decoder code does not depend on paths in the file system, avoiding file system-level permission and visibility issues, and preventing unauthorized access or tampering of the decoder code.

[0084] In one possible implementation, the memory file creation system call is `memfd_create`. In different operating system environments, equivalent memory file creation mechanisms to `memfd_create` can be used:

[0085] (1) For Linux, memfd_create is preferred; in environments that do not support this interface, shm_open+ftruncate+mmap and shm_unlink immediately after creation can be used to anonymize memory files, or O_TMPFILE can be used to create temporary files without directory entries in tmpfs (such as / dev / shm);

[0086] (2) For QNX, the POSIX shared memory mechanism shm_open+ftruncate+mmap can be used, and the equivalent semantics of "memory-resident only, no persistent directory entries, and automatic release after the last reference is closed" can be achieved by immediately using shm_unlink; when controlled physical memory is required, posix_typed_mem_open can be used.

[0087] (3) For Android Automotive, the NDK interface ASharedMemory_create can be used as a unified abstraction; memfd_create can also be used directly if supported; older systems can fall back to the ashmem ( / dev / ashmem) mechanism;

[0088] All of the above methods can achieve the equivalent effects of inter-process sharing, memory residency, and lifecycle release with file descriptors or mapping references.

[0089] Step S303: Process the replacement of the old and new versions of the decoder.

[0090] If an older decoder instance already exists, the new version's shared library files overwrite the old ones. The older decoder instance continues to run in memory, decoding the received raw CAN data until it is replaced by the new decoder instance. During this hot update process, CAN data acquisition and decoding services remain uninterrupted, enabling hot updates of the decoder code.

[0091] In one possible implementation, the shared library files of historical versions are retained in the object storage service. When a problem occurs with the new version, the vehicle-mounted device can download and load the historical version decoder code from the object storage service to achieve a fast rollback.

[0092] In one possible implementation, the decoder adopts a hot update strategy of "switching by CAN frame boundary": when the new version of the shared library has finished downloading and passed the loadability check, the system does not switch in the middle of frame processing, but waits for the old version of the decoder instance to finish processing the currently decoded CAN frame, and performs an atomic replacement of the instance pointer before the next frame arrives; after the replacement, the newly arrived CAN frame is only processed by the new version of the decoder instance, and the old version instance exits after clearing the frames it has received but not completed, thereby ensuring the integrity of single frame processing and the continuity of decoding.

[0093] In one possible implementation, the system can set a short-term parallel observation window: the new version of the decoder first processes several consecutive frames in parallel in "shadow mode" (or for a period of time) and compares them with the results of the old version for consistency. If the comparison is successful, the system can switch to the new version as the primary version. If the comparison fails or there is an abnormality in operation, the old version is kept as the primary version and a rollback is triggered. The historical version of the decoder is loaded from the object storage to achieve uninterrupted rollback.

[0094] Step S4: Create a shared memory region based on the shared memory layout definition

[0095] Based on the shared memory layout definition generated in step S1, a shared memory region is created. The shared memory region adopts a circular buffer structure, enabling lock-free concurrent access through atomic operations. This step is executed by the shared memory management module of the vehicle-side processing device.

[0096] Specifically, the shared memory management module reads the shared memory layout definition to obtain the structure size and field layout information of the decoded signal data. Based on the structure size, it determines the size of each buffer unit in the circular buffer, aligning the size of each buffer unit with the structure size defined in the shared memory layout.

[0097] The shared memory management module calls the shared memory creation interface to create shared memory objects in the operating system. For example, on a POSIX-compliant operating system, the shm_open function creates a shared memory file descriptor, specifying the name and access permissions of the shared memory; the ftruncate function sets the total size of the shared memory region; and the mmap function maps the shared memory region to the respective virtual address spaces of the decoder process and the streaming process.

[0098] The shared memory region is logically organized as a circular buffer structure. The circular buffer contains a predetermined number of buffer units, each used to store the decoding result of one frame of CAN data. The circular buffer maintains a write pointer and a read pointer, indicating the currently writable and currently readable buffer unit positions, respectively.

[0099] The write pointer is managed by the decoder process. Each time the decoder process writes a decoding result to shared memory, it updates the write pointer atomically to point to the next free buffer unit. The read pointer is managed by the streaming process. Each time the streaming process reads data from shared memory, it updates the read pointer atomically to point to the next buffer unit to be read. Atomic operations ensure that updates to the write and read pointers do not cause race conditions in multi-process concurrent scenarios, thus achieving lock-free concurrent access without using mutexes and avoiding the context switching overhead caused by lock contention.

[0100] In one possible implementation, the number of buffer units N in the circular buffer is a power of 2 (e.g., 1024 or 2048) to enable modulo indexing via bitwise AND; the size S of a single buffer unit is determined by "aligning the shared memory layout structure size upwards to 64 bytes", i.e., S = align_up(sizeof(record), 64). For example, when a single record structure is 112 bytes, the unit size is 128 bytes; the total shared memory capacity is N × S (excluding the control header).

[0101] The buffer is full when the difference between the write sequence number and the read sequence number is greater than or equal to N (i.e., write_seq-read_seq≥N), and supports the following two processing strategies: (1) Overwrite old data strategy (real-time priority, as the default strategy), the writer continues to write and advances the read sequence number to write_seq-N+1, while incrementing the dropped frame count drop_count to ensure that the acquisition and decoding are not interrupted; (2) Blocking and waiting strategy (integrity priority), the writer waits for the reader to advance the read sequence number when the buffer is full, and a timeout threshold can be set (e.g., 1ms to 5ms). After the timeout, it can be downgraded to the overwrite strategy or return a back pressure alarm.

[0102] Once the shared memory region is created, both the decoder process and the streaming process can access the same physical memory region through their respective virtual address spaces. The decoder process writes decoding results to this region, and the streaming process reads data from this region. The two processes directly share data without needing kernel-level data transfer or additional memory copying.

[0103] Step S5: Acquire the raw CAN data and decode it, then write the decoding result to shared memory.

[0104] The process acquires raw CAN data, decodes it, and stores the decoded signal data in a preset shared memory area. This shared memory area uses a circular buffer structure, enabling lock-free concurrent access through atomic operations. This step is executed collaboratively by the decoder module and the shared memory management module of the vehicle-side processing equipment.

[0105] Step S501: Obtain raw CAN data.

[0106] The decoder module acquires raw CAN data from the data acquisition channel. Raw CAN data can come from the SocketCAN interface or other CAN bus data acquisition channels. Raw CAN data is in units of CAN frames, each containing a CAN identifier (CAN ID) and a data payload. The data payload is a fixed-length (e.g., 8 bytes or 64 bytes) raw byte sequence carrying the encoded values ​​of each signal within the CAN frame.

[0107] In one possible implementation, the vehicle-side uses a native RAW acquisition link with SocketCAN and supports concurrent acquisition of multiple CAN channels. Specifically, the system creates an independent acquisition instance for each enabled CAN device according to the interface / channel in the device configuration; each instance completes socket binding, frame reception, and decoding preprocessing, and can acquire multiple bus data such as can0 / can1 / ... in parallel without blocking each other.

[0108] Step S502: Determine whether to perform decoding based on the reference count value.

[0109] Before decoding a signal, the decoder process determines whether the target signal is referenced by at least one streaming rule based on the reference count. When the reference count of the target signal is greater than zero, it means that at least one streaming rule needs the decoded value of the signal, and the decoder process performs decoding on the target signal. When the reference count is equal to zero, it means that no streaming rule currently references the signal, and the decoder process skips decoding the signal to save CPU resources.

[0110] For details on the specific maintenance mechanism of the reference count value, please refer to step S7.

[0111] In one possible implementation, the reference count value is determined in batches by CAN ID rather than individually for each signal. Specifically, the system uses a combination of channel number and CAN identifier as the reference count key; during runtime, a determination is performed once for each received frame: if the reference count value of the corresponding key for that frame is greater than zero, the signal decoding process for that frame begins; if the reference count value of the corresponding key for that frame is equal to zero, the entire frame is skipped from decoding. The increment and decrement operations of the reference count value are bound to the configuration change event, rather than being recalculated with each frame; that is, the reference count value is updated when streaming rules or models are added, updated, or deleted, or when monitoring subscription relationships change; the data plane performs constant-level frame-level table lookup determination, reducing CPU overhead per frame.

[0112] Step S503: Perform signal decoding.

[0113] The decoder process performs a decoding operation on the target signal determined to require decoding in step S502. The decoding operation includes extracting the original byte of the corresponding signal from the data payload of the CAN frame, and calculating the physical value of the signal based on parameters such as bit offset, bit length, scaling factor, and offset. The calculation formula is: Physical value = Original value × Scaling factor + Offset.

[0114] In one possible implementation, the decoder process consists of C language shared library files. The decoding functions are generated during the compilation stage based on the signal parameters in the unified data model definition file. At runtime, the corresponding decoding functions are called directly without looking up tables or traversing signal definitions.

[0115] In one possible implementation, the decoder performs the following steps for each target signal: first, it extracts the raw value from the CAN payload based on start_bit and size; then, it interprets the value based on is_signed / is_float; and finally, it calculates the physical value as physical value = raw value × scaling factor + offset. The start_bit is normalized according to DBC byte order rules during the code generation stage, ensuring that it can be directly extracted bit by bit at runtime.

[0116] For big-endian / little-endian operations: Little-endian signals (Intel format) are traversed byte by byte in forward order, starting from the least significant bit. The first byte is shifted right to remove the low-endian offset, the last byte is truncated by the effective bit mask, and the middle bytes are concatenated according to the shift amount. Big-endian signals (Motorola format) first map the big-endian start bit to an equivalent reverse bit index, and then traverse and concatenate byte by byte in reverse order. Similarly, the boundary bytes are masked and shifted to ensure the correct bit order of cross-byte signals.

[0117] The difference in processing signed and unsigned signals: For unsigned signals, the raw value extracted is directly scaled as an unsigned number; for signed signals, the sign bit (the (size-1)th bit) is checked first. If the bit is 1, sign extension (high bits padded with 1) is performed to 64 bits, and then the value is scaled as a signed integer to avoid distortion of negative values.

[0118] For byte order processing of multi-byte signals: the decoder processes cross-byte signals in segments of "first byte / middle byte / last byte", performs bit truncation and offset correction on boundary bytes, and directly concatenates the middle whole bytes; little-endian signals are accumulated from low address to high address, and big-endian signals are accumulated in reverse semantic order of the most significant bit. This method is applicable to multi-byte signals in both classic CAN and CAN FD payloads.

[0119] Step S504: Write the decoding result to the shared memory area.

[0120] The decoder process stores the decoded signal data into the shared memory region created in step S4. Specifically, the decoder process obtains the address of the buffer cell indicated by the current write pointer from the circular buffer, and writes the decoded signal data into that buffer cell according to the structure format defined by the shared memory layout.

[0121] In one possible implementation, the target platform decoder code is a C language shared library file. The shared memory layout is defined as a C language structure declared using the compact attribute annotation. The compact attribute annotation ensures that the C language structure does not contain padding bytes in memory, thereby guaranteeing that the decoder process and the streaming process interpret each signal field in the same memory region with the same byte offset. After writing is complete, the decoder process increments the write pointer to the next buffer unit through an atomic operation.

[0122] Step S6: Start the streaming processing process based on the streaming processing mode definition

[0123] Based on the streaming processing mode definition generated in step S1, the streaming processing process is started. This step is executed by the process management module of the vehicle-side processing device. The streaming processing process is used to read the decoded CAN signal data from the shared memory area and perform condition judgment and rule triggering operations based on preset streaming processing rules.

[0124] In one possible implementation, the streaming process is a streaming engine integrated with a custom in-memory data source plugin. An example of such a streaming engine is Kuiper. The custom in-memory data source plugin reads data directly from a shared memory region, replacing the channel of receiving serialized data through a message queue middleware (such as MQTT). Specifically, the custom in-memory data source plugin implements a direct read interface for the shared memory region, replacing the original topic-subscription-based data source with a data source based on shared memory addresses. This eliminates the need for the streaming engine to go through intermediate steps such as data delivery, serialization, and deserialization via message middleware.

[0125] In one possible implementation, a custom memory data source plugin is loaded as a Source plugin for the streaming engine, identified as `shm_source`. Registration is completed during engine startup via a plugin directory scan or plugin management interface. When creating a stream, the plugin type and shared memory address are specified in the data source parameters, thus replacing the original MQTT topic data source. The data source configuration method is compatible with the existing `DATASOURCE="driver / device name"` configuration method, only changing the data source to `DATASOURCE="shm: / / can / ch1"` and adding shared memory parameters (including `ring_name`, `slot_count`, `slot_size`, `read_mode`, `timeout_ms`, and `overrun_policy`). The format can still be `FORMAT="protobuf"` and `SCHEMAID` can be retained.

[0126] In one possible implementation, the interaction interface between the plugin and the shared memory ring buffer is defined as follows: (1) Initialization / attachment interface: Open the shared memory object according to ring_name and execute mmap to read control block information (version, capacity, write pointer, slot size); (2) Batch read interface: Read N slots continuously according to the read pointer. The slot header contains at least the fields seq, timestamp_ns, frame_id, dlc, flags and payload_len, followed by CAN payload bytes; (3) Submission point interface: After the plugin successfully delivers to the engine, it submits read_seq as consumption confirmation. Data that has not been submitted can be retried; (4) Out of bounds and backpressure handling: When write_seq-read_seq>capacity is detected, overrun_policy is triggered (jump to the latest, discard the oldest or alarm to stop the flow); (5) Lifecycle management: When the plugin is closed, the mapping is removed and the handle is closed. The shared memory is reclaimed by the producer or reference counting policy. This interface adopts a "producer writes alone, consumer reads alone or multiple readers read pointers independently" model, uses frame sequence number seq to ensure sequential consistency, and uses frame boundaries as the smallest processing unit to avoid half-frame reading.

[0127] Step S7: The streaming process reads shared memory data through a cross-language calling mechanism.

[0128] The streaming process reads the shared memory region through a cross-language calling mechanism and constructs the read data into a data structure in the local language reference form. This step is executed by the streaming module of the vehicle-side processing device.

[0129] Specifically, the streaming process obtains the address information of currently readable data in the circular buffer through a cross-language calling interface. Since the decoder process and the streaming process may be implemented using different programming languages, the data stored in shared memory is structured data written by the decoder process according to the shared memory layout definition. The streaming process obtains the starting address and data length information of this structured data through the cross-language calling mechanism, and uses its own programming language's memory reference construction capabilities to directly construct a data structure in the native language reference form from the starting address and length. This construction process only involves the passing of pointer and length information, without involving underlying data memory copying operations, achieving zero-copy data reading.

[0130] In one possible implementation, the target platform decoder code is a C language shared library file, the streaming process is implemented in Go, and the cross-language calling interface is CGO. The streaming process obtains the pointer to the starting address of the C language structure and the structure length information of the latest data in the circular buffer through CGO. Using Go's `unsafe` package and slice construction syntax, it converts the starting address and length of the C language array into a Go native slice reference. For example, the streaming process obtains the pointer `ptr` to the starting address of the C language structure array and the array length `n` through CGO. On the Go side, it constructs a Go native slice using `unsafe.Slice((*StructType)(unsafe.Pointer(ptr)), n)`. Subsequent streaming rules can directly access the decoded signal data based on this slice reference without data copying.

[0131] After acquiring data, the streaming process performs processing on the signal data based on preset streaming rules. Streaming rules may include, but are not limited to: threshold comparison (e.g., triggering an alarm when the vehicle speed is greater than 120 km / h), signal combination calculation (e.g., determining the correlation between vehicle speed and engine speed), and time window aggregation (e.g., calculating the average vehicle speed over the past 30 seconds).

[0132] In one possible implementation, the reference counting mechanism is implemented using a hash table. The key of the hash table is the signal ID, which is a combination of the CAN frame ID and the signal number, used to uniquely identify a CAN signal; the value of the hash table is the number of streaming rules referencing that signal.

[0133] When a streaming rule is added, the system iterates through all the signal identifiers referenced by that rule, incrementing the reference count of the corresponding signal identifier in the hash table. When a streaming rule is deleted, the system iterates through all the signal identifiers referenced by that rule, decrementing the reference count of the corresponding signal identifier in the hash table. When the reference count of a signal identifier decreases from one to zero, it means that the signal is no longer referenced by any streaming rule, and subsequent decoder processes will skip decoding that signal, but will still continue to decode other signals with reference counts greater than zero.

[0134] Before each decoding operation, the decoder process queries a pre-defined hash table to obtain the reference count value corresponding to the target signal. Decoding is performed when the reference count value is greater than zero; otherwise, decoding of the signal is skipped. The time complexity of the hash table lookup operation is constant, and the additional time spent on decoding decisions has a negligible impact on high-frequency CAN data processing.

[0135] In one possible implementation, the reference counting hash table adopts a "full initialization at system startup + incremental maintenance during runtime events" approach. Specifically, when the decoding service starts, it first reads the set of effective rules from the local metadata cache (such as a local SQLite); when the local cache is empty, it performs a full fetch from the metadata service; then it iterates through the dependent signals of each rule and fills the hash table, completing the initial reference count value establishment before entering the real-time decoding loop. Runtime maintenance occurs when rule change events arrive: when a rule is added, updated, or deleted, the signal set involved in that rule is incremented or decremented; for update events, the old rule contribution is revoked before the new rule contribution is written, and for deletion events, the contribution is revoked. The system also performs consistency correction through periodic full resynchronization (e.g., every 30 seconds) to prevent count drift caused by event loss.

[0136] Dynamic loading and unloading of streaming rules are triggered through rule management interfaces, including interfaces for rule creation, updating, deletion, enabling, and disabling (such as / edge-rule, / edge-rule / name / {name}, and enable / disable sub-interfaces). After writing metadata to the interface, a rule change event is published. The decoding side receives the changes by subscribing to the event topic and updates the reference count hash table in real time.

[0137] Through the aforementioned reference counting mechanism, the system achieves on-demand decoding: decoding is only performed on signals actually referenced by at least one streaming rule; signals not referenced by any rule are not decoded, avoiding the waste of CPU resources caused by invalid decoding. Simultaneously, when multiple streaming rules reference the same signal, deleting one rule only decrements the signal's reference count, not resets it to zero, ensuring that the decoding needs of other rules are not affected, thus avoiding the problem of accidental decoding stoppage in scenarios where multiple rules share signals.

[0138] The technical solution of the present invention will be further described below with reference to a complete embodiment.

[0139] Suppose a new CAN bus is added to a vehicle model, containing a vehicle speed signal and an engine speed signal. Engineers add the corresponding signal definitions in the unified data model definition file (.proto file). The signal name for the vehicle speed signal is "VehicleSpeed", the type is "float", and the number is "0x01". The signal name for the engine speed signal is "EngineRPM", the type is "int32", and the number is "0x02".

[0140] In step S1, the compilation module of the cloud compilation platform reads the updated protocol buffer definition file. The template engine (Jinja2) generates the corresponding C language decoding function based on the signal definition, embedding parameters such as the bit offset and bit length of the VehicleSpeed ​​signal into the decoding logic; simultaneously, it generates a shared memory layout definition header file (can_shm.h), defining a compact C language structure containing two fields: VehicleSpeed ​​and EngineRPM; it also generates a schema definition file (schema.json) for the streaming processing engine, declaring the corresponding streaming data fields. The containerization management unit starts the corresponding compilation containers for the three target processor architectures: ARM64, ARM32, and x86_64, compiling and generating the corresponding decoder shared library files (.so) for each architecture.

[0141] In step S2, the compiled artifacts are uploaded to the object storage service via the distribution module and stored according to the target processor architecture.

[0142] In step S3, the code loading module of the vehicle-side processing device (assuming an ARM64 architecture) detects the availability of the new version decoder shared library file through a configuration awareness mechanism. The code loading module loads the new version decoder shared library file into anonymous memory via a memory file creation system call. The old decoder instance continues to run and decode existing CAN data, while new data is handled by the new decoder instance.

[0143] In step S4, the shared memory management module reads the shared memory layout definition header file can_shm.h to obtain the structure size and field layout information containing the VehicleSpeed ​​and EngineRPM fields, and creates a shared memory region accordingly. The shared memory region is organized as a circular buffer. The decoder process maps this shared memory region to its own virtual address space and updates the write pointer through atomic operations. After the streaming process starts, it attaches to and maps the shared memory region based on the same shared memory address and updates the read pointer through atomic operations.

[0144] In step S5, the decoder module obtains raw CAN data from the SocketCAN interface. Before performing decoding, the decoder module queries the reference counting hash table. Assuming that only one streaming rule currently references the VehicleSpeed ​​signal, and this signal has a reference count of 1 (greater than zero) in the hash table, the decoder module performs decoding on the VehicleSpeed ​​signal; the EngineRPM signal has a reference count of 0, and the decoder module skips decoding it. The decoder module writes the decoded VehicleSpeed ​​signal value to the next available cell in the shared memory circular buffer.

[0145] In step S6, the process management module starts a streaming process implemented in Go based on the streaming processing mode definition. The streaming process loads a custom memory data source plugin and attaches it to the circular buffer created in step S4 according to the shared memory address, preparing for reading the decoded VehicleSpeed ​​signal data.

[0146] In step S7, the streaming module obtains the starting address and length information of the C language structure currently readable in the circular buffer through the CGO cross-language call interface, and uses Go's unsafe package and slice construction syntax to directly construct a Go language local slice reference from the starting address and length information. This construction process only passes pointer and length information and does not copy the underlying signal data. The custom memory data source plugin encapsulates the local slice reference into a data record format recognizable by the streaming engine. The streaming engine executes preset SQL rules on the acquired VehicleSpeed ​​signal; for example, when the VehicleSpeed ​​signal value is greater than 120km / h, an overspeed alarm is triggered. Thus, the decoding result does not need to go through the message queue middleware, nor does it need to undergo serialization, deserialization, or cross-process data copying during the process of entering the streaming engine from shared memory.

[0147] When engineers need to add a new streaming rule (such as monitoring abnormal engine speed), this rule references the EngineRPM signal. When the rule is added, the system increments the reference count of the EngineRPM signal in the hash table, changing it from 0 to 1. Subsequently, before decoding, the decoder module checks if the EngineRPM reference count is greater than zero and begins decoding the signal. Later, if the rule is deleted, the system decrements the EngineRPM reference count back to 0, and the decoder module resumes skipping decoding of the EngineRPM signal.

[0148] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions within the technical scope disclosed in the present invention should be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A CAN signal streaming processing method based on cloud and zero-copy shared memory, characterized in that, include: In the cloud-based compilation platform, based on the unified data model definition file, the target platform decoder code, shared memory layout definition, and streaming processing mode definition are generated. The unified data model definition file describes the signal name, signal type, and signal number contained in each CAN frame; The generated target platform decoder code, shared memory layout definition, and streaming processing mode definition are distributed to the vehicle-end device; On the vehicle-side device, in response to a configuration change event, a system call to create a memory file loads the shared library file corresponding to the target platform decoder code into anonymous memory to form a decoder process; Based on the shared memory layout definition, a shared memory region is created; The shared memory region adopts a circular buffer structure, and lock-free concurrent access is achieved through atomic operations; Obtain raw CAN data; The decoder process decodes the raw CAN data and stores the decoded signal data into the shared memory area; Based on the defined streaming processing mode, the streaming processing process is started; The streaming process reads the shared memory region through a cross-language calling mechanism and constructs the read data into a data structure in the form of local language references.

2. The method according to claim 1, characterized in that, Before decoding the raw CAN data, the decoder process queries a preset hash table to obtain the reference count value corresponding to the target signal. When the reference count value is greater than zero, decoding of the target signal is performed. The key of the hash table is the signal identifier, and the value is the number of streaming rules referencing that signal. The signal identifier is composed of a channel number and a CAN identifier. When a streaming rule is added, the reference count value of each signal referenced by that rule is incremented; when a streaming rule is deleted, the reference count value of each signal referenced by that rule is decremented. The increment and decrement operations of the reference count value are bound to the configuration change event.

3. The method according to claim 1, characterized in that, The generated target platform decoder code includes: A containerized compilation environment is adopted, and an independent compilation container is built for each target processor architecture. Within the compilation container, target platform decoder code adapted to the target processor architecture is generated based on the unified data model definition file. The target processor architecture includes at least one of ARM64, ARM32 and x86_64.

4. The method according to claim 1, characterized in that, If an older decoder instance already exists, the new version's shared library file overwrites the old version's file, and the older decoder instance continues to run in memory until it is replaced. The replacement of the older decoder instance includes: after the older decoder instance finishes processing the currently decoding CAN frame, it performs an atomic replacement of the instance pointer before the next frame arrives; after the replacement, the newly arriving CAN frame is processed by the new decoder instance; or, the new decoder first processes a preset number of consecutive frames in parallel observation mode and performs a consistency comparison with the old version's results; after the comparison passes, it switches to the new version as the primary decoder.

5. The method according to claim 1, characterized in that, The unified data model definition file is a protocol buffer definition file; the generation of target platform decoder code includes: based on a template engine, converting the signal structure information in the protocol buffer definition file into code output corresponding to the target platform.

6. The method according to claim 1, characterized in that, The streaming process is a streaming engine that integrates a custom memory data source plugin; the custom memory data source plugin reads data through the shared memory region.

7. The method according to claim 1, characterized in that, The target platform decoder code is a shared library file, and the shared memory layout is defined as a structure declared using compact attribute annotations. The streaming process reads the shared memory region through a cross-language call interface, and constructs the starting address and length information of the structure array stored in the shared memory region into a data structure in the native language reference form of the streaming process according to the shared memory layout definition.

8. A CAN signal streaming processing system based on cloud and zero-copy shared memory, characterized in that, This includes cloud-based compilation platforms and vehicle-mounted processing equipment; The cloud-based compilation platform includes: The compilation module is used to generate target platform decoder code, shared memory layout definition, and streaming processing mode definition based on the unified data model definition file; the unified data model definition file describes the signal name, signal type, and signal number contained in each CAN frame; The distribution module is used to distribute the generated target platform decoder code, the shared memory layout definition, and the streaming processing mode definition to the vehicle-side processing device; The vehicle-side processing equipment includes: The code loading module is used to respond to configuration change events by loading the shared library file corresponding to the target platform decoder code into anonymous memory through a system call to create a memory file, so as to form a decoder process; The shared memory management module is used to create a shared memory region based on the shared memory layout definition; the shared memory region adopts a circular buffer structure and achieves lock-free concurrent access through atomic operations; The decoder module is used to acquire raw CAN data, decode the raw CAN data, and store the decoded signal data into the shared memory area. The process management module is used to start the streaming processing process based on the defined streaming processing mode. The streaming module is used to read the shared memory region through a cross-language calling mechanism and construct the read data into a data structure in the form of local language references.

9. The system according to claim 8, characterized in that, The decoder module is further configured to query a preset hash table before performing signal decoding to obtain the reference count value corresponding to the target signal. When the reference count value is greater than zero, decoding is performed on the target signal. The key of the hash table is the signal identifier, and the value is the number of streaming rules referencing that signal. The signal identifier is composed of a channel number and a CAN identifier. When a streaming rule is added, the reference count value of each signal referenced by that rule is incremented. When a streaming rule is deleted, the reference count value of each signal referenced by that rule is decremented. The increment and decrement operations of the reference count value are bound to the configuration change event.

10. A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method according to any one of claims 1 to 7.

Images