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

Page 461

PROFIBUS-Specification-Normative-Parts-6:1997

Master/Requester . Master/Responder

.

User!FMS LLI FDL BUS FDL LLI FMS!User

=====!====!=============!======.======!=============!====!=====

Read.req ! ! ! !

<#7/IVID1>! ! ! !

----> ! ! ! !

[READ_REQ_! ! ! !

PDU] ! ! ! !

DTC.req ! ! ! !

<#7,0, ! ! ! !

READ_ ! ! ! !

REQ_PDU>! ! ! !

---->![DTC_REQ_PDU]! ! !

! !**READ_REQ_ ! !DTC.ind

!(FDL_DATA_ ! PDU !(FDL_DATA_ !<#8,0,

! ACK.req !*DTC_REQ_PDU ! ACK.ind ! READ_

! <Low>) ![SDA_REQ_PDU]! <Low>) ! REQ_PDU>

! ]------>!------------>!------------>!---->

! [<------!<-----------/! ! Read.ind

!(FDL_DATA_ ![SDA_ACK_PDU]! !<#8/IVID1>

! ACK.con) ! ! ! ---->

! ! ! ! Read.res

! ! ! !<#8/IVID1>

! ! ! ! <----

! ! ! ![READ_RES_

! ! ! ! PDU]

! ! ! !DTC.res

! ! ! !<#8,0,

! ! ![DTC_RES_PDU]! READ_

! !**READ_RES_ ! ! RES_PDU>

! ! PDU !(FDL_DATA_ !<----

! !*DTC_RES_PDU ! ACK.req !

! ![SDA_REQ_PDU]! <Low>) !

<----!<------------!<------------!<------[ !

DTC.con !(FDL_DATA_ !\----------->!------>] !

<#7,0, ! ACK.ind ![SDA_ACK_PDU]!(FDL_DATA_ !

READ_ ! <Low>) ! ! ACK.con) !

_RES_PDU>! ! ! !

Read.con ! ! ! !

<#7,IVID1>! ! ! !

<---- ! ! ! !

Figure 88. Master-Master Communication Relationship / Connection for Acyclic

Data Transfer / Mapping of a confirmed Service for the Example of

the Read Service of FMS

Page 462

PROFIBUS-Specification-Normative-Parts-6:1997

Unconfirmed FMS services:

Unconfirmed FMS services are services which are not acknowledged by the user.

For these services low or high priority may be used. The mapping of the uncon-

firmed FMS services onto Layer 2 is described here for the example of the Infor-

mationReport service. All other unconfirmed FMS services are mapped in the same

way.

InformationReport service:

On a connection for Acyclic Data Transfer the InformationReport service is used

for a single writing of data into a master. The FMS maps each request (Informa-

tionReport.req) onto the LLI service primitive DTA.req. The priority chosen by

the user is transferred transparently. LLI maps a DTA.req with high priority

onto the Layer 2 service SDA with high priority. LLI maps a DTA.req with low

priority onto the Layer 2 service SDA with low priority. Each request leads to a

transmission of the INFORMATION-REPORT_REQ_PDU with a SDA_REQ_PDU from the re-

quester to the receiver. The resulting FDL_DATA_ACK.ind leads to a DTA.ind from

the LLI of the receiver to FMS. FMS maps the DTA.ind onto an InformationRe-

port.ind to the user.

If there is memory available again (Buffer_free) for the LLI of the master (re-

ceiver) to receive another DTA_REQ_PDU, the LLI generates a DTA_ACK_PDU to sig-

nal this to the LLI of the master (requester). The LLI maps the DTA_ACK_PDU onto

the Layer 2 service SDA with high or low priority corresponding to the priority

with which the DTA_REQ_PDU was passed to LLI by the Layer 2. The SDA_REQ_PDU

transports the DTA_ACK_PDU to the LLI of the master (requester). This does not

lead to a confirmation to FMS.

Page 463

PROFIBUS-Specification-Normative-Parts-6:1997

Master/Requester . Master/Responder

.

User!FMS LLI FDL BUS FDL LLI FMS!User

=====!====!=============!======.======!=============!====!=====

INFO.req ! ! ! !

<#7,High> ! ! ! !

----> ! ! ! !

! ! ! !

[INFO_REQ_! ! ! !

PDU] ! ! ! !

DTA.req ! ! ! !

<#7,0, ! ! ! !

High, ! ! ! !

INFO_ ! ! ! !

REQ_PDU>! ! ! !

---->![DTA_REQ_PDU]!**INFO_REQ_ ! !DTA.ind

! ! PDU ! !<#8,0,

!(FDL_DATA_ !*DTA_REQ_PDU !(FDL_DATA_ ! Low,

! ACK.req ![SDA_REQ_PDU]! ACK.ind ! INFO_

!<HIGH>) ! !<HIGH>) ! REQ_PDU>

! ]------>!------------>!------------>!---->

! [<------!<-----------/! !

!(FDL_DATA_ ![SDA_ACK_PDU]! ! INFO.ind

! ACK.con) ! ! ! <#8>

! ! ! ! ---->

! ! !\Buffer_free !

! ! !"generate !

! ! ! DTA_ACK_PDU !

! ! ! !

! ! ![DTA_ACK_PDU]!

! ! ! !

! ! !(FDL_DATA_ !

! !*DTA_ACK_PDU ! ACK.req !

! ![SDA_REQ_PDU]! <High>) !

! [<------!<------------!<------[ !

!(FDL_DATA_ !\----------->!------>] !

! ACK.ind ![SDA_ACK_PDU]!(FDL_DATA_ !

! <High>) ! ! ACK.con) !

! v ! ! !

!\Buffer_free ! ! !

! ! ! !

Figure 89. Master-Master Communication Relationship / Connection for Acyclic

Data Transfer / InformationReport with high Priority

The sequence of an InformationReport with low priority is analogous to that

shown the figure above. <Low> shall be read in place of <High>.

Page 464

PROFIBUS-Specification-Normative-Parts-6:1997

Remote FMA7 services:

All remote FMA7 services are acknowledged by the user. The mapping of these

services onto Layer 2 is described here for the example of the Read Value Rem

service. All other remote FMA7 services are mapped in the same way.

Read Value Rem service:

On a connection for Acyclic Data Transfer the Read Value Rem service is used for

reading of variable values or counters out of a master. FMA7 maps each read re-

quest (ReadValueRem.req) onto the LLI service primitive DTC.req. The READ_VALUE-

REM_REQ_PDU is transported with a SDA_REQ_PDU with low priority from the re-

quester to the responder. The resulting FDL_DATA_ACK.ind leads to a DTC.ind from

the LLI of the responder to FMA7. FMA7 maps the DTC.ind onto a ReadValueRem.ind

to the user.

When the user of the responder has passed the Read-Value-Rem.res to FMA7, FMA7

generates the READ-VALUE-REM_RES_PDU and passes it to LLI with a DTC.res. LLI

passes the READ-VALUE-REM_RES_PDU to Layer 2 with a FDL_DATA_ACK.req <Low>. The

resulting SDA_REQ_PDU transports the data to the requester. The READ-VALUE-

REM_RES_PDU is passed to LLI with the FDL_DATA_ACK.ind. LLI passes it to FMA7

using a DTC.con. Then FMA7 passes the ReadValueRem.con to the user.

Page 465

PROFIBUS-Specification-Normative-Parts-6:1997

Master/Requester . Master/Responder

.

User!FMA7 LLI FDL BUS FDL LLI FMS!FMA7

=====!====!=============!======.======!=============!====!=====

RV.req<#2>! ! ! !

----> ! ! ! !

! ! ! !

[RV_REQ_ ! ! ! !

PDU] ! ! ! !

DTC.req ! ! ! !

<#7,1, ! ! ! !

RV_ ! ! ! !

REQ_PDU>! ! ! !

---->![DTC_REQ_PDU]! ! !

! ! ! !DTC.ind

!(FDL_DATA_ !**RV_REQ_PDU !(FDL_DATA_ !<#1,1,

! ACK.req !*DTC_REQ_PDU ! ACK.ind ! RV_REQ_

! <Low>) ![SDA_REQ_PDU]! <Low>) ! PDU>

! ]------>!------------>!------------>!---->

! [<------!<-----------/! !

!(FDL_DATA_ ![SDA_ACK_PDU]! ! Read.ind

! ACK.con) ! ! !<#8/IVID1>

! ! ! ! ---->

! ! ! !

! ! ! ! Read.res

! ! ! ! <#1>

! ! ! ! <----

! ! ! !

! ! ! ![RV_RES_

! ! ! ! PDU]

! ! ! !

! ! ! !DTC.res

! ! ! !<#1,1,

! ! ! ! RV_RES_

! ! ! ! PDU>

! ! ![DTC_RES_PDU]!<----

! ! ! !

! !**RV_RES_PDU !(FDL_DATA_ !

! !*DTC_RES_PDU ! ACK.req !

! ![SDA_REQ_PDU]! <Low>) !

<----!<------------!<------------!<------[ !

DTC.con !(FDL_DATA_ !\----------->!------>] !

<#7,1, ! ACK.ind ![SDA_ACK_PDU]!(FDL_DATA_ !

RV_RES_ ! <Low>) ! ! ACK.con) !

PDU> ! ! ! !

! ! ! !

RV.con<#2>! ! ! !

<---- ! ! ! !

! ! ! !

Figure 90. Master-Master Communication Relationship / Connection for Acyclic

Data Transfer / Mapping of a remote FMA7 Service for the Example of

the ReadValueRem Service

Page 466

PROFIBUS-Specification-Normative-Parts-6:1997

6.3.4.4 Monitoring on Data Transfer

Interpretation of the Layer 2 Confirmation Primitive

During the data transfer phase the parameter L_status of the Layer 2 confirma-

tion primitive (FDL_XXX.con) is interpreted. Certain values of the parameter

L_status (see formal LLI state machine definition) lead to a connection release

and in some cases to an error message (LLI-FAULT.ind) to FMA7.

Monitoring the Connection

During the data transfer phase the availability of a connection may be moni-

tored. According to the kind of connection two monitoring mechanisms are distin-

guished:

Monitoring of a connection for Acyclic Data Transfer:

This kind of monitoring is optional and specific to the connection. If a connec-

tion is to be monitored, both partners shall take part in monitoring. During the

connection establishment phase this is guaranteed by the context test. The con-

nection monitoring may be performed on master-master and master-slave connec-

tions (with or with no Slave Initiative). The monitoring mechanism is the same

for master and slave on each acyclic connection type. The connection monitoring

is configured specific to the connection by entering a time interval greater

than 0 into the attribute ACI (Acyclic Control Interval, receive interval) in

the context of the LLI CRL. ACI is the time interval in which the failure of a

connection shall be surely recognized. The connection monitoring is started af-

ter a successful connection establishment (STimer, RTimer).

The correct operation of a connection for acyclic data transfer is recognized by

receiving a correct LLI PDU during the monitoring interval ACI. It shall be

guaranteed that both partners send a LLI PDU during the send interval (con-

trolled by the STimer). If the send interval expires and no LLI PDU has been

sent, then LLI sends a control message (IDLE_PDU). After each sending of a LLI

PDU the send interval starts again. After each receipt of a LLI PDU the receive

interval (controlled by the RTimer) starts again. This interval shall be equal

for both partners. If no LLI PDU has been received during the receive interval,

the connection is disturbed and shall be released (see connection release defi-

nition).

The send interval is a third of the receive interval (ACI).

Monitoring of a connection for Cyclic Data Transfer:

The monitoring is specific to the connection. It checks if during the time in-

terval CCI (Cyclic Control Interval), which has been configured in the CRL, an

event occurs, which confirms the correct operation of the connection.

The monitoring is started by the first confirmed Layer 7 request (in the master

the first DTC.req from the FMS; in the slave the arrival of the first

DTC_REQ_PDU). The receipt of an expected DTC_RES_PDU in the master, or the arri-

val of a SRD.ind in the slave, during the monitoring interval (timer T3) shows

that the connection is operating correctly. In this case the LLI starts the

monitoring interval again. If the monitoring interval expires, the connection is

disturbed and shall be released (see see connection release definition).

The user of the master may monitor the user of the slave during the execution of

the first request because it does not receive the response out of the local IDM.

For all following requests with the same Invoke ID this is not possible because

the response is taken from the IDM and the user cannot detect the actualization

of the IDM (receipt of a DTC_RES_PDU). Because the actualization of the IDM dur-

ing the connection monitoring is detected by LLI, LLI monitors automatically the

user of the slave in addition to the connection. To guarantee the monitoring of

the user at any time the connection monitoring is mandatory in the master.

In the slave the monitoring is optional. It only makes sense if the slave can

react upon a connection failure (e.g. fail-safe, redundancy switch-over). The

Page 467

PROFIBUS-Specification-Normative-Parts-6:1997

failure of the user of the master cannot be detected with this monitoring.

6.3.4.5 Flow Control in LLI

The flow control regulates the LLI PDU traffic on connection-oriented communica-

tion relationships. The method is identical for connections for acyclic and cy-

clic data transfer. It includes confirmed and unconfirmed FMS services and all

FMA7 services equally.

During the configuration of the CRL the resources for the confirmed LLI user

services (max SCC, max RCC) and the unconfirmed services (max SAC, max RAC) are

defined specific to the connection.

- max SCC contains the maximum permitted number of parallel confirmed LLI user

services to the remote communication partner. For each confirmed service of

the LLI user to be sent an own DTC requester state machine shall be availa-

ble.

- max RCC contains the maximum permitted number of parallel confirmed LLI user

services from the remote communication partner. For each confirmed service of

the LLI user which is received an own DTC responder state machine shall be

available.

- max SAC contains the maximum permitted number of parallel unconfirmed FMS ser-

vices to the remote communication partner. For each unconfirmed FMS service

which to be sent an own DTA requester state machine shall be available.

- max RAC contains the maximum permitted number of parallel unconfirmed FMS ser-

vices from the remote communication partner. For each unconfirmed FMS service

which is received an own DTA acknowledge state machine shall be available.

On connections for cyclic data transfer max SCC and max RCC shall have the value

0, because here no parallel confirmed services are permitted.

During connection establishment the resources of both communication partners are

checked to be compatible (see context test in LLI definition).

In the data transfer phase LLI uses up to four counters on each connection (SCC,

RCC, SAC, RAC) for the execution of parallel FMS services. LLI stores the number

of currently used state machines (DTC requester, DTC responder, DTA requester

and DTA acknowledge state machines) in these counters.

For the transmission of a confirmed LLI user service the LLI user passes a

DTC.req to LLI. LLI uses a free DTC requester state machine and increments SCC.

The arrival of the associated DTC_RES_PDU releases the DTC requester state ma-

chine and decrements SCC at the same time. If there is no free DTC requester

state machine left for the DTC.req (SCC = max SCC), LLI performs a connection

release.

Upon receipt of a confirmed LLI user service (DTC_REQ_PDU), LLI uses a free DTC

responder state machine and increments RCC. The arrival of the associated

DTC.res from the LLI user releases the DTC responder state machine and decre-

ments RCC at the same time. If there is no free DTC responder state machine left

upon receipt of a DTC_REQ_PDU (RCC = max RCC), LLI performs a connection re-

lease.

For the transmission of an unconfirmed FMS service on a connection FMS passes a

DTA.req to LLI. LLI uses a free DTA requester state machine and increments SAC.

The arrival of the associated DTA_ACK_PDU releases the DTA requester state ma-

chine and decrements SAC at the same time. If there is no free DTA requester

state machine left for the DTA.req (SAC = max SAC), LLI ignores the request.

Upon receipt of an unconfirmed FMS service (DTA_REQ_PDU) the LLI uses a free DTA

acknowledge state machine and increments RAC. If a free buffer is notified

(Buffer_free) the DTA acknowledge state machine is released and RAC is decre-

mented at the same time. If there is no free DTA acknowledge state machine left

upon receipt of a DTA_REQ_PDU (RAC = max RAC), LLI performs a connection re-

lease.

Page 468

PROFIBUS-Specification-Normative-Parts-6:1997

6.4 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

release is performed. They are always in the data transfer phase. Connectionless

communication relationships are especially appropriate for application processes

with the following requirements:

- Synchronization of local clocks

- Global alarms

- Synchronous start of process parts

- Snapshots of process objects

6.4.1 Broadcast Data Transfer

For the broadcast communication relationship the master sends an unconfirmed

message to all other stations (masters and slaves).

Broadcast communication relationships have the following features:

- The requester of a broadcast message is always a master.

- The receivers of a broadcast message are all other stations with exception of

the requester.

- Only the LLI service "DTU" (high or low priority) is permitted.

- Unconfirmed data transfer

Broadcast communication relationships use the following addressing in Layer 2:

- At the requester every LSAP (0, 2 to 62/NIL) may be used.

- At every receiver the global FDL address (127) and the global LSAP (63) shall

be addressed.

6.4.2 Multicast Data Transfer

For a multicast communication relationship the master sends an unconfirmed mes-

sage to a group of stations (masters and slaves).

Multicast communication relationships have the following features:

- The requester of a multicast message is always a master.

- The receiver of a multicast message is always a group of stations, which does

not include the requester.

- Only the LLI service "DTU" (high or low priority) is permitted.

- Unconfirmed data transfer.

Multicast communication relationships use the following addressing in Layer 2:

- At the requester every LSAP (0, 2 to 62/NIL) may be used.

- At every receiver the global FDL address (127) and an individual LSAP (0, 2 to

62/NIL) shall be addressed.

6.4.3 Mapping of FMS Services onto Layer 2

In this clause the sequence of the data transfer with connectionless communica-

tion relationships is described for the example of the characteristic FMS serv-

ice InformationReport. For a connectionless communication relationship only the

unconfirmed FMS services InformationReport, UnsolicitedStatus and EventNotifica-

tion are permitted. FMS maps these services on connectionless communication re-

lationships onto the LLI service DTU. LLI maps the DTU service onto the Layer 2

service SDN. Only this Layer 2 service allows the simultaneous addressing of

several stations.

Page 469

PROFIBUS-Specification-Normative-Parts-6:1997

For a multicast / broadcast communication relationship the InformationReport

service shall be used to write data in several or in all other stations (masters

and slaves).

Every user request (InformationReport.req) is mapped by FMS onto a DTU.req and

results in a transmission of an INFO_REQ_PDU from the requester to the receivers

using a SDN_REQ_PDU. The resulting FDL_DATA.con causes no action in the LLI of

the requester. At the receivers, the FDL_DATA.ind causes the LLI to pass a

DTU.ind to FMS. FMS constructs the InformationReport.ind for the user out of the

DTU.ind.

Page 470

PROFIBUS-Specification-Normative-Parts-6:1997

Requester Receiver 1

Master . Master/Slave

.

User!FMS LLI FDL BUS FDL LLI FMS!User

=====!====!==============!======.======!==============!====!=====

INFO.req ! ! ! !

<#5,Pri- ! ! ! !

ority> ! ! ! !

----> ! ! ! !

! ! ! !

[INFO_REQ_! ! ! !

PDU] ! ! ! !DTU.ind

! ! ! !<#8,LLI

---->![DTU_REQ_PDU] !**INFO_REQ_ ! !SAP,Pri-

DTU.req ! ! PDU ! !ority,

<#5,LLI ! !*DTU_REQ_PDU ! !INFO_REQ_

SAP,Pri- !(FDL_DATA.req)![SDN_REQ_PDU]!(FDL_DATA.ind)!PDU>

ority, ! ]------->!--+--+------>!------------->!--->

INFO_ ! [<-------!--) ! ! ! INFO.ind

REQ_PDU> !(FDL_DATA.con)! ! ! ! <#8,Pri-

! ! ! ! ! ority>

! ! ! ------>

! ! !

! !

! ! Receiver 2

! ====================!====.=====

! ! !DTU.ind

! ! !<#9,LLI

! ! !SAP,Pri-

! ! !ority,

! ! !INFO_REQ_

! !(FDL_DATA.ind)!PDU>

+------>!------------->!--->

! ! ! INFO.ind

! ! ! <#9,Pri-

! ! ! ority>

! ! ! ---->

! ! !

! !

! ! Receiver n

! ====================!====.=====

! ! !DTU.ind

! ! !<#6,LLI

! ! !SAP,Pri-

! ! !ority,

! ! !INFO_REQ_

! !(FDL_DATA.ind)!PDU>

+------>!------------->!--->

! ! INFO.ind

! ! <#6,Pri-

! ! ority>

! ---->

!

Figure 91. Broadcast Communication Relationship / Mapping of an unconfirmed FMS

Service for the Example of InformationReport Service

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

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