IEEE Int. Conf. on Emerging Technologies and Factory Automation, (ETFA 2001), French Riviera 2001 “©2001 IEEE. Personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution to servers or lists, or to reuse any copyrighted component of this work in other works must be obtained from the IEEE.”
Field Device Specification for the Development of Function Block Oriented Engineering Support Systems K. Thramboulidis, A. Prayati Electrical & Computer Engineering University of Patras,26500, Patras, GREECE
[email protected]
Abstract – The Function Block (FB) concept is proposed by evolving standards to address most of the problems encountered in the development process of distributed Industrial Process Measurement and Control Systems (IPMCS) applications. To increase modularity, reliability and expandability of FB-based IPMCS applications as well as to automate the development process and increase reusability, new generation FB-oriented Engineering Support Systems (ESS), are highly required. These ESSs should be able to exploit FBs provided by intelligent field devices, which are expected to appear in the market in the near future, and also assign functionality to the great number of different field devices that already exist in the market. A common field device model is strongly required to accomplish both the above tasks. In the context of this work, we consider the requirements for the field device model imposed both by the development of the FB-oriented ESSs and the demand for device interoperability during the fieldbus operation phase. We use the Unified Modelling Language (UML) to proceed to the definition of the field device model. This model, combined with our 4-layer IPMCS architecture, constitutes a framework that facilitates the development of open FB-oriented ESSs.
network of interconnected primitive FBs, composite FBs and subapplications. New generation FB-oriented Engineering Support Systems (ESS), are highly required to support the whole life cycle of these IPMCS applications [4]. An ESS must support the engineer, in both the analysis and design phases as well as in the implementation phase. Using such a system, the engineer must be able to start with the analysis of the plant diagram so as to capture the control requirements. Then, he should be able to define the major areas of functionality and their interaction with the plant. During this task, he should be able, to exploit FBs provided by intelligent field devices such as smart valves, but also to assign functionality into physical resources such as PLCs, instruments and controllers. All the above should be accomplished independently of the underlying communication subsystem even in the extreme case, where it is an aggregation of interconnected fieldbus segments, from different vendors. In the context of the ARTIO project, we have considered the process of interconnecting heterogeneous fieldbus segments and the design and implementation of integrated FB based distributed applications over them. We came up with a 4-layer architecture, which proved to be very helpful during the process of capturing the key abstractions that will become the basis for the development of FB-oriented ESSs [5]. The architecture defines the main directions that an ESS should address and plays a significant role during the ESS’s development phase. Even more, as the needs of industrial environments increase and become more demanding, IPMCSs tend to include field devices of more than one manufacturers. Since these different field devices must interoperate, the need for a common field device description for the simple and userfriendly integration of devices is more than mandatory in today’s complex automation systems. As a result the ESS must allow the application designer to have a global overview of the system and to be able to handle devices of different manufacturers and fieldbuses. We ascertained that the device specification is one of the most important issues in such an approach. Several notations, known as Device Description Languages (DDLs), already support the specification of field devices. We discriminate HART DDL, Profibus device description, Foundation fieldbus DDL and Lonworks DDL. The HART Device Description language, which is the oldest historically, is used for the specification of transmitters and actuators in the process control area [6]. HART does not
I. INTRODUCTION The Industrial Process, Measurement and Control Systems (IPMCS) Software industry increasingly faces today the challenge of creating complex custom-made distributed control systems within time and budget, while high competition forces prices down. In order to address these issues, evolving standards, like IEC 61499 and the more recent IEC61804, define the basic concepts and a methodology for the design of modular, re-usable, distributed IPMCSs [1][2]. According to them, the function block (FB) construct constitutes the main building block of IPMCS applications. The FB, which is defined in a format that is independent of the implementation, promises to improve productivity in terms of reuseability, reliability, flexibility and interoperability. FBs can be used to define robust, reusable software components that constitute the distributed IPMCSs [3]. Even more, to address the alwaysincreasing complexity of modern IPMCSs, constructs like “composite function block” and “subapplication” are introduced. A methodology is also defined, to be used by system designers to construct distributed control systems. This methodology allows systems to be defined in terms of logically connected FBs that run on different processing resources. Complete applications, can be built from
1
International Conference on Emerging Technologies and Factory Automation, (ETFA 2001), French Riviera 2001
fieldbuses, IUs, the backbone communication subsystem and the related interconnections.
include communication parameters since it is directed to 420ma point-to-point wire communications. The Fieldbus Foundation DDL is directly derived from HART DDL. Although it covers the block component, addressing and service details of the device are not considered [7]. Profibus GSD, which is mainly for communication configuration, covers the whole communication capabilities of the PROFIBUS-DP device [8]. Lonworks Foundation provides a LONMARK external interface file named XIF that is a file defining the external interface for the LONWORK device [9]. The external interface includes the device’s selfdocumentation information, the number of address table entries, the number of message tags and the number, types and directions of network variables. It does not expose the internal algorithms of a device; instead, it only exposes the inputs to and the outputs from the algorithms. The above notations are used to represent the properties of a field device in a machine-readable format to be used by the Engineering tool during the development phase of the distributed IPMCS. The specification is also used during the IPMCS’s operation phase. However there is no common model for the device specification and the above notations result in incompatible device specifications. Dynamic aspects of the field devices as well as System Management are not covered by any of the above languages. The need for a field device model seems to be more than imperative. The field device model, presented in this paper, is based on the IEC61499 and IEC61804 standards and adds the required missing aspects that are not covered by the existing models. The rest of this paper is organized as follows. In section 2, we briefly refer to our 4-layer IPMCS architecture. We next, in section 3, analyze this part of the functionality of a FB-based ESS, that is related to the field device. This analysis results in a set of requirements that the device model must address. The proposed device model, that satisfies both these requirements and the ones set by the device interoperability in the operation phase, is presented in section 4. Finally, we conclude the paper in section 5.
Fig. 1. The 4-layer Architecture for the development of ESS.
The third layer, that is called application layer, is used to represent the required constructs used in the design and implementation of IPMCS applications. FBs, data and event connections, Industrial Process Terminators (IPTs), and industrial process parameters, are the key abstractions and correspondingly the main building blocks of the application layer diagrams that are constructed by means of an application layer editor. Finally, the HMI-layer captures all these abstractions that concern the development and operation of SCADA client systems. This layer is not of interest in the context of this work.
III. ESS’S FUNCTIONALITY RELATED TO FIELD DEVICE SPECIFICATION
II. OUR 4-LAYER IPMCS ARCHITECTURE
The design of our ESS that supports the development of FB based distributed applications relies on the above 4layer architecture. The use case driven approach has been used for the requirements specification of ESS that must allow the engineer to:
To proceed with the design and development of an ESS that is required to support the design, implementation, commissioning and operation of IPMCSs, we have defined 4-layer of abstraction to handle the complexity of modern IPMCSs [5]. In order to make the paper self-contained, we refer to this architecture briefly in the following. The bottom layer of this architecture, as is shown in Figure 1, is the real world layer i.e. the actual IPMCS system. It consists of the controlled industrial processes, the fieldbus segments used to interconnect the field devices, the Interworking Units (IUs), the backbone, the enterprise’s intranet, the control room and the engineering workspace. The next layer, that is the system layer, must include the required abstractions, used by the ESS to support the FB’s distribution and assignment process. It consists of appropriate abstract representations of field devices,
• •
•
2
Insert industrial process parameters into the working space in the application layer, so as to properly define the interaction of the control system with the plant. Insert field devices in the system layer. The engineer connects the field devices to the proper fieldbus in the real world layer and makes use of device’s specifications to create device representatives (device proxies) into the system layer. Design the application. The engineer analyses the physical plant and uses FBs, Data and Event Connections, as well as other software constructs to
International Conference on Emerging Technologies and Factory Automation, (ETFA 2001), French Riviera 2001
•
• •
• • • •
represent the key abstractions of the application domain. Design the system. The engineer physically distributes the software building blocks to the available field devices and fieldbuses. Partitioning, assignment and scheduling are among his/her most important tasks. Verify the application. Download the application.
Connect Device Connect FB Assign FB to device Download FB to Device
A. Add Device For a field device to be inserted in the IPMCS system, the following process must be followed. The engineer, working in the real world layer, connects the device to the appropriate fieldbus. He then imports the device specification into the Device type repository, as shown in Figure 2. This device specification, which accompanies the device, is a human readable representation of the device model and is created by the Device Manufacturer using application specific XML tags. The engineer has now direct access to the device specification. Afterwards, the FB-types contained in the device, are imported into the FB-type repository of the application layer. This is required for the device’s FBs to be accessed and used durring the construction of the application’s FB diagram. At the system layer, the designer uses the device icon to insert a device node in the system diagram. This would be the visual representation of the device so it must be bound to the real device. If the device is IEC61499 compliant, the XML device representation is used by the ESS to automatically create a device proxy in the appropriate IU, to implement this assignment. Otherwise, if the device is not IEC61499 compliant but the device type is supported by the ESS, the binding is implemented by means of a wrapper, that is automatically created by the ESS. This wrapper encapsulates the real device and provides an
The higher two layers of the 4-layer IPMCS architecture must be directly assigned to the system layer and this assignment must be invisible to the engineer. The abstract representations of the system layer are in the form of proxies of the actual real world objects in the developer’s workspace. The appropriate system level editor allows the engineer to construct the system design and directly map it to the real-world level. One of the means used to support such a direct mapping is the device specification. This specification should be compliant with a common device model and must accompany the device in a user readable representation such as the one accomplished using XML [10]. Furthermore the ESS must provide all the functionality required by the FB’s distribution and assignment process to the system layer building blocks and mainly to field devices. Actions of the ESS that have no meaning in the application design phase, but refer to the configuration of the underlying communication subsystem must be properly hidden by encryption and encapsulation mechanisms. We next consider this part of ESS’s functionality that highly influences the field device specification. The following ESS services are considered and analysed: • Add Device
XM L file ESS
FB1
Im port F B Type
FB3
{T ime constraints} FB4
Add F B FB2
FB T ype Repository
Application Layer Assign
IPT D1 FieldbusA
S ystem Layer
D3 IU
Backbone
DC T
DCT
D1 Device ECT FB4 Proxy or FB Table W rapper
ECT
IU
D2 Fieldbus B Add Device node
D3 D2 Device Proxy or FB T able W rapper
Im port Device Type Device T ype Repository
FB2
Fig. 2. Using the ESS in the IPMCS application development process.
3
IEEE Int. Conf. on Emerging Technologies and Factory Automation, (ETFA 2001), French Riviera 2001 “©2001 IEEE. Personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution to servers or lists, or to reuse any copyrighted component of this work in other works must be obtained from the IEEE.”
D. Assign FB to device
IEC61499 compliant device to be used during the development and the operation phase. The proxy or the wrapper may be considered as the machine-readable representation of the device through which the engineer, in order to configure the device, has direct access to its parameters and operations. As is shown in Figure 2, device proxies are created for the device nodes D1, D2 and D3 in the corresponding IUs. This is the last step for the implementation of the device’s visual representation binding to the actual field device. We consider the process of accessing the real device through the ESS, as a task carried out in two steps. In the first step, the ESS calls the required service of the wrapper or device proxy, using the available API. In the second step, the wrapper or device proxy uses the specific fieldbus communication mechanism, in order to propagate the service request to the real device.
This service allows the distribution of the application layer FBs to the target system resources. FBs are assigned to the devices of the system diagram. In Figure 2, we depict the assignment of FBs to the system layer devices. We discriminate the following cases in the assignment process: 1.
The downloaded FB is connected to one ore more FBs of the same device. This is the case of function blocks FB1 and FB2 that are assigned to device D3. If the device is IEC61499 compliant the assignment is straightforward. However, if the device is not compliant, the wrapper is responsible to provide the illusion of an IEC61499 compliant device. The FB is assigned to the real device but it is actually downloaded in its wrapper, overcharging the IU. This case is quite similar to the one below, where the Control Application (CA) is assigned to the IU.
2.
The downloaded FB is connected to one ore more FBs assigned to other devices in the same fieldbus. This is the case of function blocks FB2 and FB3 that are assigned to devices D3 and D2 respectively. The ESS should automatically implement the interconnections between these FBs on top of the communication mechanisms of the fieldbus “B”.
3.
The downloaded FB is connected to one ore more FBs of the CA resident in the fieldbus’ IU. In this case, which is not shown in Figure 2, part of the functionality of the control system is assigned to the IU. The IU’s interconnection mechanism should be updated by the ESS and its interprocess communication mechanisms should be properly used to implement the connections.
4.
The downloaded FB is connected to one or more FBs assigned to devices of other fieldbuses. This is the case of function blocks FB2 and FB4 that are assigned to devices D3 and D1 respectively. The IU’s interconnection mechanism should be properly updated by the ESS and the communication mechanism of the Backbone should be transparently used to implement the connections.
B. Connect Device We consider two approaches for the connection of a device with the controlled industrial process. Firstly, according to the bottom-up approach, the engineer working in the real world layer connects the device connection points with the measured or controlled parameters of the controlled industrial process. Following, in the system layer, he uses the Industrial Process Terminator (IPT) construct to represent the source or sink of the measured or controlled parameters. An arc, between the node’s connection point and the IPT, represents the real physical connection in this layer. Secondly, according to the top-down approach, the engineer working in the application layer uses the IPT construct to represent in the FB diagram, the source or sink of the measured or controlled parameter. An arc, that is used to connect the IPT with the appropriate FB, carries the information regarding the corresponding industrial parameter. Each arc should be implemented in the real world layer after the assignment of the corresponding FBs to the system layer devices. The ESS should perform compatibility checks regarding the FB input/output types and the device’s connection point specifications. The knowledge required by the ESS to support this operation should be provided by the device specification. This knowledge includes the number of connection points per device, their type i.e. analogue or digital, their range, units, transmission rate etc.
According to the IU’s architecture presented in [5], the interconnection mechanism of the IU is based on a set of connection tables (ECTs, DCTs), which keep information for the data and event connections that cross the fieldbus boundary. In the above cases 3 and 4, these connection tables should be automatically updated by the ESS, to discharge the control engineer from the communication mechanism details. It is evident that the assignment of a FB may imply more than one of the above cases of connections. During the assignment of each FB of the application diagram to the system diagram devices, compatibility checks must be performed automatically and transparently
C. Connect FB FBs in the application layer are connected by means of event or data connections. Time constraints must be defined and included in the FB diagram. The engineer has to take into account these constraints during the step of distribution of the FBs to the system diagram. These constraints are also used by the ESS that translates them into priorities, to define the scheduling attributes later in the development process.
4
International Conference on Emerging Technologies and Factory Automation, (ETFA 2001), French Riviera 2001
the device by the network. Communication services, like the ones defined in the Network interface class, are considered relatively to the Fieldbus’ network services. Apart from the network-related attributes that are important for the device management, an extensibility mechanism is provided for the representation of additional characteristics, which differentiate one fieldbus from another. The device model may be considered as a metamodel from which, the specific device model would be derived by instantiation. Through the User Defined Parameter class, the user is able to define specific device attributes that have a meaning only for the specific type of commercial fieldbus and are not captured by the device metamodel. This class covers the requirement, imposed by the analysis of the “Add Device” service of the ESS, for the particular attributes that a wrapper should have. For example, Lonworks defines domains and subnets for the structure of the fieldbus. These issues do not exist in Profibus but should be supported by the device model for the description of the Lonworks devices. For user-convenience reasons, the specific parameters of every type of fieldbus, are described by the device’s type and are thus provided automatically by the model. The Resource class is used to represent the device’s processing units. A resource, as defined in IEC61499, is a functional unit, which has independent operation control and provides various services to applications, including the scheduling and execution of algorithms. In order to handle the device behaviour as far as NIU, MPU, IPU are concerned, a group of configuration methods should be provided. These constitute the second quadruplet of operations in the Device class. These operations together with the AME class form the management group that is for the FB and resource handling. To specify the requirements imposed by the “Assign FB” service of the ESS, the Function Block class contains attributes like priority, scheduling turn and time bound. These attributes are set during execution of the “FB connection” service of the ESS, based on the time constraints defined on the application layer diagrams. A FB may be predefined or downloaded, depending whether it is included in the device by the manufacturer or defined by the designer during the application development phase, respectively. The FB is of a specific type, which is either imported in the FB type repository, when a new device is added to the system layer diagram or defined by the designer. The ESS and the Function Block classes provide services for the creation, deletion or downloading of FBs. Compatibility checks on the downloaded FBs and the target device should be supported by the ESS and are facilitated by the two latter self-test operations of the Device class. These checks are applied for compatibility of the connection points and FB connections. The connections among FBs are defined by means of the source and destination of the connection. A Connection may be a Data Connection or an Event Connection depending on whether the associated item is data or event. As pointed out earlier in the analysis of the “Connect FB” service of the ESS, the communication mechanism and the time constraints play an important role during the
to the user. The proper scheduling of the FBs’ execution is mandatory to meet the requirements imposed by the realtimeliness. Therefore, the time constraints and the priorities assigned to each FB, will be used by the ESS for the definition of the FB’s scheduling policy. E. Download FB to Device This service is used to download the FB diagram to the target system. The service should be executed automatically by the ESS, after the assignment of the FB diagram constructs to the system layer has been successfully completed. For each FB or group of FBs assigned to the same device, the ESS produces the proper code and downloads it to the corresponding real device, through its proxy or wrapper. The required code and parameters for each connection are also automatically implemented and downloaded to the corresponding real world devices. It must be noted that the wrapper encapsulates the specific communication mechanisms supported by the fieldbus.
IV. THE PROPOSED FIELD DEVICE MODEL The above analysis of the ESS functionality adds extra knowledge to the device model we have created to support device interoperability in the operation phase. Our model was extended to support both the development and the operation phases of an IPMCS application. In Figure 3, we present part of this model that is constructed using the UML notation and the Rational RT-Rose case tool [11]. According to this, a device is of a specific type and is considered as an aggregation of a Network Interface Unit (NIU), one or more Resources, an Industrial Process Interface Unit (IPU) and an Application Management Entity (AME). For the device identification a set of attributes such as the device’s serial number, a device ID in the system, a device address in the fieldbus, the type of the device, is provided along with operations like “Identify”, “UniqueTag”, “SetDeviceTag” and “GetDeviceTag”. These four methods are provided by the Device class and allow the designer to identify the device, as well as to get a unique reference to it. The IPU class is used to represent the interface mechanism for the connection of the devices to the IPTs. This interface includes several Connection Points each one defined to have attributes that cover the requirements of the “Connect Device” operation of the ESS class that represents the Engineering Support System in our class diagram. Such attributes are: the type, which would be analogue or digital and the direction, which would be input or output. Each industrial process parameter may be connected to one or more connection points. Connection points may be connected to one or more FBs inside the device. Knowing the device’s connection point types, the engineer can decide whether the downloaded FBs are matching the device capabilities. The NIU class is used to represent the addressing and communication mechanisms provided for the handling of
5
IEEE Int. Conf. on Emerging Technologies and Factory Automation, (ETFA 2001), French Riviera 2001 “©2001 IEEE. Personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution to servers or lists, or to reuse any copyrighted component of this work in other works must be obtained from the IEEE.”
Resource
ESS
Resou rceID : undefi ned
Connec tion source : undefined Destination : undefined TimingConstraints : undefined
AddDevice() DeleteDevice() AddFB() DeleteFB() Configure() ConnectDevice() ConnectFB() AssignFB() DnlFB() CheckCompatibility()
Confi gure() Ini t() SetResourceID () StartResource() StopResource() SetFBi nR es()
Application Management Entity
SetConnection() GetConnection() SetTimeBound()
Event Type ScheduleFB() Creat eFB() Delet eFB() StartFB() StopFB()
EventConnection
Event Item Type : unde fi ned
Device Se ri alNo : i nteger DeviceID : und efi ned Type : boolean
1..*
Downloaded FB n ame
Identi fy() UniqueTag() Se tDevice Tag() GetD eviceTag() RetrieveDefa ultConfig() Rea dAvai lable FB() Se tUserConfig() Se tVen dorConfi g() Se lfTest(Devsta tus) Che ckD eviceID ()
Device Type Name : undefined
1..*
User Defined Parameter Name : undefined Value : undefined Slave : undefined Domain : undefined Subnet : undefined
It em AvTrRate : undefined MaxTrRate : undefined Polling : boolean
FB Type
Function Block
Che ckC om patibi lity()
priority : undefined SchedulingTurn : undefined TimeBound : undefined FBID : undefined SetPriority() Assign(Device ID) SetScheduling() SetTimeBound() StartFB() StopFB() GetFBType()
Predefined FB
1..* Industrial Process Interface
Data Item range : undefined units : undefined DeviceID : undefined NoConPoint : undefined
Network Interface NodeAddress : undefined Protocol : undefined OperationMode : undefined GetAddress() SetAddress() ClearAddress()
1..*
ConnectionPoint Type : undefined Input/Output ID(No) : unefined RangeSamplFreq : undefined TimeForBroadcast : undefined
DataType
DataConnnection
read() write() InitData() SetRange() SetOffset() SetAlarmLevel() SetWarningLevel()
Fig. 3. Part of the field device model
of different field devices that already exist in the market. This imposes the need for a common field device model. For the definition of a common device model, we have examined filed device requirements in both commercial implementations as well as evolving standards. We have considered the requirements of both the development and the operation phases of distributed IPMCS. We were guided to a UML device model capable of representing both the dynamic and static aspects of field devices. The device model presented in this paper provides a formal device representation which fulfils the requirements of nowadays’ IPMCS. IPMCS’s development process is simplified by hiding complexities associated with field devices. The field device model was also constructed for the ESS to be able to provide the functionality required by the FB’s distribution and assignment process to the system layer building blocks and mainly to field devices. Information hiding of those ESS’s actions that have no meaning in the application design phase, but refer to the configuration of the
automatic implementation of the connections for the required response times to be achieved. Letting the choice to the engineer to specify the communication mechanism of the FB connection, could be a design trade-off.
V.
CONCLUSIONS
For the development of a FB-oriented ESS, we have designated four layers of abstraction and constructed a 4layer architecture. We have found this architecture very helpful in the process of capturing the key abstractions that will become the basis for the development of the FBoriented ESS. The 4-layer approach, together with the distinction of FBs to elementary and composite and the subapplication concept, constitute a solution to address the complexity of IPMCSs. These systems should enable the engineer both to exploit FBs provided by smart field devices and also to assign functionality to the large number
6
International Conference on Emerging Technologies and Factory Automation, (ETFA 2001), French Riviera 2001
underlying communication subsystem, was of primary concern. To validate our device model we are now in the process of implementing device specifications for Profibus and Lonworks fieldbuses. We hope this work will help to the direction of developing interoperable IEC 61499-compliant ESSs that will provide the industry with the ability to utilize heterogeneous software environments, with IEC 61499compliant software tools and devices available from a wide selection of vendors. VI. ACKNOWLEDGMENTS This work has been partially funded by the Greek General Secretariat for Research and Technology in the context of PENED 99 ED 469 project. We gratefully thank Stefanos Aslanis and Kostas Charatsis members of the ARTIO development team, for their helpful discussions on Profibus and Lonworks fieldbuses.
VII. REFERENCES [1]
IEC Technical CommitteeTC65/WG6, IEC61499 Industrial-Process Measurement and Control Specification, IEC Draft 2000. [2] IEC Committee No.65C, “IEC61804 General Requirements Specification”, IEC Draft 2000. [3] R.W.Lewis, “Modelling Distributed Control Systems Using IEC61499 Function Blocks”, Technical Articles, URL: http//www.searcheng.co.uk/selection/control/ tech.htm. [4] K.Thramboulidis, “Towards a UML based Engineering Support System”, 9th Mediterranean Conference on Control and Automation, Croatia 2001. [5] K.Thramboulidis, C.Tranoris, “An Architecture for the Development of Function Block Oriented Engineering Support Systems”, IEEE International Symposium on Computational Intelligence in Robotics and Automation, Banff, Alberta, Canada 2001. [6] “The HART book 9”, http://www.thehartbook.com/articles/ h9ddl.asp. [7] FF-94-890 PS 1.0 Preliminary Standard, Fieldbus Foundation 1995. [8] The International Open Fieldbus Standard EN50170, “Profibus Guideline – Specification”, PNO Draft 1998. [9] Lontalk Protocol Specification, EHELON Corporation 1999. [10] Extensible Markup Language (XML) 1.0 (Second Edition), W3C Recommendation, 6 October 2000. [11] “OMG Unified Modelling Language Specification”, Version 1.3, First Edition, Object Management Group Inc. March 2000.
7
