Спецификация протокола Profibus

Page 161

PROFIBUS-Specification-Normative-Parts-5:1997

the services which will be used in the data transfer phase, the maximum message

size and the desired connection type as well as further options of the connec-

tion.

If the remote application process accepts the request to establish the connec-

tion, it transmits a confirmation of this request to the requester.

After that, both application processes are in the data transfer phase and are

able to communicate with each other according to the agreed rules (context). The

availability of an established connection may be controlled in the LLI.

A connection is dissolved by its release (Abort service). Thereafter data trans-

fer is only possible when the connection has been established again.

Client : Server

-----------------------------------------------------------------

:

<Connection Establishment Phase>:

:

--------> Connection Request on following --------->

Conditions (Context) :

:

<-------- Connection Request on given <---------

Conditions accepted :

:

<Data Transfer Phase> :

:

<-------- Data Transfer on agreed Conditions --------->

:

<Connection Release Phase> :

:

--------> Connection Release --------->

:

or

:

<-------- Connection Release --------->

:

or

:

<-------- Error --------->

Figure 15. Connection-oriented Communication Relationship

The PROFIBUS Specification defines the following connection types:

communication relationships between master and slave

- connection for cyclic data transfer without slave initiative

- connection for cyclic data transfer with slave initiative

- connection for acyclic data transfer without slave initiative

- connection for acyclic data transfer with slave initiative

communication relationships between master and master

- connection for acyclic data transfer

In a connection for cyclic data transfer confirmed FMS services are executed cy-

clically by the communication on request of the master in the data transfer

phase. Only the FMS services Read and Write are permitted.

Page 162

PROFIBUS-Specification-Normative-Parts-5:1997

In addition the master can initiate unconfirmed FMS services with high or low

priority. Unconfirmed FMS services are only executed once per service request;

this also applies to a connection for cyclic data transfer.

On a connection for cyclic data transfer with slave initiative the slave may

also initiate unconfirmed FMS services with high or low priority.

If a connection for cyclic data transfer with or without slave initiative is re-

quired between two masters, one of them shall behave as a slave as far as Layer

7 service sequences are concerned.

In a connection for acyclic data transfer, confirmed and unconfirmed services

are only executed once. Services are always initiated by the master (in case of

a master - master communication relationship by both).

In a connection for acyclic data transfer with slave initiative, the slave is in

addition able to initiate unconfirmed FMS services with selectable priority.

3.3.3.2.2 Connectionless Communication Relationships

A connectionless communication relationship is either a one-to-many (multicast)

or a one-to-all (broadcast) communication relationship. For connectionless com-

munication relationships neither a connection establishment nor a connection re-

lease is performed. They are always in the data transfer phase. It is not possi-

ble for the communication to monitor the connection in this case. The execution

of the request cannot be acknowledged by the remote application processes, i.e.,

only unconfirmed services are permissible.

3.3.3.3 Communication Relationship List (CRL)

The Communication Relationship List (CRL) of a station contains the description

of all communication relationships of this station to other stations independent

of the time of use (see figure below). The CRL is prepared individually for each

PROFIBUS station when configuring the network and loaded locally or remotely us-

ing the management services.

Information about the type of communication relationship, the connection type,

the context, the addressing and the associated VFD are stored for each communi-

cation relationship in the CRL.

Page 163

PROFIBUS-Specification-Normative-Parts-5:1997

=====================================================

= CRL =

= *************** ####################### =

= * * # Details about # =

= * * # - real bus address # =

= * # 13 o-----># - connection type #>-------------+

= * * # - master/slave ... # = !

= * * # - context # = !

= * * # - VFD pointer # = !

= *************** ####################### = !

===================================================== !

!

I !

Application <-- I --> Communication !

I !

!

===================================================== !

= CRL = !

= *************** ####################### = !

= * * # Details about # = !

= * * # - real bus address # = !

= * # 34 o-----># - connection type #>-------------+

= * * # - master/slave ... # =

= * * # - context # =

= * * # - VFD pointer # =

= *************** ####################### =

=====================================================

Figure 16. Example of a Communication Relationship List (CRL)

3.3.4 Communication Objects

The PROFIBUS Specification provides a multitude of communication objects to the

remote application process. Object specific services act on each communication

object. If a service operates on a communication object, the behaviour of the

communication object is defined by rules (PROFIBUS models).

The PROFIBUS Specification distinguishes between explicit and implicit communi-

cation objects.

The object description of implicit communication objects is defined by the

PROFIBUS Specification. Thus the communication may neither create, read, alter

nor delete the description of implicit communication objects.

Explicit communication objects are assigned to an object description. The object

descriptions of all explicit communication objects are listed in the Object Dic-

tionary of a station.

3.3.4.1 Static and dynamic Communication Objects

Explicit communication objects are divided into two groups:

static communication objects:

simple variable, array, record, domain, event

dynamic communication objects:

program invocation, variable list

Static communication objects shall be registered in the static part of the Ob-

Page 164

PROFIBUS-Specification-Normative-Parts-5:1997

ject Dictionary. In the field area, static objects normally do not change very

often or only in certain operational modes. The definition of static communica-

tion objects may be performed in one of the following operational phases:

- during start-up or configuration phase

- on line

Typically static communication objects are registered in the Object Dictionary

during the projection phase of the bus system.

The dynamic communication objects shall be entered in the dynamic part of the

Object Dictionary. They may be predefined or created and deleted dynamically us-

ing FMS services.

======================================================

= ********************************************** =

= * :::::::::::::::::::::::::::::::::* =

= * + + : ############## :* =

= * + +/- <---------# # :* =

= * +/- <---------# Object # o-------------

= * + + : # Dictionary # :* =

= * +/- <---------# (OD) # o-------------

= * + +/- <---------# # :* =

= * + + : ############## :* =

= * :::::::::::::::::::::::::::::::::* =

= ********************************************** =

======================================================

Figure 17. Assignment of Object Dictionary to VFD

3.3.4.2 Object Addressing

Each communication object shall be able to be addressed. The PROFIBUS Specifica-

tion defines the following addressing schemes:

- physical

- implicit

- logical addressing or addressing by names

The addressing scheme depends on the object. Explicit objects may be addressed

logically or by name. In the case of explicit objects logical addressing is man-

datory, whereas addressing by name is optional.

In the case of logical addressing, each communication object shall be addressed

by use of a logical address (index) that shall be read out of the Object Dic-

tionary (see figure below). The addressing of the process object is done in the

application process itself. The assignment between logical address (communica-

tion) and real address (process object) is defined by local rules. The communi-

cation partner shall read this assignment from the Object Dictionary if it is

not known from the configuration.

In the case of addressing by names, the names shall be unique, at least within

the following groups of objects:

- domain

- program invocation

- simple variable, array, record

- variable list

- event

Page 165

PROFIBUS-Specification-Normative-Parts-5:1997

The structure of the names and their use is defined by the application and by

profiles. In the case of physical addressing, the address is specific to the de-

vice and thus not defined by the PROFIBUS Specification. Implicit addressing ap-

plies to communication objects that are important for the administration of the

communication itself (VFD, transaction object).

!Index!

+-----+----------------------------+

! 1 ! !

! . ! !

logical +-----+----+------+-------+--------+ Communica-

Address 17 ->! 17 !Name!Ob- !Object !internal!-> tion Object/

/Name ! ! !ject !Attri- !Address ! Process

! ! !Code !bute ! ! Object

+-----+----+------+-------+--------+

! . ! !

! n ! !

+-----+----------------------------+

Figure 18. Object Dictionary (Principle)

3.3.5 Object Description Model of Communication

A remote application process has to know the object description before it is

able to operate on the communication object. This information may be announced

during configuration. If an application process does not know the object de-

scription when accessing an object, the description of the object shall be read

at the communication partner.

The station where the object really exists holds the definition of the object

description (Source-OD). The Source-OD contains the description of all communi-

cation objects of a station.

The Object Dictionary is designed specifically for each VFD. The structure de-

fined in this specification does not prescribe a concrete implementation of the

Object Dictionary. Only the structure of the object descriptions transmitted

over the bus are defined. In addition, the existence of an Object Dictionary it-

self is not required if the necessary information may be constructed, e.g. with

an algorithm. Thus a uniform view of communication objects is provided over the

bus in a distributed application with devices of different manufacturers (multi-

vendor facility).

A specific object description is addressed with the same logical address (index)

or the same name as the corresponding communication object. Corresponding FMS

services are provided to the remote application process. The object description

is read with the service Get-OD. Using the Put-OD service, entries in the Object

Dictionary may be registered, deleted or changed.

Page 166

PROFIBUS-Specification-Normative-Parts-5:1997

Client : Server

-----------------------------------------------------------------

<If Object Description not > :

<not know from Configuration > :

:

--------> Get Object Description of --------->

logical Address 17 / read Name

:

<-------- Object Description for logical <---------

Address 17 / Name :

:

=

:

--------> Read Object with logical --------->

Address 17 / Name :

:

<-------- Data : <---------

:

Figure 19. Example for Reading an Entry in the Object Dictionary and the Object

(Variable Object)

Client : Server

-----------------------------------------------------------------

<If Object Description >:

<shall be generated at >:

<the Communication Partner >:

:

--------> Write Object Description on --------->

logical Address 17 / Name

:

<-------- Object Description loaded on <---------

logical Address 17 / Name

:

Figure 20. Example for Writing an Entry into the Object Dictionary of the Com-

munication Partner

3.3.5.1 Description

The object description of a single communication object contains information

about the object code, the assigned logical address and the name if desired.

Furthermore, the assignment of the real address to the logical address and, if

required, to a name are defined in the object description. The object descrip-

tion contains additional object specific attributes (see figure below).

Page 167

PROFIBUS-Specification-Normative-Parts-5:1997

+-------+--------+-----------+---------+----------+-----------+

! Index ! Object ! further ! real ! Name ! Extension !

! ! Code ! Object ! Object ! ! !

! ! ! attributes! address ! ! !

+-------+--------+-----------+---------+----------+-----------+

!

! +------------------+

! ! !

+-----> ! Communication/ !

! Process Object !

! !

+------------------+

Figure 21. Example of an Object Entry as a Communication Partner sees it (Prin-

ciple)

3.3.6 Protection Mechanisms

Protection mechanisms exist for communication end points and communication ob-

jects. Communication end points are protected by the communication whereas com-

munication objects are protected by the application process.

A communication end point on connection-oriented and also on connectionless com-

munication relationships may be protected by configuration in the Communication

Relationship list. The access right to this communication end point is given

only to a defined communication partner (access control).

In the case of connection-oriented communication relationships it is also possi-

ble to protect the access after successfully establishing the connection (open

communication end point). Therefore several communication partners are able to

use a communication end point at different times one after the other. For con-

nection-oriented data transfer several communication partners may not simultane-

ously use a communication end point.

A communication object may be protected by configuration in the Object Diction-

ary. The access to a communication object may be allowed for certain communica-

tion partners only. Beyond that it is possible to restrict the services permis-

sible on a communication object by an entry in the Object Dictionary (e.g. vari-

able is read only).

Further protection mechanisms of the application process are device specific and

therefore not affected by the PROFIBUS Specification.

3.4 Model of Fieldbus Management Layer 7 (FMA7)

The FMA7 describes management objects, services and the resulting models. The

objects are described implicitly (by the PROFIBUS Specification). Accessing the

objects is done using object specific services. One distinguishes between local

and remote FMA7 services. A parallel execution of FMA7 services is not possible.

The service parameters are described analogously to the presentation in the ta-

ble before.

The FMA7 is based on the FMA1/2 functions specified in PROFIBUS Data Link Layer

and the management functions of LLI and FMS.

Page 168

PROFIBUS-Specification-Normative-Parts-5:1997

3.4.1 Local Management

Local management services are rendered locally and allow the manipulation of lo-

cal management objects.

At the management user, a request is given by a request service primitive. The

acknowledgement of the request is received with a confirmation service primi-

tive. FMA7 maps local management services onto the management services of

FMA1/2, LLI and FMS.

3.4.2 Remote Management

Remote management services allow the manipulation of management objects at the

remote station. The FMA7 service is transmitted over the management connection

using a FMA7_PDU. The remote management is a user of the LLI (like FMS). Remote

management services are characterized by the remote user rendering a service by

means of its local management. The remote management is connection-oriented and

uses the transport functionality of the LLI.

All the PROFIBUS stations, except diagnosis and configuration tools, support re-

mote management services as a responder on exactly one management connection

only. The characteristics and the addressing of the management connection is de-

fined at the responder. Configuration or diagnosis tools support remote man-

agement services also as a requester on several management connections.

3.4.3 Default Management Connection

With the definition of the default management connection, a uniform access to

PROFIBUS stations is provided for configuration or diagnosis tools. Each

PROFIBUS station that supports FMA7 remote services as a responder shall have a

default management connection under CREF 1 registered in the CRL.

If a complete remote configuration of a station is required (Object Dictionary

(OD), Communication Relationship List (CRL) and bus parameters), two connections

have to be provided for configuration in the CRL: a management connection for

the configuration of the CRL and the bus parameters, and a FMS connection for

the configuration of the OD.

Page 169

PROFIBUS-Specification-Normative-Parts-5:1997

4 Fieldbus Message Specification (FMS)

In order to fit to a wide range of operational areas, the communication system

PROFIBUS provides the application system with a variety of services for using

open communication.

This variety is not required in all devices and areas. Restrictions are defined

in application specific profiles. The provided services take the following cri-

teria into consideration:

- The service scope is adapted to the operational area of the fieldbus.

- The compatibility to MAP (MMS) is guaranteed as appropriate.

- The hard time requirements shall be fulfilled.

- The service definition is with a modern, object oriented method.

4.1 Service Model

The service model of the application layer contains services that allow opera-

tions on objects.

Some of the objects are described implicitly, i.e. the description is defined by

the PROFIBUS Specification. The rest are described explicitly in the Object Dic-

tionary. Access to objects is achieved using object specific services.

When addressing objects the PROFIBUS Specification distinguishes between logi-

cal, physical and implicit addressing, and also addressing by name.

4.1.1 Short Description of Services

Initiate ( establishing a connection )

This service is used to establish a connection between two communication part-

ners. Mutual, connection specific agreements on the manner of using the communi-

cation are made (context). All other communication services are only permitted

after a successful connection establishment when connection-oriented data trans-

fer is used.

Abort ( release of a connection )

With this service an existing connection between two communication partners is

released. A resumption of the connection in case of connection-oriented data

transfer is only possible after the connection has been established again (Ini-

tiate).

Reject ( refusing an inadmissible service or PDU )

The FMS protocol uses the Reject service to refuse an inadmissible service or

an inadmissible received PDU. Reasons for the Reject:

- violation of the transmission protocol

- error in the service request

- error in the response of a service

- service not executable

- service offends against the context agreement.

Status ( reading the status of the device / application )

This service is used to read the status of the device / application.

UnsolicitedStatus ( spontaneous reporting of the status )

This service is used for a spontaneous transmission of the device / application

status.

Identify ( reading of manufacturer, type and version )

This service is used to read the vendor name (name of the manufacturer), model

name (name of the type of device) and revision (identification of the version)

of a device.

Page 170

PROFIBUS-Specification-Normative-Parts-5:1997

GetOD ( reading an object description )

This service is used to read a single or several object descriptions out of the

Object Dictionary (OD). Thus the index or the name of the desired object de-

scription shall be given in the GetOD service or the option to read all of the

object descriptions may be selected.

InitiatePutOD ( opening the download of the OD )

A client uses this service to indicate to the server that it intends to deliver

object descriptions.

PutOD ( loading an object description )

The client uses the PutOD service to deliver object descriptions to the server.

The object descriptions are loaded into the server's Object Dictionary.

TerminatePutOD ( termination of the downloading of the OD )

The client uses this service to indicate to the server that the delivery of the

object descriptions is complete.

InitiateDownloadSequence ( opening a download sequence )

With this service a blockwise transmission of data (parameters, program code,

...) from the "client" into a domain of the "server" is announced.

The PROFIBUS Specification requires the domain to be defined in the Object Dic-

tionary before a download can be performed. Special attributes of the domain are

also stored in the OD and are not set with the InitiateDownloadSequence service.

DownloadSegment ( transmitting a download data block )

The "server" uses this service to fetch a block of data from the "client". The

"client" transmits the data and an additional notification as to whether further

data is ready to be transmitted. The maximal block length is determined by the

length of user data in a PROFIBUS frame.

TerminateDownloadSequence ( terminating a download sequence )

With this service the "server" communicates that the blockwise transmission of

data in its domain is complete. In addition the "server" indicates if the trans-

mission has been successfully completed.

RequestDomainDownload ( requesting a download )

With this service the "server" requests its "client" to perform a download. The

request of the "server" may contain the optional information from which file of

the "client" the data shall be read. The answer (acknowledgement) to that re-

quest is transmitted only after completion of the download.

InitiateUploadSequence ( opening an upload sequence )

With this service the client opens the blockwise transmission of data (parame-

ters, program code, ...) out of a domain of the server.

UploadSegment ( transmitting an upload data block )

With this service the client fetches a block of data out of a domain of the

server. The server transmits the data and an additional notification as to

whether further data is ready to be transmitted. The maximal block length is de-

termined by the length of user data in a PROFIBUS frame.

TerminateUploadSequence ( terminating an upload sequence )

With this service the client communicates that the blockwise transmission of

data from the server to the client is complete.

RequestDomainUpload ( requesting an upload )

With this service the "server" requests its "client" to perform an Upload. The

request of the "server" may contain the optional information as to which file of

the "client" the upload data shall be written. The answer (acknowledgement) to

this request is not transmitted before the Download has been completed.

Спецификация протокола Profibus

Подождите немного. Документ загружается.