02. Domain and State Model

Back to Requirements Hub

This page covers original Section 6.

6. Domain Context

The system simulates an industrial inspection machine composed of several subsystems.

6.1 Motion Stage

The motion stage moves to X/Y positions and supports:

• connect/ready status
• homing
• commanded moves
• stopping motion
• reporting current position
• reporting moving, homed, idle, and faulted states

6.2 Camera

The camera supports:

• connection state
• start and stop streaming
• frame generation
• configurable frame rate or settings later
• simulated frame delivery into the application

6.3 Light Controller

The light subsystem supports:

• light on/off
• intensity adjustment
• current status reporting

6.4 Machine Signals / PLC-like Signals

The system exposes simulated machine signals such as:

• door closed/open
• vacuum ready/not ready
• emergency stop active/inactive
• temperature
• air pressure
• readiness conditions

6.5 Inspection Engine

The inspection component simulates:

• receiving frames
• processing frames
• detecting fake defects
• producing simple inspection results

6.6 Alarm and Fault Model

The system must support:

• warnings
• critical alarms
• faulted machine state
• operator acknowledgement where appropriate
• behavior changes when a critical fault is active

For the first slice:

• Warning alarms may block start or readiness, but do not by themselves force the workflow into Faulted
• Critical alarms must force the workflow into Faulted
• acknowledgement records operator awareness; it does not by itself clear the underlying unsafe condition

6.7 Core Runtime Objects

For the first slice, the shared runtime contracts must be kept small and explicit.

At minimum, the system must define:

• Recipe: RecipeId, Name, ordered ScanPoints
• ScanPoint: Index, X, Y
• Frame: FrameId, Sequence, CapturedAtUtc, capture position, preview payload or placeholder payload
• InspectionResult: source FrameId, HasDefect, optional simple defect summary
• Alarm: AlarmCode, Severity, Message, RequiresAcknowledgement, IsActive, IsAcknowledged
• RunSummary: RunId, RecipeName, StartedAtUtc, EndedAtUtc, terminal status, defect count, major alarms or failures

These contracts should be stable enough that later specs and tasks can reference them without re-inventing alternate shapes.

6.8 Canonical App State Model

The system must have one canonical central AppState model that acts as the source of truth for UI projection, command guards, and diagnostics.

For the first slice:

• simulator services and background workers must not update ViewModels directly
• the application layer owns state transitions and updates the central app state
• the UI may show friendly aggregate labels such as "Machine Ready", but those labels must be derived from the canonical app state rather than stored independently

The minimum state partitions are:

• ConnectionState: Disconnected, Connecting, Connected
• WorkflowState: Idle, Preparing, Homing, Ready, Running, Stopping, Stopped, Completed, Aborted, Faulted
• MotionState: NotReady, Homing, Idle, Moving, Stopped, Faulted
• CameraState: Disconnected, Connected, Streaming, Faulted
• safety and signal state: door, vacuum, emergency stop, air pressure, temperature, other readiness inputs
• current recipe state
• active run state and most recent run summary
• active alarms and recent diagnostics entries

Derived command availability must come from this model.

Examples:

• CanHome requires ConnectionState = Connected and no active critical fault
• CanStart requires ConnectionState = Connected, recipe loaded, stage homed, safety conditions satisfied, no active critical fault, and workflow state Idle or Ready
• user-facing "Machine Ready" is a derived projection, not a separate mutable state