Professional Documents
Culture Documents
IEC 61499 Function Block Model: Facts and Fallacies: IEEE Industrial Electronics Magazine January 2010
IEC 61499 Function Block Model: Facts and Fallacies: IEEE Industrial Electronics Magazine January 2010
net/publication/224089609
CITATIONS READS
34 542
1 author:
Kleanthis Thramboulidis
University of Patras
136 PUBLICATIONS 1,691 CITATIONS
SEE PROFILE
Some of the authors of this publication are also working on these related projects:
All content following this page was uploaded by Kleanthis Thramboulidis on 01 June 2014.
Abstract—Control and automation systems in factory automation are developed using the
procedural and the device centric paradigms. The always increasing complexity of systems in this
domain, as well as the need for agility, flexible plug-and-play extensibility and evolution, impose the
need for new paradigms to effectively address today’s requirements. The Function Block (FB) model
introduced by the international Electrotechnical Commission (IEC) 61499 standard is an attempt to
exploit current software engineering practices and the application-centric paradigm in the system’s
development process of this domain. In this paper, the current status of the standard is described and its
drafting process as well as its validation prior to implementation is commented. Facts and fallacies on
the 61499 FB model are presented and properly discussed to alleviate the confusion about the semantics
of the IEC 61499 FB model, which is one of the most important reasons that the industry has not yet
accepted the standard.
Index terms—IEC 61499, Function Block Model, Factory Automation, distributed control applications,
IEC61499 execution environment.
1. INTRODUCTION
The centralized control approach is the most commonly used in industrial systems
nowadays. The market is dominated by a small number of large corporations, which supply
97,5% of the market [1]. Their products and the corresponding proprietary tools used to
exploit these products are closed, with proprietary interfaces that do not support tool
integration not even the exchange of development time artifacts. Reuse across different
platforms is not supported.
The decrease of the hardware cost along with the increase in processing and
communication power makes the application of the distributed approach attractive. This
allows the distribution of intelligence on a network of interconnected processing nodes with
many potential advantages such as reduction in wiring, ability to build in additional fault
diagnostics and autonomy into the distributed elements. However, the design of new
distributed fault tolerant systems, represents a significant technical risk, which largely
originates, according to [2], from the increased level of complexity in the adoption of a
distributed system solution. It is also claimed that this increased complexity is perceived by
industry as higher development costs for a distributed system. Thus in order to make the
system affordable more emphasis is required on the utilization of Commercial Off-The-Shelf
technologies.
Even more, according to a survey on European companies reported in [3] the
development process of embedded systems, “is unsatisfactory and many years behind their
desktop counterparts.” It is also claimed that “currently used development technologies do
1
An extended version of this paper has been accepted for publication.
1/15
Only for personal use. An extended version of this paper has been accepted for publication.
19 Sept. 2008
not take into account the specific needs of ESs development”. It has also been accepted that
currently used technologies in the PC market cannot be utilized in the industrial systems
domain without properly specializing them.
The IEC61499 standard [4] is an attempt of the International Electrotechnical Commission
(IEC) to address the above issues, to open the industrial systems market and meet among
others requirements such as interoperability, portability, distribution, agility, run-time re-
configurability, higher availability and reliability. It is supposed to: a) facilitate exchange of
design information between designers and fabrication houses, and b) allow designers to
integrate competing vendors’ tools and reduce the risk of relying on proprietary languages
and data formats. Designers do not want to “be locked into a single vendor, nor do they want
products that tilt against or are insensitive to the benefits of free-market competition” [5].
However, even though the standard has been officially accepted by the year 2005 it is not
yet adopted by the industry [6,7] and its status in the academic research community is
questionable.
In this paper, the current status of the IEC61499 is examined. Its drafting process as well
as its validation prior to implementation is commented. An attempt is made to counter a
number of incorrect statements made in the literature about the way that the IEC61499
Function Block (FB) model should be implemented. Fact and fallacies are presented and
discussed, and solutions to various open problems are proposed to alleviate some of the
confusion about the execution semantics of the IEC61499 FB model, which is one of the
most important reasons that the industry has not yet accepted the standard. Motivations for
some of the design decisions already taken in our implementation of the standard are also
given. Our implementation which adopts the embrace-and-extend strategy [8] elaborates the
standard by adding extra functionalities.
The remainder of this paper is organized as follows. In the next section background work
is presented. Challenges in the system’s development process are presented and a brief
introduction to the IEC61499 function block model is given. Section 3, presents the current
status of the standard adoption process and focuses on the paradigm shift that is imposed by
the standard. In section 4, facts and fallacies on the 61499 FB model are presented and
properly discussed with more emphasis on the programming in the large support, location
transparency and run-time environments. Finally the paper is concluded in the last section.
2. BACKGROUND WORK
2.1. Challenges in the development of industrial automation systems
The always increasing complexity of today’s industrial automation systems imposes the
need for more effective development processes and toolsets. Current software engineering
practices and technologies can be exploited to address a number of challenges in the
development process that among others include the following:
• Distribution
• Interoperability
• Portability
• Reuse
• Move from the device-centric to application-centric paradigm.
To address these challenges the IEC has accepted the 61499 standard that defines the
Function Block construct as the main design level artifact for the specification of industrial
2
Only for personal use. An extended version of this paper has been accepted for publication.
19 Sept. 2008
systems. It also defines the concept of the Engineering Support System (ESS) that is a
toolset to assist the control engineer in the development process of this kind of systems.
3
Only for personal use. An extended version of this paper has been accepted for publication.
19 Sept. 2008
4
Only for personal use. An extended version of this paper has been accepted for publication.
19 Sept. 2008
5
Only for personal use. An extended version of this paper has been accepted for publication.
19 Sept. 2008
6
Only for personal use. An extended version of this paper has been accepted for publication.
19 Sept. 2008
following the Programming in the small paradigm. In fact as the size and complexity
increase, the design and specification of the overall system structure become more
significant than the choice of algorithms and data structures. By concentrating on the
structure of the industrial system will be possible to overcome shortcomings in current
engineering practices. A well-organized structure of the industrial system will reduce the
complexity; it will provide a better understanding of how the system works and also allow
the analysis of system’s properties without implementing it. A solid software architecture
will reduce complexity and thus will lead to a better understanding of how the system
works. So, the question is if the IEC61499 can be considered as a notation to define the
architecture of the system?
There is currently a trend in the 61499 community to consider the FB type as a
component. In [19] the authors referring to the “component model of IEC 61499” claim that
the “FB possesses the required characteristics of a software component,”. In [20] and [21]
the authors consider the IEC 61499 as a “high level architecture”. In [21] the FB type is
characterized as a “component with event and data interfaces”. It is also stated that “The
concept is analogous to the ideas of component, such as software component from software
engineering”. In [22] the FB is characterized as a “high level concept” and also as a
“component with a state machine inside.” The authors base this statement on the argument
that the FB type is not relying on a particular programming language, operating systems, etc.
However, adopting this argument we can also conclude that the ‘process’ construct of the
well known DFD notation is a component since is not relying on a particular programming
language and operating system.
To better understand the semantics of the FB notation a mapping of the FB type concept
to the well known and widely used in real-time system development DFD notation, is given
in Fig. 3. A detailed description of this mapping is given in [23]. From this mapping it is
clear that the interface definition of the new construct is too low level at least as far as the
data representation is concerned. The concept of the data flow is not adopted in the FB
model and instead of it a detailed representation of the constituent parts of the data flow are
represented, cluttering the design diagram with too much detail.
If we consider the current use of the FB construct we can see that it is mainly used, as for
example in [21,24], just to represent simple processes or functions. This is the approach also
7
Only for personal use. An extended version of this paper has been accepted for publication.
19 Sept. 2008
adopted for the construction of the basic library of FBDK. The example given in [21] that
uses the FB to represent the operation that calculates the expression X2 – Y2 is misleading
for the objectives of the FB model since it uses a construct defined for object representation,
to represent a function. This example can also be used as representative of the level of detail
that the IEC61499 introduces in specification. This is clear if one just compare this FB with
the method signature of the operation that implements the calculation OUT = X2-Y2, and
the method X2minusY2() of one of the provided interfaces of a component, as shown in Fig.
4. It should be emphasized that both the input and output events and data of the X2Y2_ST
FB type are the equivalent of the specification of just one method of a provided interface of
a component. Moreover, FBs that implement operations as the above mentioned cannot be
considered as components in a component based development. It should be noted that it is
not the graphical representation that makes a design level construct component but its
semantics. This is why the process construct of the DFD notation is not a component.
The interface definition of FB types is usually defined in a way that does not include
semantic information. Instead of it the interface of a component has to define the operation
provided. For example, the graphical interface of the X2Y2_ST FB type, with input event
REQ, data inputs X and Y, output event CNF and output data OUT, provides no information
on the operation represented. The name REQ used also to identify the algorithm has no
information on the specific algorithm. The example implementing X2-Y2 as a network of
function blocks given in [21] further confirms our argument.
The FB type is also used by ISaGRAF, the first commercial implementation of
IEC61499, to represent a process that was traditionally represented by an 1131 function
block. However, for a commercial tool this can be considered as an intermediate step to
simplify the paradigm shift in the industry from the procedural 1131 to the object-based
61499 paradigm. The shift from the purely procedural 1131 to the object based 61499 would
not be possible if such an intermediate level is not provided, since industrial engineers are
not familiar with the concepts of object and component. This problem can be compared to
the paradigm shift from the procedural to the object-oriented paradigm in the PC domain,
where C++ allowed an intermediate level shift. In a first step many programmers used C++
just to program in a procedural way following a smooth shift from the procedural paradigm
to the OO one.
8
Only for personal use. An extended version of this paper has been accepted for publication.
19 Sept. 2008
The advantages of the Platform Independent Model (PIM) in the system’s development
process are well known [27]. The PIM should describe the software system, which supports
a part or the whole of the industrial process system, in a highly abstract way that is
independent of any implementation technology. It should model the system from the
perspective of how it best supports the industrial process without including decision on the
type of technology on which the PIM will be implemented. The platform specific model
(PSM) will later describe in detail how the PIM will be implemented on a specific platform
or technology.
IEC61499 introduces the Service Interface FB (SIFB) to be used in the FB network to
implement event and data transfer over the network. The use of the SIFB in the design
diagram complicates the FB network diagram and makes it a PSM. However, according to
[20] an application “completely captures the desired functionality but does not include any
knowledge of the devices and their interconnections;” and it continues “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.”
Even though the authors refers to “data transfers”, no reference is done to the event transfer
that is explicitly implemented according to the standard using the SIFB concept that
completely destroys the location transparency, since it makes the design diagram closely
related to the specific hardware configuration. The authors also state that the application
“Potentially can be mapped to many possible configurations of devices.” However, this is
not easy for an FB network containing SIFBs, since a re-engineering of the FB network is
required to fit into a new configuration of the distributed environment. In [21] authors claim
that the FB network “completely captures the desired functionality but does not include any
knowledge of the devices and their interconnections.” Authors also cite the TORERO
project stating that “suitable automatic mechanism to find the best map between FBs and
9
Only for personal use. An extended version of this paper has been accepted for publication.
19 Sept. 2008
devices, in terms of memory consumption and application temporal performance, has been
proposed by the European project TORERO.” However, the proposed FBALL algorithm
[28] is criticized in [29] for its correctness. In [20] it is also claimed that “the TORERO
development environment automatically generates the needed communication.” However,
there is no proof that this environment has been ever developed.
To exploit the benefits of PIM, the design diagram should be defined for a target
technology-neutral virtual machine. This virtual machine that is shown in Fig. 5 is called
IEC61499 virtual bus and is defined as a set of parts and services which should be defined
independently of any specific platform. It include parts, as FB type container and FB
instance container, and services that provide the functionality of SIFB, Management FBs,
event FBs, etc. This virtual machine (bus) will be next realized in platform-specific ways on
different execution platforms. A prototype for this proposal has already been developed and
performance measurements show that it satisfies stringent real-time constraints [30].
It is clear from the above that the component based application approach should be
adopted, in order for the run-time environment to fulfill the objective of the standard that is
to support run-time reconfiguration. However, most of the existing or under evolution run-
time environments adopt the monolithic application approach. For example in [22] for the
implementation of a function-block compliant device a run-time environment is not used,
but the transformation of the FB based specification to the device’s OS is proposed.
10
Only for personal use. An extended version of this paper has been accepted for publication.
19 Sept. 2008
should not influence the design of the FB types and FB network diagrams, or either wise
there is no need for the designer to know the specifics of each run-time environment. The
whole design should be based on the semantics of the virtual machine. This means that the
execution semantics of FB instance and FB network should have been clearly defined by the
standard in a platform independent way. It should have been defined in such a way that the
design models be detailed and precise enough to produce fully executable models and
permit the automatic generation of the implementation models in the form of efficient code
that can be executed on specific run-time environments. The FB design models should be
behaviorally expressive and rigorous as well as intuitive and well structured. Unfortunately
the standard fail to rigorously define the semantics and this makes the development of run-
time environments a very hard task. This is also a source of incompatibility between the
different platforms as far as the execution of applications is concerned.
Since the IEC61499 standard is intended to be used by control engineers in specifying
distributed control systems, clarity and simplicity should be considered as key parameters
for deciding upon execution semantics. The control engineers should be able to understand
how the created models work in a relatively intuitive way. So the semantics have to be rich
enough to support different styles of modeling and at the same time to be simple and
intuitive.
There are several proposals regarding the execution of the FB instance and FB network.
Some of these have already provided a reference implementation; others are just specs
without reference implementations not even a theoretical proof of concept. This makes the
development of run-time environments a very hard task. This sub-section discusses on these
proposals with the objective to identify pros and cons that can be later used to complement
the standard in the direction of execution semantics.
The standard introduces many sources of confusion regarding the execution semantics.
One example is the so called ECC operation state machine that is supposed to define the
dynamics of ECC. Actually this state machine defines the dynamics of the FB instance; the
behavior of the FB instance is defined by the ECC of the corresponding FB type. The ECC
operation state machine is the source of confusion in FB instance execution. In [21] for
example it is claimed that “The execution of the FB_Receiver will be done by invocation of
its Execution Control Chart.” However, before invoking the ECC the FB instance has to
read input data and update event input (EI) variables. Also after the execution of ECC,
actions such as clear EI variables should be executed. The standard describes the dynamics
of the FB instance even though it does not provide any representation of it in the form of a
statechart. The statechart shown in Fig. 6 was constructed to clearly describe the dynamics
of the FB instance, as close as possible to the one described by the standard, for the case that
the FB instance is implemented as ‘active’. An FB instance may be defined at PIM or PSM
as ‘active’ or ‘passive’. An active FB has its own thread of execution, while a passive FB
has not its own thread of execution; it is executed by other threads. In this latter case the FB
instance is usually implemented as a monitor. It is clear that the assumed at the design level
behavior for the FB instance should be the same in both cases. The same behavior should
also be ensured for the case of an event-based implementation or a cycle-based one.
The execution semantics of the FB instance that are considered so far as undefined by the
standard can be classified in three categories:
a) queuing or losing of input events;
b) scheduling function; and
c) event processing policy.
11
Only for personal use. An extended version of this paper has been accepted for publication.
19 Sept. 2008
As far as the first issue is concerned, statechart semantics imply the use of an event-pool
that means that there is no loss of event. The concept of the scheduling function and the
concept of resource are not clearly defined by the standard and this is one of the biggest
problems for the development of a run-time environment. It is clear that the given
definitions are greatly influence by 1131 and are in contrast to the meaning of the
corresponding terms in software engineering. Our proposal is to avoid both concepts [31]
and use a) the term FB container to partially support the assumed by the resource
functionality, and b) the OS scheduler, when scheduling of FB instances is required.
Regarding the event processing policy both the first come order, or the priority based
order can be considered. However, to obtain a more efficient response to safety critical
events the priority based order was adopted. According to the UML statecharts adopted
policy, the state machine processes one event at a time and finishes all the consequences of
that event before processing another event, a policy known as run-to-termination. However,
the FB type definition and especially the definition of event input (EI) variables, and their
use in transition expressions favours a policy influenced by the cycle-based implementation
approach, where all pending input events are candidates for processing. Events from the
event queue will be transferred to the EI variables that are to be consumed based on their
priority.
The problem of the undefined transition evaluation order that rises when the trigger
expressions of two transitions starting from the same state are simultaneously fulfilled, a
situation that leads to non-determinism, can be easily handled by the definition of the
“evaluation-order priority” that explicitly defines the evaluation order on the PSM [31]. The
concept of negated trigger event [32] can also be used to address this problem. The standard
assumes as order of execution the order of transitions in the XML specification but this is a
source of ambiguity.
Many assumptions made last years in the 61499 community in the process of defining the
execution semantics are erroneous, without proof of concept, which could be either a
reference implementation or clear theoretical basis, and thus create confusion in the domain.
A detailed discussion of the above issues can be found in the original paper.
12
Only for personal use. An extended version of this paper has been accepted for publication.
19 Sept. 2008
5. CONCLUDING REMARKS
The market of industrial systems needs open solutions. Distribution, interoperability,
portability, run-time reconfiguration are open issues that have to be addressed in the
development process of today’s complex industrial process systems. IEC61499 is here to
provide some solutions. However, it is clear that this standard has been influenced very
much from the 1131 standard and fails in successfully exploiting current software
engineering practices. It also has many ambiguities and open issues; the requirements
elicitation phase as well as the architectural design phase have to be addressed. This is why
a major revision is required for the standard to be seriously considered by the industry. A
reliable reference implementation is required to demonstrate the applicability of the standard
and also validate the concepts behind it.
Since the standard attempts to introduce at the same time two paradigm shifts, the one
from the procedural to the object-based, and the other from the device-centric to the
application-centric, a very long time is required for its adoption from industrial engineers.
Experiences from the procedural to the object-oriented paradigm shift in the PC domain can
be exploited to ease this paradigm shift. ISaGRAF that follows a quite similar approach as
the one adopted by C++, that is to allow the developer to apply the old paradigm using the
new constructs may be probably the intermediate step for this steep paradigm shift in
industrial process software systems.
REFERENCES
[1] B. Heck, L. Wills, and G. Vachtevanos, Software Technology for Implementing Reusable, Distributed
Control Systems, IEEE Control Systems Magazine, February 2003.
[2] Thompson, H.A., D.N.Ramos-Hernandez, K. Cartledge, J. Fortune, A. Brown, Flexible control systems
development and integration environment for distributed systems, UKACC Control 2006 Mini Symposia,
Glasgow, UK, 31 Aug. 2006.
[3] Graaf, B., M., Lormans, H., Toetenel, Embedded Software Engineering: The State of the Practice, IEEE
Software, November/December 2003, vol. 20, no. 6.
[4] International Electro-technical Commission, (IEC), International Standard IEC61499, Function Blocks,
Part 1 - Part 4, IEC Jan. 2005.
[5] M. Tiemann, An objective definition of open standards, Computer Standards & Interfaces 28 (2006) 495–
507
[6] K. Thramboulidis, IEC 61499 in Factory Automation, Advances in Computer, Information, and Systems
Sciences, and Engineering, Proceedings of IETA 2005, TeNe 2005, EIAE 2005,
[7] A. Zoitl, T. Strasser, K. Hall, R. Staron, C.K. Sünder, B. Favre-Bulle: The Past, Present, and Future of
IEC 61499, 3rd Intern. Conf. on Industrial Applications of Holonic and Multi-Agent -Systems, HoloMAS
2007, Regensburg, Deutschland.
[8] T.M. Egyedi, Standard-compliant, but incompatible?!, Computer Standards & Interfaces 29 (2007) 605–
613.
13
Only for personal use. An extended version of this paper has been accepted for publication.
19 Sept. 2008
[9] C. Tranoris, K. Thramboulidis, A tool supported engineering process for developing control applications,
Computers in Industry, Volume 57, Issue 5, June 2006, Pages 462-472
[10] T. Strasser, I. Müller, M. Schüpany, G. Ebenhofer, et al., An Advanced Engineering Environment for
Distributed & Reconfigurable Industrial Automation & Control Systems based on IEC 61499, Intelligent
Production Machines and Systems, 2006, Pages 493-498.
[11] J. Chouinard, Lavallée, D., Laliberté, J., Landreaud, N., Thramboulidis, K.,et al. An IEC 61499
configuration with 70 controllers; challenges, benefits and a discussion on technical decisions, Available
on-line: http://www.isagraf.com/pages/documentation/whitepapers.htm
[12] Panjaitan, S., G. Frey, “Functional Control Objects in Distributed Automation Systems”, Workshops on
Intelligent Manufacturing Systems (IMS’07), Alicante, Spain, 23-25 May, 2007.
[13] K. Soundararajan, R. W. Brennan, Design patterns for real-time distributed control system benchmarking,
Robotics and Computer-Integrated Manufacturing, Volume 24, Issue 5, October 2008, Pages 606-615
[14] R.W. Brennan, P. Vrba, P. Tichy, A. Zoitl, C. Sünder, T. Strasser, V. Marik, Developments in dynamic
and intelligent reconfiguration of industrial automation, Computers in Industry, Volume 59, Issue
6, August 2008, Pages 533-547
[15] International Electrotechnical Commission. IEC International Standard IEC 61131–3:2003, Programmable
Controllers, Part 3: Programming Languages, 2003
[16] ISO/IEC Directives, Part 1, Preparation stages for standards, Available on line:
http://www.iec.ch/ourwork/stages-e.htm
[17] K. Thramboulidis, Using UML in Control and Automation: A Model Driven Approach, 2nd IEEE
International Conference on Industrial Informatics, 24-26 June, Berlin, Germany, (INDIN´04).
[18] K. Thramboulidis, S. Sierla, N. Papakonstantinou, K. Koskinen, An IEC 61499 Based Approach for
Distributed Batch Process Control, 5th IEEE Inter. Conf. on Industrial Informatics (INDIN 07), July 23-
27, 2007, Vienna, Austria.
[19] Sunder, C. et al. Usability and Interoperability of IEC 61499 based distributed automation systems, 4th
IEEE Inter. Conf. on Ind. Informatics (INDIN 06).
[20] V. Vyatkin, V. Dubinin, Sequential Axiomatic Model for Execution of Basic Function Blocks in
IEC61499, 5th IEEE Inter. Conf. on Ind. Informatics (INDIN 07), July 23-27, 2007, Vienna, Austria.
[21] V. Vyatkin, Victor Dubinin, Carlo Veber, Luca Ferrarini, Alternatives for Execution Semantics of
IEC61499, 5th IEEE Inter. Conf. on Ind. Informatics (INDIN 07), July 23-27, 2007, Vienna, Austria.
[22] V. Vyatkin, Victor Dubinin, Execution Model of IEC61499 Function Block based on Sequential
Hypothesis, Available on-line at : http://www.ece.auckland.ac.nz/~vyatkin/o3fb/vd_seqsem.pdf Accessed
at 3 Oct 2007.
[23] K. Thramboulidis, A model based approach to address inefficiencies of the IEC61499 function block
model, 19th Int. Conf. on Software and Systems Engineering, Dec. 2006, Paris, France.
[24] J. P. Peltola, J. H. Christensen, S. A. Sierla, K. O. Koskinen, A Migration Path to IEC 61499 for the Batch
Process Industry, INDIN 07, July 2007, Vienna, Austria.
[25] Szyperski, C., Component Technology – What, Where, and How?, 25th Inter. Conf. On Software
Engineering (ICSE’03).
[26] Rumbaugh, J., I. Jacobson, G. Booch, The Unified Modeling Language Reference Manual, 2nd edition,
Addison Wesley 2005.
[27] Richard Soley and the OMG Staff Strategy Group, Model Driven Architecture, White Paper, Draft 3.2 –
November 27, 2000, Available on-line: ftp://ftp.omg.org/pub/docs/omg/00-11-05.pdf
[28] A. Prayati, C. Koulamas, S. Koubias, and G. Papadopoulos, A methodology for the development of
distributed real-time control applications with focus on task allocation in heterogeneous systems, IEEE
Trans. Ind.Electron., vol. 51, no. 6, pp. 1194–1207, Dec. 2004.
[29] K. Thramboulidis, Comments on “A Methodology for the Development of Distributed Real-Time Control
Applications With Focus on Task Allocation in Heterogeneous Systems”, IEEE Transactions on Industrial
Electronics, vol. 54, no. 2, April 2007.
[30] G. Doukas, K. Thramboulidis, A Real-Time Linux Execution Environment for Function-Block Based
Distributed Control Applications,3nd IEEE International Conference on Industrial Informatics, Perth,
Australia, August 2005, (INDIN´05).
[31] K. Thramboulidis, G. Doukas, IEC61499 Execution Model Semantics, International Conference on
Industrial Electronics, Technology & Automation, (CISSE-IETA 06), Dec. 4-14, 2006.
[32] Von der Beek, A comparison of statechart variants, In Formal Techniques in Real-Time and Fault-
Tolerant Systems, L. de Roever and J. Vytopil, Eds. Lecture Notes in Computer Science, vol. 863, 128–
148.
14
Only for personal use. An extended version of this paper has been accepted for publication.
19 Sept. 2008
15
View publication stats