SIMS · SPEC
Full spec →
01 / 11

Product specification walkthrough · 2026-06-02

Build SIMS to the client's spec.

What the product must be, per the Simoldes RFI and client documentation — the roles, the views, the KPI rules, the code taxonomy. This is the target. The job: make the app comply.

In English. Portuguese terms are kept where they're the literal UI/DB/client-doc strings, each glossed — full PT→EN glossary in the spec.

KPIs in the RFI
31

+23 supporting indicators

Shopfloor boards
10

+16 historical reports

Codes (M026PP06)
150+

defects + stoppages

Manual inputs
6

the "why" behind the data

The one idea

Every KPI is the same quantities, recombined.

# get these right and the 31 KPIs follow  (PT term = English)
Parts          = Shots × Actual Cavities          # Nº Peças = Nº Injeções × Cav. Efetivo (manual)
Theoretical Parts = (Operating Time / Theo. Cycle) × Theo. Cavities
Good Parts     = Parts − Rejects

OEE  = RU × RQT × RQL
       RU  Availability = Operating Time / Planned Opening Time
       RQT Performance  = Parts / Theoretical Parts
       RQL Quality      = Good Parts / Parts

A machine produces injections. SIMS turns them into parts, subtracts rejections, times it against planned open time. Machines give the what; operators give the why.

Roles

Four roles. The role decides the view.

Operator

Floor tablet, locked kiosk. Clock in by code; justify stoppages; log rejections; start OF + confirm mould/cavities; validate first piece; see own session. No sidebar, no reports.

Supervisor

Laptop / office tablet. Full app — machines, detail tabs, reports, admin config. Monitors the fleet, reads KPIs, configures codes & operators. Can't do operator input on the laptop.

IT (Simoldes)

Provisions tablets, issues one-time codes, maps OPC topics. D4: owns operator lifecycle.

System admin D4

Splits from supervisor — only Simoldes IT creates/deletes operators + tenant config.

Plus an EasySolutions training overlay (P/D/C/A + colour per operator-mould) on shopfloor boards — future phase.

Operator views · D2 built

The kiosk flow — clock in, then input the "why".

  • Machine confirm + handover — pick machine, idle KPIs, "Identificar-me". Inputs signed with the machine.
  • Clock-in + hub — keypad, live OF tile, input cards. No PIN in D2 (deliberate).
  • Rejections — >100 codes by category, "sugeridos para esta OF", offline queue. compliant
  • Stoppage justify — assign a code to auto-detected downtime. New-ID rule. compliant
  • OF start — open WO, confirm mould, enter effective cavities. compliant
  • 1ª Peça OK — placeholder; full workflow D3. future
  • My session — audit trail, but omits OF-starts + clock-ins. partial

Supervisor views · D2 built

Monitor the fleet, read the truth, run the report.

/machines

Live fleet cards — state, OEE, parts today, from OPC-UA every few seconds. Offline → "sem comunicação", never fabricated.

/machines/:code

Four tabs: Produção (Production — how much) · Timeline (why stopped) · Validação (Validation — first piece) · Diagnóstico (Diagnostics — sensor health).

/reports/tempo-trabalho

Operator work-time report — central D2 deliverable. Sessions + CSV in proGrow schema. Excludes open sessions. One session = one Work Order (OF).

That report = RFI KPI #10. The other 15 reports + 10 shopfloor boards are the post-demo monitoring layer.

The rules engine

31 KPIs, two rules you can't forget.

Exclude OF=1G by default

Nearly every KPI excludes OF=1G. The only ones that include it: TEEP (#08), OOE (#22), Tempo Total OF 1G (#28).

TNA codes = planned time

1G, 2A, 2B, 2C, 6E reduce the availability denominator. Maintenance KPIs use 6A-6D. SMED IDs start on 3A, 3F, 3G.

Core 3
OEE·PPM·TEEP

demo scope

Collaborator
#10-13,18,26

#11 stubbed

Maintenance
MTTR·MTBF

6A-6D

Future
EUROMAP·Peso

later phase

Manual inputs · 4 of 6 built

Six "Registo Manual" (Manual Entry) sources drive everything.

  • Estado (Status — stoppage codes + new-ID rule) built
  • Rejeições (Rejects — code/type/ref/label) built
  • Ordens de Fabrico (Work Orders — effective cavities, qty) built
  • Colaboradores (Operators — clock-in/out) — built; per-operator stoppage time + feed incomplete partial
  • Primeira Peça OK (First Part OK) — placeholder; gates SMED end-time future
  • Alteração Parâmetros (Parameter Change) — no UI/route/model at all missing

To hit RFI compliance: build Parameter Change, wire First Part OK as real capture, finish per-operator stoppage time, and UNION Work-Order starts + clock-ins into the session feed.

Taxonomy & cavities

The codes are the client's. The cavities are the trap.

Code families (M026PP06)
  • Defects — 8 categories, >100 codes (Injeção 19, Montagem 27…)
  • Stoppages — 6 categories, ~47 (Production, SMED, Quality, Maint, Logistic, TNA)
  • Classify by family, never by prefix — letters repeat across families.
The ~50% OEE bug

RFI mandates two cavity fields — Teórico (mould has) vs Efetivo (actually running). A 2-cavity mould with 1 blocked, targeted as 2, reports OEE ~50% low. Single combined field is rejected. Mould — not OF — is the attribution unit.

Canonical source

Manual wins. proGrow is fallback, and it's leaving.

# source priority for any KPI input
manual SIMS  →  Xpert/ERP  →  proGrow (fallback)  →  default

# the trap:
USE_PROGROW_FALLBACK=False  # does NOT make KPIs standalone —
                            # only governs the /stoppages read path.
# the real cut is the G1-G6 rewire in the KPI calculator.

The RFI is proGrow-agnostic — sources are EWON, ERP, and manual input. proGrow elimination (D4) means rewiring OEE/TEEP/PPM to SIMS-native cavities + moulds.

Conformance scorecard

Build the app to turn every row green.

KPI engine standalone (G1-G6)
  • G1 OEE parts = proGrow cavities → must be SIMS critical · demo
  • G2-G4 availability / TEEP / PPM still proGrow-primary high
  • G5-G6 cycle deviation + % stoppage from proGrow medium
Other gaps
  • Rejection count: max() vs manual-canonical inconsistency
  • TNA classification hardcoded, not the DB flag
  • KPI #11 stub=0 · #16 no input · #17 placeholder
  • Estado / Rejeições / OF-cavities ahead of spec compliant

Most "deviations" are the build being ahead of a stale spec doc — not regressions. The real work is moulds runtime + G1-G6 + #11/#16/#17.

What you do with this

Make the app
match the spec.

  • Open the full spec — every view, KPI, code, gap with status.
  • Pick a red/amber row, build it toward green.
  • Check each change against the RFI requirement, not just "does it run".
  • Confirm the open client sign-offs before finalising cavity/first-piece code.
  • File a ticket for every gap you close — link the spec section.
  • Where code disagrees with the client doc, the client wins.

Full reference: the product spec →

← → · space · F fullscreen