Part 1: Architecture
IEC 61499-1 defines the architecture for distributed systems. In IEC 61499 the cyclic execution model of IEC 61131 is replaced by an event driven execution model. The event driven execution model allows an explicit specification of the execution order of function blocks. If necessary, periodically executed applications can be implemented by using the E_CYCLE function block for the generation of periodic events as described in Annex A of IEC 61499-1. IEC 61499 enables an ''application-centric'' design, in which one or more applications, defined by networks of interconnected function blocks, are created for the whole system and subsequently distributed to the available devices. All devices within a system are described within a ''device model''. The topology of the system is reflected by the ''system model''. The distribution of an application is described within the ''mapping model''. Therefore, applications of a system are distributable but maintained together. IEC 61499 is strongly influenced by Erlang, with its shared-nothing model and distribution transparency. Application and device model of IEC 61499 Like IEC 61131-3 function blocks, IEC 61499 function block types specify both an interface and an implementation. In contrast to IEC 61131-3, an IEC 61499 interface contains ''event'' inputs and outputs in addition to ''data'' inputs and outputs. Events can be associated with data inputs and outputs by ''WITH constraints''. IEC 61499 defines several function block types, all of which can contain a behavior description in terms of service sequences: Function block interface * Service interface function block – SIFB: The source code is hidden and its functionality is only described by service sequences. * Basic function block - BFB: Its functionality is described in terms of an Execution Control Chart (ECC), which is similar to a state diagram (UML). Every state can have several actions. Each action references one or zero algorithms and one or zero events. Algorithms can be implemented as defined in compliant standards. * Composite function block - CFB: Its functionality is defined by a function block network. * Adapter interfaces: An adapter interface is not a real function block. It combines several events and data connections within one connection and provides an interface concept to separate specification and implementation. * Subapplication: Its functionality is also defined as a function block network. In contrast to CFBs, subapplications can be distributed. To maintain the applications on a device IEC 61499 provides a ''management model''. The ''device manager'' maintains the lifecycle of any resource and manages the communication with the software tools (e.g., configuration tool, agent) via ''management commands''. Through the interface of the software tool and the management commands, online reconfiguration of IEC 61499 applications can be realized.Alois Zoitl Real-Time Execution for IEC 61499, Instrumentation Society of America (ISA), USA, , November 2008.Part 2: Software tool requirements
IEC 61499-2 defines requirements for software tools to be compliant to IEC 61499. This includes requirements for the representation and the portability of IEC 61499 elements as well as a DTD format to exchange IEC 61499 elements between different software tools. There are already some IEC 61499 compliant software tools available. Among these are commercial software tools, open-source software tools, and academic and research developments. Usually an IEC 61499 compliant runtime environment and an IEC 61499 compliant development environment is needed.Part 3: Tutorial Information (2008 withdrawn)
IEC 61499-3 was related to an early Publicly Available Specification (PAS) version of the standard and was withdrawn in 2008. This part answered FAQs related to the IEC 61499 standard and described the use of IEC 61499 elements with examples to solve common challenges during the engineering of automation systems. Among other examples, IEC 61499-3 described the use of SIFBs as communication function blocks for remote access to real-time data and parameters of function blocks; the use of adapter interfaces to implement object oriented concepts; initialization algorithms in function block networks; and the implementation of ECCs for a simplified motor control of hypothetical VCRs. Additionally the impacts of the mapping concerning the communication function blocks was explained, as well as the device management by management applications and its function blocks, and the principle of the device manager function block (DEV_MGR).Part 4: Rules for compliance profiles
IEC 61499-4 describes the rules that a system, device or software tool must follow to be compliant to IEC 61499. These rules are related to ''interoperability, portability'' and ''configuration''. Two devices are ''interoperable'' if they can work together to provide the functionality specified by a system configuration. Applications compliant to IEC 61499 have to be ''portable'', which means that they can be exchanged between software tools of different vendors considering the requirements for software tools described within IEC 61499-2. Devices of any vendor have to be ''configurable'' by any IEC 61499 compliant software tool. Besides these general rules, IEC 61499-4 also defines the structure of ''compliance profiles''. A compliance profile describes how a system conforms to the rules of the IEC 61499 standard. For example, the configurability of a device by a software tool is determined by the supported management commands. The XML exchange format which determines portability of IEC 61499 compliant applications is defined within part 2 and is completed by the compliance profile, for example by declaring the supported file name extensions for exchange of software library elements. The ''interoperability'' between devices of different vendors is defined by the layers of theReferences
Sources
* * * *External links
* * {{List of IEC standards #61499
