FlowTime-integration — Systemflödesmodellering
Kan vi spara resonemanget bakom en systemmodell, inte bara simuleringsresultaten?
Forskning | FlowTime, diskret tidssimulering, flaskhalsanalys, modellprovenans
Scenariot
Norrland Logistik driver tre lager längs E4-korridoren mellan Sundsvall och Umeå och hanterar paketsortering och sista-milen-distribution för nordisk e-handel. Sex månader sedan migrerade de från sitt äldre WMS till ett molnbaserat system. Sedan migreringen har genomströmningen vid Härnösands-hubben sjunkit 30 %. Paket som tidigare klarade sorteringen på 45 minuter tar nu över en timme. Eftersläpningen byggs upp under eftermiddagen och klaras inte av förrän nattskiftet.
De har telemetri — tidsstämplar på varje skanningshändelse, ködjup från transportörernas PLC:er, bearbetningstider per sorteringsstation. Tusentals datapunkter per timme. Men datan berättar vad som är långsamt, inte varför. Driftchefen misstänker att det nya systemets batch-bearbetningsintervall är för långt. IT-teamet tror att det är nätverkslatens. Skiftledaren säger att de bara behöver en andra sorteringslinje.
Alla har en teori. Ingen har en modell. Och ingen kan testa sin teori utan att spendera pengar.
Tre integrationsmodeller
FlowTime och Liminara relaterar på tre sätt samtidigt. De utesluter inte varandra — de komponerar.
Modell 1: FlowTime som beräkningsmotor
Den enklaste vyn. FlowTime är en extern beräkningsmotor — ett C#/.NET 9-program som Liminara anropar för att köra simuleringar. Artefakter in, simuleringsresultat ut. Liminara förstår inte kodynamik. Det behöver den inte.
Modell 2: Modellbyggande som en Liminara-pipeline
Mer intressant. FlowTimes simulering är deterministisk — samma modell, samma indata, samma utdata. Men att bygga modellen från ett verkligt system är inte deterministiskt. Det involverar genuina val: hur systemet ska delas upp i tjänster och köer, vilka retry-parametrar som antas, var gränserna dras. Dessa är beslut värda att registrera.
Modell 3: Delad filosofisk grund
Båda systemen delar övertygelser — determinism, DAG-evaluering, immutabilitet, förklarbarhet, tid som struktur — men opererar i olika skalor. FlowTime är ett mikroskop (finkornig flödesdynamik över kontinuerlig tid). Liminara är en verkstad (diskret process att producera och besluta). De kompletterar snarare än konkurrerar.
FlowTime och Liminara delar författare och samutvecklas. FlowTime är skrivet i C#/.NET 9 med ett Blazor WebAssembly-gränssnitt.
Pipelinen
PHASE 1: INGEST AND MODEL (decisions are here)
══════════════════════════════════════════════════════════════════
telemetry ──→ ingest ──→ detect_services ──→ propose_model ──→ validate ──→ calibrate ──→ model
(PLC logs,
scan events,
timestamps)
│ │ │
│ identified: │ AI proposes: │ parameter fit:
│ 5 services │ "inbound dock modeled │ sorting station
│ 3 queues │ as M/D/2 queue, │ μ = 47s (±3s)
│ 2 routers │ sorting as 4 parallel │ confidence: 94%
│ │ servers with shared │
│ │ input queue" │ DECISION RECORDED
│ │ DECISION RECORDED │ (seeds, iterations,
│ │ │ convergence path)
PHASE 2: SIMULATE AND COMPARE (computation is here)
══════════════════════════════════════════════════════════════════
model ──→ scenario_baseline ──→ ┐
│
├──→ compare ──→ recommend ──→ report
model ──→ scenario_second_line ─┤
│
│
model ──→ scenario_batch_fix ───┘
│ │ │
│ FlowTime simulates: │ throughput │ LLM synthesizes:
│ 24h of warehouse ops │ comparison: │ "Second sorting line
│ at 1-minute granularity │ │ improves throughput 22%
│ 1440 time bins │ baseline: 847 │ but batch interval fix
│ deterministic │ +line: 1034 │ recovers 26% at 1/10th
│ │ +batch: 1068 │ the cost"
│ │ │
│ │ │ DECISION RECORDEDFas 1 — Ingest och modellera:
ingest: Hämta 7 dagars telemetri från Härnösands PLC-historian och WMS-API. 2,3 miljoner skanningshändelser, 168 ködjupsmätningar per timme.detect_services: Statistisk uppdelning av skanningshändelseströmmen i logiska tjänster. Identifierar: inlastningsbrygga, primärsortering, sekundärsortering, utlastningsbuffert, utlastningsbrygga. Tre köer mellan dem. Två dirigeringspunkter (pakettyp → sorteringslinje).propose_model: AI undersöker de identifierade tjänsterna och föreslår en FlowTime-modellstruktur — ködiscipliner, serverantal, dirigeringsregler. Detta är det kreativa steget. AI:ns val registreras som ett beslut: “modellerade primärsortering som 4 parallella servrar med delad FIFO-kö baserat på observerat samtidigt bearbetningsmönster.” En människa kan justera detta. Beslutsposten dokumenterar exakt vad som valdes och varför.validate: Kör den föreslagna modellen mot historisk telemetri i FlowTime. Jämför simulerade ködjup med observerade ködjup. Modellnoggrannhet: R² = 0,91 för primärsorteringskön, 0,87 för utlastningsbufferten. Tillräckligt bra för att gå vidare.calibrate: Optimera modellparametrar (betjäningstider, batch-intervall, dirigeringssannolikheter) för att minimera gapet mellan simulerat och observerat beteende. Använder iterativ sökning — slumpfrön och konvergeringsväg registreras som beslut. Utdata: kalibrerad modell med konfidensintervall.
Fas 2 — Simulera och jämföra:
scenario_baseline: Simulera det nuvarande systemet under 24 timmar med FlowTime. Samma modell, samma ankomstmönster. Genomströmning: 847 paket/timme under topplast. Eftersläpningen klaras av kl. 22:30.scenario_second_line: Klona modellen, lägg till en andra sorteringslinje (8 servrar istället för 4). Simulera. Genomströmning: 1 034 paket/timme (+22 %). Eftersläpningen klaras kl. 19:15.scenario_batch_fix: Klona modellen, minska batch-bearbetningsintervallet från 300s till 60s. Simulera. Genomströmning: 1 068 paket/timme (+26 %). Eftersläpningen klaras kl. 18:45.compare: Tabellera resultat över alla scenarier. Kostnadsuppskattningar från referensdata.recommend: AI syntetiserar jämförelsen till en rekommendation. “Batch-intervallfixen återhämtar mer genomströmning till ungefär en tiondel av investeringskostnaden jämfört med en andra sorteringslinje. Den andra linjen blir relevant först vid över 1 200 paket/timme sustained.” Beslut registrerat.
Varje FlowTime-simulering är deterministisk — samma modell ger samma resultat och kan återanvändas. Modellbyggnads- och rekommendationsstegen involverar genuina bedömningar som systemet fångar. Datainsamlingen hämtar från den externa världen.
Vad du kan fråga efteråt
| Fråga | Hur den besvaras |
|---|---|
| ”Varför modellerades primärsorteringen som 4 parallella servrar?” | Beslutspost för propose_model: AI undersökte samtidiga bearbetningsmönster i skanningshändelser, fann 4 simultana paket i sortering vid 94:e percentilen. Modellval registrerat med resonemang och den telemetriskiva det baserades på. |
| ”Hur noggrann är modellen?” | Valideringsartefakt: simulerade vs. observerade ködjup, R² per tjänst. Valideringen körde modellen mot 7 dagars verklig data — jämförelsen är en immutabel artefakt, inte ett påstående. |
| ”Tänk om AI:n hade modellerat sorteringen som 3 servrar istället för 4?” | Forka körningen vid propose_model. Åsidosätt beslutet: 3 servrar. Allt nedströms körs om — validering (R² sjunker till 0,83), kalibrering (andra parametrar), scenarier (andra genomströmningssiffror). Jämför båda modellvarianterna sida vid sida. Telemetriinsamlingen och tjänstedetektionen är cachade. |
| ”Vad händer om paketvolymen växer 40 % nästa år?” | Lägg till ett fjärde scenario: samma kalibrerade modell, skala ankomstfrekvensen ×1,4. FlowTime simulerar — deterministiskt. Varken modellbyggnadsbesluten eller de befintliga scenarioresultaten ändras. Bara det nya scenariot och jämförelsen/rekommendationen körs om. |
| ”Vem beslutade att batch-fixen var bättre än den andra linjen?” | Beslutspost för recommend: AI-resonemang bevarat. Om en människa åsidosatte rekommendationen är den åsidosättningen också ett registrerat beslut med egen motivering. |
Före och efter
Idag: Norrland Logistiks driftchef bråkar med IT baserat på magkänsla. De tar in en konsult som lägger tre veckor på att bygga en simuleringsmodell i ett kommersiellt verktyg. Modellen lever i konsultens licens. När parametrar ändras ringer de tillbaka konsulten. Sex månader senare minns ingen vilka antaganden som låg bakom modellen. Skiftledarens teori om den andra sorteringslinjen testades aldrig eftersom konsulten fick slut på fakturerbara timmar.
Med provenans: Modellen byggs från telemetri i en registrerad pipeline. Varje modelleringsval — varför 4 servrar, varför FIFO-disciplin, varför 300s batch-intervall — är ett beslut med spårbarhet till den data som motiverade det. Tänk-om-scenarier är billiga: ändra en parameter, FlowTime simulerar om på sekunder, allt annat cachas. När driftchefen frågar “vad händer om volymen ökar 40 %?” sex månader senare behöver ingen rekonstruera modellen. Den är en immutabel artefakt. Lägg till ett nytt scenario, få ett svar.
Batch-intervallfixen? Det var rätt beslut. Beslutsposten visar exakt varför — och när volymen till slut når 1 200 paket/timme finns modellen redan där, redo för nästa scenario.
FlowTime-källkod: github.com/23min/flowtime. Söker driftteam och flödesmodelleringspraktiker. [Kontakt ->]