Controller area network (CAN) signal routing method and apparatus, vehicle

Abstract

This disclosure provides a method, apparatus, and vehicle for routing CAN signals in a controller area network (CAN). The method includes: running a first task, wherein the first task includes performing a receiving action, an unpacking action, and a routing action to obtain the target CAN signal corresponding to the source CAN message when the source CAN message arrives; running a virtual task in parallel with the first task, wherein the virtual task includes verifying the source CAN message; and running a second task, wherein the second task includes packaging the target CAN signal obtained from the first task into a target CAN message and sending the target CAN message, wherein the execution cycle of the first task is shorter than the execution cycle of the virtual task. By setting the verification operation to be executed in an independent virtual task, the signal delay of source CAN message routing is significantly reduced, ensuring the correctness of the verification operation, and achieving optimal resource allocation with minimal architectural changes.

Description

Technical Field

[0001] This disclosure relates to the field of vehicle control technology, specifically to a CAN signal routing method and device for controller area networks and a vehicle. Background Technology

[0002] In modern automotive electrical and electronic architecture, the Controller Area Network (CAN) is a key bus for enabling reliable communication between various Electronic Control Units (ECUs). With the continuous improvement of vehicle intelligence and connectivity, especially with the introduction of complex functions such as Advanced Driver Assistance Systems (ADAS), body domain control, and chassis integrated control, the number of signals that need to be exchanged between ECUs has surged, and higher requirements have been placed on the real-time performance and determinism of signal transmission.

[0003] Traditional CAN signal routing strategies typically distribute the processing flow across two operating system tasks with fixed cycles. Task one handles CAN message reception, verification, unpacking, and signal routing, while task two packages the signals to be sent and transmits the CAN messages. However, this processing mode suffers from significant latency, especially when the CAN signals themselves have long cycles. The resulting routing delay increases dramatically, making it difficult to meet the growing demand for low-latency communication.

[0004] Therefore, as the requirements for network real-time performance continue to increase in functions such as intelligent driving and vehicle control, how to optimize the delay performance of signal routing paths while maintaining the integrity of system functions and the rationality of resource consumption has become an urgent technical problem to be solved. Summary of the Invention

[0005] In view of this, the embodiments of this disclosure aim to provide a CAN signal routing method and apparatus, and a vehicle for a controller area network, to solve the problem of excessive signal routing delay in CAN signal routing strategies.

[0006] In a first aspect, this disclosure provides a CAN signal routing method for a controller local area network (Controller Area Network), comprising: running a first task, wherein the first task includes performing a receiving action, an unpacking action, and a routing action to obtain a target CAN signal corresponding to a source CAN message when the source CAN message arrives; running a virtual task in parallel with the first task, wherein the virtual task includes verifying the source CAN message; and running a second task, wherein the second task includes packaging a target CAN message based on the target CAN signal obtained from the first task and sending the target CAN message, wherein the running period of the first task is a first cycle, the running period of the virtual task is a second cycle, and the first cycle is shorter than the second cycle.

[0007] In the method provided in the first aspect of this disclosure, by integrating the receiving, unpacking, and routing actions into a first task, when the source CAN message arrives, the target CAN signal corresponding to the source CAN message can be obtained through the first task. Simultaneously, the verification function of the source CAN message is processed in parallel in a virtual task with a second cycle, enabling the source message to be processed quickly in the first task to obtain the target CAN signal, and achieving complete verification in the virtual task. This process not only significantly reduces the signal latency of source CAN message reception, unpacking, and signal routing processing, improving the real-time performance of signal transmission, but also ensures the correctness of the verification operation, achieving optimal resource allocation with minimal architectural changes.

[0008] In conjunction with the first aspect, in some implementations, the above method also includes: the second period is N times the first period, where N is a positive integer greater than or equal to 1.

[0009] Based on the above implementation, the method provided in this disclosure limits the period of the virtual task (the second period) to an integer multiple N of the period of the first task, ensuring that each execution of the virtual task is strictly aligned with the execution rhythm of the first task in time. This allows the verification of the source message to always be performed based on a complete and definite processing cycle, fundamentally avoiding the problem of message data overwriting or inconsistent message states caused by the misalignment of message verification timing and reception timing due to the second period being a non-integer multiple of the first period. This reliably ensures the reliability and functional safety of communication.

[0010] In conjunction with the first aspect, in some implementations, the above method further includes: the arrival period of the source CAN message is equal to the second period, wherein a count is performed each time the first task is completed; when the count value reaches N, the first task and the virtual task are performed for the newly arrived source CAN message, and the count value is reset.

[0011] Based on the above implementation, the method provided in this disclosure introduces a counter function, causing the virtual task to trigger the verification of the source packet arriving in a new frame only when the counter accumulates to N. This ensures that the period of the virtual task is consistent with the theoretical packet period (i.e., the period when a new frame packet arrives), logically aligning the three key periods: the packet period, the signal processing period, and the verification period. Under the absolute premise of ensuring functional safety and correctness, this reduces signal routing latency.

[0012] In conjunction with the first aspect, in some implementations, the second task runs in a third cycle, which is configured independently of the first and second cycles.

[0013] Based on the above implementation, the method provided in this disclosure defines the third cycle as a cycle independent of the signal reception and verification process, ensuring that the sending behavior of the target CAN message is driven by the second task and is not affected by the previous task, avoiding instantaneous load peaks caused by irregular sending behavior, and ensuring the reliability of the network architecture.

[0014] In conjunction with the first aspect, some implementations also include: storing the CAN signal obtained after unpacking the source CAN message in the first task into a signal buffer. The virtual task further includes: after confirming that the source CAN message verification is successful, executing a transmission subtask in the second cycle. The transmission subtask includes reading the CAN signal from the signal buffer and transmitting the CAN signal to the application layer.

[0015] Based on the above implementation, in the method provided in this disclosure, the virtual task must execute the action of transmitting the signal in the signal buffer to the application layer only after confirming that the source CAN message has been successfully verified. This avoids invalid or erroneous data that has failed verification being transmitted to the application layer and misused. Furthermore, the period of CAN signal transmission to the application layer is always consistent with the second period, which functionally ensures the consistency of the signal period and the security and validity of the delivered data.

[0016] In conjunction with the first aspect, in some implementations, the above method also includes: the CAN signal obtained after unpacking the source CAN message in the first task is the current CAN signal, and the signal buffer also stores the historical CAN signal that was successfully verified last time. The virtual task also includes: after determining that the verification of the source CAN message has failed, the historical CAN signal is passed to the application layer.

[0017] Based on the above implementation, the method provided in this disclosure can prevent abnormal data from polluting the security backup by storing the historical CAN signal that was successfully verified in the signal buffer. It can also ensure that even if there are occasional communication or verification errors, the signal stream received by the application layer function will not be interrupted or will have illegal values. This allows a known and recent valid state to be maintained temporarily, preventing the function from stopping abruptly due to a single communication problem and enhancing the reliability of the signal routing system.

[0018] In conjunction with the first aspect, in some implementations, the application layer receives the CAN signal, where the receiving period of the application layer is equal to the second period.

[0019] Based on the above implementation, the method provided in this disclosure further ensures that the period during which the successfully verified CAN signal is transmitted to and received by the application layer is consistent with the message period, thus avoiding coordination problems that may be caused by the asynchronous arrival time of the application layer data update and the new frame message, and optimizing the functional consistency of the signal routing system.

[0020] Secondly, this disclosure provides a Controller Area Network (CAN) signal routing device, comprising: a first operating module for running a first task and a virtual task running in parallel with the first task, wherein the first task includes performing a receiving action, an unpacking action, and a routing action to obtain a target CAN signal corresponding to the source CAN message when the source CAN message arrives; the virtual task includes verifying the source CAN message; the operating cycle of the first task is a first cycle, and the operating cycle of the virtual task is a second cycle, wherein the first cycle is less than the second cycle; and a second operating module for running a second task, wherein the second task includes packaging a target CAN message based on the target CAN signal obtained from the first task and sending the target CAN message.

[0021] Thirdly, this disclosure provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the above-described method.

[0022] Fourthly, this disclosure provides a vehicle including a memory and a processor, the memory for storing a computer program, and the processor for calling and running the computer program from the memory, causing the vehicle to perform the steps of the above-described method. Attached Figure Description

[0023] To more clearly illustrate the technical solutions of the embodiments of this disclosure, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this disclosure. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0024] Figure 1 This is a schematic diagram of the structure of an in-vehicle network system provided in one embodiment of the present disclosure.

[0025] Figure 2 This is a flowchart illustrating a Controller Area Network (CAN) signal routing method provided in one embodiment of the present disclosure.

[0026] Figure 3 This is a flowchart illustrating a Controller Area Network (CAN) signal routing method provided in one embodiment of the present disclosure.

[0027] Figure 4 This is a schematic diagram of a Controller Area Network (CAN) signal routing device provided in one embodiment of the present disclosure.

[0028] Figure 5 This is a schematic diagram of the structure of a vehicle provided in one embodiment of the present disclosure. Detailed Implementation

[0029] To make the above-mentioned objectives, features, and advantages of this disclosure more apparent and understandable, the technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this disclosure, and not all embodiments. Based on the embodiments of this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.

[0030] Numerous specific details are set forth in the following description in order to provide a full understanding of this disclosure. However, this disclosure may also be implemented in other ways different from those described herein, and those skilled in the art can make similar extensions without departing from the spirit of this disclosure. Therefore, this disclosure is not limited to the specific embodiments disclosed below.

[0031] Secondly, the term "an embodiment" or "embodiment" as used herein refers to a specific feature, structure, or characteristic that may be included in at least one implementation of this disclosure. The phrase "in one embodiment" appearing in different places throughout this specification does not necessarily refer to the same embodiment, nor is it a single or selective embodiment that is mutually exclusive with other embodiments.

[0032] In the field of CAN communication, especially in gateways or domain controllers involving signal routing and forwarding, a software architecture based on fixed-cycle tasks is typically used to process CAN messages. A commonly recognized approach is to set up a Task 1 (hereinafter referred to as TASK1) to handle the reception, verification (such as E2E verification), unpacking, and signal routing of source CAN messages, and a Task 2 (hereinafter referred to as TASK2) to package and send target CAN messages. The two tasks run independently with their respective fixed cycles.

[0033] However, this method has certain limitations: Assuming the current source CAN message arrives precisely after the previous TASK1 has completed its receive and unpacking operations, TASK1 for the previous source CAN message is currently within its verification task cycle. Therefore, the current source CAN message cannot be processed by this TASK1 and must wait for almost the entire fixed cycle of TASK1 until the next TASK1 trigger. After the source CAN message is processed by TASK1, the acquired target CAN signal is passed to TASK2. If the previous task cycle of TASK2 is not complete, this target CAN signal must also wait for the previous TASK2 task cycle to complete, potentially waiting for almost the entire fixed cycle of TASK2. Therefore, the total routing delay from the arrival of the source CAN message on the CAN bus to its final packaging into the target CAN message and transmission will be the sum of the TASK1 and TASK2 cycles. In other words, for signals with large periods, such as signals with both source and destination message periods of 500ms, the routing delay may reach the second level, resulting in excessive latency that makes it difficult to meet the ever-increasing real-time requirements of vehicle networks.

[0034] In related technical solutions, to address the aforementioned problem of excessive signal routing delay, those skilled in the art typically employ a method of directly compressing the task cycle, such as reducing latency by simply compressing the TASK1 cycle. However, this approach can lead to verification errors due to a mismatch between the execution frequency of the verification operation and the arrival cycle of the new frame's message, while also causing a sharp increase in the CPU load. Specifically, if the TASK1 cycle (e.g., compressed to 10ms) is much shorter than the actual arrival cycle of the source CAN message in the new frame (e.g., 500ms), the E2E verification function will be incorrectly called multiple times or placed in an unexpected state within a single message cycle, resulting in verification failure. Simultaneously, the signal transmission cycle from TASK1 to the application layer (compressed to 10ms) becomes disconnected from the actual arrival cycle of the source CAN message in the new frame (500ms), causing the application layer to read outdated or repeatedly updated old signals, disrupting its normal logical timing and leading to functional abnormalities. Therefore, this scheme may cause the verification function task and the application layer signal receiving task to be frequently triggered. Even if there are no new messages for most of the cycle, task switching and empty check will occur, which will significantly increase CPU overhead, squeeze the computing resources of other key functions, and ultimately affect the overall stability and energy efficiency of the system.

[0035] Therefore, in traditional architectures, reducing signal routing latency by directly shortening task cycles inevitably faces two side effects: firstly, a significant increase in system CPU load, and secondly, disruption of the strict timing conditions upon which functions such as E2E verification depend. The root cause lies in the fact that the original design tightly coupled high-real-time-requirement signal flow operations (such as signal reception, unpacking, and routing processing) with periodically dependent verification operations (such as E2E verification) into the same task (e.g., task one) sequence, creating an irreconcilable timing conflict.

[0036] To address the aforementioned contradictions, this disclosure proposes a CAN signal routing method for controller area networks (CAN). Specifically, it implements a separate design for "signal routing processing" and "verification operation" of the source CAN message. The verification operation is separated from the delay-sensitive signal reception and main routing path, freeing it from serial dependency and making it asynchronous with the signal routing processing flow. This maintains the correct cycle and reliability of the verification function while enabling rapid signal flow, thereby significantly reducing signal routing latency while maintaining overall system load stability.

[0037] Figure 1 This is a schematic diagram of an in-vehicle network system provided in one embodiment of the present disclosure.

[0038] For example, such as Figure 1 As shown, the vehicle network system 100 includes: a transmitting ECU 110, a receiving ECU 120, and a CAN bus 130.

[0039] Generally, the transmitting ECU 110 typically refers to the electronic control unit in the vehicle network system that generates and transmits source CAN messages. This can include various electronic control units such as the Body Domain Controller (BDC / BCM), Powertrain Domain Controller (PDC), Autonomous Driving Domain Controller (ADC), Battery Management System (BMS), and sensor gateways. The receiving ECU 120 typically refers to the electronic control unit that can receive and process messages from the transmitting ECU 110, and can generate new target messages based on these messages and send them out. This can include various electronic control units such as the Cockpit Domain Controller (CDC), Chassis Domain Controller (FDC), Electronic Stability Program (ESP) controller, Gateway (GW), and Microcontroller Controller (MCU). The CAN bus 130 is typically used to connect the communication network of all ECUs, responsible for broadcasting and transmitting CAN messages. This can include powertrain CAN, body CAN, chassis CAN, and intelligent driving CAN, as well as a CAN bus used to interconnect multiple gateways to achieve cross-domain signal routing.

[0040] To achieve the above-described inventive concept, in the implementation of this disclosure, the aforementioned components of the vehicle network system 100 can be configured as follows: The transmitting ECU 110 generates and sends source CAN messages at a fixed period (e.g., 500ms). These source CAN messages contain key signals that need to be acquired and used by other ECUs, such as vehicle status, sensor data, or control commands. The receiving ECU 120 processes the received source CAN messages. Specifically, it runs a short-period (e.g., 10ms) receive processing task to quickly complete receiving, unpacking, and routing actions. When a source CAN message arrives, the first task retrieves the corresponding target CAN signal. Simultaneously, a longer-period (e.g., 500ms) virtual task is executed asynchronously, specifically responsible for verifying the received source CAN messages and delivering the signal to the application layer after successful verification. In this way, the receiving ECU 120 allows for the parallel execution of rapid signal flow and rigorous periodic verification. The CAN bus 130 serves as a communication medium between different ECUs, connecting network nodes such as the transmitting ECU 110 and the receiving ECU 120. Specifically, the CAN bus 130 is responsible for broadcasting and transmitting CAN messages generated by the ECUs between nodes, forming the basic channel for signal interaction in the vehicle network system.

[0041] The controller area network (CAN) signal routing method provided in this disclosure can be applied to the above. Figure 1 The provided in-vehicle network system mainly involves fine-tuning the in-vehicle network software architecture. By reconstructing the original message processing tasks in the receiving ECU, the delay in the signal traveling from the sending ECU to the receiving ECU and completing the routing process is shortened from waiting for the entire source message cycle to a fixed short task cycle. At the same time, the signal verification task can also be stably completed within the verification cycle. The entire process can significantly reduce the signal routing delay while ensuring normal function execution and without a significant increase in CPU resource consumption, thereby meeting the ever-increasing real-time requirements of in-vehicle networks.

[0042] Figure 2 This is a flowchart illustrating a Controller Area Network (CAN) signal routing method provided in one embodiment of the present disclosure.

[0043] For example, such as Figure 2 As shown, the method includes the following steps S210~S220: S210: Run the first task and run the virtual task in parallel with the first task.

[0044] The first task includes performing receiving, unpacking, and routing actions to obtain the target CAN signal corresponding to the source CAN message when it arrives. The virtual task includes verifying the source CAN message. The first task has a first cycle, and the virtual task has a second cycle, with the first cycle being shorter than the second cycle.

[0045] Specifically, the first task operates on a first cycle. Each time this task is scheduled, it performs receiving, unpacking, and routing actions. When raw source CAN message data arrives, the source CAN message can be read. Then, the source CAN message can be unpacked to extract one or more signal values. These signal values ​​are then routed to obtain the target CAN signal for subsequent processing. The virtual task operates on a second cycle. When its execution cycle is activated, it performs verification operations on the source CAN messages currently or recently received by the first task.

[0046] For example, a virtual task is logically a sub-process or processing branch defined within the first task, which can be triggered in parallel with the first task. The execution logic of the virtual task will not block or interfere with the completion of the main process of the first task (receiving action, unpacking action, and routing action).

[0047] Therefore, step S210 separates the time-consuming and periodically demanding verification operation into a virtual task and executes it in parallel with the first task, so as to separate it from the main path of signal reception, unpacking and routing processing that are sensitive to delay, thereby reducing the signal routing delay and improving the real-time performance of signal transmission.

[0048] S220: Run the second task.

[0049] The second task includes packaging the target CAN signal obtained from the first task into a target CAN message and sending the target CAN message.

[0050] Specifically, the second task performs the actions of packaging and transmitting the target CAN signals obtained from the first task. After performing receiving, unpacking, and routing actions on the arriving source CAN message signals, the first task classifies the CAN signals to be transmitted according to the requirements of the target message, generates the corresponding target CAN signals, and stores them in the transmit buffer or signal queue prepared for transmission. When the second task is triggered, it processes the multiple collected target CAN signals according to the requirements of their respective target CAN messages to package them into target CAN messages. Subsequently, the packaged target CAN messages can be sent to the CAN bus.

[0051] It should be noted that during the target message packaging process in the above embodiments, protective information (also known as "verification information") for downstream ECUs to verify may be included. For example, the E2E module in the gateway may be called to recalculate a CRC for the target message and the target counter. This CRC is a completely new CRC, different from the CRC of the source message. This is the core of achieving end-to-end data protection, ensuring that the integrity and authenticity of the signal can still be verified after crossing multiple ECUs and buses.

[0052] According to the Controller Area Network (CAN) signal routing method provided in this disclosure, the receiving action, unpacking action, and routing action are integrated into a first task, wherein the running cycle of the first task is a first cycle. Simultaneously, the source message verification function is processed in parallel in a virtual task, wherein the running cycle of the virtual task is a second cycle. This allows the source message to be processed quickly in the first task to obtain the target CAN signal when it arrives. Furthermore, the first cycle is shorter than the second cycle. This process, by setting the verification operation in the receiving ECU to be executed in a virtual task strictly synchronized with the source CAN message cycle, not only significantly reduces the signal latency of source CAN message reception, unpacking, and signal routing processing, improving the real-time performance of signal transmission, but also ensures the correctness of the verification operation, achieving optimal resource allocation with minimal architectural changes.

[0053] It should be noted that the verification performed by the virtual task refers to any step or algorithm that verifies the integrity, authenticity, or security of CAN messages or their carrying data. For example, this may include, but is not limited to: end-to-end (E2E) protection verification compliant with the AUTOSAR standard, verification based on cyclic redundancy check (CRC), or verification for specific security mechanisms.

[0054] The following explanation uses E2E verification performed by a virtual task as an example.

[0055] The core of E2E verification is to implement signal protection verification between the application layer of the transmitting electronic control unit (ECU) and the application layer of the receiving electronic control unit (ECU). This verification can be specifically designed for specific fault modes in the communication links between different ECUs. Specifically, the E2E verification operation can protect the authenticity of data, for example, ensuring that the signal received by the receiving ECU indeed comes from the expected and correct transmitting ECU; it can also protect the integrity of data, for example, ensuring that the signal value has not unexpectedly changed or flipped after traversing multiple modules and physical links such as the bus, gateway, driver layer, and communication stack; and it can also protect the correctness of data, for example, by verifying through serial numbers (e.g., counters) to prevent signal loss, duplication, out-of-order delivery, or severe delays, ensuring that the application layer of the receiving ECU processes valid data that arrives in the correct timing. In short, the above verification process is one of the core links in ensuring the correct functional coordination of signals across ECUs.

[0056] Furthermore, in the AUTOSAR architecture, the aforementioned E2E verification operation is not a static, on-demand check, but rather a dynamic process embedded in a continuous data stream. For example, each E2E verification operation typically corresponds to the arrival of a new round of periodic data. Specifically, each time an E2E verification operation is triggered, it is expected to process a new data unit that has just arrived from the communication link (e.g., a new frame of message data just received by the receiving ECU). Its internal logic (including its state maintenance, timeout judgment, and result validity marking) is executed based on the premise that "this verification operation processes the latest data." Therefore, the arrival cycle of a new frame of message needs to be consistent with the cycle that triggers the verification of the "new data unit." Thus, the cycle for triggering the aforementioned E2E verification needs to be consistent with the message cycle (i.e., the arrival cycle of a new frame of message). Additionally, in automotive functional safety systems, E2E verification is a safety mechanism, and its behavior should be deterministic and predictable. In other words, for each specified message frame, the trigger time of its verification operation, the data content processed, and the output verification result should all be clearly defined. Maintaining consistency between the verification cycle and the message cycle can be the basis for establishing this determinism. Conversely, if the verification operation is decoupled from the data stream or runs independently at high frequency, then the verification operation is unpredictable and may fail to meet the deterministic requirements of security analysis.

[0057] Based on this, in some embodiments of this disclosure, the second period is N times the first period, where N is a positive integer greater than or equal to 1.

[0058] Specifically, the core objective of the method in the above embodiments is to construct a deterministic and implementable timing framework between the first task and the virtual task, which can ensure that the execution rhythm of the virtual task can adapt to and match the fixed transmission period of the source CAN message, and remain consistent with the frequency of the period of running the first task, thereby satisfying the deterministic requirements of the E2E verification operation for the execution timing.

[0059] For example, if the message period is 500ms and the first period is 10ms, then N=50 can be set so that the virtual task is triggered to run at a 500ms period (the second period). This integer multiple constraint ensures that the triggering period of the virtual task can be strictly mathematically aligned with the message period that conforms to this integer multiple relationship through configuration, thereby ensuring that the verification rhythm is consistent with the rhythm of new data arrival in the architecture. Conversely, if the message period is 500ms, the first period is 10ms, and the second period is set to 505ms (not an integer multiple of the first period), then the triggering time of the virtual task relative to the starting point of the first task will drift after each period. This continuous drift will cause the correspondence between the triggering time of the virtual task and the expected arrival time of the new frame message to become unstable and unpredictable. In some periods, the virtual task may execute immediately after the arrival of the new frame message; while in other periods, it may execute long before or after the arrival of the new frame message. This uncertainty will seriously interfere with the normal operation of the E2E verification state machine and may lead to the loss of verification real-time performance and accuracy. Integer multiple relationships fundamentally eliminate this timing drift, ensuring the stability of the triggering time.

[0060] In some embodiments of this disclosure, the arrival period of the source CAN message is equal to the second period, wherein a count is performed each time the first task is completed; when the count value reaches N, the first task and the virtual task are performed for the newly arrived source CAN message, and the count value is reset.

[0061] Specifically, the above embodiment controls the triggering of the virtual task by employing a counting method in the first task: the count value in this counting method accumulates with each completion of the first task. When the count value reaches a preset integer N, a new source CAN message arrives, and the virtual task and the first task can be triggered simultaneously. At the same time, the count value is reset to allow for the simultaneous triggering of the virtual task and the first task in response to the newly arrived source CAN message. This method ensures that the virtual task is triggered strictly only once every N first task cycles, thus locking its execution rhythm to a fixed time interval that matches the expected arrival period of the newly arrived source CAN message.

[0062] It should be noted that the trigger condition "for newly arrived source CAN messages" explicitly states that the object of the virtual task verification is the latest message received by the first task within the second cycle window. This avoids the verifier processing expired data or repeatedly processing the same frame of data, ensuring that the context of each verification is correct and uniquely new data.

[0063] For example, assuming the source CAN message is vehicle speed signal data (i.e. speed message), the transmission period of the speed message at the sending end ECU is 500ms (i.e., the message period is 500ms), the first task execution period (first period) in the receiving end ECU is 10ms, and the integer multiple of the second period and the first period is N=50, based on the above assumptions, the specific routing process of the speed message is as follows.

[0064] First, the aforementioned speed message is triggered and executed for the first time. Specifically, upon system startup, the first task begins running with a 10ms cycle, its internal counter initially set to 0. When the first speed message arrives, the first task is triggered at its nearest scheduling point, immediately executing the reception, unpacking, and signal routing of the speed message. Simultaneously, a virtual task is also triggered to perform E2E verification on the speed message just received by the first task. Subsequently, counting and cycle management are performed. Specifically, each time the first task completes its execution within the first cycle (10ms) (regardless of whether a new message has been processed), the counter is incremented by 1. When this counter accumulates to the preset N=50, the virtual task should be triggered again to verify the newly arrived speed message. Since the speed message, i.e., the message period, is 500ms (50 times the first cycle), a new speed message should arrive precisely at this time, thus allowing the virtual task to be triggered normally when a new speed message arrives. If a slight phase drift occurs between the execution rhythm of a virtual task and the arrival point of a message due to minor delays in task scheduling, a period end judgment when the count value reaches N can be used to achieve forced synchronization. In other words, the counting-based scheme can adjust or ensure that the virtual task is triggered at the next expected time, thereby strictly locking its long-term average execution cycle to N × the first cycle, consistent with the message cycle T1, and preventing loss of synchronization.

[0065] It should be noted that in the above embodiments, the periodic execution of the first task is independent of whether it processes new CAN messages. The first task is triggered and run by the operating system at a fixed first cycle (10ms), which is a deterministic, time-triggered event. That is to say, even during periods when no new CAN messages arrive on the bus, the first task will still be triggered and executed periodically. In such execution operations, from a data processing perspective, since there is no new CAN message data, the first task (performing receiving, unpacking, and routing actions) can be considered to be idling.

[0066] Therefore, in the above embodiments, the main function of the first task's continuous periodic operation is to act as a stable counter, providing a reliable time measurement basis for the synchronization mechanism of the entire signal routing. This ensures that the triggering period of the virtual task is strictly and persistently consistent with the theoretical transmission period of the message, thereby strictly aligning the three key periods: the message period, the signal processing period, and the verification period. Under the absolute premise of ensuring functional safety and correctness, this achieves a reduction in signal routing latency.

[0067] Preferably, in some embodiments of this disclosure, the first period is 10ms.

[0068] In automotive electronic and electrical architecture, the message transmission periods for critical control signals and status signals (such as vehicle speed, engine speed, driving mode, door status, etc.) are typically 10ms, 20ms, 50ms, 100ms, 200ms, 500ms, etc. To ensure compatibility with different signal periods, the value of the first period should be a common divisor of these different signal period values. In this embodiment, 10ms is chosen as the first period, meaning it can be an integer fraction of the aforementioned common periods (i.e., 10ms is a common divisor of 10, 20, 50, 100, 200, and 500). This allows the verification period (second period) of the virtual task to be configured to be strictly aligned with any of the aforementioned signal periods by setting different integers N (e.g., N=1, 2, 5, 10, 20, 50), thereby achieving period adaptability and system versatility.

[0069] Furthermore, in the embodiments of this disclosure, 10ms is chosen as the first period. Compared to the longer signal waiting delays (e.g., 500ms) in related technologies, the 10ms period significantly reduces the delays in signal reception, unpacking, and signal routing when an active CAN message arrives. This can meet the significant real-time requirements for most cross-functional applications that require rapid signal interaction, such as mode switching, dynamic control response, and human-machine interaction feedback, and can also meet the performance requirements of most in-vehicle functions. However, the shorter the execution period of the first task, the more times the operating system switches tasks per unit time, and the fixed scheduling overhead will increase linearly. Even if the first task idles, its triggering and execution of the minimum checks and counting logic will still consume CPU time. For example, if the first period is shortened from 10ms to 5ms, it may mean that the execution frequency of the first task will double, and the CPU utilization will also nearly double, but the actual signal delay gain (from 10ms to 5ms) has a diminishing marginal effect on the overall system performance improvement. Specifically, reducing the first cycle from 10ms to 5ms only reduces latency by 5ms. While this improves signal routing latency, the improvement is virtually imperceptible to most in-vehicle functions (such as interface refresh, mode switching, and routine control), and it may not significantly improve the stability of the control algorithm. However, achieving this 5ms improvement requires nearly doubling the CPU resource consumption. Therefore, choosing 10ms as the first cycle is a preferable compromise, significantly improving signal routing latency while avoiding the resource waste and system instability risks associated with pursuing extremely low latency.

[0070] In some embodiments of this disclosure, the second task operates on a third cycle, which is configured independently of the first and second cycles. Specifically, setting the second task's operating cycle to a third cycle independent of the first and second cycles means that the signal transmission frequency is determined by the target packet's own requirements. This design decouples the fast signal reception verification action from the signal transmission action. The first and second cycles can focus on optimizing signal reception delay and ensuring verification correctness without considering the cascading impact on the signal transmission rhythm. The third cycle can be configured independently and flexibly according to the requirements of the network where the target packet resides and the needs of downstream functions, without being bound to the characteristics of the source packet. This allows the solution to flexibly adapt to signal routing requirements of different real-time levels.

[0071] For example, the Body Control Controller (BDC) sends a driving mode signal with a message period of 500ms. The central gateway can route this signal to the instrument cluster ECU, which displays the signal. The instrument cluster requires fast refresh and a smooth user experience, with a desired reception period of 100ms (i.e., the third cycle). First, the first task runs every 10ms. When the BDC sends a new frame of the driving mode message, the first task quickly receives, unpacks, and routes the message to obtain the target signal, such as "Sport," and writes it to the signal buffer. Simultaneously, the virtual task runs for 500ms, consistent with the message period. When the BDC sends a new frame of the driving mode message, the virtual task performs a verification operation on this message. Subsequently, since the third cycle is 100ms, the current target signal, such as "Sport," is read from the signal buffer every 100ms, packaged into a message, and sent. Within 500ms, five messages are sent. Except for the first message which corresponds to a new value, the latter four are stable repetitions of the same value, thus meeting the instrument cluster's requirement for smooth display.

[0072] The above embodiments ensure that the sending behavior of the target CAN message is driven by the second task and is not affected by the preceding task, thus avoiding instantaneous load peaks caused by irregular sending behavior and ensuring the reliability of the network architecture.

[0073] In some embodiments of this disclosure, the above-described controller area network CAN signal routing method may further include: storing the CAN signal obtained after unpacking the source CAN message in the first task into a signal buffer, wherein, after confirming that the source CAN message verification is successful, a transmission subtask is executed in the second cycle, wherein the transmission subtask includes reading the CAN signal from the signal buffer and transmitting the CAN signal to the application layer.

[0074] It should be noted that the signal buffer in the above embodiment is a shared data area located between the first task and the virtual task, and related operations are performed by the high-frequency running first task. Specifically, whenever the first task completes the reception and unpacking of a new source CAN message, the acquired new source CAN signal can be written into the signal buffer. Simultaneously, the virtual task performs a verification calculation based on the source CAN message in the first task during the second cycle. The verification result (success or failure) directly determines whether the corresponding source CAN signal value in the signal buffer can be transmitted to the application layer. When the source CAN message verification is successful, the virtual task can trigger the execution of a transmission subtask during the second cycle, thereby transmitting the unpacked source CAN signal value of the successfully verified source CAN message in the signal buffer to the application layer. At the same time, the application layer can actively initiate a read operation to the signal buffer or its interface during its own task cycle to read the unpacked source CAN signal of the successfully verified source CAN message in the signal buffer.

[0075] It should be noted that, based on the different verification results of the source CAN message, the unpacked signal values ​​in the signal buffer can be marked. For example, if the source CAN message verification is successful, the source CAN signal value in the signal buffer can be marked as "verified" or "valid," indicating successful verification; conversely, if the source CAN message verification fails, the source CAN signal value in the signal buffer can be marked as "unverified" or "invalid," indicating verification failure.

[0076] It should be noted that in the first task, after receiving and unpacking the source CAN message, the resulting source CAN signal can be divided into two independent branch paths that proceed simultaneously. Path one involves routing the source CAN signal into a target signal. Specifically, based on the routing table, it determines which target CAN message(s) the unpacked source CAN signal can be sent to, and preprocesses and maps it according to the signal layout format of the target message to generate the target CAN signal. Path two involves writing the unpacked source CAN signal into a signal buffer serving the virtual task, preparing for the subsequent transmission of the signal in the signal buffer to the application layer. Thus, in the above embodiment, the signal routing and buffering operations after unpacking in the first task are performed simultaneously and are independent of each other.

[0077] For example, if the source CAN message is an engine speed message, the source message period is 50ms, the first task period is 10ms, and the second virtual task period is 50ms (corresponding to N = 5), and the signal buffer is set as a storage unit for temporarily storing the speed value, then the routing process of this engine speed signal is as follows: First, a new frame of speed message arrives at the CAN bus with a value of 1200rpm. The first task executes the reception, unpacking (extracting the speed value 1200), signal routing (processing the speed message to generate the target signal), and buffering (writing the unpacked speed value 1200 into the signal buffer) of this speed message at its nearest 10ms period scheduling point, and the counting logic function of the first task begins to perform counting work. At the same time, the virtual task is also triggered to execute when a new frame of speed message arrives at the CAN bus (i.e., when the count value executed by the first task in the previous source message period reaches N = 5), and performs E2E verification on this new frame of speed message, such as verifying the counter, CRC, etc. If the verification is successful, the virtual task marks the signal with the speed value of 1200 as valid, and then this signal is passed from the signal buffer to the application layer in the second cycle; if the verification fails, the virtual task marks the signal with the speed value of 1200 as invalid, and does not perform the subsequent transmission action to the application layer.

[0078] In the above embodiments, the virtual task only executes the action of transmitting the signal in the signal buffer to the application layer after confirming the successful verification of the source CAN message. This avoids invalid or erroneous data that fails verification being transmitted to the application layer and misused. Furthermore, the period of CAN signal transmission to the application layer is always consistent with the second period, which functionally ensures the consistency of the signal period and the security and validity of the delivered data.

[0079] In some embodiments of this disclosure, the application layer receives CAN signals, and the reception period of the application layer is equal to the second period.

[0080] Specifically, the above embodiment keeps the source message period, the second period of the virtual task, and the period of the application layer's received signal consistent, and the execution frequency of the first task at the first period is also synchronized with the period of the application layer's received signal. This design prevents the application layer from reading "too early" (repeated within the same period) or "too late" signal values ​​due to the accelerated processing of the source CAN message by the first task, thereby avoiding algorithm logic errors, state machine erroneous jumps, or filter response characteristic distortions caused by this, fundamentally ensuring the correctness and stability of the upper-layer functions.

[0081] In some embodiments of this disclosure, the CAN signal obtained after unpacking the source CAN message in the first task is the current CAN signal, and the signal buffer also stores the historical CAN signals that were successfully verified last time. The virtual task also includes: after determining that the verification of the source CAN message has failed, passing the historical CAN signals to the application layer.

[0082] Specifically, the current CAN signal can refer to the signal that the first task unpacked from the latest arriving source CAN message and stored in the signal buffer, but which has not yet been verified and whose validity is unknown. The historical CAN signal can refer to the CAN signal stored in the signal buffer that was successfully verified by the virtual task in the previous second cycle, and which represents a known, valid security state. Based on the description of the above embodiments, when the virtual task performs verification on the current source CAN message and determines it to be successful, the current CAN signal can be marked as valid and allowed to be passed to the application layer according to the normal process. Simultaneously, the signal is saved and updated to a new "historical CAN signal." When the virtual task performs verification on the current source CAN message and determines it to be unsuccessful, the current CAN signal can be marked as invalid. The virtual task will not pass the unverified current CAN signal to the application layer, but instead reads the historical CAN signal from the signal buffer and passes it to the application layer as the valid output of the current cycle.

[0083] It should be noted that the marking action for the current CAN signal is performed in the virtual task. That is, in the second cycle corresponding to the virtual task, the validity of the signal is judged based on the internally configured logic module. The judgment result depends on the verification result of the source CAN message and is directly reflected in the update of the corresponding signal status in the signal buffer.

[0084] It's important to note that a historical signal buffer can be set up within the signal buffer area to store historical CAN signals, which will not be overwritten by current signal updates. This historical signal buffer is logically or physically isolated from the buffer area storing the current CAN signal. Specifically, when a virtual task successfully verifies and confirms the current source CAN message, it can copy or move the verified current CAN signal value to the historical signal buffer, overwriting any older content. This ensures that the historical signal buffer always contains the latest verified and valid signal value. Thus, when a virtual task determines that the current source CAN message has failed, the signal in the historical signal buffer can serve as a backup data source, transmitting this safe and valid signal to the application layer.

[0085] For example, if the source CAN message is an engine coolant temperature message with a period of 100ms, the verification process for different scenarios is as follows: First, before a new frame of temperature message arrives, the historical signal buffer stores the previously successfully verified value, such as a coolant temperature of 85℃. When a new frame of temperature message arrives, the first task receives the message, unpacks it, extracts the coolant temperature signal of 88℃, and writes this signal into the current signal buffer (overwriting the 85℃ signal value in that buffer). The historical buffer retains the 85℃ signal value. When the verification of the new frame of temperature message carrying the 88℃ coolant temperature is completed and confirmed successfully, the 88℃ signal value in the current signal buffer can be passed to the application layer. Simultaneously, the 88℃ signal value can be written into the historical signal buffer to overwrite the original 85℃ signal value. At this point, the historical signal buffer is updated with the latest temperature signal value. When the next new temperature frame arrives, the first task receives it, unpacks it, extracts the signal (water temperature 92℃), and writes this signal into the current signal buffer (overriding the signal value of 88℃ in that area). The signal value of 88℃ remains unchanged in the historical buffer. When the verification of the new temperature frame carrying the water temperature 92℃ fails, the signal value of 92℃ in the current signal buffer is deemed untrusted and will not be passed to the application layer. At this time, the virtual task reads the signal value of 88℃ from the historical signal buffer as the valid output of this cycle and passes it to the application layer, while the signal value of 88℃ remains in the historical signal buffer.

[0086] In some embodiments of this disclosure, when the source CAN message verification fails, the virtual task, in addition to transmitting historical security signals to the application layer, is typically triggered with an error reporting and handling mechanism. For example, a continuous verification failure counter can be set within the virtual task, incrementing with each verification failure. When the counter value exceeds a preset threshold (e.g., three consecutive failures), the system can determine it as a "persistent fault" rather than "intermittent interference," thereby triggering a higher-level fault response. Alternatively, an invalid signal flag can be set within the software, and a separate health monitoring task can periodically collect such flags, transmitting the ECU's communication health status message via the CAN bus to report its signal reception anomalies to the gateway or main controller.

[0087] Based on the above embodiments, the method provided in this disclosure stores the historical CAN signal that was successfully verified in the signal buffer area, which can prevent abnormal data from polluting the security backup. It can also ensure that even if there are occasional communication or verification errors, the signal stream received by the application layer function will not be interrupted or will have illegal values. It can maintain a known and recent valid state for a short time, prevent the function from stopping due to a single communication problem, and enhance the reliability of the signal routing system.

[0088] Figure 3 This is a flowchart illustrating a Controller Area Network (CAN) signal routing method according to one embodiment of this disclosure. Exemplarily, this method can be applied to... Figure 1 In the vehicular network system 100 shown, the implementation process of this method is as follows: Figure 3 As shown.

[0089] In this embodiment, the transmitting ECU 110 in the vehicle network system 100 includes an application layer, a CAN controller, and a CAN bus, used to send a new frame of source CAN message according to the source CAN message cycle; the receiving ECU 120 is used to perform three tasks, namely a first task, a virtual task, and a second task. The first task includes receiving, unpacking, and routing actions; when a source CAN message arrives, it passes through the first task to obtain the target CAN signal. The virtual task includes verifying the source CAN message, and the cycle of the virtual task is consistent with the cycle of the source CAN message. The second task includes packaging and sending the target CAN signal.

[0090] Specifically, such as Figure 3 As shown, the overall signal routing process of the source CAN message is as follows: First, the source CAN message is sent from the application layer to the CAN bus via the CAN controller in the transmitting ECU according to the source CAN message period. For example, if the source CAN message period is 500ms, then theoretically, a new source CAN message will be sent from the transmitting ECU to the CAN bus every 500ms.

[0091] Subsequently, after the receiving ECU receives a new source CAN message, the first task receives and unpacks the source CAN message within the first cycle (e.g., 10ms) to obtain the source CAN signal. Within the first cycle, it performs routing processing on the source CAN signal, converting it into a target CAN signal according to the routing table. This target signal can be placed in a buffer for transmission, to be used by the second task. Simultaneously, the unpacked source CAN signal is stored in the current signal buffer within the signal buffer area. The first task performs a count after each execution. Since the source CAN message cycle is 500ms, the first task idles when no new source CAN message arrives, incrementing the count by 1 after each first task cycle.

[0092] At the same time, after the receiving ECU receives a new frame of source CAN message, the virtual task is also triggered. In the second cycle (consistent with the message cycle, such as 500ms), the source CAN message is verified and it is determined whether the verification is successful.

[0093] When the first task execution count reaches N (N=50), it means that the first task has been executed 50 times and the virtual task has been executed once. The next frame of new CAN message will arrive again. At this time, the counter is reset, and the first task and the virtual task are triggered again to receive the new frame of source CAN message.

[0094] In the first task, the signal buffer stores the current CAN signal and historical CAN signals. When the source CAN message in the virtual task is valid, the current CAN signal in the signal buffer is passed to the application layer in the second cycle, and the current CAN signal is written to the historical signal buffer, overwriting the original historical CAN signal to become the new historical CAN signal. When the source CAN message in the virtual task is invalid, the virtual task reads the historical CAN signal from the historical signal buffer in the second cycle and passes it to the application layer, while the current CAN signal in the current signal buffer is discarded and not written to the historical signal buffer. Subsequently, the application layer receives the successfully verified CAN signal, and the application layer's receiving period is equal to the second cycle.

[0095] Finally, the second task runs independently and periodically in a third cycle. It retrieves the target CAN signal processed by the first task from the transmit buffer, packages the target CAN signal according to the target CAN message format, and generates a new protection field for the next ECU's verification process. The packaged target CAN message is then sent to the CAN bus via the CAN controller.

[0096] The above embodiments, by setting the verification operation in the receiving ECU to be executed in a virtual task that is strictly synchronized with the source CAN message period, not only significantly reduce the signal latency of source CAN message reception, unpacking, and signal routing processing, but also ensure the correctness of the verification operation, achieving optimal resource allocation with minimal architectural changes.

[0097] Figure 4 This is a schematic diagram of a Controller Area Network (CAN) signal routing device provided in one embodiment of the present disclosure.

[0098] Based on the same concept as the methods provided in the above embodiments, and referring to... Figure 4 This disclosure also provides a Controller Area Network (CAN) signal routing device. For example... Figure 4 As shown, the device 400 may include: a first operating module 410, used to run a first task and a virtual task running in parallel with the first task, wherein the first task includes performing receiving actions, unpacking actions, and routing actions to obtain the target CAN signal corresponding to the source CAN message when the source CAN message arrives, and the virtual task runs in parallel with the first task, wherein the virtual task includes verifying the source CAN message, and the running period of the first task is a first cycle, the running period of the virtual task is a second cycle, and the first cycle is less than the second cycle; a second operating module 420, used to run a second task, wherein the second task includes packaging the target CAN signal obtained from the first task to obtain a target CAN message and sending the target CAN message.

[0099] In the Controller Area Network (CAN) signal routing device provided in the above embodiments of this disclosure, the first task operates on a first cycle, integrating the receiving, unpacking, and routing actions within it. Simultaneously, the virtual task operates on a second cycle, processing the source message verification function in parallel within the virtual task. This allows the source message to be processed quickly in the first task to obtain the target CAN signal. This process not only significantly reduces the signal latency of source CAN message reception, unpacking, and signal routing processing, improving the real-time performance of signal transmission, but also ensures the correctness of the verification operation, achieving optimal resource allocation with minimal architectural modifications.

[0100] In some embodiments of this disclosure, in the first running module 410, the second cycle is N times the first cycle, where N is a positive integer greater than or equal to 1.

[0101] In some embodiments of this disclosure, the arrival period of the source CAN message in the first operation module 410 is equal to the second period. Specifically, the first operation module 410 further includes a counter module 411, which is used to count once each time the first task is completed; when the count value reaches N, the first task and the virtual task are executed for the newly arrived source CAN message, and the count value is reset.

[0102] Preferably, in some embodiments of this disclosure, the first cycle in the first running module 410 is 10ms.

[0103] In some embodiments of this disclosure, the running cycle of the second task in the second running module 420 is a third cycle, which is a cycle configured independently of the first cycle and the second cycle.

[0104] In some embodiments of this disclosure, the first running module 410 further includes a signal buffer module 412, used to store the CAN signal obtained after unpacking the source CAN message in the first task into a signal buffer area. After confirming that the source CAN message verification is successful, a transmission subtask is executed in the second cycle, wherein the transmission subtask includes reading the CAN signal from the signal buffer area and transmitting the CAN signal to the application layer.

[0105] In some embodiments of this disclosure, the CAN signal obtained after unpacking the first task execution source CAN message in the first running module 410 is the current CAN signal, and the signal buffer area of ​​the signal buffer module 412 also stores the historical CAN signals that were successfully verified last time. Wherein, after determining that the verification of the source CAN message has failed, the historical CAN signals are transmitted to the application layer.

[0106] In some embodiments of this disclosure, in the first operating module 410, the application layer receives CAN signals, wherein the receiving period of the application layer is equal to the second period.

[0107] It should be noted that the specific implementation methods and corresponding technical effects of the Controller Area Network (CAN) signal routing device provided in some embodiments of this disclosure can be referred to the description of the corresponding embodiments in the Controller Area Network (CAN) signal routing method proposed in this disclosure, and will not be repeated here.

[0108] Figure 5 This is a schematic diagram of the structure of a vehicle provided in one embodiment of the present disclosure.

[0109] Based on the same concept as the methods provided in the above embodiments, and referring to... Figure 5 This disclosure also provides a vehicle. For example... Figure 5 As shown, Figure 5The vehicle 500 shown includes a memory 510 and a processor 520. The memory 510 stores executable program code, and the processor 520 calls and executes the executable program code to perform a Controller Area Network (CAN) signal routing method.

[0110] The memory 510 may be a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM). The memory 510 may store a program, and when the program stored in the memory 510 is executed by the processor 520, the processor 520 performs the various steps of the method of the embodiments of this disclosure.

[0111] The processor 520 may be a general-purpose central processing unit (CPU), microprocessor, application specific integrated circuit (ASIC), graphics processing unit (GPU), or one or more integrated circuits, used to execute relevant programs to achieve the functions required by the modules in the apparatus of this disclosure embodiment.

[0112] The processor 520 can also be an integrated circuit chip with signal processing capabilities. In implementation, each step of the method disclosed herein can be completed by the integrated logic circuitry in the hardware of the processor 520 or by instructions in software form. The processor 520 described above can also be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this disclosure. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in the embodiments of this disclosure can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules can be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in the memory 510. The processor 520 reads the information in the memory 510 and, in conjunction with its hardware, performs the functions required by the units included in the apparatus of this disclosure embodiment, or performs the methods of the method embodiment of this disclosure.

[0113] It should be noted that, although Figure 5 The vehicle 500 shown only illustrates the memory and processor; however, those skilled in the art should understand that in specific implementations, the vehicle 500 may also include other devices necessary for normal operation. Furthermore, depending on specific needs, those skilled in the art should understand that the vehicle 500 may also include hardware devices for implementing other additional functions. Moreover, those skilled in the art should understand that the vehicle 500 may only include the devices necessary for implementing the embodiments of this disclosure, and may not necessarily include... Figure 5 All the devices shown.

[0114] Some embodiments of this disclosure can divide the vehicle into functional modules based on the above method examples. For example, functional modules can be divided according to each function, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware. It should be noted that the module division in this embodiment is illustrative and is only a logical functional division. In actual implementation, there may be other division methods.

[0115] When each functional module is divided according to its corresponding function, the vehicle may include: a determination module, a judgment module, and a control module, etc. It should be noted that all relevant content of each step involved in the above method embodiments can be referenced from the functional description of the corresponding functional module, and will not be repeated here.

[0116] The vehicle provided in this embodiment is used to execute the above-described Controller Area Network (CAN) signal routing method, and therefore can achieve the same effect as the above implementation.

[0117] In addition to the methods, apparatus, and vehicles described above, embodiments of this disclosure may also be computer program products comprising computer program instructions that, when executed by a processor, cause the processor to perform the steps of the methods provided in the various embodiments of this disclosure.

[0118] The computer program product can be written in any combination of one or more programming languages ​​to perform the operations of the embodiments of this disclosure. The programming languages ​​include object-oriented programming languages ​​such as Java and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on a user's computing device, partially on a user's computing device, as a standalone software package, partially on a user's computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0119] Furthermore, embodiments of this disclosure may also be computer-readable storage media storing computer program instructions thereon, which, when executed by a processor, cause the processor to perform the various steps of the methods provided in the various embodiments of this disclosure.

[0120] The computer-readable storage medium may be any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may, for example, include, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatuses, or devices, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: electrical connections having one or more wires, portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0121] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this disclosure.

[0122] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0123] In the several embodiments provided in this disclosure, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual couplings, direct couplings, or communication connections may be through some interfaces; indirect couplings or communication connections between apparatuses or units may be electrical, mechanical, or other forms.

[0124] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0125] In addition, the functional units in the various embodiments of this disclosure can be integrated into one unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0126] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this disclosure, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this disclosure. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory, random access memory, magnetic disks, or optical disks.

[0127] The above description is merely a specific embodiment of this disclosure, but the scope of protection of this disclosure is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this disclosure should be included within the scope of protection of this disclosure. Therefore, the scope of protection of this disclosure should be determined by the scope of the claims.

Claims

1. A method for routing CAN signals in a controller area network, comprising: Run the first task, which includes performing a receiving action, an unpacking action, and a routing action to obtain the target CAN signal corresponding to the source CAN message when the source CAN message arrives; A virtual task runs in parallel with the first task, wherein the virtual task includes verifying the source CAN message; and Run a second task, wherein the second task includes packaging the target CAN signal obtained from the first task into a target CAN message, and sending the target CAN message. The first task has a first cycle, and the virtual task has a second cycle, with the first cycle being shorter than the second cycle.

2. The method of claim 1, wherein, The second period is N times the first period, where N is a positive integer greater than or equal to 1.

3. The method of claim 2, wherein, The arrival period of the source CAN message is equal to the second period, wherein the method further includes: A count is performed each time the first task is completed; When the count value reaches N, the first task and the virtual task are executed for newly arrived source CAN messages, and the count value is reset.

4. The method of claim 1, wherein, The second task has a third cycle, which is configured independently of the first and second cycles.

5. The method of claim 1, wherein, Also includes: The CAN signal obtained after unpacking the source CAN message in the first task is stored in the signal buffer. The virtual task further includes: After confirming that the source CAN message has been successfully verified, a transmission subtask is executed within the second cycle. The transmission subtask includes reading the CAN signal from the signal buffer and transmitting the CAN signal to the application layer.

6. The method of claim 5, wherein, The CAN signal obtained after unpacking the source CAN message in the first task is the current CAN signal. The signal buffer also stores historical CAN signals that were successfully verified last time. The virtual task also includes: After determining that the verification of the source CAN message has failed, the historical CAN signal is transmitted to the application layer.

7. The method according to claim 5, characterized in that, Also includes: The application layer receives the CAN signal, wherein the receiving period of the application layer is equal to the second period.

8. A Controller Area Network (CAN) signal routing device, comprising: The first running module is used to run a first task and a virtual task running in parallel with the first task. The first task includes performing receiving actions, unpacking actions, and routing actions to obtain the target CAN signal corresponding to the source CAN message when the source CAN message arrives. The virtual task includes verifying the source CAN message. The running period of the first task is a first cycle, and the running period of the virtual task is a second cycle. The first cycle is shorter than the second cycle. The second operation module is used to run a second task, wherein the second task includes packaging the target CAN signal obtained from the first task into a target CAN message and sending the target CAN message.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method as described in any one of claims 1 to 7.

10. A vehicle, characterized in that, include: Memory, used to store computer programs; A processor for calling and running the computer program from the memory, causing the vehicle to perform the method as described in any one of claims 1 to 7.

Images