Stateful Real-Time Communication Schedules

Size: px

Start display at page:

Download "Stateful Real-Time Communication Schedules"

Marcus Gardner
5 years ago
Views:

1 Rishi Bhat Chris Walstad Advisor: Insup Lee Stateful Real-Time Communication Schedules Abstract The typical approach to guaranteed message delivery in distributed real-time systems uses Time Division Multiple Access (TDMA) to ensure that no scheduling collisions occur. The most important property of scheduling in a real-time system is to guarantee that each node is given its scheduled timeslot and no collisions exist between all of the nodes timeslots. TDMA uses a fairly simplistic approach to satisfy this property: each node is assigned a single timeslot and can only send messages during that slot. On the other hand, stateful communication schedules allow for a significantly more complicated schedule. By using network code programs which run on top of the scheduler we can allow each node to send and receive messages and perform error recovery in a more efficient manner. This is done by maintaining information in the scheduler which allows it to intelligently choose the next best node to be scheduled. Stateful communication schedules are thus valuable in distributed systems such as automobiles or medical devices in which there must be a guarantee that messages are delivered very quickly (consider a driver pushing on a brake pedal, for example). There were several goals of this project. We studied several related high-level specification languages such as AADL and Giotto, and due to unnecessary complexity we created our own simple specification language to model network constraints. Secondly, we developed a scheduler which schedules communications on the network and CPUs based on constraints specified in the input. Next we created a compiler which

2 translates the schedule into network code which can be run on the RTLinux scheduler. Finally, we created a visualization tool that creates a pictorial representation of our schedule. Related Work The typical approach to communication in real-time distributed systems uses TDMA. An example of a TDMA schedule is shown in Figure 1. Here Sync is a synchronization message, Ctrl is a control message, and the remainder of the blocks represent nodes. Node A 1 is allowed to send a message during the 10 to 20 time units slot, A 2 is allowed to send a message in the 20 to 30 time units slot, and so on. Figure 1 (source: slides from Sebastian Fischmeister) TDMA can ensure that collisions do not occur, but it is not the most efficient method of ensuring this property. Consider, for example, what would happen if node A 1 did not have any message to send during the 10 to 20 time unit slot. The communication medium would be wasted during this time because no other nodes are allowed to transmit during this time and A 1 has nothing to send. This project focuses on stateful communication schedules which allow much more complicated schedules and can be used to solve some problems with TDMA. Earlier research by Gregor A. König has produced a first version of the network code compiler. Our project significantly expands on the existing work by using a more sophisticated scheduler. We also completely redeveloped the network code compiler and input language. Technical Approach

3 Figure 2 (source: slides from Sebastian Fischmeister) This project is concerned with the shaded bubbles of Figure 2. Our developed code generator takes as input a set of specifications in our input language. These specifications define the network and CPU constraints for all of the nodes in the system. The output is annotated network code as well as visual and textual representations of the created schedule. We developed a simple input language that models the properties of the system. The input language contains three sections in which we specify tasks, communications, and guards. Tasks are defined to be periodic processes running on a node that have a worst case execution time and transmission time. We assume that all data can be transmitted in one Ethernet frame and thus the transmission time is always one. Communications specify the way in which tasks transmit between each other. Additionally, each task uses an input and output port which is specified in the communication section. Guards are used to specify a choice between two or more

4 communications based on a dynamic computation performed by the function specified in the guard. An example of a possible input to the system is: // Task section // Task ID, Node, Period, WCET, Transmission Time 1, 1, 10, 3, 1 2, 1, 20, 2, 1 3, 2, 10, 5, 1 4, 2, 5, 1, 1 // Communication section // Sending Task.Port -> Receiving Task.Port 1.1 -> > > > 4.2 // Guard section // Guard ID, Function, Input Task, True Branch, False Branch 1, fun1, {2}, 1, 2 2, fun2, {1}, 3, 4 Note that in the guard section the true and false branches specify which communications to run. The communications are given an implicit ID based on their position in the file. It is also possible to represent more than two choices by chaining guards. For example, to choose between three communications we could write: 1, fun1, {1}, 1, g2 2, fun2, {1}, 2, 3 We have developed and implemented a scheduling algorithm in Java which takes the input described above. The algorithm then returns not schedulable or a schedule for both the network communication medium as well as the CPU on each node up to the least common multiple of the periods of all tasks (since if there are no conflicts up to the LCM of the periods, then there will never be a conflict). We define the slack of a task to be the difference of the task s computation time and period. Thus, the slack of a task can be viewed as the amount of time that a task has to transmit information over the network before it must be run again. We also define an active communication as a

5 communication that has not yet been scheduled during the current period of the sending task or receiving task. Our algorithm works by first scheduling the transmission of each task over the network communication medium, and then uses this schedule to determine the CPU schedule for each node specified by the input. The algorithm for scheduling the network communication medium is below: - Initialize the current time to lcm (T 1, T 2,, T n ). - Repeat while current time > 0: o Pick the active communication, C, whose sending task has the smallest slack. o If C is guarded Schedule C as well as all of its alternate choices (specified by the guards) for the current timeslot o Else C is not guarded Schedule C for the current timeslot o Decrement current time by one. o Update active tasks based on what was scheduled. A visualization of the network schedule for the example given above is shown below: Our scheduler also outputs a textual representation of the schedule: 3: g2 3: c4 3: c3 4: g1 4: c2 4: c1 8: g2

6 8: c4 8: c3 9: g1 9: c2 9: c1 13: g2 13: c4 13: c3 14: g1 14: c2 14: c1 18: g2 18: c4 18: c3 19: g1 19: c2 19: c1 The schedule above shows which communication is scheduled for each timeslot. The communications are also labeled with guards if there is a guard that chooses between them. Note that guards do not actually occupy a timeslot. For example, at time three if the function specified in guard two returns true then communication one will be run on the network otherwise communication two will be run. After the schedule for the network communication medium is determined, the algorithm schedules computation time on each nodes CPU. This is done using an earliest deadline first algorithm where the deadlines are the transmission time assigned to each task by the network schedule. The algorithm is as follows: - For each node (curnode) o curslot = 0; nextslot = 0; o While there are still more deadlines to check, get the next deadline (for task T) for node curnode and assign the value to nextslot. Schedule T for the time max(curslot, T.previous_deadline). If (curslot + T.computation_time > T.deadline) then return unscheduable curslot = curslot + T.computation_time

7 Our network code compiler translates the generated schedule into network code which can be run on RTLinux. We will now describe the instruction set: Future (dl, jmp) : schedules the program to wake up in dl time units and begin execution program counter plus jmp. Halt() : halts execution until a trigger enables it again. If (g, jmp) : implements a conditional jump. If the guard g evaluates to true the execution will continue at program counter plus jmp. Otherwise, the program counter is increased by one. Create (msgid, loc) : creates a message with the specified ID in memory location loc. Destroy (msgid) : destroys the specified message. Send (ch, msgid, reltime) : sends message msgid on channel ch. reltime specified the message s lifetime. Receive (ch, loc) : receives a message on channel ch into location loc. For example, consider the following input: 1, 1, 10, 1, 1 2, 2, 10, 1, > 2.1 This input generates the schedule shown below: And the resulting network code is: Program for Node 1 /*0*/ future( 9, 2 ), /*1*/ halt(), /*2*/ nop(), /*3*/ create( 0, 1 ), /*4*/ send( 1, 0, 1 ),

8 /*5*/ destroy( 0 ), /*6*/ halt(), Program for Node 2 /*0*/ future( 10, 2 ), /*1*/ halt(), /*2*/ nop(), /*3*/ receive( 1, 1 ), /*4*/ halt(), The program for node one waits until time nine and then sends a message, and the program for node two waits until time ten and then receives this message. We implemented one optimization which prevents generation of duplicate code around guards. Our schedule is stored in a graph structure and the network code is generated recursively. Thus, it is possible to get duplicate code around guards, for example if there are two paths to the same node then the code for that node would be generated twice. In some cases, such as program checkers, this may be an ideal behavior because there are no backwards jumps. However, it also generates a lot of excess code, so we implemented this optimization by coloring nodes after we generated code for them and then jumping to the previously generated code in the event that a colored node was reached. We also implemented a visualization tool (images from which are shown above) which takes as input the graph structure representing a schedule. This is useful to test schedules and quickly see the result on a timeline. Conclusion Our project began with an analysis of existing specification languages. Once we realized that existing languages were unnecessarily complex for our purposes, we developed our own specification language. We created a network scheduling algorithm which is unique in that it allows choices on the network and allows for stateful real-time communication. The generated schedules are compiled into network code using our

9 network code compiler. Also, our visualization tool translates the generated schedules into a visual representation. There are numerous extensions to this project. We planned to have testing on RTLinux complete by April 30 th (see proposal two), and we are currently in the process of finishing this. Another extension is to translate the schedules into VERSA input for schedule verification. References 1. Fischmeister, Sokolsky, Lee. Network-Code Machine: Programmable Real- Time Communication Schedules. Currently unpublished. 2. König, Gregor A. Using Interpreters for Scheduling Network Communication in Distributed Real-Time Systems Lee, Insup and Fischmeister, Sebastian. Senior Design Project Proposal: Stateful Real-Time Communication Schedules. l%20schedules.pdf 4. Society of Automotive Engineers. The SAE Architecture Analysis & Design Language (AADL) Standard The University of Pennsylvania, Real-Time Systems Group. VERSA: Verification Execution and Rewrite System for ACSR.

Network-Code Machine: Programmable Real- Time Communication Schedules

University of Pennsylvania ScholarlyCommons Departmental Papers (CIS) Department of Computer & Information Science April 2006 Network-Code Machine: Programmable Real- Time Communication Schedules Sebastian