Re-Engineering IEC 61131-3 into IEC 61499 Function Blocks

Get Complete Project Material File(s) Now! »

IEC 61499 Execution Semantics

The event-triggered semantics of the standard requires the dynamic activation of function blocks on the presence of an event. When a basic function block is activated, the embedded 18 Literature Review ECC performs a function block run, during which transitions are evaluated and taken until no further transitions are enabled. Algorithms are executed and events are emitted whenever a state is entered during the run. When a composite function block is enabled by an event, block instances in its network that are connected to the event are also activated.
The most common method of executing function block applications is to use a runtime to implement inter-block semantics, compiling each function block into a new class that can be instantiated and executed. Free run-times such as FBRT [39] and FORTE [40] and commercial run-time environments such as nxtForte [45] and ISaGRAF [16] are available for a range of industrial controllers, as well as standard PCs. A recent alternative approach, presented in [33], proposes a semantics which enables more ecient direct execution of function block applications without a run-time.

Run-time Approaches

IEC 61499 run-times are responsible for managing event propagation and the activation and scheduling of blocks. Individual function blocks and function block applications are compiled into objects which are then managed by the run-time they are deployed to. The Function Block Run Time (FBRT) [39], included with Function Block Development Kit (FBDK), is considered to be the reference implementation for researchers and developers. FBDK’s function block compiler generates Java code [46] from any function block type, which can then be executed in FBRT. FBRT faithfully implements an eventtriggered approach for invoking function blocks, by compiling code which directly calls a function from connected blocks when an event is emitted. This produces a depth-rst method of event propagation. While simple, this requires a large stack to implement long
chains of event connections. By directly following the standard with regard to eventtriggered activation of blocks, FBRT only evaluates data-only transitions once on entry to a state. As a result, if a state only has data-only exiting transitions, if none are true when the state completes its actions, the ECC will not re-activate, even after the data values have changed. FORTE [40] provides an open-source event-triggered run-time, which has also been adapted and modied into the commercial nxtForte [45] run-time. FORTE features an event dispatcher, which uses a rst-in-rst-out (FIFO) queue to pass events between blocks. This produces a breadth-rst method of event propagation. Unlike depth-rst, this de-couples the execution of the emitting block from the receiving block, removing any blocking period during the execution of a single block. The 4DIAC-IDE generates C++ code for FORTE, removing the need for a virtual-machine as used by Java.
However, the compiled C++ run-time is still slow and bulky as noted in [30]. In [47] Lastra et al. present an execution semantics for function blocks using a scancycle based approach: assigning inputs, executing the logic and then writing outputs in every cycle. This approach is adopted by the commercial run-time ISaGRAF as explained in [32]. Unlike other approaches, ISaGRAF executes function blocks using a cyclic approach.
In this cyclic run-time, function blocks are executed in every scan-cycle regardless of the presence of input events. Emitted output events can be received by other blocks in the same cycle if they are executed after the emitting block, otherwise they are received in the next scan-cycle. In this way, unlike the standard, the behaviour of an application is dependent on the execution order of function blocks in the network. Cyclic execution also gives rise to the possibility for simultaneous events, a scenario not explicitly covered by the standard. In fact, because simultaneous events are not possible in the event-triggered standard, transitions in an ECC can only be dependent on at most one event. As a result, instead of ECCs, ISaGRAF diverges from the standard by using IEC 61131-3 Sequential Function Charts (SFCs) for state-machine design. This also allows specications in ISaGRAF to react to the absence of events, which is not possible in the standard.
A key disadvantage to run-time approaches is the overhead of event and block management, resulting in sluggish performance and a larger memory footprint. The buering of events also creates the possibility of event loss due to buer overow. The event-triggered run-times may also create non-deterministic behaviours because of the dynamic scheduling of events and block execution. The cyclic model of ISaGRAF, on the other hand, does not accurately follow the the event-triggered standard, forcing the user to decide on an execution order for blocks. Generally however, it is possible for cyclic execution to behave as in the event-triggered semantics. Finally, all run-times need to be developed and compiled for each target hardware platform before a function block application can be executed. This limits users to either: (1) waiting for commercial run-times nxtFORTE and ISaGRAF to be developed for the required platform, or (2) porting the open-source
FORTE run-time themselves.

READ RHYTHM PERCEPTION BY COCHLEAR IMPLANTEES IN CONDITIONS OF VARYING PITCH

1 Introduction
1.1 Industrial Practice
1.1.1 Drawbacks
1.2 Model-Driven Engineering
1.3 Research Objectives .
1.4 Thesis Contributions .
1.5 Thesis Organization
2 Literature Review
2.1 Limitations of IEC 61499 .
2.2 IEC 61499 Execution
2.3 Synchronous Function Blocks
2.4 Enhancing ECCs for reactive systems .
2.5 Migrating From IEC 61131-3 to IEC 61499
2.6 Remarks .
3 An IEC 61499 Case Study
3.1 Development of a BHS .
3.2 Discussion
4 Hierarchical and Concurrent ECCs for IEC 61499 Function Blocks
4.1 Formalisation of IEC 61499 .
4.2 Hierarchical and Concurrent ECCs .
4.3 Discussion .
4.4 Conclusions .
5 Re-Engineering IEC 61131-3 into IEC 61499 Function Blocks
5.1 IEC 61131-3 specications .
5.2 Proposed Mapping of IEC 61131-3 to IEC 61499
5.3 Proposed Approach .
5.4 Results .
5.5 Discussion
6 Compilation of IEC 61499 Function Blocks
7 Development of IEC 61499 Tools
8 Conclusions
References