Petri Nets Modeling for the Schedulability Analysis of Industrial Real
Time Systems
Alessandro Fantechi and Stefano Pepi
DINFO, University of Florence, Via S. Marta 3, Firenze, Italy
Petri Nets, Timed Petri Nets, Coloured Petri Nets, Real Time Systems, Scheduling Algorithm, Modeling,
Formal Verification, Railway Signalling.
In the experience of a railway signaling manufacturer, schedulability analysis takes an important portion of the
time dedicated to configure a complex, generic, real-time application into a specifically customized signalling
embedded application. We report on an approach aimed at substituting possibly unreliable and costly empirical
measures with rigorous analysis. The analysis is done resorting to modeling the scheduling algorithms by Petri
Nets. We have compared two types of Petri Nets: Timed Petri Nets (TPN) and Coloured Petri Nets (CPN),
supported by open source tools, respectively TINA and CPN Tools 4.0 concluding that the latter are more
suited for the dealt problem.
Real-Time Systems (RTS) are those computer-based
systems where correct operation does not only depend
on the correctness of the results obtained, but also on
the time at which the results are produced (Stankovic,
The interest for real-time systems is motivated by
many applications that require that computations sat-
isfy given time constraints, in domains such as auto-
motive, avionics, communications, railway signalling
The most important property of a RTS is pre-
dictability. Predictability is the ability to determine
in advance if the computation will be completed
within the time constraints required. Predictability
depends on several factors, ranging from the archi-
tectural characteristics of the physical machine, to the
mechanisms of the core, up to the programming lan-
guage. Predictability can be measured as the percent-
age of processes for which the constrains are guaran-
In this article we report the experience made in
collaboration with our industrial partner, a railway
signalling manufacturing company, in the implemen-
tation of a generic real-time platform based on a pro-
prietary microkernel Real Time Operating System;
in particular we present a method for schedulability
With the recent expansion of markets to Asia and
Africa, the company has experienced a growing need
for a versatile system that can be configurable for each
different application. The transition from a traditional
”main loop”-based system to a general purpose plat-
form has allowed low-cost configuration, simply by
changing the application inside and the hardware to
interact with. With the same Hw/Sw platform both
ground and on-board systems can be built, either for
urban (like metro) or main line applications, meeting
the signaling regulations of different countries.
Experience has however shown that guarantee-
ing predictability for the different customizations of
the platform takes a considerable portion of the cus-
tomization effort, if based only on testing every time
the newly customized software on the platform.
We have therefore considered the possibility of
building a generic model of the scheduling algorithms
employed in the platform that is going to be instan-
tiated on the temporal constraints and tasks num-
bers of the different specific applications (that is, cus-
tomizations), in order to support the validation of pre-
dictability by means of proper model simulation tools.
Basing on the wide literature about modeling real-
time systems with Petri Nets (see, for example, (Bar-
reto et al., 2004; Berthomieu and Diaz, 1991; Felder
et al., 1994; Grolleau and Choquet-Geniet, 2002)) and
on the availability of related tools, we have chosen to
experiment two Petri Nets dialects for the modeling of
the scheduling algorithms, in order to predict schedu-
lability of the set of tasks governing a new specific ap-
Fantechi, A. and Pepi, S.
Petri Nets Modeling for the Schedulability Analysis of Industrial Real Time Systems.
DOI: 10.5220/0005841700050013
In Proceedings of the International Workshop on domAin specific Model-based AppRoaches to vErificaTion and validaTiOn (AMARETTO 2016), pages 5-13
ISBN: 978-989-758-166-3
2016 by SCITEPRESS Science and Technology Publications, Lda. All rights reserved
plication. Both Timed Petri Nets (TPN) and Coloured
Petri Nets (CPN) have been evaluated for this pur-
pose, together with their support tools, favouring at
the end the adoption of Coloured Petri Nets.
Due to the limited time available to conduct the
experiments, in order to satisfy stringent temporal re-
quirements from our industrial partner, we have cho-
sen not to investigate other temporal modeling for-
malisms, such as timed automata (Alur, 1992). The
results obtained by these experiments were however
judged sufficiently satisfactory to consider the adop-
tion of the technique inside the development process
of our industrial partner.
A real-time process is characterized by a fixed time
limit, which is called deadline. A result produced af-
ter its deadline is not only late, but can be harmful to
the environment in which the system operates. De-
pending on the consequences of a missed deadline,
real-time processes are divided into two types:
Soft Real-time: if producing the results after its
deadline has still some utility for the system, al-
though causing a performance degradation, that
is, the violation of the deadline does not affect the
proper functioning of the system;
Hard Real-time: if producing the results after its
deadline may cause catastrophic consequences on
the system under control.
To meet this requirement, scheduling plays an im-
portant role. Depending on the assumption done on
the processes and on the type of hardware architec-
ture that supports the application, the scheduling al-
gorithms for real-time systems can be classified ac-
cording to the following orthogonal characteristics:
Uniprocessor vs. Multiprocessor
Preemptive vs. No preemptive
Static vs. Dynamic
Pre-runtime vs. Runtime
Best-Effort vs. Guaranteed
For what concerns the fourth characteristic, in pre-
runtime scheduling all decisions are taken before the
process activation on the basis of information known
a priori. The schedule is stored in a table which will
be integrated into a run-time kernel. The kernel has
one component called dispatcher which takes tasks
from the table and loads them onto the processing ele-
ments, according to specified timing constraints. The
Runtime category represents instead those algorithms
in which the scheduling decisions are made at runtime
on all current active processes. The ordering of tasks
is then recalculated for each new activation.
The choice between pre-runtime or run-time schedul-
ing has been done in our case in favour of the former
thanks to the better possibility to demonstrate pre-
dictability, which is a must in a safety-critical environ-
ment. That is, with pre-runtime scheduling it is possi-
ble to exhibit to an assessor the analyses conducted
on the considered set of tasks in order to establish
that tasks do not miss their deadline, while with run-
time scheduling evidences provided simply by run-
ning tests can be not convincing about their coverage
of all possible cases.
Indeed, the present paper aims to show a method to
strengthen the analysis on pre-runtime scheduling to
a high level of confidence. In particular, we present
a method that can be used to verify the pre-runtime
schedulability of a task set that contains only periodic
tasks with time and priority constrains.
The motivations for this approach come also from
the high variability of installations of the same sig-
nalling system at different locations or controlling
different stations or lines. Indeed, in railway sig-
nalling systems, a distinction is often done between
generic applications and specific applications (see,
e.g., the CENELEC EN50128 (Cenelec, 1996) guide-
lines): generic software is software which can be used
for a variety of installations purely by the provision
of application-specific data and/or algorithms. A spe-
cific application is defined as a generic application
plus configuration data, or plus specific algorithms,
that instantiate the generic application for a specific
While the platform is part of a generic application,
and hence it is validated once for all, for each specific
application the satisfaction of real-time constraints
must be verified from scratch.
Indeed, quite often in everyday work it is necessary
to revise the schedule of some systems, and all this
is routinely done in an empirical way. It is clear that
each application has a different way to interact with
the platform and especially with its resources, such as,
for example, input/output drivers for different hard-
ware. It is for this reason that the schedule of real-
time tasks should be revised at any new specific ap-
The adopted empirical approach includes actions to
be taken when configuring the platform for a new spe-
cific application, such as: get a new schedule configu-
ration offline and test it on the target. It rarely happens
AMARETTO 2016 - International Workshop on domAin specific Model-based AppRoaches to vErificaTion and validaTiOn
that the first test is successful.
The estimated effort required for the identification
and testing of a new configuration of scheduling can
be summarized with the following parameters:
Offline Identification Time: time needed in or-
der to design the new schedule, it is usually about
30 minutes.
Flashing Time: the time needed to load the
scheduling on the target, 15 minutes.
Startup Time: start-up time of the platform, 1.5
Running Time: time during which the system
must run without exhibiting timing problems, 30
minutes / 1 hour.
Attempts: average number of attempts to get the
scheduling, 3.
Summing all the times shown above we get that for
each test scheduling, the whole process easily reaches
8 hours, which means an entire working day. This
process can be automated by a tool that, given a task
set and a number of constraints, is able to produce a
feasible scheduling. This would mean a huge saving
in terms of man hours used to refine the scheduling.
Moreover, an empirical evaluation of schedulability
of a given dataset does not guarantee that the dead-
lines are met in any case, putting in danger the overall
safety of the system. Using a rigorous approach to
the analysis of the schedulability will improve hence
the conformance, of a specific application, to safety
In our system the application is decomposed into a set
of tasks τ
: i = 1, ...n and for this paper we only con-
sider periodic tasks, and we assume that non-periodic
tasks are carried out by a periodic server, or processed
in the background (Buttazzo, 2011). The temporal
model mostly used in real-time scheduling theory is
an extension of the model of Liu and Layland (Liu
and Layland, 1973) where each task τ
is character-
ized by the following parameters:
: first release time of τ
: run time of τ
, which is its worst case execu-
tion time (WCET);
: relative deadline of τ
, the mamimum time
elapsed between the release of an instance of τ
and its completion;
: release period of τ
In the following we use as a running example the case
of a real signalling application, an interlocking sys-
tem. An interlocking system is the safety-critical sys-
tem that controls the movement of trains in a station
and between adjacent stations. The interlocking mon-
itors the status of the objects in the railway yard (e.g.,
points, switches, track circuits) and allows or denies
the routing of trains in accordance with the railway
safety and operational regulations that are generic for
the region or country where the interlocking is lo-
cated. The instantiation of these rules on a station
topology is stored in the part of the system named
control table that is specific for the station where the
system resides. We refer to (Fantechi, 2013) for a
review on how interlocking functionality is formally
modeled. In this context, we are interested to focus
on the characteristics of the task set of this applica-
tion, consisting of 7 threads which have the following
is in charge of operating on the Ethernet chan-
is one of the most important thread and it is in
charge of the safety of the system;
implements a protocol stack for the receipt and
transmission of messages;
is in charge of copying the value received in
the input of the Business Logic and preparing the
output for the trasmission.
is the application thread that contains the logic
of the system.
is a diagnostic thread;
is a USB driver used for logging data in a key.
The scheduler operates by dividing processor time
into epochs. Within each epoch, every task can exe-
cute up to its time slice. In this case, the scheduler has
two epochs of 100 milliseconds and the taskset have
the following constraints:
The total time of scheduling cycle is 200 millisec-
Each epoch needs to last exactly 100 milliseconds.
The first execution of T
in the first and second
epoch must terminate within 95 milliseconds.
The second execution of T
in the first and second
epoch must terminate within 95 milliseconds.
The second execution of T
in the first and second
epoch must execute at least 65 milliseconds after
the first one.
in the first epoch must terminate within 90 mil-
liseconds and in the second epoch in 140 millisec-
Petri Nets Modeling for the Schedulability Analysis of Industrial Real Time Systems
The sum of times for T
must be of at least 90
The taskset used in our example is defined in the
Tables 1 and 2 with the relative scheduling order and
Table 1: TaskSet in first epoch.
Epoch1 R
0 6 6
6 5 11
11 16 27
27 5 32
32 4 36
36 24 60
60 40 100
Table 2: TaskSet in second epoch.
Epoch2 R
0 6 6
6 5 11
11 16 27
27 5 32
32 4 36
36 40 76
76 8 84
84 10 94
94 6 100
These assumptions are the basis on which a model
of the scheduling algorithm can be built. We resorted
to the use of Petri Nets, that result quite intuitive in the
modeling of scheduling algorithms (Berthomieu and
Diaz, 1991; Felder et al., 1994; Leveson and Stolzy,
1987; Tsai et al., 1995). In order to represent time,
we have investigated the use of bothTimed Petri Nets
(TPN) (Ramchandani, 1974) and Coloured Petri Nets
(CPN) (Jensen, 1987). In the following part of the
article we illustrate the two kinds of models by means
of the running example, giving a comparison between
the two modeling approaches.
A Petri Net (Petri, 1962; Murata, 1989; Peterson,
1981) is a mathematical representation of a dis-
tributed discrete system. As a modeling language, it
describes the structure of a distributed system as a bi-
partite graph with annotations. A Petri Net consists
of places, transitions and directed arcs. There may be
arcs between places and transitions but not between
places and places or transitions and transitions.
The places can hold a certain number of tokens and
the distribution of tokens on all the places of the net-
work it’s named marking. Transitions act on input
tokens according to a rule, that is named firing rule.
A transition is enabled if you can fire it, that is, if
there are tokens in every input place. When a tran-
sition fires, it consumes tokens from its input places
and places a token in each of its output places.
Figure 1: Representation of an ordinary Petri Net.
In Figure 1 is an example of an ordinary Petri Net.
The execution of Petri Nets is not deterministic, that
is, if there are more transitions enabled at the same
time any of them can fire. Since taking a transition is
not predictable in advance, Petri Nets are well suited
for modeling the concurrent behavior of distributed
Formally we can define a Petri Net as a tuple PN =
(P, T, F,W, M
) where:
P is a finite set of places;
T is a finite set of transition;
F (PxT ) (T xP) is a set of arches;
W : F N represents the weight of the flow rela-
tion F.
: P N is the initial marking vector, which
represents the initial state of system.
P T =
0 and P T 6=
4.1 TPN
A Timed Petri Net is a Petri Net extended with time.
In Timed Petri Nets, the transitions fire in ”real-time”,
i.e., there is a (deterministic or random) firing time
associated with each transition, the tokens are re-
moved from input places at the beginning of firing,
and are deposited into output places when the firing
terminates. Formally we can define a Timed Petri
Net (Ramchandani, 1974) as a tuple T PN = (PN, I)
AMARETTO 2016 - International Workshop on domAin specific Model-based AppRoaches to vErificaTion and validaTiOn
Figure 2: Timed Petri Net model for a fixed scheduler.
PN is a standard Petri Net;
I : T N × N is a function that maps each transi-
tion to a bounded static interval
P T =
0 and P T 6=
In Figure 2 is reported the model generated with
the tool TINA (Berthomieu and Vernadat, 2006) for a
fixed scheduler (Grolleau and Choquet-Geniet, 2002;
Barreto et al., 2004; Aalst, 1996). As we can see the
representation with TPN is a little bit chaotic and rep-
resenting larger sets of tasks could be very difficult.
Looking at the model we can underline some diagram
parts which are used for the verification of constraints
(Tsai et al., 1995):
Check for the Total Time
The network used to control the time of each
epoch consists of two transitions and respectively
five and three places. Taking into consideration
the network a) in Figure 3, the transition t27
counts the total time available for the execution
in the epoch. When the time available ends, the
token content in place p34 is moved in place p35
and inhibits the passage of the token, from the last
thread running, in places p36, p62 and p30.
If this happens it means that the execution time in
this epoch is not the one expected. If, however,
the performance ends too soon the transition t28
will not be inhibited by p35 place and pass tokens
in places p36, p62 and p30, decreeing the passage
of the positive control and the start of the second
Figure 3: Diagram of epoch control block.
Check Constrains on T
The network in Figure 4 models the various con-
trols on the execution times for T
. For example
the last block checks that between the first execu-
tion of T
in the first epoch and the second execu-
tion in the second epoch, at least 65 milliseconds
have expired. The transition t25 is enabled when
the task is running and, if the task completes be-
fore the time set in the transition t23, scheduling
can continue. Otherwise, if the task does not com-
plete within the specified time, the inhibitor arc
Petri Nets Modeling for the Schedulability Analysis of Industrial Real Time Systems
that starts from p65 does not allow the scheduler
to continue.
Figure 4: Diagram of block for the verification of con-
straints on task T
Checking the Scheduled Time between Two
The network in Figure 5 monitors the execution
time of a task between the two epochs. The transi-
tions t14 and t17 are enabled when the task is run
in both the first and the second period. This starts
the timer of transition t2. If the task completes
before the time set in the transition, the schedul-
ing can continue. Otherwise, if the task does not
complete within the specified time, the inhibitor
arc that starts from p19 does not allow the sched-
uler to continue.
With this model and TINA tool we are able to under-
stand if the hypothesized schedule is correct, and in
fact if all checks are satisfied we can found a token
in p54, otherwise the tool stops the simulation on the
place that generated the error.
Figure 5: Check block for the scheduled time between two
epoch for task T
4.2 CPN
An ordinary PN has no types and no modules, only
one kind of tokens and the net is flat. With CPNs it is
possible, instead, to use data types and complex data
manipulation. In fact each token has attached a data
value called the token colour, which defines the range
of values that the attributes can assume and the oper-
ations applicable in the same way of a variable type
in any programming language. The types can be ba-
sic types or structured types, the latter defined by the
user. The token colours can be investigated and mod-
ified by the occurring transitions.
With CPNs it is possible to build a hierarchical de-
scription and for this reason a large model can be ob-
tained by combining a set of submodels.
In Figure 6 the model of the running example gener-
ated with CPN tools 4.0 (Jensen et al., 2007) is re-
ported. As we can see the representation with CPN
is more concise than the one seen with TPN, for ex-
ample in one place we can represent all the tasks of
the set. The tasks are represented as a list of objects
and each one is represented by a token that have two
attributes: a string that contains the name and one in-
teger that represent the WCET C
of the task.
The verification of the constraints on the exe-
cution time of the thread are realized through some
functions listed on the transitions. On the first and
second transitions named ”Put”, for example, we can
find respectively the functions called [verifyTh3 ()]
and [verify2Th3 ()]. These two functions implement
the constraint that between the two executions of T
cannot elapse less than 65 milliseconds. The func-
tions are defined as follows:
fun verifyTh3((n,t)::l) =
if n="Thread3" andalso
intTime() > 65
then false else true
fun verify2Th3(((n,t)::l)) =
if n="Thread3" andalso
(intTime()-100) > 65
then false else true
The function checks if the token in input to the
transition represents the task 3, and verifies that the
current simulation time (obtained with the function
intTime()) is less than 65 units. If the constraint is not
respected, the transition is not enabled.
On the transition ”End” we can find a function named
[verifyTime()] that checks all the other constraints
(the function is similar to the one above) except that
the one on T
that is represented by function [veri-
fyTh5ctime()] placed as guard on the same transition.
The modeling of this last constraint, specific for task
, requires to save in a variable the timing at which
AMARETTO 2016 - International Workshop on domAin specific Model-based AppRoaches to vErificaTion and validaTiOn
Figure 6: Coloured Petri Net model for a fixed scheduler.
the token of the T
exits from the ”Run” place in the
first epoch. This has been achieved through the tran-
sition ”T” with the pattern input, output, action where
we take a variable in input (variable n) and by the ac-
tion (getTime() function) we generate an output (vari-
able ctime). This transition is enabled only for T
we can see from the guard on the arch. So the variable
that we have obtained could be used in the function:
fun verifyTh5 ((n, t), ctime)=
if n= "Thread5" andalso
(intTime () - ctime) >= 90
{then false else true}
Similarly to the modeling done with TPN, also the
simulation of the CPN model by means of the CPN
Tools 4.0 stops if one of the constraint is not satisfied,
so the user is able to understand where the problem is
4.3 Comparison between TPN and CPN
The experiments have allowed a comparison between
the two Petri Nets dialects, in particular enlightening
the following points:
The TPN model is difficult to read, and the addition
of further tasks would result in a huge increase of the
places and transitions number, making it more and
more unreadable. This increase is due to the fact that:
Any place can hold a single token and the execu-
tion of a thread must be reproduced a number of
times equal to the number of modeled processes;
indeed in TPNs it is not possible to express an at-
tribute that differentiates the identity of a token.
Time management for each thread is left to time
constraints on the transitions themselves.
It is not possible to create aggregate objects: a
FIFO queue, for example, can be realized only
through checks by inhibitors arcs with a num-
ber of places that depends on how many threads
should be modeled (the number of places to repre-
sent the queue is equal to n
where n is the number
of threads).
The CPNs instead can represent a queue using a single
place that contains a token of type list. Time manage-
ment is left to the token using an integer and a times-
tamp. This allows to represent a large number of tasks
by simply adding tokens to the initial marking, leav-
ing the structure of the model unaffected.
The time constraints can be grouped in auxiliary func-
tions, thus simplifying size and readability of the
model. In TPNs, instead, for each thread it is nec-
essary to model a constraint through places and tran-
With TINA and TPNs the control of time during sim-
ulation allows to easily understand the global state of
the system. The time is increased at any time unit
time. In CPNTools and CPNs if there are no transi-
tions enabled at the current time, the simulated time
count is increased in one step up to the time at which
Petri Nets Modeling for the Schedulability Analysis of Industrial Real Time Systems
at least one transition is activated.
CPNs have however resulted to be more advantageous
in terms of time spent in model design or in changes,
mainly for two reasons:
1. constraints can be simply modeled by a guard on
the transition, expressed by a function written in
pseudo code, which is easier to express;
2. to populate the model with new tasks it is not nec-
essary to draw new graphic elements but just add
an entry to the related place;
We have experienced that the time spent in CPN mod-
eling is at the end more than half that spent in TPN
We have applied the two modeling options sketched
above to different scheduling algorithms and differ-
ent sets of tasks as well. The quite straightforward
conclusion is that the CPN modeling is more advan-
tageous in terms of size and readability of the model,
and in terms of adaptability of the model to different
task sets.
It is indeed easier with CPN to instantiate the same
model, for the same scheduling algorithms, on a dif-
ferent set of tasks, and this is what is important in the
daily application of this modeling framework. Since
essentially only the characteristics of the taskset need
to be changed for a new, or modified, specific appli-
cation, the overall time to analyse a new taskset, sum-
ming up the time to produce a model of the sched-
ule of a new specific application, to run a simulation
and to analyse the simulation is about two hours with
a TPN modeling and about one hour with the CPN
modeling. Anyway, this time compares with the much
longer time (eight hours) needed by the empirical ap-
proach previously used, and therefore is convenient in
both cases.
Even if some rework is needed due to a negative re-
sponse of the simulation, the information returned by
the simulation helps understanding where the prob-
lem lies, indicating the solution to the problem. Usu-
ally one rework cycle is at most needed, so the overall
cost is anyway reduced.
For this reason we have not considered convenient
to investigate solutions based on counterexample gen-
erated by a model checker (Guillaume Gardey, 2005),
able to provide automatically the taskset parameters
satisfying the scheduling requirements.
The low cost of the simulation based solution has
an obvious positive impact on the costs of the process
of instantiating a generic application to a new specific
application for marketing a new product or variant.
This process is currently under experimentation in our
partner company, with the aim of introducing it in the
routine customization process. An help for this intro-
duction could come from providing tools to support
an easier instantiation of the generic models into spe-
cific ones, so that the use of CPN is transparent to the
final user who only sees the simulation results. This
objective requires also a facility to explain the reasons
of a negative response without showing the underly-
ing CPN model. This is considered as future work.
We wish to thank Marco Bartolozzi, Daniele
Marchetti and Luca Santi for their contribution to the
conducted modeling experiments.
van der Aalst, W. M. P. (1996). Petri Net based schedul-
ing. In Operations-Research-Spektrum vol.18 (219-
229). Springer-Verlag.
Alur, Rajeev and Dill, David (1992). The theory of timed
automata. In 17th Real-Time: Theory in Practice,
Lecture Notes in Computer Science vol.600 (45-73).
Barreto, R., Cavalcante, S., and Maciel, P. (2004). A
time Petri Net approach for finding preruntime sched-
ules in embedded hard real-time systems. In Dis-
tributed Computing Systems Workshops (846-851),
2004. Proceedings. IEEE.
Berthomieu, B. and Vernadat, F. (2006). Time Petri Nets
analysis with TINA. In Quantitative Evaluation of
Systems (123-124), 2006. IEEE.
Berthomieu, B., Diaz, M. (1991) Modeling and Verifica-
tion of Time dependent system using Time Petri Nets.
IEEE Transactions on Software Engineering, vol. 17 ,
no. 3 (259-273). IEEE.
Buttazzo, G. (2011). Hard Real-Time Computing System.
Springer, New York, 3rd edition.
Cenelec (1996). Cenelec en 50128. In Railway Appli-
cations - Communications, Signalling and Processing
Systems - Software for Railway Control and Protec-
tion Systems.
CPNTools (2015). <http://>.
Fantechi, A. (2013) Twenty-Five Years of Formal Meth-
ods and Railways: What Next? SEFM Workshops
2013, Lecture Notes in Computer Science vol.8368
(167-183), Springer.
Felder, M., Mandrioli, D., Morzenti, A. (1994) Prov-
ing Properties of Real-Time Systems through Logical
Specifications and Petri Net Models, IEEE Transac-
tions on Software Engineering, vol.20, no.2 (127-141)
AMARETTO 2016 - International Workshop on domAin specific Model-based AppRoaches to vErificaTion and validaTiOn
Grolleau, E., Choquet-Geniet, A. (2002). Off-line compu-
tation of real-time schedules using Petri Nets. In Dis-
crete Event Dynamic Systems, vol.12, no.3 (311-333).
Guillaume Gardey, Didier Lime, Morgan Magnin, and
Olivier (H.) Roux (2005). Romo: A tool for analyzing
time Petri nets. In 17th International Conference on
Computer Aided Verification (CAV05), Lecture Notes
in Computer Science vol.3576 (418-423), Edinburgh,
Scotland. Springer.
Jensen, K. (1987). Coloured Petri Nets. In Petri Nets:
Central Models and Their Properties. Lecture Notes
in Computer Science, vol.254 (248-299), Springer.
Jensen, K., Kristensen, L. M., and Wells, L. (2007).
Coloured Petri Nets and CPN tools for modelling and
validation of concurrent systems. In International
Journal on Software Tools for Technology Transfer,
vol.9, no.3 (213-254) Springer-Verlag.
Leveson, N. G., Stolzy, J. L. (1987) Safety Analysis using
Petri Nets. IEEE Transactions on Software Engineer-
ing, vol.13, no.3
Liu, C. L. and Layland, J. W. (1973). Scheduling algo-
rithms for multiprogramming in a hard-real-time envi-
ronment. In Journal of the ACM, vol.20, no.1 (46-61).
Murata, T. (1989). Petri Nets: Properties, analysis and ap-
plications. In Proceedings of the IEEE, vol.77, no.4
(541-580). IEEE.
Peterson, J. L. (1981). Petri Net Theory and the Modeling
of Systems. Prentice Hall PTR, Upper Saddle River,
Petri, C. A. (1962). Kommunikation mit automaten. In PhD
thesis. Universitat Hamburg.
Ramchandani, C. (1974). Analysis of asynchronous con-
current systems by Timed Petri Nets. Massachusetts
Institute of Technology.
Stankovic, J. (1988). Misconceptions About Real-Time
Computing. IEEE Computer, vol.21 (10-19). IEEE.
TINA (2015). <http://http://>.
Tsai, J., Jennhwa Yang, S., and Chang, Y.-H. (1995).
Timing constraint Petri Nets and their application to
schedulability analysis of real-time system specifica-
tions. In IEEE Transactions on Software Engineering,
vol. 21, no. 1 (32-49). IEEE.
Petri Nets Modeling for the Schedulability Analysis of Industrial Real Time Systems