Ignore local markdown notes
This commit is contained in:
masterdev
2
.gitignore
vendored
2
.gitignore
vendored
@@ -69,3 +69,5 @@ compose.override.yml
|
|||||||
# Local archives and non-production notes
|
# Local archives and non-production notes
|
||||||
archive/
|
archive/
|
||||||
archive/*
|
archive/*
|
||||||
|
local-md/
|
||||||
|
local-md/*
|
||||||
|
|||||||
267
UI.md
267
UI.md
@@ -1,267 +0,0 @@
|
|||||||
# UI Guide
|
|
||||||
|
|
||||||
## Purpose
|
|
||||||
|
|
||||||
This file documents the current frontend UI direction for `Plast Track MVP`.
|
|
||||||
|
|
||||||
The product surface is now organized as module tabs instead of one long dashboard page. The goal is to keep the operator focused on one task area at a time while preserving fast access to workshop status, selected machine context, and actions.
|
|
||||||
|
|
||||||
## UI Direction
|
|
||||||
|
|
||||||
The current UI aims for:
|
|
||||||
|
|
||||||
- modern industrial dashboard
|
|
||||||
- simple and readable operator flows
|
|
||||||
- elegant but restrained visual language
|
|
||||||
- fast status scanning
|
|
||||||
- clear separation between monitoring modules and operator actions
|
|
||||||
|
|
||||||
Design principles:
|
|
||||||
|
|
||||||
- show machine state first
|
|
||||||
- reduce visual noise
|
|
||||||
- separate workflows into tabs
|
|
||||||
- keep passive acquisition and machine safety explicit
|
|
||||||
- avoid sending any command back to machines
|
|
||||||
|
|
||||||
## Layout
|
|
||||||
|
|
||||||
The application uses a tabbed module workspace:
|
|
||||||
|
|
||||||
```text
|
|
||||||
Hero Header
|
|
||||||
Summary Ribbon
|
|
||||||
Module Tabs
|
|
||||||
Current Module Panel
|
|
||||||
```
|
|
||||||
|
|
||||||
Current module tabs:
|
|
||||||
|
|
||||||
- `Atelier`: machine cards, filtering, sorting, quick actions, fullscreen workshop mode
|
|
||||||
- `Machine`: selected machine detail, cycles, events, downtime history
|
|
||||||
- `TRS`: daily OEE/TRS and per-machine OEE
|
|
||||||
- `OF`: production order creation and status management
|
|
||||||
- `Arrets`: open downtime qualification and timeline
|
|
||||||
- `Rebuts`: scrap declaration and recent scrap log
|
|
||||||
- `Config`: selected machine signal and timing configuration
|
|
||||||
|
|
||||||
Desktop, tablet, and mobile all use the same module model. On smaller screens, tab buttons and module content stack naturally without horizontal page scroll.
|
|
||||||
|
|
||||||
## Main UI Blocks
|
|
||||||
|
|
||||||
### 1. Hero Header
|
|
||||||
|
|
||||||
Purpose:
|
|
||||||
|
|
||||||
- establish product identity
|
|
||||||
- show realtime connection status
|
|
||||||
- provide top-level hierarchy
|
|
||||||
|
|
||||||
Content:
|
|
||||||
|
|
||||||
- product title
|
|
||||||
- realtime status
|
|
||||||
- error feedback if data loading fails
|
|
||||||
|
|
||||||
### 2. Summary Ribbon
|
|
||||||
|
|
||||||
Purpose:
|
|
||||||
|
|
||||||
- provide workshop-level scanning before entering a module
|
|
||||||
|
|
||||||
Current metrics:
|
|
||||||
|
|
||||||
- global OEE
|
|
||||||
- machines in production
|
|
||||||
- open downtimes
|
|
||||||
- produced quantity vs scrap quantity
|
|
||||||
|
|
||||||
### 3. Module Tabs
|
|
||||||
|
|
||||||
Purpose:
|
|
||||||
|
|
||||||
- separate supervision, production order, downtime, scrap, TRS, and configuration workflows
|
|
||||||
- avoid crowding all operator forms on one page
|
|
||||||
- keep each module readable on tablets and production displays
|
|
||||||
|
|
||||||
### 4. Atelier Module
|
|
||||||
|
|
||||||
Purpose:
|
|
||||||
|
|
||||||
- show every machine at a glance
|
|
||||||
- support quick triage and routing to the right workflow
|
|
||||||
|
|
||||||
Features:
|
|
||||||
|
|
||||||
- machine card grid
|
|
||||||
- status filter
|
|
||||||
- sort by code, OEE, or stops first
|
|
||||||
- fullscreen workshop mode
|
|
||||||
- state duration badge
|
|
||||||
- no-active-OF empty state
|
|
||||||
- quick actions to OF, Rebuts, and Arrets modules
|
|
||||||
|
|
||||||
### 5. Machine Module
|
|
||||||
|
|
||||||
Purpose:
|
|
||||||
|
|
||||||
- turn the selected machine into the focal point
|
|
||||||
|
|
||||||
Contains:
|
|
||||||
|
|
||||||
- status KPIs
|
|
||||||
- current order
|
|
||||||
- average cycle
|
|
||||||
- daily OEE
|
|
||||||
- machine context
|
|
||||||
- recent cycle SVG bars
|
|
||||||
- recent events
|
|
||||||
- downtime history
|
|
||||||
|
|
||||||
### 6. TRS Module
|
|
||||||
|
|
||||||
Purpose:
|
|
||||||
|
|
||||||
- keep daily performance visible without mixing it with operator forms
|
|
||||||
|
|
||||||
Contains:
|
|
||||||
|
|
||||||
- global OEE
|
|
||||||
- availability
|
|
||||||
- performance
|
|
||||||
- quality
|
|
||||||
- per-machine OEE list
|
|
||||||
|
|
||||||
### 7. Operator Action Modules
|
|
||||||
|
|
||||||
Purpose:
|
|
||||||
|
|
||||||
- keep write workflows focused and auditable
|
|
||||||
|
|
||||||
Modules:
|
|
||||||
|
|
||||||
- `OF`: create, start, pause, and close production orders
|
|
||||||
- `Arrets`: qualify open downtimes
|
|
||||||
- `Rebuts`: declare scrap
|
|
||||||
- `Config`: update passive signal configuration
|
|
||||||
|
|
||||||
All forms use inline validation, inline API error feedback, and success toasts.
|
|
||||||
|
|
||||||
## Visual Language
|
|
||||||
|
|
||||||
### Typography
|
|
||||||
|
|
||||||
Fonts:
|
|
||||||
|
|
||||||
- `Instrument Sans` for interface text
|
|
||||||
- `Space Grotesk` for headings and numeric emphasis
|
|
||||||
|
|
||||||
### Color
|
|
||||||
|
|
||||||
Base direction:
|
|
||||||
|
|
||||||
- light industrial gray background
|
|
||||||
- industrial blue primary structure
|
|
||||||
- anthracite text and secondary structure
|
|
||||||
- technical orange active accent
|
|
||||||
- white panels for contrast
|
|
||||||
|
|
||||||
Final palette:
|
|
||||||
|
|
||||||
| Usage | Color | Code |
|
|
||||||
|-------|-------|------|
|
|
||||||
| Couleur principale | Bleu industriel | `#0A2F5A` |
|
|
||||||
| Couleur secondaire | Gris anthracite | `#2B2B2B` |
|
|
||||||
| Couleur accent | Orange technique | `#F28C28` |
|
|
||||||
| Fond clair | Gris tres clair | `#F5F7FA` |
|
|
||||||
| Fond / contraste | Blanc | `#FFFFFF` |
|
|
||||||
|
|
||||||
Status colors:
|
|
||||||
|
|
||||||
- `production`: industrial blue
|
|
||||||
- `arret_non_qualifie`: technical orange
|
|
||||||
- `arret_qualifie`: anthracite
|
|
||||||
- `reglage`: mixed industrial blue / orange
|
|
||||||
- `hors_planning`: neutral anthracite tint
|
|
||||||
|
|
||||||
### Surfaces
|
|
||||||
|
|
||||||
Surfaces use:
|
|
||||||
|
|
||||||
- rounded panels
|
|
||||||
- soft shadows
|
|
||||||
- token-driven borders
|
|
||||||
- high contrast status text
|
|
||||||
|
|
||||||
## Responsive Behavior
|
|
||||||
|
|
||||||
Desktop:
|
|
||||||
|
|
||||||
- centered workspace
|
|
||||||
- full tab row
|
|
||||||
- wide machine grid
|
|
||||||
- split layouts inside form/list modules
|
|
||||||
|
|
||||||
Tablet:
|
|
||||||
|
|
||||||
- tab row wraps to fewer columns
|
|
||||||
- form/list modules stack
|
|
||||||
|
|
||||||
Mobile:
|
|
||||||
|
|
||||||
- single-column flow
|
|
||||||
- summary cards stack
|
|
||||||
- tabs stack
|
|
||||||
- tables scroll horizontally only inside their wrapper
|
|
||||||
- touch targets remain at least 44px high
|
|
||||||
|
|
||||||
## Operator Experience
|
|
||||||
|
|
||||||
The UI is designed so an operator or supervisor can quickly:
|
|
||||||
|
|
||||||
1. see which machines are running or stopped
|
|
||||||
2. filter or sort machines by operational need
|
|
||||||
3. open a selected machine detail view
|
|
||||||
4. create or manage production orders
|
|
||||||
5. qualify downtime
|
|
||||||
6. declare scrap
|
|
||||||
7. review daily TRS/OEE
|
|
||||||
8. configure passive signal timing per machine
|
|
||||||
|
|
||||||
## Current Frontend Files
|
|
||||||
|
|
||||||
Core files:
|
|
||||||
|
|
||||||
- [frontend/src/App.tsx](/d:/@@@DEV/apps/plast%20track/frontend/src/App.tsx:1)
|
|
||||||
- [frontend/src/styles.css](/d:/@@@DEV/apps/plast%20track/frontend/src/styles.css:1)
|
|
||||||
- [frontend/src/components/MachineCard.tsx](/d:/@@@DEV/apps/plast%20track/frontend/src/components/MachineCard.tsx:1)
|
|
||||||
- [frontend/src/components/Panel.tsx](/d:/@@@DEV/apps/plast%20track/frontend/src/components/Panel.tsx:1)
|
|
||||||
- [frontend/src/components/CycleBarChart.tsx](/d:/@@@DEV/apps/plast%20track/frontend/src/components/CycleBarChart.tsx:1)
|
|
||||||
|
|
||||||
## Suggested Next UI Improvements
|
|
||||||
|
|
||||||
Near-term:
|
|
||||||
|
|
||||||
- improve table empty states for OF and machine event history
|
|
||||||
- add optimistic row updates for order and downtime actions
|
|
||||||
- add tablet-first operator shortcuts for common reason codes
|
|
||||||
|
|
||||||
Medium-term:
|
|
||||||
|
|
||||||
- create separate operator and supervisor views
|
|
||||||
- add richer downtime timeline with duration buckets
|
|
||||||
- add historical trend charts for OEE and scrap
|
|
||||||
- add saved workshop display presets
|
|
||||||
|
|
||||||
High-value UX additions:
|
|
||||||
|
|
||||||
- keyboard-friendly action flow for industrial tablets
|
|
||||||
- larger gloved-use mode
|
|
||||||
- alarm emphasis rules without overusing red
|
|
||||||
- quick action drawer for the selected machine
|
|
||||||
|
|
||||||
## UI Goal
|
|
||||||
|
|
||||||
The target is not a generic admin panel.
|
|
||||||
|
|
||||||
The target is a calm, production-oriented interface that helps people notice problems fast, act with minimal friction, and understand machine performance in context.
|
|
||||||
@@ -1,236 +0,0 @@
|
|||||||
# Plast Track MVP - Codex Prompt & UI Instructions
|
|
||||||
|
|
||||||
## 1. Codex Task Prompt
|
|
||||||
|
|
||||||
Use this as the top-level prompt when opening a Codex session on this repository.
|
|
||||||
|
|
||||||
```text
|
|
||||||
You are working on Plast Track MVP - a lightweight MES/IoT dashboard for
|
|
||||||
supervising multi-brand injection molding machines. The stack is:
|
|
||||||
|
|
||||||
Backend FastAPI + PostgreSQL + Mosquitto MQTT (Python)
|
|
||||||
Frontend React + TypeScript (Vite, port 5173)
|
|
||||||
Infra Docker Compose
|
|
||||||
|
|
||||||
Repository layout:
|
|
||||||
/backend FastAPI app, MQTT consumer, OEE logic, WebSocket
|
|
||||||
/frontend React + TypeScript operator dashboard
|
|
||||||
/edge-simulator Publishes simulated MQTT machine events
|
|
||||||
/database init.sql + seed.sql
|
|
||||||
/mqtt mosquitto.conf
|
|
||||||
docker-compose.yml
|
|
||||||
|
|
||||||
Key rules:
|
|
||||||
- Never send commands back to the machines. Acquisition is read-only / passive.
|
|
||||||
- All timestamps are UTC ISO-8601.
|
|
||||||
- OEE = Availability x Performance x Quality (see README for exact formulas).
|
|
||||||
- The WebSocket at /ws/dashboard pushes refresh notifications; the UI then
|
|
||||||
refetches via REST. Do not push full payloads over the socket.
|
|
||||||
- Machine status values: production | arret_non_qualifie | arret_qualifie |
|
|
||||||
reglage | hors_planning
|
|
||||||
|
|
||||||
Before writing code:
|
|
||||||
1. Read the relevant backend route or model file first.
|
|
||||||
2. Confirm the PostgreSQL schema in /database/init.sql for any DB changes.
|
|
||||||
3. Run `pytest` in /backend and `npm run build` in /frontend to verify changes.
|
|
||||||
4. Keep backend business logic inside service modules, not route handlers.
|
|
||||||
5. For frontend changes, follow the UI instructions below.
|
|
||||||
```
|
|
||||||
|
|
||||||
## 2. UI Instructions for Codex
|
|
||||||
|
|
||||||
Paste these instructions into any Codex task that touches the frontend.
|
|
||||||
|
|
||||||
### 2.1 Design System - Non-Negotiable Tokens
|
|
||||||
|
|
||||||
All visual decisions must derive from these tokens. Do not introduce new color
|
|
||||||
hex values, font families, or border-radius values without updating this table.
|
|
||||||
|
|
||||||
#### Colors
|
|
||||||
|
|
||||||
| Token name | Hex | Role |
|
|
||||||
|------------------------|-----------|-----------------------------------------|
|
|
||||||
| `--bg-base` | `#F5F7FA` | Page background |
|
|
||||||
| `--bg-panel` | `#FFFFFF` | Panel and card surface |
|
|
||||||
| `--bg-panel-alt` | derived | Alternate very light gray surface |
|
|
||||||
| `--border` | derived | Anthracite tint border |
|
|
||||||
| `--teal-900` | `#0A2F5A` | Primary industrial blue structure |
|
|
||||||
| `--teal-700` | derived | Darker industrial blue |
|
|
||||||
| `--teal-100` | derived | Industrial blue tint |
|
|
||||||
| `--accent` | `#F28C28` | Technical orange accent and CTA |
|
|
||||||
| `--accent-light` | derived | Technical orange tint |
|
|
||||||
| `--text-primary` | `#2B2B2B` | Anthracite body text |
|
|
||||||
| `--text-secondary` | derived | Anthracite metadata tint |
|
|
||||||
| `--text-on-dark` | `#FFFFFF` | Text on dark surfaces |
|
|
||||||
| `--status-production` | `#0A2F5A` | Industrial blue, machine running |
|
|
||||||
| `--status-unqualified` | `#F28C28` | Technical orange, unqualified stop |
|
|
||||||
| `--status-qualified` | `#2B2B2B` | Anthracite, qualified stop |
|
|
||||||
| `--status-setup` | derived | Blue/orange mix, setup / reglage |
|
|
||||||
| `--status-off-plan` | derived | Anthracite tint, outside planning |
|
|
||||||
|
|
||||||
#### Typography
|
|
||||||
|
|
||||||
| Role | Font family | Weight | Usage |
|
|
||||||
|----------------|-------------------|--------|----------------------------------------|
|
|
||||||
| Display / KPI | `Space Grotesk` | 600 | Headings, large numbers, machine codes |
|
|
||||||
| Body / UI | `Instrument Sans` | 400 | Labels, descriptions, form fields |
|
|
||||||
| Body emphasis | `Instrument Sans` | 600 | Sub-headings, table headers |
|
|
||||||
| Caption / meta | `Instrument Sans` | 400 | Small labels, timestamps, hints |
|
|
||||||
|
|
||||||
Type scale:
|
|
||||||
|
|
||||||
```css
|
|
||||||
--text-xs: 0.75rem;
|
|
||||||
--text-sm: 0.875rem;
|
|
||||||
--text-base: 1rem;
|
|
||||||
--text-lg: 1.125rem;
|
|
||||||
--text-xl: 1.25rem;
|
|
||||||
--text-2xl: 1.5rem;
|
|
||||||
--text-3xl: 2rem;
|
|
||||||
```
|
|
||||||
|
|
||||||
#### Surfaces
|
|
||||||
|
|
||||||
```css
|
|
||||||
border-radius: 12px;
|
|
||||||
box-shadow: 0 1px 3px rgba(10, 47, 90, 0.06), 0 4px 12px rgba(10, 47, 90, 0.04);
|
|
||||||
```
|
|
||||||
|
|
||||||
Selected card:
|
|
||||||
|
|
||||||
```css
|
|
||||||
box-shadow: 0 4px 16px rgba(10, 47, 90, 0.12), 0 0 0 2px var(--accent);
|
|
||||||
```
|
|
||||||
|
|
||||||
Inset surfaces:
|
|
||||||
|
|
||||||
```css
|
|
||||||
background: var(--bg-panel-alt);
|
|
||||||
border: 1px solid var(--border);
|
|
||||||
border-radius: 6px;
|
|
||||||
```
|
|
||||||
|
|
||||||
### 2.2 Layout Rules
|
|
||||||
|
|
||||||
The current UI uses a tabbed module workspace, not a fixed action sidebar.
|
|
||||||
|
|
||||||
```text
|
|
||||||
Hero Header
|
|
||||||
Summary Ribbon
|
|
||||||
Module Tabs
|
|
||||||
Current Module Panel
|
|
||||||
```
|
|
||||||
|
|
||||||
Current modules:
|
|
||||||
|
|
||||||
- `Atelier`: machine cards, filters, sorting, quick actions, fullscreen workshop mode
|
|
||||||
- `Machine`: selected machine detail, cycle trend, events, downtime history
|
|
||||||
- `TRS`: daily OEE/TRS
|
|
||||||
- `OF`: production order creation and management
|
|
||||||
- `Arrets`: downtime qualification
|
|
||||||
- `Rebuts`: scrap declaration and scrap log
|
|
||||||
- `Config`: passive signal and timing configuration
|
|
||||||
|
|
||||||
Responsive rules:
|
|
||||||
|
|
||||||
- Desktop: centered workspace, full tab row, split form/list modules where useful.
|
|
||||||
- Tablet: tabs wrap, form/list modules stack.
|
|
||||||
- Mobile: single column, no horizontal page scroll.
|
|
||||||
|
|
||||||
### 2.3 Component Conventions
|
|
||||||
|
|
||||||
#### Machine Card
|
|
||||||
|
|
||||||
- Card uses `min-height: 180px`.
|
|
||||||
- Machine code uses `Space Grotesk 600`, `--text-xl`.
|
|
||||||
- Status badge uses tokenized status color and text label.
|
|
||||||
- State duration badge shows elapsed time since `status_since`.
|
|
||||||
- No active order state must be visually distinct.
|
|
||||||
- Quick actions route to OF, Rebuts, or Arrets modules.
|
|
||||||
- Selected state uses the elevated `box-shadow`; do not use outline for the selected ring.
|
|
||||||
|
|
||||||
#### Status Badge
|
|
||||||
|
|
||||||
Use `<StatusBadge status="production" />`. Always include a text label; color is never the only state indicator.
|
|
||||||
|
|
||||||
#### KPI Block
|
|
||||||
|
|
||||||
Use for summary and machine detail metrics:
|
|
||||||
|
|
||||||
- label: `--text-xs`, uppercase, `--text-secondary`
|
|
||||||
- value: `--text-2xl`, `Space Grotesk 600`
|
|
||||||
- optional sub-label: `--text-xs`, `--text-secondary`
|
|
||||||
|
|
||||||
#### Forms
|
|
||||||
|
|
||||||
- Fields use full width, `border-radius: 6px`, `border: 1px solid var(--border)`, `padding: 8px 12px`.
|
|
||||||
- Primary action button uses `var(--accent)`, `border-radius: 8px`, `Space Grotesk 600`.
|
|
||||||
- Inline validation appears below the field in `--status-qualified`.
|
|
||||||
- API errors appear inside the active module, not as global alerts.
|
|
||||||
- Success toasts appear inline and auto-dismiss after 3 seconds.
|
|
||||||
|
|
||||||
#### Cycle Bar Mini-Chart
|
|
||||||
|
|
||||||
- Use SVG directly; no third-party charting library.
|
|
||||||
- Newest cycle appears on the right.
|
|
||||||
- Theoretical cycle is a dashed `--teal-100` reference line.
|
|
||||||
- Bars at or below theoretical are green.
|
|
||||||
- Bars above theoretical by more than 10% are orange.
|
|
||||||
- Tooltip shows exact cycle time in seconds.
|
|
||||||
|
|
||||||
### 2.4 Interaction Rules
|
|
||||||
|
|
||||||
| Trigger | Expected behavior |
|
|
||||||
|-------------------------|-------------------------------------------------------|
|
|
||||||
| Click machine card body | Selects machine and opens Machine module |
|
|
||||||
| Click quick OF action | Selects machine and opens OF module |
|
|
||||||
| Click quick Rebut | Selects machine and opens Rebuts module |
|
|
||||||
| Click quick Arret | Selects machine and opens Arrets module |
|
|
||||||
| WebSocket refresh event | Re-fetch dashboard data without unmount flash |
|
|
||||||
| Submit downtime qualify | Validate inline, send REST request, refresh on success |
|
|
||||||
| Submit scrap | Validate inline, clear form on success |
|
|
||||||
| Create production order | Add order; do not auto-start unless user starts it |
|
|
||||||
|
|
||||||
Data fetching:
|
|
||||||
|
|
||||||
- REST calls go to `http://localhost:8000/api/...`.
|
|
||||||
- WebSocket connects to `ws://localhost:8000/ws/dashboard`.
|
|
||||||
- On WS disconnect, show a small reconnecting banner and retry with exponential backoff up to 30 seconds.
|
|
||||||
- Do not poll. Refresh is WebSocket-driven.
|
|
||||||
|
|
||||||
### 2.5 Accessibility Minimums
|
|
||||||
|
|
||||||
- Interactive elements must be reachable by keyboard.
|
|
||||||
- Status colors must have text labels.
|
|
||||||
- Touch targets should be at least 44px high.
|
|
||||||
- Respect `prefers-reduced-motion`.
|
|
||||||
- Body text on panel backgrounds must pass WCAG AA contrast.
|
|
||||||
|
|
||||||
### 2.6 File Conventions
|
|
||||||
|
|
||||||
| What | Where |
|
|
||||||
|-------------------------------|-----------------------------------------------|
|
|
||||||
| Global CSS variables / resets | `frontend/src/styles.css` |
|
|
||||||
| Root app layout | `frontend/src/App.tsx` |
|
|
||||||
| Machine card component | `frontend/src/components/MachineCard.tsx` |
|
|
||||||
| Reusable panel wrapper | `frontend/src/components/Panel.tsx` |
|
|
||||||
| New components | `frontend/src/components/<ComponentName>.tsx` |
|
|
||||||
| Types | `frontend/src/lib/types.ts` |
|
|
||||||
|
|
||||||
Rules:
|
|
||||||
|
|
||||||
- One component per file.
|
|
||||||
- No inline styles in TSX.
|
|
||||||
- No Tailwind.
|
|
||||||
- No UI component library.
|
|
||||||
- No charting library for cycle bars.
|
|
||||||
- No machine command/control path.
|
|
||||||
- No `localStorage` for production state.
|
|
||||||
|
|
||||||
### 2.7 Suggested Next Tasks
|
|
||||||
|
|
||||||
1. Add historian-style OEE and scrap reporting endpoints.
|
|
||||||
2. Add edge gateway buffering for MQTT outage periods.
|
|
||||||
3. Add a real passive gateway adapter specification with example payload mappings.
|
|
||||||
4. Add operator and supervisor views when role needs are defined.
|
|
||||||
5. Add richer downtime timelines and duration buckets.
|
|
||||||
643
prompt_mvp.md
643
prompt_mvp.md
@@ -1,643 +0,0 @@
|
|||||||
# Prompt Codex — Développer un MVP MES/IoT pour superviser des presses à injecter multi-marques par acquisition passive de signaux
|
|
||||||
|
|
||||||
## Rôle attendu de l'AI coder
|
|
||||||
|
|
||||||
Tu es un développeur senior full-stack + IoT industriel. Tu dois concevoir et développer un MVP de supervision de production pour des presses à injecter utilisées en plasturgie/injection plastique, quelle que soit leur marque.
|
|
||||||
|
|
||||||
Contrainte importante : le parc machine peut inclure plusieurs marques et modèles, sans garantie d'interface Euromap 63, Euromap 77, OPC UA ou autre protocole standard. Le MVP ne doit donc dépendre d'aucun protocole constructeur spécifique. L'acquisition doit se faire principalement par lecture passive de signaux électriques machine isolés, capteurs externes et saisie opérateur.
|
|
||||||
|
|
||||||
## Objectif du MVP
|
|
||||||
|
|
||||||
Développer une application web MES légère permettant de superviser les machines en temps réel et de calculer les indicateurs de production de base.
|
|
||||||
|
|
||||||
Le MVP doit permettre de suivre :
|
|
||||||
|
|
||||||
- état machine : production, arrêt, réglage, hors planning ;
|
|
||||||
- compteur cycles automatique ;
|
|
||||||
- temps de cycle réel ;
|
|
||||||
- OF en cours ;
|
|
||||||
- quantité produite ;
|
|
||||||
- quantité bonne ;
|
|
||||||
- quantité rebutée ;
|
|
||||||
- arrêts machine automatiques ;
|
|
||||||
- qualification des causes d'arrêt par opérateur ;
|
|
||||||
- saisie des rebuts ;
|
|
||||||
- calcul TRS/OEE ;
|
|
||||||
- dashboard atelier temps réel.
|
|
||||||
|
|
||||||
## Périmètre machine
|
|
||||||
|
|
||||||
Machines cibles : presses à injecter toutes marques.
|
|
||||||
|
|
||||||
Hypothèse technique :
|
|
||||||
|
|
||||||
- pas d'Euromap 63 garanti ;
|
|
||||||
- pas d'Euromap 77 garanti ;
|
|
||||||
- pas d'OPC UA machine garanti ;
|
|
||||||
- pas d'accès direct aux paramètres process avancés au démarrage ;
|
|
||||||
- acquisition basée sur signaux électriques isolés et/ou capteurs externes ;
|
|
||||||
- approche compatible avec différentes marques via une configuration par machine, sans dépendance à un automate ou protocole propriétaire.
|
|
||||||
|
|
||||||
## Acquisition machine par signaux passifs
|
|
||||||
|
|
||||||
### Option A — Lecture signaux électriques machine
|
|
||||||
|
|
||||||
Le MVP doit gérer une acquisition basée sur des entrées digitales issues de la machine, via relais d'interface ou optocoupleurs.
|
|
||||||
|
|
||||||
Ne jamais connecter directement la gateway IoT aux sorties automate ou aux circuits machine. Toute connexion doit être isolée électriquement. L'acquisition doit rester strictement passive et non intrusive.
|
|
||||||
|
|
||||||
Chaîne recommandée :
|
|
||||||
|
|
||||||
```text
|
|
||||||
Sortie machine / contact sec / relais auxiliaire
|
|
||||||
→ relais d'interface ou optocoupleur
|
|
||||||
→ entrée digitale gateway IoT
|
|
||||||
→ service edge
|
|
||||||
→ MQTT
|
|
||||||
→ backend MES
|
|
||||||
```
|
|
||||||
|
|
||||||
### Signaux machine minimum à supporter
|
|
||||||
|
|
||||||
Le système doit pouvoir configurer les signaux suivants par machine :
|
|
||||||
|
|
||||||
| Signal | Type | Utilisation |
|
|
||||||
|---|---|---|
|
|
||||||
| machine_power_on | digital input | machine sous tension |
|
|
||||||
| auto_mode | digital input | machine en mode automatique |
|
|
||||||
| cycle_signal | digital input | détection cycle ou fin de cycle |
|
|
||||||
| mold_open | digital input optionnel | validation fin de cycle |
|
|
||||||
| ejector_forward | digital input optionnel | comptage cycle fiable |
|
|
||||||
| general_alarm | digital input optionnel | détection arrêt ou alarme |
|
|
||||||
| pump_running | digital input optionnel | machine active |
|
|
||||||
|
|
||||||
Le MVP doit fonctionner avec seulement 2 signaux minimum :
|
|
||||||
|
|
||||||
1. machine_power_on ;
|
|
||||||
2. cycle_signal.
|
|
||||||
|
|
||||||
Les autres signaux doivent être optionnels.
|
|
||||||
|
|
||||||
## Logique de détection cycle
|
|
||||||
|
|
||||||
Le signal principal est `cycle_signal`.
|
|
||||||
|
|
||||||
Règles :
|
|
||||||
|
|
||||||
- détecter un cycle uniquement sur front montant ou front descendant configurable ;
|
|
||||||
- appliquer un anti-rebond logiciel ;
|
|
||||||
- ignorer les impulsions trop proches ;
|
|
||||||
- calculer `cycle_time_sec` entre deux cycles valides ;
|
|
||||||
- publier un événement `cycle_completed` à chaque cycle valide.
|
|
||||||
|
|
||||||
Paramètres configurables par machine :
|
|
||||||
|
|
||||||
```json
|
|
||||||
{
|
|
||||||
"machine_id": "INJ-01",
|
|
||||||
"cycle_signal_edge": "rising",
|
|
||||||
"debounce_ms": 300,
|
|
||||||
"min_cycle_time_sec": 5,
|
|
||||||
"max_cycle_time_sec": 300,
|
|
||||||
"stop_detection_delay_sec": 180
|
|
||||||
}
|
|
||||||
```
|
|
||||||
|
|
||||||
### Exemple événement cycle
|
|
||||||
|
|
||||||
```json
|
|
||||||
{
|
|
||||||
"machine_id": "INJ-01",
|
|
||||||
"event_type": "cycle_completed",
|
|
||||||
"timestamp": "2026-06-14T10:32:15Z",
|
|
||||||
"cycle_time_sec": 18.7,
|
|
||||||
"source": "digital_input",
|
|
||||||
"input_name": "cycle_signal"
|
|
||||||
}
|
|
||||||
```
|
|
||||||
|
|
||||||
## Logique de détection arrêt
|
|
||||||
|
|
||||||
Un arrêt est détecté automatiquement si aucun cycle valide n'est reçu pendant une durée configurable.
|
|
||||||
|
|
||||||
Règle par défaut :
|
|
||||||
|
|
||||||
```text
|
|
||||||
Si aucun cycle depuis 180 secondes alors créer un arrêt machine automatique.
|
|
||||||
```
|
|
||||||
|
|
||||||
L'arrêt reste ouvert jusqu'au prochain cycle valide ou jusqu'à action opérateur.
|
|
||||||
|
|
||||||
À la reprise :
|
|
||||||
|
|
||||||
- fermer l'arrêt automatiquement ;
|
|
||||||
- calculer la durée ;
|
|
||||||
- laisser la cause vide si non qualifiée ;
|
|
||||||
- demander à l'opérateur de qualifier l'arrêt.
|
|
||||||
|
|
||||||
### Exemple événement arrêt
|
|
||||||
|
|
||||||
```json
|
|
||||||
{
|
|
||||||
"machine_id": "INJ-01",
|
|
||||||
"event_type": "machine_stopped",
|
|
||||||
"timestamp": "2026-06-14T10:35:20Z",
|
|
||||||
"reason_code": null,
|
|
||||||
"auto_detected": true
|
|
||||||
}
|
|
||||||
```
|
|
||||||
|
|
||||||
### Causes d'arrêt initiales
|
|
||||||
|
|
||||||
Créer les causes suivantes :
|
|
||||||
|
|
||||||
- changement_moule ;
|
|
||||||
- reglage ;
|
|
||||||
- attente_matiere ;
|
|
||||||
- attente_operateur ;
|
|
||||||
- panne_machine ;
|
|
||||||
- panne_moule ;
|
|
||||||
- attente_qualite ;
|
|
||||||
- nettoyage ;
|
|
||||||
- pause ;
|
|
||||||
- micro_arret ;
|
|
||||||
- autre.
|
|
||||||
|
|
||||||
## Stack technique souhaitée
|
|
||||||
|
|
||||||
Développer une application simple, robuste et industrialisable.
|
|
||||||
|
|
||||||
Stack recommandée :
|
|
||||||
|
|
||||||
- Backend : Python FastAPI ;
|
|
||||||
- Frontend : React + TypeScript ;
|
|
||||||
- Base de données : PostgreSQL ;
|
|
||||||
- Temps réel : WebSocket ;
|
|
||||||
- Messaging IoT : MQTT ;
|
|
||||||
- Broker MQTT : Mosquitto ;
|
|
||||||
- Edge simulator : service Python simulant les entrées digitales ;
|
|
||||||
- Déploiement local : Docker Compose.
|
|
||||||
|
|
||||||
Le MVP doit être exécutable localement avec :
|
|
||||||
|
|
||||||
```bash
|
|
||||||
docker compose up --build
|
|
||||||
```
|
|
||||||
|
|
||||||
## Services à créer
|
|
||||||
|
|
||||||
Créer les services suivants :
|
|
||||||
|
|
||||||
```text
|
|
||||||
/plast-track-mvp
|
|
||||||
/backend
|
|
||||||
/frontend
|
|
||||||
/edge-simulator
|
|
||||||
/mqtt
|
|
||||||
/database
|
|
||||||
docker-compose.yml
|
|
||||||
README.md
|
|
||||||
```
|
|
||||||
|
|
||||||
### backend
|
|
||||||
|
|
||||||
API FastAPI.
|
|
||||||
|
|
||||||
Responsabilités :
|
|
||||||
|
|
||||||
- recevoir les événements MQTT ;
|
|
||||||
- historiser les cycles ;
|
|
||||||
- historiser les états machine ;
|
|
||||||
- détecter ou clôturer les arrêts ;
|
|
||||||
- gérer les OF ;
|
|
||||||
- gérer les rebuts ;
|
|
||||||
- calculer TRS/OEE ;
|
|
||||||
- exposer API REST ;
|
|
||||||
- exposer WebSocket pour dashboard temps réel.
|
|
||||||
|
|
||||||
### frontend
|
|
||||||
|
|
||||||
Application React.
|
|
||||||
|
|
||||||
Écrans minimum :
|
|
||||||
|
|
||||||
1. Dashboard atelier ;
|
|
||||||
2. Détail machine ;
|
|
||||||
3. Lancement OF ;
|
|
||||||
4. Qualification arrêt ;
|
|
||||||
5. Saisie rebut ;
|
|
||||||
6. Vue TRS journalier.
|
|
||||||
|
|
||||||
### edge-simulator
|
|
||||||
|
|
||||||
Service Python permettant de simuler une ou plusieurs presses à injecter de marques différentes.
|
|
||||||
|
|
||||||
Fonctions :
|
|
||||||
|
|
||||||
- publier `machine_power_on` ;
|
|
||||||
- publier `cycle_completed` ;
|
|
||||||
- simuler temps de cycle variable ;
|
|
||||||
- simuler arrêt machine ;
|
|
||||||
- simuler reprise ;
|
|
||||||
- simuler alarme générale optionnelle.
|
|
||||||
|
|
||||||
Le simulateur doit publier sur MQTT.
|
|
||||||
|
|
||||||
Exemple topic :
|
|
||||||
|
|
||||||
```text
|
|
||||||
plasttrack/machines/INJ-01/events
|
|
||||||
```
|
|
||||||
|
|
||||||
Payload :
|
|
||||||
|
|
||||||
```json
|
|
||||||
{
|
|
||||||
"machine_id": "INJ-01",
|
|
||||||
"event_type": "cycle_completed",
|
|
||||||
"timestamp": "2026-06-14T10:32:15Z",
|
|
||||||
"cycle_time_sec": 18.7
|
|
||||||
}
|
|
||||||
```
|
|
||||||
|
|
||||||
## Modèle de données PostgreSQL
|
|
||||||
|
|
||||||
Créer au minimum les tables suivantes.
|
|
||||||
|
|
||||||
### machines
|
|
||||||
|
|
||||||
Champs :
|
|
||||||
|
|
||||||
- id ;
|
|
||||||
- code ;
|
|
||||||
- name ;
|
|
||||||
- brand ;
|
|
||||||
- model ;
|
|
||||||
- status ;
|
|
||||||
- is_active ;
|
|
||||||
- created_at ;
|
|
||||||
- updated_at.
|
|
||||||
|
|
||||||
Exemples :
|
|
||||||
|
|
||||||
```text
|
|
||||||
code = INJ-01
|
|
||||||
brand = Haitian
|
|
||||||
model = Mars II
|
|
||||||
|
|
||||||
Les champs `brand` et `model` doivent rester totalement configurables pour supporter n'importe quelle machine du parc.
|
|
||||||
```
|
|
||||||
|
|
||||||
### production_orders
|
|
||||||
|
|
||||||
Champs :
|
|
||||||
|
|
||||||
- id ;
|
|
||||||
- order_number ;
|
|
||||||
- machine_id ;
|
|
||||||
- article_ref ;
|
|
||||||
- article_name ;
|
|
||||||
- mold_ref ;
|
|
||||||
- material_ref ;
|
|
||||||
- planned_qty ;
|
|
||||||
- cavities ;
|
|
||||||
- theoretical_cycle_time_sec ;
|
|
||||||
- status ;
|
|
||||||
- started_at ;
|
|
||||||
- ended_at ;
|
|
||||||
- created_at ;
|
|
||||||
- updated_at.
|
|
||||||
|
|
||||||
### machine_events
|
|
||||||
|
|
||||||
Champs :
|
|
||||||
|
|
||||||
- id ;
|
|
||||||
- machine_id ;
|
|
||||||
- event_type ;
|
|
||||||
- timestamp ;
|
|
||||||
- payload JSONB ;
|
|
||||||
- created_at.
|
|
||||||
|
|
||||||
### cycles
|
|
||||||
|
|
||||||
Champs :
|
|
||||||
|
|
||||||
- id ;
|
|
||||||
- machine_id ;
|
|
||||||
- production_order_id ;
|
|
||||||
- timestamp ;
|
|
||||||
- cycle_time_sec ;
|
|
||||||
- cavities ;
|
|
||||||
- produced_qty ;
|
|
||||||
- is_valid ;
|
|
||||||
- created_at.
|
|
||||||
|
|
||||||
### downtimes
|
|
||||||
|
|
||||||
Champs :
|
|
||||||
|
|
||||||
- id ;
|
|
||||||
- machine_id ;
|
|
||||||
- production_order_id ;
|
|
||||||
- start_time ;
|
|
||||||
- end_time ;
|
|
||||||
- duration_sec ;
|
|
||||||
- reason_code ;
|
|
||||||
- comment ;
|
|
||||||
- auto_detected ;
|
|
||||||
- qualified_by ;
|
|
||||||
- created_at ;
|
|
||||||
- updated_at.
|
|
||||||
|
|
||||||
### scraps
|
|
||||||
|
|
||||||
Champs :
|
|
||||||
|
|
||||||
- id ;
|
|
||||||
- machine_id ;
|
|
||||||
- production_order_id ;
|
|
||||||
- quantity ;
|
|
||||||
- reason_code ;
|
|
||||||
- comment ;
|
|
||||||
- operator_name ;
|
|
||||||
- timestamp ;
|
|
||||||
- created_at.
|
|
||||||
|
|
||||||
### reference tables
|
|
||||||
|
|
||||||
Créer aussi :
|
|
||||||
|
|
||||||
- downtime_reasons ;
|
|
||||||
- scrap_reasons ;
|
|
||||||
- operators optionnel.
|
|
||||||
|
|
||||||
## API REST minimum
|
|
||||||
|
|
||||||
Créer les endpoints suivants.
|
|
||||||
|
|
||||||
### Machines
|
|
||||||
|
|
||||||
```http
|
|
||||||
GET /api/machines
|
|
||||||
GET /api/machines/{machine_id}
|
|
||||||
GET /api/machines/{machine_id}/status
|
|
||||||
GET /api/machines/{machine_id}/events
|
|
||||||
GET /api/machines/{machine_id}/cycles
|
|
||||||
GET /api/machines/{machine_id}/downtimes
|
|
||||||
```
|
|
||||||
|
|
||||||
### OF
|
|
||||||
|
|
||||||
```http
|
|
||||||
GET /api/production-orders
|
|
||||||
POST /api/production-orders
|
|
||||||
POST /api/production-orders/{id}/start
|
|
||||||
POST /api/production-orders/{id}/pause
|
|
||||||
POST /api/production-orders/{id}/close
|
|
||||||
```
|
|
||||||
|
|
||||||
### Arrêts
|
|
||||||
|
|
||||||
```http
|
|
||||||
GET /api/downtimes/open
|
|
||||||
POST /api/downtimes/{id}/qualify
|
|
||||||
```
|
|
||||||
|
|
||||||
Payload qualification :
|
|
||||||
|
|
||||||
```json
|
|
||||||
{
|
|
||||||
"reason_code": "attente_matiere",
|
|
||||||
"comment": "Matière non disponible au poste",
|
|
||||||
"qualified_by": "operateur_1"
|
|
||||||
}
|
|
||||||
```
|
|
||||||
|
|
||||||
### Rebuts
|
|
||||||
|
|
||||||
```http
|
|
||||||
POST /api/scraps
|
|
||||||
GET /api/scraps
|
|
||||||
```
|
|
||||||
|
|
||||||
Payload rebut :
|
|
||||||
|
|
||||||
```json
|
|
||||||
{
|
|
||||||
"machine_id": "INJ-01",
|
|
||||||
"production_order_id": 1,
|
|
||||||
"quantity": 12,
|
|
||||||
"reason_code": "bavure",
|
|
||||||
"comment": "Bavure côté plan de joint",
|
|
||||||
"operator_name": "operateur_1"
|
|
||||||
}
|
|
||||||
```
|
|
||||||
|
|
||||||
### TRS/OEE
|
|
||||||
|
|
||||||
```http
|
|
||||||
GET /api/oee/daily?date=2026-06-14
|
|
||||||
GET /api/oee/machines/{machine_id}?from=2026-06-14T00:00:00Z&to=2026-06-14T23:59:59Z
|
|
||||||
```
|
|
||||||
|
|
||||||
## Calcul TRS/OEE
|
|
||||||
|
|
||||||
Formule :
|
|
||||||
|
|
||||||
```text
|
|
||||||
TRS = Disponibilité × Performance × Qualité
|
|
||||||
```
|
|
||||||
|
|
||||||
### Disponibilité
|
|
||||||
|
|
||||||
```text
|
|
||||||
Disponibilité = Temps de marche / Temps planifié
|
|
||||||
```
|
|
||||||
|
|
||||||
Pour le MVP :
|
|
||||||
|
|
||||||
- temps planifié = durée entre démarrage OF et fin OF, ou journée de production configurée ;
|
|
||||||
- temps arrêt = somme des downtimes ;
|
|
||||||
- temps marche = temps planifié - temps arrêt.
|
|
||||||
|
|
||||||
### Performance
|
|
||||||
|
|
||||||
```text
|
|
||||||
Performance = (Cycle théorique × Nombre de cycles valides) / Temps de marche
|
|
||||||
```
|
|
||||||
|
|
||||||
Limiter la performance à 100% par défaut pour éviter les valeurs aberrantes.
|
|
||||||
|
|
||||||
### Qualité
|
|
||||||
|
|
||||||
```text
|
|
||||||
Qualité = Quantité bonne / Quantité produite totale
|
|
||||||
```
|
|
||||||
|
|
||||||
Avec :
|
|
||||||
|
|
||||||
```text
|
|
||||||
Quantité produite totale = cycles valides × nombre empreintes
|
|
||||||
Quantité bonne = quantité produite totale - rebuts
|
|
||||||
```
|
|
||||||
|
|
||||||
## Frontend attendu
|
|
||||||
|
|
||||||
### Dashboard atelier
|
|
||||||
|
|
||||||
Afficher des cartes machines.
|
|
||||||
|
|
||||||
Chaque carte doit montrer :
|
|
||||||
|
|
||||||
- code machine ;
|
|
||||||
- état courant ;
|
|
||||||
- couleur d'état ;
|
|
||||||
- OF en cours ;
|
|
||||||
- article ;
|
|
||||||
- moule ;
|
|
||||||
- cycle réel moyen ;
|
|
||||||
- cycle théorique ;
|
|
||||||
- quantité produite ;
|
|
||||||
- quantité rebutée ;
|
|
||||||
- avancement OF ;
|
|
||||||
- TRS du jour ;
|
|
||||||
- dernier arrêt.
|
|
||||||
|
|
||||||
Codes couleur :
|
|
||||||
|
|
||||||
| État | Couleur UI |
|
|
||||||
|---|---|
|
|
||||||
| production | vert |
|
|
||||||
| arret_non_qualifie | orange |
|
|
||||||
| arret_qualifie | rouge |
|
|
||||||
| reglage | bleu |
|
|
||||||
| hors_planning | gris |
|
|
||||||
|
|
||||||
### Détail machine
|
|
||||||
|
|
||||||
Afficher :
|
|
||||||
|
|
||||||
- état temps réel ;
|
|
||||||
- courbe des cycles récents ;
|
|
||||||
- historique des arrêts ;
|
|
||||||
- bouton qualifier arrêt ;
|
|
||||||
- bouton déclarer rebut ;
|
|
||||||
- OF en cours.
|
|
||||||
|
|
||||||
### Interface opérateur
|
|
||||||
|
|
||||||
L'interface doit être simple, utilisable sur tablette industrielle.
|
|
||||||
|
|
||||||
Boutons grands :
|
|
||||||
|
|
||||||
- Lancer OF ;
|
|
||||||
- Déclarer rebut ;
|
|
||||||
- Qualifier arrêt ;
|
|
||||||
- Appel maintenance optionnel ;
|
|
||||||
- Fin OF.
|
|
||||||
|
|
||||||
## Données de démonstration
|
|
||||||
|
|
||||||
Créer un seed avec :
|
|
||||||
|
|
||||||
Machines :
|
|
||||||
|
|
||||||
```text
|
|
||||||
INJ-01 — Haitian Mars II
|
|
||||||
INJ-02 — Engel e-victory
|
|
||||||
INJ-03 — Arburg Allrounder
|
|
||||||
```
|
|
||||||
|
|
||||||
Causes rebut :
|
|
||||||
|
|
||||||
- bavure ;
|
|
||||||
- manque_matiere ;
|
|
||||||
- brulure ;
|
|
||||||
- retassure ;
|
|
||||||
- deformation ;
|
|
||||||
- point_noir ;
|
|
||||||
- humidite ;
|
|
||||||
- couleur_non_conforme ;
|
|
||||||
- collage_moule ;
|
|
||||||
- casse_piece ;
|
|
||||||
- defaut_dimensionnel ;
|
|
||||||
- autre.
|
|
||||||
|
|
||||||
Créer au moins deux OF de démonstration.
|
|
||||||
|
|
||||||
## Exigences qualité
|
|
||||||
|
|
||||||
Le code doit être :
|
|
||||||
|
|
||||||
- clair ;
|
|
||||||
- typé autant que possible ;
|
|
||||||
- documenté ;
|
|
||||||
- modulaire ;
|
|
||||||
- prêt pour extension vers vraies gateways IoT ;
|
|
||||||
- sans dépendance à Euromap ni à un protocole propriétaire constructeur.
|
|
||||||
|
|
||||||
Ajouter :
|
|
||||||
|
|
||||||
- tests unitaires backend pour calcul OEE ;
|
|
||||||
- test de parsing événement MQTT ;
|
|
||||||
- README d'installation ;
|
|
||||||
- exemple de payload MQTT ;
|
|
||||||
- script seed database.
|
|
||||||
|
|
||||||
## Sécurité industrielle
|
|
||||||
|
|
||||||
Ajouter dans le README une section sécurité :
|
|
||||||
|
|
||||||
- ne jamais raccorder directement une sortie automate à une gateway ;
|
|
||||||
- utiliser relais d'interface, optocoupleurs ou modules d'entrées industrielles isolées ;
|
|
||||||
- valider tout câblage avec automaticien ou électricien industriel ;
|
|
||||||
- ne jamais modifier la logique automate machine pour le MVP ;
|
|
||||||
- l'acquisition doit rester passive et non intrusive ;
|
|
||||||
- le système MES ne doit jamais piloter la presse dans cette première version.
|
|
||||||
|
|
||||||
## Livrables attendus
|
|
||||||
|
|
||||||
Produire un repository complet avec :
|
|
||||||
|
|
||||||
```text
|
|
||||||
README.md
|
|
||||||
CONTRIBUTING.md optionnel
|
|
||||||
docker-compose.yml
|
|
||||||
/backend
|
|
||||||
/frontend
|
|
||||||
/edge-simulator
|
|
||||||
/database/init.sql
|
|
||||||
/database/seed.sql
|
|
||||||
```
|
|
||||||
|
|
||||||
Le README doit expliquer :
|
|
||||||
|
|
||||||
1. l'objectif du MVP ;
|
|
||||||
2. l'architecture ;
|
|
||||||
3. comment lancer le projet ;
|
|
||||||
4. comment simuler les machines ;
|
|
||||||
5. comment tester les endpoints ;
|
|
||||||
6. comment brancher plus tard une vraie gateway IoT ;
|
|
||||||
7. les limites du MVP.
|
|
||||||
|
|
||||||
## Critères d'acceptation
|
|
||||||
|
|
||||||
Le MVP est considéré terminé si :
|
|
||||||
|
|
||||||
- `docker compose up --build` lance tous les services ;
|
|
||||||
- le simulateur publie des cycles MQTT ;
|
|
||||||
- le backend reçoit et historise les cycles ;
|
|
||||||
- le dashboard affiche au moins 3 machines ;
|
|
||||||
- les cycles incrémentent la quantité produite ;
|
|
||||||
- un arrêt est créé automatiquement si absence de cycle ;
|
|
||||||
- un opérateur peut qualifier un arrêt ;
|
|
||||||
- un opérateur peut saisir un rebut ;
|
|
||||||
- le TRS/OEE journalier est calculé ;
|
|
||||||
- aucun composant ne dépend d'Euromap 63, 77 ou d'un protocole propriétaire constructeur.
|
|
||||||
|
|
||||||
## Important
|
|
||||||
|
|
||||||
Commencer par une version simple mais fonctionnelle. Ne pas développer de fonctionnalités avancées de pilotage machine. Le MVP doit uniquement superviser, historiser, calculer et afficher.
|
|
||||||
|
|
||||||
Ne pas implémenter de commande vers la presse. Le système est en lecture passive + saisie opérateur.
|
|
||||||
Reference in New Issue
Block a user