The IEC 61499 Standard:

Concepts and R&D Resources

James H. Christensen
INDIN03 - 2002-08-20
[email protected]
http://www.rockwell.com
http://www.holobloc.com
1
The IEC 61499 Standard

1. Architecture
2. Design Patterns
3. R&D Resources

2
 What is IEC 61499?

• A standardization project of IEC Technical Committee 65

(TC65) to standardize the use of function blocks in
distributed industrial-process measurement and
control systems (IPMCSs).
• Work item approved 1991; assigned to Working
Group 6 (WG6) 1993
– Experts from USA, Germany, Japan, UK, Sweden,
France, Italy
– Also responsible for IEC 61131-3 (Programmable
Controller Languages) and 61131-8 (Programmable
Controller Language Guidelines)

3
 IEC 61499 Status

• Part 1, Architecture
– PAS (Publicly Available Specification), 2000
– Standard => 2004
• Part 2, Software Tool Requirements
– PAS 2001 => Standard 2004
• Part 3, Application Guidelines
– TR (Technical Report) => 2003
• Part 4, Rules for Compliance Profiles
– PAS 2002 => Standard 2005

4
 Function Blocks:The Architectural Dialectic

Centralized
Programmable
Configurable

PLC
IEC 61131-3 agility! dynamically
Thesis distributability reconfigurable
= agile !
Common
Function Blocks Architecture
Synthesis Reference
IEC 61499
Model
distributed
Antithesis programmability configurable
DCS agility! programmable
IEC 61804
Distributed
Configurable

5
 Agile Manufacturing Requirement:
Dynamic Reconfiguration
• The Vision (Iacocca Institute, 1991)
– Production to Order
– Lot/Batch size > 1 Unit
– "Information intensive, reprogrammable, reconfigurable,
continuously changeable"
• Physical Reconfiguration
– Modular Machines and Workcells
– Distributed Automation
• Logical Reconfiguration
– Dynamic Reorganization of Control Plans
– Minimum Human Intervention (zero preferred)
– Maintain Configuration Control
• Not just Parameterization
– Leads to Large, Complex Software Modules
– Reduces Distributability, Flexibility, Reliability

6
 Architectural Co-Evolution

IEC 61499 Holonic Manufacturing Systems (HMS)

• Parent organization: IEC • Parent organization: IMS
• Working group: TC65/WG6 • Working group: HMS Consortium
• Goal: Standard model (function • Goal: Intelligent manufacturing through
blocks) for control encapsulation holonic (autonomous, cooperative)
& distribution modules
• Started: 10/90 • Feasibility study: 3/93-6/94
• Active development: 3/92 • First phase: 2/96 - 6/00
• Trial period: 2001-03 • Second phase: 6/00-6/03
• Completion: 2005

Requirements
Controls architecture
Intelligent Automation architecture

7
 Intelligent Systems: Requirements of
The IP Value-Add Chain
•Intellectual Property (IP) Operational
•Development Expertise
Industrial
•Deployment = Reuse + Enterprises Software
Distribution + Integration Components
Integration
System Expertise
Integrators Software Intelligent
Design Patterns Enterprise
Components
+ Software Tools Machine
Tools/Methods/ Machine Expertise Intelligent
Standards Vendors Software
Components Systems
Expertise
Tool/ Software Intelligent
Service Components Machines
Vendors
RTOS/Standards Device Device Intelligent
Expertise Vendors Expertise Devices

Runtime Hardware
Platforms Components

8
 Architectural Requirements
• Component-Based
– Support encapsulation/protection of Intellectual Property (IP)
– IP Portable across Software Tools and Runtime Platforms
• Distributed
– Map IP modules into distributed devices
– Integrate IP Modules into distributed applications
• Functionally Complete
– Control/Automation/Diagnostics components
– Machine/Process Interface components
– Communication Interface components
– Human/Machine Interface (HMI) components
– Software Agent ("Holonic") components
• Extendable
– Encapsulate new types of IP
– Create new IP through Functional Composition of existing IP modules
• OPEN!
– Multiply the value of IP through widest possible deployment
– Benefits available to all market players
9
 What is an Open Architecture?
• An architecture whose functional units are capable of exhibiting
portability, interoperability and configurability:
– portability: Software tools can accept and correctly interpret
library elements produced by other software tools.
– interoperability: Devices can operate together to perform the
functions specified by one or more distributed applications.
– configurability: Devices and their software components can be
configured (selected, assigned locations, interconnected and
parameterized) by multiple software tools.
• architecture: The structure and relationship among functional units in
a system.
• functional unit: An entity of hardware or software, or both, capable of
accomplishing a specified purpose.
10
Requirements for an Open Distributed Architecture

Software
Tools

Project PORTABILITY Software

Repository Libraries

CONFIGURABILITY

INTEROPERABILITY

Distributed intelligent devices & machines

11
 IEC 61131-3 Function Blocks:
Component-Based Encapsulation and Reuse

DEBOUNCE
BOOL IN OUT BOOL
TIME DB_TIME

External Interface Specification

Control Algorithm Specification

ON_TMR
OFF_TMR
TON IN OUT
TON
IN IN Q |/| (R)
DB_FF IN Q
PT ET
DB_TIME PT ET
SR
OFF_TMR S1 Q1 OUT
ON_TMR
TON R
IN Q IN TON OUT
|| IN Q (S)
DB_TIME PT ET
DB_TIME PT ET

Examples: X2Y2S, X2Y2S_ST

12
IEC 61499 Basic Function Block Types:
Encapsulation and Reuse
Event inputs Event outputs

Execution
Control
Chart

Type identifier

Algorithms
(IEC 1131-3)

Internal
variables

Input variables Output variables

Examples: X2Y2_FBD, X2Y2_ST, X2Y2_J, X2Y2_J2, STACK_INT

13
The Execution Control Chart (ECC):
An Event-Driven State Machine

EC initial state
START

1 INIT EX 1

EC action
INIT INIT INITO MAIN EX EXO event
EC state algorithm

14
 Functional Composition and Reuse:
IEC 61499 Composite Function Block Types
Event inputs Event outputs

Execution
Control

Type identifier

Input variables Output variables

Example: X2Y2

15
 IEC 61499 Service Interface Function Blocks
• Access to Resource functionality, e.g., I/O, HMI, comms
• Modeled as sequences of service primitives per ISO TR 8509
INIT INITO EVENT EVENT INIT INITO EVENT
EVENT
REQ CNF EVENT EVENT RSP IND EVENT
EVENT

INITIATOR RESPONDER
BOOL QI QO BOOL BOOL QI QO BOOL
ANY PARAMS STATUS ANY ANY PARAMS STATUS ANY

RD_1 ANY ANY SD_1 RD_1 ANY

ANY SD_1
: : : : : :
: :
ANY SD_m RD_n ANY ANY SD_m RD_n ANY

(application-initiated transactions) (resource-initiated transactions)

application resource application resource
INIT(+) INIT(+)

PARAMS startService PARAMS startService

INITO(+) INITO(+)
STATUS STATUS

IND(+)
readInputs
REQ(+)
writeOutputs
SD_1,...,SD_m RD_1,...,RD_n

CNF(+)
readInputs STATUS
RSP(+)
RD_1,...,RD_n writeOutputs
SD_1,...,SD_m
STATUS

INIT(-) INIT(-)

endService endService
INITO(-) t INITO(-)
STATUS STATUS

Examples: OUT_EVENT, OUT_BOOL, OUT_COLOR Examples: IN_EVENT, IN_BOOL, RADIO_BOOL

16
IEC 61499 Communication Service Interfaces:
Publish/Subscribe Model
EVENT INIT INITO EVENT EVENT INIT INITO EVENT
EVENT REQ CNF EVENT EVENT RSP IND EVENT

PUBLISH_m SUBSCRIBE_m
BOOL QI QO BOOL BOOL QI QO BOOL
ANY PARAMS STATUS ANY ANY PARAMS STATUS ANY
ANY SD_1 RD_1 ANY
: : : :
ANY SD_m RD_m ANY

INIT(+)
PARAMS
INITO(+)

~ INIT(+)
PARAMS
INITO(+)

REQ(+)
SD_1, ..., SD_m IND(+)

~
RD_1, ..., RD_m
CNF(+) RSP(+)

Example: m=1

17
IEC 61499 Communication Service Interfaces:
Client/Server Model
EVENT INIT INITO EVENT EVENT INIT INITO EVENT
EVENT REQ CNF EVENT EVENT RSP IND EVENT

CLIENT_m_n SERVER_n_m
BOOL QI QO BOOL
ANY PARAMS STATUS ANY BOOL QI QO BOOL
RD_1 ANY ANY PARAMS STATUS ANY
ANY SD_1 : : ANY SD_1 RD_1 ANY
: : RD_n ANY : : : :
ANY SD_m ANY SD_n RD_m ANY

INIT(+)
PARAMS
INITO(+)
INIT(+)
PARAMS
INITO(+)

REQ(+)
SD_1, ..., SD_m IND(+)
RD_1, ..., RD_m
RSP(+)
CNF(+) SD_1, ..., SD_n

RD_1, ..., RD_n

Example: m=2, n=1

18
IEC 61499 Distributed System Architecture

Event flow

Application
=
Function Block
Network

Data flow

Communication network

Device 1 Device 2 Device 3 Device 4 System

=
Communication
Application A Network
+
Application B Devices
Appl. C
+
Process/Machines
Controlled process/machines
Examples: X2Y2_TESTD, X2Y2_TESTR, TEST_SYS

19
 IEC 61499 Device Architecture
• Device = Container for Resources
• Device provides Communications & Process Interfaces
Communication link(s)
Device boundary

Communication interface(s)

Resource x Resource y Resource z

Application A

Application C Application B

Process interface(s)

Controlled process/machine

Examples: FRAME_DEVICE, RMT_DEV, TEST_DEV

20
 IEC 61499 Resource Architecture
• Resource schedules & executes FB algorithms
• Resource maps Communications & Process I/O Functions
to Service Interface Function Blocks

Communication functions
Local application
Communication mapping
(or local part of distributed application)

Events

Data
Service Service
Interface Interface
Algorithms
Function Function
Block Block

Process mapping

Process I/O functions

Scheduling Function

Examples: PANEL_RES, EMB_RES, TEST_RES

21
 Standard Event Processing Function Blocks
• E_SPLIT/E_MERGE/E_REND - Event split, merge, rendezvous
• E_PERMIT - Permissive event propagation
• E_SELECT - 1 of 2 (boolean) event selection
• E_SWITCH - 1 of 2 (boolean) event demultiplexing
• E_DELAY - Event delay (timer)
• E_CYCLE - Periodic event generation
• E_RESTART - Generation of COLD/WARM restart, STOP events
• E_TRAIN/E_TABLE/E_N_TABLE - Finite trains of events
• E_SR/E_RS/E_D_FF - Event-driven bistables
• E_R_TRIG/E_F_TRIG - Event-driven rising/falling edge detection
• E_SR/E_RS/E_D_FF - Event-driven bistables
• E_CTU - Event-driven up-counter
• See IEC 61499-1, Annex A

22
Conversion of IEC 61311-3 Function Blocks to 61499
Without error detection

With error detection

(See IEC 61499-1, Annex D)

23
 IEC 61499 Device Management Architecture

• Separation of Concerns
– Software Tools vs. Runtime Device
– Communication Services vs. Management Services

Device Management Proxy Device Management Kernel

(in Software Toolset) (in Device)

24
 Dynamic Configuration in IEC 61499:
The Device Management Service Interface
<Request ID="3" Action="CREATE" >
<FB Name="DIAG" Type="SUBL_2" />
</Request>

<Request ID="4" Action="CREATE" >

<FB Name="LOG" Type="DIAG_LOG" />
</Request>
?!
<Request ID="7" Action="CREATE" >
<Connection Source="DIAG.IND" Destination="LOG.REQ" />
</Request>

<Request ID="10" Action="WRITE" >

<Connection Source="700" Destination="LOG.W" />
</Request>

<Request ID="8" Action="CREATE" >

<Connection Source="DIAG.RD_1" Destination="LOG.SRC" />
</Request>

25
The IEC 61499 System Management Model

26
IEC 61499 Software Tool Models

27
IEC 61499-2: Software Tool Requirements

• Exchange of library elements

• Information to be provided by the supplier of
library elements
• Display of declarations
• Modification of declarations
• Validation of declarations
• Implementation of declarations
• System operation, testing and maintenance

28
 Open Distributed Systems: The IEC 61499 Solution
DeviceNet EDSs
Project Fieldbus DDs
KEY: IEC 61915
Existing & Normative in IEC 61499 Repository ISO 15745
Existing but non-Normative in IEC 61499 ISO 10303
Defined in Compliance Profiles import etc.

Software
Tools XML Libraries:
IEC 61499
PORTABILITY IEC 61131-3

Standard management protocols (XML) ==>CONFIGURABILITY

Standard data transfer protocols (ASN.1)==>INTEROPERABILITY

Distributed intelligent devices & controllers

29
The IEC 61499 Standard

1. Architecture
2. Design Patterns
3. R&D Resources

30
 What is a Design Pattern?

• A formalized approach to a common problem

within a context (B.P. Douglass, Real-Time UML,1998, p. 219)
• Our context = automation systems engineering
• Typically consists of:
– A framework: "skeletal structure...that must be
fleshed out to build a complete application"
(R. Wirfs-Brock et.al., Designing Object-Oriented Software,1990, p. 13)

– An associated engineering methodology

31
 Design Patterns for IEC 61499
• Problem: Account for communication and synchronization
Pattern: Distributed Application
• Problem: Improve efficiency of intraprocess communication
Pattern: Local Multicast
• Problem: Integrate simulation and deployment
Pattern: Layered Model/View/Controller
• Problem: Retrofit existing systems
Pattern: Proxy
• Problem: Utilize processing power in physical devices
Pattern: Mechatronic
• Problem: Increase system flexibility& robustness
Pattern: Holon
• Problem: Integrate multiple models (electrical, mechanical, functional,...)
Pattern: Automation Object

32
Methodology for Distributed Applications
Libraries Application Mapping Configuration

1. Obtain or develop a library of function block,

resource and device types.
2. Define and develop the application.
3. Map function block instances from the
application to distributed resources.
4. Configure devices and resources.
5. Configure communication connections, using
communication service interface function blocks
to implement the event connections and data
connections of the application across resource
boundaries

33
Application Example: Orange Sorter

Pneumatically
actuated
Presence/Color Sensor diverter
Accepted product

Feed conveyor

Rejected product

34
Distributed Orange Sorter Application

Communication Connection

Pneumatically actuated diverter

Presence/Color Sensor Accepted product

Feed conveyor
Rejected product

35
 Using Libraries
Libraries Application Mapping Configuration

Example: process/PIDD_TANK
36
 A Centralized Application
Libraries Application Mapping Configuration

37
 Mapping to Distributed Devices
Libraries Application Mapping Configuration

38
Configuring Devices (1) - Setting Parameters
Libraries Application Mapping Configuration

39
Configuring Devices (2) - Editing Resources
Libraries Application Mapping Configuration

40
Running the Distributed Configuration

41
 Pattern: Local Multicast
Distributed Multicast Local Multicast

encode

copy
decode
Local
Group

encode
copy
decode

Example: process/PIDD_TANKL
42
Pattern: Layered MVC (Model/View/Controller)

HMI HMI Layer

HMI HMI HMI HMI
parameters
Inter- Layer
Communication

control
Controller Controller Control Layer
parameters

sensor inputs actuator outputs Inter- Layer

Communication

model
Model Model Model Model Layer
parameters

rendering data user input Inter- Layer

Communication

display
View View View View Layer
parameters

43
Realization: Simulation => Physical Interface

HMI HMI Layer

HMI HMI HMI HMI
parameters
Inter- Layer
Communication

control
Controller Controller Control Layer
parameters

sensor inputs actuator outputs Inter- Layer

Communication

interface
Interface Interface Interface Interface Layer
parameters

actuature/sensor Physical
signals + power Connections

Mech- Mech- Mech- Machine/Process Layer

anism anism anism

44
Elements of the Engineering Architecture

45
 Engineering Methodology
Sketch Views Animation Models Controllers Diagnostics Distribution Physical

1. Sketch & describe the problem to be solved.

2. Develop & test Views.
3. Animate the desired operational sequences.
4. Develop & test Models.
5. Develop & test Controllers.
6. Develop & test Diagnostic & fault recovery elements.
7. Perform distribution design.
8. Integrate to physical components and systems.

46
 An Example
Sketch Views Animation Models Controllers Diagnostics Distribution Physical

47
 View Development Framework
Sketch Views Animation Models Controllers Diagnostics Distribution Physical

HMI
parameters HMIElement ... HMIElement HMI Layer

user rendering user rendering Inter- Layer

input data input data Communication

display
ViewElement ... ViewElement View Layer
parameters

Example: mach/DRILL_VIEWL
48
 Model Development Framework
Sketch Views Animation Models Controllers Diagnostics Distribution Physical

HMI
parameters HMIElement ... HMIElement HMI Layer

sensor actuator sensor actuator Inter- Layer

inputs outputs inputs outputs Communication
inter-model
interactions
Model
Model Layer
parameters ModelElement ... ModelElement

user rendering user rendering Inter- Layer

input data input data Communication

display
ViewElement ... ViewElement View Layer
parameters

Example: mach/DRILL_MVL
49
 Controller Development Framework
Sketch Views Animation Models Controllers Diagnostics Distribution Physical

HMI
parameters HMIElement ... HMIElement HMI Layer

Inter- Layer
Communication
control
interactions
Control Control Layer
parameters ControllerElement ... ControllerElement

sensor actuator sensor actuator Inter- Layer

inputs outputs inputs outputs Communication
inter-model
interactions
Model
Model Layer
parameters ModelElement ... ModelElement

user rendering user rendering Inter- Layer

input data input data Communication

display
ViewElement ... ViewElement View Layer
parameters

Example: mach/DRILL_MVCL
50
 Low-Level Diagnostics
Sketch Views Animation Models Controllers Diagnostics Distribution Physical

HMI
parameters HMIElement ... HMIElement ... HMIElement HMI Layer

Inter- Layer
Communication
control
interactions
Control Control Diagnostic DiagnosticElement ...
parameters ControllerElement ... ControllerElement Layer parameters

sensor actuator sensor actuator

inputs outputs inputs outputs Inter- Layer
inter-model Communication
interactions
Model
Model Layer
parameters ModelElement ... ModelElement

user rendering user rendering Inter- Layer

input data input data Communication

display
ViewElement ... ViewElement View Layer
parameters

Example: mach/DRILL_MVCDL
51
 Distribution Design
Sketch Views Animation Models Controllers Diagnostics Distribution Physical

HMI
parameters HMIElement ... HMIElement ... HMIElement HMI Layer

Inter- Layer
Communication
control
interactions
Control Control Diagnostic DiagnosticElement ...
parameters ControllerElement ... ControllerElement Layer parameters

sensor actuator sensor actuator

inputs outputs inputs outputs Inter- Layer
inter-model Communication
interactions
Model Convert from local
Model Layer
parameters ModelElement ... ModelElement
to distributed
user rendering user rendering Inter- Layer
communications
input data input data Communication

display
ViewElement ... ViewElement View Layer
parameters

Example: mach/DRILL_MVCDR
52
 Physical Design
Sketch Views Animation Models Controllers Diagnostics Distribution Physical

HMI
parameters HMIElement ... HMIElement ... HMIElement HMI Layer

Inter- Layer
Communication
control
interactions
Control Control Diagnostic DiagnosticElement ...
parameters ControllerElement ... ControllerElement Layer parameters

sensor actuator sensor actuator

inputs outputs inputs outputs Inter- Layer
Communication
Interface
Interface Layer
parameters InterfaceElement ... InterfaceElement
Substitute physical
signals + power Physical interfaces for Models
Connections

Mechanism ... Mechanism Machine/Process Layer

53
 Pattern: Mechatronic

HMI
HMI HMI HMI HMI Partition control/diagnostic functions to:
parameters
– Use existing mechatronic devices
– Design new mechatronic devices
HL control
HLController HLController
parameters
HL = High Level
HL status HL commands LL = Low Level

device LLC LLC LLC

parameters Interface Interface Interface
Mechatronic
physical inputs physical outputs Element

physical
Mechanism Mechanism Mechanism
behaviors

54
MVC Example #2: Assembly

55
MVC Example #3: Demo Testbed

56
 Pattern: Proxy

…"decouples clients from their servers by creating a local proxy, or

stand-in, for the less accessible server. When the client needs to
request a service from the server, such as retrieving a value, it asks
its local proxy. The proxy can then marshal a request to the original
server… " (Douglass, 1998)

Device 1 Application FBs Device 2

Proxy Communication SIFBs

SIFBs

Sensor/ Sensor/
Actuator Machine Machine Actuator
Link #1 #1 #2 Link #2
Coordinated Operation

57
An I/O Proxy Service Interface

58
 Pattern: Holon
(An Autonomous, Cooperative Functional Unit)

Cogitoque coopero,
ergo sum
Holonic Control Device

Inter-Holon Communication

Software Agents

Control Functions

Physical Interfaces

59
Dynamic Reconfiguration of Holonic Systems

PH = Product Holon
MH = Machine Holon
RH = Robot Holon
TH = Transport Holon
MD = Machining Domain
TD = Transport Domain

Holons negotiate and coordinate tasks via

Cooperation Domains. Tasks are perfomed by

IEC 61499 Applications, generated as needed.

60
FIPA (Foundation for Intelligent Physical Agents):
an Architecture for Open Holonic Systems

(ACL = Agent Communication Language)

See: http://www.fipa.org

61
IEC 61499 + FIPA = Holonic Control Architecture

Messaging
+
Directory
Services

ACL

IEC 61499
Management
Task Negotiation in CD
HMS Task/Application KB Services
(Cooperation Domain)
(Knowledge Base)

62
Adapting FIPA to Holonic Control Devices (HCDs)
• Develop application-specific extensions of FIPA Standards
applying to HCD architecture.
• Develop, test and demonstrate prototype implementations of
HCDs to validate these extensions.
• Specific areas of investigation:
– Interaction/negotiation protocols
– Manufacturing task ontologies (PSL?)
• Material handling (*)
• Machining
• Fixturing/Assembly
– Knowledge base development & maintenance

(*) - Work in progress

63
 Pattern: Automation Objects

Source: IEC Sector Board 3 - Ad Hoc Group 2 (SB3/AHG2), 2002-04-11

64
The AO Model Type: Generalization of the
IEC 61499 Function Block Type

association association

Type name

itype1 iname1 oname1 otype1

itype2 iname2 oname2 otype2

itype3 iname3 oname3 otype3

itype4 iname4

names types names types

{

{
inputs outputs
parameters

Source: IEC SB3/AHG2

65
The AO Diagram: Generalization of the
IEC 61499 Function Block Network

AOModel AOModel

AOConnection
output input

parameters

• Body of a composite AO type, or

• Part of a system configuration

Source: IEC SB3/AHG2

66
AO Reference Model

Source: IEC SB3/AHG2

67
The IEC 61499 Standard

1. Architecture
2. Design Patterns
3. R&D Resources

68
 EMBench: The Electromechanical Workbench

Flexible Automation Laboratory, U. of Illinois at Urbana/Champaign (USA)

69
VEDA- Verification Environment for Distributed Applications

Specifications of
desired or
Model Generator prohibited behavior
(translator of •Temporal logic
sources to SNS) •Timing diagrams

Model checker SESA

Translator of
results into the
original system

Interpreter and
visualizer of
results

Automation Technology Lab, Martin-Luther-Universität, Halle/Wittenberg, Germany

70
Next-Generation Testbed

http://at.iw.uni-halle.de/~testbeds/
71
 Odo Struger Laboratory - Tech Uni Vienna

Testbed for Distibuted and Holonic Control

Storage Handling Pallet Transfer Robot Assembly
System (SHS) System (PTS) System (RAS)

72
Lego™ Testbed

73
 Experimental Development Framework
Current State
• Microsoft Visio template is created
• Template is supported with macros running in background
• VBA is used as programming language
FDBK

Featuring the IEC 61499 Visio Template

• IEC 61499 standard Function Blocks Creation XML
• Function Blocks Configuration
• Network Design (FB-n)
• Import/Export using XML

CORFU-FDBK

Assembly Automation Lab, Tech. Uni. Tampere, Finland

74
 The CORFU Architecture

University of Patras, Greece (Prof. K. Thramboulidis)

75
 FBDK/FBRT Reference Implementation

FBDK <www.holobloc.com>

SNAP <www.imsys.se> Ethernet

FBRT (customized) <www.holobloc.com>

DeviceNet
TILT.CAN <www.systronix.com>
I/O Device
(in development) Device Logix (future)

76
 IEC 61499 Resources
• Automation Technology Lab, Martin-Luther-Universität, Halle/Wittenberg, Germany
– http://cobweb.iw.uni-halle.de/~valeriy/project/proj_descr.html
– <[email protected]> (Dr. Valeriy Vyatkin)
• Odo Struger Lab, TU Wien, Austria
– http://www.infa.tuwien.ac.at/
– <[email protected]> (DI Alois Zoitl)
• Profactor GmbH, Steyr, Austria
– http://www.profactor.at
– <[email protected]> (Dr. Franz Auinger)
• Rockwell Automation Advanced Technology, USA
– http://www.holobloc.com
– <[email protected]> (Dr. James H. Christensen)
• Flexible Automation Laboratory, U. of Illinois at Urbana/Champaign, USA
– http://www.mie.uiuc.edu/content/asp/research/laboratories/flexible_automation_lab.asp
– <[email protected]> (Prof. Placid Ferreira)

77
 IEC 61499 Resources
• Dept. of Mechanical & Manufacturing Engineering, U. of Calgary, Canada
– http://isg.enme.ucalgary.ca
– <[email protected]> (Prof. Bob Brennan)
• Yamatake Corporation, Japan
– http://www.yamatake.co.jp/
– <[email protected]> (Mr. Hirotsugu Tsunematsu)
• Assembly Automation Laboratory, Technical University of Tampere, Finland
– <[email protected]> (Dr. Jose Lastra)
• University of Patras, Greece
– <[email protected]> (Prof. Kleanthis Thramboulidis)

78