S95×S88×UNS 智能制造架构设计：以可交付机制为核心

Implication: the architecture should treat 'data' not as logs for later analytics, but as evidence for runtime governance—the system must be able to answer why an action was taken, under which constraints, and what proof supports it.

3) Principle B: separate 'business intent' (S95) from 'procedural execution' (S88), then connect them via contracts

A common failure mode is mixing ERP/MES intent directly into PLC logic, producing brittle coupling. Instead:

• S95 layer defines what must be accomplished:
  • Work definitions (product/segment definitions, BOM/BOP, routing)
  • Work schedules/dispatch lists
  • Performance, quality, inventory, maintenance, energy objectives
• S88 layer defines how execution occurs:
  • Recipes (master/control/site recipe)
  • Equipment capabilities and procedural control
  • Batch/lot records with parameter traces

The bridge is not point-to-point integration—it's a set of explicit contracts:

• SegmentRequirement / ProcessSegment (S95/IEC 62264) maps to UnitProcedure/Operation/Phase (S88)
• MaterialDefinition / EquipmentSpecification maps to Equipment Module / Control Module capabilities
• WorkRequest / WorkDirective maps to Recipe instantiation + parameterization
• Performance/Quality records map to Batch record + conformance evidence

This is mechanismism: the bridge is a designed coupling, not an accidental dependency.

4) Principle C: treat UNS as the canonical 'observable reality,' not just a messaging bus

A UNS is often misunderstood as 'MQTT topics with some names.' Under embodied mechanismism, UNS is the shared operational reality that enables distributed loops to stay coherent.

A robust UNS design must provide:

1. Canonical semantics
   • Standardized event types and state models (equipment state, job state, material state, quality state)
   • Stable identifiers (asset IDs, lot IDs, order IDs, recipe instance IDs)
2. Evidence-preserving eventing
   • Every critical action should emit events with: who/what/when/why + references to constraints and approvals
   • Events should be immutable; corrections are new events (auditability)
3. State projection
   • Runtime components need queryable 'current truth' (digital shadow) derived from events
   • Separate event streams from state stores (so late-joining services can reconstruct context)
4. Time and causality handling
   • Manufacturing is distributed; design for out-of-order events, clock drift, retries
   • Use correlation IDs, causation IDs, and deterministic reconciliation rules

In short: UNS is the mechanism that makes the system's 'world model' shareable and governable.

5) Principle D: introduce an L2.5 'edge orchestration layer' as the embodiment boundary

S95 is enterprise/operations; S88 is procedural control; PLCs are physical actuation. The missing piece is often L2.5: an edge layer that embodies operational intelligence close to machines while remaining governable.

L2.5 responsibilities:

• Translation & Anti-Corruption Layer (ACL)
  • Normalize PLC/vendor protocols into canonical UNS semantics
  • Prevent business systems from leaking into control logic (and vice versa)
• Deterministic orchestration
  • Coordinate multi-PLC sequences and interlocks at 'cell/line' level
  • Provide bounded-latency execution coordination
• Safety and constraint enforcement
  • Hard constraints: interlocks, safety states, critical alarms
  • Soft constraints: energy caps, schedule priorities, material availability
• Local resilience
  • Operate under degraded connectivity (store-and-forward, local decision fallback)

This is where 'embodied' matters: intelligence must survive contact with physics—latency, faults, partial observability, and safety boundaries.

6) Principle E: make constraints first-class objects (not comments in code or tribal knowledge)

A mechanismist architecture elevates constraints to explicit, machine-checkable entities:

• Process constraints: temperature/pressure windows, mixing ratios, cure profiles, phase duration bounds
• Quality constraints: spec limits, sampling rules, traceability requirements
• Resource constraints: equipment availability, tooling, labor, WIP limits
• Energy constraints: peak shaving, tariff windows, demand response commitments
• Compliance constraints: audit trails, electronic records/signatures, segregation of duty

Architecturally, constraints should be:

• declared (in models),
• referenced (by decisions and actions),
• checked (by automated guards), and
• proven (by evidence in event logs).

This transforms 'smart manufacturing' from optimization theater into enforceable operations.

7) Principle F: design the system as composable bounded contexts, not a monolithic MES

Use domain boundaries aligned with mechanisms:

• S95 contexts: Order Management, Scheduling/Dispatch, Inventory/Genealogy, Quality, Maintenance, Energy
• S88 contexts: Recipe Management, Procedural Execution, Equipment Capability, Batch Record
• UNS platform contexts: Schema Registry, Event Governance, Identity/Authorization, Observability

Each bounded context:

• owns its models,
• publishes canonical events to UNS,
• subscribes only to what it needs,
• and integrates through contracts rather than shared databases.

This yields evolvability: you can upgrade scheduling, add AI optimization, or change equipment without rewriting everything.

8) Principle G: AI is an advisor inside the loop, but governance sits above the loop

In an embodied mechanismism architecture, AI should not be a magical controller. It should be a bounded mechanism:

• AI proposes: parameter adjustments, dispatch priorities, anomaly explanations
• Deterministic guards validate: safety envelopes, policy rules, change limits
• Human-in-the-loop approves when needed: recipe changes, out-of-spec rework decisions
• The system records: recommendation → approval → action → outcome (for learning and accountability)

A practical rule:

AI may optimize within declared constraints; it must never redefine constraints without governance.

9) Principle H: define operational SLIs/SLAs as architecture-level invariants

'Working' is measurable. Examples of mechanism-level SLIs:

• Control/Orchestration: phase-start latency, command success rate, interlock breach rate
• Data/Evidence: event completeness, schema compliance rate, lineage continuity, time sync error bounds
• Scheduling/Dispatch: plan adherence, queue time percentiles, changeover performance
• Quality: first-pass yield, deviation closure time, batch record completeness
• Resilience: edge offline tolerance, recovery time, replay correctness
• Safety/Compliance: audit trail integrity, approval policy adherence

These are not dashboards; they are architectural acceptance criteria.

10) A reference mental model: 'S95 decides what and why, S88 ensures how, UNS ensures shared truth'

Put together:

• S95 provides the operational intent and accountability surface (orders, objectives, performance).
• S88 provides the executable procedural semantics and traceability (recipes, phases, batch records).
• UNS provides the shared observable world and the evidence chain (events, state projections, governance).

Under embodied mechanismism, the architecture is correct when it can consistently answer:

1. What are we doing right now? (state)
2. Why are we doing it? (intent + constraints)
3. How exactly are we doing it? (procedure + parameters)
4. What proves we did it correctly? (evidence chain)
5. How do we improve without breaking safety/compliance? (governed learning)

That is the essence of an S95 × S88 × UNS smart manufacturing architecture designed as a deliverable mechanism.