semi合集-English.pdf - 第2132页
SEMI E54.15-0305 © SEMI 2005 4 6 Communication Protocol High Level Struc ture 6.1 The SafetyBUS p protocol is loosely based on three layer architecture. These three la yers constitute a collaps ed form of the seven layer…
SEMI E54.15-0305 © SEMI 2005 3
5.2.4 ISO — International Standards Organization
5.2.5 MAC — Media Access Control
5.2.6 NCS — Network Communication Standard
5.2.7 OCS — Object Communications Specification
5.2.8 OSI — Open Systems Interconnect
5.2.9 SAC — Sensor, Actuator, Controller (Object)
5.2.10 SAN — Sensor/Actuator Network
5.2.11 SDM — Specific Device Model
5.3 Device Component Definitions
5.3.1 As this standard specification defines the presentation or mapping of CDM data structure and behavior over a
network, it makes use of many of the terms in the SEMI E54.1 CDM document. Table 1 provides a mapping of
fundamental terminology of the CDM document into this document and the SafetyBUS p standard specifications.
Note that Column 2 contains an equal sign “=” if the definition is used exactly as specified in the CDM
specification.
Table 1 Mapping of Common Device Model to NCS Terminology
CDM Term NCS Equivalent SafetyBUS p Equivalent
Device = =
Device Model = =
Class = Server Class
Object =, Class, Instance =, Server Class, Instance
Instance = =
Attribute = =
Behavior = =
Service = =
State Diagram = =
Byte = =
Nibble = =
Character String = =
5.4 SafetyBUS p Specific Definitions
5.4.1 Server Class — subset of devices that offer similar functions and provide fixed defined functionality in a
uniform way.
5.4.2 master/slave — communication over a SafetyBUS p network provides exclusive control of data by a “master”
or “host” device. All network input data is reported exclusively to the host when requested by the host, and the host
has exclusive control over the states of all network output signals of all nodes acting as its “slaves”. Master/Slave
communication provides the typical request/response oriented network communications.
5.4.3 peer-to-peer — On SafetyBUS p networks, messages formatted according to the SafetyBUS p protocol are
embedded into the SafetyBUS p packet structure that is used on the CAN network. The SafetyBUS p protocol over
CAN supports the asynchronous or unsolicited bi-directional transmission of data between nodes. This type of
communication is referred to as peer-to-peer.
5.4.4 SafetyBUS p — an open protocol maintained by Pilz GmbH & Co and distributed by SafetyBUS p Club
International as a reliable and standard means of interconnection for simple field devices. The SafetyBUS p
standard wraps a communication model and protocol as well as CAN specifications for OSI reference model layers
1 and 2, to provide a complete network definition. The OSI reference model layer 7 specifies the application layer.
SEMI E54.15-0305 © SEMI 2005 4
6 Communication Protocol High Level Structure
6.1 The SafetyBUS p protocol is loosely based on three layer architecture. These three layers constitute a collapsed
form of the seven layer OSI architecture which map into the physical, data link, and application layers of the OSI
Basic Reference Model (see ¶4.2). The high-level protocol architecture is shown in Figure 1.
Application Layer
Physical Layer
Data Link Layer
Physical Layer
Data Link Layer
Network Layer
Transport Layer
Session Layer
Presentation Layer
Application Layer
Layered View of SafetyBUS p
OSI Reference Model
Figure 1
Layered View of SafetyBUS p
6.1.1 Note that Figure 1 represents a conceptual view of the technology architecture. Conforming implementations
must implement the services defined in this specification at each layer and must appear (from the network) to have
implemented this architecture, however an internal modular partitioning is not required. Implementations may
sacrifice modularity in order to achieve high performance.
6.1.2 The application layer is specified in the SafetyBUS p OCS (see reference ¶4.3) and provides for the definition
of SafetyBUS p applications as a collection of addressable objects. A subset of these objects may be addressed over
the network (as defined by the implementation).
6.1.3 In the remainder of this section the protocol structure is described in more detail in terms of the OSI seven
layer reference model, the object model environment and network management specifications.
6.2 Physical Layer — The device shall comply with a physical layer specification identified in the Controller Area
Network (CAN) specification. Physical layer specification includes physical signaling (levels and data rates),
transceivers, node isolation, media topology, cable specifications, network connectors and taps, and power
considerations (load limits, system tolerances, and power supply options).
6.3 Data Link Layer — The device shall comply with a data link layer specification the Controller Area Network
(CAN) specification. Data link layer specification includes the media access control mechanism and the logical link
control mechanism.
6.4 Network Layer — There is no distinct Network layer.
6.5 Transport (Messaging) Layer — There is no distinct Transport layer.
6.6 Session Layer — There is no distinct Session layer.
6.7 Presentation Layer — There is no distinct Presentation layer.
6.8 Application Layer — The device shall comply with the SafetyBUS p application layer specification for defining
and addressing objects, including their attributes and services, and enabling specified network behavior. The device
shall comply with the object messaging and object model specifications included in the SafetyBUS p OCS. In
addition the device shall comply with the object specifications defined in §7 of this document.
6.8.1 Object Models — The SafetyBUS p protocol includes an object-oriented specification for addressing objects
explicitly, including their attributes and services, and communicating object attributes in an application dependent
format. The device shall comply with the object messaging and object model specifications included in the
SEMI E54.15-0305 © SEMI 2005 5
SafetyBUS p OCS documentation. In addition the device shall comply with the object specifications defined in §7
of this document.
6.9 Network Management — The device shall comply with the SafetyBUS p and CAN network management
specifications detailed in the SafetyBUS p standard and SafetyBUS p Guide to Programmable Safety Systems
Standard Specifications (e.g., physical layer bit rate, master/slave and peer-to-peer network management, etc.). No
(additional) network management functions are specified in this document.
7 Required And Optional Object Types
7.1 The SafetyBUS p standard specification does not require any specific objects to exist in a SafetyBUS p device
in order to be a compliant SafetyBUS p device. The SafetyBUS p standard specification is extended in this standard
to identify and describe objects (i.e. classes) that shall exist in devices that are to be interoperable and
interchangeable on a SafetyBUS p SEMI compliant SAN network.
7.1.1 The Common Device Model (CDM) specification (see reference SEMI E54.1 ¶4.1) identifies two objects
(namely the Device Manager (DM) and Sensor Actuator Controller (SAC) objects) that shall exist in all SEMI
compliant SAN devices.
7.1.2 The required object types for a SEMI compliant SAN device utilizing the network communication
specification described herein necessarily comprises, at minimum, the union of the SafetyBUS p object type
requirements and the CDM specification requirements.
7.1.3 A list of required and optional object types is given in Table 2. Additional objects that are specified in a
particular SDM are given identifiers in that SDM specification; SafetyBUS p specific presentation information for
these identifiers is given in Section 9 of this document.
Table 2 Required and Optional Object Types
Object Name SafetyBUS p
Class ID / Instance ID
#1
CDM Tag
#2
Required by
SafetyBUS p
#1
Required by
CDM
#2
Required
by NCS
Device Manager 1/1 DmI0 No Yes Yes
Sensor/ Actuator/ Controller 2/1 SacI0 No Yes Yes
Assembly 3/1 through i Asm No No No
Local Link 4/1 through j Lnk No No No
Sensor – AI 33/1 through k Sai No No No
Sensor – EI 34/1 through l Sei No No No
Sensor – BI 35/1 through m Sbi No No No
Actuator – AO 36/1 through n Aao No No No
Actuator – EO 37/1 through o Aeo No No No
Actuator – BO 38/1 through p Abo No No No
Controller 39/1 through q C No No No
Sensor – BI-TH 40/I through s Sbith No No No
Application Objects 129 through x/1 through r (3) No No No
#1
See SafetyBUS p specification for further information; values are decimal; ‘i’, ‘j’, ‘k’, ‘l’, ‘m’, ‘n’, ‘o’, ‘p’, ‘q’, ‘r’ and ‘s’ represent arbitrary
numbers (greater than or equal to 1) indicating that more than one instance may be supported. ‘x’ is a number greater than or equal to 129
indicating that one or more application object classes may be supported.
#2
See CDM specification for further information
#3
Application Dependent objects’ tags as specified in SDM
7.1.4 An embodiment of a specific device type represented as an aggregation of the object types listed in Table 2
that is compliant with both the CDM specification and the SafetyBUS p specification, is a candidate for a SEMI
SDM as well as a SafetyBUS p device definition. Conversely, all SEMI SDMs and SafetyBUS p device definitions
specified for operation over a SEMI compliant SafetyBUS p network must be an aggregation of the object types
listed in Table 2, and be compliant with both the CDM specification and the SafetyBUS p standard specifications.