1. 3rd IEEE Int. Conference on Industrial Informatics (INDIN), 10-12 August 2005, Perth, Australia
A Real-Time Linux Execution Environment for Function-Block Based Control Applications
Authors:
George S. Doukas
Kleanthis C. Thramboulidis
Software Engineering Group
Electrical & Computer Engineering
University of Patras, Greece

2. Outline IEC 61499 Function Block model Archimedes System platform
RTAI based Execution Environment
Proposed FB Implementation Model
Performance Metrics
Conclusions
INDIN 2005

3. IEC 61499 Function Block model
IEC61499 offers:
Flexibility
Reusability
Robustness
IEC61499 does not
exploit modern software engineering practices such as:
Model Driven Architecture
Component based development
address runtime implementation issues
provide means to capture real-time requirements
INDIN 2005

4. Our approach Corfu ESS Archimedes System Platform
Integrates UML with the IEC model.
Archimedes System Platform
Provides the infrastructure required for FB-based distributed control applications to
exploit current Software Engineering practices
meet their real-time requirements and
allow re-configuration during run-time.
INDIN 2005

5. Archimedes System Platform
exploits
the MIM (Model Integrated Mechatronics) paradigm in the development of Manufacturing Systems.
is comprised of:
a methodology,
an IEC-compliant Engineering Support System (Archimedes ESS),
a set of execution environments, on which the FB based control applications can be executed, and
a set of implementation frameworks, for the constructions of the application’s implementation models.
INDIN 2005

6. Archimedes ESS is a Toolkit allows Model Driven Development,
that supports the construction of IEC compliant Function Block based design models for distributed control and automation and their subsequent transformation to executable systems.
allows Model Driven Development,
it is based on the Generic Modeling Environment (GME), a configurable toolkit for creating domain-specific modeling and program synthesis environments.
can be easily extended to
allow QoS characteristics to be captured in the design model,
support various execution environments
automate the deployment process
INDIN 2005

7. Development process
INDIN 2005

8. IEC61499-compliant Execution Environment
FBRT
The 1st execution environment from Rockwell Automation (based on Java)
Archimedes system platform
provides various implementations of the execution environment
Real-time Linux
Real-time Java
CORBA Component Model (CCM)
A Real-time Linux execution environment was adopted in the context of this work
INDIN 2005

9. 3-Layer Execution Environment Architecture
We focus on AE Layer
INDIN 2005

10. AE Layer Details
ECM and DCM are used to obtain a flexible re-configurable implementation scheme for event and data connections.
Each FB Container provides the execution context for one or more FB Instances.
Favors run-time re-configuration.
provides the deployment and re-deployment services of the AE Layer
enables dynamic loading and management of FB Types.
INDIN 2005

11. A real-time Linux Execution Environment
RTLinux
was adopted in our first prototype implementation
GPL version of RTLinux does not support user space programming.
RTAI (modular Hard RTOS based on Linux).
Allows user-space programming through LXRT
User threads have 2 modes of operation:
Soft RT → LXRT API & Linux system calls allowed.
Hard RT → Only LXRT API calls are allowed.
A thread can change operation mode anytime while keeping the same address context.
Is based on a Microkernel Architecture
Small HRT kernel handles RT tasks while Linux kernel runs as its lowest priority task (it operates transparently through a virtual interrupt mechanism).
Uses Priority based scheduling
INDIN 2005

12. RTAI Implementation of AE layer
Is implemented as a Soft RT Thread
Passive entity (no thread)
Hard RT Thread(s).
Supports event or time triggered execution.
Multiple event queues allow handling events of different importance. Different event queues are handled by different threads.
One Hard RT Thread per FBContainer.
Event or Time Triggered execution.
Soft RT Thread.
Dynamic FBType loading through standard linux dynamic library loading machanism.
INDIN 2005

13. FB Implementation Meta-Model
Our FB implementation model is based on 2 key constructs FB Type and FB Instance.
Object Oriented implementation alternatives:
Class – Instance relationship.
Tow different classes, with FBInstance class instances being associated to specific FBType class instances.
The more flexible second alternative is adopted.
A FB instance of type B is implemented as an instance of the FBInstance class and is associated with the instance of class FBType that represents the FB type B.
INDIN 2005

14. Implementation meta-model details
INDIN 2005

15. Capturing real-time requirements
Constraints such as end-to-end deadlines from input event MPPs to output event MPPs should be captured during design.
Mechanical Process Parameters (MPPs) are used during application design to refer to actual parameters (event or data) read from or written to the controlled system.
INDIN 2005

16. Event Path Each EP is characterized by: a deadline
a relative priority, that denotes its importance among EPs with the same deadline
Event Path (EP): Denotes an event propagation path from an event source MPP to an event sink MPP through finite number of FBs within a FB Network.
INDIN 2005

17. Assigning Scheduling parameters
EP parameters are utilized to produce runtime priorities for FBs (FBContainers) and Events.
FBC
Event Output
Name
Prior. A 1
A.E1 B
B.E2 C
C.E3 D 2
D.E4 3
D.E5 E
E.E6 F
E.E7
Deadline Monotonic Like
Algorithm EP DL
Rel. P
Final P #1
5ms 1 #2
10ms 2 3 #3
Tables show the corresponding parameters for the FB network presented in the previous slide.
INDIN 2005

18. Application Deployment Process
Download FBTypes
Internet
FBType2Linux DLL interpreter utilized the constructed FBType models to automatically produce source code of dynamic loading libraries used for downloading FBTypes to devices.
A cross compiler is needed along with a part of the “RTAI Application eXecution Environment Implementation Framework” to produce the binary files of the DLLs.
FBNetwork Deployer utilizes the constructed FBNetwork model (topology aspect) to perform the downloading of FBTypes to specific devices.
INDIN 2005

19. Application Deployment Process
Create FBInstances and inject them to FBContainers.
Set priorities of FBContainers.
Internet
FBNetwork Deployer utilizes the constructed FBNetwork model (topology aspect) to issue commands to devices so that FBInstances and FBContainers are created.
INDIN 2005

20. Application Deployment Process
Create event & data connections
Intra-device
Inter-device
Internet
FBNetwork Deployer utilizes the constructed FBNetwork model (topology and connectivity aspect) to issue commands to devices so that intra-device and inter-device event/data connections to be established.
INDIN 2005

21. FBType DLL Generation …
class FBType_TEST_FB : public FBType {
private:
static void algINIT(void *fbi) {
FBInstance *fb=(FBInstance*)fbi; }
static bool cond_START_TO_INIT(void *fbi) {
return GET_IE_INIT;
public:
FBType_TEST_FB() {
//The constructor properly initializes FBType
//class attributes.(FB interface, Internal
//Variables, FB ECC, etc.) };
extern "C" {
FBType* FBType_factory(void) {
return new FBType_TEST_FB();
The FBType DLL defines a new class that extends the basic FBType class.
FB Type algorithms and ECC transition conditions are mapped to class methods.
Class constructor initializes FBType class attributes that describe the FB type interface, the internal variables and the ECC.
INDIN 2005

22. Performance Metrics Definition
Key metrics definition is based on FB ECC operation state machine:
Sample inputs = f(#input_data, #input_events)
Evaluate transitions = f(#transitions, condition_complexity)
Perform actions = f(#actions, algorithm_exec_time)
Write output data = f(#output_data)
Issue generated events = f(#gen_events, #connections)
Based on the ECC state machine defined by the standard the following key metrics are defined:
“Sample Inputs” operation (that is performed during transition t1 when an event is received) delay which is affected by the number of event and data variables to be sampled (the sizes of variables may also affect the measurement but we assume all variables have the same size).
“Evaluate Transition” operation (that is performed in state s1) delay which depends on the number of transitions associated with the current FB ECC State and the complexity of each transition condition expression.
“Perform actions” operation (that is performed in state s2) delay which depends on the number of actions to be performed and the execution time of algorithms associated with the performed actions.
“Write output data” operation (that is performed during transition t4) delay which depends on the number of output data to be written ( and their sizes which is assumed to be all equal).
“Issue generated events” operation (that is also performed during transition t4) delay. First of all this measurement is affected by the number of generated events and secondly by the number of connections that each generated event participates.
INDIN 2005

23. Performance Metrics Environment
P4, 3GHz, 512 MB SDRAM (cache enabled)
RTAI 3.1
Linux kernel (SMP disabled)
Assumptions:
All data 4 bytes long
Negligible complexity of transition condition expressions
Actions: 1 dummy algorithm & 1 generated event
Only one event is delivered to FBs for each activation
Measurements made by high priority threads to avoid preemption
INDIN 2005

24. Performance Metrics Results (1)
INDIN 2005

25. Performance Metrics Results (2)
INDIN 2005

26. Performance Metrics Results (3)
INDIN 2005

27. Performance Metrics Results (4)
INDIN 2005

28. Performance Metrics Results (5)
Local event connection latency:
Is the difference between the time an event is delivered to the destination FB (one connection only) and the time that this event is generated.
Includes the overhead imposed by ECM (Event propagation delay within ECM), event queues and signaling mechanisms
Maximum local event connection latency = 15μS
INDIN 2005

29. Performance Metrics Result Evaluation
Results of time measurements depict:
the efficiency of the proposed execution environment
local event connection latency 15μS of which just 2,6μS is the propagation delay within ECM
while one shot timer setup time as reported by RTAI is 2μS
the predictability of the execution environment
all measurement indicate that execution time is linearly affected by the variable parameters
INDIN 2005

30. Teabag Boxing System case study
An example control application of TBS based has been developed to:
demonstrate the applicability of the proposed approach
test the efficiency of the proposed execution environment and FB implementation model
test re-configurability of the proposed execution environment
The example application can be downloaded on request from
INDIN 2005

31. Teabag Boxing System case study
Conveyor-1 belt-1
Conveyor -2
Conveyor-1 belt-2
Scale
INDIN 2005

32. Conclusions The proposed FB implementation model :
offers great degree of flexibility
supports dynamic runtime loading of FB types in any OO language.
The proposed execution environment:
allows run-time reconfiguration
offers real-time predictability (RTAI)
The adopted application development process:
supports Model Driven Architecture
allows real-time requirements capturing during application design
enables automatic transformation of design model to implementation model and semi-automatic application deployment
INDIN 2005

33. http://seg.ee.upatras.gr/MIM/ MIM & Archimedes web site
A Real-Time Linux Execution Environment for Function-Block Based Control Applications
MIM & Archimedes
web site
INDIN 2005