TV Inspection and Adjustment

Simulates a TV production line quality control process with a feedback loop for rework.

Problem

TV sets arrive from a production line and first undergo inspection. The inspection station is staffed by two parallel inspectors. If a TV passes inspection, it leaves the system. If it fails (with a 15% probability), it must be sent to a single adjuster for repair. Once adjusted, the TV is routed back to the inspection station to be verified again. This creates a feedback loop where a single TV may visit the inspection station multiple times.

This is based on the "TV Inspection and Adjustment" problem from Schriber-1974 and reprinted in Schriber-GPSS/H.

Model in this directory

The model utilizes a state-machine approach for the TV puck:

TV puck (lines 46-118): The puck transitions through several states: Arriving \(\rightarrow\) WaitingForInspection \(\rightarrow\) BeingInspected \(\rightarrow\) WaitingForAdjustment \(\rightarrow\) BeingAdjusted \(\rightarrow\) Done.
sim.Storage (line 26): The inspection station is modeled as a multi-server resource, allowing up to two TVs to be inspected simultaneously.
sim.Facility (line 27): The adjustment station is a single-server resource.
Feedback Loop: The transition from BeingAdjusted triggers a call to try_enter_inspection (line 116), sending the puck back to the start of the inspection process.

Why this shape

The use of sim.Storage for inspection is necessary to model the parallel nature of the two inspectors. The la-puck idiom for "rework" is implemented as a simple state transition. By returning the puck to the try_enter_inspection procedure, the model naturally handles the re-entry into the multi-server queue without needing complex routing logic.

The la-puck's state machine (lines 62-118) explicitly separates "Waiting" from "Being Processed" (e.g., WaitingForInspection vs BeingInspected). This allows the model to accurately track and report wait times separately from service times.

Alternatives considered

Single Storage for both: Using different storage levels within one resource would not allow for the specific a-facility vs a-storage behavior required for the single-adjustor vs two-inspector setup.
Routing Puck: A separate dispatcher could have handled the loop, but having the TV puck simply "re-enter" the first stage is more efficient.

What this example teaches

Feedback Loops: How to model a system where an entity can return to a previous stage for rework.
Resource Heterogeneity: Combining multi-server resources (sim.Storage) and single-server resources (sim.Facility) in one workflow.
Puck State Machines: using enums to track a puck's progress through a multi-stage pipeline.

Running it

odin run examples/tv_inspection

CLI

./tv_inspection [options]

Add --json to emit the uniform envelope (metadata, execution_stats, metrics, details) instead of the default text output.

Flag	Type	Default	Description
`--json`	bool	`false`	Emit uniform JSON envelope instead of text.

Example runs:

./tv_inspection           # default text run
./tv_inspection --json    # uniform envelope

TV Inspection — README