Brevet FR3147032A1 — publié le 20240927

L’invention concerne un dispositif de pilotage d’un centre logistique, exécutant un logiciel de gestion d’entrepôt « WCS », et comprenant : - une interface homme machine « IHM » exécutant un logiciel de programmation du WCS : - le logiciel de programmation étant configuré pour concevoir un organigramme de programmation du WCS, dit « logigramme (1) » ; - le logiciel de programmation comprenant une bibliothèque de blocs de logigramme (1) ; - la conception du logigramme (1) consistant à disposer, relier et paramétrer des blocs de logigramme (1) paramétrables, au moyen de l’IHM ; - un compilateur pour générer un code objet à partir du logigramme (1). Figure pour l’abrégé : Fig. 1. Dispositif de pilotage d’un centre logistique, et procédé de programmation L’invention se rapporte au domaine technique de centres logistiques équipés d’un trieur automatique, et plus particulièrement à la programmation de logiciels de gestion d’un tel centre. Art antérieur Un trieur automatique d’un centre logistique est piloté par un logiciel couramment appelé « WCS » selon l’anglicisme « Warehouse Control System ». Le WCS dirige les activités en temps réel du centre logistique, et fait l’intermédiaire entre : - le système de gestion de stock, correspondant à un niveau supérieur, et désigné « WMS » selon l’anglicisme « warehouse management system » ; et - les systèmes embarqués, ou automates des machines d’un trieur, correspondant à un niveau inférieur. Le WCS a la charge d'assurer la fluidité des opérations, de maximiser l'efficacité des matériels de manutention, et souvent des activités annexes à l'entrepôt. Il offre une interface unique pour de nombreux matériels de manutention, tels que des transtockeurs, des bandes transporteuses, des trieurs, des palettiseurs. Les principales tâches d'un WCS sont : - Effectuer l’interface entre le système de niveau supérieur « WMS » et échanger avec le WMS des informations nécessaires à l'exploitation quotidienne du centre de distribution ; - Assigner dynamiquement les colis aux gares, selon des algorithmes de tri ; - Fournir en temps réel des consignes aux opérateurs et matériels du niveau inférieur, pour la préparation des commandes et le routage des produits ; - Exporter des fichiers de rapport ou d'acquittement pour les systèmes de niveaux supérieurs ; - Fournir des écrans, un environnement graphique, et fonctions opérationnels pour assurer une gestion et un contrôle efficace du centre logistique. En pratique : - le WCS traite des événements de « haut niveau », par exemple « un colis est arrivé », « un colis est hors gabarit » ; - l’automate gère des événements de « bas niveau », par exemple « orienter le colis dans la gare indiquée par le WCS », « effectuer la pesée d’un colis pour fournir sa masse au WCS ». Le WCS exécute des règles de tri, qui peuvent être nombreuses, et qui sont propres aux souhaits du client et à l’implantation mécanique du trieur. Parmi les règles et les critères de tri les plus courants, il existe par exemple des règles portant : - Sur des informations de l’étiquette du colis, telles qu’un code postal ; - Sur des caractéristiques du colis, telles que son poids. Le WCS est conçu : - soit par un éditeur de logiciel de WCS ; - soit par le fabricant du trieur. Lorsque le WCS est conçu par un éditeur de WCS, il s’agit alors d’un progiciel, généralement dédié à des utilisateurs disposant de plusieurs trieurs, et éventuellement multisites. Le déploiement de nouvelles règles de tri ou de nouveaux procédés de tri sur un trieur est rendu compliqué car la modification du WCS concerne alors l’ensemble du progiciel. Le coût de déploiement d’une nouvelle règle ou d’un nouveau procédé est donc augmenté. De plus, la modification du code source du progiciel, destinée à un trieur ou à un site particulier, peut avoir un impact sur un autre trieur ou un autre site si jamais la reprogrammation du progiciel n’est pas correctement testée et déboguée. Ces étapes de vérification, préalables au déploiement de la nouvelle règle ou du nouveau procédé, empêchent l’utilisateur de faire des modifications sur site, et en temps réel. Lorsque le WCS est conçu par le fabricant du trieur, le WCS peut être modifié sur site, et en temps réel. En revanche, le WCS est peu évolutif, généralement conçu pour un seul procédé de tri, et impose à un client disposant de plusieurs trieurs de maitriser les langages de programmation ainsi que les architectures des programmes de chacun des WCS de ses différents trieurs. Il existe donc des difficultés pour programmer un WCS. Le brevet EP1825424 décrit une méthode de programmation assistée. L’assistance se limite au débogage de règles isolées, qui doivent ensuite être intégrées dans un code général, destiné à exécuter plusieurs règles. Ce procédé offre donc une assistance limitée. Enfin, des inconvénients existent pour les deux types de WCS, que le WCS soit conçu par un éditeur de logiciel, ou par un fabricant de trieur : - la modification de la programmation du WCS implique généralement un redémarrage du WCS, ce qui est synonyme d’une interruption du trieur automatisé. Dans le cas de modifications mineures ou concernant une partie isolée du WCS, l’interruption globale du trieur ne semble pas justifiée ; - au cours de la vie du logiciel, la complexification progressive du code source entraîne des risques de dépendance de règles : certaines règles peuvent être impactées par d’autres développements ultérieurs, sans qu’il ne soit possible de détecter ces dépendances ; - l’analyse a posteriori d’un tri d’un colis peut s’avérer complexe, car il faut alors soit disposer d’un outil spécifique de suivi de l’exécution du WCS, soit accéder à des fichiers de trace du WCS et comprenant un volume important de données. L’analyse a posteriori, qu’il s’agisse d’un débogage du WCS ou d’une détection d’une erreur de tri d’un colis, est difficile. L’un des buts de l’invention est de pallier les inconvénients de l’art antérieur, notamment en proposant une interface qui simplifie la programmation d’un logiciel de gestion d’entrepôt dit « WCS ». A cet effet, il a été mis au point un dispositif de pilotage d’un trieur automatisé d’un centre logistique, exécutant un logiciel de gestion d’entrepôt « WCS », et comprenant : - une interface homme machine « IHM » exécutant un logiciel de programmation du WCS : - le logiciel de programmation étant configuré pour concevoir un organigramme de programmation du WCS, dit « logigramme » ; - le logiciel de programmation comprenant une bibliothèque de blocs de logigramme ; - la conception du logigramme consistant à disposer, relier et paramétrer des blocs de logigramme paramétrables, au moyen de l’IHM ; - un compilateur pour générer un code objet à partir du logigramme. De cette manière, la programmation du WCS est simplifiée car la conception d’un logigramme permet : - de structurer facilement les enchaînements des blocs, alors qu’un équivalent du logigramme rédigé en code source serait long de plusieurs milliers de lignes de codes, au sein desquelles il serait difficile de situer une règle précise ou un enchaînement de règles, car seules des indentations du code ou des référencements de fonctions seraient disponibles ; - de fournir une interface visuelle de la structure du programme. En particulier, si le logigramme présente des légendes désignant le but ou le fonctionnement de chaque bloc, ces légendes permettent de comprendre le fonctionnement du logigramme sans aucun lecture de code source. Le fonctionnement du logigramme est donc plus compréhensible. Les blocs sont paramétrables au moyen de courtes instructions en code source, ce qui permet de segmenter les instructions à coder. Ainsi : - le codage est simplifié, car des fonctions simples peuvent être reprises facilement, - le débogage est également simplifié, car il est plus facile d’isoler, au sein du logigramme, un embranchement qui serait non fonctionnel. Les blocs du logigramme sont la base d’un « code source équivalent », composé de blocs codés individuellement, et dont l’enchaînement est effectué par le logiciel de programmation sur la base des liens établis entre les blocs. En particulier, le logiciel de programmation constitue le code source équivalent, sur la base des codes sources individuels contenus dans chaque bloc, en structurant par exemple le passage de paramètres ou de variables d'un bloc au suivant. La génération de code objet par le compilateur permet toutefois de surmonter l’inconvénient des logigrammes, qui est leur lenteur d’exécution : en effet, lors de l’exécution d’un logigramme rédigé en code source, l’ordinateur exécutant le logigramme doit interpréter le code source au moyen d’un interpréteur, dont une des tâches est l’analyse syntaxique du code source. Cette analyse rallonge les temps d’exécution du logigramme. Or les cadences des trieurs automatiques, de l’ordre de 10 colis par seconde, ne sont pas compatibles avec la durée d’exécution directe d’un logigramme. Le compilateur permet de traduire le code source équivalent du logigramme en un code objet dont l’exécution sera beaucoup plus rapide, car les étapes d’interprétation ou d’analyse syntaxique sont supprimées. L’invention rend donc possible : - une programmation aisée du trieur, car les compétences nécessaires au codage de blocs à relier de manière graphique sont bien inférieures aux compétences nécessaires pour rédiger un code source codant l’intégralité des règles de tri ; - d’obtenir un WCS dont la vitesse d’exécution est compatible avec la cadence d’un trieur automatique. Le logiciel de programmation prend en compte et implémente automatiquement les contraintes et les considérations techniques de codage informatique dans le code source équivalent. Il s’agit par exemple de la gestion de la temporalité des tâches, du nommage de variables du code ou de fonctions, ou encore de l’allocation de la mémoire vive de l’ordinateur. L’utilisateur n’a donc pas besoin de coder lui-même tous ces éléments, qui relèvent de l’expertise du codage informatique. Avantageusement, la bibliothèque comprend des blocs d’interfaçage préprogrammés, comprenant des instructions de code d’un protocole de communication programmé pour assurer la compatibilité entre un code objet du WCS et un protocole de communication du trieur. Plusieurs blocs d’interfaçage sont préprogrammés par l’éditeur du logiciel de programmation, de sorte que le WCS peut être compatible avec la majorité des trieurs automatiques du marché. La bibliothèque comprend également des blocs d’interfaçage programmables, conçus pour que l’utilisateur programme un protocole de communication manquant. Ainsi, un seul langage de code source est nécessaire pour programmer le WCS, alors que le WCS est compatible avec une multitude de trieurs, même s’ils doivent être pilotés par des langages différents. De préférence, le logiciel de programmation est configuré pour recharger à chaud le code objet, c’est-à-dire que le code objet généré est chargé dynamiquement dans le WCS : il n’y a pas besoin de redémarrer le WCS pour modifier les règles de tri. Ainsi, une modification du WCS peut se faire sans interruption du trieur automatique. La compilation puis le déploiement à chaud du code objet généré est généralement dénommée « compilation à chaud », sans que ne soit exclue la mise en œuvre d’une compilation à la volée. De manière à programmer plus facilement un WCS qui soit compatible avec plusieurs trieurs, le WCS comprend un premier logigramme dit « logigramme-règle » conçu pour déterminer des sorties logiques d’une règle de tri, et un second logigramme dit « logigramme-machine ». Le logigramme-machine peut être conçu pour faire correspondre les sorties logiques de la règle à des sorties physiques du trieur. Avantageusement, le logigramme-machine est également conçu pour programmer l’interopérabilité entre le WCS et le trieur. Pour cela, il comprend des blocs d’interfaçage nécessaires pour adapter les données issues du code objet et les rendre interprétables par l’automate du trieur, et réciproquement. De cette manière : - Un même logigramme-règle peut être mutualisé pour le pilotage de plusieurs trieurs mettant en œuvre la même règle de tri. Seule l’affectation d’une sortie physique pour chaque sortie logique de la règle doit être traitée au cas par cas pour chaque trieur, lors de la conception. - les spécificités d’interfaçage de chaque trieur sont isolées dans le logigramme-machine de chaque trieur, ce qui permet de simplifier le logigramme-règle. - Une modification matérielle du trieur, impliquant une modification des sorties physique, est gérée au sein d’un logigramme-machine qui est plus petit qu’un logigramme complet du trieur, et donc plus simple à mettre à jour. De manière que le WCS et le logiciel de programmation soient exécutés au sein d’une même interface graphique, le logiciel de programmation du WCS est un sous-programme du WCS, et de préférence le logiciel de programmation du WCS est lancé lors du démarrage du WCS. Cette structure logicielle facilite le déploiement à chaud du code objet, et offre également à l’utilisateur la possibilité de procéder à des modifications du logigramme et à des tests, sans nécessiter de naviguer entre plusieurs logiciels. L’ergonomie est améliorée. Avantageusement, la bibliothèque comprend des blocs de logigramme pré-paramétrés avec des fonctions préprogrammées telles qu’une règle de tri courante d’un trieur, par exemple la lecture d’un code à barres. Le code source d’une fonction logique est déjà rédigé avec des opérateurs et des opérandes. L’utilisateur n’a plus qu’à affecter les bons opérandes, c’est-à-dire saisir les variables correspondant à son logigramme en cours de conception. Le code de ces fonctions préprogrammées par l’éditeur du logiciel est enregistré dans une librairie du logiciel de programmation, sous forme de code objet. Pour laisser une plus grande marge de manœuvre à un utilisateur, la bibliothèque comprend des blocs de logigramme vierges, et programmables par un utilisateur au moyen de la saisie d’un code source. Afin que le WCS puisse exécuter des fonctions plus complexes, et notamment puisse interagir avec un logiciel externe tel qu’un logiciel de messagerie électronique, le logiciel de programmation est programmé pour intégrer dans la librairie des codes objets de fonctions de module d’extension (ou « plug in » en anglais), qui sont développées à l’aide d’un logiciel de développement dédié. . Le WCS peut ainsi être programmé pour déclencher l’envoi de courriels, pour mettre à jour une base de données consultable par internet pour un suivi de colis en ligne, ou encore pour interroger une base SQL. En d’autres termes, la bibliothèque comprend des blocs de logigramme d’appel de module d'extension, et programmables par un utilisateur au moyen de la saisie d’un code source. Afin de disposer d’un outil ergonomique d’analyse a posteriori du tri d’un colis, le WCS est programmé pour afficher l'enchaînement des blocs exécutés pour une opération de tri réalisée de ce colis. De préférence, l’affichage des blocs exécutés comprend la mise en évidence, telle qu’en surbrillance, sur le logigramme, des blocs exécutés. Si un colis a été mal trié, il est plus facile de retrouver quel cheminement le colis a suivi au sein des règles de tri, et donc de comprendre d’où vient l’erreur. L’invention concerne également un procédé de programmation d’un système de gestion d’entrepôt dit « WCS », destiné à piloter un trieur d’un centre logistique, remarquable en ce qu’il comprend les étapes successives suivantes : - concevoir un organigramme de programmation du WCS, dit « logigramme » ; - exécuter un compilateur afin de traduire automatiquement le logigramme dans un code objet. Un tel procédé permet d’obtenir les avantages précités, c’est-à-dire de faciliter la programmation du WCS tout en obtenant un WCS dont la vitesse d’exécution est compatible avec la cadence d’un trieur automatique. Avantageusement, le code objet est rechargé à chaud, ce qui permet de tester directement la programmation effectuée sans nécessiter le redémarrage du trieur. Les modifications peuvent donc être effectuées en temps réel, sur site. L’invention concerne également un programme d'ordinateur comportant des instructions pour mettre en œuvre un procédé selon les caractéristiques précitées. L’invention concerne également un support de données susceptible d'être lu par un système informatique, comportant des données ou des instructions pour mettre en œuvre un procédé selon les caractéristiques précitées. est un logigramme-règle, codant des règles de tri d’un trieur automatique. est une interface graphique d’édition du logigramme-règle. est un logigramme-machine. est une interface graphique mettant en évidence le cheminement effectué lors du tri d’un colis. est une interface graphique illustrant un horodatage ainsi que des valeurs d’opérandes et de résultats de fonctions lors du tri de ce colis. Description détaillée de l’invention Un système de gestion d’entrepôt, dit « WCS », pilote un trieur automatisé de cet entrepôt. Le WCS est exécuté sur une interface homme machine « IHM », c’est-à-dire un ordinateur ou un serveur équipé de périphériques d’entrées et de sorties usuels (tels qu’un écran, un clavier, une souris), et de moyens de connexion avec le matériel du trieur automatique, en particulier les automates. L’IHM est configurée pour exécuter un logiciel de programmation du WCS. En référence aux figures 1 à 3, l’invention se rapporte essentiellement à la programmation du WCS sous forme de logigramme (1). L’intérêt d’une représentation graphique d’un WCS est de pouvoir visualiser simplement l’architecture complexe des règles de tri mises en œuvre par le WCS. Ces règles peuvent être nombreuses, et l’arborescence de ces règles est difficile à interpréter lorsqu’uniquement un code source du WCS est disponible. Le logigramme (1) du WCS comprend des blocs (11, 12) de logigramme, chacun correspondant : - soit à un bloc de décision (11), au niveau duquel le WCS exécute une fonction booléenne afin de déterminer deux alternatives ; - soit à un bloc d’action (12), au niveau duquel le WCS effectue une tâche spécifique, telle que fournir des informations à un système de gestion de stock « WMS », ou donner des instructions à un automate du trieur. Chaque bloc (11, 12) du logigramme (1) comprend des instructions sous forme de code source. Dans le cas de blocs vierges, le code source est saisi par l’utilisateur du logiciel de programmation. Bien que l’utilisateur ait besoin de maîtriser des rudiments d’un langage de codage informatique, le code source à saisir dans chaque bloc est généralement simple. En revanche, la complexité de la rédaction d’un code source complet, comprenant généralement plusieurs milliers de lignes de code, est évitée, car les enchaînements des blocs n’ont pas besoin d’être codés : il suffit de relier graphiquement des blocs (11, 12), au moyen de liens (13) tracés sur une interface graphique de programmation (2) du logiciel de programmation. Sur le logigramme (1), il est possible de saisir des légendes (15) décrivant succinctement le contenu d’un bloc ou le résultat d’un test, à la manière d’un commentaire rédigé dans un code source. Néanmoins, les légendes (15) du logigramme (1) selon l’invention sont plus lisibles qu’un commentaire, car elles ne sont pas disséminées au sein des instructions du code source. L’interface graphique de programmation (2) proposée permet donc une conception et une navigation au sein de l’algorithme de tri plus aisées. Afin de faciliter la programmation de certaines étapes du logigramme (1), une bibliothèque du logiciel de programmation comprend des blocs pré-paramétrés. Ces blocs renvoient à un code source préalablement rédigé, et codant les instructions correspondant à des fonctions courantes d’un trieur automatique. Il peut s’agir par exemple d’un test selon le code postal d’une adresse de destination, ou encore d’une vérification d’un gabarit de colis. En pratique, un bloc pré-paramétré ne charge pas le code source préprogrammé, seule la saisie des opérandes étant nécessaire. Lors de la compilation du code source équivalent, le logiciel de programmation reconstitue le code du bloc en question, en inscrivant les opérandes saisis par l’utilisateur au sein du code source préprogrammé. Les temps de conception du logigramme (1) et les risques d’erreurs de programmation sont donc réduits. En référence particulière à la , le WCS exécute un sous-programme programmé pour éditer le logigramme (1) du WCS. L’interface graphique de programmation (2) de ce logiciel de programmation permet de rajouter des blocs de logigramme (1) au moyen d’un bouton cliquable « ajouter » (21). L’utilisateur choisit le type de bloc à insérer au sein d’un menu déroulant, puis le positionne sur le logigramme (1) avant de le relier à un autre bloc par un lien (13). La liaison entre les blocs se fait au moyen de points d’ancrage (14) de chaque bloc (11, 12). Lorsque l’utilisateur clique sur un bloc du logigramme (1), l’interface graphique (2) ouvre une fenêtre de paramétrage (22) configurée pour paramétrer ce bloc. Cette fenêtre de paramétrage (22) contient des champs affichant des données non modifiables, telles qu’un « identifiant » du bloc qui est généré automatiquement par le logiciel de programmation. Cet identifiant est unique, permet au compilateur d’analyser la structure du logigramme (1), et de gérer l’unicité de chaque variable ou résultat d’un bloc au sein du « code source équivalent » du logigramme (1). La fenêtre de paramétrage (22) contient également des champs affichant des données modifiables, telles que le « Code » du bloc, et qui correspond à un nom abrégé du bloc, choisi par l’utilisateur selon l’action ou la décision effectuée par ce bloc. Dans le cas d’un bloc vierge, un champ « Code » correspond à une zone de saisie du code source contenant les instructions que doit exécuter le bloc. L’utilisateur est libre de saisir les instructions qu’il souhaite, et correspondant à l’action élémentaire que doit effectuer le bloc au sein du logigramme (1). Un bloc vierge propose néanmoins une interface de programmation limitée : il n’est pas possible de faire appel à d’autres librairies que celle du logiciel de programmation, et les fonctions proposées sont limitées. Dans le cas d’un bloc pré-paramétré, un champ « Process » contient un menu déroulant permettant de sélectionner la fonction désirée, au sein de la librairie du logiciel de programmation. Il suffit ensuite de saisir les opérandes nécessaires à l’exécution de la fonction, au sein d’un ou de plusieurs champs « Variable ». Lors de la sélection d’une fonction, les champs « Variable » s’affichent en nombre, et avec les intitulés nécessaires, définis par le code source de cette fonction. La fenêtre de paramétrage (22) comprend également des cases à cocher permettant de paramétrer certains comportements du bloc lors de l’exécution du logigramme (1). La case « historiser le passage » permet d’inclure ou non l’exécution de ce bloc dans des fichiers de traces permettant d’historiser les événements survenus lors de l’exécution du WCS. Ces données sont également enregistrées au sein d’une base de données dont la durée de sauvegarde est plus longue que celle d’un fichier de traces. Dans le même but, la case « historiser les variables en sortie » permet d’inclure au sein des fichiers traces quelles valeurs ont prises les sorties logiques du code source de ce bloc. Il est possible d’ajouter des légendes (15) sur le logigramme (1), qui permettent de savoir quel est le but du code source saisi dans le champ « Process », sans consulter ledit code source. Ces légendes (15) sont ajoutées au moyen de même bouton « ajouter » qui est utilisé pour ajouter des blocs de logigramme. Dans le cas de blocs de décision (11), des champs de légendes (15) sont donc disponibles pour identifier, sur le logigramme (1), à quel résultat correspondent les deux sorties du bloc de décision (11). Dans un mode de réalisation, les légendes (15) sont des blocs de logigramme de type texte, et sont insérées au sein du logigramme (1) de la même manière que les blocs de décision (11) ou les blocs d’action (12). Afin que le WCS puisse interagir avec d’autres systèmes ou d’autres logiciels, la librairie du logiciel de programmation est programmée pour intégrer des codes sources de fonctions des modules d’extension, servant à programmer des modules d’extension. Par exemple un module d’extension est programmé pour effectuer une mise à jour d’une base de données une fois que le tri d’un colis est effectué. Cette base de données est utilisée dans le cadre d’un service en ligne de suivi de colis, permettant à un destinataire de consulter par internet l’avancement de la livraison du colis. Le développement du code source d’un module d'extension, plus complexe qu’un simple test d’une condition, ou qu’une instruction donnée au trieur, se fait au travers d'un éditeur de logiciel dédié, et permettant d'organiser le code source plus facilement. En particulier, il peut être nécessaire de séparer le code source du module d’extension en plusieurs fichiers. Lorsque la programmation du module d’extension est achevée, son code source est compilé afin que son code objet soit constitué. Le fichier informatique de ce code objet est ensuite disposé dans un répertoire configuré pour être consulté par le logiciel de programmation, et le logiciel de programmation est programmé pour intégrer à sa bibliothèque les codes sources contenus dans ce répertoire. De cette manière, il est possible de rajouter des fonctions au sein de la librairie du logiciel de programmation. Ces nouvelles fonctions sont donc proposées au sein du menu déroulant « Process » des blocs pré-paramétrés, et l’utilisateur n’a qu’à saisir les champs « Variables » afférents. Lors de la compilation du code source équivalent du logigramme, les blocs appelant des fonctions de module d’extension sont traités comme les blocs appelant des fonctions préprogrammées. Il est donc possible de coder des fonctions plus complexes, notamment celles faisant appel à d’autres librairies que celle initialement incluse dans le logiciel de programmation. Pour simplifier la programmation du WCS, il peut être intéressant de séparer le logigramme (1) en plusieurs logigrammes distincts : - un premier logigramme-règle définit les règles de tri à mettre en œuvre, c’est-à-dire le scénario de tri fournissant des sorties logiques ; - un second logigramme-machine définit le protocole de communication, et comment est-ce que le trieur met en œuvre les règles définies, c’est-à-dire le plan de tri fournissant des sorties physiques. Par exemple, pour le cas d’une fonction de tri sur la base d’un code postal : Le logigramme-règle définit les sorties logiques, en résultat d’un test : - si le code postal commence par « 42 », orienter le colis vers la « sortie 1 » ; - si le code postal commence par « 69 », orienter le colis vers la « sortie 2 ». Le logigramme-machine d’un premier trieur affecte chaque sortie logique à une sortie physique : - si « sortie 1 », orienter le colis vers le convoyeur A ; - si « sortie 2 », orienter le colis vers le convoyeur B. La illustre un logigramme-règle, tandis que la illustre un logigramme-machine. Dans le cas où différents trieurs sont pilotés par les mêmes règles de tri, il devient très facile de dupliquer des scénarios et de ne modifier que les logigramme-machine. Par exemple le logigramme-machine du second trieur serait : - si « sortie 1 », orienter le colis vers le convoyeur C ; - si « sortie 2 », orienter le colis vers le convoyeur D. Le logigramme machine est également utilisé pour programmer les protocoles de communication entre le WCS et le trieur. Dans notre exemple : - le premier trieur peut utiliser un premier protocole de communication comme le protocole de contrôle de transmissions (ou « TCP » selon l’anglicisme Transmission Control Protocol) ; - le second trieur peut utiliser un second protocole de communication comme le « Modbus ». La programmation du protocole de communication est également nécessaire pour que le WCS puisse obtenir des informations du trieur. Le logigramme machine homogénéise le format des données obtenues, et communique les informations finales au logigramme règle. Le logigramme règle peut donc être unique, quel que soit le trieur utilisé et quel que soit le protocole de communication qu’il met en œuvre. En pratique, un utilisateur du WCS peut devoir gérer un parc comprenant une vingtaine machines, réparties sur une quinzaine de sites. Une machine peut être dédiée à un type de produit particulier, par exemple des colis import, ou de la presse non adressée. Pouvoir dupliquer les logigrammes-règles et ne reparamétrer que les logigrammes-machine est donc une simplification évidente de la programmation mise en œuvre pour gérer le parc. Sur les figures 1 et 3, des blocs de départs permettent de réagir à des évènements paramétrés, tels que l’injection d’un colis sur un trieur, ou encore la connexion d'un opérateur à une interface homme-machine du trieur. Afin de simplifier la programmation de l’ensemble des règles de tri, il est également possible de programmer distinctement plusieurs logigramme-règles au sein du WCS. Par exemple, un logigramme règle peut être dédié à la gestion des colis import, alors qu’un autre logigramme-règle peut être dédié à la gestion de la presse non adressée. Différents logigrammes peuvent être disposés sur une même fenêtre de l’interface de programmation, afin que l’utilisateur puisse visualiser l’ensemble de la programmation. En pratique, lorsqu’un logigramme-machine obtient un évènement du trieur, le logigramme-machine informe tous les logigramme-règle en cours d’exécution au sein du WCS. Pour un évènement donné, il faut s'assurer qu'un seul logigramme-règle applique les règles de tri correspondant à cet événement et détermine la sortie trieur à utiliser. Certains logigrammes-règles comprennent donc un bloc de décision (11) jouant le rôle d’un filtre. Par exemple sur la , un premier bloc de décision (11) « Etiquette Chronopost » ne comprend qu’une seule sortie : la suite du logigramme-règle ne peut être exécuté que si le colis en question est du type « Chronopost ». Si ce n’est pas le cas, le logigramme-règle illustré ne peut pas être poursuivi. Un autre logigramme-règle, non représenté, comprend les instructions pour traiter les autres types de colis. En référence à la , la même démarche peut s’appliquer à des situations que l’utilisateur ne souhaite pas gérer : par l’exemple, si l’évènement d’automate détecté n'est ni une information de type poids, ni une information de type compte rendu de tri, il n’est pas nécessaire de déclencher une autre action. Pour ne pas alourdir la description, il ne sera ensuite fait référence qu’au logigramme (1) complet du WCS, c’est-à-dire comprenant éventuellement un ou plusieurs logigrammes-règles et un ou plusieurs logigrammes-machines. Une fois que la conception du logigramme (1) est achevée, l’utilisateur peut déclencher la compilation, et de préférence la compilation ainsi que le rechargement à chaud du code source équivalent du logigramme (1), en cliquant sur un bouton « sauvegarder » (23). Le logiciel de programmation exécute alors un compilateur qui convertit le coude source équivalent du logigramme (1) en un code objet exécutable par l’ordinateur ou le serveur exécutant le WCS. Le code objet est rechargé à chaud, c’est-à-dire qu’il est rechargé alors que le WCS est en cours d’exécution, et la nouvelle version de code objet est injectée lors de l’exécution. De cette façon, le WCS n’est pas arrêté, c’est-à-dire que l’activité du trieur n’est pas interrompue. Ce principe est particulièrement utile lorsque l’utilisateur apport des modifications mineures au WCS. Il ne s’agit pas d’un rechargement en direct, qui réinitialise complètement l’état du logiciel. Le rechargement à chaud permet donc de procéder à des modifications du WCS, et d’implémenter directement les modifications effectuées. Il est donc possible de bénéficier d’une flexibilité pour la modification du WCS, qui n’était pas disponible jusqu’alors. Lors du fonctionnement du trieur automatique, il peut arriver qu’un colis soit mal aiguillé. Afin de prévenir la répétition de cette erreur, il est important de détecter si ce mauvais aiguillage résulte par exemple d’un incident mécanique (convoyeur dysfonctionnel), d’un incident logiciel (programmation inadaptée) ou d’un incident électronique (lecture erronée d’un code à barre). Pour ce faire, le WCS dispose d’une interface graphique de vérification de tri (3) au moyen de laquelle il est possible, pour un tri d’un colis qui a déjà été effectué, de vérifier quel parcours a suivi le logigramme (1) pour ce tri. En référence à la , cette vérification se fait de préférence au moyen d’un affichage dédié (31) du parcours sur le logigramme (1), par exemple par la mise en évidence, telle qu’une mise en surbrillance de ce parcours. Ce premier niveau de visualisation permet de détecter rapidement au niveau de quel bloc est-ce que l’erreur est survenue, l’utilisateur pouvant repérer par exemple un bloc de décision (11) du logigramme (1) où le WCS n’a pas suivi le bon embranchement. La recherche de l’incident est donc facilitée. En référence à la , en cliquant sur un bouton « Afficher le détails des étapes et des variables » (non représenté) l’utilisateur peut accéder à une fenêtre de traces (32) affichant des données stockées dans un fichier de traces. Les données comprennent : - l’identification du logigramme (1) considéré, dans le cas où le WCS exécute plusieurs logigramme (1)s (colonne « scénario ») ; - un horodatage (colonne « date màj ») ; - un identifiant d’une variable (colonne « Clé »), qu’il s’agisse d’une donnée d’entrée (obtenue auprès du WMS ou de l’automate du trieur), d’une donnée calculée (résultat du test d’un bloc de décision (11) ou d’une action d’un bloc d’action (12)) ; - le cas échéant, une valeur d’une variable (colonne « Valeur actuelle »). Lorsque l’utilisateur a détecté d’où venait le dysfonctionnement, au moyen de l’interface graphique de vérification de tri (3), il peut se focaliser directement au bon niveau du fichier de traces, correspondant au bloc où a survenu l’erreur. S’il n’avait pas le repérage graphique (31) du parcours suivi par le colis pour détecter le bloc où a survenu l’erreur, l’utilisateur aurait dû parcourir l’intégralité d’un fichier traces du logiciel pour essayer de reconstituer le parcours du colis, et pour essayer de comprendre l’origine de l’erreur. Cette analyse aurait été beaucoup plus compliquée. L’invention permet donc de profiter de la grande paramétrabilité des logigrammes, tout en évitant l’inconvénient de leur lenteur d’exécution. La maitrise basique d’un seul langage de code source permet de programmer un WCS complet, via la programmation d’instructions élémentaires au sein de blocs du logigramme (1). Par ailleurs, le dispositif de pilotage, le logiciel de programmation et le procédé de programmation peuvent être conformés différemment des exemples donnés sans sortir du cadre de l’invention, qui est défini par les revendications. En outre, les caractéristiques techniques des différents modes de réalisation et variantes mentionnés ci-dessus peuvent être, en totalité ou pour certaines d’entre elles, combinées entre elles. Ainsi, le dispositif de pilotage, le logiciel de programmation et le procédé de programmation peuvent être adaptés en termes de coût, de fonctionnalités et de performance. Dispositif de pilotage d’un centre logistique, exécutant un logiciel de gestion d’entrepôt « WCS », et comprenant : - une interface homme machine « IHM » exécutant un logiciel de programmation du WCS : - le logiciel de programmation étant configuré pour concevoir un organigramme de programmation du WCS, dit « logigramme (1) » ; - le logiciel de programmation comprenant une bibliothèque de blocs de logigramme (1) ; - un compilateur pour générer un code objet à partir du logigramme (1). Dispositif selon la revendication 1, caractérisé en ce que le logiciel de programmation est configuré pour recharger à chaud le code objet. Dispositif selon l’une des revendications précédentes, caractérisé en ce que le WCS comprend un premier logigramme (1) dit « logigramme-règle » conçu pour déterminer des sorties logiques d’une règle de tri, et un second logigramme (1) dit « logigramme-machine » conçu pour faire correspondre les sorties logiques de la règle à des sorties physiques du trieur et/ou conçu pour programmer l’interopérabilité entre le WCS et le trieur. Dispositif selon l’une des revendications précédentes, caractérisé en ce que le logiciel de programmation du WCS est un sous-programme du WCS, de préférence le logiciel de programmation du WCS est lancé lors du démarrage du WCS. Dispositif selon l’une des revendications précédentes, caractérisé en ce que la bibliothèque comprend des blocs de logigramme (1) pré-paramétrés. Dispositif selon l’une des revendications précédentes, caractérisé en ce que la bibliothèque comprend des blocs de logigramme (1) vierges, et programmables par un utilisateur au moyen de la saisie d’un code source. Dispositif selon l’une des revendications précédentes, caractérisé en ce que la bibliothèque comprend des blocs de logigramme (1) d’appel de module d'extension, et programmables par un utilisateur au moyen de la saisie d’un code source. Dispositif selon l’une des revendications précédentes, caractérisé en ce que la bibliothèque comprend des blocs d’interfaçage préprogrammés, comprenant des instructions de code d’un protocole de communication programmé pour assurer la compatibilité entre un code objet du WCS et un protocole de communication du trieur Dispositif selon l’une des revendications précédentes, caractérisé en ce que le WCS est programmé pour afficher l'enchaînement des blocs exécutés pour une opération de tri réalisée, de préférence par la mise en évidence, telle qu’en surbrillance, sur le logigramme (1), des blocs exécutés. Procédé de programmation d’un système de gestion d’entrepôt dit « WCS », destiné à piloter un trieur d’un centre logistique, remarquable en ce qu’ il comprend les étapes successives suivantes : - concevoir un organigramme de programmation du WCS, dit « logigramme (1) » ; - exécuter un compilateur afin de traduire automatiquement le logigramme (1) dans un code objet. Procédé selon la revendication 10, caractérisé en ce que le code objet est rechargé à chaud. Programme d'ordinateur comportant des instructions pour mettre en œuvre un procédé selon l'une des revendications 10 ou 11. Support de données susceptible d'être lu par un système informatique, comportant des données ou des instructions pour mettre en œuvre un procédé selon l'une des revendications 10 ou 11.