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

PLC actuators/sensors PLC bus-capableactuators/sensors PLC intelligentfield devices stand-alone units distributed control Figure 0: Trend towards distributed automation Modern micro ele

PROFINET

Specification

PROFINET CBA Architecture Description and Specification

Version 2.02 May 2004 Order No: 2.202

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"

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

Version Overview

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

Chapter 0: Overview and Introduction

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

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 neering to an open distributed automation system

engi-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 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

seam-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 ing increasingly complex

beThese requirements for open automation solutions, PC-based control, and consistent corporate munication - combined with available standard products and technologies - result in the need for a new approach to automation

com-0.1.2 Trend Towards Open Distributed Automation

The goals of increasing productivity and reducing costs are the principal forces behind new 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

develop-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-capableactuators/sensors

PLC

intelligentfield devices stand-alone units

distributed control

Figure 0: Trend towards distributed automation

Modern micro electronics, software technology, communication engineering and the influence of mercial mass markets on the costs make a change of paradigm likely

com-• 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

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 grammer can realize increased flexibility and lowered costs in the engineering, commissioning, ac-ceptance and service phases

pro-• 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 faces does not necessarily mean the disclosure of all device-internal implementations

inter-• Consistency (communication and cooperation of devices on all levels via similar nisms)

mecha 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 tive

perspec-• Intuitive usability (ease of use; simplified and uniform application model; taking different user groups into account)

• 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 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

archi-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

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 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

con-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)

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 plemented in an automation object

im-• 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 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)

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

Client Server

parameter method

interface objects

PROFINet node

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 faces and methods that are accessible from the outside through OLE automation The model also describes the interrelationship between the individual objects

inter-The following figure shows the object model of PROFInet

ES-LDev

ES-Auto

Physical Device

ACCO

ES-PDev

Figure 5: Object model

In the runtime object model, the PhysicalDevice (abbreviated PDev) represents a physical 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-

compo-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

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 tions from the LDev programmer

defini-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 wards Engineering

to-The LDev must have a functioning default so that it can be used immediately after “unpacking” or 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

in-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

0.5 Communication

Communication between the PROFInet nodes takes place on the application level via RPC/DCOM The commonly used and widely available TCP/IP1 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 tions and communication procedures This can mean in individual cases, that standard communication

applica-is used for connection setup, download, parameter value assignment, etc., while the runtime 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

commu-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

Standard application

TCP / IP DCOM

ACCO

0.6 Engineering

When discussing the Engineering of automation components we must distinguish between the ess of creating the components (programming, interface definition) and using the components (appli-cation configuration) Engineering tools typically execute on a Windows-based PC

proc-The AUTOs visible during runtime possess a proxy in engineering proc-The engineering proxy of an 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 )

auto-Figure 7 : Typical PROFInet interconnection editor

The ES AUTOs (Engineering Autos) are either provided by the component manufacturer, or 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)

pro-Using the configuration tool, an application is created out of components For this purpose, nents are retrieved, provided with parameter values, and interconnected

compo-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