03. Functional Scope

Back to Requirements Hub

This page covers original Section 7.

7. Functional Scope

The first meaningful version of the prototype must include the following feature areas.

7.1 Application Foundation

The system must provide:

• .NET 10 WPF desktop application
• generic host setup
• dependency injection
• logging
• application state management
• clear project boundaries

7.2 Machine Connection

The system must allow the operator to:

• connect to the simulated machine
• disconnect from the simulated machine
• observe current connection state

The system must simulate:

• connection delay
• occasional connection failure
• state transitions Disconnected -> Connecting -> Connected
• failed connection attempts that return to Disconnected and surface an alarm or diagnostic entry

7.3 Recipe Loading

The system must support:

• loading a recipe object into the application
• associating a recipe with an inspection run
• showing the currently loaded recipe in the UI

For the first slice:

• recipes must come from in-memory seed data
• at least one seeded recipe must contain at least 3 ordered scan points
• JSON-backed recipe loading is a later slice

7.4 Motion and Homing

The system must support:

• homing the motion stage
• moving to recipe scan points
• blocking movement when not connected
• blocking movement when not homed
• stopping motion safely
• exposing stage position and status

The simulator must model time-based movement instead of instant teleportation.

7.5 Inspection Workflow

The system must support an explicit inspection workflow with at least:

• idle
• preparing / initializing
• homing
• ready
• running
• stopping
• stopped
• completed
• aborted
• faulted

The workflow must:

• validate prerequisites before starting
• move through scan positions
• acquire data at scan points
• update run progress
• stop or abort safely
• respond to faults
• produce one terminal run summary with status Completed, Stopped, Aborted, or Faulted

7.6 Telemetry Streaming

The system must continuously stream machine telemetry such as:

• stage position
• machine state
• temperature
• pressure
• signal values
• current run metrics where available

The application must consume and display telemetry without freezing the UI.

For the first slice:

• simulator telemetry should have a documented default cadence of about 5 Hz
• telemetry buffering must be bounded
• when consumers lag, the system may coalesce stale telemetry and keep the most recent values rather than accumulate an unlimited backlog

7.7 Frame Streaming

The camera simulator must produce frames while streaming is active.

The application must:

• receive frames asynchronously
• buffer them through a pipeline
• show a preview or simplified live image representation
• avoid unbounded growth in memory usage

For the first slice:

• the simulator should produce preview frames at a documented default cadence of about 2 fps
• preview buffering must be bounded
• when consumers lag, the system should prefer recent preview frames over preserving an indefinitely growing backlog

7.8 Fake Defect Detection

During an inspection run, the system must simulate inspection results:

• some frames may contain defects
• defect count must be shown
• simple defect details may be stored in run state
• results must be associated with the current run

The first version does not need real computer vision.

7.9 Alarms and Faults

The system must support fault conditions such as:

• emergency stop
• door open
• connection loss
• motion failure
• camera unavailable
• generic simulator fault

The system must:

• surface alarms in the UI
• block invalid operations
• transition to faulted state where appropriate
• support acknowledgment or recovery for selected cases

For the first slice:

• the system must expose an explicit operator recovery or reset action after the unsafe condition is cleared
• critical fault recovery must require both condition clearance and an explicit operator action

7.10 Stop and Abort

The system must distinguish between:

• stop: graceful shutdown of the current run
• abort: immediate operator-requested interruption of active work
• fault: immediate safety-driven interruption that ends in Faulted

The workflow and UI must reflect this difference clearly.

7.11 Logging and Diagnostics

The system must provide enough runtime visibility to understand:

• commands issued
• state transitions
• faults and warnings
• run start and end
• movement steps
• dropped data or queue pressure later
• recovery attempts later

For the first slice, a minimal diagnostics surface is required, even if it is embedded in the main screen rather than a dedicated page.

7.12 Run Summary

After a run finishes, is stopped, fails, or is aborted, the system should preserve a summary including:

• run id
• recipe name
• start time
• end time
• final status
• defect count
• major alarms or failures
• completion reason where useful to distinguish stop, abort, and fault outcomes

Persistence may initially be in-memory or file-based.