Semi E173

SEMI E173 specifies the XML SECS-II Message Notation (SMN), a standardized text-based way to write out a SECS-II message — stream, function, and every item's type and value — in human-readable, machine-parseable XML instead of the binary byte sequence SECS-II actually transmits on the wire. SECS-II itself answers "how does equipment and host exchange this message as bytes"; SMN answers a question the binary wire format was never built to answer: how does an engineer write that same message down, read it in a log, hand-author it in a test script, or embed it in a simulator's configuration file, without decoding a binary dump by hand every time.

SECS-II message travels on the wire as a binary byte sequence
Stream/function header, item headers, packed binary values
What the binary wire format alone doesn't provideBinary is efficient to transmit, unreadable to a human without tooling
No standardized way to write a message in a test script
Each test harness or simulator invents its own text representation
No standardized way to log or document a message for debugging
Engineers manually decode hex dumps to understand what was sent
SEMI E173 — XML SECS-II Message Notation (SMN)A standardized XML text representation of any SECS-II message
Stream, function, and item structure written as readable, parseable XML
The same message, round-trippable to and from its binary form
Test scripts, simulators, and logs all describe messages the same way
No tool-specific or ad hoc text format needed

A few things are worth knowing about why SECS-II needed a standardized text notation on top of its own binary wire format:

SECS-II's binary format was designed for one job — efficient transmission between equipment and host — and does that job well, but nothing about an efficient binary encoding makes it convenient to read, write, or author by hand, which is a completely different requirement that only shows up once engineers need to work with messages outside the wire itself. A test engineer writing a script to simulate a host sending S2F41 to request a remote command doesn't want to hand-assemble the binary byte sequence; a debugging engineer staring at a captured message in a log doesn't want to decode item headers and packed values from a hex dump just to confirm what was sent. Every team that has ever needed to do either of those things has, historically, built its own ad hoc text notation to paper over the gap — which means the same SECS-II message could be written three incompatible ways across three different vendors' tooling.

Same Message, Three Ways to Write It Down SEMI E173 (SMN) gives SECS-II one standard text notation instead of several ad hoc ones Wire bytes: 00 02 00 29 ... (S2F41, binary item list, packed values) Efficient to transmit, unreadable without a decoder Vendor A test harness "S2F41{RCMD=START, PARAMS=[LOT=5]}" Proprietary syntax Vendor B simulator config S:2 F:41 / RCMD=START / LOT=5 Different, incompatible syntax SEMI E173 (SMN) <Message S="2" F="41"> <L><A>START</A>...</L> One standard XML notation Only SMN's XML round-trips losslessly to and from the same binary message every tool in the ecosystem can read

SMN's round-trip guarantee — that an XML document can be converted to the exact binary SECS-II message and back without loss — is what separates it from the ad hoc notations it replaces, because a notation that can't round-trip losslessly is only useful for human reading, not for actually driving equipment or simulators. A text format invented by one vendor's test team might be perfectly readable but have no formally specified mapping back to binary item types and packed values, which means it can document a message but can't reliably reproduce it. SMN defines that mapping precisely enough that any tool implementing the standard — a test harness, a protocol analyzer, a simulator — can convert in either direction and get back exactly the same message, which is what makes it usable as more than documentation.

SMN sits alongside E172's SEDD as a readability and tooling layer built on top of plain SECS-II, though the two solve different problems — SEDD standardizes what a VID number means, while SMN standardizes how an entire message, VIDs and all, gets written down as text. Neither changes anything about what travels on the wire between equipment and host; both exist purely to make SECS-II's binary protocol workable for the humans and tools that have to read, write, test, and debug it around the edges of that wire transmission.

Read E173 as the standard that closes the gap SECS-II's binary wire format was never built to close: equipment and host have always exchanged messages efficiently as bytes, but nothing about that efficiency made those messages easy to write in a test script or read in a debug log, and SMN is what actually gives every tool in the ecosystem one standard, round-trippable text notation instead of a different ad hoc one for each vendor's tooling.

Take SEMI E173 further

Ask the copilot about this term, or have our engineers assess it against your process.

Ask CFSGPT about this → Request a technical assessment → Open the CFS app