Semi E170.1

SEMI E170.1 specifies the SECS-II protocol binding for SFORMS — the actual message set that carries E170's authenticated, role-checked recipe operations between equipment and host, following the same split this glossary has already seen between a GEM-based concept standard and its SECS-II transport companion, like E39/E39.1 for object services or E167/E167.1 for energy-saving communications. E170 defines what authorization and audit-logging a recipe operation requires conceptually; E170.1 defines the specific SECS-II stream/function messages that actually carry an authenticated identity, a permission check, and a signed audit record over the wire between host and equipment.

E170 (SFORMS) defines role-based access control and audit requirements for recipe operations
The conceptual model: who's authorized, what gets logged
What E170 alone doesn't specifyAn access-control model isn't a wire protocol
No defined SECS-II stream/function messages
Without this, every vendor encodes identity and audit data its own way
SEMI E170.1 — SECS-II protocol for SFORMSThe specific messages a host actually sends and receives
Authenticated recipe-operation request messages carrying identity and role
Collection-event messages reporting the signed audit record of what happened
Any SECS-II-capable host can request and audit SFORMS-governed recipe operations on any compliant tool
No vendor-specific message translation layer required

A few things are worth knowing about why SFORMS needed this protocol-level companion standard in addition to E170 itself:

Every GEM-based concept standard in this glossary's SECS/GEM family eventually needs a wire-format companion, because SECS-II is the actual transport layer underneath all of them, and "SECS-II support" is never automatic just because a concept standard exists. E39 defined object services conceptually; E39.1 defined the SECS-II messages that carry object-service data. E167 defined energy-saving states conceptually; E167.1 defined its SECS-II messages. E170 follows the identical pattern: a host and a piece of equipment both understanding "this upload requires process-engineer-level authorization and must be logged with a signed timestamp" conceptually still can't exchange that fact without an agreed message format, and E170.1 is that message format for exactly this access-control and audit model.

From Access-Control Concept to Wire Message E170.1 is the SECS-II binding that carries SFORMS's identity and audit data SEMI E170 (SFORMS) concept Role-based access control, authenticated identity requirement, signed audit-record requirement No wire format defined yet Vendor A encodes identity one way, Vendor B encodes it another — host needs per-vendor translation gap E170.1 — SECS-II protocol for SFORMS Stream/function messages carrying authenticated recipe-operation requests, role-check results, and collection-event audit records in a single vendor-neutral wire format Any SECS-II host can command and audit SFORMS operations on any compliant tool

The specific messages E170.1 defines matter because SFORMS's whole value proposition — an authenticated, auditable recipe operation — collapses back into an unverifiable claim if the identity and audit data travels over an ad hoc, vendor-specific channel instead of a standardized one. E170 can require that every recipe upload carry a role check and a signed log entry, but if each vendor's equipment reports that role and that signature in its own proprietary message format, a host managing mixed equipment has no uniform way to verify compliance across its fleet — it would need a per-vendor translation layer just to confirm SFORMS is actually being enforced, which defeats the purpose of a security standard in the first place. E170.1's stream/function definitions give every compliant tool the same wire-level vocabulary for identity, authorization result, and audit-record delivery.

E170.1 sits alongside E39.1 and E40.1 (SECS-II protocol for object services and processing management) and E167.1 (SECS-II protocol for energy-saving communications) as part of a now-familiar pattern this glossary has tracked across the GEM standard family — a concept standard defines a model, and a numbered .1 companion defines the SECS-II messages that make that model actually interoperable. Where E170 is the access-control and audit policy, E170.1 is narrower and purely mechanical: it's the agreed message format that lets any SECS-II-capable host participate in that policy without vendor-specific integration work.

Read E170.1 as the standard that closes the gap E170 alone leaves open: an access-control and audit model is only as interoperable as the wire format carrying it, and E170.1 is what actually gives SFORMS's authenticated recipe-operation requests and signed audit records a vendor-neutral SECS-II message format to travel in.

Take SEMI E170.1 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