SEMI E STANDARD FOR SENSOR/ACTUATOR NETWORK COMMUNICATIONS FOR PROFIBUS-DP

Transcription

1 SEMI E STANDARD FOR SENSOR/ACTUATOR NETWORK COMMUNICATIONS FOR PROFIBUS-DP This standard was technically approved by the Global Information & Control Committee and is the direct responsibility of the North American Information & Control Committee. Current edition approved by the North American Regional Standards Committee on April 15, Initially available on SEMI OnLine August 1999; to be published September Purpose 1.1 This specification is part of the SEMI Sensor/Actuator Network (SAN) suite of standards and defines a specific communications protocol based on the PROFIBUS-DP standard. This Network Communication Standard (NCS) taken together with the SEMI Sensor/Actuator Network standard suite and the PROFIBUS standard completely and unambiguously defines an open standard providing an industry specific solution to off-the-shelf interoperability of networked devices in semiconductor manufacturing equipment. 1.2 PROFIBUS is a vendor independent, open fieldbus standard for a wide range of applications in manufacturing, process and building automation. Vendor independence and openness are guaranteed by the European standard for PROFIBUS, EN PROFIBUS-DP is one version of PROFIBUS which is optimized for high speed and inexpensive connectivity between automation control systems and distributed I/O at the device level. 2 Scope 2.1 This document specifies a SAN communications standard based on the PROFIBUS-DP specification that is in compliance with SEMI E54.1. As such, it specifies the protocol, services, and behavior that compliant intelligent devices must support in order to interchange information over this SAN in a method compatible with SEMI E In conjunction with a SEMI st andard SAN Common Device Model (CDM) specification and one or more SEMI standard Specific Device Model (SDM) specifications (e.g., for a mass flow controller), this Network Communication Standard (NCS) with the related PROFIBUS-DP standard describe the data structures, interactions, and behavior that are characteristic of the various devices on the network. This composite model forms a complete interoperability standard for communications among intelligent sensors, actuators, and controllers in semiconductor manufacturing equipment. 2.3 This standard does not purport to address all of the safety issues associated with its use. It is the responsibility of the users of this standard to establish appropriate safety and health practices and determine the applicablity of regulatory limitations prior to use. 3 Limitations 3.1 This document specifies a semiconductor equipment SAN based solely on PROFIBUS-DP and is a companion document to the PROFIBUS-DP specification, including, by reference, the PROFIBUS-DPV1 standard; thus, a complete specification of this standard necessarily includes the PROFIBUS-DP specifications. There are other semiconductor equipment SAN communications options. The specifications for these options are not included here. 3.2 The specifications within are s trictly enhancements that provide additional capabilities over and above those currently required by PROFIBUS-DP. Included throughout this document, primarily in Section 6, is information paraphrased from the PROFIBUS-DP specifications such as: protocol structure, capabilities, options, and limitations. This information is provided here for reference only and is not intended to provide specification definitions. In all such areas, refer to the PROFIBUS-DP specification documents for information. This document is limited to describing enhancements or limitations to the PROFIBUS-DP specification that are imposed by this standard. 3.3 A complete specification of th e conformance testing procedure shall include the PROFIBUS-DP protocol conformance testing specification. Conformance testing shall also include enhancements and limitations to the PROFIBUS-DP specification required by this standard. 4 Referenced Standards 4.1 SEMI Standards SEMI E39 Object Services Standard: Concepts, Behavior, and Services SEMI E54.1 Standard for Sensor/Actuator Network Common Device Model SEMI E54.3 Specification for Sensor/Actuator Network Specific Device Model for Mass Flow Device 1

2 4.2 ISO Standard 1 ISO 7498 OSI Basic Reference Model for Open Systems Interconnection 4.3 Other Standard EN Volume 2 DIN Part 1 to 4 PROFIBUS Standard 23 NOTE 1: As listed or revised, all documents cited shall be the latest publications of adopted standards. 5 Terminology 5.1 Acronyms CDM Common Device Model CSRD Cyclic Send and Request Data DDLM Direct Data Link Mapper DP Decentralized Periphery DPM1 DP-MasterClass1 DPM2 DP-MasterClass2 DPV1 DP Extensions Version 1 DSAP Destination SAP FDL Fieldbus Data Link FMA1/2 Fieldbus Management for Layers 1 and 2 NCS Network Communication Standard OSI Basic Reference Model for Open Systems Interconnection (ISO 7498) PDU Protocol Data Unit PHY Physical Layer SAN Sensor/Actuator Network SAP Service Access Point SDA Send Data with Acknowledge SDM SpecificDeviceModel SDN Send Data with No acknowledge SRD Send and Request Data with reply SSAP SourceSAP 1 International Organization for Standardization, 1 rue de Varembe, Case postale 56, CH-1211, Geneva 20, Switzerland 2 Deutches Institut für Normung e.v., Beuth Verlag GmbH, Burggrafenstrasse 4-10, D Berlin, Germany, PROFIBUS Trade Organization, 5010 East Shea Blvd., Scottsdale, AZ 85254, USA 3 The original Profibus standard was the DIN standard listed, in March 1996, the DIN standard became the EN standard listed. UI User Interface 5.2 Terminology Defined in Sensor/Actuator Network Common Device Model (SEMI E54.1) attribute behavior byte common device model device Device Manager (DM) Object device model instance network communication standard object Sensor, Actuator and Controller (SAC) Object service specific device model state diagram 5.3 Terminology Defined in PROFIBUS Device Data Base an electronic file that provides a clear and comprehensive description of the characteristics of a device type in a precisely defined format. Also called a GSD File. Device Profile a Device Data Base Sheet, which specifies the characteristic features of a device, and a GSD File. Direct Data Link Mapper a protocol layer that provides an interface to the User Interface Layer by translating service requests and responses between the User Interface Layer and the Fieldbus Data Link. DP-Master Class 1 (DPM1) a device that polls its assigned DP-Slave devices and handles user data exchange. DP-Master Class 2 (DPM2) a device that interacts as a configuration or diagnostic tool; usually a programming device. DP-Slave a device that is configured, managed, and polled by Master devices; a DP-Slave initiates no unsolicited communications. Fieldbus Data Link the PROFIBUS-DP model for the OSI Layer 2 definition. GSD File see Device Data Base Service Access Point an addressable location in a device for the directing of service requests. 2

3 Send Data with No acknowledge a service request that sends data with no reply. Send and Request Data with reply a service request that sends data followed by a reply by the receiving device. Slave Diagnostics a method of retrieving a specifically formatted Data Structure that represents the diagnostic status of a DP-Slave. 5.4 Terminology Defined in This Document DP Service Protocol a messaging specification for the request of, and response to, services for the PROFIBUS-DP NCS using the PROFIBUS-DP standard. DPV1 Service Protocol a messaging specification for the request of, and response to, services for the PROFIBUS-DP NCS using the PROFIBUS-DPV1 standard. 6 Communication Protocol High Level Structure 6.1 In a typical remote I/O configuration, single master architectures are used to optimize response times. In lower speed applications, multi-master architectures are also possible. PROFIBUS-DP uses the polling principle for communication (Master-Slave method) Message transfer is organized in cycles. A message cycle mainly consists of a request-frame followed by a corresponding acknowledge/responseframe of the addressed station. An exception to this is the global-control function for synchronization and coordination of several remote I/O stations A brief description of the PRO FIBUS-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 7. However, since the OSI model specifies Layer 7 as the interface between the Application Process and the communication stack, it is appropriate to discuss several aspects of the PROFIBUS-DP standard at this level. These include: the Direct Data Link Mapper, the User Interface, the Service Access Point, the Device Profile, and the Device Data Base. NOTE 2: 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 There are currently two option s specified for the Physical Layer (PHY): RS-485 and Optical. See the PROFIBUS-DP standard for more information about these options. 6.3 Data Link Layer Layer Data Transfer 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) A PDU is restricted to 246 bytes. Preferably, the PDU size should not exceed 32 bytes for optimum performance. 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 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), Send and Request Data with Reply (SRD), and Cyclic Send and Request Data with Reply (CSRD) Bus Management The Fieldbus Management for Layers 1 and 2 is provided by the FMA1/2 component. The FMA1/2 acts as a mediator between the local FMA1/2 user and layers 1 and 2. Requests from the FMA1/2 user, modified as required, are transferred to the FDL and PHY control, and acknowledged with a confirmation to the local FMA1/2 user. The FMA1/2 immediately receives indications from the FDL and PHY if status changes have occurred within the layers, which then leads to an FMA1/2 user indication. 6.4 Application Layer Layer As stated above, PROFIBUS-DP does not define Layer 7. The following components may be considered part of, or above, Layer Direct Data Link Mapper (DDLM) The DDLM performs the interpretation of service requests from, and responses to, the User Interface (UI). The DDLM offers a well defined, easy interface between the UI and the FDL. Table 1 is included to demonstrate the basic structure of the 3

4 PROFIBUS-DP DDLM. 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) User Interface (UI) The UI provides the user with access to functionality of the PROFIBUS-DP protocol. There is one UI definition for DPM1 devices and one for DPM2 devices. To better understand the UI, a summary of application functions follows: DPM1 and DPM2 UI Master-Slave Application Functions Read Diagnostic Information of DP-Slaves Cyclic User Data Exchange Parameterization and Configuration Checking Submit Control Commands DPM2 UI Master-Slave Application Functions Read Configuration of a DP-Slave Read Input/Output Values Address Assignment to DP-Slaves Table 1 DDLM Primitive Functions DDLM Function Description SSAP DSAP FDL SRV Master-Slave DDLM_Data_Exchange Exchanges I/O Data NIL NIL SRD DDLM_Check_Cfg Sends Configuration to DP-Slave for verification SRD DDLM_Set_Prm Sends Parametric Data to DP-Slave SRD DDLM_Slave_Diag DDLM_Get_Cfg DDLM_Global_Control DDLM_RD_Outp DDLM_RD_Inp Retrieves the Diagnostic Data Structure from a DP-Slave. Retrieves the Configuration Data Structure from a DP-Slave. Controls the Operational and Synchronization Modes of DP-Slaves. DPM2-Slave Retrieves the Status of the Outputs of the DP- Slave. Retrieves the Values of the Inputs of the DP- Slave SRD SRD SDN SRD SRD DDLM_Set_Slave_Add Sets the Node Address of a DP-Slave SRD DDLM_xxx DDLM_Act_Para_Brct Master-Master Various Services for Master-Master Communications Accept and Activate the most recent Download of Parameters. Master-Slave Extended Communications SRD SDN DDLM_Read Acyclic Read of DP-Slave Data SRD DDLM_Write Acyclic Write of DP-Slave Data SRD DDLM_xxx DPM2-Slave Connection Configuration Various Services for Control and Management of the MSAC_C2 Connection

5 DPM2 UI Master-Master A pplication Functions Read DP-Master Class 1 Diagnostic Information of the Associated DP-Slaves Upload and Download of Parameters Activate Bus Parameters Activate and Deactivate DP-Slaves Select Operating Mode of a DP-Master Class Service Access Point (SAP) 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 Device Profile/Device Data Base 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 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 These GSD Files are maintain ed and managed by the PROFIBUS Trade Organization. 6.5 Network Management 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 In the sections that follow, the se 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. 7.2 Object Model The Object Model defined in the CDM is represented in the PROFIBUS NCS. Specifically, the DM and SAC objects are mapped The Application Objects associated with the SDM standards are mapped in PROFIBUS-DP Device Data Base documents as defined above in the Device Profile/Device Data Base section. Section 9 specifies the mapping of SDM Objects in PROFIBUS-DP. 7.3 Component Mapping Summary Table 2 provides a summary of the components of the CDM object model as they relate to the components of PROFIBUS-DP. Table 2 Component Mapping Summary SEMI SAN PROFIBUS-DP Definition Object Component Device Component Attributes DM Identification and related device attributes Remote Device Data Base DM Status and Exception Slave Diagnostics Active Element DM & Active Element Input/Output Master/Slave I/O Data Exchange Configuration Slave Configuration 5

6 SEMI SAN PROFIBUS-DP Definition Object Component Device Component Services All Get_Attribute and Set_Attribute Behavior States Master/Slave Service Request DM & SAC Reset Slave Service Request Master_Unlock DM & SAC Operate and Recover Slave Service Request Send Parameter Data Check Configuration DM & SAC Abort Slave Service Request Clear_Data DM & SAC Initialized/Self Testing Slave Wait_Prm DM & SAC Idle Slave Wait_Cfg DM & SAC Executing Slave Data_Exch DM & SAC Self Test Exception and Critical Fault Slave Diag.Station_Not_Ready DM & SAC Abort Slave Device Clear 7.4 Objects The required objects of the CDM are identified here. Additional objects that are contained in the SDM are given identifiers in the Device Profile. Section 9 specifies additional mapping information Table 3 lists the Object Identif iers specified for use in protocol messages. Table 3 Object Identifiers Object ID Object 0 Invalid 1 DM Object 2 SAC Object 3 n Application Objects as specified in Section Attributes All attributes are accessible via Get_Attribute and Set_Attribute services defined in the sections below. Additionally, attributes are accessible via different PROFIBUS-DP defined methods which are mapped in this document based on attribute type The attributes of the DM object are divided into three types: Identification, Status, and Configuration. Identification attributes are communicated with the Device Data Base. Status attributes are communicated using the DP-Slave Diagnostic method. Configuration attributes are communicated using the Configuration method The attributes of Application objects are divided into two types: Input/Output and Configuration. Input/Output attributes are communicated using the I/O Data Exchange method. Configuration attributes are communicated using the Configuration method See Table 5 for a list of DM attributes and their related alternative access methods PROFIBUS-DP Device Data Base The specification of the Device Data Base (or GSD file) for a given SDM is beyond the scope of this document. The PROFIBUS Trade Organization is responsible for the management of these files Table 5 lists which attributes o f the CDM are mappedtothegsdfile PROFIBUS-DP Slave Diagnostics The two attributes of the DM object listed in Table 5 that are identified with an alternative access method of slave diagnostics are mapped into the PROFIBUS-DP Slave Diagnostics as specified in this section. See the PROFIBUS-DP standard for a description of the DP Slave Diagnostics These two attributes, each a single byte in length, are mapped into the Slave Diagnostic data structure. Additional diagnostic data may be included as specified by PROFIBUS-DP In response to a DDLM_Slave_Diag request, the device responds with its Diag_Data. Specifically, Table 4 shows the mapping that applies to the Device Related Diagnostic Block. 6

7 Table 4 Device Related Diagnostic Block Format Byte Definition Value 0 Length 3 1 Octet 1 Device Status 2 Octet 2 Exception Status PROFIBUS-DP I/O Data Exchange Input/Output attributes of the Application objects are communicated using the I/O Data Exchange method of PROFIBUS-DP. This method is described in the PROFIBUS-DP standard. A list of which attributes are accessible with this method is included in the PROFIBUS Device Profile for a given device type PROFIBUS-DP Configuration Configuration attributes of the DM object and Application objects are communicated using the Configuration method of PROFIBUS-DP. This method is described in the PROFIBUS-DP standard. A list of which Application object attributes are accessible with this method is included in the PROFIBUS Device Profile for a given device type Attribute Identifiers Every object specified in the CDM and SDMs uses tags to identify its attributes. These tags are formatted with letters (identifying the object) followed by an upper case A, followed by a numerical identifier. The Attribute ID used in the PROFIBUS-DP NCS is simply the numerical portion of these tags The PROFIBUS attribute ID is used to identify attributes for access via PROFIBUS-DP message requests, which are explained in later sections Table 5 shows the attributes defined in the SEMI CDM with the respectively mapped ID numbers. Also shown is the alternative PROFIBUS-DP access method. 7.6 Services PROFIBUS-DP specifies stand ard mechanisms for the communication of data over the network. These mechanisms are used to communicate attributes specified in the device model of a DP-Slave device. The attributes of the DM that are accessible with this method are identified in Table Additionally, PROFIBUS-DP specifies standard methods for the control of devices over the network. These mechanisms are used to control the basic operational states associated with a DP-Slave device. These standard mechanisms and methods are identified in this document but specified in the PROFIBUS-DP standard. Table 5 DM Object Attribute Identifiers SEMI CDM Attribute ID PROFIBUS Attribute ID Attribute Alternative Access Method DmA1 1 Device Type Device Data Base DmA2 2 Standard Revision Level Device Data Base DmA3 3 Device Manufacturer Identifier Device Data Base DmA4 4 Manufacturer Model Number Device Data Base DmA5 5 Software or Firmware Revision Level Device Data Base DmA6 6 Hardware Revision Level Device Data Base DmA7 7 Serial Number Device Data Base DmA8 8 Device Configuration Device Data Base DmA9 9 Device Status Slave Diagnostics DmA12 12 Exception Status Slave Diagnostics DmA13 13 Exception Detail Alarm N/A DmA14 14 Exception Detail Warning N/A DmA15 15 Visual Indicator N/A DmA16 16 Alarm Enable Configuration DmA17 17 Warning Enable Configuration 7

8 7.6.3 Service Requests There are two methods defined in this standard that allow service requests to be delivered to DP-Slave devices The PROFIBUS-DPV1 method can be used by devices with Extended Data Communications capabilities as defined by the PROFIBUS-DPV1 specification. The specification for communication of these service requests is defined in the following sections The PROFIBUS-DP method is used by devices without Extended Data Communications capabilities. Support of the PROFIBUS-DP method requires specific definitions for I/O Data Exchange data. These definitions are described in the following sections DPV1 Service Request For systems utilizing the Exten ded Data Communication capabilities, additional services may be requested over the network using the Extended Data Communications together with the DPV1 Service Request Protocol specified in this section The Extended Data Communication definition describes a method of establishing connections between a DPM1 and DP-Slaves via the Supplemental Service Access Point SAP DPV1 Service Request Protocol All service request messages, except Get- Attribute and Set_Attribute, are sent to a DP-Slave using the DDLM_Write function of PROFIBUS-DPV1. The responses to these message requests are specified by PROFIBUS-DPV The DPV1 Service Request message is formatted (as defined by PROFIBUS-DPV1) with the following Protocol Fields defined: Slot = Object ID Index = Table 6 shows the Data Fields defined by this standard for the Extended Data Communications. Table 6 Data Field of DPV1 Service Request Protocol Byte Description 0 Service Request ID 1 n Service Parameters NOTE 1: Service ID 4 (Get_Attribute) and Service ID 5 (Set_Attribute) are invalid for this protocol. The following two sections specify the protocol for these service requests DPV1 Set_Attribute Protocol The DPV1 Service Request message for the Set-Attribute is sent to a DP-Slave device using the DDLM_Write function of PROFIBUS-DPV1. It is formatted with the following protocol fields defined: Slot = Object ID Index = Attribute ID Data Field = Attribute Value The Slot and Index limit is 255 and data is limited to 244 bytes. Therefore, the Device Models of the PROFIBUS-DP devices defined here are limited to 255 Objects, each with no more than 255 attributes, each no larger than 244 bytes DPV1 Get_Attribute Protocol The DPV1 Service Request message for the Get-Attribute is sent to a DP-Slave device using the DDLM_Read function of PROFIBUS-DPV1. It is formatted with the following protocol fields defined: Slot = Object ID Index = Attribute ID The Slot and Index limits are as defined above for Set_Attribute. The response to this request is the attribute value DP Service Request Beyond that which is specified by PROFIBUS-DP, additional services may be requested over the network using the I/O Data Exchange method definition together with the DP Service Protocol specified in this section. Additionally, specified in this standard is a DP Service Response Protocol A DP-Slave device must identify support for the DP Service protocol in its GSD File. Support is enabled during the configuration of the DP-Slave device. In this mode of I/O Data Exchange, each data packet delivered to the DP-Slave device is formatted per the DP Service Request protocol and each data packet received from the DP-Slave device is formatted per the DP Service Response protocol The I/O Data Exchange data length must be specified for the longest message (MAX). That is, the DP-Slave device output data length must be set to accommodate the longest request message; and the input data must be set for the longest response message The SDM may specify service s in addition to what is specified in the CDM. However, for reference, support of the services of the CDM requires a maximum request message length of three bytes plus the maximum data value length associated with the Set_Attribute. 8

9 In the same context, support of the services of the CDM requires a maximum response message length of one byte plus the maximum data value length associated with the Get_Attribute DP Service Request Protocol The output data communicated to a DP-Slave device configured for DP Services is formatted as specified in Table 7. Table7 DataI/ODataFieldforDPService Request Protocol Byte Description 0 Object ID 1 Service ID 2 through n Service Parameters (n+1) through Max Zero DP Service Response The response to a service request may or may not contain data based upon the type of request. However, all service responses contain a Response Code A Response Code of Zero indicates a successful service completion. A non-zero Response Code indicates an error. An error is identified via the DP-Slave diagnostics DP Service Response Protocol The input data communicated from a DP-Slave device configured for DP Services is formatted as specified in Table 8. Table8 DataI/ODataFieldforDPService Response Protocol Byte Description 0 Response Code 1 through n Data (n+1) through Max Zero Service Identifiers The required services of the CDM are identified here. Additional services that are contained in the SDM are given identifiers in the Device Profile. Table 9 specifies the required services and ID numbers. Table 9 Service Identifiers Service ID Service 0 Invalid 1 Reset 2 Abort 3 Recover 4 Get Attribute 5 Set Attribute 6 Execute 7 Perform Diagnostics Specified Services The following sections define the details associated with each of the services required by the CDM Reset The Reset Request specifies no parameters In addition to an explicit Reset Service Request, PROFIBUS-DP specifies others methods whereby a DP-Slave device can be reset. The following sections describe methods by which a DP-Slave will execute a reset Startup During the startup phase, a DP- Master locks the DP-Slave for protection. A DP-Master can also unlock a DP-Slave which causes a Reset to the DP-Slave Incorrect Configuration If a DP-Master delivers an incorrect set of data for parameterization or for configuration to a DP-Slave, it will automatically resetthatdp-slave Watchdog A DP-Slave will automatically reset upon the expiration of its watchdog timer. During the startup phase, a DP-Master sends a Watchdog Time to the DP-Slave. This time must be longer than the Buscycle time for the DP-Slave to operate properly. A DP-Master can also send a Watchdog Time to a DP- Slave during normal operation. Therefore, a DP-Master could affect a reset by intentionally sending a Watchdog Time that is shorter than the Buscycle time Abort The Abort Service Request specifies no parameters Recover The Recover Service Request specifies no parameters Get Attribute As defined ab ove, in the section on attributes there are several methods used to retrieve the value of an attribute: Device Data Base, 9

10 DP-Slave Diagnostic, I/O Data Exchange, and explicit use of the Get Attribute Service request Set Attribute As defined above, there are several methods used to set the value of an attribute: Configuration, I/O Data Exchange, and explicit use of the Set Attribute Service request Execute The Execute Service Request specifies no parameters Perform Diagnostics The Perform Diagnostic Request specifies one parameter: Test ID. The Test ID parameter is one byte in length, as specified in the CDM. 7.7 Behavior The behavior of PROFIBUS-DP devices is broken down by device type. A DP-Master device controls the operational modes of its assigned DP-Slave devices and polls them using a cyclic communication scheme. This cyclic communication is used to set outputs, read inputs and check the status of DP-Slaves. DP-Slave devices implement the CDM and one or more SDM standards in addition to the DP-Slave standards for behavior DP-Master A DPM1 device can be controlled either locally or via the network by the configuration Device. A DPM1 device has three main states as described in Table 10: Table10 DPM1BehaviorStates State Stop Clear Operate Description No data transmission between the DPM1 and DP-Slaves occurs. The DPM1 reads input information from the DP-Slaves and holds the outputs in fail-safe status. The DPM1 is in the data transfer phase. In a cyclic communication scheme, inputs of the DP-Slaves are read and output information is written to the DP-Slaves DP-Slave The DM object shares a unique relationship with the DP-Slave device. State Transitions associated with the DP-Slave device cause analogous transitions in the DM Object. However, Transitions associated with the DM object may, or may not, cause transitions in the DP-Slave device There are essentially four state s associated with a DP-Slave device. These states are mapped to the states of the CDM DM Model. Any change of state in one context (i.e., DM object or DP-Slave) causes the corresponding change of state in the other context. This mechanism is achieved via implicit service requests automatically generated within the device to affect the correlated change of state Table 11 defines the correlation of DP-Slave states to DM object states. Table 12 shows the reverse correlation of DM object states to DP-Slave states. Table 11 DP-Slave Behavior States Effect on DM Object DP-Slave State Wait_Prm Wait_Cfg Data_Exch Device_Clear Resulting DM State Initialized/Self Testing Idle Executing Abort Table 12 DM Object Behavior States Effect on DP-Slave DM State Initialized/Self Testing Idle Executing Self Test Exception Critical Fault Abort Resulting DP-Slave State Wait_Prm Diag.Station_Not_Ready Data_Exch Diag.Station_Not_Ready Diag.Station_Not_Ready Device_Clear 8 Protocol Compliance 8.1 PROFIBBUS International has established a qualified certification system, with test laboratories in Europe and USA, which includes conformance testing and interoperability testing. Certified products are listed with their certificate number in the PROFIBUS Electronic Product Guide. 8.2 GSD files of all PROFIBUS-DP devices that are tested for their conformity to the PROFIBUS standard are available in the GSD library on the World Wide Web Server of the PROFIBUS User Organization at 10

11 9 Specific Device Model Ma ppings 9.1 Every type of device must have an identifier number. Vendors must apply for an identifier number from the PROFIBUS User Organization for every Device Type. In order to receive a valid identifier number, a Device Profile must be submitted in the form of a GSD File and Device Data Base Sheet The Device Profile must specify the identifiers for Objects, Attributes and Services for CDM and SDM components, including data formats and bit mappings for specified parameters, as represented in this document The following sections specify mappings for Sensor Actuator Network Specific Device Models. 9.2 Mass Flow Device Reference SEMI E54.3 for a complete specification of the SDM for Mass Flow Devices. Accordingly, the following mapping rules apply to the identification tags for the Objects, Attributes and Services of this model Objects Consistent with SEMI E54.3 and Section 7.4 above, the DM and SAC objects are identified as Object 1 and Object 2, respectively Notice that references for the Local Link Objects are not included; the existence of these objects are implied by behavior and not explicitly included. Therefore, these objects are not accessible from the network and the Sensor-AI-Aux Object is not supported. Also, Assembly Objects are defined in the Device Profile as required Table 13 shows the mapping of the SDM Object Instances specified in SEMI E54.3 Instance numbers are listed under the heading Instance in the table and the PROFIBUS Object ID is listed under ID in the table Attributes The mapping of Attribute Tags and Identifiers is defined in Section for the CDM. The same method applies here for the SDM Services The mapping of Service Tags and Identifiers is defined in Section for the CDM. The same method applies here for the SDM. NOTICE: SEMI makes no warranties or representations as to the suitability of the standards set forth herein for any particular application. The determination of the suitability of the standard is solely the responsibility of the user. Users are cautioned to refer to manufacturer s instructions, product labels, product data sheets, and other relevant literature respecting any materials mentioned herein. These standards are subject to change without notice. The user s attention is called to the possibility that compliance with this standard may require use of copyrighted material or of an invention covered by patent rights. By publication of this standard, SEMI takes no position respecting the validity of any patent rights or copyrights asserted in connection with any item mentioned in this standard. Users of this standard are expressly advised that determination of any such patent rights or copyrights, and the risk of infringement of such rights, are entirely their own responsibility. Table 13 MFD Object Identifiers SDM Object Name SDM Object ID Instance ID Sensor-AI-MF MFD3 1 3 Actuator-AO-MF MFD7 1 4 Controller MFD8 1 5 SISO-Setpoint MFD Sensor-AI-AT MFD4 1 7 NOTE 1: Additional objects may be defined by the manufacturer in the Device Profile for a given device. Copyright by SEMI (Semiconductor Equipment and Materials International), 805 East Middlefield Road, Mountain View, CA Reproduction of the contents in whole or in part is forbidden without express written consent of SEMI. 11