Hybrid application layer data processing system and method based on vehicle-mounted CAN / LIN bus

Abstract

The invention discloses a data processing system and method based on a vehicle-mounted CAN / LIN bus hybrid application layer, and the system comprises a data collection layer which is used for receiving and transmitting a CAN message, and receiving and transmitting an LIN message; the cache management layer comprises a cache strategy and cache partitions, the cache strategy comprises cache according to a matrix table and cache index counting, and the cache partitions comprise a CAN channel partition and an LIN channel partition; the network transmission layer comprises a communication protocol and frame header filling, the communication protocol comprises a UDP (User Datagram Protocol) and CAN / LIN (Controller Area Network / Local Interconnect Network) packaging and reassembling, the frame header filling comprises a filling format and filling content, and the method further comprises a CAN / LIN message circular cache management method, a dynamic template CAN data acquisition method and a timestamp synchronous calibration method. The method has the advantages that the CAN message processing efficiency is improved, the memory occupation is reduced, the timestamp synchronization precision is enhanced, dynamic configuration and template switching are supported, and CAN / LIN bus unified management is realized.

Description

Technical Field

[0001] This invention relates to the field of automotive electronics technology, specifically to a data processing method and system for a hybrid application layer of automotive CAN / LIN buses. In particular, this application provides a technical solution for achieving unified processing, efficient caching, intelligent acquisition and reassembly, and reliable transmission of CAN bus and LIN bus data in an in-vehicle data acquisition terminal, applicable to application scenarios such as remote monitoring, fault diagnosis, and data acquisition in intelligent connected vehicles. Background Technology

[0002] The automotive industry is undergoing a profound transformation driven by "software-defined" and "intelligent connectivity." Modern vehicles have evolved into complex systems integrating numerous electronic control units (ECUs), communicating internally via in-vehicle networks. The Controller Area Network (CAN) bus and the Local Area Network (LIN) bus form the backbone and capillaries of the vehicle's nervous system, respectively responsible for critical control functions and low-cost body control. The data messages flowing on these buses are the ultimate basis for understanding vehicle status and diagnosing electronic faults.

[0003] The Controller Area Network (CAN) bus is a serial communication protocol developed by Bosch in 1986 to solve the data exchange problem between numerous control units in modern automobiles. After more than 30 years of development, the CAN bus has become one of the most important and widely used fieldbuses in the automotive electronics field.

[0004] The core technical features of the CAN bus include: 1. Priority-based lossless arbitration mechanism: This is one of the core features of the CAN bus, ensuring the real-time performance of high-priority messages. When multiple nodes send data simultaneously, through bit-by-bit arbitration of identifiers, the message with the highest priority (the smaller the identifier value, the higher the priority) gains bus access, while lower-priority messages automatically withdraw from transmission and retry when the bus is idle. This process does not cause any data corruption or loss, and ultimately the message with the highest priority wins the right to use the bus.

[0005] 2. Message Priority Management within the Node (FIFO and Priority Queues): It is important to clarify that FIFO (First-In, First-Out) is not a bus arbitration mechanism, but rather an internal message buffer management strategy of the node's controller. A CAN node may have multiple messages to be sent simultaneously, and its internal CAN controller typically provides multiple send mailboxes or buffers. Under certain configurations, the controller will ignore the priority of CAN messages and submit and send them in the order they enter the send buffer.

[0006] 3. Powerful error handling capabilities: The CAN protocol defines a comprehensive error detection mechanism, including Cyclic Redundancy Check (CRC), frame inspection, acknowledgment errors, bit stuffing, etc.

[0007] 4. High Reliability Design: The CAN bus features differential signal transmission characteristics and strong resistance to electromagnetic interference. Nodes automatically shut down their output when a serious error is detected, preventing impact on the entire network and demonstrating excellent fault isolation capabilities.

[0008] However, the traditional CAN bus data processing methods that currently dominate the market still have the following problems: First, the processing of multi-channel CAN messages lacks a unified cache management mechanism, resulting in low memory utilization efficiency. Second, existing CAN message acquisition methods typically use static configuration, which cannot adapt to dynamically changing network requirements. Furthermore, the low efficiency of multi-channel CAN message acquisition easily leads to message loss.

[0009] In existing technologies, CAN message processing often uses simple queues or fixed-size buffers, which can easily lead to data loss when processing a large number of sudden CAN messages.

[0010] Ensuring timestamp synchronization between different channels is a significant challenge in multi-channel CAN data processing. Existing technologies typically employ hardware timestamps or simple software timing, but these methods suffer from shortcomings in accuracy and reliability. Furthermore, the acquisition and reassembly of multi-channel data lacks an intelligent management mechanism.

[0011] LIN bus, a low-cost, low-speed in-vehicle serial communication protocol, has been widely used in the automotive industry since it was proposed by the LIN Alliance in 1998. LIN bus was originally designed as a supplement to CAN bus to implement distributed electronic system control in automobiles, especially in situations where the high bandwidth and complex functions of CAN bus are not required.

[0012] The technical features of the LIN bus include: 1. Single Master-Multiple Slave Architecture: The LIN network adopts a master-slave structure, consisting of one master node and up to 16 slave nodes. The master node controls the communication scheduling of the entire network. 2. Low communication rate: The maximum communication rate is 20kbps, far lower than the 5Mbps of the CAN bus, making it suitable for applications with low real-time requirements. 3. Simplified frame structure: A LIN frame consists of two parts: a frame header (sent by the master node) and a response (sent by the slave node). The frame header includes a synchronization interval field, a synchronization field, and an identifier field. 4. Low-cost implementation: Based on the Universal Serial Interface (UART), the hardware implementation cost is significantly lower than that of the CAN bus. 5. Deterministic Scheduling: Ensures deterministic communication through a predefined scheduling table. While the LIN bus performs well in low-cost applications, it still faces several challenges in practical use. First, its limited bandwidth—a maximum communication rate of 20kbps—severely restricts its use in data-intensive applications and cannot meet the demands of emerging intelligent vehicle applications. Second, reliability is limited; the LIN bus lacks the robust error detection and fault tolerance mechanisms of the CAN bus. The single-master node design also introduces a single point of failure risk; if the master node fails, the entire network will be paralyzed. Third, clock synchronization accuracy is crucial. Slave nodes synchronize with the master node's clock via a synchronization field, and the synchronization accuracy is affected by the node's crystal oscillator accuracy and temperature stability, potentially leading to bit timing errors during long frame transmissions.

[0013] With the increasing complexity of automotive electronic architecture, the mixed use of LIN and CAN buses has become the industry norm. LIN and CAN buses differ significantly in the physical layer, data link layer, and application layer, which brings the following technical challenges to mixed bus data processing: Protocol differences make unified processing difficult: the LIN bus uses a master-slave architecture with a low communication rate (maximum 20kbps), while the CAN bus uses a multi-master architecture with a communication rate of up to 5Mbps. This difference makes it difficult to unify the data processing of the two buses.

[0014] Message format incompatibility: The LIN message frame structure is relatively simple and lacks the arbitration mechanism and error detection capability of the CAN bus, which requires the use of different verification and recovery mechanisms during data processing.

[0015] Timing synchronization is complex: the LIN bus communicates based on a predefined schedule table, while the CAN bus is event-driven. These two different communication mechanisms make unified timestamp management complex.

[0016] Currently, the industry lacks an effective unified management solution for CAN / LIN hybrid buses. Existing methods typically treat CAN and LIN as two independent systems, processing them separately before data fusion. This approach has the following problems: Resource waste: Two independent processing systems lead to redundant investment in hardware and software resources.

[0017] Data consistency is difficult to guarantee: separate processing may lead to inconsistencies in the timestamp base of CAN messages and LIN messages.

[0018] High system complexity: Maintaining two systems increases the complexity of development and maintenance.

[0019] In summary, existing technologies exhibit significant gaps in CAN / LIN hybrid bus data processing. Particularly in areas such as multi-channel message buffering, dynamic acquisition, and timestamp synchronization, systematic solutions are lacking. This severely restricts the development of intelligent connected vehicle data acquisition systems, urgently requiring an innovative technological solution to address these issues. Summary of the Invention

[0020] In automotive CAN / LIN bus hybrid application layer data processing, this application aims to solve the following key technical problems: First, multi-channel CAN message processing. In automotive electronic systems, with the continuous increase in functionality, the CAN bus needs to process messages from multiple channels. How to achieve efficient caching of multi-channel CAN messages to avoid data loss and memory overflow is a crucial issue. Traditional methods are prone to acquisition errors and delays during multi-channel CAN message acquisition and reassembly, making it difficult to meet real-time requirements. Therefore, an efficient multi-channel CAN message acquisition and reassembly method is needed.

[0021] Second, the timestamp synchronization strategy. Different CAN nodes have clock discrepancies, and CAN bus transmission has delays. How to accurately calibrate timestamps based on UTC timestamp messages, and how to fuse multiple time sources to generate precise timestamps, ensuring millisecond-level accuracy, are urgent problems to be solved.

[0022] Third, dynamic template control. The requirements of automotive electronic systems are constantly changing, necessitating the ability to dynamically adjust the CAN data acquisition template according to different scenarios and tasks. This application aims to address how to drive the switching of acquisition options, acquisition version numbers, and acquisition templates through received message parameters; how to perform dynamic channel enable control based on dynamic templates A and D; and how to perform special processing of network management (NM) messages to meet the dynamic configuration requirements of the system.

[0023] Fourth, LIN bus processing. The LIN bus and CAN bus differ in hardware interface, communication protocol, data format, and transmission rate. Achieving unified data processing for both, enabling the system to manage LIN and CAN messages collaboratively, is crucial for hybrid bus applications. When LIN and CAN messages are acquired together, conflicts and errors can easily occur due to their different acquisition rules, necessitating an effective hybrid acquisition method.

[0024] Fifth, CAN / LIN to Ethernet data forwarding. When forwarding CAN / LIN data to Ethernet, it is necessary to automatically generate data frame headers to adapt to the Ethernet transmission format. Simultaneously, for ease of system management and maintenance, version information needs to be dynamically embedded. Furthermore, the management of the UDP send buffer also affects the efficiency and stability of data forwarding. How to optimize UDP send buffer management and improve data forwarding performance is a key focus of this application.

[0025] To address the aforementioned technical problems, this application proposes the following innovative technical solutions: A multi-channel CAN message circular buffer pool management method is proposed. This application designs a CAN message storage mechanism based on a signal buffer pool, which centrally manages multi-channel CAN messages to avoid memory fragmentation caused by independent caching of each channel. Each CAN channel corresponds to a signal buffer pool, which consists of multiple buffer units, each used to store one CAN message. This design allows CAN messages from different channels to be stored separately, avoiding message confusion and conflicts. The buffer units adopt a fixed-size structure and contain key information such as the CAN message identifier, data, and timestamp for fast storage and retrieval. When the CAN controller receives a new CAN message, it stores it in the corresponding signal buffer pool according to the channel number.

[0026] To efficiently manage the signal buffer pool, this application employs a circular buffer index management algorithm. This algorithm maintains a circular index to record the currently available buffer unit positions. When a new CAN message arrives, it is directly stored in the buffer unit pointed to by the circular index, and then the circular index is updated. When the buffer pool is full, new messages overwrite the oldest stored messages, ensuring the buffer pool is always available. This method enables fast storage and retrieval of CAN messages while avoiding memory fragmentation. The circular index update operation is simple and efficient, requiring only an increment of the index value, and is reset to 0 when the buffer pool size limit is reached.

[0027] In multi-channel CAN message acquisition and reassembly, this application achieves accurate acquisition and reassembly based on the CAN message identifier and channel, combined with a pre-configured matrix table. The matrix table records the source channel and data length corresponding to each CAN message identifier. After a CAN message is stored in the signal buffer pool, the system queries the matrix table based on the message identifier to determine its source and destination channels and data length, and then forwards the message to the corresponding channel and module for processing. This acquisition and reassembly method ensures that CAN messages arrive at their destination accurately and quickly, improving the system's communication efficiency and real-time performance. The matrix table can be dynamically updated according to system requirements to adapt to different communication scenarios and tasks.

[0028] A timestamp synchronization calibration method. This application combines the second-level time base of UTC timestamp messages with the millisecond-level calculation results of the STBM (Synchronized Time-Base Manager) module to achieve high-precision timestamp synchronization, solving the problem of insufficient accuracy of traditional single time sources.

[0029] The UTC timestamp message serves as the system's base time message and is periodically sent by the main controller (every 500 milliseconds). Its data frame contains only a second-level timestamp (such as the cumulative number of seconds since system startup) and no millisecond-level information. Upon receiving a UTC timestamp message, the system first parses the second-level timestamp (denoted as base_sec) as the base for the "second" portion of the timestamp. Simultaneously, it reads the current count value of the STBM module (denoted as stbm_cnt). The STBM module operates at a fixed frequency (20MHz) with microsecond precision, and calculates the current number of milliseconds using stbm_cnt (denoted as current_ms = stbm_cnt / 1000) as the "millisecond" portion of the timestamp. When a new UTC timestamp message is received, the system updates base_sec to the newly parsed second-level time and resets the STBM count value to 0, ensuring that current_ms restarts counting from 0, thus achieving a timestamp anchoring system of "second-level base + millisecond-level supplementation." This fusion method does not rely on other time sources (such as GPS). It can generate continuous and stable timestamps by using only a fixed-period second-level reference and a high-frequency timer for millisecond counting, thus avoiding the problem of multi-source time conflicts.

[0030] Furthermore, the UTC timestamp message is a special type of CAN message containing precise time information. When the system receives a UTC timestamp message, it extracts the time information and compares it with the local clock. Based on the difference between the two, the time deviation is calculated. If the calculated time deviation is less than 5 seconds, the system continues timing according to the local clock; if the deviation is greater than 5 seconds, the system calibrates the local clock based on the time deviation to synchronize the local clock with the time in the UTC timestamp message. The final calculated millisecond-level timestamp is mapped to the corresponding Ethernet segment's UDP packet as the acquisition timestamp of the entire UDP packet.

[0031] A dynamic template CAN data acquisition control system. This application uses CAN acquisition message parameters to drive the switching of CAN data acquisition templates. The CAN acquisition message parameters contain key data such as system configuration information and acquisition requirements. When the system's acquisition requirements change, such as switching from acquiring engine operating data to acquiring vehicle driving data, this functional transition can be achieved by modifying the CAN acquisition message parameters. The system selects the appropriate acquisition template based on the updated CAN acquisition message parameters. The acquisition template defines the rules for CAN data acquisition, including the acquisition channel, data format, and acquisition frequency. In this way, dynamic configuration of CAN data acquisition can be achieved to meet the acquisition needs in different scenarios. The CAN acquisition message parameters can be set and updated via external devices, or they can be automatically adjusted according to the system's operating status.

[0032] Based on dynamic templates A and D, this application implements dynamic enable control of the CAN channel. Dynamic templates A and D are two dynamic configuration parameters, representing the acquisition requirements under two different operating conditions. The system determines whether the current acquisition template is dynamic template A or dynamic template D based on the current CAN acquisition message parameters, thus determining which CAN message data needs to be acquired. When an acquisition template is enabled, the system activates the acquisition flag corresponding to that template and begins acquiring data to the payload area of ​​the UDP message. When a template is switched, the system clears the acquisition flag of the previous template, stops acquiring the CAN message corresponding to the previous template, and activates the acquisition flag of the new template, acquiring the CAN message corresponding to the newly switched template. This effectively saves system resources and improves data acquisition efficiency. Dynamic templates A and D can be dynamically adjusted according to the system's operating status and acquisition requirements to achieve optimal channel enable control. For the remaining two empty templates (dynamic template B and dynamic template C), if switched to one, three empty UDP messages with the current platform version number, and a count and content of all zeros are sent at 1-second intervals.

[0033] This application employs a special processing mechanism for Network Management (NM) messages. NM messages are used to manage the state of the CAN network, such as node sleep and wake-up. Their CANID ranges from 0x600 to 0x67F. Upon receiving the corresponding PowerMode message, the system first parses it to determine its content. Different processing methods are applied to PowerMode messages with different content. When a PowerMode on message is received, the system updates the CAN acquisition list and does not acquire any network management messages within the current template; when a PowerMode off message is received, the system updates the CAN acquisition list again and acquires all network management messages within the current template. This special processing mechanism ensures the stable operation of the CAN network and improves system reliability.

[0034] This application presents a unified management method for LIN bus message processing and CAN bus. Similar to CAN message processing, this application designs a circular buffer pool management mechanism for LIN messages. Each LIN channel has a corresponding signal buffer pool, employing a circular buffer index management algorithm to achieve efficient storage and retrieval of LIN messages. When the LIN controller receives a new LIN message, it stores it in the corresponding signal buffer pool. The buffer unit structure in the buffer pool is similar to that of the CAN message buffer unit, but it is optimized according to the characteristics of LIN messages, including the LIN message identifier, data, channel number, and other information. Through the circular buffer index management algorithm, the system can quickly find an available buffer unit to store the new message, and automatically overwrite the oldest message when the buffer pool is full, ensuring efficient utilization of the buffer pool. The management and update operations of the circular index are simple and reliable, adapting to the transmission characteristics of LIN messages.

[0035] This application establishes a unified matrix table for the unified acquisition and reassembly of LIN and CAN messages. The matrix table contains node information for both CAN and LIN messages. The system queries the unified matrix table based on the message identifier and channel to determine if the message falls within the table's acquisition range. During acquisition, the system prioritizes messages, forwarding higher-priority messages first to ensure timely transmission of critical messages. The unified matrix table can be dynamically updated according to system configuration and requirements, enabling efficient collaborative transmission of LIN and CAN messages. The matrix table's query and update operations are fast and accurate, adaptable to complex message acquisition and reassembly needs.

[0036] Similar to CAN data acquisition, this application implements a dynamic template control mechanism for LIN messages. Driven by CAN acquisition message parameters, the LIN message acquisition template is switched according to different acquisition tasks and system requirements. The acquisition template defines the acquisition rules for LIN messages, including the acquisition channel, data format, and acquisition message ID. The system selects the appropriate acquisition template based on changes in the CAN acquisition message parameters and configures the LIN controller accordingly. During acquisition, the system dynamically adjusts the enabling state of the LIN channel and the data acquisition range according to the template requirements. This enables flexibility and adaptability in LIN message acquisition, meeting the LIN message processing needs of different scenarios. The parsing of CAN acquisition message parameters and template switching operations are fast and reliable, enabling timely responses to changes in system requirements.

[0037] An optimized method for CAN-to-Ethernet data forwarding. This application employs an automatic data frame header generation algorithm when forwarding CAN data to Ethernet. This algorithm automatically generates the data frame header according to the Ethernet transmission protocol and format requirements. The data frame header contains key information such as the source address, destination address, platform version number, and acquisition version number. The system generates the corresponding data frame header based on the source and destination of the CAN data, as well as the Ethernet configuration parameters. When generating the source address, it converts the MAC address based on the CAN node; when generating the destination address, it sets it according to the destination IP address of the Ethernet. By automatically generating the data frame header, it ensures that CAN data can be correctly transmitted over Ethernet, improving the efficiency and accuracy of data forwarding. The data frame header generation process is fast and efficient, meeting the needs of real-time data transmission.

[0038] To facilitate system management and maintenance, this application implements a dynamic embedding mechanism for version information. When generating Ethernet data frames, the system dynamically embeds the CAN data version information into the data frame. This version information includes the CAN data protocol version, software version, and data format version. Thus, upon receiving a data frame, the receiving end can determine the data's compatibility and validity based on the version information, thereby enabling correct processing. The embedding location and format of the version information conform to the standard Ethernet protocol, ensuring it is not tampered with during transmission. The version information can be dynamically adjusted based on updates and upgrades to CAN data to guarantee data consistency and reliability.

[0039] A hybrid bus data acquisition system is presented. This application implements unified timestamp synchronization for CAN / LIN messages in the hybrid bus data acquisition system. Through the multi-time source fusion timestamp generation method described above, unified timestamps are generated for CAN and LIN messages. After CAN and LIN messages are acquired and stored in the buffer pool, the system adds a unified timestamp to them based on the time source information. This ensures the time consistency of CAN and LIN messages, facilitating subsequent data processing and analysis. During synchronization, the system considers the transmission delay differences between the CAN and LIN buses and corrects the timestamps to improve synchronization accuracy. The timestamp generation and synchronization operations are efficient and accurate, guaranteeing the time consistency of the hybrid bus data.

[0040] This application designs a specialized hybrid bus data frame header generation algorithm. Based on the characteristics of CAN / LIN messages and the requirements of the target transmission network, a unified data frame header is generated. The data frame header contains key information such as message type (CAN or LIN), source address, destination address, count, and timestamp. During data frame header generation, the system sets corresponding field values ​​according to the message source and destination, as well as the protocol specifications of the transmission network. Through this unified data frame header generation algorithm, unified transmission and processing of CAN / LIN messages in a hybrid bus system can be achieved. The data frame header generation process is fast and flexible, adapting to the transmission requirements of CAN / LIN hybrid buses.

[0041] During the data transmission phase, this application employs a multi-bus data fusion transmission mechanism. The system merges CAN and LIN messages according to certain rules and then sends them to the target network. During the fusion process, the system sorts and combines messages based on factors such as priority and timestamp. Messages with higher priority are sent first, and messages with similar timestamps are grouped together as much as possible to improve data transmission efficiency and real-time performance. The system adjusts the UDP packet transmission rate and data packet size appropriately based on the current CAN / LIN message transmission frequency. Through this multi-bus data fusion transmission mechanism, network resources can be fully utilized to achieve efficient transmission of CAN / LIN hybrid bus data. The coordinated and orderly data fusion and transmission operations fully leverage the performance advantages of the hybrid bus system.

[0042] This application achieves the following significant beneficial effects through the above technical solution: Improving CAN message processing efficiency: A multi-channel CAN message circular buffer pool management method based on signal buffer pool and circular buffer index management achieves efficient storage and fast retrieval of CAN messages, reducing data processing latency and improving CAN message processing efficiency. In multi-channel CAN message acquisition, accurate matrix tables and fast acquisition and reassembly algorithms ensure that CAN messages arrive at the target node accurately and in a timely manner, further improving the efficiency and real-time performance of CAN message processing.

[0043] Reduced memory footprint: The circular buffer management method makes the storage of CAN and LIN messages more efficient, avoids memory fragmentation, and effectively reduces memory usage. Through reasonable cache pool design and index management, the system can store more messages in limited memory space, improving memory utilization.

[0044] Enhanced timestamp synchronization accuracy: A timestamp calibration algorithm based on UTC timestamp messages and a timestamp generation method using multi-time source fusion achieves millisecond-level timestamp synchronization accuracy in CAN data acquisition, providing more accurate time data for system monitoring and fault diagnosis. In hybrid bus data acquisition systems, unified timestamp synchronization of CAN / LIN messages further ensures data consistency in time, improving the system's ability to process and analyze hybrid bus data.

[0045] Supports dynamic configuration and template switching: The dynamic template CAN data acquisition control system, driven by CAN acquisition message parameters, enables the system to flexibly switch acquisition templates according to different needs and scenarios, realizing dynamic enable control of CAN and LIN channels and meeting the ever-changing configuration requirements of automotive electronic systems. This dynamic configuration and template switching capability improves the system's adaptability and flexibility, enabling it to better cope with different application scenarios and tasks.

[0046] Unified Management of CAN / LIN Buses: Through a unified matrix table and message processing mechanism, this application achieves unified acquisition, reassembly, and collaborative processing of CAN / LIN messages, improving the system's ability to manage hybrid bus data. The unified management mechanism enables better collaboration between the CAN and LIN buses, reducing system complexity and improving system reliability and stability.

[0047] Reduced System Complexity: This application simplifies the data processing flow of the CAN / LIN hybrid bus through an innovative technical solution, thereby reducing system complexity. A unified management mechanism, efficient processing methods, and collaborative working modes enable better cooperation among various parts of the system, reducing internal conflicts and contradictions, and improving overall system performance and maintainability. Attached Figure Description

[0048] Figure 1 The diagram illustrates the overall architecture of the CAN / LIN hybrid system in a specific embodiment of the present invention. It shows the overall system architecture of this application, including three main layers: the data acquisition layer, the buffer management layer, and the network transmission layer, as well as the data flow and control flow relationships between each layer. Figure 2 The flowchart illustrating the circular cache pool management process in this specific embodiment of the invention describes in detail the storage, management, and retrieval processes of CAN and LIN messages in the circular cache pool, including index calculation, boundary handling, and data consistency guarantee mechanisms. Figure 3 This invention provides a specific embodiment reflecting the dynamic template control state diagram, illustrating the state transition process of dynamic template switching, including states such as template matching, data acquisition enable control, and platform version number field control; Figure 4 The flowchart of the timestamp synchronization algorithm is shown in the specific embodiment of the present invention. It describes the timestamp generation algorithm of multi-time source fusion, including steps such as local timestamp acquisition, CAN message timestamp parsing, multi-time source fusion and accuracy calibration. Figure 5 The diagram illustrates the structure of a hybrid data frame in a specific embodiment of the present invention, showcasing the structural design of a unified data frame, including the frame header field (source address, destination address, message length), payload data field (collection timestamp, version number, transmission count), and other parts. Detailed Implementation

[0049] The technical solutions in this embodiment 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.

[0050] It should be noted that in the description of this invention, all directional indications (such as up, down, forward, backward, etc.) are only used to explain the relative positional relationship and operational status of each component under a certain forward posture (as shown in the figure). If the forward posture changes, the directional indication will also change accordingly.

[0051] Furthermore, in this invention, the use of terms such as "first," "second," etc., is for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. In the description of this invention, "a number" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0052] Furthermore, the technical solutions of the various embodiments of the present invention can be combined with each other, but only if they are feasible for those skilled in the art. If the combination of technical solutions is contradictory or cannot be implemented, it should be considered that such combination of technical solutions does not exist and is not within the scope of protection claimed by the present invention.

[0053] like Figure 1-5 As shown, the first step is the circular buffer pool management. Raw messages are collected from the CAN / LIN message receiving and sending processing functions and parsed to determine if the message ID falls within the collection range of the matrix table. If it does, the circular buffer management module updates the index using a circular buffer index management algorithm. For each message conforming to the matrix table rules collected, the index count is incremented by 1, and the buffer boundary is checked in real time. If the buffer threshold is not reached, the data content is stored in the calculated and arranged signal buffer pool according to the index count. If the buffer threshold is reached, the index count is reset to 0, and new messages overwrite the oldest stored messages in the signal buffer pool, thus achieving circular message storage.

[0054] Each CAN / LIN channel supports a different number of buffers to meet varying data storage needs. Messages received or sent that are not within the acquisition range will not participate in subsequent circular buffer management. The message buffer size is optimized based on the specific application scenario and data traffic. Full use is made of the buffer pool space to avoid memory waste, ensuring the buffer pool always has space to store new messages while guaranteeing message timeliness.

[0055] Secondly, there's dynamic template control. The CAN acquisition message parameter structure contains key data such as system configuration information and acquisition requirements, and is the core parameter of dynamic template control. For example, the acquisition template selection field indicates the acquisition template to be used, and the acquisition enable configuration field configures the acquisition status of CAN and LIN messages. By parsing and processing these fields, the system can dynamically adjust the acquisition template and acquisition enable status according to different needs.

[0056] The system performs template matching based on the acquisition template selection field in the CAN acquisition message parameters. For example, when the acquisition template is selected as dynamic template A, the system will configure the acquisition rules for the CAN and LIN channels according to the definition of dynamic template A, including the acquisition channel, data format, and data length; if dynamic template D is selected, the system will configure it according to dynamic template D. Through a precise template matching algorithm, the system can accurately switch acquisition templates according to different tasks and scenarios.

[0057] Based on the acquisition enable configuration field in the CAN acquisition message parameters, and in accordance with the requirements of dynamic templates A and D, the enable status of the CAN and LIN channels is dynamically updated. When the enable condition of a channel is met, the system activates the controller for that channel and begins data acquisition; when the enable condition is not met, the system deactivates the controller for that channel and stops data acquisition. For example, when the vehicle starts, based on the initial CAN acquisition message parameters, the CAN and LIN channels related to vehicle startup are enabled to ensure the timely acquisition of critical data.

[0058] For Network Management (NM) messages, upon receiving the corresponding PowerMode message, the system first parses it to determine its content. Different processing methods are applied to PowerMode messages with different content. When a PowerMode on message is received, the system updates the CAN acquisition list and does not acquire any network management messages within the current template. When a PowerMode ≠ on message is received, the system updates the CAN acquisition list again and acquires all network management messages within the current template. For example, if a CAN acquisition message parameter corresponds to acquisition template field A and a PowerMode message is received as on, all network management messages within the current dynamic template A are not acquired.

[0059] Thirdly, timestamp synchronization is performed. First, the local clock (in microseconds) is obtained from the STBM module as the base time. Then, the time information (in seconds) in the received UTC timestamp message is encoded according to a specific format, converting it into timestamp information consistent with the local time. Simultaneously, the timestamp in the currently received UTC timestamp message is compared with the local time timestamp (in seconds), and the time deviation is calculated. If the calculated time deviation is greater than 5 seconds, the second-level timestamp in the UTC timestamp message is overwritten with the second-level timestamp of the local time. The millisecond to microsecond-level timestamp portion of the local time is uniformly calculated and reduced to the millisecond level, and the two are merged into one, becoming the final millisecond-level accurate acquisition timestamp filled into the UDP packet. If the calculated time deviation is less than 5 seconds, the second-level timestamp of the local time remains unchanged, and the millisecond to microsecond-level timestamp portion is uniformly calculated and reduced to the millisecond level, combined into the final millisecond-level accurate acquisition timestamp filled into the UDP packet.

[0060] Fourthly, data forwarding is optimized. The frame header generation function dynamically constructs the frame header by parsing message attributes. First, it extracts the message's timestamp, acquisition version number, platform version number, and transmission count. Then, it concatenates the frame header according to the format "timestamp (8 bytes) + acquisition version number (2 bytes) + platform version number (2 bytes) + transmission count (2 bytes)" to ensure that the frame header information is complete and in a consistent format. The remaining information, such as the source address, destination address, and message length, is automatically filled in by the other modules of the protocol stack according to the configuration at the time of transmission.

[0061] The automatic embedding mechanism for acquisition version information is activated during system initialization. The system reads the version configuration file stored in non-volatile memory to obtain a 2-byte version number. The platform version number is dynamically changed based on the platform version number field parameter in the real-time received CAN acquisition messages, and its length is also 2 bytes. During frame header generation, the acquisition version number is fixedly embedded in bytes 9 to 10 of the frame header, and the platform version number is fixedly embedded in bytes 11 to 12 of the frame header. When the acquisition version is upgraded, the system will synchronously update the acquisition version information in the frame header.

[0062] The transmission count management is implemented through a global counter. The counter increments by 1 for each successfully transmitted data frame; it is automatically reset to zero when it reaches its maximum value (65535); the counter value is used as an extended field (optional) in the frame header to determine the continuity of data transmission at the receiving end, and can identify data loss when a count jump is detected.

[0063] Fifth is the optimization of LIN message processing. Similar to CAN messages, LIN message circular buffer management employs a circular index and buffer boundary handling mechanism. LIN messages are stored in structures using circular indexes to achieve efficient storage and retrieval. When the buffer pool is full, new messages overwrite the oldest stored messages, ensuring that the buffer pool always has space to store new messages.

[0064] In the acquisition and forwarding module, a unified matrix table is established to package and reassemble LIN and CAN messages. The matrix table is queried based on the message ID and channel to determine message priority. During forwarding, messages are sorted according to priority, with higher-priority messages forwarded first to ensure timely transmission of critical messages. The system also adjusts the UDP packet transmission rate and packet size based on the current CAN / LIN message transmission frequency. If too many messages are acquired simultaneously, the UDP packet transmission period is shortened, and the number of packets sent per UDP packet is increased (fragmentation is implemented if the packet size exceeds 1500 bytes); conversely, if too few messages are acquired simultaneously, the UDP packet transmission period is lengthened, and the number of packets sent is reduced.

[0065] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in the present invention, based on the technical solution and inventive concept of the present invention, should be covered within the scope of protection of the present invention.

Claims

1. A data processing system based on a hybrid application layer of vehicle CAN / LIN bus, characterized in that, include: The data acquisition layer is used for receiving and sending CAN messages, as well as receiving and sending LIN messages; The cache management layer includes cache policies and cache partitions. The cache policies include cache based on matrix tables and cache index counting. The cache partitions include CAN channel partitions and LIN channel partitions. The network transport layer includes communication protocols and frame header padding. The communication protocols include UDP and CAN / LIN packet reassembly. The frame header padding includes padding format and padding content.

2. A data processing method for a hybrid application layer based on an in-vehicle CAN / LIN bus, characterized in that, This includes methods for managing CAN / LIN message loop buffers, dynamic template CAN data acquisition, and timestamp synchronization calibration.

3. The data processing method based on the hybrid application layer of vehicle CAN / LIN bus according to claim 2, characterized in that, The CAN / LIN message circular buffer management method includes: S1. Collect received or transmitted CAN / LIN messages; S2. Determine whether the message ID belongs to the matrix table collection range; S3. If the message ID belongs to the matrix table collection range, update the circular buffer index and determine whether the index has reached the buffer threshold. If the index has reached the buffer threshold, reset the index to zero; if the index has not reached the buffer threshold, increment the index count by 1, and then store the message in the signal buffer pool according to the index. S4. If the message ID is not within the scope of the matrix table collection, then discard the message.

4. The data processing method based on the hybrid application layer of vehicle CAN / LIN bus according to claim 2, characterized in that, The dynamic template CAN data acquisition method includes: S11. Parse the CAN acquisition message parameters; S22. Determine the matching status of the selected fields in the data collection template. If the selected fields in the data collection template match dynamic template A, then configure the data collection rules according to dynamic template A; if the selected fields in the data collection template match dynamic template D, then configure the data collection rules according to dynamic template D. S33. Parse the acquisition enable configuration field, and then determine whether the channel enable condition is met. If the channel enable condition is met, activate the channel controller and start acquisition; if the enable condition is not met, close the channel controller and stop acquisition. S44. Determine whether a PowerMode message has been received. If a PowerMode message has been received, update the collection list and do not collect NM messages. If no PowerMode message has been received, update the collection list and collect NM messages.

5. The data processing method based on the hybrid application layer of vehicle CAN / LIN bus according to claim 2, characterized in that, The timestamp synchronization calibration method includes: S111, Obtain local microsecond-level time from the STBM module; S222, Receive UTC timestamp messages and decode the second-level time; S333, Calculate the second-level deviation between local time and UTC time; S444. Determine if the time deviation is greater than 5 seconds. If the time deviation is greater than 5 seconds, overwrite the local second-level timestamp with the UTC second-level timestamp. If the time deviation is less than or equal to 5 seconds, keep the local second-level timestamp unchanged. S555: Compresses the microsecond-level time portion to the millisecond level; S666: Combine second-level and millisecond-level timestamps to generate the final timestamp.

Images