SIMS — Product Specification

What SIMS must be, per the Simoldes RFI and client documentation. Build the app toward this. Where the current code deviates, each area carries a conformance badge.

1 · What SIMS is

SIMS is an MES for Simoldes' injection-molding factories. It computes real-time efficiency KPIs (OEE, TEEP, PPM…) per machine, mould and factory, from two streams: automated machine telemetry (EWON IoT over OPC-UA) and manual operator input on tablets (the why behind stoppages, the rejections, the OF/mould/cavity context machines can't self-report). It replaces the legacy proGrow platform.

2 · Roles

The RFI defines a project team; the product defines four operating roles. Role determines which views are reachable.

3 · Data sources canonical model met

The RFI lists 16 information sources. The product reduces them to: EWON device (automated), ERP "Ordens de Fabrico" / Xpert (OF headers, theoretical cavities, operators), 6 manual-input flows, and Calendário (open-time schedule). proGrow is not an RFI dependency — the RFI is proGrow-agnostic.

The canonical-source rule

Manual SIMS entries are canonical. proGrow is fallback / validation only, and is being removed from the KPI path at D4. The mould (turno-molde), not the OF, is the KPI attribution unit — a mould can change mid-OF (a SMED 3A/3F/3G is the boundary).

# Source priority for any KPI input
manual SIMS entry  →  Xpert/ERP  →  proGrow (fallback)  →  default
# Setting USE_PROGROW_FALLBACK=False does NOT make KPIs standalone —
# it only governs the /stoppages read path. The real cut is the G1-G6 rewire (§13).

4 · Operator views D2 built

The operator never leaves the kiosk layout. Each view below is from the demo script (the canonical D2 walkthrough) reconciled with the RFI manual-input requirements.

4.1 · Machine identification + handover /operator/machine-confirm

Purpose: pick the observed machine; show an idle "handover" state between operators. Shows: machine selector (only machines this tablet may serve); big machine name + live KPIs (OEE, parts, downtime); one Identificar-me button, readable at 3 m.

• All inputs from the tablet are signed with the chosen machine.
• Data collection is independent of the operator session — with nobody identified, machine telemetry still flows, but stoppages/rejections aren't attributed.
• Idle OEE includes operator-less hours (industry standard — else OEE is artificially high).

4.2 · Clock-in + manual-input hub /operator/login → /input

Purpose: clock in by personal code, reach the central input panel. Shows: numeric keypad (Limpar + ⌫); the live OF tile (OF id, PRODUZIDAS, TC real vs theoretical); cards for REJEIÇÕES, ORDEM DE FABRICO, 1ª PEÇA OK, COLABORADOR; an OFFLINE indicator.

4.3 · Rejection logging /input/rejections compliant

Purpose: log a defective part. Shows: codes by category (Injeção/Aspecto/Forma/Embalagem… >100 codes); a "Sugeridos para esta OF" section that learns from the last 24h; a quantity keypad; a "Submeter N × CÓDIGO" summary.

• Rejection signed with operator ID → audit log + reports. Code taxonomy in §11.
• Codes editable in admin (add/disable/rename) with history preserved — an old rejection keeps its original code.
• Offline → IndexedDB queue (PWA), syncs on reconnect. Parallel duplicate rejections each kept with timestamp + session_id; supervisor can invalidate.
• Rejection carries: Tipo de Rejeição, Código, Referência, data de rejeição (derives Turno), Rótulo.

4.4 · Stoppage justification /input/stoppages compliant

Purpose: assign a reason code to an auto-detected downtime. Shows: stoppage categories (Manutenção/Material/Falta de Material/Troca de Molde…); a list of unjustified stoppages with timestamps.

• The machine auto-detects stoppages (cycle too long / sensor); the Timeline updates live.
• Justify after shift (carry to next day) or via supervisor admin.
• Stoppage new-ID rule (RFI #01) — a new stoppage ID on: (1) change into stopped state, (2) a manual pause-button stoppage, (3) a history split. Auto per-shift splits keep the same ID to avoid double-counting.

4.5 · OF start + mould/cavity confirm /input/work-order compliant

Purpose: open a work order, confirm the mould, capture effective cavities. Rule (RFI): Nº Cavidades Efetivo is operator-entered (manual OF source), distinct from Nº Cavidades Teórico (ERP). Defaults to theoretical, editable down (blocked-cavity case). See §12.

4.6 · First-piece validation /input/part-validation D2 placeholder

RFI intent (#17): validate the first conforming part — occurrence + timestamp, signed by a Colaborador (often different from the machine operator). The timestamp is the SMED end-time (§9 #02). Current: honest "Em breve / Funcionalidade futura" placeholder — full workflow is D3 once the client defines it. route reaches placeholder, bypassing the disabled menu gate — cosmetic

4.7 · My session /operator/session partial

Purpose: the operator's own audit trail — confirm numbers before shift end. Shows: header (name, code, machine, start); summary (parts, rejections, stoppages); chronological event list.

5 · Supervisor views D2 built

5.1 · Login /login

Simoldes email + existing password policy. UI is permanent European Portuguese, no English fallback. Sessions expire after 30 min inactivity. SSO automation deferred to D4.

5.2 · Machines overview /machines

First screen after login. Cards per machine (pilot: KM 850 II, KM1300) — live state (producing / stopped / no-operator), OEE, parts today, "updated Ns ago". Numbers are live-calculated from OPC-UA, never manual. Machine offline → "sem comunicação" (no fabricated data). New machine = add reference + map OPC topic in admin (~5 min, no code).

5.3 · Machine detail /machines/:code

The most-used supervisor page. Four tabs:

5.4 · Tempo de Trabalho Colaborador report /reports/tempo-trabalho central D2 deliverable

Purpose: collaborator work-time report. Shows: all sessions (who / machine / OF / start–end / duration); open sessions flagged "ABERTA"; KPIs (sessions, total hours, distinct operators, open count); filters (date/operator/machine/shift); Exportar CSV.

• CSV follows the proGrow schema exactly (columns for HR import, no transformation).
• CSV excludes open sessions (only closed — else wrong duration).
• One session = one OF: each OF change closes the prior session, opens a new one.
• Sessions open >24h are auto-closed; supervisor notified in Active Sessions admin.

6 · Admin & IT views D2 built

6.1 · Tablet provisioning /admin/tablets (IT)

• Enter an Etiqueta (e.g. "Sala Injeção A") → get an ID + provisioning code.
• Code shown exactly once, not recoverable — only the hash stored in DB, plaintext never persisted. Regenerate if lost.
• Token lasts 30 days default; revoke → token dies immediately. One tablet can serve two machines.

6.2 · Tablet activation /tablet-setup

Paste ID + code → "Activar tablet" → tablet is locked to the operator layout (any supervisor URL redirects back here — "fundamental para a confiança no audit log"). Initial activation needs network; then works offline with the local queue.

6.3 · Administration /admin/* (Supervisor)

All business config lives here — no Procimo IT needed (only OPC mapping + new machines go through Procimo). Operators (add/suspend/edit code) · Rejection codes (>100, add/rename/disable) · Stoppage codes · Active sessions (who's on which machine + force-end) · Tablets (state/revoke).

7 · Shopfloor dashboards RFI · largely D3+

The RFI specifies 10 real-time shopfloor boards (43-inch floor monitors, ≤5-min refresh). These are mostly beyond the demo but are the product's monitoring backbone. Summary of each:

8 · Reports RFI · D3+

The RFI specifies 16 historical reports across Módulo / Fábrica / Grupo. Cross-cutting rules: almost every report excludes OF "1G"; stoppage-time reports exclude the TNA set (1G, 2A, 2B, 2C, 6E); "SMED" everywhere = the new SMED definition (§9 #02).

9 · KPI definitions core 3 built · 31 total

The RFI defines 31 KPIs + 23 supporting indicators, each with an exact formula, components, temporal granularity, and dimensions. The engine is kpi_calculator.py. Below: the identities that govern all of them, then the full table.

Master identities

# The whole KPI system reduces to these  (PT source term in comments)
Parts            = Shots × Actual Cavities          # Nº Peças = Nº Injeções × Cav. Efetivo (manual OF input)
Theoretical Parts= (Operating Time / Theo. Cycle) × Theo. Cavities  # Nº Peças Teórico
Good Parts       = Parts − Rejects                  # Nº Peças OK = Nº Peças − Nº Rejeições
Planned Opening Time = Opening Time − TNA Stoppage Time   # Tempo Abertura Planeada; TNA = 1G,2A,2B,2C,6E

RU  (Availability)  = Operating Time / Planned Opening Time   # Disponibilidade
RQT (Performance)   = Parts          / Theoretical Parts      # Performance
RQL (Quality)       = Good Parts     / Parts                  # Qualidade
OEE  = RU × RQT × RQL
TEEP = RU' × RQT × RQL   # TEEP/OOE use Opening Time (not Planned); INCLUDE OF=1G

The 31 KPIs

Common dimensions (filter axes): Máquina · Módulo · Fábrica · Hora · Turno · Dia · Semana · Mês · OF · Molde · Referência · Tipo/Código de Paragem · Tipo/Código de Rejeição · Colaborador · Rótulo Início/Fim.

10 · Manual inputs 4 of 6 built

Six "Registo Manual" sources drive the KPIs. They are the heart of the product — machines give the what, these give the why and the business context.

11 · Code taxonomy seeded from M026PP06

The client's official code table (doc M026PP06_V6) has two families. Codes are seeded in SIMS; categories drive the rejection + stoppage UIs.

11.1 · Defect (rejection) codes — 8 categories, >100 codes

11.2 · Stoppage codes — 6 categories, ~47 codes

12 · Cavities & moulds model built · sign-off pending

This is the spec's most defect-prone area and the root of the historic "~50% OEE" MES bug.

# cavity resolution at runtime
run.effective_cavities  →  mould.theoretical_cavities  →  proGrow last-known  →  1.0

13 · Conformance scorecard

Where the build stands against the RFI. Build the app to turn every row green. The KPI engine's proGrow coupling (G1-G6) is the main thing blocking "standalone".

KPI-engine standalone gaps (proGrow → SIMS)

Other conformance findings

14 · Open client sign-offs

Spec questions that need Paulo / Simoldes before the relevant code is final:

• Cavity / mould model (4 assumptions): (1) run boundary = operator confirms mould at OF-start; (2) one mould per machine at a time; (3) effective cavities = single per-run value (per-reference split for collection moulds is follow-up); (4) effective cavities editable at start + during run.
• Tolerance contract (DEV2-545): Paulo wants "nem 1 peça nem 1 minuto" lost before proGrow termination; Procimo's bar is <1%. Unresolved.
• First-piece workflow: client must define the 1ª Peça OK validation flow before #17/#02-end-time are built for real.
• Demo KPI scope: G1 OEE-fix is required for the demo; confirm whether G3/G4/G5 are demo or fast-follow.
• Phasing (blue/black): confirm the precise Intermediate-vs-later split against the original RFI Excel colours for any ambiguous item.

Spec compiled 2026-06-02 from the Simoldes RFI (Jan 2023), code table M026PP06_V6, the demo script, and the manual-input + proGrow-standalone conformance audits. Client documentation is authoritative; where code disagrees it's flagged a gap. · Companion: docs/SPEC.md in the repo.

15 · PT → EN glossary

Every Portuguese domain term used in this spec, with its English equivalent. These PT strings appear in the UI, DB columns and client docs — devs will meet them verbatim.

KPIs & quantities

Time

Dimensions / grouping

Stoppage / rejection / status

Views / dashboards / reports

UI strings