PROFInet Architecture Description, Objects in Automation Version V2.0, January 2003 Device 1 Res y Res x Device 2 Res z a b Function block/ Automation object Ressource / Logical
Trang 1PROFInet Architecture Description, Objects in Automation Version V2.0, January 2003
Device 1
Res y
Res x
Device 2 Res z
a
b
Function block/
Automation object
Ressource /
Logical Device
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
con-nected 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 inher-ently 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 nec-essary 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 communica-tion informacommunica-tion for the interconneccommunica-tions
Data flow Event 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
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 fea-tures 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
Trang 2PROFInet Architecture Description, Objects in Automation Version V2.0, January 2003
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 de-vices it can be a functionality programmed in C language The idea is to adopt the internal implemen-tation of the functionality of the automation component as it stands
PROFIBUS
Vendor A Parameterization
Fieldbus X
Vendor C
Programming Configuration Parameterization
Programming Configuration Parameterization
PROFIBUS
Vendor B
PROFInet Connection Editor
Configuration Programming
Vendor specific Vendor specific
Vendor specific
Vendor independent
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 en-gineering tools which are mostly IEC 61131-3 conformant programming systems like Simatic Step 7 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
tech-nological modularization, since for the interaction of the modules only the external interfaces are sig-nificant 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
Trang 3PROFInet 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 correspond-ing 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
Algorithms
(hidden)
Internal Data
(hidden)
Execution control
(hidden)
Data flow
Event flow
State diagram, Event Control Chart
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 realiza-tion
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
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 algo-rithms 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 re-quired 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 dif-ferent 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
Trang 4PROFInet Architecture Description, Objects in Automation Version V2.0, January 2003
Events
data
Figure 1-14: Combinations of events with data
PROFInet restricts the degree of freedom for the combination of events and data (Figure 1-15)
Events
Data
Event with data f
p1 p2 g
q1 q2
f(p1, p2)
g(q1, q2)
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 re-ceiver side The parameters (data) of the event do not have to be available as individually handled pieces of information at the external interface of the function This restriction was done as a simplifica-tion for the project engineer since the mensimplifica-tioned 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)
Trang 5PROFInet 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
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 inter-connections 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
Trang 6PROFInet Architecture Description, Objects in Automation Version V2.0, January 2003
PROFInet takes a slightly different approach As explained above PROFInet does not make any pro-visions 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
1
* Logical Device
1
*
RT-Auto
ACCO
Logical Device (=Software)
Physical Device (=Hardware)
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
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 de-vice
• 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
Trang 7
PROFInet Architecture Description, Runtime Model Version V2.02 – February 2 nd , 2004
Trang 8PROFInet Architecture Description, Runtime Model Version V2.02 – February 2 nd , 2004
Contents
2 PROFINET RUNTIME MODEL 2-15
2.1 COMTERMS 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 1 2-27 2.2.8.2 Character Set Type 2 2-28 2.2.8.3 Character Set Type 3 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
Trang 9PROFInet Architecture Description, Runtime Model Version V2.02 – February 2 nd , 2004
2.8.2 User Perspective 2-52 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
Trang 10PROFInet Architecture Description, Runtime Model Version V2.02 – February 2 nd , 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