semi合集-English.pdf - 第2004页

SEMI E54.6-0997 © SEMI 1997, 2004 10 The type SCPT_rept _mode(*) contains two fou r -bit fields specifying the reportin g method for alarms and warning con ditions. For exam ple, in Neuron C, t he application pro grammin…

100%1 / 7923
SEMI E54.6-0997 © SEMI 1997, 2004 9
Table 6 Device Manager Object Network Variables
Name Storage Class CDM Tag Standard NV DataType
Device Type const DmA1 SNVT_str_asc or SNVT_str_int
Standard Rev. Level const DmA2 SNVT_str_asc or SNVT_str_int
Device Mfgr. Identifier const DmA3 SNVT_str_asc or SNVT_str_int
Mfr. Model Number const DmA4 SNVT_str_asc or SNVT_str_int
S/W or F/W Rev. Level const DmA5 SNVT_str_asc or SNVT_str_int
Hardware Rev. Level const DmA6 SNVT_str_asc or SNVT_str_int
Serial Number const DmA7 SNVT_str_asc or SNVT_str_int
Device Config’n const DmA8 SNVT_str_asc or SNVT_str_int
Device Status output DmA9 SNVT_dev_status
Reporting Mode config DmA10 SCPT_rept_mode
Exception Status Rept Interval config DmA11 SCPT_exc_sts_t
Exception Status output DmA12 SNVT_exc_status
Exception Detail Alarm output DmA13 SNVT_exc_detail
Exception Detail Warning output DmA14 SNVT_exc_detail
7.4.1 Device Manager Object Requests — Table 7 summarizes the services implemented by the Device Manager
object.
Table7 Device Manager Object Request Services
Service Name CDM Tag Service Code Request Parameters Result Parameters
Reset DmS1 1
Abort DmS2 2
Recover DmS3 3
GetAttribute# DmS4 4 Attribute ID## Attribute Value
SetAttribute### DmS5 5 Attribute ID##, Attribute Value
Execute DmS6 6
Perform Diagnostics DmS7 7 Test ID####
# The GetAttribute service may also be implemented as a network variable poll.
## The attribute ID is the numerical sequence number specified by the CDM tag for the attribute.
This is the same as the LonMark member ID of the network variable in its owning object.
### The SetAttribute service may also be implemented as a network variable update.
#### The Test ID parameter will be the first parameter in the Perform Diagnostics Request Parameters field.
The Publish (DmS8) notification service for the Device
Manager exception status is implemented when the
device updates the output network variable of type
SNVT_exc_status. This causes the value of this
network variable to be propagated across the network to
other network variable(s) to which it may be bound.
The implementation of the Device Manager object
updates this output network variable according to the
conditions specified by the Reporting Mode and
Exception Status Reporting Interval configuration
properties of the object.
7.4.2 Device Manager Object Constant Output
Network Variables — Table 6 lists the constant output
network variables of the Device Manager object. The
type of each of these network variables is either
SNVT_str_asc, a Standard Network Variable Type that
can represent from 0 to 30 ASCII characters, or
SNVT_str_int, a Standard Network Variable Type that
can represent from 0 to 14 international 16-bit
characters.
7.4.3 Device Manager Object Configuration Properties
— The DM object has two configuration properties to
control exception reporting as shown in Table 6. These
parameters are of Standard Configuration Parameter
Types (SCPTs).
SEMI E54.6-0997 © SEMI 1997, 2004 10
The type SCPT_rept_mode(*) contains two four-bit
fields specifying the reporting method for alarms and
warning conditions. For example, in Neuron C, the
application programming language used on the Neuron
Chip, the declaration of SCPT_rept_mode is as follows:
typedef enum {
REP_REQUEST = 0,
REP_REQ_LATCHED = 1,
REP_EVT_TRIGD_ON = 2,
REP_EVT_TRIGD_ONOFF = 3,
REP_TIME_TRIGD = 4,
REP_EVT_ON_TIME_TRIGD = 5,
REP_EVT_ONOFF_TIME_TRIGD = 6,
} rept_mode_t;
typedef struct {
rept_mode_t alarm_rept_mode :4;
rept_mode_t warn_rept_mode :4;
} SCPT_rept_mode;
The type SCPT_exc_sts_t(*) is a 16-bit value
representing times from 0.00 to 655.35 seconds, with a
resolution of 0.01 seconds. This parameter is optional.
The default reporting mode is REP_REQUEST.
7.4.4 Device Manager Object Output Network
Variables — The Device Manager object has four
output network variables as shown in Table 6. The data
type SNVT_dev_status is an enumeration,
corresponding to the device status attribute defined in
Table 6 of the CDM. The values of this type are defined
in Table 8.
Table 8 Device Status Enumeration Values
Value Enumeration Tag
0 DS_UNKNOWN
1 DS_INIT_SELFTEST
2 DS_IDLE
3 DS_SELFTEST_EXCPT
4 DS_EXECUTING
5 DS_ABORT_1
6 DS_ABORT_2
The value DS_ABORT_1 corresponds to the Abort
from Idle or Executing state, and the value
DS_ABORT_2 corresponds to the Abort from
Initialized/Self Testing or Self Test Exception state of
the DM object.
The type SNVT_exc_status(*) is a union of two
structures, depending on whether expanded or basic
exception reporting mode is used. For example, in
Neuron C, the declaration of SNVT_exc_status is as
follows:
typedef union {
struct {
int excpt_method : 1; //set to 0
int dev_spec : 7;
} basic_method;
struct {
int excpt_method : 1; //set to 1
int warn_mfr_spec : 1;
int warn_dev_spec : 1;
int warn_dev_comn : 1;
int resvd : 1;
int alrm_mfr_spec : 1;
int alrm_dev_spec : 1;
int alrm_dev_comn : 1;
} expanded_method;
} SNVT_exc_status;
SEMI E54.6-0997 © SEMI 1997, 2004 11
The type SNVT_exc_detail(*) is a sequence of three
structures containing arrays. The LonWorks Network
Communication Standard limits the size of each of
these arrays to 9 bytes, so that the type fits within the
network variable size limit of 31 bytes. For example, in
Neuron C, the declaration of SNVT_exc_detail is as
follows:
typedef struct {
u_char comn_exc_size;
int resvd1 : 1;
int real_time : 1;
int communic : 1;
int RAM : 1;
int EEPROM : 1;
int EPROM : 1;
int microproc : 1;
int diagnostic : 1;
/*--------------------------*/
int resvd2 : 1;
int reset : 1;
int notify_mfr : 1;
int maintenance : 1;
int power_inputV : 1;
int power_outptV : 1;
int power_resvd : 1;
int power_overC : 1;
u_char comn_exc_dtl[7];
/*--------------------------*/
u_char dev_exc_size;
u_char dev_exc_dtl[9];
/*--------------------------*/
u_char mfr_exc_size;
u_char mfr_exc_dtl[9];
} SNVT_exc_detail;
7.5 Sensor, Actuator, and Controller Objects — These
objects are necessarily specific to the Specific Device
Models. The LonMark Application Layer
Interoperability Guidelines provide a framework for
defining LonMark objects, together with specifications
of generic sensor and actuator objects. Specific Device
Models may employ these objects, and/or may define
their own objects and Standard Network Variable
Types for device-specific requirements. As long as the
LonMark object definition guidelines are followed,
these device-specific objects may be proposed to the
LonMark Interoperability Association for incorporation
within the LonMark guidelines.
8 Protocol Compliance
A method of testing protocol compliance is required to
verify implementation conformance to the standard. By
virtue of the fact that the intermediate layers of the
LonTalk protocol are implemented in commercially
available silicon, compliance verification is needed
only at the physical and application layers. The
LonMark Interoperability Association provides a
compliance verification service to its members. When
the SEMI Sensor/Actuator Network standard is
incorporated into the LonMark guidelines, this service
may be used to verify compliance with the SEMI
guidelines.
8.1 Interoperability Guidelines Checklist
Applicant Name
Product Name
Standard Program ID
Manufacturer ID
Device Class
Device Subclass
Model Number
Comm. Transceiver
Standard Xcvr Type
Network Connector
Neuron Chip Clock Rate
Oscillator Accuracy
Network Buffer Size
Receive Transactions
SAC Object
Mandatory NVs
Optional NVs
Configuration Properties
Device Manager Object
Mandatory NVs
Optional NVs
Configuration Properties
Functional Profiles
Mandatory NVs
Optional NVs
Configuration Properties