Files
mcp-wms-wiki/wiki/operations/robotics-project-lifecycle.md
arthur 9ce6ae37be lint(standard): corrections completes mode standard
- Em dashes: 1712 remplaces par tirets simples (86 fichiers + _index.md,
  en-tete section Limagrain conserve)
- Checklists: 24 '- [ ]' -> '- ☐' (3 pages operations, plus de todos Obsidian)
- Ancres: 33 reparees (slugs GitHub + ancres HTML <a id> reconnues),
  1 reciblee (manuel de reten)
- related: tenseflow -> tense-flow, pie -> mechanical-elements,
  group.md retire (doublon shipping)
- Registre: compteur global 122 -> 131 pages
- Rapport racine _lint_report.md mis a jour (scan v2 + re-scan final: 0 anomalie)
- Aucun fichier limagrain/ modifie (cloisonnement)
2026-07-20 13:01:21 +02:00

150 lines
8.1 KiB
Markdown

---
title: "Robotics Project Lifecycle (DTR, Planning, Tests, Roles)"
type: operation
sources:
- sources/archives/Organisation_projet_Robotique.md
- sources/archives/Planning_Installation_Miniload.md
- sources/archives/DTR_configuration_reseau_materiel.md
- sources/archives/Documents_utiles.md
- sources/archives/Plan_tests_stations.md
related:
- architecture/galileo-integration.md
- operations/galileo-simulation.md
- operations/galileo-troubleshooting.md
- operations/vm-installation.md
- operations/vm-network-routing.md
- operations/first-deployment.md
- concepts/mechanical-elements.md
- concepts/stations.md
last_compiled: "2026-04-17"
---
# Robotics Project Lifecycle (DTR, Planning, Tests, Roles)
## Overview
Robotics projects - installations with mechanized hardware (miniload, TK, conveyors, APS, AGV…) - require tighter coordination than pure-software projects because physical installation, electrical work and IT integration run in parallel. This page covers the organizational roles, reference documents, planning artifacts, and the station-test milestone that validates the WMS ↔ GALILEO configuration before go-live.
## 1. Project organization
A robotics project pulls in multiple Mecalux stakeholders:
- **Chef de chantier** - site supervisor for the mechanical build
- **Chef de projet IT** - IT lead (WMS + automation integration)
- **Responsable électricité** - electrical lead
- **Responsable de projet** - master coordinator who aligns the above, owns the schedule, and guarantees everyone has the right information at the right time
The **Responsable de projet** is the single point of escalation; without them, gaps between disciplines (e.g. the rack is installed but the DTR has not been validated) lead to slippage.
> The canonical organisational diagram for a robotics project is on [Confluence - Organisation d'un projet Robotique](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000434425874).
## 2. DTR - Document Technique de Référence
The **DTR (Document Technique de Référence)** lists every technical element required for an automated installation - hardware, IP addresses, services, accounts - along with the **responsibility split between Mecalux and the client**.
The DTR answers "who provides what and by when":
- WMS server specs and OS
- Network segments (WMS LAN, PLC LAN, wireless for RF terminals)
- IP allocations (WMS, Gateway, GALILEO PLCs, RF terminals, printers, scanners)
- Services (Active Directory, DNS, NTP, SMTP)
- Physical access and ports opened between segments
The DTR template lives on [Confluence - DTR configuration réseau et matériel](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000562515980) as a table format. Fill a copy per project; track outstanding client deliverables in Jira.
## 3. Planning (Miniload installation)
Two reference plannings used on every miniload project:
1. **Global installation planning** - overview of all phases (civil works → rack install → electrical → PLC commissioning → WMS integration → tests → go-live)
2. **IT ROB planning** - the slice owned by the IT Robotics team (VM install, WMS deploy, EasyS configuration, Gateway, station tests, Hypercare)
Both plannings live as Gantt images on [Confluence - Planning Installation Miniload](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000567955477). Copy the Gantt at project kick-off and adjust dates to site reality.
## 4. Reference documentation
| Document | Purpose | Location |
|----------|---------|----------|
| **Control_Communications_Interface_EN_GB.pdf** | All station types, event types, PIE flags | [MSSCC Automation docs](https://msscc.mecalux.com/documentation/Automation/master/ES/Documents/GalileoAWS/Control_Communications_Interface_EN_GB.pdf) |
| **EasyWMSGateway_ControlInterface_EN.pdf** | Frame structure (low-level - used when a frame translation looks wrong) | [MSSCC services docs](https://msscc.mecalux.com/documentation/documentation/master/ES/docs_downloads/services/docs/EasyWMSGateway_ControlInterface_EN.pdf) |
| **Stations index** | Station-specific behaviours and quirks | [MSSCC Stations index](https://msscc.mecalux.com/documentation/documentation/master/EN/areas/layout/stations/index.md) |
Use them as the source of truth when writing the functional spec / interface document with GALILEO.
## 5. Station test milestone
Before the first real container enters the installation, run the **Plan de tests des stations** to confirm that EasyWMS and GALILEO agree on every station, route, container type and height type.
### 5.1 Container type / height type sync
Every support entering a TK must pass through a **PIE** first, which calibrates the support. GALILEO reports to the WMS:
- Barcode read
- **Container Type** (PLC Container Type)
- **Height Type** (PLC Height Type)
Both types are defined in EasyS via the **PLC Types** menu.
> ⚠️ On miniloads, container type and height are usually **coupled**. If GALILEO reads `PLCHeightType = 1`, the `PLCType` must also be `1`. Explicit coupling must be recorded in the interface document and cross-checked on site.
### 5.2 Station audit query
Run on the **writing** database to extract the WMS view of GALILEO stations and their coordinates:
```csharp
Context.StationRoutes.Where(sr => sr.Manager.ToString() == "Galileo")
.Select(sr => new {
StationType = sr.StationTo.Type,
StationNumber = sr.StationTo.Number,
StationCode = sr.StationTo.Code,
StationTypeName = sr.StationTo.Type.ToString(),
X = sr.StationTo.RealLocations.Any() && sr.StationTo.RealLocations.FirstOrDefault().LogicalCoordinate != null
? sr.StationTo.RealLocations.FirstOrDefault().LogicalCoordinate.X : 0,
Y = sr.StationTo.RealLocations.Any() && sr.StationTo.RealLocations.FirstOrDefault().LogicalCoordinate != null
? sr.StationTo.RealLocations.FirstOrDefault().LogicalCoordinate.Y : 0,
StationSide = sr.StationTo.RealLocations.Any() && sr.StationTo.RealLocations.FirstOrDefault().LogicalCoordinate != null
? sr.StationTo.RealLocations.FirstOrDefault().LogicalCoordinate.Side : 0,
AisleNumber = sr.StationTo.AisleNumber
})
// union with StationFrom - see full query on Confluence
.OrderBy(sr => sr.StationType)
.ThenBy(sr => sr.StationNumber)
```
Compare the result with the GALILEO program (`C:\<NomDuClient>\Programme\<installation>.mgp`) line by line.
### 5.3 "Full" route checks
GALILEO must be able to push these routes as **status 3 = Full** (otherwise recirculation logic cannot work):
| Source type | Destination type |
|-------------|------------------|
| CME | TE (ME) |
| PKE | PK |
| ET | PS |
Verify during simulation by temporarily saturating each route and confirming the Gateway log shows the `3` status.
## 6. Pre-go-live checklist
Consolidated checklist merging what each phase must deliver:
- ☐ DTR signed by client and Mecalux (hardware, IPs, services provisioned)
- ☐ VM installed, joined to the domain, reachable via VPN (see [VM Installation](vm-installation.md) / [VM Network Routing](vm-network-routing.md))
- ☐ EasyWMS deployed (see [First Deployment](first-deployment.md))
- ☐ EasyS layout matches the execution plan (racks, stations, routes, PLC Types)
- ☐ Gateway installed, `tenantCode` + `TokenUser` configured, port 3000 open
- ☐ Station test query matches GALILEO `.mgp` station list
- ☐ PLC Container Type / PLC Height Type coupling validated in simulation
- ☐ "Full" route checks passed (CME→TE, PKE→PK, ET→PS)
- ☐ End-to-end flows validated in EasyS (PIE → Miniload → PK → PS)
- ☐ Reject route + floor virtual route configured (no lost container)
- ☐ Automation Dashboard wired up with the client's monitoring (see [Automation Dashboard](../modules/automation-dashboard.md))
## Related
- [GALILEO Integration](../architecture/galileo-integration.md) - protocol reference
- [Galileo Simulation](galileo-simulation.md) - EasyS bring-up, PIE injection, station sync
- [Galileo Troubleshooting](galileo-troubleshooting.md) - log analysis, faults
- [VM Installation](vm-installation.md) · [VM Network Routing](vm-network-routing.md) · [First Deployment](first-deployment.md)
- [Mechanical Elements](../concepts/mechanical-elements.md) · [Stations & Routes](../concepts/stations.md)