semi合集-English.pdf - 第2164页

SEMI E54.16-0705 © SEMI 2005 9 Table 3 Common Dev i ce Model Required a nd Optional Objec t Types SEMI Object Name L ON M ARK SEMI Class ID/Instance ID #1 CDM Tag #2 L ON M ARK Functional Profile Name Required By L ON M …

100%1 / 7923
SEMI E54.16-0705 © SEMI 2005 8
6.8.2 Functional Block Structure — The LONMARK Application Layer Interoperability Guidelines define a structure
for functional profiles. Each functional profile may have a set of mandatory network variables, a set of optional
network variables, a set of configuration properties (both mandatory and optional), and a manufacturer-defined
section, which may be used for non-interoperable extensions to the profile. This is illustrated in Figure 2. This
notation is defined in the LONMARK Application Layer Interoperability Guidelines.
NOTE: Diagram notation, the arrow-like symbol used in Figure 2 is defined in the LonMark Application Layer Interoperability
Guidelines.
Figure 2
LonMark Object Structure
6.8.3 The LONMARK Application Layer Interoperability Guidelines provide for the definition of Standard Network
Variable Types, Standard Configuration Property Types, and Functional Profiles. In the mapping of the SEMI CDM
to the LONMARK object structure in §7, extensions to the current SNVT list and LONMARK Interoperability
Guidelines are marked with an asterisk (*). Functional profile numbers are specified by the guidelines; a device may
consist of one instance of a Node Object type, and one or more instances of other functional profiles.
6.9 Network Management — The ANSI/EIA/CEA-709.1 (LONWORKS) protocol defines a complete network
management and diagnostic protocol for LONWORKS devices. This protocol is a layer above the Session layer
(request/response service) and provides mechanisms for application downloading, device address assignment,
distribution of destination addresses for implicit messaging, router configuration, and device-level diagnostics. The
LONMARK Application Layer Interoperability Guidelines define a device management layer for functional blocks.
7 Required and Optional Object Types
7.1 The LONMARK guidelines do not require any specific objects to exist in a device in order to be a compliant
LONMARK device, except that a Node object functional block is required for devices that contain multiple functional
blocks (SEMI compliant devices will typically have a Node object functional block). New LONMARK standard
profiles are defined in this standard to identify and describe functional blocks that shall exist in devices that are to be
interoperable and interchangeable on a LONMARK SEMI compliant SAN network.
7.1.1 LONMARK International Association publishes functional profiles for various sensor, actuator, and controller
objects. A specific device may be implemented using functional blocks based on these profiles. The Common
Device Model specification additionally identifies two functional blocks (namely the Device Manager (DM) and
Sensor Actuator Controller (SAC) objects) that must exist in all SEMI compliant SAN devices. The required
functional profiles for a SEMI compliant SAN device utilizing the network communication specification described
herein necessarily comprise, at minimum, the union of the LONMARK functional profile requirements and the CDM
specification requirements.
7.1.2 A list of required and optional object types is given in Table 3. Additional objects that are specified in a
particular SDM are given identifiers in that SDM specification. The LONMARK specific presentation information for
these identifiers is given in §9 of this document.
SEMI E54.16-0705 © SEMI 2005 9
Table 3 Common Device Model Required and Optional Object Types
SEMI Object
Name
LONMARK SEMI Class
ID/Instance ID
#1
CDM Tag
#2
LONMARK Functional
Profile Name
Required By
LONMARK
#1
R
equired By
CDM
#2
Required
By NCS
(DM)
Device Manager
#4
0 / 1 DmIO Node Object Yes Yes Yes
(SAC)
Sensor/Actuator/C
ontroller
#4
0 / 1 SacIO Node Object Yes Yes Yes
Assembly 180.81 / 1 through i Asm Manufacturer-specific
Members
No No No
Local Link Turnaround
Connection
#3
Lnk Turnaround Connection
#3
No No No
Sensor-AI 180.11 / 1 through k Sai SFPTsemiSensorAI No No No
Sensor-EI 180.22 / 1 through l Sei SFPTsemiSensorEI No No No
Sensor-BI 180.18 / 1 through m Sbi SFPTsemiSensorBI No No No
Actuator-AO 180.31 / 1 through n Aao SFPTsemiActuatorAO No No No
Actuator-EO 180.34 / 1 through o Aeo SFPTsemiActuatorEO No No No
Actuator-BO 180.33 / 1 through p Abo SFPTsemiActuatorBO No No No
Controller 180.51 / 1 through q C SFPTsemiController No No No
Sensor-BI-TH 180.19 / 1 through s Sbith SFPTsemiSensorBITH No No No
#1
LonMark groups SEMI Class IDs as reference 180 and designates specific object name categories as .XX. See LONMARK Application Layer
Interoperability Guideline and http://types.lonmark.org.
#2
See E54.1 – CDM specification for further information
#3
A turnaround connection is not a profile, but is a protocol-specific method for creating a link
#4
The LonMark Application Layer maps the SEMI Device Manger (DM) and Sensor/Actuator/Controller (SAC) objects to the LonMark Node
object.
7.1.3 Service Requests Code — Most service requests are implemented as network variable updates addressed to the
network variable corresponding to the specified attribute. The exceptions to this mapping are requests that require
more than a 31 byte response. In that case, the request is implemented as a network variable update containing a file
request to an nviSemiReq input to the Node Object functional block of a device. This input is defined by the
SNVT_semi_req type as follows:
typedef enum {
struct {
CMD_RESET = 1,
CMD_ABORT = 2,
CMD_RECOVER = 3,
CMD_GET_ATTRIBUTE = 4,
CMD_SET_ATTRIBUTE = 5,
CMD_OERATE = 6,
CMD_RESTOTE_DEFAULT = 7,
CMD_PUBLISH_ATTRIBUTE = 8,
CMD_LOCK = 9,
SEMI E54.16-0705 © SEMI 2005 10
CMD_UNLOCK = 10,
CMD_GET_EXCEPTION_QUEUE = 11,
CMD_CLEAR_EXCEPTION_QUEUE = 12,
CMD_EXECUTE = 13,
CMD_PERFORM_DIAGNOSTICS = 14,
} semi_request_t;
typedef struct {
unsigned int flblock_index;
semi_request_t service_code;
unsigned int parameter; // Optional parameter
} SNVT_semi_req;
7.1.4 A device accepts a SNVT_semi_req request by updating the nvoSemiStat and nvoFileStat outputs of the
Node Object function block. The nvoSemiStat output is defined by the SNVT_semi_status type as follows:
typedef enum {
struct {
STAT_SUCCESS = 0,
STAT_UNSUPPORTED_SERVICE = 1,
STAT_UNSUPPORTED_ATTRIBUTE = 2,
STAT_SET_ATTRIBUTE_ERROR = 3,
STAT_GET_ATTRIBUTE_ERROR = 4,
STST_CALIBRATION_ERROR = 5,
STAT_SERVICE_REQUEST_ERROR = 6,
STAT_DIAGNOSTIC_ERROR = 7,
} semi_status_t;
typedef struct {
semi_status_t status;
unsigned long selected_file;
struct address { // Address of the requesting device
unsigned short domain_id[6];
unsigned short domain_length;
unsigned short subnet;
unsigned short node;
}
} SNVT_semi_status;
7.1.5 If the nvoSemiStat and nvoFileStat outputs indicate the request was accepted, the requesting device then
fetches the requested data by transferring the file with the file index reported by the nvoSemiStat response.
7.1.6 Object Attributes — The SEMI GetAttribute and SEMI SetAttribute service requests are implemented as
network variable fetch, poll, and update requests addressed to the network variable corresponding to the specified
attribute. This is appropriate when responses greater than 31 bytes are not required. A GetAttribute service request
may be addressed directly to any network variable as a LonTalk request message, using the LonTalk protocol
network management NV fetch mechanism. A GetAttribute service request may also be addressed to an output
network variable as a LonTalk NV poll message, using the NV selection mechanism. A SetAttribute service request