mcp-wms-wiki/wiki/sources/archives/Présentation Module AGV.md

---
créé: 15/05/2026 09h53
màj: 15/05/2026 09h53
---
## 1. Introduction

### 1.1 Qu'est-ce qu'un AGV en logistique ?

Un AGV (Automated Guided Vehicle) est un véhicule de manutention autonome utilisé dans les entrepôts et sites industriels pour transporter des charges (palettes, bacs, rolls) sans intervention humaine. Il se déplace le long de trajets prédéfinis ou calculés dynamiquement, guidé selon la technologie par des bandes magnétiques, des réflecteurs laser, une cartographie embarquée ou une combinaison de ces systèmes.

Les AGV remplacent les chariots élévateurs conduits par des opérateurs sur les trajets répétitifs à faible valeur ajoutée : transferts entre zones de réception et de stockage, alimentation de postes de picking, acheminement vers les quais d'expédition. Leur intérêt principal est le fonctionnement continu (24h/24 hors recharges), la régularité du débit et la suppression des risques liés à la conduite humaine dans les allées de circulation.

Un AGV ne travaille pas seul : il est piloté par un logiciel de gestion de flotte (fleet manager) qui répartit les missions entre les véhicules disponibles, optimise les trajets et gère les priorités. C'est ce fleet manager qui fait l'interface entre le système de gestion d'entrepôt (WMS) et les véhicules physiques. Certains AGV ont un mode manuel, un opérateur peut reprendre le contrôle et s'en servir comme un chariot classique.

### 1.2 Qu'est-ce qu'un AGV dans le contexte EasyWMS ?

Dans EasyWMS, le module AGV est un module optionnel qui permet d'intégrer une flotte d'AGV dans les flux logistiques gérés par le WMS. Il ne pilote pas directement les véhicules - il génère des ordres de transport et les transmet au fleet manager externe via un protocole d'échange par tables de base de données.

Concrètement, quand EasyWMS décide qu'un support doit être déplacé (par exemple, une palette réceptionnée doit aller vers un convoyeur d'entrée de magasin automatique), il crée une tâche AGV. Cette tâche est sérialisée dans des tables d'échange (PostgreSQL), lue par le fleet manager qui l'assigne à un véhicule, et le module suit l'exécution phase par phase jusqu'à confirmation de la dépose.

Le module s'intègre dans l'écosystème EasyWMS au même titre que les autres systèmes de transport automatisé (convoyeurs, transstockeurs, Pallet Shuttle). La station AGV est un type de station (type 65) qui se configure dans EasyS et qui participe au système de routes entre stations. Les tâches AGV apparaissent dans les vues de monitoring standard et sont supervisables depuis l'interface PC.

Un point important : le module AGV est **agnostique vis-à-vis du constructeur** du fleet manager. Le protocole d'échange repose sur 5 tables intermédiaires dans une base PostgreSQL. Tout fleet manager capable de lire et écrire dans ces tables (directement ou via un middleware) peut être intégré. Cette architecture a été utilisée avec des systèmes Mecalux, Rocla, et plus récemment Still iGO.

### 1.3 À qui s'adresse cette documentation

Cette documentation s'adresse aux consultants fonctionnels, chefs de projet et intégrateurs EasyWMS qui doivent comprendre le module AGV pour le dimensionner, le configurer ou le présenter à un client. Elle couvre le fonctionnement du module, ses capacités, son architecture et ses cas d'usage, sans entrer dans le détail de l'installation technique (couverte par la documentation d'installation dédiée : [https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3001775390721](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3001775390721) ).

---

## 2. À quoi sert le module AGV ?

### 2.1 Problèmes adressés

Dans un entrepôt semi-automatisé ou automatisé, certains trajets ne sont pas couverts par les convoyeurs ou les transstockeurs. Un exemple typique : le transport entre une zone de réception au sol (images de quai) et le convoyeur d'entrée du magasin automatique. Ces trajets sont répétitifs, prévisibles et à faible valeur ajoutée, mais ils mobilisent des caristes à temps plein.

Le module AGV permet de confier ces trajets à une flotte de véhicules autonomes, pilotée par le WMS. Le WMS décide quoi déplacer, quand et où - les AGV exécutent.

### 2.2 Cas d'usage typiques

Les mouvements AGV dans EasyWMS couvrent tous les types de transport interne :

- **Réception → stockage automatique** : transport des palettes depuis les images de quai vers les convoyeurs d'entrée (PIE) du magasin automatique. C'est le cas d'usage le plus courant en réception production.
    
- **Réception → poste de picking** : transport des palettes fournisseur/intersite depuis les images de quai vers les postes de travail (PK) pour contrôle et traitement avant mise en stock.
    
- **Stockage → expédition** : transport depuis les zones de stockage ou les postes de sortie vers les quais de chargement.
    
- **Transferts inter-zones** : déplacements entre emplacements de stockage conventionnels (réapprovisionnement, rééquilibrage de stock, regroupement).
    
- **Transport de Pallet Shuttle** : déplacement des navettes autonomes entre les canaux de racks compacts, avec accroche électromagnétique.
    

### 2.3 Bénéfices clés

- **Débit continu** : les AGV fonctionnent en continu, sans pause ni rotation d'équipe (hors cycles de recharge).
    
- **Fiabilité et répétabilité** : pas d'erreur de destination, pas de palette oubliée en chemin.
    
- **Traçabilité complète** : chaque ordre de transport est tracé phase par phase dans le WMS, avec horodatage et identifiant véhicule.
    
- **Supervision centralisée** : toutes les tâches AGV sont visibles dans les vues de monitoring EasyWMS, avec les messages d'échange entrants et sortants.
    
- **Fallback opérateur** : si un AGV est en panne ou si la flotte est saturée, les tâches AGV peuvent être exécutées manuellement par un opérateur via TRF (menu "Mouvements AGV").
    

---

## 3. Architecture et principe de communication

### 3.1 Schéma d'ensemble

Le module AGV repose sur une architecture à 4 composants qui communiquent via une base de données intermédiaire :

`┌───────────────────────┐ │       EasyWMS       │ │  (workflows + module│ │   AGV)         │ └──────────┬────────────┘            │ workflows AGV            ▼ ┌───────────────────────┐ │   Gateway AGV       │ │   (service Windows) │ │   workflows ↔ tables│ └──────────┬────────────┘            │ DBLink Oracle → PostgreSQL            ▼ ┌───────────────────────┐ │  Base intermédiaire │ │  PostgreSQL         │ │  5 tables d'échange │ └──────────┬────────────┘            │ lecture/écriture directe            │ ou via middleware            ▼ ┌───────────────────────┐ │  Fleet manager      │ │  (iGO, Rocla, etc.) │ └───────────────────────┘`

Le principe fondamental : EasyWMS et le fleet manager **ne communiquent jamais directement**. Toute communication passe par les 5 tables de la base intermédiaire. Cela découple complètement le WMS du constructeur AGV.

### 3.2 Les tables d'échange

La base PostgreSQL intermédiaire contient 5 tables fonctionnelles :

|   |   |   |
|---|---|---|
|Table|Direction|Rôle|
|agv_outputqueue|WMS → Fleet manager|File de sortie - les ordres émis par le WMS (création, modification, annulation)|
|agv_eag|WMS → Fleet manager|Détail des ordres - opération demandée (Create/Update/Delete), paramètres du transport|
|agv_inputqueue|Fleet manager → WMS|File d'entrée - les réponses et événements du fleet manager|
|agv_age|Fleet manager → WMS|Événements de transport - changements de phase (accepté, véhicule assigné, chargé, déchargé, annulé)|
|agv_ags|Fleet manager → WMS|Événements de statut véhicule - état des AGV (prêt, en panne, en charge, batterie faible)|

La Gateway AGV (côté WMS) écrit dans agv_outputqueue / agv_eag et lit agv_inputqueue / agv_age / agv_ags. Le fleet manager (ou son middleware) fait l'inverse.

### 3.3 Le cycle de vie d'un ordre de transport

Chaque ordre de transport suit un protocole en phases numérotées. Le flux nominal :

|   |   |   |
|---|---|---|
|Phase|Direction|Signification|
|-|WMS → Fleet manager|Création de l'ordre de transport|
|00|Fleet manager → WMS|Ordre accepté|
|03|Fleet manager → WMS|Véhicule assigné|
|04|Fleet manager → WMS|Demande d'autorisation de chargement (si CanPick = false)|
|-|WMS → Fleet manager|Autorisation de chargement accordée|
|06|Fleet manager → WMS|Chargement confirmé|
|08|Fleet manager → WMS|Demande d'autorisation de déchargement (si CanDrop = false)|
|-|WMS → Fleet manager|Autorisation de déchargement accordée|
|10|Fleet manager → WMS|Déchargement confirmé - ordre terminé|
|255|Fleet manager → WMS|Ordre annulé par le fleet manager|

Les phases 04 et 08 (demandes d'autorisation) ne sont émises que si les flags CanPick / CanDrop sont configurés à false sur la tâche. Cela permet au WMS de garder le contrôle sur le moment exact du chargement ou du déchargement (par exemple, attendre qu'un emplacement se libère avant d'autoriser la dépose).

---

## 4. Composants du module

### 4.1 Station AGV (type 65)

Dans EasyWMS, chaque AGV physique est représenté par une station de type 65. Ces stations sont créées dans EasyS au sein d'un **AGV equipment group** (groupe d'équipements AGV). Le groupe représente la flotte ; chaque station du groupe représente un véhicule.

Les routes entre la station AGV et les emplacements autorisés pour les mouvements doivent être déclarées dans EasyS. Les types d'emplacements compatibles avec les mouvements AGV sont : rack conventionnel, compact (simple/multi), dynamique, pushback, cantilever, stage, dock, PIE, ET. Chaque emplacement participant à un mouvement AGV doit avoir une allée de chargement manuel configurée.

### 4.2 Gateway AGV

La Gateway AGV est un service Windows fourni par Mecalux. Elle fait le pont entre les workflows internes d'EasyWMS et les tables d'échange PostgreSQL. Elle est responsable de :

- Sérialiser les tâches AGV créées par les workflows dans les tables agv_outputqueue / agv_eag
    
- Lire les événements entrants (agv_inputqueue / agv_age / agv_ags) et les injecter dans le moteur de workflows
    
- Gérer les cycles de polling (fréquence configurable, typiquement 1 seconde)
    

La Gateway crée automatiquement les tables et séquences PostgreSQL à son premier démarrage.

### 4.3 Base intermédiaire PostgreSQL

La base PostgreSQL héberge les 5 tables d'échange plus les séquences associées et une table de suivi de migration. Elle est accédée par la Gateway via un DBLink Oracle (composant dg4odbc) et par le fleet manager directement ou via un middleware.

### 4.4 DBLink Oracle → PostgreSQL

EasyWMS tourne sur Oracle. Pour que les workflows puissent lire et écrire dans les tables PostgreSQL, un DBLink est configuré entre Oracle et PostgreSQL via le composant dg4odbc (Database Gateway for ODBC). Des synonyms Oracle sont créés dans le schéma db_read pour que les tables PostgreSQL soient accessibles comme des tables locales.

Ce DBLink est le composant le plus délicat de l'installation - il touche 5 fichiers de configuration Oracle et exige une cohérence stricte sur les noms et la casse. Les détails sont couverts dans la documentation d'installation.

---

## 5. Capacités fonctionnelles

### 5.1 Types de mouvements supportés

Le module AGV gère deux types de charge :

- **support** (LoadType = 0) : le cas standard - transport d'une palette, d'un bac ou de tout support identifié dans le WMS.
    
- **Pallet Shuttle** (LoadType = 1) : transport d'une navette Pallet Shuttle entre deux canaux de rack compact. L'AGV utilise un électroaimant pour accrocher/décrocher la navette.
    

Les mouvements possibles couvrent toutes les combinaisons source/destination entre les types d'emplacements compatibles : sol → convoyeur, convoyeur → stockage, stockage → quai, stockage → stockage, etc.

### 5.2 Gestion des priorités

Chaque tâche AGV a un niveau de priorité. Les tâches les plus urgentes sont dispatchées en premier par le fleet manager. La priorité peut être modifiée tant qu'un véhicule n'a pas encore été assigné (avant la phase 03). Après assignation, la modification de priorité génère une erreur de configuration (code 1011).

### 5.3 Autorisations de chargement et déchargement (CanPick / CanDrop)

Les flags CanPick et CanDrop sur chaque tâche contrôlent si le fleet manager doit demander une autorisation au WMS avant de charger ou décharger :

- CanPick = true : l'AGV charge directement sans attendre
    
- CanPick = false : l'AGV envoie une demande (phase 04), attend l'autorisation du WMS, puis charge (phase 06)
    

Même logique pour CanDrop avec les phases 08 / 10. Ce mécanisme permet au WMS de synchroniser les mouvements AGV avec l'état réel de l'entrepôt (emplacement libre, convoyeur disponible, etc.).

### 5.4 Annulation et relocalisation en cours d'exécution

Une tâche AGV peut être annulée depuis la vue Tâches du WMS. Deux cas de figure :

- **L'AGV n'a pas encore chargé** : l'ordre est retiré de la file et le fleet manager est notifié. Pas de complication.
    
- **L'AGV a déjà chargé le support** : le WMS cherche un emplacement de rangement valide en appliquant les stratégies configurées. Si un emplacement est trouvé, l'AGV est redirigé. Sinon, l'opérateur est notifié pour intervention manuelle.
    

### 5.5 Fallback TRF

Quand les AGV sont indisponibles (panne, maintenance, saturation), les opérateurs peuvent exécuter les tâches AGV manuellement depuis le TRF via le menu "Mouvements AGV". Le processus suit le flux de picking standard : sélection de la tâche, confirmation du support à l'emplacement de chargement, confirmation de l'emplacement de déchargement.

Les anomalies possibles pendant l'exécution TRF :

- **Au chargement** : support non trouvé (→ Lost & Found), marquage pour comptage
    
- **Au déchargement** : marquage pour comptage, marquage emplacement plein, changement de destination
    

---

## 6. Monitoring et supervision

### 6.1 Vues disponibles

Le module AGV ajoute 5 vues dans le menu AGV de l'interface PC :

|   |   |
|---|---|
|Vue|Contenu|
|Stations AGV|Liste des AGV enregistrés avec leur statut de contrôle (disponible, en panne, en charge, etc.)|
|Tâches AGV|Tous les ordres de transport avec statut, priorité, emplacements de chargement/déchargement|
|Messages Export|Messages envoyés par le WMS au fleet manager (création, modification, annulation, autorisation)|
|Messages Import|Messages reçus du fleet manager (phases 00/03/04/06/08/10/255)|
|Messages Statut|Mises à jour de statut des AGV : Prêt (vert), En panne (rouge), En attente (gris), Batterie faible (jaune), En charge (bleu)|

### 6.2 Gestion des erreurs

Les erreurs sont classées en trois catégories :

**Erreurs de configuration** (codes 1001-1014) : station de chargement/déchargement incorrecte, identifiant d'ordre en doublon, type d'opération invalide, modification de destination après assignation du véhicule, etc. Ces erreurs indiquent un problème dans la configuration des routes ou des stations.

**Erreurs d'exécution** (codes 2003-2005) : erreur d'extraction (pas de support à l'emplacement de prise), erreur de rangement (destination occupée), support non conforme, pas de relocalisation trouvée. Le comportement dépend du type d'emplacement :

- Sur rack conventionnel ou APS : tâche annulée, emplacement verrouillé avec un type de verrou "Mark for review"
    
- Sur autre type de stockage : tâche annulée, emplacement verrouillé avec le type de verrou dédié "For AGV"
    
- Sur emplacement non-stockage (stage, dock) : tâche **non** annulée, AGV en attente d'intervention manuelle
    

**Erreurs de communication** (codes 2500-2503) : échec d'envoi de l'ordre, de la mise à jour de priorité, de l'annulation ou du changement de destination. Indiquent un problème réseau ou un dysfonctionnement du fleet manager.

Un type de verrou d'emplacement dédié avec le flag "For AGV" doit être créé dans la configuration (Masters > Types de verrous > Verrous d'emplacement). Un seul type de verrou AGV peut exister par entrepôt.

### 6.3 Notifications

Toutes les erreurs AGV sont regroupées sous le groupe de notification **AGV**. Niveau de sévérité : Erreur pour toutes. Les profils abonnables sont : SuperAdmin, Administrateurs, Managers.

---

## 7. Intégration avec un fleet manager externe - exemple iGO (STILL)

### 7.1 Contexte

Le protocole standard du module AGV repose sur les tables d'échange PostgreSQL. Certains fleet managers ne lisent/écrivent pas directement dans ces tables et exposent à la place une API REST. C'est le cas de **iGO easy** (STILL / KION Group), utilisé chez Limagrain avec des gerbeurs Still EXV CB iGo.

### 7.2 Différences avec le protocole standard

|   |   |   |
|---|---|---|
|Aspect|Standard EasyWMS|iGO (STILL)|
|Communication|Tables d'échange SQL directes|API REST HTTPS (port 7002, TLS 1.2)|
|Authentification|Credentials base de données|Header X-API-Key|
|Routing|Routes entre stations dans EasyS|Géré en interne par iGO (invisible côté WMS)|
|Autorisation CanPick/CanDrop|Phases 04/08 explicites|Via le mécanisme de "Group" et décision tardive|
|Annulation après chargement|Relocalisation automatique|Impossible après l'état "Retrieved" - intervention manuelle|

### 7.3 Architecture à 4 composants avec middleware

Pour intégrer iGO sans modifier les workflows EasyWMS ni la Gateway AGV, un **middleware** (pool IIS C# [ASP.NET](http://ASP.NET) Core .NET 8) est ajouté entre les tables d'échange et l'API iGO :

`EasyWMS ─► Gateway AGV ─► Tables AGV_* ─► Middleware IIS ─► API iGO (HTTPS)                                         ◄─              ◄─ (webhooks)`

Le middleware assure deux fonctions :

- **Pompe sortante** : poll régulier sur agv_outputqueue, lecture des ordres dans agv_eag, traduction en appels REST vers l'API iGO
    
- **Webhook receiver** : réception des callbacks iGO (changements d'état des transports et véhicules), traduction en lignes dans agv_inputqueue / agv_age / agv_ags
    

L'avantage de cette architecture : **aucun composant EasyWMS existant n'est modifié**. Les workflows, la Gateway, les vues de monitoring et le fallback TRF fonctionnent exactement comme avec le protocole standard.

### 7.4 Mapping des concepts

|   |   |
|---|---|
|EasyWMS|iGO (STILL)|
|Tâche AGV (AgvTask)|Transport|
|Station AGV (type 65)|Vehicle|
|support / LPN|Load|
|Emplacement (Location)|Location|
|Zone de travail (WorkingZone)|Group|
|Type de support|LoadType|

Le concept de **Group** côté iGO permet la "décision tardive" : le WMS crée un transport vers un groupe de destinations, et iGO demande la destination finale quand l'AGV arrive au point de décision. Cela reproduit le comportement des phases 04/08 du standard, mais via un mécanisme différent.

---

## 8. Prérequis et périmètre d'installation

### 8.1 Prérequis techniques

|   |   |
|---|---|
|Élément|Exigence|
|Binaires EasyWMS|Version minimum 18.10.22154.1|
|PostgreSQL|Version >= 14|
|Driver ODBC PostgreSQL|psqlodbc x64|
|Oracle|DBLink dg4odbc configuré sur le schéma db_read|
|Réseau|Port PostgreSQL ouvert (5432 par défaut, 5433 si PostgreSQL 18+)|

### 8.2 Composants à installer

1. PostgreSQL + base AGV + utilisateurs
    
2. Driver ODBC PostgreSQL + System DSN
    
3. DBLink Oracle → PostgreSQL (dg4odbc, tnsnames.ora, listener.ora, initPostgreSQL35W.ora)
    
4. Gateway AGV (service Windows) + configuration
    
5. Module AGV dans EasyWMS (deploy via response.xml)
    

La procédure détaillée étape par étape est couverte dans la [documentation d'installation du module AGV](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3001775390721).

---

## 9. Glossaire

|   |   |
|---|---|
|Terme|Définition|
|AGV|Automated Guided Vehicle - véhicule de manutention autonome|
|ASRS|Automated Storage and Retrieval System - système de stockage/déstockage automatisé (transstockeurs)|
|CanPick / CanDrop|Flags indiquant si le fleet manager doit demander une autorisation au WMS avant chargement/déchargement|
|DBLink|Lien de base de données Oracle permettant d'accéder à des tables distantes (ici PostgreSQL via dg4odbc)|
|dg4odbc|Database Gateway for ODBC - composant Oracle pour les connexions vers des bases non-Oracle|
|EasyS|Outil de simulation 3D et de configuration Mecalux pour la topologie d'entrepôt|
|Fleet manager|Logiciel de gestion de flotte AGV (iGO, Rocla, etc.)|
|Gateway AGV|Service Windows Mecalux faisant le pont entre les workflows EasyWMS et les tables d'échange PostgreSQL|
|LPN|License Plate Number - identifiant unique d'un support/support|
|PIE|Poste d'Identification d'Entrées - station de contrôle dimensionnel et d'identification à l'entrée du magasin automatique|
|PK|Poste de picking - station de préparation de commandes|
|TRF|Terminal Radio Fréquence - terminal portable utilisé par les opérateurs pour les tâches guidées|