PROFINET Specification PROFINET CBA Architecture Description and Specification Version 2.02 May 2004 Order No: 2.202 TC2-04-0001 PROFINET CBA Architecture Description and Specification V 2.02 Document Identification: TC2-04-0001 File name: PN-CBA-Architecture_2202_V202_Oct04 Prepared by the PROFIBUS Working Group 10 “PROFINET CBA” in the Technical Committee “Communication Profiles” The attention of adopters is directed to the possibility that compliance with or adoption of PI (PROFIBUS International) specifications may require use of an invention covered by patent rights PI shall not be responsible for identifying patents for which a license may be required by any PI specification, or for conducting legal inquiries into the legal validity or scope of those patents that are brought to its attention PI specifications are prospective and advisory only Prospective users are responsible for protecting themselves against liability for infringement of patents NOTICE: The information contained in this document is subject to change without notice The material in this document details a PI specification in accordance with the license and notices set forth on this page This document does not represent a commitment to implement any portion of this specification in any company's products WHILE THE INFORMATION IN THIS PUBLICATION IS BELIEVED TO BE ACCURATE, PI MAKES NO WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, WITH REGARD TO THIS MATERIAL INCLUDING, BUT NOT LIMITED TO ANY WARRANTY OF TITLE OR OWNERSHIP, IMPLIED WARRANTY OF MERCHANTABILITY OR WARRANTY OF FITNESS FOR PARTICULAR PURPOSE OR USE In no event shall PI be liable for errors contained herein or for indirect, incidental, special, consequential, reliance or cover damages, including loss of profits, revenue, data or use, incurred by any user or any third party Compliance with this specification does not absolve manufacturers of PROFIBUS or PROFINET equipment, from the requirements of safety and regulatory agencies (TÜV, BIA, UL, CSA, FCC, IEC, etc.) PROFIBUS® and PROFINET® logos are registered trade marks The use is restricted for members of Profibus International More detailed terms for the use can be found on the web page www.profibus.com/libraries.html Please select button "Presentations & logos" Publisher: PROFIBUS Nutzerorganisation e.V Haid-und-Neu-Str D-76131 Karlsruhe Germany Phone: +49 721 / 96 58 590 Fax: +49 721 / 96 58 589 E-mail: pi@profibus.com Web site: www.profibus.com © No part of this publication may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from the publisher © Copyright PNO 2004 – All Rights Reserved page of pages TC2-04-0001 PROFINET CBA Architecture Description and Specification V 2.02 Version Overview Chapter – Overview and Introduction – Objects in Automation – PROFInet Runtime Model – PROFInet Engineering Model – WebIntegration – Network Management © Copyright PNO 2004 – All Rights Reserved Version V2.01 V2.0 V2.02 V2.02 V0.73 V2.02 Issue Date August 2003 January 2003 February 2004 February 2004 January 2003 May 2004 Remarks Released Released Released Released Working Draft Released page of pages This page is intentionally left blank PROFInet Architecture Description, Overview and Introduction Version V2.01, August 2003 Chapter 0: Overview and Introduction © Copyright by PNO 2003 - All rights reserved Page 0-1 PROFInet Architecture Description, Overview and Introduction Version V2.01, August 2003 Contents OVERVIEW AND INTRODUCTION 0.1 REQUIREMENTS AND GOALS .3 0.1.1 Changes in the Automation Landscape 0.1.2 Trend Towards Open Distributed Automation 0.2 AUTOMATION USING PROFINET .4 0.2.1 Goals of the Architecture 0.2.2 The Keystones of the Open Interoperable System 0.3 THE PROFINET CONCEPT 0.3.1 Runtime 0.3.2 Automation Objects 0.3.3 Implementation Methods for Automation Objects 0.4 PROFINET -RUNTIME MODEL 0.4.1 Including Non-PROFInet Components 0.5 COMMUNICATION 10 0.6 ENGINEERING 11 0.7 SUMMARY 11 0.7.1 Further Development, New Communication Systems 12 © Copyright by PNO 2003 - All rights reserved Page 0-2 PROFInet Architecture Description, Overview and Introduction Version V2.01, August 2003 Overview and Introduction 0.1 Requirements and Goals 0.1.1 Changes in the Automation Landscape This document is based on Information which has been gained through market research and the study of our competitors The main focus of the document is the further development of automation engineering to an open distributed automation system This development is motivated by the principal customer requirements for openness, consistency and ease of use, and the belief that these requirements will increase efficiency and reduce costs, in both the development and usage of automation applications From our customers viewpoint, openness means products with open interfaces that can be seamlessly integrated into an existing automation task The need for openness is relevant for both the runtime components (PLC, drives, switchgear, field devices, actuators, sensors, HMI, etc.) and the engineering platform Consistency means a consistent configuration and transparent data traffic, from the corporate level down to the automation field level It also implies transparent data interfaces across all automation phases, from product planning (CAD tools) via system installation, up to operation, service and maintenance Under ease of use, the customer understands the simplified handling of a technology which is becoming increasingly complex These requirements for open automation solutions, PC-based control, and consistent corporate communication - combined with available standard products and technologies - result in the need for a new approach to automation 0.1.2 Trend Towards Open Distributed Automation The goals of increasing productivity and reducing costs are the principal forces behind new development and Innovation In the field of automation technology these goals have similarly lead to increasingly smaller, faster and more cost-effective solutions Bus systems replaced parallel wiring, electronics replaced mechanical systems, and software substituted for hardware In spite of all these developments, there has never been a major paradigm change in the realization of automation solutions since the introduction of the PLC Automation still consists chiefly of a central computing power (PLC, PC, IPC, ) which is connected either centrally with actuators/sensors, or decentrally via a field bus with actuators/sensors or intelligent field devices distributed control PLC actuators/sensors PLC bus-capable actuators/sensors PLC ? intelligent field devices stand-alone units Figure 0: Trend towards distributed automation Modern micro electronics, software technology, communication engineering and the influence of commercial mass markets on the costs make a change of paradigm likely • The central computing power is beneficially and economically distributed to the components that participate in the automation solution • PC, Internet and new software technologies (COM, Java, VB ) change automation engineering and permit new solution approaches to be used © Copyright by PNO 2003 - All rights reserved Page 0-3 PROFInet Architecture Description, Overview and Introduction Version V2.01, August 2003 The central computing power is distributed to the places where it is naturally required according to the task specification and/or the technological requirement (in the drive, valve, control panel, etc.) This results in the creation of autonomous functional units that can be combined according to the application requirements However, in order that this development can take place, an open architecture model that forms the basis of the Engineering System and the Runtime System (communication relationships between the functional units) is needed The interest groups pushing the paradigm change towards distributed computing power are many and varied • The consumer has come to expect more competition between producers, and as a result, better prices Doing without the central components can facilitate this by lowering production and operation costs • Through the use of encapsulated autonomous and tested functional units, the application programmer can realize increased flexibility and lowered costs in the engineering, commissioning, acceptance and service phases • OEMs (machine builders, suppliers of process-related units and subsystems) are able to optimize their processes (engineering, reusability, series quantities, delivery units) and deliver prefabricated tested subsystems for a complete system 0.2 Automation Using PROFInet PROFInet permits a distributed automation solution to be created through the use of prefabricated components and sub solutions The delivery of prefabricated components and the reusability of existing components enables significant reductions in the engineering costs associated with automation system development The primary goal of PROFInet is the combination of the naturally distributed automation objects of an application rather than the distribution of the computing power Principally the focus is on components with a fixed functionality that can be parameterized (drive, valve, measuring unit, control station, manipulator, monitoring equipment, etc.) The free computing power of PLC or PC can be then dedicated to higher-level sequencing logic (such as recipe handling), higher-level safety (such as guards, energy supply) or interfacing to the outside world (such as office applications, access control) PROFInet is the answer of PNO to the change of paradigm in automation engineering and to the trend towards increased utilization of the Ethernet network, right down to the field device (Ethernet as field bus) Using PROFInet, the PNO member companies are in a position to take the leading role in the creation of the next phase of automation solutions, thereby realizing the basis for successful production 0.2.1 Goals of the Architecture The definition of PROFInet has been shaped by the following considerations: • Openness (using standards which are universally accepted); open via clearly defined interfaces does not necessarily mean the disclosure of all device-internal implementations • Consistency (communication and cooperation of devices on all levels via similar mechanisms) Horizontally between programmable controllers (Automation Integration), and Vertically between office, control and field level (Business Integration) • Integration of unchanged PROFIBUS field systems with homogenous engineering perspective • Intuitive usability (ease of use; simplified and uniform application model; taking different user groups into account) © Copyright by PNO 2003 - All rights reserved Page 0-4 PROFInet Architecture Description, Overview and Introduction Version V2.01, August 2003 • Upward compatibility to PROFIBUS and existing engineering tools (PLC programming, DP configuration) • Uniform engineering and data model (consistent tool sequence, common database) • Component- and object-oriented Applications are created by interconnecting objects The interconnection can be made graphically, textually, or via scripts 0.2.2 The Keystones of the Open Interoperable System PROFInet is based on the following keystones, all open and established industry standards IP ORPC/DCOM COM/OLE ETHERNET PROFIBUS IP and the transport protocols TCP and UDP are used for communication (transport) and for addressing the nodes Additional protocols of the IP stack (routing, network administration, ) are also used This makes network layer and transport layer uniform and consistent The interface to automation objects that is defined via IDL (Interface Definition Language) is consistently used at the application level Communication takes place via the DCOM protocol This provides an open, interoperable and selfdocumenting application protocol In addition to data relationships, event mechanisms and method calls to remote device are also made possible COM/OLE forms the basis for all the objects that interact during engineering This lays the foundation for component-based engineering Ethernet and its further developments (such as Fast and Gigabit Ethernet) form the basis of the PROFInet communication system Using proxies, PROFIBUS network segments can be linked to both the engineering and runtime world The use of interface and communication standards that were developed in the Microsoft world does not necessarily mean that PROFInet is confined to Microsoft operating systems (such as Windows NT, 2000 or Windows CE ) With the runtime systems (field devices, controllers) in particular, the PROFInet functions can also be implemented in operating system environments that exist or have been tailored to the PLC requirements Open TCP/IP protocol stacks and operating system - independent DCOM /RPC protocol implementations are currently widely available With regard to the Engineering Systems, PROFInet works primarily with established Microsoft architectures and software interface standards, such as COM / OLE and IDL PROFInet Engineering Systems should therefore be conceived for PC platforms with WINDOWS NT / 2000 operating system © Copyright by PNO 2003 - All rights reserved Page 0-5 PROFInet Architecture Description, Overview and Introduction 0.3 Version V2.01, August 2003 The PROFInet Concept The PROFInet concept is relevant to both the engineering and the runtime world Windows configuring applications configuration tools other engineering tools for diagnosis, simulation, Engineering System (ES) programming components field devices programming tools components of fixed functionality (field device) Runtime (RT) PLC programming tools ES-AUTO RT-AUTO programable components (e.g PLC) RT-AUTO AUTO = automation object Figure : PROFInet total overview 0.3.1 Runtime PROFInet Runtime defines the necessary common points which interacting automation components must provide in order to be able to fulfill an automation task Besides addressing the issues of compatibility and interoperability with today's programmable controllers, PROFInet must also ensure the same level of performance of today's devices and device - device communication 0.3.2 Automation Objects In the runtime world, we distinguish between automation components with a fixed functionality and automation components with programmable and loadable functionality An automation component with a fixed functionality is already operational when it comes from the manufacturer (valve, drive, field device, actuator, sensor ) A programmable automation component (PLC, PC ) is programmed and/or configured by the user as required by the application Although both component types can have individual product-specific internal structures (architecture, execution system, programming ), their behavior is identical to the outside world They are always visible as a collection of automation objects with COM interfaces This view is particularly valid for subordinate NON-PROFInet systems (such as unchanged DP slaves on the PROFIBUS or AS-I via proxy) Only the so called automation objects (AUTOs) are seen by a client in a remote programmable controller These are COM objects that are tailored to the automation engineering requirements They provide their functionality via well-defined COM interfaces DCOM mechanisms can be used to determine which interfaces have been implemented in an AUTO The automation objects are interconnected via the DCOM object bus Automation objects can interact not only with each other but also with other COM objects (office world, databases SAP ) via this object bus Readily available products from the market enable the integration of objects which exist on other object busses (CORBA objects in UNIX mainframes) The use of the DCOM object bus ultimately lays the basis for openness and interoperability (consistency) © Copyright by PNO 2003 - All rights reserved Page 0-6 PROFInet Architecture Description, Overview and Introduction Version V2.01, August 2003 manufacturer-independent automation system PROFInet is easily integrated in a vendor’s existing product range and enhances and/or completes the functionality that is required for a distributed automation The openness of the PROFInet approach is based on the utilization of established and accepted market standards • Automation object model according to the Microsoft COM/DCOM standard • Communication: TCP(UDP)/IP and DCOM wire protocol • Object handling in engineering and HMI: Microsoft OLE, ActiveX • Integration of existing unchanged PROFIBUS bus segments and PROFIBUS DP field devices 0.7.1 Further Development, New Communication Systems The flexible PROFInet structure and, in particular, the consistent separation of the application and communication layers, makes it possible to integrate new communication systems and methods into the concept In this way, "Hard" real-time applications using a deterministic real-time transfer in conjunction with the Ethernet bus (currently only in its definition/discussion phase) could be implemented Likewise, a communication network with a redundant structure based on an Ethernet fiber optics ring or a redundant TCP-IP transport system would make it possible to satisfy the requirements from the process control system world for a "fault-tolerant" system to be implemented The flexible PROFInet structure with the possibility of integrating entire PROFIBUS segments also allows the proven PROFIBUS technique to be used for special applications (such as in drive engineering), and to connect these system to the standard Ethernet via a proxy, thus integrating them into the PROFInet system © Copyright by PNO 2003 - All rights reserved Page 0-12 PROFInet Architecture Description, Objects in Automation Version V2.0, January 2003 Chapter 1: Objects in Automation © Copyright by PNO 2003 - All rights reserved Page 1-1 PROFInet Architecture Description, Objects in Automation Version V2.0, January 2003 Contents OBJECTS IN AUTOMATION 1-3 1.1 PROFINET OBJECTS ARE COM OBJECTS 1-3 1.2 AUTOMATION PROJECTS AT RUNTIME AND IN ENGINEERING 1-3 1.3 PROFINET AND THE INTEGRATION POSSIBILITIES IN THE AUTOMATION WORLD 1-6 1.3.1 Horizontal Integration on "Process Control" Level 1-6 1.3.2 Vertical Integration Between the Levels 1-7 1.4 OPERATION ENVIRONMENT 1-8 1.5 COOPERATION MECHANISMS BETWEEN PROFINET OBJECTS 1-8 1.5.1 Direct COM Method Call 1-8 1.5.2 COM Event Mechanism 1-8 1.5.3 Interconnecting Events and Data Analogously to the Block Concept 1-9 1.6 INTERRELATION BETWEEN PROFINET AND OTHER STANDARDIZATION ACTIVITIES 1-9 1.6.1 PROFInet and OPC 1-9 1.6.1.1 PROFInet as an Extension of OPC 1-10 1.6.1.2 PROFInet Node as OPC Server 1-10 1.6.1.3 OPC Objectizer 1-11 1.6.2 IEC 61499 as reference model for PROFInet 1-13 1.6.2.1 IEC 61499 – Distributed automation requires common standards 1-13 1.6.2.2 PROFInet is based on the IEC 61499 reference models 1-13 1.6.2.3 Extensions and differences 1-15 1.6.2.4 Mapping of the technological modularization 1-16 1.6.2.5 Interconnections among the blocks (functions) 1-17 1.6.2.6 Mapping of the communication 1-19 1.6.2.7 Extensions of PROFInet exceeding the scope of IEC 61499 1-20 Figures Figure 1-1: Objects at runtime and in engineering 1-5 Figure 1-2: Horizontal and vertical integration 1-6 Figure 1-3: Horizontal integration between subsystems 1-7 Figure 1-4: Horizontal integration between the components of a subsystem 1-7 Figure 1-5: PROFInet node as OPC server (alternatives) 1-11 Figure 1-6: OPC Objectizer 1-12 Figure 1-7: System model with distributed application program 1-14 Figure 1-8: Device model with multiple resources 1-14 Figure 1-9: Resource model with distributed application 1-15 Figure 1-10: Application model with interconnections of data and events 1-15 Figure 1-11: Manufacturer spanning engineering 1-16 Figure 1-12: Various characteristics of the IEC 61499 functions blocks 1-16 Figure 1-13: Function block according IEC 61499 1-17 Figure 1-14: Combinations of events with data 1-18 Figure 1-15: PROFInet supports events with data 1-18 Figure 1-16: Data interconnections 1-19 Figure 1-17: Communication function block with IEC 61499 1-19 Figure 1-18: Class diagram of PROFInet 1-20 © Copyright by PNO 2003 - All rights reserved Page 1-2 PROFInet Architecture Description, Objects in Automation Version V2.0, January 2003 Objects in Automation 1.1 PROFInet Objects are COM Objects The Microsoft Component Object Model (COM) is a conceptual continuation of the development of object orientation with the goal of enabling applications to be developed on the basis of prefabricated components PROFInet employs this component model, since the utilization of prefabricated components is of a central significance in PROFInet too The COM interface concept is the key to understanding COM An interface is the summary of a certain quantity of functions; hence a sort of contract It defines the functionality that shall be furnished A COM component1 can commit itself to fulfill a certain contract, i.e an interface In this case we say that a component implements the interface For a user a COM component merely consists of a number of interfaces When the client calls a function of an interface, it employs the services of a COM component Based on such an interface concept, the component of one application can easily be replaced with another component if the new component supports at least the same interfaces as the old component In addition, the new component is able to implement further interfaces This permits an application to be adjusted selectively to the progressing requirements and to the changing technological boundary conditions There is a special 'Interface Definition Language' (IDL) for the description of a COM interface An interface IExample with two functions goo() and foo() could be described as follows: [ object, uuid(32bb8323-b41b-11cf-a6bb-0080c7b2d682), helpstring("Interface Example") ] interface IExample : IUnknown { HRESULT foo([in] int x, [in,out] int* y, [out] int* z); HRESULT goo([in] long size); }; The IDL syntax is quite similar to the C++ syntax The obvious difference is in the sections between the brackets They enclose the meta information that is necessary for COM to function, and is additional to the C++ syntax The key word uuid, for example, specifies a 128-bit unambiguous identifier, under which the interface is registered The key word helpstring is followed by a text that provides a more detailed description of the interface The identifiers in and out, respectively, define whether the parameter is an input or output parameter The concept of the objects in PROFInet is based on the Component Object Model Each automation object is a COM component; it possesses interfaces that are tailored to the automation engineering tasks Defining the corresponding interfaces is one of the central tasks within the scope of the definition of these System Specifications 1.2 Automation Projects at Runtime and in Engineering When using automation objects, you must always distinguish between the object in the Engineering System (ES Object2) and the object in the Runtime System (RT Object) The ES Object is the representative of the RT Object during engineering Instantiation, interconnection and parameter value assignment of the ES Object produce the model of the automation solution of a concrete system Triggered by a download, and evaluating the engineering model, the system produces the runtime software The term COM object is synonymous with the term COM component A PROFInet component is something different This term denotes the output of the component creation step See chapter for details In the text below, the notation ES Object or RT Object is used if exactly the elements of the object models explained in the Chapters and are meant © Copyright by PNO 2003 - All rights reserved Page 1-3 PROFInet Architecture Description, Objects in Automation Version V2.0, January 2003 The basic idea is that exactly one ES Object in the Engineering System corresponds to each RT Object This makes the mapping capability of the Engineering world to the Runtime world - and vice versa - (during an upload, for example) significantly easier Relationships between ES Objects (such as an interconnection during a download) can thus simply be mapped onto relationships between the corresponding RT Objects This basic idea will be stated more precisely in the individual chapters There are, for example, engineering information that is not available in the runtime These statements are true for the Engineering representatives of the devices (ES Device) and of the software (ES Auto) Since configuration shall be performed at a time at which the runtime world (i.e the devices) does not yet exist, ES Object and RT Object are always two different objects3 Furthermore, the functionalities of the objects are different since only the RT Object is able to provide the automation functionality proper Two activities can be distinguished during the engineering phase: • Creating a template (master description) for the ES Object (component generation) • Using an ES Object within the scope of configuring an application (component utilization) This difference is shown in the following figure Exceptionally and with PC-based RT software, the implementation of ES Object and RT Object can be performed in a software unit ("DLL") They still remain two distinguishable COM objects © Copyright by PNO 2003 - All rights reserved Page 1-4 PROFInet Architecture Description, Objects in Automation Programming (vendor-specific): Version V2.0, January 2003 Master of an ES Object Creation of an ES Master (Template) of an ES Object Provide ES Master in library Engineering (vendorindependant): Library Application Creation of an application based on ES Objects Masters for ES Objects in library ES Objects Creation of Runtime Objects based on the configuration of the ES Objects and download onto the devices Runtime: Application consisting of cooperating RT Objects Runtime Objects Figure 1-1: Objects at runtime and in engineering Corresponding with these three levels, there are three different variants of automation objects A template for an ES Object, an ES Master Object is produced on the top level This includes the description of the interfaces and the programming of the corresponding methods with respect to the two aspects of engineering and runtime The resulting template is stored in a library Storage is performed in the form of a component description (XML file) and, optionally, specific component servers and private data Using the engineering objects, the concrete system is described on the middle level The major ES Objects are the Device Object (ES Device) and the Automation Object (ES Auto) The ES Device is the representative of a unit in Engineering It can be a device with a fixed or a loadable functionality A mixed form (a device with a fixed and additionally loadable functionality) is also permitted The Automation Object is used for application-specific interconnection and parameter value assignment Where a device with a loadable functionality is concerned, each ES Auto becomes a corresponding RT Auto when an application is compiled and loaded This is basically the same for devices with a fixed functionality; however, a code is not loaded in this case In this case it can be possible that an RT Auto already exists in the device (in an active state, i.e not only as a code) The download then loads the configuration information (such as the parameter value assignments) into these RT Autos The Runtime-Object, finally, is the object that represents the executable code, and contributes to the automation solution as a part of the system © Copyright by PNO 2003 - All rights reserved Page 1-5 PROFInet Architecture Description, Objects in Automation 1.3 Version V2.0, January 2003 PROFInet and the Integration Possibilities in the Automation World PROFInet permits the individual levels and segments within the automation pyramid to be interconnected corporate control level production control level vertical integration between the levels process control level field level horizontal integration between the segments such as PLC technology and drive technology Figure 1-2: Horizontal and vertical integration Within the levels, there is a "horizontal integration" between the individual automation engineering segments (such as drive engineering or programmable logic controllers) PROFInet chiefly deals with the horizontal integration on process control and field level Vertical integration includes various levels of the automation pyramid, such as the process control level and the production control level PROFInet extends vertical integration up to field level, in particular 1.3.1 Horizontal Integration on "Process Control" Level PROFInet permits subsystems to be interconnected that were implemented using different technologies For example, a drive based subsystem‚ synchro-controlled conveyor' can be linked to a plc based subsystem ‚machining station' This is achieved by packing such a subsystem as a PROFInet Object and making it thus available to the application This corresponds exactly to the intention of a COM Object with the separation between interface (the packaging) and implementation of the associated functionality (in a plc or a drive) The implementation method is irrelevant to the utilization of the PROFInet Object Proven programming languages, such as Structured Text, can still be employed There is merely the additional possibility of packing the programs as COM Objects © Copyright by PNO 2003 - All rights reserved Page 1-6 PROFInet Architecture Description, Objects in Automation Subsystem machining station (plc based) Version V2.0, January 2003 Subsystem conveyor (drive based) Figure 1-3: Horizontal integration between subsystems Interconnecting subsystems is only the first step in the direction of horizontal integration In the second step, the subsystems can be implemented on the basis of PROFInet Objects and, if applicable, using PROFInet components from different providers for this purpose Subsystem machining station (plc based) Subsystem conveyor (drive based) Figure 1-4: Horizontal integration between the components of a subsystem Obviously, subsystems in this context are also PROFInet-based HMI systems that provide their service (such as archiving and reporting system) in the form of PROFInet Objects In particular, they employ the PROFInet interconnection to set up a link between image and PLC, for example, in a way that is independent of the destination system 1.3.2 Vertical Integration Between the Levels Besides the horizontal integration within the process control level, PROFInet also covers the possibility of a vertical integration between the other levels of the automation pyramid The topic is an integration of the PROFInet runtime and engineering concepts with the production control level and the corporate management level A few standard products (SAP, BAAN, ) have asserted themselves on corporate management level They also provide interfaces for adaptation and integration The production control level is a heterogeneous world with a wide spectrum of applications under different operating systems and on different communication platforms However, there is a clear trend towards MS-Windows and DCOM Another important aspect is the integration with the Office applications (MS Word, MS Excel, etc.) © Copyright by PNO 2003 - All rights reserved Page 1-7 PROFInet Architecture Description, Objects in Automation Version V2.0, January 2003 Vertical integration also includes the possibility of connecting product and system planning tools (CAD, circuit diagram, ) The PROFInet runtime system fulfills the following conditions for a vertical integration: • Transparent, object-oriented access to the automation level from any level via the IP addresses of the devices and by referencing runtime objects via names • Standardized RT-COM interfaces and objects (e.g devices) with exactly defined semantics • COM automation interfaces for access to the runtime objects • RT Objects "live" in the device Representative objects (even in a different device) are not necessary With respect to the Engineering System, PROFInet fulfills the following conditions for the integration: • Uniform object-oriented access to all engineering aspects of an automation object • Expandability by additional functions and tools • Outside control capability and script ability due to OLE automation interfaces • Engineering of components from different manufacturers in one engineering tool All in all, PROFInet has the potential for setting a standard beyond the process control level and field level Even without exhausting this potential, PROFInet at least offers an optimum integration of process control level and field level5 1.4 Operation Environment With PROFInet, the engineering components execute in an MS Windows computer It is not intended to make the engineering components too to run in a PLC, for example PROFInet does not stipulate either that a device brings its engineering object in the sense that it can be loaded directly from the device 1.5 Cooperation Mechanisms Between PROFInet Objects Since the PROFInet objects are COM objects, they automatically support the COM interaction mechanisms These are the COM method call and the COM event mechanism Automation industry applications additionally requires the possibility of event and data interconnection Within the scope of PROFInet, this is defined on the basis of the COM mechanisms 1.5.1 Direct COM Method Call An RT Object is a COM component that offers its functionality in the form of interfaces An interface is the summary of a certain quantity of methods For a client, a COM component merely consists of a number of interfaces When the client calls a method of an interface, it employs the services of a COM component This requires the client to have a reference to the automation object This reference is either specified from the outside, or it is 'firmly programmed' 1.5.2 COM Event Mechanism The event source informs all logged-on event sinks about an occurred event The individual reactions of the event sinks can be different At the side of the event source, the event is linked to the method of an 'outgoing interface' In the sink, this interface must have been implemented as an 'incoming interface' Vertical integration can, of course, also be attained via representatives Within the scope of PROFInet, this is particularly necessary for integrating non-PROFInet devices This means, in particular, that HMI systems that not offer PROFInet objects themselves may also use the benefits PROFInet provides for vertical integration (i.e towards the automation level) © Copyright by PNO 2003 - All rights reserved Page 1-8 PROFInet Architecture Description, Objects in Automation Version V2.0, January 2003 The event sink possesses a reference to the event source It is able to control whether or not it is invoked by the event source 1.5.3 Interconnecting Events and Data Analogously to the Block Concept In contrast to the two above-mentioned cooperation methods, in the block concept which is commonly used in the automation world none of the objects involved has reference to its partner during runtime Interconnection only takes place when the objects are used, and is performed completely from the outside This procedure offers the highest degree of decoupling between two RT Objects, since the code contains neither direct nor indirect references to the partners, and a free interconnection of data and events is possible that show different semantics from the perspective of the related creators and/or users A free interconnection with respect to events is only possible if these are 'binary events' A binary event does not carry any data in the form of parameters If, for example, the 'ReaktorFull()' method is used as an event at an 'outgoing interface', it can be interconnected with a 'Drain()' event of an 'incoming interface' The interconnection possibilities are restricted as soon as an event is linked with data (Event(para1, para2, )) In this case, the recipient of the event must provide the interface that matches exactly the parameter profile These two interconnection types are not provided in COM The COM event mechanism declared in the previous section only works if the interface definition is the same on both sides In addition to the identical parameter profiles, the output event and input event must also be of the same name This contradicts the concept of free interconnection The interconnection of RT Objects in analogy to the function blocks as it is outlined here can be defined as an extension of COM and is explained in detail in the chapters further below 1.6 Interrelation Between PROFInet and Other Standardization Activities The correlation between PROFInet and other Standardization Activities is shown in the following Chapters However, these comparisons employ PROFInet terms/concepts that will be introduced in Chapters and 1.6.1 PROFInet and OPC OPC (OLE for Process Control) has been established as the standard interface for the connection of PC applications (such as HMI systems) to the devices on process levels (chiefly PLC) Although PROFInet is fully OPC-compliant, it defines an additional functionality that goes beyond OPC Compliance (conformance, not approved compliance!) with the OPC standard6 is reached by the following points: • Each PROFInet node may also be addressed as an OPC server via a general intermediate layer • Each OPC server can be used as a PROFInet node via a standard adapter (OPC Objectizer) These concepts are explained in detail in the following sections The following sections are chiefly related to OPC Data Access © Copyright by PNO 2003 - All rights reserved Page 1-9 PROFInet Architecture Description, Objects in Automation 1.6.1.1 Version V2.0, January 2003 PROFInet as an Extension of OPC PROFInet additionally defines a functionality that goes beyond OPC This functionality is explained in detail in the individual chapters of these System Specifications In summary, these are: • OPC makes very few statements about the Engineering System7; it chiefly defines Runtime interfaces PROFInet also defines a standard for Engineering in order to enable different component manufacturers / tool manufacturers to produce compatible products • OPC defines interfaces for exactly specified function areas (e.g variable access) In addition, PROFInet defines a frame that specifies how own interfaces can be defined The programmer of a plc function block, for example, wants to provide the function block functionality via specific COM interfaces Predefined interfaces are not suitable for this purpose (the interface of a function block is defined by the programmer) • OPC is tag-oriented, not object-oriented This means that, for example, calling a method at an object is not possible Logging on for a notification at an object is not possible either (unless this is a change of value) This also shows in program technology The automation objects are handled as (tag) names only, not as COM objects Meaning that there is only access provided to tag names (variables) not containers (IKessel not provided): • Communicating with a representative in the PC instead of the device itself is one of the basic ideas of OPC The communication proper towards the device is proprietary Consequently, OPC is not suitable for communication between devices since this communication would always be routed via an intermediate PC Although devices have already appeared on the market that have the OPC interfaces implemented directly in the unit, the majority of the OPC servers will continue to be PC-based One of the PROFInet basic ideas says that the (illusions of the) COM objects live directly in the device Here, OPC is supported by PROFInet concepts DCOM as a uniform object bus, and IP as a uniform transport protocol provides the prerequisites of addressing OPC directly in the device 1.6.1.2 PROFInet Node as OPC Server Each PROFInet node can also be addressed as an OPC server via a general intermediate layer The basis functionality is already provided by the PROFInet Runtime implementation (in particular ACCO9) On the one hand it is conceivable that the OPC interfaces are implemented directly in the PROFInet node.10 On the other hand, an implementation in the PC - that is additionally enriched by engineering data - is also conceivable Due to the confined memory space, an OPC server in the PROFInet node does not know the symbolic names of the connecting points of its RT Autos, for example Since the interfaces to the PROFInet Runtime are standardized in the device, the OPC server in the PC could be developed as a standard component A browse interface is defined that permits the server's name space to be inquired OPC interfaces are not documented in these System Specifications They can be found in the corresponding documents of the OPC Foundation The exact functionality of the ACCO is described in Chapter The fact that ACCO is responsible for the exchange of data/events between PROFInet devices is all that is needed for a better understanding at this point 10 By its principle, this variant has the disadvantage that caching the data is not possible in an expedient way and that device-overlapping access is not possible either © Copyright by PNO 2003 - All rights reserved Page 1-10 PROFInet Architecture Description, Objects in Automation Version V2.0, January 2003 PC PC OPC Client OPC Client OPC Server ES data OPC Server ACCO PROFInet node ACCO PROFInet node Figure 1-5: PROFInet node as OPC server (alternatives) 1.6.1.3 OPC Objectizer Only a few devices will have the PROFInet RT model implemented during the PROFInet introduction phase Thus, it is desirable to use the multitude of OPC servers, that are available for almost every programmable controller and bus system, in the PROFInet context This enables an OPC server, for example, to be interconnected with a PROFInet device in the PROFInet ES system Communication proper to Runtime is of course routed via the PC But this is a general migration concept in PROFInet for devices that have not yet implemented the RT model This is achieved by the OPC Objectizer This is a component that implements a PROFInet device on the basis of an OPC server in the PC This component need only be implemented once and can then be used for all OPC servers Implementing the ACCO of the PROFInet runtime model (see Chapter 2) This part permits the external connection of components as it is described in Chapter 1.5.3 "Interconnecting Events and Data Analogously to the Block Concept" In the default structure, only one RT Auto can be reached via the ACCO of the OPC Objectizer This encapsulates the variable household of the OPC server It has all variables of the OPC server at its connecting points Additional configuration information (or utilizing assumptions of hierarchical variable names) can of course be used for providing the variable household via multiple RT Autos Determining which variables of the OPC server shall be offered via which interfaces is therefore the next configuration step This information is then made available to a generic engineering object Interconnection with the OPC variables, for example, is then possible via that object © Copyright by PNO 2003 - All rights reserved Page 1-11 PROFInet Architecture Description, Objects in Automation Version V2.0, January 2003 PC OPC objectizer ACCO OPC Server DCOM/IP proprietary communication PROFInet node device X ACCO Figure 1-6: OPC Objectizer The OPC Objectizer is a migration option for OPC servers to PROFInet The restrictions of this variant are shown in Chapter 1.6.1.1 "PROFInet as an Extension of OPC" (such as the disadvantages of a representative solution, the limitation to the functionality standardized by OPC, no special engineering support but a generic engineering representative, no event support, etc.) © Copyright by PNO 2003 - All rights reserved Page 1-12 PROFInet Architecture Description, Objects in Automation Version V2.0, January 2003 1.6.2 IEC 61499 as reference model for PROFInet 1.6.2.1 IEC 61499 – Distributed automation requires common standards A working group of the International Electrotechnical Committee (IEC 65 WG 6) started some years ago the new work item to define in a manufacturer spanning manner the interfaces and reference models for the upcoming distributed automation systems The state of the art PLC systems are based on the IEC 61131-3 standard from 1993 This PLC language standard offers a well recognized basis by defining a modular and hierarchical programming model for stand-alone (central) controllers The well-known concept of function blocks defined by IEC 61131-3 forms the basis of the new standard IEC 61499 “Function Blocks for distributed Automation Systems – Part 1: System Architecture” Part of IEC 61499 was published as IEC PAS (publicly available specification) end of 2000 PAS documents are published as “pre-standard” made available to the industry for evaluation and comments With this PAS the industrial automation industry is invited to gather experiences in the next two years in order to complete then the final standard by integrating the proposed improvements from the test period This standard does not define any new programming languages, but an universal systems architecture and a set of useful rules and guidelines for the “component based systems” in order to offer a consistent basis for other standardization groups and industrial consortia involved in various application technologies and specific field bus domains Part of IEC 61499 was recently published under the title “Software Tools Requirements” It contains detailed specifications of the “Document Type Definitions” for the exchange of library elements in the standardized XML language This new part is not yet considered in this system specification IEC 61499 and PROFInet have the following main goals in common: Distributed component based automation, manufacturer spanning engineering and open communication The following clauses substantiate the common features of the common concept and model but also explains some differences Those aspects which can improve the ability for the mapping of distributed solutions with technological modules onto the IEC standard will be forwarded as comments to the IEC PAS For some differences between the IEC standard and PROFInet which are kept by purpose the different scopes in the system model are explained 1.6.2.2 PROFInet is based on the IEC 61499 reference models The reference models of IEC 61499 form a hierarchy with multiple levels These models are all realized correspondingly in PROFInet The uppermost level of the hierarchy of the IEC 61499 models is called system model (Figure 1-7) The application program is distributed over a set of devices, which are interconnected via a communication network, e.g Ethernet The distributed application program controls the common process © Copyright by PNO 2003 - All rights reserved Page 1-13 PROFInet Architecture Description, Objects in Automation Version V2.0, January 2003 Communication network System Device Device Device Application program A Controlled process Figure 1-7: System model with distributed application program On the second level the device model (Figure 1-8) encompasses devices consisting in one or more resources on which the local parts of the distributed application program are executed Devices of different kind like PLC or PC may be included Also embedded controllers and intelligent field devices with specific firmware are typical for distributed systems The device of IEC 61499 with their included resources are called in PROFInet Physical Device which include Logical Devices Device/ Communication connections Physical Device Ressource / Logical Device Communication interface Res x Res y Application program Process interface Controlled process Figure 1-8: Device model with multiple resources In the next level the resource model (Figure 1-9) with the distributed application program is illustrated, which is composed of interconnected software objects They communicate within a device directly among each other or they have connections via the bus system In IEC 61499 these objects are called function blocks In PROFInet the corresponding term is automation object (function) © Copyright by PNO 2003 - All rights reserved Page 1-14 ... PROFINET CBA Architecture Description and Specification V 2.02 Document Identification: TC2-04-0001 File name: PN -CBA- Architecture_ 2202_V202_Oct04 Prepared by the PROFIBUS Working Group 10 ? ?PROFINET. .. photocopying and microfilm, without permission in writing from the publisher © Copyright PNO 2004 – All Rights Reserved page of pages TC2-04-0001 PROFINET CBA Architecture Description and Specification. .. PROFInet Architecture Description, Overview and Introduction Version V2.01, August 2003 Chapter 0: Overview and Introduction © Copyright by PNO 2003 - All rights reserved Page 0-1 PROFInet Architecture