--- 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:\\Programme\.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)