Embedded system end-to-end scheduling anomaly detection method based on CAN bus

Abstract

The invention relates to an embedded system end-to-end scheduling anomaly detection method based on a CAN bus, and belongs to the technical field of simulation. Aiming at a CAN bus interconnected embedded system, a mathematical model of the system and each component, especially a CAN bus data frame model and a transmission time calculation method, is established, and a simulation framework of the system is established. In addition, according to the method, the operation mechanism of the system is analyzed in detail, the interaction relation among the components is cleared, a non-destructive arbitration mechanism and a priority-based preemptive scheduling strategy are combined, state updating functions of tasks and messages are designed respectively, and a basis is provided for system state updating in the simulation process. Compared with an existing method, the method has the advantages that a specific model of the CAN bus is directly given, application is easy, and expandability is high.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of simulation, and particularly relates to an end-to-end scheduling anomaly detection method for an embedded system based on a CAN bus. BACKGROUND

[0002] Scheduling anomaly is an anti-intuitive phenomenon that positive adjustment of system parameters produces negative results, which has serious harm to system determinacy and is difficult to detect. At present, the utilization rate of system resources is mainly sacrificed to avoid the occurrence of anomaly, and there is still a lack of effective detection means for scheduling anomaly detection.

[0003] The existing scheduling anomaly detection method mainly analyzes task-level scheduling anomaly. The literature "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 system architecture and task parameters, and dynamic constraints depend on the state of the system during task execution. The method summarizes seven kinds of scheduling anomaly behaviors, and judges the possible scheduling anomaly through offline and online constraint detection algorithms.

[0004] For end-to-end anomaly detection, the literature "McSad: A Monte Carlo-Based End-to-End Scheduling Anomaly Detection Method for Distributed Real-Time Systems" proposes an end-to-end scheduling anomaly detection method based on Monte Carlo simulation. The method defines two types of absolute and statistical end-to-end scheduling anomalies, and designs different sampling methods for the two types of scheduling anomalies. By designing the state update function of the task and the message, the simulation algorithm of the distributed system is established. Finally, based on Monte Carlo simulation and task chain timing analysis, the detection of end-to-end scheduling anomaly is realized.

[0005] Although the method proposed in the literature "Work-in-Progress: Models and Tools to Detect Real-Time Scheduling Anomalies" comprehensively considers various factors leading to scheduling anomaly, it only gives the necessary and sufficient conditions for the occurrence of anomaly according to the combination of two types of constraints, and fails to further give more accurate analysis.

[0006] The method in the document "McSad: A Monte Carlo-Based End-to-End Scheduling Anomaly Detection Method for Distributed Real-Time Systems" simply abstracts the data transmission process as the scheduling process of messages, cannot depict the data frame model and the bus arbitration mechanism, and is difficult to apply in actual engineering. SUMMARY

[0007] (I) Technical problems to be solved The technical problem to be solved by the present application is how to provide a CAN bus-based embedded system end-to-end scheduling anomaly detection method to solve the problem that the necessary and sufficient conditions for the generation of anomalies are given according to the combination of two types of constraints, and more accurate analysis cannot be further given, the data transmission process is simply abstracted as the scheduling process of messages, and the data frame model and the bus arbitration mechanism cannot be depicted, and it is difficult to apply in actual engineering.

[0008] (II) Technical solutions In order to solve the above technical problems, the present application provides a CAN bus-based embedded system end-to-end scheduling anomaly detection method, which comprises the following steps: Step 1, defining an embedded system model, including: CAN bus and computing node; Step 2, defining a CAN bus model; Step 3, defining a computing node model, including: node task, sending mailbox, receiving FIFO, task ready queue and task waiting queue; Step 4, defining a task model, the task includes: including periodic task, sporadic task and message triggered task; Step 5, defining a message model; Step 6, defining a task chain model; Step 7, defining an end-to-end scheduling anomaly detection method; Step 8, constructing a simulation system, the CAN bus and the computing node are connected through SendMailBox and ReceiveFIFO, and the system simulation process is clock-driven; Step 9: end-to-end scheduling anomaly analysis.

[0009] (III) Advantages 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

[0010] Figure 1 This is the main flowchart of the end-to-end anomaly detection of the present invention; Figure 2 This is a system simulation framework diagram of the present invention; Figure 3 This is a system simulation flowchart of the present invention. Detailed Implementation

[0011] 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.

[0012] 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.

[0013] 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: Step 1: Define the embedded system model, including: CAN bus and computing nodes.

[0014] 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.

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

[0016] The CAN bus model is shown in (1): (1) 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.

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

[0018] The computation node model in the system is shown in formula (2): (2) 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.

[0019] Step 4: Define the task model.

[0020] The task model in the system is represented as shown in formula (3): (3) 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.

[0021] Step 5: Define the message model.

[0022] The message model in the system is shown in formula (4): 4 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): (5) 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.

[0023] Step Six: Define the Task Chain Model A sequence of tasks or messages that have dependencies is called a task chain, represented as: (15) 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.

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

[0025] 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): 7 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.

[0026] 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: (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 task's state update function is shown in formula (8): (8) 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.

[0027] (4) If the task is configured SendMsg A message will be sent after the task is completed. 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 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): (9) 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.

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

[0029] 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.

[0030] Key points of this invention: 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.

[0031] Effects of the invention: 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.

[0032] 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 9: End-to-end scheduling anomaly analysis.

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): (1) 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.

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): (2) 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.

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): (3) 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 five includes: The message model is shown in formula (4): (4) 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): (5) 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.

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 six includes: A sequence of tasks or messages that have dependencies is called a task chain, represented as: (6) 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.

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 seven includes: If the sum of the execution times of all nodes in the task chain does not follow the same trend as the end-to-end latency, it is called an end-to-end scheduling anomaly, as shown in formula (7): (7) 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.

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 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 task's state update function is shown in formula (8): (8) 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 A message will be sent after the task is completed. 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 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): (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 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.

10. The method for detecting end-to-end scheduling anomalies in an embedded system based on a CAN bus as described in claim 9, 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 as well as the end-to-end latency; 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 latency in the two scenarios is different, then it is determined that there is an end-to-end scheduling anomaly.

Images