PROFInet Architecture Description, Objects in Automation Version V2.0, January 2003 Device Device Res x Ressource / Logical Device Function block/ Automation object Res y Res z a c d b Figure 1-9: Resource model with distributed application The function blocks of IEC 61499 resp the automation objects (functions) of PROFInet are the “atomic” elements, i.e the not more divisible base elements, which are used for the engineering view and as the run time objects They consists in a body containing the executable algorithms and they have interconnectable external interfaces for input and output data Furthermore the function blocks resp the automation objects obtain a new kind of interface which is not existing for the function blocks of the PLC standard IEC 61131-3 The graphical editor Simatic iMap for PROFInet enables the project engineer to pick the automation objects from a library and places them in his chart on the screen Then the object types obtain their project specific names and become instances Afterwards the interfaces of the instances are connected by the graphically drawing of lines between the input and outputs Thus the communication links over the bus are implicitly projected The automation solutions with technological modules typically have a fixed association between the devices (resources) and the function blocks resp automation objects, i.e the associations are inherently existing in the library elements Therefore it is possible to load automatically the communication information and the instances without any additional engineering This loading is of course only necessary if the instances are not yet pre-programmed or loaded earlier into the device The devices with in the firmware implemented functionality are only loaded with the preset values and the communication information for the interconnections Event flow Data flow Figure 1-10: Application model with interconnections of data and events For a concise structuring of a larger application IEC 61499 defines the subapplication containing a subset of interconnected function blocks This subapplication may span also over multiple devices For PROFInet such a construct is also possible 1.6.2.3 Extensions and differences The differences of PROFInet and IEC 61499 can be divided in two categories The first category of differences are necessary to make the basis model of IEC 61499 more exact and clearer, or the features exceed the given of the IEC model The second category (see 1.6.2.3) is not discussed in this specification because these extensions are not in the current and also future scope of IEC 61499 © Copyright by PNO 2003 - All rights reserved Page 1-15 PROFInet Architecture Description, Objects in Automation 1.6.2.4 Version V2.0, January 2003 Mapping of the technological modularization It is an important principle of the PROFInet concept not to define any internal details of the automation components This “inner live” shall not be influenced by PROFInet The internal realization can be in the case of a PLC a task model with function blocks according IEC 61131-3 in the case of other devices it can be a functionality programmed in C language The idea is to adopt the internal implementation of the functionality of the automation component as it stands Vendor independent Vendor specific PROFInet Connection Editor Vendor specific Vendor specific Programming Programming Programming Configuration Configuration Configuration Parameterization Parameterization Parameterization Vendor B Vendor A Vendor C PROFIBUS PROFIBUS Fieldbus X Figure 1-11: Manufacturer spanning engineering The same principle is also applicable for the corresponding engineering tools, i.e the programming, configuring and parameterization of a device like a PLC can be achieved with the today available engineering tools which are mostly IEC 61131-3 conformant programming systems like Simatic Step Therefore PROFInet defines exclusively the external interface of the components and not the internal realization Such an encapsulation of the functionality supports directly automation solutions with technological modularization, since for the interaction of the modules only the external interfaces are significant and not the internal implementation IEC 61499 permits in principle such an encapsulation of the algorithms, however in the current PAS it is not especially emphasized For the mapping of PROFInet the various characteristics of the term function block in IEC 61499 have also be taken into account (Figure 1-12) Function block (generic term) Function block (Execution control + IEC 61131 –3) Service Interface Function Block (SIFB) (generic term for incapsulated FBs) Service interface Function Block (SIFB) (incapsulated application FB) Service Interface Function Block (SIFB) (Driver FB) Figure 1-12: Various characteristics of the IEC 61499 functions blocks • Function block (FB): On the one hand this term is used by IEC 61499 as the generic term for all kinds of blocks on the © Copyright by PNO 2003 - All rights reserved Page 1-16 PROFInet Architecture Description, Objects in Automation Version V2.0, January 2003 other hand it is used for a specific characteristic of a function block where the internals are defined by the Event Control Chart (ECC) for the execution control and by an IEC 61131-3 programming language for the control algorithms (Figure 1-13) Here the incoming events provoke corresponding state transitions of the execution control, which activate the algorithms programmed in IEC 61131-3 and sends outgoing events when appropriate For these function blocks also the internal model of execution and programming is defined by IEC 61499 State diagram, Event Control Chart Event flow Execution control (hidden) Data flow Algorithms (hidden) Internal Data (hidden) Programming and data declaration according IEC 61131-3 Figure 1-13: Function block according IEC 61499 As described above PROFInet does not make any provisions about the internal implementation, thus the implementation with execution control and IEC 61131 are also permitted, however this does not have any particular position • Service Interface Function Blocks (SIFB): This IEC 61499 term identifies function blocks whose internal implementation is unknown There is no distinction between SIFB which encapsulate application programs and those who act as “driver blocks” e.g as interface to the controlled process The application oriented SIFB are equivalent to the automation objects (functions) of PROFInet However the “Driver SIFB“ are not part of PROFInet, because they belong to the internal realization For the ability of the mapping of IEC 61499 onto the technological modularization the specification of the internal realization of a function block with the execution control and the IEC 61131 programming is not required This applies also to the definition of “driver SIFB” Such specifications of internals should not be part of the mandatory set of the standard, but shall be defined in an optional part of the specification 1.6.2.5 Interconnections among the blocks (functions) The interconnection between function blocks - in PROFInet called functions - is accomplished in IEC 61499 by events and data Here the event is relevant, i.e when a new event arrives an internal algorithms is invoked Data may be combined with the event This is graphically represented by a line and some connection points, however this graphic is only for illustration purpose and not imperatively required by the standard like all other graphical representations The combination of event with data can be made on the input and the output side, and therefore different variants are possible Typically an event from the output side and the associated data of an IEC function block are combined and connected with another IEC function block on its input side At the receiver side the event and the associated data are combined as well (Figure1-14a) Further variants are illustrated in Figure 1-14 b, c, d © Copyright by PNO 2003 - All rights reserved Page 1-17 PROFInet Architecture Description, Objects in Automation Version V2.0, January 2003 Events data a) b) c) d) Figure 1-14: Combinations of events with data PROFInet restricts the degree of freedom for the combination of events and data (Figure 1-15) IEC 61499 PROFInet Events Event with data f p1 p2 f(p1, p2) g g(q1, q2) q1 q2 Data Figure 1-15: PROFInet supports events with data For PROFInet an event always has a set of parameters which has to match on the sender and receiver side The parameters (data) of the event not have to be available as individually handled pieces of information at the external interface of the function This restriction was done as a simplification for the project engineer since the mentioned degree of freedom offered by IEC 61499 is required only in very few application cases Another extension in PROFInet is the interconnection of data without an event (Figure 1-16) © Copyright by PNO 2003 - All rights reserved Page 1-18 PROFInet Architecture Description, Objects in Automation Version V2.0, January 2003 Figure 1-16: Data interconnections Data connection between function blocks are a well established concept defined by IEC 61131-3 PROFInet extends this concept in a device spanning aspect This facilitates the stepwise introduction of a new concept since it extends the already existing paradigm “data connection” and it offers the new paradigm “event connection” as an option 1.6.2.6 Mapping of the communication IEC 61499 typically presumes an IEC 61131 function block model in the devices Therefore specific communication function blocks have to be utilized for the implementation of the device spanning interconnections on the sender and receiver side (Figure 1-17) The installation of communication function blocks can be done explicitly by the user or automatically by the engineering tool The details of the communication are not element of the normative part of IEC 61499, since they should be specified by other standardization bodies or user organizations For this purpose IEC 61499 supplies application examples in the annex Mounting of communication function blocks Publish Subscribe Figure 1-17: Communication function block with IEC 61499 © Copyright by PNO 2003 - All rights reserved Page 1-19 PROFInet Architecture Description, Objects in Automation Version V2.0, January 2003 PROFInet takes a slightly different approach As explained above PROFInet does not make any provisions about the internal realization within the devices, i.e it does not presumes a specific block model However PROFInet defines a run time model whose external interface is implemented by all devices (Figure 1-18) Physical Device (=Hardware) Physical Device * ACCO Logical Device 1 * RT-Auto Logical Device (=Software) Figure 1-18: Class diagram of PROFInet An important element of the run time model is the ACCO object (Active Control Connection Object) This object implements a consumer-provider model at run time for the interconnections, i.e the device spanning communication relations specified in the engineering can be directly loaded into the devices For these interconnections PROFInet also defines the behavior in the error case: • Additional transmission of validity information (quality code) and optional time stamp with values • Output of substitute values in error case • Monitoring of the communication partner • Restart after loss of connection • Ability of diagnosis and test for interconnections Consequently the specifications of PROFInet substantiate the generic model of the interconnections of the IEC 61499 function blocks These specifications are required to embrace the practice in term of interoperability of devices in a distributed automation solution 1.6.2.7 Extensions of PROFInet exceeding the scope of IEC 61499 The PROFInet specification comprises also some areas exceeding the scope of IEC 61499 From PROFInet view they are necessary for a comprehensive concept of distributed automation They should be briefly listed here: • Engineering of the network topology, in particular multiple network types, e.g PROFIBUS and Ethernet • Proxy model, i.e inclusion of the existing bus systems without change of the protocol or the device • Real time communication • Manufacturer specific supplementations of the engineering for parameters, diagnosis etc • Support of technological components containing also elements of HMI or documentation besides the control elements Further supplements like e.g network management and web integration are already incorporated in the planning of the PNO working groups © Copyright by PNO 2003 - All rights reserved Page 1-20 PROFInet Architecture Description, Runtime Model Version V2.02 – February 2nd, 2004 Chapter 2: PROFInet Runtime Model © Copyright by PNO 2004 - All rights reserved Page 2-1 PROFInet Architecture Description, Runtime Model Version V2.02 – February 2nd, 2004 Contents PROFINET RUNTIME MODEL 2-15 2.1 COM TERMS 2-15 2.1.1 Interface and Implementation 2-15 2.1.2 Properties 2-15 2.1.3 Methods 2-16 2.1.4 Events 2-16 2.1.5 Dispatch Interface 2-16 2.1.6 Communication Paths and Marshaling 2-16 2.1.7 IUnknown 2-17 2.1.7.1 Resource Management: IUnknown::AddRef, IUnknown::Release 2-18 2.1.7.2 Type Coercion: IUnknown::QueryInterface 2-18 2.1.8 Inheritance 2-18 2.2 RUNTIME OBJECT MODEL 2-19 2.2.1 Object Illusion 2-21 2.2.2 Basic Rules for Interface Definitions 2-22 2.2.3 Visual Basic Deficits 2-22 2.2.3.1 Using Automation Data Types 2-22 2.2.3.2 S-Codes as Return Values 2-24 2.2.3.3 Automation Wrapper 2-24 2.2.4 Instantiation of PROFInet Runtime Objects 2-25 2.2.5 Navigation in the Object Model 2-26 2.2.6 Life Cycle of PROFInet Runtime Objects 2-26 2.2.7 Definitions for the IDispatch Implementation 2-27 2.2.8 Definitions for Identifiers 2-27 2.2.8.1 Character Set Type 2-27 2.2.8.2 Character Set Type 2-28 2.2.8.3 Character Set Type 2-28 2.2.8.4 Common Definitions 2-28 2.2.8.5 Definitions for Domain Names 2-29 2.2.8.6 Usage of Character Sets 2-29 2.2.9 Definitions for Event Interfaces 2-29 2.2.10 Definitions for Properties 2-30 2.2.11 Extended Type Description 2-30 2.2.12 Additional Definitions for Structures 2-31 2.2.13 Security Aspects of PROFInet Runtime Components 2-32 2.2.13.1 COM Activation Security 2-33 2.2.13.2 COM Call Security 2-33 2.2.13.2.1 Explicit Call to CoInitializeSecurity 2-33 2.2.13.2.2 Implicit Call to CoInitializeSecurity 2-33 2.2.13.2.3 Visual Basic and Call Security 2-34 2.2.13.2.4 Scripts and Call Security 2-34 2.2.13.3 PROFInet Security Model 2-34 2.2.14 Interaction with Windows Systems 2-34 2.2.15 Optimizing Network Performance 2-35 2.2.16 Script Integration without Installation 2-37 2.2.17 Plug & Play 2-37 2.2.18 Baptism 2-37 2.2.19 Handling the Runtime Object Model 2-37 2.2.20 Supplying PROFInet Proxy Stub and PC PDev Software 2-38 2.2.21 Component Description and Type Library 2-39 2.3 INCLUDING NON–PROFINET COMPONENTS 2-40 2.4 INTERFACES OF THE RUNTIME COMPONENTS 2-43 2.5 IDENTIFICATION AND NAVIGATION 2-46 2.6 OPERATING STATE 2-47 2.6.1 ICBAStateEvent – Operating State Messages 2-48 2.7 DATE AND TIME 2-50 2.8 DIAGNOSIS 2-51 2.8.1 Motivation 2-51 © Copyright by PNO 2004 - All rights reserved Page 2-2 PROFInet Architecture Description, Runtime Model Version V2.02 – February 2nd, 2004 User Perspective 2-52 2.8.2 2.8.3 Diagnosis Interface 2-53 2.8.4 Common Diagnosis 2-54 2.8.5 Detailed Diagnosis 2-55 2.8.6 Proprietary Diagnosis 2-57 2.8.7 Typical Device Faults 2-57 2.8.8 Monitoring 2-58 2.9 REPORTING 2-58 2.10 PARAMETER VALUE ASSIGNMENT 2-58 2.11 UPLOAD AND DOWNLOAD 2-59 2.12 ON-LINE / OFF-LINE COMPARISON 2-60 2.12.1 PDev Stamp 2-60 2.12.2 ACCO Stamp 2-61 2.12.3 LDev Stamp 2-61 2.12.4 Code / Configuration Data Stamp 2-61 2.13 INTERCONNECTING RTAUTOS – CBAACCO 2-63 2.13.1 Motivation 2-63 2.13.2 Architecture 2-64 2.13.3 Short Overview 2-65 2.13.3.1 Establishing connections 2-65 2.13.3.2 Productive Operation of Data Connections 2-66 2.13.3.3 Productive Operation of Event Connections 2-67 2.13.4 Definitions 2-67 2.13.4.1 Configuration Data Base 2-67 2.13.4.2 Rules for Connections 2-68 2.13.4.3 Definition of the Identifiers 2-69 2.13.4.3.1 Identifier for an LDev 2-69 2.13.4.3.2 Identifier for an RTAuto Member 2-69 2.13.4.3.3 Identifier for a System Member 2-70 2.13.4.3.4 Identifiers for accessing Sub elements 2-71 2.13.4.4 Data Types 2-73 2.13.4.5 Quality of Service (QoS) 2-75 2.13.4.6 Dead Band and Epsilon Value 2-77 2.13.4.7 Version of a connection 2-79 2.13.4.8 Substitute Values 2-79 2.13.4.9 Quality Code 2-80 2.13.4.9.1 Definitions in PROFInet 2-80 2.13.4.9.2 Standard Behavior 2-82 2.13.4.9.3 Startup of a Connection 2-83 2.13.4.9.4 Communication Fault of a Connection 2-83 2.13.4.9.5 Connection is cleared 2-84 2.13.4.9.6 Connection is deactivated 2-84 2.13.4.9.7 Transfer of „Incorrect” Connection Data 2-84 2.13.4.9.8 Provider in „CBAReady” State 2-85 2.13.4.9.9 Clearing an Object from the Provider 2-86 2.13.4.9.10 Connection is forced 2-86 2.13.4.9.11 QoS Violation 2-87 2.13.4.9.12 Write Access to Values via PropertyPut or WriteItem 2-87 2.13.4.9.13 Encoding the Quality Code 2-87 2.13.4.9.14 Component-Overlapping Quality Code 2-90 2.13.4.9.15 Property Access and Quality Code 2-91 2.13.4.9.16 OPC Server and Quality Code (OPC Quality flags) 2-92 2.13.4.10 Operating state 2-93 2.13.4.11 Power-On 2-93 2.13.4.12 Persistence 2-94 2.13.4.13 Online–/Offline Comparison of the Connections 2-96 2.13.5 Communication Channels 2-97 2.13.5.1 Configuration 2-97 2.13.5.2 DCOM 2-97 2.13.5.2.1 Context Management 2-97 © Copyright by PNO 2004 - All rights reserved Page 2-3 PROFInet Architecture Description, Runtime Model Version V2.02 – February 2nd, 2004 2.13.5.2.2 QoS 2-98 2.13.5.2.3 QoS Violation 2-98 2.13.5.2.4 Connection Monitoring 2-99 2.13.5.2.4.1 Connection Monitoring by the Consumer 2-99 2.13.5.2.4.2 Connection Monitoring by the Provider 2-100 2.13.5.2.5 UML Model 2-100 2.13.5.3 SRT 2-100 2.13.5.3.1 Definitions 2-100 2.13.5.3.2 Application Relations and Communication Relations 2-101 2.13.5.3.3 Using SRT 2-103 2.13.5.3.3.1 SRT Variants 2-103 2.13.5.3.3.2 Segmentation 2-103 2.13.5.3.3.3 SRT Cycle Time and QoS Value 2-103 2.13.5.3.3.4 QoS Violation 2-104 2.13.5.3.3.5 Connection Monitoring 2-104 2.13.5.3.3.5.1 Connection Monitoring by the Consumer 2-104 2.13.5.3.3.5.2 Connection Monitoring by the Provider 2-105 2.13.5.3.3.6 IP Address and MAC Address 2-106 2.13.5.3.4 UML Model 2-108 2.13.5.3.4.1 Remote Interactions 2-108 2.13.5.3.4.2 State Machine for Application Relations 2-108 2.13.5.3.4.2.1 Consumer 2-110 2.13.5.3.4.2.2 Provider 2-111 2.13.5.3.4.3 State Machine for AccoDataCR 2-111 2.13.5.3.4.3.1 Consumer 2-112 2.13.5.3.4.3.2 Provider 2-112 2.13.5.3.4.3.3 Establishing the AccoDataCR 2-113 2.13.5.4 Local 2-114 2.13.5.4.1 QoS 2-115 2.13.5.4.2 QoS Violation 2-116 2.13.5.5 Constant 2-116 2.13.6 ACCO Management Operation 2-116 2.13.6.1 Overview 2-116 2.13.6.1.1 Tasks of the Consumer 2-116 2.13.6.1.2 Tasks of the Provider 2-116 2.13.6.2 Establishing Connections 2-117 2.13.6.2.1 Connections with a Constant 2-117 2.13.6.2.2 Negotiating with the Provider – Common Definitions 2-118 2.13.6.2.2.1 Connect Attempt 2-119 2.13.6.2.2.2 Signature Identity Check 2-120 2.13.6.2.2.2.1 Signature Identity Check for Data Connections (PROFInet Version 1)2-120 2.13.6.2.2.2.2 Signature Identity Check for Data Connections (PROFInet Version 2)2-121 2.13.6.2.2.2.3 Signature Identity Check for Event Connections 2-121 2.13.6.2.3 Negotiating with the Provider – DCOM 2-121 2.13.6.2.4 Negotiating with the Provider – SRT 2-122 2.13.6.2.4.1 Reconfiguration 2-123 2.13.6.2.4.1.1 Motivation 2-123 2.13.6.2.4.1.2 Algorithm 2-123 2.13.6.2.5 Negotiating with the Provider – Local 2-123 2.13.6.2.6 Negotiating with the Provider – Constant 2-124 2.13.6.3 Changing Connections 2-124 2.13.6.4 Clearing Connections 2-124 2.13.6.4.1 Negotiating with the Provider – DCOM 2-124 2.13.6.4.2 Negotiating with the Provider – SRT 2-124 2.13.6.4.3 Negotiating with the Provider – Local 2-124 2.13.6.4.4 Negotiating with the Provider – Constant 2-125 2.13.6.5 Activating and Deactivating Connections 2-125 2.13.6.5.1 Negotiating with the Provider – DCOM 2-125 2.13.6.5.2 Negotiating with the Provider – SRT 2-125 2.13.6.5.3 Negotiating with the Provider – Local 2-125 © Copyright by PNO 2004 - All rights reserved Page 2-4 PROFInet Architecture Description, Runtime Model Version V2.02 – February 2nd, 2004 2.13.6.5.4 Negotiating with the Provider – Constant 2-126 2.13.7 Productive Operations of Connections 2-126 2.13.7.1 Productive Operation for Data Connections 2-126 2.13.7.1.1 DCOM Channel 2-126 2.13.7.1.2 SRT Channel 2-127 2.13.7.1.3 Local Channel 2-128 2.13.7.2 Productive Operation for Event Connections 2-128 2.13.7.3 Format for Connection Data 2-129 2.13.7.3.1 DCOM Channel Item Header 2-129 2.13.7.3.2 SRT Channel Item Header 2-130 2.13.7.3.3 Data 2-130 2.13.7.3.4 Serialization of Values and Parameters 2-131 2.13.7.3.4.1 Restrictions for the DCOM channel 2-131 2.13.7.3.4.2 Restrictions for the SRT channel 2-132 2.13.7.3.5 Serialization of Time Stamps 2-132 2.13.7.3.6 DCOM Peculiarities 2-133 2.13.7.3.7 SRT Peculiarities 2-133 2.13.7.4 Productive Operation (SRT) 2-134 2.13.7.5 Fault Scenarios 2-134 2.13.7.5.1 Error Classification 2-134 2.13.7.5.2 Time Intervals 2-136 2.13.7.5.3 Packet Duplication 2-136 2.13.7.5.4 Packet Loss 2-136 2.13.7.5.5 Garbled Data 2-136 2.13.7.5.6 Sequence Switching 2-136 2.13.7.5.7 Recycling Frames 2-137 2.13.7.5.8 Failure of the Provider in Productive Operation 2-137 2.13.7.5.8.1 DCOM Communication Channel 2-137 2.13.7.5.8.2 SRT Communication Channel 2-138 2.13.7.5.9 Failure of the Consumer in Productive Operation 2-140 2.13.7.5.9.1 DCOM Communication Channel 2-140 2.13.7.5.9.2 SRT Communication Channel 2-141 2.13.7.5.10 Unilateral Communication Failure Recognition during Productive Operation2-142 2.13.7.5.10.1 DCOM Communication Channel 2-142 2.13.7.5.10.2 SRT Communication Channel 2-142 2.13.7.5.11 Failure of the Provider during Negotiation 2-143 2.13.7.5.12 Transmission of Garbled Data 2-144 2.13.8 Connection Diagnosis 2-144 2.13.8.1 User Perspective 2-144 2.13.8.2 Status Model for the Common Diagnosis 2-145 2.13.8.3 Status Model for the Detailed Diagnosis 2-146 2.13.8.4 Diagnosis Information from the Consumer 2-149 2.13.8.5 Diagnosis Information from the Provider 2-149 2.13.8.6 GetDiagnosis Method 2-149 2.13.8.6.1 Common Definitions 2-149 2.13.8.6.2 Function 0: PROFInet Function Directory 2-150 2.13.8.6.3 Function 0x1000: Performance Characteristics 2-150 2.13.8.6.4 Function 0x2000: Statistics Reset 2-151 2.13.8.6.5 Function 0x3000: Consumer Communication Events Statistic 2-151 2.13.8.6.6 Function 0x4000: Provider Communication Events Statistic 2-152 2.13.8.7 Outside View 2-152 2.13.8.8 Inside View 2-152 2.13.8.9 Influencing Testing 2-152 2.13.8.9.1 Forcing 2-152 2.13.9 Synchronous Read / Write 2-154 2.13.9.1 Synchronous Access 2-154 2.13.10 HMI and ACCO 2-154 2.14 OPERATORS 2-155 2.14.1 Motivation 2-155 2.14.2 Operators to Data Connections 2-155 © Copyright by PNO 2004 - All rights reserved Page 2-5 PROFInet Architecture Description, Runtime Model Version V2.02 – February 2nd, 2004 2.14.3 Operators to Event Connections 2-156 2.15 APPLICATION FUNCTIONALITY – RTAUTO 2-157 2.15.1 Possible Implementation Methods 2-158 2.15.1.1 Fixed Functionality 2-158 2.15.1.2 Loadable Functionality 2-158 2.15.2 Implementation of the Property Access Functions 2-160 2.15.3 Event Functionality 2-163 2.16 INTEGRATION OF PROFIBUS DP-SLAVES 2-164 2.16.1 Motivation 2-164 2.16.1.1 Object World and Station Failure 2-166 2.16.2 Tasks of the Proxy 2-167 2.16.3 Views 2-167 2.16.4 Decoupling Host and Componentized Slave 2-168 2.16.5 Proxy for LDev 2-169 2.16.5.1 Identification and Browse 2-169 2.16.5.2 Diagnosis 2-170 2.16.5.3 Operating State 2-170 2.16.5.4 Interface Implementation 2-171 2.16.5.5 Limitations for Programmable DP Slaves 2-172 2.16.6 Proxy for an RTAuto 2-172 2.16.6.1 Property Access 2-173 2.16.6.1.1 Property Access and Station Failure 2-174 2.16.6.1.2 Property Access and Pulled Modules 2-175 2.16.6.1.3 Property Access and DP Master in CLEAR State 2-175 2.16.6.1.4 Overview 2-177 2.16.6.2 DP Mapping 2-179 2.16.6.2.1 View of the DP Master 2-179 2.16.6.3 View of the DP Slave 2-179 2.16.6.3.1 Simple DP Slaves of a Fixed Functionality 2-180 2.16.6.3.2 Complex DP Slaves of a Fixed Functionality 2-181 2.16.6.3.3 Programmable DP Slaves 2-181 2.16.6.4 PROFIBUS Data Types vs Automation Data Types 2-181 2.16.7 Proxy for ACCO 2-183 2.16.8 Open Points 2-183 2.16.8.1 DPV1 Integration 2-183 2.16.8.1.1 Data Records 2-183 2.16.8.1.2 Alarms 2-184 2.16.8.2 DPV2 Integration 2-184 2.16.8.3 PROFInet Master Profile 2-184 2.16.8.4 Lateral Communication 2-184 2.17 SYSTEM RTAUTO 2-185 2.17.1 Motivation 2-185 2.17.2 Requirements 2-185 2.17.3 Engineering View 2-185 2.18 PERFORMANCE CHARACTERISTICS 2-186 2.18.1 Motivation 2-186 2.18.2 Assurances 2-186 2.18.2.1 Constant, Local and SRT Connections 2-186 2.18.2.2 DCOM Connections 2-187 2.18.3 Device Parameters 2-187 2.18.4 ES / RT Parameter Set 2-189 2.18.4.1 Overview 2-189 2.18.4.2 General Parameters 2-189 2.18.4.3 Connection Relations 2-190 2.18.4.4 Communication Channels 2-195 2.18.4.4.1 General Definitions 2-195 2.18.4.4.2 Property Size 2-195 2.18.4.4.3 SRT Frame Costs according to Data Type 2-196 2.18.4.5 Constant Channel 2-196 2.18.4.6 Local Channel 2-197 © Copyright by PNO 2004 - All rights reserved Page 2-6 PROFInet Architecture Description, Runtime Model Version V2.02 – February 2nd, 2004 2.18.4.7 SRT Channel 2-198 2.18.4.8 DCOM Channel 2-201 2.18.4.9 DCOM HMI Connections Parameter 2-203 2.18.4.10 DCOM Status Connection Parameters 2-203 2.18.4.11 Further Device Parameters 2-204 2.18.5 Assessment of RT Parameter Set in Version 2.0 2-204 2.18.6 Rules for ES systems 2-205 2.18.6.1 Client Best Practice Patterns 2-205 2.18.6.2 Timeouts for method calls 2-205 2.19 CLASSES 2-207 2.19.1 CBAPhysicalDevice 2-207 2.19.2 CBALogicalDevice 2-207 2.19.3 CBAACCO 2-207 2.19.4 RTAuto 2-207 2.20 INTERFACE DESCRIPTIONS 2-208 2.20.1 ICBAPhysicalDevice 2-208 2.20.1.1 ICBAPhysicalDevice::get_Producer 2-208 2.20.1.2 ICBAPhysicalDevice::get_Product 2-209 2.20.1.3 ICBAPhysicalDevice::get_SerialNo 2-209 2.20.1.4 ICBAPhysicalDevice::get_ProductionDate 2-210 2.20.1.5 ICBAPhysicalDevice::Revision 2-211 2.20.1.6 ICBAPhysicalDevice::get_LogicalDevice 2-211 2.20.2 ICBAPhysicalDevice2 2-213 2.20.2.1 ICBAPhysicalDevice2::Type 2-213 2.20.2.2 ICBAPhysicalDevice2::PROFInetRevision 2-214 2.20.2.3 ICBAPhysicalDevice2::get_PDevStamp 2-215 2.20.3 ICBABrowse 2-216 2.20.3.1 ICBABrowse::get_Count 2-216 2.20.3.2 ICBABrowse::BrowseItems 2-217 2.20.4 ICBABrowse2 2-218 2.20.4.1 ICBABrowse2::get_Count2 2-218 2.20.4.2 ICBABrowse2::BrowseItems2 2-219 2.20.5 ICBAPersist 2-221 2.20.5.1 ICBAPersist::Save 2-221 2.20.6 ICBAPersist2 2-222 2.20.6.1 ICBAPersist2::Save2 2-222 2.20.7 ICBAPhysicalDevicePC 2-224 2.20.7.1 ICBAPhysicalDevicePC::AddLogicalDevice 2-224 2.20.7.2 ICBAPhysicalDevicePC::RemoveLogicalDevice 2-225 2.20.7.3 ICBAPhysicalDevicePC::AdvisePDevPC 2-225 2.20.7.4 ICBAPhysicalDevicePC::UnadvisePDevPC 2-226 2.20.8 ICBAPhysicalDevicePCEvent 2-227 2.20.8.1 ICBAPhysicalDevicePCEvent::OnLogicalDeviceAdded 2-227 2.20.8.2 ICBAPhysicalDevicePCEvent::OnLogicalDeviceRemoved 2-228 2.20.9 ICBALogicalDevice 2-229 2.20.9.1 ICBALogicalDevice::get_Name 2-229 2.20.9.2 ICBALogicalDevice::get_Producer 2-230 2.20.9.3 ICBALogicalDevice::get_Product 2-230 2.20.9.4 ICBALogicalDevice::get_SerialNo 2-231 2.20.9.5 ICBALogicalDevice::get_ProductionDate 2-232 2.20.9.6 ICBALogicalDevice::Revision 2-232 2.20.9.7 ICBALogicalDevice::get_ACCO 2-233 2.20.9.8 ICBALogicalDevice::get_RTAuto 2-233 2.20.10 ICBALogicalDevice2 2-234 2.20.10.1 ICBALogicalDevice2::PROFInetRevision 2-235 2.20.10.2 ICBALogicalDevice2::ComponentInfo 2-235 2.20.11 ICBAState 2-236 2.20.11.1 ICBAState::get_State 2-237 2.20.11.2 ICBAState::Activate 2-237 2.20.11.3 ICBAState::Deactivate 2-238 © Copyright by PNO 2004 - All rights reserved Page 2-7 PROFInet Architecture Description, Runtime Model Version V2.02 – February 2nd, 2004 2.20.11.4 ICBAState::Reset 2-238 2.20.11.5 ICBAState::AdviseState 2-239 2.20.11.6 ICBAState::UnadviseState 2-239 2.20.12 ICBAStateEvent 2-241 2.20.12.1 ICBAStateEvent::OnStateChanged 2-241 2.20.13 ICBATime 2-242 2.20.13.1 ICBATime::get_Time 2-242 2.20.13.2 ICBATime::put_Time 2-243 2.20.14 ICBAGroupError 2-244 2.20.14.1 ICBAGroupError::GroupError 2-244 2.20.14.2 ICBAGroupError::AdviseGroupError 2-245 2.20.14.3 ICBAGroupError::UnadviseGroupError 2-246 2.20.15 ICBAGroupErrorEvent 2-247 2.20.15.1 ICBAGroupErrorEvent::OnGroupErrorChanged 2-247 2.20.16 ICBAAccoMgt 2-248 2.20.16.1 ICBAAccoMgt::AddConnections 2-248 2.20.16.2 ICBAAccoMgt::RemoveConnections 2-250 2.20.16.3 ICBAAccoMgt::ClearConnections 2-251 2.20.16.4 ICBAAccoMgt::SetActivationState 2-252 2.20.16.5 ICBAAccoMgt::GetInfo 2-253 2.20.16.6 ICBAAccoMgt::GetIDs 2-253 2.20.16.7 ICBAAccoMgt::GetConnections 2-254 2.20.16.8 ICBAAccoMgt::ReviseQoS 2-256 2.20.16.9 ICBAAccoMgt::get_PingFactor 2-256 2.20.16.10 ICBAAccoMgt::put_PingFactor 2-257 2.20.16.11 ICBAAccoMgt::get_CDBCookie 2-258 2.20.17 ICBAAccoMgt2 2-259 2.20.17.1 ICBAAccoMgt2::GetConsIDs 2-259 2.20.17.2 ICBAAccoMgt2::GetConsConnections 2-260 2.20.17.3 ICBAAccoMgt2::DiagConsConnections 2-261 2.20.17.4 ICBAAccoMgt2::GetProvIDs 2-262 2.20.17.5 ICBAAccoMgt2::GetProvConnections 2-263 2.20.17.6 ICBAAccoMgt2::GetDiagnosis 2-264 2.20.18 ICBAAccoCallback 2-266 2.20.18.1 ICBAAccoCallback::OnDataChanged 2-266 2.20.19 ICBAAccoCallback2 2-267 2.20.19.1 ICBAAccoCallback2::Gnip 2-267 2.20.20 ICBAAccoServer 2-268 2.20.20.1 ICBAAccoServer::Connect 2-268 2.20.20.2 ICBAAccoServer::Disconnect 2-270 2.20.20.3 ICBAAccoServer::DisconnectMe 2-271 2.20.20.4 ICBAAccoServer::SetActivation 2-271 2.20.20.5 ICBAAccoServer::Ping 2-272 2.20.21 ICBAAccoServer2 2-274 2.20.21.1 ICBAAccoServer2::Connect2 2-274 2.20.22 ICBAAccoServerSRT 2-277 2.20.22.1 ICBAAccoServerSRT::ConnectCR 2-277 2.20.22.2 ICBAAccoServerSRT::DisconnectCR 2-280 2.20.22.3 ICBAAccoServerSRT::Connect 2-280 2.20.22.4 ICBAAccoServerSRT::Disconnect 2-282 2.20.22.5 ICBAAccoServerSRT::DisconnectMe 2-283 2.20.22.6 ICBAAccoServerSRT::SetActivation 2-284 2.20.23 ICBAAccoSync 2-285 2.20.23.1 ICBAAccoSync::ReadItems 2-285 2.20.23.2 ICBAAccoSync::WriteItems 2-286 2.20.23.3 ICBAAccoSync::WriteItemsQCD 2-288 2.20.24 ICBARTAuto 2-290 2.20.24.1 ICBARTAuto::get_Name 2-290 2.20.24.2 ICBARTAuto::Revision 2-291 2.20.25 ICBARTAuto2 2-292 © Copyright by PNO 2004 - All rights reserved Page 2-8 PROFInet Architecture Description, Runtime Model Version V2.02 – February 2nd, 2004 2.20.25.1 ICBARTAuto2::ComponentInfo 2-292 2.20.26 ICBASystemProperties 2-294 2.20.26.1 ICBASystemProperties::get_StateCollection 2-294 2.20.26.2 ICBASystemProperties::get_StampCollection 2-295 2.20.27 PROFInet Runtime IDL Specification 2-296 2.20.27.1 Basic Information 2-296 2.20.27.2 Error Messages 2-297 2.20.27.3 Interface Definitions for the PROFInet Device 2-309 © Copyright by PNO 2004 - All rights reserved Page 2-9 PROFInet Architecture Description, Runtime Model Version V2.02 – February 2nd, 2004 Figures Figure 2-1: InProc call 2-17 Figure 2-2: InterProc or Remote call 2-17 Figure 2-3: Runtime object model 2-19 Figure 2-4: Relationship between Engineering and Runtime 2-20 Figure 2-5: Automation Wrapper 2-25 Figure 2-6: Navigation in the runtime object model 2-26 Figure 2-7: Inclusion of non-PROFInet devices 2-41 Figure 2-8: Interfaces 2-43 Figure 2-9: Operating state block diagram 2-47 Figure 2-10: Typical operating state block diagram with sub-states 2-48 Figure 2-11: On-line view of the device diagram 2-53 Figure 2-12: Diagnosis procedure 2-53 Figure 2-13: Information levels 2-54 Figure 2-14: Device status model for the common diagnosis 2-54 Figure 2-15: Events in common diagnosis 2-55 Figure 2-16: Convenience information (brief information) for the device 2-56 Figure 2-17: Convenience information (long information) for the device 2-57 Figure 2-18: Possible User Perspective 2-63 Figure 2-19: Consumer and provider of a connection 2-64 Figure 2-20: ACCO structure 2-65 Figure 2-21: Productive operation of data connections 2-66 Figure 2-22: Productive operation of event connections15 2-67 Figure 2-23: Quality code transfer – standard behavior 2-82 Figure 2-24: Startup of a Connection 2-83 Figure 2-25: Quality code with communication fault 2-83 Figure 2-26: Quality code when a connection is cleared 2-84 Figure 2-27: Quality code when a connection is deactivated 2-84 Figure 2-28: Quality Code during the transfer of „incorrect” connection data 2-85 Figure 2-29: Quality code for provider in „CBAReady” state 2-86 Figure 2-30: Clearing an object from the provider 2-86 Figure 2-31: Quality code when a connection is forced 2-87 Figure 2-32: Quality Code at QoS violation 2-87 Figure 2-33: QoS and DCOM Communication Channel 2-98 Figure 2-34: Monitoring the providers heartbeat 2-99 Figure 2-35: Communication Stack for PROFInet Devices 2-101 Figure 2-36: Application Relations between PROFInet Devices 2-102 Figure 2-37: Communication Relations 2-102 Figure 2-38: Communication Channel SRT 2-104 Figure 2-39: Logical network view of PROFInet devices 2-106 Figure 2-40: DCOM and ACP Interaction between Provider and Consumer 2-108 Figure 2-41: State Machine ARSRT – Consumer 2-110 Figure 2-42: State Machine ARSRT – provider 2-111 Figure 2-43: State Machine AccoDataCR – Consumer 2-112 Figure 2-44: State Machine AccoDataCR – Provider 2-112 Figure 2-45: SRT Frame Layout 2-113 Figure 2-46: Establishing an AccoDataCR 2-114 Figure 2-47: Flowchart – Copy Cycle for Local Connections 2-115 © Copyright by PNO 2004 - All rights reserved Page 2-10 PROFInet Architecture Description, Runtime Model Version V2.02 – February 2nd, 2004 Figure 2-48: State Machine Connect Attempt 2-119 Figure 2-49: Productive operation of data connections (DCOM) 2-126 Figure 2-50: Productive operation of data connections (SRT) 2-127 Figure 2-51: Productive operation of data connections (Local) 2-128 Figure 2-52: Productive operation of event connections47 2-128 Figure 2-53: Format of the byte stream for connection data 2-129 Figure 2-54: SRT Frame 2-132 Figure 2-55: Data Flow for Cyclic SRT 2-134 Figure 2-56: Failure of the provider in productive operation (DCOM) 2-137 Figure 2-57: Scenario 1: Provider failure in productive operation (SRT) 2-139 Figure 2-58: Scenario 2: Recovery from provider failure in productive operation (SRT) 2-140 Figure 2-59: Failure of the consumer 2-141 Figure 2-60: Failure of the consumer 2-142 Figure 2-61: Failure of the provider when setting up connections 2-144 Figure 2-62: Information levels 2-145 Figure 2-63: ACCO status model for the common diagnosis 2-145 Figure 2-64: ACCO status model for the detailed diagnosis 2-146 Figure 2-65: Implementation of an RTAuto for IEC 61131-3 PLC 2-159 Figure 2-66: Modeling a PROFIBUS DP Proxy 2-165 Figure 2-67: Views 2-166 Figure 2-68: Views 2-167 Figure 2-69: Decoupling Host and Slave 2-169 Figure 2-70: Device status model for the common diagnosis regarding a DP slave 2-170 Figure 2-71: Correlation PROFInet view and DP view 2-173 Figure 2-72: Mapping the PROFInet view onto the application 2-179 Figure 2-73: Producing a process-related view onto a DP slave of a fixed functionality 2-180 Figure 2-74: Componer for DP slaves of a fixed functionality 2-181 Figure 2-75: Proxy for ACCO 2-183 Figure 2-76: Device Parameters in Engineering and Runtime 2-188 Figure 2-77: Remote ACCO and ACCO pair 2-191 Figure 2-78: Constant Connections 2-193 Figure 2-79: DCOM and SRT Connections 2-194 Figure 2-80: Interface and class definition diagram for PROFInet 2-296 © Copyright by PNO 2004 - All rights reserved Page 2-11 PROFInet Architecture Description, Runtime Model Version V2.02 – February 2nd, 2004 Tables Table 2-1: Using Automation Data Types in Visual Basic 2-23 Table 2-2: Usage of Character Sets 2-29 Table 2-3: Differences between Record and Structure 2-32 Table 2-4: Interfaces 2-45 Table 2-5: Date and time 2-50 Table 2-6: CRC32 Table 2-61 Table 2-7: Connectable data types 2-73 Table 2-8: Supported Data Types according to PROFInet Version 2-74 Table 2-9: QoS Subtypes in the DCOM Communication Channel 2-75 Table 2-10: QoS Type and QoS Value 2-77 Table 2-11: Epsilon value for connectable data types 2-78 Table 2-12: Quality Codes explicitly created and used by PROFInet 2-81 Table 2-13: Encoding the Quality Code – Overview 2-88 Table 2-14: Encoding the Quality Code – Limits 2-88 Table 2-15: Encoding the Quality Code – Bad 2-88 Table 2-16: Encoding the Quality Code – Uncertain 2-89 Table 2-17: Encoding the Quality Code – Good (Non Cascade) 2-89 Table 2-18: Encoding the Quality Code – Good (Cascade) 2-90 Table 2-19: Encoding the Quality Code – Invalid Quality Codes 2-90 Table 2-20: Quality Code priority table 2-91 Table 2-21: Mapping Quality Codes towards OPC 2-93 Table 2-22: Maximum DCOM Substitute Value Apply Time (shown in ms) 2-100 Table 2-23: Usage of SRT Variants 2-103 Table 2-24: Mapping QoS Value to SRT Cycle Time (shown in ms) 2-104 Table 2-25: Maximum SRT Substitute Value Apply Time (shown in ms) 2-105 Table 2-26: Transfer Format 2-129 Table 2-27: Header structure 2-129 Table 2-28: Structure of a connection data item (DCOM channel) 2-129 Table 2-29: Structure of a connection data item (SRT channel) 2-130 Table 2-30: Data connection data 2-130 Table 2-32: Data format for serialized connection data 2-131 Table 2-33: How to compute the Length of the SRT Reference Data 2-132 Table 2-34: HRESULT Structure 2-135 Table 2-35: HRESULT Classification 2-135 Table 2-36: Time Intervals and Timeouts 2-136 Table 2-37: Error codes for the ACCO detailed diagnosis 2-148 Table 2-38: ICBAAccoMgt2::GetDiagnosis Functions IDs 2-149 Table 2-39: Access to properties of an RTAuto and the appropriate HRESULT 2-161 Table 2-40: Access to properties of a “!SYSTEM” RTAuto and the appropriate HRESULT 2-161 Table 2-41: Common HRESULTs on Access to properties of an RTAuto 2-162 Table 2-42: Quality Codes for an RTAuto 2-162 Table 2-43: Quality Codes for a “!SYSTEM” RTAuto 2-162 Table 2-44: Mapping the PROFInet Runtime Object Model onto a PROFIBUS DP Slave 2-166 Table 2-45: Mapping the DP View onto the PROFInet View 2-168 Table 2-46: Implementation of the standard interfaces for a Proxy LDev 2-171 Table 2-47: Overview Operating State and Group Error for a Proxy LDev 2-172 Table 2-48: Implementation of the properties of an RTAuto 2-173 © Copyright by PNO 2004 - All rights reserved Page 2-12 PROFInet Architecture Description, Runtime Model Version V2.02 – February 2nd, 2004 Table 2-49: Access to properties of a Proxy to a DP-Slave and appropriate HRESULT 2-177 Table 2-50: Access to system properties of a Proxy to a DP-Slave and appropriate HRESULT 2-177 Table 2-51: Common HRESULTs on Access to properties of an RTAuto 2-178 Table 2-52: Quality Codes for a Proxy to a DP-Slave 2-178 Table 2-53: Quality Codes for system properties of a Proxy to a DP-Slave 2-179 Table 2-54: PROFIBUS Data Types vs Automation Data Types 2-182 Table 2-55: General Parameters 2-190 Table 2-56: Connection Parameters 2-190 Table 2-57: Property Size 2-195 Table 2-58: SRT Frame Costs 2-196 Table 2-59: Constant Connections Parameters 2-196 Table 2-60: Local Connection Parameters 2-197 Table 2-61: SRT Connections Parameters 2-198 Table 2-62: SRT Power Parameters 2-199 Table 2-63: DCOM Productive Data Connections Parameters 2-201 Table 2-64: DCOM Power Parameters 2-202 Table 2-65: DCOM HMI Connections Parameters 2-203 Table 2-66: DCOM Status Connections Parameters 2-204 Table 2-67: Further Device Parameters 2-204 Table 2-68: Timeouts for Method Calls 2-206 © Copyright by PNO 2004 - All rights reserved Page 2-13 PROFInet Architecture Description, Runtime Model Version V2.02 – February 2nd, 2004 Changes Changes compared to the last distributed Version of this paper are marked with a change bar However editorial changes are not further marked Version Chapter Change 2.02 2.2.7 2.02 2.13.4.5 Status connections are only allowed to connect system variables Allowed QoS values for status connections reduced to 500 and 1000 ms 2.02 2.13.4.9.8 Properties of a !SYSTEM RTAuto as provider remain valid in “CBAReady” 2.13.4.9.15 Clarification on exception and HRESULT 2.02 2.13.4.12 Persistence of SRT connections on no longer functional Ethernet interface 2.02 2.13 Maximum size of SRT reference data changed from 480 bytes to 484 bytes 2.02 2.13.5.3.3.3 Maximum SRT cycle time reduced to 512 ms according to PROFInet IO specification 2.02 2.02 2.13.5.3.3.5.2 Gnip time interval changed to 10 seconds 2.13.7.5.1 Added error classification and time intervals chapter for clarifications 2.13.7.5.2 2.02 2.13.7.5.9.1 Added error correction on slow update 2.02 2.13.7.5.10.2 Added error scenario, which is not detected by PROFInet Runtime Source Version 2.02 2.13.8.3 2.02 2.13.8.6.1 Added note for upward compatibility 2.02 2.13.8.6.6 Added SrtDropCnt to CBA_Stats_ProviderEvents_t 2.02 2.15.2 2.02 2.16.5.4 2.02 2.16.6 Added system properties to description 2.02 2.18.4.3 Added CBA_CAT_CNT_OBSERVERS 2.02 2.18.5 2.02 2.18.6.2 2.02 2.20 2.02 2.20.23.2 Updated behavior on access to sub elements 2.02 2.20.26.1 Incompatible change to get_StateCollection 2.02 2.20.27.2 Added CBA_E_LINKFAILURE 2.02 2.20.27.3 Incompatible change to get_StateCollection (only comment in this case) Added station failure and link failure to table 2-37 Added system properties to description Clarifications to interface implementation Updated computation since only one reconfiguration frame is needed in PROFInet Runtime Source Version Changed Alive Timeout to 1500 ms Updated error returns © Copyright by PNO 2004 - All rights reserved Page 2-14 ... combination of events and data (Figure 1-15) IEC 61499 PROFInet Events Event with data f p1 p2 f(p1, p2) g g(q1, q2) q1 q2 Data Figure 1-15: PROFInet supports events with data For PROFInet an event... rights reserved Page 1-19 PROFInet Architecture Description, Objects in Automation Version V2.0, January 2003 PROFInet takes a slightly different approach As explained above PROFInet does not make... Chapter 2: PROFInet Runtime Model © Copyright by PNO 2004 - All rights reserved Page 2-1 PROFInet Architecture Description, Runtime Model Version V2.02 – February 2nd, 2004 Contents PROFINET RUNTIME