FMS (Schriber-Stecke): model notes

Schriber / Stecke FMS

Models a Flexible Manufacturing System (FMS) featuring parallel processing and a synchronization join.

Problem

Raw parts arrive at the system and are immediately split into three sub-parts. Each sub-part is routed to one of three different machine groups (each containing 2 machines). The finished product is only complete once all three sub-parts have finished their respective machining processes. This model highlights the "synchronization penalty"—the time wasted when a finished unit is stalled by the slowest of its components.

This is based on the FMS grooming/loading problem described in the Stecke-FMS papers and implemented as Example 11 in the Schriber-GPSS/H textbook.

Model in this directory

The model leverages a "spawn-and-converge" architecture:

Raw_Part puck (lines 178-198): Acting as a "split" point, this puck spawns three Sub_Part pucks and a shared Assembly object before terminating itself.
Sub_Part puck (lines 85-127): These pucks process in parallel. They seize a machine in their assigned group and, upon completion, proceed to the assembly join.
Assembly struct (lines 73-78): A coordination object shared by the three siblings of a single raw part. It tracks the arrival count and stores references to the siblings.
Machine_Group (lines 54-60): Manages a sim.Storage for machine capacity and a sim.Set for the local queue.

Why this shape

The SPLIT logic is implemented by having the Raw_Part create multiple independent Sub_Part pucks. This is more idiomatic in puck-based simulation than maintaining a parent-child relationship, as the "raw part" entity ceases to be the primary actor once the split occurs.

The ASSEMBLE logic (lines 130-155) uses a "last person out" pattern. The first two sub-parts to reach the assembly point are simply suspended. The third sub-part (the "finisher") is responsible for recording the total system sojourn time and terminating its suspended siblings. This avoids the need for a separate coordinator puck or a polling loop.

Alternatives considered

Coordinate Puck: Instead of the "finisher" terminating siblings, a separate "Assembly Manager" puck could have been used to track the counts. However, the current approach is more efficient as it reduces the number of active processes in the engine.
Helper Library: While this logic could be extracted into a sim.Assemble_Point helper, it is implemented inline here to clearly demonstrate the underlying puck primitives (suspend/terminate) used to create synchronization joins.

What this example teaches

Parallel Workflows: How to spawn multiple pucks to represent a single entity's decomposed components.
Synchronization Joins: Implementing the "ASSEMBLE" pattern where multiple independent processes must converge before the entity can proceed.
Resource Grouping: Managing utilization and queues across a group of identical resources.

Running it

odin run examples/fms_schriber_stecke

CLI

./fms_schriber_stecke [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:

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