Step 11 - Vision NATS user rules

Goal

Deploy three NatsUserRule resources for Phase 2 fab inspection. User rules must exist before you deploy the vision-inspection Application in step 13.

Scenario context

Phase 2 adds wafer map thumbnails, ONNX defect inference, and an inspection gallery. All three microservices share one NATS account (vision-inspection-local, step 12) but run on different Edgelet nodes:

• frame-generator on site-a publishes wafer metadata on vision.wafers.fab-01
• object-detector on edge-c subscribes to wafer frames and publishes results on vision.inspections.fab-01
• snapshot-service on ops-b subscribes to inspections and serves an HTTP gallery

This step creates user rules only. No microservices run yet.

Unlike Phase 1 step 1, there is no ops-viewer import path. Vision traffic stays in one account across three nodes.

YAML walkthrough

The manifest deploy/steps/11-nats-user-rules-vision.yaml in pot-edge-patterns defines three rules.

frame-publisher

The frame generator publishes one JSON message per wafer on subjects like vision.wafers.fab-01. The rule allows publish on the wildcard vision.wafers.>.

frame-publisher

---
apiVersion: datasance.com/v3
kind: NatsUserRule
metadata:
name: frame-publisher
spec:
description: frame-generator - publish wafer map metadata (in-account)
pubAllow:
  - vision.wafers.>

vision-detector

The object detector subscribes to all wafer frames, runs wafer-defect ONNX inference, and publishes inspection JSON with defect class and confidence.

vision-detector

---
apiVersion: datasance.com/v3
kind: NatsUserRule
metadata:
name: vision-detector
spec:
description: object-detector - subscribe wafer frames, publish inspections (in-account)
pubAllow:
  - vision.inspections.>
subAllow:
  - vision.wafers.>

snapshot-consumer

The snapshot service subscribes to inspection results. It does not publish vision data on NATS. HTTP responses come from the microservice port map instead.

snapshot-consumer

---
apiVersion: datasance.com/v3
kind: NatsUserRule
metadata:
name: snapshot-consumer
spec:
description: snapshot-service - subscribe inspections for HTTP snapshot API (in-account)
subAllow:
  - vision.inspections.>

Why this design

Subject pattern	Who uses it	Purpose
vision.wafers.{lineId}	frame-generator → object-detector	Wafer thumbnail metadata (v1.1.0)
vision.inspections.{lineId}	object-detector → snapshot-service	Defect class, confidence, bounding boxes

PoT mounts NATS credentials from these rules when a microservice sets natsConfig.natsRule. Tight pub/sub lists prevent the gallery user from publishing fake wafer frames back into the inspection pipeline.

Cross-account vs in-account: Phase 1 used export/import between production-monitoring and operations-center (steps 2 and 5). Phase 2 keeps all vision subjects inside vision-inspection-local. Router bridges HTTP to ops-b for the gallery, but NATS never crosses Applications.

Do not use v1.0.0 subject names (vision.frames.*, vision.detections.*). This tutorial uses v1.1.0 vision.wafers.> and vision.inspections.>.

Deploy

From the pot-edge-patterns repo root:

potctl deploy -f deploy/steps/11-nats-user-rules-vision.yaml

Verify

potctl get nats-user-rules

You should see frame-publisher, vision-detector, and snapshot-consumer.

Common mistakes

• Deploying the Application first. Step 13 references these rule names. Deploy user rules before any Application.
• Mixing v1.0.0 subject names. Use vision.wafers.> and vision.inspections.>, not deprecated vision.frames.* / vision.detections.*.
• Expecting cross-account import. Vision does not use export/import like Phase 1. Step 12 is an in-account account rule only.

Next step

Step 12: Vision NATS account rule: deploy the in-account NatsAccountRule that binds the vision-inspection Application.

See anything wrong with the document? Help us improve it!

Edit this page on GitHub!