semi合集-English.pdf - 第2784页

SEMI E98-1102 © SEMI 2000, 2002 49 RELATED INFORMATION 4 OBEM EQUIPMENTIODEVICE AN D SENSOR/ACTUATOR NETWORK COMMON DEVICE MODEL NOTE: This related information is not an official part of SE MI E98 and was derived from wo…

SEMI E98-1102 © SEMI 2000, 2002 48

R3-1.5.2 This representation has the advantages of the “Tick since Epoch” representation for date value arithmetic.

Second, the separation of the date and time from a date value is simple. The date is the whole value, the time is the

fractional value. Third, the minimum time resolution is very small, and is not fixed by the representation.

R3-1.5.3 The following calculation is used to determine roughly the minimum time resolution that can be

expressed:

R3-1.5.4 The IEEE 8 byte floating point representation uses an excess 128 notation. This means 7 bits of exponent

and one bit of sign. This leaves 7 bytes of significant. On November 18, 1997 the day number is 35752. This is

hex 8BA8, and requires two bytes. This leaves 5 bytes of significant to represent the fractional day, or the time

portion of the date value. These 5 bytes of significant contain 40 bits, and can represent values to 2^ 40, or one part

in 1,099,511,627,776. There are 86,400 seconds in one day, so this representation is accurate to approximately

7.86E-08 seconds, or about 1/10 of a microsecond. In about a hundred years the day number will have doubled, and

this resolution will have shrunk by a factor of 2. For practical purposes the resolution is no worse than one

microsecond resolution.

Advantages Disadvantages

All legal float values are valid date values. Minimum resolution changes over time.

Simple to separate date and time from a date value. No simple way to convert date value to display format (but

simpler than the “Tick since the Epoch” representation).

Intervals are simple to express.

Date value arithmetic is simple.

The eight byte floating point representation used is supported

on most computer platforms.

The time resolution is not implied by the representation, but

is valid to very small intervals.

R3-1.6 Examples

11/18/1997 35752

11/18/97 1:03:13 PM 35752.543912037

One second 1.15740740740741E-05

One day 1

One microsecond 1.15740740740741E-11

1/1/1000 -328716

12/30/1899 0

SEMI E98-1102 © SEMI 2000, 2002 49

RELATED INFORMATION 4

OBEM EQUIPMENTIODEVICE AND SENSOR/ACTUATOR NETWORK

COMMON DEVICE MODEL

NOTE: This related information is not an official part of SEMI E98 and was derived from work developed in the Object-Based

Model Task Force in North America, and the Sunsor/Actuator Bus subcommittee. This related information was approved for

publication by full letter ballot on April 30, 2001.

R4-1 Relationship between OBEM

EquipmentIODevice and Sensor/Actuator

Network Common Device Model

R4-1.1 This section describes the relationship between

the EquipmentIODevice defined in Section 10.3 and the

Common Device Model defined in SEMI E54.1

Standard for Sensor/Actuator Network Common

Device Model.

R4-1.2 SEMI E54.1 defines in detail the internal

structure of a sensor/actuator device on an E54-

compliant sensor/actuator network. That is, it defines

the possible internal components of such a device and

the relationships between these components. To ensure

proper behavior, it was necessary to give sufficient

guidance to implementers using an E54 network

communication protocol. E54.1 defines sensor (input)

objects, actuator (output) objects, controller objects, a

sensor/actuator controller object (SAC), and a device

manager object (DM) as individual components of a

sensor/actuator device aggregation as components of an

aggregate Common Device Model (CDM). The device

aggregation must have at least one sensor or actuator or

controller (combined) and exactly one SAC and one

DM. In addition, the CDM defines additional classes to

further classify components, such as the ActiveElement,

Sensor, and Sensor-Analog Input classes, which should

be considered. Some attributes of the

EquipmentIODevice Observables only apply to

elements of certain classes.

R4-1.3 E54.1 does not define the CDM, which is the

aggregation of these elements, as an object in its own

right,. Such an aggregation might have the sum of all of

the attributes of its components.

R4-1.4 OBEM defines a high-level device, the

EquipmentIODevice, that is of interest to factory

system applications such as Advanced Process Control

(APC) and Fault Detection Classification (FDC). These

systems are seldom interested in all of the low-level

details. Actual raw data as read directly by an analog

sensor may not be desired but rather a calculated value

that has been converted into some specified units, such

as degrees Celsius. OBEM can support either.

R4-1.5 Some of the attributes of the

EquipmentIODevice are maintained only by the

equipment. Most of the attributes must come directly

from the attributes read from the CDM components for

E54.1 compliant devices. The following sections

suggest a way to relate attributes of the

EquipmentIODevice and attributes of the elements from

the CDM in a consistent manner.

R4-1.6 Each individual sensor or actuator or controller

element within the CDM corresponds to one

Observable in the EquipmentIOElement model.

Observables were not made into formal objects, as they

could be, but rather are included as one set of data

within the EquipmentIODevice. Each

EquipmentIODevice may have multiple sets of

Observables data.

R4-1.7 Table R4-1 lists all of the attributes of an

EquipmentIODevice, including those it inherits from

the AbstractEquipmentElement (marked with asterisks)

and shows the object and attribute in the General

Device Model hierarchy to which it corresponds, where

a correspondence exists.

R4-1.7.1 The “em dash” character “—”is used where

no correspondence exists.

R4-1.7.2 This table is intended for equipment

implementers of E98 and not for the suppliers of E54-

compliant devices.

SEMI E98-1102 © SEMI 2000, 2002 50

Table R4-1 Relationships between EquipmentIOElement and Generic Device Model

EquipmentIODevice

Attribute Name

Generic Device Model

Object Name

Corresponding Attribute Name

ObjType — —

ObjID — —

AlgorithmID — —

Cycles*

(units may be time)

SAC Run Hours (SacA5)

Description* — —

DeviceType Device Manager Device Type (DmA1)

Function* — —

HardwareRevision Device Manager Hardware Revision Level (DmA6)

ImmutableID* DeviceManager Serial Number (optional) (DmA7)

InService* — —

ModelNumber Device Manager Manufacturer Model Number (DmA4)

NumberofObservables — —

SoftwareRevision Device Manager Software or Firmware Revision Level (DmA5)

Supplier* Device Manager Device Manufacturer Identifier (DmA3)

Observable

DataDimension Sensor-Analog Input Class

element

—

Datatype Sensor-Analog Input Class or

Actuator-Analog Output Class or

Controller Class element

Datatype SaiA66or AaoA66 or Controller CA19

(translated for host as necessary to conform to SECS-II

format types (10,11,20, etc.)

DeltaValue Sensor of Sensor-Analog Input

Class element

ReportDelta (SaiA70)

InterlockStatus — —

Name Sensor or Actuator or Controller Text strings “SenIn” or “ActIn” or “CntIn” where n

represents the instance number of the corresponding

device object (Table 2, E54.1)

NominalValue — —

ObservableType — —

Possible Units — —

Range — —

ReadRate — —

ReportChange Sensor-Analog Input Class

element

EnableReportROC SaiA71

ReportRate Sensor-Analog Input Class

element

ReportROC SaiA72

Timestamp Device Manager Date and Time (DmA21)

Units Sensor-Analog Input or Actuator-

Analog Output Class element

DataUnits (SaiA67 or Aao67)

Value Sensor or Actuator or Controller Value or Setting (nA16) or Setpoint (CA16)