semi合集-English.pdf - 第7883页

SEMI T13.2-1104 © SEMI 2004 3 Service Message Name Supporting Class Service Message Element Name Base Remarks logException DieTraceManag er LogException planDTD DieTracer PlanDTD registerTracer DieTraceMa chine RegisterT…

100%1 / 7923
SEMI T13.2-1104 © SEMI 2004 2
one of mapping means. Also this extension standard
document follows IPC-2541 “Generic Requirements for
Electronics Manufacturing Shop-Floor Equipment
Communication Messages” and IPC-2551 “Sectional
Requirements for Manufacturing Execution System”
for that reason. The following subsections describe a
part of these specifications for introduction. Refer to
these documents for detail reference.
6.2 SOAP Structure — A HTTP message in this
specification has an envelope to contain a couple of
MIME blocks. One is for SOAP Envelope and the other
is for message detail to be able to mix with such non-
XML information as binary data. The service message
specified in SEMI T12 is contained in latter one. SOAP
standard envelope MIME Block contains SOAP Header
which has message information and SOAP Body which
contains SOAP Faults. Outlined diagram is shown in
Related Information. Official definitions are given in
referenced documents.
6.3 Messaging Mechanism — Message Broker, that is
logical middle ware server to handle and relay
messages, is assumed somewhere on communication
network. While the broker behaves as communication
server, the other logical nodes are message clients.
Every message starts with a client and responded by the
server. Messages communicated between clients are
exchanged through the server. The server keeps posted
messages from clients in a queue for each individual
client. Expecting recipient client asks the server for
messages and a topmost message in the queue for the
client is responded if the queue is not empty. The
recipient client posts acknowledge back to the server.
When the recipient replies back a message to the
original sender client, same thing happens with
switched roles between sender and recipient clients.
Explanatory diagrams for this outline are shown in
Related Information. Official specification is given in
referenced documents.
6.4 Issues Specific to this Messaging — A few issues
for IPC based communication protocol for Jigs and
Implements Tracking are introduced here.
6.4.1 Domain Configuration — Message Broker has
domain configuration information to make sure all
acting entities, possible messages with related
publisher, recipient and subscriber clients. Also it has
other detail characteristics of the domain of
communication. Every client needs to look up the
information before the first messaging.
6.4.2 Message Information — This is an element
contained in SOAP Header. This information provides
time of transaction, sender, destination, message
identification and schema type used for service message
detail in the second MIME block.
6.4.3 Attributes in Service Message Element — The
top element of each service message has date/time of
the message, session ID or session reference, request ID
or request reference, and optional values. Some of the
optional values are extended for Jigs and Implements
Tracking communication: linkId, linkCnt and linkExp.
The extension may be used for delayed reply message
and multiple divided replies to keep conformance of
related messages.
7 Requirements
7.1 Service Mapping — Services defined in SEMI T12
are mapped on the following table.
7.1.1 Capitalized Service Message Element Name Base
— Each service message is mapped into an XML
element with capitalized heading letter to prevent
collision with XML or XML Schema native words.
7.1.2 Service Message Element Name Suffix —
Because of symmetry of message broker
communication and for XML element naming
convention, suffix of ‘Request’ or ‘Response’ is added
to each service message element name for request or
response respectively: e.g. AddEventRequest to request
service and AddEventResponse for its response
message.
Table 1 Service Instruction Mapping
Service Message Name Supporting Class Service Message Element
Name Base
Remarks
acquireDTD DieTraceMachine AcquireDTD
admit DieTraceManager Admit
catchDTD DieTracer CatchDTD
collectDTD DieTracer CollectDTD
devolve DieTraceManager Devolve
enroll DieTracer Enroll
flush DieTraceMachine Flush
SEMI T13.2-1104 © SEMI 2004 3
Service Message Name Supporting Class Service Message Element
Name Base
Remarks
logException DieTraceManager LogException
planDTD DieTracer PlanDTD
registerTracer DieTraceMachine RegisterTracer
resign DieTraceManager Resign
setAlert DieTraceClient SetAlert
setForward DieTracer SetForward
setPlanningItems DieTraceMachine SetPlanningItems
showData DieTraceData ShowData
showDaughter CircuitModule ShowDaughter
showDTD DieTracer ShowDTD
showPhenomena DieTraceClient ShowPhenomena
showProperty CircuitModule, DieTraceData ShowProperty
takeDTD DieTracer TakeDTD
7.2 Service Parameter Mapping — Service parameter type mapping is shown in the following table.
Table 2 Service Parameter Type Mapping
Parameter Name Attribute/Element Type Remarks
Alert Element anyType Formatted Text
Clarifier Element string
DataName Element string
DataNameList Element string Repeating DataName
DataValue Element anyType Formatted Text
Designation Element string
Exceptions Element anyType Formatted Text
MachineType Element string
ManagingTracer Element string
Phenomena Element anyType Formatted Text
Property Element anyType Formatted Text
ServiceStatus Element complexType status+Rejection
Target Element string
TraceData Element anyType Formatted Text
Tracer Element string
Tracers Element string Repeating Tracer
7.3 Additional Parameters for Service Messages — Because this protocol mapping works for asynchronous HTTP
server-client communication on message broker, such additional parameters to give complementary information as
issued time and transaction identification are required to be attached to each message. The information may be
dependent to the role of the message. Type mapping of them are shown in the following table.
Table 3 Type Mapping of Additional Parameters
Parameter Name Attribute/Element Type Remarks
dateTime Attribute dateTime
sessionId Attribute string
sessionRef Attribute string
requestId Attribute string
requestRef Attribute string
linkId Attribute string extended for delayed response
SEMI T13.2-1104 © SEMI 2004 4
Parameter Name Attribute/Element Type Remarks
linkCnt Attribute integer extended for delayed response
linkExp Attribute duration extended for delayed response
7.4 Example XML Message Fragments — The following subsections give examples of some fragments of service
messages in XML. A full message is given with envelops and headers.
7.4.1 showProperty Request — The following XML description is an example of the principal part of service
request message for showProperty provided by CircuitModule objects. Because the Designation of parameters for a
CircuitModule is dependent to the circuit module and tracing objectives, they should be discussed between trace
data provider and consumer.
<ShowPropertyRequest dateTime=”2004-03-29T13:05:25.000-08:00”
SessionRef=”SemiDtQs-9876543210” RequestId=”123456”>
<Designation>Id</Designation>
<Designation>Type</Designation>
<Designation>ProductName</Designation>
<Designation>Lot</Designation>
</History>
</ShowPropertyRequest>
7.4.2 showPhenomena Response — The following XML description is an example of the principal part of service
response message for showPhenomena provided by DieTraceClient objects. Detail information of argument
“Phenomena” is not specified in the standard because it’s dependent to target product. Additional definition should
be exchanged in the system.
<ShowPhenomenaResponse dateTime=”2004-03-29T09:07:59.000-08:00”
SessionRef=”SemiDtQs-9876543123” RequestRef=”123443” status=”GRANTED”>
<Phenomena>
<Registered>2004-03-26T18:07:51.000-08:00<Registered>
<Product>meson689-4A</Product>
<Problem>Noise sensitive</Problem>
<Problem>Restarted Occasionally</Problem>
<Application>Office Computers</Application>
</Phenomena>
<ServiceStatus>
<SvcAck>Successful</SvcAck>
</ServiceStatus>
</ShowPhenomenaResponse>