1. style and fashion
2. jewelry
3. rings

A Simulation Model based on a Stochastic Petri Net Approach for Dependability
Evaluation of PROFIBUS-DP Networks
Paulo Jose Portugal
Faculdade de Engenharia - DEEC
Rua Dr. Roberto Frias s/n
4200-465 Porto, PORTUGAL
pportugal(fe.up.pt
Adriano da Silva Carvalho
Faculdade de Engenharia - DEEC
Rua Dr. Roberto Frias s/n
4200-465 Porto, PORTUGAL
asc@fe.up.pt
Abstract
The paper proposes a dependability model which enables
the evaluation of Profibus-DP networks in scenarios of
transient faults which affect data communications. The full
behavior of Profibus-DP communication stack is modeled,
including: cyclic process data exchange between master
and slave stations; configuration, parameterization and diagnostics of slave stations. The model is based on a high
level Stochastic Petri Net formalism referred as Stochastic
Activity Networks (SAN), supported by the Mobius tool.
High modeling power, state-of-the-art analytical and simulation solutions, and a flexible and integrated environment
are their main features. Dependability measures are established from the fulfillment of the real-time constraints
(deadlines) defined on process data messages exchanged
between master and slave stations. The reward concept is
used to define the measures, which are obtained by means
of a simulation approach. A case study is proposed to assess the modelperformance.
1. Introduction
Dependability attributes, like safety, reliability and availability, have become essential parameters on industrial automation systems design. Nowadays fieldbuses have a central
role in these systems, with large application domains which
extend to almost any area in manufacturing and process
industries. They are presently the backbone of distributed
industrial control architectures providing a communication
infrastructure which supports control, monitoring and
supervision applications [1].
The importance presently assumed by these control systems compels to evaluate their dependability. In a distributed system, determining the dependability of the communication channel is of particular importance, especially
when this component is susceptible to EMI (Electromagnetic Interference) problems. Therefore in these systems it
is vital to evaluate how the system dependability is affected
by faults on communication.
Industrial environments are characterized by the existence
of a high diversity of equipments that are source of large
EMI patterns [2]. These interferences induce faults in electronic circuits that disturb their normal operation. In communication systems these types of faults usually affect the
transmission medium and related circuits, since these are
the components most exposed to them. EMI faults are generally characterized by occurring in bursts, a long latent period followed by relatively short period of presence, and by
having a short duration (transient faults) [2].
In this context, faults produce errors on transmitted messages by corrupting their contents. To recover from these
situations fieldbus networks implement several faulttolerant mechanisms. However, this creates a communication overhead by introducing delivery delays in messages
0-7803-9402-X/05/$20.00 © 2005 IEEE
which could imply a performance degradation in the control
system [3,4]. When messages have real-time requirements,
which is common in control systems [1,3,4], these problems
can seriously disturb the system operation which can even
lead to its failure [3,4].
This paper deals with a specific fieldbus: Profibus-DP [5].
It proposes a model that enables to determine the network
dependability with respect to deadline failures in the presence of faults induced by external sources (EMI).
2. Profibus-DP
The Profibus-DPI [5] is a fieldbus designed for use at the
low level of factory automation systems, where it performs
high-speed data exchange between process controllers and
field devices, such as sensors and actuators.
Two types of stations can be connected to the network: (i)
Masters, usually performing automation and control tasks
(e.g. PLCs). Their operation typically consists of polling a
set of associated slave devices and executing control programs; (ii) Slaves, consisting on peripheral devices (e.g.
I/O) exchanging data with the masters. Masters are referred
as active stations, and slaves as passive ones. Communications can only be initiated by the active stations. Passive stations can only access to the medium in response to an active
station request. The communication stack is organized according the OSI model, but using only with 3 layers: Physical, Fieldbus Data Link (FDL) and Application. The later
one is split into 2 sub-layers: Direct Data Link Mapper
(DDLM) and User Interface. The stations are interconnected according a bus topology.
The medium access control is achieved by a hybrid access
medium method: a decentralized method accordingly to the
principle of token passing is underlain by a central method
according to the master-slave principle. In order to manage
the bus access, active stations have to build and manage a
logical ring. Each active station has its own List of Active
Stations (LAS), which represents all active members of the
ring. According to the LAS, the token is passed on the ring
from active to active station on ascending station address
way, except if the token holder is the station with the higher
address value. In this case, the token is passed to the station
with lowest address value.
The station that possesses the token is referred as this station (TS). After receiving the token from the station immediately below in LAS, referred as previous station (PS), it is
able to initiate the message cycles with the slaves. When it
finishes, it has to pass the token to the immediate station on
the LAS referred as next station (NS). If the token holder is
the only active station on the ring it has to pass the token to
itself. Each active station has two main types of tasks: an
active phase where the station communicates with the asso1 Now referred as
485
Profibus-DP-VO
VOLUME 2
ciated slaves and a management phase, where the station
performs maintenance ring operations. On the management
phase the station has to keep its LAS updated in response
either to a station insertion or removal from the ring.
easily constructed and less error-prone than simulation programs.
Due to their advanced modeling characteristics and flexibility SPNs have become a popular formalism to evaluate
communication systems. Their use extends from performance to dependability studies [11,12,13,14,15,17].
4.2. Modelling Methodology
The global behavior of Profibus-DP is characterized by
complex mechanisms which make use of several timers,
most of then running in parallel (concurrent). From an SPN
modeling viewpoint these timers are usually represented by
concurrent timed transitions. Among several conditions, to
obtain an analytical solution from a SPN model it is necessary that the number of concurrent timed transitions (non
exponential ones) enabled at each marking must not exceed
one2 [13,15,16]. From the Probifus-DP behavior it is clear
that the respective model doesn't fulfills the previous condition. Therefore it was necessary to use a simulation approach to obtain the model solution.
4.2.1. Simulation Solution
The use of simulation for dependability evaluation arise
some important problems that must be properly analyzed
[1 8]. For an accurate estimation of dependability measures
it is necessary frequent observations of the system-failure
event, which by definition are rare events. This results into a
substantial increase of the simulation time, which could lead
to impractical values. To attack this problem, in recent
years, there have been considerable and successful efforts to
develop fast simulation techniques [12,18]. Among these
techniques the most important are: importance sampling and
variance reduction techniques (e.g. control and antithetic
variables).Their main goal is to reduce the simulation time
necessary to obtain the results. During the last decade these
techniques have been systematically incorporated into SPNs
tools [12,18,19], offering therefore a state-of-the-art simulation environment. Meanwhile most of these tools also provide a distributed (parallel) simulation environment, which
permits a further reduction of the simulation time. Moreover, SPNs are also an adequate modeling formalism to capture the behavior of Discrete Event Systems [12], which become the basis of simulation environments. The combination of all these aspects allows to conclude that SPNs supports efficiently simulation solutions in a dependability
evaluation context.
Even if SPNs provide an adequate modeling environment,
the use of a simulation solution is characterized by some aspects that must be properly understood. First, simulation
produces results that are just an approximation of the real
ones. A confidence interval is used to characterize the accuracy of the results [12,14,18]. Second, in many situations
the results are obtained through the use of exigent computational resources (CPU time and memory). While the former
problem is inherent to the simulation process, the latter can
be minimized by adopting the following measures: (i) Developing the model in a way that maximizes its execution
performance; (ii) Choosing an adequate modeling tool that
enables to develop high-performance models.
4.2.2. Modeling Tool
The following requirements were established for the
modeling tool: (i) Be able to model efficiently the complexity of the Profibus-DP behavior; (ii) Provide a high performance simulation environment; (iii) Include efficient
mechanisms to allow model's validation (modeling errors);
3. Analysis of the Previous Work
In the last years only a few number of works have focused
on Profibus dependability.
In [6] a simulation model based on Stochastic Petri Nets
is proposed. Although an exhaustive identification of the
types and characteristics of the faults involved is performed,
only small subsets (the major ones) are included in the
model. As a result of this simplification process, the proposed model is very simple and doesn't capture properly the
network behavior in the presence of faults. Moreover some
parameters are is some cases unclear or even unknown. The
combination of all these aspects makes the model difficult
to use (or even useless) for dependability evaluation.
In [7,8,9] the ring stability of Profibus in error-prone links
is analyzed. This work focuses only in transient faults and
proposes both a simulation model [8], based on a proprietary development environment, and an analytical model [9]
as an approximation to [8], to evaluate the network behavior. Although this is very relevant work it has some limitations. First, most of the analyses don't include any message
(data) traffic, but only token and ring management frames
[5]. This is a consequence of the objectives proposed, which
are focused on the ring stability and not the in the real-time
properties of the network. Second, when message traffic is
considered their modeling is not performed according to the
characteristics of the DP component of the Profibus protocol. An example of this aspect is the cyclic data exchange
with the slaves. Third, there are some modelings imprecision's about the Profibus-DP behavior.
4. Modeling Framework
From the previous discussion it becomes clear that these
works don't provide the necessary means to perform a complete or accurate evaluation of Profibus-DP dependability in
scenarios where faults affect the real-time properties of the
network. Therefore it is necessary to propose a new evaluation methodology to cope with this issue.
4.1. Stochastic Petri Nets
Dependability evaluation is necessarily associated with
the development of a model that describes the system behavior in the presence of faults and which enables to retrieve dependability measures from it. Petri Nets (PN) are a
graphical and mathematical modeling tool which enables
the description and analysis of the system dynamics, where
concurrent, asynchronous, distributed, parallel and stochastic behaviors are present [10]. Over the last decade Stochastic Petri Nets (SPN) have become a widely used framework
for the performance and dependability evaluation of various
kinds of systems [11,12,13,14,15,17] by several reasons: (i)
An intuitive description of the system behavior; (ii) Representation of complex systems by very compact models; (iii)
A formal basis; (iv) Full representation of the stochastic
processes; (v) Possibility to obtain different types of solutions from the same model; (vi) Large number of analysis
tools available.
The use of SPNs to derive dependability models can be
performed from two viewpoints, according to the type of solution required [1 1,12,13,16]: (i) Analytical, when the SPNs
transitions obey to certain structural rules an analytical stochastic process can be automatically generated; (ii) Simulation, in this case neither of the previous limitations are present and a significant number of SPNs modeling extensions
are available to reduce the model complexity. Since the
SPNs semantics are formally well-established, models are
2
486
There are some exceptions which permit a higher number of concurrently
timed transitions [12,13,15,16], however they impose very strict conditions which are no meet by the model.
VOLUME 2
(iv) Support of reward measures [1 1,12,13,14,15,16]. After
mapping these requirements in the functionalities of the existent modeling tools [19], the Mobius one was chosen.
Mobius [20] is a tool which supports a SPN extension referred as Stochastic Activity Networks (SANs) [21] and
which provides a hierarchical modeling approach. It includes a flexible development environment capable of producing very compact models, combined with advanced and
state-of-the-art analytical and simulation solutions. The
modeling formalism is quite similar to the classic SPNs
with two minor exceptions: (i) Transitions can have probabilistic choices. When a transition fires a output path is
chosen with a pre-defined probability. This is represented
by cases (small circles attached to transitions); (ii) The conditions which enable transitions are defined by input gates
and the actions (changes on SPN marking) executed after
their firing are defined by both input and output gates.
Gates are represented by triangles. The user defines conditions and actions by means of C++ code, which permits to
model complex behaviors in a very compact way. After
building the model, this one is automatically converted to
C++ and an executable is obtained by using the O.S. language developments tools (compiler, linker, etc.). This allows using language optimization aspects, providing therefore high-performance models.
4.3. Model Assumptions
Dependability models were developed accordingly the
following assumptions:
* The network behavior was considered as close as possible
to the real applications. Namely, it was included the
Profibus-DP specific behavior, such as: cyclic process
data exchange between master and slaves, configuration,
parameterization and diagnostics of slave stations. The
standard [5] was used as the reference document;
* There is a single transmission medium (bus) without any
type of redundancy;
* Faults occur accordingly a homogeneous Poisson process
[14] (independent errors) and their effects are equally
seen by all the stations. Although this a simple fault
model it can extended to represent more complex fault
behaviors such as Gilbert-Elliot models (mean bit error
rate) [2,8];
* If a fault occurs during a frame transmission it is assumed
that it corrupts its contents by introducing errors. It is also
assumed that errors are always detected by the stations.
All frames (except the token one) have a FCS (Frame
Check Sequence) field which is used to detect transmission errors. In [8] it is shown that although the detection
efficiency of this mechanism has smaller than a 32-bit
CRC, the probability of undetected errors is smaller than
10-9. Therefore this is a valid assumption. The token
frame is an exception to this behavior. Further details will
be discussed in section (§5.1.1);
* Process data messages have real-time requirements which
are represented by means of deadlines;
* A network failure occurs if a message misses its deadline;
* The most important dependability measure is defined by
the probability of a deadline to be missed.
in the evaluation process. Due to the intensive use of C++
code (gates) the models are described from a functional perspective (near to the SPN marking evolution) and without
any mention to their internal code.
In order to maximize the model performance the following aspects were considered during its development: (i) Reduction of the number of simultaneously enabled transitions
in order to minimize the size of the simulation events list
their management; (ii) At most one immediate transition is
enabled at each marking. This guarantees a well-defined behavior for the stochastic process [12,15,16]; (iii) Efficient
C++ coding of input and output gates.
5.1. Master Model
Masters are responsible by several tasks such as: token
passing, ring management and cyclic process data exchange
with the associated slaves. Since this behavior is quite complex and in order to simplify the presentation, this model is
decomposed into several sub-models, each one discussed in
the following sub-sections. From a perspective centered in
the FDL layer, the master evolution is described by a state
machine [5]. These states are represented in the model by a
place with a similar name.
5.1. 1. Token Passing
This model represents the behavior during the token passing procedure (Fig. 1). After the master has finished its message cycles it passes the token to its successor in the ring
(NS) by transmitting a token frame. In parallel and during a
period of time referred as Slot Time (TST) the master also
monitors their transmission. Therefore, if transmission errors occur they are always detected by the master. If during
this interval of time the master detects any bus activity it assumes that its successor owns the token. Otherwise it retries
the token transmission, until a limit is reached. The token
frame is composed by 3 UART characters (SD - Start Delimiter (a fixed char, OxDC), DA - Destination Address, SA
- Source Address), each one with 11 bits (1 start bit, 8 data
bits, 1 parity bit and 1 stop bit).
MAD1
MADn
active)
)offline
)listen
Figure 1 - Token passing.
When the pass place (a FDL state) is marked the master
owns the token and wants to pass it to the NS. The time
necessary to transmit the token frame is represented by the
deterministic transition t TT. When this transition fires one
of four scenarios, represented by the 4 cases, could happen:
1. Fatal errors in the token frame were detected. Although
[5] describes this situation as result of a permanent fault
in the transceivers or in the bus, fault injection experiments performed in [22] showed that this could also happen if the SD character is severely affected by transient
faults. When this scenario occurs, the 1st case (o_eg) of
t_TT is chosen withp_eg probability;
2. Normal errors (not fatal ones) in the token frame had occurred and weren't detected by the other masters. Since
the token frame integrity is assured only by the character's parity bits, it is possible that an error in SA or DA
5. Dependability Models
For each network structure (number of master and slave
stations) it is necessary to develop a specific dependability
model. To avoid the process of building a model from
scratch for each structure it was employed a modular perspective for their development. Therefore, the model is
composed by three small models: Master, Slave and Global.
These models can be composed in different ways in order to
reflect different network structures without the need of internal modifications. This provides an important flexibility
487
VOLUME 2
fields occur without being detected (e.g. 2 bit errors). An
undetected error in those fields (a wrong address) could
lead to an erroneous token passing, which originates a
disturbance in the logical ring. When this scenario occurs, the 2nd case (oel) is chosen with p_el probability
and TKE is marked. This leads to the execution of the
Global model (§5.3), which suspends the execution of
this model (§5.1.1) until it finishes;
3. Normal errors in the token frame had occurred and were
detected (by all the stations). The 3rd case (o_el_d) is
chosen withp_el_d probability;
4. The token frame was transmitted without errors. The 4th
case (o_ok) is chosen with (1 -p eg-p el-p el d) probability.
In all previous scenarios the place ck_pass is also marked
to indicate that the master waits for an (indirect) confirmation of the token acceptance by NS. This marking will enable the deterministic transition t_ST, which represents TST.
If this transition fires then the token wasn't passed successfully. This could happen by several reasons, some already
presented (token with errors) and others that will be discussed in the following paragraphs and sub-sections. Otherwise, the master assumes that the token was passed successfully and it enters in the active state.
If during TST the next station (NS) doesn't accept the token (e.g. token with errors) and if the transmitting master
detects activity in the bus (valid or invalid frames, including
disturbances), it assumes that the token was passed successfully, which leads to a token lost. This behavior was not
foreseen by [7,8,9], and fault injection experiments [22]
showed that its occurrence has a higher probability than a
token frame with undetected errors. In the model, this behavior is represented by the 2 cases of t_ST transition. The
1st case (o_st) indicates no disturbances had occurred during
TST and it is selected with (1-p_e_st) probability. Otherwise,
the 2nd case (o_st_e) is chosen with p_e_st probability.
The existence of errors during the token transmission is
managed by a retransmission mechanism. In this situation
one of 3 scenarios could happen:
1. A fatal error occurred and tk_eg_ct marking, which
represents this situation, is incremented. If two consecutive errors [22] of this type happen the master enters in
the offline state and the token is lost;
2. A normal error occurred and tk_el_ct marking, which
represents this type of errors, is incremented. If two consecutive errors of this type happen the master enters in
the listen state. In this situation two scenarios could happen: (i) If the token frame has detected errors the token is
lost; (ii) If the token frame has undetected errors but
which corresponds to valid addresses, it is possible that
an erroneous master (not in the logical ring order) will
accept the token. Otherwise the token is lost;
3. There aren't errors and tk r ct marking, which represents the number of token transmissions, is incremented
(this also happens in the previous scenarios). The maximum number of token retransmissions is 2 [5]. If this
happens, the master assumes that NS is not available and
tries to transmit the token to the successor of this one,
and so on. A master should only accept the token from a
station not registered as their PS, if two consecutive tokens with the same contents are transmitted. The places
lD, ... MAD, are each one marked with an identifier (a
marking) which represents the address of a master accordingly their logical position on the ring. Therefore a
master always knows the addresses of the others stations
in the ring.
This model closely interacts with the token transmission
model (§5.1.2), which is executed immediately after t_TT
firing. During their execution this model (§5.1.1) suspends
its execution until the latter has finished. After this and if
488
the maximum number of errors is reached, the immediate
transition t_tk_me fires, removing ck_pass marking and the
master enters in listen or offline state according the error
type. During the several phases of the token transmission
the place BUS is marked with different types of identifiers,
each one represents a particular situation (e.g. token with errors detected, without errors, etc.).
5.1.2. Token Transmission
The existence of errors in a token frame induces a complex behavior in the other master stations. To represent it
accurately, the model supports the concept of logical ring
(Fig.2). This concept is implemented by merging places
BUS_UP and BUS_DW between adjacent master models,
emulating therefore a logical ring. The addresses of the
predecessor (PS) and the successor (NS) stations are defined
as the marking of the places ps and ns respectively. The
master address is defined in ts marking.
PSA
BUS
NSA
ts
ns
0 0 0
i_lbe
ps
Figure 2 - Token transmission.
After a token transmission (t_TT firing, §5.1.1) the following places are marked: NSA with the address of the successor, PSA with the master address, BUS with the token
status (e.g. error not detected), and BUS_UP with an identifier which indicates a token transmission. After this, the
immediate transitions t lbe in the several master models are
fired in sequence allowing the execution of local (model)
operations. This sequence ends with the firing of transition
tlbm in the model which "owns" the token. During the token transmission the following operations could be performed in each of the master models:
* Token transmitted without errors. In this scenario only the
successor (NS) will accept the token, which is verified if
NSA=ts and PSA=ps. The master that accepts the token
enters in the use state. To inform the master that transmitted the token from this occurrence the place BUS is
marked with an identifier. When this information
"reaches" to the master (tlIbm firing) the ck_pass marking is removed (§5.1.1) (and t_ST is disabled) and this
master enters in the active state;
* Token transmitted with undetected errors. In this situation
one of the following scenarios could happen:
i. Destination address (DA) with errors. In this case NSA
is marked with a wrong address (§5.3) and only the
master with this address will react to the token frame. If
this master is in the active state and receive two consecutive tokens with the same contents, then it must accept the token. Auxiliary places (not represented) are
used to save temporarily the token contents, which allows to compare consecutive token transmissions;
ii. Source address (SA) with errors and equal to the station
address. In this case PSA is marked with a wrong adVOLUME 2
dress. If the station is in the listen state and receives
two consecutive tokens with the same contents, then it
assumes that there is another station in the ring with the
same address and it enters in the offline state. In the
same context and if the master is in the active state then
it enters in the listen state;
iii. Destination and source addresses equal (SA=DA). This
type of token corresponds to a ring initialization procedure (§5.1.5). If the station is in the active state and receives two consecutive tokens with the same contents
then it enters in the listen state;
* Masters out-of-ring. If a master accepts a token which in
principle is not addressed to it (with undetected errors),
then all the masters which are placed between the two stations (logical addresses between sender and receiver)
must leave the ring by entering in the listen state. This
behavior results from the fact that these masters assume
that their ring image (LAS list) is inconsistent. [7,8,9] reports it, but affirms that it happens after the first token
transmission with these characteristics, when in practice 2
transmissions are necessary. Practical experiments [22]
had confirmed it. This is consistent with the expected
network behavior, since the intermediate masters should
only leave the ring if a master, out of the logical ring order, accepts the token and originates bus activity. If the
behavior assumed in [7,8,9] was true, the ring would be
very unstable. This behavior was modeled in the following way. When a master accepts a token with these characteristics marks BUS with an identifier which indicates
this situation. After t_lbm firing the master which transmitted the token verifies (o_lbm) if this situation happens.
In an affirmative case, the t_ore transitions in the several
master models (which also have a firing sequence) will
put the intermediate masters out-of-ring. This sequence
ends with t_orm firing in the new master that owns the
token
The other group of immediate transitions, t_bpe and
t_bea, implement a dual logical ring which is necessary to
initialize the models (initial marking) and to "clean" temporary markings during previous operations.
5.1.3. Token Rotation
When a master accepts the token it initiates the message
cycles with the associated slaves. The cycle duration is defined by the token holding time (TTH) and by the number of
messages to transmit [5]. After a master has received the token, the measurement of the token rotation time begins. The
time measurement ends at the next token receipt and results
in the real token rotation time (TRR). At the same instant a
new measurement of the following rotation time starts. The
TTH is defined as the difference between the target rotation
time (TTR), which is a configuration parameter, and TRR.
The implementation of this mechanism by using PNs is a
difficult task because TRR is not a parameter and depends
from the model real time evolution. This problem was
solved by using two Mobius functionalities. The extended
place concept implements a formalism which is analogous
to Colored Petri Nets [10,12], in which the marking of a
place is defined as a data structure (C++). To access the
simulation time Mobius provides a C++ function.
By using both functionalities, TTH behavior was modeled
in the following way (Fig.3). The extended place ttr_a contains on its marking (a float type) the time instant of the
previous token reception. Just after the token reception, TRR
is obtained as the difference between the actual simulation
time and trr_a marking. After this, trr_r extended place is
marked with TTR minus the previous difference, which corresponds to TTH and ttr_a is marked with the actual simulation time. If ttr_r has a positive marking the place tth_s is
marked and the deterministic transition t_TTH is enabled.
489
This transition has duration equal to the ttr_r marking, implementing therefore TTH. When this transition fires, TTH
had expired and tth_e is marked. If ttr_r is negative or zero
tth_e is immediately marked.
After receiving the token (use state), the master station
must respect an idle time between successive frame transmissions. The idle time (TIDLE) is a function of several factors [5], which include the station delay time (TSDR) and the
type of frame to be transmitted. This time is represented by
t_IDLE deterministic transition, which includes all the aspects mentioned in [5]. When this transition fires, ck_time is
marked and the immediate transition t_ck_time also fires
enabling the execution of the o ck_time gate. This output
gate is responsible for performing several actions, including
verifying the conditions for message transmissions.
trr_a
Q
trr_r
Q
use
n receipt
ck_time
tth_s
<ess
t_ck_time
ao
0
No
sg
es
nageme
Dt
7 > f | ~~~~Transmission
Data
Message
Transmission
__e
tth_e
ifncesay
-
ck_time
t_TTH
(*)YesIncludes
t_lDLE
t_IDLE
ess
es
anagement
Transmission
Yes;g
pass
J
pass
9
Figure 3 - Token rotation.
If there aren't messages to transmit the place pass is
marked immediately, which initiates the token passing procedure (§5.1.1). If there are messages to transmit, their
transmission (§5.1.6) proceeds accordingly their number
and the TTH value [5]. The model assumes two types of
messages: process data, which are exchanged between master and slave stations, and ring management, exchanged between masters. Although PROFIBUS supports both high
and low priority data messages, in PROFIBUS-DP all data
messages are transmitted as high priority ones. After the
message transmissions pass is marked as previously.
5.1.4. Ring Management
Each master in the logical ring examines its address range
(GAP List - GAPL) periodically in the interval given by the
GAP Update Time (TGUD). This is accomplished by examining one address per token receipt, using a management message (FDL Status). The GAPL represents all the stations
which are situated in the range from the master address to
NS. The management message is composed by a request
frame, sent by the master who owns the token, and by a reply frame sent by the station which receives the request.
)gap_e
gap_l
\_
/
i_fdl_ir
o_fdl_ir
o fdl
s_fdl
o_fdl
t_fdl_irtfd
-
r_ok
r
e
~~~~~t_fid_mr
Figure 4- Ring management.
When gap_s is marked the master fulfills the necessary
conditions to transmit ring management messages (Fig.4).
The TGUD timer is represented by the t_GUD deterministic
transition which is enabled by the previous marking. When
this transition fires, gap_e is marked and the number of stations in the GAPL is calculated (from ns and ts marking).
The place gap_l is marked with this value. The place fdl_ct
VOLUME 2
is used as a counter for the number of management messages transmitted by the master. When gap_l and fdl_ct
have the same marking all the stations in the GAPL were
polled and TGUD is re-initialized (gap_s is marked and
gap_e and fdl_ct have their marking removed).
The model described in this section only covers reception
and replying of management frames, being their transmission addressed by another model (§5.1.6). When a master
receives a request frame addressed to it, the immediate transition tfdl_ir fires initiating the reply by marking sfdl. If
the station is already in the logical ring, it should reply with
a normal answer. Otherwise and if the station is ready to enter in the ring (it must be on the listen state for a certain period of time [5]), it should reply with their status. In this
case the master that receives the response includes this station in the logical ring and registers it as the NS.
The response duration (including the station TSDR) is
modeled by tfdl_mr deterministic transition. This transition
has 2 cases that represent the occurrence of errors during the
transmission of the reply frame. If there weren't any errors,
the 1St case (ofdl_r_ok) is chosen with (1-p_eJdl_r) probability and BUS is marked with an identifier which indicates
this occurrence. If the master was out-of-ring then it is inserted (it was assumed that the necessary conditions are always fulfilled). This is performed by actualizing both its
predecessor (ps) and successor (ns), and by entering in the
active state. The master that sent the request actualizes its
successor (ns) and their GAPL (gap_l). If there were errors,
the 2nd case is chosen withp eJdl_r probability and BUS is
marked accordingly.
5.1. 5. Ring and Master Re-Initialization
A ring re-initialization happens when the token is lost. To
detect this situation a time-out timer (TTO) it is used to
monitor the bus activity. If this timer expires, the bus is regarded as inactive and the re-initialization procedure begins.
The timer value is directly related with the station address
[5], which prevents masters from triggering these procedures simultaneously. As consequence, this timer will expire first in the master with the lowest address. When this
happens the token is automatically generated in this master,
who begins to execute message cycles or passes the token to
the NS. This re-initialization doesn't imply the lost of the
LAS or the GAPL lists existent in the master stations. This
is an important aspect which is not properly addressed by
[7,8,9], who assumes that both lists are lost, which implies a
complete ring initialization (complete ring construction).
BUS
o_to
i_to
t_TO
o_off
offline
listen
t_TOF
Figure 5- Ring and master re-initialization.
This behavior is modeled in the following way (Fig.5).
When the token is lost the place BUS is marked with an
identifier. If the master is in the active or listen states t_TO
deterministic transition, which represents TTO defined according to [5] rules, is enabled. When it fires, the master enters in the use state which indicates that it owns the token.
The model also includes the possibility of a ring initialization. This is defined by the use of another identifier in BUS.
In this situation the token is also generated as previously,
but now it is assumed that both the LAS and GAPL lists are
lost in all the masters and a complete ring reconstruction is
necessary.
A master re-initialization is necessary when the offline
state is entered (Fig.5). In most of the cases this scenario
implies a manual intervention to re-start the station. To represent this behavior it was assumed that a master in offline it
enters in the listen state after a certain period of time (fixed
or stochastic). This is represented by the t_TOF timed tran-
sition. In this state the master waits for their insertion in the
ring by other master station.
5.1.6. Message Transmission
Messages exchanges between master and slaves stations
are organized into cycles composed by a request and a reply. Messages semantics are defined by services at the User
Interface sub-layer which are mapped into FDL services by
the DDLM sub-layer [5]. So, a message transmission corresponds to the transmission of a request (FDL) frame) followed by the reception of a response (FDL frame). After
sending the request the master waits no more than a slot
time (TST) for the response frame.
Although [5] defines several services at the User Interface, only the most important and relevant ones are implemented by this model. This option results from the following: (i) The chosen services correspond to a typical network
operation; (ii) Behind many of the services there are complex state machines whose behavior is difficult to model.
Further details will be presented in (§5.1.7).
So, it was chosen to implement the following messages
(services): process data, global control commands, slave diagnostics, slave parameterization and slave configuration.
Besides, the model it also implements the transmission of
ring management messages (§5.1.4). Since the mechanisms
involved in the message transmissions are independent of
their semantics, it was used a model able to represent all the
previous messages (Fig.6). This model closely interacts
with (§5.1.3) model.
o_msg_fok
BUS
0 0
mgps
mgp
0
__~~
MSg_tP
msg_r
0
C
i_msg_r_ok
t_msg_rLok
NSA
msgir
~
o_msg_o
~~
sg_ ~
rt_msg_ir_
msg_r
MSg_Ct
°
_
t_ M_ _St
t_ms g_r_e
ms
e
_g__
Figure 6 - Message Transmissions.
When the conditions necessary to transmit a message are
fulfilled (§5.1.3), msg_p_s and msg_tp are both marked.
The former one indicates the beginning of a message transmission, and the latter one the type of message (by means of
an identifier). This identifier permits to define both the request frame duration and its probability of transmission
(with)out errors. The place NSA is also marked with frame
destination address (station address). This guarantees that
only that destination station will process the request. The
deterministic transition t_msg represents the request frame
transmission. This transition has 2 cases which represent the
occurrence (or not) of errors during the transmission.
If there weren't errors, the It case is chosen
(o_msg_p_ok) with (1-p_e_XX) probability, where p_e_XX
represents the probability of an unsuccessful transmission of
a type XX frame (e.g data, diagnostics, etc.). In this situation
BUS is marked with an identifier which represents the type
of the request. The place msg_w r is also marked.
If there were errors, the 2't case is chosen with the
p_e_XX probability and the place msg_w_r is marked. This
marking enables t_msg_st deterministic transition, which
represents the slot time. If this transition fires, it indicates
that no response frame was received (a station should not
respond to requests with errors). In this case the request
frame is retransmitted (limited to 1 retransmission [5]) by
marking msg_p s again. If the maximum number of transmissions is reached, represented by msg_r marking, the
place use is marked and the conditions to transmit new messages are verified again (§5.1.3).
490
VOLUME 2
If there weren't errors during the request transmission,
then when the destination station receives it marks BUS
with an identifier. This enables and fires the t msg ir immediate transition which removes msg_w_r marking and
disables t msg_st. After this, msgf r is marked and the
master waits for the response frame. This response can also
contain errors. The station that sends the response indicates
this situation by marking BUS with an identifier.
If there were errors during the response frame transmission, the immediate transition t_msg_r_e fires and a sequence similar to previously described (errors during the request transmission) is initiated. If there weren't any errors,
the immediate transition t_msg_r_ok fires and initiates a sequence of operations by executing the o_msgf ok gate.
These operations depends both of the type of message
transmitted and the destination station status (§5.1.4,
§5.1.7). After performing these operations the place use is
marked as previously (§5.1.3). Some messages don't involve the transmission of a response frame (Global Control
frames). In this case transmission errors are ignored and use
is marked after their transmission. The marking of msg_ct
indicates that at least one message was transmitted, and it is
used by the token rotation model (§5.1.3) to establish the
message transmission conditions.
5.1.7. Slave Management
Communication between a master and a slave is initiated
at the master User Interface sub-layer by the execution of a
function primitive request. This request is mapped into a
DDLM service and later into a FDL service. The response
sent by the slave station follows the opposite path. All master-slave communication functions are executed in one FDL
message cycle (immediate response).
The User Interface sub-layer implements 3 function
blocks: Slave Handler, Scheduler and Service Handler,
which implement several state machines that execute functions that carry out data exchange within the slaves. The
state machine of the Slave Handler takes over the control of
exactly one slave. The state machines for each slave react
individually depending on the state of the slave. The slaves
are processed following a fixed sequence. At each call the
corresponding Slave Handler will make only one DDLM
service request. The Scheduler determines the sequence of
the calls of the corresponding Slave Handlers. The minimum time which has to elapse between two subsequent requests to the same slave is defined by the Min Slave Interval
(TMsI) [5]. This timer implements the cyclic exchange of
data between the master and the associated slaves. The Data
Control Interval (TcI) controls status data exchanged between the User Interface sub-layer and the user application.
This status refers which slaves executed a data transfer cycle within the last control interval. Additionally this timer
also defines the time in which a master indicates its operation mode (by issuing a Global Control command) to the
slaves.
Since the behavior of these state machines is very complex, their implementation in the model would be cumbersome. Therefore, it was chosen only to represent their typical behavior. The Scheduler state machine can be obtained
directly from the FDL states. The Slave Handler state machine was condensed from the states of a typical message
exchange between a master and a slave station (Fig.7). This
state machine also assumes that after slave's parameterization and configuration the master is configured to be maintained in the Operate [5] state.
The slave state defines the type of the message that the
master has to send to it. For each slave x their state is recorded by the slvx_op marking. The making of SLVx defines the slave address. This guarantees that only the correct
slave station will process the requests.
The cyclic slave polling (TMSI) is represented by the
491
t_slv_MS deterministic transition, which is enabled by the
s_slv_MS marking. When this transition fires slv MS e it is
marked. The transition is re-enabled after polling all the
slaves. This is controlled by the place slvyct, whose marking indicates the number of slaves already polled. The TcI
timer is implemented in a similar way by s slv CI (enable)
and s_CIe (expired) places and the t_slv_CI deterministic
transition. This transition is re-enabled only during the message transmissions [5]. When it fires, a Global Command
message is sent for the slaves. This model closely interacts
with (§5.1.3) and (§5.1.6) models. It is important to notice
that the slave state (slv_x_op) evolution depends also from
the type of the responses received (e.g. with errors, needs
diagnostic, etc.).
............. ......
t_sIv_MS
s siv MS
siv MS e
OFFLINE
---------
--------
F.IA.NOSTICS
IN'TIAL
F.A
SENT
METERS
CHECK
F CONFIGURATION
F
4
i_sIv_MS
s siv C
o_sIv_MS
t_sIv_C
I
i_slv_CI
-
I
sivCCl e
o_slv_CI
)slv_x_m
FINAL
DIAGNOSTICS
)slv-xdl
PROCESS DATA
EXCHANGE
slv_ct
0
Figure 7 - Slave management.
Process data message deadlines were defined accordingly
[23]. Each message is produced periodically and it has a
deadline equal to their production period. A network failure
happens if deadlines are missed. To simplify the model it
was assumed that a master transmit only one data message
for each slave. For the associated x slave, message production is represented by the t slv_xp deterministic transition,
whose duration is the production period. To represent a continuous data production this transition is always enabled.
When it fires, slv_x_m marking is analyzed and one the following scenarios could happen:
* If slv_x_m isn't marked, then the previous produced message was transmitted before its deadline had expired. In
this situation, slv_x_m is marked to indicate that a new
message was produced. When this message is transmitted
successfully (both request and response) (§5.1.6) this
marking is removed;
* If slv_x_m is marked, then the previous message wasn't
yet transmitted successfully (it is assumed that messages
are overwritten in a buffer) and its deadline was missed.
To represent this situation slv_x_dl is marked. This marking is only removed when the message is successfully
transmitted.
The model assumes that all data to parameterize and to
configure the slaves was correctly uploaded in the master
stations and that the user application doesn't send any asynchronous command (e.g. Sync or Freeze) [5] to the slave
stations.
5.2. Slave Model
The Slave model describes the behavior of a slave station.
The slave receives requests from a master and responds to
it. A slave is associated with only one master. When a master sends a request frame which isn't affected by errors
(§5.1.6) the place BUS is marked with an identifier that indicates the type of request and NSA is marked with the slave
address (Fig.8). The slave accepts the request if it is addressed to it (ts marking has the slave address). In this case
VOLUME 2
the immediate transition t_msg_i fires and BUS is marked
with an identifier which indicates that the slave has accepted the request. This marking also affects the behavior of
the (§5.1.6) model.
Meanwhile, s_slv_r is also marked with the request identifier. This identifier permits, as previously, to define the response type and the probabilities of their successful transmission. The response frame transmission is modeled by the
deterministic transition t_msg_slv_r, whose duration also
includes the TSDR from the slave station. This transition has
3 cases which represents the occurrence (or not) of errors
during the response transmission.
NSA
ts
C
C
BUS
i_msg_s
o_msg_r_ok
i_msg_slv_r
o_slv_r
t_msg_i
s_slv_r
t_msg_slv_r
omsg_r_ok
d
o_msg_r_e
Figure 8 - Slave model.
If there weren't any errors, the 1st case is chosen
(o_msg_r_ok) with (1-p_e_XX) probability, where p_eXXX
represents the probability of occurring errors during a type
XX response transmission. In this case BUS is marked with
an identifier which indicates a response without errors. The
2nd case represents an alternative to the 1st, and it is used to
indicate that the slave needs diagnostic. In this case a probability p_diag is used do represent the frequency of these
requests. The master receives this indication by marking
BUS with an identifier. If there were errors during the
transmission, the 3rd case is chosen (o msg_r_e) with probabilityp_eXX and BUS is marked accordingly.
5.3. Global Model
This model enables the interaction between the master
(§5.1) and slave (§5.2) models through the use of global
places (Fig.9). These are places which are shared between
models3. Moreover it also models the process of generating
token frames with undetected errors.
BUS
0
0
0
tion. In this situation, one of the following scenarios happens: (i) The (wrong) address doesn't correspond to any station in the ring. In this case the 1st case of the immediate
transition t_e_da (t_e_sa) is chosen and da_rest (sa rest)
place is marked; (ii) If the address corresponds to an existent master station, one of remain cases o DA_i (o_SAi) is
chosen and NSA (PSA) is marked with the station address.
This overwrites the original address. It is assumed that a token with undetected errors but with a valid master address
has a p_e_sa_da probability of occurrence. This corresponds to the t_e_sa(da) cases probabilities except the first
one, which is the complementary sum. It is necessary to include a case selection for each master in the ring.
Even when the token has undetected errors which don't
correspond to any master on the ring, there is a possibility
that two consecutive and equal tokens are transmitted. It is
assumed that this scenario has a p_e_dup probability of occurrence. This is modeled by the immediate transition
t_da rest (t_sa_rest) which has 2 cases. When it fires, the
fSt case corresponds to different consecutive addresses and
it is chosen (o_DA_g or o_SAg) with (1-p_e_dup) probability. When the 2' case is chosen (o DA dp or oSAdp),
with p_edup probability, it is "generated" an address equal
to the previous one and NSA (PSA) is marked accordingly.
A special identifier is used to represent this situation. If the
generated address don't' change the NSA or PSA markings
it is assumed that the token doesn't has errors (§5.1.1).
5.4. Model Parameters
Most of the model parameters are related to the transitions
that represent message transmissions. These parameters can
be grouped as following: (i) Probabilities; (ii) Duration.
5.4. 1. Transitions - Probabilities
Since faults occur according to a Poisson process [14], the
probability that a bit has its contents corrupted by a fault is
defined by the BER (Bit Error Rate) parameter, which can
be expressed as follows4:
(1)
BER = 1 - exp(-A TBIT)
where X is the fault rate and TBIT is the bit duration. It is
assumed that the BER value is independent of the bit contents. By assuming that at least one erroneous bit in a frame
is sufficient to corrupt their contents, the probability of a
successful frame transmission PSF is:
(2)
PSF (I BER)'
where n is the number of bits of the frame. This expression can be used to define the case probabilities in all transitions related with frame transmissions (success cases).
As discussed previously (§5.1.1) token frames can have
errors which are undetected by other master stations. In
[7,8,9] it is obtained an expression for the probability PTK2E
of a token frame with 2 undetected bit errors (SA or DA):
14 ( 332
BER2 (1-BE 3 -2)
(3)
PT TKE
E11.
1056 ~2
=
NSA
PSA
2
Figure 9 - Global model.
It was assumed that an undetected error in the token frame
only affects the source (SA) or the destination address (DA)
but not both. This assumption is based on the fact that the
latter scenario has a very low probability of occurrence (this
value is the product of the probabilities of errors in SA/DA,
which have in practice (§5.4) very small values).
When a token with undetected errors occur the place TKE
is marked (§5.1.1) and t_sa_da immediate transition is enabled. This transition has 2 cases which correspond respectively to an error in SA (e_sa marked) or DA (e_da
marked). It is assumed an equal probability for each situa-
Although an expression for a higher number of errors
could be obtained, in [8] it is shown that is not necessary to
include their effects since their contribution is residual.
Since the conditions which rule the occurrence of fatal errors in token frames are somewhat undefined, their quantification was defined based on heuristics aspects. Since the token frame Start Delimiter (SD) is a fixed character with a
Hamming a distance of 4 [5], it was assumed that a fatal error happens if at least 4 bits of SD are corrupted (independently of the remaining bits of the frame).
3 These places are represented by capital letters in the models.
4 Due to space limitations expression's deductions are omitted.
492
VOLUME 2
other types of measures, such as performability ones (e.g.
mean token rotation time, mean number of stations in the
ring, etc.) [12,13.14,17,19]. This flexibility results from the
manner how the model was developed.
5.6. Network Dependability Model
The network dependability model is obtained by the composition of the models defined previously (Fig.10). Both
masters (M) and slaves (N) are represented by their own
model whose interaction is assured by the Global model.
This composition is performed by means of the Mobius Join
primitive [20]. Models are connected through global places
with the same name. The only exceptions are BUS_DW and
BUS_UP places in the master model, which are merged in
adjacent master models to emulate the logical ring. The
proposed models can also be used (without any modifications) to evaluate a mono-master network.
Therefore, the probability PTKFE of a fatal error (SA or
DA) in the token frame is:
PTKFE
=
2
BERk (1- BER)
(4)
From the previous expressions t_TT case probabilities
(§5.1.1) can be defined according to Table 1.
Table 1 - t_TT case probabilities.
Parameter
Equation
Prob. successful transmission
(2)
Prob. fatal error
(4)
Prob. nornal error undetected
(3)
1- ((2)+(3)+(4))
Prob. nornal error detected
By assuming that a token frame with undetected errors
has wrong addresses (SA or DA) in 0.. .255 range, all equal
probable, then if the network has M master stations t_e_da
and t_e_sa case probabilities (§5.3) can be defined according to Table 2.
Table 2 - t_e_da(sa) case probabilities.
Case
1
2....M+1
Expression
1- M/255
1/255
Equation
(5)
(6)
Figure 10 - Network dependability model.
6. Case Study
The p_e_dup probability, associated to t_da _rest and
t_sa_rest transitions (§5.3), can be expressed as follows:
pe dup = 1/(255 - M)
(7)
The probability PSTE of occurring errors during the Slot
Time (TST) is defined as
The usefulness of a simulation model is strongly dependent from their performance. A model can be structurally
well defined and however to take an unacceptable time to
get the results. Therefore is necessary to assess the model
(8)
PSTE -exp(-A (TST -TSI))
where TSYN is the synchronization time [5]. This last term
is due to the fact that the master only begins the bus monitoring after a TSYN time.
5.4.2. Transitions - Duration
Since most timed transitions represents frame transmissions their duration is related with both the frame length
(bytes) and the network data rate (bits/s). Nevertheless,
there are some parameters (TIDLE, TST and TSDR) which only
depend from the network speed. Typical values for these parameters can be found in [5]. Although the signal propagation time in the bus was not considered, it can be easily included in the timed transitions related to frame transmissions. All timed transitions were implemented accordingly a
single server policy and with a PRD (Preemptive Repeat
Different) preemption policy [ 12,16].
5.5. Dependability Measures
Dependability evaluation is performed by defining a set of
measures in the model. In the SPNs context this measures
are derived from the concept of reward [11,12,13,14,15,16].
Two types of rewards ca be defined: (i) Rates, associated
with SPN markings and which are collected during the time
the SPN resides on the marking; (ii) Impulses, associated
with transitions firings which are collected when the transition fires. From these definitions other important measures
can be derived such as: marking probability, expected number of tokens in a place, expected number of firings of a
transition, etc. These measures are typically obtained considering two scenarios: steady-state and transient analysis.
The probability of missing deadline of a process data
message related with slave x can be obtained by defining a
reward rate of 1 in slv_x_dl place and by computing the stationary expected instantaneous reward. When it is necessary to consider all the messages, the measure it is defined
as the sum of all rates. The model can be also used to obtain
493
performance.
Performance is typically defined from the simulation time
needed to obtain the results in a specific context. Trying to
characterize performance is a difficult task since there are
several factors involved: (i) Computational platform used
(e.g. CPU, memory); (ii) Simulator characteristics (e.g.
event list management); (iii) Message scheduling and deadline definitions; (iv) Fault assumptions (e.g. rate); (v) Results precision degree (e.g. confidence interval characteristics). Is therefore easy to understand that it is almost impossible to define a performance metric truly independent from
all these factors.
Face to this problem, a pragmatic choice was used to define this metric. From the previous factors, (i), (iii), (iv) and
(v) are those which have a major influence in the simulation
time. Since (iii) and (iv) are part of the evaluated scenario,
if a typical one is chosen then the metric also reflects this
aspect. The same perspective can also be used with (i). To
overcome (v) it is necessary for the metric to be independent of the statistical aspects. In typical situations this factor
it is certainly the most important one, since it defines the
number of samples required to obtain the results which directly related with the simulation time. Therefore the metric
was defined as the simulation time necessary to run a single
execution (sample path) of the model during a simulated
time interval. This is an objective metric that reflects the
model performance and which doesn't depend from the statistical methods used to obtain the results.
A case study with the following characteristics was chosen5: (a) A network composed by 3 masters, each one associated with 3 slaves; (b) Messages and network parameters
defined according typical values found in [5]; (c) Network
cycle time obtained from the methodology presented in
[24]. It was assumed a pessimistic approach by considering
that all types of messages are transmitted when a master
owns the token; (d) TTR was defined as equal to the cycle
time and TMSI as 1/4 of this value; (e) Message deadlines
were defined as 2 TTR. This value combined with TTR and
5 Due to space limitations only the main aspects are presented.
VOLUME 2
TMSI implies that is necessary several consecutive errors for
the message deadline to be missed; (f) A network speed of
50OKbits/s was chosen.
Table 3 presents the results obtained for the metric defined previously. The experiments were performed in a PC
(PIII@730MHz, 512MB memory) running Linux Mandrake
10.1. Since fault occurrence will typically extend the time
intervals between events (e.g. master enters in offline), a
scenario with BER=0 was chosen to impose a high load to
the simulator. The results refer to the real execution time
(not CPU time) observed by a user and includes the loading
effects imposed by other (typical) applications executed in
parallel by the operating system.
[4]
[5]
[6]
[7]
Table 3 - Simulation time.
Scenario
BER= 0
Simulated Interval
1 Second
10 Seconds
0.53 seconds
3.6 seconds
[8]
From a performance viewpoint the quality of the model
can be measured as the ratio between the simulated interval
and the (real) simulation time. High values for this ratio indicate a good model performance. The results (Tab.3) show
that this ratio varies in a 2 to 3 range. Although this is not a
very high value, it is important to notice that these results
were obtained using a large network (12 nodes) and conservative scenarios (characteristics (a), (c), (d) and (e)). Therefore, it can be concluded that in a typical situation the model
has a good performance. To prove this conclusion a complete simulation were executed to obtain the dependability
measures. The measures were defined as previously, but referring to only one message. They were used the BER values defined in [7]. The results (Tab.4) show the simulation
time necessary to obtain the measures using a typical (and
accurate) confidence interval in the former computational
environment. This value corresponds to a steady-state
analysis.
BER
lo-,
I0-4
[9]
[10]
[11]
[12]
[13]
[14]
[15]
Table 4- Complete simulation time.
Complete Simulation Confidence Interval: 95%
Relative Error: 10%
37 seconds
2268 seconds
[16]
-
[17]
These results confirms that in a typical case study the
simulation model has a good performance and can be used
efficiently to evaluate the behavior of a Profibus-DP network in the presence of faults. The use of a distributed
simulation environment (fully supported by Mobius, but not
used here) will also permit a dramatic increase in the model
performance.
[18]
[19]
7. Conclusions
A simulation model was proposed to evaluate ProfibusDP dependability in scenarios of transient faults that occur
during communications. The model is both accurate and detailed, and includes all typical communication aspects found
in real applications. Although the results are obtained by
means of simulation, the model presents a good performance which makes it useful to evaluate the Profibus-DP behavior in typical fault scenarios.
References
[1] J. P. Thomesse, "A review of the Fieldbuses", Annual Reviews in Control, Vol. 22, pp. 35-45, 1998.
[2] H. Kim, A. White, K. Shin, "Effects of Electromagnetic Interference on Controller-Computer Upsets and System Stability", IEEE Transactions on Control Systems Technology,
Vol. 8, pp. 351-357, 2000.
[3] H. Kim, K. Shin, "On the Maximum Feedback Delay in a
Linear/Nonlinear Control System with Input Disturbances
[20]
[21]
[22]
[23]
[24]
tions on Control Systems Technology, Vol. 2, No. 2, pp. 110122, 1994.
K. Shin, H. Kim, "Derivation and Application of Hard Deadlines for Real-Time Control Systems", IEEE Transactions
on Systems, Man and Cybernetics, Vol. 22, No. 6, pp. 14031413, 1992.
EN 50170, General Purpose Field Communication System,
Volume 2/3 (PROFIBUS), CENELEC, 1996.
L. Bello, 0. Mirabella, "A Fault Tolerance Analysis of
PROFIBUS Systems by Means of Generalized Stochastic
Petri Nets", Proceedings of 25th Int. Conf on Industrial
Electronics, Control and Instrumentation - IECON'99, 1999.
A. Willing, A. Wolisz, "Ring Stability of the PROFIBUS
Token-Passing Protocol Over Error-Prone Links", IEEE
Transactions on Industrial Electronics, Vol. 48, No. 5, pp.
1025-1033, 2001.
A. Willing, "Analysis and Tuning of the PROFIBUS Token
Passing Protocol for Use over Error Prone Links", TKN
Technical Report TKN-99-001, 1999.
A. Willing, "Markov Modeling of the PROFIBUS Ring
Membership over Error Prone Links", TKN Technical Report TKN-99-004, 1999.
T. Murata, "Petri Nets: Properties, Analysis and Applications", Proceedings of the IEEE, Vol. 77, pp. 541-580, No.
4, 1989.
M. Malhotra, K. Trivedi, "Dependability Modeling Using
Petri-Nets", IEEE Transactions on Reliability, Vol. 44, No.
3, pp. 428-440, 1995.
P. Haas, Stochastic Petri Nets. Modelling, Stability, Simulation, Springer-Verlag, 2002.
C. Lindemann, Performance Modelling with Deterministic
and Stochastic Petri Nets, Wiley, 1998.
K. Trivedi, Probability and Statistics with Reliability, Queuing and Computer Science Applications - 2nd Edition, Wiley,
2002.
R. German, Performance Analysis of Communication Systems - Modeling with Non-Markovian Stochastic Petri Nets,
Wiley, 2000.
A. Bobbio, A. Puliafito, M. Telek, K.Trivedi, "Recent Developments in Non-Markovian Stochastic Petri Nets", Journal of Systems Circuits and Computers, Vol. 8, No. 1, pp.
119-158, 1998.
J. Billington, M. Diaz, G. Rozenberg (Eds.), Application of
Petri Nest to Communication Networks, Lecture Notes in
Computer Science, Vol. 1605, Springer, 1999.
V. Nicola, P. Shahabuddin, M. Nakayama, "Techniques for
Fast Simulation of Models of Highly Dependable Systems",
IEEE Transactions on Reliability, Vol. 50, No. 3, pp. 246264, 2001.
B. Haverkort, I. Niemegeers, "Performability Modelling
Tools and Techniques", Performance Evaluation, Vol. 25,
pp. 17-40, 1996.
G. Clark, T. Courtney, D. Daly, D. Deavours, S. Derisavi, J.
M. Doyle, W. H. Sanders, P. Webster, "The Mobius Modeling Tool", Proceedings of the 9th Int. Workshop on Petri
Nets and Performance Models, 2001.
W. Sanders, J. Meyer, "Stochastic Activity Networks: Formal Definitions and Concepts", Lectures Notes in Computer
Science, No. 2090, pp. 315-343, 2001.
J. Carvalho, A. Carvalho, P. Portugal, "Assessment of
PROFIBUS Networks Using a Fault Injection Framework",
Proceedings of 1 0th Int. Conf. on Emerging Technologies
and Factory Automation - ETFA '05, 2005.
E. Tovar, F. Vasques, "Real-time Fieldbus Communications
using Profibus Networks", IEEE Transactions on Industrial
Electronics, Vol. 46, No. 6, pp. 1241-1251, 1999.
S. Vitturi, "On the Effects of the Acyclic Traffic on Profibus
DP Networks", Computer Standards & Interfaces, Vol. 26,
pp. 131-144,2004.
Caused by Controller-Computer Failures", IEEE Transac-
494
VOLUME 2