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

Page 351

PROFIBUS-Specification-Normative-Parts-6:1997

5.7.7 PhysWrite

PhysWrite-Request ::= SEQUENCE {

local-address [0] IMPLICIT Local-Address,

data [1] IMPLICIT Data

}

PhysWrite-Response ::= NULL

5.7.8 InformationReport

InformationReport ::= SEQUENCE {

access-specification CHOICE {

index [0] IMPLICIT Index,

variable-name [1] IMPLICIT Name,

variable-list-name [2] IMPLICIT Name

},

subindex [3] IMPLICIT Subindex OPTIONAL,

data [4] IMPLICIT Data

}

5.7.9 ReadWithType

ReadWithType-Request ::= SEQUENCE {

access-specification CHOICE {

index [0] IMPLICIT Index,

variable-name [1] IMPLICIT Name,

variable-list-name [2] IMPLICIT Name

},

subindex [3] IMPLICIT Subindex OPTIONAL

}

ReadWithType-Response ::= SEQUENCE {

typedescription [0] IMPLICIT Typedescription,

data [1] IMPLICIT Data

}

5.7.10 WriteWithType

WriteWithType-Request ::= SEQUENCE {

access-specification CHOICE {

index [0] IMPLICIT Index,

variable-name [1] IMPLICIT Name,

variable-list-name [2] IMPLICIT Name

},

subindex [3] IMPLICIT Subindex OPTIONAL,

typedescription [4] IMPLICIT Typedescription,

data [5] IMPLICIT Data

}

WriteWithType-Response ::= NULL

Page 352

PROFIBUS-Specification-Normative-Parts-6:1997

5.7.11 InformationReportWithType

InformationReportWithType ::= SEQUENCE {

access-specification CHOICE {

index [0] IMPLICIT Index,

variable-name [1] IMPLICIT Name,

variable-list-name [2] IMPLICIT Name

},

subindex [3] IMPLICIT Subindex OPTIONAL,

typedescription [4] IMPLICIT Typedescription,

data [5] IMPLICIT Data

}

Page 353

PROFIBUS-Specification-Normative-Parts-6:1997

5.8 Event Management

5.8.1 AlterEventConditionMonitoring

AlterEventConditionMonitoring-Request ::= SEQUENCE {

access-specification CHOICE {

index [0] IMPLICIT Index,

event-name [1] IMPLICIT Name

},

enabled [2] IMPLICIT BOOLEAN

}

AlterEventConditionMonitoring-Response ::= NULL

5.8.2 AcknowledgeEventNotification

AcknowledgeEventNotification-Request ::= SEQUENCE {

access-specification CHOICE {

index [0] IMPLICIT Index,

event-name [1] IMPLICIT Name

},

eventNumber [2] IMPLICIT Unsigned8

}

AcknowledgeEventNotification-Response ::= NULL

5.8.3 EventNotification

EventNotification ::= SEQUENCE {

access-specification CHOICE {

index [0] IMPLICIT Index,

event-name [1] IMPLICIT Name

},

eventNumber [2] IMPLICIT Unsigned8,

eventData [3] IMPLICIT Data OPTIONAL

}

5.8.4 EventNotificationWithType

EventNotificationWithType ::= SEQUENCE {

access-specification CHOICE {

index [0] IMPLICIT Index,

event-name [1] IMPLICIT Name

},

eventNumber [2] IMPLICIT Unsigned8,

typedescription [3] IMPLICIT Typedescription OPTIONAL,

eventData [4] IMPLICIT Data OPTIONAL

}

Page 354

PROFIBUS-Specification-Normative-Parts-6:1997

5.9 Detailed Coding Examples

EXAMPLE: Knowledge of the syntax description of the PDUs is required to produce

encoding examples. The example encodings are written in hexadecimal notation,

whereby XX shall be replaced by user data.

READ-REQUEST_PDU:

The READ-REQUEST_PDU is a Confirmed-RequestPDU. A Confirmed-RequestPDU has the

tag 1 in the FMS PDU CHOICE. It is a SEQUENCE consisting of 2 components (P/C

flag =1, tag=1, length=2).

The first component is the InvokeID. Data Type and length of this component are

known implicitly (universal tag - Integer8). Therefore the ID Info is omitted,

i.e. there is only user data here.

The second component is a CHOICE (ConfirmedServiceRequest), from which the Read-

Request with tag=2 is selected. This component is again a SEQUENCE. It consists

of only one component - the index.

The Index has the Type unsigned16.

The Subindex is OPTIONAL and is omitted in this case.

Encoding PDU

92 confirmed-RequestPDU [1] SEQUENCE {

XX InvokeID,

A1 confirmedServiceRequest [2] SEQUENCE {

02 XX XX [0] IMPLICIT Index

}

The READ-REQUEST_PDU with a Subindex is as follows:

The second SEQUENCE has 2 components and there is a Subindex with tag=3.

Encoding PDU

92 confirmed-RequestPDU [1] SEQUENCE {

XX InvokeID,

A2 confirmedServiceRequest [2] SEQUENCE {

02 XX XX [0] IMPLICIT Index

31 XX [3] IMPLICIT Subindex

}

The whole READ-REQUEST_PDU without Subindex has a length of 6 octets. Three of

these octets contain user data.

Read PDUs:

Read-Request(InvID 8, Index 3) 92 08 A1 02 00 03

Read-Response(InvID 8, Integer16 1234 hex) A2 08 22 12 34

Read-Request(InvID 5, Index 32) 92 05 A1 02 00 20

Read-Response(InvID 5, Boolean true) A2 05 21 FF

PhysRead PDUs:

PhysRead-Request(InvID 6, Address 12345678 hex, 4 octets)

92 06 F2 1A 04 12 34 56 78 11 04

PhysRead-Response(InvID 6, 47110815 hex) A2 06 74 1A 47 11 08 15

Page 355

PROFIBUS-Specification-Normative-Parts-6:1997

GetOD PDUs:

GetOD-Request(InvID 7, All-Attributes FALSE, Index 27 )

92 07 C2 01 00 72 07 00 1B

GetOD-Response(InvID 7, List of 2 object descriptions

object description:

Index 27,

Object Code Simple Variable,

Data Type Index Integer8,

Length 1,

object description:

Index 28,

Object Code Simple Variable,

Data Type Index Octet String,

Length 5,

more-follows True )

A2 07 C2 82 06 00 1B 07 00 02 01

06 00 1C 07 00 0A 05

11 FF

Page 356

PROFIBUS-Specification-Normative-Parts-6:1997

6 Lower Layer Interface (LLI)

6.1 General

The Lower Layer Interface (LLI) represents the interface between the Fieldbus

Message Specification (FMS) and the Layer 2 (FDL) with a part of the Layer 2

management (FMA1/2). In the same way, the LLI represents the interface between

the Fieldbus Management Layer 7 (FMA7) and FDL, with FMA1/2 for remote manage-

ment functions. In the following text, FMS and FMA7 are called LLI users.The

definitions of the LLI are optimized for the FDL and the FMA1/2. Moreover the

LLI provides an interface to the Layer 7 management (FMA7) for local management

functions.

6.1.1 Tasks of the Lower Layer Interface (LLI)

- The LLI simulates the necessary Layer 3 to 6 functionality.

- The LLI provides a service interface to the LLI User independent of FDL.

- The LLI maps the FMS and FMA7 services onto the FDL services. The necessary

FMA1/2 services are considered thereby.

6.1.2 Use of FDL Services and FMA1/2 Services

The LLI uses the following FDL services for the mapping of the LLI services onto

the FDL services:

- Send Data with No Acknowledge (SDN)

- Send Data with Acknowledge (SDA)

- Send and Request Data with Reply (SRD)

- Cyclic Send and Request Data with Reply (CSRD)

At the active station (master) the services are processed as initiator, re-

sponder or both, at the passive station (slave) as responder. The following

FMA1/2 services are used to set the parameters of the service access points

(LSAPs):

- SAP Activate FMA1/2

- RSAP Activate FMA1/2

- SAP Deactivate FMA1/2

These FMA1/2 services are marked as optional in the PROFIBUS specification. They

shall, however, be implemented to realize the functionality of the LLI; i.e.

they are mandatory for LLI.

6.2 LLI Model

Between two application processes one or more communication relationships may

exist. Communication end points are uniquely assigned to each communication re-

lationship (see chapter 2). All communication relationships shall be configured

in the Communication Reference List (CRL) independent of the time of use and

shall be addressed with local communication references (CREF).

The configuration may either statically assign a communication end-point to a

communication partner, or may allow the access to it for all partners (in the

following called "open communication end-point"). In case of static assignment,

no other communication partner has access to the communication end-point.

A communication relationship may either be connection-oriented or connection-

less.

Page 357

PROFIBUS-Specification-Normative-Parts-6:1997

For a connection-oriented communication relationship a logical connection is es-

tablished between two communication end-points of different communication part-

ners (also called "one-to-one" communication relationship).

The LLI distinguishes three phases thereby:

- Connection establishment phase

- Data transfer phase

- Connection release phase

In the data transfer phase the communication end-point used shall be statically

assigned to the end-point of the partner. For the open communication end-point

this assignment is accomplished during the connection establishment phase.

Furthermore, the LLI distinguishes for connection oriented communication rela-

tionships between master-slave (M-S) and master-master (M-M). A master corre-

sponds to an active station and a slave to a passive station according to the

PROFIBUS Data Link Layer specification.

For a master-slave communication relationship logical connections for

- cyclic data transfer with no slave initiative or

- cyclic data transfer with slave initiative or

- acyclic data transfer with no slave initiative or

- acyclic data transfer with slave initiative

may exist.

A logical connection with slave initiative means that the slave may issue a un-

confirmed service request to the master.

For the master-master communication relationship only the logical connection for

- acyclic data transfer

may exist.

If a connection for cyclic data transfer is to be configured between two mas-

ters, then one of the two masters shall emulate the slave for this connection.

This connection is valid as a masterslave communication relationship. It is

called a connection for cyclic data transfer with or with no slave initiative.

A connectionless communication relationship is either used for multicast data

transfer (also called "one-to-many" communication relationship), or for broad-

cast data transfer (also called "one-to-all" communication relationship). These

communication relationships are always in the data transfer phase and are not

distinguished further.

6.2.1 LLI Addressing

An application process shall address its communication relationships with the

help of communication references (CREF). Each CREF is assigned to exactly one

local Link Service Access Point (local LSAP) of the Layer 2 (see PROFIBUS Data

Link Layer, SSAP). On the other hand, some appointed local LSAPs may be assigned

to multiple CREFs. Furthermore each CREF is assigned to exactly one LLI Service

Access Point (LLI SAP). The assignment between CREF, the local LSAP and the LLI

SAP is configured in the Communication Reference List (CRL) specifically to each

communication relationship.

The CRL also contains the assignment of the CREF to:

- the remote address (see PROFIBUS Data Link Layer, rem_add) and

- the related remote LSAP (see PROFIBUS Data Link Layer, DSAP)

Page 358

PROFIBUS-Specification-Normative-Parts-6:1997

The LLI provides two service access points at the interface to the LLI user. The

FMS shall use for all services the LLI SAP 0. The FMA7 shall use for all remote

services the LLI SAP 1.

The LLI tests for every service request at the LLI user - LLI interface whether

the service request may be assigned to a Layer 2 address (remote address, remote

LSAP) which is configured in the CRL (see LLI CRL definition below). If the

service request could be assigned to a Layer 2 address, the LLI enters the LLI

SAP into the LLI PDU and delivers it to Layer 2 for transmission. Otherwise a

fatal error has occurred. In this case the LLI ignores the service request and

issues an error indication to the FMA7.

Upon receipt of a LLI PDU, the LLI tests whether the PDU could be assigned to a

communication relationship which is registered in the CRL. If the PDU could be

assigned to a CREF, the LLI delivers the received PDU to the LLI user at the as-

signed LLI SAP. PDUs which could not be assigned to a CREF are ignored by the

LLI (see LLI CRL definition below).

To ensure a uniform access to all PROFIBUS stations by configuration or diagnos-

tic devices, every station which supports the remote management services as re-

sponder, shall reserve the LSAP 1 and the CREF 1 for the default management con-

nection (see FMA7). All other stations which do not support remote management,

shall not use the LSAP1 and the CREF 1.

These assignments and definitions are shown in the following figure.

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

= * Application Process * * * =

= * FMS User * * FMA7 User * =

= * #2 #3 #4 #5 * * #6 #7 #8 * =

= *****o*********o***o***o****** *****o*********o***o********** =

= ! ! ! ! ! ! ! =

= :::!:::::::::!:::!:::!:: :::!:::::::::!:::!:::::: =

= : LLI SAP 0 : : LLI SAP 1 : =

= :::!:::::::::::!:!:!:::: :::!:::::::::::!:!:::::: =

= ! ! ! ! ! ! ! =

= %%%!%%% %!%!%!% %%%!%%% %!%!%% =

= % 17 % % 19 % % 18 % % 15 % =

= %%%!%%% %!%!%!% %%%!%%% %!%!%% =

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

! ! ! V ! ! V

! ! ! Rem_add2/ ! ! Rem_add5/

! ! ! DSAP2/ ! ! DSAP = 1/

! ! ! LLI SAP = 0 ! ! LLI SAP = 1

! ! V ! !

V ! Rem_add3/ ! V

Rem_add1/ ! DSAP3/ ! Rem_add6/

DSAP1/ ! LLI SAP = 0 V DSAP = 1/

LLI SAP = 0 V Rem_add7/ LLI SAP = 1

Rem_add4/ DSAP = 1/

DSAP4/ LLI SAP = 1

LLI SAP = 0

Legend: #n : Communication Reference (CREF)

o : Communication End-point

Loc_add : Source FDL Address (see PROFIBUS Data Link Layer)

====== %%%%%%

= = : Device % % : LSAP

====== %%%%%%

::::::

: : : LLI SAP

::::::

Figure 16. Addressing of Communication Relationships

Page 359

PROFIBUS-Specification-Normative-Parts-6:1997

6.2.2 Communication Relationships

The services of FMS and FMA7 are executed for connection-oriented communication

relationships over logical connections. The connections may be distinguished

from each other by their connection qualities (control mechanisms, resources

etc.). Different requirements apply for master-slave communication relationships

as compared to master-master communication relationships.

It is assumed for the devices at the slave side of master-slave communication

relationships that they have only slave behaviour relative to the FMA7 and the

confirmed FMS services. These devices may be client or server for unconfirmed

FMS services.

Sensors usually need a fast and cyclic data exchange into a process image data

memory at the master side. Actors often need to be actualized cyclically in or-

der that a failure of the communication relationship to the master may be recog-

nized (fail-safe, redundancy control etc. ). The logical connection for cyclic

data transfer with no slave initiative is appropriate for these applications.

Simple input / output devices, bar code readers, simple controllers or similar

devices perform acyclic data transfer when the application process at the master

works in spontaneous operation (loading of parameters, etc), or when the fre-

quency of the data exchange is low (every 100 seconds, every 24 hours, process

start-up, etc.). The logical connection for acyclic data transfer with no slave

initiative is appropriate for these applications.

To indicate device errors and to notify process alarms, a priority controlled

data transfer is necessary for intelligent slave devices with the initiative at

the slave side. The logical connections for cyclic or acyclic data transfer with

slave initiative are appropriate for these applications.

Master-master communication relationships allow parallel and mutual data ex-

change with priority controlled transmission. Thereby they may have client or

server behaviour relative to the functionality.

Even between two master devices a cyclic data exchange may be necessary. The

logical connection for cyclic data transfer is appropriate for these applica-

tions. Thereby one of the masters (the server of the confirmed services) shall

behave like a slave, i.e. it is a master-slave communication relationship.

The unconfirmed services of the LLI user may also be executed on connectionless

communication relationships (without logical connection). Broadcast or multicast

communication relationships are appropriate for synchronization of stations,

snapshots and exchange of global data to several or to all stations.

EXAMPLE: The characteristic communication relationships are illustrated for ex-

ample in the following five figures and named " cyclic with / with no slave ini-

tiative, acyclic with / with no slave initiative, broadcast and multicast". Ex-

perience shows that devices for automatic control and systems in the field use

these communication relationships side by side.

Notation in the following figures:

% : Link Service Access Point (LSAP)

%% : Poll List LSAP (see structure of LLI CRL definition below)

%%% : Global Link Service Access Point (LSAP 63, see connectionless

CRL definition below)

Page 360

PROFIBUS-Specification-Normative-Parts-6:1997

a) 1-Master <--> n-Slaves

An examples of the communication relationships of one master to several slaves

(sensors, actors and regulators) is shown in following figure.

Master 1 Slave 1

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

= !----------- Acyclic with ---------------% =

= ! = Slave Initiative = =

= ! = = =

= !---------- Acyclic with no ------+ ========

= ! = Slave Initiative !

= ! = !

= !---------- Acyclic with no ----+ ! Slave 2

= ! = Slave Initiative ! ! ========

= ! = ! +------% =

= ! = +--------% =

= !----------- Cyclic with ----------------% =

= ! = Slave Initiative = =

= ! = ========

= ! =

= %%-+ =

= ! = Slave 3

= ! = ========

= !---------- Cyclic with no --------------% =

= ! = Slave Initiative = =

= ! = ========

= ! =

= ! = Slave 4

= ! = ========

= !---------- Cyclic with -----------------% =

= = Slave Initiative = =

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

Figure 17. Communication Relationships between 1 Master and n Slaves

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

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