semi合集-English.pdf - 第2783页

SEMI E98-1102 © SEMI 2000, 2002 48 R3-1.5.2 This rep resentation has the advant ages of the “Tick si nce Epoch” representation f o r date val ue arithmetic. Second, the separation of the date an d time from a date value …

100%1 / 7923
SEMI E98-1102 © SEMI 2000, 2002 47
RELATED INFORMATION 3
ADDITIONAL DATA
NOTE: This related information is not an official part of SEMI E98. This is Related Information for the provisional specification
and is not intended to modify or supersede the official standard. Determination of the suitability of the material is solely the
responsibility of the user.
This section provides examples of equipment models to clarify the standard.
This section contains additional information that is not part of the standard.
R3-1 Representations of Date and Time
R3-1.1 This section discusses several date and time representations, and provides background information in
support of the OBEM adoption of an IEEE floating point representation of date and time values.
R3-1.2 In this section, the term “date value” means an encoding of a date and time value, such as 12/25/1997
11:04:56.
R3-1.3 ASCII Digit Representation
R3-1.3.1 The standard date and time format in SECS communication is the ASCII representation
“YYYYMMDDhhmmsscc”. In this representation, date and time are represented as a fixed length sequence of
ASCII digit characters, grouped into fields as indicated.
Advantages Disadvantages
Very simple conversion to display format. Date computations difficult. For example, adding two date
values is not a trivial operation.
Simple to extract date and time from date value. Many digit sequences are not valid date values.
The format does not lend itself to expressions of time
intervals. The representation of “ten minutes” might be
“00000000001000”, but the job of adding this interval to a
date value is not simple.
The resolution of the representation is fixed at seconds.
R3-1.4 Long Signed Integer Representation
R3-1.4.1 UNIX represents date and time as the number of ticks since Epoch. Typically the time interval of a tick is
one second. Date values are expressed as the number of ticks since a certain instant, called the Epoch.
R3-1.4.2 There are 31,536,000 seconds in a 365 day year. If stored as a four byte signed integer, with ticks in
seconds, this representation will overflow after approximately 68 years. Eight byte integers provide sufficient range
for dates spanning human history many times. Unfortunately, eight byte integers are inconvenient on many
computer platforms.
Advantages Disadvantages
All bit sequences are valid date values. Difficult to separate date and time from date value.
Intervals are simple to express. Eight byte representation required for sufficient range, but
inconvenient on many computer platforms.
Date value arithmetic is simple. No simple way to convert date value to display format.
The resolution of the representation is fixed at the tick value,
typically seconds.
R3-1.5 Floating Point Representation
R3-1.5.1 This representation is used in many applications. It represents date values as floating point numbers, with
units of days past 12/30/1899. It is very similar to the “Ticks since the Epoch” representation, except that the tick
values are days.
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.