IEEE PES TRANSACTIONS ON POWER DELIVERY
Implementing substations automatic control
functions designed with Petri Nets on IEC 61850
Pinto de Sá, J.L., Senior Member IEEE
Abstract - This paper shows how cooperative automatic control
functions in transmission substations, specified by Petri Nets
(PN), fit the IEC 61850 Standard.
In the PN model, each automaton is specified by an interpreted
state machine communicating with others through shared condi-
tions, featuring operational improvements and still assuring good
behavior, as it can be proven through formal analysis. However,
to avoid jeopardizing the good properties of the model in a distri-
buted implementation, a few rules on how to split the functions in
concurrent tasks must be followed, particularly on how some run-
time conflicts have to be resolved.
Although the IEC 61850 environment provides a set of communi-
cation services for the substations functions, implementing PN
specifications on it is not a straightforward process. Therefore, a
new class of logical nodes is proposed to model the functions re-
quired for that purpose.
Index Terms-- Petri Nets, IEC 61850, Substation Automation
I. INTRODUCTION
Petri Nets (PNs) are a powerful mathematical tool for describ-
ing relationships between logical conditions and discrete
events, supporting the modeling and analysis of the behavior
of automatic control systems [1].
Avoiding some modeling extensions, which can ease the speci-
fication job but also reduce analysis capabilities, ordinary PNs
can be mathematically validated before they are implemented.
This validation, for which computer aids exist, can be inter-
preted into desirable guarantees of good operational behavior
for the automatic control functions, whose concurrency makes
it extremely difficult to predict for possible malfunctions [2].
The first published reference to the application of PN to Subs-
tation Automation dates to 1978 [3]. A complete PN specifica-
tion for a set of Automatic control functions in Distribution
Substations was developed in the eighties [4] and dealt with
Automatic Line Reclosure, Communications-Enhanced Trip
and Restore, Voltage and Under Frequency Load Shedding,
and Automatic Restoration. The absence of deadlocks and a
full deterministic behavior were mathematically proven. In ad-
dition, important operational properties were guaranteed, such
as the requirements that ―a circuit-breaker will never close if
any control function does not want it,‖ and ―a previously
closed circuit-breaker, opened by any automatic control func-
tion, will always close in the end if all the control functions
agree.‖ This PN specification was fully implemented on a
Manuscript received May 27, 2010; revised September 17, 2010; accepted
October 30, 2010. Paper nº TPWRD-XXXX.
J.L. Pinto de Sá is a Professor of Instituto Superior Técnico, CIEEE, 1049-
001 Lisboa, Portugal (e-mail: pintosa@ist.utl.pt).
R. Cartaxo is with the electrical transmission utility REN, 2685-038
Sacavem, Portugal (e-mail: ricardocartaxo@clix.pt)
Digital object 10.1109/TPWRD.2010.2090952.
TPWRD-00395-2010 1
Cartaxo, R.
Substation microprocessor-based controller and thoroughly
tested, running on a multi-tasking software environment with
special features to guarantee faithful conformance to the vali-
dated PN [5].
Shortly afterwards a similar approach was applied to
Transmission Substations. Details on the formal verification of
the resulting Petri Net and the meaning of its results were pub-
lished in 1991 [6]. These specifications were also widely ap-
plied in the Portuguese Transmission Network [7]; however,
over the past 15 years Substations control systems have
evolved into distributed architectures, and the previous multi-
tasking implementation techniques for PN-designed automatic
control became outdated.
In the meantime, the emergence in the last decade of a new pa-
radigm for Power Substations distributed control, the IEC
61850 standard [8], was seen as an opportunity to return to the
PN-designed automatic control functions with only minor up-
dating costs. The Portuguese power transmission utility is
committed to revamping its substations automation with IEC
61850 [9], a trend currently followed by many utilities around
the world.
This paper intends to present a convergence for these two po-
werful tools: on one hand, the IEC 61850, which is an increa-
singly accepted standard with features such as standardization
of data semantics, improvement of the engineering process and
the decoupling between hardware and software; and, on the
other hand, Petri Nets, a specifying tool capable of ensuring
the validated behavior of complex automatic functions not
covered by the IEC 61850 standard.
II. PETRI NETS AND SUBSTATIONS AUTOMATIC CONTROL
A. Definitions and Properties
A safe Petri Net structure is a bipartite graph N = (P, T, A,
M0), where P = {p1, p2, . . . , pn} is a finite set of n places
(drawn as circles), T = {t1, t2, . . . , tm} is a finite set of m tran-
sitions (drawn as bars), and A  (P × T)  (T × P) is a set of
arcs (from places to transitions and from transitions to places).
At each time t, a marking Mt is a vector Mt: P →{0, 1, 2, . . . n}
that assigns to each place of the Petri Net zero or one token
(drawn as a dot). This token can be viewed as a truth attribute.
The initial marking M0 denotes the existence or non-existence
of a token in each place of the Petri Net at the initial time t = 0.
The only execution rule of a Petri Net can be informally stated
as follows:
 a transition is enabled (it may fire) in M if there is a token in
all its input places for the consuming to be possible, i.e., if all
its pre-conditions hold;
 firing a transition t in a marking M consumes one token from
each of its input places, and produces one token in each of its
IEEE PES TRANSACTIONS ON POWER DELIVERY TPWRD-00395-2010 2

output places. In other words, firing a transition resets its ports the proof that some conditions cannot happen simulta-
pre-conditions and sets its post-conditions. neously (places invariance) and that some events always hap-
Note that the transition may fire, but it does not have to. This is pen together (transitions invariance). All these properties can
the basis of the Petri Nets‘ capability to model asynchronous be proven with the aid of easily available software tools [10].
concurrency.
An interpreted safe Petri Net consists of a safe PN, as pre- B. Modeling with Petri Nets
viously defined, an operational domain OD = (D, OP, PR) and To illustrate both the usefulness and the need for a formal tool
two functions,  and , which establish a relationship be- such as Petri Nets, Figs. 1 and 2 present two interpreted PN
tween the PN (or control domain) and the operational domain, specifications for automatic Line Reclosure (Fig. 1) and for
where: automatic Undervoltage Line Shedding and Restoration (Fig.
D is the set of states of the operational domain; 2). One other involved automatic control function for Under
OP = {op1, op2, … opr} is a set of operators opi : DD; frequency Load Shedding and Tie-line tripping is not shown
 = P  OP, associates an operator to each place over the for the sake of clarity, but it can be found in [6]. In these fig-
operational states; ures the dashed places are shared by more than one automaton.
PR = {pr1, pr2, … prs} is a set of logical predicates over D; For a better understanding of the improved features of these
automatic functions, we invite the reader to trace their beha-
prj = D  {true, false};
vior. For example, assume that in Fig. 1 the line protection
 = T  (PR,OP), associates an ordered pair (predicate, op-
starts and next opens the circuit-breaker (meaning that the fault
erator) to each transition of the PN.
was not cleared somewhere downstream and that the Circuit-
An interpreted Petri Net represents a system in which a state is
Breaker is fully operable). The automaton then runs a dead
the composition of the operational domain status with the ac-
time, which is a requirement to guarantee the fault path deioni-
tual marking of the PN. Graphically, the interpretation is
zation, and, if at the end of the dead time the CB is ok, the
represented by labels close to the circles (places) and bars
automaton will be ready to re-close it. However, on doing so,
(transitions). An interpreted safe Petri Net is equivalent to a
the automaton may find a forbiddance instead of an authoriza-
so-called Petri Net Controller, where sensors and actuators are
tion, in which case it will respond by resetting the forbiddance
bonded to predicates and operators, places represent condi-
and setting a ―transferred responsibility to close‖, returning to
tions, and transitions represent events.
sleep without reclosing.
Note that contrary to the rule for firing transitions, predicates
Now imagine that while the line is in its dead time following
on the operational domain are not formally controllable. They
the CB trip by its protective relay, there is a bus undervoltage
have only to be acknowledged by the control domain, although
condition, perhaps because an uncoordinated relay tripped
operations triggered by the execution of the PN are expected to
somewhere else. The automatic Line Shedding function (Fig.
lead to changes in the status of the operational domain.
2) will proceed to open the line, but will find it already open. It
A conflict between transitions is said to be a free choice if
will then keep holding a forbiddance to close the line while
each of those transitions has a single input arc; otherwise, the
waiting for the bus voltage to be restored, and after all the con-
conflict is of a non-free choice type. Both concurrency and
ditions to restore the line are met, the automaton will reset the
conflict can exist in a PN with only free choices, but not at the
forbiddance and return to sleep, leaving the line as open as it
same time. A situation where conflict and concurrency are
found it. This will not happen if instead of its forbiddance the
mixed is known as a ―confusion‖.
automaton finds a ―transferred responsibility to close‖ (set by
Certain properties of ordinary Petri Nets must be verified when
the Line Automatic reclosure), in which case it will restore the
they are applied to a control system:
Line as if it were shed by itself.
(i) deadlock-free - it is always possible to fire at least one
There is a similar logical communication design between the
transition from each reachable marking;
Undervoltage and the UFLS and restoration automata, in addi-
(ii) proper - from any reachable marking, there is a sequence of
tion to their involvement with the Line Reclosure automaton
transitions that leads to any other reachable marking, including
[6]. That is how this design improves on the traditional inter-
the initial one;
locking approach, which does not provide a final line restora-
(iii) safe - in each place, there is no more than one token, a re-
tion when all the conditions to do it are met. In addition, none
quired feature for a PN to be considered a Petri Net controller.
of the functions is ever locked by another, thus ensuring that
In addition to the previously mentioned properties of ordinary
each sequence of events always proceeds with its right timing.
Petri Nets, two other properties concerning the data part or in-
This is an important requirement, because events have a dif-
terpretation (labels) must also be verified for interpreted PNs:
ferent meaning depending on the time elapsed.
(iv) determinism - the conflicts that occur in an interpreted
It must be pointed out that the above schemas are simplified
Petri Net are always solved, which means that the predicates
views of the complete automata. Sequential sequences not in-
associated to conflicting transitions are disjoint.
volving inter-communication can be reduced to simple places
(v) determination - the operations associated to parallel opera-
or transitions without jeopardizing the reaching properties of
tions are compatible. Operations that cannot be performed si-
the original PN, given that ordinary PN modeling does not in-
multaneously cannot be associated to parallel operations.
volve time, which is left for the operational domain. Therefore,
Although the formal analysis of ordinary Petri Nets does not
some places and transitions in these reduced schemas are ac-
involve the operational domain, PN structural analysis sup-
IEEE PES TRANSACTIONS ON POWER DELIVERY TPWRD-00395-2010 3

Sleep state
Protective relay resets
Protective relay starts

waits CB opening
CB opens Time
Dead time out ends
waits
running CB not protective
All conditions to operable relay reset
Any condition restore load & Protective relay resets
to not restore time-out ends
CB free to
load ready to operate
reclose

Not possible OK
UFLS forbids UVLS forbids
Reclosing
Transfer to
UFLS Transfer to
UVLS

Fig. 1. Petri Net specification for automatic line reclosure

Sleep state

Line selected to be shed

CB opened
CB closed

CB opening

Time out ends CB opens

Waits conditions
waits CB to restore
CB not opening
operable
CB opens Line can be UVLS forbids Transfer
CB opened restored from AR
by UVLS

forbidden

OK OK
CB
closing

Fig. 2. Petri Net specification for automatic undervoltage Line shedding and restoration
 IEEE PES TRANSACTIONS ON POWER DELIVERY
tually abstract views of detailed sequences.
The complexity of the concurrency between these communi-
cating automata is now clear, as is the reason why it requires
the use of a formal modeling tool such as Petri Nets.
Note that in [4-7] Petri Nets have been used not to model the
implemented control system, but to specify it. Therefore, from
the perspective of its logical correctness, after the specification
is validated, the only remaining concern is that its implemen-
tation does not jeopardize the properties of the designed
model.
C. Implementation issues for Petri Nets specifications
At a detailed representation level, the automatic control func-
tions that have been presented can be considered mainly as
state machines with local conflicts. These state machines
communicate with each other through shared conditions in-
volved in confusions (as previously defined).
The implementation of state machines extracted from Petri
Nets can be done in a number of ways, either through hard-
wiring or software [11]. In the last few decades much work
has been published on methods and techniques to map Petri
Nets onto programming languages used in PLC, such as ladder
logic [12], and more generally according to the IEC 61131-3
standard [13], which supports a number of programming op-
tions. On the other hand, most modern multi-function protec-
tive relays offer, at minimum, some automation programming
tools such as control equations elements, Boolean operators,
binary elements and sequential devices, with a growing trend
to adopt the IEC 61131-3 standard. While computational effi-
ciency is an issue for the real-time implementation of large
PN-based automation systems [14], most of their industrial
achievements have been centralized in a single task running in
a single physical device, which coordinates the sequential
scheduling of the operational tasks. This was also the ap-
proach followed for Substations [5,7].
Regardless of how distributed the implementations of PN-
based automatic control functions are, a fully decentralized
and yet faithful solution for PN confusions has not been de-
vised so far. Fig. 3 illustrates why, with a portion of the pre-
viously shown PN (from Figs.1 and 2).
AR wants UVLS for-
to reclose bids closing
(CB ok * Voltage (stable voltage;)
(CB not ok;)
still unstable;)
Fig. 3. A typical confusion in the PN specifications for Substations
The confusion results from having two concurrent automatic
functions, Line Reclosure (AR) and Under-Voltage Load
Shedding (UVLS), involved in a conflict: either the voltage is
stable (which means that a time-out has confirmed it, a job
performed by the UVLS function of which the AR function is
not aware), or it is not. In addition, the AR function has its
own conditions to consider the circuit-breaker ready to close.
The conflict is determined by the complementary logic of the
operational conditions (in the transitions labels), but the point
is that the assessment of both the marking of the input places
TPWRD-00395-2010 4
and of the operational conditions has to be an atomic opera-
tion, whatever the decision turns out to be. On the other hand,
the firing of a transition does not have to be indivisible, but
first the booting of that firing (the reset of its pre-conditions),
and next its ending (the setting of its post-conditions), must
be.
III. IEC 61850 AND SUBSTATIONS AUTOMATIC CONTROL
IEC 61850 is a communication standard [8] developed to al-
low interoperability between devices from different manufac-
turers and to decouple the configuration engineering from
hardware and local network (LAN) details. To this end, the
names of functions are standardized by means of the so-called
'Logical Nodes' (LNs), which can be viewed as the smallest
part of a function that exchanges information.
It should be noted that IEC 61850 does not standardize func-
tions, but only names of functions. This means that the object
model defined by the standard is not complete, in the sense
that the inner behavior of an LN instance is not, in some cases,
inferred from its name.
Of course it would not be feasible for IEC 61850 to define
names for all the functions employed by utilities around the
world, so a trade-off solution has been adopted: a set of LN
classes for a representative group of protection and automation
functions are defined, together with rules to add new classes,
if needed. These are the so-called 'extension rules' and they
may be used to create new LN classes or new data classes for
existing LNs. If a new data object is created, its semantics
must be defined and documented, to keep it unambiguous.
Edition 2 of the IEC 61850 standard extends the former 90 LN
to a few hundred, already covering wind and hydro plants. A
detailed presentation of the application view of IEC 61850 can
be found in [15,16].
Among the 19 LN groups considered in its 2nd edition, IEC
61850 has definitions for a few automatic functions such as
Line Reclosure, but takes this as Protection-related, mirroring
how this function was usually hardwired in traditional protec-
tive relays, with no provision for direct interlocks. Interlocks
are considered in a specific class of LN, named CILO, which
acts directly on circuit-breakers. More complex automatic
UVLS
waiting
functions such as UVLD and UFLS and Restoration are men-
for stable tioned as examples of an LN class named as ―Generic Auto-
Voltage matic Process Control‖ (GAPC). The definition of GAPC (part
7-4 of [8]) includes a few status points (output information)
and some generic control inputs, but no mechanism that could
serve as a map for firing transitions in Petri Nets. Therefore,
the existing LNs in IEC 61850 do not provide direct support
for cooperative automatic process functions such as those pre-
viously presented.
On the other hand, the communication services considered in
IEC 61850 for peer-to-peer real-time fast data exchange are of
the ―annunciation‖ type. Those services are actually the GSE
and the GOOSE messages, suitable for real-time because they
bypass the MMS protocol suite and run directly on ISO 8802.3
Ethertype (part 8 of [8]). GOOSE are designed to be repeat-
edly sent after some output status of an LN changes, mirroring
what happens with the usual hardware ―annunciations‖ in
 IEEE PES TRANSACTIONS ON POWER DELIVERY
Substations and providing reliable signaling. However, they
do not support easy Petri Nets implementation, as it will be
shown in the next section. On the other hand, server/client ser-
vices such as Set_data and Get_data are implemented on
MMS and are usually too heavy for real-time automatic con-
trol, even in industrial environments less demanding than
Power Substations, and that is precisely the reason for the ex-
istence of GOOSE.
In the meantime, a new approach [17] proposes that the IEC
61850 environment be integrated into the more general frame-
work of an emerging new Automation standard, IEC 61499.
With this approach, LNs are mapped to Function Blocks, the
basic entities of this last Standard, which in addition provides
a set of logical operations (AND, OR, etc) to be programmed
into specific Function Blocks or to interconnect them, includ-
ing those representing protection functions. However, there
are still a few issues in this approach that need to be clarified,
specifically: a) the reliability of the described tight integration,
namely for the critical protective relaying functions; b) real-
time responsiveness, particularly for the Get_data/Set_data
communication services between different physical devices; c)
support from vendors of protective relays.
IV. IEC 61850 GOOSE MESSAGES AND PETRI NETS
To clarify why GOOSE, while providing fast real-time com-
munications, are not well suited to a direct and methodical im-
plementation of Petri Nets Controllers, we show in Fig. 4 a
Petri Net model for simple synchronization between two con-
current functions and in Fig. 5 a corresponding model for its
implementation through an exchange of GOOSE.
Fig. 4. A PN model for two functions that synchronize their beginning and
their end.
To initiate the synchronization, the first task sets a GOOSE,
signaling a request that was initially negated. The second task
acknowledges that GOOSE, but it cannot negate its value, as it
would be appropriate. However, it can send its own GOOSE,
which can be acknowledged but not negated by the first task
as it finishes its job, when it will negate its initial GOOSE, an
action modeled by resetting that GOOSE and setting its com-
plementary place. It is the test to THIS place that provides the
second task with the knowledge that the first one has finished
its job, for which it will reset its own GOOSE and will set its
complementary place. Of course, the complementary places
for the GOOSE only model a False value for the signaled
state.
TPWRD-00395-2010 5
The reason why the implementation of the synchronization
shown in Fig. 4 is so complicated in Fig. 5 is that ordinary Pe-
tri Nets are unable to test zero. To make a decision based on
the non-existence of a token in a place, or on the false value of
a condition, Petri Nets require a so-called complementary
place, which has a token when the other does not. This is a
fundamental limitation of Petri Nets, which some extensions
can solve; however, the price to pay for those modeling en-
hancements is the loss of the capability to prove essential for-
mal properties, which is the fundamental reason to chose Petri
Nets as a modeling tool.
Fig. 5. A PN model for the PN of Fig. 4 implemented through GOOSE.
Dashed places model GOOSE conditions
Implementing a Petri-Nets-based specification for a set of au-
tomata running in different physical devices by GOOSE-based
communications is a matter for future research. However,
from this example it will be clear that direct mapping is not
possible and that a new Petri Net will be required to model the
implementation itself.
V. MODELING PETRI NETS ON THE IEC 61850
STANDARD
From the previous considerations, a new data definition for the
IEC 61850 emerges as a proposal for Petri Nets implementa-
tion. The execution of the Petri Nets control domain will be
centralized in a special Function Block running on a dedicated
Controller, while the production of local logical predicates on
the Substation equipment states, including the status of protec-
tion functions, is decentralized to the remaining IED and
communicated through GOOSE. As a matter of fact that ―an-
nunciation‖ job is the GOOSE‘s true calling. Additional logi-
cal processing is required close to the Petri Nets controller in
order to compute global predicates on the local predicates pro-
duced throughout the Substation.
GOOSE will also be used to send commands to the circuit-
breakers through the other IED, where some predicates on the
equipment state can yield decentralized interlocks resulting
just from equipment data (operational domain).
 IEEE PES TRANSACTIONS ON POWER DELIVERY TPWRD-00395-2010 6

behavior. For instance, the CILO class (interlocking) will cer-

A. The general idea
tainly use function blocks to implement the interlocking equa-
This work included the following steps (as it is detailed in tions for the isolators and circuit-breakers.
later sections): TABLE I
- Decomposing the Petri Nets in communicating state ma- LOGICAL NODE CLASS
chines, which are executed by any of the many methods LOGICAL NODE class
available for that purpose, namely in the IEC 61131-3 pro- Attribute Name Attr. Type Value/value range/explanation
gramming languages or described by logical equations and FB [0..n] FUNCTION BLOCK
sequences, plus a PN Controller; The outputs of function blocks can be referred as data
- Encapsulating the elements of the Petri Nets into IEC 61850 attributes of Common data Classes (CDC). For instance, the
Function Block classes; Boolean data attribute stVal of the Single Point Status CDC
- Choosing the proper Logical Node Classes to accommodate can be a result of a function block that implements a logic eq-
the Function Blocks. uation.
Each automaton will reside in a Logic Node and will commu- Table II shows the formal definition of the function block
nicate with a special function, the arbiter, via ―set data‖/―get
class. The last two attribute types, Equation and StMach, are
data‖- like services. This communication runs into the same
the only ones that are not defined in the IEC 61850 standard
physical device and hence it involves software only, while the
and that we propose to define its behavior.
implementation of those services from a physical machine to
another will be as slow as it is nowadays. TABLE II
There must also be a mechanism with the purpose of giving FUNCTION BLOCK CLASS
FUNCTION BLOCK class
the Petri Net its initial marking.
Attribute
Attr. Type Value / value range / explanation
B. Modeling of the internal behavior of the new data Name
Instance name of a FUNCTION-
As previously stated, the IEC 61850 standard does not de- FBName ObjectName
BLOCK
scribe the internal behavior of logical nodes. As a conse- FBRef ObjectReference
Path-name of an instance of FUNC-
quence, and since the goal of this work is the distributed TION-BLOCK
Input [0..n] DataAttribute
implementation of automata specified by PN, the ordinary IEC
IntVar [0..n] DataAttribute Internal variables
61850 is not sufficient for that purpose. To overcome this Ouput [1..n] DataAttribute
limitation we suggest the creation of the necessary IEC 61850 Parameter [0..n] DataAttribute
classes to provide a formal way to define their behavior. Equation [0..n] EQUATION
The class intended for the representation of the logical nodes StMach [0..n] STATE MACHINE State machines
will be called function block. Fig. 6 shows the position of this Once the formal definition of the function block class has been
new class in the IEC 61850 data model hierarchy. established, the next step is to determine how to name the spe-
Server cific classes for the applications to be modeled, that is, the
specializations of the abstract class defined in Table II,.
First, it was decided to create a class FFB0, ‗function block
LD LD zero,‘ which will hold the common attributes related to the
logical node, in the same way the logical node class LLN0 ac-
commodates all common data regarding the logical device.
LN LN LN Fig. 7 shows how the specific classes inherit the structure of
the abstract class. The specific classes will be named in the
same way as the logical node classes, that is, with four letters,
Data FB Data the first referring to the function block group and the other
three being an abbreviation of the class purpose.
FB Abstract class, as
Data Data
Attribute Attribute defined in Table II

T
in Table II
LD = Logical Device
LN = Logical Node
FFB0
Fig. 6. Data model hierarchy including function block class.
Domain Specific
FBs
Consequently, the formal definition of the logical node class
presented in the part 7-2 of the IEC 61850 will have to be

added with the function block class, as shown in Table I.
The indication [0..n] means that a logical node may have an
arbitrary number of function blocks (including the value
‗zero‘). The existence or non-existence of function blocks in a
logical node will depend on the need for modeling its internal
a
Fig. 7. Function Block (FB) Relationship.
Each class will have a graphical representation, specifically a
rectangle in which the inputs and the outputs are represented
(inputs at left side and outputs at right). The interconnection
between the instances will be done graphically, with lines con-

b
 IEEE PES TRANSACTIONS ON POWER DELIVERY TPWRD-00395-2010 7

necting the outputs of one instance to the inputs of other in- APNP class
stances.
OpPrc = Mrk
A template, represented in Table III, will define each of the
specialized classes. TABLE VI
TABLE III TRANSITION CLASS
TEMPLATE FOR FUNCTION BLOCK CLASSES APNT class
CLASS_NAME class Attribute
Attr. Type Explanation T M/O
Attribute Name
Attr. Type Explanation T M/O
Name Inputs
Inputs
Prd BOOLEAN Predicate associated to the transition M
Name Type Description of inputs
Internal variables Reception of the request to set next places,
PrvMrk1 BOOLEAN M
Name Type Description of internal variables received from previous place 1
Outputs Reception of the request to reset previous
NxtUnmrk BOOLEAN M
Name Type Description of outputs places, received from next place 1
Parameters Outputs
Name Type Description of parameters MrkNxt BOOLEAN Request to set a next places M
Behavior
Equations and state machines defining the class behavior UnmrkPrv BOOLEAN Request to reset previous places M
Notes: OpPrc BOOLEAN Actuation over the operational domain T M
T = transient attribute
M/O = mandatory/optional attribute Parameters
OpPrcTms INT32 Duration of pulse OpPrc M
C. Modeling Petri Nets with free choices only
Behavior
Two classes of function blocks will be defined for describing
the Petri Net elements place and transition. MrkNxt = PrvMrk1* PrvMrk2* Prd
Table IV illustrates the creation of names for the classes mod- UnmrkPrv = PrvMrk1* PrvMrk2* NxtUnmrk1 * NxtUnmrk2 * Prd
eling places and transitions. The two following Tables V and OpPrc = Pulse with duration given in the parameter OpPrcTms after a tran-
VI outline the structural definitions for these classes. sition of MrkNxt from '0' to '1'
TABLE IV Another class must be created in order to generate an initia-
NAMES OF THE REQUIRED CLASSES lizing pulse. This will allow the initial marking: places corres-
ponding to the initial marking will be set while the others will
1st letter
Function 2nd to 4th letter be reset. Class FFB0 will be used for this purpose, since initia-
Function block group
Place A - Automatic control Petri Net Place lizing is an issue shared by the entire logic node.
Transition A - Automatic control Petri Net Transition It can be shown that the interconnection of the function blocks
TABLE V built on the defined places and transitions classes respects the
PLACE CLASS execution of state machines, so this is a suitable model to
APNP class represent an automaton specified by a Petri Net and residing in
Attribute one device.
Attr. Type Explanation T M/O
Name
D. Modeling the solver for Petri Nets confusions
Inputs
This section shows how a set of state machines will be inter-
StrMrk BOOLEAN Request to set the place, during initialization M
connected, assuming that they share one common place with
Request to reset the place, during initializa- outgoing transitions in a confusion situation, as in Fig. 8.
StrUnmrk BOOLEAN M
tion
Request to set the place, received from input Lcommon
PrvMrk1 BOOLEAN M
transition 1
Request to reset the place, received from out-
NxtUnmrk1 BOOLEAN M P1a P1b P1c
put transition 1
Internal variables
SetPlc BOOLEAN Set of the place M Ta Tb Tc

RsPlc BOOLEAN Reset of the place M

Outputs
P2a P2b P2c
Mrk BOOLEAN Place is marked M
Automaton Automaton Automaton
UnmrkPrv BOOLEAN Request for unmarking previous places M A B C

OpPrc BOOLEAN Actuation over the operational domain M Fig. 8. Interconnection between automata.

Behavior In this figure it can be seen that there is a possibility of si-

SetPlc = PrvMrk1 + PrvMrk2 multaneous firing transitions Ta, Tb and Tc (or two of them) if
the previous places of these transitions are marked; also, the
RsPlc = NxtUnmrk1 + NxtUnmrk2
corresponding predicates may vary according to uncontrolla-
 IEEE PES TRANSACTIONS ON POWER DELIVERY TPWRD-00395-2010 8

ble operational events. To overcome this problem, a mechan- Petri Net). The prefix of each instance will give the function
ism to guarantee a coherent evaluation of those conditions has semantic; as an example, the ‗Line Reclosure‘ function would
to be created, as explained in section II.C. This will lead to the be represented by an instance named LRCFPNT. The FPNT
formation of another function block, named arbiter, class is defined in Table IX.
represented in Table VII. The existence of the arbiter will The correspondence between the outputs of the function
cause changes in the transition class, represented in Table blocks defined previously and the data of the FPNT class is
VIII. given in Table X.
TABLE VII TABLE IX
ARBITER CLASS FPNT CLASS
Class APNA FPNT class
Attribute Attribute Attr.
Attr. Type Description T M/O Explanation T M/O
Name Name Type
Inputs LNName Shall be inherited from Logical Node class
Ask1 BOOLEAN Requesting signal for transition 1 M Data
Outputs Plc[p] SPS Place p of the Petri Net M
Ena1 BOOLEAN Enable signal for transition 1 M Trs[t] SPS Transition t of the Petri Net T M
Behavior Request n to mark the next place in another au-
NxtAut[n] SPS O
TABLE VIII tomaton
Request p to unmark the previous place in
TRANSITION CLASS - MODIFIED PrvAut[p] SPS
another automaton
O
Class APNT AskArb[a] SPS Request a for arbitration O
Attribute
Attr. Type Description T M/O EnaArb[e] SPS Arbitration enable e O
Name
Inputs GooseFlt SPS Fail in at least one incoming GOOSE message O

EnaArb1 BOOLEAN Enable signal from arbiter M TABLE X

CORRESPONDENCE BETWEEN FPNT AND FUNCTION BLOCKS
Outputs
FPNT Function block outputs
AskArb1 BOOLEAN Request for arbitration M
Plc[p] APNP/OpPrc
Behavior
Trs[t] APNT/OpPrc
AskArb = PrvMrk1 * PrvMrk2 * Prd
NxtAut[n] APNP/Mrk and APNT/MrkNxt
MrkNxt = EnaArb1 * EnaArb2
PrvAut[p] APNP/UnmrkPrv and APNT/UnmrkPrv
The arbiter function block has the function of the traditional
―token-player‖ algorithm in single-processor implementations. AskArb[a] APNT/Ask
It is a special entity required to ensure the correct solution of EnaArb[e] APNA/Ena
confusions. GooseFlt Logic sum of the negation of all FFB0/DataVld

E. Logical nodes used in the implementation
The next step is to define the logical node classes used to
model each one of the studied automata. These classes will
contain the previously mentioned function blocks.
First, we have to decide whether there will be a logical node
per transition and place or, instead, a logical node that will
group several places and transitions. Since a logical node ex-
ecuting a state machine can perform a meaningful function, it
was decided to associate a logical node to each automaton.
Then it must be decided whether the classes defined by the
standard are suitable for PN representation or whether there is
a need to create new classes according to the extensions rules.
The IEC 61850 does not consider any classes to model func-
tions defined by PNs, just a class for a generic application
GAPC.
So, a new logical node class will be created for the purpose of
modeling the Petri Net data. First, the logical node group for
this new class has to be chosen. In edition 2 of the IEC 61850,
the F group (logical nodes for functional blocks) were defined,
which are the option we propose. The class will therefore be
named FPNT (F = logical nodes for functional blocks, PNT
The data on the Petri Net evolution are mandatory, whereas
the data concerning interconnection between automata are op-
tional, since they do not apply if there are no communicating
automata.
VI. CONCLUSIONS
Petri Nets are a mathematical tool suitable for the specification
of cooperative automatic control functions, supporting en-
hanced features not provided by traditional interlocks, namely
the automatic power restoration of loads, which was not easy
to achieve with traditional methods without relaxing security.
Early implementations of automatic control functions de-
signed with Petri Nets in Substations were based on single-
processor environments. Modern Substation Automation Sys-
tems are now distributed, but the reliable resolution of con-
flicts involving concurrency in Petri Nets still requires a single
entity.
The IEC 61850 Standard defines a powerful distributed envi-
ronment for Substations, but its real-time services for peer-to-
peer communications, the GOOSE, are better suited for sig-
naling than for the mechanisms of PN synchronization. There-
 IEEE PES TRANSACTIONS ON POWER DELIVERY TPWRD-00395-2010 9

fore, in this work the GOOSE were considered only for ―an-
BIOGRAPHIES
nunciating‖ logical values of predicates on the states of equip-
ments and to perform operational commands; the execution of Pinto de Sá, J.L. (1951, SM 88) is a Professor of Elec-
trical Engineering at Instituto Superior Técnico in Lis-
the control logic by Petri Nets is centralized in a single device, bon, Portugal. He has worked in Substations advanced
even though they can be split into state machines and an arbi- automation since 1981. In the nineties he led the devel-
ter function. opment from scratch of multi-function protective relays
A new class, function block, has been proposed to describe the for EFACEC, and from 2001 to 2006 he was with LA-
BELEC as a coacher. His main research interests are in
behavior of the logical nodes. This class possesses mechan- Power Systems Protection, protective relaying and Subs-
isms for a formal definition of combinatory and sequential tations Automation.
functions.
Cartaxo, R. (1966) is a senior engineer at Rede
REFERENCES Eléctrica Nacional (REN), the Portuguese Transmission
System Operator. He works in its Automation Depart-
[1] J. Cladé, J. Miroux, J.M. Tesseron, L. Tourres, C. Corroyer, J. Kowali, ment and is involved in a joint project for 61850-based
"Recent Developments in Substation Control, Internal Communications transmission substations automation. Previously he
and Automatic Devices as Used in the French Distribution Network‖, pa- worked for 11 years in Substations Automation systems
per NP. 34-01, CIGRÉ Int. Conf. on L.H.V.E.S., September 1978. for EFACEC, a manufacturer of power and control
[2] K.P.Brand, J.Kopainsky, ―Principles and engineering of process control equipment for Power Systems. He holds a Master de-
with Petri Nets‖, IEEE Trans. on Automatic Control AC-33, 2, 138-149, gree in Electrical and Computer Engineering from In-
1988. stituto Superior Técnico.
[3] R. Zuraski, M. Zhou, "Petri Nets and Industrial Applications: a Tutorial,"
IEEE Trans. on Industrial Electronics, vol. 4, 6, pp. 567-583, Dec. 1994.
[4] J. L. Pinto de Sá, J. P. Sucena Paiva, "Design and verification of concur-
rent switching sequences with Petri Nets," IEEE Trans. on Power Deli-
very, vol. 5, 4, pp. 1766-1772, Oct. 1990.
[5] Ibid, "A multitasking software architecture to implement concurrent
switching sequences designed with Petri Nets," IEEE Trans. on Power
Delivery, vol. 6, 3, pp. 1058-1064, July 1991.
[6] J. L. Pinto de Sá, J. Damasio, "Coordination of automatic control func-
tions in transmission substations, using Petri Nets," IEEE Trans. on
Power Delivery, vol. 7, 1, pp. 262-268, Jan. 1992.
[7] A. Pita de Abreu, M. Fernanda Fernandes, ―Automation in Portuguese
Transmission Substations – a pragmatic approach‖, IEEE Trans. on
Power Delivery, vol. 8, 3, pp. 1088-1094, July 1993.
[8] IEC Communication networks and systems in substations, IEC Standard
61850, 2nd edition, 2008 to 2010.
[9] A. Carrapatoso, R. Cartaxo, F. Matos, A. Menezes, R. Paulo, ―Integra
project – applying 61850 technology‖, paper B5-106, CIGRE 2006
General Session, Paris, 2006.
[10] W.M.P. van der Aalst, Complete Overview of Petri Nets Tools Database,
[Online]: http://www.informatik.uni-hamburg.de/TGI/PetriNets/tools/complete_db.html
[11] R. Valette, M. Courvoisier, ―Systèmes de commande en temps réel‖ (in
French), Ed. SMC, Toulouse, France, 1980.
[12] S. S. Peng, M. C. Zhou, «Ladder diagram and Petri-Net-Based Discrete
Event Control Design Methods‖, IEEE Trans. on Systems, Men and Cy-
bernetics – part C: Applications and Reviews‖, vol. 34, 4, pp. 523-531,
November 2004.
[13] Programmable Controllers – Part 3: programming languages, IEC Stan-
dard 61131, 2nd edition, 2003.
[14] R. P. Moreno, J. L. Villarroel, ―Performance Evaluation of Petri Nets Ex-
ecution Algorithms‖, IEEE Intern. Conference on Systems, Man and Cy-
bernetics, (ISBN978-1-4244-0991-4), pages 1400-1407, 2007.
[15] C. R. Ozansoy, .A. Zayegh, A. Kalam, ―Object Modeling of Data and
Datasets in the International Standard IEC 61850‖,IEEE Trans. on Power
Delivery, vol. 24, 3, pp. 1140-1147, July 2009.
[16] Ibidem, ―The Real-Time Publisher/Subscriber Communication Model for
Distributed Substations Systems‖, IEEE Trans. on Power Delivery, vol.
22, 3, pp. 1411-1423, July 2007.
[17] N. Higgins, V. Vyatkin, N-K. C. Nair, K. Schwarz., ―Distributed Power
System Automation With IEC 61850, IEC 61499, and Intelligent Con-
trol‖, IEEE Trans. on Systems, Man, and Cybernetics—Part C: Applica-
tions and Reviews, vol. 41,1, pp. 81-92, January 2011.