Borja Ramis, Jorge Garcia, Jose L. Martinez Lastra. Factory Automation Systems and Technologies Lab, Tampere University of Technology. Tampere, Finland.
Assessment of IEC-61499 and CDL for Function Block composition in factory-wide system integration Borja Ramis, Jorge Garcia, Jose L. Martinez Lastra Factory Automation Systems and Technologies Lab, Tampere University of Technology Tampere, Finland {borja.ramisferrer, jorge.garcia, jose.lastra}@tut.fi enrichment of the composition to simplify the task for the definition of CFBs and even automate it. The use of Service Oriented Computing (SOC) has been growing sharply during the last years due to the increased complexity and applications demand. This design paradigm aims towards reusability and modularity of services for simplifying integration efforts [1]. The loosely-coupled outcome of the servitization approach can be orchestrated or/and choreographed to link the functionality of the services in order to generate a composite of functions or a process. Choreography and orchestration languages permit software developers to define Web Service compositions that are complex services composed by groups of services. Web Service Choreography Description Language (WS-CDL) [2], Web Service Choreography Interface (WSCI) [3] and Ontology Web Language for Services (OWL-S) [4] are the most used Web Service Choreography based standards for modeling workflows for the service interaction which are widely used today. On the other hand, the most used Web Service Orchestration based standard is the Web Service Business Process Execution Language (WS-BPEL) [5]. While orchestration presents the composition with a predefined process sequence centrally controlled by an orchestrator, it can be stated that choreography is suited for distributed asynchronous cases since it does not determine specific orders of communication between services and they are deployed by a choreographer in a decentralized manner. Arguably, there are some important reasons to choose the language to be used but this composition strategies can be analyzed and compared in real scenarios as in [6]. In this paper, it is presented an approach based on WSCDL as an execution language for the composition of FBs. This is an uncommon use of choreography because, during the last years, the trend to utilize CDL as a modeling language instead of using it as an execution one. Also, CDL can enrich the composition of FBs by including roles and behaviors of each component deployed in the system to simplify the composition of functions and even to reach a dynamic composition solution. The assessment of this work includes the evaluation of the modeling languages in a FB based Enterprise Integration solution such the PLANTCockpit framework. This implies the identification of benefits and drawbacks of using CDL and IEC-61499 as a descriptor for the creation of routes that connect the modules to exchange messages correctly. The rest of the paper is structured as follows: Section 2 discusses the work done in the industry with Web Service Choreography Languages during the last years, presents the
Abstract— Factory Information Systems (FIS) are clustered with a variety of heterogeneous systems using different protocols making integration tasks complex and time consuming. A common practice for integration of large applications is modularity and servitization as seen in the Service Oriented Computing (SOC) paradigms. Services can be encapsulated as a Function Block (FB) according to IEC61499 standard bridging the gap between shop-floors and Information Technology (IT) distributed systems. This approach eases the task to describe the overall system in a single descriptive language. However, along with all these concepts comes the critical task of ensuring trustful communication between distributed modular functions to transform the atomic functionality into processes. One of the main challenges for function composition is the need to establish the interactions between the compatible modules to compose a process. This encourages the use of a rich descriptive language as a control strategy to manage the exchange of messages and to define the connections among the services. Primarily, this paper provides a contrast for Function Block composition using IEC-61499 and Choreography Description Languages (CDL) for Function Block based integration. The results are later evaluated within the PLANTCockpit’s Function Block Engine reference architecture for deployment of Function Block Networks (FBNs). Keywords- Choreography; IEC-61499; SOA; CDL; WS-CDL, Factory Automation.
I. INTRODUCTION IEC-61499 is an open standard used to model distributed control and Automation Systems (ASs). It bases its design in Function Blocks (FBs) that encapsulate the business logic and internal FBs providing a modular approach for modeling distributed systems. Within its specification, IEC-61499 presents the Composite Function Blocks (CFBs) as a container for FBs to encapsulate processes or complex functions. This increases reusability of components allowing re-configurability of the system’s model without having to edit monolithic large implementations. However, semantics contained in the description of CFBs is limited. For instance, no semantic description is defined which would allow inferring whether FB is compatible by their role or behavior with other FBs. Currently, CFB defines a set of FBs that can be interconnected via events and data signals, which composes a Function Block Networks (FBN) with source and destination. However, roles and behaviors of participating FBs are not considered. This encourages the
978-1-4799-0752-6/13/$31.00 ©2013 IEEE
212
information with other services without the need of a central controller. It can be stated that WS-CDL is divided in two parts [8]. Firstly, in the static part there are defined all the important and unchangeable relationships. Secondly, in the dynamic part there is defined the choreography as a correlation of interactions between services and/or interdependencies. The static part of the WS-CDL, defines Role Types, Participant Types, Relationship Types and Channel Types which are the invariant collaborating participants used in the dynamic part allowing the choreography in a web service composition. On the other hand, the dynamic part of the WS-CDL determines the choreography structure. Here is where the language describes the interactions between Role Types that will interact between them developing the choreography. Moreover, the standard describes the actions performed by the choreography with a block called activity. There are three activities that can be achieved. The first possible activity is an Ordering Structure that is a combination of activities to describe task ordering by the choreography. The second available activity is named WorkUnit which is used to permit the repetition of the activities that are defined inside the WorkUnit structure. Finally, there is a set of activities included in a Basic Activity which is used to define the primary actions that can be performed by choreographies. In the last activity case it can be defined structures like Interaction, Perform, Assign, SilentAction, NoAction and Finalize activities as it is specified in [2]. To sum up this brief introduction about WS-CDL, it has to be noted that the aim of this declarative XML based language is to define complex choreographies performing relationships and interactions between web services to accomplish one or more tasks.
basics of choreography, introduces briefly WS-CDL and IEC-61499 standards, and compares them. Section 3 refers to the the actual gaps that are in the use of choreography based technologies. Section 4 explains how the WS-CDL based DSL is defined using a theoretical example. Section 5 presents the evaluation of the modeling languages in PLANTCockpit and Section 6 concludes the paper. II.
BACKGROUND AND RELATED WORK
A. Web Service Choreography Description Languages Choreography Description languages, describe decentralized models allowing services to interact between them following rules of message exchange. CDL are descriptive languages which define sequences of interactions that can be completed in a Web Service composition. Choreography is a not a widely developed topic within Factory Automation research community as execution language in industrial applications. It could be right to state that the evolution of SOC implied the appearance of choreography more than ten years ago. It was in those years when emerged the idea to use Extensible Markup Language (XML) based languages in business process choreography giving the chance to developers to create and develop standards to model behaviors of web services. However, it has not been long since automation has taken a step towards a web oriented vertical integration. Devices are including services as interface mechanism extending the reach of business applications down to the lowest granular component of an enterprise. The most common languages that can describe Web Service Choreographies are: Web Service Choreography Description Language (WS-CDL), Web Service Choreography Interface (WSCI) and Ontology Web Language for Services (OWL-S). These descriptive languages present different characteristics and structures [7] but all of them are used to specify Web Services choreographies in a different form. Comparison between different choreographic schemes can be made by checking [2, 3, and 4]. From the few work exposed in the research community, [6] presents an evaluation between service-oriented schemes in shop-floor and explains the advantages and disadvantages of using a choreography approach for pallet flow. In addition, [6] shows opportunities between the schemes and proposes as well as the use of a combined approach.
C. Function Block Compostion with IEC-61499 IEC-61499 standard proposes the encapsulation of business logic as algorithms in basic FBs that are triggered by event flows. Execution control charts (ECCs) control the execution of the logic while keeping record of its state. The encapsulation of the business logic protects intellectual property of each component and allows the instantiation of components for reusability of the functionality. The standard allows the composition of higher-level FBs called CFBs. This type of FB acts as a higher-level shell to encapsulate the atomic functionality of basic FBs as well as other CFBs. It does not rely on ECC and its execution is controlled by the FBN configured. Moreover, applications can be used in IEC-61499 to define certain functions as it is explained in [9]. Thus, a functionality of an AS can be defined by a FB composition because an application is defined by a FBN. This structure determines the data and event flow that control the process execution. In [9] it is explicated that this definition is abstract because data and events can be passed from an application to another through Service Interface Function Blocks (SIFBs) without any type of specification about the resources or devices where FBs are being executed.
B. Service composition with WS-CDL “The Web Services Choreography Description Language (WS-CDL) is an XML-based language that describes peerto-peer collaborations of participants by defining, from a global viewpoint, their common and complementary observable behavior; where ordered message exchanges result in accomplishing a common business goal.” [2] The WS-CDL objective is to be a powerful specification to describe the collaboration between participants in a Web Service composition. Due to be a choreography based standard, WS-CDL provides each service the possibility of directly exchange the
213
FBType
Package Token Attr: name, informationType Elem: description
Identification Attr: Standard CompilerInfo Attr: Header
roleType Attr: name Elem: description
InterfaceList
relationshipType Attr: name Elem: description, roleType
EventInputs Elem: Event
paricipantType Attr: name Elem: description, roleType
EventOutputs Elem: Event
Choreography
InputVars Elem: VarDeclaration
relationship Attr: type
OutputVars Elem: VarDeclaration
variableDefinitions Elem: variable FBNetwork Ordering Activities FB Attr: Name Attr: Type
Basic Activities
WorkUnit
EventConnections exceptionBlock Connection Attr: Source Attr: Destination
finalizerBlock
Fig. 1. IEC-61499 and WS-CDL structures.
that there is a choreography package level in where a choreography can be defined to state order of message exchange between composition services. Moreover, the connections between FBs are defined in IEC-61499 stating only source and destination in the dynamic part, while WS-CDL firstly defines the relationships between services and, secondly, the type of channel in the static part. Then, WS-CDL offers more description because define the relation between participants and how they are connected. In addition, WS-CDL describes types of interactions between FBs that is useful in a choreography solution because the dynamic composition can behave in a
D. Comparison between IEC-61499 and WS-CDL Due to the need of using a description language in a dynamic FB composition, it must be compared different qualities of the available standards that can be used for choreography strategies. Thereby, IEC-61499 and WSCDL structures presented in Fig. 1 schematically show a possible use of each standard. Then, having Fig. 1 as a reference, IEC-61499 only is concerned about the definition of events and variables of FBs for the static part and the FBN for the dynamic part, while WS-CDL adds roles, behaviors, relations between participants, channel types, etc. for the static part and interaction types for the dynamic part. In fact, [2] indicates
214
decentralized way, while IEC-61499 just defines the structure of the dynamic FB composition. Actually, as IEC-61499 does not describe anything related about interactions between services, there is no control of the message exchange sequence between participants. Hence, this comparison purposes that using WS-CDL is a better descriptive solution as a strategy of choreography description in distributed enterprise applications.
B. Solution for the presented scenario As it can be seen in Fig. 2, there are three FBs that could represent three services interconnected by outputs and inputs being all an approach of a web service composition. In this scenario, it is not considered problems of compatibility between blocks because is a simple case but, in that case, it should be necessary to add some filters in the connections or process the messages to avoid misunderstanding between blocks. Firstly, the definition of the choreography’s static part is described. This means that Role Types, Participant Types, Relationship Types, Information Types, Tokens and Tokenlocators and Channel Types have to be identified and represented following the WS-CDL format used in [2]. On the other hand, the dynamic part needs to be solved. It is here where the type of interactions and the rules to relate services is described. Then, again following the scenario in Fig. 2, two interactions can be described in a sequence, where the first of those interactions is to define the message exchange between dbAdapter and ruleEngine blocks, and the second is to define the message exchange between the ruleEngine and visEngine blocks. Once more, as in the static part, the definition of the WS-CDL dynamic part components must match the format explained in [2].
III. PROBLEM STATEMENT Probably, the most important drawback of using choreography languages as standards to solve practical problems is that they are descriptive languages instead of execution languages. Moreover, there are few tools which permit to execute WS-CDL specifications. The aim of a choreography description language is to describe possible relationships and interactions between services instead of offering to the software developer an available execution language to be used with some tool. In fact, there are implementations performed to execute choreography standards as WS-CDL, demonstrated in [8], with the idea to face with this critical gap in the choreography execution. Hence, it can be stated that this is one of the reasons to perform the DSL presented in this paper, which provides a WS-CDL use that can help to the execution and more extensive description of choreographies in a FB based architecture. IV.
V. EVALUATION OF IEC-61499 AND CDL IN PLANTCOCKPIT’S FUNCTION BLOCK INTEGRATION APPROACH
CONCEPTUAL APPROACH FOR IMPLEMENTATION
PLANTCockpit is a research project launched by the European Commission within the 7th Framework Programme under the umbrella of “Factories of the Future”. The project develops a central environment for monitoring and controlling of all intra-logistical processes of multiple domains in manufacturing such as: car manufacturing, construction infrastructures, chip manufacturing among others [10]. As part of the results, the project defined a reference architecture for intra logistic cockpits. The architecture was designed using the concept of FBs as described in [11]. This architecture has a noticeable influence from the IEC-61499 standard. The functionality is encapsulated and communication is homogenized using XML as integration language. The approach presented is flexible and modular allowing during system configuration to compose different scenarios for data processing and metric calculation. The most intuitive approach for modeling these FB scenarios is via IEC-61499 FBN description. However, messaging, mapping, routing, and transformation mechanisms that are required by the framework are not covered by the description of EIC-61499 alone. Hence, a more descriptive semantic specification is needed to satisfy the missing information for FBN modeling which has guided this research on the consideration of CDL as FBN description. Fig. 3 depicts the basic interaction of FBs within the platform of PLANTCockpit.
A. Presenting the scenario In this section, it is presented a theoretical example to explain how the presented DSL is used in a three FB party. The scenario presented in Fig. 2 is composed of three blocks that are linked by in and out topics. The idea is to use a WS-CDL to describe an executable choreography that has to be able to define the communication and the message exchange between FBs that can be understood as individual services.
Fig. 2. Three FB message interaction scenario.
215
B. Identifying the constraints Modeling variables, events and connections does not provide a complete configuration description for FBNs in a wide-range integration solution such as the one proposed by PLANTCockpit as seen from Fig. 3 and Fig. 4. Each FBN model provides different levels of expressivity. On one hand, IEC-61499 presents the FBN as a combination of event connections which has a source and destination defined while separating data from events. On event arrival, the FB retrieves the variables linked to the event and triggers. However, in the PLANTCockpit’s platform the message itself becomes the event and each component reacts based on the information the message carries. Furthermore, message filtering is done during message routing; this decreases the amount of message flow in the system by routing messages of interest to a consumers. Filters cannot be expressed since eventing and the data is separated. Moreover to that IEC-61499 lacks of a descriptive semantics to identify the roles and categories of the interacting FBs. On the other hand, CDL provides a rich language for modeling interactions with roles and relationships. It also provides semantic extensions that allow the inclusion of structured attributes using RDF or OWL [2] which are widely known semantic languages. The definition of these attributes could be linked to the filtering information as well as the FB configuration model. However, CDL has been crafted for WS* and its use as execution language has not been widely popular and its usability is mostly based as modeling language. Even so, CDL still provides a more descriptive modeling language for deployment of FBN against the simpler model of IEC-61499 within the context of PLANTCockpit.
Fig. 3. Message routing and transformation in PLANTCockpit
The route is constructed by specifying a source, a destination, and a filter. The filter specifies the messages that are of interest for a consumer and it can be seen as a message subscription. A FB Instance may contain several inputs and output message types that processes and generates respectively. Interoperability between FBs is done via transformation scripts executed in the output and input endpoints of each FB. This provides a dynamic mechanism to transform messages to other types. The scripts are included as part of the configuration of a FB however it is relevant during the generation of the route since message types are being converted. The following subsections elaborate on the characteristics of CDL and IEC-61499 identifying the constraints of each approach. A. From model to FBN The procedure to generate a FBN consists of the step depicted in Fig. 4. The first step consists in the deployment of the model into the PLANTCockpit framework, next the FB Managers extract the involved components information and identifies the involved message types and transformations per interaction and finally deploys routes with filter definition. It can be noticeable that FBNs interactions are tightly related to transformation scripts [12]. In this case it is necessary to configure the necessary transformation in the involved FB to deploy a FBN. For this reason, it is recommendable to have a highly expressive modeling language for the definition of FBN.
VI. CONCLUSIONS AND FURTHER WORK Based on the comparison presented in this work, the selection of CDL over IEC-61499 seems more reasonable for the implementation approach of FB based Enterprise Integration such as the PLANTCockpit’s platform. However, CDL has little support in the area of execution. Transformation from CDL to actual FB instances may require of extra semantics such as configuration and transformation that the structured attributes provided by CDL may not suffice. In this case as future work we will include an approach for FBN deployment based on other semantic technologies such as OWL, RDF which allows a goal oriented semantic reasoning approach to generate FBN. ACKNOWLEDGMENT The research was founded by the European Union's Seventh Framework Programme (FP7/2007-2013) under grant agreement n° 260018 (PLANTCockpit Production Logistics and Sustainability Cockpit).
Fig. 4. Model execution for FBN deployment
216
REFERENCES
[11] Vasyutynskyy, V.; Hengstler, C.; McCarthy, J.; Brennan, K.G.; Nadoveza, D.; Dennert, A., "Layered architecture for production and logistics cockpits", Emerging Technologies & Factory Automation (ETFA), 2012 IEEE 17th Conference, vol., no., pp.1,9, 17-21 Sept. 2012, doi: 10.1109/ETFA.2012.6489548 [12] Dennert, Alexander, Jakob Krauze, Jorge Garcia, Stephan Hesse, J.L. Martinez Lastra, Martin W. “Advanced Concepts for Flexible Data Integration in Heterogenous Production Environments”. 11th IFAC Workshop on Intellingent Manufacturing Systems (IMS 2013), São Paulo, Brazil, May 22-24, 2013. [13] Lastra, J.L.M.; Delamer, I.M., "Semantic web services in factory automation: fundamental insights and research roadmap", Industrial Informatics, IEEE Transactions, vol.2, no.1, pp.1,11, Feb. 2006, doi: 10.1109/TII.2005.862144 [14] Jammes, F.; Smit, H.; Lastra, J.L.M.; Delamer, I.M., "Orchestration of service-oriented manufacturing processes", Emerging Technologies and Factory Automation, 2005. ETFA 2005. 10th IEEE Conference, vol.1, no., pp.8 pp.,624, 19-22 Sept. 2005, doi: 10.1109/ETFA.2005.1612580 [15] Colombo, A. W.; Jammes, F.; Smit, H.; Harrison, R.; Lastra, J.L.M.; Delamer, I.M., "Service-oriented architectures for collaborative automation", Industrial Electronics Society, 2005. IECON 2005. 31st Annual Conference of IEEE, vol., no., pp.6 pp.,, 6-10 Nov. 2005, doi: 10.1109/IECON.2005.1569325 [16] Delamer, I.M.; Lastra, J.L.M., "Loosely-coupled Automation Systems using Device-level SOA", Industrial Informatics, 2007 5th IEEE International Conference, vol.2, no., pp.743,748, 23-27 June 2007, doi: 10.1109/INDIN.2007.4384866 [17] Puttonen, J.; Lobov, A.; Lastra, J.L.M., "An application of BPEL for service orchestration in an industrial environment", Emerging Technologies and Factory Automation, 2008.ETFA 2008. IEEE International Conference, vol., no., pp.530,537, 15-18 Sept. 2008 doi: 10.1109/ETFA.2008
[1]
Michael P. Papazoglou, Paolo Traverso, Schahram Dustdar, Frank Leymann, "Service-Oriented Computing: State of the Art and Research Challenges”. Computer, vol. 40, no. 11, pp. 38-45, Oct. 2007, doi:10.1109/MC.2007.400. [2] N. Kavantzas et al. Web Service Choreography Description Language (WSCDL) 1.0. [Online]. Available: http://www.w3.org/TR/ws-cdl-10/. [3] A. Arkin et al. Web Service Choreography Interface (WSCI) 1.0. [Online]. Available: http://www.w3.org/TR/wsci/. [4] D. Martin et al. OWL-S: Semantic Markup for Web Services. [Online]. Available: http://www.w3.org/Submission/OWL-S/. [5] Web Services Business Process Execution Language Version 2.0, OASIS Standard, 11 April 2007, [Online]. Available: http://docs.oasis-open.org/wsbpel/2.0/wsbpel-v2.0.html. [6] J. Minor, J. M. Garcia Izaguirre, J. Martinez, A. Lobov, and J.L. Martinez Lastra, "Evaluating Service-Oriented Orchestration Schemes for Controlling Pallet Flow", ICONS 2012 : The Seventh International Conference on Systems, pp. 88-92, February 29 March 5 2012, ISBN: 978-1-61208-184-7. [7] Cambronero, M.E.; Diaz, G. Martinez, E. Valero, V. , "A Comparative Study between WSCI, WS-CDL, and OWL-S" eBusiness Engineering, 2009. ICEBE'09. IEEE International Conference , vol., no., pp.377-382, 21-23 Oct. 2009. [8] Lars-Åke Fredlund, “Implementing WS-CDL”, JSWEB 2006: II Jornadas Científico-Técnicas en Servicios Web, 16-17 November 2006, pp. 107-113. [9] Valeriy Vyatkin. (2007). “IEC 61499 Fuction Blocks for Embbeded and Distributed Control Systems Design”. ISAInstrumentation, Systems, and Automation Society. ISBN: 978-09792343-0-9. [10] “PLANTCockpit,” [Online]. Available: http://www.plantcockpit.eu
217
Powered by TCPDF (www.tcpdf.org)
