Bus route frame loss detection system, method and electronic device

Abstract

This application relates to the field of automotive electronic communication technology, and particularly to a bus routing frame loss detection system, method, and electronic device. The system includes a hardware layer, a bus driver layer, a bus interface layer, a device driver layer, and a software component layer. The hardware layer transmits data signals for bus routing. The bus driver layer transmits the event status of the data signals to the bus interface layer. The bus interface layer calls a first callback interface and a second callback interface to send the event status to the protocol data unit layer and the signal layer, respectively. The protocol data unit layer calls a first update function to update the frame loss counter table, and the signal layer calls a second update function to update the signal routing table. The device driver layer forwards the callback data from the bus interface layer to the software component layer. The software component layer generates the frame loss result for bus routing based on the signal routing table and the frame loss counter table. This solves the problems of insufficient granularity in frame loss detection and difficulty in detecting signal value errors in the routing path in related technologies.

Description

Technical Field

[0001] This application relates to the field of automotive electronic communication technology, and in particular to a bus routing frame loss detection system, method and electronic device. Background Technology

[0002] In automotive ECU (Electronic Control Unit) software development, the reliability of CAN bus communication is crucial. Frame loss detection in related technologies only performs message-level detection by counting the number of transmitted and received frames at the PDU (Protocol Data Unit) layer. This cannot detect anomalies in signal values ​​along the routing path. That is, when the PDU layer transmit and receive counts are normal, inconsistent signal values ​​can occur during PduR / Com / SWC routing due to configuration errors, parsing errors, or cache not being refreshed. This results in insufficient granularity of frame loss detection and the inability to detect hidden faults such as incorrect signals even when the message itself is not lost. Summary of the Invention

[0003] This application provides a bus routing frame loss detection system, method, and electronic device to solve the problems of insufficient frame loss detection granularity and difficulty in detecting signal value errors in the routing path in related technologies.

[0004] The first aspect of this application provides a bus routing frame loss detection system, comprising: a hardware layer, a bus driver layer, a bus interface layer, a device driver layer, and a software component layer. The hardware layer transmits data signals for bus routing; the bus driver layer transmits the event status of the data signals to the bus interface layer; the bus interface layer calls a first callback interface to send the event status to a protocol data unit layer and a second callback interface to send the event status to a signal layer; the protocol data unit layer calls a first update function to update a frame loss counter table; and the signal layer calls a second update function to update a signal routing table. The device driver layer forwards callback data from the bus interface layer to the software component layer; the software component layer maintains a signal routing table and a frame loss counter table, and generates frame loss results for bus routing based on the signal routing table and the frame loss counter table.

[0005] Optionally, the bus routing frame loss detection system also includes: a task layer, which periodically executes signal transmission tasks based on the scheduling entry point, and calls the interface function of the software component layer when activated by the scheduler to perform bus routing frame loss detection on the signal routing table and the frame loss count table.

[0006] Optionally, the bus routing frame loss detection system also includes: a log layer, used to record the frame loss results of bus routing, identify frame loss events in the frame loss results, and generate reporting events according to the type of frame loss events.

[0007] Optionally, the hardware layer is used to send data signals through the transmit path and receive data signals through the receive path.

[0008] Optionally, the data structure of the signal routing table includes a first field, a second field, a third field, and a fourth field. The first field is used to accumulate the number of times the data signal is processed by the software component layer after being decoded via the receiving path. The second field is used to accumulate the number of times the data signal is transmitted after being encoded via the transmitting path. The third field is used to store the original value of the data signal when it was last processed by the software component layer via the receiving path. The fourth field is used to store the original value of the data signal when it was last processed by the software component layer via the transmitting path.

[0009] Optionally, the first update function uses the identifier of the data signal as an index to perform a counting operation on the target field of the corresponding entry in the frame loss count table array on both the receiving and transmitting paths.

[0010] Optionally, after the frame loss count table is updated, the second update function synchronously performs a counting operation and a value snapshot update operation on the signal routing table on both the receiving and transmitting paths.

[0011] Optionally, the second update function includes a first processing function and a second processing function, wherein the first processing function performs a counting operation on the signal routing table synchronously on the receiving path and the sending path, and the second processing function performs a value snapshot update operation on the signal routing table synchronously on the receiving path and the sending path.

[0012] A second aspect of this application provides an electronic device, including: the bus routing frame loss detection system described in the above embodiments.

[0013] A third aspect of this application provides a bus routing frame loss detection method, which is applied to the bus routing frame loss detection system of the above embodiments. The method includes the following steps: transmitting bus routing data signals through the hardware layer; passing the event status of the data signals to the bus interface layer through the bus driver layer; sending the event status to the protocol data unit layer and the signal layer through the bus interface layer by calling a first callback interface; the protocol data unit layer calling a first update function to update the frame loss counter table; and the signal layer calling a second update function to update the signal routing table; forwarding the callback data of the bus interface layer to the software component layer through the device driver layer; and maintaining the signal routing table and the frame loss counter table through the software component layer, and generating the frame loss result of the bus routing based on the signal routing table and the frame loss counter table.

[0014] Therefore, this application has the following beneficial effects: This application embodiment constructs a layered architecture comprising a bus driver layer, a bus interface layer, and a device driver layer. By utilizing the bus interface layer to simultaneously call the first callback interface and the second callback interface, the protocol data unit layer updates the frame loss count table and the signal layer updates the signal routing table, respectively. The software component layer generates frame loss results based on the joint analysis of the two tables, achieving dual fine-grained monitoring of messages and signals. This not only accurately identifies message loss but also effectively detects hidden faults such as incorrect or outdated signal values ​​in the routing path. While solving the problem of insufficient detection granularity, the simplified routing path improves the system's real-time performance and fault location accuracy.

[0015] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description

[0016] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein: Figure 1 This is a block diagram of a bus routing frame loss detection system according to an embodiment of this application; Figure 2 This is a flowchart of a bus routing frame loss detection method according to an embodiment of this application; Detailed Implementation The embodiments of this application are described in detail below. Examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this application, and should not be construed as limiting this application.

[0017] The following description, with reference to the accompanying drawings, outlines a bus routing frame loss detection system, method, and electronic device according to embodiments of this application. Addressing the problems mentioned in the background section, this application provides a bus routing frame loss detection system. This method constructs a layered architecture comprising a bus driver layer, a bus interface layer, and a device driver layer. The bus interface layer simultaneously calls both a first callback interface and a second callback interface to drive the protocol data unit layer to update the frame loss count table and the signal layer to update the signal routing table, respectively. The software component layer then generates frame loss results based on joint analysis of the two tables. This achieves refined monitoring of both messages and signals, accurately identifying message loss and effectively detecting hidden faults such as incorrect or outdated signal values ​​in the routing path. While solving the problem of insufficient detection granularity, the simplified routing path improves the system's real-time performance and fault location accuracy.

[0018] Specifically, Figure 1 This is a block diagram of a bus routing frame loss detection system according to an embodiment of this application.

[0019] like Figure 1 As shown, the bus routing frame loss detection system includes: hardware layer 100, bus driver layer 200, bus interface layer 300, device driver layer 400, and software component layer 500.

[0020] The hardware layer 100 is used to transmit data signals for bus routing; the bus driver layer 200 is used to pass the event status of the data signals to the bus interface layer 300; the bus interface layer 300 is used to call the first callback interface to send the event status to the protocol data unit layer and the second callback interface to send the event status to the signal layer; the protocol data unit layer calls the first update function to update the frame loss count table; the signal layer calls the second update function to update the signal routing table; the device driver layer 400 forwards the callback data from the bus interface layer 300 to the software component layer 500; the software component layer 500 maintains the signal routing table and the frame loss count table, and generates the frame loss result of bus routing based on the signal routing table and the frame loss count table.

[0021] It is understandable that the bus routing frame loss detection system, in its architecture, includes, from bottom to top, a hardware layer 100 (CAN controller hardware), a bus driver layer 200 (CanDrv), a bus interface layer 300 (CanIf), a device driver layer 400 (CDD), and a software component layer 500 (SWC). These layers work together to achieve highly reliable communication monitoring. In the AUTOSAR standard architecture, the Protocol Data Unit (PDU) layer and the SWC layer typically have the Protocol Data Unit Routing Module (PDUR) handling the forwarding function. In this embodiment, CDD can replace PDUR, allowing CanIf callbacks to directly reach the SWC.

[0022] Specifically, the underlying hardware layer 100 includes CAN controller hardware (such as the NXP TJA1043, the MCMCAN module built into the Infineon AURIX TC3xx series MCU, etc.), which is responsible for completing the lowest-level communication actions such as physical layer signal transmission and reception, bit timing synchronization, bus arbitration, error frame detection and hardware-level automatic retransmission. It does not directly involve the frame loss detection logic in this application, but its transmission and reception results will be thrown to the upper interface layer through hardware interrupt.

[0023] In this embodiment, the hardware layer 100, as the physical foundation, is responsible for transmitting bus routing data signals; the bus driver layer 200 receives the underlying signals and transmits the event status to the bus interface layer 300; the bus interface layer 300, as a key routing distribution node, calls the first callback interface (CanIf_TxConfirmation) and the second callback interface (CanIf_RxIndication) respectively to synchronously distribute the event status to the protocol data unit layer and the signal layer, thereby triggering the protocol data unit layer (PDU layer) to execute the first update function to update the frame loss count table (CanFrame Count Table), and the signal layer to execute the second update function to update the signal routing table (Signal Route Table); the device driver layer 400 is responsible for transparently forwarding the callback data from the bus interface layer 300 to the software component layer 500; and the software component layer 500, as the detection core, maintains the signal routing table and the frame loss count table. By comprehensively comparing the real-time status in the routing table and the count table, it finally generates accurate bus routing frame loss results, thereby realizing end-to-end fault monitoring from physical transmission to the application layer.

[0024] In one embodiment of this application, after the frame loss count table is updated, the second update function synchronously performs a counting operation and a value snapshot update operation on the signal routing table on both the receiving path and the sending path.

[0025] Specifically, the first update function is invoked when the receive callback (RxIndication) or send confirmation callback (TxConfirmation) of the CanIf layer is triggered. Internally, the function locates the corresponding entry in the pre-allocated frame loss count table array using the passed PDU ID. If the path is to receive, the target field is locked to the first field (RxCount) and an atomic increment operation is performed; if the path is to send, the target field is locked to the second field (TxCount) and an atomic increment operation is performed. This operation involves only simple memory read / write operations, is extremely short-lived, and strictly guarantees real-time performance within the interrupt context.

[0026] In one embodiment of this application, the second update function includes a first processing function and a second processing function, wherein the first processing function synchronously performs a counting operation on the signal routing table on the receiving path and the sending path, and the second processing function synchronously performs a value snapshot update operation on the signal routing table on the receiving path and the sending path.

[0027] To improve code maintainability and execution efficiency, the second update function is split into a first processing function and a second processing function. The first processing function is specifically responsible for synchronously performing counting operations on the signal routing table on both the receive and transmit paths. This function only handles the increment logic of integer variables and does not involve complex data copying. The second processing function is specifically responsible for synchronously performing value snapshot update operations on the signal routing table on both the receive and transmit paths. This function internally contains memory copy or bit-by-bit extraction logic to safely transfer the signal values ​​parsed from the message to the LastRxValue or LastTxValue fields.

[0028] Therefore, the embodiments of this application decouple the counting logic from the value snapshot logic, so that when optimizing the code or adapting to different byte order parsing rules, only the second processing function needs to be modified, without affecting the counting stability of the first processing function.

[0029] In one embodiment of this application, the first update function uses the identifier of the data signal as an index to perform a counting operation on the target field of the corresponding entry in the frame loss count table array on both the receiving and transmitting paths. The first update function performs corresponding counting operations according to the different communication paths: the first update function includes the Rte_Swc_UpdateRxCount function for the receiving path and the Rte_Swc_UpdateTxCount function for the transmitting path. Specifically, the Rte_Swc_UpdateRxCount function is used to increment the receive count when a message is received, and the Rte_Swc_UpdateTxCount function is used to increment the transmit count when a transmission acknowledgment is received.

[0030] In one embodiment of this application, after the frame loss count table is updated, the second update function synchronously performs counting and value snapshot update operations on the signal routing table on both the receiving and transmitting paths. The second update function includes a first processing function and a second processing function. The first processing function synchronously performs counting operations on the signal routing table on both the receiving and transmitting paths, and the second processing function synchronously performs value snapshot update operations on the signal routing table on both the receiving and transmitting paths. The second update function performs corresponding counting and value snapshot update operations according to the different communication paths: on the receiving path, the second update function includes a receive counting processing function (Rte_Swc_ProcessSignalRx) and a receive value snapshot processing function (Rte_Swc_UpdateSignalSnapshot); on the transmitting path, the second update function includes a transmit counting processing function (Rte_Swc_ProcessSignalTx) and a transmit value snapshot processing function (Rte_Swc_UpdateSignalSnapshot).

[0031] In one embodiment of this application, the frame loss count table is declared as a C language structure array with a length of MAX_PDU_COUNT, corresponding to the maximum number of all CAN link layer protocol data units (LPDUs) involved in the communication of this electronic control unit (ECU). The subscript of this array corresponds one-to-one with the transmit identifier (CanTxPduId) or receive identifier (CanRxPduId) of each LPDU, thereby enabling the query and update of the corresponding table entries in the callback interface of the bus interface layer 300 (CanIf) with a time complexity of O(1).

[0032] In this embodiment, the data structure of the frame loss count table includes a first field and a second field, wherein, The first field can be the receive count field (RxCount), which is used to accumulate the number of packets that the corresponding LPDU has been notified of as successfully received through the receive indication interface (CanIf_RxIndication). The increment operation of this field occurs in the receive callback (User_RxIndication) of the device driver layer 400 (CDD), that is, whenever CanIf reports a packet frame, the update function (Rte_Swc_UpdateRxCount) increments it by 1; The second field can be a transmission count field (TxCount), used to accumulate the number of messages that the corresponding L-PDU has been notified of as successfully transmitted through the transmission confirmation interface (CanIf_TxConfirmation). The increment operation of this field occurs in the transmission confirmation callback (User_TxConfirmation) of the CDD layer, that is, whenever CanIf reports that a frame of messages has been successfully transmitted, the update function (Rte_Swc_UpdateTxCount) increments it by 1.

[0033] Furthermore, this application embodiment uses the uint32 type to define the above fields, ensuring counting reliability under long-term operation. At a typical CAN communication rate of 1 Mbps, even if the ECU continues to operate at full load, a 32-bit unsigned integer is sufficient to cover a continuous cumulative duration of up to tens of days without overflow.

[0034] In actual implementation, this embodiment continuously records and compares the receive count and transmit count of the same L-PDU. The count table can effectively identify various message-level faults, including: transmission failures due to bus errors, bit stuffing errors, or missing acknowledgments (ACKs); message loss due to receive buffer overflow or interrupt loss; and unbalanced receive and transmit counts due to CAN controller hardware malfunctions. Furthermore, the count table provides fundamental data support for frame loss determination at the PDU layer in the subsequent detection function (Swc_CheckFrameLoss), and is the core data structure of the first layer (PDU layer) in the two-layer detection mechanism of this embodiment. In one embodiment of this application, the data structure of the signal routing table includes a first field, a second field, a third field, and a fourth field. The first field is used to accumulate the number of times the data signal is processed by the software component layer 500 after being decoded via the receiving path. The second field is used to accumulate the number of times the data signal is transmitted after being encoded via the sending path. The third field is used to store the original value of the data signal when it was last processed by the software component layer 500 via the receiving path. The fourth field is used to store the original value of the data signal when it was last processed by the software component layer 500 via the sending path.

[0035] In this embodiment, the Signal RouteTable constructed in the Signal Layer is declared as a C language structure array with a length of MAX_SIGNAL_COUNT, corresponding to the maximum number of application layer signals involved in the communication of this Electronic Control Unit (ECU). The subscript of this array corresponds one-to-one with the identifier (SignalId) of each signal, thereby enabling the query and update of the corresponding table entries in the callback interface of the Software Component Layer 500 (SWC) with a time complexity of O(1).

[0036] Unlike the CanFrame Count Table at the PDU layer, which only records message-level counts, the SignalRoute Table introduces four key fields in each entry to enable finer-grained signal-level monitoring and numerical consistency verification.

[0037] Specifically, the first field is the signal reception count (RxCount), which is used to accumulate and record the number of times the corresponding signal has been processed by SWC after being decoded through the reception path. The increment operation of this field occurs in the reception callback (User_RxIndication) of the Complex Device Driver Layer 400 (CDD), that is, the processing function (Rte_Swc_ProcessSignalRx) increments it by 1 after the signal is successfully extracted, reflecting the execution status of the signal at the receiving end on the signal routing path; The second field is the signal transmission count (TxCount), which is used to accumulate and record the number of times the corresponding signal has been transmitted after being encoded through the transmission path. The increment operation of this field occurs in the transmission confirmation callback (User_TxConfirmation) of the CDD layer, that is, the processing function (Rte_Swc_ProcessSignalTx) increments it by 1 after the signal is successfully packaged, reflecting the execution status of the signal at the sending end on the signal routing path; The third field is the most recently received signal value (LastRxValue), which stores the original value of the signal when it was last processed by SWC through the receiving path. This field is written synchronously by Rte_Swc_ProcessSignalRx while updating RxCount, realizing the ability to capture the "most recent snapshot" of the signal value at the receiving end; The fourth field is the most recently transmitted signal value (LastTxValue), which stores the original value of the signal when it was last transmitted via the transmission path. This field is written synchronously by Rte_Swc_ProcessSignalTx while updating TxCount, realizing the ability to capture the "most recent snapshot" of the signal value at the transmitting end.

[0038] It should be noted that the `Rte_Swc_ProcessSignalRx` function is called within the `User_RxIndication` callback in the CDD layer, and is the entry processing function for the signal layer receive path. This function accepts two parameters: `SignalId` represents the identifier of the signal currently being processed; `SignalValue` represents the current value of the signal obtained from the received message after decoding by the COM layer. The function body performs two atomic operations: (a) Increment the SignalRouteTable[SignalId].RxCount field by 1 to record the cumulative number of times the signal has been received; (b) Update the SignalRouteTable[SignalId].LastRxValue field to the SignalValue passed in this time, recording the value of the signal when it was last received. Since this function is designed to be called at the end of the CanIf_RxIndication callback chain, its execution context is usually located in the interrupt service routine or its directly derived callbacks. Therefore, the execution time of the function body must be strictly controlled. This function does not perform any conditional checks, loop iterations, or log reporting operations.

[0039] (2) Rte_Swc_ProcessSignalTx: This function is called in the User_TxConfirmation callback of the CDD layer and is the entry processing function for the signal layer sending path. The function parameters are the same as Rte_Swc_ProcessSignalRx, representing the signal identifier and the signal value of this successful transmission, respectively. The function body also performs two atomic operations: (a) Increment the SignalRouteTable[SignalId].TxCount field by 1 to record the cumulative number of times the signal has been successfully sent; (b) Update the SignalRouteTable[SignalId].LastTxValue field to the SignalValue passed in this time to record the value when the signal was last sent.

[0040] Therefore, in this embodiment, Rte_Swc_ProcessSignalRx and Rte_Swc_ProcessSignalTx synchronously update the count and latest value of the corresponding entries in the Signal Route Table each time a signal is processed, thereby providing a reliable detection data foundation for the subsequent Swc_CheckFrameLoss function. The design of these two functions fully embodies the engineering concept of "separation of data acquisition and fault determination" in this application: the interrupt callback only undertakes lightweight data acquisition and status recording responsibilities, without performing any time-consuming determination or log reporting; the time-consuming frame loss determination, error flag setting, and DLT log output are uniformly postponed to the OS cycle task. This design avoids injecting too much execution time into the CanIf callback chain (ensuring real-time communication) and also ensures the integrity, determinism, and observability of the detection.

[0041] Therefore, this application embodiment not only utilizes RxCount and TxCount to detect signal-level counting anomalies (similar to the PDU layer mechanism), but also achieves signal value consistency detection through the comparison of LastRxValue and LastTxValue. Even if the PDU layer's CanFrame Count Table shows that the transmit and receive counts are consistent (i.e., the message is not lost), due to the long signal routing path between PduR, Com, and SWC in the AUTOSAR architecture, signal value errors may still occur in the following scenarios: (1) PduR routes the signal to the wrong destination due to configuration errors during multi-path signal routing; (2) Com layer causes the signal value to be misinterpreted due to bit offset, byte order, or length configuration errors during signal packing / unpacking; (3) SWC fails to read the old value or write the new value in the Rte_Read / Rte_Write interface call because the cache is not refreshed in time. The Signal Route Table can effectively expose the above-mentioned hidden faults by recording and comparing the most recent transmit and receive values.

[0042] In one embodiment of this application, the bus routing frame loss detection system further includes: a task layer, which is used to periodically execute signal transmission tasks based on the scheduling entry point, and when activated by the scheduler, calls the interface function of the software component layer to perform bus routing frame loss detection on the signal routing table and the frame loss count table.

[0043] Specifically, in this embodiment, a periodic operating system (OS) task (e.g., named FrameLossCheck_10ms) is configured in the task layer. This task serves as the scheduling entry point for the detection logic in this embodiment. When this task is activated by the OS scheduler according to a set time period (e.g., 10ms), the task layer automatically calls a pre-registered interface function (e.g., Swc_CheckFrameLoss function) in the software component layer (SWC). After being called, the interface function performs a complete two-layer frame loss detection on the pre-maintained signal routing table and frame loss count table in the current task context. The specific detection logic includes: Message-level detection: Traverse the frame loss count table, compare the receive count (RxCount) and transmit count (TxCount) of each PDU. If the receive count is greater than the transmit count, it is determined that a message-level frame loss has occurred and the number of lost frames is calculated. Then, a log containing the PDU ID and the number of lost frames is reported as a CAN message frame loss (CFL) event through the DLT interface, and the receive count is reset to the transmit count. This ensures that the detection in the next cycle is only for newly occurring frame losses, effectively avoiding log storms caused by the same fault being repeatedly reported.

[0044] Signal-level detection: After the PDU layer detection is completed, the signal layer detection in this embodiment performs two sub-detections for each signal by traversing the signal routing table: count consistency detection and value consistency detection. In count consistency detection, the received count and the transmitted count of the signal are compared. If the received count is greater than the transmitted count, it is determined that the routing count is abnormal. In value consistency detection, the most recent received value (LastRxValue) and the most recent transmitted value (LastTxValue) of the signal are compared. If the two are not equal, it is determined that the signal value is abnormal. When any sub-detection finds an abnormality, the abnormality is reported through the DLT interface as a CAN signal routing frame loss (CSL) event, thereby realizing the accurate identification of hidden faults where the message count is normal but the signal content is wrong.

[0045] Therefore, the embodiments of this application adopt a two-level detection architecture from coarse to fine. First, coarse-grained detection at the PDU layer is performed to quickly locate message-level faults, and then fine-grained detection at the signal layer is performed to identify hidden faults that are normal in count but abnormal in routing. This sequential design takes into account both detection efficiency and detection depth, and effectively achieves comprehensive coverage of explicit frame loss and hidden routing anomalies.

[0046] It should be noted that in the dual-layer detection mechanism of this application, the PDU layer detection and the signal layer detection have different design in terms of counting management strategies. After completing log reporting, the PDU layer detection resets the receive count (RxCount) to the transmit count (TxCount) to prevent the same frame loss event from being repeatedly reported in subsequent cycles; while the signal layer detection does not reset the count. The reason for this is that the value consistency detection of the signal layer relies on the LastRxValue and LastTxValue samples accumulated over multiple scheduling cycles. Retaining the accumulated count ensures that the system obtains sufficient data samples, thereby effectively avoiding misjudgment as routing anomalies when the signal is in the initial transmission stage and a stable baseline value has not yet been established.

[0047] Through the above implementation, the detection function (Swc_CheckFrameLoss) provided in this application can simultaneously cover three types of faults within a unified scheduling period: message-level frame loss, signal-level count anomaly, and signal-level value anomaly, enabling the dual-layer detection mechanism of this application to be executed efficiently and completely in a closed loop.

[0048] In one embodiment of this application, after the OS periodic task is activated at each preset scheduling period (e.g., 10ms), it executes a complete two-layer frame loss detection process. This process is strictly divided into three stages in chronological order: PDU layer detection, signal layer detection, and task termination. The specific execution logic is as follows: I. PDU Layer Detection Phase After the task starts, it first enters the detection loop of the PDU layer. The detection function iterates through each PDU identifier (PDU_ID) in the CanFrame Count Table and compares its receive count (RxCount) with its transmit count (TxCount): If the RxCount of a certain PDU_ID is determined to be greater than the TxCount, then it is confirmed that there is a message-level frame loss in that link layer protocol data unit (L-PDU), and the following three actions will be performed in sequence: Set the error flag (ErrorFlag) of this entry to TRUE to indicate that the PDU has detected an abnormal state in this period; report the packet loss log through the log sending interface (Dlt_SendLogMessage) with the application identifier AppID = CFL (CANFrame Loss); reset the RxCount of this entry to TxCount to avoid the same frame loss event being repeatedly reported in subsequent periods due to the continuously large count, effectively preventing log storms.

[0049] If RxCount is determined to be less than or equal to TxCount, the above actions are not performed, and the process proceeds directly to the determination of the next PDU_ID. After all MAX_PDU_COUNT PDU_IDs have been traversed, the PDU layer detection phase ends, and the process automatically transitions to the signal layer detection phase.

[0050] II. Signal Layer Detection Stage Iterate through each signal identifier (SIG_ID) in the SignalRouteTable and perform two sub-detections for each signal in sequence: Sub-detection 1 (Count Consistency Detection): Compare the signal's RxCount with TxCount. If Signal.RxCount is greater than Signal.TxCount, it is determined that the signal has a count anomaly during routing. The ErrorFlag of this entry is set to TRUE, and a "signal count anomaly" log is reported through the log sending interface with AppID = CSL (CAN Signal Loss) and ContextID = STD. If Signal.RxCount is less than or equal to Signal.TxCount, no action is taken, and the process proceeds directly to Sub-detection 2.

[0051] Sub-detection 2 (Value Consistency Detection): Compare the most recently received value (LastRxValue) of the signal with the most recently sent value (LastTxValue). If the two are not equal, it is determined that the signal has an abnormal value during the routing process, the ErrorFlag of the entry is set to TRUE, and a "signal value inconsistency" log is reported through the log sending interface with AppID = CSL and ContextID = STD; if the two are equal, no action is taken, and the process continues to the next SIG_ID determination.

[0052] III. Mission Termination Phase Once all MAX_SIGNAL_COUNT SIG_IDs have been traversed, the signal layer detection phase ends. At this point, the AUTOSAR OS standard interface (TerminateTask()) is called to terminate the current task instance, switching the task from running to suspended state, waiting for the operating system to reactivate it when the next 10ms cycle arrives.

[0053] Through the above process, this embodiment clearly presents the "coarse-to-fine" execution logic of the two-layer detection: message-level faults are quickly identified through PDU layer detection, and hidden faults such as normal message counts but abnormal signal values ​​are further exposed through signal layer detection; at the same time, the judgment results of the two layers of detection are reported through the CFL and CSL channels of DLT respectively, realizing accurate classification and rapid location of fault types.

[0054] In one embodiment of this application, the OS periodic task serves as the scheduling entry point and execution carrier for the entire two-layer frame loss detection mechanism. In the AUTOSAR architecture, the FrameLossCheck_10ms task defined in this embodiment is configured as a periodic task, uniformly managed by the operating system scheduler, and activated at a fixed interval of 10ms, thereby switching from the ready state to the running state.

[0055] The choice of a 10ms period is based on the following engineering considerations: First, the typical CAN message period is mostly 10ms to 100ms, and a 10ms detection period can ensure that frame loss events under the most common message period are detected at least once; Second, this period will not significantly occupy the ECU's CPU resources under normal communication load, and the detection overhead is controllable; Third, this period is consistent with other typical periodic tasks in the vehicle ECU (such as the 10ms control loop), which facilitates unified scheduling.

[0056] During operation, the main execution logic of this task consists of only two core steps: First, the core detection function of this invention (Swc_CheckFrameLoss) is called to perform a complete PDU layer and signal layer double-layer frame loss determination; then, the execution of this task instance is terminated through the AUTOSAR OS standard interface (TerminateTask()), so that the task is switched from the running state to the suspended state, waiting for the operating system to reactivate it when the next 10ms cycle arrives.

[0057] Using an OS-based periodic task mechanism to drive frame drop detection has the following significant advantages compared to related technologies that trigger detection sporadically in event callback functions: Determinism and predictability: The detection cycle is strictly guaranteed by the operating system and will not drift due to the unstable frequency of underlying callbacks; at the same time, the detection time is relatively stable, which makes it easy to evaluate its impact on the worst execution time of other high-priority tasks during the system design phase.

[0058] Decoupling: The detection logic is completely decoupled from the underlying communication events, avoiding time-consuming log reporting and traversal operations in the interrupt context or CanIf callback, which complies with AUTOSAR's strict constraints on the execution time of interrupt service routines and callback functions.

[0059] Observability: By centralizing detection behavior into a single cycle task, developers can more easily observe the execution frequency, time, and results of the task through debuggers, trace tools, or DLT logs, thereby improving the efficiency of problem localization.

[0060] By working together with the FrameLossCheck_10ms periodic task and the Swc_CheckFrameLoss detection function, this invention achieves a complete technical solution of "unified detection of PDU layer and signal layer within a deterministic period, and reporting according to frame loss type".

[0061] In one embodiment of this application, in order to improve the efficiency of fault location, the bus routing frame loss detection system further includes: a log layer, used to record the frame loss results of bus routing, identify frame loss events in the frame loss results, and generate reporting events according to the type of frame loss events.

[0062] Specifically, the logging layer categorizes frame loss events into two main types based on their occurrence level and assigns them independent application identifiers (AppIDs): CFL (CAN Frame Loss): When the Swc_CheckFrameLoss function detects that the RxCount of an L-PDU is greater than the TxCount during PDU layer detection, it determines that the L-PDU has experienced a message-level frame loss and triggers this type of log reporting. AppID = CFL (CAN Frame Loss) is used to identify that the log originates from the message-level frame loss detection mechanism of this invention; ContextID = STD (Standard) indicates that this is a standardized regular log event. Logs reported through the CFL channel should at least contain two key fields: PDU ID and the number of lost frames, to facilitate fault location and statistics by upper-layer diagnostic tools.

[0063] CSL (CAN Signal Loss): When the Swc_CheckFrameLoss function detects an anomaly in the signal layer detection (RxCount > TxCount) or an anomaly in the value (LastRxValue ≠ LastTxValue), it determines that the signal has experienced frame loss or errors during routing, triggering this type of log report. AppID = CSL (CAN Signal Loss) identifies that the log originates from the signal-level frame loss detection mechanism of this invention; ContextID = STD indicates that this is a standardized regular log event. Logs reported through the CSL channel should at least include three key fields: SignalId, anomaly type (anomaly in count / anomaly in value), and anomaly value.

[0064] Therefore, this embodiment of the application classifies and reports frame loss events according to the PDU layer and the signal layer, enabling upper-layer diagnostic tools to quickly determine the root cause level of the fault based on the AppID field. When the diagnostic tool only sees the CFL log, it can initially determine that the problem may be in the bus physical layer, CAN controller hardware, or interrupt handling; when the diagnostic tool only sees the CSL log, it can initially determine that the problem may be in the routing configuration between the PDUR, COM layer, or SWC; when both CFL and CSL logs appear, it can be inferred that the bus frame loss has been propagated to the signal layer, and the underlying message frame loss problem should be addressed first. Compared with the existing "unclassified unified reporting" scheme, this "reporting by type" classification scheme can significantly improve fault location efficiency and reduce on-site debugging costs.

[0065] In one embodiment of this application, when the Device Driver Layer 400 (CDD) replaces the Standard Protocol Data Unit Router (PDUR), key parameters must be configured in the Bus Interface Layer 300 (CanIf) module. The difference between the scheme of this embodiment and the standard PDUR scheme in the behavior of the CanIf interface is entirely achieved through these four configuration parameters. After configuration, the CanIf send acknowledgment and receive indication callbacks will be directly routed to the CDD layer described in this invention, without being forwarded by the PDUR module. The specific configuration is as follows: The upper-level module configuration for sending confirmation callbacks indicates that when CanIf is called, it will directly route the send confirmation event to the CDD layer; The configuration of the send confirmation callback target function specifies the name of the target function in the upper-layer module that actually receives the CanIf_TxConfirmation callback. In this application, the function is named User_TxConfirmation, which is the send confirmation callback entry point provided by the CDD layer. The specific implementation of this function is located inside the CDD layer. After receiving the CanTxPduId parameter, it calls Rte_Swc_UpdateTxCount and Rte_Swc_ProcessSignalTx to complete the data update between the PDU layer and the signal layer.

[0066] The receive indication callback is configured in the upper-level module, indicating that when CanIf is called, the receive indication event will be directly routed to the CDD layer.

[0067] The configuration for the target function to receive the CanIf_RxIndication callback specifies the name of the target function in the upper-layer module that actually receives the CanIf_RxIndication callback. In the standard PDUR scheme, this function is named PduR_RxIndication; in this invention, it is named User_RxIndication, which is the entry point for the receive indication callback provided by the CDD layer. The specific implementation of this function is located inside the CDD layer. After receiving the Mailbox and PduInfo parameters, it sequentially calls Rte_Swc_UpdateRxCount and Rte_Swc_ProcessSignalRx to complete the data update between the PDU layer and the signal layer.

[0068] Therefore, the embodiments of this application can achieve the architectural adjustment of replacing PDUR with CDD simply by changing the configuration. This pure configuration change implementation method has strong engineering scalability, can be reused under different vendors' AUTOSAR architectures, and will not bring additional code review burden to functional safety certification.

[0069] In some embodiments, by strictly adhering to the 11 interface requirements for CanIf_TxConfirmation and CanIf_RxIndication in the AUTOSAR specification, compliance checks were performed in parameter verification, state update, and initialization checks. This ensures that the proposed solution achieves dual optimization of architecture and performance while remaining compatible with the AUTOSAR standard basic software environment. On the one hand, by replacing the upper-layer callback receiver with a standard PDUR and a CDD, a simplified communication route directly to the SWC is constructed, effectively reducing system overhead. On the other hand, the dual-layer frame loss detection mechanism and diagnostic classification reporting capability are fully retained, thereby significantly improving the real-time performance and fault location accuracy of vehicle communication monitoring while ensuring system compliance.

[0070] In one embodiment of this application, the hardware layer 100 is used to transmit data signals via a transmit path and receive data signals via a receive path.

[0071] The CAN message transmission path is a complete execution link from hardware transmission completion to PDU layer and signal layer counter table update. This path is activated when the CAN controller hardware successfully completes the bus transmission of an L-PDU frame (including successful bus arbitration, ACK response received, and error detection passed) and triggers a transmission completion interrupt. Specifically, it includes the following steps: Step 11: CAN Transmission Interrupt Triggered. After the CAN controller hardware completes the transmission of one L-PDU frame, it triggers a transmission completion interrupt. The interrupt vector entry points to the interrupt handler function Can_17_McmCan_1TxEventProcessingHandler of the Can_17_McmCan driver used in this embodiment. This interrupt handler reads the hardware event status register, identifies which mailbox's message has been successfully transmitted, and converts the mailbox's ID to the standard CanTxPduId before using it as a parameter to send a notification to the upper layer.

[0072] Step 12: CanIf_TxConfirmation call. CanDrv calls the AUTOSAR standard interface CanIf_TxConfirmationService (ID 0x13, synchronous, reentrant) in the interrupt context to pass the confirmation event up to the CanIf layer.

[0073] Step 13: In a multi-core ECU scenario (the Infineon AURIX TC3xx platform on which this application embodiment is based is a typical multi-core architecture), CanIf_TxConfirmation will further call the local core's CanIf_XCore_LocalCore_TxConfirmation function to complete the localization processing of multi-core routing, ensuring that the sending confirmation event is only processed by the local core corresponding to the core to which the LPDU configuration belongs.

[0074] Step 14: After multi-core localization processing, CanIf routes the confirmation event to the CDD layer described in this invention through the callback function (i.e., UserTxConfirmation) specified in the configuration item. This step is the key routing point on the sending path of "replacing PDUR with CDD" in this application embodiment: in this application embodiment, it is directly routed to User_TxConfirmation in the CDD layer.

[0075] Step 15: PDU Layer Count Update (Rte_Swc_UpdateTxCount). The Rte_Swc_UpdateTxCount(CanTxPduId) function is called in the User_TxConfirmation callback of the CDD layer. This function increments the TxCount field of the corresponding entry in the CanFrame Count Table array by 1 (CanFrameCountTable[id].TxCount++), using CanTxPduId as the index, and records the successful transmission event of this message in the PDU layer count table.

[0076] Step 16: Signal Layer Count and Value Snapshot Update (Rte_Swc_ProcessSignalTx). After completing the PDU layer count update, the Rte_Swc_ProcessSignalTx(SignalId, SignalValue) function is further called to synchronously perform two atomic operations on the corresponding signal table entry in the Signal Route Table: (a) SignalRouteTable[id].TxCount++, recording the cumulative number of times the signal has been successfully sent; (b) SignalRouteTable[id].LastTxValue = SignalValue, recording the value of the signal when it was last successfully sent. These two operations are completed in the same function call, ensuring that LastTxValue and TxCount are always updated synchronously, avoiding inconsistent states such as "count has been incremented but value has not been updated" or "value has been updated but count has not been incremented".

[0077] The CAN message receive path is a complete execution link from hardware receive interrupt to PDU layer and signal layer counter table update. This path is activated when the CAN controller hardware successfully receives a message frame (including bit stuffing check, CRC check, ACK acknowledgment, and format check) and triggers a receive interrupt.

[0078] Step 21: CAN Receive Interrupt Triggered. When the CAN controller hardware detects a matching message ID on the bus and successfully receives one L-PDU frame, it writes the message content to the hardware Rx Buffer and triggers a receive interrupt. The interrupt vector entry points to the interrupt handling function Can_17_McmCan_1RxExtractData of the Can_17_McmCan driver used in this application.

[0079] Step 22: CanIf_RxIndication call. CanDrv calls the AUTOSAR standard interface CanIf_RxIndication(Mailbox, PduInfo) (Service ID 0x14, synchronous, reentrant) in the interrupt context, passing the received indication event up to the CanIf layer. The Mailbox parameter carries hardware-level metadata (Mailbox ID, HOH, CanId, etc.), and the PduInfo parameter carries the decoded data length and a pointer to the data content.

[0080] Step 23: Similar to the sending path, in a multi-core ECU scenario, CanIf_RxIndication will further call the local core's CanIf_XCore_LocalCore_RxIndication function to complete the localization of multi-core routing.

[0081] Step 24: Function Pointer Array Routing. After multi-core localization processing, CanIf searches for the corresponding function pointer in the function pointer array RxAutosarUL_Ptr[Index] using the callback function name specified in the configuration item, and calls the corresponding callback function through the CanIfRxPduIndicationName() field. Therefore, in this embodiment, CDD replaces PDUR as the key routing point on the receiving path, and in this solution, the function pointer array directly routes to the User_RxIndication of the CDD layer.

[0082] Step 25: User_RxIndication Invocation. The target function User_RxIndication(Mailbox, PduInfo), located through the function pointer array, is invoked, receiving the indication event and formally entering the CDD layer described in this invention. The specific implementation of this function is located inside the CDD layer.

[0083] Step 26: PDU Layer Count Update (Rte_Swc_UpdateRxCount). The Rte_Swc_UpdateRxCount(PduId) function is called in the User_RxIndication callback of the CDD layer. This function increments the RxCount field of the corresponding entry in the CanFrame Count Table array by 1 (CanFrameCountTable[id].RxCount++) using PduId as the index, recording the successful reception event of this message in the PDU layer count table.

[0084] Step 27: Signal Layer Count and Value Snapshot Update (Rte_Swc_ProcessSignalRx). After completing the PDU layer count update, the Rte_Swc_ProcessSignalRx(SignalId, SignalValue) function is further called to synchronously perform two atomic operations on the corresponding signal entry in the Signal Route Table: (a) SignalRouteTable[id].RxCount++, recording the cumulative number of times the signal has been received; (b) SignalRouteTable[id].LastRxValue = SignalValue, recording the value of the signal when it was last received. It should be noted that the SignalValue parameter is the original signal value obtained by decoding from PduInfo according to the signal layout (start bit, length, byte order) defined by the Com layer. The CDD layer does not perform any business logic processing, but only performs a lightweight action of "updating immediately after decoding".

[0085] The bus routing frame loss detection system proposed in this application constructs a layered architecture comprising a bus driver layer, a bus interface layer, and a device driver layer. By utilizing the bus interface layer to simultaneously call the first callback interface and the second callback interface, the system drives the protocol data unit layer to update the frame loss count table and the signal layer to update the signal routing table, respectively. The software component layer then generates frame loss results based on the joint analysis of the two tables. This achieves dual fine-grained monitoring of both messages and signals, enabling not only accurate identification of message loss but also effective detection of hidden faults such as incorrect or outdated signal values ​​in the routing path. While solving the problem of insufficient detection granularity, the system improves real-time performance and fault location accuracy through simplified routing paths.

[0086] Next, referring to the accompanying drawings, a bus routing frame loss detection method according to an embodiment of this application is described, which is applied to the bus routing frame loss detection system of the above embodiment.

[0087] Figure 2 This is a flowchart of a bus routing frame loss detection method provided in an embodiment of this application.

[0088] like Figure 2 As shown, the bus routing frame loss detection method includes the following steps: In step S101, bus routing data signals are transmitted through the hardware layer.

[0089] In step S102, the event status of the data signal is transmitted to the bus interface layer through the bus driver layer; the event status is sent to the protocol data unit layer through the first callback interface and to the signal layer through the second callback interface; the protocol data unit layer calls the first update function to update the frame loss count table; and the signal layer calls the second update function to update the signal routing table.

[0090] In step S103, the callback data of the bus interface layer is forwarded to the software component layer through the device driver layer; the signal routing table and the frame loss count table are maintained by the software component layer, and the frame loss result of the bus routing is generated based on the signal routing table and the frame loss count table.

[0091] It should be noted that the foregoing explanation of the bus routing frame loss detection system embodiment also applies to the bus routing frame loss detection method of this embodiment, and will not be repeated here.

[0092] This application also provides an electronic device, including: the bus routing frame loss detection system described in the above embodiments.

[0093] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0094] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "N" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0095] Any process or method described in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or N executable instructions for implementing custom logic functions or processes, and the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as should be understood by those skilled in the art to which embodiments of this application pertain.

[0096] It should be understood that various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any of the following techniques known in the art, or a combination thereof: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (FPGAs), field-programmable gate arrays (FPGAs), etc.

[0097] Those skilled in the art will understand that all or part of the steps of the methods implementing the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.

[0098] Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of this application.

Claims

1. A bus route frame loss detection system, characterized by, include: The hardware layer, bus driver layer, bus interface layer, device driver layer, and software component layer are as follows: The hardware layer is used to transmit data signals for bus routing; The bus driver layer is used to transmit the event status of the data signal to the bus interface layer; The bus interface layer is used to call the first callback interface to send the event status to the protocol data unit layer and the second callback interface to send the event status to the signal layer. The protocol data unit layer calls the first update function to update the frame loss count table. The signal layer calls the second update function to update the signal routing table. The device driver layer forwards the callback data from the bus interface layer to the software component layer; The software component layer maintains the signal routing table and the frame loss count table, and generates the frame loss results of the bus route based on the signal routing table and the frame loss count table.

2. The bus route frame loss detection system of claim 1, wherein, Also includes: The task layer is used to periodically execute signal transmission tasks based on the scheduling entry point. When activated by the scheduler, it calls the interface function of the software component layer to perform bus routing frame loss detection on the signal routing table and the frame loss count table.

3. The bus route frame loss detection system of claim 1, wherein, Also includes: The log layer is used to record the frame loss results of the bus routing, identify the frame loss events in the frame loss results, and generate reporting events according to the type of the frame loss events.

4. The bus routing frame loss detection system according to claim 1, characterized in that, The hardware layer is used to send the data signal through the sending path and receive the data signal through the receiving path.

5. The bus routing frame loss detection system according to claim 1, characterized in that, The data structure of the signal routing table includes a first field, a second field, a third field, and a fourth field. The first field is used to accumulate and record the number of times the data signal is processed by the software component layer after being decoded via the receiving path. The second field is used to accumulate and record the number of times the data signal is transmitted after being encoded via the sending path. The third field is used to store the original value of the data signal when it was last processed by the software component layer via the receiving path. The fourth field is used to store the original value of the data signal when it was last processed by the software component layer via the sending path.

6. The bus routing frame loss detection system according to claim 1, characterized in that, The first update function uses the identifier of the data signal as an index to perform a counting operation on the target field of the corresponding table entry in the frame loss count table array on the receiving path and the sending path.

7. The bus routing frame loss detection system according to claim 1, characterized in that, After the frame loss count table is updated, the second update function synchronously performs a counting operation and a value snapshot update operation on the signal routing table on both the receiving and sending paths.

8. The bus routing frame loss detection system according to claim 7, characterized in that, The second update function includes a first processing function and a second processing function, wherein the first processing function synchronously performs a counting operation on the signal routing table on the receiving path and the sending path, and the second processing function synchronously performs a value snapshot update operation on the signal routing table on the receiving path and the sending path.

9. An electronic device, characterized in that, Includes the bus routing frame loss detection system as described in any one of claims 1-8.

10. A method for detecting frame loss in bus routing, characterized in that, The method is applied to the bus routing frame loss detection system as described in any one of claims 1-8, wherein the method includes the following steps: Transmit bus-routable data signals through the hardware layer; The event status of the data signal is transmitted to the bus interface layer through the bus driver layer; The event status is sent to the protocol data unit layer by calling the first callback interface through the bus interface layer and to the signal layer by calling the second callback interface. The protocol data unit layer calls the first update function to update the frame loss count table. The signal layer calls the second update function to update the signal routing table. The callback data from the bus interface layer is forwarded to the software component layer through the device driver layer; The signal routing table and the frame loss count table are maintained by the software component layer, and the frame loss results of the bus routing are generated based on the signal routing table and the frame loss count table.

Images