Generalize live material consumption architecture

This commit is contained in:
2026-09-04 16:43:24 +02:00
parent e144935439
commit 231e18082c
4 changed files with 209 additions and 32 deletions
+32 -14
View File
@@ -6,27 +6,43 @@ Establish package boundaries, architecture documentation, example calculation
configuration, basic domain/protocol models, tests, and an optional local
TimescaleDB Compose design.
## 1. ENLYZE API exploration client/CLI (recommended exact next milestone)
## 1. ENLYZE API exploration client/CLI (completed baseline)
A read-only, GET-only raw inspection CLI and fixture sanitizer are implemented.
The remaining work is live, authorized exploration of machines, signal catalog,
bounded samples, state history, production-order history, and article/material
context. Record sanitized fixtures and update `docs/enlyze-api.md` with
evidence. Do not implement ingestion or a database schema before this is
complete.
Exploration established a K7 candidate mass-flow signal and speed gate; the
evidence and remaining uncertainties are recorded in `docs/enlyze-api.md`.
Continue to record sanitized fixtures for newly verified semantics.
## 2. Persistence foundation
## 2. Live material-consumption MVP (next implementation milestone)
Detect the currently active Production Run and production order, continuously
ingest new ENLYZE samples, maintain persistent incremental integration state,
and store/expose cumulative material consumption for Grafana. Implement this
as generic rate integration (`material_rate * elapsed_time`) subject to
configured machine/process-specific validity conditions, so it can serve more
than one machine/material pair. The first validated implementation is K7:
integrate `Stundenleistung Anlage` (kg/h) only while `Geschwindigkeit
Gesamtanlage > 0.5 m/min`; do not use `Anlage läuft` as the primary gate.
Bento 1 bentonite-powder consumption is the next analogous use case. Select
and validate its ENLYZE source variable and gating logic from process data
before implementing it; neither is defined yet.
## 3. Persistence foundation
Design and migrate a TimescaleDB schema for derived metrics/events, calculation
runs, context, and incremental state. Add Grafana-oriented query examples.
runs, Production Run/order context, and incremental state. Add Grafana-oriented
query examples.
## 3. First vertical slice
## 4. Historical replay/backfill
Implement one configured integration calculation over a verified signal and
production-order context. Include backfill, rerun/provenance behavior, and
Enable bounded historical Production Run replay and production-order analysis
using the same generic integration engine as live processing. Integrate each
Production Run separately and aggregate derived values at the production-order
level; never bridge gaps between runs. Include rerun/provenance behavior and
tests against sanitized fixtures.
## 4. Peak detection (first detector completed)
## 5. Peak detection (first detector completed)
The generic configurable sawtooth detector is implemented: it retains the
current maximum, closes a cycle after a configurable below-peak fraction has
@@ -38,5 +54,7 @@ non-zero resets, and varying peak heights without detector special cases.
## Later
State/cycle durations, aggregates by order, rolling statistics, threshold
events, derivatives, and specific-consumption calculations.
State/cycle durations, rolling statistics, threshold events, derivatives, and
specific-consumption calculations. An optional historical mass-balance
refinement is actual QA/QS basis-weight data from SQL, replacing static article
basis weight; it is not required for the live material-consumption MVP.