semi合集-English.pdf - 第2024页

SEMI E54.8-0305 © SEMI 1999, 2005 6 6.4.3.1. 1 A set of services are defined for these object classes. 6.4.3.2 IO Data is handled mainly by buffered servi ces which allow decoup ling between application an d communicatio…

SEMI E54.8-0305 © SEMI 1999, 2005 5

6.1.1 Message transfer is organized in cycles. A message cycle mainly consists of a request-frame followed by a

corresponding acknowledge/response-frame of the addressed station. An exception to this is the global-control

function for synchronization and coordination of several remote I/O stations.

6.1.2 A brief description of the PROFIBUS-DP protocol as it relates to the ISO 7498 OSI model follows in the

sections below. For protocol efficiency, PROFIBUS-DP does not define layers 3 to 6. Layer 7 is the interface

between the Application Process and the communication stack.

NOTE 1: The information contained in this section is for reference only. It in no way represents specifications for PROFIBUS-

DP. See related documentation for these specifications.

6.2 Physical Layer — Layer 1

6.2.1 There are three options specified for the Physical Layer (PHY): Manchester Coded Interface for Bus Powered

Systems, RS-485 and Optical. See the PROFIBUS-DP standard for more information about these options.

6.3 Data Link Layer — Layer 2

6.3.1 Data Transfer

6.3.1.1 The Data Link Layer or Fieldbus Data Link (FDL) provides the functions for sending and receiving data

over the network. Protocol Data Units (PDU) are packaged, delivered, and checked. Acknowledgements,

responses, retries, and timeouts are used to guard against Line Protocol Errors (e.g., frame, overrun, and parity) and

Transmission Protocol Errors (e.g., start and end delimiters, frame check, frame length, and response times).

6.3.1.2 A PDU is restricted to 246 bytes. In addition to the PDU, a transmission frame of variable length will

contain 8 bytes of overhead; one of fixed length (8 bytes) will contain 6 bytes of overhead. Various

acknowledgement and response frames are also defined.

6.3.1.3 To better understand the FDL, a summary of FDL data transfer services is given by the following list:

 Send Data with Acknowledge (SDA),

 Send Data with No Acknowledge (SDN), and

 Send and Request Data with Reply (SRD).

6.4 Application Layer — Layer 7

6.4.1 The PROFIBUS application layer is structured in a so called service definition and protocol specification.

The service definition uses an object orientated approach and specifies the services for remote access and local

functions together with their objects (the ASE is a class definition of these objects). The protocol specification

includes both coding and state machines.

6.4.2 Service Definition

6.4.2.1 Application layer services are structured to reflect the needs of flexible configurable automation devices. A

Device consists of a set of modules that are placed in slots (see Figure 2). Modules are addressed uniquely by the

slot number. The module view can be a hardware oriented or reflects the software structure of the DP-Slave.

6.4.3 Slot 0 is used to address the DP Slave itself. Subslot 0 represents the module and contains no IO Data. The

other object classes can have instances scattered over the modules addressed by slot number. Each module can

contain IO Data, Context parameter, Diagnosis information, Process Data and Alarms. Process Data is a generic

class which can contain different application specific parameters accessible by read and write services. There is a

set of identification and maintenance parameters defined in a PROFIBUS Guideline.

6.4.3.1 Object classes are defined for:

 IO Data for periodic reporting,

 Context for configuration,

 Diagnosis for event collection,

 Process Data for polled access, and

 Alarms for asynchronous event reporting.

SEMI E54.8-0305 © SEMI 1999, 2005 6

6.4.3.1.1 A set of services are defined for these object classes.

6.4.3.2 IO Data is handled mainly by buffered services which allow decoupling between application and

communication. Client/Server service structure (request/response) is used for Record Data, Context and Diagnosis.

6.4.4 Protocol Specification

6.4.4.1 A DP-Slave shall get a FDL address before using it in the target configuration.

6.4.4.2 To access a DP-Slave the DP-Master has to check the availability with a Slave-Diag service. To establish

the context a SetPrm service is issued first. A check is done to ensure that the appropriate device type with the

required resources is accessed. The following ChkCfg service. Another Slave Diag service has been used to check

the establishment of the application relationship.

6.4.4.3 After this start up procedure the data exchange of IO data can be done and alarms can be signaled from the

DP Slave to the DP Master. The DP Master can invoke services to read and write process data that contain all kind

of information e.g. produced units, calibration information, and batch information.

6.4.4.4 A context is monitored by the Data Exchange Service at the DP-Slave. The DP-Master monitors the

communication by the receipt of the responses to the FDL services.

6.4.5 Data Link Mapping Protocol Machine (DMPM)

6.4.5.1 The DMPM performs the interpretation of service requests from, and responses to, the Application Protocol

Machines. Table 2 is included to demonstrate the basic structure of the PROFIBUS-DP DMPM. For speed and

efficiency, the PROFIBUS-DP protocol defines the Service Access Point (SAP). These are included in the

transmission protocol to direct messages within the device for fast dedicated processing. Defined are Destination

SAP (DSAP) and Source SAP (SSAP).

6.4.6 I&M Functions

6.4.6.1 “Identification & Maintenance Functions” (I&M functions) define general parameters and protocols. The

main purpose of the I&M functions is to support the end user during various scenarios of a device’s life cycle be it

configuration, commissioning, parameterization, diagnosis, repair, firmware update, asset management, audit

trailing, and alike. Well-defined uniform parameters and rules should enable the manufacturers to offer devices that

behave in a uniform manner These profile guidelines take into account requirements from FDA (Food & Drug

Administration) and others. The basic information offered can be characterized as “Type Plate” or “Boiler Plate”. It

consists of Manufacturer ID, Order ID, Serial Number, Hardware Revision, Software Revision, Revision Counter,

and Profile ID.

DP Slave

...

Slot0

Slot 1 carries

M o dule x

...

Record Data

Diagnosis

Alarm

IO Data

Context

Slot n carries

Module y

Figure 1

Device Model

SEMI E54.8-0305 © SEMI 1999, 2005 7

Table 2 DMPM Primitive Functions

DMPM Function Description SSAP DSAP FDL SRV

Master-Slave

Data_Exchange Exchanges I/O Data NIL NIL SRD

Check_Cfg Sends Configuration to DP-Slave for verification. 62 62 SRD

Set_Prm Sends Parametric Data to DP-Slave. 62 61 SRD

Slave_Diag Retrieves the Diagnostic Data Structure from a DP-Slave. 62 60 SRD

Get_Cfg Retrieves the Configuration Data Structure from a DP-Slave. 62 59 SRD

Global_Control Controls the Operational and Synchronization of DP-Slaves. 62 58 SDN

DPM2-Slave

RD_Outp Retrieves the Status of the Outputs of the DP-Slave. 62 57 SRD

RD_Inp Retrieves the Values of the Inputs of the DP-Slave. 62 56 SRD

Set_Slave_Add Sets the Node Address of a DP-Slave. 62 55 SRD

Master-Master

Various Services for Master-Master Communications 54 54 SRD/SDN

Master-Slave — Extended Communications

Read/Write Acyclic Read/Write of DP-Slave Data 51 51 SRD

DPM2-Slave — Connection Configuration

Initiate/Read/Write ... Services for Control and Management of the MS2 Connection 50 x..49 SRD

6.4.7 Service Access Point (SAP)

6.4.7.1 The Service Access Point provides standard access addressing for messages. The FDL message frame

includes fields for Source and Destination SAP. By directing a message to a particular Destination SAP, its context

is immediately known. This provides a fast and interoperable environment for device messaging.

6.4.8 Device Profile/Device Data Base

6.4.8.1 PROFIBUS devices have different performance characteristics. Features differ in regard to available

functionality (i.e., number of I/O signals and diagnostic messages) or possible bus parameters such as baud rate and

time monitoring. These parameters vary individually for each device type and vendor. These parameters are usually

documented in the technical manual. To achieve simple plug-and-play configuration of PROFIBUS, the

characteristic features are specified in an electronic data sheet called a Device Data Base file or GSD file.

6.4.8.2 The GSD Files provide a clear and comprehensive description of the characteristics of a device type in a

precisely defined format. These are prepared individually by the vendor for each type of device and made available

to the user in the form of a Device Data Base Sheet and a GSD File. The device data base file is divided into three

parts: General Specifications, Master Related Specifications, and Slave Related Specifications.

6.4.8.3 These GSD Files are maintained and managed by the PROFIBUS Trade Organization.

6.5 Network Management

6.5.1 The PROFIBUS-DP system is managed through several phases of operation. A Master device must have

knowledge of the Device Profile for each of the Slave devices it will connect. The Device Data Base Files serve this

purpose. Upon initialization, a Master will control a DP-Slave through three operational modes: Parameterization,

Configuration, and I/O Data Exchange. In any operational mode, a Master may interrogate a DP-Slave for its

Diagnostic information.

6.5.2 In the sections that follow, these operation modes are mapped to related SAN CDM behavior states.

7 Required Object Types

7.1 This section describes a general mapping of the SEMI SAN Object Model to the PROFIBUS-DP environment.

Component definitions are clarified and the mapping of Attributes, Services, and Behaviors are specified.