A CAN bus-based embedded system end-to-end scheduling anomaly detection method

Abstract

The application relates to a CAN bus-based embedded system end-to-end scheduling exception detection method and belongs to the technical field of simulation. The application establishes mathematical models of a system and components of an embedded system interconnected by a CAN bus, especially a CAN bus data frame model and a transmission time calculation method, and builds a simulation framework of the system. In addition, the application analyzes the operation mechanism of the system in detail, clarifies the interaction relationship between the components, combines a non-destructive arbitration mechanism and a priority-based preemptive scheduling strategy, and respectively designs state update functions of tasks and messages, so that the application provides a basis for system state updating in a simulation process. Compared with an existing method, the method directly gives a specific model of the CAN bus, is easy to apply, and is high in expandability.

Description

Technical Field

[0001] This invention belongs to the field of simulation technology, specifically relating to an end-to-end scheduling anomaly detection method for embedded systems based on CAN bus. Background Technology

[0002] Scheduling anomalies are counterintuitive phenomena where actively adjusting system parameters produces negative results. They severely jeopardize system determinism and are difficult to detect. Current methods primarily sacrifice system resource utilization to avoid these anomalies, but effective detection techniques for scheduling anomalies remain lacking.

[0003] Existing scheduling anomaly detection methods mainly target task-level scheduling anomaly analysis. The paper "Work-in-Progress: Models and Tools to Detect Real-Time Scheduling Anomalies" proposes a task-level scheduling anomaly detection method based on constraint combination. Static constraints are generated by the system architecture and task parameters, while dynamic constraints depend on the system state during task execution. This method summarizes seven types of scheduling anomaly behaviors and uses offline and online constraint detection algorithms to determine possible scheduling anomalies.

[0004] For end-to-end anomaly detection, the paper "McSad: A Monte Carlo-Based End-to-EndScheduling Anomaly Detection Method for Distributed Real-Time Systems" proposes an end-to-end scheduling anomaly detection method based on Monte Carlo simulation. This method defines two types of end-to-end scheduling anomalies: absolute and statistical. Different sampling methods are designed for each type of scheduling anomaly. By designing the state update functions of tasks and messages, a simulation algorithm for the distributed system is established. Finally, based on Monte Carlo simulation and task chain timing analysis, the detection of end-to-end scheduling anomalies is achieved.

[0005] The method proposed in the paper "Work-in-Progress: Models and Tools to Detect Real-TimeScheduling Anomalies" comprehensively considers various factors that lead to scheduling anomalies, but it only gives the necessary but not sufficient conditions for the occurrence of anomalies based on the combination of two types of constraints, and fails to provide a more accurate analysis.

[0006] The method proposed in the paper "McSad: A Monte Carlo-Based End-to-End Scheduling AnomalyDetection Method for Distributed Real-Time Systems" simply abstracts the data transmission process into a message scheduling process, which cannot characterize the data frame model and bus arbitration mechanism, making it difficult to apply in practical engineering. Summary of the Invention

[0007] (a) Technical problems to be solved

[0008] The technical problem this invention aims to solve is how to provide an end-to-end scheduling anomaly detection method for embedded systems based on CAN bus, in order to address the issues that the method provides necessary but not sufficient conditions for anomaly generation based on the combination of two types of constraints, but fails to provide a more precise analysis; and that the method simply abstracts the data transmission process as a message scheduling process, which cannot characterize the data frame model and bus arbitration mechanism, making it difficult to apply in practical engineering.

[0009] (II) Technical Solution

[0010] To address the aforementioned technical problems, this invention proposes an end-to-end scheduling anomaly detection method for embedded systems based on the CAN bus. This method includes the following steps:

[0011] Step 1: Define the embedded system model, including: CAN bus and computing nodes;

[0012] Step 2: Define the CAN bus model;

[0013] Step 3: Define the computing node model, including: node tasks, send mailbox, receive FIFO, task ready queue and task waiting queue;

[0014] Step 4: Define the task model, which includes: periodic tasks, occasional tasks, and message-triggered tasks;

[0015] Step 5: Define the message model;

[0016] Step 6: Define the task chain model;

[0017] Step 7: Define the end-to-end scheduling anomaly detection method;

[0018] Step 8: Construct a simulation system. The CAN bus and computing nodes are connected via SendMailBox and ReceiveFIFO. The system simulation process is clock-driven.

[0019] Step 9: End-to-end scheduling anomaly analysis.

[0020] (III) Beneficial Effects

[0021] This invention proposes a method for detecting end-to-end scheduling anomalies in embedded systems based on the CAN bus. This method models the system interconnect, computing nodes, and the CAN bus, defines task chains and end-to-end scheduling anomaly models, designs state update functions for tasks and messages in the system, and determines the existence of end-to-end scheduling anomalies based on statistical results. Compared with existing methods, this method directly provides a specific model of the CAN bus, making it easy to apply and highly scalable. Attached Figure Description

[0022] Figure 1 This is the main flowchart of the end-to-end anomaly detection of the present invention;

[0023] Figure 2 This is a system simulation framework diagram of the present invention;

[0024] Figure 3 This is a system simulation flowchart of the present invention. Detailed Implementation

[0025] To make the objectives, contents, and advantages of the present invention clearer, the specific embodiments of the present invention will be described in further detail below with reference to the accompanying drawings and examples.

[0026] The purpose of this invention is to provide an end-to-end scheduling anomaly detection method for embedded systems with CAN bus interconnection. This method establishes a quantitative characterization model of the CAN bus data frame format, arbitration mechanism, and system, and calculates the system-level end-to-end latency through simulation analysis, thereby realizing the detection of scheduling anomalies.

[0027] Figure 1 This is the main flowchart of the technical solution of this invention. The specific steps of the implementation scheme for the end-to-end scheduling anomaly detection method for embedded systems based on the CAN bus are as follows:

[0028] Step 1: Define the embedded system model, including: CAN bus and computing nodes.

[0029] CAN bus-based embedded system model ,in This represents the set of CAN buses in the system. Represents the first in the system i One CAN bus, K Indicates the number of CAN buses in the system; Represents the set of computing nodes in the system. Indicates the first i One computing node, n This indicates the number of nodes in the system.

[0030] Step 2: Define the CAN bus model.

[0031] The CAN bus model is shown in (1):

[0032] (1)

[0033] in, The baud rate of the bus is used to characterize the bus. The transmission rate; This indicates a bit-filling mechanism, where This indicates average bit filling. Indicates no fill. Indicates worst-case bit padding; Indicates bus The data frame type, where Represents a standard data frame. Indicates an extended data frame; Indicates connection to the bus The set of computing nodes.

[0034] Step 3: Define the computing node model.

[0035] The computation node model in the system is shown in formula (2):

[0036] (2)

[0037] in, This represents the set of tasks for that node. Indicates the first i One task, m Indicates the number of tasks; This indicates the sending mailbox of this node. This indicates the receive FIFO of the node. This represents the task ready queue. This represents the task waiting queue.

[0038] Step 4: Define the task model.

[0039] The task model in the system is represented as shown in formula (3):

[0040] (3)

[0041] in, Indicates the type of task, including periodic tasks, occasional tasks, and message-triggered tasks; Indicates the priority of the task; This parameter indicates the task's duration and is only valid for periodic tasks. This indicates the minimum time interval to reach the target; this parameter is only valid for occasional tasks. Indicates the worst-case execution time of the task; Indicates the task's release time; Indicates the response time of the task; Indicates the relative deadline for the task; This indicates the message sent when the task is completed.

[0042] Step 5: Define the message model.

[0043] The message model in the system is shown in formula (4):

[0044] 4

[0045] in, This represents the arbitration segment of a data frame, used to identify the priority of the data frame; Indicates the number of bytes in the data segment, ranging from 1 to 8; This indicates the node that sent the message; Indicates the target node of the message; Indicates the task triggered by the message; This indicates the time when the message was generated, i.e., the time when the task of sending the message was completed; Indicates the relative deadline for message transmission; The time it takes for a message to travel on the bus is represented by formula (5):

[0046] (5)

[0047] in, L i Indicates the number of bytes of data in the message. ; g Indicates the total number of control bits. CAN bus data frames are divided into standard frames and extended frames. Standard frame messages... g =34, Extended Frame Message g =54; This indicates the bus baud rate.

[0048] Step Six: Define the Task Chain Model

[0049] A sequence of tasks or messages that have dependencies is called a task chain, represented as:

[0050] (15)

[0051] in, Indicates a task chain. This represents a node in a task chain, which can be a task or a message. The release time of the task chain is defined as the release time of the first node, the completion time as the completion time of the last node, and the task's response time. This is the difference between the task chain completion time and the release time, also known as the end-to-end latency of the task chain. The first node can be either a task or a message. If it is a task, the release time of the first node is the same as the task's release time, i.e., in formula (3). RlsT If it is a message, the release time of the first node is the time when the message was generated.

[0052] Step 7: Define the end-to-end scheduling anomaly detection method.

[0053] If the sum of the execution times (task execution time and message passing time) of all nodes in the task chain does not follow the trend of the end-to-end latency, it is called an end-to-end scheduling anomaly, as shown in formula (7):

[0054] 7

[0055] in, and For task chain The nodes in , x For task chain The number of tasks in the middle, y For task chain The number of messages in the middle, z For task chain The number of all nodes in the network. This indicates the amount of change in task execution time or message transmission time.

[0056] Step 8: Figure 2 This is a system simulation framework diagram, illustrating the system's simulation architecture through two computing nodes and one CAN bus. The CAN bus and computing nodes communicate via... SendMailBox and ReceiveFIFO The connection and system simulation process are clock-driven. Combined with... Figure 3 The system simulation flowchart and description of the embedded system simulation process are as follows:

[0057] (1) Periodic tasks and occasional tasks are triggered by time. The tasks are inserted into the ready queue of the computing node. The tasks in the queue are sorted according to priority, and the highest priority task is at the head of the queue.

[0058] (2) The tasks in the ready queue are scheduled using a priority-based preemptive scheduling algorithm, and the preempted tasks are placed into the waiting queue;

[0059] (3) The task's state update function is shown in formula (8):

[0060] (8)

[0061] This formula represents how the state of tasks in the system is updated over time: if the task Located in the waiting queue WaitQ middle( )and The updated response time is less than or equal to the deadline. Then the task The response time plus 1, that is If the task Located in the waiting queue WaitQ But The updated response time is longer than the deadline. At this point, the task timed out, so the task was removed. This indicates that the task is in a running state. and The updated response time is less than or equal to the deadline. Then the task The response time plus 1, that is If the task is in a running state but The updated response time is longer than the deadline. At this point, the task timed out, so the task was removed. express.

[0062] (4) If the task is configured SendMsg After the task is completed, a message will be sent to SendMailBox The message awaits the allocation of CAN bus usage rights according to a non-destructive arbitration mechanism;

[0063] (5) The message transmission time on the bus is calculated using formula (5). After the message transmission is completed, it is sent to the destination computing node. If the message is configured... TriTask This message will trigger the release of the configured task, and the message status update is shown in formula (9):

[0064] (9)

[0065] This formula represents how the status of messages in the system is updated over time, where, Indicates the time since the message existed; This indicates the message's expiration time; if the message's existence time equals the expiration time, and the message has not been fully transmitted, then the message is deleted, indicated as... . This indicates that the message is being transmitted; Indicates the remaining transmission time of the message. If the message is currently being transmitted... The message's current age after the update is less than or equal to the message's expiration time. And the message transmission was not completed. If the message already exists, then increment the message's timeout by 1. If the message is in transit The message has existed for less than or equal to its expiration time and the message transmission is complete. If the message already exists, increment the message's expiration time by 1 and deliver the message to [the appropriate address]. ReceiveFIFO In the middle; if the message is located in the sending mailbox SendMailBox Furthermore, the time since the message was updated is less than or equal to the message's expiration time. If the message's existing time is greater than its expiration time, then increment the message's existing time by 1; And the message transmission timed out before completion, so the message was removed and used. express.

[0066] Step 9: End-to-end scheduling anomaly analysis.

[0067] Users configure the system model based on actual system parameters and begin simulation, traversing all system operation scenarios and calculating the sum of task execution time and message transmission time in the task chain, as well as the end-to-end latency. If any two scenarios meet the conditions described in formula (7), i.e., the trends of the sum of execution time of all nodes in the task chain and the end-to-end latency are different in the two scenarios, then an end-to-end scheduling anomaly is identified.

[0068] Key points of this invention:

[0069] This invention addresses embedded systems interconnected by CAN bus, establishing mathematical models of the system and its components, particularly the CAN bus data frame model and transmission time calculation method, and constructing a simulation framework for such systems. Furthermore, this invention provides a detailed analysis of the system's operational mechanism, clarifies the interaction relationships between components, and designs state update functions for tasks and messages by combining a non-destructive arbitration mechanism and a priority-based preemptive scheduling strategy, providing a basis for system state updates during simulation.

[0070] Effects of the invention:

[0071] The present invention provides an end-to-end scheduling anomaly detection method for embedded systems based on the CAN bus. It models the system interconnection, computing nodes, and the CAN bus, defines task chains and end-to-end scheduling anomaly models, designs state update functions for tasks and messages in the system, and determines the existence of end-to-end scheduling anomalies based on statistical results. Compared with existing methods, this method directly provides a specific model of the CAN bus, making it easy to apply and highly scalable.

[0072] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the technical principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A method for detecting end-to-end scheduling anomalies in an embedded system based on a CAN bus, characterized in that, The method includes the following steps: Step 1: Define the embedded system model, including: CAN bus and computing nodes; Step 2: Define the CAN bus model; Step 3: Define the computing node model, including: node tasks, send mailbox, receive FIFO, task ready queue and task waiting queue; Step 4: Define the task model, which includes: periodic tasks, occasional tasks, and message-triggered tasks; Step 5: Define the message model; Step 6: Define the task chain model; Step 7: Define the end-to-end scheduling anomaly detection method; Step 8: Construct a simulation system. The CAN bus and computing nodes are connected via SendMailBox and ReceiveFIFO. The system simulation process is clock-driven. Step Nine: End-to-End Scheduling Anomaly Analysis; in, Step five includes: The message model is shown in formula (4): (2) in, This represents the arbitration segment of a data frame, used to identify the priority of the data frame; Indicates the number of bytes in the data segment, ranging from 1 to 8; This indicates the node that sent the message; Indicates the target node of the message; Indicates the task triggered by the message; This indicates the time when the message was generated, i.e., the time when the task of sending the message was completed; Indicates the relative deadline for message transmission; The time it takes for a message to travel on the bus is represented by the formula (5). (3) in, L i Indicates the number of bytes of data in the message. ; g Indicates the total number of control bits. CAN bus data frames are divided into standard frames and extended frames. Standard frame messages... g =34, Extended Frame Message g =54; Indicates the bus baud rate; This indicates average bit filling. Indicates no fill. This indicates the worst-case bit padding.

2. The method for detecting end-to-end scheduling anomalies in an embedded system based on a CAN bus as described in claim 1, characterized in that, Step one includes: CAN bus-based embedded system model ,in This represents the set of CAN buses in the system. Represents the first in the system i One CAN bus, K Indicates the number of CAN buses in the system; Represents the set of computing nodes in the system. Indicates the first i One computing node, n This indicates the number of nodes in the system.

3. The method for detecting end-to-end scheduling anomalies in an embedded system based on a CAN bus as described in claim 2, characterized in that, Step two includes: The CAN bus model is shown in formula (1): (4) in, The baud rate of the bus is used to characterize the bus. The transmission rate; Indicates bit stuffing mechanism, Indicates bus The data frame type, where Represents a standard data frame. Indicates an extended data frame; Indicates connection to the bus The set of computing nodes.

4. The method for detecting end-to-end scheduling anomalies in an embedded system based on a CAN bus as described in claim 3, characterized in that, Step three includes: The computation node model is shown in formula (2): (5) in, This represents the set of tasks for that node. Indicates the first i One task, m Indicates the number of tasks; This indicates the sending mailbox of the node. This indicates the receive FIFO of the node. This represents the task ready queue. This represents the task waiting queue.

5. The method for detecting end-to-end scheduling anomalies in an embedded system based on a CAN bus as described in claim 4, characterized in that, Step four includes: The task model is represented as shown in formula (3): (6) in, Indicates the type of task, including periodic tasks, occasional tasks, and message-triggered tasks; Indicates the priority of the task; This parameter indicates the task's duration and is only valid for periodic tasks. This indicates the minimum time interval to reach the target; this parameter is only valid for occasional tasks. Indicates the worst-case execution time of the task; Indicates the task's release time; Indicates the response time of the task; Indicates the relative deadline for the task; This indicates the message sent when the task is completed.

6. The method for detecting end-to-end scheduling anomalies in an embedded system based on a CAN bus as described in claim 5, characterized in that, Step six includes: A sequence of tasks or messages that have dependencies is called a task chain, represented as: (7) in, Indicates a task chain. This represents a node in a task chain, which can be a task or a message; the release time of the task chain is defined as the release time of the first node, the completion time of the task chain is defined as the completion time of the last node, and the response time of the task. This is the difference between the task chain completion time and the release time, also known as the end-to-end latency of the task chain.

7. The method for detecting end-to-end scheduling anomalies in an embedded system based on a CAN bus as described in claim 6, characterized in that, Step seven includes: If the sum of the execution times of all nodes in the task chain does not show the same trend as the end-to-end latency, it is called an end-to-end scheduling anomaly, as shown in formula (7): (8) in, and For task chain The nodes in , x For task chain The number of tasks in the middle, y For task chain The number of messages in the middle, z For task chain The number of all nodes in the network. This indicates the amount of change in task execution time or message transmission time.

8. The method for detecting end-to-end scheduling anomalies in an embedded system based on a CAN bus as described in claim 7, characterized in that, Step eight includes: The simulation process is described as follows: (1) Periodic tasks and occasional tasks are triggered by time. The tasks are inserted into the ready queue of the computing node. The tasks in the queue are sorted according to priority, and the highest priority task is at the head of the queue. (2) The tasks in the ready queue are scheduled using a priority-based preemptive scheduling algorithm, and the preempted tasks are placed into the waiting queue; (3) The state update function of the task is shown in formula (8): (9) This formula represents how the state of tasks in the system is updated over time: if the task Located in the waiting queue WaitQ and The updated response time is less than or equal to the deadline. Then the task The response time plus 1, that is If the task Located in the waiting queue WaitQ But The updated response time is longer than the deadline. At this point, the task timed out, so the task was removed. This indicates that the task is in a running state. and The updated response time is less than or equal to the deadline. Then the task The response time plus 1, that is If the task is in a running state but The updated response time is longer than the deadline. At this point, the task timed out, so the task was removed. express; (4) If the task is configured SendMsg After the task is completed, a message will be sent to SendMailBox The message awaits the allocation of CAN bus usage rights according to a non-destructive arbitration mechanism; (5) The message transmission time on the bus is calculated by formula (5). After the message transmission is completed, it is sent to the destination computing node. If the message is configured... TriTask This message will trigger the release of the configured task, and the message status update is shown in formula (9): (9) This formula represents how the status of messages in the system is updated over time, where, Indicates the time since the message existed; Indicates the deadline for the message; This indicates that the message is being transmitted; Indicates the remaining transmission time of the message; if the message is in transmission... The message's current age after the update is less than or equal to the message's expiration time. And the message has not been fully transmitted. If the message already exists, then increment the message's timeout by 1. If the message is in transit The message has existed for less than or equal to its expiration time and the message transmission is complete. If the message already exists, increment the message's expiration time by 1 and deliver the message to [the appropriate address]. ReceiveFIFO In the middle; if the message is located in the sending mailbox SendMailBox Furthermore, the time since the message was updated is less than or equal to the message's expiration time. If the message's existing time is greater than its expiration time, then increment the message's existing time by 1; And the message transmission timed out before completion, so the message was removed and used. express.

9. The method for detecting end-to-end scheduling anomalies in an embedded system based on a CAN bus as described in claim 8, characterized in that, Step nine includes: the user configures the system model according to the actual system parameters and starts the simulation, traverses all the running scenarios of the system, and counts the sum of task execution time and message transmission time in the task chain and the end-to-end delay; if there are any two scenarios that meet the situation described in formula (7), that is, the trend of the sum of execution time of all nodes in the task chain and the end-to-end delay in the two scenarios is different, then it is determined that there is an end-to-end scheduling anomaly.

Images