Stage : Développeur Backend Industriel — Alstef Group

Dans le cadre de mon Master 2 Informatique (parcours SAIM) à l’Université de Bretagne-Sud, j’ai réalisé un stage de fin d’études de 6 mois au sein du pôle Intégration Système d’Alstef Mobile Robotique (Alstef Group), situé à Mordelles près de Rennes.

Ma mission principale a porté sur la conception et le développement en Java (Spring Boot) d’un module de simulation d’automates industriels (PLC) communiquant via le protocole OPC UA, directement intégré à la plateforme logicielle de supervision de flottes de véhicules à guidage automatique (AGV) nommée OPAL FLEET.

1. Contexte & Problématique

L’Intralogistique automatisée & la suite OPAL

Alstef Group est un acteur majeur mondial de la conception et de l’intégration de systèmes intralogistiques automatisés pour l’industrie et les plateformes aéroportuaires. Au cœur de ces installations, des véhicules à guidage automatique (AGV / AMR) déplacent des charges lourdes (palettes, conteneurs, pièces industrielles) entre des lignes de production, des zones de stockage et des postes d’expédition.

Pour piloter ces flottes, Alstef a développé la suite logicielle OPAL, successeur moderne et modulaire de l’ancien monolithe AGV Manager. Basée sur une architecture microservices en Java Spring Boot, des API REST, une messagerie asynchrone AMQP (RabbitMQ) et des interfaces web réactives, la suite OPAL regroupe plusieurs modules métiers :

• OPAL STORE : Gestion des emplacements et des stocks.
• OPAL FLEET : Supervision temps réel, calcul de trajectoires et attribution des missions aux AGV.
• OPAL ANALYTICS & NOTIFY : Analyse de performance et remontée d’alertes.

La problématique : L’absence de simulation des automates physiques

Si OPAL FLEET disposait déjà d’outils avancés pour simuler le comportement des véhicules sur un circuit virtuel, aucun outil ne permettait de simuler le comportement des automates industriels (PLC) en interaction avec la supervision.

Dans un entrepôt automatisé réel, les AGV interagissent en permanence avec des équipements physiques pilotés par des automates (portes automatiques, SAS de sécurité, convoyeurs, barrières, alarmes incendie).

En l’absence de matériel physique lors des phases de développement ou de configuration en laboratoire, un AGV virtuel restait inévitablement bloqué devant une porte fermée simulée ou un poste inactif. Cela imposait de décaler la validation des flux complexes à la toute fin des projets, lors de l’intégration sur le site du client, générant des risques importants de retard, de régressions et de surcoûts financiers.

Pourquoi la simulation d’automates est-elle stratégique ?
En reproduisant fidèlement les échanges entre la supervision et des automates virtuels via le standard OPC UA, le simulateur offre un environnement de test totalement virtuel, autonome et maîtrisé. Il permet d’anticiper la validation des flux logistiques dès les premières phases du projet, sans dépendre du matériel physique client.

2. Architecture Globale du Système

Le module de simulation d’automates s’intègre dans l’architecture microservices d’OPAL FLEET. Le schéma ci-dessous illustre la circulation des données entre la couche d’interface web, la logique métier du simulateur, les connecteurs réseau et le serveur OPC UA :

flowchart TD
    subgraph ClientUI["1. Interface Web & Supervision (IHM)"]
        WebControl["OPAL Controle (Web Components / TypeScript)"]
        FeatureApi["API Feature Flagging & Statut SSE"]
    end

    subgraph CoreSim["2. Core Engine Simulation (Java / Spring Boot)"]
        SimulationServices["SimulationServices"]
        VirtualPLCEngine["Moteur VirtualPLC"]
        FlowEngine["Moteur de Flux & Scheduling"]
        JPAStore[("PostgreSQL / Liquibase (Spring Data JPA)")]
    end

    subgraph OPCNetwork["3. Couche Communication OPC UA"]
        ConnectorService["OpcUaConnectorService"]
        EclipseMilo["Client Eclipse Milo (OPC UA Stack)"]
        TaniServer["Tani Server / Applicom (Serveur OPC UA/DA)"]
        PLCOPCModule["Module Historique PLCOPC"]
    end

    WebControl <-->|"APIs REST / HTTP"| SimulationServices
    FeatureApi <-->|"Flux temps reel"| WebControl

    SimulationServices --> VirtualPLCEngine
    SimulationServices --> FlowEngine
    VirtualPLCEngine <--> JPAStore

    VirtualPLCEngine <--> ConnectorService
    ConnectorService --> EclipseMilo
    EclipseMilo <-->|"Protocole OPC UA"| TaniServer
    TaniServer <-->|"OPC DA / DCOM"| PLCOPCModule

Les 3 briques clés de l’architecture :

1. Couche de communication OPC UA (OpcUaConnectorService) : Encapsule la pile open source Eclipse Milo. Elle gère l’ouverture des connexions sécurisées, l’exploration de l’espace d’adressage (Address Space), la souscription aux événements et l’écriture synchrone/asynchrone sur les registres d’automates.
2. Moteur Métier & Modélisation (VirtualPLC) : Architecture modulaire basée sur une classe abstraite VirtualPLC déclinée en plusieurs modèles d’automates standards (portes, accès aux emplacements, requêtes d’évacuation/approvisionnement, alarme incendie).
3. Persistance, Sécurité & API Web : Stockage relationnel versionné via Liquibase et Spring Data JPA, accès sécurisé aux endpoints via Keycloak (OAuth2/OIDC), et rafraîchissement réactif de l’IHM via Server-Sent Events (SSE).

3. Protocole OPC UA & Choix Technologiques

Transition d’OPC DA vers OPC UA

Historiquement, le module PLCOPC d’Alstef s’appuyait sur le protocole OPC DA Classic (Data Access). Créé en 1996, ce protocole propriétaire repose exclusivement sur la technologie DCOM (Distributed COM) de Microsoft, ce qui engendre des vulnérabilités de sécurité, une forte dépendance à Windows et un coût de maintenance élevé.

Le passage à OPC UA (Unified Architecture) apporte des avancées majeures :

• Indépendance vis-à-vis de la plateforme (fonctionne sous Linux, conteneurs Docker, etc.).
• Modèle de données orienté objet basé sur des nœuds (Nodes), espaces de noms (Namespaces) et identifiants uniques (NodeId).
• Sécurité intégrée nativement (chiffrement TLS, certificats X.509, authentification par jetons).

Étude comparative des bibliothèques Java OPC UA

Pour intégrer un client OPC UA en Java dans OPAL FLEET, trois solutions principales ont été évaluées :

Le choix s’est porté sur Eclipse Milo, la référence open source dans l’écosystème Java. Son architecture découplée (client/serveur) et sa conformité avec la licence EPL-2.0 permettent une intégration transparente dans les produits industriels d’Alstef.

Développement Frontend (TypeScript, Web Components & Client Léger)

Synoptique de l’interface de simulation et panneau de contrôle de la supervision OPAL.

L’un des changements majeurs de la suite OPAL réside dans l’abandon du client lourd Java historique d’AGV Manager au profit d’une application web réactive (client léger) exécutée directement sur navigateur web (navigateurs basés sur Chromium).

J’ai participé au développement des composants frontend dédiés à la simulation au sein de l’interface OPAL Contrôle :

1. Intégration d’une bibliothèque d’IHM (simulation_lib) : Développement en TypeScript et Web Components des panneaux de contrôle interactifs permettant de sélectionner les automates à simuler et de basculer l’état de la simulation en temps réel.
2. Propagation réactive via SSE (Server-Sent Events) : Mise en place d’un canal unilatéral HTTP persistant entre le serveur backend et l’IHM web pour pousser la position des véhicules et l’état des automates en temps réel sans surcoût de polling.
3. API de Feature Flagging & Détection dynamique : Développement d’un mécanisme de configuration dynamique. Lors de l’authentification, le client web interroge une API backend dédiée pour identifier les modules activés sur le serveur. Seuls les composants d’interface des services actifs sont instanciés dans le navigateur, évitant la surcharge mémoire et l’émission de requêtes HTTP vouées à échouer (404) sur les installations hors simulation.

5. Validation, Tests & Déploiement Terrain

Stratégie de Qualité & CI/CD Pipeline

Pour garantir un niveau d’exigence industriel, le développement du simulateur a suivi un pipeline strict d’intégration continue :

Chaîne d’outils et processus de validation logicielle appliqués sur la suite OPAL.

• Tests Unitaires & Mocks : Écrits en Java avec JUnit 5 et Mockito pour valider les machines à états des automates sans dépendance réseau.
• Analyse Statique : Conformité aux normes de codage d’Alstef via Checkstyle et détection de bugs potentiels par SpotBugs.
• Relecture de Code : Validation obligatoire par les pairs via Merge Requests sur GitLab avant toute intégration dans la branche principale.

Tests d’endurance en conditions réelles sur piste d’essais

La validation finale du simulateur a été réalisée en conditions réelles sur la piste d’essais d’Alstef Mobile Robotique. En raccordant la plateforme de simulation aux AGV physiques évoluant sur la piste d’essai, il a été possible de simuler le passage répété de véhicules réels au travers de portes et de zones de transfert virtuellement pilotées par le module OPC UA.

6. Bilan & Évolutions Futures

Ce stage au sein de l’équipe Intégration Système a permis de livrer un module de simulation d’automates opérationnel, éprouvé et directement utilisable par les ingénieurs d’intégration pour sécuriser les déploiements chez les clients d’Alstef.

Perspectives d’évolution pour le système :

• Générateur visuel de scénarios : Création d’une interface Drag & Drop pour composer des séquences de panne d’automates.
• Support d’OPC UA PubSub : Intégration de la spécification Part 14 d’OPC UA pour la transmission à haute fréquence via MQTT/UDP.
• Injection d’anomalies réseau : Simulation de pertes de paquets et de déconnexions intempestives pour éprouver la résilience de la supervision.