modelling control systems using iec 61499 applying function blocks to distributed systems iee...

Introduction v

Contents

Foreword viiPreface ixAcknowledgements xiAbbreviations and conventions xiii

1 Introduction 1IEC 61499 function block standard 5Development of function block concept beyond IEC 61131-3 9IEC 61499—a developing standard 12Why use function blocks? 14System design views 17The future beyond IEC 61499 19

2 IEC 61499 models and concepts 21System model 22Device model 23Resource model 24Application model 25Function block model 26Function block types 29Execution model for basic function blocks 29Distribution model 33Management model 33Operational state model 36Common interfaces using adapters 37Textual syntax for IEC 61499 entities 38Summary 41

3 Defining function block and subapplication types 43Types and instances 43Different forms of function block 44Defining basic function blocks 44Definitions for composite function blocks 55Defining subapplications 61Summary 67Notes 68

vi Modelling control systems using IEC 61499

4 Service Interface function blocks 69Overview 69Type definitions 71Behaviour of Service Interface function blocks 75Partnered Service Interface function blocks 81Management function blocks 82Summary 86

5 Event function blocks 87Overview 87Standard Event function block types 88Using Event function blocks 103Summary 105

6 Industrial application examples 107Overview 107Temperature control example 108Conveyor test station example 112Fieldbus applications 120Summary 130

7 Future development 131Current status of IEC 61499 131Compliance with IEC 61499 133Engineering support task 134File exchange format 135Summary 137

Bibliography 139

Appendix A: Common elements 141Appendix B: Overview of XML 151Appendix C: Frequently Asked Questions (IEC 61499 FAQs) 155Appendix D: PID function block example 165Appendix E: Textual syntax 181

Index 189

Introduction vii

Foreword

In early 1990, Technical Committee 65 of the International Electrotechnical Com-mission (IEC TC65) received a New Work Proposal (NWP) to standardise certainaspects of the application of software modules called function blocks in distributedindustrial-process measurement and control systems (IPMCS). IPMCSs utilisingthe ‘fieldbus’ (IEC 61158) standard then in development in Working Group 6 ofSubcommittee 65C (SC65C/WG6) were especially emphasised in the NWP.However, function blocks were also an essential part of the programming languagestandard IEC 61131-3 for programmable controllers being developed in SC65B/WG7. Therefore, TC65 determined that a common model for the use of functionblocks was required and assigned the new Project 61499 to a new Working Group6 (TC65/WG6) of the parent committee.

Due to the relative immaturity of the IEC 61158 project at the time of theproposal, experts and a project leader were not available for the 61499 projectuntil approximately two years after its inception, at which time the first edition ofIEC 61131-3 was also completed and available for reference. Because of the closerelationship between IEC 61131-3 and the projected IEC 61499, many of the expertsparticipating in the development of the latter came from the previous project,including Bob Lewis and myself.

In its first meetings TC65/WG6 identified a number of fundamental issues whichhad to be resolved in order to achieve a common model for the application offunction blocks in distributed IPMCSs. Through a long process of systematicapplication of software engineering and open systems principles, with intensiveinternational review and revision, the TC65/WG6 experts reached consensus onthe basic concepts and detailed technical approach to the resolution of these issues.This consensus is reflected and thoroughly explained in the present book.

It is particularly opportune that this book should appear at this time, since thefirst two Parts of IEC 61499 have now achieved IEC PAS (Publicly AvailableSpecification) status for a two-year period of trial implementations prior to finalstandardisation. It is my sincere hope and belief that this book will contribute asmuch to the widespread understanding, application and implementation of IEC61499 as did Bob Lewis’ previous pioneering book on IEC 61131-3.

James H. ChristensenEuclid, Ohio USA6 February 2001

viii Modelling control systems using IEC 61499

Introduction ix

Preface

New technologies and standards are emerging that are set to have a dramatic effecton the design and implementation of industrial control systems in the newmillennium. These technologies will reduce the time to bring new systems on-stream, and leverage the integration of business and industrial systems.

There is currently an explosion in the use of object oriented (OO) softwareencapsulated as components. In business systems the use of software componentsand technology is becoming more widespread. In industrial systems, PLCs andsoft controllers based on PC architectures are also starting to adopt many of thesetechniques. The different worlds of factory automation and business systems areclearly starting to share the same software technology.

With so much scope for complexity, new tools and techniques are clearly neededto design and model such systems. To date, some new methodologies have emergedsuch as the Unified Modelling Language

7 (UML) that allow software engineers to

deal with some of the complexity of OO based systems.Control and system engineers are also faced with increased software complexity

as advances in industrial networking, such as Fieldbus technology, allowintelligence to be distributed throughout the system from controllers, instruments,actuators and even out to the sensors themselves. As these systems become morecomplex, new tools and techniques are needed to model their behaviour.

Some of this complexity can be dealt with effectively by use of the IEC 61499standard which has been developed specifically as a methodology for modellingdistributed control systems. This standard defines concepts and models so thatsoftware in the form of function blocks can be interconnected to define thebehaviour of a distributed control system.

Process and system engineers have used function blocks in various forms for anumber of years as an effective way to represent and model software functionalityin instrumentation and controllers. The PID algorithm is probably the best exampleof an early form of function block. New forms of smart devices and sensors nowallow intelligence to be distributed widely throughout a control system. It is nowbecoming more difficult to define where the main intelligence of any control systemreally resides; intelligence is becoming truly distributed.

x Modelling control systems using IEC 61499

It is envisioned that tools based on the IEC 61499 standard will emerge tomodel, validate and simulate the behaviour of complex networks of function blocks.IEC 61499 is a new standard but has been in development for a number of yearsby international experts working in the field of control system software. It is set tobecome an important methodology for process and system engineers working withcomplex distributed systems.

The main objective of this book is to widen the understanding of the mostimportant concepts in the IEC 61499 standard and to show how these conceptscan be applied to industrial problems. IEC 61499 is a complex standard that definesmany new concepts related to function blocks and the supporting architecture in arigorous and thorough manner – as a consequence, the standard can be difficult tounderstand by people who read it for the first time. This book has therefore concen-trated on the main concepts and has intentionally summarised or omitted some ofthe less significant details in the standard. For this reason, some topics such as theTextual Syntax for describing function block definitions have not been covered ingreat detail.

IEC 61499 provides for the first time a framework and architecture for describingthe functionality in distributed control systems in terms of co-operating networksof function blocks. It is the author’s intention that the benefits of this standard willbe understood by a wide audience; including not only people working in industrialcontrol but also those with a general interest in methodologies for modellingdistributed systems.

Introduction xi

Acknowledgements

The development of the IEC Function Block Standard has taken many yearsinvolving numerous meetings, animated discussions, debate and argument. I musttherefore thankfully acknowledge all contributions of the members of the IEC 65/WG6 working group whose efforts are distilled in the IEC 61499 standard. I wouldalso particularly like to thank the chairman, Dr. Jim Christensen who, throughhumour and gentle persuasion, ensured that the working group remained on trackto create a concise and effective standard. I must also thank Jim and RockwellAutomation for permission to use his FBEditor tool, which I put to good use, toprove the syntax and structure of the PID example given in Appendix D.

I would also like to thank Terry Blevins from Fisher-Rosemont Systems Inc.for all his information and help on the development of the Fieldbus standards.Some of his application examples have been particularly useful in demonstratinghow function blocks can be used to model distributed systems.

I would also like to give special thanks to Dr. Bob Brennan at the University ofCalgary and Dr. John Wilkinson at Queen’s University, Belfast for all their help inreviewing the manuscript.

Bob Lewis, Worthing, West [email protected]

xii Modelling control systems using IEC 61499

Introduction xiii

Abbreviations and conventions

DCS Distributed Control SystemFB Function blockFBD IEC 1131-3 Function Block Diagram graphical languageFIP Fieldbus implementation based on a French standardFRD Functional Requirements DiagramHMI Human Machine Interface (see MMI)HVAC Heating venting and air conditioning systemIEC International Electro-technical CommissionI/O Inputs and outputs to a control systemIPMCS Industrial-process measurement and control systemsIS International StandardISA Instrument Society of AmericaISO International Standards OrganisationLD IEC 1131-3 Ladder Diagram graphical languageMMI Man-machine interface (now replaced by HMI)MMS Manufacturing Message SpecificationOO Object orientedOSI Open Systems InterconnectionPAS Publicly Available SpecificationPC Personal computerPID Three term controller, proportional, integral, derivative closed-loop

control algorithmP&ID Process and Instrumentation DiagramPLC Programmable logic controllerPOU IEC 1131-3 Program Organization UnitRAM Random access memorySCADA Supervisory, control and data acquisition systemSFC IEC 1131-3 Sequential Function Chart graphical languageSI Service InterfaceSIFB Service Interface Function BlockST IEC 1131-3 Structured Text languageUML Unified Modelling LanguageXML Extensible Markup Language

xiv Modelling control systems using IEC 61499

The following font and style is used to distinguish examples of textual programminglanguage from ordinary text:

BEGINA := A + 100.5; (* Comment *)

END

The suppression of superfluous detail in textual language examples is indicatedusing an ‘ellipsis’ as follows:

…

Note that from January 1997, the IEC changed the numbering scheme for industrialstandards. Standards which formally had a four digit identifier were renumberedby prefixing the identifier with a ‘6’. The full IEC identifier for the function blockstandard is IEC 61499. However, for brevity, the original and better known fourdigit numbering scheme has been retained in some references in this book, i.e.IEC 1499 represents IEC 61499, IEC 1131 represents IEC 61131.

Introduction 1

Chapter 1

Introduction

In this introductory chapter we review the background and reasons behind thedevelopment of the IEC 61499 standard. Specifically we will:• review the design of current-day control systems and consider the impact of

new technology• look at the reasons for starting the development of the IEC 61499 standard• consider the reasons why function blocks are still an important concept to process

and system engineers• show how function blocks have some of the characteristics of object oriented

software• and finally show how IEC 61499 models can be used in the control system

development life-cycle.

Note: Every effort has been made to ensure that this book accurately describes theconcepts and definitions in the IEC 61499 standard. However, although parts 1 and2 of the IEC 61499 standard are fairly advanced in their development, they maystill be subject to minor changes, which are not reflected in this book.

As manufacturing companies fight to compete in today’s unpredictable andever changing global markets, there is an increased urgency to improve the agilityof manufacturing systems. To produce competitive and innovative products,companies must be able to quickly design and create new forms of advancedautomated production. Such levels of automation require the creation of largesystems involving an amalgam of industrial control, manufacturing execution andbusiness logistics systems. A key characteristic of all of these new systems will bea built-in ability to rapidly handle change, i.e. agile manufacturing systems. Amanufacturing plant will need to be able to quickly switch product types and bringnew processes on stream to remain in business.

Currently there is growing interest in new technologies and architectures forcreating the next generation of distributed systems for industrial automation. Thesewill be systems where software is organised as sets of co-operating componentsrather than as the integration of large bespoke units of software [1].

2 Modelling control systems using IEC 61499

Up to now industrial control systems have fallen into one of two main camps,either based on traditional distributed control systems (DCSs) or on programmablelogic controllers (PLCs). Current DCSs, as typically used in petrochemical plantsand refineries, are structured around using a few large central processors, thatprovide supervisory control and data acquisition, communicating via local networkswith numerous controllers, instruments, sensors and actuators located out in theplant. A system may have both discrete instruments and out-stations with clustersof instruments with local controllers. In a DCS, the main supervisory control comesfrom one or more central processors. Instruments positioned out in the planttypically provide local closed loop control, such as for PID control (Figure 1.1).

In contrast, for many machine control and production processes, particularly inautomotive production lines, systems have generally been designed using program-mable logic controllers (PLCs). In these systems, the human-machine interface(HMI) is normally provided by a wide variety of different types of panels, lightsand switches. Advanced HMIs can also be provided by colour display panels withoperator input via dedicated keypads or from touch sensitive screens.

Workstation

Centralsupervisory andcontrol stations

Distributed instruments

Out-stations withinstrument clusters

Figure 1.1 Distributed control system

Introduction 3

A large PLC system will generally have a number of PLCs communicating viaone or more proprietary high-speed networks. PLCs will typically be connectedto a large number of input and output (I/O) signals for handling sensors andactuators. In some cases, discrete instruments, for example, for temperature andpressure control, are also connected to PLCs (Figure 1.2).

With both design approaches, systems have tended to be developed by writinglarge monolithic software packages, which are generally difficult to re-use in newapplications and are notably difficult to integrate with each other. The data andfunctionality of one application are not readily available to other applications,even if the applications are written in the same programming language and runningin the same machine. Significant system development time is concerned withmapping signals between devices and providing drivers to allow different types ofinstruments and controllers to communicate.

Both types of system, DCS and PLC, tend to be difficult to modify and extendand do not provide the high degree of flexibility that will be expected in systemsfor advanced and flexible automation.

Figure 1.2 PLC control system

HMI Display

PLC withdiscrete

instruments

PLC Network


With the emergence of standards in industrial communications such as Fieldbusthat will allow different types of instruments and control devices to interoperate,the differences between DCS and PLC based systems are starting to disappear.DCS instruments and PLCs are beginning to offer similar functionality. Industrialapplications are also being implemented on PC hardware with concepts such asthe SoftPLC, i.e. PLC logic running on a normal PC. As industrially hardened PCplatforms that offer high reliability become more common, we will see a trend tousing more PC based controllers. Until recently, classical PLCs were only able tobe programmed using proprietary languages as offered by the PLC vendor. Withusers now requesting a more open approach to software, a new breed of soft-controller is emerging that is able to be programmed in a wide range of differentprogramming languages.

We can now foresee the time when systems for controlling industrial, manufac-turing and business processes start to merge. For example, consider the case wherea company could seamlessly link a business system running in a head office tomanufacturing processes and industrial control systems or even controllers runningin any plant in any part of the world.

Figure 1.3 depicts part of a system having advanced distributed functionality.In such systems, each device connected to the industrial network can provide partof the control functionality. Smart devices, such as pumps, valves, and sensorswill have built in control functionality that can be linked by software with moreintelligent devices such as HMI panels, temperature controllers, and soft-controllersto form the total control system functionality. For example, a pressure sensor canbe linked directly by software to a valve actuator and to a display bar graph on aHMI panel. A slider on a HMI panel can be directly software wired to the setpointof a PID controller controlling the speed of a pump.

To achieve these high levels of integration and yet enable the creation of flexiblesystems that can be re-engineered as industrial and business needs change we will

Figure 1.3 Advanced distributed functionality

Soft controller

Temperaturecontroller

Pump

Pressure sensor

Human MachineInterface

Valve actuator

Position sensor

Introduction 5

require a completely new approach to software design—a new technology basedon the interaction of distributed objects [2]. There are several software technologiesalready well advanced that are set to have an influence in this area. CORBA[2](Common Object Request Broker Architecture) is a new standard for designingdistributed objects that is being developed by a consortium of leading softwarevendors, the Object Management Group (OMG).

OPC [2] (OLE for Process Control) based on Microsoft’s OLE/COM (ObjectLinking and Embedding, Common Object Model) technology will allow softwarein the form of software components to interoperate regardless of where they arelocated, be it in a remote industrial controller in a blast furnace or in the PC of theproduction manager’s office. Internet technology using Java and the World WideWeb is also being considered for the development of software components formanufacturing systems. There are even proposals for industrial devices, such assmart valves, to be able to execute embedded Java code directly.

The industrial community has long been aware that the ready interconnectionof software components, such as in the form of function blocks, will have majoradvantages, especially for end-users. These advantages will include improvedsoftware productivity through the re-use of standard solutions, and improved designflexibility by being able to plug-and-play software and devices from differentvendors. So far, the new standards all enable ‘technical integration’ of distributedcomponents, but the next major hurdle is ‘semantic integration’. We may be ableto link and exchange data between software in a remote industrial controller and acontrol algorithm running in a PC, but will the connection be meaningful?

IEC 61499 function block standard

The International Electrotechnical Commission (IEC) has now developed a newstandard, IEC 61499 [3], that defines how function blocks can be used in distributedindustrial process, measurement and control systems. This standard may help solvepart of the semantic integration problem.

In industrial systems, function blocks are an established concept for definingrobust, re-usable software components. A function block can provide a softwaresolution to a small problem, such as the control of a valve, or control a major unitof plant, such as a complete production line. Function blocks allow industrialalgorithms to be encapsulated in a form that can be readily understood and appliedby people who are not software specialists. Each block has a defined set of inputparameters, which are read by the internal algorithm when it executes. The resultsfrom the algorithm are written to the block’s outputs. Complete applications canbe built from networks of function blocks formed by interconnecting block inputsand outputs.

The IEC 61499 standard, which builds on function block concepts defined inthe PLC language standard IEC 61131-3, is being developed in liaison with Fieldbusstandardisation work. It is envisioned that the Application Layer part of the Fieldbuscommunications stack will provide the software interface to allow remote function


blocks to interoperate over Fieldbus. However, IEC 61499 is being developed as ageneric standard that is also applicable in other industrial sectors; in fact whereverthere is a requirement for software components that behave as function blocks,such as in building management systems.

IEC 61499 defines a general model and methodology for describing functionblocks in a format that is independent of implementation. The methodology canbe used by system designers to construct distributed control systems. It allows asystem to be defined in terms of logically connected function blocks that run ondifferent processing resources.

Figure 1.4 depicts how the IEC 61499 methodology could be used as part ofthe system design life-cycle. The design of a control system typically starts withthe analysis of the physical plant diagrams and documentation of the control systemrequirements. This analysis leads to the definition areas of functionality and theirinteraction with the plant. The final phase results in mapping functionality intophysical resources such as PLCs, instruments and controllers.

The use of IEC 61499 can be best demonstrated by considering the followingphases in the design of a distributed control system:

(1) Functional design phase

During this phase, process engineers analyse the physical plant design, forexample using Process and Instrumentation Diagrams (P&IDs), to create thetop-level functional requirements. These can be represented as a series of

Figure 1.4 Applying IEC 61499

Physical system

Design

Implementation

081 PT

082 PT

Tank 1 Tank 2Physical plant andinstrumentationdesign e.g. P&ID

PT1

Tank 1Tank 2

Top level FunctionalRequirement Diagram(FRD)

PT1 Tank 1 Server

Resource 1 Resource 1

Client Tank 2..................

Distributed FunctionBlock Diagram (IEC 1499)

Introduction 7

blocks that outline the main software components and their primary inter-connections. At this design phase, the physical distribution of the softwareblocks is not considered. In many cases diagrams that show the physical designof the plant or machinery, such as P&IDs, also show the location of activedevices such as valves and pumps, and instrumentation points, such as thelocation of pressure and temperature sensors.

(2) Functional distribution phase

In a distributed system a further design phase is required to define the distribu-tion of control functionality on to processing resources. The IEC 61499standard provides models and concepts for defining the distribution of function-ality into interconnected function blocks. System engineers complete thedetailed design by mapping the software requirements on to IEC 61499 functionblocks. These may be distributed on various processing resources. In manycases, function blocks as provided in field devices will be exploited; e.g. intelli-gent devices such as smart valves may provide software packaged as a functionblock.

Each function block in turn will have its own particular software designlife-cycle. Some blocks will need to be specifically designed for a systemapplication, in other cases, existing blocks within instrumentation andcontrollers can be used.

We will see later that the function block model defined by IEC 61499 providesjust one view of a distributed system design. Other design views will be necessaryto give all aspects of a system design. IEC 61499 is the first step in providingdesign methodologies for developing and modelling distributed applications.

As the trend to use component based software continues, it is foreseen thatindustrial controllers and instruments will either provide function blocks as partof the device firmware or provide function block libraries from which blocks canbe selected and down-loaded. System design will become the process of softwarecomponent selection, configuration and interconnection, just as much of electronichardware design is now primarily concerned with the selection and interconnectionof IC chips.

IEC 61499 allows function blocks that encapsulate software functionality andalgorithms to be defined in a standard format. This allows tools and other standardsthat deal with function blocks to use the same concepts and methodology.The IEC61499 standard also defines a range of communication blocks, such as Server andClient blocks, which can be used to formalise the exchange of data between blocksin different physical processing resources. There are also service interface blocksto provide interfaces with the processing resource infrastructure.

Figure 1.5 shows three interconnected function blocks, representing theconnections between a Pressure Transmitter and PID control block and a Pumpusing concepts from IEC 61499. Notice that there are both data and event flowsbetween blocks. We will see later that the IEC 61499 methodology allows data


and its associated event to be closely coupled, i.e. to be coherent, or alternativelyfor events and data to be handled asynchronously.

Figure 1.6 depicts the trends in industrial control technology during the lastfifty years; since the 1950s, there has been a steady growth in the functionalityprovided by control systems due to advances in both hardware and software. Ascontrol systems became digital, using microprocessors, there has been an increasedneed for standards to reduce unnecessary diversity in software and lessen cross-system integration problems.

Figure 1.5 Function block data and event flows

Pressure PID Pump

Event flow

Data flow

Figure 1.6 Development of technology for industrial control

Fun

ctio

nalit

y

Advancing Technology

Mechanicalfunction

Analoguedevice

Digital device

Functiondistribution

Toolintegration

Defenceindependentfunctionality

IEC61131-3

IEC 61499

Transistor Micro-processor Industrialcommunications

Data modelling Object orientedtechnology

Introduction 9

IEC 61131-3 has focused on standardising PLC languages for single processorsor small configurations with a few closely coupled multi-processors. With themove to large scale distributed functionality, there is need for further standardssuch as IEC 61499 to harmonise the way functionality is defined and distributed.There is also a growing requirement that all the related system build tools can beintegrated as well. For example, all the software tools used to design, configureand manage a distributed system should run as an integrated suite. The design toolthat defines a system should be integrated with tools for programming andconfiguring devices along with tools for defining HMI screens and configuringindustrial networks. It is the intention that IEC 61499 will define system modelsthat will help not only with the design of functionality in distributed systems butalso with the integration of system tools through the definition of data andinformation models.

Development of function block concept beyond IEC 61131-3

Why was it not possible to use the function block concepts defined in IEC 61131-3 for distributed systems? There are a number of limitations with the originalfunction block concept introduced by the PLC Languages standard IEC 61131-3.With the IEC 61131-3 Function Block Diagram (FBD) graphical language, functionblocks can be linked by simply connecting data flow connections between blockinput and output variables, see Figure 1.7a. Each function block provides a singleinternal algorithm that is executed when the function block is invoked. The normalexecution order is determined by the function block dependency on the other blocks;the order normally runs from left to right because blocks to the right depend on theoutput values of blocks on the left.

However, when a feedback path is introduced, see Figure 1.7b, the executionorder cannot be determined from the diagram, since the execution of both blocksdepends on an output value of the other block. In a complex network, it is verydifficult for a programming system to determine a valid order of execution. Toovercome this problem, many IEC 61131-3 programming systems provideadditional mechanisms to define the execution order of blocks. For example, theuser can view a list of function blocks and manually assign an execution order.Unfortunately, such mechanisms are outside the scope of the IEC 61131-3 standard.As a consequence, an important aspect of a function block network, i.e. the methodfor defining the execution order of blocks, is not consistent or portable acrossdifferent control systems.

There is one feature in IEC 61131-3 that does provide a crude mechanism forpassing execution flow through a chain of function blocks that is worth considera-tion; that is the use of the EN input and ENO output signals (Figure 1.8). The ENand ENO signals were intended for function blocks to pass ‘power flow’ whenused in rungs of a Ladder Diagram. However, it is now recognised that use of theEN and ENO signals does not provide the degree of flexibility needed for complex


FB networks. In effect, the EN and ENO signals can be regarded as a means ofpassing events between blocks. ‘EN’ signals that the block may be invoked becauseits input data is ready; ‘ENO’ is signalling that the block has executed and theoutput data is ready for the next block. We will see that this idea of event passinghas been extended in IEC 61499.

The focus of the IEC 61131-3 standard [4] has been to define a software modeland languages for PLCs where software is typically running on one processingresource. However, the IEC 61131-3 software model, see Figure 1.9, does considerconfigurations that have multiple resources. The standard provides two differentmechanisms for passing data and control signals between resources, namely globalvariables and communications function blocks.

Figure 1.7 Using IEC 61131-3 function blocks

Figure 1.8 Using IEC 61131-3 EN and ENO signals

Loop1

MainControl

EN

ProcVal

SetPoint

ENO

Output

Error

Load1

Load

EN

FlowRate

SetPoint

ENO

Level

Error

Introduction 11

Global variables

By using global variables located at the configuration level, it is possible totransfer data and control signals between programs and function blocks runningin different resources. However, it is well understood that the use of globalvariables is a very poor and sometimes unsafe mechanism for handling datatransfer between procedures running in different processors. It is not possibleto clearly identify where global variables are updated and where they are used.There is no graphical means in IEC 61131-3 of defining the linkage betweenglobal variables and the variables, which reference them, that are located insideprograms and function blocks. There are also more serious problems with globalvariables because the timing and synchronisation of signals passed by globalsis difficult to define. Furthermore, the mechanisms provided within theconfiguration for handling the initialisation and updating of shared globalvariables is not defined in IEC 61131-3.

Communications function blocks

Part 5 of the PLC standard, IEC 61131-5 [8], is concerned with communicationsservices for PLCs programmed using the IEC 61131-3 software model. IEC61131-5 defines a range of function blocks that can be used to exchange databetween PLCs. This includes blocks to allow a PLC to function as a ‘server’,i.e. allow a PLC to support and respond to external service requests. There are

Figure 1.9 IEC 61131-3 software model

Task Task

Program Program

FBFB

Task Task

Program Program

FBFB

Global and directly represented variables

Access paths

Configuration

Communication functions(defined in IEC 61131 Part 5)

KeyVariables

FB Function Blocks

Access paths

Execution control path

Resource Resource


also blocks to support ‘client’ behaviour, i.e. support services that enable aPLC to request and control another PLC or system functioning as a server.

IEC 61131-3 allows a sub-set of variables within a configuration to beaccessed externally. These are called ACCESS variables and can be accessedvia a communications interface from an external PLC using communicationfunction blocks or can be accessed from other non IEC 61131-3 devices usingservices that are outside the IEC 61131-3 standard.

We have seen that IEC 61131-3, along with the Manufacturing Messagingstandard IEC 61131-5, provides a range of different software mechanisms forallowing PLCs to communicate. These are quite adequate for systems with only afew PLCs. However, it was clear to the IEC working group developing the functionblock standard that the IEC 61131 communications model has serious limitations.Concepts such as global variables and communications function blocks do notprovide a clear and concise method for defining the connections between distributedfunction blocks.

A consistent communications model was required that could be used not onlyfor PLC-to-PLC communications but also between large and small devicesdistributed over industrial networks. The new function block model had to bescalable and extensible, so it would be equally applicable to modelling the com-munications between control systems, PLCs and controllers as between smallerFieldbus devices, such as smart valves and sensors. In fact, a function block modelwas sought that would cover all types of devices and controllers.

To summarise, the main deficiencies of the software model provided by IEC61131-3 for distributed systems are as follows:

• Applications in the IEC 61131-3 model are not distributable over multipleresources.

• The function block execution order is not always clearly defined.• The assignment of tasks to programs and function blocks does not provide

sufficient flexibility.• The ‘scanned’ nature of IEC 61131-3 function block execution cannot be mapped

to function blocks connected across distributed resources.

IEC 61499—a developing standard

When the International Electro-technical Commission first set up the FunctionBlock working group in 1990, it was realised that function blocks would be ageneric concept that could be applied to a wide range of standards. For example,function block concepts can be used within PLCs, smart devices, buildingmanagement systems and Fieldbus protocols. It was therefore prudent to place thefunction block working group WG 6 directly under the management of the industrialprocess measurement and control technical committee, TC 65. It was the intentionof the IEC that the function block standard would become a generic standard that

Introduction 13

could be used as a basis for standards throughout the domain of industrial processmeasurement and control. For this reason, because of its generic nature, IEC 61499appears to be a rather academic standard. It has been deliberately defined to be‘application domain neutral’, i.e. it contains no specific features for any particularindustrial application area. It is designed so that other standards can build on theIEC 61499 concepts and add their own domain specific extensions.

A good example of a standard built on the IEC 61499 function block model isdemonstrated by the Process Control Function Block working group WG7, set upunder digital communications sub-committee SC65C. This group has the primaryobjective of defining function blocks for use in the process industries, but theyhave taken concepts from the generic function block model in IEC 61499 as thebasis of their work. By applying the generic model to real industrial process controlapplications, the Process Control group has provided useful feedback to the IEC61499 working group. In many cases they have highlighted shortcomings in thefunction block model that have resulted in improvements to IEC 61499.

The IEC working group for IEC 61499 has members from USA, Japan, UKand many European countries who represent both industrial control system suppliersand end-users. IEC 61499 is a multi-part standard that will take a number of yearsto complete. Part 1 covers the function block architecture, which at the time ofwriting this book is now well advanced in a committee draft and is ready to bedistributed as a “Publicly Available Standard” (PAS) — this is discussed furtherin chapter 7.

IEC Technical Committee

Sub-committees

Working Groups

TC65Industrial process

measurement and control

SC65ASystem Aspects

SC65BDevices

SC65CDigital

Communications

Advisory group

WG1: Terms and Conditions

WG4: Interface characteristics

WG6: Standardisation of Function Blocks

WG7: Documentation of software forWG7: process control systems

WG2: Service Conditions

WG4: Electromagnetic Interference

WG8: Evaluation of System Properties

WG9: Safe software

WG10: Functional safety of PES

WG11: Batch control systems

WG5: Temperature sensors

WG6: Methods of testing & EvaluationWG6: of performance of systemWG6: elements

WG7: Programmable control systems

WG9: Final control elements

WG1: Message data format

WG3: Programmable MeasuringWG3: Apparatus

WG6: IntersubsystemWG6: Communications

WG7: Process control function blocks

Figure 1.10 IEC Working Group structure


Part 1 covers the architecture and concepts for designing and modelling functionblock oriented systems and covers the following topics:

1. general requirements—including an introduction, scope and normative referen-ces (i.e. to other standards), definitions and reference models

2. rules for the declaration of function block types, and rules for the behaviour ofinstances of function block types

3. rules for the use of function blocks in the configuration of distributed industrial-process measurement and control systems (IPMCSs)

4. rules for the use of function blocks in meeting the communication requirementsof distributed IPMCSs

5. rules for the use of function blocks in the management of applications, resourcesand devices in distributed IPMCSs

6. requirements for compliant systems and standards.

The main focus of this book concerns the architecture and models defined inPart 1 of the IEC 61499 standard.

Part 2 defines software tool requirements to create function block type defini-tions and manage function block libraries. It includes an extensive annex of XMLdocument definition types for the exchange of function block designs betweensoftware tools from different suppliers. XML is now the preferred exchange formatfor function block designs. The main focus of Part 2 is “Engineering task support”and will provide guidance on engineering tasks concerned with the design, imple-mentation, operation and maintenance of IPMCSs constructed using the architectureand concepts defined in Part 1.

The standard for the exchange of product data, STEP (ISO 10303), hadpreviously been considered for this purpose. STEP is used by CAD stations forthe storage and porting of electronic circuit designs in an implementationindependent form. There is clearly a strong synergy between electronic schematicsand control system designs based on function blocks.

It is also now proposed in IEC 61499 Part 2 that the Extended Markup Language(XML) can be used as a means of saving and porting function block definitions.This will provide the exciting possibility of being able to transfer designs acrossthe Internet and view them using the next generation of Web browsers. XML hasbeen developed as a major enhancement to the Hypertext Markup Language(HTML) currently used for Web page creation. The use of XML will allow designsto be saved with various attributes including version information and graphicallayout details—this is discussed further in chapter 7.

Why use function blocks?

To many software engineers, the idea of function blocks seems to some degreearchaic, a strange software paradigm that appears to represent software as piecesof hardware. In effect, that is exactly what a function block is, a model of softwarethat treats the encapsulated behaviour in a form that is similar to an electronic

Introduction 15

circuit. Objects used in the object oriented (OO) software world have becomesuccessful because they can be used to model the behaviour of entities and conceptsin the real world.

In OO design, the software designer is primarily concerned with the relationshipsbetween objects, such as looking at how an object can inherit behaviour from asuper-class or how objects that have similar behaviour can be treated in a similarway—so called polymorphic behaviour. Polymorphism comes from a Greek wordthat means ‘many forms’. When it is applied to objects, it means that the developercan apply the same kinds of operations to similar objects. For example, two classesof object ‘customer’ and ‘supplier’ might both have a method called ‘getAddress’to return the customer and supplier addresses. In many cases, polymorphism allowsa developer to treat different objects sharing some aspect of behaviour using thesame code. We will see later, that the IEC 61499 function block model providesfacilities to allow function blocks to share interfaces and therefore have polymorphicbehaviour.

In function block world, the system designer’s main focus is to take standardproven encapsulated functionality and link it together in the quickest and mostintuitive way possible. The use of function blocks is nearer to the mind-set of theindustrial system designer who is familiar with connecting physical devices togetherin different ways to provide a particular system solution.

Function blocks share many of the benefits from using software objects. Sowhat are the useful features of an object? An object is a self-contained softwarepackage that has its own procedures (called methods) that manipulate the object’sinternal data. Some of the methods provide an external interface (called publicmethods) for communicating with other objects. “The key characteristic of anobject is that it provides a fusion of process logic with data.”—see DistributedObjects for Business [9].

The main benefits from using objects can be summarised as:

• Objects reflect the real worldWhen designing an application it is more natural and intuitive to represent real-world entities associated with an application as objects, e.g. document,employee, and product.

• Objects are stableGenerally objects are proven software elements that do not change significantly.In many cases, developers use the same object classes in a wide range ofapplications. For example, when an object has been created that represents allthe behaviour and characteristics of an entity such as ‘product supplier’ thiscould be used in a wide range of different business applications dealing withsuppliers. A ‘product supplier’ object would typically have details such as name,address, product ranges, trading terms etc., and methods for obtaining andupdating this information.

• Objects reduce complexityA developer can work with an object without really understanding how theobject works internally. An application can be developed by creating and linkingobjects—there is generally no need to understand the object’s internals.


• Objects are reusableOnce an object has been developed and tested it can become part of a developer’srepertoire. In some cases an object can be published in a library where it can beused by developers either locally or even globally.

Function blocks also share most of these characteristics which results in somesignificant benefits to the system developer and end-user:

• the quantity of control software to be developed for an application is reducedby using function blocks

• the time required to develop control systems is reduced• control systems using the same types of function block will have more consistent

behaviour• the quality of control systems will be improved.

Table 1.1 highlights the main similarities and differences between objects andfunction blocks. The notable shortcoming of the IEC 61499 function block modelis that there is no provision for inheritance. However, future extensions to thestandard may consider mechanisms that bring function blocks closer to softwareobjects.

Table 1.1 Objects and function blocks compared

Feature Objects Function Blocks Comment

Encapsulated � � Objects may contain data thatdata is also instances of other

objects. Function blocks maycontain instances of otherfunction blocks

External � � In IEC 61499 function block,interface there is no distinction between

private and public interfacesInvocation Objects have Function blocks With function blocks, data can

methods with use input and be synchronised with an eventarguments and output variablesreturned values and events

Inheritance � � Currently in IEC 61499 there isno mechanism for a functionblock to inherit behaviour

Polymorphism � � IEC 61499 introduces a new‘adaptor’ concept that allowsfunction blocks to sharecommon interfaces

Instantiated An object class Function blockfrom a class and function instances are

block type are defined fromsynonymous function block

type

Introduction 17

System design views

The design of software for any large project can be very complex. Where there isalso some aspect of distributed control involving software running in differentprocessing resources, the design problems can be daunting. There is a clear require-ment for a number of graphical design views to allow the different aspects of adesign to be analysed and expressed. Some views will express the abstract aspectsof the design while others are required to show the physical structure of the systemor the way the software is organised.

No matter how hard people have tried, it is just not possible to convey all aspectsof a system design using one design methodology. There are so many design issuesto consider that they cannot be expressed in a single type of graphical notation;issues such as:

• What is the top-level software structure?• What functionality does the system deliver to its end-users?• How is the functionality distributed throughout the system?• How are the system components connected?• How are the software libraries and standard components managed?• How does the system respond to certain critical events?

Many system design problems are a result of trying to use too few or inappro-priate different design methodologies to depict all the aspects of a system design. Aparticular design view might be able to show how software for a system is logicallyconnected, but it would not be able to depict the way the system responds to events.

In fact, it is now recognised that most complex software designs can require atleast four different design views and a set of scenarios — this forms an architectureknown as the 4+1 View Model, as proposed by Kruchten [10] (Figure 1.11).

Although Kruchten has considered applying these design views to the world ofobject oriented software, the same design views are also applicable to distributedcontrol system design.

Logical view

This design view is used to depict the functional requirements of the system. Itexpresses the software functionality as required by the system user. In a distributedsystem design, it would show the main software function blocks and the maininterfaces between them. Issues such as how the system functionality is distributedand executed are not addressed.

A methodology such as the IEC 61131-3 Function Block Diagram languagecould be used to define some aspects of the logical design view, as discussedearlier in this chapter.

Process view

The process design view is concerned with many of the non-functional requirementsof a system; these include performance, system distribution and issues such as


concurrency. Kruchten defines the Process View as depicting “logical networks ofcommunicating programs that are distributed across a set of hardware resources”.

This corresponds almost exactly to the concepts in the IEC 61499 FunctionBlock standard which provides an architecture for depicting the implementationview of a distributed system as networks of interconnected function blocks.

Development view

The development view depicts how the software that is used to build a large systemis organised. Building a large distributed control system will involve numeroussoftware libraries and software modules. The development view shows therelationships between software components, such as function blocks in terms ofease of reuse, constraints, component size and version compatibility. For example,consider a function block used for conveyor control; we would want to indicatewhich device types support it and we would like to show any constraints on otherblocks that need to interact with it.

Currently there is no IEC standard methodology that deals with the developmentview of a distributed control system.

Physical view

In a distributed control system, the physical view is well understood. It depicts thephysical devices and controllers in a system and shows the various networkcommunications links between them.

Figure 1.11 The 4+1 View Model of system development

System userfunctionality

System software managemente.g. function block libraries

Distribution of functionality showing ‘threads of control’ – IEC 1499 function block diagram

System topology –network layout, devices, controllers

LogicalView

DevelopmentView

Scenarios

PhysicalView

ProcessView

Introduction 19

A physical view will generally consider the physical configuration of the systemshowing the location of devices and details on bus and communications links.

Scenarios

The last but important design view that completes any system design is whatKruchten calls “Scenarios”. A scenario depicts the major interactions betweenunits of software to provide the most important, key functionality of a system. Forexample, in a distributed control system, some important scenarios to considermight be: system start-up, device fault detection and recovery, recipe activation,and system shutdown. Each scenario would consider the interactions between thedifferent functional parts of the software. A scenario might show both aspects ofthe logical and process design views.

By describing the various scenarios, the designer can review and test the designby asking a series of ‘what if?’ questions. The design cannot be considered to becomplete until all the key scenarios have been defined. There is currently nomethodology defined by any IEC standard that can be used to define scenarios fordistributed control systems.

From this quick overview of the 4+1 View Model of Architecture, it is clearthat IEC 61499 provides just one of the five design views required for distributedcontrol systems. However, IEC 61499 does represent an important step towards aunified design architecture. The other views will no doubt emerge as designersstart to face the challenge of building large distributed systems.

The future beyond IEC 61499

The function block model proposed by IEC 61499 has been criticised for notadopting concepts from object oriented (OO) software technology. For example,there are currently no concepts of inheritance; function blocks are not able toinherit behaviour from, say, a block base class. The standard has started bymodelling existing industrial function block concepts but extensions to movetowards OO concepts will undoubtedly need to be considered in the near future.

New industrial standards for communications and software components willclearly bring benefits in allowing physical devices and software to be readilyinterconnected. However, before we can achieve truly interoperable softwarecomponents that can be used to implement large systems, we need to agree ongeneral methods for describing requirements such as information models and datatransformations. It is the intention that IEC 61499 should be able to address thisproblem in the domain of industrial control systems.

In the following chapters we will review the concepts from IEC 61499 and seehow this new standard can be used to model the design of distributed controlsystems.

IEC 61499 models and concepts 21

Chapter 2

IEC 61499 models and concepts

We will now review the main models and concepts defined in IEC 61499 to gain ageneral overview of the Function Block Standard. It is advisable to have someunderstanding of the material in this chapter before proceeding to any of thefollowing chapters where we will review specific features of IEC 61499 in moredetail.

Topics covered in this chapter include:

• the system, device and resource models for distributed control systems• models for representing distributed applications• characteristics of function blocks and their execution• type specifications for different forms of function block• service interface function blocks to provide interfaces into hardware and

operating systems• adapters for sharing block interfaces• textual syntax for defining IEC 61499 entities.

Before we proceed to look at the many models and concepts introduced by IEC61499 in detail, let us reconsider the scope of the IEC 61499 standard as firstdiscussed in the introductory chapter. Surprisingly the primary purpose of IEC61499 is not as a programming methodology but as an architecture and model fordistributed systems. There is no intention that the standard, as defined, will beused directly by programming tools. Instead, IEC 61499 provides a set of modelsfor describing distributed systems that have been programmed using functionblocks. This is an important distinction and must be understood to avoid many ofthe misunderstandings about IEC 61499.

If it does not let you program a distributed control system, how can it be of anyuse? IEC 61499 provides terminology, models and concepts to allow the imple-mentation of a function block oriented distributed control system to be describedin an unambiguous and formal manner. Having a formal and standard approach todescribing systems will allow systems to be validated, compared and understood.This is the first step towards standard programming methodologies for distributed


systems. The IEC 61499 standard writers have taken the view that it is not possibleto have a consistent programming methodology unless there is a consistent architec-ture that underpins what we are trying to program. However, undoubtedly in thefuture IEC 61499 concepts may also be used as part of system design methodology.

We will now review the various models introduced by IEC 61499 that togetherform the architecture for a function block oriented distributed system.

System model

At the physical level, a distributed system consists of a set of devices interconnectedby various networks to form a set of co-operating applications. An application,such as the control of a production line, process vessel, and conveyor will typicallyrequire the interoperation of software running in a number of devices. Until veryrecently, a typical distributed application has involved a small percentage of soft-ware running in remote devices such as loop and temperature controllers, whilestill having the main intelligence back in a central device such as a PLC. As devicessuch as smart sensors and actuators start to provide more processing capability,software functionality can become truly distributed across many more devices, toa point where it is difficult to identify a main controlling device.

We will start by looking at the top level system model defined in IEC 61499.This defines the relationship between communicating devices and applications.An application can exist on a single device or have functionality distributed over anumber of devices. A distributed application will be designed as a network ofconnected function blocks. However, when the application is loaded onto a systemit will typically be loaded as a series of function block network fragments that arelocated into different devices. Communication services provided by each device

Figure 2.1 IEC 61499 system model


ensure that function blocks that form part of an application maintain their data andevent connections.

Note: The IEC 61499 system model allows devices to support the execution ofmore than one application. The standard defines a device model in which it ispossible to load and unload distributed applications without disturbing existingapplications; this is achieved through the use of management services within thedevice—these will be reviewed later in chapter 4.

Device model

The device model shown in Figure 2.2 introduces some further important concepts.A device is able to support one or more resources. An IEC 61499 resource hassimilar properties to the resource concept defined in the PLC Programming Lan-guages standard IEC 61131-3. A resource provides independent execution andcontrol of networks of function blocks.

The device model has a ‘process interface’ that provides the services that enableresources to exchange data with the input and output (I/O) points on the physicaldevice. There is also a communications interface that provides communicationsservices for resources to exchange data via external networks with resources inremote devices.

The internal structure and behaviour of the process and communicationsinterfaces are not within the scope of IEC 61499 but they are expected to providea range of services to support the execution of function blocks within the resources.

Figure 2.2 Device model

Communications interface

Process interface

Resource A

Application 2

A device may have one or more resources,communication interfaces to other devices and aprocess interface.

Resource B Resource C

Application 3

Application 1


The purpose of the device is to provide an infrastructure to sustain one or moreresources. Fragments of function block networks are distributed between resourcesthat exist either on the local device or in resources on remote devices.

Resource model

The resource provides facilities and services to support the execution of one ormore function block application fragments. Function blocks of a distributed systemwill be allocated to resources within interconnected devices. In fact, the mainfocus of IEC 61499 is to model the behaviour of function blocks within eachresource. The resource provides interfaces to the communications systems and tothe ‘device specific process’, i.e. to external services and sub-systems that areclosely connected to the device, such as the device I/O sub-system. For example,each resource will have an interface to the communications system to allow functionblocks to exchange data with blocks in remote resources and an interface to readand write to local device inputs and outputs (I/Os). The resource is thereforeconcerned with the mapping of data and event flows which pass between functionblocks in the local resource to remote resource function blocks via the devicecommunications interfaces. Similarly the resource maps all requests to read andwrite to device I/O onto the process interfaces.

It is clear that the resource defines the important boundary that exists betweenwhat is within the scope of the IEC 61499 model and what is device and systemspecific functionality. Issues such as operating system design and communicationsprotocols that are specific to types of devices and networks are, as yet, outside thescope of the standard.

Figure 2.3 depicts the main features of an IEC 61499 resource. Within theresource, it shows a network of interconnected function blocks linked by data andevent flows. A scheduling function provided by the resource ensures that algorithmswithin function blocks are executed in the correct order, i.e. as required by thearrival of events at each function block. ‘Service Interface’ (SI) function blocksare a special form of function block that provide a link between function blocksand the interfaces of the resource. For example, a communications SI block canbe used to read or send data to function blocks in remote resources. A number ofdifferent types of SI blocks are identified and defined in IEC 61499 and aredescribed in detail in chapter 4.

An important characteristic of a resource is that it supports independent opera-tion. A resource can be loaded, configured, started and stopped without affectingother resources in the same device or network.

However, it is important to note that the management of a distributed applicationmay require the co-ordinated control of a number of resources where functionblock network fragments are loaded, e.g. when loading and starting the variousfunction block network fragments that make up the distributed application. Thefacilities required to achieve such co-ordination is an issue not yet fully addressedby IEC 61499.


Application model

An IEC 61499 application is defined as a network of interconnected functionblocks, linked by event and data flows. An application can be fragmented anddistributed over many resources. Within an application, further decomposition ispossible using subapplications. A subapplication has the external characteristicsof a function block, but can contain networks of function blocks that can, them-selves, be distributed over other resources. The standard defines a ‘fractal’ form ofapplication decomposition that allows subapplications to be further decomposedinto yet smaller subapplications if required.

The application defines the relationships between events and data flows thatare required between the various blocks. The various resources on which the blocksare distributed must ensure that events are used to schedule the appropriatealgorithms within the blocks at the correct priority and time. The resources areresponsible for retaining the values of variables within function blocks betweenalgorithm invocations. The resources are also concerned with propagating eventsand transferring data between function blocks either on the same resource orbetween resources.

Features of the IEC 61499 application model are shown in Figure 2.4.In practical terms, an application is the entire set of function blocks and inter-

connections to solve a particular automation control problem. Examples mightbe: the set of function blocks required to control a production line, a plastics xtruder,or a fermentation vessel.

Figure 2.3 Resource model

Serviceinterface

FB

AlgorithmFB

Serviceinterface

FB

Communications interface

Process interface

Scheduling function

Communicationsmapping

Processmapping

Events

Data

Local application or fragmentof distributed application


Note that IEC 61499 function blocks contain all algorithms and initialisation valuesto define their complete behaviour.

An application therefore consists of function block instances and interconnectiondefinitions which, in some cases, includes multiple instances of function blocksof particular block types. It is a principle of IEC 61499 that all behaviour is definedin terms of function blocks. As a result, we will see that there are no global orlocal variables in an application that can exist outside of function blocks. This isan important distinction between an application program created for a PLC basedon IEC 61131-3 and an IEC 61499 application.

Function block model

At the core of the standard is the function block model that underpins the wholeIEC 61499 architecture. A function block is described as a ‘functional unit ofsoftware’ that has its own data structure which can be manipulated by one or morealgorithms. A function block type definition provides a formal description of the

Figure 2.4 Application model

ServiceInterface

block

Resource 1

ServiceInterface

block

Resource 2

Event flows

Sub-application

Data and events passedbetween applications viaService Interface blocks

Data flows

Application – distributed over resources

Subapplication – distributed over resources

ServiceInterface

block

Resource 2

ServiceInterface

block

Resource 2Resource 3


data structure and the algorithms to be applied to the data that exists within thevarious instances.

This is not a new concept but based on common industrial practice applied toreusable control blocks of various forms. A good example is the Proportional,Integral and Derivative (PID) block used in many PLCs and controllers. The systemvendor will typically supply a type definition for a PID block. The programmercan then create multiple instances of the PID block within the control program,each of which can be run independently. Each PID instance, such as ‘Loop1’,‘Loop2’ will have its own set of initialisation parameters and internal state variablesand yet share the same update algorithm.

IEC 61499 defines several forms of function block, which we will review indetail in later chapters. The main features of a function block are summarised asfollows:

• Each function block type has a type name and an instance name. These shouldalways be shown when the block is depicted graphically.

• Each block has a set of event inputs, which can receive events from other blocksvia event connections.

• There are one or more event outputs, which can be used to propagate events onto other blocks.

• There is a set of data inputs that allow data values to be passed in from otherblocks.

• There is a set of data outputs to pass data values produced within the functionblock out to other blocks.

• Each block will have a set of internal variables that are used to hold valuesretained between algorithm invocations.

• The behaviour of the function block is defined in terms of algorithms and stateinformation. Using the block states and changes of state, various strategies canbe modelled to define which algorithms are to execute in response to particularevents.

In Figure 2.5, the main characteristics of an IEC 61499 function block aredepicted. The top part of the function block, called the ‘Execution Control’ portioncontains a definition in some cases, given in terms of a state machine, to mapevents on to algorithms; i.e. it defines which algorithms defined in the lower bodyare triggered on the arrival of various events at the ‘Execution Control’ and whenoutput events are triggered—what the standard calls the ‘causal relationship amongevent inputs, event outputs and the execution of algorithms’. The standard definesmeans to map the relationships between events arriving at the event inputs, theexecution of internal algorithms and the triggering of output events—this will bediscussed in later sections of this chapter.

The lower portion of the function block contains the algorithms and internaldata, both of which are hidden within the function block. A function block is atype of software component and, if well designed, there should be no requirementfor a user to have a detailed understanding of its internal design.


A function block relies on the support of its containing resource to providefacilities to schedule algorithms and map requests to communications and processinterfaces.

The standard states that a resource may optionally provide additional featuresto allow the internals of a function block to be accessed. Clearly, say in a Fieldbusdevice, it would be always useful for maintenance or commissioning purposes tobe able to examine the internal variables within a block. So there may be ‘back-door’ methods to access function block internals; however, from the IEC 61499architecture view point, control variables and events are only passed by the externalexposed interfaces.

Figure 2.5 Function block characteristics

Execution control(hidden within block)

Algorithms(hidden within block)

Internal data(hidden within block)

Event flow Event flow

Data flow Data flow

Data inputs Data outputs

Event inputs Event outputs

Instance Name

Type Name

Resource capabilities(scheduling, communications and process mapping)


Function block types

An important concept in IEC 61499 is the ability to define a function block typethat defines the behaviour and interfaces of function block instances that can becreated from the type. This is synonymous with the way in object oriented (OO)software that the behaviour of object instances is defined by the associated object’sclass definition.

A function block type is defined by a type name, formal definitions for theblock’s input and output events, and definitions for the input and output variables.The type definition also includes the internal behaviour of the block but this isdefined in different ways for different forms of block.

Basic function block types

The behaviour of a basic function block is defined in terms of algorithms that areinvoked in response to input events. As algorithms execute they trigger outputevents to signal that certain state changes have occurred within the block. Themapping of events on to algorithms is expressed using a special state transitionnotation called an Execution Control Chart (ECC).

Composite function block types

The internal behaviour of composite function block and subapplication types isdefined by a network of function block instances. The definition therefore includesdata and event connections that need to exist between the internal function blockinstances.

Service Interface function block types

Service Interface (SI) function blocks provide an interface between the functionblock domain and external services, for example to communicate with functionblocks in a remote device or to read the value of a hardware real-time clock. Becausean SI function block type is primarily concerned with data transactions, it is definedusing time sequence diagrams. This form of diagram is more commonly used todefine transactions across communications interfaces. Time sequence diagramsare described later in this chapter in the section on Service Interface blocks.

Execution model for basic function blocks

A special execution model is used to define the behaviour of a basic functionblock. This is best described with the aid of Figure 2.6 for basic function blocks.The numbered features on the function block show the order in which the differentparts of the block are handled by the underlying ‘scheduling function’. The modelassumes that the resource in which a function block exists provides a scheduling


function that ensures that each phase of function block execution occurs in thecorrect order and at the correct priority.

There are a number of discrete timing phases, each of which may take someperiod of time to elapse, required for the basic function block to execute; eachphase depends on defined interactions between the function block and theunderlying scheduling function. Figure 2.6 depicts the eight timing points whichmust occur sequentially for the basic function block to operate; the termination ofeach phase is defined by a particular numbered timing point.

Time 1 Values coming from external function blocks are stable at the functionblock inputs.

Time 2 An event associated with the input values arrives at the event input.Time 3 The function block execution control signals to the scheduling function

that it has input values and is ready to execute its algorithm.

Figure 2.6 Execution model for basic function blocks

Execution control

Algorithms

Internal data

Scheduling function

3

Type Name

4 6 7

1

2 8

5


Time 4 After some period of time as determined by the loading and perfor-mance characteristics of the resource, the scheduling function starts toexecute the function block’s algorithm.

Time 5 The algorithm processes input values and, in some cases, also processesinternally stored values to create new output values that are written tothe function block’s outputs.

Time 6 The algorithm completes its execution, and signals the schedulingfunction to indicate that output values are stable and ready.

Time 7 The scheduling function invokes the function block’s execution controlto generate an output event. Different output events may be generateddepending on which input events have arrived and the internal state ofthe execution control.

Time 8 The execution control in turn creates an appropriate output event at thefunction block’s output event interface. The output event is used bydownstream function blocks to signal that they can now use outputvalues generated by this block.

It is important to note that there are a number of constraints on this executionmodel. These timing phases cannot overlap and must occur in the prescribed orderfor the function block to execute correctly. However, in some implementations,some phases can be so short in duration as to be regarded as being instantaneous.IEC 61499 does not define limits on any of these times. However, it does state thatin any function block model it should be possible to define the duration of thesedifferent phases in order to accurately model the timing characteristics of thecomplete function block network.

The standard defines the following durations that will be significant whenbuilding applications:

Tsetup

= Time2 – Time1 time between receiving input values and theirassociated input event arriving

Tstart

= Time4 – Time2 time between receiving an input event and executingthe algorithm; this duration may depend on the resourceloading, i.e. how many other function blocks are alsoin the scheduling function’s pending queue

Talgorithm

= Time6 – Time4 time between starting and completing the functionblock’s algorithm

Tfinish

= Time8 – Time6 time from finishing the algorithm and raising the outputevent.

The relationship between these timing points is depicted in Figure 2.7; the pointswhere the input and output data from the function block change are also shown. Itshould be noted that the standard assumes that events behave as discrete points intime and have no duration. In a physical system, events may require the transfer ofsome form of state change information between blocks and may have a short butfinite duration.


It is clear that in different implementations a variety of mechanisms may benecessary to ensure that the function block is able to execute using consistentdata. For example, it is important that input data values remain stable while analgorithm executes. The algorithm should only use input values that exist at thetime the input event arrives, i.e. the input event can be used to snapshot the inputvalues ready for algorithm execution. It is also very important for the underlyingscheduling function to detect when a function block receives input events at afaster rate than can be handled by the block.

The IEC 61499 model assumes that there are no input event and data queues;an implementation may provide some form of input queuing but this is not explicitlymodelled by IEC 61499. However, such behaviour may be modelled by creatingspecial function blocks built-up from networks of basic blocks. The model doesallow resources to provide facilities to process function block algorithms usingmultitasking. With appropriate prioritisation of events within the schedulingfunction, it is possible for most event overloading problems to be avoided. However,note that the characteristics and internal behaviour of the scheduling function arenot currently within the scope of this standard.

Figure 2.7 Execution timing

Tsetup

Tstart

Talgorithm

Tfinish

1 2 3 4 5 6 7 8

Input data

Input event

Output data

Output event


Distribution model

There is an important differentiation between function blocks and applications.Both applications and subapplications can be ‘distributed’, that is, configured torun on several resources. A distributed application will consist of a network offunction blocks with fragments of blocks running on designated resources. Notethat IEC 61499 considers distribution to concern the arrangement of function blockson different resources. Because a device can support multiple resources, it is pos-sible for a distributed application to run on a single device, i.e. using resourceswithin the same device. A subapplication is a smaller form of application that canbe replicated but otherwise has the same distribution characteristics as anapplication.

The timing and performance of an application or subapplication will dependon the resources on which it has been distributed and the communications networksthat connect them. For example, consider two identical subapplications, forconveyor line control, running on two different networks of controllers, one networkusing fibre optic data links running at 10 MBaud and the other using lower costtwisted-pair copper running at 98 KBaud. Because the communications data ratesof the two networks are so different, the two subapplications will clearly havedifferent performance and response times due to network latencies, although theirinternal software algorithms will be the same.

In contrast, function blocks are assumed to be ‘atomic’ and to only run in asingle resource. In this respect, the performance of a function block is not affectedby the characteristics of communications networks. However, the performancemay to a lesser extent be affected by the behaviour and characteristics of the resourceand device in which the block has been instantiated. These distributioncharacteristics are summarised in Table 2.1.

Management model

We have seen that a resource can support fragments of function block networksthat form parts of distributed applications or subapplications. But how are these

Table 2.1 Distribution characteristics

Distributable Timing Reliability Replication

FFFFFunction blockunction blockunction blockunction blockunction block No Depends on Depends on As instancesdevice only device only from FB Type

SubapplicationSubapplicationSubapplicationSubapplicationSubapplication Yes Depends on Depends on As copies ofdevices and devices and subapplicationcommunications communications type

ApplicationApplicationApplicationApplicationApplication Yes Depends on Depends on Nodevices and devices andcommunications communications


application fragments created and managed? For this purpose, IEC 61499 alsodefines a special form of application called a ‘management application’ that isresponsible for the creation of function block networks within a resource. Themanagement application, with higher privileged functionality than normalapplications, can construct parts of other applications by creating function blocksand connections. It typically will interface with external agents such as remoteprogramming stations via communications links.

The functionality of a management application will include:

• creating function block instances within a resource• associating function block fragments with a particular application• creating data and event connections between function blocks and service inter-

face blocks• initiating the execution of function blocks as part of a distributed application• providing services to support queries from communication links on the status

of function block instances• deleting function block instances along with their data and event connections.

An important constraint is that the management application should be able toload function block network fragments for different applications without disturbingthe execution of other running applications.

So it may now be asked, what is then responsible for loading the managementapplications? It is assumed that a device will need a certain level of baseline func-tionality within the management application in order to ‘bootstrap’ load the functionblocks for the main applications. It is likely that part of the management applicationwill exist in a non-volatile form within the device and is always able to load applica-tions when the device is powered-up.

Note that some devices may hold all their function block networks in a non-volatileform that cannot be modified via external communications, in which case most ofthe functionality of the management application may not be required.

The standard proposes two schemes for providing management applications.Figure 2.8 depicts a device which has a special ‘Management resource’ that containsmanagement applications that provide functionality to build and maintain functionblock networks in the adjacent resources provided in the device.

In Figure 2.9 an alternative arrangement is defined where each resource containsa management application that is responsible for loading function block networkswithin the same resource.

Management applications can be modelled in exactly the same way as otherapplications using networks of function blocks and service interface functionblocks. It is likely that a management application will require a number of serviceinterface function blocks to handle the interfacing with external communicationslinks, e.g. to process requests to create function block instances.

The functionality of a management application is not yet defined in detail withinIEC 61499 but clearly this is an important area that will need to be standardised


Figure 2.8 Shared function block management

Device boundary Communications links

Controlled process

Application A

Application B

Management resource

Communications interface(s)

Device management application

Resource X managementapplication

Resource Y managementapplication

Process interface(s)

Resource X Resource Y

Figure 2.9 Distributed function block management

Device boundary Communications links

Controlled process

Application A Application B

Communications interface(s)

Process interface(s)

Resource X Resource Y Resource Z


before it is possible to load and configure IEC 61499 compliant devices in aconsistent manner.

Operational state model

Large systems based on networks of IEC 61499 function blocks will typically bedeveloped, commissioned and brought on-stream in a series of stages. So within afunction block network, IEC 61499 proposes that the concept of ‘life-cycle’ ismodelled and applied to functional units such as devices, resources and applications.As with all large software based systems, this is necessary so that it is possible tomanage and track the states of the different component parts.

The operational state model is not yet fully defined within the standard but it isproposed that each functional unit will have well defined states such as:

• STOPPED – unit is not running• LOADED – unit has been loaded, for example a device may be in a ‘loaded’

state when all function block definitions and associated function block instancesfor an application have been loaded into a device

• CONFIGURABLE – unit is loaded and ready to be configured prior tobecoming operational; a device would be in a ‘configurable’ state when functionblock instances have been loaded but still await function block connection details

• OPERATIONAL – unit has been loaded and configured and is ready to startexecution or support the execution of part of a loaded application

• RUNNING – the unit is fully operational and is running.

To control and synchronise the loading of a distributed application, the standardproposes that strategies are developed to ensure ‘a consistent operational stateacross its components’. For example, a distributed application may require thatfragments of function block networks are loaded onto a number of differentresources located in a variety of different and, in some cases, remote devices. Theloading and configuration of the function blocks residing in the different devicesmay occur at different times; however, the switch from ‘Operational’ to ‘Running’states for all associated devices and resources may need to be synchronised for anapplication to start-up correctly.

The standard also foresees situations where certain privileged functional unitsmay take control of other function units. For example, a ‘job loader’ function blockin device A may be used to load new function block definitions in remote devicesB and C in order to modify an application for a certain type of batch profile. Insuch cases, there is a requirement to be able to give certain blocks the rights toload, configure and change the states of other blocks. The management applicationfunction blocks that have already been introduced in this chapter will clearly needto have special privileges to be able to load and start complete applications.

Application management and the control of application operational states is anarea that still awaits development within IEC 61499 and will probably be addressedin other sections of the standard.


Common interfaces using adapters

One of the great strengths of object oriented (OO) software is the ability to havedifferent objects sharing the same interfaces. It is general practice in OO softwarefor objects that represent entities with similar basic characteristics to have parts oftheir external interface in common. For example, when designing graphical userinterfaces (GUI), it is typical for graphical entities with similar characteristicssuch as objects representing circles and squares to have common interface methods.For example, objects representing items such as squares and circles are likely tohave numerous methods in common, such as for resizing, moving, copying andcolour filling.

Sharing of behaviour is achieved in OO software through a technique called‘inheritance’. This allows new specialised objects to ‘inherit’, i.e. share, the sameinterface and basic behaviour from another more generic type of object. Havingdifferent types of objects with common interfaces gives significant benefits insoftware design. It means that software can be created that is more flexible andcan be applied to a wider range of objects—a powerful technique that is now knownas ‘polymorphism’.

It is recognised that some form of ‘polymorphic’ behaviour is also useful infunction block design. A good example of this concerns function blocks that handlesensors with similar characteristics. We could envisage blocks handling analoguesensors, say for temperature and differential pressure, to have some commonfeatures in their interfaces. For example, both would need to be able to set highand low alarm levels, and detect out of range conditions. It would clearly be usefulto be able to have the same software for handling the common aspects of functionblocks for different types of sensors.

To facilitate support for common interfaces, IEC 61499 defines a special conceptcalled an ‘adapter interface’. This allows function blocks that have similarbehaviour to share the same interface by attaching a special type of function block.This type of function block is called an ‘adapter’. It is analogous to an electronicdevice that can be connected to other devices providing specialised behaviourusing a plug and socket arrangement. The concept is depicted graphically in Figure2.10; the left-hand side of this figure shows the adapter block that is able to connectclosely with a specialised block above it; on the right-hand side we see that thetwo blocks are joined to form an adapter connection.

To further clarify the benefits from using adapters, consider the design of functionblocks to handle various forms of analogue input. Let us consider a block to handletemperature input and another to handle a differential pressure input. Clearly eachblock will require its own specialised interface inputs and outputs. The temperatureblock will require inputs to define thermocouple ranges, calibration offsets, scalingand so on, while the differential pressure input will require specialised inputs andoutputs to define pressure hysteresis, and pressure sensor characteristics. However,both blocks will also have a range of inputs and outputs that are common. Justconsider the requirements for alarm definition and creation; it would clearly bemore efficient and consistent to have a standard implementation of alarm handling


encapsulated in a block. Figure 2.11 depicts how the adapter concept can be usedto provide a common block for alarm management that can be connected tospecialised blocks that have the specific behaviour and interfacing for differenttypes of sensors.

In IEC 61499, function blocks can be configured to either an adapter ‘provider’or an ‘acceptor’. In our example, the alarm block is depicted as an adapter ‘provider’while the sensor specialisation blocks ‘Temperature’ and ‘Diff_Pressure’ are theadapter ‘acceptor’.

Note that common behaviour can be modelled in different ways. It would also bepossible in this example to have a common sensor block as an adapter acceptorthat has all the shared behaviour and then to attach specialised blocks as adapterproviders to give the sensor specialisation.

Textual syntax for IEC 61499 entities

A significant feature of the IEC 61499 standard is a rich textual syntax that allowsthe models of entities such as applications and function blocks to be described ina text language. The textual definitions can be used to unambiguously define modelsso that the graphical representations can be created automatically and consistently.

Figure 2.10 Adapter interfacesNote: This figure depicts the adapter concept; it does not depict howadapters are shown graphically using IEC 61499.

Adapter acceptor

Adapter provider

adapter insertion adapter connection

specializedinterface

genericinterface


For example, a composite function block may be constructed from a network ofseveral smaller blocks with appropriate data and event connections. All aspects ofthe internal design of the composite block can be represented using the IEC 61499textual syntax.

It is envisioned that it will be possible to compile textual definitions as a meansto check the validity of a particular model. The textual form is certainly useful forporting model designs from one workstation platform to another. It defines thesemantic aspects of the model but does not fully describe the graphical details.For example, a particular model may have been developed showing function blockslocated at certain positions in a network diagram. The actual location and finergraphical details such as colour and font are not part of this syntax. However, thelogical connections between blocks are defined precisely.

Note: In Part 2 of the IEC 61499 standard, graphical attributes can be transferredusing a file exchange format based on XML. This is reviewed in chapter 7.

The standard contains an extensive annex that describes the production rulesfor all the features of the textual syntax. Note that some aspects of this syntax willbe described in this book but for full and exact definitions it is advisable to seeAnnex B in Part 1 of the IEC 61499 standard.

2 out of 3 voter example

A simple function block is used here to illustrate some of the features of the textualsyntax. Many features of the syntax will be discussed in more detail in later chapters.

Consider a function block that applies a ‘2 out of 3 voting’ algorithm on threeinputs A, B and C. This can be modelled as a ‘basic’ function block as depicted in

Figure 2.11 Adapter example

TemperatureSensitivityCalibrationSensorRange>>AlarmSkt

TempMaxValue

temperatureinput block

AlarmHighHighHighLowLowLow

HighAlmLowAlm

AlarmPlug>>

alarminterfaceblock

Diff_PressurePressRangePressSensorHysteresisOffset>>AlarmSkt

PressRate

differentialpressureinput block

AlarmHighHighHighLowLowLow

HighAlmLowAlm

AlarmPlug>>

alarminterfaceblock

adapter connection adapter connection


Figure 2.12. The block has two event inputs, Reset and Vote. The Reset eventtriggers an algorithm to reset the stored internal state of the voter. When the resetalgorithm has successfully been completed, an event is produced at the Readyoutput.

The Vote event is used to trigger the main voter algorithm which checks thestate of the three boolean inputs A, B and C. If two or more inputs are true, theoutput State is set to true and remains true until the reset algorithm is executed.When the voter algorithm has been completed, an event is produced at the Votedevent output.

The textual syntax to describe the Voter function block is as follows:

FUNCTION_BLOCK VOTER (* Voter FB *)EVENT_INPUTReset; (* Reset event *)Vote WITH A,B,C; (* Trigger Voter *)

END_EVENTEVENT_OUTPUTReady;Voted WITH State;

END_EVENTVAR_INPUTA : BOOL;B : BOOL;C : BOOL;

END_VARVAR_OUTPUT State : BOOL;END_VAREC_STATES Ready : ResetAlg -> Ready;Voted : VoteAlg -> Voted;

END_STATES

Figure 2.12 Voter function block example

Reset

Vote

A

B

C

State

Voted

Ready

Voter


EC_TRANSITIONSReady TO Voted := Vote;Voted TO Voted := Vote;Voted TO Ready := Reset;

END_TRANSITIONS

ALGORITHM ResetAlg IN ST; (* Reset Algorithm *)State := 0; (* Reset the state output *)

END_ALGORITHM

ALGORITHM VoteAlg IN ST; (* Voter algorithm *)IF State = 0 THENState := (A AND B) OR (A AND C) OR (B AND C);

END_IF;END_ALGORITHM

END_FUNCTION_BLOCK

The following points can be noted from this example:

• The textual definition includes EVENT_ and VAR_ sections to declare all theevents and data for the input and output interfaces of the block.

• The internal states of the block are defined and associated with the events thattrigger transitions between states; this is declared in EC_STATES andEC_TRANSITIONS sections.

• Algorithms are triggered by events when the block is in a particular state asdefined in the EC_STATES section of the block definition.

• Each algorithm can be defined in a particular textual language. In this exampleboth the ResetAlg and VoteAlg algorithms are defined using the StructuredText (ST) language; this is a high level language defined in the PLC program-ming languages standard IEC 61131-3. However note that IEC 61499 does notpreclude the use of other languages such as JAVA or C to define the algorithmcontents. In fact, surprisingly, IEC 61499 does not define the textual syntax foralgorithm definition but allows any existing standard textual language to beused.

Summary

We have now reviewed the main concepts introduced by IEC 61499 that provide aframework and architecture to model function block oriented distributed systems.To summarise:

• The System model defines a set of interconnected devices that can communicatevia network connections.


• The Device model supports one or more resources which provide support forthe loading, configuration and execution of function block networks.

• An application can reside on one or more resources. Each resource can supportthe management and execution of part of an application, with each part beingdistributed as a fragment of a function block network.

• There are both basic and composite function blocks for dealing with differentforms of block construction and block hierarchy.

• Service Interface blocks provide network communications and hardwareinterface facilities.

• The adapter concept allows function blocks to share generic interfaces.• The IEC 61499 textual syntax provides a concise and compilable form for porting

and creating definitions of entities such as function blocks and applications.

Defining function block and subapplication types 43

Chapter 3

Defining function block andsubapplication types

In this chapter we will review how to create type definitions for function blocksand subapplications and show how these can be used to create function blockinstances and copies of subapplications.

Specifically we will:

• review different forms of function block definition• show how events and data interfaces can be defined• examine how algorithms are constructed and linked to the event execution• consider how instances of function blocks behave• review where subapplications can be used and compare their behaviour and

properties with composite function blocks.

Types and instances

Before proceeding to define the mechanisms provided in IEC 61499 to definefunction block types in some detail, let us recall the role of function block typesand instances. A function block type definition describes the external interfaceand internal behaviour of a particular type of function block. However, a functionblock instance is, in effect, a working copy of the function block created using thefunction block type definition. In a large system it is likely that function blocktype definitions will be held in various libraries, for such purposes as, ‘controlalgorithms’, ‘alarm management’, ‘input sensors’ and so on. The configuration ofa large function block based system will require the selection of appropriate functionblock type libraries and then the declaration of function block instances based onselected function block types. Clear, precise and unambiguous definitions offunction block types are therefore germane to using IEC 61499 effectively.


Different forms of function block

The standard provides type definitions for three different forms of function block;each form has its own particular properties and uses, as listed in Table 3.1.

The main characteristics of these three forms are depicted in Figure 3.1. It shouldbe noted that basic and composite function blocks always reside on a single resourceand provide variables at their inputs and outputs to hold data values. Basic blocksalso require internal storage for the execution control state machine. However, incontrast a subapplication does not specifically have storage for inputs, outputsand events. With subapplications, such storage is provided by internal functionblocks that exist within the subapplication body.

Defining basic function blocks

Basic function blocks can be described either textually using the IEC 61499 textualsyntax or graphically. There are two graphical representations that together depict

Table 3.1 Different forms of function block

Form Distributable Definition Comment

Basic functionBasic functionBasic functionBasic functionBasic function No States defined A basic function blockblockblockblockblockblock using the Execution cannot be distributed; it

Control Chart (ECC). can only run on a singleAlgorithms defined resource. Basic functionusing an appropriate blocks define thelanguage, e.g. fundamental blocks fromStructured Text, which large compositeJava. blocks can be built.

CompositeCompositeCompositeCompositeComposite No Constructed from a A composite functionfunction blockfunction blockfunction blockfunction blockfunction block network of basic and block is built from a

composite function network of lower levelblocks. Definition is function blocks. Thesegiven in terms of the can be either basic ordata and event lower level compositeconnections between blocks.function blocks.

SubapplicationSubapplicationSubapplicationSubapplicationSubapplication Yes Constructed from This type of block isnetworks of basic intended to provide aand composite re-usable part of anfunction blocks. A application that can besubapplication can in distributed over manyturn contain copies resources.of smallersubapplications.


the properties and behaviour of a basic function block: (i) the external interfacedeclaration and (ii) the execution control chart (ECC) that defines the relationshipsbetween events, states and algorithm execution.

External interface declaration

The external interface declaration as shown in Figure 3.2 has the following features:

• The function block type name should be positioned in the centre of the mainblock as shown by ‘Ramp’ in Figure 3.2. Inputs to the block are always shownon the left of the block; outputs are shown coming from the right side of theblock.

• Input events are depicted entering the left side of the upper part of the block,output events are shown coming from the right.

Figure 3.1 Different forms of function block

Type identifier

Composite function block type

Event inputs

Data inputs

Event outputs

Data outputs Type identifier

Subapplication type

Event inputs

Data inputs

Event outputs

Data outputs

Key:

Shows the presence ofstorage, i.e. variables for inputand output data and events

ExecutionControlChart

Algorithms

Type identifier

Basic function block type

Internal variables

Event inputs

Data inputs

Event outputs

Data outputs


• The names of input and output variables are shown inside the block next totheir associated graphical connectors.

• The data types of inputs and outputs are shown at the left hand and right handends of the graphical connectors respectively.

The graphical representation provides sufficient information to be used as aformal type declaration. In fact, a primary objective of IEC 61499 is that graphicalrepresentations always have a precise textual representation. It is envisioned thatgraphical modelling tools will always be able to convert graphical forms into textualrepresentations and vice-versa.

Input events such as the E_Init event depicted in Figure 3.2 that are shownentering the function block header can, if required, be associated with one or moreinputs. This would typically be required where the block needs to sample inputvalues prior to running an internal algorithm. In the Ramp function block example,inputs X0, X1, Cycle and Duration need to be stable whenever an E_Init eventoccurs, i.e. at the instant when the block is initialised. Similarly, the PV inputvalue will be sampled when the E_Run event occurs.

The association of input events with input data uses a construct that IEC 61499denotes as the WITH qualifier. In the graphical representation this is shown usingsmall square connectors that link the event with its associated data.

It is also possible to associate output events with certain output variables. Thisis used to denote those output variables that have been updated by an internalalgorithm and are ready at the instant the output event is fired. In the basic functionexample in Figure 3.2 the E_Ex0 output event occurs when the internal rampalgorithm has updated outputs Out and Hold.

The same WITH textual qualifier and graphical representation is used to showthe association between output events and their output data.

Events can be defined to have an optional event type. This is provided so thatfunction blocks can be designed to only accept certain types of events at theirevent inputs. Event types provide increased robustness in the design. This is alogical extension to the way that data types are used to increase design integrityby only allowing the connection of inputs and outputs carrying compatible data.In the example figure, the E_Init input can only accept initialisation events of type

Figure 3.2 Graphical function block type declaration


Init_Event; for example, it would not be possible to connect a shutdown event oftype E_stop to this event input.

If block event input or output is not given an event type, the default type EVENTis applied. Events of this generic type EVENT can be connected to any otherevent inputs of type EVENT. Conversely, an event input of type EVENT can receiveevents of any event type.

Note that every input and output of a basic function block must be associatedwith at least one event input or output, respectively. This is because, at least oneevent is always required to signal when an input value is sampled or when anoutput value has changed. Another way of viewing this is to regard the event andits associated data as a type of message that allows an event and its data to bepassed between blocks as a coherent set.

One consequence of this feature is the implication that the block must havestorage to hold the values of inputs between event samples. Likewise, it has storageto hold values of outputs between times when output events are fired. There is ofcourse always the possibility that a block may receive events with data at a ratethat is faster than the block can store and then process. The standard states that, insuch cases, the underlying scheduling function should prioritise function blockalgorithm execution in a manner that ensures that such overload situations do notoccur.

Internal behaviour

There are two aspects to the description of the internal behaviour of a basic functionblock: algorithm bodies and algorithm execution control. The basic block willgenerally contain one or more algorithms. Each algorithm is invoked by the resourcescheduling function in response to particular input events arriving at the blockinterface. As the algorithm executes it processes data from input and internalvariables to create new values for both internal and output variables. When thealgorithm has completed certain phases of its execution it may fire output eventsto signal that output data is ready and can be ‘consumed’ by other blocks. Everyalgorithm must result in firing at least one output event to signal that it has completedits execution.

IEC 61499 does not define a language that should be used for algorithmdefinitions. Any high level language can be used provided that a mapping can bedefined between the input and output data variables and their data types, andvariables within the algorithm’s language. We will see later that Structured Text(ST) as defined in the PLC Languages Standard IEC 61131-3 as well as JAVA areboth good examples of high level languages that can be used to express thebehaviour of function block algorithms.

An important aspect of the behaviour of a basic function block concernsmodelling the relationship between events and algorithm execution. This is achievedusing a concept called the Execution Control Chart (ECC). Like other featuresof the block, the ECC can either be defined graphically or textually.

Each basic function block requires an ECC to define the following:


• the main internal states of the block• how the block will respond to each type of input event• which algorithms are activated in response to input events• which output events are fired when algorithms are executed.

The ECC is a form of state transition diagram that bears many similarities tothe graphical Sequential Function Chart in IEC 61131-3. However, as a statemodelling technique its purpose is very different and should not be confused withgraphical programming languages such as SFC1.

In Figure 3.3 there is an example of an ECC suitable for the Ramp functionblock as discussed earlier (see Figure 3.2). In this case, the ECC depicts threestates ‘START’, ‘INIT’ and ‘RAMP’ that correspond to the three primary states ofthe block. The ‘START’ state represents the quiescent state of the block when it iswaiting to receive events. The ‘INIT’ state occurs while the block is running theinitialisation algorithm ‘ALG_INIT’. The ‘RAMP’ state exists while the mainramping algorithm is running, i.e. ‘ALG_RAMP’.

The transition between states is depicted by Boolean expressions involvingevent variables and Boolean variables that are declared within the function blockbody. Event variables provide internal representations of input events and are usedto describe transitions between states. Table 3.2 lists the transition conditions forthis example ECC.

In this example, ‘INIT’ and ‘RAMP’ are transient states that only exist whilean algorithm is executing. In more complex blocks it is possible for states torepresent fundamental states or modes of the block.

Figure 3.3 Execution Control Chart


Execution Control Chart features

The standard defines a range of features and rules that apply to using ExecutionControl Charts (ECCs) which are summarised as follows:

• A basic function block will always have exactly one Execution Control Chart,which is defined using the textual syntax in the execution control block sectionof the function block type definition.

• Each ECC must have an initial state that is always depicted with a double-outlined shape.

• Either round or rectangular shapes can be used to depict states within the ECC.Note: throughout this book, rectangular shapes have been used to representECC states.

• The ECC can use event inputs represented as event variables. Typically, transi-tions between states are defined by logical expressions using event inputvariables.

• The ECC can also test or modify event outputs, again represented within theECC as Boolean event output variables.

• The ECC can also test but not modify Boolean variables declared within thefunction block body. This allows the ECC behaviour to be modified dependingon the internal states of the function block body.For example, a function block may have two major modes such as ‘Manual’and ‘Auto’ defined by an internal Boolean variable called ‘ManualFlag’. Onthe arrival of a particular input event, the ECC could test ‘ManualFlag’ and goto appropriate states to invoke either Manual or Auto algorithms.

• Transition expressions that trigger a change of state within the ECC normallyinvolve input event variables. However, these expressions can also includevariables representing output events, function block internal states, andconditional expressions based on the values of the block’s main input and outputvariables.

• Each ECC state can have zero or more actions. As an example, Figure 3.4depicts a state ‘MAIN’ that has two actions to call algorithms ‘CALC’ and‘FILTER’; these trigger output events ‘ExO_1’ and ‘ExO_2’, respectively, whenthey complete execution. Each action is normally associated with one algorithmand one output event. When the state is active, all actions defined for the stateare executed. However, an action may have a null algorithm where it is onlyrequired to fire an output event. It is also possible to have actions with no output

Table 3.2 Transitions in the example ECC

From state To state Transition

START INIT E_Init (Event)INIT START 1 (always true)START RAMP E_Run (Event)RAMP START 1 (always true)


events. Normally a state will have at least one action that has an output event tosignal to the external world that certain outputs have been updated.

It is important to note that transition conditions within an ECC are not testeduntil the state preceding the transition is active. So, even though a function blockmay have a very complex ECC with a large number of transitions between states,the overhead involved in testing transitions may be small because at any time onlyone state will be active.

It should be stressed that the ECC is primarily intended to represent the relation-ships between input events, algorithm execution and the firing of output events. Itshould not be used to model application state behaviour, e.g. to model variouscontrol modes. Application states and related behaviour should be defined withinthe function block algorithms themselves. For a large majority of fairly complexfunction blocks, the ECC should be relatively simple with as little as four or fivestates.

Textual syntax example

Let us consider the required behaviour for a very simple Ramp function block,used here to demonstrate how behaviour can be modelled using IEC 61499. Thisfunction block ramps an output ‘OUT’ from an initial value given by input ‘X0’ toa target value ‘X1’ during a time given by the ‘Duration’ input. The ‘Cycle’ inputdefines the elapse time between updates of the Ramp output. The block also checkswhether the output exceeds the input ‘PV’, in which case, the ‘Hold’ output is settrue. It is assumed that the Ramp block is called repeatedly and at an update rategiven by the ‘Cycle’ time; for example, it may be configured to execute every200 milliseconds.

We have already reviewed the two graphical views of this basic function block:(i) the graphical function block type declaration (see Figure 3.2) and (ii) theExecution Control Chart (see Figure 3.3). The information given in these two

Figure 3.4 EC state example


figures can also be represented textually using the IEC 61499 textual syntax whichtogether with the algorithms expressed using the IEC 61131-3 Structured Textlanguage (ST) provides the full textual definition of the Ramp block as follows:

Note: the reader is advised to consult the IEC 61499 PAS for a full specificationof the textual syntax.

FUNCTION_BLOCK Ramp(* Ramp function block type definition *)

EVENT_INPUTE_Init WITH X0,X1,Cycle,Duration;E_Run WITH PV;

END_EVENT

EVENT_OUTPUTE_Rdy;E_Ex0 WITH Out,Hold;

END_EVENT

EC_STATESTART; (* Initial state *)INIT: ALG_INIT -> E_Rdy;RAMP: ALG_RAMP -> E_Ex0;

END_STATES

EC_TRANSITIONSSTART TO INIT := E_Init;INIT TO START := 1;START TO RAMP := E_Run;RAMP TO START := 1;

END_TRANSITIONS

VAR_INPUTX0 : REAL;X1 : REAL;Cycle : TIME;Duration : TIME;PV : REAL;

END_VAR

VAR_OUTPUTOut : REAL;Hold : BOOL;

END_VAR


VART : TIME; (* Time into Ramp *)

END_VAR

(* Algorithm definitions *)ALGORITHM ALG_INIT IN ST:T := T#0s;

END_ALGORITHM

ALGORITHM ALG_RAMP IN ST:IF T < Duration THENOUT := X0 + (X1-X0)*TIME_TO_REAL(T)/TIME_TO_REAL(Duration);

T := T + Cycle;Hold := PV > Out;

END_IF;END_ALGORITHM

END_FUNCTION_BLOCK

The behaviour of the Ramp function block is now completely defined in thistype declaration. On the arrival of the initialisation event ‘E_Init’, input valuesthat characterise the Ramp behaviour, i.e. X0, X1, Cycle and Duration, are stored.

The ‘INIT’ state is activated causing the initialisation algorithm ‘ALG_INIT’to be invoked. This resets the internal timer variable ‘T’. The output event ‘E_rdy’is fired when the initialisation algorithm has terminated, as defined in theEC_STATE declarations.

Similarly when the run event ‘E_Run’ is received, a transition to state ‘RAMP’occurs causing the ‘ALG_RAMP’ algorithm to run. This calculates the new outputvalue for ‘OUT’ based on the values of X0, X1, Cycle and Duration and the timeinto the Ramp ‘T’. The algorithm also checks whether the output exceeds theinput value of ‘PV’, in which case the output ‘Hold’ is set true.

Behaviour of instances of basic function blocks

Using either textual or graphical declarations it is possible to define instances, i.e.copies of basic function blocks, created from basic function block type definitions.An instance of a basic function type will have behaviour that is defined by its typedefinition but it will have its own storage for its input and output variables, eventvariables and for holding the state of its ECC. In other words, the state of eachbasic function instance is totally independent of the other instances.

The resource, in which a basic function block has been declared, will initialiseeach basic function instance prior to activating the block for the first time. Thisinitialisation includes the following:


• The value of each input, output and internal variable is set to an initial value asdefined in its declaration given in the block type definition. Where aninitialisation value has not been given, default values for the particular datatype will be taken. For example, Boolean inputs that do not have a definedinitial value will always be initialised to ‘FALSE’, which is the default initialvalue for Boolean (BOOL) variables.

• All event input and output variables as used within the ECC will be initialisedto ‘FALSE’.

• Algorithm internal states will be initialised. For example, if an algorithm hasbeen defined using the IEC 61131-3 Sequential Function Chart (SFC) language,then the algorithm will be reset so that it will start on the SFC initial step.

• The initial state of the instance ECC will be set active; all other states withinthe ECC will be inactive.

Execution of algorithms

The standard defines very precisely the manner in which events that arrive at func-tion block event inputs trigger changes of state within the ECC that then, in turn,cause the scheduling of function block algorithms by the resource. The main aspectsof this behaviour are summarised as follows:

• The resource stores and updates event variables to record the arrival of inputevents at the interface of the function block instance.

• The resource then only allows a change in state within the ECC if: (a) inputevents have been received, (b) the transition condition leading from the currentactive state (i.e. from the transition’s predecessor state) is fulfilled and (c) allalgorithms invoked by actions in the current state have ceased execution.

Figure 3.5 ECC operational state machine


One consequence of this IEC 61499 algorithm execution model is that if thereare multiple occurrences of an input event before or during algorithm execution,events may be lost. For this reason, in the standard it is stated that the resourceshould provide means for detecting when such overload conditions exist and takeappropriate action for error recovery.

Note that it should always be possible, by various means, to create a modelwhere event overloads are avoided; for example, by creating blocks to provideevent and data queues, or by feeding back loading information to upstream blocksto modify event output generation rates.

The Execution Control Chart (ECC) of a basic function block instance can atany time be in one of three primary states with regard to its relation to the resourcescheduling function. These form a simple state machine as shown in Figure 3.5and are described in Table 3.3.

The resource scheduling function performs the following operations ontransitions associated with changing between these states:

• s0 to s1 Input event variables associated with arriving input events are set trueand any input variables associated with the events using the ‘WITH’ constructare sampled and stored within the block.

• s1 to s2 The resource schedules the block’s algorithm to run, i.e. the resourcestarts to execute algorithms associated with the new active ECC state. Duringalgorithm execution, various output event variables may be set to ‘true’. Duringthis time, the algorithm will typically update the values of various outputvariables.

• s2 to s1 The resource detects that the algorithm(s) have completed execution.• s1 to s0 The resource triggers output events associated with output event variables

as set during algorithm execution. All output variables that have been definedas being ‘WITH’ a particular output event are now ready to be sampled byexternally connected blocks. Input event variables are also cleared down whenreturning to the s0 idle state, ready for the arrival of new events.

Table 3.3 Execution Control Chart primary states

State Condition Notes

s0s0s0s0s0 Idle In this state, nothing in the block is either executing orpending execution. The block is waiting for the arrival ofinput events.

s1s1s1s1s1 Scheduling While in state s1, the resource has detected that analgorithms input event has arrived and will schedule the block’s

algorithm(s) when other currently active or higherpriority algorithms of other blocks have terminated.

s2s2s2s2s2 Waiting for The resource has started the execution of the block’salgorithms to selected algorithm(s) and now waits until thecomplete algorithm(s) has terminated.


The way in which a resource actually executes a particular algorithm of a basicfunction block is to some degree ‘implementation-dependent’. As stated earlier,an algorithm can be expressed using a variety of languages and therefore itsbehaviour is not regarded as being within the scope of IEC 61499. The algorithmimplementation should however have the following characteristics:

• Input and output variables and event variables should be mapped precisely andunambiguously to variables within the algorithm.

• The algorithm should be so encapsulated that it can only read and write tovariables within the function block body.

• The algorithm execution time should be short in relation to the expected arrivalrate of events that will trigger its execution. Clearly if an algorithm is designedto execute every 100 milliseconds and is going to be triggered using a 100milliseconds clock event, its worst case execution duration should be well under100 milliseconds to allow other algorithms to execute.

• The algorithm should have a well-defined initial state, which it can enter whenthe block is first made ready for execution by the resource.

Definitions for composite function blocks

Composite function blocks provide a means for building up more complex blocksfrom basic and other smaller composite blocks in a hierarchical fashion. The typedefinition for a composite function block contains declarations of function blockinstances of selected types that are linked by data and event connections. Thestandard regards blocks that are used within a composite block as componentfunction blocks. The data connections between component blocks define the transferof data values between block outputs to inputs while the event connections definethe order of execution of algorithms within the blocks.

Rules for composite block type specification

There are a number of rules and restrictions regarding the specification of compositefunction block type definitions, particularly regarding the connection of the externalevent and data inputs and outputs with the internal component blocks. These rulesarise because events cannot be fanned-out directly; i.e. there must be a one to oneconnection between an event output and an event input. It is possible to make anevent generate multiple concurrent events by using an E_SPLIT function block;this is one of IEC 61499’s special event function blocks discussed in chapter 5. Incontrast, data inputs can be fanned-out allowing a single data output to drive manydifferent data inputs.

Rules for event connections

1. Each composite event input must be connected to exactly one input event of aninternal component function block or must be ‘through routed’ to a composite


block event output. That is, it is not possible for the event input to be connecteddirectly to multiple event inputs in different component blocks.Note: Event function blocks such as E_SPLIT can be used to create fan-outevents from a single input event if required, see chapter 5.

2. Each component event input must be connected to exactly one component outputevent or to a composite block event input.

3. Similarly, each event output of a component function block can only be connec-ted to exactly one component input event or to one composite event output.

4. Each composite block output event must be connected to exactly one outputevent of a component function block or come directly from a composite inputevent.Note: Some component block input and output events may remain unconnected.In such cases, algorithms associated solely with unconnected input events willnot be executed.

Rules for data connections

The following rules apply to the connections between composite data inputs andoutputs and component inputs and outputs.

1. Each data input of the composite block may be (a) connected to one or manydata inputs of internal component blocks, or (b) connected directly through toone or more composite function block outputs or both.

2. Each component block data input can either be (a) not connected, or (b) connec-ted to one other component block output, or (c) connected to the composite blockdata input. Clearly the standard does not allow a component block input to beconnected to multiple outputs because the input would then have an indeter-minate value.

3. Each component block data output can be (a) not connected, or (b) connectedto one or more component data inputs, or also (c) connected to one or morecomposite data outputs.

4. Each composite data output must be connected to either (a) one componentdata output, or (b) ‘through routed’ from one composite data input.

Composite block example

Consider the example function block depicted in Figure 3.6 that has been chosento demonstrate many of the characteristics of composite function blocks. The figureshows the graphical body of a composite block depicted as a network of functionblocks linked together to form a new block. In this case, an additional componentfunction block of type Compare, and Event function block E_MERGE, have beenused to extend the functionality of the ‘Ramp’ function block to form a ‘Sawtooth’generator.

Note that Ramp1 is an instance of the Ramp basic block as described in thepreceding section of this chapter. The instance name of each component block isshown just above the outline of each block in the graphical body.


The external interface of this new block is shown in Figure 3.7. Note that it hasthe same appearance as a basic function block. In fact, from an external viewpoint,it is not possible to distinguish between a basic and composite block just from ablock’s external interface.

We will now review the behaviour of this block and show how it has beenmodelled as a composite function block. The purpose of this block is to provide anoutput value that follows a ‘sawtooth’ profile as shown in Figure 3.8, i.e. thatrepeatedly ramps the output from 0.0 to a Target value and then resets and restartsthe ramp again from 0.0.

The block is initialised using an initialisation event at input event E_Init—atthis point, the input values for inputs X0, X1, Cycle, and Duration are storedwithin the ‘Ramp1’ input variables. In this example, X0 and X1 are fixed at values0.0 and 1000.0 by constants defined within the composite block’s body effectivelysetting the limits for the Ramp output ‘Out’. The values of Cycle and Durationcome from values provided at the external interface of the block and define thetiming characteristics of the ‘sawtooth’ waveform.

Figure 3.6 Composite function block—graphical body


After initialisation, the block is ready to receive a regular stream of events atevent input E_Run. Each event at the E_Run input triggers the Ramp1 block toincrement its output ‘Out’ towards the upper limit set by X1. Each time the Ramp1internal algorithm completes its execution, an output event E_ExO is passed tothe Compare1 block which then checks the value of ‘Out’ against the ‘Target’value, i.e. it compares inputs X and Y. After execution, the Compare block outputsthe value of X to output XO and issues event E_Ex0. Eventually, when theRamp1.Out value reaches the Target value the Compare block detects that input Xis greater than input Y and triggers its output event E_GT. This event is fed back tothe Merge1 block, which produces a new initialisation event for the Ramp1 block.The Ramp1 block is re-initialised and the output is reset to 0.0. As long as the blockcontinues to receive events at its event input E_Run, it will continue to generatethe sawtooth waveform.

The slope of the sawtooth profile can be changed by re-initialising the blockwith an initialisation event at event input E_Init issued with a different Duration

Figure 3.8 Sawtooth profile

Figure 3.7 Composite function block—external interface


value. Merge1 is an instance of one of the standard event function blocks asdescribed in chapter 5 and provides a means for multiple events to be merged intoa new stream of events. In this case Merge is used to allow the Ramp block to beinitialised either by an external event on event input E_Init or from an internallygenerated event coming from the Compare block.

Use of the WITH construct

It is possible to show graphically which data inputs and outputs are associatedwith particular input and output events, respectively, by using the WITH construct.For example, in Figure 3.7, the initialisation event E_Init is shown associated withinputs Cycle and Duration. However, unlike the behaviour of the basic functionblock, the WITH construct does not indicate that inputs are stored in variables thatare part of the block’s interface. With composite blocks, WITH is a means to showwhich inputs are required to be ready when a particular input event occurs. Theinput values are actually sampled and stored in input variables of internal componentblocks. Similarly, with output events, the use of the WITH construct shows whichoutput values are ready when a particular event occurs, e.g. in Figure 3.7, the dataoutput Out is ready when the output event E_Ex0 occurs.

Note that the standard stipulates that every data input and data output of a compositefunction block declaration is required to be associated with at least one WITHconstruct. For inputs, this ensures that their value is sampled by at least one event;for outputs it ensures that there is a clear point in time when the output is updated.

Execution of composite function blocks

Instances of composite blocks can be created as part of function block networksexisting within a resource and may exist at the top level or be used within thedefinition of other larger composite function blocks. In all situations, the executionof the composite block is determined by the arrival of events at its event inputs. Thestandard defines the following simple rules that determine how events are handled:

1. If a composite block input event is routed through directly to a composite blockevent output, then an occurrence of an event at the event input will generate anevent at the block’s event output.

2. If an input event is connected to an internal component function block, then theoccurrence of an input event will result in an event arriving at the component’sinput event. The component block will then be scheduled for execution by theresource’s scheduling function.

3. Similarly, if an output event of a component block is connected to the inputevent of another component block, then an output event from the first will causethe second block to be scheduled for execution.

4. If a composite output event is connected to a component block output eventthen the composite output event will be generated when the component blockproduces an output event.


These simple rules provide an intuitive and logical association between eventsand block execution. In essence, events propagate through the network of compo-nent function blocks progressing from the input to the output side of the compositeblock.

Textual syntax composite function block example

So far we have concentrated on the graphical representation of a composite functionblock. As with basic function blocks, the IEC 61499 Textual Syntax can also be usedto describe the structure and internal networks that form composite function blocks.For example, the Sawtooth block as depicted in Figure 3.6 can be represented bythe following textual description:

FUNCTION_BLOCK SAWTOOTH(* Event definitions *)EVENT_INPUTE_RUN WITH TARGET;E_INIT WITH CYCLE, DURATION;

END_EVENTEVENT_OUTPUTE_RDY;E_ExO WITH OUT;

END_EVENT(* Variable definitions *)VAR_INPUTCYCLE : TIME;DURATION : TIME;TARGET : REAL;

END_VARVAR_OUTPUTOUT : REAL;

END_VAR(* Function blocks *)FBSRAMP1 : RAMP;COMPARE1 : COMPARE;MERGE1 : E_MERGE;

END_FBS(* Event connections *)EVENT_CONNECTIONSE_RUN TO RAMP1.E_RUN;E_INIT TO MERGE1.EI1;MERGE1.EO TO RAMP1.E_INIT;RAMP1.E_Rdy TO E_Rdy;RAMP1.E_ExO TO E_ExO;


COMPARE.E_GT TO MERGE1.EI2;END_CONNECTIONS(* Data connections *)DATA_CONNECTIONS0.0 TO RAMP1.X0;1000.0 TO RAMP1.X1;CYCLE TO RAMP1.CYCLE;DURATION TO RAMP1.DURATION;RAMP1.OUT TO COMPARE1.X;TARGET TO COMPARE1.Y;Compare1.X0 TO OUT;

END_CONNECTIONSEND_FUNCTION_BLOCK;

The textual form is rather like a build list for an electronic circuit. It describesall event and data inputs and outputs, the internal function blocks and the eventand data connections. Each part of the definition is introduced by a block keyword,e.g. EVENT_INPUT ... END_EVENT defines all input events for the block,similarly DATA_CONNECTIONS ... END_CONNECTIONS defines all the dataconnections between the external interface and internal blocks.

The Textual Syntax has been developed to form a generic and portable formatthat can be used to express the structure of a composite block. It does not directlyexpress the algorithmic aspects of the block’s behaviour but it does defineunambiguously how the block is constructed from which its behaviour can bededuced. In fact, software tools are currently being developed that can automaticallytranslate between the graphical and textual representations.

Defining subapplications

A subapplication can be regarded as a special form of composite function blockthat is designed to be ‘distributed’. That is, it can optionally run on more than oneresource. It has a similar structure to a composite block but some of the rulesregarding the use of data and events are relaxed. A subapplication function blocktype can only be used within the body of other larger subapplications and withincomplete applications. However, a subapplication type may itself be defined usingcomposite, basic and other subapplication function blocks.

The main contrasting feature of a subapplication when compared with a com-posite function block is that it can optionally be run on multiple resources. Remem-ber that basic and composite blocks can only run on the same resource, i.e. it is notpossible to break them down into parts that can run on different resources. Asubapplication, however, may run on the one resource or be distributed so thatdifferent parts run on different resources; in other words, it is distributable.

One way of regarding a subapplication is that it represents a re-usable sectionfunction block network. It would typically be used for defining an arrangement of


function blocks and connections that can be re-used in different network configura-tions. In many ways a subapplication type definition resembles a software macroin that it allows a particular solution in the form of a function block network to bereadily copied.

For example, consider a subapplication block that provides a temperature controlloop consisting of an analogue input block, a PID control block and an analogueoutput block as shown in Figure 3.9a. Typically this would be used to control thetemperature of a device, for example, a heating vessel or furnace. The primaryfunction of this control loop is to (i) measure the current temperature, (ii) compareits value against the setpoint or desired temperature and then (iii) adjust an outputvalue that drives a heating device to correct the temperature. These three functionsare mapped onto three component function blocks that make up the subapplication.The Input1 block reads the current value of an external sensor. The PID1 blockprovides a PID2 algorithm to compare the measured (process value) and setpointvalues and create the output value. The Output1 block takes the value created bythe PID block and transfers it to the external actuator.

Input1 and Output1 will be constructed as composite function blocks and willeach require at least one Service Interface function block to provide an interfacewith the underlying controller in order to read input and output (I/O) values fromthe controller hardware. Service Interface function blocks are a special form ofblock that provides various interfaces with the physical device or communicationssystem and are discussed in chapter 4.

Figure 3.9b shows how the TempControl subapplication could be run within asimple controller to provide closed-loop temperature control of a vessel heatedusing a steam jacket. The input to the TempControl subapplication is a temperaturevalue that is read from a sensor such as a thermocouple; the subapplication outputdrives some form of actuator, such as a steam valve, to modify the heating.

Note that in this example, the TempControl subapplication is actually part of anapplication Single_Vessel_Control that has been declared within a single IEC 61499resource, i.e. all of its function blocks are running within the same resource.

This subapplication has two event inputs, E_Init and E_Run. E_Init is used toinitialise the internal component blocks. It triggers the PID block to execute andread its input variables, i.e. the value of Setpoint input is read and stored withinthe PID. This defines the desired temperature at which the control loop will stabilise.Generally, a PID algorithm will require a large number of parameters such astiming constants for integral and derivative actions. These are not shown in orderto keep the example simple but would be initialised in the same way as the Setpoint.The E_Run event propagates through the subapplication and causes the controlloop to update its external output according to the value calculated by the PIDalgorithm. In this example, we can assume that another timing function blockwithin the application provides a regular stream of events, at say 100 millisecondintervals at the E_Run event input, to ensure that the TempControl block is regularly


invoked. This will ensure that the temperature is measured at a given scan rate andits value propagated to the PID1, which in turn creates a new output value tomodulate the heat output.

Rules for subapplication type specification

The rules for subapplication construction are as follows:

1. An instance of a subapplication can only be declared within other subapplicationtype definitions or with an application.

E_Run E_Ex0

Analog_Input

OUT

E_Run E_Ex0

Analog_Output

OUT

E_Init E_Ex0

OUT

E_Run E_Ex0

E_Run

Input 1 PID 1 Output 1

PV

SP

Setpoint

E_Init

Subapplication TempControl Loop

Sensor temperature reading Actuator for heater output

Figure 3.9a Subapplication example: temperature control subapplication definition

Resource: Controller 1

Application: Single Vessel Control

TempControl

Temperaturesensor

Heateractuator

Vessel

Controller device

Resource

Application

TempControlSubapplication

Figure 3.9b Subapplication example: temperature control application


2. The WITH construct is not used in subapplication type definitions because theassociation between events and data will depend on how the subapplication isdistributed between resources.

3. In the textual syntax, input and output variables to subapplications are declaredusing VAR_INPUT and VAR_OUTPUT constructs but, as with compositefunction blocks, this does not imply that storage is created for these variables.All values of inputs and outputs to subapplications are stored at the internalinterfaces of component blocks.

Rules for subapplication execution

Instances of subapplications can be declared within applications and also withinother subapplications. Nevertheless, an instance of a subapplication is ratherdifferent to an instance of a composite function block in that it really represents acopy of a set of function blocks and their interconnections. In this regard, a subappli-cation can be compared to a software macro or a graphical pattern.

The standard defines the following rules for how subapplications execute:

1. Events may be routed directly through the subapplication, so that an eventarriving at an event input will immediately trigger an event at the event output.

2. Each event input that is not directly routed through must be connected to anevent input of an internal component block. In this case when the event arrivesat the subapplication event input, the internal component block will receive anevent and will be scheduled for execution.

3. As a component block executes it will produce one or more output events. Thesewill in turn trigger the execution of other component blocks to which they areconnected within the subapplication.

4. Subapplication event outputs that are not directly routed through from eventinputs must be connected to one output event of a component block. When theassociated component block executes and generates an output event, the eventis propagated through to the subapplication’s event output.

Subapplication distributed example

So far we have considered subapplications that run on a single resource. A signifi-cant feature of IEC 61499 is the ability to re-arrange applications and subappli-cations so that they can provide the same functionality and yet run on differentresources in different distribution arrangements. Subapplications such asTempControl as depicted in Figure 3.9 can be broken into smaller function blocknetwork fragments that run in different resources. In the case of TempControl thefollowing arrangements could be considered:

1. all blocks run on one resource, i.e. a non-distributed configuration2. Input1, PID1 and Output1 blocks run on different resources, i.e. a totally

distributed configuration3. Input1 runs on one resource while blocks PID1, Output1 run on a second

resource, i.e. a split resource configuration


4. blocks Input1, PID1 run on one resource while Output1 runs on a secondresource, i.e. an alternative split resource configuration.

Figure 3.10 shows the fourth distribution arrangement where the blocks Input1and PID1 for the analogue input and PID algorithm run on one resource ‘Resource1’and the analogue output Output1 runs on a second resource Output1. In practicalterms, this arrangement means that the subapplication TempControl can be run intwo separate resources located in different controllers. Figure 3.10 shows onepossible physical system configuration that could be considered. It shows twocontrollers A and B linked by some form of communications system, for example

Figure 3.10 Subapplication distributed example

OUT

Q1PARAMSSD_1

E_Run E_Ex0

Analog_Input

OUT

Input 1

E_RunE_Ex0

OUT

PID 1

E_InitE_Ex0

PV

SP

E_Run

E_Init

Setpoint

REQINIT0

PUB 1

INITCNF

PUBLISH

QOSTATUS

<ADDR1>

Resource1

Resource2

Q1PARAMSSD_1

E_Ex0

Output 1

E_RunRSP

INIT0

SUB 1

INITIND

SUBSCRIBE

QOSTATUS

RD1

<ADDR1>

Analog_Output

Subapplication Temperature Control Loop

Linked by Resource -Resource communications


a network using Fieldbus or Ethernet. The analogue input is connected to controllerA while the actuator is now driven from the other controller B. The subapplicationis now distributed over two controllers but the internal functionality is still deter-mined by the function blocks defined in the original TempControl subapplicationtype definition.

It is envisaged that a system designer will be free to select the appropriatedistribution arrangement for a subapplication according to the system designrequirements. The distribution arrangement selected by a designer will depend onmany factors including: (i) whether a resource is capable of supporting particulartypes of function blocks, (ii) the loading and performance of a particular resource,and (iii) the latency and reliability of communications services between resources.

It will be noted that some extra function blocks Pub1 and Sub1 have been addedto the distributed TempControl subapplication as shown in Figure 3.11. These arefurther examples of Service Interface function blocks that are discussed in moredetail in chapter 4 and provide an interface between function blocks within aresource and the resource’s communications system. PUB1 is a Publisher functionblock that is used to transmit one or more data values over a communications linkto one or more external resources within other controllers. It simply sends outvalues using a given identification address. SUB1, a Subscriber function block, isused within the second resource to receive the values sent out by PUB1. In thiscase there is only one subscriber, but it is possible to have configurations wherethere are multiple subscribers.

Figure 3.11 Temperature control distributed application

Temperaturesensor

Heateractuator

Vessel

Resource: Resource1

Controller_A

Resource: Resource2

TempControl Subapplication

Controller_B

Communications link


The example has used the publisher/subscriber Service Interface blocks butother blocks offering different types of communications models such as Requesterand Responder are also discussed in the standard. In this particular example, thePublisher/Subscriber model has been used because there is no requirement in thissimple design for any feedback to the PID1 block as to whether the transmissionof the value to the analogue output has been successful. The PID1 block willcontinue to output new values to its output regardless of downstream communica-tions problems. Clearly, in a full design there would be a requirement to monitorthe communications and check whether the complete control loop is workingcorrectly. This could be achieved by using, say, a request and response communi-cations model or by feeding back a signal from the Output1 block.

Note that when a subapplication is re-arranged to run on different resources,additional parameters will generally be needed for the communications system.This would typically include details such as resource addresses and network routingparameters. Such information will generally be passed as parameters to ServiceInterface function blocks that are handling the inter-resource communications. Itshould be stressed that IEC 61499 does not define communications protocols orstandardise addressing or parameters related to communications. But it does providea framework and architecture for defining services such as communications usingService Interface function blocks.

Summary

In this chapter we have covered most important aspects of function block typedefinition. We have reviewed how type definitions can then be used to create functionblock instances. In turn, we have seen how Function Block Instances can be usedin new type definitions to hierarchically build function blocks of yet higherfunctionality. Although designs can be created graphically, we have noted that thestandard also defines a formal textual syntax that can be used as an alternativerepresentation.

To summarise:

• There are three categories of function block: (i) basic, (ii) composite and (iii)subapplication.

• The behaviour of a basic function block is defined in terms of an ExecutionControl Chart (ECC) and one or more algorithms.

• Composite function blocks are defined in terms of a network of componentfunction blocks.

• Subapplication blocks are similar to composite function blocks but also havethe flexible characteristic that they can be distributed to run on more than oneresource.

• Service Interface function blocks provide a way to model the interaction betweenthe resource and the underlying hardware and communications systems.


• All function block type definitions can either be defined graphically or textually.The graphical and textual representations are interchangeable.

Notes

1 SFC – Sequential Function Chart language defined in the PLC ProgrammingLanguage standard, IEC 61131-3 and used to program sequential behaviour interms of steps and transitions.

2 PID – Proportional, Integral and Derivative control algorithm commonly usedto provide stable closed-loop control for temperature and pressure.

Service Interface function blocks 69

Chapter 4

Service Interface function blocks

This chapter reviews a special form of function block that provides interfaces intothe underlying resource and communications systems.


• discuss why Service Interface function blocks are required and show wherethey can be used

• review standard input and output data and event variables required in ServiceInterface function block type definitions

• review the special notation used to describe the sequencing of external inter-actions with Service Interface function blocks

• consider some examples of Service Interface function blocks and look at wherethey could be applied

• finally we will review Management function blocks, which are a further special-ised form of Service Interface block for controlling the creation and managementof function blocks within resources and devices.

Overview

So far we have focussed on function blocks used to model the internal behaviourof a resource. At the end of chapter 3, we reviewed the creation of a simple dis-tributed application and showed that this was only possible if additional ServiceInterface (SI) function blocks were provided to communicate data values and eventsbetween resources. In fact, wherever any form of interaction is required betweenfunction blocks within the resource and the external world, there is a requirementfor an SI function block. IEC 61499 does not set standards for particular types ofSI function blocks but does stipulate that these forms of function block should bedefined using a standard set of input and output variables and input and outputevents. There is also a special notation used to describe the sequence of interactions,such as sending a request and waiting for a response, that occur externally duringthe execution of an SI function block.


We will now consider where we might need SI function blocks. In an industrialcontroller there is clearly a requirement to read the values of physical inputs suchas those from pressure and temperature sensors and also to write output values toactuators for example, for driving devices such as valves, pumps, motors and soon. There are also requirements to transmit values over serial communicationslinks, to send out copies of data to external controllers, drive displays and readinputs from display panels and other HMI devices. In fact, these are all examplesof external interactions with a resource that can be modelled using different typesof SI function blocks.

Some examples of SI function blocks that might be used to model an industrialcontrol system are set out in Table 4.1.

These are just a few typical examples of the kinds of SI function blocks thatmight be required. It should be noted that the standard does not attempt to definespecific SI blocks as it is clear that every system will have its own particularspecial requirements. However, we will see that IEC 61499 does standardise someimportant aspects of the SI function block interface including the main input andoutput parameters.

Table 4.1 Service Interface function block examples

Type name Service provided Application example

IO_Writer Allows a resource to transmit Used to update the value ofone or more values to locally actuators driving physicalconnected I/O device(s). devices, such as valves, heatersNote: IEC 61499 assumes that or pumps.the controller I/O sub-systemlies outside the resource but canbe accessed using ServiceInterface blocks.

IO_Reader Allows a resource to receive Read the latest values ofthe latest value(s) read in from positions of input devices, e.g.one or more devices. micro-switches on a robotic

placement mechanism.Publisher Transmits the value(s) of one To continuously transmit output

or more variables to one or values to a number of remotemore external resources that controllers to drive actuators.support a ‘Subscriber’ service.

Subscriber Receive one or more values To regularly receive a stream offrom an external resource that values from a given externaloffers the publisher service. resource, for example, to updateNote: The publisher and a set of HMI displays.subscriber will identify aparticular set of values by anetwork specific unique addressor service identifier. There canbe many subscribers receivingdata from a single publisher.


Type definitions

IEC 61499 specifies in general terms the way in which an interface to an SI functionblock is defined. Every SI function block provides some kind of service, such asReading I/O, Publishing values over a network and so on. It is therefore proposedthat the name given to each type of SI function block reflects the name of theservice that the block provides, e.g. ValvePositioner, HMIWriter.

It should be noted that a SI block may initiate a service in response to a stimulusfrom an application. Alternatively, the SI block may respond to an external request,such as a signal from an HMI panel, to obtain a value from an application. SIfunction blocks can be modelled to support both types of behaviour.

Standard inputs and outputs for SI function blocks

Every SI function block should use the following standard inputs and outputs,although not all of these will be used necessarily in every SI type definition:

Event inputs

INITThis input event is used to initialise a particular service that has been providedby the block. For example, it could start a service to provide data transmissionover a serial link. This event is typically sent with a number of input parametersto characterise the type of service, such as network address and Baud rate.

REQThis event initiates a request to obtain data from an external agent. For example,this event could be used to initiate a transmission of a request to get data froman external device.

RSPThis event initiates the transmission of a response to an external agent. Forexample, it could send data to a remote HMI device in response to a request fordata.

Event outputs

INITOThis output event signals that the SI function block has completed its initialisa-tion, i.e. as a result of receiving an INIT event. It does not necessarily meanthat the service has been initialised successfully; a Status output is provided forthis purpose.

CNFThe ‘confirmation’ event is output when the block has completed the transmis-sion of a request to an external agent. For example, it should be used to indicatethat a request to read a particular physical I/O point has been processed by thecontroller’s I/O sub-system.


INDThe ‘indication’ event is output when the service interface block has received aresponse from an external agent. For example, an IND event would be producedwhen an I/O read from the controller’s I/O sub-system has obtained the valuefrom the selected sensor.

Data inputs

QI: BOOLThe QI data input is used with the INIT input event as a simple qualifier. When‘true’ it indicates that the service provided by the block should be initiated.When it has the value ‘false’ with an INIT event, it indicates that the serviceshould be terminated.

PARAMS: ANYThis input represents a data structure that holds a set of values that are associatedwith the SI service and define its particular characteristics. The data types andnumber of values within the structure will be specific to the type of serviceprovided by the function block. SI function block type definition will definethe PARAMS structure and default values of parameters within it. This input isonly used with the INIT event and is used for the initialisation of the service.

For example, a PARAMS input for a communications SI function blockwould contain network addressing information and other communicationscharacteristics.

SD_1, ... SD_N: ANYThese data inputs are used to send data with requests and with responses. Thenumber of inputs and their data types will be specific to the type of serviceprovided by the function block; this is shown by the notation SD_1, … SD_N.

For example, when writing values to output devices, these parameters willcontain the hardware addresses (such as rack, module, channel) and outputvalues.

Data outputs

QO: BOOLThis qualifier output is used to indicate whether the service has been successfullycompleted for any input event. For example, following an initialisation INITevent, a ‘true’ value would indicate a successful start-up; ‘false’ would indicatethat the service has failed to be initialised.

STATUS: ANYThis output can be set with any of the input events and is used to provide thestatus from processing the last input event. For example, Status will be setwhen a service is initialised using the INIT event and has been unsuccessful.Similarly when a REQ event used to transmit values to a remote device isprocessed and subsequently fails, Status is used to hold the reason for the failure.

RD_1, ..., RD_N: ANYThese outputs are used to convey data received from confirmations and


indications. As with the SD_1 ... SD_N inputs, the number of these outputs andtheir data types will be specific to the type of service being provided.

For eample, consider when a request has been made to read, say, the valuesfrom a set of 10 input points—an IND indication event will occur when theservice has received the values from the I/O sub-system; their values will beavailable on a set of RD_1...RD_10 outputs.

Figure 4.1 depicts two SI function blocks that are given as examples in the IEC61499 standard. These blocks are still ‘generic’ in the sense that they have notbeen given a specific number of inputs and outputs. Data types of inputs and outputsare also defined using the keyword ANY. In other words, these are outline templatesfor type definitions. Further specific details and data types will be required to usethese in a particular application domain.

The Requester SI function block provides a communications service to obtaindata from a remote resource. The PARAMS input is used to specify the communica-tions address and other details; inputs SD_1 to SD_m provide parameters for arequest, e.g. by sending a request command string and arguments. The RD_1 toRD_n outputs are used for the response data received from the remote resourceand will arrive when the block issues a confirmation CNF output event.

The Responder SI function block, in effect, provides the other end of the commu-nications. It receives requests arriving from a remote resource and creates anindication IND event and output data on RD_1 to RD_n to indicate that a remote

Figure 4.1 Requester, Responder SI function blocks

REQUESTER Service Interface function block

RESPONDER Service Interface function block


data request has been received. The response to the request can be returned, bywriting the data to the Responder inputs SD_1 to SD_m and triggering an event atthe response RSP event input. This data will then be sent by the communicationssystem back to the originating Requester block where it will be received and inturn trigger a confirmation CNF output event with data, as already discussed.

Together, the Requester and Responder SI function blocks can be used toexchange data between two resources linked by some form of communications ornetworking facility. The Requester block provides a service for what IEC 61499calls an “application-initiated interaction”; in other words, the request for externaldata is triggered by an event generated within an application.

In contrast, the Responder block provides a service for a “resource-initiatedinteraction”. The request for data arrives from an external resource and results inan indication IND event being produced. In this case, the application will need toreact to an event that can occur at any time.

Figure 4.2 shows two further examples of SI function blocks; IO_Writer isused to write values to physical outputs while IO_Reader is provided to read invalues from selected physical inputs. Both function in a similar manner.

Let us consider how the IO_Writer block could be used. An application willrequire at least one instance of this block to write values out to physical outputs.

Figure 4.2 IO_Writer, IO_Reader SI function blocks

IO_READER Service Interface function block

IO_WRITER Service Interface function block


To set up the service, the application must first send an INIT event with QI inputset to ‘true’ and the PARAMS input set to identify characteristics of the service.The PARAMS input could contain details, such as ‘write’ update rates, number ofretries on failure and so on. Thereafter, data can be sent to the selected output bysetting the input SD_1 to an output address, e.g. rack, channel and I/O point andsetting the new value to input SD_2. The write is initiated by an event at eventinput REQ .

Some time later when the hardware I/O system has completed the writeoperation, an output event CNF will occur to confirm that the ‘write’ has beencompleted. The output STATUS provides an indication of whether the operationhas been successful. If the operation has failed, STATUS will contain an appropriateerror code. The output RD_1 provides a feedback of the value as read from theoutput device. This can be used to confirm that the write has been successful.

The IO_Reader block performs in a very similar manner. After initialising theservice using the INIT event, with the QI and PARAMS inputs, the value of anyphysical input can be read by setting the IO address at input SD_1 and sending anevent to event input REQ . Some time later, when the data has been read from theinput sensor, a confirmation event will occur at output event CNF. The success ofthe read operation will be indicated by the value of output STATUS and, if success-ful, the value read from the input will be available on output RD_1.

IO_WRITER and IO_READER are fairly simple forms of SI blocks foraccessing hardware I/O. However, more complex blocks could be considered tomodel facilities to read and write, say, multiple values for many I/O points in oneoperation.

Note that the time taken between issuing a request by triggering a REQ eventand receiving the confirmation event CNF will depend on many factors such as:

• the loading of the resource scheduling system• the speed of the device operating system in responding to the request from the

resource• the time to transmit a request to the physical I/O point.

Behaviour of Service Interface function blocks

As with other forms of function block, the behaviour of an SI function block isdefined by a function block type specification. However, because an SI functionblock is primarily concerned with external transactions, the standard specifies anadditional notation, called Time-sequence diagrams from ISO Technical Report8509. These can be used to show the timing and sequential relationships betweenvarious interactions with the function block. In fact, Time-sequence diagrams arecommonly used in communications standards and provide an effective way tovisualise the order in which various messages or events occur.

Figure 4.3 shows part of the Time-sequence diagram to describe the behaviourof the Requester function block as shown earlier in Figure 4.1. The Time-sequencediagram depicts three transactions: (i) Normal_initialisation which applies when


the application starts the Requester service, (ii) Normal_data_transfer which depictsthe sending of a request to a remote resource and (iii) Normal_termination whichdepicts the termination of the service by the application.

Let us look more closely at the characteristics of the Time-sequence diagram.Firstly, the diagram shows time increasing downwards. For example, in Figure4.3, the INIT+ event occurs before INITO+, because INTIO is an output eventthat is produced as a response to input event INIT but occurs some time later. Inaddition, events that are closely related, such as INIT and INTIO, are always shownby a vertical connecting line within the vertical bars. Note that the names of thefunction block input and output events involved with the transactions are depictedon the Time-sequence diagram.

The two vertical bars depicted in each Time-sequence diagram separate thetwo different domains in which operations occur. Figure 4.3 shows examples ofapplication initiated transactions, in which case the convention is to place thename of the function block type on the left-hand side of the two vertical bars and

Figure 4.3 Time-sequence diagram—Application initiated interactions


the resource on the right. Events that occur in the function block domain are alwaysdepicted on the side with the function block type name.

Figure 4.4 shows some examples of transactions for the Responder functionblock, which was also described earlier in this chapter. In this case, because themain interactions are initiated by the resource and not the application, it is theconvention to depict the Resource on the left-hand side of the vertical bars.

Note that it is only the Normal_data_transfer transaction that is initiated by theresource by the arrival indication of an IND event. In this example, the applicationprocesses the indication data and returns a positive response RSP+. TheNormal_initialisation and Normal_termination transactions to establish and clear-down the service are all initiated by the application.

The event name suffix ‘+’ indicates whether the event is associated with asuccessful (or normal) transaction while the suffix ‘–’ is associated with anunsuccessful (or abnormal) transaction. With input events, the suffix ‘+’ indicates

Figure 4.4 Time-sequence diagram—Resource initiated interactions


that the value of the input QI that is set with the event will be ‘TRUE’. Conversely,the suffix ‘–’ implies that the input QI will be set to FALSE.

For example, the event INIT+ indicates that it will be sent with QI set to TRUEand implies that the service will be initialised. In contrast, INIT– indicates that theevent will be sent with QI set to FALSE and signals that the service should beterminated.

Similarly with output events, the suffix ‘+’ indicates a successful or positiveevent while the suffix ‘–’ indicates that the event is associated with an unsuccessfulor negative transaction. With output events, a ‘+’ suffix indicates that the value ofoutput QO will be set to TRUE, while a ‘–’ suffix indicates that QO will be set toFALSE.

For example, IND– would be a negative indication and would imply that thetransaction has in some way been unsuccessful. If this occurs with the Responderfunction block, it may imply that the data sent from a remote resource is incorrect—maybe the data has been formatted incorrectly. The application should respondby issuing a negative response, i.e. RSP– as shown in Figure 4.5.

Clearly, with complex SI function blocks all the various combinations and formsof normal and abnormal transactions should be considered.

There are definitions for the meaning, i.e. semantics, of the positive and negativeforms of all of the standard events supported by SI functions. IEC 61499 definesthese various event forms as service primitives. Table 4.2 has two columns thatcorrespond to communications services and general purpose services, respectively,and provide definitions for the standard service primitives.

Textual syntax – SI function block example

IEC 61499 specifies an additional textual syntax for SI function block type specifi-cations that allows the various service transactions to be defined. This can be bestdemonstrated by reviewing the textual type definition for the IO_Writer functionblock that was described earlier in this chapter and is shown in Figure 4.2.

FUNCTION_BLOCK IO_WRITER(* IO_Writer Service Interface *)EVENT_INPUTINIT WITH QI, PARAMS;REQ WITH QI, SD_1, SD_2;

END_EVENTEVENT_OUTPUTINIT0 WITH QO, STATUS;CNF WITH QO, STATUS, RD_1;

END_EVENT

VAR_INPUTQI : BOOL; (* Event input qualifier *)PARAMS : IO_PARAMS; (* Service parameters *)


Table 4.2 Service primitives

Service Semantics when used in Semantics when usedprimitive communications services in general services

INIT+ Request to initialise Request to initialise service.communications service.

INIT- Request to terminate Request to terminate service.communications service.

INITO+ Indication that communications Indication that service has beenservice has been initialised. initialised.

INITO- Indication that either a Indication that service has notcommunications service could been initialised or has terminatednot be initialised or has been successfully.terminated successfully.

REQ+ Normal request to transfer data. Normal request for service.REQ- Disable request for data transfer. Disable request for service.CNF+ Confirmation of successful Normal confirmation of service.

data transfer.CNF- Confirmation that data transfer Confirmation that service request

was unsuccessful. was unsuccessful.IND+ Indication of successful data Indication of normal service

arrival. arrival.IND- Indication of unsuccessful Indication of unsuccessful service

data arrival. arrival.RSP+ Response by the application Response by application of a

of successful data arrival. successful service.RSP- Response by the application Response by the application of an

of unsuccessful data arrival. abnormal or unsuccessful service.

Figure 4.5 Negative indication


SD_1 : IO_ADDR; (* Output address *)SD_2 : IO_VALUE; (* Output value *)

END_VARVAR_OUTPUTQO : BOOL; (* Event output qualifier *)STATUS : ANY; (* Service status *)RD_1 : IO_VALUE (* Returned value *)

END_VAR

SERVICE REQUESTER/RESOURCESEQUENCE normal_initialisationREQUESTER.INIT+(PARAMS)->REQUESTER.INITO+();

END_SEQUENCESEQUENCE abnormal_initialisationREQUESTER.INIT+(PARAMS)->REQUESTER.INITO-();

END_SEQUENCESEQUENCE normal_data_transferREQUESTER.REQ+(SD_1,SD_2)->REQUESTER.CNF+(RD_1);

END_SEQUENCESEQUENCE abnormal_data_transferREQUESTER.REQ+(SD_1,SD_2)->REQUESTER.CNF-(STATUS);

END_SEQUENCESEQUENCE normal_terminationREQUESTER.INIT-()->REQUESTER.INITO-();

END_SEQUENCESEQUENCE abnormal_terminationREQUESTER.INIT-()->REQUESTER.INITO-(STATUS);

END_SEQUENCESEQUENCE resource_initiated_termination-> REQUESTER.INITO-(STATUS)

END_SEQUENCEEND_SERVICE

END_FUNCTION_BLOCK

New keywords SERVICE and END_SERVICE are provided to containdefinitions of the service sequence. Each service sequence is introduced with thekey word SEQUENCE and closed with the key word END_SEQUENCE. Thesequence definition defines the service primitive and associated parameters thatinitiate the transaction. The ‘->’ operator implies two things: (i) that there may bea time delay due to external processing or communications latency and (ii) thatthe resulting service primitive, as stated to the right of this operator, will occur asa consequence of the service primitive on the left. The names of sequences mustmap one-to-one to the names given on the Time-sequence diagrams. The names ofinputs, which should be valid when the service is initiated, are enclosed in


parentheses after the service primitive. Similarly, the names of outputs, which areset for the resulting service primitive, are shown on the right.

Note that in the last sequence definition for resource_initiated_termination thereis no component to the transaction given to the left of the ‘->’ symbol. This isbecause, in this case, the transaction is produced by some unknown agent outsidethe resource. For example, this might occur when there is an imminent power-supply failure and the device is therefore sending an unsolicited transaction acrossthe resource interface to terminate the IO_WRITER service.

Any additional behaviour of the SI function block, for example to check thevalidity of particular inputs prior to initiating a service, can be modelled by encapsu-lating the SI block within a composite block as discussed in chapter 3. Extra functionblocks could then be added to filter input data and verify response data.

It should be noted that the SI function block type definition only contains defini-tions of behaviour that occurs within the function block domain, i.e. within theResource. It does not define the behaviour outside the Resource that is providedby the device operating system, hardware or communications systems. This is alloutside the scope of IEC 61499.

Partnered Service Interface function blocks

There are situations where SI function blocks are used to provide and exchangeinformation between different resources. For example, an application may bedistributed between two resources A and B, and there is a requirement to sendrequest data from A and receive a response from B. However, both parts of theapplication residing in A and B must be able to detect whether the data exchangehas been successful. One solution to this is to provide Client and Server SI functionblocks that are capable of bi-directional data transfer. The Client block in resourceA sends out the request to the Server block in resource B; the Server responds andsends the response data back to the Client block in A.

To model this, the standard specifies that Time-sequence diagrams may showthe transactions for both partners. Consider the Client and Server function blocks

Figure 4.6 Client, Server SI function blocks

EVENT EVENTEVENTEVENT

BOOL BOOL

STRING STRING

ANY ANYANYANY

CLIENT

INITREQ

QI QO

ID

SD_1SD_n

INIT0CNF

STATUS

RD_1RD_n

CLIENT Service Interface function block

EVENT EVENTEVENTEVENT

BOOL BOOL

STRING STRING

ANY ANYANYANY

SERVER

INITREP

QI QO

ID

SD_1SD_n

INIT0IND

STATUS

RD_1RD_n

SERVER Service Interface function block


as shown in Figure 4.6, and assume that these provide an interlocked data exchangeservice. When the Client issues a request, the Server responds. Part of the Time-sequence diagram for this is shown in Figure 4.7; in this case the two vertical barsrepresent the processing and time delays that occur to transfer a message betweenClient and Server.

The textual syntax for service sequences can include definitions of both ends ofthe transaction. For example, the type definitions for Server can include the expectedresponse from the other Client. To illustrate this, the following textual syntax woulddefine the bi-directional data transfer service sequence as part of the Server’s typedefinition, i.e. it describes the Time-sequence diagram shown in Figure 4.7.

SEQUENCE normal_data_transfer

CLIENT.REQ+(SD_1,...,SD_m) ->SERVER.IND+(RD_1,...,RD_m);SERVER.RSP+(SD_1,...,SD_n) ->CLIENT.CNF+(RD_1,...,RD_n);

END_SEQUENCE

Note that the Client’s definition will simply refer to the Server for the full transactiondefinition. Also note that in this example the notation ‘ ..., SD_m’ just indicatesthat the Client/Server blocks are general purpose and can be tailored to fit particularapplications. In a real system, each Client/Server pair would be specified to sendand receive a fixed number of data items of a given data type.

A Client and Server pair in effect provides a mechanism to create a local ‘proxy’of a remote function block. They can provide a local set of inputs and outputs thatmimic those available on the remote block. It is envisaged that engineering supporttools will be able to automatically insert client/server pairs when an application issplit between resources.

Management function blocks

The last form of SI function block that is defined in the standard concerns servicesto load, start and initiate function block execution. The standard defines a generic

Figure 4.7 Bidirectional data transfer


form of Management function block as shown in Figure 4.8 that can be used toinitiate a range of service functions using different command definitions. Thedescriptions of these services and how they work is only given in outline in thestandard. This is an area which is particularly difficult to model because systemswill tend to have completely different mechanisms for loading and creating functionblock networks and starting the execution of loaded applications. In the future, itis likely that further details on these services will be included in other parts of thestandard but it is a large topic that will be difficult to model in a general way.

At one extreme, to start an application, a system may require that all functionblocks and supporting resource libraries be compiled to a binary format and down-loaded into separate devices. At the other extreme, devices may have large librariesof pre-loaded function blocks; for example, function block definitions could all bepart of the device firmware. In this case, an application can be created by simplydownloading the definitions of the connections that are required to create theapplication’s function block networks in the different devices. There may also behybrid systems where some function blocks are in firmware while others aredownloaded.

The services that are supported by the Management function block apply atboth the resource and device level as shown in Table 4.3 and Table 4.4

The Manager function block can be used by specifying different values for theCMD input to initiate the various service functions. The response to each form ofservice function is given by the value returned in the Status output. The servicefunction is further characterised by the value of input CMD_PARAMS.

Figure 4.8 Management function block

Examples:

CMD = CREATECMD_PARAMS = fb_instance_definitionPARAMS = fb instance definition dataRESULT = fb instance referenceThis initiates the service function to create a function block instance definition.


Note: In these two examples the data types for values shown in italics are notdefined in IEC 61499 and are regarded as implementation specific. However, thestandard has defined a data exchange format for porting function block definitionsbased on XML—see chapter 7 and appendix B.

As a general comment, function blocks are very effective at modelling systemswhere the behaviour is concerned primarily with data and event flows. It is question-able whether management operations for loading and creating function blocks toform applications that are distributed across devices can be best described usingthe same model. This type of behaviour may require a different type of model, asit is mainly concerned with data management issues.

Table 4.3 Resource level management service functions

Service function Description

Create Create data type definitions, function block types andinstances and connections between function blocks. Thiswill involve downloading definitions from a source, e.g.copying across a network, copying in from a memorysmart card.

Initialise Initialise data types, function block types and instancesand connections. This concerns setting up function blocksand connections into a runnable state and will includeresetting variables to their default initial values.

Start The Start function triggers the execution of function blocknetworks within a resource. Typically it will start theresource scheduling function and start to run SI functionblocks that generate timing events. These in turn triggerchains of events that cause function block execution.

Stop The Stop service causes all execution to cease bysuspending the resource scheduling function.

Delete The Delete service can be used to delete the definition ofany data type, function block or connection.

Query The Query service provides a means to accessinformation about the status, attributes and existence ofdata types, function blocks and connections.

CMD = QUERYCMD_PARAMS = connection_start_pointPARAMS = connection start point definitionRESULT = connection end point definitionThis shows an example of the Query management service function to find the

reference to the end-connection for a given start-connection.


Table 4.4 Device level management service functions

Service function Description

Create Creates and establishes a resource within a device. Thissets up the characteristics and attributes of a resourcein a device.

Initialise Initialise the resource to be ready to load and executefunction blocks.

Start Start the resource to allow function block execution.Stop Stop the resource execution of function blocks.Delete Delete resource from the device so that it can no longer

be accessed to load and execute function blocks.Query Query the device to obtain information regarding the

status, attributes and existence of resource(s) in thedevice.

Table 4.5 Main states of managed function blocks

State Meaning

THAWED The function block instance internal state information is availableand the function block is ready to start execution. This state existswhen the function block’s containing device is being powered-up.

RETAINED A function block is considered to be in this state when its containingdevice is completely powered down.

IDLE The function block is in an initialised state. The block’s executioncontrol chart is in its initial state; input and output variables havetheir initial values.

RUNNING In this state, the function block is considered available for thereception of input events. Any input event will be processed by theresource scheduling function.

STOPPED All processing of algorithms and input events is terminated by thescheduling function.

KILLED Operation of all input events and algorithm processes is inhibited.

Managed function blocks

Function blocks that can be loaded and accessed by Management function blocksare called ‘Managed function blocks’. This is in contrast to non-managed functionblocks; these would include blocks that are part of device firmware and thereforehave a certain degree of fixed functionality.

Managed function blocks can have a number of states as defined in Table 4.5.The state of a managed function block can be changed if it is associated with aManager function block. The concept is that a resource can dynamically changethe configuration of function blocks by issuing requests to Manager function blocks.The way this will actually occur is still very sketchy in the standard but it may bedealt with in more detail in the second part of IEC 61499.


Note: This is just an overview of the main states of managed function blocks. Forfurther details, the reader should refer to the IEC 61499 Part 1 section “Behaviourof managed function blocks” where there are details on the state machine for amanaged function block and also descriptions of the associated transitions betweenthe different states.

Summary

We have now covered the important features of IEC 61499 Service Interfacefunctions. To re-cap, Service Interface (SI) function blocks are provided to give aninterface between function blocks running in the resource and services providedoutside the resource. An SI function block type definition only defines the interfaceinto the service and its response; it does not define the service behaviour outsidethe resource. A special notation, the Time-sequence diagram, is used to show thetiming relationships between events on the input and output side of SI blocks.SI function blocks can be used to:

• read and write to I/O points accessed via the device’s I/O sub-system• request data from external resources or respond to data requests from external

resources• set-up interlocked exchanges of data with external resources, e.g. using Client

and Server blocks• manage the creation and execution of function blocks in a resource.

Event function blocks 87

Chapter 5

Event function blocks

As discussed in chapters 1 and 2, a fundamental property of IEC 61499 functionblock networks is that the execution of all software within every function block is,in some way, event triggered. In this chapter we will review a special set of standardfunction blocks that are provided for event behaviour. These function blocks canbe used to model the control, generation and detection of events.

This chapter will describe the standard event function blocks that:

• allow events to be split to produce new events• allow events to be merged• permit the propagation of particular events• select between two or more events• delay an event by a given period• generate streams of events• create events from Boolean edge detection.

Overview

In the previous chapters we have reviewed several different ways to create functionblock type definitions, i.e. for basic, composite and service interface function blocks.In this chapter we will now review a special set of function block types that aredefined in IEC 61499 specifically to handle events. Most of these function blocksare defined as ‘basic’ blocks. A couple of blocks are defined as a form of ‘serviceinterface’ as they require some interaction with the containing resource. There arealso some more complex event blocks which are built as composites from theelementary event blocks.

All the standard event function blocks are designed to be used within the defini-tions of larger user composite function blocks and applications and provide manyof the common operations required when modelling event behaviours.

In any event-oriented system there is always a need to be able to generate theinitial event that triggers the execution of the first item of software. Likewise, in


IEC 61499 function block networks, an event is required to trigger the first functionblock in every chain of function blocks. Control systems will typically also haveother requirements such as a need to split events to simultaneously trigger multiplechains of blocks or to create trains of events so that blocks are regularly re-executed,e.g. when modelling a system that scans I/O.

Figure 5.1 shows a simple example of a control system that starts executionwhen the system is initially powered-up, i.e. ‘cold started’ and then goes on toexecute two chains of function blocks in parallel. A ‘cold start’ event is clearlyneeded to initiate the first function block in the chain. When the first block FB1has completed its execution, there is a requirement to execute two separate chainsof function blocks. This is shown by the event splitting and triggering blocks FB2aand FB3a. When FB2b and FB3b have both completed their execution, eventsfrom the two blocks are joined using a ‘rendezvous’ to create a single event thatthen in turn fires the last function block FB4.

In this first example, the function blocks only execute once when the systemcold starts, because only one initial event is generated. However, typically a controlsystem will require scanned behaviour where function blocks need to executerepeatedly to monitor plant states and update actuators and so on. This can beachieved by passing a train of events into the first function block, as shown inFigure 5.2. Assume that the event train consists of a regular stream of events sent atregular intervals, say every 100 milliseconds. Now all function blocks in bothparallel paths will be continually re-executed every 100 milliseconds after cold start.

In Figures 5.1 and 5.2, each shaded circle represents some form of eventbehaviour. In fact, we will see that each circle can be replaced by one of the IEC61499 Event function blocks. The timing diagram shown below the function blocknetwork in Figure 5.2 depicts the stream of events entering the event control headerof function block FB1. The event stream emerging from the event rendezvous isalso shown. Notice that here the events are slightly delayed because of the time toexecute algorithms in the parallel function block networks and because of delaysin resource scheduling. The period between events also varies slightly becauseexecution delays may vary; for example, an algorithm may not necessarily alwaystake the same period of time to execute as this may depend on the values of inputand internal variables.

Standard Event function block types

We will now review the rich repertoire of standard Event function block typesdefined in IEC 61499 that allows a wide range of different event scenarios to bemodelled. In the following descriptions each figure shows the external template ofthe function block type on the left of the figure and its corresponding typespecification on the right. Many of these event function blocks are of the ‘basic’form and can be defined using an Execution Control Chart (ECC); some requireinteractions with the resource and are therefore defined using Time-sequencediagrams. There are a few complex event function blocks, such as the ‘Boolean


Figure 5.1 Event chain example

Figure 5.2 Cyclic Event chain example


Rising Edge Detector’, that are defined as composite blocks formed from simplerevent blocks.

Note that in the block type declarations that are shown in the following figures,the formal IEC 61499 function block type name is shown inside the block template.Where associated algorithms are required, these are depicted below the ECC inthe block type specification. In some cases, timing diagrams are also depictedbelow some of the blocks to clarify the timing relationships between input andoutput events.

It is surprising to find that for many of these blocks the internal behaviour canbe completely described by just using an Execution Control Chart (ECC). As anaid to understanding the following ECCs, the points as shown in Figure 5.3 sum-marise the main aspects of the ECC notation that is fully described in chapter 3.

In some of the following definitions such as for the Event Merger, the numberof inputs or outputs may vary. For example, the Event Merger block may merge twoor more events. In such cases, it is envisaged that software tools will automaticallydimension function block instances to have the required number of inputs andoutputs.

Figure 5.3 Understanding ECC notation


Event Splitter

The Event Splitter produces two or more simultaneous output events on thereception of a single input event, as shown in the timing diagram (Figure 5.4).

Event Merger

The Event Merger produces a single output event stream by merging the incomingevents on the input events EI1 to EIn. This can be used to merge two or moreevents (Figure 5.5).

Two Event Rendezvous

The Two Event Rendezvous waits for the reception of one event on both inputevents EI1 and EI2 and produces a single output event on output EO. If the blockreceives a further single event on both EI1 and EI2 inputs, it will produce a furtheroutput event on EO (Figure 5.6).

Note that if at any time the block receives a reset event on input R then a singleevent on both EI1 and EI2 is always required before a further output event on EOis produced, as shown in the timing diagram. In other words, the reset can be usedto re-synchronise the rendezvous of the two event streams.

Figure 5.4 Event Splitter


Event Rendezvous blocks that handle other larger numbers of input events canbe defined using similar designs.

Permissive Event Propagator

The Permissive Event Propagator controls the flow of events from input EI to EOdepending on the value of input PERMIT. A true value is required to allow eventsto flow through the block (Figure 5.7).

Event Selector

The Event Selector allows the output event stream to be selected from either eventinput EI0 or EI1 depending on whether G has the value ‘false’ or ‘true’, respectively(Figure 5.8).

Event Switch

The Event Switch can be used to steer the incoming event stream on EI to go tothe output event EO0 or EO1. G set to ‘false’ switches the events to output EO0; Gset to ‘true’ switches the events to output EO1 (Figure 5.9).

Figure 5.5 Event Merger


Delayed Event Propagator

The Delayed Event Propagator provides a means to delay an event arriving atinput START by a defined period as given by input DT. For example, if DT is setto 100 milliseconds, then an event at output EO will be produced 100 millisecondsafter every event arriving at input START, provided that the input events are atleast 100 milliseconds apart.

However, if further events arrive at input START before the output event at EOhas been produced, these will be ignored because there is no input event queue. Ifa STOP event is received while an input event is being delayed, it will be cancelledand no output event will be produced.

Note that this block requires interactions with the underlying resource and so isdescribed using a simple Time-sequence diagram. Generally, timing can only beachieved by some form of interaction outside of the resource, for example, throughthe use of a timer circuit in the device sub-system (Figure 5.10).

Figure 5.6 Two Event Rendezvous


Restart Event Generator

The Restart Event Generator provides single events when the resource Cold andWarm starts and also when the resource is stopped by some external agent. It islikely that most applications will require at least one instance of this block toinitiate the triggering event that starts execution of a chain of function blocks in anetwork, as shown in Figure 5.1 and Figure 5.2.

This block requires interactions with the resource and is therefore describedusing a Time-sequence diagram (Figure 5.11).

Cyclic Event Generator

The Cyclic Event Generator is used to produce a stream of events at regularintervals. The event stream starts when an event arrives at input START and stops

Figure 5.7 Permissive Event Propagator

Figure 5.8 Event Selector


when an event arrives at input STOP. The period between output events is set bythe value of DT.

This block is described as a composite block using an instance of DelayedEvent Propagator E_DELAY. The feedback path from EO to START ensures thata new event is delayed after the initial start event, and subsequently after everyoutput event (Figure 5.12).

Event Train Generator

The Event Train Generator produces a train of events at output EO each separatedby a given interval. The number of events is set by the value of input N and theinterval is defined by the value of input DT. The count of the number of outputevents that have been produced is given on output CV.

If an input event is received on input STOP, the event output train will cease. Afurther START event will cause a new train of output events to be produced (Figure5.13).

Figure 5.9 Event Switch

Figure 5.10 Delayed Event Propagator


This block is defined as a composite block using instances of the Event-drivenUp Counter, the Event Switch and Delayed Event Propagator function blocks;these are all described in this chapter.

Event Train Table-driven Generator

The Event Train Table-driven Generator provides a train of events on output EOwhere the number of events and the intervals between events can be specified. Thenumber of events is given by input N, the TIME array given at input DT definesthe interval between each sequential output event. For example, if DT is set to thevalue of a time array of size 4, i.e. TIME[4], then the interval between the first and

Figure 5.11 Restart Event Generator

Figure 5.12 Cyclic Event Generator


second events will be the value of TIME[0], between the second and third thevalue of TIME[1], and so on (Figure 5.14).

Note that if the size of the array is m, then the value of N should be m + 1. Forexample, if there are five output events in the train, then four intervals are requiredin the time array.

This block is defined as a composite using instances of the Table Control block,E_TABLE_CNTL and Delayed Event Propagator, E_DELAY. TheE_TABLE_CNTL is a special support block used to select delay times from theTIME[4] array as the output events are counted. In this case it is designed for anarray of size 4 but could be used for arrays of any size by changing the constantsin the expressions where CV is tested.

Separate Event Table-driven Generator

The Separate Event Table-driven Generator is used to produce single events ateach of the event outputs, with each event separated by a defined interval. Thenumber of events is defined by input N and the time interval between output eventsis given by the time array set on input DT (Figure 5.15).

For example, assume that the input to DT is a time array of size 4, i.e. TIME[4],and input N is set to 4 and the block is defined to have 4 output events. Then when

Figure 5.13 Event Train Generator


an event arrives at input START, an output event at EO0 will be produced after aperiod TIME[0], a further output event will be produced at output event EO1 aftera period TIME[1] and so on until all 4 output events have fired once.

If an event is received on input STOP, the generation of output events ceases. Asubsequent START event can then trigger a new set of output events.

This block is defined as a composite using instances of the Event Train Table-driven Generator and an Event De-multiplexor.

Figure 5.14 Event Train Table-driven Generator


Event-driven Bistable (Set dominant)

The Event-driven Bistable (Set dominant) provides a means to latch the arrival ofan event. Its output Q is set to true when an event arrives at the ‘set’ input S. Theoutput Q is cleared to false when an event arrives at the ‘reset’ input R. If eventssimultaneously arrive at both S and R inputs then the S event input is dominantand the Q output is set to true (Figure 5.16).

Event-driven Bistable (Reset dominant)

The Event-driven Bistable (Reset dominant) also provides a means to latch thearrival of an event. Its output Q is set to true when an event arrives at the ‘set’ inputS. The output Q is cleared to false if an event arrives at the ‘reset’ input R. Unlikethe (Set dominant) bistable, if events simultaneously arrive at both S and R inputsthen the R input is dominant and the Q output is set to false (Figure 5.17).

Figure 5.15 Separate Event Table-driven Generator


D (Data Latch) Bistable

The Data Latch Bistable stores the state of a Boolean input D on the arrival of aclock input event (CLK). If the input state has been inverted, an output event EOis produced; the state of the stored Boolean is provided on output Q (Figure 5.18).

Figure 5.16 Event-driven Bistable (Set dominant)

Figure 5.17 Event-driven Bistable (Reset dominant)


Boolean Rising Edge Detector

The Boolean Rising Edge Detector produces an output event EO when the datainput QI has changed from ‘false’ to ‘true’ while tested with input event E1. Thisis best described by the timing diagram in Figure 5.19.

This is a composite function block that uses the functionality of the Data Latchand Event Switch blocks. Because the Data Latch only produces an output eventwhen the input changes state, an event is only produced when there is a changefrom ‘false’ to ‘true’. The Event Switch ensures that only the event for a positivetransition is selected.

Boolean Falling Edge Detector

The Boolean Falling Edge Detector produces an output event EO when the datainput QI has changed from ‘true’ to ‘false’ while tested with input event E1. Thisis best described by the timing diagram in Figure 5.20.

The Boolean Falling Edge Detector has a similar design to the Boolean RisingEdge Detector.

Event-driven Up-counter

The Event-driven Up-counter counts the number of input events arriving on inputCU. An output event CUO is produced after each input event has been counted.

Figure 5.18 D (Data Latch) Bistable


Figure 5.19 Boolean Rising Edge Detector

Figure 5.20 Boolean Falling Edge Detector


The count of the number of events is also provided on output CV. When the counthas reached the value of PV, no further output events are produced and CV remainsat the value of PV; the output Q is then set ‘true’ indicating that the event count iscomplete (Figure 5.21).

The counter can be reset at any time by a reset event on R. The output Q is thenreset to ‘false’, the counter CV is cleared to zero and an output event RO is produced.

Using Event function blocks

It is envisaged that software tools will provide definitions of these Event functionblocks in their standard function block libraries. We can now review the cyclicevent chain example as shown in Figure 5.2 and see how the events can be modelledusing the standard Event function blocks. Figure 5.22 shows how the event schemeas depicted in Figure 5.2 can be created by inserting standard Event function blocks.

The Cold start event is provided by an instance of the Restart Event Generator(see FB_E3). The train of events required to maintain the cyclic execution of thetwo chains of function blocks is provided by an Event Cyclic Generator (seeFB_E4). The Cold start event and the event train are merged using an Event Merger(see FB_E5). The resulting merged event stream is used to trigger the execution ofFB1. The event stream emerging from FB1 is split into two event streams to executethe two function block chains using an Event Splitter (see FB_E1).

Figure 5.21 Event-driven Up Counter


The final event streams from the two function block chains, i.e. from FB2b andFB3b, are then passed into a rendezvous block (see FB_E2). This ensures that theexecution of both function block chains is complete before the execution of thefinal block FB4.

It may be argued that the addition of the Event function blocks adds extra detailsthat make the function block networks overly complex. However, it should benoted that the resulting diagram is now a formal model that defines the blockexecution order precisely and unambiguously.

To simplify function block diagrams, the standard states that some of thecommonly used event constructs may be represented by a graphical shorthandnotation. Figure 5.23 shows how simple graphical connectors can be used in placeof Event Splitter and Event Merger blocks.

Figure 5.22 Using Event function blocks


Note: If graphical connectors are used in this way, software tools should recordthat each connector represents a particular type of Event function block. This isparticularly important if the diagram is converted into a textual form.

Summary

We have now covered all of the standard Event function blocks defined in IEC61499 and seen that these can be used to model a wide range of different eventschemes; for example, from networks where function blocks are only required toexecute once, say as a response to a system cold start, to complex networks wherethere are parallel chains of blocks that require cyclic execution.To summarise:

• Event function blocks provide a precise definition for event behaviour.• Events can be created for common situations such as system Cold start and

Warm re-start.• Events trains can be created where events occur at regular intervals.• Events can be merged and or made to ‘rendezvous’.• Events can be produced when Booleans change state.• Simple graphical connectors can be used to represent common event blocks.

Figure 5.23 Graphical shorthand notation

Industrial application examples 107

Chapter 6

Industrial application examples

In this chapter we will consider how the IEC 61499 concepts and standard functionblocks can be applied to modelling some examples of industrial control systems.


• model a simple temperature control system and its main function blocks• consider how to design a FB model for a conveyor belt control system• consider issues related to modelling systems running on Fieldbus devices• explore some of the special requirements for function blocks used in process

control.

Overview

Through chapters 2 to 5 we have reviewed the concepts and techniques for definingfunction blocks and applications. This included a discussion on the fundamentalelements of the IEC 61499 architecture that covered concepts such as devices andresources and then we went on to show how applications could be modelled usingnetworks of function blocks. We are now ready to consider how these ideas can beused together to model some typical industrial control problems. This chapter willreview some example applications that have been chosen to illustrate some commoncontrol system problems.

There is clearly not space in a book of this format to give detailed model designs.The intention is therefore to show how the important aspects of the control systemcan be modelled and not to spend time on the less important details. Thereforeissues such as error detection and recovery, raising alarms and handling exceptionsto normal behaviour are not covered in detail in the following models. However, itis anticipated that the reader should be able to deduce how these models could beextended to cover the range of additional functionality that would be needed in acomplete industrial system model.

In the following models, input values depicted on models with a ‘#’ prefix,such as #IO_PARAMS, denote configuration constants. It is envisaged that software


tools used for creating IEC 61499 models will provide the means for assigningvalues to such configuration constants. In some cases, where input values are knownto be fixed, literal values are given, e.g. T#100ms.

Note: Data types and literal constants are based on the definitions in the PLCsoftware standard IEC 61131-3. A list of data types is given in Appendix A.

Temperature control example

The first example that we will consider is a simple temperature control system asdepicted in Figure 6.1. In this application we have a heat treatment oven, forexample, used to cure products made from epoxy resin. The oven is heated by aheater element and its temperature is measured using a sensor. We will assumethat the heater is controlled by some form of current regulator, such as a thyristorstack, and that the temperature is measured accurately using a thermocouple. Forour model, we are just going to consider the high-level aspects of the functionalityof this control system, so that finer details such as how to interface with the heatercurrent regulator and sensor are not necessary. We will also assume that issuessuch as thermocouple linearisation and cold-junction compensation are handledin firmware built into the hardware I/O system. Finally we will assume that thecontrol will all run on a single device within a single resource.

This application has been chosen because it typifies a wide range of industrialinstrumentation and control problems. There are many instances where themeasurement of a process is taken, in this case by reading the temperature, and

Figure 6.1 Temperature control example


then an algorithm is used to adjust some form of flow or process variable. In thistemperature control example, we will assume that a simple PID algorithm will beused to monitor the temperature and make appropriate adjustments to the heatercurrent to stabilise the temperature. Similar models could be used for pressureand speed control loops.

To keep the model simple, the oven will be controlled at a fixed temperature;i.e. the set-point temperature is built into the configuration of the control systemand is not adjustable. Clearly in a real system, the set-point would normally beadjustable either via an external device or by a control panel. Similarly, the PIDtuning parameters such as the proportional range, integral and derivative timeconstants are assumed to be fixed.

The top-level application model for this control system is shown in Figure 6.2.The model has the following function blocks:

FB_Scan1This is an instance of a Scanner function block type and provides the ‘Init’ and‘Scan’ events. The ‘Init’ event triggers the initialisation of the rest of the blocksthat are linked in a chain. The Scan event provides an event every 100ms tocyclically execute the other blocks.

FB_Temp1This is an instance of the ‘IO_READER’ block that is described in chapter 4. Itis used to read in the latest value from the temperature sensor every time itreceives an ‘RSP’ input event. The address of the temperature sensor for thedevice I/O sub-system is specified in the constant #T1_ADDR. This blockprovides a service interface to access I/O values from the device I/O sub-system.When the new value from the temperature sensor has been obtained, the blocktriggers its output event ‘IND’.

FB_PID1This is an instance of a PID_SIMPLE block and provides the control algorithmthat adjusts the heater current. It has two input events ‘INIT’ and ‘RUN’. The‘INIT’ event is used to initialise the internal variables used by the PID algorithm.The ‘RUN’ event triggers the execution of the PID algorithm. This causes thePID algorithm to take the latest values for the process value (PV) and set-point(SP) and calculate the new value for its output to drive the heater. When thePID algorithm has run, output event ‘OK’ is produced along with output ‘OUT’.Note that the PID algorithm runs every time the FB_Temp1 block receives anew value for the temperature and has raised event ‘IND’.

FB_Heat1This is an instance of the IO_WRITER block described in chapter 4 and is usedto write the new output value produced by FB_PID1 to the heater currentregulator. In fact, like FB_Temp1, this is a Service Interface block that sendsvalues across the resource interface to the device I/O sub-system. In this case,the value placed on input SD_2 is sent to the I/O device as given by the address#H1_ADDR1. Note that this block runs every time FB_PID1 updates its output.


The top-level model shows the main functionality partitioned into functionblocks and clearly depicts the execution control. Such partitioning allows designmodifications to be readily modelled. For example, an alternative algorithm couldbe used by simply replacing the instance of the PID_SIMPLE block with, say, aFUZZY logic control function block.

This is an example of a scanned execution strategy where the function blocksare run at a regular and repeated update rate; this is typical of a closed loop controldesign. In this case an update rate of 100 milliseconds has been assumed. The useof function blocks in feedback control loops is sometimes referred to as ‘directdigital control’. From the general theory of digital control there is a theoreticalminimum rate at which signals should be sampled to give stable and accuratecontrol. This is typically less than half the time constant of the response of thecontrolled process to step changes. In practice, establishing the appropriate samplingrate may require detailed information on equipment response times, process timeconstants, etc. These issues are outside the scope of this book. However, under-standing the timing aspects of a controlled process is clearly an important aspectof control system design and modelling.

Figure 6.2 Temperature control system FBD


The Scanner function block type used to create FB_Scan1, is built as a com-posite function using standard event function blocks as reviewed in chapter 5: seeFigure 6.3.

The Scanner function block uses an instance of an ‘E_RESTART’ block toprovide the initialisation event ‘INIT’ and an instance of the ‘E_CYCLE’ block toproduce the cyclic event ‘SCAN’.

Note that the periodicity of the ‘SCAN’ events is defined by the configurationconstant T#100ms, i.e. the block generates an event every 100 milliseconds.

The PID_Simple function block type specification is defined as a basic functionblock and is specified in terms of an execution control chart (ECC) and algorithmswritten in the IEC 61131-3 high-level language Structured Text (ST). However,note that any language could be used for the algorithm provided the rules formapping to FB inputs and outputs are clearly defined—this is discussed in chapter 3.

Figure 6.3 Scanner function block


Part of this block’s type specification is given in Figure 6.4; this shows theexternal type specification and the internal type specification. The ECC showstwo states ‘INIT’ and ‘PID_RUN’ that exist when this block receives ‘INIT’ and‘RUN’ events, respectively. The initialisation algorithm ‘ALG_INIT’ runs whenthe ‘INIT’ state is active; likewise, the PID algorithm ‘ALG_PID’ runs when the‘RUN_PID’ state is active. When either algorithm has completed, the ECC alwaysreturns to the initial ‘START’ state.

The Function Block Diagram shown in Figure 6.2 shows the function blocknetwork running on a single resource. This same model may be distributed to runon multiple resources by using service interface blocks, such as PUBLISH andSUBSCRIBE, to transfer data between resources. For example, this applicationcould be run on two controllers as shown in the subapplication example reviewedin chapter 3.

Conveyor test station example

In the second application example, we will consider the control of a conveyorused to feed components past a test station as part of a quality acceptance process.The components under test are plastic housings used in the production of an elec-tronic product. We will assume that these components have been produced by aninjection-moulding machine. Before each component can be used in production itmust pass a quality inspection test that checks a number of key parameters includingthe main dimensions and component identity that is etched into the componentsurface as a bar-code. A record of each test will be recorded in an external databaseheld on a remote server machine.

The main features of the conveyor are shown in Figure 6.5. This depicts aconveyor belt that is driven by a conveyor drive motor. Components are fed ontothe conveyor one at a time and passed under a quality acceptance station from acomponent feeder. If the component has compliant quality parameters, i.e. theyare within the accepted tolerance, and the component has the correct identity, asread from a component bar-code, the component is passed on to the ‘compliantcomponent’ roll-off table. On the other hand, if the component fails any of thequality checks, the reject gate is operated and the component is dropped into thereject hopper. As each component leaves the conveyor, a new component is fed onto the belt from the feeder. The conveyor can be started and stopped by an operatorfrom a small control panel that has ‘start’ and ‘stop’ buttons.

The top-level function block diagram model for this system is depicted in Figure6.6 To create this model we have assumed that the control will run on a singleresource. Later we will consider how the design could be distributed to run ondifferent controllers. Issues such as dealing with conveyor jamming and otherexceptional conditions have not been considered to keep the example simple. Wehave also assumed that the quality parameters are fixed and can therefore be partof the configuration data. In a real system it is likely that these would be providedby an external device or entered from a control panel.


Figure 6.4 PID_Simple function block


The function blocks that represent the functionality in this design are:

FB_Exec1This is an instance of an Exec block type. This block fires up a chain of eventsthat keep the whole control system running. It does this by issuing a singleinitial event ‘InitO’ when the control system is first powered-up. It also produces

Figure 6.6 Conveyor test station FBD

Figure 6.5 Conveyor test station example


a ‘Stop’ event when the control system is powered down that causes the conveyorand all equipment to stop.

FB_DriveCntl1This is an instance of a ‘DriveCntl’ type. This block controls the motor driveand its interaction with the control panel; we will look at its internal designlater. This block produces an initialisation event ‘InitO’ when it is first activatedthat is used to trigger the initialisation of all the other blocks. It also producesan output event ‘EXO’ when the motor changes state, i.e. changes from ‘stopped’to ‘running’, or from ‘running’ to ‘stopped’. It also has a ‘Running’ outputsignal that remains true while the belt is moving. The ‘Running’ signal must betrue for the feeder and roll-off mechanisms to operate. Note that when an ‘EXO’event occurs and the output ‘Running’ is true, this indicates that the motor hasstarted and the belt is moving.

FB_Feed1This is an instance of a ‘Feed’ type and is used to control the component feeder.The ‘Start’ event from the ‘FB_DriveCntl’ is passed to the ‘FB_Feed1’ block tooperate the component feeder. An event at its ‘Feed’ input along with an asserted‘Running’ signal causes the ‘FE_Feed1’ block to push a new component ontothe conveyor. If the feed operation is successful, this block then asserts an‘Onbelt’ output signal and issues an ‘OK’ event.

FB_QualStation1This is an instance of a ‘QualStation’ type and provides an interface into qualitytest station equipment. Values for the parameters to be tested are passed intothis block on its ‘Parm’ input. This block starts the check of the componentdimensions and the scan for the component bar-code when it receives the ‘Check’input event along with an ‘Onbelt’ signal from the ‘FB_Feed1’ block. Whenthe component has passed under the test station equipment, this block issues a‘Done’ event and sets a number of outputs. These are: a Pass signal that indicateswhether the component has passed the quality checks, the Component identity,quality data and a count of components tested so far.

FB_RollOff1This is an instance of ‘RollOff’ type and provides an interface into the Roll-offtable and the reject gate mechanisms. When this block receives a ‘Done’ eventfrom the test station block ‘FB_QualStation1’ on its ‘Run’ event input, it readsthe values of its ‘Running’ and ‘Pass’ inputs. If the ‘Running’ input is not asserted,this indicates that the belt has stopped and so no action is taken. If the belt isrunning and a pass signal is true, the roll-off mechanism is activated to movethe component on to the compliant component table. However, if the componenthas failed the quality tests and the pass signal is set to ‘false’, this block opensthe reject gate and the component is dropped into the reject hopper.

FB_Inventory1This is an instance of the ‘Inventory’ type and provides an interface into adatabase in a remote server to store information from the component tests.When this block receives an ‘OK’ event from the ‘FB_RollOff1’ block, indica-ting that the component has been removed from the belt and a signal indicating


that the component is off the belt, it gathers data to be sent to the remote database.The input event ‘Save’ triggers the block to gather the following information:whether the component has passed the quality test, the component identity,quality data and a count of components tested. This information is sent andstored on a remote server. When the data has been successfully received andstored in the remote database, this block produces a ‘Done’ output event. Thisis fed back to the ‘FB_Feed1’ block to trigger the loading of the next component.

Note that the event streams merge where the ‘Done’ event from ‘FB_Inventory1’is fed back to ‘FB_Feed1’, shown by a tee-junction. As discussed in chapter 5,this is graphical shorthand for an instance of a standard event function block‘E_Merge’.

This conveyor example is one in which the execution timing of the functionblocks is synchronised exactly with the speed of transfer of components along thebelt. The ‘FB_Feed1’ block is only triggered to feed a new component on the beltwhen the last component has been removed from the belt and its data processed.This contrasts with the scanned execution timing strategy of the previousTemperature control example.

The design of the ‘Exec’ function block type is shown in Figure 6.7. This is anexample where an instance of a standard event function block ‘E_RESTART’ hasbeen re-encapsulated as a new function block type to simplify the external interface.

The ‘DriveCntl’ is an example of a fairly complex component function blockas depicted in Figure 6.8. This provides the following functionality:

• It continually reads the values of the start and stop buttons from the controlpanel, i.e. every 100 milliseconds.

• It sets the motor drive state, i.e. ‘running’ or ‘stopped’ and writes this out to themotor drive actuator whenever the panel requests a change of state.

• It produces an initialisation event when the panel and motor I/O have beensuccessfully initialised.

Figure 6.7 Exec function block


• It produces an ‘EXO’ event when the motor (i.e. the belt) changes state between‘stopped’ and ‘running’.

Examining the internal design of this block, we see that the ‘FB_Cycle’ block,an instance of an ‘E_Cycle’ event block, produces a stream of events at 100 milli-second intervals. These events are used to request to read the value of the controlpanel buttons, i.e. using ‘FB_Rd_Panel’. For simplicity, it is assumed that thepanel buttons can be read as a single Boolean value where true means ‘run’ themotor and false means ‘stop’.

Figure 6.8 DriveCntl function block


The Run state is held in an RS bistable block ‘FB_EnableRun’, an instance of‘E_RS’ as described in chapter 5. The ‘Run’ state is set by the rising edge ofoutput RD_1 from ‘FB_Rd_Panel’, which is set to true when the start button isdepressed. The bistable ‘FB_EnableRun’ is reset when either the stop button isdepressed and ‘RD_1’ is false or a stop input event is received. Whenever theoutput Q for ‘FB_EnableRun’ changes state, an event is produced on output ‘EO’.This is used to trigger a request event ‘REQ’ to the ‘FB_Wrt_Motor’ block tochange the state of the motor actuator. When the motor actuator has completed itschange of state, i.e. it has switched between ‘Off’ and ‘On’, the ‘FB_Wrt_Motor’block produces a confirmation event ‘CNF’. This is used to create the final outputevent ‘EXO’.

‘FB_Rd_Panel’ and ‘FB_Wrt_Panel’ are instances of service interface blocksIO_READER and IO_WRITER as described in chapter 4 and provide an interfaceinto the device I/O sub-system to read inputs and write to outputs.

We can now outline the designs of the other function block types used in theconveyor test station example:

Feed FB Type—provides an interface to the feed mechanism; its design willalso use instances of the service interface block types IO_Writer and IO_Readerto write output values to actuators and read in values from sensors concernedwith operating and monitoring the feeder.QualStation FB Type—provides interfaces to the quality test station equipment.This design will again use service interface block types IO_Writer andIO_Reader to operate and read values from the test equipment and visioninspection units. The interface to the bar-code reader uses serial communicationsthat can be modelled using another form of service interface block.RollOff FB Type—this provides the interface for the roll-off mechanism andreject gate. Again this functionality can be modelled using instances of theservice interface block types IO_Writer and IO_Reader to control the variousactuators and read back the values of sensors.

Distributed system model

We will now consider how the system model for the conveyor test station could bedistributed so that it models functionality that runs on different controllers, i.e.devices. Note that if we use the correct IEC 61499 parlance, anything that is capableof supporting a resource is regarded as an IEC 61499 ‘device’. We will assumethat the user panel and motor actuator control is located in one device ‘A’ and therest of the functionality to handle the component feed mechanism, the test equip-ment and the roll-off is located in a second device ‘B’. The two devices as depictedin Figure 6.9 are linked by a local network. The type of network does not affectthe design of the top-level model; it is assumed that it provides a reliable commu-nications link between the devices. For this example, we can assume that someform of industrial ethernet is being used that can reliably send data from onedevice to another, using a network addressing scheme.


The application design is now split between two IEC 61499 Resources 1 and 2located in the two devices. To link the two parts of the application, additionalinstances of PUBLISH and SUBSCRIBE function blocks have been added asshown in Figure 6.10. These are service interface function blocks that can be usedto send data across a communications medium or network. The PUBLISH block‘FB_Pub1’ sends out data with a particular identifier. This is represented in thedesign using the configuration constant ‘ADDR_1’. The SUBSCRIBE functionblock ‘FB_Sub1’ is used to receive data sent out by the publisher block. The‘FB_Pub1’ and ‘FB_Sub1’ can be considered as an associated pair of blocks;together these provide the link between ‘FB_DriveCntl1’ and ‘FB_Feed1’ thatexisted in the single resource model shown in Figure 6.6.

It is envisaged that tools that create function block networks will be able toautomatically insert the appropriate service interface blocks when applicationsare broken into parts that are distributed in different resources.

Although the type of network is not important in the high level model, clearlythere are performance and reliability issues that will need to be considered. Forexample, the additional communications time delay from issuing an ‘REQ’ requestevent to publish data and receiving the associated ‘RSP’ response event may affectthe overall model and system design.

Note that each resource requires its own initialisation event to start the functionblock execution. An additional E_RESTART block has been added to the modelin Resource 2 to ensure that this fragment of the application network is initialised.

Also note that the indication output event ‘IND’ from the subscriber block‘FB_Sub1’ is fed back to the response input event ‘RSP’. This is necessary toensure that the subscriber block is always ‘listening’ for the next item of data to besent by the publisher block.

Figure 6.9 Conveyor test station networked devices


Fieldbus applications

New intelligent plant sensors and actuators are now appearing in the industrialautomation arena that combine built-in processing capabilities with standardcommunications interfaces; such devices are now known collectively as ‘Fieldbus’devices, even though they may not all use the same communications standards. Infact, the IEC has been developing a multi-part Fieldbus standard under thedesignation of IEC 1158 for a number of years. The IEC Fieldbus standard isplanned to cover the complete ISO communications stack from the physical to

Figure 6.10 Conveyor test station distributed FBD

QualData

Resource 2

INIT

RSP

Q1

ID

SD_1

INIT0

IND

QO

STATUSRD_1

SUBSCRIBE

FB_Sub1

#TRUE#ADDR_1

COLD

WARM

STOP

E_RESTART

INIT

Feed

INIT0

OK

Feed

FB_Feed1

Running OnBelt

InitI

Check

OnBelt

Parms

INIT0

Done

Pass

Count

FB_QualStation1

QualStation

Identify

QualData

#Parms

InitI

Save

Stored

Done

FB_Inventory

Inventory

InitI

Run

Running

INIT0

OK

OffBelt

FB_RollOff1

RollOff

PassPass

Pass

Identify

Count

INIT

REQ

Q1

ID

SD_1

INIT0

IND

QO

STATUSRD_1

PUBLISH

FB_Pub1

Initl

Stopl

INIT0

EXO

Running

DriveCntl

FB_DriveCntl1

#TRUE

#ADDR_1

Init

Stop

Exec

FB_Exec1

Resource 1

FB_Start1


application protocol layers. It is intended as a global standard that will allow sensorsand actuators from different vendors to be both compatible at a physical level, i.e.by having standard plugs and sockets, and software compatible, i.e. new replace-ment devices from different vendors can be automatically re-configured to operatein an existing system. It should be possible to build a system using I/O devicesfrom different vendors that interoperate at all levels. For example, it should bepossible to remove a pressure sensor produced by vendor A and exchange it for adevice from vendor B and the system software should be able to automatically adaptand remain operational.

IEC 1158 is not yet an agreed international standard but parts are becomingfairly stable. At the physical layer, the IEC 1158 standard defines a variety ofdifferent options for the physical communications media and data rates. Figure6.11 shows some of the physical cabling and data rate options in IEC 1158-2;there are also wireless and fibre optic options defined in the standard. Unfortunately,this standard has been a long time in development so that a variety of alternativeproprietary Fieldbus solutions are now emerging in the marketplace, e.g. usingSiemens Profibus, and Allen-Bradley’s DeviceNet.

It has been extremely difficult for the IEC to find a suitable compromise solutionthat is acceptable to all industrial nations and that also fits all types of applicationdomains. For example, field devices used in a hazardous area of a petro-chemicalplant will need to be intrinsically safe, i.e. designed for low voltage and low energyto remove risks of gas ignition; these devices will also need to react at relativelyhigh-speed. On the other hand, field devices used by water utilities, for example,to monitor water treatment plants, will generally need to be low cost and operateover longer distances at lower data rates. Having so many conflicting requirementshas resulted in a wide range of different options and solutions being defined forFieldbus communications standards, so that interoperability of different devicesat the physical level may not always be possible. Currently there is also a variety

Figure 6.11 Fieldbus IEC 1158-2 physical layer options


of proprietary implementations of the Fieldbus concepts that allow devices eitherfrom a single vendor or group of vendors to interoperate.

Although a single standard for all industrial field devices is still some way offor may never be achieved, the issues regarding how to design and model systemsbuilt from networks of intelligent devices is still relevant. IEC 61499 concepts canapply to both IEC Fieldbus as well as the proprietary Fieldbus devices.

When using Fieldbus, devices are connected to a common communicationsmedium so that data can be transferred between any two or more devices. Thelayout of the physical wiring arrangement of Fieldbus devices is not determinedby the application. Devices can generally be cabled together in any way that ismost convenient to the installer, such as in a daisy chain that minimises point-to-point cabling: see Figure 6.12. The linkage between the processing elements withineach device is achieved by software by routing data between devices in such amanner as to satisfy a particular application.

Figure 6.13 shows part of an application created by linking instrumentation indifferent Fieldbus segments. This is part of a causticising process used to makewood pulp in paper manufacturing. Each instrument provides a ‘resource’ that iscapable of executing function blocks. Each Fieldbus device may either have abuilt-in repertoire of function blocks or may be installed with new function blocks;for example new block type definitions can be downloaded and stored in someform of non-volatile storage within an instrument. Applications are created byconfiguring the software links between Fieldbus devices and, in some cases,between controllers. Where controllers are connected these will be typicallyDistributed Control System (DCS) work stations but other types of controllerssuch as PLCs may be used. With small applications, clusters of Fieldbus devicesmay be configured into simple applications without the need for a main controller.For example, a simple control loop could be configured by linking an analogueinput instrument, such as a temperature controller, that has an on board PID block,with an intelligent valve that has an analogue output block.

The top-level functional control requirements can be expressed in terms of thefunction blocks that exist within the distributed instruments as shown in Figure6.14. Blocks within clusters of instruments concerned with a specific aspect of thecontrol can be linked into a network. The example shows part of a cascade andratio control loop used in the causticising process. The main advantage of usingFieldbus devices is that the logical connections between function blocks withinthe instrumentation are de-coupled from the physical location of the instruments.It is also necessary to identify the timing relationships between the various blocks.A large number of blocks can be scheduled to run concurrently if they have nointer-dependencies. Part of the execution strategy for this example is shown at thebottom of Figure 6.14.

The next stage is to use IEC 61499 models for the various function blocks tocreate an IEC 61499 application. This will include the addition of service interfacefunction blocks to provide the communications links between the IEC 61499Resources that exist in the different instruments.


There is a proposal to develop a range of standard Fieldbus function blocks thatcan provide the main types of functionality required in general process controlapplications; these are listed in Figure 6.15. Of course, additional specialist blockswill also be required in other control domains, and instrument vendors will also befree to develop their own blocks to encapsulate proprietary algorithms or to interfacewith new types of instrumentation.

Analogue input function block example

We will now consider a typical Fieldbus function block for handling analogueinputs and see how the IEC 61499 concepts can be applied to model its behaviour.

Figure 6.12 Fieldbus concepts

Intelligent Transmittersand Valves

Field Wiring - shielded twisted pair

Fieldbus based on the IEC 1158-2 Standard

Terminator To PC/DCSInterface

Figure 6.13 Distributed instrumentation using Fieldbus

LT101

19

20

FT102

GreenLiquor

Storage

AT103

IP102

IP104A

Heater Cooler

IP104B

TT104

TT105

21

Re-

Bur

ned

Lim

e

SC111

24

LT111

Pur

chas

edLi

me

SC112

25

LT112

AT106

AT107A

AT107B

LT108

DT109

FT110

SC110 23

SC108

22

H1 FieldbusSegment # 3



Control RoomPC

CV-101A/O


The main features of the control of an analogue input are shown in Figure 6.16.This block provides an interface for a range of different transducers, such as forflow, pressure, temperature, water quality (impurity measured in parts per million(PPM)) and so on.

Figure 6.14 Mapping Fieldbus function blocks

FIC

102

FRC

103

AIC

106

AIC

107

FT102

IP102

SC103

AY103

AT103

AT106

AT107A

AT107B

HS107

CV-102A/O

Conductivity

Function requirements – showing main block interconnections

AI CALC PID PID RATIO AO

AI AI LL

AI

AI PID AO

AT107B HS107 AIC107

AT107A AT103 AY103

AT106AIC106 FRC103 SC103

FT102 FIC102 IP102

AT107BHS107AT107AAIC107AT106AIC106AT103AY103FRC103FT102SC103FIC102IP102

Time slots

Execution strategy showing concurrency


The raw input measurement from the transducer is first converted into a workingrange or span. This generally requires calibration to set the maximum and minimumvalues. The calibrated value from the transducer is then passed through some formof linearisation function to convert the values to engineering units. The form oflinearisation function will depend on the type of transducer. In this example, weassume that the transducer is measuring some form of water impurity that requiresa square root function to convert the measured value into a measurement in partsper million.

Figure 6.15 Fieldbus function blocks

Pulse input

Complex analog output

Complex analog input

Complex discrete output

Step output PID

Device control

Setpoint ramp generator

Splitter

Input selector

Signal characteriser

Lead lag

Dead time

Arithmetic

Calculate

Integrator (Totalizer)

Timer

Analog Alarm

Discrete Alarm

Analog Human Interface

Discrete Human Interface

Figure 6.16 Analogue Input functionality

TRANSDUCER

TRANSDUCERRANGE

OUTPUTRANGE

ProcessValue

100% = 200 in H2O

0% = 0 in H2O

25% 50%

100% = 500 PM

0% = 0 PMManual mode

Out-of-servicemode

FILTERLinearSquare Root

FUNCTIONOUT

MANUALValue Alarms

HI/LO


The value is then filtered to remove short measurement spikes that may occurdue to noise from the transducer. Finally the value is converted into an outputrange. There is also a requirement to set an alarm output when a certain thresholdvalue is reached. There is also provision for modes for out-of-service operationand manual operation where a manually supplied value can be used instead of thevalue read in from the transducer. This is provided for commissioning and testingpurposes.

Figure 6.17 depicts the Analogue_Input function block type that models themain parts of the behaviour of this analogue input. Additional functionality thatwould be required for an analogue input in a real system, such as provision forfurther high and low alarm levels and alarm hysteresis, and setting calibrationscales for the PV span range and so on, are not shown to simplify the example.

Figure 6.17 Analogue_Input function block type


This block uses the adapter concept, as discussed in chapter 2, to allow it towork with different types of transducer; i.e. the functionality to handle the interfaceswith different types of transducer is contained in external blocks that are connectedto the analogue input.

The external interface of the Analogue_Input function block is shown at the topof Figure 6.17; there are three input events—‘InitI’ to initialise the block, ‘XMode’to change the operating mode and ‘EXI’ to cause a new process value to be readfrom the transducer.

The block also has the following inputs:

• ‘Mode’ gives an enumerated variable that defines the operating mode, i.e. ‘O_S’for out of service, ‘MANUAL’ and ‘AUTO’.

• ‘ManValue’ input gives the process value to be used when the analogue input isswitched to manual mode.

• ‘TRANS_SKT’ is a transducer socket that receives a ‘plug’ connection from atransducer block of type ‘INPUT_TRANSDUCER’.

• ‘HiAlm’ input defines the alarm level for the high alarm threshold.

On the output side, the block has two output events: ‘InitO’ that occurs whenthe block with its connected transducer has been initialised and ‘EXO’ that occurswhen the block has read a new process value ‘PV’ from the transducer. If theprocess value exceeds the high alarm value, the Boolean output ‘alarm’ is set truewhen the ‘EXO’ output event occurs.

The internal specification of this block is depicted at the lower part of Figure 6.17.The shaded block ‘TRANS_SKT’ is the transducer socket and depicts the inter-face that must be presented by an external transducer block via an adapter interface.

The transducer produces two outputs ‘TransPV’ and ‘Type’ that are passed intothe linearisation block of type ‘LINEAR’. The linearisation block provides analgorithm that is appropriate for the type of transducer and takes the raw transducerprocess value ‘TransPV’ and converts it into engineering units. This value is thenpassed through a filter block. The filter block also has an input to read the transducertype. This is required in order to modify the filter characteristics to match thetransducer type. The filter block produces the final output process value ‘PV’ that isthen passed into the ‘MODE’ block for handling the changes in operating mode.

The ‘MODE’ block provides mode switching between: (a) ‘out-of-service mode’where the process value is not updated, (b) ‘auto mode’ where the process value isderived from the value read in from a transducer, and (c) ‘manual mode’ where theprocess value is derived from the manual input ‘ManValue’. The internal algorithmtests the value of the enumerated input Mode when the change mode event ‘XMode’arrives and selects the appropriate state. The execution control chart for the Modeblock is shown in Figure 6.18. This example assumes that the mode can be changedat any time. In a complete industrial design for an analogue input, there may beadditional contraints concerning when the mode can be switched; for example, forsafety reasons there may be an inhibit to prevent switching to and from the automode. This could be handled by adding further inputs to the MODE block andchanging the expressions for the transitions between the mode states.


Finally an alarm block provides the test to compare the process value with thehigh alarm value and produces the ‘Alarm’ output when the process value exceedsthe high alarm threshold.

Notice that the input events ‘InitI’ and ‘EX1’ are passed directly into the trans-ducer socket. This means that these events will be passed into the transducer blockthat is connected externally to the Analogue Input block via the adapter interface.

Figure 6.19 shows a small sub-application that has been created using twoinstances of the Analogue Input function block, ‘FB_Press1’ and ‘FB_Flow1’.These have been characterised by connecting blocks for pressure and flow trans-ducers, i.e. ‘FB_Trans1’ and ‘FB_Trans2’, to create analogue input values forpressure and flow, respectively. The transducer blocks are connected to the Analo-gue Input function blocks using a plug and socket interface. This allows eachAnalogue Input function block to have internal access to the transducer block viathe transducer block’s external interface. In effect the transducer block replacesthe ‘transducer socket’ shown in the Analogue Input type specification in Figure6.17. The transducer block modifies the Analogue Input’s behaviour to be ‘specific’for a particular transducer type.

In this example sub-application, the two analogue measurements for pressureand flow are passed to a block ‘FB_Panel1’ that handles a small display panel.The ‘FB_Exec’ block provides initialisation event ‘InitO’ to initialise the AnalogueInput function blocks and their transducers and also an execution event ‘EXO’ toensure that the analogue input process values are repeatedly updated at a regularrate, such as every 200 milliseconds. To simplify this example, the mode facilities

Figure 6.18 Mode execution control chart


are not used. In fact the mode of both blocks is set to ‘Auto’ when Analogue Inputblocks are initialised.

Note that each transducer block receives two initialisation events—one receivedon its external interface on event input ‘InitI’. This is used to cause the block toread the transducer I/O address and initialise its interface with the hardware. Afurther initialisation event is received across the adapter interface on event input‘InitTI’ as shown in Figure 6.17; this is used to initialise the interface between theAnalogue Input block and the transducer.

As a final note in this chapter, the approach taken when modelling or designingsystems using the IEC 61499 function block concepts will be the same irrespectiveof the types of systems and the types of devices that are used. As discussed inchapter 1, the first stage in designing any function block based system is to considerthe top level Functional Requirement Diagram. This outlines the functionality interms of the main blocks and interconnections. The next stage is to apply the IEC

Figure 6.19 Using the Analogue Input blocks

Initl

Addr#pres1

PRESS_TRANS

Initl

Addr#flow1

FLOW_TRANS

InitO

EXEC

EXO

Initl

ModeManValue>>TRANS_SKTHiAlm

ANALOG_INPUT

XModeEXI

InitO

EXO

Alarm

PV

#Auto

60.0

Initl

Pres1Flow1HiAlm1HiAlm2

MMI

EXI EXO

Initl

ModeManValue>>TRANS_SKTHiAlm

ANALOG_INPUT

XModeEXI

InitO

EXO

Alarm

PV

#auto

45.0

FB_Trans1

FB_Trans2

FB_Exec

FB_Press1

FB_Flow1

FB_Panel1

ANALOG_INPUT Example subapplicationThis reads the values of flow and pressure from two transducers and displays the values on a display panel.


61499 concepts to decompose the blocks of functionality into networks of functionblocks with data and event flow connections. This can include hierarchical decom-position where larger blocks are specified as composites made up from smallerblocks. The function blocks can then be distributed to run on processing resourcesthat are interconnected by various networks and communication links. Here, theterm processing resources applies to any device that is capable of running functionblocks, e.g. PCs, Programmable Logic Controls, DCS out-stations and intelligentdevices and instruments. In some cases, the required functionality may already bebuilt into a particular type of instrument. For example, the model may require acascade PID controller, so the functionality expressed in the IEC 61499 modelmay reflect the behaviour of existing devices. Having the complete IEC 61499function block system model with information on all blocks’ internal specifications,algorithms and timings, it is then possible to go on and verify the design andsimulate the system behaviour. The IEC 61499 function block model also providesan implementation independent view of the system. This could be particularlyuseful when it is necessary to formally verify and validate a system design; forexample, as would be necessary for a safety-related system.

Summary

This chapter has now considered a range of industrial applications that demonstratethe features of the IEC 61499 function block standard. This has shown that thefunction block model is very flexible and can be easily adapted to model differenttypes of system arrangements. This has ranged from systems that require scannedexecution strategies to those where the function block execution is directly relatedto the way the plant is behaving and from systems that run on a single resource tothose that are distributed across resources connected in a network.

It has also been shown that the function block model can be applied to Fieldbusdevices where software functionality is distributed in instrumentation linked viacommunications networks.

The adapter concept is also very useful for creating generic blocks wherebehaviour is characterised by the connection of external blocks using a ‘plug’ and‘socket’ interface. This concept is particularly useful for blocks dealing with familiesof input and output devices such as analogue inputs and outputs.

Future development 131

Chapter 7

Future development

In this final chapter we will review how the IEC 61499 standard is likely to developin the future and its possible impact on the design of systems and support tools.

This chapter will review:

• current limitations of part 1 of the IEC 61499 standard• proposals for IEC 61499 part 2 that covers ‘Engineering Task Support’• requirements of a standard file exchange format for porting• future developments.

Current status of IEC 61499

We have now covered the main concepts defined in the first part of the IEC 61499Function Block standard. This book has focused more on providing an overview andshowing how the standard can be applied rather than exploring some of the morecomplex details within formal definitions. One area, which has not been exploredin any great detail, has been the textual syntax that is defined within Part 1.

The textual syntax is defined formally in terms of ‘production rules’ that can beused by compiler writers to build software tools for processing function blockdesigns. This is an important feature of the standard because it means that designsthat are produced graphically can be stored in a textual form that is portable todifferent support tools. It should be emphasised that all function block typespecifications, applications and subapplications have two equivalent forms. Theycan be defined either graphically, which has been the main form used in this book,or they can be defined in a concise textual form. Tools are already being developedthat can automatically convert between graphical and textual forms.

To recap, IEC 61499 Part 1 defines an architecture, models and definitions thatallow function blocks and applications to be defined in a precise form withbehaviour that is well understood. However, to create and manage systems basedon function block concepts, further definitions and concepts are required; this isthe domain of Part 2 of the IEC 61499 standard.


Part 2 covers ‘Engineering Task Support’ and includes the following topics:

• specification of function blocks in a form that can be manipulated by softwaretools

• the functional specification of resource and device types• the specification, analysis and validation of distributed industrial-process

measurement and control systems (IPMCSs)• the configuration, implementation, operation and maintenance of distributed

IPMCSs• the exchange of information among software tools.

At the time of writing this book, Part 1 has become fairly stable and beenreviewed by international standards bodies. It is planned that it will be publishedas a Publicly Available Specification (PAS) towards the end of 2000. Part 2 is welladvanced and is also likely to be published as a PAS by early 2001. PAS is a newconcept being promoted by the IEC for publishing standards early, avoiding someof the more time-consuming bureaucratic stages of standards approval. A PAScan be published even though the standard has not been through all the internationalstandardisation approval processes. A PAS can be regarded as a trial standard thatis made available to the world industrial community to allow the early developmentof products and services. If Parts 1 and 2 of the IEC 61499 standard have a positiveresponse from industrial users, then the PAS forms will be re-published as formalinternational standards (IS) within a couple of years.

The main problem with the development of a new standard like IEC 61499 isthat it requires significant time in industry before all the ideas have been ingestedand put to the test by being applied to model real control systems. Clearly, advancedgraphical programming tools will be needed to apply function block concepts inearnest. It is therefore clearly better to release these ideas early and allow industryand research institutes the opportunity to evaluate the concepts.

Work has also started on Part 3, which will provide “Application Guidelines”on applying the IEC 61499 concepts. This will include examples of how softwaretools can be used to create, edit and manipulate function block designs andapplications and configure function block oriented systems.

As discussed in chapter 1, IEC 61499 function blocks can be used to provide aview of how the functionality of a system is distributed and how algorithms areexecuted. It does not yet cover other areas of the system design life-cycle. Forexample, IEC 61499 does not cover how requirements are captured and used tocreate an initial functional design. It also does not cover issues such as the definitionof low level communication protocols that are needed to load, initiate and configurefunction blocks—this has to be part of domain specific standards that apply theIEC 61499 function block concepts. IEC 61499 is a generic standard and thereforedoes not attempt to define domain specific function blocks, so the standard doesnot contain definitions for common function blocks such as analogue inputs, andPID algorithms. Such definitions should be developed in domain specific standards.It is an IEC objective that IEC 61499 will be referenced in all future standards thatdeal with function blocks which may range from domain standards for processcontrol and building management to safety systems.


A further apparent limitation of IEC 61499 is the fact that it does not give anydetails on how function blocks are actually implemented. How does the Resourceactually schedule function block algorithms? The standard defines the requirementsand rules but does not give details on the implementation. This issue is outside thescope of IEC 61499 and must be dealt with in domain specific standards. Forexample, we would expect Fieldbus standards to cover the implementation offunction block scheduling in a Fieldbus device. On the other hand, devices used inbuilding management systems may be based on different hardware and use differentsoftware operating systems and therefore will require different techniques forscheduling function blocks. Issues related to how function blocks are compiled,downloaded and stored within a device are also related to the implementation andso are not part of the IEC 61499 high level functional model.

So although IEC 61499 currently does not cover the complete system designlife-cycle and has not yet been applied in domain specific standards, such as forfunction block designs for process control, we may ask, is it useful? The answermust be yes, because it provides for the first time a precise methodology for model-ling function block behaviour. This will allow models to be ported between softwaretools and, in the future, for tools to be developed to validate and simulate IEC61499 system models. Throughout this book we have discussed IEC 61499 as asystem modelling technique rather than as a design methodology. This is because,per se, it cannot be used to express all the information required for a completesystem design. However, as a model it can be used to express the most importantaspects of a control system as it shows the relationships between executable algo-rithms, the events that trigger their execution and their timing. Using IEC 61499 itis now possible for software tools to simulate the execution of system models andprove that the models are correct.

Compliance with IEC 61499

The IEC has recognised that it would be impracticable to expect all system productsto be fully compliant with all facets of the architecture and models defined in Part1. It has therefore defined the following compliance classes:

Class 0—Simple devicesClass 1—Simple programmable devicesClass 2—User re-programmable devices

A brief summary of the device functionality required to meet these differentcompliance classes is given as follows:

Class 0—Simple devices

For a device to be compliant with class 0 it should provide basic functionality tosupport: (a) the creation of connections between function blocks, (b) the ability tostart and stop function blocks and applications, and (c) an external query (e.g.arriving across a network) to provide definitions of function block external


interfaces. The query provides a means for exploring the types of function blockswith their input and output data types that exist within the device. Such informationis required by a network configuration tool that is setting up connections betweenfunction blocks in different devices.

Class 1—Simple programmable devices

This class of device has additional functionality beyond class 0 that includes: (a)the ability to create new function block instances as well as connections, (b) theability to delete instances and connections, (c) the ability to start and stop functionblocks and applications and (d) the ability to support queries about data types,function block types and connections. Devices in this class will typically have apredefined set of function blocks, for example, held in firmware; i.e. there is nosupport for changing on-board function block type definitions.

Class 2—User-programmable devices

The final compliant class provides all the functionality defined in Part 1. In additionto the functionality of class 2, these devices have the ability to create new datatypes and new function block types, i.e. to be able to create completely newconfigurations with different function block definitions. This class of device alsosupports a richer range of queries to provide access to all the features of functionblocks and applications. Such devices must allow new function block typedefinitions to be downloaded across a network from a configuration tool.

Engineering support task

Part 2 of IEC 61499 is concerned with the ‘Engineering Support Task’ and definesthe main capabilities of software tools for handling function block oriented systems.A key requirement addressed in Part 2 that applies to any IEC 61499 compliantengineering support system is the ability to create and store library elements andalso to be able to exchange library element designs between different supportsystems.

Part 2 defines a ‘library element’ as a collection of declarations applying to datatypes, function block, adapter, resource and device types and system configura-tions. In effect, this includes all IEC 61499 elements that can be specified as definedin Part 1. Any software tool for handling function blocks must clearly be able tocreate, edit, store and retrieve all of the different types of IEC 61499 libraryelements. In the standard it is stated that software tools should be able to producelibrary elements such as function block type specifications in a file form that isimplementation independent. In other words, means should be provided in allsoftware tools that are compliant with IEC 61499 to be able to produce filescontaining library element definitions, such as function block specifications, thatcan be exchanged between tools and systems from different vendors.


The main features of an IEC 61499 engineering support tool are summarised asfollows:

• to store, retrieve and exchange library elements• to implement particular library elements, e.g. to create an instance of a function

block in a particular Resource• to browse and display the declarations of selected library elements• to create and modify the definitions of library elements, e.g. to open a function

block type definition and modify its internal specification• to validate the correctness of library element definitions, e.g. to be able to check

a composite function block specification and ensure that all internal connectionsare between points of compatible data types

• to produce compilable forms of function blocks suitable for either committingto firmware or downloading into devices, and also to be able to produce connec-tions between function block instances in a form that can be established acrossa network.

File exchange format

The ability to exchange function block and application models between differentsoftware tools and platforms is a very important aspect of the IEC 61499 standard.Being able to exchange function blocks between different products and systemswill bring significant end-user benefits. This will include major cost savings frombeing able to re-use function block designs in different hardware and systemconfigurations.

The ability to exchange software designs between different vendors’ productshas been a serious limitation of the IEC 61131-3 PLC Software standard becauseIEC 61131 failed to include a definition of a file exchange format. It has not beenpossible for graphical PLC software designs using IEC 61131-3 languages to beexchanged between different PLC software support tools.

There is now an option in IEC 61499 Part 2 to use the Extended MarkupLanguage XML as a file exchange format for IEC 61499 library elements. XMLis the next generation language on from the hypertext markup language (HTML)that is used for all World Wide Web page definitions. The use of XML will bringsome exciting benefits and should have a major impact on how quickly IEC 61499is accepted by the industrial community. This will mean that IEC 61499 functionblock designs can be transferred across the Internet and viewed on Web pages usingthe next generation of Web browsers. Part 2 defines Document Type Definitions(DTDs) for use with XML to provide additional attributes to the various libraryelements. For example, there is the provision for adding attributes such as Version,Author, Date and Remarks to function block type specifications.

Part 2 also allows XML to be used to express function block type specificationsthat use both textual and graphical languages for algorithm definitions. For example,there are extensions to allow function block algorithms to be defined using the


IEC 61131-3 Ladder Diagram language. This means that a function block can bedesigned graphically and then stored and transferred using the XML file format.The complete graphical design can then be viewed on XML compliant Webbrowsers as shown in Figure 7.1.

Note: XML browsers will display the hierarchical structure and attributes of IEC61499 library elements using a tree view. Browsers will require additional add-insor applets to show the various graphical views of IEC 61499 library elements.

As use of the Internet and the World Wide Web becomes more commonplacewe will undoubtedly start to see the influence of this technology in the industrialcontrol domain. Dr. Christensen from Rockwell Automation has already demon-strated the use of Java as a viable control language for expressing function block

Figure 7.1 Using XML for function block definitions

IEC 1499 FunctionBlock Specification

VoterBlk

In 1 In 2 Out 1

In 1 In 3

Algorithm defined using IEC1131-3 Ladder Diagram

Complete function blockdefinition in XML format

<?xml version=“1.0”encoding=“UTF-8”?><!DOCTYPE System SYSTEM “FBType.dtd”><FBType Name=“VoterBlk” Comment=“2 outof 4 voter”><Identification Function=“VOTER”Classification=“Safety” Type=“Boolean”/><VersionInfo Organisation=“LewisTechnology”Version=“1.0”…

VoterBlk

XML viewed using Webbrowsers


algorithms. If we link the use of Java along with XML as a method for storingfunction block definitions, we are very close to having an Internet centred controlsystem design methodology. Perhaps we will start to see IEC 61499 being appliedin completely novel control system designs where functionality is distributed acrossan Intranet or even world-wide across the Internet.

Summary

As this is the end of the last chapter, we have reached a point where we haveconsidered all the main aspects of the new IEC 61499 function block standard. Wehave seen how the various elements defined in Part 1 fit together to create a systemarchitecture for function block execution. The standard covers the key features ofthe function block specification including formal definition of its external interfaceincluding the inputs and outputs of the block and their association with input andoutput events.

We have seen that the standard includes a special form of state machine, theExecution Control Chart, to define how events and algorithms are related within afunction block. There are also special forms of function block for dealing with theinterfaces to external services, such as accessing device I/O values or communi-cating with other function blocks in other resources.

In chapter 6 we reviewed how these concepts can be applied to some industrialapplications. We have seen that the function block approach is particularly applic-able to Fieldbus devices. In this final chapter we have reviewed IEC 61499 Part 2and considered some of the capabilities of engineering tools that are required tomanage and create function block oriented system models. This included adiscussion on the use of a file exchange format based on XML which will allowfunction block designs to be viewed in the future using Web browsers.

Introduction 139

Bibliography

1 Aguiar, M.W., Murgatroyd, I.S., and Edwards, J.M.: ‘Object-oriented resourcemodels: their role in specifying components of integrated manufacturingsystems’, Computer Integrated Manufacturing Systems, 1996, 9, (1), pp. 33–48

2 Orfali, R., Harley, D., and Edwards, J.: ‘The essential distributed objectssurvival guide’ (Wiley, 1996)

3 International Electrotechnical Commission, Technical committee 65, WorkingGroup 6: ‘Function blocks for industrial-process measurement and controlsystems, Part 1: ‘Architecture’. Revision 2000, PAS

4 International Electrotechnical Commission (1993): ‘Programmable controllersPart 3: Programming Languages’. IEC 1131-3, IEC Geneva (also BritishStandard BS EN61131-3 : 1993)

5 OPC Task Force, 1996: ‘OLE for process control, Final Release, Version 1.0’.Available from www.industry.net/OPC

6 Lewis, R.: ‘Programming industrial control systems using IEC 1131-3’. IEEControl Engineering Series 50, 1995

7 Fowler, M., and Scott, K.: ‘UML Distilled’ (Addison-Wesley, 1997)8 International Electrotechnical Commission: ‘Programmable controllers Part

5: Manufacturing Messaging Service’. IEC 1131-5, IEC Geneva9 Fingar, P., Read, D., and Stikeleather, J.: ‘Next generation computing: Distrib-

uted objects for business’ (SIGS Books & Multimedia, New York, 1996)10 Kruchten, P.: ‘The 4+1 view model of architecture’, IEEE Software, November

1995

Appendix A

Common elements

This Appendix outlines the common elements used in IEC 61499 that are based ondefinitions from the IEC 61131-3 PLC Software Standard. This appendix is providedas a brief overview —the formal definitions for all of these elements are given inPart 3 of the IEC 61131 standard.

Character set

All textual information should use a restricted set of letters, digits and characters.The standard requires that only characters from standard ISO 646 “Basic codetable” are used.

Optionally lower case letters can be used but they are not significant in languageelements, for example, Ramp1 and RAMP1 are treated as identical. However lowercase letters are still significant if used to define printable strings such as ‘Load Job1a’. Upper and lower case letters can be used within comments.

Note: In IEC 61499 and IEC 61131-3, identifiers are case insensitive but languagekeywords are case sensitive and should always be in uppercase.

Identifiers

Identifiers are used for naming different elements within the IEC languages, forexample for naming variables, new data types, function blocks, applications. Anidentifier can be any string of letters, digits and underlines, provided that:

(a) the first character is not a digit(b) there are not two or more underline characters together.

The standard provides options for supporting identifiers with lower case letters,and identifiers with a leading underline character. There can be no embedded spaces.


The following are acceptable identifiers:

FBMAIN_P1 INPUT_3PV aEvent1 _APP1 �

The following are illegal:

FB__PV EX 3PV 1EXpa �

The standard states that the first six characters should be tested for uniqueness.The following two identifiers may therefore be regarded as identical on somesystems:

ABX456_XY ABX456_69

Consequently to avoid the possibility of ambiguous identifiers, when developingsoftware that may be ported to different systems it is important that at least thefirst six characters are always unique.

Comments

Various length comments from short to multi-line can be inserted in any textualdefinitions of IEC 61499 library elements. Comments can be placed wherever it isacceptable to insert one or more spaces.

Comments are framed by the characters (* ....... *).Examples are :

(* Event input qualifier *)(****************************)(* Service initialisation *)(* Comment

on several lines *)

Data types

The IEC data type range includes floating point numbers for arithmetic compu-tations, integers for counts and identities, Booleans for logic operations, times anddates for timing and managing batch systems, strings for holding textual informationand bits, bytes and words for low level device operations.

Literals for each data type are included in the following descriptions. Note thata literal is a constant that defines how a given value for a particular data type isrepresented, for example, integer literals are 12, 343, -3, 0. Where the data type ofa literal may be ambiguous, the data type can be prefixed, e.g. INT#12, #LINT#342.

Integer

Table A.1 Integer data types

IEC data type Description Bits Range

SINT Short integer 8 - 128 to + 127INT Integer 16 -32768 to 32767DINT Double integer 32 -231 to +231-1LINT Long integer 64 -263 to +263-1USINT Unsigned short integer 8 0 to 255UINT Unsigned integer 16 0 to 216-1UDINT Unsigned double integer 32 0 to 232-1ULINT Unsigned long integer 64 0 to 264-1

Integer literals

These can be represented using decimal values, e.g.-123 0 +463 23_123

As binary values, i.e. base 2 values, e.g. 2#1111_1111 (255 decimal)2#0000_1000 (8 decimal)

As octal, i.e. base 8 values, e.g. 8#377 (255 decimal)8#020 (16 decimal)

As hexadecimal, i.e. base 16 values, e.g. 16#FF (255 decimal)16#A0 (160 decimal)

Note: The standard allows the underline character ‘_’ to be inserted into numericliterals to aid readability, otherwise it has no significance.

Floating point (REAL)

Table A.2 Floating point (REAL) data types

Data type Description Bits Range

REAL Real numbers 32 ±10±38 Note 1LREAL Long real numbers 64 ±10±308 Note 2

Note 1: REAL values have a precision of 1 part in 223

Note 2: LREAL values have a precision of 1 part in 252

The format is defined by standard IEC 559; this is identical to the commonlyused IEEE floating point number format.

REAL literals

These can be represented using normal decimals and can be distinguished frominteger literals by the presence of a decimal point. For large and very small values,

Appendix A: Common elements 143


the exponential notation can be used giving the power of ten by which the numbercan be multiplied; either uppercase ‘E’ or lowercase ‘e’ can be used to denote theten’s exponential value, e.g.

20.123, +12_133.21, -0.0001598, -2.65E-10, 0.9E10, 0.6276e+14

Duration (TIME)

Data type Description Bits Usage

TIME Time duration Note 1 Storing the duration of timeafter an event

Note 1: The length and precision of this data type are implementation dependent. TheTIME data type is used to store durations, i.e. in days, hours, minutes, seconds andmilliseconds.

TIME literals

Two forms of time literals are provided: short form and long form. The short formis concise and fairly readable but where improved readability is required, the longform can be used.

In both forms the following letters are used:d = days, h = hours, m = minutes, s = seconds, ms = milliseconds

Short form examples:T#16d3h3s defines 16 days, 3 hours and 3 secondsT#3s30ms defines 3 seconds and 30 milliseconds

Long form examples:TIME#7d_10m defines 7 days, and 10 minutesTIME#16d_5h_4m_4s defines 16 days, 5 hours, 4 minutes and 4 seconds

The last field of a time literal can also be given in a decimal format.Examples:

T#12d3.5h defines 12 days, 3.5 hoursT#10.12s defines 10.12 seconds

Dates and times of day

Table A.3 Dates and times of day data types


DATE Calendar Date Note 1 Storing calendar datesTIME_OF_DAY Time of day Note 1 Storing times of theor TOD day, i.e. real time clockDATE_AND_TIME Date and time Note 1 Storing the date and theor DT of day time of day

Note 1: The length of this data type is implementation dependent.

Time of day and date literals

There are two forms of time of day and date literals: short form and long form.The short form is concise and fairly readable but where improved readability isrequired, the long form can be used.

Table A.4 Dates and times of day literal prefixes

Data type Short form Long form

DATE D# DATE#TIME_OF_DAY TOD# TIME_OF_DAY#DATE_AND_TIME DT# DATE_AND_TIME#

Examples of DATE literals are:D#2001-06-10 — 10th June 2001d#2004-01-13 — 13th January 2004DATE#2002-10-15 — 15th October 2002

Examples of TIME_OF_DAY literals are:TOD#10:10:30 — 10 o’clock, 10 minutes and 30 secondsTOD#23:59:59 — 1 second to midnightTIME_OF_DAY#05:00:00.56 — 0.56 seconds past 5

Examples of DATE_AND_TIME literals are:DT#2002-06-12-15:36:55.40 — 12th June 2002, at 15 hours,

36 minutes and 55.4 secondsDATE_AND_TIME#2008-02-01-12:00:00 — Midday on 1st February 2008

Strings

Table A.5 String data type


STRING Character strings Note 1 Storing textual information

Note 1: The method used to store this data type is implementation dependent.

STRING literals

A string literal defines a number of characters enclosed in quotes.Examples of string literals are:

‘Batch AX201_65’‘ProductID’



Bit strings

Table A.6 Bit string data types


BOOL Bit string of 1 bit 1 Digital, logical statesBYTE Bit string of 8 bits 8 Binary informationWORD Bit string of 16 bits 16 “ “DWORD Bit string of 32 bits 32 “ “LWORD Bit string of 64 bits 64 “ “

Boolean

The Boolean data type is used to define the state of Boolean variables, such asthose associated with digital inputs and outputs.

IEC data type Description

BOOL Has two states FALSE, equivalent to 0, and TRUEequivalent to 1.

A Boolean variable can be assigned logical values FALSE or TRUE. Alter-natively the logical values 0 and 1 can be used.

Boolean literals

FALSE and TRUE can be used to define the literal values of Booleans and aretreated as reserved language keywords.

FALSE 0TRUE 1

Bit string literals

Bit string literals are used to define the contents of bit strings having multiple bits.The same representation as defined for integers, e.g. 146, 2#1101 (value 1101 inbinary), 16#FFAC (value FFAC in hexadecimal), can be used.

Use of generic data types

The elementary data types that have similar properties are organised in a hierarchyas shown in Figure A.1.

Generic data types that start with the prefix ‘ANY_’, can be used for describingvariables in function blocks where there is support for overloaded inputs andoutputs. Overloaded refers to the ability of a variable to be used for different typesof data.

For example, a function block input ‘RATE’ that can accept all types of numericvalues could be defined using the data type ANY_NUM. This would imply thatthe input can be used with any data type from the hierarchy that comes under thegeneric data type ANY_NUM.

Initial values of elementary data types

The IEC 61131-3 standard states that all variables have a known initial value. Bydefault all variables are initialised to zero or in the case of strings to an empty nullstring. Dates default to the value of D#0001-01-01. Alternative initial values canbe defined for derived data types.

Derived data types

New data types can be defined from the elementary data types for use withinfunction block specifications. A new data type is declared by framing the definitionwith TYPE and END_TYPE.

For example, all values for pressures could be held in a derived data type calledPRESSURE which is based on the REAL data type but with an initial value of 1.0.


Figure A.1 Hierarchy of IEC data types


The type can be declared as:

TYPEPRESSURE : REAL := 1.0;

END_TYPE;

Structured data types

New composite data types can be defined by creating a structure using existingdata types. A structure is declared by framing the definition with STRUCT andEND_STRUCT.

For example, the data from a pressure sensor may consist of the followinginformation:

(a) the current pressure as an analogue value(b) the status of the device, i.e. operating or faulty(c) the calibration date(d) the maximum safe operating value(e) the number of alarms in the current operating period.

This can all be defined in a single structure as a new data typePRESSURE_SENSOR:

TYPE PRESSURE_SENSOR:STRUCTINPUT: PRESSURE;STATUS: BOOL;CALIBRATION: DATE;HIGH_LIMIT: REAL;ALARM_COUNT: INT;

END_STRUCT;END_TYPE

Enumerated data types

Enumerated data types allow different states of a value to be given different names.For example, all function blocks within a particular system may have a number

of different operational modes. A data type suitable for variables holding functionblock modes would be:

TYPE BLOCK_MODE:(OUT_OF_SERVICE,MANUAL,AUTO,CALIBRATE);

END_TYPE

Note that variables of type BLOCK_MODE can only be assigned values from thelist of named states, i.e. as given in the enumerated list.

Sub-range data types

A sub-range can be specified that limits the range of a value for a particular datatype.

For example, variables used to store voltages for controlling a set of DC motorsmay be restricted to values +12 volts and -6 volts. A suitable data type forMOTOR_VOLTS would be :

TYPEMOTOR_VOLTS: INT(-6..+12);

END_TYPE

Array data types

An array can consist of multiple elementary data types or other derived data types.For example, consider a variable required to hold a set of operating pressures

for various points around a steam vessel. Suitable data types would be:

TYPE VESSEL_PRESS_DATA :ARRAY[1..20] OF PRESSURE;

END_TYPE

TYPE VESSEL_MATRIX :ARRAY[1..3,1..4] OF VESSEL_PRESS_DATA;

END_TYPE

Note: PRESSURE is also a derived type. VESSEL_MATRIX is a two dimensionalarray of 3 by 4 elements where each element is itself a VESSEL_PRESS_DATAarray.

Notes: The use of array and structure data types can greatly simplify the connectionsbetween function blocks allowing multiple values to be passed between blocksusing a single connection. When composite data is passed into a function blockinput, all data within the composite value must be valid at the time when theinput’s associated ‘WITH’ input event occurs.


Appendix B

Overview of XML

This Appendix gives a brief overview of the XML language and the reasons why ithas been chosen as a file exchange format for IEC 61499 library elements, forexample, for exchanging function block definitions between engineering supportsystems and other IEC 61499 compliant applications.

XML—the next generation Web page markup language

The Extensible Markup Language (XML) has been derived as a subset of thegeneric ISO Standard Generalized Markup Language (SGML). XML is beingdeveloped as the next generation markup language to replace HTML, which is thelanguage that is currently used for page content on the Internet World Wide Web.

SGML is a standard document formatting language that enables a publisher tocreate a single document source that can be viewed, displayed, or printed in avariety of different ways. However, SGML is a comprehensive language with avery complex format that is unsuitable, as it stands, for Web usage. HypertextMarkup Language (HTML) and XML are both simplified versions of SGML thatthat have been especially developed to create and view Internet Web pages. XMLand HTML are both used to define how pages and graphics appear when viewedby Web Browsers. However, XML has an extensible range of features that willallow information to be accessed more quickly and displayed in different ways.XML is being developed to support applications that need to not only viewdocument content but also to extract and manipulate information in a variety ofdifferent ways.

Language structure

SGML related languages have a syntax that provides ways to express howinformation is accessed, structured and displayed. These languages are implementedas a series of tags used to ‘mark up’ the document. As an example, in HTML the<p>tag marks the beginning of a paragraph.


A Web browser will contain a parser that understands the syntax and can interpretthe tags and decide how contents of the document are displayed; i.e. the tags definefeatures such as the layout of headings, tables, indentations, highlights. It alsoidentifies certain attributes that apply to different parts of the document or to thedocument as a whole.

Document Type Definitions (DTDs)

Document type definitions (DTDs) are a very important aspect of SGML thatconcerns how documents are structured and displayed. A DTD defines a set oftags that are used to mark up a particular type of document. With HTML a singledocument type has been created that defines all the HTML tags. However, fromthe experience of the many and varied users of the current World Wide Web, it hasbeen found that HTML language does not provide a sufficient range of tags andfunctionality to cover all the diverse uses of Web content. In fact, a number ofusers have had to develop private extensions to HTML to handle their own specialrequirements.

Benefits from using XML

The XML language has a structure that is very similar to HTML and is actuallyinteroperable with HTML. Unlike HTML, it does not rely on a single documenttype definition (DTD). XML has a standard mechanism for any document builderto define new XML tags within any XML document. So in addition to being amarkup language, XML can also be regarded as meta-language because it can beused to define new DTDs. In IEC 61499 Part 2, this feature has been exploited todefine new document type definitions for function blocks and related IEC 61499elements.

Viewing XML documents

Each DTD defines the format for a particular XML document type and identifieswhich tags should be used in the document. Each document should either containits related DTD or have a reference to where its DTD is held, i.e. in an externalfile. All XML parsers that will be built into the next generation of Web Browserswill automatically parse the embedded DTD to understand how to apply the XMLtags within the document. With knowledge on how the tags are defined it is thenalso possible to validate the document and display its contents.

Use as a Universal Data Interchange Format

Initially XML was developed as a means to structure Web document material.However today, it is now being considered by many organizations as a way totransfer information between applications and tools. Being extensible and, in effect,being self-describing within the documents, XML is an extremely flexible meansof storing different types of information and yet allowing that information to be

Appendix B: Overview of XML 153

read and manipulated in different packages and on different platforms. With XML,because there is already an agreed way to describe information, it is not necessaryto create new file exchange formats for the transfer of information between differentapplications.

An application can now format messages that are destined for other applicationsusing XML. Provided that the receiving application has a built-in XML parser, itcan then dynamically interpret the message format. This approach allows XML tobe used as a universal data interchange format.

For example, XML could be used to describe a part in a control system asshown in the following code block:

<part name= “MainRack” Position= “12.5” Version= “1.0” />

When parsed, this XML block is interpreted as an entity called “Part” that hasthree child attributes: “Name”, “Position” and “Version”. An application can findany attribute and extract its value, irrespective of the order of the attributes withinthe document.

Benefits from using XML

The main benefits from using XML come from its ability to be very extensiblewhich in turn means it is very flexible. New document types with new attributescan be readily created that closely map the characteristics of the original documentor information that is being exchanged. In many cases, applications can still usedocuments in their original format. It is only necessary to add a utility to convertdocuments into XML format for export and parse incoming XML documents onimport.

With XML it is no longer necessary for two applications to agree on a specificmessage format, but they must still agree on the semantics of the data being passed.Generally, it is not sufficient to simply pass information from one application toanother; the application exporting the XML document and the recipient applicationmust agree on how to use the data. It is still necessary for the two applications tohave a common understanding on how the information is used—this cannot beconveyed in the XML.

For example an IEC 61499 engineering support tool can create a function blockdefinition in XML format for export to other applications. XML compliant WebBrowsers will then be able to view the definition. However, it will only be otherIEC 61499 based tools that will understand the structure and meaning of the differ-ent elements within the function block definition.

XML can be regarded as a powerful enabling technology that is now beingconsidered as a means to solve system wide integration problems. Certainly XMLwill provide an effective way to transfer information over the Internet usingprotocols similar to HTTP that is now used to access Web pages written in HTML.


Document Object Model (DOM)

An important aspect of XML is the use of a Document Object Model (DOM).This provides a standard programming interface that allows applications to readand write attributes in an XML document. The DOM provides a repository ofinformation extracted from an XML document. When an XML document is parsed,the attributes are extracted and stored in the DOM. This provides a mechanism bywhich an application can access data for the XML document through a standardsoftware interface.

Clearly enhancing current applications to work with XML may still require asignificant amount of effort. This must include additional software to access theDocument Object Model and the creation of an XML parser. However, if XMLbecomes the main document markup language for the Web after HTML, thenthere clearly will be many advantages to using it for storing and exchanging IEC61499 function block definitions.

Appendix C

Frequently Asked Questions(IEC 61499 FAQs)

This Appendix is a compendium of frequently asked questions with answers con-cerning the development and application of the IEC 61499 Function BlockStandard. The answers have been provided by international experts working inthe IEC working group (IEC 65/WG6) and are not necessarily consistent with thecurrent version of the IEC 61499 standard. The author has restructured and addedadditional comments to some of the answers and also provided some additionalquestions with answers.

Note: This information is not copyrighted and is made publicly available andperiodically updated via links to the Internet siteftp://ftp.cle.ab.com/stds/iec/sc65bwg7tf3/html/news.htm

General questions

• What are the benefits from using IEC 61499?

IEC 61499-compliant distributed industrial-process measurement and control sys-tems (IPMCSs), devices, and their associated life-cycle support systems will beable to deliver a number of significant benefits to their owners and systemintegrators, including:

1. IEC 61499-compliant life cycle support systems will be able to reduceengineering costs through integrated facilities for configuration, program-ming and data management. Additional engineering cost savings will resultfrom the ease of system integration provided by IEC 61499’s simple yetcomplete model of distributed systems. This model provides hardware- andoperating system-independent representations for all functions of the system,including control and information processing as well as communicationsand process interfaces.


2. Economies of scale from uniform application of common software and firm-ware technologies should reduce hardware costs. The most significant costitems in modern control hardware are its embedded firmware and supportingsoftware.

3. Engineers and technicians will be able to reduce system implementationtime by applying a common set of concepts and skills to all elements of thesystem. Further reductions in implementation time will result from theelimination of software patches and “glueware” formerly required to integrateincompatible system elements and software tools.

4. The elimination of patchware and glueware, the availability of interoperablesoftware toolsets, the portability of engineering skills, and the ease of integra-tion of system elements, will yield higher reliability and maintainabilityover the system life cycle.

5. IEC 61499 provides an abstract, implementation-independent means forrepresenting system functions. This common “target” will lead to simplifiedmigration from existing systems to 61499-compliant systems, and fromolder to newer technological platforms (operating systems, communications,etc.) in 61499-compliant systems.

• Is IEC 61499 a “stand-alone” standard?

No, in order to realise the benefits listed in the previous answer, distributed industrial-process measurement and control systems (IPMCSs) will need:

1. communication profiles which define standard communications functionblocks and their mapping to standard open communication services such asthose under development in IEC 61158 Fieldbus

2. standard programming languages such as those defined in IEC 61131-3for the specification of algorithms in basic function block types

3. standardized function block types and guidelines for their application inspecific domains, such as the process control function blocks under develop-ment by IEC SC65C/WG7; this working group is developing function blocksfor process control applications.

• Will IEC 61499 have any impact on existing IEC 61131 products?

In the short term no. However there is an intention that the PLC software standardIEC 61131-3 will be revised so that the function block model becomes compatiblewith IEC 61499. In fact, IEC 61131 function blocks can be easily converted into aform that fits the IEC 61499 model by being encapsulated as basic function blocks.It is also possible to use IEC 61131-3 languages such as Structured Text (ST) andLadder Diagram (LD) to define algorithms within IEC 61499 function block typespecifications.

• I already have a huge amount of legacy programs based on IEC 61131-3 andother procedural languages. How can this be re-used?

Procedural control algorithms will have to be encapsulated in IEC 61499 basicfunction block types. How quickly and fully this will be possible depends on

Appendix C: Frequently Asked Questions (IEC 61499 FAQs) 157

how soon software tools will be available to support this migration. It is certainlyfairly straightforward to take algorithms expressed in IEC 61131-3 StructuredText and encapsulate them as IEC 61499 function blocks.

• Can an application interface with other applications?

No, since there is no application type within which an interface could be defined.However, applications may communicate with each other by means of communica-tion function blocks. Also, subapplications may interface with each other via eventconnections and data connections.

• Why doesn’t 61499 define applications as instances of application types?

An application contains a complete definition for its distribution of function blocksand subapplications over many resources. It is not possible to create an applicationinstance from an application type because each application instance would requirespecific configuration information on how its internal component function blocksare distributed.

• How are applications distributed?

The applications can be distributed using the following process:

1. Create and interconnect one or more instances of the subapplication typesrepresenting the application.

2. Create instances of the service interface function blocks representing theprocess interfaces of the application.

3. Create appropriate event connections and data connections between theprocess interface function blocks and the subapplications representing theapplication.

4. If necessary to improve the distribution, remove the encapsulation aroundthe subapplications, exposing their component function blocks (which mayalso be subapplications) as re-distributable elements of the application.

5. Remove the encapsulation of all of the newly exposed subapplications,repeating as necessary.

6. Distribute the application by allocating its function block instances toappropriate resources.

7. Create and configure appropriate communication function block instancesto maintain the event and data flows of the application.

Note: it is envisaged that the engineering support tools will automatically insertservice interface function blocks to maintain event and data flows between connec-ted blocks when they are distributed to run on different resources.

• Why can’t a composite function block have internal variables?

Internal variables are not required in composite function blocks, since samplingand storage is defined for all possible sources of data, i.e. input variables or outputsof component function block instances.


• What is the difference between a Composite Function Block and aSubapplication?

A Composite Function Block can have Internal Variables, and it has guaranteesfor the sampling of input and output data when these are associated with events.For these reasons, it is not distributable, i.e. it is not possible to break the internalconnections between component blocks and run them on different processingresources. However, to achieve the same effect this can be done by converting thecomposite block type into a subapplication type.

• Can alternative graphical representations be used?

Software tools can use alternative graphical, textual or tabular representations, aslong as accompanying documentation specifies an unambiguous mapping to thegraphical elements and associated textual syntax defined in IEC 61499-1. It shouldbe noted that IEC 61499 defines a model not a graphical programming language.

• How can a function block respond to faults and exceptions?

In the IEC 61499 model, faults and exceptions are modelled as event outputs andassociated data outputs of service interface function blocks. These outputs can beconnected to appropriate event inputs and associated data inputs of any functionblocks, which must respond to the fault or exception, e.g. by changing theiroperational modes (modes are discussed in chapter 6).

• How is the loading and starting of applications managed?

Software tools for this purpose will take as input a system configuration andgenerate sequences of commands to management function blocks to performloading and the starting of applications, either locally or remotely viacommunication function blocks.

Note: The communications protocol and interactions to load and start-upapplications are not defined within IEC 61499 and are not part of its scope. Thisshould be defined in domain specific standards. However, IEC 61499 does definea textual syntax and file exchange format to allow applications to be ported betweensystems.

• Why are there no GLOBAL or EXTERNAL variables?

All variables are encapsulated. There is no guarantee that there will be an implicitglobal distribution mechanism available. When such mechanisms are available,they can always be mapped to service interface function blocks. For example,configuration parameters can be encapsulated in a function block that is thenconnected to other blocks that require the values.

• What is an ECC? Why should it be used and when?

An Execution Control Chart (ECC) is a specialised state machine to enable multipleevents to trigger multiple algorithms, possibly dependent on some internal state.

It should be used when it is necessary to have maximum flexibility in algorithmselection and scheduling, or when there is a requirement for a high-performance,event-driven state machine. It is defined in IEC 61499 as a formal and precise wayto show how events can trigger the execution of internal algorithms. (This isdiscussed in chapter 3.)

• Why use function blocks to model device or resource management applications?

This usage is described in subclauses 1.4.7, 3.3 and Annexes F and G of IEC61499-1. The benefits of using function blocks to model device and resourcemanagement are:

1. a consistent model of all applications in the system, including managementapplications

2. a consistent means of encapsulating and re-using all functions, includingmanagement functions

3. re-use of existing data types4. use of existing, standardised means for the definition of required new data

types and specification of management messages.

• What is the difference between event and data?

More formally the difference can be expressed as:

• Event an instantaneous occurrence that is significant to scheduling theexecution of an algorithm

• Data a reinterpretable representation of information in a formalised mannersuitable for communication, interpretation or processing.

It is important to note that an event signifies some form of state change thatmay signal that an algorithm should be run. In practical terms, it is sometimesdifficult to decide when an event is required or whether a state change can bereflected in the value of an input or output. For example, a function block modechange could be signalled by a dedicated mode input event. Alternatively, it couldalso be signalled by a mode input variable and an update event.

Also note that data cannot be transferred between blocks without an accom-panying event.

Object orientation questions

• Why use such a heavily object-oriented model?

The degree of object orientation used in IEC 61499 is necessary in order to achievethe required level of distributability of encapsulated, re-usable software modules(function blocks).

Note: There are limitations to the OO capabilities provided in IEC 61499, forexample, IEC 61499 does not support multiple-inheritance; this is discussed inchapter 1.



• Is the IEC 61499 model very expensive to implement?

Not necessarily; a full object-oriented implementation is not required by the IEC61499 model—only that the externally visible behaviours of a compliant deviceconform to the requirements for the device compliance class as defined in subclause5.2 of IEC 61499-1. The implementation of a “Class 0” simple device can be quiteeconomical (compliance classes are discussed in chapter 7).

• Why not use a general-purpose distributed object model, like DCOM or CORBA?

There are a number of reasons:

1. Implementation of the features specified for these information-technologymodels would be too expensive, and their performance would almost alwaysbe too slow, for use in a distributed real-time industrial-process measurementand control system (IPMCS).

2. There is no standard, easily understood graphical model for representing theinterconnections of events and data among these kinds of objects in distributedapplications.

3. The function block paradigm is closer to the way system and processengineers think about control functionality.

• Are data and event connections a kind of object?

Data and event connections can be considered objects insofar as IEC 61499 definesa textual syntax for their declaration and a management service for their creation,query and deletion. However, the only attributes that IEC 61499 defines for aconnection are its source and destination. Software tools may require additionalattributes, such as scheduling priority for event connections, and communicationtimeliness constraints for both data and event connections in order to determinewhether a proposed system configuration is feasible. Software tools should alsocheck the types of data and event inputs and outputs for consistency. Annex J ofIEC 61499-1 will define syntax and semantics for the declaration of additionalattributes.

The event-driven model questions

• Why use an event-driven model?

Any execution control strategy (cyclic, time scheduled, etc.) can be represented interms of an event-driven model, but the converse is not necessarily true. IEC 61499opts for the more general model in order to provide maximum flexibility anddescriptive power to compliant standards and systems.

• How can a change in a data value generate an event?

E_R_TRIG and E_F_TRIG function block types are defined in Annex A of IEC61499-1 which propagate an input event when the value of a Boolean input rises

or falls, respectively, between successive occurrences of the input event. Instancesof this type may be combined with other function blocks to produce rising- andfalling-edge triggers, threshold detection events, etc. (A discussion of standardevent function blocks is given in chapter 5.)

• What are event types? What are they used for?

An event type is an identifier associated with an event input or an event output ofa function block type, assigned as part of the event input or output declaration, asdescribed in IEC 61499-1-2.2.1.1. It can be used by software tools to assure thatevent connections are not improperly mixed; for instance to assure that an eventoutput that is intended to be used for initialisation is not connected to an eventinput that is intended to be used for alarm processing.

Event types cannot be detected by Execution Control Charts (ECCs), so thetype of event cannot be used to influence the processing of events in basic functionblock types.

Note that IEC 61499 does not define any standard event types other than thedefault type EVENT. Domain standards may define their own specific event types.

• Why and when should the WITH construct be used?

This is used when designing function block types; the WITH construct is used tospecify:

1. which input variables to sample when an event occurs at the associated eventinput of an instance of the type

2. which output variables to sample when an event occurs at the associatedevent output of an instance of the type.

When using the WITH construct, it should be noted that this information willbe used by software tools to assist the designer of applications using instances ofthese types to assure that:

1. the data used by an algorithm in one function block is consistent with thedata produced by an algorithm in another function block and delivered overone or more data connections associated with one or more event connections

2. the messages transmitted over communication connections between resourcesin a distributed application carry consistent data and events between thefunction block instances in the application in the way intended by the applica-tion designer.

• How can this model accommodate sampled-data systems?

The major issues in sampled-data systems such as those used in motion, roboticand continuous process control are:

1. how to achieve synchronised sampling of inputs2. how to assure that all data has arrived in time for processing by control

algorithms



3. how to assure that all outputs are present and ready for sampling beforebeginning the next cycle of sampling and execution.

Solutions to these problems typically require specialised communication andoperating system services, which can be represented in terms of the IEC 61499model by service interface function blocks. The inputs and outputs to be sampledcan likewise be represented by service interface function blocks, while thealgorithms to be performed will typically be encapsulated in basic function blocks.The relationships between the system services, input and output sampling, andalgorithm execution can then be expressed as event connections and dataconnections.

• What happens if a critical event is lost by the communication subsystem?

This issue is common to all distributed control systems and its solutions are wellknown, e.g. via periodic communication, missing event detection and/or positiveacknowledgement protocols. The IEC 61499 model provides for notification ofabnormal operation via the IND-, CNF- and INITO- service primitives and theSTATUS output of service interface function blocks (see chapter 4).

Engineering methodologies

• How can I use IEC 61499 to design and implement state-machine control?

There are various formal and informal methodologies for the design of state-machine control systems. A general outline of these methods and how IEC 61499models and software tools can be used is as follows:

1. Define the desired sequence of operations for the controlled machine orprocess, as well as possible abnormal sequences that may occur. This maybe done informally in ordinary language, or using more formal notationssuch as Petri nets or IEC 61131-3 Sequential Function Charts (SFCs).

2. Define the actuators that are to be used to implement the desired behaviours,the sensors that are to be used to determine the actual state of the controlledmachine or process, and their interfaces to the state-machine controller(s).IEC 61499 service interface function block types may be used for thispurpose; such type definitions will typically be provided for this purpose bythe supplier of the 61499-compliant sensor and actuator devices.

3. Model the behaviours of the machine or process in response to commands(events plus data) given to the actuators, and the resulting, observable time-dependent outputs (events plus data) from the sensors. This modellingmay be done formally using notations such as Petri nets, or informally usingsimulation models (which may be implemented with appropriate IEC 61499models).

4. Define the appropriate state-machine controllers, typically as the ECCsand algorithms of basic function block types. Methodologies for carrying


out this step may be informal, based on engineering experience, or moreformal, using for example Petri-net theory. Best of all is to re-use existing,proven state-machine controllers from an IEC 61499 function block library!

5. Validate the proposed state-machine controllers versus the model of thecontrolled machine or process. To catch possible design or specificationerrors, this should normally be done using simulation in addition to moreformal validation methods if available.

6. Finally, replace the simulated sensor and actuator interfaces with theservice interfaces to the actual machine or process to be controlled. Thisinstallation is normally to be done piecewise for testing purposes.

Appendix D

PID function block example

This Appendix depicts how a Proportional, Integral and Derivative (PID) algorithmcan be encapsulated as a composite function block.

A PID algorithm is used in ‘closed loop’ control where there is a requirement tocontrol a process that may be subject to disturbances caused by external factors orby unpredictable changes to the process. Examples are: to control the temperatureof a heat treatment oven where the internal temperature has to remain stable whilethe oven door is opened and different loads are inserted into the oven, or to controlthe pressure in a reactor vessel while a chemical reaction is progressing. The PIDalgorithm uses the error between the current process value (PV) and the desiredprocess value or setpoint (SP), along with the integral and derivative values of theerror, to calculate a new output value to drive the process. This output value isused to drive an actuator to, say, adjust the current in a heater or change a pumpspeed in order to bring the process value closer to the setpoint. A PID algorithmhas a number of parameters that must be ‘tuned’ to match the process under control.This is required to ensure that the control action is responsive and has minimumovershoot. An application using a PID is discussed in the beginning of chapter 6.The main features of the PID algorithm are shown in Figure D.1.

Note: this example is intended to demonstrate the use of IEC 61499 to encapsu-late algorithms. The design of PID algorithms is a complex subject and outsidethe scope of this book. An industrially robust PID function block would requiresignificantly more functionality than is described in this appendix.

In this example, the PID function block is constructed by connecting instancesof three function blocks: FB_INT, FB_DEV and FB_CALC. These are createdfrom DERIVATIVE_REAL, INTEGRAL_REAL and PID_CALC function blocktypes, respectively. The DERIVATIVE_REAL and INTEGRAL_REAL blocksprovide derivative and integration functionality for inputs of REAL data type andare based on definitions given as examples in the IEC 1131-3 PLC softwarestandard. The PID_CALC block encapsulates the PID algorithm and calculates a


new output value that is proportional to a weighted summation of the error, thederivative of the error and the integral of the error.

The PID_CALC function block type has two execution states PRE and POST.During the PRE state, it runs an algorithm to calculate the error between the setpointand the process value. It then generates an output event PREO that is used totrigger the execution of the derivative and integral function blocks that are externalto this block. These external blocks use the error value calculated by the PREalgorithm. The POST state is triggered by input event POST, and is entered whenthe external derivative and integral blocks have completed their execution. ThePOST algorithm uses the values of error derivative and error integral from theexternal blocks, along with the current error to calculate the new value for theoutput XOUT.

The PID_CALC block has two modes, ‘AUTO’ and ‘MANUAL’, set by theinput AUTO when it is set to ‘true’ and ‘false’, respectively. In the AUTO mode,the PID algorithm is used to update the output ‘XOUT’. When the AUTO input isFALSE, the PID is not active and the block is set to MANUAL mode. In thismode, the output XOUT is set directly by a manually supplied value given byinput MANOUT.

The graphical function block type declarations required to create the PID aredepicted in the following figures. The IEC 61499 Textual Syntax that describesthe specification for each of the blocks is also given. These specifications includealgorithms expressed using the IEC 1131-3 Structured Text language. At the endof this Appendix is an example of an algorithm expressed using the Java language.

Derivative_real function block specification (Figure D.2)

(* Derivative real *)(* This function block produces an output XOUT *)(* proportional to the rate of change of the *)(* input XIN. The derivative is calculated *)(* while the RUN input is true. The CYCLE time *)

Figure D.1 PID algorithm

PROCESS

Appendix D: PID function block example 167

(* is required to calculate the change of *)(* input value over time. *)

FUNCTION_BLOCK DERIVATIVE_REALEVENT_INPUTINIT : INIT_EVENT;EX WITH RUN, XIN, CYCLE;

END_EVENTEVENT_OUTPUTINITO : INIT_EVENT WITH XOUT;EXO;

END_EVENTVAR_INPUTRUN : BOOL; (* 0 = Run 1 = Hold *)XIN : REAL; (* Derivative input *)

Figure D.2 Derivative_real function block type


CYCLE : TIME; (* Scan cycle time *)END_VARVAR_OUTPUTXOUT : REAL; (* Derivative output *)

END_VARVARX1, X2, X3 : REAL;

END_VAREC_STATESSTART;INIT: INIT -> INITO; (* Initial state *)MAIN: MAIN -> EXO; (* Main state *)

END_STATESEC_TRANSITIONSSTART TO INIT := INIT;START TO MAIN := EX;INIT TO START := 1;MAIN TO START := 1;

END_TRANSITIONS(* Algorithms expressed using Structured Text *)ALGORITHM INIT IN ST: (* Initialisation *)XOUT := 0.0;X1 := XIN;X2 := XIN;X3 := XIN;

END_ALGORITHMALGORITHM MAIN IN ST: (* Main algorithm*)IF RUN THENXOUT : = (3.0 * (XIN-X3) +

X1 – X2))/10.0 * TIME_TO_REAL(CYCLE);

X3 := X2;X2 := X1;X1 := XIN;

END_IF;END_ALGORITHMEND_FUNCTION_BLOCK

Integral_real function block specification (Figure D.3)

(* Integral_real *)(* This function block integrates the value of *)(* input XIN over time. The integration can be *)(* reset by an initialisation event INIT. The *)(* CYCLE time defines the time between block *)


(* update events EX. The integration continues *)(* while the HOLD input is false. If it is *)(* true, the integration value is frozen. *)

FUNCTION_BLOCK INTEGRAL_REALEVENT_INPUTINIT : INIT_EVENT WITH CYCLE;EX WITH HOLD, XIN;

END_EVENTEVENT_OUTPUTINITO : INIT_EVENT WITH XOUT;EXO WITH XOUT;

END_EVENTVAR_INPUTHOLD : BOOL; (* 0 = Run, 1 = Hold *)

Figure D.3 Integral_real function block type


XIN : REAL; (* Integrand *)CYCLE : TIME; (* Scan cycle time *)

END_VARVAR_OUTPUTXOUT : REAL; (* Integrated output *)

END_VARVARDT : REAL; (*Time (Sec) for one cycle*)

END_VAREC_STATESSTART;INIT: INIT -> INITO; (* Initial state *)MAIN: MAIN -> EXO; (* Main state *)

END_STATESEC_TRANSITIONSSTART TO INIT := INIT;START TO MAIN := EX;INIT TO START := 1;MAIN TO START := 1;

END_TRANSITIONS(* Algorithms expressed using Structured Text *)ALGORITHM INIT IN ST: (* Initialisation *)XOUT : = 0.0;DT : = TIME_TO_REAL(CYCLE);

END_ALGORITHMALGORITHM MAIN IN ST: (* Main algorithm*)IF NOT HOLD THENXOUT := XOUT + XIN * DT;


PID_Calc function block specification (Figure D.4)

(* PID_Calculation *)(* The function block provides the *)(* calculations to create the PID algorithm. *)(* It has two main states PRE and POST. During *)(* the PRE state the error between the *)(* setpoint (SP) and process value (PV) is *)(* calculated. During the POST state, the *)(* value for the PID output XOUT is *)(* calculated using the current error, *)(* integrated error and derivative error. *)(* AUTO input when true allows the PID *)


(* to run, when false, sets output to the *)(* manual output value, i.e. MANUAL mode. *)

FUNCTION_BLOCK PID_CALCEVENT_INPUTINIT : INIT_EVENT;PRE WITH AUTO,PV, SP, KP, KI, TD;POST WITH ITERM, DTERM;

END_EVENTEVENT_OUTPUTINITO : INIT_EVENT WITH XOUT;PREO WITH ETERM;

Figure D.4 PID_Calc function block type


POSTO WITH RUN_D, HOLD_I, XOUT;END_EVENTVAR_INPUTAUTO : BOOL; (* 1 = Auto 0 = Manual *)PV : REAL; (* Process value*)SP : REAL; (* Setpoint *)KP : REAL; (* Proportionality or (gain) *)KI : REAL; (* Integration constant 1/sec *)TD : REAL; (* Derivative time, sec *)ITERM : REAL; (* Integral of error *)DTERM : TIME; (* Derivative of error *)MANOUT : REAL; (* Manual output value *)

END_VARVAR_OUTPUTETERM : REAL; (* Error output *)XOUT : REAL; (* PID output *)RUN_D : BOOL; (* Run the derivative *)HOLD_I : BOOL; (* Hold the integral *)

END_VAREC_STATESSTART;INIT: INIT -> INITO; (* Initial state *)PRE: PRE -> PREO; (* Pre state *)POST: POST -> POSTO; (* Post state *)

END_STATESEC_TRANSITIONSSTART TO INIT := INIT;INIT TO START := 1;START TO PRE := PRE;PRE TO START := 1;START TO POST := POST;POST TO START := 1;

END_TRANSITIONS(* Algorithms expressed using Structured Text *)ALGORITHM INIT IN ST: (* Initialisation *)XOUT := 0.0;

END_ALGORITHMALGORITHM PRE IN ST: (* PRE algorithm*)IF AUTO THEN

(* Auto mode *)(* Calculate the control error*)

ETERM := SP - PV;RUN_D := TRUE;(*Run derivative *)HOLD_I := FALSE; (*Integral Hold off*)

ELSE

(* Manual mode *)RUN_D := FALSE; (*Stop derivative*)HOLD_I := TRUE; (*Hold integral *)

END_IF;END_ALGORITHMALGORITHM POST IN ST: (* POST algorithm*)

(* Calculate the new output value *)IF AUTO THEN

(* PID is running *)XOUT:=(ETERM + KI*ITERM + TD*DTERM) * KP;

ELSEXOUT := MANOUT; (* Manually set output *)


PID function block type specification (Figures D.5 and D.6)

(* PID implementation as a composite *)(* function block. This is constructed *)(* using the Integral_real, *)(* Derivative_real, and PID_Calc FBs *)

FUNCTION_BLOCK PIDEVENT_INPUTINIT : INIT_EVENT;RUN WITH MODE,PV,SP,KP,KI,TD;

END_EVENTEVENT_OUTPUTINITO : INIT_EVENT;OK WITH XOUT;

END_EVENTVAR_INPUTMODE : BOOL; (* 1=Auto or 0=Manual *)PV : REAL (* Process value *)SP : REAL; (* Setpoint *)KP : REAL; (* Proportional gain *)KI : REAL; (*Integration constant 1/sec *)TD : REAL; (* Derivative time, sec *)CYCLE : TIME; (* Sampling period *)MANOUT : REAL; (* Manual set output *)

END_VARVAR_OUTPUTXOUT : REAL; (* PID output *)ERROR : REAL; (* Error from setpoint *)

END_VAR



Figure D.5 PID function block type

(* Function blocks *)FBSFB_INT : INTEGRAL_REAL;FB_DEV : DERIVATIVE_REAL;FB_CALC : PID_CALC;

END_FBSEVENT_CONNECTIONSINIT TO FB_CALC.INIT;FB_CALC.INITO TO FB_DEV.INIT;FB_DEV.INITO TO FB_INT.INIT;FB_INT.INIT TO INITO;RUN TO FB_CALC.PRE;FB_CALC.PREO TO FB_DEV.EX;FB_DEV.EXO TO FB_INT.EX;FB_INT.EXO TO FB_CALC.POST;FB_CALC.POSTO TO OK;

END_CONNECTIONSDATA_CONNECTIONSMODE TO FB_CALC.AUTO;PV TO FB_CALC.PV;SP TO FB_CALC.SP;KP TO FB_CALC.KP;KI TO FB_CALC.KI;TD TO FB_CALC.TD;MANOUT TO FB_CALC.MANOUT;FB_CALC.ETERM TO ERROR;FB_CALC.ETERM TO FB_INT.XIN;FB_CALC.ETERM TO FB_DEV.XIN;FB_CALC.RUN_D TO FB_DEV.RUN;FB_CALC.HOLD_I TO FB_INT.HOLD;FB_DEV.XOUT TO FB_CALC.DTERM;FB_INT.XOUT TO FB_CALC.ITERM;CYCLE TO FB_DEV.CYCLE;CYCLE TO FB_INT.CYCLE;FB_CALC.XOUT TO XOUT;

END_CONNECTIONSEND_FUNCTION_BLOCK

Algorithms expressed using Java

The IEC 61499 standard allows algorithms to be expressed in alternative languagesprovided there is a clear and unambiguous mapping between the language variabledata types and the IEC data types. In this PID example, the algorithms defined inthe Textual Syntax for Derivative_real, Integral_real and PID_Calc could beexpressed in other languages such as Java or C.



To illustrate this, the INIT and MAIN algorithms for the Derivative_real functionblock could be expressed in Java as follows:

(* Derivative_real algorithms *)(* Algorithms expressed using Java *)

ALGORITHM INIT IN Java: (* Initialisation *){ XOUT = 0.0; X1 = XIN; X2 = XIN; X3 = XIN;}

END_ALGORITHMALGORITHM MAIN IN Java: (* Main algorithm*){ if ( RUN ){// Calculate derivative valueXOUT = (3.0 * (XIN-X3) +

X1 – X2)/(10.0 *(real)CYCLE);X3 = X2;X2 = X1;X1 = XIN;

}}

END_ALGORITHM

Figure D.6 PID function block type declaration

Testing function block models using a software engineering tool

A major benefit that comes from developing function blocks using IEC 61499 dueto using a standard methodology is that it opens up the possibility for software toolsto be developed for editing, parsing, and testing function blocks. Dr. Christensenfrom Rockwell Automation has developed a prototype of such a software tool,called the FBEditor that has been written in Java. FBEditor enables block designsto be verified, tested and then used as component blocks in larger composite functionblock designs. Function block specifications can be entered using the textual syntax.The FBEditor then parses the specification and if the syntax and structure is correct,automatically produces a view of the external interface of the block. The toolhighlights errors in the textual syntax and allows the user to correct the textualspecification directly on screen. For basic function blocks, the tool also producesa graphical view of the Execution Control Chart (ECC). It can also be used tocreate composite, service interface and adapter function block designs.

The user can test a particular block by defining values in a test window for eachinput and then running the internal algorithm. The values of the block outputs areupdated each time the algorithm is executed when triggered by the user. The usercan then at any time compare the output values displayed in the window withthose expected.

The following screen shots have been taken from a Function Block Editor tooland they show how the tool can be used to develop blocks such as the PID examplediscussed in this Appendix. Figure D.7 shows the Derivative block while it isbeing tested using the FBEditor and depicts the test window with input and outputvalues after the algorithm has been executed. The lower portion of the main windowshows the textual syntax for the block specification.

Note that blocks such as Derivative have internal variables so that it may benecessary to run the algorithm many times with the same input values to checkthat it iterates to the correct output values.

Figure D.8 shows the PID_Calc block during development and depicts itsExecution Control Chart (ECC). This has been created automatically by the toolfrom the block’s textual syntax.

Figure D.9 also shows the PID_Calc block but this time depicts the externalinterface of the block. Note that the association of events with their inputs andoutputs is also shown. The tool from analysis of the textual syntax automaticallyproduces the interface view.

Figure D.10 depicts a further powerful feature of the FBEditor where it allowssimple mimics to be produced to create a test-bed for simulating block behaviour.In this screen shot we see the PID being used in a simple application to control thefluid level in a tank.

Note: The screen shots depicted in Figures D.7, D.8, D.9 and D.10 were producedusing the FBEditor tool developed by Dr. J.H. Christensen, and are shown courtesyof Rockwell Automation.



Figure D.8 PID_Calc ECC screen shot

Figure D.7 Derivative screen shot

Figure D.9 PID_Calc Interface screen shot

Figure D.10 PID Test Simulation screen shot


Appendix E

Textual syntax

This Appendix gives a brief overview of the main keywords used in the IEC 61499Textual Syntax. It is provided to assist with the understanding of the examples ofTextual Syntax given in this book. For a full description and the full and formalproduction rules, the reader is advised to read Annex B in IEC 61499, Part 1.

Text enclosed in quotes ‘...’ are keywords, text enclosed in angle brackets <...>is descriptive.

Function block type specification

SYNTAX:

‘FUNCTION_BLOCK’ <function block name><function block type specification body>

‘END_FUNCTION_BLOCK’

This is used to define a function block type specification. Each specification bodymust contain the function block interface variable list. This identifies the inputand output events and data passed across the interface into and out from the functionblock algorithms (for basic blocks) or component function blocks (for compositeblocks).

For a basic function block, the specification body also contains internal variables,the execution control chart declaration and the algorithm declarations.

For composite function blocks, the specification contains a list of componentfunction block instances, and a list of connections between the components.

A function block specification for a service interface function block contains aservice declaration.


Event I/O specification

SYNTAX:

‘EVENT_INPUT’<event input declarations>

‘END_EVENT’‘EVENT_OUTPUT’<event output declaration>

‘END_EVENT’

These keywords are used to define the input and output events in a function blockspecification body, i.e. they define events that pass into and out of the functionblock interface. Each event input and output declaration contains the event nameand an optional event type. The ‘WITH’ keyword can be used to associate anevent with one or more data inputs (for input events) or data outputs (for outputevents), e.g.

EVENT_INPUTINIT : INIT_EVENT;RUN WITH MODE,PV;

END_EVENTEVENT_OUTPUTINITO : INIT_EVENT WITH XOUT;EXO WITH XOUT;

END_EVENT

Data I/O specification

SYNTAX:

‘VAR_INPUT’<input variable declarations>

‘END_VAR’

’VAR_OUTPUT’<output variable declarations>

‘END_VAR’

These keywords are used to define the input and output variables in a functionblock specification. Each input and output declaration contains the variable nameand its data type, e.g.

VAR_INPUTMODE : BOOL;PV : REAL;CYCLE : TIME;

END_VARVAR_OUTPUTXOUT : REAL;

END_VAR

Internal variable specification

SYNTAX:

‘VAR’<internal variables>

‘END_VAR’

This is used to define internal variables required by the algorithms within a basicfunction block body.

Function block instance list specification

SYNTAX:

‘FBS’<internal function block instances>

‘END_FBS’

This defines a list of component function block instances required within acomposite function block. Each function block instance name is given, followedby its function block type name, e.g.

FBSFB_INT : INTEGRAL_REAL;FB_DEV : DERIVATIVE_REAL;

END_FBS

Adapter plug list specification

SYNTAX:

‘PLUG’<plug declarations>

‘END_PLUGS’

This defines a list of adapter plugs; each plug has an adapter type. A plug declarationis required to allow a basic function block to connect with a socket of the sameadapter type in another function block.

Appendix E: Textual syntax 183


Adapter socket list specification

SYNTAX:

‘SOCKETS’<socket declarations>

‘END_SOCKETS’

This defines a list of adapter sockets; each socket has an adapter type. A socketdeclaration is required to allow a basic function block to accept a connection witha plug of the same adapter type in another function block.

Connection list specification

SYNTAX:

<event connection list><data connection list><adapter connection list>

A connection list within the body of a composite function block specification canoptionally contain a list of event connections, data connections and adapterconnections. Note that a composite block may contain instances of basic functionblocks connected by adapter plugs and sockets.

A connection list within a subapplication is similar.

Event connection list specification

SYNTAX:

‘EVENT_CONNECTIONS’<event connection declarations>

‘END_CONNECTIONS’

This defines a list of event connections between component function block inputsand outputs, and external interface events for a composite function block. A similarevent connection list can be used in a subapplication, e.g.

EVENT_CONNECTIONSINIT TO FB_INT.INIT;FB_INT.OUT TO FB_DEV.PV;FB_INT.INITO TO INITO;

END_CONNECTIONS

Data connection list specification

SYNTAX:

‘DATA_CONNECTIONS’<event connection declarations>


This defines a list of data connections between component function block inputsand outputs and the external interface. Each data declaration defines the mappingof data between component function block instances within a composite functionblock. A similar data connection list can be used in a subapplication, e.g.

DATA_CONNECTIONSPV TO FB_INT;FB_INT.OUT TO OUT;

END_CONNECTIONS

Adapter connection list specification

SYNTAX:

‘ADAPTER_CONNECTIONS’<event connection declarations>


This defines a list of adapter connections between function block inputs and outputs.Each adapter declaration defines the mapping between a plug and socket ofcomponent function block instances within a composite function block.

Execution control state list specification

SYNTAX:

‘EC_STATES’<execution state declarations>

‘END_STATES’

This defines a list of execution control states that are used in the Execution ControlChart (ECC) for a basic function block specification. Each state declaration containsa list of algorithms to be executed when the state is active and associated outputevents to be triggered when the algorithm has executed, e.g.

EVENT_STATESSTART;INIT : INIT -> INITO;POST : POST -> POSTO;

END_STATES



Execution control transition list specification

SYNTAX:

‘EC_TRANSITIONS’<execution transition declarations>

‘END_TRANSITIONS’

This defines a list of execution control transitions that are used in the ExecutionControl Chart (ECC) for a basic function block specification. Each transition hasa transition condition. This is a logical expression that is expressed in terms ofevents, input and output variables and internal variables and defines the conditionto cause a state change from one given state to another, e.g.

EC_TRANSITIONSSTART TO INIT := INIT;INIT TO POST := (PV > 100 AND RUN);

END_TRANSITIONS

Algorithm declaration

SYNTAX:

‘ALGORITHM’ <algorithm name> ‘IN’ <language> ‘:’<algorithm body>

‘END_ALGORITHM’

This defines an algorithm within the body of a basic function block specification.A basic function block may have either no algorithm, or one or more algorithms.Each algorithm can be defined in a given language, e.g. C, ST, Java, e.g.

ALGORITHM POST IN ST:OUT := SP-PV;STATUS := 1;

END_ALGORITHM

Service declaration

SYNTAX:

‘SERVICE’ <service interface name1>‘/’ <service interface name2> ‘:’

< sequence specifications>‘END_SERVICE’

This defines the service provided by a Service Interface function block. The servicehas two parts to its name to reflect the initiating and receptive aspects of the service,e.g. “PUBLISH/SUBSCRIBE”. The service body contains a list of sequences thatperform the various operations supported by the service.

Service sequence declaration

SYNTAX:

‘SEQUENCE’ <sequence name><service transactions>

‘END_SEQUENCE’

This defines a particular sequence of transactions to provide a given operation ina service specification. Each transaction is associated with an event arriving orissued across the resource boundary, e.g.

SEQUENCE event_delayE_DELAY.START(DT) -> E_DELAY.EO();

END_SEQUENCESEQUENCE delay_cancelledE_DELAY.START(DT) ;E_DELAY.STOP() ;

END_SEQUENCE

Subapplication type specification

SYNTAX:

‘SUBAPPLICATION’ subapp_type_name<subapplication specification body

‘END_SUBAPPLICATION’

This is used to define a subapplication type specification. The body of eachspecification must contain the subapplication interface variable list. This identifiesthe input and output events and data passed across the subapplication interface.

A subapplication is built from a network of other function block and subappli-cation instances. The subapplication specification body contains a list of functionblock instance declarations, a list of subapplication instance declarations and aconnections list.



Subapplication instance list specification

SYNTAX:

‘SUBAPPS’<subapplication instance declarations>

‘END_SUBAPPS’

This is used to define a list of subapplication instances. Each subapplication instancename is given followed by its subapplication type. This is used within asubapplication or application specification body, e.g.

SUBAPPSSUB_Temp1 : LOOPController;SUB_Press1 : PressController;

END_SUBAPPS

Application type specification

SYNTAX:

‘APPLICATION’ <application name><application specification body>

‘END_APPLICATION’

This is used to define a complete application. The application specification bodycontains a list of function block instances, a list of subapplication instances and aconnections list.

System configuration

SYNTAX:

‘SYSTEM’<system configuration body>

‘END_SYSTEM’

The system configuration body contains a complete definition of an IEC 61499system. This contains application configuration details, device configurations andparameters, and function block mappings.

Note: The Textual Syntax for SYSTEM, RESOURCE and DEVICE is complex;the reader is advised to consult the IEC 61499 Part 1, Annex B for full and formaldescriptions.

Index 189

4+1 view model 17

actuators 162adapter

concept 37example of usage 127

advanced distributed systems 4agile manufacturing 1algorithm, for function block behaviour

27algorithm execution 53analogue input, function block example

123–9application

general 22model 25

array data types 149arrays 149asynchronous behaviour 7

BOOL 146boolean 146boolean falling edge, detector 101boolean rising edge, detector 101business systems 4

CASE tools 14character set 141CLIENT/SERVER 81coherent data 7comments 142commissioning 36common interfaces 37compliance to IEC 61499 133component function blocks 55composite function block

definition 55

example (sawtooth) 57rules 55

configuration constants 107conveyor

distributed system model 118example network 112–15

CORBA 5cyclic event 88

generator 94

D (data latch) bistable 100data coherence, using WITH 46data connection, rules 56data flow, concept in IEC 61499 7data types 142

generic, use of 146DCS 2delayed event, propagator 93derivative function block 167derived data type 147design tools 9development view 18device

in system model 22model 23simple 133simple programmable 134user-programmable 134with multiple resources 33

DeviceNet 121differential pressure 37distributed functionality 118distributed instrumentation 123distribution model 32Document object model 154

ECC see execution control chart

Index


ECC notation 90ECC primary states 54EN and ENO concept 9engineering costs 155engineering support 134enumerated data types 148event, if lost 162event connection, rules 55event drive model 160event flow, concept in IEC 61499 7event function blocks 88

graphical shorthand notation 105using 103–4

event merger 91(E_MERGE) usage 56

event rendezvous 88event selector 92event splitter 91

(E_SPLIT) usage 55event switch 92event train, generator 95event train table-driven, generator 96event-driven bistable, (Reset dominant)

99event-driven bistable, (Set dominant) 99event-driven up-counter 101execution

of algorithms 53of composite function blocks 59

execution control 27execution control chart

concept 47features 49

execution model 29constraints 31

execution timing 29

FAQ, frequently asked questions 155–63

FBEditor tool 177fermentation vessel 25Fieldbus

applications 120–3standardisation work 5

file exchange format 39use of XML 135–6

floating point data type, (REAL) 143function block

as IC chip 7as software component 27atomic execution 33

basic form 44basic type 29composite form 44composite type 29event function blocks 87–8external interface 45forms 44instance name 27instances of basic function blocks 52internal behaviour 47main features 27managed main states 85management 82model 26network fragments 24service interface 69service interface type 29SI type definition 71subapplication form 44type 26, 28types and instances 43

functional design 6functional distribution 7

global variables 10globals, why they are not used 158

hardware costs 156HMI, use with service interface blocks

70

identifiers 141IEC

technical committees 13work on IEC 61499 5

IEC 1131 see IEC 61131IEC 1158 120IEC 1499 see IEC 61499IEC 61131-3

ACCESS variables 11communication function blocks 11distinction with IEC 61499 26limitations 9relation to IEC 61499 5

IEC 61499as methodology 6compliance 133current status 131IEC technical working group 12impact on IEC 61131 156PAS 132

Index 191

initial values 147instance behaviour 52integer data type 143integral function block 168intranet 136IO_READER 70

example of usage 109IO_WRITER 70

example of usage 109IPMCS 14

Javaalgorithms expressed using 175new technologies 5to express algorithm 47

Ladder Diagram 9,136libraries, of function blocks 43,134life-cycle 36literals 108loading, function block fragments 34logical view 17

managed function blocks 84main states 85

management application 33management function block 82

service functions 84management model 33mapping, Fieldbus function blocks 124mode control, in analogue function

block 127mode ECC 128modes, how are they modelled 158

objectscharacteristics 15relationship to function blocks 16

OLE/COM 5OO, object oriented methodology 14

why OO concepts are used 159OPC 5operational state model 36

P&ID 6permissive event, propagator 92physical view 18PID

algorithm 166as re-usable algorithm 27function block example 165–79

in instruments 2in subapplication 62simple algorithm 109,113

plastics extruder 25PLC

soft PLC concepts 4systems 2

polymorphic behaviour, using adapters37

process control 13process interface 23process view 17production line 25Profibus 121PUBLISH, example of usage 119publisher 70

RAMP function block 51REQUESTER 73resource

model 24related to device 23

RESPONDER 73restart event, generator 94

sample-data 161sawtooth function block, example 60scanner, function block 111scanning 110–11scenarios 19scheduling function 29,31semantic integration 5sensors 162separate event table-driven, generator 97SERVICE 80service interface 24

function block behaviour 75function block overview 69function block type definition 71

service primitives 78,79SI see service interfaceSIFB see SI function blocksoftware components 5software tools 132storage

for variables 47of inputs and outputs 47

string data type 145structured data 148Structured Text, to express algorithm 47subapplication


defining 61distribution example 64relation to application 25rules for type specification 62temperature control example 62timing and performance 33

SUBSCRIBE, example of usage 119subscriber 70syntax see textual syntaxsystem design views 16system life-cycle 36system model 22

temperature control 62example network 108

textual syntaxcomposite example (sawtooth) 60function block example 50outline description 38SI function block example 78see also Appendix E

time data type 144time-sequence diagram 76timing see execution timingtiming of events 88transaction, defined in service interfaces

77two event rendezvous 91

voter, function block example 39

WG6, IEC working group 6 12WG7, IEC working group 7 13WITH construct

concept 46in composite function blocks 58why it is used 161

XML 135–6overview 151–4proposal in IEC 61499 14

modelling control systems using iec 61499 applying function blocks to distributed systems iee...

Documents

vibration control

multivariable control

ogtimal control

lntelligent control

fligbt control systems

irwinmodelling control

bistory of control engineering

control engineering