Petri Net Models for Single Processor Real-Time Scheduling TIK-Report No. 61 November 1998 Martin Naedele Abstract
Petri nets are increasingly used for the evaluation and analysis of real-time systems. Petri nets are a powerful speci cation language for real-time and embedded systems, as they allow to model the computational parts of the system, the target hardware, and the system environment within the same executable and analyzable model. However, up to now most approaches that use Petri nets to specify realtime systems are only concerned with a high-level description of the system functionality and largely ignore timing aspects, such as scheduling, which are particularly important for real-time systems. This report suggests a novel approach to the modeling of real-time systems with Petri nets which provides a clear separation between the functional task model, the timing information, and the scheduler subnet. For the scheduler subnet, a library of Petri net models of standard scheduling algorithms has been developed, based on a general technique to express preemption with Petri nets.
ETH Zurich, Computer Engineering and Networks Laboratory, CH-8092 Zurich, email:
[email protected]
1
Contents
1 2 3 4
Introduction Problem Statement Previous work Petri Nets
4.1 Basic Formalism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Notion of Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5 Generic Real-Time System Model 6 Representation of Tasks
6.1 Task Attributes . . . . . . . . . . . . . . . . 6.1.1 Functional Attributes . . . . . . . . 6.1.2 Temporal Attributes . . . . . . . . . 6.1.3 Resource Access Attributes . . . . . 6.1.4 Task Descriptor Token Type . . . . 6.2 Task Structure . . . . . . . . . . . . . . . . 6.2.1 Task Dependencies . . . . . . . . . . 6.2.2 Application Speci c Transition Code 6.2.3 Tasks with Shared Resources . . . . 6.2.4 Nonlinear Control Flow . . . . . . . 6.3 Task invocation dynamics . . . . . . . . . . 6.4 Examples . . . . . . . . . . . . . . . . . . . 6.4.1 Synchronous Data ow . . . . . . . . 6.4.2 Mine Drainage System . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
7.1 Nonpreemptive FCFS Scheduling . . . . . . . . . . . 7.2 Preemptive Fixed-Priority Scheduling . . . . . . . . 7.2.1 Basic Model . . . . . . . . . . . . . . . . . . . 7.2.2 Realistic Models . . . . . . . . . . . . . . . . Integrated Interrupt Driven Scheduling . . . Non-Integrated Interrupt Driven Scheduling . Timer Driven Scheduling . . . . . . . . . . . 7.2.3 Resources Access Protocols . . . . . . . . . . Priority Inheritance Protocol PIP . . . . . . . Priority Ceiling Protocol PCP . . . . . . . . Stack Resource Policy SRP . . . . . . . . . . 7.2.4 Aperiodic Servers . . . . . . . . . . . . . . . . Background Service . . . . . . . . . . . . . . Polling Server . . . . . . . . . . . . . . . . . . Deferrable Server . . . . . . . . . . . . . . . . Priority Exchange Server . . . . . . . . . . . 7.3 Preemptive EDF Scheduling . . . . . . . . . . . . . . 7.4 Other Scheduling Policies . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
7 Schedulers and Processors
8 Conclusion References
2
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
3 4 6 7 7 9
9 11
11 11 12 13 14 15 15 16 16 17 17 18 18 19
23
23 24 24 25 25 25 26 29 29 29 29 36 36 36 36 38 40 40
41 42
1 Introduction Petri nets [32, 34, 38] are increasingly used for the evaluation and analysis of real-time systems [9, 5, 4, 8, 35, 16, 17, 33]. Real-time systems are systems for which both functional correctness and timing correctness need to be guaranteed in order to achieve the intended purpose. Petri nets are a powerful speci cation language for real-time and embedded systems, as they allow to create an integrated model of the computational parts of the system, the target hardware and the system environment (sensors, actors, physical phenomena). This model then can be executed for debugging and performance evaluation and possibly also mechanically analyzed for certain properties. However, up to now most approaches that use Petri nets to specify real-time systems are only concerned with a high-level description of the system functionality and largely ignore timing aspects, such as scheduling [28, 3, 47], which are particularly relevant and important for real-time systems. A Petri net model can very well be used for scheduling simulation and has considerable advantages in exibility and extendibility over conventional scheduling simulators (e. g. [48]), which only allow more or less prede ned task precedence structures. Even though there exist a lot of theoretical results about schedulability in single processor real-time systems [47], scheduling simulation is still necessary [18, 22, 8] when non-ideal behavior of system components (e. g. overhead) or overload situations have to be taken into account, or when the task system interacts with an environment for which no theoretical results exist, but which can very well be modeled as a Petri net. Petri net models of real-time systems serve two main audiences: Engineers developing real-time systems can use these models for the rapid prototyping of systems and rapid evaluation of suitable scheduling strategies. Real-time researchers can use these models to explore and evaluate new algorithms. Algorithms that are documented and made available as Petri nets can easily be understood by other researchers and practitioners [4] and can be evaluated by simulation using the variety of Petri net tools available today. This report treats three issues concerning the modeling of real-time systems with Petri nets: A modeling methodology is presented, which allows to extend a subnet specifying the functionality of a system with scheduler/processor net building blocks which take care of the timing/scheduling aspects. A comprehensive library of Petri net implementations of standard scheduling and resource access algorithms is presented. All scheduler models have a common interface to the sub-model specifying the other parts of the system, so they can simply be interchanged. The schedulers presented in this report are meant to cover most standard scheduling situations for single-processor systems. All have been implemented and tested using the CodeSign1 tool, but can also be used with any other Petri net tool that o ers the formalism features described in section 4. Further models can easily be developed within the suggested framework. An appropriate technique to model preemptive scheduling in the general case, which is needed for the implementation of standard scheduling algorithms [28, 47, 2], using high-level time Petri nets is presented. 1
www.tik.ee.ethz.ch/naedele/moses/download.html
3
2 Problem Statement Up to now, two fundamentally di erent ways to model task execution systems with Petri nets have been used (see section 3): task1
task2 allTasks
Delay: 3
Delay:2
schedule
procIdle proc
executingTask
Delay: 3
execute Delay: exponential
Delay:2
completedTasks A
B
task1 structure
task2 timing
structure
addTiming
timing
addTiming
start
start
inProcess
inProcess
scheduler
requests schedule
procIdle executingTask
identifyAck end
identifyAck execute
end
Delay: f(executingTask) completedTasks
C
Figure 1: A system with two tasks and one processor modeled with task-centered execution (A), resource-centered execution (B), and delegated execution (C). For the delegated execution model colored tokens are used in the scheduler subnet as well as in the addTiming and identifyAck transitions, which augment the execution request with timing attributes and identify for which task execution has been acknowledged, respectively. Details of the model inscription have been left out and will be treated in detail in later sections. 1. The control ow structure of the task is mapped to a Petri net and a token moving through the resulting net indicates, which task segment is being executed at any moment in time (see Fig. 1(A)). Processors and other shared resources are represented as tokens, or not considered at all. Transitions stand for the basic blocks of the task program and may be annotated with a delay which expresses the execution time needed for this basic block. This style will be called task-centered execution in the following. Task execution is usually nonpreemptive and scheduling is random. In this model, the task structure is well represented while the speci c properties of processors and other resources are of minor importance. 2. The structure of the processor or computer system is mapped to a Petri net and the tasks are represented as black tokens moving through the processor 4
structure (see Fig. 1(B)). Each task token passes through the same delayannotated transition in the processor subnet and the delay is independent of the actual task. With this technique, processor and communication structures are well represented while individual tasks play a minor role. It is mostly used for performance evaluation. Preemption is modeled only for very special cases and usually requires replication of the processor subnet. This modeling style will be called resource-centered execution in the following. Both of these modeling styles are not adequate for real-time task systems, which have usually only a limited number of tasks with distinct execution behavior and for which the timing correctness is as important as the functional correctness. Timing correctness in real-time systems depends largely on the actual processor structure and the scheduling policy, which often involves task preemption [28, 47, 2]. Preemption can not easily be modeled in a fully general way in either the task-centered execution or the resource-centered execution model alone. For the task-centered execution model, this is caused by the decentralized model, and for the resource-centered execution model, by the fact that the tasks can only be unstructured and that the assumption of uniform, indistinguishable tasks is not valid for most real time task sets. In particular, it is not possible to resume the execution of a preempted task, if the task token is not identi able and can not carry values. As solution, a speci c model structure is proposed, which combines aspects of both task-centered execution and resource-centered execution while using high-level Petri nets (see Fig. 1(C)). This style will be called delegated execution in the following. As in the task-centered execution model, the task body is usually explicitly modeled as a Petri net, however, without any delay-annotated transitions. Functional and timing speci cations are clearly separated in two parts of the task sub-model. As in the resource-centered execution model, another explicit sub-net exists for the scheduler/processor combination. The basic idea is that for each task segment in the task body model that needs to be executed, an execution request is sent to the scheduler. The scheduler delays it according to its strategy and the available processing capacity, and sends a completion acknowledgement back to the task body. Because all time progress is concentrated in the scheduler, it has complete knowledge about the execution progress of each task, thus a general preemption mechanisms can be implemented there. The proposed model structure allows to construct a library of application independent, reusable real-time scheduler models. The remainder of this paper discusses various aspects of the proposed approach to real-time system modeling with Petri nets: The Petri net formalism required to support real-time task modeling and preemptive scheduling is presented in section 4. A generic model structure for real-time systems and a corresponding modeling process are described in section 5. 5
Speci c issues with respect to task representation, such as the separation of task functionality and task timing information, as well as provisions for the use of standard resource allocation policies are treated with guidelines and examples in section 6. Petri net models of standard scheduling and resource allocation algorithms together with examples of their use for scheduling simulation of real-time systems are presented in the subsections of section 7. These models also demonstrate how preemption is implemented.
3 Previous work Previous work relevant to the problem of real-time task modeling with Petri nets has been done in research on using Petri nets for real-time system analysis [4, 5, 35, 9, 8, 16, 17, 33] as well as research on the use of stochastic Petri nets for performance evaluation [30, 12, 14, 15, 52]. In [4, 5] the Protob methodology and tool (now Artifex) are introduced as analysis and design environment for the development of real-time systems. While the ability to represent and even execute/simulate both the hardware and the software of an embedded system at the same time with Petri nets, is well suited for embedded system modeling at the functional level, similar to SA/RT [19]. In [35], basic Petri net structures for inter-task communication are presented in order to integrate Petri nets with the ADARTS and CODARTS software design methods for real-time systems. In these papers, task-centered execution without resource restrictions is used and timing or scheduling problems are not treated. In [33], Petri nets are used to represent state machines in the context of the DART object-oriented real-time system modeling methodology. Though it is suggested to model a scheduler as part of the net, no general rules for the construction of schedulers have been given and issues such as the allocation of shared resources are not treated. The model uses task-centered execution (the delays are located in the state transitions), and there is no provision for preemption. In [9] the ideas of [4] are extended with respect to actual scheduling analysis. In this paper, a distinction is made between two so-called execution policies: With the standard behavior policy, only transitions representing physical phenomena are annotated with a delay, following timed Petri net semantics[36], whereas transitions representing execution of program code do not compete for computational resources. The restricted behavior on the other hand, takes into account, that in a single-processor system only one program transition can be executed at a time. The objective of the approach in [9] is to obtain an optimal static schedule, based on the algorithm of [51], and to calculate maximum allowed arrival frequencies of external events. As the paper is only concerned with static schedules, preemption is only mentioned in the form of self-preemption, achieved by expanding a program transition into a chain of nonpreemptable transitions. Tokens represent data items to be exchanged between processes and thus implicitly precedence constraints. No nondeterminism is allowed in the control ow, and thus the expressiveness of Petri nets is not fully used. In [8], it is stated that in order to be able to model real-world systems, a Petri net based formalism must support some non-determinism. A restricted timed Petri net formalism is developed from time-annotated marked graphs. Transitions may be re ned by nondeterministic subnets. The formalism is applied to the calculation of 6
system performance gures, though on a very high level of abstraction. This work does not look at lower level responsiveness, deadlines, or scheduling issues. In [16] the need for expressive speci cation languages for time-critical systems is motivated and a high-level Petri net formalism with a very comprehensive time concept is suggested. An analysis method for this high-level Petri net formalism is presented in [17]. Some of the examples are drawn from the real-time scheduling domain. They use task-centered execution and non-preemptive 'random scheduling'. While the use of stochastic Petri nets in the strict sense is generally not appropriate for the modeling of real-time systems where statistical statements about the system behavior are usually not sucient, [30] and [52] give several examples of models with task-centered execution and resource-centered execution. In [30], it is mentioned that preemption can be modeled by removing a token waiting in front of a timed transition before this transition res. However, as the remaining delay until the transition would have red is in this Petri net formalism stored inside the transition, not inside the token, preemptive scheduling with resumption of execution requires subnet replication for identi able tasks, which does not scale well. In [52], tasks preempt themselves during I/O operations. In the area of performance analysis of parallel programs, several approaches to model composition have been described: Ferscha [14, 15] points out that most models of computing systems are either resource oriented or program centered. He suggests a method where resource nets and program nets are constructed separately and fused in variable con gurations to explore di erent resource mapping options. The resulting model is still basically a task-centered execution model, but resource tokens carry information about the performance they can o er for di erent operations, so that actual delay of a task transition depends on the value of the resource token. Donatelli and Franceschinis [12] suggest to model programs in form of a multilayered structure. In the bottom layer there exists a Petri net for each resource (hardware), with di erent paths starting from the 'idle' marking, corresponding to the supported operations. The execution progress is determined by timed transitions in this resource net, whereas all transitions in the upper layers are untimed. On top of the resource layer, multiple application layers (software) of increasing level of abstraction provide macros for the the operations of the layer below. The di erent layers are connected implicitly by transition superposition.
4 Petri Nets
4.1 Basic Formalism
This report assumes that the reader is familiar with Petri nets in general. Introductory material about Petri nets can be found e.g. in [32, 34, 38, 39, 53]. The Petri net formalism used is a so-called high-level Petri net similar to the ER-nets of [16], that is, tokens can carry arbitrary data values, and expressions can be evaluated using the data values carried by tokens. Expressions can contain the usual mathematical operations and control ow statements, as well as make use of user-de ned functions. Data types for tokens are integer, real, bool, string, records, and lists. A further type is nil, which denotes a so-called 'black' token. The elds of a record are accessed using the syntax recordname.field. 7
Lists have the following methods: isEmpty(), first(), addLast(element: any type), addFirst(element: any type), removeFirst(), size(), and removeAt(index: element), with indices starting at '1'. Two more methods are de ned for lists of records: insertOrdered(element: record, field:string) inserts an element in
the list according to the value of the record eld speci ed by the ' eld' argument. In the case of the ordering key being an integer eld, the elements are ordered with increasing values and a new value is inserted ahead of the rst element with the same value in the list. find(element: record, field: string) returns the integer index value of the rst list entry where the speci ed eld is identical to the 'element' argument, or '-1', if no match is found. All methods for which this is relevant (add, remove, insert) do not change the original variable but return a modi ed copy. No particular token ordering on places is assumed for the scheduler models. When using certain storage constructs like FIFO-queues in the modeled application (task body subnet), these either need to be provided by the underlying Petri net or must be implemented explicitly. A: record{field1: integer, field2: bool; field3: real}
anInput
anOutput
aPlace
v aTransition Guard: v.field1>5 AND v.field2 u Action: u:=v u.field1:=v.field1+5 u.field2:=v.field1 