Tài liệu PROFINET CBA Architecture Description and Specification P1 docx

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
© Copyright PNO 2004 – All Rights Reserved page 2 of 3 pages
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 2
“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. 7
D-76131 Karlsruhe
Germany
Phone: +49 721 / 96 58 590

Fax: +49 721 / 96 58 589
E-mail:
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.
TC2-04-0001 PROFINET CBA Architecture Description and Specification V 2.02
© Copyright PNO 2004 – All Rights Reserved page 3 of 3 pages
Version Overview

Chapter Version Issue Date Remarks
0 – Overview and Introduction V2.01 August 2003 Released
1 – Objects in Automation V2.0 January 2003 Released
2 – PROFInet Runtime Model V2.02 February 2004 Released
3 – PROFInet Engineering Model V2.02 February 2004 Released
4 – WebIntegration V0.73 January 2003 Working Draft
5 – Network Management V2.02 May 2004 Released

This page is intentionally left blank.



PROFInet Architecture Description, Overview and Introduction Version V2.01, August 2003

© Copyright by PNO 2003 - All rights reserved. Page 0-1



Chapter

0: Overview and Introduction
PROFInet Architecture Description, Overview and Introduction Version V2.01, August 2003

© Copyright by PNO 2003 - All rights reserved. Page 0-2

Contents

0
OVERVIEW AND INTRODUCTION 3
0.1 REQUIREMENTS AND GOALS 3
0.1.1 Changes in the Automation Landscape 3
0.1.2 Trend Towards Open Distributed Automation 3
0.2 AUTOMATION USING PROFINET 4
0.2.1 Goals of the Architecture 4
0.2.2 The Keystones of the Open Interoperable System 5
0.3 THE PROFINET CONCEPT 6
0.3.1 Runtime 6
0.3.2 Automation Objects 6
0.3.3 Implementation Methods for Automation Objects 7
0.4 PROFINET -RUNTIME MODEL 8
0.4.1 Including Non-PROFInet Components 9
0.5 COMMUNICATION 10
0.6 ENGINEERING 11
0.7 SUMMARY 11
0.7.1 Further Development, New Communication Systems 12

PROFInet Architecture Description, Overview and Introduction Version V2.01, August 2003

© Copyright by PNO 2003 - All rights reserved. Page 0-3

0 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 engi-
neering 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 seam-
lessly integrated into an existing automation task. The need for openness is relevant for both the run-
time components (PLC, drives, switchgear, field devices, actuators, sensors, HMI, etc.) and the engi-
neering 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 main-
tenance.
Under ease of use, the customer understands the simplified handling of a technology which is becom-
ing increasingly complex.
These requirements for open automation solutions, PC-based control, and consistent corporate com-
munication - 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 develop-
ment and Innovation. In the field of automation technology these goals have similarly lead to increas-
ingly smaller, faster and more cost-effective solutions. Bus systems replaced parallel wiring, electron-
ics 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 .
PLC
actuators/sensors
PLC
bus-capable
actuators/sensors
PLC
intelligent
field devices
stand-alone units
distributed control
ÖÖ
?
Ö


Figure 0: Trend towards distributed automation

Modern micro electronics, software technology, communication engineering and the influence of com-
mercial 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.

PROFInet Architecture Description, Overview and Introduction Version V2.01, August 2003

© Copyright by PNO 2003 - All rights reserved. Page 0-4

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 applica-
tion 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 opera-
tion costs.
• Through the use of encapsulated autonomous and tested functional units, the application pro-
grammer can realize increased flexibility and lowered costs in the engineering, commissioning, ac-
ceptance 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 exist-
ing 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, ma-
nipulator, 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 produc-
tion.
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 inter-
faces does not necessarily mean the disclosure of all device-internal implementations.
• Consistency (communication and cooperation of devices on all levels via similar mecha-
nisms)
- 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 perspec-
tive
• Intuitive usability (ease of use; simplified and uniform application model; taking different
user groups into account)
PROFInet Architecture Description, Overview and Introduction Version V2.01, August 2003

© Copyright by PNO 2003 - All rights reserved. Page 0-5

• 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 IP and the transport protocols TCP and UDP are used for communication (trans-
port) and for addressing the nodes. Additional protocols of the IP stack (routing,
network administration, ) are also used. This makes network layer and trans-
port layer uniform and consistent.
ORPC/DCOM 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 self-
documenting application protocol. In addition to data relationships, event mecha-
nisms and method calls to remote device are also made possible.
COM/OLE COM/OLE forms the basis for all the objects that interact during engineering.
This lays the foundation for component-based engineering.
ETHERNET Ethernet and its further developments (such as Fast and Gigabit Ethernet) form
the basis of the PROFInet communication system.
PROFIBUS Using proxies, PROFIBUS network segments can be linked to both the engi-
neering 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 - inde-
pendent DCOM /RPC protocol implementations are currently widely available.

With regard to the Engineering Systems, PROFInet works primarily with established Microsoft archi-
tectures and software interface standards, such as COM / OLE and IDL. PROFInet Engineering Sys-
tems should therefore be conceived for PC platforms with WINDOWS NT / 2000 operating system.
PROFInet Architecture Description, Overview and Introduction Version V2.01, August 2003

© Copyright by PNO 2003 - All rights reserved. Page 0-6

0.3 The PROFInet Concept

The PROFInet concept is relevant to both the engineering and the runtime world.


Windows



ES-AUTO


field devices
programming tools


PLC programming
tools

Runtime
(RT)

Engineering
System (ES)

programming
components

configuring
applications


components of fixed
functionality (field device)

RT-AUTO

configuration tools

other engineering tools for
diagnosis, simulation,


programable components
(e.g. PLC)

RT-AUTO
AUTO = automation object

Figure 2 : 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 com-
patibility 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 con-
troller. 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 deter-
mine 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 ulti-
mately lays the basis for openness and interoperability (consistency).

PROFInet Architecture Description, Overview and Introduction Version V2.01, August 2003

© Copyright by PNO 2003 - All rights reserved. Page 0-7

The COM interfaces of the automation objects are subdivided into four categories depending on the
functionality they provide:
• Mandatory interfaces
These interfaces define a standard that must be implemented by all resources (devices) of
an automation solution that is based on PROFInet. In addition to the interfaces defined by
COM (such as identification), the mandatory functionality also includes the support of data
and event communication between AUTOs.
The descriptions of the interfaces are open and may be employed by any user or be im-
plemented in an automation object.
• Optional interfaces
This category includes interfaces that must not necessarily be provided by all devices.
However, if this functionality is to be provided, it must be realized according to the specifi-
cations.
• Device-specific interfaces
These are the interfaces that permit access to device-specific functionality. These inter-
faces cannot be standardized and are usually implemented in the firmware.
The objects that implement the device-specific interfaces form the device object model (for
example: interfaces for loading an AUTO in a SIMATIC S7 CPU).
• Application-specific interfaces
These interfaces are application-specific. The corresponding automation objects are de-
veloped using programming tools that are usually specific to the destination system.

application-specific
optional
interconnectable
interfaces

param. value ass.
loading the AUTOs
interconnecting

PROFInet resource
(node, device)
application-specific
functionality
device-specific
expansion
standardized
functionality
Engineering system
automation object ES-
AUTO
mandatory

Figure 3: Categories of the RTAutomation objects


0.3.3 Implementation Methods for Automation Objects

Automation objects are defined as COM objects with corresponding interfaces. PROFInet does not
make any assumptions about the internal implementation of these interfaces. Any implementation is
permitted as long as the PROFInet object view is preserved towards the outside world. With a
SIMATIC controller, for example, the objects are created in the STEP 7 language, and executed as
blocks.

On the communication line (DCOM wire protocol), DCOM defines the identification of an object (during
startup only), as well as which methods shall be triggered at which interface with which parameters.

This results in the transfer of standardized DCOM packets on the line. These packets are generated in
the client, and evaluated and interpreted in the server. The way how this generation and/or interpreta-
tion takes place is up to the individual systems, as long as the rules for the DCOM object bus are ob-
served. In fact, it is not even necessary that COM objects exist within a server. It is sufficient that the
illusion of these objects (the object impression) is created on the DCOM object bus.

PROFInet Architecture Description, Overview and Introduction Version V2.01, August 2003

© Copyright by PNO 2003 - All rights reserved. Page 0-8

Client Server
parametermethodinterfaceobjects
PROFINet
node
PROFINet node object
distributor
line
DCOM wire protocol
object 1
object 2
utilization in a client
language, e.g.
(interface)Objekt1.M
ethode()


Figure 4: Illusion of COM objects by DCOM object bus

0.4 PROFInet -Runtime Model

The PROFInet Runtime model represents the objects that exist in a device, together with their inter-
faces and methods that are accessible from the outside through OLE automation. The model also
describes the interrelationship between the individual objects.

The following figure shows the object model of PROFInet.


ES-LDev
ES-Auto
Ph
y
sical
Device
1
*
Logical Device
1
*
RT-Auto
Logical Device
(=Software)
Physical Device
(=Hardware)
1
1
ACCO
ES-PDev


Figure 5: Object model

In the runtime object model, the PhysicalDevice (abbreviated PDev) represents a physical compo-
nent (i.e. hardware). It offers a network access to one or more IP networks. The PDev exposes the
physical properties of the component via the ICBAPhysicalDevice and ICBAPhysicalDevice2 inter-
faces. Exactly one instance of the PDev exists on each hardware component (e.g. PLC, drive, PC).
A PDev contains one or more LogicalDevices (abbreviated LDev). An LDev represents a software
package or a firmware package as an autonomous self-contained unit. The LDev participates as an
actuator, sensor, controller, CNC in solving the distributed automation task.
PROFInet Architecture Description, Overview and Introduction Version V2.01, August 2003

© Copyright by PNO 2003 - All rights reserved. Page 0-9

The PDev is able to navigate to all contained LDev by their names; it offers browsing functionality for
the names of the LDevs.
The LDev consists of the components operating system and application.
The PROFInet component of an LDev’s operating system consists of two parts: One part that is
standardized by PROFInet as a system definition, and an enhanced part that is used for special defini-
tions from the LDev programmer.
The PROFInet standard employs the LogicalDevice and ACCO objects to describe the functionality
that is the same throughout all LDevs.
The LogicalDevice object provides general automation functionalities such as identification or diag-
nosis, and is used as navigation anchor for all further objects of the operating system. In addition, it is
able to navigate to all contained RTAutos by their names and it offers browsing functionality for the
names of the RTAutos.
The ACCO (Active Control Connection Object) objects implements a configurable connection of
RTAutos.
The RTAuto object (runtime automation object) represents the automation functionality in the form of
a process-related component. Examples are „boiler”, „controller”, etc. These automation functional-
ities exist in the form of pre-tested, self-contained and universally employable components. Using the
interconnecting functionality that was defined by ACCO, they can be configured as a distributed appli-

cation.
Each RT Auto has one ES-Auto as a representative in Engineering. All the other objects of the LDev
together have one Engineering System device as representative in the engineering. This representa-
tive hides the internal object structure and the producer-specific features of the enhanced LDev to-
wards Engineering.
The LDev must have a functioning default so that it can be used immediately after “unpacking” or in-
stallation in a basic scope and without parameter value assignment. In particular, this concerns defini-
tions with regard to a default configuration for the IP stack.
0.4.1 Including Non-PROFInet Components
At any time – not only when PROFInet is introduced – there will be modules that have not yet been
integrated into PROFInet (or will never be). The reasons can be in continued usage existing hardware
as part of a particular migration policy, prohibitive costs in the implementation of PROFInet for some
devices or that a bus system does not support the necessary communication mechanisms (IP and
DCOM) to be mapped (such as the ASI bus). Nevertheless, it is relatively easy to integrate these com-
ponents into PROFInet.

Non-PROFInet modules that are used centrally or remotely at PROFInet are represented as Proxies
in the PROFInet system. The proxies are integrated as LDevs in the runtime model.

The integration of central or distributed I/O modules on a PROFIBUS shall be used as an example:
This proxy offers access in the PROFInet sense via interfaces to
• process data (i.e. inputs and outputs of the module in direct access or via the process image)
• asynchronous events (i.e. process or diagnosis alarm)
• diagnostics

PROFInet Architecture Description, Overview and Introduction Version V2.01, August 2003

© Copyright by PNO 2003 - All rights reserved. Page 0-10

0.5 Communication

Communication between the PROFInet nodes takes place on the application level via RPC/DCOM.
The commonly used and widely available TCP/IP
1
suite including DCE RPC is used for transport and
addressing.
Irrespective of the underlying bus system, PROFInet employs TCP/IP as the common communication
interface. Although any bus system can be used, the primary emphasis is placed on Ethernet net-
works.
Subordinate communication systems such as AS-I or the unmodified PROFIBUS can be linked to the
PROFInet application via runtime proxies and/or engineering proxies.

Figure 6: PROFInet communication structure
2


PROFInet communication must in no way compromise the performance expected by current applica-
tions and communication procedures. This can mean in individual cases, that standard communication
is used for connection setup, download, parameter value assignment, etc., while the runtime commu-
nication is mapped onto existing or optimized mechanisms. The possibility of alternative optimized
communication procedures for runtime communication also permits PROFInet systems to be inte-
grated into real-time Ethernet networks.




1
Includes also UDP/IP, ICMP, …
2
For sake of comprehenseness the optimized communication procedures were left out here. See

chapter 2 for more details on this issue.
TCP / IP
TCP / IP
DCOM
PROFIBUS
Field device
DP
"3rd
party"
Field
device
Protocol

PROFInet
engineering

TCP / IP
DCOM
Standard
application

TCP / IP
DCOM
Ethernet

PROFIBUS

Bus s
y
stems

Proxy
Proxy
COM COM
ACCO
PROFInet
controller

PROFInet
field device

TCP / IP
DCOM

ACCO
PROFInet Architecture Description, Overview and Introduction Version V2.01, August 2003

© Copyright by PNO 2003 - All rights reserved. Page 0-11

0.6 Engineering

When discussing the Engineering of automation components we must distinguish between the proc-
ess of creating the components (programming, interface definition) and using the components (appli-
cation configuration). Engineering tools typically execute on a Windows-based PC.
The AUTOs visible during runtime possess a proxy in engineering. The engineering proxy of an auto-
mation component is used as the anchor of all information, tools and data that are linked with this
object. This proxy implements the view of the AUTO in the Engineering System ( it contains for exam-
ple, the masks for setting parameters, the description of interconnectable data/events or the HMI per-
spective onto the object ).

Figure 7 : Typical PROFInet interconnection editor

The ES AUTOs (Engineering Autos) are either provided by the component manufacturer, or pro-
grammed by the application programmer and subsequently integrated into the library of the program-
ming tool. The manufacturer employs suitable firmware programming tools for programming devices
with fixed functionality. The device supplier provides tools for programming loadable AUTOs (such as
STEP 7 for SIMATIC S7).
Using the configuration tool, an application is created out of components. For this purpose, compo-
nents are retrieved, provided with parameter values, and interconnected.
Since the necessary interfaces have been standardized, the tools used for assembling applications
out of prefabricated components can come from any system provider.
0.7 Summary

The PROFInet concept represents the basis of a PNO-wide automation and engineering system.
PROFInet tries to define only the minimum number of common points that are required for an open
PROFInet Architecture Description, Overview and Introduction Version V2.01, August 2003

© Copyright by PNO 2003 - All rights reserved. Page 0-12

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 auto-
mation.
The openness of the PROFInet approach is based on the utilization of established and accepted mar-
ket 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 con-
junction 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 engineer-
ing), and to connect these system to the standard Ethernet via a proxy, thus integrating them into the
PROFInet system.


PROFInet Architecture Description, Objects in Automation Version V2.0, January 2003

© Copyright by PNO 2003 - All rights reserved. Page 1-1



Chapter
1: Objects in Automation
PROFInet Architecture Description, Objects in Automation Version V2.0, January 2003

© Copyright by PNO 2003 - All rights reserved. Page 1-2

Contents

1
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


PROFInet Architecture Description, Objects in Automation Version V2.0, January 2003

© Copyright by PNO 2003 - All rights reserved. Page 1-3

1 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 compo-
nents 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 component
1
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 func-
tion 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 in-
terface 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 addi-
tional 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 pro-

vides 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 defini-
tion 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 Object
2
) and the object in the Runtime System (RT Object). The ES Object is the repre-
sentative of the RT Object during engineering. Instantiation, interconnection and parameter value as-
signment of the ES Object produce the model of the automation solution of a concrete system. Trig-
gered by a download, and evaluating the engineering model, the system produces the runtime soft-
ware.


1
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 3 for
details.
2
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 2 and 3 are meant.
PROFInet Architecture Description, Objects in Automation Version V2.0, January 2003

© Copyright by PNO 2003 - All rights reserved. Page 1-4

The basic idea is that exactly one ES Object in the Engineering System corresponds to each RT Ob-
ject. 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 objects
3
. 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.



3
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.
PROFInet Architecture Description, Objects in Automation Version V2.0, January 2003

© Copyright by PNO 2003 - All rights reserved. Page 1-5

Library Application

ES Objects
Runtime Objects
Master of an
ES Object
Runtime:
Application
consisting of
cooperating
RT Objects
Engineering
(vendor-
independant):
Creation of an
application based
on ES Objects
Masters for
ES Objects in
library
Creation of Runtime Objects
based on the configuration of the
ES Objects and download onto
the devices
Programming
(vendor-specific):
Creation of an ES
Master (Template)
of an ES Object
Provide ES Master in
library

Figure 1-1: Objects at runtime and in engineering

Corresponding with these three levels, there are three different variants of automation objects.
1. 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.
2. 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 as-
signment. 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.
3. The Runtime-Object, finally, is the object that represents the executable code, and contributes to
the automation solution as a part of the system.
PROFInet Architecture Description, Objects in Automation Version V2.0, January 2003

© Copyright by PNO 2003 - All rights reserved. Page 1-6

1.3 PROFInet and the Integration Possibilities in the Automation World
PROFInet permits the individual levels and segments within the automation pyramid to be intercon-
nected.

corporate control level
production control level
process control level
field level
vertical integration
between the levels
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 par-
ticular.
1.3.1 Horizontal Integration on "Process Control" Level
PROFInet permits subsystems to be interconnected that were implemented using different technolo-
gies. 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 associ-
ated 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.
PROFInet Architecture Description, Objects in Automation Version V2.0, January 2003

© Copyright by PNO 2003 - All rights reserved. Page 1-7

Subsystem
machining station
(plc based)
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 ser-
vice (such as archiving and reporting system) in the form of PROFInet Objects. In particular, they em-
ploy 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 possibil-
ity of a vertical integration between the other levels of the automation pyramid. The topic is an integra-

tion of the PROFInet runtime and engineering concepts with the production control level and the cor-
porate 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 applica-
tions (MS Word, MS Excel, etc.).
PROFInet Architecture Description, Objects in Automation Version V2.0, January 2003

© Copyright by PNO 2003 - All rights reserved. Page 1-8

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 neces-
sary.
4


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 proc-
ess control level and field level
5
.
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 mecha-
nisms. These are the COM method call and the COM event mechanism. Automation industry applica-
tions additionally requires the possibility of event and data interconnection. Within the scope of PRO-
FInet, 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 inter-
face'.

4
Vertical integration can, of course, also be attained via representatives. Within the scope of PROFI-
net, this is particularly necessary for integrating non-PROFInet devices.
5
This means, in particular, that HMI systems that do not offer PROFInet objects themselves may also
use the benefits PROFInet provides for vertical integration (i.e. towards the automation level).
PROFInet Architecture Description, Objects in Automation Version V2.0, January 2003

© Copyright by PNO 2003 - All rights reserved. Page 1-9

The event sink possesses a reference to the event source. It is able to control whether or not it is in-
voked 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
1. the code contains neither direct nor indirect references to the partners, and
2. a free interconnection of data and events is possible that show different semantics from the per-
spective 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 'incom-
ing 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 de-
fined 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 2 and 3.

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 PRO-
FInet is fully OPC-compliant, it defines an additional functionality that goes beyond OPC.

Compliance (conformance, not approved compliance!) with the OPC standard
6
is reached by the fol-
lowing 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.



6

The following sections are chiefly related to OPC Data Access.