Cet article est écrit en collaboration avec Simon Black (Directeur principal de l'évangélisation et de l'habilitation technique), Alistair Crawford (Évangéliste de solutions), et Adrien Preston (Évangéliste des solutions).

Le scénario

Comme nous l'avons évoqué dans notre blog sur la logistique de la chaîne du froid, nous avons eu le scénario de la logistique de la chaîne du froid et la manière de suivre le transport de marchandises à température contrôlée. Pour y parvenir, nous avons utilisé Mendix pour créer une interface d'application Web prise en charge par les services AWS. À l'aide de ces outils, nous avons voulu créer :

• Une application Web pour les utilisateurs de bureau
• Une version mobile pour le personnel sur le terrain
• L'architecture cloud AWS de support pour traiter et fournir les données

Création de la partie démo 1 : IoT et AWS

Pour simplifier la démonstration de données réelles (et pour supprimer le besoin d'un camion physique avec des capteurs), nous avons décidé de construire un simulateur de données que nous utiliserions ensuite pour alimenter les services AWS en données.

Pour gérer les données IoT dans AWS, nous avons choisi d'utiliser AWS Timestream, c'est donc par là que nous avons commencé. Nous avons créé un flux de données à partir de Timestream qui représentait les données des capteurs pour la température et l'humidité. Nous aurions également besoin des données de parcours et des données des appareils IoT finaux, des serrures et du compresseur de secours.

Les verrous sont une simple valeur booléenne à stocker, qu'ils soient activés ou non. Le compresseur de secours est également une valeur booléenne activée ou désactivée, mais elle serait renvoyée dans le simulateur pour les données Timestream afin que les données de température aient tendance à baisser lorsque le compresseur est activé.

Nous avons également décidé d'implémenter une fonctionnalité AWS supplémentaire : la reconnaissance d'image. Dans le scénario qui nous a été donné, les camions transporteraient des produits frais, dans ce cas des fruits, et ils devaient être inspectés à la livraison. Une fois la livraison terminée et la personne inspectant les marchandises à l'autre bout prenant une photo, nous pouvions l'exécuter via AWS Rekognition et détecter si le produit était bon ou mauvais.

Voici un bref aperçu de la manière dont chacun de ces ensembles de données et fonctions a été créé dans AWS.

Configuration d'AWS IoT

Pour recevoir les données des appareils, nous avons exploité AWS IoT Core. Nous avons d'abord besoined pour configurer nos appareils également connus dans l'IoT sous le nom »Choses»Nous avons mis en place un "Chose » pour nos données de véhicule du camion et une autre chose pour chaque conteneur du camion. Cela nous aidera à suivre le véhicule et à surveiller l'état des conteneurs. 

Une fois ceux-ci configurés avec les politiques de sécurité appropriées, nous avons automatiquement accès aux mécanismes de publication et d'abonnement MQTT utilisés pour envoyer et recevoir des données.

Enfin, nous pouvons configurer une règle dans AWS IoT Core qui stockera les données entrantes de nos véhicules et conteneurs dans un TimestreamDB pour une utilisation ultérieure.

Configuration de la base de données Amazon Timestream

Amazon Timestream Database est simple à configurer. Nous avons créé une base de données appelée « logistique » et à l'intérieur de celle-ci une table appelée « conteneur » pour contenir les données des capteurs de conteneur et une table appelée « transport » pour recevoir les données des camions.

Pour que des données historiques soient disponibles dans la base de données Amazon Timestream peu de temps après le démarrage de l'application, celle-ci initialise « Things » en ajoutant un ensemble d'enregistrements générés de manière aléatoire à la base de données. Cette opération est réalisée à l'aide d'une action Java qui s'interface avec le SDK Java AWS pour accéder à la fonction d'écriture d'enregistrements Timestream.

Par la suite, de nouvelles données sont ajoutées aux tables de base de données par des règles dans AWS IoT Core. Les règles prennent les messages sélectionnés qui ont été publiés par le capteur/simulateur via AWS IoT Core et les écrivent dans la table de base de données spécifiée.

Une fois le flux de base de données AWS Timestream opérationnel, nous avons dû créer des données de parcours.

Générer des données de voyage

Dans un scénario réel avec suivi de trajet et d'appareil, notre camion serait généralement équipé d'un module GPS pour envoyer des données de localisation, de cap et de vitesse. Cela nous donnerait les données de latitude, de longitude, de MPH (ou KPH) et d'accélération.

Pour notre simulation de voyage, nous avons utilisé des itinéraires de simulation existants, accessibles au public grâce à AWS. Ils disposent d'un grand nombre d'itinéraires statiques comportant une origine, une destination, puis un ensemble d'étapes ou de points qui se situent entre eux selon un modèle réaliste. Tout cela est au format JSON et facilement assimilable.

Pour la plupart des autres données de capteur, nous avons utilisé des mathématiques simples pour générer des valeurs aléatoires qui se situent dans nos seuils, par exemple la température et l’humidité.

Après avoir généré les données de trajet afin de pouvoir simuler le suivi du camion, nous avons ensuite dû implémenter les fonctions de reconnaissance d'image et créer l'ensemble de données.

Reconnaissance AWS

Pour simplifier le processus d'inspection de la qualité des produits (dans notre cas, des fruits), nous avons décidé d'implémenter une certaine IA. AWS propose une gamme de solutions de Machine Learning et d'IA conçues pour plusieurs types de scénarios. Pour la reconnaissance d'images et de vidéos, AWS fournit AWS Rekognition. Rekognition fournit une gamme de modèles de machine learning pré-entraînés, et vous permet également d'entraîner les vôtres. Pour notre cas d'utilisation, nous voulions permettre à l'utilisateur de prendre une photo d'un fruit et d'en inspecter la qualité.

Tout d'abord, nous avons dû entraîner notre modèle de reconnaissance à comprendre à quoi ressemblent les bons et les mauvais fruits. Pour créer un modèle efficace, il est important de disposer d'un bon ensemble de données. Plus nous sommes en mesure de fournir d'images pour entraîner le modèle, meilleurs seront les résultats que nous obtiendrons. Heureusement pour nous, il existait de nombreux ensembles de données ouverts et gratuits pour nous aider à accélérer notre développement. Nous avons trouvé cet ensemble de données qui contenait des milliers d'images représentant des fruits pourris et frais :

https://www.kaggle.com/datasets/sriramr/fruits-fresh-and-rotten-for-classification

Nous avons pris cet ensemble de données et l'avons téléchargé sur AWS S3, afin qu'AWS Rekognition puisse utiliser ces images pour s'entraîner et se tester. La création d'un modèle pour détecter des étiquettes personnalisées est simple et rapide. En 6 étapes, vous pouvez créer un modèle détectant des étiquettes :

Lors de la formation de l'ensemble de données, AWS Reconnaissance Vous pouvez étiqueter automatiquement vos images en fonction des noms de dossiers utilisés dans S3 ou vous pouvez ajouter des étiquettes manuellement. En raison du grand nombre de données, nous avons décidé d'utiliser l'attribution automatique d'étiquettes. Cela signifiet qui lors de la création de l'ensemble de données, nous n'avons pas eu à ajouter manuellement des étiquettes à chaque image  saved nous avons beaucoup de temps et d'efforts. Lors de la création d'un ensemble de données, il est important de fournir à la fois un ensemble de données de formation et un ensemble de données de test. Cela permet à AWS Reconnaissance à s'entraîner lui-même et à alors teste la précision du modèle construit à l'aide de l'ensemble d'entraînement. 

Une fois le modèle formé à l'aide des ensembles de données, ce qui peut prendre environ 30 minutes, le modèle doit être démarré. Une fois formé et démarré, le modèle est prêt à accepter les requêtes via l'API AWS, dont les détails peuvent être trouvés plus loin dans cet article, et à détecter les étiquettes en fonction d'une entrée d'image.

Construction de la démo partie 2 : Mendix

Pour démarrer la construction, nous avons élaboré des wireframes et des flux de processus et notre concepteur UX a proposé une conception Figma pour guider l'apparence de l'application.

Maintenant que nous savions à peu près à quoi cela ressemblerait, nous pouvions commencer à assembler les différentes pièces.

• intégrations
• Modèles de domaine
• Applications

La construction a commencé avec les outils d'administration pour prendre en charge le système et un moyen de préremplir le système avec des données. Nous avons créé les entités du modèle de domaine pour stocker les informations dont nous avions besoin pour les camions, leurs conteneurs, les conducteurs et les marchandises qui seraient transportées. Nous avons ensuite créé des routines pour préremplir ces données avec des exemples de données pour la démonstration et pour permettre à d'autres personnes de les utiliser facilement à l'avenir.

Les camions ont ensuite été liés aux données de voyage et les conteneurs ont été connectés à la source de données Timestream.

Intégration Mendix avec AWS Timestream
	Lorsque l'application Logistics doit récupérer les données IoT historiques de Timestream, elle doit pour cela configurer une instruction SELECT et l'exécuter via l'action Java de requête Timestream. Il s'agit d'une action Java conçue pour utiliser le SDK Java AWS afin d'exécuter des requêtes sur la base de données Timestream et de renvoyer les résultats.

Pour faciliter la génération des données et vérifier que tout fonctionne, nous avons créé quelques pages d'administration pour prévisualiser, modifier et exporter les données. L'exportation est particulièrement utile car les fichiers JSON que nous avons créés peuvent ensuite être utilisés comme source de données pour le pré-remplissage dans l'application de démonstration.

Ensuite, nous avons présenté sur une page de présentation les informations sur le camion et le conducteur que nous avions créées. Cela donne à un utilisateur du back-office la possibilité de choisir le véhicule qu'il souhaite examiner. Un seul véhicule a été mis en mouvement pour la démonstration, mais s'il y en avait eu plusieurs, il aurait été facile de choisir.

En cliquant sur un camion, vous obtenez une vue des détails de ce camion et de son statut actuel. C'est là qu'interviennent les informations simulées. En travaillant de haut en bas, nous avons commencé par le sélecteur de conteneur, car chaque camion de notre système possède deux conteneurs, ce qui contrôle la vue des moniteurs dans la section ci-dessous.

La carte en haut à droite est venue ensuite. MendixLe widget par défaut de est parfait pour afficher les emplacements, mais à l'époque, il n'avait pas d'option intégrée pour dessiner la ligne d'itinéraire ou afficher facilement le camion en mouvement. Une recherche rapide sur le marché n'a rien donné qui corresponde exactement à ce que nous voulions, nous avons donc créé notre propre widget widget enfichable en utilisant React et JavaScript. Ce nouveau widget affiche la ligne de l'itinéraire, le camion se déplaçant le long de la ligne et la direction dans laquelle il se dirige.

La section inférieure affiche les mises à jour de la température et de l'humidité dans le conteneur sélectionné et les produits qu'il transporte. De plus, les boutons pour le compresseur de secours et les verrous. Tout cela devait être connecté à nos données Timestream.

Les données sont ensuite régulièrement actualisées pour fournir des informations à jour. Toutes les alertes déclenchées par le dépassement du seuil de température ou d'humidité sont transmises au client via un socket Web pour une mise à jour quasi instantanée. Nous avons étendu cette fonctionnalité avec Amazon SNS pour proposer également des notifications par SMS et par e-mail.

Toutes les actions sont enregistrées et présentées dans une chronologie indiquant les événements clés du trajet du camion, depuis les alertes jusqu'au moment où les portes sont verrouillées, en passant par leur déverrouillage. Toutes les données des capteurs sont également présentées dans une vue détaillée.

La dernière pièce du puzzle est l'application mobile destinée aux utilisateurs sur le terrain. Pour cette démonstration, nous avons décidé d'utiliser une application Web réactive plutôt qu'une application mobile native, de sorte qu'une grande partie de la conception était réutilisable entre le système de back-office et la version mobile.

La dernière chose à mettre en œuvre a été le formulaire d'inspection et l'API Rekognition. Le formulaire est assez simple : une photo des marchandises, la date d'arrivée et une évaluation de leur état. Une fois la photo prise, elle est envoyée à l'API Rekognition, que nous avons formée pour reconnaître les bonnes et les mauvaises pommes sur la base d'un large échantillon d'images. Elle renvoie une évaluation de la qualité des bonnes ou des mauvaises pommes et du degré de confiance dans le résultat.

Intégration Mendix avec AWS Rekognition

C'est facile à intégrer Mendix avec AWS Rekognition. AWS propose souvent plusieurs façons d'intégrer sa plateforme. Vous pouvez soit utiliser le SDK en utilisant le langage de votre choix, soit choisir d'utiliser l'API sous-jacente. Avec Mendix nous avions deux options : soit utiliser le SDK AWS Java, soit intégrer les API à l'aide du Mendix Actions REST Microflow. Nous avons choisi d'emprunter la voie REST, pour minimiser nos dépendances Java et utiliser autant de natifs que possible Mendix aussi possible (Mendix étant de loin la voie la plus simple et la plus rapide, car l'intégration avec une API REST est un processus simple, contrairement à l'intégration avec un SDK que nous ne connaissons pas.)

Nous nous sommes d'abord concentrés sur la mise en œuvre de l'activité principale, qui consistait à détecter les étiquettes personnalisées. Grâce à cette API, nous avons pu créer le mappage dans Mendix: https://docs.aws.amazon.com/rekognition/latest/APIReference/API_DetectCustomLabels.html

Tout d’abord, nous avons créé un extrait JSON pour la réponse et un mappage d’importation pour traiter la réponse.

Ensuite, nous avions besoin d'un moyen d'envoyer l'image à AWS dans un attribut « Bytes » sous forme de chaîne codée en Base64. Pour ce faire, nous avons créé une définition de message pour le Mendix System.Image, sélectionnez l'attribut Contenu et modifiez le nom externe en : « Octets ».

Nous avons ensuite utilisé un mappage d’exportation et la définition de message ci-dessus, nous permettant de convertir l’image au bon format JSON.

Enfin, un appel Microflow est nécessaire pour envoyer l'image à AWS Rekognition et renvoyer les étiquettes détectées par le modèle d'apprentissage automatique. Dans cet appel Microflow, nous avons une série de paramètres requis par AWS Rekognition. Tout d'abord, Microflow exporte l'image vers une chaîne d'objet JSON avec un attribut appelé « Bytes ». Celui-ci est ensuite utilisé avec les autres paramètres à l'intérieur de la charge utile pour l'action REST.

Dans l'action REST, nous définissons l'emplacement en utilisant la région AWS transmise dans le paramètre. Ajoutez les en-têtes HTTP requis par l'API. Ajoutez la charge utile de la requête nécessaire et le mappage de réponse.

La dernière pièce magique que nous avons construite pour notre démonstrateur est un peu plus technique. sous les couvertures. Les API AWS nécessitent que chaque appel d'API soit signé à l'aide d'un processus appelé Sig4. Il utilise AccessKey et SecretKey pour signer la requête HTTP avant son envoi afin de garantir son authenticité. Dans le microflow après démarrage, nous avons ajouté une action Java pour intercepter tous les appels à AWS Rekognition et ajouter les en-têtes Sig4 supplémentaires requis avant l'envoi.

Toutes les intégrations à AWS Rekognition et à Sig4 Interceptor seront disponibles sur le Mendix Marketplace prochainement. Cela simplifie encore davantage l'intégration à AWS Rekognition, vous permettant d'utiliser AWS Rekognition comme illustré dans la vidéo.

Pour finir

Nos applications de démonstration montrent comment un produit peut être suivi et surveillé pendant son transport de la source au magasin. Nous avons utilisé AWS IoT Core pour surveiller la température, l'humidité et l'emplacement avec les services AWS Timestream et analysé les images avec Rekognition. Ensuite, nous avons utilisé Mendix pour créer rapidement un front-end réactif pour se connecter à ces services et proposer les données, en temps réel, à plusieurs types d'appareils.

Si vous souhaitez en savoir plus sur la façon dont vous pouvez utiliser Mendix et AWS, inscrivez-vous à notre webinaire du 30 juin où nous présenterons les possibilités du Mendix Plateforme optimisée par les services AWS. Nous avons préparé une démo dans laquelle vous verrez une application intelligente en cours de création pour améliorer la logistique du transport des denrées périssables. Inscrivez-vous ici!