Execution Model of IEC61499 Function Block
based on Sequential Hypothesis
Valeriy Vyatkin, Victor Dubinin
Disclaimer:
This paper summarizes two talks given by V. Vyatkin at INDIN and ETFA
conferences in 2006. It is intended to be submitted to a journal (somewhere
sometime) but may undergo substantial modifications until then. For the time being,
if you wish refer to it please do it as follows:
V. Vyatkin, V. Dubinin, Execution Model of IEC61499 Function Blocks based on
Sequential Hypothesis, paper draft, private communication
Your critical comments will be very much appreciated!
Abstract
This paper advocates an execution model of IEC 61499 which implies purely
sequential execution of function blocks within a resource. Implementation of this
model apparently is less resource demanding than of other execution models. Most
importantly, an attempt is made to base this execution model on very few rules
derived from the standard’s text.
I.
INTRODUCTION
The function block architecture of the IEC 61499 standard is being discussed in the
automation community for several years. In 2005 it has been finally standardized as
an open component-based architecture for industrial process measurement and
control systems [1]. The IEC 61499 architecture allows complete description of
distributed embedded systems within its framework. The core elements of this
architecture are: function blocks – an encapsulation model, application, device – a
deployment model, and system – a collection of interconnected devices with
applications deployed to them. The standard, however, allows for ambiguous
interpretation of function block execution rules, see [7, 9, 5] for details.
This paper discusses an execution model of function blocks which is based
on the assumption of sequential execution of such blocks within a single
computational container (resource in IEC 61499 terminology). This assumption
is referred to as sequential hypothesis. The idea of sequential execution is not
invented in this paper – it has been discussed earlier, for example, in [4], [5] and
[6] and even was partially implemented in compilers and run-time platforms.
This paper attempts to justify this approach as the most grounded by the letter
and spirit of the IEC 61499. Having said this, we admit that there could be good
reasons in favor of other execution models. Their implementation and use,
however, require explicit definition of the assumptions taken and of the
amendments made to the standard, to avoid any confusion and to enable
portability of function block applications. Such an approach would increase the
credibility of the standard and would simplify understanding of the functional
block concept by application developers.
The paper is structured as follows. In Section II the IEC 61499 architecture is briefly
introduced. In Section III we attempt to show, what an implementation of the
function blocks may include and point out some issues with the semantic rule
definitions in the Standard’s text. In Section IV the success metrics and challenges
for implementation of this architecture are outlined. In Section V we look more
specifically into the issue of event passing, and event-driven activation of a function
block. Section VI discusses the issue of transition evaluation in basic function blocks
using an example. In Section VII the most essential rules of a function block
execution model are presented in form of six postulates. Section VIII discusses first
four postulates influencing the rules of basic function block evaluation. Section IX
shows that the postulates 5 and 6 naturally lead to the sequential hypothesis – an
execution model with purely sequential invocation of function blocks within a
network. Section X proposes an informal implementation idea of this sequential
model. Section XI discusses benefits and shortcomings of the sequential model and
outlines an alternative, ‘parallel’ model of execution. The paper is concluded with
summary outcomes and acknowledgements.
II. MAIN FEATURES OF IEC 61499
The development of the IEC61499 architecture was started around 1995 with a goal
perceived as a narrow means of interconnecting Programmable Logic Controllers
(PLC) and of software applications running in them. However, it has gradually
evolved in a more flexible and elegant concept providing for a function based and
hardware independent design of distributed automation systems. The IEC 61499
architecture provides answers to several questions like:
- How to re-use efficiently the intellectual property developed in automation
projects?
- How to make controllers more intelligent yet predictable and reliable?
The IEC61499 architecture is based on several pillars, the most important of
which is the concept of a function block. The concept is analogous (but not identical)
to the idea of a software component. The distinction becomes clearer now with the
proliferation of hybrid hardware/software co-design technologies. This concept is
high level (i.e. is not relying on a particular programming language, operating
systems, etc.). The same time it is precise enough to capture the desired function
unambiguously.
A. Component with event and data interfaces
The desire was to encapsulate the behavior inside the block defining clear interfaces
between the block and its environment. This intends to improve the re-use potential
of the component.
B. Component with a state machine inside
State machine is a simple visual yet mathematically rigorous way of capturing
behavior. It is widely used in computer applications. In IEC 61499 basic function
block a state machine (called Execution Control Chart, ECC for short) defines the
reaction of the block on input events in a given state. The reaction can consist in
execution of several algorithms computing some values as functions of input and
internal variable, followed by emitting of one or several output events.
C. Model of a distributed system
The function block concept of IEC61499 implies two stage design process
supported by the corresponding artifacts of the architecture: applications and system
configurations. An application is a network of function block instances
interconnected by event and data connections. It completely captures the desired
functionality but does not include any knowledge of the devices and their
interconnections. That is why an application usually does not include function blocks
implementing data transfer over networks, as well as other hardware-dependent
functions, like reading of input signals. Potentially it can be mapped to many
possible configurations of devices. A system configuration adds these fine details,
representing the full picture of devices, connected by networks and with function
blocks allocated to them. Each device (or more precisely, each resource of a device)
is populated by a network of function blocks which is a part of the original
application. Technically, such a network is an application as well (that however
includes service interface function blocks).
D. Shortcomings of the standard
The trial use of IEC61499 has revealed that the standard has no means to define:
−
−
−
Real-time properties of applications, such as desired reaction time;
Real-time properties of resources, their scheduling, polling of data by SIFBs
and communication;
Properties of algorithms (like periodic, one off, etc.)
III. IMPLEMENTATION OF FUNCTION BLOCKS
A vague idea in the beginning of the standard’s development process was to create
an abstraction for a PLC populated with some programs and participating in a
network with other PLCs.
As the concept has been evolving, the idea has been very much influenced by
the pioneering work of Dr. James Christensen who has shown how to execute
function blocks directly in Function Block Development Kit (FBDK) on Function
Block Runtime execution environment (FBRT) [2], that is implemented using Java.
The concept of function block is quite abstract. It assumes that the function
blocks are executed by compliant devices. Implementation of an IEC 61499
compliant device on a particular platform (that is a combination of hardware (CPU
and peripherals), an operating system, and a particular programming language),
requires translation of the function block to this language or its interpretation by
another program that can run on the given platform. Thus, we understand
implementation of function blocks as a mapping of the IEC61499 artefacts to the
constructs of a particular platform as illustrated in Figure 1.
Figure 1. Implementation of a function-block compliant device requires platformspecific translation of function blocks to executable code.
While the ultimate goal of an implementation is to produce correctly working
executable code, doing it for a variety of devices may require a lot of efforts. This
explains the choice of JAVA for the first trial implementation of function blocks.
JAVA possesses certain attributes of platform independence, so it is enough to define
mapping of function blocks to JAVA structures (classes). JAVA provides further
platform independence, as it runs on different operating systems and different
hardware architectures. However, JAVA brings also overheads, such as nondeterminism, slower execution, and excessive memory requirements.
Figure 2. Java-based implementation of function blocks provides for easier
development of compliant devices on account of Java’s platform-independence.
The idea of direct execution of function blocks implies that specification of
their execution semantic can be done without references to the underlying
platforms.
Unfortunately, in the previous publications on this topic, e.g. [2, 4] the execution
semantics of the function block formalism has been often confused with particular
properties of platform dependent implementations, mainly FBDK and JAVA. To the
best of the authors knowledge, the first attempt to propose a pure function block
semantic definition was done in [8, 9] followed by an application example in [10].
These works, though incomplete, prove that the standard provides definitions that are
sufficiently deep to talk about direct execution of function block applications and,
therefore, about execution semantics of this formalism.
The idea of independent semantic definition leads to the introduction of an
intermediate level of abstraction between the function blocks syntax and details of a
particular platform, as illustrated in Figure 3. By defining a platform independent
semantic model of function blocks much richer variety of device platforms can be
targeted, also those which do not support JAVA or where using JAVA is not practical.
Figure 3. Reaching platform independence by defining an intermediate semantic
layer.
However, many authors have pointed out, that the picture of execution model
provided by the standard is incomplete and, sometimes, self contradictory.
Nevertheless, the standard is a serious normative document and it shall be
carefully analysed in order to derive correct execution model according with
standard’s letter and spirit. Our experience shows that semantic definitions in IEC
61499 can be related to one of the following classes:
A. Well defined semantic properties of function blocks;
B. Elements of the semantic that are present in the standard explicitly, but
scattered around the text;
C. Semantic-relevant definitions that are present either implicitly or
completely left ‘implementation-dependent’. In some cases conclusions can
be made by analogy.
What is the way to define such an execution model then? A feasible approach
would be:
•
•
•
Implement cases A in a more formal way than it is done in the standard;
Collect and collate cases (B);
Suggest interpretation of the issues (C) not contradicting with the cases (A)
and (B);
As a result, a complete execution model of IEC61499 can be developed. The
model can be described formally or even semi-formally. An attempt to formal
description, although yet incomplete, has been shown in [9].
Due to the ambiguity and incompleteness of the standard, an explicit execution
semantic of function blocks is important for many reasons. In fact any
implementation implies an implicit development of a semantic. Explicitly defined
complete and consistent execution model would enormously contribute to the
credibility of the standard, and improve such performance metrics, such as
portability of function block applications and determinism of their execution.
In subsequent Sections we provide examples of dealing with cases of all three
classes. This way we prepare the reader to applying similar kind of reasoning when
discussing the Sequential Hypothesis.
IV. CHALLENGES
Industrial automation systems specified and implemented using the directly
executable function blocks of IEC61499 need to exhibit the following properties:
A. Determinism
A deterministic Function Block application gives same outputs for same inputs
in the same state at every run. If determinism is guaranteed for any application, does
it hold for any system? Apparently this is not necessarily, as the underlying
communication mechanism can, for example, toggle the order of messages, and
cause different outputs as a result.
B. Reactivity
The classic definition of reactivity [3] can be applied to Function Block
Applications as follows: an application eventually emits some output (reaction) after
an input stimuli. This, however, requires explicit definition of the correspondence
between inputs and outputs, which is not always obvious.
A stricter requirement is to give the reaction within certain time interval. A
Function Block Application gives output for an input stimuli within some time
interval.
Suppose we can determine explicit correspondence between input and output
events. In this case an application is said to preserve event sequence if reaction on
the first event occurs before reaction on the second.
C. Portability
A Function Block Application is portable if it gives same outputs for same
inputs being executed on any compliant run-time platform and device. Portability is
one of targeted key features of IEC 61499.
Achieving these properties is the main challenge for
implementing standard’s compliant devices, compilers and tools.
engineers
V. WHERE EVENTS COME FROM AND WHAT HAPPENS WHEN AN EVENT ARISES?
Implementation of the concept of event (and of event connection between blocks) is
the most confusing in the standard.
Function blocks have event and data inputs and outputs that constitute their interface.
Events are emitted by function blocks and are passed from an event output of one
block to event input of another by means of event connections. This is illustrated in a
simple example in Figure 4,a .
a)
b)
Figure 4: a) An example of two function blocks connected by event and data
connections; b) Illustration of a single run of FBT2.
What happens when an event ‘arrives’ at its destination? Some code gets executed
until an exit point is reached as illustrated in Figure 4, b. This activity will be
referred to as a single run of a function block. Which exactly code will be executed
during the single run is determined by the block’s ECC. According to the standard a
run ends when there no more transitions to clear in the ECC.
Implementation of the event passing mechanism raises a number of questions, for
example:
- How not to loose an event and what if event is lost?
- What is the minimum time interval between events?
- If a block issues two events simultaneously – which one ‘arrives’ to the
destination first?
- What if an event arrives when the destination function block is busy?
What literally happens in the example above is described in the Standard (Section
“Composite function blocks/Behavior of instances”) as follows:
“…occurrence of an event at the event output of the first block shall cause the
scheduling of an invocation of the execution control function of the second block,
with an occurrence of an event at the associated event input of the second block.”
From this rule one can conclude that the event receiver FB_Receiver will be
executed sometime after the event has been emitted by FB_Emitter (the word
‘scheduled’ suggests that it not necessarily should happen immediately). The
standard does not set any restrictions on the time when it should happen. The
execution of the FB_Receiver will be done by invocation of its Execution Control
Chart.
The behaviour of a basic function block upon occurrence of an input event is
described by the famous Table 1 in 5.2.2 whose (partial) copy is presented below in
Figure 5.
State
s0
s1
s0
t2
t1
s1
t4
s2
t3
s2
Transition
t1
t2
t3
t4
Condition
Invoke ECC
No transition clears
A transition clears
Actions completed
Operations
--Evaluate
transitions
Perform actions
Operations
Sample inputs
Figure 5. Table 1 from [1], 5.2.2, defining the ECC operation state machine.
VI. EXAMPLE-I: ORDER OF TRANSITIONS EVALUATION IN BASIC FUNCTION BLOCKS
The problem discussed in this Section is important for implementation of basic
function blocks as it concerns the rules of ECC evaluation.
Let us consider a basic function block in Figure 6 reacting on event EI1 when both
Boolean inputs COND1 and COND2 have values true. The current state of the ECC
is STATE1. The question is: which out of two transitions STATE1 → STATE2 or
STATE1 → STATE3 to clear in this situation?
Figure 6. Basic function block.
Let us see, what the standard says about this case. First of all, the famous Table 1 in
Section 5.2.2 “Basic Function blocks/ Behaviour of Instances”, remark c) says that:
“The order in which the transition conditions are evaluated corresponds to the
order in which they are declared following the textual syntax defined in Annex B.2.1,
or equivalently in the XML syntax defined in IEC 61499-2”
One thing what this sentence suggests clearly and unambiguously is that we
won’t be able to determine the transition to clear looking only at the graphical
notation of ECC. Its text source or XML source is required. Besides, the reference to
order in XML is not a very good idea, since by its nature XML is not supposed to
carry any information in the order of its elements (a better idea would be to add an
explicit transition order parameter).
Function block editing tools could add to the confusion. As illustrated in Figure 7,
even the function block editor of FBDK would produce the same graphical
representation of ECC for transitions differently ordered in XML. Transition
STATE1 -> STATE3 is the first in the list in the left screenshot and is the second in
the right screenshot. So, these two ECCs will have different behaviour in the
situation described in this example, but they would look the same graphically.
a)
b)
Figure 7. Function Block Editor of FBDK produces identically looking ECCs which
will have different behaviour.
First conclusions:
1. Semi-formal description of execution model for basic function block execution
is provided in the standard.
2. The description is sufficiently unambiguous and can be used directly for an
implementation, however, it contains references to the issues bringing potential
ambiguity (order of transitions in XML).
VII. POSTULATES
A few assertions regarding the execution of function blocks can form an axiomatic
basis of its execution model. It would be wise to keep this set of postulates as small
as possible. We assume that all other properties of an execution model can be
derived from the postulates. Altering one or several postulates can give us
completely different execution model. Theoretical study of this approach in general
and of this set of postulates in particular is very much encouraged.
At this stage we suggest the following set of postulates:
Table 1: Postulates critical for the function block execution model
#
1
Statement: A Function Block can be activated only by an event occurrence at
its event input
Roots in the standard: Implicit, derived from 5.3.2#3:
“…occurrence of an event at the event output of the first block shall cause the
scheduling of an invocation of the execution control function of the second
block, with an occurrence of an event at the associated event input of the second
block.”
Comment: This refers to Basic and Composite blocks. Service Interface
Function Blocks (SIFBs) can be activated from within, by internal events of the
resource, e.g. timer interrupts, external signals, etc. These, however can be
specified explicitly when the SIFB is created.
3
4
Statement: Execution (a single run) is a critical section
Properties of a single run of a basic FB
2
Roots in the standard text: Explicit, by remark e) to the Table 1 in 5.2.2:
e) All operations performed from an occurrence of transition t1 to an
occurrence of t2 shall be implemented as a critical region with a lock on the
function block instance.
Comment: We interpret it as: “A function block run” cannot be preempted by
another function block run. It could however be preempted by resource to
register external events and put them in the queue.
Statement: A single run of a basic function block is “short”
Roots in the standard text: Implicit
Comment:
Statement: Event input of a function block clears after single ECC transition,
regardless of was this event used in the evaluation or not
Roots in the standard: Added
5
Statement: Output events are issued immediately after the corresponding action
is completed
Roots in the standard text: Implicit
6
Statement: If a function block emits several output events in one state of ECC,
they are emitted sequentially
Roots in the standard text: Partially follows from the postulate 5 and other
explicit definitions
So far there have been different semantic ideas tried in research
implementations. The NPMTR model (“Non-Preemptive Multi-Threaded Resource”)
is implemented in FBRT. Sequential semantic was discussed in [4] and [6] and
implemented in run-time platforms µCrons and FUBER respectively. Semantic
based on PLC-like scan of inputs followed by subsequent re-evaluation of FB –
network was developed in [12, 13]. The essential difference of these three
approaches is in the way how blocks in the network are activated which depends on
the way of event passing, determined by the postulates 4 and 6.
VIII.
PROPERTIES OF SINGLE RUN
A. Reference to event inputs
Postulates 1-4 relate to the properties of a single run. These properties depend on the
way of treating input events, e.g. their references in ECC transition conditions.
According to the Standard the names of event inputs can be used in the conditions of
transitions:
Each EC transition shall have an associated Boolean condition, equivalent to a
Boolean expression utilizing one or more event input variables, input variables,
output variables, or internal variables of the function block
This definition clearly allows several event input names to be used in one condition.
On the other hand, as pointed out in syntax of conditions formally defined in BNF in
Annex B.2.1 (and is normative by Note "c" of Table 1, 5.2.2) and shown in Table 2
allows at most one event variable name.
Table 2. Excerpt from Annex B.2.1
ec_transition_condition ::= event_input_name
| guard_condition
| event_input_name ('&' | 'AND')
(guard_variable | '(' guard_condition ')')
guard_variable ::= input_variable_name
| output_variable_name
| internal_variable_name
<Shall be of BOOL type>
guard_condition ::= expression
<as defined in IEC 61131-3>
<Shall evaluate to a BOOL value>
The reasons of that discrepancy are explained in [15] as follows:
In particular guard_variable cannot contain an event_input_name,
so the implication is there (but not the explicit statement) that neither can the guard
condition contain an event_input_name. Furthermore, at the provisions for
algorithm invocation in 5.2.2 there is no longer any provision for an event input
state machine; therefore, there would be no way to use an event input name to
represent its "state". The conclusion one should draw is that "events are not stateful"
(although the process underlying the propagation of events may have states such as
"blocked") and that the Working Group forgot to go back and modify 5.2.1.3#8 after
changing everything else to get closer to a subset of Harel State Charts.
The issue of how many event input names to allow in a condition reflects the
fundamental shift from the FB model in which event input variables could have been
stored and ‘used’ many times, to the model where an event is just a cause of an FB
invocation and disappears after that. However, the interpretation of event variable
names proposed in NPMTR seems to be inconsistent and counterintuitive. This is
further illustrated in the next Section.
B. Example-II: How long an event is alive?
Let us consider another issue relevant to the implementation of the event processing
in a basic function block: how long information about event remains active inside a
basic function block? (And, by the way, shall the same policy apply (whatever it is)
in service interface function blocks?).
Continuing the same example, we found that after the EI1 event the transition
State1-> State3 will happen. Shall the run stop in State 3? Since the transition
condition from State 3 to State4 is true, it can follow the transition State1->State3, as
illustrated in Figure 8.
a)
b)
c)
Figure 8. Shall the run started in State 1 by EI1 continue until State4 or it stops at
State3?
Answer to this question depends on whether the EI1 variable remains true after
the transition State1-> State 2 occurred? To find it out we again shall read the
standard.
The rules for the input events “clearance” are not defined in the standard in
sufficient detail. The famous Table 1 ([1], Section 5.2.2) contains no clue on when
EI1 shall be true and when it resets to false. This gives some freedom in the
implementation leading to implementations with potentially different behaviour of
the same function block application. However, it is interesting to note that the earlier
drafts of the standard, e.g. Publicly Available Specification (PAS) released in 2002
[IEC61499 PAS, 2002], contained more details on the event clearance. The PAS was
using a Boolean latch variable for every input event. The rules were defined when to
set and when to clear this variable.
In the final version of the standard it was chosen to omit these definitions. The
reasons are explained in [5] as follows:
The “event latching” model was removed to avoid the combinatorial complexity of
application states … intent of the Standard: events not relevant to control of
algorithm execution are discarded.
Additional explanations were provided in [11] as follows:
“… in the older drafts an event input was modelled as a bistable state machine
whose state could be represented as a Boolean variable. Quite complex rules were
defined for when the variable could be "cleared" which as … research showed could
lead to unanticipated complexity and unsafe conditions. The FBRT never even
implemented that model.
Event inputs are no longer modelled that way. An event is now consistently
modelled as an "instantaneous occurrence" throughout the architecture. So there is
no such thing as "clearing an event" because it is never "set". One might think of the
event as a single pulse on the transition line…”
Although we support this argumentation, still event variables can be used in
conditions of ECC transitions, so formal rules need to be defined (when to set
and when to reset them) in order to resolve the question illustrated in this
example. It has nothing to do with combinatorial complexity of event latch
implementation or with the length of queue needed to store unprocessed events
arrived during execution of the function block.
The suggested answer form the postulate #4 – an input event can be used at most
once. Arrival of event activates the function block and leads to evaluation of ECC
conditions going out of the current ECC state even if this event is not used in any of
these conditions. This interpretation is consistent with the spirit of event as
instantaneous occurrence.
C. Example-III: What to do with ‘not Eventful’ Transitions?
In this example we considering a function block having the same interface as the
previously used “Sample’ but with different ECC inside as shown in Figure 9. The
block receives two events, one with both COND1 and COND2 equal to false, and the
other when both inputs became true, as illustrated in Figure 9,b.
a)
b)
Figure 9 . (a) ECC of function block and (b) timing diagram describing its input sequence.
It is clear that upon the first occurrence of EI1 the ECC will transfer from State 1 to
the State 2. The question is how the next event will be interpreted?
For example, the new version of the function block development kit (FBDK)
released in March, 2006 has the execution semantics following the NPMTR
approach [5] described as follows [14]: “…transitions containing no events will only
be evaluated once, at the completion of an EC state. So if you have any EC states
with no "eventful" transitions, you have to be able to guarantee that at least one (and
preferably only one) guard condition will be true upon completion of the State.
Otherwise the ECC will freeze in the culpable state.”
So, in that version of FBDK the ECC would not react on the second occurrence
of EI1 at all. In our view this is a counter-intuitive interpretation, as the state
machine in the Table 1 ([1], Section 5.2.2) explicitly implies three things:
1. Function block is activated by an input event
2. Input data variables associated with the input event are sampled at every
occurrence of that event.
3. ECC is evaluated at every input event.
So, it is difficult to see why ‘not eventful’ should not be interpreted the same
way as ‘eventful’ and get evaluated causing subsequent ECC transition?
IX. SEQUENTIAL HYPOTHESIS
th
The 6 postulate defines the behaviour exemplified in Figure 10. We believe that the
spirit of the 6th postulate implies the execution model which we further refer to as
“Sequential hypothesis”. Removing the 6th postulate will imply a possibility of
parallel function block execution within one resource. This model may also look
quite feasible and is implementable. However, we believe that it does not accord well
to the letter and the spirit of the standard. Argumentation in favour of the 6th
postulate is as follows.
Let us consider example in Figure 10. FB0 is activated by event input EI
and DI in that moment is TRUE. The run of FB0 will consist of STATE2 and
STATE3. When the ALG1 is completed and EO1 is to be issued, the question is if
the FB1 will be activated immediately or after the run of FB0 is completed? Then, in
STATE3, the question is whether to issue EO2 right after ALG2 is completed or wait
until ALG3 completes and issue EO2 and EO3 together? In the latter case, shall FB2
and FB3 shall be started simultaneously? Answers to these questions are determined
by postulates #5 and #6.
Figure 10. Run of FB0 consists of passing through STATE2 and ending in STATE3,
issuing EO1, EO2 and EO3.
Although the Standard leaves unanswered the issue when the output events of a
Basic FB are issued, three options are possible:
1) Output event is emitted immediately after the corresponding algorithm in
the action is completed;
2) After all actions of a state are completed;
3) After the single run of the basic FB is completed.
The interpretation 3) was explicitly present in the previous drafts of the standard but
was discarded. According to that interpretation, events EO1, EO2 and EO3 in our
example should be emitted together at the end of the run.
From that we conclude that the interpretation 3) is less attractive than 1) and 2). The
interpretations 1) and 2) are not different in the order of generated events and can be
only different in their timestamps.
We adopted the interpretation 1) which forms the Postulate #5.
As for the states with several actions, the Standard says explicitly that the
actions associated with an ECC state are executed sequentially, one after another.
Following the spirit of Postulate#5 it is quite logical to assume that in a single state
output events shall be executed immediately after the corresponding algorithm
completes, i.e. sequentially with respect to each other. This forms the Postulate #6.
Both these postulates imply that there is no such thing as concurrent execution
of function blocks within a single resource, or pre-emption of one block by another.
Indeed, what happens after an output event is emitted, is defined by the clause 3
in 5.3.2 as follows:
If an event output of a component function block is connected to an event input
of a second component function block, occurrence of an event at the event
output of the first block shall cause the scheduling of an invocation of the
execution control function of the second block, with an occurrence of an event at
the associated event input of the second block.
From that one can conclude that even though output events can be emitted during a
function block run, their recipient will not be started immediately, but will be just
scheduled and started after this run is completed. As a consequence of the Sequential
Hypothesis the following assertion can be made:
Proposition 1:
In a resource there is no more than one non-SIFB function block is in the run
state at any moment of time.
Remark. The sequential Hypothesis essentially relies on the Postulate 3. If the
algorithms are not short, that could lead to unnecessary delay in invocation of
already scheduled blocks, which could be counter-intuitive.
X. HOW TO IMPLEMENT THE SEQUENTIAL HYPOTHESIS
A. Informal implementation algorithm
Implementation of the sequential hypothesis requires further details as follows:
-
-
Emitting an event by a function block means request to the scheduler of the
resource to pass the event to the destination function block. The scheduler
ensures that two or more event inputs of a basic FB or SIFB never occur
simultaneously;
A resource (FB scheduler) maintains the queue of external events and can be in
one of two states (see the state machine in Figure 11 and the description in Table
3):
o Receptive to external events in SIFBs;
o Not receptive to external event in SIFBs (when executing FB). When
an event arises in such a state it is stored in a FIFO queue. The queue is
processed in the next receptive state of the resource.
Table 3: Description of the resource state machine operation
State/
Transition
S1
Description
Check if the queue of external events is not
empty
While the queue is not empty
For each event :
Take (and remove) it from the queue;
Activate the recipient SIFB and pass the
events arising from its execution to the
FB scheduler of the resource;
Figure 11: State machine
of resource operation;
S2
t1
t2
FB Scheduler selects next FB from its queue
and starts its execution
Queue of scheduled blocks is not empty
Scheduled block completed its execution
B. Example: Implementation of the Sequential Hypothesis
Let us consider a network of function blocks shown in Figure 12. The network is
allocated to a device that has single resource.
Figure 12. Function block network activated by an external event through block SIFB_S
The device has one input channel which is polled by the function block SIFB_S.
Arrival of an external event at this channel causes activation of the rest of the
network. The execution process is illustrated in Figure 13.
Figure 13. Timing diagram representing activity of blocks in the network.
Scheduling of block activations and registration of arrived external events is
implemented using two queues of First-In First-Out kind (FIFO): Scheduling FIFO,
further referred to as Queue 1 and SIFBs FIFO, referred to as Queue 2. Queue 1
stores the events passed from a block to another block. Queue 2 stores occurrences of
external events that occur while the resource is in the non receptive state S2. It is
needed to ensure the processing of input events will follow the order of their
occurrence. In our example, the network is activated by arrival of an external event
to the input channel Ev. Arrival of an external event interrupts the execution of a
function block which is preempted by execution of the resource, which places the
corresponding request to the Queue 2. This can be seen in case of the execution of
FB_C. Pre-emption of the FB_C execution by the Scheduler after the second
occurrence of Ev does not contradict the 3rd postulate as no other FB is executed
while the pre-emption occurred, so the integrity of the FB network evaluation is not
affected.
When resource returns to the receptive state it checks if the Queue 2 is not
empty and adds the request of kind r → S to the Queue 1, clearing the Queue 2. Then
it takes next request from the top of Queue 1 and executes the corresponding
function block (that is target of the request, i.e. in case of request r → S the service
interface block S is executed.)
Remark: In a more general case the queues 1 and 2 may not necessarily be FIFO but
just sets of requests where scheduler places the requests and from where it selects an
event to activate next function block.
XI. HOW GOOD IS THE SEQUENTIAL HYPOTHESIS FOR A SYSTEM DEVELOPER?
Benefits of the Sequential Hypothesis for application developer are:
- more predictable model of execution in terms of reaction time and invocation
sequence;
- requires less resources i.e. will lead to potentially more efficient
implementations:
o direct call invocation in NPMTR model requires stack space and
context switching;
o can be implemented in one thread;
-
allows customisation for handling real-time constraints, and other priority
mechanisms;
The question of “How good is this model for developers” can be answered only
after certain trial period of using the tools and devices that comply with this semantic
model. The most popular at the moment FBDK/FBRT follows different semantic
(NPMTR), so the final comparison is yet to be made. However, there is a possibility
of an alternative semantic which could allow for parallel execution of function
blocks.
As illustrated in Figure 14, splitting an event connection to two or more blocks
(left side), is currently interpreted as implicit E_SPLIT block (right side), that leads
to sequential scheduling of FB2 and FB3 under Sequential Hypothesis.
Figure 14. Event fork can lead to parallel execution of function blocks.
However, the event fork in Figure 14 can be interpreted by many developers as
parallel invocation of FB2 and FB3, and this vision is quite intuitive. The main
reason to think about sequential execution of function blocks is the sequential nature
of modern computers. The function blocks are not necessarily to be implemented as
sequential software code, they could be compiled into hardware form, where it is
only natural to work in parallel.
The parallel execution of function blocks within a resource can be achieved by
modifying Postulates #5 and #6, for example as follows:
Postulate #5’ Output events are issued immediately after the corresponding
action is completed. The destination function block is invoked right after the event is
issued.
Postulate#6’ If a function block emits several output events in one state of ECC,
they are emitted simultaneously.
With this set of postulates our execution model becomes Parallel Hypothesis,
whose discussion, however is beyond the scope of this paper. We acknowledge that
there could be good reasons in favour of Parallel Hypothesis, such as:
- better fit to the ‘not so short’ algorithms assumption;
- more intuitive in ‘event-forking’ situations;
- better fit to multi core hardware implementation;
However, at this stage we see that Sequential Hypothesis is the best grounded by the
current text of IEC 61499 and shall be adopted as the base of its complete execution
model.
XII. CONCLUSIONS
The Sequential Hypothesis advocated in this paper is better grounded by the spirit
and letter of IEC61499, than the most widely used NPMTR semantics of function
blocks. It promises more predictable and less resource-consuming run-time behavior.
The sequential model is especially suitable for blocks with short algorithms, such as
rungs of ladder diagrams.
XIII.
ACKNOWLEDGEMENTS
The authors are grateful to James Christensen, Partha Roop, Yoong Li Hsien, José
Lastra, Alois Zoitl, Christoph Sünder and all other colleagues for valuable comments
and ideas.
XIV.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
REFERENCES
Function blocks for industrial-process measurement and control systems - Part
1: Architecture, International Electrotechnical Commission, Geneva, 2005
Function
Block
Development
Kit
(FBDK),
http://www.holobloc.com/doc/fbdk/index.htm
Z. Manna and A. Pnueli. Models for reactivity. Acta Informatica, 30:609--678,
1993
Zoitl A., Grabmair G., Auinger F., and Sunder C. Executing real-time
constrained control applications modelled in IEC 61499 with respect to dynamic
reconfiguration, 3rd IEEE Conference on Industrial Informatics, Proceedings,
Perth, Australia, August 2005
C. Sünder, A. Zoitl, J. H. Christensen, V. Vyatkin, R. Brennan, A. Valentini, L.
Ferrarini, K. Thramboulidis, T. Strasser, J. L.Martinez-Lastra, and F. Auinger:
Usability and Interoperability of IEC 61499 based distributed automation
systems, 4th IEEE Conference on Industrial Informatics (INDIN 2006),
Proceedings, Singapore, 2006
G. Čengić, O. Ljungkrantz, and K. Ǻkesson, “Formal Modeling of Function
Block Applications Running in IEC 61499 Execution Runtime,” in 11th IEEE
International Conference on Emerging Technologies and Factory Automation
(ETFA), Prague, September 2006.
L. Ferrarini and C. Veber, Implementation approaches for the execution model
of IEC 61499 applications, 2nd IEEE Conference on Industrial Informatics,
Proceedings, Berlin, June 2004.
V. Dubinin, V. Vyatkin “Formalized definition and modelling of IEC 61499
function block systems”, Letters of Tertiary Education Institutions, Volga
region, Russia, Penza State University Publishers, 2005, N 5, pp.76-89
V. Dubinin, V. Vyatkin, Towards a Formal Semantics of IEC 61499 Function
Blocks, 4th IEEE Conference on Industrial Informatics (INDIN’2006),
Singapore, 2006
V. Dubinin, V. Vyatkin, H.-M. Hanisch, “Using Prolog for Modelling And
Verification of IEC 61499 Function Blocks and Applications”, 11th IEEE
Conference on Emerging Technologies and Factory Automation (ETFA 2006),
Proceedings, Prague, 2006
J. Christensen, private communication, October, 2005
L. Ferrarini, M. Romanò, and C. Veber, Automatic Generation of AWL Code
from IEC 61499 Applications, 4th IEEE Conference on Industrial Informatics
(INDIN 2006), Proceedings, Singapore, 2006
J. LM Lastra, L. Godinho, A. Lobov, R. Tuokko, An IEC 61499 Application
generator for Scan-Based Industrial Controllers, 3rd IEEE Conference on
Industrial Informatics, Proceedings, Perth, Australia, August 2005
J. Christensen, remark on the execution semantic in the new version of FBDK,
2006, March, - private communication.
J. Christensen, remark on transition condition syntax and its impact on event
clearance, 2006, October, - private communication.