3.9 KiB
Roadmap
0. Bootstrap (this milestone)
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 (completed baseline)
A read-only, GET-only raw inspection CLI and fixture sanitizer are implemented.
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. Live material-consumption MVP (in progress)
The integration engine, ENLYZE gateway, single-cycle polling service, atomic
JSON checkpoint store, and configured continuous foreground polling runner are
implemented and covered by synthetic tests. Configure the validated K7 instance
in config/k7-material-consumption.yaml; start it with
production-analytics run material-poll --config config/k7-material-consumption.yaml.
Runtime options select the polling interval, state directory (default: ignored
data/state/material/), and existing secrets-file handling. Only one writer may
poll each machine/order state key.
The runner now persists cumulative material-consumption snapshots for Grafana in
PostgreSQL using db/schema.sql. JSON remains the restart checkpoint; PostgreSQL
stores derived time-series snapshots only. No Timescale-specific features are used.
A new order may first appear with a non-zero total after initial sample integration.
Grafana dashboard validation remains pending. No HTTP endpoints, application
containers, daemonization, or schedulers have been added.
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, Production Run/order context, and incremental state. Add Grafana-oriented query examples.
4. Historical replay/backfill
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.
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 actual sample support for a configurable elapsed duration, and emits one completed peak. Its pure state can later be persisted for incremental use. It has been validated with a clean K7 roll-length reference signal and a more variable Bento 2 roll-weight robustness signal; the latter includes plateaus, non-zero resets, and varying peak heights without detector special cases.
Later
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.