To overcome the limitations of current embedded industrial automation and control engineering methods, an application centred engineering method was developed for efficient component based modelling of applications for controlled evolution of industrial automation and control systems and their execution. The method focuses on replacing state-of-the-art "ramp down—stop—download—restart—ramp up" with a simple continuous system evolution, which is controlled by an evolution control application that is modelled with components in the same way as control applications. Evolution control can be either executed from an engineering environment or—if constraints regarding fault tolerance, real–time and safety have to be met—it can be distributed to different controllers (as shown in the following figure).

Evolution control applications for downtimeless system evolution

Unfortunately, the process of reconfiguring an automation system without downtimes sets high demands on the underlying concepts and methodologies. Applications of the automation system have to work without disturbances; the reconfiguration process has to be adapted to the special environmental conditions of the affected application part. Any failure during the reconfiguration process has to be managed at least to such a degree, that the system is left in a defined state. The standard IEC 61499 already includes basic management services for configuration and reconfiguration of applications. The major work was the extensions to the IEC 61499 management model and a new application centred engineering method, enhancing the reconfiguration abilities of IEC 61499 with special regard to remaining compliant to the ideas of the IEC 61499 standard. To reduce the complexity of the reconfiguration, the following engineering workflow was proposed. This workflow is a cyclic process of evolution steps. Every step consists out of four major parts as depicted in the following figure:

Engineering process of a system evolution

1. Acquire Current System State (Acquire existing application):Collect all data necessary for describing the current system state and deliver it as input to the application modelling. The data consists of the system model including applications currently running in the system, the hardware configuration of the system (used devices and network structure), the mapping of the applications to the different devices and the hardware capability descriptions.
2. Model New Control Application (Application Modeling): Modelling of the new control application based on the existing ones by adding/removing components, their interconnections and specification of application properties (e.g.timing constraints). The next step is the configuration of the hardware structure with devices and network connections. After this the modelled application parts are mapped to the according devices they should be executed on. The final step is the verification and validation of the control application in order to determine if the specified constraints will be met.
3. Model Evolution Control Application (Evolution Engineering): With the Delta Analysis differences between the current running control application and the newly modelled control application are determined. These differences serve as input and starting point for the modelling of the evolution or reconfiguration control application that will change the existing application to the new one. The reconfiguration control properties and parameters are specified in the same way as control application properties (according to step 2). Similar to the mapping of the control application the evolution application parts are mapped to the devices. The final step is the verification of the evolution control application together with device capabilities in order to determine if evolution constraints will be met and the running application is disturbed as less as possible.
4. Execute Evolution Control Application (Execution of System Evolution): To execute evolution control applications the utilization of basic reconfiguration services at runtime platforms based on IEC 61499 management commands is necessary. The first step is to instantiate the evolution control application on the according devices. Next the execution of the evolution control application is done, i.e. the currently running control application is transformed into the new control application. This is achieved through basic reconfiguration services proving real–time constraint execution of reconfiguration processes at device level. The main services are:

• Control application component
• Load/remove
• Connect/disconnect
• Query parameters
• Write parameters
• Query component state
• Write component state

To finish the evolution procedure the evolution control application will be removed after it has successfully executed all commands and all changes are finished.

In order to easy the evolution engineering a structuring method for evolution control applications was introduced. The basic elements of this new method are so-called Evolution Region(s) of Interest (EROI) which are the specific part of an IEC 61499 application were the reconfiguration will take place. The  reconfiguration in an EROI is encapsulated in a special IEC 61499 Evolution Execution Control Function Block (EECFB). This means that the evolution process can be described using EECFBs for each reconfiguration step in an EROI forming an evolution control application (as depicted in the following figure).

Evolution Control Application modelled via EECFBs

Using the EECFBs for modelling and execution of evolution control application(s) the evolution process can be controlled using the following three phases:

• Initialisation of reconfiguration steps (RINIT),
• Reconfiguration of EROIs (RECONF), and
• De-initialisation of reconfiguration steps (RDINIT).

The Control Modelling Language (CML) provided by IEC 61499 provides models for systems, device configurations, mappings and a component based application model. Furthermore the standard provides also a basic reconfiguration support true the device management model. During the εCEDAC project the above mentioned standard was used for modelling of distributed control applications. The Evolution Control Modelling Language (εCML), which was introduced in εCEDAC, is an extension to this CML and covers a new language for component and system descriptions for modelling system evolution. Based on the management model introduced by IEC 61499, the following set of basic reconfiguration services were identified and categorized:

• Structural Services: these services modify the structure and the behaviour of the control application. IEC 61499 provides already a sufficient set of services that allow to create and delete FBs, resources and connections and to write parameters of function blocks and resources.
• Execution Control Services: these services allow interaction to take place with the currently executing control application. IEC 61499 provides start, stop and kill mechanism for function blocks. eCML extends these services with an additional restart service.
• State Interaction Services: with these services one can retrieve and set the internal state of FBs. Within IEC 61499 no clear definition is made on these services.
• Query Services: to acquire the current state of the overall control system, these services are needed. The query mechanisms provided by IEC 61499 can serve as a basis for these services.
• FB Library Services: these services allow adding or deleting function blocks to the function block library of an embedded control device, which can than be used by the structural services. IEC 61499 does not clearly define these services.

For the evolution engineering the identified services are modelled in separate IEC 61499 function blocks (see Figure 2.7). The collection of these new defined function blocks form the eCML and enables low-level reconfiguration of distributed control applications.

εCML modelled as special IEC 61499 function blocks

Hardware description is closely related to communication aspects within industrial automation systems. Niemann [K.-H. Niemann, “Stand der Integration intelligenter Systemkomponenten in die Prozessleittechnik”, Automatisierungstechnische Praxis (atp), Ouldenbourg Verlag, Vol. 49, Nb. 5, pp. 15-20, 2007] provides an overview of the different techniques such as GSD files for Profibus, the IEC 61804 standard and the EDD language, but also tool integration approaches, such as FDT or TCI. In general, these heterogeneous approaches focus on one special communication protocol and its capabilities. A quite different approach is available called Field Device Configuration Markup Language (FDCML). The FDCML provides a meta-language for the description of any device and its capabilities. Schwab et al. [C. Schwab, M. Tangermann, L. Ferrarini, "Web based Methodology for Engineering and Maintenance of Distributed Control Systems: The TORERO Approach", Proceedings of IEEE Int. Conf. on Industrial Informatics (INDIN’05), 2005.] describe the use of XDDML, the predecessor of FDCML, for enhanced engineering support in the TORERO approach.

The general structure of the FDCML is compliant to the standard ISO 15745 (open system configuration) and covers four different aspects within the device description (see the following figure, left bottum): DeviceIdentity (general information about the device), DeviceManager (interface situation, communication possibilities and resource capabilities), DeviceFunction (inherent functionality) and ApplicationProcess (the application located on the device). Furthermore, also groups of devices (i.e. modular devices) can be described. The standard IEC 61499 defines a system model capable of describing a distributed automation system from the applications point of view. The following figure (left, top) depicts the main elements of an IEC 61499 system: Applications (function block (FB) networks), Devices (IEC 61499 execution environments) and their location within the distributed system (Mapping of FBs to devices and a simple representation of the network connections: Segment, Link). Including the IEC 61499 models into the basic meta-model provided by the FDCML yields to the εCEDAC Hardware Capability Definition (HCD). The bold arrows in the following figure (left) describe this interrelation. The FDCML provides a detailed description of all interfaces of a device, which can be used within the control program. The IEC 61499 device provides the capability of execution of control logic. Therefore, the runtime capabilities are part of Device-Manager, such as the Library Elements and Data Types. But this may include even more than pure IEC 61499, for instance also a description of the formal models for these elements may be included. The FB networks within the device are part of ApplicationProcess. The inherent functionality of the device can be described by the Service Interface FBs in IEC 61499, which can be part of DeviceFunction. Again, the pure IEC 61499 descriptions may be enhanced by more detailed information. The connections of devices within the network are already part of the FDCML model, the mapping of FB networks to applications can be restored from the information within ApplicationProcess. The εCEDAC HCD includes all information available about the distributed automation system, its devices and applications. This summary of information is the so-called KAPPA vector in εCEDAC. The KAPPA vector characterizes the current system state. It can be considered for the overall system, one device or only a special point of interest.

Interrelation between FDCML and IEC 61499 (left), Integration of hardware information into the device view (right)

By use of the HCD the engineering of system evolution becomes efficient, because a huge amount of needed parameter will be provided by the vendor of the hardware devices, imported into an engineering environment by use of the HCD. The above figure (right) gives an overview of the handling for the user. On the one hand, the users have to model the control and evolution control applications in the usual way (upper part). On the other hand, he can describe the system configuration by putting the appropriate HCD files together (lower part). There may be some parts, consisting of several hardware devices, which are provided as one file. After this step, the IEC 61499 devices can be located to the hardware devices. At this point, the system configuration of an IEC 61499 system has been established. The only missing point is the mapping of the application(s) to the devices (middle part). If a formal verification should be provided, the engineering environment is capable to find all necessary parameters within the enhanced system model. And of course in case of an evolution control application, it can collect all needed parameter for the verification of the system evolution.

As mentioned above the IEC 61499 reference model for distributed automation systems was used in εCEDAC. The standard includes a system model, which builds the basis for the εCEDAC approach. The main items of this system model are:

• Identification and VersionInfo: These elements are used to determine a label of the current system.
• Application: One central element of IEC 61499 systems are applications. There may be several applications modelling the behaviour of the control logic of the system. An application consists of a function block network, which is described by its FBs and their event, data and adapter interconnections. The application has no interrelation to a device.
• Device: The second central element of IEC 61499 systems are devices. These devices may include resources that again include a FB network.
• Segment and Link: Theses elements provide a documentation of the network architecture of the overall system. Devices are connected to segments by links.
• Mapping: This element provides the interrelation between applications and devices. An application may be distributed to several devices. This mapping is documented within this element.

Based on the IEC 61499 an enhanced system model was developed in εCEDAC in order to perform the evolution of distributed control application and to formal verify the evolution steps. The modified system model is depicted in the following figure. According to the evolution engineering method there exist evolution control applications that have to be included in the system model. As described above, several EECFBs may be applied in an evolution control application. The EECFB itself contains the reconfiguration application necessary for downtimeless changes within the corresponding EROI. Another important aspect missing in the system model of IEC 61499 regards to the hardware, which executes devices. The IEC 61499 device is an instance of a standard compliant runtime environment. Therefore the hardware itself is not mentioned within the system model of IEC 61499. One main point within the downtimeless evolution of systems is that one has to be sure that the new application will work properly. This can be done by simulation (as it is applied in state-of-the-art automation systems) or by means of formal verification. In εCEDAC the formal verification approach was used. In order to perform the formal verification an extension to the system model regarding the description of hardware devices was necessary. Therefore in εCEDAC the term hardware was introduced (see following figure) into the system model.

Enhanced IEC 61499 system model

In order to describe the capabilities of the hardware devices a Hardware Capability Description (HCD) was developed (see above). The εCEDC HCD in general is related to one hardware device. A hardware device is a piece/unit that can be put into the system configuration. For instance, an embedded controller is such a piece of hardware. A programmable logic controller (PLC) with one processing module and several input/output (I/O) modules are several hardware devices. The reason for this is that the configuration can be changed very easily and also an I/O module may include some processing power. The basis for the εCEDAC HCD builds the Field Device Configuration Markup Language (FDCML), which has been defined for the use in field bus devices. This basis was used in εCEDAC to describe the capabilities of hardware devices (see following figure).

εCEDAC Hardware Capability Description (HCD)

The KAPPA vector can be the basis for a huge amount of engineering support within an automation system. The following figure includes the εCEDAC evolution cycle with additional hints on the advantageous use of the KAPPA vector within the engineering process.

Application of the KAPPA calculus within the εCEDAC engineering cycle

In detail, there is no step within the evolution engineering that does not benefit from the KAPPA vector. These enhancements are provided by calculations on the KAPPA vector, yielding necessary information and parameters. Therefore, these calculations are called KAPPA calculus in εCEDAC. The following list provides an excerpt of possible KAPPA calculations:

• Acquire existing Application: The purpose of this step is to get a picture of the current situation of the automation system. The KAPPA vector of a device can be used to identify the device by an ID and load e.g. the description from the hardware vendor. The application dependent part has to be loaded directly from the devices. By use of the KAPPA vector, the correct way of interacting with the device can be loaded from the description, e.g. supported compliance profiles in case of IEC 61499.
• Application Modelling: When modelling an application, the concrete hardware is not known before the mapping. But of course the use of an I/O interface will be visible, although the concrete SIFB necessary for the device is an open point. Within the engineering environment, a generic SIFB for the interfacing of a digital input, digital output, analogue input and output can be used instead of concrete instances.
• Also in case of the communication, the engineering tool is able to support the user to a great extend by use of the KAPPA vector. The situation is quite similar to the process interface. The only difference concerns to the way, communication occurs in the application-centred engineering paradigm. Communication is not visible within the application explicitly. As soon as the mapping has happened, the different application fragments are visible within the devices, but the communication has to be added afterwards.
• A first version of KAPPA vector based tool support is quite similar to the approach presented above. The tool can analyze the communication relations that are necessary because of the mapping. Of course, the tool can not decide which kind of communication and which protocol should be used. But the tool can provide generic communication SIFBs that are visible within the devices. There is also another possibility for better support within the application-centred engineering paradigm can start at an even higher level. After the mapping of the FB network, an engineering tool can provide this information about the borders of the devices within the application view. The user may just want to specify the quality of these connections, and the tool can automatically insert the necessary communication SIFBs.
• Evolution Engineering, Verification: Correct verification of the evolution process requires information about the devices, the runtime environments, the FB types, the applications etc. The KAPPA vector provides the database for all these information. For instance, the real processing time of the execution of a FB instance is needed within the verification process. A more detailed description of this topic is given below.
• Execution of System Evolution: The KAPPA vector can provide the information necessary for interfacing devices, e.g. supported compliance profiles in case of IEC 61499.

For the verification of downtimeless system evolution, different rules can be applied that enable a decision whether a reconfiguration step will be possible or not. The following rules have been developed within εCEDAC in the context of the KAPPA calculus:

• Logical order rule: A reconfiguration application includes different FBs that capsule management commands. Therefore, the current system state changes dynamically. Possible failures regard to a mismatch of the management command and the current system state. The changes of the KAPPA vector can be calculated offline by “simulation” of the evolution control application and failures within the logical order of the management commands can be detected.
• Type consistency rule: The creation of new FB instances requires the availability of the corresponding FB types. The eCEDAC HCD enables the check of the evolution control application with regard to the KAPPA vector.
• Memory rule: Different management commands require a certain amount of memory or release memory. Again a calculation can be applied about the amount of necessary memory as well as its structure (memory consumption of the single commands) and enable a check or at least a rough estimation of the correct execution of the reconfiguration application.
• Computational power rule: This rule includes a calculation about the behaviour of the reconfiguration application as well as the current application within the device with regard to the computational power. This may be simple in the case of cyclic execution, but the event driven nature of IEC 61499 complicates such a check. Therefore, a formal verification including physical time is necessary. For the R(D)INIT sequence, a rough estimation is possible with regard to the capabilities of the runtime environment and its execution platform based on the eCEDAC HCD.

The general situation for verification of system evolution is depicted in the following figure.

Scope for the εCML safety proofing

There is an evolution control application (or reconfiguration application) which is responsible for changes within control applications. The logic of the system evolution is modelled within the evolution control application with the same means as already used for the control tasks. The interrelation between these two applications is twofold. First, the evolution control application is able to influence the control application by use of management commands, which provide changes in the control application (e.g. instantiation of a function block). Second, the evolution control application gets aware of the current system state based on the data and event connections from the control application. This enables an appropriate behaviour of the evolution control application, e.g. for synchronization with a control sequence.

The methodology for the verification of system evolution has to be coupled very tightly to the engineering methodology. The evolution control application consists of three characteristic sequences that are performed sequentially. Accordingly, the verification strategy is split into three parts as shown in the following figure:

• RINIT Sequence: Within the starting phase the needed function blocks and connections necessary for the controlled reconfiguration of the control application are instantiated and initialized. During this sequence the control application will not be influenced in any way; only its environment is prepared for the next sequence. Especially there will be no time critical operations during this phase. Therefore, the verification process depends on static parameters only, such as free memory available for new function blocks and connections etc. The verification can be done by a rulebased check
• RECONF Sequence: This is the really critical part during the evolution step. The verification process is split up into two parts: On the one hand, the static parameters can be checked by application of rules in the same manner as for the RINIT sequence. On the other hand, the correctness of the reconfiguration logic with regard to the control application needs to be checked. Therefore, also the reconfiguration logic itself needs to be modelled within the formal description (see below).
• RDINIT Sequence: The third step is characterized by the deinitialisation and deletion of the FBs and connections that are no more needed. The characteristic is the same as already described for the RINIT sequence. The verification can be done by a rule-based check.

Methodology for the verification of system evolution

The models of the reconfiguration logic have to face the specific problem that a dynamic architecture (reconfiguration within IEC 61499) needs to be mapped to a static description (the formal models). There are no constructs available, which are capable to dynamically (during the analysis of the model) change the model. Therefore, the needed structures have to be available and are only activated/deactivated during the analysis of the model. For general consideration, this would become very complicated. But due to the structured and very limited range of the reconfiguration within the εCEDAC approach, this methodology can be handled. During the project, the following reconfiguration services have been modelled:

• Read and write of variable, especially also internal variables of FBs
• Creation and Deletion of event and data connections.

Further reconfiguration services do not need to be modelled with regard to their physical effects, such as starting / stopping of FBs or creation and deletion of FB instances. Here, the pure execution time is sufficient. Therefore, the εCML safety proofing can be applied by adding the formal model of reconfiguration applications to the overall system.

© The εCEDAC Consortium