Étude de cas « Smart Traçabilité pour Suivi des Incidents »

(1)

Étude de cas « Smart Traçabilité pour Suivi des Incidents »

Denis Conan

CSC4102

Télécom SudParis Janvier 2022

(2)

1 Lettre de mission

Le contexte de votre mission : l’Organisation internationale de normalisation (ISO) définit la chaîne d’approvisionnement comme « [l’]ensemble lié de ressources et de processus qui commence avec l’identification de l’origine des matières premières et qui va jusqu’à la livraison des produits ou services à l’utilisateur final en passant par les divers modes de transport» [ISO/TC 292 Sécurité et résilience, 2007]. Elle peut inclure des fournisseurs, des installations de fabrication, des transporteurs, des prestataires logistiques, des centres de distribution internes, des distributeurs, des grossistes et d’autres entités. Cette étude de cas concerne la partie logistique de la chaîne d’approvisionnement.

Le Conseil des professionnels de la gestion de la chaîne d’approvisionnement (CSCMP) définit la logistique comme « le processus de planification, de mise en œuvre et de contrôle des procédures pour le transport et le stockage efficaces et efficients des biens, y compris les services et les informations connexes, du point d’origine au point de consommation, dans le but de se conformer aux exigences des clients » [CSCMP, 2021].

Dans cette étude de cas, nous nous limitons aux activités liées à l’opération de transport. Une opération de transport implique au moins trois catégories de parties prenantes : un expéditeur ou chargeur (à l’origine de la demande de transport), un transporteur (en charge de l’opération de transport) et un destinataire (le destinataire de l’envoi transporté). Pour simpliﬁer l’étude, nous ignorons volontairement les nombreuses autres parties prenantes, parmi lesquelles les prestataires de services logistiques et les douanes.

Un envoi est déﬁni par l’ISO comme « les biens de consommation courante transportés et/ou stockés selon les termes d’un seul connaissement¹, d’une seule lettre de transport ou d’un seul contrat de transport, indépendamment de la quantité ou du nombre de conteneurs, de colis ou de pièces » [ISO/TC 122 Packaging, 2017]. Nous utilisons le terme d’envoi pour désigner tout objet conﬁé au transporteur par le chargeur pour être acheminé vers le destinataire. Tous les acteurs concernés doivent partager des données de traçabilité sur la progression de l’envoi dans la chaîne logistique.

La traçabilité est déﬁnie par l’ISO comme « l’aptitude à retrouver l’historique, la mise en œuvre ou l’emplacement de ce qui est examiné[, y compris] dans le cas d’un produit, l’origine des matériaux et composants, l’historique de réalisation, et la distribution et l’emplacement du produit après livraison » [ISO/TC 176/SC 1 Concepts et terminologie, 2015]. Par exemple, des envois comme les kits de diagnostic médical périssables utilisés pour les tests sanguins requièrent un contrôle de la température entre +2 et +8^◦ Celsius. Le non-respect de cet intervalle de températures peut rendre les kits de diagnostic médical inutilisables. Les parties prenantes doivent être informées de tout non-respect de la température.

Pour réaliser cette traçabilité dans la chaîne logistique, il est important de collecter des données sur les conditions de transport et de stockage des envois. En plus des données de base (telles que la description, le volume, et le poids) et des données transactionnelles (telles que l’expédition et la livraison), l’aspect « smart » de l’étude de cas est l’utilisation de l’Internet des Objets (IoT) : chaque envoi est associé à des sources ou capteurs de données dites sources de données IoT ou sources IoT. Ainsi, nous supposons que l’envoi dispose d’une source IoT principale qui est l’objet connecté accompagnant l’envoi. Le rôle de cet objet est de collecter des données sur les conditions de transport de l’envoi tout au long de l’opération de transport : par exemple, la localisation, la température, le taux d’humidité, le degré d’exposition à des vibrations. Pour envoyer les données collectées au système d’information (SI) de traçabilité, l’objet connecté utilise une passerelle de réseau LPWAN (Low Power Area Network) qui transmet les messages reçus au SI. Chaque partie prenante peut aussi décider d’aﬀecter à un envoi une source IoT qu’elle possède, ceci à tout moment pendant la progression de l’envoi dans la chaîne logistique. Ces sources IoT sont donc ajoutées puis retirées par un transporteur sur un des segments de la chaîne logistique, c’est-à-dire au début d’un jalon. Ces sources IoT sont aussi prises en compte dans le SI.

Votre mission : créer un logiciel de gestion de la traçabilité des envois pour le suivi des incidents dans la chaîne logistique.

Vous appelez votre logiciel «_SmartTSI», pour «Smart Traçabilité pour Suivi des Incidents».

Voyez un exemple de chaîne logistique en Annexe 1 à la page 6.

(3)

2 Cahier des charges

Vous créez le logiciel_SmartTSIde gestion de la traçabilité des envois avec suivi des incidents détectés à partir des données transmises par des sources IoT. Le terme « envoi » désigne tout objet conﬁé au transporteur par le chargeur pour être acheminé vers le destinataire.

Utilisateurs de SmartTSI. L’administrateur du système est responsable de la création des parties prenantes de la chaîne logistique (clients et transporteurs). Le second type d’utilisateurs est le groupe des parties prenantes. Ce sont eux qui créent les sources IoT dans_SmartTSI. Le troisième type d’utilisateurs est consti- tué des sources IoT : autrement dit, le logiciel qui s’exécute sur une source IoT est un acteur de_SmartTSI car il fournit des données à _SmartTSI.

Hypothèses simpliﬁcatrices. Nous limitons le périmètre des fonctionnalités de_SmartTSI:

• tout d’abord, toutes les données de traçabilité nécessaires concernant l’avancement des opérations de transport sont fournies par les sources IoT, et les jalons d’avancement peuvent être déduits automatiquement des données IoT. Nous ne faisons donc pas de planiﬁcation d’un envoi ;

• ensuite, nous ne considérons que deux types de partenaires : les clients qui déposent des envois (l’ex- péditeur au point d’origine) et qui sont livrés (le destinataire au point de consommation) ainsi que les transporteurs (de jalons en jalons). Par exemple, nous ignorons les sous-traitants / prestataires logistiques qui, dans un port, transfèrent un envoi depuis un porte-conteneur vers un train de marchandises ;

• en outre, nous ne décomposons pas les envois en conteneurs, colis ou pièces qu’ils contiennent, et les biens transportés sont « fragiles ». Les clients sont des professionnels, c’est-à-dire que ce ne sont pas des particuliers et qu’ils sont en capacité d’adjoindre une source IoT (des capteurs) à leurs envois ;

• par ailleurs, une source IoT fournit des données qui sont toutes des nombres réels (type JAVAdouble) et nous ne décomposons pas le dispositif matériel, c’est-à-dire que nous ne sommes pas intéressés par la liste des capteurs d’une source IoT. Plus précisément, nous souhaitons seulement savoir qu’une source IoT recueille un ensemble de paires (nom d’attribut, valeur) sous la forme d’un enregistrement : par exemple, {(température, 19), (humidité, 0.8), (latitude, 48.6333), (longitude, 2.45), (nom_attribut, valeur), ...};

• enﬁn, nous ne gérons pas la logistique des sources IoT. En d’autres termes, mis à part l’association des sources IoT avec les envois, nous ne nous préoccupons ni de la localisation des sources IoT ni de qui possède quand telle ou telle source IoT.

Sprint 1 : gestion d’un envoi de l’expéditeur au destinataire. La chaîne logistique d’un envoi commence avec le dépôt par le client expéditeur et se termine avec la réception par le client destinataire.

SmartTSIgarde la date de ces deux événements. L’expéditeur est responsable de la création de l’envoi dans SmartTSI. Il indique toutes les données requises par les transporteurs pour la bonne exécution de l’opération de transport, comme l’origine, la destination, le volume, le poids, les conditions d’envoi, etc. Dans le Sprint 1, nous ignorons les conditions d’envoi, qui sont le sujet du Sprint 2 avec la détection des incidents.

Ensuite, le premier transporteur prend en charge l’envoi, et ainsi de suite avec les diﬀérents transporteurs.

Au ﬁnal, l’envoi est livré au destinataire. Aﬁn de pouvoir imputer un incident à la partie prenante qui est responsable de l’envoi, les événements du dépôt par l’expéditeur, des prises en charge par les transporteurs, et de la livraison au destinataire, sont datés (à la [nano]seconde près) : cf. l’annexe B avec la classe JAVA Instant.

Nota Bene1: un envoi peut être pris en charge plusieurs fois par la même partie prenante : par exemple, la même société de transport pour plusieurs segments de la chaîne logistique.

Nota Bene 2 : au fur et à mesure de l’utilisation de votre logiciel, le nombre de prises en charge augmentera pour devenir très grand. Par conséquent, dans la mesure du possible, il serait intéressant de ne pas avoir à les parcourir toutes pour trouver les prises en charge en cours.

L’annexe A.1 présente un scénario d’utilisation du logiciel_SmartTSIque vous construisez dans le Sprint 1.

(4)

Sprint 2 : collecte des données IoT d’un envoi et détection des incidents. Dans ce sprint, nous ajoutons le fait que l’expéditeur et les transporteurs adjoignent des sources IoT aux envois.

Autres hypothèses simpliﬁcatrices. Pour simpliﬁer le Sprint 2, nous supposons que :

• aucune donnée n’est perdue par une source IoT, et

• aucun message transitant entre les sources IoT et _SmartTSIn’est perdu.

Par conséquent, toutes les données IoT arrivent sur _SmartTSIau bout d’un certain temps et les incidents sont détectés à la réception de ces données IoT.

L’expéditeur adjoint une source IoT qui recueille des données pendant toute la durée de l’envoi. La source IoT peut ensuite être utilisée pour un autre envoi. Lorsque l’envoi est pris en charge par un nouveau transporteur, ce transporteur peut adjoindre une ou plusieurs nouvelles sources IoT. Les données IoT de SmartTSI possèdent une date de collecte et une date de réception, et avec les dates de début et de ﬁn de prise en charge, il est possible d’imputer a posteriori un incident à une partie prenante (tel client ou tel transporteur).

Dans ce sprint, nous nous focalisons sur la gestion des incidents liés à la traçabilité, c’est-à-dire sur les incidents qui sont détectés automatiquement sur la base des données envoyées par les sources IoT, comme le non-respect de l’intervalle de température de transport négocié. Ainsi, entre le dépôt de l’envoi et la prise en charge par le premier transporteur de la chaîne logistique, le client indique les conditions d’envoi à respecter. Comme les attributs de donnée IoT sont des nombres réels, une condition d’envoi est exprimée par un intervalle fermé avec une valeur minimale et une valeur maximale.

Les sources IoT transmettent, quand elles le peuvent, les données collectées. Ce sont des enregistre- ments structurés, c’est-à-dire des ensembles composés d’attributs, comme indiqué ci-avant :enregistrement

= {(nom_attribut, valeur), ...}. Chaque enregistrement possède une date de collecte et une date de ré- ception par_SmartTSI. Chaque attribut de donnée IoT possède un nom et une valeur de type JAVAdouble.

Dans l’étude de cas, nous nous limitons aux attributs suivants : la localisation avec la latitude et la longitude, la température, le taux d’humidité, et le degré d’exposition aux vibrations.Les messages en provenance des sources IoT contiennent l’identiﬁant de la source IoT et les mesures.SmartTSIgarde toutes les données collectées.

Lorsque des données IoT sont reçues par_SmartTSI, si certaines données montrent un non-respect d’une des conditions d’envoi, le client expéditeur, le client destinataire, le transporteur incriminé le cas échéant, sont notifiés. La notification contient l’identifiant de l’envoi, l’identifiant de la source IoT, l’identifiant de la partie prenante courante, le nom de la condition d’envoi non respectée, le nom de l’attribut de donnée IoT concerné, les valeurs minimales et maximales de la condition d’envoi, la valeur de l’attribut qui pose problème, la date de la collecte par la source IoT, et la date de réception par_SmartTSI.

Si vous voulez simplifier votre solution, vous pouvez considérer que la première valeur en erreur génère une notification et que la vérification est interrompue. Autrement dit, la première valeur trouvée en erreur est notifiée et tous les attributs de l’enregistrement collecté ne sont pas analysés.

L’annexe A.2 présente un scénario d’utilisation du logiciel_SmartTSIque vous construisez dans le Sprint 2.

(5)

Références

[Ahmed Mohamed, 2021] Ahmed Mohamed, M. (2021). Enhancing the traceability of B2B logistic chains using blockchain, IoT and Deep Learning. PhD thesis, Institut Polytechnique de Paris.

[CSCMP, 2021] CSCMP (2021). CSCMP Supply Chain Management Deﬁnitions and Glossary. Council of Supply Chain Management Professionals, https://cscmp.org/CSCMP/Academia/SCM_Definitions_

and_Glossary_of_Terms/CSCMP/Educate/SCM_Definitions_and_Glossary_of_Terms.aspx?hkey=

60879588-f65f-4ab5-8c4b-6878815ef921, accédé le 12 novembre 2021.

[ISO/TC 122 Packaging, 2017] ISO/TC 122 Packaging (2017). ISO/TS 17451-2:2017 Packaging — Codi- ﬁcation of contents for inventories for shipments of household goods and personal eﬀects — Part 2 : XML messaging structure for electronic transmission of inventory data. International Standard ISO- 17451-2:2017, ISO Technical Committee ICS 55.020 Packaging and distribution of goods in general, https://www.iso.org/standard/63804.html.

[ISO/TC 176/SC 1 Concepts et terminologie, 2015] ISO/TC 176/SC 1 Concepts et terminologie (2015). ISO 9000:2015 Systèmes de management de la qualité — Principes essentiels et vocabulaire. Internatio- nal Standard ISO-9000:2015, ISO Technical Committee ICS 01.040.03 Services. Organisation de l’entreprise. Gestion et qualité. Administration. Transport. Sociologie. (Vocabulaires),https://www.iso.org/

fr/standard/45481.html.

[ISO/TC 292 Sécurité et résilience, 2007] ISO/TC 292 Sécurité et résilience (2007). ISO 28000:2007 : Spéciﬁ- cations relatives aux systèmes de management de la sûreté de la chaîne d’approvisionnement. International Standard ISO-28000:2007, ISO Technical Committee ICS 03.100.01 Organisation et gestion d’entreprise en général,https://www.iso.org/fr/standard/44641.html.

Remerciements

L’idée initiale de l’étude cas ainsi que le contexte du sujet sont inspirés des travaux de Mohamed Ahmed Mohamed réalisés dans le cadre de sa thèse intitulée « Enhancing the traceability of B2B logistic chains using blockchain, IoT and Deep Learning » [Ahmed Mohamed, 2021]. Nous l’en remercions ainsi que ses encadrantes de thèse.

(6)

A Scénarios exemples d’utilisation du logiciel

Voici quelques scénarios proposés pour la compréhension de l’étude de cas. Ce ne sont en aucun cas des tests de validation. Par conséquent, vous n’avez aucune obligation de les programmer. Ils sont fournis pour aider à la compréhension de l’étude de cas. Dans ces scénarios, la marque «3» indique que l’opération est acceptée et eﬀectuée, la marque «7» indique que l’opération est refusée et donc non eﬀectuée.

A.1 Scénario du Sprint 1

Tout d’abord (les opérations eﬀectuées par l’administrateur) (1) 3 ajouter le clientclient1dont le nom...

(2) 3 ajouter le clientclient2dont le nom...

(3) 3 ajouter le transporteurtransporteur1dont le nom...

Ensuite (les opérations eﬀectuées par les clients ou les transporteurs)

(1) 3 le clientclient1dépose l’envoienvoi1ayant pour origine et destination...

Jalon 2

(1) 7 le clientclient2accepte la livraison de l’envoienvoi1

• L’envoienvoi1est encore chez le client et nous suggérons de ne pas autoriser le clientclient2à aller chercher l’envoi chez le client expéditeurclient1.

(2) 3 le transporteurtransporteur1prend en charge l’envoienvoi1

• L’envoienvoi1n’est plus chez le clientclient1.

Jalon 3

• L’envoienvoi1n’est plus géré par le transporteurtransporteur1.

Livraison

• L’envoienvoi1est livré.

• L’envoienvoi1a été livré.

Si vous voulez choisir un exemple quelque peu réaliste, voici une proposition, dont nous vous laissons l’in- terprétation, avec une chaîne logistique composée de 7 segments, et donc de 8 jalons :

• dépôt à TSP,

• livraison à l’ENISA, Nikolaou Plastira 95, Vassilika Vouton, 700 13 Heraklion, Greece.

Jalon A : Rue Charles Fourier, 91000 Évry, France

Jalon B : 69100 Villeurbanne, Auvergne-Rhône- Alpes, France

Jalon C : 10071 Torino (10071 Turin), Italy Jalon D : 72020 Brindisi, Italy

Jalon E : 9401 Vlorë, Vlorë, Albania Jalon F : 45221 Ioannina, Epirus, Greece Jalon G : 10431 Athens, Central Athens, Greece Jalon H : 70011 Irákleio (70011 Iraklion), Greece

(7)

A.2 Scénario du Sprint 2

Ce scénario complète celui du Sprint 1 avec les nouvelles fonctionnalités. Nous indiquons les nouvelles fonc- tionnalités enrouge.

Tout d’abord (les opérations eﬀectuées par l’administrateur) (1) 3 ajouter le clientclient1dont le nom...

(2) 3 ajouter le clientclient2dont le nom...

Ensuite (les opérations eﬀectuées par les clients ou les transporteurs)

(1) 3 ajouter la source de données IoTsourceIoT1dont la description...

• Nous ne sommes pas intéressés de savoir qui ajoute quelle source de données IoT.

(4) 3 le clientclient1dépose l’envoienvoi1ayant pour origine et destination..., et pour source de données IoT principale sourceIoT1

(5) 3 le clientclient1ajoute une condition d’envoi, par exemple indiquant que la température doit rester entre +2 et +8^◦Celsius

Puis (les données reçues depuis la source de données IoT)

(1) 3 ajouter un enregistrement de données IoT en provenance de la source de donnéessourceIoT1dont la date de collecte... avec les paires (nom d’attribut IoT, valeur réelle)...

• L’envoienvoi1est encore chez le clientclient1.

(2) 3 ajouter un enregistrement de données IoT en provenance de la source de donnéessourceIoT1 qui inclut une température à +1^◦

• Le clientclient1doit être notiﬁé d’un incident.

Jalon 2

(1) 3 le transporteurtransporteur1prend en charge l’envoienvoi1en ajoutant la source de données IoTsourceIoT2

• L’envoienvoi1n’est plus chez le clientclient1.

• La source de données IoTsourceIoT2est adjointe à l’envoienvoi1.

• Le clientclient1et le transporteurtransporteur1doivent être notiﬁés d’un incident.

Jalon 3

(1) 3 le transporteurtransporteur2prend en charge l’envoienvoi1en ajoutant la source de données IoTsourceIoT3

• La source de données IoTsourceIoT2n’est plus adjointe à l’envoienvoi1.

• La source de données IoTsourceIoT3est adjointe à l’envoienvoi1.

• Le clientclient1et le transporteurtransporteur2doivent être notiﬁés d’un incident.

Livraison

• L’envoienvoi1est livré.

• Les sources de données IoTsourceIoT1etsourceIoT3ne sont plus adjointes à l’envoienvoi1.

(8)

B Manipulation des dates avec la bibliothèque csc4102-util

Nous proposons une bibliothèque pour aider et accélérer la mise en œuvre de votre logiciel. Les quelques explications qui suivent sont à compléter avec la documentation Javadoc des classes de la bibliothèque²ainsi qu’avec les exemples d’utilisation proposés dans le projet GitLabcsc4102-exemples.

B.1 Classe eu.telecomsudparis.csc4102.util.Datutil

Deux manières de dater sont proposées avec les classesjava.time.Instant et java.time.LocalDate. Un instant est un point du temps à la précision de la nanoseconde. Une date est un jour dans le temps avec le mois et l’année. C’est a priori la classe Instant qui est la plus intéressante pour cette étude de cas : les données IoT sont horodatées à la nanoseconde près. Voici donc quelques méthodes de la classeDatutil: static Instant instantDuTest()

static Instant maintenant()

static boolean memeInstant(Instant premierInstant, Instant secondInstant) static boolean instantEstAvant(Instant premierInstant, Instant secondInstant) static void ajouterJoursALInstantDuTest(int nbjours)

static void retirerJoursALInstantDuTest(int nbjours)

static Instant ajouterJoursAInstant(Instant instant, int nbJours) static Instant retirerJoursAInstant(Instant instant, int nbJours) static String instantToString(Instant instant)

static LocalDate aujourdhui()

static boolean dateEstAujourdhui(LocalDate date)

static boolean memeJour(LocalDate premiereDate, LocalDate secondeDate) static boolean dateEstAvantAujourdhui(LocalDate date)

static boolean dateEstAvant(LocalDate premiereDate, LocalDate secondeDate) static boolean dateEstAvantOuAujourdhui(LocalDate date)

static boolean dateEstApresAujourdhui(LocalDate date) static boolean dateEstApresOuAujourdhui(LocalDate date) static LocalDate ajouterJoursADate(LocalDate date, int nbJours) static LocalDate retirerJoursADate(LocalDate date, int nbJours) static String dateToString(LocalDate date)

La classe ...csc4102.utilisationdelabibliothequeutil.ExempleManipulationsDatesEtInstants dans le projet GitLabcsc4102-exemplesdonne des exemples d’utilisation.

Enﬁn, au besoin, les classes Instant et LocalDate déﬁnissent les valeurs minimales et maximales : Instant.MIN,Instant.MAX,LocalDate.MIN, etLocalDate.MAX.

B.2 Classe eu.telecomsudparis.csc4102.util.IntervalleInstants

Voici quelques méthodes de la classeIntervalleInstantsqui nous intéressent : IntervalleInstants(Instant instantDebut, Instant instantFin)

Instant getInstantDebut() Instant getInstantFin()

boolean instantEstDansIntervalleInstants(Instant instantATester) boolean intervalleInstantsSIntersectent(IntervalleInstants intervalle) int hashCode()

boolean equals(Object obj) String toString()

La classe IntervalleInstants est accompagnée d’une classe déﬁnissant un comparateur : la classe ComparateurIntervalleInstants, qui implémente l’interface java.util.Comparator. La classe ComparateurIntervalleInstantsdéﬁnit la méthode compare qui est utilisée pour réaliser un ordre total sur une collection d’objets de typeComparateurIntervalleInstants:compareretourne un entier négatif,

(9)

zéro, ou un entier positif selon que le premier objet est « inférieur », « égal », ou « supérieur » au second objet. Les objets sont ordonnés par leur instant de début d’intervalle, puis par leur instant de ﬁn d’intervalle en cas d’égalité. Par exemple, il est possible de créer un ensemble triéTreeSet<IntervalleInstants>en fournissant un objet comparateur au constructeur :new TreeSet<>(new ComparateurIntervalleInstants()).

La classe...csc4102.utilisationdelabibliothequeutil.ExempleManipulationsIntervalleInstantsdans le projet GitLab csc4102-exemples donne des exemples d’utilisation des classes IntervalleInstants et ComparateurIntervalleInstants.

B.3 Classe eu.telecomsudparis.csc4102.util.IntervalleDates

Voici quelques méthodes de la classeIntervalleDatesqui nous intéressent : IntervalleDates(LocalDate dateDebut, LocalDate dateFin)

LocalDate getDateDebut() LocalDate getDateFin()

boolean dateEstDansIntervalleDates(LocalDate dateATester) boolean intervalleDatesSIntersectent(IntervalleDates intervalle) int hashCode()

boolean equals(Object obj) String toString()

La classe IntervalleDates est accompagnée d’une classe déﬁnissant un comparateur : la classe ComparateurIntervalleDates, qui implémente l’interface java.util.Comparator. La classe ComparateurIntervalleDatesdéﬁnit la méthode comparequi est utilisée pour réaliser un ordre total sur une collection d’objets de type ComparateurIntervalleDates: compareretourne un entier négatif, zéro, ou un entier positif selon que le premier objet est « inférieur », « égal », ou « supérieur » au second objet.

Les objets sont ordonnés par leur date de début d’intervalle, puis par leur date de ﬁn d’intervalle en cas d’égalité. Par exemple, il est possible de créer un ensemble triéTreeSet<IntervalleDates>en fournissant un objet comparateur au constructeur :new TreeSet<>(new ComparateurIntervalleDates()).

La classe ...csc4102.utilisationdelabibliothequeutil.ExempleManipulationsIntervalleDates dans le projet GitLab csc4102-exemples donnent des exemples d’utilisation des classes IntervalleDates et ComparateurIntervalleDates.