Process Studio¶

Designer + simulatore di processi produttivi a griglia (spirito Factorio, disciplina da discrete-event simulation): si disegna una linea (celle, skid, buffer, magazzini, AGV), la si parametrizza, la si simula su settimane di calendario (turni, festivi, straordinari) e la si confronta — tipicamente manuale vs automatizzato — con la possibilità di esportare il modello in formalismi standard per lo studio analitico. Si raggiunge dal viewer del twin col link [Studio] nell'header (/studio/); dal Process Studio si torna al twin con [← Twin].

Il design completo (semantica del passo, dominio, schema di traduzione, roadmap M1-M5) è in docs/process_studio_design.md.

Architettura in breve¶

digital_twin/studio/
  engine/        motore PURO a tick sincrono two-phase (zero dipendenze, hash deterministico)
  scenario.py    schema+validatore dello scenario JSON (errori leggibili, tempi → tick)
  catalog.py     catalogo tipi di cella (default = ASSUMPTION dichiarate dai benchmark)
  runner.py      batch: N settimane, seed, KPI + traccia campionata → SQLite
  import_twin.py factory_model.json (twin live) → scenario aggregato
  translate/     scenario → rete di Petri P/T temporizzata e π-calcolo
  server.py      API HTTP aiohttp :8081 (/studio/api/*)
web/site/studio/ editor a griglia nel browser (canvas, palette, playback, confronti)

Principi ereditati dal resto del twin: motore puro e headless (la GUI non tocca mai la logica), bake → replay (la simulazione gira server-side, il browser riproduce la traccia), determinismo (stessa config + stesso seed ⇒ stessa sequenza di hash — è la base dei regression test), persistenza in SQLite (scenari, run, tracce compresse).

Come si usa¶

Disegna — palette a sinistra: celle tipizzate (taglio, mini-AFP, drappatura, compattazione, pressa, ispezione…), buffer/magazzini, linee skid con dock, corsie AGV, zone (es. clean room). Ogni cella ha variante manual/auto, manning, ciclo e sotto-cicli di debulk (la manopola che separa manuale e automatizzato).
Simula — [Esegui] con settimane e seed: KPI (throughput, lead p50/p95, ore-uomo, utilizzo, code) + playback della traccia. Il calendario supporta 1x8/2x8/3x8 su 5-7 giorni, festivi (shifts.holidays, giorni sim in cui le celle manual sono ferme) e straordinario al sabato (shifts.overtime_h): le celle auto girano h24.
Confronta — [Confronta] esegue A/B a seed appaiato (stessi arrivi per entrambi); la vista Risultati aggiunge Gantt dei carrier e curva CONWIP (sweep sui carrier).
Esporta — [Esporta] traduce lo scenario corrente nei formalismi qui sotto.

Con [Apri] → "dal twin live" l'editor importa factory_model.json come scenario aggregato: una stazione con c risorse parallele diventa c celle replicate, un buffer finito fra stadi consecutivi fa da cap di WIP (niente skid/AGV: il layout è una linea astratta auto-generata), la cura è resa come celle parallele (capacità aggregata preservata, mix per settore no). Tutti i numeri restano ASSUMPTION ereditate dal twin.

I cinque export formali¶

Export	Formato	Perché
Rete di Petri PNML	`.pnml` (ISO/IEC 15909-2)	scambio standard verso tool di model checking (LoLA: deadlock, invarianti, CTL)
Rete di Petri TINA	`.net` testuale	durate deterministiche `[d,d]` leggibili: analisi TPN in TINA e carta-e-penna
π-calcolo	`.pi` testo	struttura di comunicazione (chi parla con chi) ed equivalenze comportamentali
π-calcolo LaTeX	`.tex` standalone	la stessa algebra impaginata per note e discussione
P-invarianti	JSON	prova automatica delle leggi di conservazione (carrier CONWIP, pool operatori) calcolata con Gauss sull'incidenza

Limiti dichiarati (design, sez. 4.3): il model checking regge scenari piccoli/medi; FIFO e priorità non vivono nella P/T pura — la fedeltà di politica resta al motore.

Perimetro epistemico

I default del catalogo celle vengono da forbici pubbliche di letteratura e sono ASSUMPTION finché non tarati su dati reali; gli scenari sono strumenti di screening comparativo, non validazione di processo.