<figure><img src="image_33.png" /><figcaption>FIGURE 3.14 – Les liaisons complètes entre les défis Input et Output.</figcaption></figure>

sachant que :

$$ W_{P,C} + W_{S,C} + W_{H,C} + W_{I,C} + W_{E,C} + W_{Cn,C} + W_{d,C} + W_{Cu,C} + W_{T,C} + W_{G,QoS} = 1 \quad (3.15) $$

### 3.3.3 Les liens entre les défis

Les défis identifiés dans la première section sont bien corrélés avec les exigences industrielles (flexibilité, interoperabilité, QoS, communication en temps réel, sécurité, etc.). Afin de surmonter ces défis identifiés, une analyse de leurs interactions doit être faite, ce qui facilitera la conception des solutions efficaces. L'identification des liens se réfère au numéro de défi représenté par la Figure 3.15, qui sera expliqué ci-dessous.

#### H VS Coût (1-4) :

L'hétérogénéité des systèmes présents dans l'architecture, qui génèrent une grande quantité de données différentes, a un impact direct sur le coût d'installation et de gestion de ces données. La transmission, le traitement et le stockage de ces données dans les FNs nécessitent une puissance de calcul coûteuse. L'intégration
<figure><img src="image_34.png" /><figcaption>FIGURE 3.15 – Les défis liés au Fog Computing.</figcaption></figure>

des protocoles de communication performants, des adaptateurs, des modules et des FNs adéquats avec le reste des systèmes hétérogènes existants augmente le coût du Fog Manufacturing.

Par la suite l'hétérogénéité a un effet direct sur le coût. Il est donc important de prendre le défi du coût en considération lors de la recherche des solutions afin d'homogénéiser l'environnement du Fog Manufacturing.

L'hétérogénéité touche aussi à la capacité de stockage de chaque dispositif, qui est très limitée pour certains. Homogénéiser les capacité de stockage est primordial afin de supporter la quantité de calcul de données acheminée tout le long de l'architecture. Renforcer ces capacités limitées de stockage rajoute des coûts supplémentaires.

### H VS Consommation d'énergie (1-5) :

Le fonctionnement hétérogène des systèmes industriels consomme d'une manière différente les ressources énergétiques. L'utilisation du Fog Computing augmente cette demande énergétique à cause de la puissance électrique nécessaire au fonctionnement des différentes nœuds de Fog. D'autre part, l'architecture distribuée permise par le Fog Computing peut être exploitée pour limiter cette consommation croissante.

Au regard des exigences d'optimisation de la consommation d'énergie, la maîtrise de cette consommation constitue un véritable défi à relever notamment au regard de la forte demande des systèmes hétérogènes pour la fourniture d'énergie. En ce qui concerne les exigences d'optimisation de la consommation d'énergie, la maîtrise de cette consommation composite constitue un véritable défi à relever, notamment en ce qui concerne la forte demande des systèmes hétérogènes pour la fourniture d'énergie.

### H VS I (1-6) :
Les sources industrielles hétérogènes génèrent des données de formes et de types divers qui sont recueillies. L'hétérogénéité des données augmente l'interopérabilité du système, mais l'utilisation de la couche de Fog la réduit, car le Fog computing peut faire un pont efficace entre les différents dispositifs du système industriel.

Cependant, l'homogénéisation du flux de données augmentera l'interopérabilité, car l'adaptation des différentes formes de données assurera une communication facile entre des dispositifs hétérogènes. Une classification en fonction de la source homogénéisera le flux de données et rendra la communication interopérable.

L'interopérabilité et l'hétérogénéités sont deux défis qui se dirigent vers la même direction, résoudre l'hétérogénéité des systèmes d'exploitation, des données et des protocoles augmente l'interopérabilité de l'environnement. Cette dernière est la solution pour homogénéiser les échanges dans un atelier industriel.

**H VS QoS (1-7) :**

La QoS est considérée comme l'indicateur de performance le plus important du Fog Computing. Cependant, l'hétérogénéité des données peut avoir des effets qui dégradent les métriques de la QoS. Lorsqu'un système envoie un tel format de données à un système différent, un refus de réception va causer une perte de requête. Cette perte de données augmente le délai de transmission et entraîne une retransmission. Cet effet diminue forcément la QoS.

La QoS est considérée comme l'indicateur de performance le plus important pour évaluer l'état et l'efficacité du processus de communication. Considéré comme un défi Output, l'homogénéisation des données générées et transmises réduira le délai de transmission et de traitement, ce qui augmentera directement la QoS.

Les FNs peuvent servir d'intermédiaire entre les systèmes connectés qui sont à la fois hétérogènes et distribuent le calcul sur l'ensemble de l'usine.

**S VS P (2-3) :**

L'intégration des politiques de sécurité dans une architecture basée sur le Fog Manufacturing dépend du choix des FNs. Ces FNs doivent respecter plusieurs caractéristiques (la capacité de stockage, la capacité de traitement, la confidentialité des données, etc.) afin de pouvoir supporter les protocoles de sécurité et de cryptage de données.

L'amélioration de l'infrastructure industrielle avec de nouvelles fonctionnalités ou la suppression de celles qui ne sont pas nécessaires abaissera le niveau de sécurité, comme certaines fonctionnalités intègrent des politiques de sécurité. La sécurité est influençable par la programmabilité des FNs.

**S VS Coût (2-4) :**

La sécurité est un défi Input influant les défis Output. Un lien entre la sécurité des échanges et le coût de la solution basée sur le Fog Manufacturing existe.

Le fait d'insérer une couche intermédiaire génère des risques de sécurité supplémentaire. Le Fog distribue le calcul des données sur un nombre évolutif des nœuds, ce qui fait que garantir la sécurité des différents niveaux d'une architecture basée sur le Fog représente un défi d'investissement.

L'installation des politiques de sécurité partout dans le réseau augmente les coûts logiciels et de traitements. Posséder une architecture sécurisée au moindre coût est un défi à relever.

**S VS I (2-6) :**

L'utilisation de systèmes autonomes interopérables qui appliquent l'aspect lecture seule pour partager leurs données, comme le protocole MTConnect (LEE, BAGHERI et KAO, 2015), peut protéger les dispositifs et les données échangées, ce qui augmente la sécurité du CPS d'une application basée sur le Fog Manufacturing.
#### S VS QoS (2-7) :

Comme la fiabilité et la perte de données font partie des indicateurs de performance de la QoS, la sécurisation des échanges entre les différentes couches augmente ces caractéristiques de QoS.

Cependant, renforcer le canal de transmission avec plus de politiques de sécurité pèsera sur le traitement des données car il faut plus de temps pour crypter et décrypter les données envoyées, ce qui augmente les délais de transmission et de traitement au niveau de chaque nœud. Il faut équilibrer le lien entre ces deux défis.

#### P VS (Coût & Consommation d'énergie) (3-4) :

La programmabilité permet d'intégrer de nouvelles fonctionnalités aux fonctionnalités existantes, elle devient coûteuse surtout lors de l'ajout de d'extensions de stockage et de calcul. Cependant, obtenir des FN programmables distribuées qui supportent l'évolutivité est considéré comme une solution économique pour ajouter en permanence de nouvelles fonctionnalités. Ainsi la programmabilité évite les modules inutiles qui consomment de l'énergie et optimise les fonctionnalités pour diminuer la consommation électrique.

#### P VS I (3-6) :

La programmabilité est liée à l'interopérabilité, elle nécessite l'accès aux données et aux fonctionnalités de différents dispositifs pour les manipuler, ce qui est impossible sans protocole de communication interopérable, tel que le protocole MT-Connect (ibid.). Même l'ajout de nouveaux modules programmables nécessite une communication interopérable pour intégrer les fonctionnalités.

#### P VS QoS (3-7) :

La programmabilité des FNs permet d'ajouter d'une manière fluide de nouvelles fonctionnalités et modules, de mettre à jour les fonctionnalités existantes et d'augmenter la flexibilité du système. Cette notion de programmabilité augmente la flexibilité des applications industrielles. Par conséquent, la flexibilité mène à mieux s'adapter aux besoins des systèmes de production et de fournir des décisions précises et en temps réel, ce qui améliore la QoS.

#### Coût VS Consommation d'énergie (4-5) :

Les industries prêtent attention à l'aspect économique. Le coût de la solution basée sur le Fog Manufacturing a un grand rôle pour encourager les investisseurs du secteur industriel.

Les systèmes de production respectueux de l'environnement constituent un enjeu important pour l'Industrie 4.0. La consommation d'énergie devrait être optimisée afin de réduire les coûts de la production et la pollution.

L'utilisation d'une couche supplémentaire de Fog computing augmente logiquement le coût et la consommation d'énergie, mais une architecture basée sur le Fog peut être conçue pour réduire la consommation d'énergie en raison de l'aspect distribué du Fog Manufacturing.

Par conséquent, l'adoption d'une stratégie économique de consommation d'énergie est un défi à relever. La modélisation de l'architecture permettra d'optimiser le coût d'installation en terme de l'énergie consommé par chaque FNs

#### Consommation d'énergie VS QoS (5-7) :

Il faut assurer un équilibre et une stabilité entre les exigences des utilisateurs (qualité de service) et celles des fournisseurs (Consommation d'énergie). Pour augmenter la QoS, il faut intégrer des améliorations logicielles et matérielles. Cette couverture des besoins des applications va causer une augmentation de la consommation d'énergie.
Ce lien entre les deux défis Output nécessite un traitement équitable pour les sur-
monter. L'optimisation de la consommation énergétique du matériel assurant l'archi-
tecture basée sur le Fog manufacturing doit être prise en considération.

I VS QoS (6-7) :

L'interopérabilité des systèmes de production permettra de réduire le délai de transmission et de traitement. Le format utilisé sera compréhensible par tous les systèmes, ce qui réduira le délai d'échange entre la FN et les points d'extrémité, ce qui permet de relever le défi de la QoS.

Les défis sont corrélés, ce qui signifie que satisfaire certains autres défis facili-
tera leur résolution. Les quatre défis en entrée, comme présentés sur la Figure 3.5
influencent directement les défis en sortie : la QoS, le coût et la consommation élec-
trique. Les liens entre les différents défis (Input et Output) sont définis afin de les
satisfaire par la mise en œuvre du Fog Manufacturing.

## 3.4 Les possibles applications du fog computing dans le contexte de l'Industrie 4.0

Malgré les nombreux avantages du Fog computing, son adoption reste limitée dans le contexte d'Industrie 4.0. Les défis identifiés dans la section précédente re-présentent une barrière : le coût de la solution basée sur le Fog Manufacturing doit être optimisé ainsi que la consommation d'énergie. La couche du Fog doit maintenir un haut niveau de QoS sans oublier de considérer les caractéristiques du Fog computing (Hétérogénéité, Interopérabilité et programmabilité).

Un autre obstacle freinant l'adoption du Fog Manufacturing est estimé très important de notre point de vue : nous pouvons en effet considérer que les industriels n'ont pas une réelle évaluation précise de la valeur ajoutée du Fog Computing. Il manque une étude pour identifier les domaines où il est (clairement) avantageux d'intégrer les caractéristiques du Fog computing.

L'Industrie 4.0 regroupe un ensemble d'applications qui varient sur l'ensemble de la chaîne de production, qui peut concerner différentes étapes du cycle de vie (Beginning of life BOL, Middle of life MOL, End of life EOL). Chacune s'occupe d'un processus spécifique et se caractérise par des besoins matériels et logiciels spécifiques.

Nous introduisons ici un indicateur que l'on a choisi d'appeler le "degré d'uti-
lité" pour mesurer l'adaptabilité du Fog computing pour chaque domaine d'appli-
cation industriel. Cet indicateur est déterminé en fonction du nombre de services
fournis ou besoins satisfais par les caractéristiques du Fog computing. Certains do-
maines d'application présentent plus de besoins que les autres, ce qui augmente les
chances d'intégration du Fog Manufacturing.

Les **aspects de mesure** que l'on a identifiés (l'aspect temps réel, le traitement de données, la quantité de données, la mobilité, la distribution, l'hétérogénéité) sont choisis en fonction des caractéristiques du Fog computing adopté en général. Ces aspects de mesure sont utilisés dans des applications identifiées, certains auteurs les considèrent d'ailleurs comme étant des caractéristiques de base pour leurs cas d'études.

L'exploration de ces caractéristiques est très importante pour l'amélioration ou
les travaux à venir. Le concept émergeant de l'Industrie 4.0 a un impact sur un grand
nombre de services industriels, et il fait évoluer leur mode de fonctionnement et
leurs besoins. Par exemple, le passage d'une application industrielle traditionnelle
à la vision Industrie 4.0 exige l'addition de l'aspect temps réel ou la mobilité en cas
de présence de robots ou CPS mobiles. Cette amélioration pourrait augmenter les performances de l'application. Par conséquent, les applications choisies sont considérées comme des propositions de mise en œuvre du Fog Manufacturing.

À cette étape, nous avons passé en revue un grand nombre de travaux afin de faire correspondre les besoins des applications industrielles traditionnelles existantes aux caractéristiques du Fog computing identifiées (les aspects de mesure). Tant que le domaine d'application supporte un ou plusieurs aspects de mesure, le degré d'utilité s'incrémente.

Le tableau 3.2 donne quelques exemples de domaine d'applications industrielles où le Fog Manufacturing peut être mis en œuvre. Il présente également le degré d'utilité du Fog computing pour chaque application.

Ce tableau est constitué à partir de l'étude bibliographique afin d'identifier l'ensemble des applications potentielles. Pour chaque domaine d'application on a visé un groupe d'articles qui concerne l'application en domaine industriel et étudié ses besoins en se projetant dans le contexte de l'Industrie 4.0. La sélection des caractéristiques présentées est une conclusion des sections précédentes qui relie les caractéristiques du Fog computing avec les besoins des applications de l'Industrie 4.0.

Compte tenu de la migration vers le paradigme Industrie 4.0, une telle description permet d'adopter le Fog computing tout en améliorant l'ensemble des applications industrielles traditionnelles. Une application basée sur le Fog computing peut non seulement améliorer les performances du Cloud Manufacturing mais aussi ouvrir de nouveaux horizons en termes de distribution, d'interopérabilité, de flexibilité et de rapidité.

A l'aide de cette étude, nous avons sélectionné le domaine d'application de logistique sur lequel on va intégrer la solution du Fog Manufacturing comme il présente le degré d'utilité le plus élevé.

Pour la construction du tableau 3.2, nous nous sommes basés non seulement sur l'état de l'art mais aussi sur la conclusion des autres sections développées tout au long de ce chapitre.
<table><caption>TABLE 3.2 – Les applications possibles du Fog Manufacturing.</caption><thead><tr><th>Application</th><th>Aspect temps réel</th><th>Traitement de données</th><th>Quantité de données</th><th>Mobilité</th><th>Distribution</th><th>Hétérogénéité</th><th>Degré d'utilité</th></tr></thead><tbody><tr><td>Logistique</td><td>✓</td><td>✓</td><td>✓</td><td>✓</td><td>✓</td><td>✓</td><td>6</td></tr><tr><td>Consommation d'énergie</td><td>✓</td><td>✓</td><td>✓</td><td>✓</td><td>✓</td><td>✓</td><td>6</td></tr><tr><td>Traçabilité</td><td>✓</td><td>✓</td><td>✓</td><td>✓</td><td>✓</td><td>✓</td><td>6</td></tr><tr><td>La disponibilité des systèmes de production distribué</td><td>✓</td><td>✓</td><td>✓</td><td>-</td><td>✓</td><td>✓</td><td>5</td></tr><tr><td>Localisation en intérieur</td><td>✓</td><td>✓</td><td>✓</td><td>✓</td><td>✓</td><td>-</td><td>5</td></tr><tr><td>Processus d'ingénierie virtuelle</td><td>✓</td><td>✓</td><td>✓</td><td>-</td><td>✓</td><td>✓</td><td>5</td></tr><tr><td>Gestion du cycle de vie des produits</td><td>✓</td><td>✓</td><td>✓</td><td>-</td><td>✓</td><td>✓</td><td>5</td></tr><tr><td>Gestion (Collecte/Filtrage/Suppression) de données et Prise de décision</td><td>✓</td><td>✓</td><td>✓</td><td>-</td><td>✓</td><td>✓</td><td>5</td></tr><tr><td>Gestion de l'inventaire</td><td>✓</td><td>✓</td><td>✓</td><td>✓</td><td>✓</td><td>-</td><td>5</td></tr><tr><td>Supervision</td><td>✓</td><td>✓</td><td>✓</td><td>-</td><td>✓</td><td>✓</td><td>5</td></tr><tr><td>Scheduling</td><td>✓</td><td>✓</td><td>✓</td><td>-</td><td>✓</td><td>✓</td><td>5</td></tr><tr><td>Diagnostic et pronostic</td><td>✓</td><td>✓</td><td>✓</td><td>-</td><td>✓</td><td>-</td><td>4</td></tr><tr><td>Interaction homme-machine/robot</td><td>-</td><td>✓</td><td>✓</td><td>✓</td><td>✓</td><td>-</td><td>4</td></tr><tr><td>Automatisation des tâches manuelles</td><td>-</td><td>✓</td><td>✓</td><td>-</td><td>✓</td><td>✓</td><td>4</td></tr><tr><td>Monitoring en temps réel</td><td>✓</td><td>✓</td><td>✓</td><td>-</td><td>-</td><td>✓</td><td>4</td></tr><tr><td>Sécurité</td><td>✓</td><td>✓</td><td>✓</td><td>-</td><td>✓</td><td>-</td><td>4</td></tr><tr><td>Maintenance prédictive</td><td>-</td><td>✓</td><td>✓</td><td>-</td><td>✓</td><td>✓</td><td>4</td></tr><tr><td>Inspection</td><td>✓</td><td>✓</td><td>✓</td><td>-</td><td>✓</td><td>-</td><td>4</td></tr><tr><td>Identification et prédiction des systèmes dynamiques</td><td>-</td><td>✓</td><td>✓</td><td>-</td><td>✓</td><td>-</td><td>3</td></tr><tr><td>Évaluation des risques</td><td>-</td><td>✓</td><td>✓</td><td>-</td><td>✓</td><td>-</td><td>3</td></tr><tr><td>Système de contrôle de la qualité</td><td>-</td><td>✓</td><td>✓</td><td>-</td><td>-</td><td>-</td><td>2</td></tr></tbody></table>
## 3.5 Conclusion

Dans ce chapitre, les différentes applications basées sur le Fog Manufacturing ont été présentées à travers des cas d'études de la littérature, de façon à analyser leurs intérêts dans notre contexte applicatif. Par la suite, nous avons constaté que l'adoption du Fog Manufacturing reste modeste à cause de nombreux défis à relever. Les défis ont été identifiés et analysés afin de pouvoir surmonter les limitations d'adoption du Fog Manufacturing. Sur le plan théorique, nous avons identifié les PIs pour chaque défi et nous avons établi les liens entre eux. Cela peut avoir une importance non négligeable si nous souhaitons optimiser les défis simultanément. Comme perspectives, ces liens peuvent être écrits sous forme d'équations séquentielles afin de définir des probabilités bien déterminées, et pouvoir mesurer chaque défi. Nous avons ainsi proposé plusieurs applications pour l'Industrie 4.0 à travers lesquelles il est possible d'intégrer le Fog computing selon un certain degré d'utilité.

Dans la suite de ce mémoire, nous allons nous attacher à détailler notre cas d'étude en proposant un modèle d'optimisation des coûts d'installation de l'architecture basée sur le Fog Manufacturing. Cette solution sera par la suite implémentée afin d'évaluer ses performances vis-à-vis des critères comme la consommation d'énergie et le délai.
<figure><img src="image_35.png" /></figure>
# Chapitre 4

# Déploiement optimal du Fog
# Computing pour la logistique
# interne dans le contexte de
# l'Industrie 4.0

## 4.1 Introduction

Après avoir examiné dans le chapitre 2 les travaux de la littérature sur les applications de l'Industrie 4.0 intégrant une architecture basée sur le Fog computing, nous proposons un modèle d'optimisation du coût du déploiement d'un réseau à plusieurs niveaux contenant une couche Fog. Ce réseau est utilisé pour la gestion d'un atelier de production flexible (usine 4.0) contenant une flotte de robots mobiles et des machines intelligentes. Ceci représente un support pour l'utilisation des données pour la logistique interne dans un exemple d'usine 4.0 basée sur le Fog Manufacturing.

Dans ce chapitre, nous présentons dans un premier temps les travaux qui ont porté sur l'optimisation du coût de déploiement d'une architecture basée sur le Fog Manufacturing. Dans une deuxième partie, nous allons concevoir l'architecture adoptée lors de la modélisation du déploiement. Finalement, nous allons spécifier le modèle d'optimisation du coût, en détaillant les paramètres, toutes les contraintes adoptées et le résultat d'optimisation selon l'instance.

Ce problème devient encore plus complexe quand il s'agit d'entités intelligentes, communicantes et mobiles. C'est un problème d'actualité concernant l'introduction des IoTs dans le domaine industriel. Il faut noter que le problème occupe une importance majeure pour les industriels qui sont en phase de passage vers l'industrie 4.0 et la communauté de recherche à travers l'apparition de recherches similaires récemment (LIN et YANG, 2018YEH, LAI et TSAI, 2019). La décision de dimensionnement du réseau (nombre de ENs, FNs et passerelles et les types de liaison qu'il faut prendre en compte) influence en grande partie le coût d'investissement sur la nouvelle solution basée sur le Fog. Le type de décision rentre dans le domaine de décision stratégique ou tactique qui ne peut pas être changé tous les jours et qui affecte le fonctionnement de tout l'atelier de production pour une longue période.
## 4.2 La logistique dans le contexte de l'Industrie 4.0

### 4.2.1 Contexte

Bien que le Cloud Computing offre des ressources de calcul élevées rendant le traitement des données extrêmement efficace, le mouvement des données qui en résulte pourrait avoir un impact sur les performances de l'application en raison d'éventuelles latences importantes de la transmission. Pour améliorer ce type d'applications, une bonne gestion de l'information devient fondamentale pour livrer l'information au bon moment, au bon endroit, avec une bonne qualité et avec un coût minimal (BILL, 2016).

La logistique, en tant que partie importante du processus industriel, doit s'adapter et profiter de la succession des révolutions technologiques telles que l'IoT le cloud et la vision industrielle. Le processus logistique à l'intérieur de l'atelier implique de nombreux types de systèmes connectés tels que des AGV (véhicules guidés automatisés, qui suivent des routes pour transporter des matériaux et des produits dans l'atelier de production), des machines de production, des postes manuels, des stocks, des tablettes d'opérateurs, etc.

Les manières et technologies ordinaires qui soutiennent la logistique industrielle ne sont plus suffisantes pour les exigences de l'Industrie 4.0. En effet, le système de pilotage est amené à prendre de multiples décisions d'une manière complètement autonome sans pour autant dévier l'objectif global de l'atelier. C'est pourquoi l'intégration des fonctions du Fog Manufacturing est bénéfique (BOUZARKOUNA et al., 2018) vue la capacité de calcul au sein du réseau qu'il peut offrir. Compte tenu de l'importance d'une telle application pour le pilotage du transfert interne, l'Industrie 4.0 exige que les services logistiques deviennent de plus en plus intelligents, efficaces et réagissent en temps réel pour répondre au niveau élevé d'intelligence artificielle.

L'ajout des caractéristiques du Fog Manufacturing aidera à prendre rapidement la décision la plus adéquate pour améliorer les opérations logistiques. En connectant les serveurs du Fog au Cloud computing, on obtiendra davantage d'analyses qui permettront de gérer les futures tâches logistiques.

Pour intégrer le Fog Manufacturing, de nombreux aspects doivent être étudiés, en particulier la modélisation de l'architecture de l'application et l'optimisation du coût de l'installation d'une telle solution, avec la prise en compte des contraintes liées à la latence, la distribution et les limites de capacité de traitement et d'acheminement de l'information. Certains travaux s'intéressent à ce domaine de recherche comme (Qu et al., 2016), qui a présenté l'intégration Cloud Manufacturing dans la logistique de la production. Parmi les nombreuses applications de l'Industrie 4.0, présentées dans le chapitre 3 précédant, l'intégration du Fog Manufacturing pour optimiser les performances d'une application de logistique est présente.

### 4.2.2 Problématique du déploiement du Fog Manufacturing

L'intégration du Fog Manufacturing est certes un investissement pour les industries, mais elle doit être maîtrisée en termes de performance, de coût et de consommation énergétique. La solution Fog est non seulement composée des serveurs Fog mais également des liens avec toutes les couches de l'architecture. Chacune est constituée de nombreux noeuds connectés qui sont déjà installés (terminaux ou Cloud) ou à installer (des noeud edge EN, des noeud Fog FN et des passerelles).
<figure><img src="image_36.png" /><figcaption>FIGURE 4.1 – Le processus de décision opérationnelle basé sur le Fog Manufacturing.</figcaption></figure>

Le déploiement des noeuds constituant une architecture basée sur le Fog Manufacturing est une étape primordiale afin de préciser le coût d'installation et le coût de fonctionnement d'une telle architecture à long terme.

Une usine 4.0 est composée de nombreux systèmes connectés, pouvant être mobiles, qui assurent un bon déroulement de la production. Les AGVs par exemple sont importants pour la logistique et le transport des pièces entre les différents départements dans une usine, ils sont caractérisés principalement par la mobilité et la communication avec le système de supervision et les systèmes de production connectés. Un AGV doit être présent dans une zone incessamment couverte afin de ne pas interrompre la transmission des requêtes/réponses et également la bande passante doit être suffisamment large pour supporter le grand nombre de transmissions simultanées.

Afin de soutenir un bon niveau de réactivité en temps réel, il est nécessaire d'adopter une stratégie de déploiement des noeuds de l'architecture réseau afin de satisfaire les besoins en termes de couverture, bande passante et du coût d'installation et de fonctionnement. Un autre aspect à considérer lors du déploiement des noeuds, est de ne pas surcharger les réseaux par les requêtes des noeuds de communication et priver les utilisateurs de la rapidité à l'accès aux services principaux liés à la production.

Conséquemment, le déploiement des noeuds d'une architecture basée sur le Fog Manufacturing est une problématique d'importance majeure et complexe à la fois. Le dimensionnement du réseau concerne principalement le nombre des EN, FN et passerelles à installer ainsi que le type de lien adéquat pour les installations des systèmes. La Figure 4.1 présente un exemple de déploiement de l'architecture Fog Manufacturing, et présente un exemple des différentes parties qui peuvent être impliquées. Cette figure présente le processus de la prise des décisions opérationnelles à court terme. On remarque que chaque niveau présente un type de communication spécifique avec le niveau supérieur. Par conséquent, avoir spécifié le type des dispositifs et liens utilisés selon le besoin est nécessaire afin d'optimiser la solution basée sur le Fog. Les composants d'une telle architecture doivent couvrir les besoins de l'atelier de production et assister à la prise des décisions. Les décisions sont classées en trois catégories au niveau des industries, expliquées ci-dessous :

- Stratégiques (Long terme et coût important) : uniques, imprévisibles et irréversibles (changement coûteux) elles concernent l'ensemble de l'usine.
Exemples : fabrication d'un nouveau produit, suppression d'une activité, fu-
sion avec un autre domaine de production.

— Tactiques (Moyen terme et coût moyen) : ces décisions concernent la gestion ou le pilotage des tâches de production peu fréquentes et peu prévisibles.
Exemples : acquisition de matériel de production, recrutement.

— Opérationnelles (Court terme) : elles sont fréquentes et répétitives. Exemples : organisation des horaires des tâches, achat des matières premières, planification.

Le Fog manufacturing permet de gérer les décisions opérationnelles en temps réel tout en traitant d'une manière locale les demandes et décide d'une façon distribuée afin de fournir des solutions à court terme aux CPS de l'atelier de production. Les décisions concernant le déploiement des noeuds de l'architecture basée sur le Fog Manufacturing rentrent dans le domaine des décisions stratégiques ou tactiques qui ne peuvent être changées souvent et qui affectent le fonctionnement de tout l'atelier de production pour une longue période.

Si on opte pour la quantité, c'est à dire un grand nombre de noeuds, on va avoir une large couverture ce qui est sensée faciliter le traitement, mais en contre partie, on risque d'augmenter le coût et de surcharger le réseau par des noeuds connectés (Un grand nombre de transmissions et une haute consommation d'énergie) et sous exploités. La qualité est la deuxième option d'installation, ou on trouve beaucoup moins de noeuds qui ont plus de capacité de connexion et de couverture. Dans ce cas, on gagnera certes en terme de coût et d'installation mais on risque d'augmenter les délais de prises de décision et de limiter la flexibilité de l'architecture. C'est pourquoi le placement de différents composants de l'architecture est une décision à la fois stratégique et tactique qui mène à une meilleure prise des décisions opérationnelles. Par exemple, le déploiement peut affecter la couverture réseau des AGVs circulant dans l'atelier : si on sur-déploie des ENs on aura un coût élevé dû à l'achat d'un grand nombre de noeuds EN. Par contre si l'on sous-déploie des ENs, les AGVs vont traverser des zones non couvertes ce qui peut générer des risques de perte d'information et de prise de décision à l'aveugle. La figure 4.2 présente les trois cas possibles de déploiement pour les ENs tout en prenant en compte la mobilité des robots. Les couleurs de cercles de couverture distinguent les différents ENs.

Un autre exemple, qui montre l'importance et la délicatesse d'une telle problé-
matique, est la liaison avec la consommation d'énergie des noeuds installés. Il faut
bon étudier les besoins de chaque zone en fonction de l'ensemble de ces systèmes
connectés. Dans une usine, il existe des zones de faible productivité ou de faible va-
leur ajoutée. Par conséquent il ne sera pas optimal d'investir dans cette zone et il est
préférable de consacrer du budget dans les zones où le besoin est le plus important.
Sur la figure 4.3, on remarque la présence de la même concentration des noeuds
sur l'ensemble de l'usine. Par contre chaque zone (I, II et III) possède une activité
différente. Sur les zones I et II, la présence massive des noeuds est utile comme il
existe une productivité et mobilité importantes. Par contre la zone III (entourée du
cercle jaune) ne possède qu'un poste manuel, donc les noeuds présents consomment
de l'énergie sans sollicitation. Nous pouvons conclure qu'un mauvais déploiement
aura des conséquences non seulement à court terme (Coût d'installation) mais aussi
à long terme. Le nombre et la position des noeuds aura aussi un effet sur le coût de la
maintenance. La multiplication des noeuds augmente la probabilité d'intervention
et ainsi les coûts de maintenance associés.

De nombreux travaux s'intéressent à l'optimisation du coût et du placement des
noeuds constituant le réseau du Fog Manufacturing. Les travaux de (GU et al., 2015)
se sont intéressés aux CPS médicaux (MCPS). Pour répondre à la haute QoS des
<figure><img src="image_37.png" /><figcaption>FIGURE 4.2 – Le problème de déploiement des ENs en terme de mobilité.</figcaption></figure>

<figure><img src="image_38.png" /><figcaption>FIGURE 4.3 – Le problème de déploiement des noeuds en terme de consommation d'énergie.</figcaption></figure>
MCPS et pour alléger la couche Cloud, ils proposent d'intégrer le Fog computing (FC-MCPS) et d'optimiser la gestion des ressources et la QoS. Un modèle d'optimisation du coût de la solution FC-MCPS est présenté tout en prenant en compte les contraintes de l'association des noeuds de communication et de calcul (FN) et la distribution des tâches. Afin d'atténuer la complexité du modèle, ils ont linéarisé sous la forme d'un problème de programmation linéaire mixte à nombres entiers (MILP). Les résultats obtenus par l'heuristique proposés par les auteurs ont montré des performances proches de la solution optimale.

Nous avons trouvé d'autres travaux qui ont étudié la même problématique tout en optimisant le coût de l'intégration du Fog computing comme dans (YAO et al., 2017 et WAN et al., 2018). Le déploiement des serveurs était optimisé afin d'améliorer la QoS.

Les travaux de (LIN et YANG, 2018) sont considérés comme les plus proches de notre cas d'étude comme ils s'intéressent au déploiement du Fog computing dans une application de logistique dans un contexte de l'Industrie 4.0. Leur but est d'optimiser le coût d'intégration du Fog computing (FN, EN et passerelles) sous les contraintes de capacité maximale de la demande, de latence maximale, de couverture maximale et de nombre maximal des liens. La résolution est faite à l'aide d'un algorithme méta-heuristique (un algorithme de singe discret génétique). Les résultats de la simulation ont montré que l'algorithme DMGA (Discrete Monkey Genetic Algorithm) proposé donne de bons résultats dans les cas problématiques des centres logistiques de taille moyenne.

Pour la majorité de ces travaux, le coût et l'emplacement des noeuds activés étaient les termes les plus importants à prendre en compte et à optimiser. Par contre, il serait intéressant d'étudier les effets de déploiement sur les flux dynamiques des systèmes et des produits. Pour chaque partie de l'atelier il existe une dynamique (répétitive ou imprévue) des différentes tâches de production. Un déploiement basé sur le Fog aide à optimiser la mobilité, la QoS en terme de latence, de consommation d'énergie, etc,...

La mobilité, par exemple, est un enjeu fondamental dans le contexte de l'Industrie 4.0. De nombreux appareils mobiles (AGVs, Drônes, tablette d'opérateur,...) existent dans l'usine pour assurer la logistique et le déplacement des produits et des outils entre les différents départements et cellules de production. Chaque zone de l'usine possède des allées et corridors bien définis pour stabiliser les temps de déplacement et éviter les collisions. Chaque zone possède une probabilité de présence des AGVs selon le besoin et le volume de chacune.

Ainsi, les différents noeuds constituant l'architecture du Fog Manufacturing sont répartis dans l'ensemble de l'atelier. La prise en considération des emplacements initiaux des noeuds est importante comme cela facilite l'installation de certains noeuds après l'optimisation du déploiement. Par exemple l'emplacement de :

— L'alimentation électrique (prises) ou l'on peut brancher les FN et les EN,

— Les trajectoires fixes des déplacements des AGVs dans l'atelier.

Pour traiter les cas problématiques à plus grande échelle et avec un grand nombre des noeuds, il serait intéressant de proposer de nouvelles contraintes qui renforcent celles utilisées, pour avoir une optimisation plus efficace et réaliste. Les facteurs influençant le déploiement doivent également être examinés, par exemple le type de lien entre les différentes couches, la probabilité de présence des AGVs dans une zone bien définie, la consommation d'énergie, l'équilibre des charges, l'hétérogénéité, l'équité et la qualité de service (QoS).
<figure><img src="image_39.png" /><figcaption>FIGURE 4.4 – L'architecture basée sur le Fog Manufacturing.</figcaption></figure>

## 4.3 L'architecture du Fog Manufacturing

Dans cette section, nous présentons l'architecture basée sur le Fog Manufacturing que nous allons adopter tout au long de ce chapitre. Cette architecture ainsi que les liens entre ces différentes couches superposées, va être modélisée afin d'optimiser le coût de déploiement de ces noeuds hétérogènes.

Dans notre travail nous avons choisi l'architecture évoluée qui comporte 5 niveaux (les terminaux connectés, les noeuds Edge, les serveurs Fog, les passerelles et la couche Cloud). Les raisons derrière ce choix sont :

- La mobilité de certains CPS présents dans l'atelier de production,

- La distribution à grand échelle des CPS dans l'atelier,

- La nécessité de contrôle de la quantité de données transmise entre deux niveaux.

Cette architecture fournit des fonctions de calcul, de réseau et de stockage plus complexes et plus étendues. Les noeuds de l'architecture Fog intègrent des fonctions de distribution, de coordination, de gestion et de protection des ressources de réseau croisées, ce qui assure les services du Fog Manufacturing.

Les cinq couches communiquent entre elles pour assurer une transmission de données du niveau le plus bas jusqu'au Cloud. La couche Fog est adoptée pour assurer un calcul en temps réel distribué tout le long de l'atelier de production. La figure 4.4 présente l'architecture à cinq niveaux basée sur le Fog dans le contexte de l'Industrie 4.0.

### La couche des terminaux

Cette couche est la plus basse, elle regroupe un grand nombre des terminaux hétérogènes et distribués. Dans notre contexte de l'application de logistique de l'Industrie 4.0, les terminaux sont les CPSs ou des dispositifs IoT :

- Les AGVs,

- Les bras robotiques,
— La chaîne de production (les machines),

— Les postes manuels,

— Les machines de découpes laser et les imprimantes 3D,

— Les capteurs de présence, les caméras,

— ...

Les CPS sont équipés des capteurs qui visent à détecter/surveiller le processus de production. Chaque catégorie de CPS présente dans l'usine occupe un rôle spécifique.

Par exemple, les AGV permettent de planifier et gérer les tâches de logistique, le traitement des images et la navigation automatique, intégrant des répartitions des tâches, le transport des pièces ou produits entre les différents département et le calcul de l'inventaire à reconstituer à l'entrepôt. Les AGVs communiquent avec les autres CPS soit directement soit à travers l'architecture basée sur le Fog Manufacturing. Ils transmettent leurs demandes régulièrement afin de recevoir les données nécessaires à la prise de décision en temps réel.

Les bras robotiques sont généralement programmables, avec des fonctions de préhension et de placement de produits. Les segments de ces bras sont reliés par des axes permettant, soit des mouvements de rotation et/ou de translation. Ces mouvements sont nécessaires pour l'exécution des tâches répétitives et exigeant une haute précision. Ces robots peuvent être seuls ou fixés sur des AGVs pour être mobile et exécuter les tâches dans toute l'usine.

L'Industrie 4.0 est caractérisée par la mobilité et la personnalisation. C'est pour cela que des machines de fabrication additive, imprimantes 3D et des machines de découpes laser peuvent être présentes dans les usines. Ces CPS sont connectés et équipés des capteurs. Ils envoient d'une façon continue leur données (état, tâche, panne, disponibilités, etc.) et reçoivent des instructions ou décisions afin d'organiser les tâches selon la priorité et la quantité.

Les postes manuels permettant par exemple des opérations d'assemblage ou de contrôle, ont des emplacements fixes pendant l'activité de production mais peuvent être déplacés afin de réorganiser les flux et les configurations de production au sein de l'atelier.

Les machines sont souvent connues par la contribution directe au processus de production. Elles sont capables de produire, mais aussi de servir à conditionner, transformer et façonner des matières afin d'obtenir un produit fini. Les machines s'appuient sur tous les autres CPS cités ci-dessus afin de répondre aux exigences de l'Industrie 4.0 en termes de qualité, rapidité et efficacité.

Les appareils mobiles utilisés par les opérateurs, représentent aussi des noeud CPS. A travers ces interfaces, les opérateurs envoient leurs rapports, souhaits et commandes. Les personnels sont également dotés de terminaux mobiles pour effectuer la supervision, la gestion, la maintenance et la prise de décisions stratégiques, tac-tiques ou opérationnels en cas d'urgence. Ces équipements doivent être dans des zones couvertes et connectés au système d'information de l'atelier à n'importe quel moment.

## La couche du Edge computing

La couche du Edge est constituée des ENs, ils ne sont pas seulement utilisés pour la transmission de données des CPS aux FNs, mais fournissent également aux AGVs et autres CPS mobiles des réponses en temps réel lorsqu'ils rencontrent d'autres AGV sur la trajectoire du mouvement. Donc les ENs assurent la couverture réseau pour les systèmes mobiles afin de garantir la non rupture des échanges de données.
Les données nécessaires à la prise de décision sont identifiées et collectées par les ENs, et sont transmises aux FNs qui stockent et traitent temporairement les données, et renvoient les décisions aux CPS. Dans le même temps, les données sont également transmises aux serveurs de la couche cloud pour permettre par exemple des analyses basées sur les données d'historique et un stockage à long terme. Il existe plusieurs types de PA :

- Point d'accès sans fil,

- Modem,

- Routeur,

- Commutateur réseau (Switch),

- Concentrateur réseau

- Boitier Courants porteurs en ligne (CPL).

La plupart de ces équipements ont une autre finalité que le simple point d'accès. Par exemple, ils peuvent relier deux réseaux disjoints. Ces ENs sont multi-fonctions et généralement de type Wi-Fi IEEE 802.11n ou IEEE 802.11ac.

## La couche du Fog computing

L'introduction de la couche Fog permet aux CPS connectés d'échanger des informations pour coordonner les opérations. Les FNs sont déployés sur le bord du réseau et ils réalisent l'interaction entre les noeuds, la mise en cache des informations et le traitement des tâches, ainsi que certaines autres fonctions en périphérie du réseau. Les FNs s'occupent de la collecte des données générées par les capteurs. Certaines de ces données concernent le contrôle nécessitant un traitement en temps réel (ms). Ce premier niveau du Fog est conçu pour l'interaction machine-machine, la collecte, le traitement des données et l'émission des commandes aux actionneurs. Le Fog filtre également les données à utiliser localement et envoie le reste aux niveaux supérieurs. Toutes les interactions du Fog sont en temps réel (de quelques millisecondes à quelques secondes). En conséquence, le Fog fournit plusieurs types de stockage, de l'éphémère (niveau le plus bas) vers le semi-permanent (niveau le plus élevé, la couverture géographique est plus élevée et l'échelle du temps est plus large). A la fin, la couverture mondiale est fournie par le Cloud, qui est utilisé comme un entrepôt de données permanent (mois, années). La figure 4.5 illustre cette interaction entre les deux modèles de calculs.

Les FNs peuvent être des serveurs de calcul intégrés à des routeurs et destinés au déploiement industriel. Il existe de nombreuses technologies commercialisées qui permettent l'implémentation et l'exploitation de la solution Fog Manufacturing (DASTJERDI et BUYYA, 2016). Nous allons en présenter quelques unes dans ce qui suit :

- **LocalGrid (plateforme Fog)** : Est un logiciel embarqué installé sur des périphériques réseaux (commutateurs, routeurs) et des capteurs. Il standardise et sécurise les communications entre tous les types de périphériques, ce qui minimise les coûts des services. Il réside entre le bord et le Cloud, ce qui permet aux applications de prendre des décisions en temps réel au bord de réseau, tout en éliminant la latence élevée causée par la communication avec le Cloud.

- **ParStream** : Est une plate-forme d'analyse IoT en temps réel. Elle s'intègre aux équipements Cisco pour créer une infrastructure rapide, fiable et haute- ment évolutive pour l'analyse du Fog, comparée à l'infrastructure tradition- nelle. Étant une base de données en mémoire, elle est idéale pour les dispo- sitifs Fog. Elle peut repousser l'exécution de la requête au bord du réseau où
<figure><img src="image_40.png" /><figcaption>FIGURE 4.5 – Les trois types d’intégrations de l’Industrie 4.0.</figcaption></figure>

<figure><img src="image_41.png" /><figcaption>FIGURE 4.6 – Le principe de la technologie ParStream.</figcaption></figure>

les données sont produites et effectuer des analyses de manière hautement distribuées comme l'explique la figure 4.6.

— **Cisco Data In Motion (DMo)** : Est une technologie offrant la gestion et l'analyse des données au bord du réseau. Elle est utilisée pour effectuer des analyses sur les données entrantes (la recherche de données spécifiques d'intérêt, le résumé des données, la génération de nouveaux résultats) et destinée à être déployée sur des périphériques de manière distribuée et à contrôler les flux importants de données provenant des appareils IoT.

— **Vortex** : Est une plate-forme de partage (operable, évolutive, efficace, sécurisée et en temps réel) des données pour l'IoT, du bout en bout à travers les périphériques, les bordures, les passerelles et le Cloud. Vortex offre des exigences de sécurité, d'authentification et de confidentialité et ses dispositifs Vortex Edge appartiennent au domaine Fog. La figure 4.7 présente une illustration du principe du Vortex.

La couche du passerelle

Cette couche relie deux réseaux informatiques de types différents, le local (Fog) et le réseau Internet (Cloud). Elle joue principalement le rôle d'une intermédiaire
<figure><img src="image_42.png" /><figcaption>FIGURE 4.7 – Le principe de la technologie Vortex.</figcaption></figure>

entre les FNs et les serveurs du Cloud. Les passerelles concentrent les informations localement reçues de la couche Fog, les regroupent et les transmettent via Internet au Cloud computing.

Lorsqu'un FN contacte une passerelle, ce dernier examine sa requête et, si jamais celle-ci correspond aux règles que l'administrateur réseau a définies, la passerelle crée un lien entre les deux couches. Les données ne sont donc pas directement envoyées, mais interprétées afin d'assurer la continuité des deux réseaux possédant deux protocoles différents.

Cet intermédiaire facilite la transmission malgré l'hétérogénéité et offre une sécurité supplémentaire (pare-feu, proxy, etc.). Cette sécurité est due à la vérification de chaque donnée transmise, ce qui entraîne des délais supplémentaires pouvant causer un ralentissement.

Les passerelles peuvent être logicielles ou matérielles. Dans notre contexte, on considère que les passerelles de l'architecture basée sur le Fog Manufacturing sont matérielles et qu'elles peuvent être de trois niveaux :

- Un répéteur : Niveau 1,

- Un pont : Niveau 2

- Un relais, nommé aussi routeur : Niveau 3.

## La couche du Cloud computing

Cette couche est la plus élevée et elle regroupe des serveurs avec des importantes capacités de calcul et de stockage. Ces serveurs se chargent de la synchronisation avec les dernières données transmises par les FNs. Cette couche assure les mises à jour et la prise de la décision. Avec la présence des FNs, le Cloud prend les décisions à long terme et s'occupe des calculs qui nécessitent des méthodes d'apprentissage (notamment d'apprentissage profond) et des techniques de Big Data. Donc le Cloud peut assurer les décisions non urgentes et fédérées. Généralement le Cloud computing est un ensemble des serveurs (publics ou privés) localisés à l'extérieur du site de production. Cependant, pour certaines entreprises ou sites de production, les entreprises préfèrent garder les serveurs en interne pour sécuriser leurs données. Il existe bien évidemment d'autres solutions comme la location des serveurs. Depuis plusieurs années, l'alternative de location des serveurs est proposée aux entreprises, afin de stocker et sauvegarder les données. Il est ainsi possible de louer des capacités de calcul et de stockage chez des hébergeurs donnant ainsi une grande flexibilité en
fonction de l'évolution des besoins de l'entreprise. Cette alternative est choisie parce qu'elle est moins coûteuse et assure le maintien des serveurs par des spécialistes.

4.4 L'optimisation du coût de déploiement du Fog Manufac-
turing

Dans cette section, nous nous intéressons au déploiement du Fog Manufacturing dans une application de logistique interne. Ce déploiement est basé sur l'architecture illustrée par la figure 4.4 dans une usine 4.0.

Pour modéliser le problème de déploiement du Fog Manufacturing, un ensemble d'hypothèses de travail est considéré pour limiter la complexité du problème étudié. Le problème étudié dans le cadre de cette modélisation s'appuie sur les hypothèses et caractéristiques suivantes :

— Dans cette usine, il existe un Cloud centralisé dont l'emplacement est connu et fixé,

— L'emplacement des systèmes connectés fixes (bras robotisés, machines, postes manuels, imprimantes 3D et découpes laser) est connu,

— Les trajectoires des AGVs mobiles sont fixées et identifiées, les zones de leurs déplacements sont définies lors de leur installation. Chaque AGV ne peut pas être présent dans une zone en-dehors des trajectoires pré-définies.

— Compte tenu de ce qui précède, l'emplacement des passerelles, des FNs, et des ENs sont inconnus, uniquement les emplacements candidats sont connus,

— Les terminaux ou CPS seront connectés aux ENs via WiFi,

— L'architecture de ce réseau, c'est-à-dire comment connecter les noeuds est inconnue. Le lien entre les ENs, FNs, passerelles et Cloud est filaire,

— L'environnement de cette usine est considérée comme homogène et chaque système possède une capacité de génération et de consommation de donnée définie.

— Le nombre de connexions de chaque noeud est supposé défini,

— Chaque système peut être connecté à un seul EN à la fois, et respectivement chaque EN, FN, passerelle à un FN, passerelle Cloud,

— Le problème à optimiser est étudié sous l'angle d'une minimisation du coût d'installation de la solution Fog Manufacturing.

Le modèle de minimisation du coût lié au déploiement est construit en utilisant les FNs. Ce modèle permet non seulement de réduire le coût d'installation et de fonctionnement, mais reflète également l'effet de cette optimisation sur la répartition des noeuds sur les différentes zones de l'atelier et sur la QoS.

La contribution principale de notre modèle pour l'optimisation efficace est présentée dans cette partie et porte sur les points suivants :

— La description de la fonction « objectif »,

— La définition des différentes contraintes,

— La résolution du problème de la non-linéarité des contraintes,

— La spécification des liens en donnant le choix entre de la fibre optique ou le câble RJ45, en fonction de la charge maximale de calcul et le nombre de noeuds connectés à chaque EN, FN ou passerelle,

— L'introduction de la probabilité de la présence des AGVs selon les zones de circulation.
## 4.4.1 Paramètres

Le problème du déploiement du Fog a été présenté et défini de façon formelle au paragraphe précédent. Les notations utilisées dans le modèle sont indiquées dans le tableau 4.1. Les tableaux 4.2 et 4.3 présentent respectivement les variables de décision et les vecteurs de variables.

<table><caption>TABLE 4.1 – Définition des paramètres.</caption><thead><tr><td>Paramètre</td><td>Définition</td></tr></thead><tbody><tr><td>Ω<sub>C</sub></td><td>L'ensemble des serveurs Cloud</td></tr><tr><td>Ω<sub>G</sub></td><td>L'ensemble des sites potentiels des passerelles</td></tr><tr><td>Ω<sub>F</sub></td><td>L'ensemble des sites potentiels des FNs</td></tr><tr><td>Ω<sub>E</sub></td><td>L'ensemble des sites potentiels des ENs</td></tr><tr><td>S</td><td>L'ensemble des terminaux</td></tr><tr><td>C<sub>f</sub></td><td>Le coût d'une unité de fibre</td></tr><tr><td>C<sub>RJ</sub></td><td>Le coût d'une unité de câble RJ45</td></tr><tr><td>C<sub>G</sub></td><td>Le coût de l'installation d'une passerelle</td></tr><tr><td>C<sub>F</sub></td><td>Le coût de l'installation d'un FN</td></tr><tr><td>C<sub>E</sub></td><td>Le coût de l'installation d'un EN</td></tr><tr><td>H<sup>G</sup><sub>c</sub></td><td>La capacité maximale d'une passerelle c</td></tr><tr><td>H<sup>F</sup><sub>m</sub></td><td>La capacité maximale d'un FN m</td></tr><tr><td>H<sup>E</sup><sub>n</sub></td><td>La capacité maximale d'un EN n</td></tr><tr><td>N<sub>G</sub></td><td>Le nombre maximal de liens d'une passerelle</td></tr><tr><td>N<sub>F</sub></td><td>Le nombre maximal de liens d'un FN</td></tr><tr><td>N<sub>E</sub></td><td>Le nombre maximal de liens d'un EN</td></tr><tr><td>d<sub>ij</sub></td><td>La distance entre deux nœuds i et j</td></tr><tr><td>L</td><td>La longueur des trames de données d'un terminal à un EN (Identique ∀ terminales)</td></tr><tr><td>L<sub>E</sub></td><td>La longueur des trames de données d'un EN à un FN</td></tr><tr><td>L<sub>F</sub></td><td>La longueur des trames de données d'un FN à une passerelle</td></tr><tr><td>R<sub>n</sub></td><td>Le diamètre de couverture d'un EN n</td></tr><tr><td>r</td><td>La charge de travail d'un terminal</td></tr><tr><td>μ<sub>tn</sub></td><td>Le débit de transmission de données d'un terminal t à un EN n</td></tr><tr><td>μ<sub>nm</sub></td><td>Le débit de transmission de données d'un EN n à un FN m</td></tr><tr><td>μ<sub>mc</sub></td><td>Le débit de transmission de données d'un FN m à une passerelle c</td></tr><tr><td>γ<sup>n</sup><sub>t</sub></td><td>La latence maximale d'une liaison entre un terminal t et un EN n</td></tr><tr><td>γ<sup>m</sup><sub>n</sub></td><td>La latence maximale d'une liaison entre un EN n et un FN m</td></tr><tr><td>γ<sup>c</sup><sub>m</sub></td><td>La latence maximale d'une liaison entre un FN m et une passerelle c</td></tr><tr><td>MaxCapR</td><td>La capacité maximale pour l'utilisation du câble RJ45</td></tr><tr><td>H<sup>E</sup><sub>P</sub></td><td>La capacité de réseau maximale</td></tr></tbody></table>

## 4.4.2 La fonction objectif

La résolution du modèle a pour objet, dans notre travail, de minimiser un objectif : Le coût de déploiement des noeuds de l'architecture basée sur le Fog Manufacturing. Ainsi, résoudre ce problème consiste à trouver une solution S qui minimise le nombre des ENs, FNs et passerelles utilisés, à préférer la solution avec la plus petite distance totale en fibre tout en favorisant l'utilisation du câble RJ45 lorsque c'est suffisant. Pour surmonter le problème de la non-linéarité des contraintes nous
<table><caption>TABLE 4.2 – Définition des variables de décisions.</caption><thead><tr><th>Variable de décision</th><th>Définition</th></tr></thead><tbody><tr><td>x<sub>ij</sub></td><td>Variable binaire, décide si y aura un lien fibre entre un nœud i et j</td></tr><tr><td>xR<sub>ij</sub></td><td>Variable binaire, décide si y aura un lien câble RJ45 entre un nœud i et j</td></tr><tr><td>xF<sub>ij</sub></td><td>Variable binaire, décide si y aura un lien câble RJ45 entre un nœud i et j</td></tr><tr><td>G<sub>c</sub></td><td>Variable binaire, indiquant la sélection des noeuds c activés des passerelles</td></tr><tr><td>F<sub>m</sub></td><td>Variable binaire, indiquant la sélection des noeuds m activés des FNs</td></tr><tr><td>E<sub>n</sub></td><td>Variable binaire, indiquant la sélection des noeud n activées des ENs</td></tr></tbody></table>

<table><caption>TABLE 4.3 – Définition des variables.</caption><thead><tr><th>Variable</th><th>Définition</th></tr></thead><tbody><tr><td>ω(X<sub>i</sub>)</td><td>La demande de capacité de calcul pour un site de noeud X<sub>i</sub></td></tr><tr><td>ω<sub>P</sub>(X<sub>ij</sub>)</td><td>La capacité de réseau pour un site de noeud X<sub>i</sub></td></tr></tbody></table>

avons divisé les variables de décisions en sous-ensembles afin de faciliter le calcul. Le détail de cette démarche sera expliqué dans la section 4.4.4.

$$ Cost = C_f \cdot \sum_{(i,j) \in \Omega_G \cup \Omega_F \times \Omega_F \cup \Omega_E} xF_{ij} \cdot d_{ij} + C_{RJ} \cdot \sum_{(i,j) \in \Omega_G \cup \Omega_F \times \Omega_F \cup \Omega_E} xR_{ij} \cdot d_{ij} + C_G \cdot \sum_{c \in \Omega_G} G_c + C_F \cdot \sum_{m \in \Omega_F} F_m + C_E \cdot \sum_{n \in \Omega_E} E_n \quad (4.1) $$

Dans cette formulation, l'équation (4.1) modélise la fonction objectif du problème :

- Le premier terme est le coût des liaisons par fibre optique entre Cloud-passerelles, entre passerelles-FNs et entre FNs-ENs;

- Le deuxième terme est le coût des liaisons par câble RJ45 entre Cloud-passerelles, entre passerelles-FNs et entre FNs-ENs;

- Les trois autres termes sont les coûts d'installation des passerelles, des FNs et des ENs, respectivement.

### 4.4.3 Les contraintes de base

De multiples contraintes viennent également limiter l'espace de décision dans lequel la solution d'un problème de déploiement doit être trouvée. La partie suivante détaille les contraintes adoptées pour notre modèle d'optimisation.

#### L'activation des nœuds

Cet ensemble des contraintes concerne principalement l'établissement de la topologie réseau entre les différentes couches de l'architecture présentée par la section 4.3. Pour faciliter la modélisation, on suppose que le sens des liens entre les différents ensembles de nœuds est ascendant et que chaque nœud ne peut être lié qu'avec un seul noeud appartenant à la couche qui suit.

La contrainte 4.2 impose que pour chaque terminal *t*, un seul lien $x_{nt}$ avec un EN *n* peut être établi.
$$ \sum_{n \in \Omega_E} x_{nt} = 1, \forall t \in S \quad (4.2) $$

Par la suite, les contraintes 4.3 et 4.4 considèrent que la variable de décision binaire $E_n$ du déploiement d'un EN $n$ est déterminée par les liens avec les terminaux. La possibilité d'activer un EN $n$ dépend du nombre de liaisons avec l'ensemble des terminaux $t$ (il suffit que le nombre de liens soit $\ge 1$) :

$$ E_n \le \sum_{t \in S} x_{nt}, \forall n \in \Omega_E \quad (4.3) $$

$$ x_{nt} \le E_n, \forall n \in \Omega_E, \forall t \in S \quad (4.4) $$

La même démarche s'applique pour les autres liens : ENs-FNs et FNs-passerelles. La contrainte (4.5) impose qu'il doit y avoir un seul FN $m$ lié à un EN $n$.

$$ \sum_{m \in \Omega_F} x_{mn} = 1, \forall n \in \Omega_E \quad (4.5) $$

De même, les contraintes (4.6) et (4.7) déterminent l'activité de la variable de décision binaire $F_m$ de déployer un FN $m$ en fonction de ses liens avec les noeuds ENs;

$$ F_m \le \sum_{k \in \Omega_E} x_{mn}, \forall m \in \Omega_F \quad (4.6) $$

$$ x_{mn} \le F_m, \forall m \in \Omega_F, \forall n \in \Omega_E \quad (4.7) $$

La contrainte (4.8) impose qu'il doit y avoir un seul FN $m$ lié à un EN $n$.

$$ \sum_{c \in \Omega_G} x_{cm} = 1, \forall m \in \Omega_F \quad (4.8) $$

Passons maintenant aux liens des passerelles. Elles seront liées aux FNs et au serveur Cloud. Le même principe va s'appliquer en reliant chaque FN à une seule passerelle. Les contraintes (4.9) et (4.10) déterminent la variable de décision binaire $G_c$ modélisant l'opportunité de déployer une passerelle $c$ en fonction des liens établis avec les FNs.

$$ G_c \le \sum_{m \in \Omega_F} x_{cm}, \forall c \in \Omega_G \quad (4.9) $$

$$ x_{cm} \le G_c, \forall c \in \Omega_G, \forall m \in \Omega_F \quad (4.10) $$

Finalement, il faut activer le lien entre les passerelles $c$ déployées et le serveur du Cloud référé par $s$. Chaque passerelle $c$ déployée doit être liée avec le Cloud comme le montre l'équation (4.11). La position du serveur Cloud est fixée et occupe un seul emplacement dans l'atelier de production.

$$ x_{sc} = G_c, \forall c \in \Omega_G \quad (4.11) $$

## La capacité de demande des nœuds

Le deuxième groupe des contraintes concerne la capacité de demande. Les terminaux, ENs et Fns transmettent d'une façon continue une quantité de données
aux noeuds des niveaux supérieurs, ENs, FNs et passerelles, pour les traiter. Par exemple, les données envoyées par tous les terminaux liés à un EN *t* ne doivent pas dépasser sa capacité maximale pour garantir une haute performance de délivrance des décisions en temps réel.

Cette contrainte est non linéaire comme elle intègre dans son calcul une multi-
plication de deux vecteurs de variable de décision : la variable binaire $x_{ij}$, décide si
y aura un lien fibre entre un nœud $i$ et un autre nœud $j$ et la demande de capacité
de calcul pour un site $X_i : \omega(X_i)$. Dans ce qui suit, une de nos contributions sera
la linéarisation de ces équations afin de résoudre ce problème à l'aide d'un solver
utilisant la méthode linéaire exacte.

Les contraintes relatives à la capacité de demande de tous les terminaux sont expliquées comme suit. La contrainte (4.12) impose que la quantité de la demande $\omega(E_n)$ desservie par le nœud EN $n$ soit la somme des demandes de tous les terminaux déterminée par tous les liens entre le nœud EN $n$ et chaque terminal $t$.

$$
\omega(E_n) = \sum_{t \in S} r \cdot x_{nt}, \forall n \in \Omega_E \quad (4.12)
$$

La contrainte (4.13) impose une limite pour que la somme de la demande provenant des terminaux ne soit pas supérieure à la capacité maximale $H_n^E$ pour un EN $n$.

$$
\omega(E_n) \leq E_n \cdot H_n^E, \forall n \in \Omega_E \quad (4.13)
$$

La même condition s'applique pour les données transmises des ENs aux FNs.
Les contraintes (4.14) et (4.15) considèrent la capacité maximale $H_m^F$ pour un FN $m$
comme étant une limite de capacité pour la demande provenant des ENs $n$.

$$
\omega(F_m) = \sum_{n \in \Omega_F} \omega(E_n) \cdot x_{mn}, \forall m \in \Omega_F \quad (4.14)
$$

$$
\omega(F_m) \leq F_m \cdot H_m^F, \forall m \in \Omega_F \qquad (4.15)
$$

Pour la capacité de demande entre les FNs et les passerelles, les contraintes (4.16) et (4.17) considèrent la capacité maximale $H_c^G$ pour une passerelle $m$. La capacité de demande est la somme des demandes des FNs $m$ liées à une passerelle $c$.

$$
\omega(G_c) = \sum_{m \in \Omega_F} \omega(F_m) \cdot x_{cm}, \forall c \in \Omega_G \quad (4.16)
$$

$$
\omega(G_c) \leq G_c \cdot H_c^G, \forall c \in \Omega_G \qquad (4.17)
$$

La latence des transmissions

La latence pour une application basée sur le Fog Manufacturing est un critère notable afin de juger la performance de cette solution. La latence influence le problème d'optimisation du coût. Pour chaque lien, il ne faut pas dépasser un seuil de latence de transmission.

Les contraintes (4.18), (4.19) et (4.20) calculent les temps de latence entre un EN *n* et un terminal *t*, entre un FN *m* et un EN *n*, et entre la passerelle *c* et un FN *m*. Ces délais ne doivent pas dépasser des latences maximales $\gamma_t^n, \gamma_n^m$ et $\gamma_m^c$, respectivement.
$$L/(\sum_{t \in T} x_{nt} \cdot \mu_{tn}) \cdot E_n \le \gamma_t^n \quad (4.18)$$

$$L/(\sum_{n \in \Omega_E} x_{mn} \cdot \mu_{nm}) \cdot F_m \le \gamma_n^m \quad (4.19)$$

$$L/(\sum_{m \in \Omega_F} x_{mc} \cdot \mu_{mc}) \cdot G_c \le \gamma_m^c \quad (4.20)$$

### La couverture des AGVs par les nœuds Edge

Parmi les terminaux $t$ appartenant à $S$, il existe des CPS mobiles qui assurent les tâches de transport dans les différents départements d'un atelier de production. Les AGVs ou les AGVs équipés de bras mobiles sont connectés sans fil aux ENs. Lors de leur déplacement, ils risquent de sortir de la zone de couverture d'un EN 1 par exemple, donc il est nécessaire de garantir le relais de couverture instantané par un autre EN $t$ afin de ne pas interrompre leur connectivité.

La contrainte (4.21) traduit cette condition et considère que la distance entre les ENs et les AGVs $t$ ne doit pas être supérieure à la portée de couverture $R_n$ d'un EN $n$.

$$x_{nt} \cdot d_{nt} \le R_n/2, \forall n \in \Omega_E, \forall t \in \Omega_{AGV} \quad (4.21)$$

### Le nombre maximal des liens supporté par un nœud

Il est logique d'attribuer un max de dispositifs avec chaque noeud de niveau supérieur mais cette stratégie risque de saturer les noeuds et centraliser le traitement au niveau de quelques nœuds. Par contre le principe du Fog Manufacturing est de distribuer le calcul sur l'ensemble de l'atelier de production. La limitation des liens pour chaque nœud est nécessaire. Le nombre de liens pour chaque EN, FN et passelle a une capacité maximale $N_E, N_F, N_G$, respectivement dans les contraintes (4.22)-(4.23) et (4.24).

$$\sum_{t \in T} x_{nt} \le N_E, \forall n \in \Omega_E \quad (4.22)$$

$$\sum_{n \in \Omega_E} x_{mn} \le N_F, \forall m \in \Omega_F \quad (4.23)$$

$$\sum_{m \in \Omega_F} x_{cm} \le N_G, \forall c \in \Omega_G \quad (4.24)$$

### 4.4.4 Nos contributions

Le modèle adopté comme base dans notre travail (voir. LIN et YANG, 2018) était souvent optimisé à l'aide des méthodes métaheuristiques (les algorithmes génétiques). Ce choix a été adopté par les auteurs parce que le modèle possède des non-linéarité ce qui rend l'optimisation à l'aide de méthodes exactes compliquée lente ou impossible. La deuxième raison est la nature de ce problème qui est considéré comme un problème NP-complet qui consomme beaucoup de temps avant de converger. Malgré ces justifications de l'utilisation des méta-heuristiques, aucune comparaison avec des solutions optimales n'a été mentionnée dans la littérature, ce qui rend difficile d'apprécier les solutions proposées par les méthodes méta-heuristiques. Dans notre travail, nous avons choisi de travailler avec la méthode
exacte pour fournir un seuil de comparaison aux autres méthodes. Nous avons ren-
contré les même problèmes de non-linéarité et de complexité du problème qui ont
empêché les autres équipes de procéder par méthode exacte. Dans ce qui suit, nous
allons commencer par traiter le problème de non-linéarité. Cette contribution nous
aidera à enrichir le modèle d'optimisation du coût de deux nouvelles contraintes
concernant le type de lien et la considération de dispositifs mobiles dans le modèle
tels que les AGVs ou les interfaces de commande mobiles. Ces deux contraintes se-
ront expliquées et modélisées dans ce qui suit.

La linéarisation

Le modèle brut utilisé par les autres travaux était habituellement optimisé à l'aide des algorithmes génétiques vu sa grande taille et sa non-linéarisation au niveau des contraintes de la capacité de la demande 4.4.3, qui regroupe à la fois deux variables de décision que sont le lien et la capacité de demande d'un nœud.

La linéarisation des contraintes est utilisée pour respecter les normes de conception et les exigences de la résolution. Néanmoins, il est nécessaire d'écrire des équations non-linéaires afin de définir les conditions à poser au modèle.

Nous avons résolu ce problème en divisant la variable de décision en plusieurs
afin de limiter le nombre de variables de décision. Également, nous avons utilisé
des variables intermédiaires qui contiennent les variables de décisions des sous en-
sembles.

La probabilité de la capacité de réseau

Dans un atelier de production, les trajectoires de déplacement des robots mobiles sont généralement pré-définies afin de faciliter le déplacement et empêcher les accidents de travail. Cette dernière contrainte concerne principalement le AGVs qui se déplacent pour accomplir des tâches. Elle impose une condition sur chaque zone de présence d'AGV de telles sorte à ce qu'il existe une probabilité de présence des AGVs. Cette probabilité est influencée par deux paramètres :

— L'impossibilité de présence d'AGV dans deux endroits en même temps, comme le montre la figure 4.8,

— La capacité d’une zone à contenir un nombre limité d’AGV. Par exemple un couloir ne peux contenir plus que deux ou trois AGVs selon la largeur du couloir et les distances de sécurité minimales entre les robots.

Cette contrainte sert à répartir la charge sur toute la zone et à éviter la surcharge du réseau par les requêtes dans une petite zone gérée par un faible nombre d'ENs. En conséquence, cette contrainte limite la capacité de réseau à un maximum $H_p^E$. Pour faciliter la modélisation, on considère le plan, présenté par la figure 4.9, de notre laboratoire sur lequel nous allons appliquer le modèle pour la suite de ce travail. Par exemple, pn prend un plan de surface 30mx20m, dont chaque cellule est un carré de $1m^2$. Chaque cellule ne peut supporter plus qu'un terminal (AGV dans ce cas). Les trajectoires sont marquées par les flèches bleues sur la figure 4.9. Nous avons traduit ce plan en une matrice de probabilités de présence d'un terminal pour chaque cellule. Nous avons également défini un vecteur de variables, nommé $\omega_p$. Ce vecteur est la probabilité de présence des terminaux sur chaque cellule ou ensemble de cellules (zones) multiplié par la demande d'un terminal. L'équation (4.25) donne la probabilité $P_z(X_i)$ de chaque cellule $X_i$ appartenant à une zone z de l'environnement de l'atelier de production comme suit :
<figure><img src="image_43.png" /><figcaption>FIGURE 4.8 – Transmission d'un dispositif mobile (AGV).</figcaption></figure>

<figure><img src="image_44.png" /><figcaption>FIGURE 4.9 – Le plan du laboratoire LINEACT CESI.</figcaption></figure>
<figure><img src="image_45.png" /><figcaption>FIGURE 4.10 – Les probabilités de chaque cellule en fonction de la mobilité des AGVs.</figcaption></figure>

$$
P_z(X_i) = \frac{NbrTMax_z}{NbrCell_z}, \forall i \in M, \forall z \in Z \quad (4.25)
$$

Avec NbrTMax_z le nombre maximal possible des terminaux présents dans une
zone z, et NbrCell_z le nombre de cellules constituant la zone z, M est l'ensemble des
cellules constituant l'atelier de production, et Z est l'ensemble des zones de l'atelier
de production.

La calcul de cette probabilité dans la zone de production de l'atelier du laboratoire CESI est donnée par l'équation (4.26)

$$
P_z(X_i) = \frac{NbrTMax_z}{NbrCell_z}, \forall i \in \{1, \dots, 600\}, \forall z \in \{1, \dots, 6\} \quad (4.26)
$$

Comme le montre la matrice présentée sur la figure 4.10, la probabilité des cel-
lules où sont installés les terminaux fixes est égale à 1. Pour les terminaux mobiles,
qui sont les AGVs, leur présence est définie par les trajectoires colorées (Orange,
Bleue, Jaune et verte) sur la figure 4.10. Par contre cette présence étant dynamique,
nous avons pensé à la rendre statique en introduisant un AGV sur chaque cellule
des trajectoires et en gardant une distance de sécurité de 1 mètre. La probabilité va-
rie d'une zone à une autre selon les trajectoires et la présence maximale des AGVs.
Nous pouvons distinguer les zones suivantes :

— Z₁ : Pz₁(Xᵢ)=1, ∀Xᵢ ∈ Z₁ et Xᵢ représenté en gris

— Z₂ : Pz₂(Xᵢ) = 0,65, ∀Xᵢ ∈ Z₂, Avec NbrTMaxz₂ = 7 et NbrCellz₂ = 20 et Xᵢ représenté en orange,

— Z₃ : Pz₃(Xᵢ) = 0,71, ∀Xᵢ ∈ Z₃, NbrTMaxz₃ = 5 et NbrCellz₃ = 7, et Xᵢ représenté en bleu,

— Z₄ : Pz₄(Xᵢ) = 0,31 ∀i ∈ Z₄, Avec NbrTMaxz₄ = 21 et NbrCellz₄ = 67, et Xᵢ représenté en jaune,

— Z₅ : Pz₅(Xᵢ) = 0,36 ∀Xᵢ ∈ Z₅, Avec NbrTMaxz₅ = 18 et NbrCellz₅ = 50, et Xᵢ représenté en vert,

— Z₆ : Pz₆(Xᵢ) = 0 ∀Xᵢ ∈ Z₆, Avec NbrTMaxz₆ = 0 et NbrCellz₆ = 456, et Xᵢ représenté en blanc,

Finalement la contrainte est donnée par les équations (4.27) & (4.28) :

$$
\omega_P(E_n) = \sum_{t \in T} P(t).r.x_{nt}, \forall n \in \Omega_E \quad (4.27)
$$

$$
\omega_P(E_n) \leq E_n \cdot H_P^E, \forall n \in \Omega_E \quad (4.28)
$$
## Le type de lien

Nous avons proposé l'optimisation des types de liens filaires entre les ENs-FNs, FNs-Passerelles et Passerelles-Cloud pour minimiser le coût de l'installation de la solution Fog et augmenté la qualité de service. Nous avons créé une contrainte qui détermine le type du lien à choisir entre la liaison avec fibre optique ou avec le câble RJ45 selon la demande en données. Cette contrainte dépend de la contrainte (4.13) de la capacité de la demande expliqué dans la section 4.4.3. Si la demande provenant d'un nœud à un autre ne dépasse pas un seuil on utilise un lien RJ45 sinon on opte pour la fibre optique.

Pour faciliter la modélisation du problème nous avons supposé que le lien entre les noeuds de traitement de données peut être un lien fibre ou un lien câble RJ45. Donc le lien sera activé selon le besoin en terme de la capacité de demande. La contrainte (4.29) traduit cette condition et la contrainte (4.29) force que le lien sera binaire (0 ou 1) :

$$x_{ij} = xF_{ij} + xR_{ij}, \forall i \in \Omega_E \cup \Omega_F \cup \Omega_G, j \in \Omega_F \cup \Omega_G \cup S \quad (4.29)$$

$$xF_{ij} + xR_{ij} \le 1, \forall i \in \Omega_E \cup \Omega_F \cup \Omega_G, j \in \Omega_F \cup \Omega_G \cup S \quad (4.30)$$

Par la suite nous passons à la définition de la condition d'un tel choix. La première contrainte (4.31) concerne les liens entre les ENs $n$ et les FNs $m$.

$$x_{mn} = \begin{cases} xR_{mn} & \text{si } \sum_{t \in T} r.x_{nt} \le \text{MaxCapR} \\ xF_{mn} & \text{sinon.} \end{cases} \quad \forall n \in \Omega_E, \forall m \in \Omega_F \quad (4.31)$$

La contrainte (4.32) concerne les liens entre les FNs $m$ et les passerelles $c$.

$$x_{cm} = \begin{cases} xR_{cm} & \text{si } \sum_{n \in \Omega_E} r.x_{mn} \le \text{MaxCapR} \\ xF_{cm} & \text{sinon.} \end{cases} \quad \forall m \in \Omega_F, \forall c \in \Omega_G \quad (4.32)$$

Les derniers liens sont ceux entre les passerelles $c$ et le centre Cloud $s$. Le choix de ces liens dépend principalement de la capacité de demande provenant des FNs $m$ liés aux passerelles $c$. La contrainte (4.33) traduit cette condition.

$$x_{sc} = \begin{cases} xR_{sc} & \text{si } \sum_{m \in \Omega_F} r.x_{cm} \le \text{MaxCapR} \\ xF_{sc} & \text{sinon.} \end{cases} \quad \forall c \in \Omega_G, \forall s \in S \quad (4.33)$$

## 4.5 L'optimisation du modèle

Les méthodes d'optimisation sont le fruit du croisement de mathématiques appliquées et de l'informatique. Elles représentent une grande partie de la recherche opérationnelle. Elles sont généralement adoptées pour surmonter la grande difficulté des problématiques de résolution et pour faciliter l'optimisation des critères de nombreuses applications. Les nombreux travaux parcourus dans la section 4.2.2 ont utilisé les approches Méta-heuristiques (les algorithmes génétiques) pour obtenir des solutions les plus proches de l'optimal. Dans notre travail nous avons choisi de résoudre le modèle de minimisation du coût à l'aide de la méthode exacte. Le nombre d'instances du modèle étant important, nous avons choisi d'opter pour une démarche en deux temps en résolvant d'abord le modèle pour une petite instance
et dans une seconde étape en nous intéressant à l'instance complète. Ainsi, nous allons présenter les résultats de la résolution avec les cinq premières contraintes (l'activation des liens, la capacité de demande, la latence, la couverture et le nombre maximale, des liens) et par la suite nous allons intégrer le type de lien et ensuite la capacité de réseau.

4.5.1 La méthode exacte

Les méthodes exactes telles que la programmation linéaire, sont des méthodes heuristiques qui garantissent de trouver des solutions optimales exactes et prouvent l'optimalité pour toutes les instances d'un problème d'optimisation combinatoire (POC) de petite et de moyenne taille. En revanche, le temps de résolution du problème augmente selon la taille du problème à optimiser.

Le principe essentiel d'une méthode exacte consiste généralement à énumérer, souvent d'une manière implicite, l'ensemble des solutions de l'espace de recherche. Pour améliorer l'énumération des solutions, une telle méthode dispose de techniques pour détecter le plus tôt possible la solution exacte. Parmi les méthodes exactes, on trouve la plupart des méthodes traditionnelles telles que les techniques de séparation et évaluation progressive (SEP) ou les algorithmes avec retour arrière.

De plus, pour certains problèmes, la consommation de mémoire de ces algorithmes peut être très grande et peut parfois entraîner l'arrêt prématuré de l'application. La programmation linéaire peut être utilisée pour résoudre de façon exacte les POC. En effet, lorsqu'un POC peut être modélisé en programme linéaire, il peut alors être résolu, par exemple à l'aide de l'algorithme du simplexe. Lorsqu'on a la contrainte supplémentaire voulant que les valeurs des variables de décision soient entières, on a un programme linéaire en nombre entier (PLNE).

L'algorithme B&B est utilisé par les méthodes exactes pour résoudre d'une façon exacte des problèmes en nombre entier en utilisant le branchement pour séparer l'ensemble des solutions en sous ensembles et l'évaluation pour mettre des bornes supérieures ou inférieures sur les solutions (KHERBOUCHE et OUBAHRI, 2017).

Pour l'optimisation des différents cas d'étude et exemples nous avons utilisé le solver FICO Xpress IVE. Ce solver utilise comme langage le Mosel, qui est un environnement dédié à la modélisation et à la résolution des problèmes. Il fournit un langage, à la fois de modélisation et de programmation. L'originalité du langage Mosel est qu'il n'y a pas de séparation entre une déclaration de modélisation (par exemple, déclarer une variable de décision ou exprimer une contrainte) et une procédure qui résout réellement le problème (par exemple, appel à une commande d'optimisation). Grâce à cette association, on peut programmer un algorithme de solution complexe en combinant la modélisation et la résolution du problème.

4.5.2 Description des cas d'étude

Cette section met en œuvre le modèle d'optimisation proposé, et effectue des
simulations sur des problèmes de petite taille et de taille moyenne. Nous avons op-
timisé le modèle avec et sans les nouvelles contraintes et nous avons comparé les
différentes approches afin de démontrer l'apport de nos contributions en terme du
coût. Nous avons considéré le plan du laboratoire LINEACT CESI qui était présenté
précédemment par la figure 4.9.

La première étape est l'attribution des nœuds de l'architecture basée sur le Fog
Manufacturing qui sont les ENs, FNs et les passerelles. Nous avons choisi de mettre
un maximum de noeuds à côté de toutes les prises d'alimentation électriques du
<figure><img src="image_46.png" /><figcaption>FIGURE 4.11 – Le plan du laboratoire LINEACT CESI avec l'emplac- cement potentiel des différents nœuds.</figcaption></figure>

laboratoire. La figure 4.11 présente le plan de l’usine (i.e. laboratoire), l’emplac- ment fixe du centre Cloud, les trajectoires des AGVs, les emplacements des sys- tèmes fixes et tous les emplacements potentiels possibles des ENs, FNs et passe- relles. Les deux instances de modèles sont de petite taille et de taille moyenne. Le premier sera une simulation sur un petit plan deLongueur × Largeur = 6m × 6m (une surface de 36 m²) et le deuxième correspond au plan réel du laboratoire Longueur × Largeur = 30m × 20m (soit une surface de 600 m²). Nous avons divisé l’environnement en cellules de 1 m². Chaque cellule ne peut contenir qu’un noeud. Afin de pouvoir appliquer le modèle déjà présenté nous allons numéroter les cel- lules Cᵢ de Longueur × Largeur . chaque cellule Cᵢ a des coordonnées (Cₓᵢ, Cᵧᵢ). Les distances utilisées lors de différentes résolutions sont calculées en utilisant Matlab. La première matrice de distance D composée d’éléments dᵢⱼ est obtenu par les dis- tances de Manhattan représentant les distances en escalier entre les ENs-FNs, FNs- passerelles et Passerelles-Cloud en utilisant la formule de l’équation (4.34) :

$$
d_{ij} = |C_j^x - C_i^x| + |C_j^y - C_i^y|, \forall i, j \in \{1, \dots, \text{Longueur} \times \text{Largeur}\} \quad (4.34)
$$

Les distances de lien WIFI peuvent être calculées par la distance euclidienne comme le montre l'équation (4.35) :

$$
d_{ij} = \sqrt{(C_j^x - C_i^x)^2 + (C_j^y - C_i^y)^2}, \forall i, j \in \{1, \dots, \text{Longueur} \times \text{Largeur}\} \quad (4.35)
$$

Ces fichiers de distance sont utilisés comme étant des données d’entrée pour
la résolution du modèle. Le paramétrage utilisé dans les simulations sera présenté
avant chaque résolution.
4.5.3 Résolution et résultats

Tout au long de cette section les paramètres utilisés pour la résolution du modèle sont fixés à :

— Les coûts cf = 5, cG = 30, cF = 25, et cF = 10, cRJ45=3, MaxCapaR=50;

— Les débits de données $\mu_{tn} = 1000$, $\mu_{mn} = 4000$, et $\mu_{mc} = 4000$;

— Le diamètre de couverture d'un dispositif de bord (edge) $R_n = 15$;

— Les capacités maximales $N_E = 15$, $N_F = 10$, et $N_G = 7$;

— Les longueurs de données L = 5000, $L_E = 10000$, et $L_F = 15000$;

— Les capacités de demande maximales, c'est-à-dire $H_n^E = 150$, $H_m^F = 1500$, et $H_c^G = 7000$.

— Les temps de latence maximaux ont les valeurs suivantes : $\gamma_t^n = 80$, $\gamma_n^m = 20$, et $\gamma_c^m = 15$;

— La demande des terminaux r = 50.

Le modèle sans linéarisation

Nous avons commencé par la résolution du modèle sans la linéarisation et sans les nouvelles contraintes (La probabilité de demande du réseau et le type de lien). Nous avons démarré par l'optimisation d'une petite instance qui a convergé. Par contre cette résolution n'a pas convergé même au bout de nombreuses heures de recherche de solution optimale exacte (Out of Memory) pour l'instance complète. L'instance a généré un énorme nombre de variables qui dépasse largement les capacités du solver malgré l'utilisation des fonctionnalités de résolution non-linéaire. Nous avons donc conclu que la linéarisation était une étape essentielle afin de pouvoir obtenir une solution exacte.

Le modèle avec linéarisation & sans nouvelles contraintes

Dans un premier temps, nous avons résolu l'exemple simplifié afin de visualiser des résultats plus simples à analyser et de tester les contraintes avant de résoudre la grande instance. Le plan et les emplacements potentiels des nœuds de l'architecture sont illustrés par la figure 4.12.

Nous avons supposé que tous les nœuds terminaux sont connectés sans fil aux ENs. Les AGVs assurent la logistique interne dans un atelier de l'Industrie 4.0. Le reste des liaisons entre les ENs, FNs, Passerelles et Cloud est filaire (Liens de type fibre optique). On considère 4 AGVs, 2 machines, 1 imprimante 3D, 12 ENs, 7 FNs, 2 passerelles et 1 serveur Cloud. Il est nécessaire de pré définir les ensembles de chaque catégorie de nœuds, constituant l'architecture, pour créer les liens et activer les noeuds par la suite. Cette définition est présentée ci-dessous :

— $S=\{21\}$

— $\Omega_G=\{18, 19\}$

— $\Omega_F = \{8, 11, 13, 23, 24, 25, 32\}$

— $\Omega_E = \{1, 3, 5, 6, 7, 12, 30, 31, 34, 35, 36\}$

— $T = \{9, 10, 15, 16, 26, 27, 28\}$

La position de chaque nœud est fixe et la distance entre chaque nœud est calculée en fonction du type de liaison (sans fil/fibre). Le modèle est résolu en utilisant l'approche de la méthode exacte et la Programmation Linéaire. Le modèle est optimisé à l'aide du solveur de Fico "Xpress IVE" afin de minimiser le coût de déploiement du Fog Manufacturing avec une architecture de 5 couches.

La figure 4.19 illustre le résultat de l'optimisation du modèle simplifié. Les noeuds activés et les liens établis sont présentés : ENs (7,12,30), FNs (13,23) et la
<figure><img src="image_47.png" /><figcaption>FIGURE 4.12 – Le plan et l'emplacement potentiel de différents noeuds de la petite instance du modèle.</figcaption></figure>

passerelle 19 reliant les FNs au Cloud. Le coût *Cost* du déploiement du Fog Manufacturing dans ce cas est égal à 765 (unité de coût), affiché sur la figure 4.14.

Par la suite nous avons résolu le modèle complet qui modélise le plan de 600 m². Nous avons gardé le même paramétrage mais avec de nouveaux ensembles de noeuds adéquats au nouvel intervalle. Ces différents ensembles sont indiqués ci-dessous :

$$ \text{— } S = \{413\} $$

— T=\{18, 22, 51, 53, 79, 81, 83, 109, 103, 128, 129, 130, 131, 132, 133, 134, 135, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 184, 185, 186, 187, 188, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 208, 214, 215, 216, 218, 219, 225, 226, 230, 231, 283, 241, 242, 243, 244, 245, 246, 248, 249, 255, 256, 260, 261, 271, 272, 273, 274, 275, 276, 278, 279, 285, 286, 290, 291, 304, 305, 306, 308, 309, 315, 316, 320, 321, 331, 332, 333, 334, 335, 336, 338, 339, 345, 346, 350, 351, 361, 362, 363, 364, 365, 366, 367, 368, 369, 370, 371, 372, 373, 374, 375, 376, 380, 381, 394, 395, 396, 397, 398, 399, 400, 401, 402, 403, 405, 406, 407, 408, 409, 410, 411, 424, 425, 426, 427, 428, 429, 430, 431, 432, 433, 434, 435, 436, 437, 438, 439, 440, 441, 454, 455, 456, 457, 458, 459, 460, 461, 462, 463, 464, 465, 485, 486, 487, 488, 489, 490, 491, 492, 493, 494, 517, 518, 519, 520, 521, 522, 523, 524\}

— $\Omega_G$=\{77, 388, 423\}

— $\Omega_F$=\{1, 7, 11, 20, 29, 47, 73, 99, 211, 232, 337, 391, 414, 452, 582, 598\}

— $\text{Omega}_E$=\{2, 3, 8, 10, 12, 13, 17, 19, 23, 24, 25, 27, 28, 31, 60, 61, 70, 72, 92, 101, 102, 120, 122, 177, 180, 181, 183, 207, 262, 301, 322, 330, 360, 377, 379, 387, 393, 412, 415, 418, 419, 421, 450, 451, 453, 467, 468, 470, 481, 500, 530, 540, 564, 571, 573, 574, 583\}

Partant de la même démarche faite avec la petite instance du modèle, nous avons réparti des ENs, FNs et passerelles dans toutes les cellules possédant une alimentation électrique avec une distribution maximale sur tout l'atelier. Cette répartition est illustrée par la figure 4.15.

Le modèle est optimisé suite à la linéarisation qui nous a permis d'obtenir une convergence en moins du temps. Le résultat de cette optimisation du modèle est présenté sur la figure 4.16. Le coût est optimisé à Cost=6013 présenté par la figure 4.17.
<figure><img src="image_48.png" /><figcaption>FIGURE 4.13 – Les noeuds activés pour la petite instance du modèle avec la linéarisation.</figcaption></figure>

<figure><img src="image_49.png" /><figcaption>FIGURE 4.14 – Le coût et le temps de résolution pour la petite instance du modèle avec la linéarisation.</figcaption></figure>
<figure><img src="image_50.png" /><figcaption>FIGURE 4.15 – Le plan et l'emplacement potentiel de différents noeuds pour la grande instance du modèle.</figcaption></figure>

<figure><img src="image_51.png" /><figcaption>FIGURE 4.16 – Les noeuds activés pour la grande instance du modèle avec la linéarisation.</figcaption></figure>
<figure><img src="image_52.png" /><figcaption>FIGURE 4.17 – Le coût et le temps de résolution pour la grande ins-
tance du modèle avec la linéarisation.</figcaption></figure>

Les configurations initiales avant l'optimisation présentées sur les figures 4.12 et 4.15 seront utilisées comme configurations initiales pour la suite des résolutions.

Étude de la sensibilité

L'implémentation du Fog Manufacturing est un investissement pour les indus-
tries qui cherchent à diminuer les coûts de la production et du déploiement des nou-
veaux outils pouvant gérer. Notre modèle est optimisé selon la méthode exacte, donc
tous les résultats avec les différents paramétrages sont optimaux. Par contre certains
d'entre eux possèdent la meilleure configuration permettant un déploiement ren-
table (coût et activation des noeuds) non seulement à court terme mais aussi à long
termes. Ainsi fournir un conseil pour le choix des caractéristiques du matériel à dé-
ployer. On préfère souligner que cette étude de sensibilité touche seulement au coût
du déploiement et d'installation de l'architecture basée sur le Fog et surtout pas du
coût du fonctionnement des noeuds et des liens. Pour notre exemple, nous avons
fait une étude de la sensibilité du modèle suite à la variation des deux paramètres
suivants :

— r : La charge envoyée par chaque terminal à son EN.

— Rn : Le diamètre de couverture d'un EN.

Ces deux paramètres contrôlent les caractéristiques des ENs à choisir. Cette étude est proposée pour permettre un meilleur choix du paramétrage et conseiller les demandeurs du déploiement de l'architecture basée sur le Fog Manufacturing concernant :

— Quel type et portée d'EN choisir ?

— Quelle capacité et fréquence d'envoi de la charge de données par les différents terminaux ?
Les tableaux 4.4, 4.5, 4.6, 4.7, 4.8 présentent les résultats d'optimisation pour la variation du Rn quand r=5,10,15,20,25. Les paramètres à observer sont la faisabilité du modèle, le temps de résolution du modèle et le coût du déploiement.

<table><caption>TABLE 4.4 – Les résultats de la variation du Rn avec r=5.</caption><thead><tr><th>Rn</th><th>5</th><th>10</th><th>14</th><th>15</th><th>20</th><th>25</th><th>30</th><th>35</th><th>40</th><th>45</th></tr></thead><tbody><tr><th>Possible</th><td>Non</td><td>Non</td><td>Oui</td><td>Oui</td><td>Oui</td><td>Oui</td><td>Oui</td><td>Oui</td><td>Oui</td><td>Oui</td></tr><tr><th>Temps</th><td>0</td><td>0</td><td>1648</td><td>2648</td><td>5102</td><td>6346</td><td>4046</td><td>7801</td><td>7861</td><td>10974</td></tr><tr><th>Coût</th><td>0</td><td>0</td><td>2550,87</td><td>2313,23</td><td>2029,71</td><td>1940,68</td><td>1750</td><td>1750</td><td>1750</td><td>1750</td></tr><tr><th>ENs activés</th><td>0</td><td>0</td><td>15</td><td>14</td><td>14</td><td>14</td><td>14</td><td>14</td><td>14</td><td>14</td></tr><tr><th>FNs activés</th><td>0</td><td>0</td><td>4</td><td>4</td><td>4</td><td>3</td><td>3</td><td>3</td><td>3</td><td>3</td></tr><tr><th>Passerelles activées</th><td>0</td><td>0</td><td>1</td><td>1</td><td>2</td><td>1</td><td>1</td><td>1</td><td>1</td><td>1</td></tr></tbody></table>

<table><caption>TABLE 4.5 – Les résultats de la variation du Rn avec r=10.</caption><thead><tr><th>Rn</th><th>14</th><th>15</th><th>20</th><th>25</th><th>30</th><th>35</th><th>40</th><th>45</th></tr></thead><tbody><tr><th>Possible</th><td>Oui</td><td>Oui</td><td>Oui</td><td>Oui</td><td>Oui</td><td>Oui</td><td>Oui</td><td>Oui</td></tr><tr><th>Temps</th><td>2249</td><td>2392</td><td>7739</td><td>18456</td><td>13065</td><td>10934</td><td>7058</td><td>21064</td></tr><tr><th>Coût</th><td>2505,52</td><td>2313,23</td><td>2029,71</td><td>1940,68</td><td>1750</td><td>1750</td><td>1750</td><td>1750</td></tr><tr><th>ENs activés</th><td>14</td><td>14</td><td>14</td><td>14</td><td>14</td><td>14</td><td>14</td><td>14</td></tr><tr><th>FNs activés</th><td>4</td><td>4</td><td>4</td><td>3</td><td>3</td><td>3</td><td>3</td><td>3</td></tr><tr><th>Passerelles activées</th><td>1</td><td>1</td><td>2</td><td>1</td><td>1</td><td>1</td><td>1</td><td>1</td></tr></tbody></table>

<table><caption>TABLE 4.6 – Les résultats de la variation du Rn avec r=15.</caption><thead><tr><th>Rn</th><th>14</th><th>15</th><th>20</th><th>25</th><th>30</th><th>35</th><th>40</th><th>45</th></tr></thead><tbody><tr><th>Possible</th><td>Oui</td><td>Oui</td><td>Oui</td><td>Oui</td><td>Oui</td><td>Oui</td><td>Oui</td><td>Oui</td></tr><tr><th>Temps</th><td>1132</td><td>2505</td><td>6010</td><td>16624</td><td>5481</td><td>7613</td><td>8603</td><td>11277</td></tr><tr><th>Coût</th><td>2505,52</td><td>2313,23</td><td>2029,71</td><td>1940,68</td><td>1750</td><td>1750</td><td>1750</td><td>1750</td></tr><tr><th>ENs activés</th><td>14</td><td>14</td><td>14</td><td>14</td><td>14</td><td>14</td><td>14</td><td>14</td></tr><tr><th>FNs activés</th><td>4</td><td>4</td><td>4</td><td>3</td><td>3</td><td>3</td><td>3</td><td>3</td></tr><tr><th>Passerelles activées</th><td>1</td><td>1</td><td>2</td><td>1</td><td>1</td><td>1</td><td>1</td><td>1</td></tr></tbody></table>

<table><caption>TABLE 4.7 – Les résultats de la variation du Rn avec r=20.</caption><thead><tr><th>Rn</th><th>5</th><th>10</th><th>14</th><th>15</th><th>20</th><th>25</th><th>30</th><th>35</th><th>40</th><th>45</th></tr></thead><tbody><tr><th>Possible</th><td>Non</td><td>Non</td><td>Oui</td><td>Oui</td><td>Oui</td><td>Oui</td><td>Oui</td><td>Oui</td><td>Oui</td><td>Oui</td></tr><tr><th>Temps</th><td>0</td><td>0</td><td>912</td><td>702</td><td>4438</td><td>13709</td><td>9824</td><td>10563</td><td>9657</td><td>14359</td></tr><tr><th>Coût</th><td>0</td><td>0</td><td>2550,87</td><td>2313,23</td><td>2029,71</td><td>1940,68</td><td>1750</td><td>1750</td><td>1750</td><td>1750</td></tr><tr><th>ENs activés</th><td>0</td><td>0</td><td>15</td><td>14</td><td>14</td><td>14</td><td>14</td><td>14</td><td>14</td><td>14</td></tr><tr><th>FNs activés</th><td>0</td><td>0</td><td>4</td><td>4</td><td>4</td><td>3</td><td>3</td><td>3</td><td>3</td><td>3</td></tr><tr><th>Passerelles activées</th><td>0</td><td>0</td><td>1</td><td>1</td><td>2</td><td>1</td><td>1</td><td>1</td><td>1</td><td>1</td></tr></tbody></table>

<table><caption>TABLE 4.8 – Les résultats de la variation du Rn avec r=25.</caption><thead><tr><th>Rn</th><th>14</th><th>15</th><th>20</th><th>25</th><th>30</th><th>35</th><th>40</th><th>45</th></tr></thead><tbody><tr><th>Possible</th><td>Oui</td><td>Oui</td><td>Oui</td><td>Oui</td><td>Oui</td><td>Oui</td><td>Oui</td><td>Oui</td></tr><tr><th>Temps</th><td>2497</td><td>1358</td><td>6115</td><td>1884</td><td>4083</td><td>4360</td><td>8000</td><td>7526</td></tr><tr><th>Coût</th><td>2678</td><td>2441,86</td><td>2121,71</td><td>2050,93</td><td>1887,87</td><td>1871,68</td><td>1871,68</td><td>1871,68</td></tr><tr><th>ENs activés</th><td>16</td><td>16</td><td>15</td><td>15</td><td>15</td><td>15</td><td>15</td><td>15</td></tr><tr><th>FNs activés</th><td>4</td><td>4</td><td>4</td><td>4</td><td>3</td><td>3</td><td>3</td><td>3</td></tr><tr><th>Passerelles activées</th><td>1</td><td>1</td><td>1</td><td>1</td><td>2</td><td>1</td><td>1</td><td>1</td></tr></tbody></table>
D'après les résultats présentés dans les tableaux 4.4, 4.5, 4.6, 4.7, 4.8, nous pouvons remarquer que la valeur de $Rn$ influence le temps de résolution du modèle. Tant que le $Rn$ est faible, le modèle converge rapidement et le champ des ENs est largement distribué. Cela peut s'expliquer avec le fait que la portée limitée de couverture WI-FI des ENs limite le nombre de possibilité de connexion avec les terminaux.

Nous avons commencé la variation de $Rn$ par 14 comme pour les valeurs inférieures à cette valeur, le modèle ne converge pas et la solution est impossible. C'est parce que le champ de chaque EN n'est pas suffisant pour couvrir les terminaux et il existe un terminal éloigné de tous les nœuds EN de plus de 13 m.

Tant que l'on continue à augmenter la valeur du rayon $Rn$, on couvre évidemment plus de champs et le programme commence à minimiser le nombre d'ENs et par la suite des FNs en les concentrant dans la même zone. Cette concentration des noeuds est basée sur la minimisation du nombre de liens (câblage), qui sont coûteux. La minimisation du coût des liens ne concerne pas les liens WI-FI (entre les terminaux et les ENs) parce que ce n'est pas inclus dans le calcul de la fonction objectif (Ce coût n'est pas visible dans le déploiement, mais on peut avoir des coûts de fonctionnement à cause de la consommation énergétique élevée des grandes portées de WIFI). Une fois un terminal couvert par un EN, la distance n'impacte pas le coût contrairement à la longueur de connexion assurée par un lien filaire.

D'après cette étude, nous pouvons remarquer un autre point important. Notre modèle n'est pas sensible à la quantité de données générées par un terminal avec l'ensemble des valeurs r=5, 10, 15, 20, 25 testées. Cela est dû principalement à la limitation du nombre des terminaux qui peuvent être connectés à un EN en même temps ou bien des ENs à FN. Donc la charge totale ne dépasse pas la capacité maximum, respectivement, d'un EN ou d'un FN. Néanmoins pour la valeur de r=25 le modèle prend un temps très important pour converger. Nous l'avons arrêté avec un GAP de 0.03%. cela peut s'expliquer par le fait que si $r \ge 25$ le réseau explore des espaces de solution restes impossibles avant ce qui augmente le temps de calcul.

La variation du $Rn$ a un effet sur le nombre des terminaux connectés à un Edge. Si ce diamètre est :

- Trop faible, il y aura une contradiction avec la contrainte de la capacité de demande, la probabilité de la capacité du réseau. Chaque EN sera forcé à se connecter à un nombre très limité de terminaux et par la suite le nombre des ENs déployés va augmenter ainsi que le coût.

- Trop élevé : la majorité des terminaux vont se connecter à un seul EN, ce qui est contradictoire avec la contrainte de la capacité de demande et avec le nombre maximal des liens pour un EN. Une fois un seuil permettant que n'importe quelle cellule est capable de se connecter à n'importe quel edge les solutions données par le solver sont équivalentes même si on augmente encore le $Rn$.

Quand $Rn$ atteint la valeur 20, nous avons remarqué que le modèle exige l'activation de 2 passerelles (La passerelle 388 pour certains exemples). Nous pouvons expliquer ce déploiement d'une passerelle supplémentaire par le fait que le modèle arrive à une solution ou le coût des liens commence à dépasser le coût d'une passerelle. Donc pour minimiser le coût général du déploiement de l'architecture basée sur le Fog, il est préférable d'activer une deuxième passerelle éloignée et de supprimer des liens sur des longues distances du FN concerné (dans notre exemple 414) vers la passerelle qui connecte la majorité des FNs. La solution optimale ne veut pas dire forcément moins de noeuds activés mais plutôt le moindre coût possible, et comme les liens dépendent des distances, il sera parfois nécessaire de comparer les coûts d'installation par rapport au coût du câblage. Dans les autres cas, où la valeur
de Rn est différente de 20, la différence entre le coût du câblage et le coût d'activation des noeuds est beaucoup plus grande donc le modèle active une seule passerelle.

En ce qui concerne Rn = 25, on remarque d'après les tableaux présentés auparavant et les courbes illustrées sur la figure 4.18, que c'est une valeur critique où le modèle met le plus de temps pour converger. Nous pouvons expliquer cette augmentation en terme de temps de résolution par le fait que 25 est une valeur intermédiaire ou médiane et elle n'est pas suffisante pour couvrir n'importe quel terminal par n'importe que EN sur l'ensemble de l'atelier.

Le temps de résolution est l'une des sorties du solver pour laquelle on peut comparer la légèreté du modèle. D'après les courbes qui tracent le temps en fonction de la variation de Rn et de r, on peut constater qu'il existe une allure similaire entre les différentes courbes malgré le fait que les valeurs ne sont pas identiques. Cette différence des valeurs de temps est dûe non seulement à la différence d'instance mais aussi à l'état de l'ordinateur lors de la résolution du modèle (travail sur autre programme, lancement d'anti-virus, etc.) ce qui joue un rôle important dans la variation du temps de résolution. Nous remarquons également que avec toutes les variations de r, que le coût se stabilise à partir de Rn = 30. Après cette valeur de Rn, le coût reste fixe mais par contre le temps de résolution commence à croître à cause de l'exploration de nouvelles possibilités de solutions que des r plus petits ne le permettent pas.

D'après les résultats de l'étude de sensibilité on remarque que l'augmentation de la quantité de données dans un atelier de production demande plus de noeuds fog et ce même si la couverture du réseau WIFI est plus large. On remarque que nous avons eu besoin de plus de noeuds fog (nombre FN = 4) pour un Rn = 25 quand la quantité de donnée est augmentée à r = 25. Avec une quantité donnée inférieure le nombre de FN est de 3 uniquement.

A travers cette étude on peut donner quelques recommandations pour les industriels qui veulent installer des réseaux avec des noeuds Fog. Il faut choisir un nombre adapté à la moyenne des quantité de données générées par les terminaux de telle sorte que l'on assure un coût minimal permettant plus de flexibilité par rapport à la quantité de données générées. Cela peut être traduit par la modification des outils de production. Dans ce cas il faut que le réseau supporte cette variation sans demander une modification sur le réseau. Par exemple, dans notre cas il est préférable de choisir un Rn = 25m et 4 nœud Fog.

## Le modèle avec la contrainte de la probabilité de demande de réseau

Le paramétrage de cette partie est le même que les autres parties afin de garder le même exemple pour juger l'effet de cette nouvelle contrainte sur le coût de l'intégration de la solution basée sur le Fog Manufacturing et sur le nombre des noeuds activés.

La figure 4.19 schématise la nouvelle configuration des nœuds constituant l'architecture basée sur le Fog Manufacturing en intégrant la contrainte de la probabilité du réseau sur le modèle de petite taille. Les nœuds activées et les liens établis sont présentés. Le nombre des noeuds Edge est réduit de 3 ENs (7,12,30) à 2 noeuds activés (12,30). Par conséquence, le coût *Cost* du déploiement du Fog Manufacturing est réduit de *Cost* = 765 au *Cost* = 605. Les résultats sont présentés par la figure 4.20. On remarque une amélioration au niveau de la solution optimale grâce à l'intégration de la probabilité de la demande de réseau. Cette contrainte agit principalement pour diminuer le coût dans les zones ou les AGVs ne se déplacent pas (sur les trajectoires de déplacement), ce qui entraîne une diminution des ENs dans ces zones.
<figure><img src="image_53.png" /><figcaption>FIGURE 4.18 – les courbes de sortie de l'étude de sensibilité pour la variation de r et Rn.</figcaption></figure>
<figure><img src="image_54.png" /><figcaption>FIGURE 4.19 – Les noeuds activés pour la petite instance du modèle avec la contrainte de probabilité de demande de réseau.</figcaption></figure>

<figure><img src="image_55.png" /><figcaption>FIGURE 4.20 – Le coût et le temps de résolution pour la petite instance du modèle avec la contrainte de probabilité de demande de réseau.</figcaption></figure>
<figure><img src="image_56.png" /><figcaption>FIGURE 4.21 – Les noeuds activés pour la grande instance du modèle avec la contrainte de probabilité de demande de réseau.</figcaption></figure>

La grande instance est ainsi résolue avec l'intégration de cette dernière contrainte. Le temps de calcul a considérablement diminué si on le compare à la résolution du modèle sans la contrainte de la probabilité du réseau. Les résultats présentés sur la figure 4.22 montrent une minimisation importante du coût optimisé initialement dans la section précédente, il est passé de Cost = 6013 à Cost = 2312.

Le modèle avec la contrainte du choix du lien

Lorsque l’on ajoute la contrainte du choix du lien à notre modèle nous avons re-
marqué que la complexité a énormément augmenté et que le nombre de solutions a
atteint quelques millions. Par conséquent, nous avons proposé de diminuer la com-
plexité et à la fois linéariser les équations par la division de la variable de décision
xij en sous variable de décision pour soulager le système et alléger le calcul. Donc,
on aura :

$$
x = xF + xR \tag{4.36}
$$

$$
x = xF_{te} \wedge (xF_{ef} + xR_{ef}) \wedge (xF_{fg} + xR_{fg}) \wedge (xF_{gc} + xR_{gc}) \quad (4.37)
$$

Au lieu de passer par l'ensemble des liens existants à chaque fois, cette dé-
marche aidera à se limiter aux liens de chaque ensemble de deux noeuds consécutifs.
Comme le montre l'équation (4.37), nous exigons que tous les liens soient activés
pour assurer une connexion entre un terminal et le Cloud en passant par tous les
autres noeuds

Les paramètres adoptés sont les mêmes que ceux du premier groupe de résolu-
tion présentés dans la section 4.5.3. Nous ajoutons la variable de la capacité maxi-
male pour l'utilisation d'un câble RJ45, nommé MaxCapR=50.

Dans un premier temps, nous avons commencé par le test sur la petite instance. Les résultats de la simulation du modèle avec le choix du lien sont présentés par la figure 4.23, qui schématise la configuration des noeuds. Le temps d'optimisation a augmenté de 0 à 3 à cause de la nouvelle contrainte et la séparation de la variable de décision en sous variables de décision. Par contre, le coût Z est minimisé et passe de Cost = 605 avec la linéarisation et la contrainte de la probabilité à Cost = 138 avec l'ajout du choix du lien. Ces nouveaux résultats sont présentés sur la figure 4.24. Cette diminution du coût est due au choix du lien et à la réduction du coût des ENs et FNs déployés :

— ENs : De 2 à 4,
<figure><img src="image_57.png" /><figcaption>FIGURE 4.22 – Le coût et le temps de résolution pour la grande instance du modèle avec la contrainte de probabilité de demande de réseau.</figcaption></figure>

— FNs : De 2 à 1,

Dans un deuxième lieu, nous avons lancé la simulation pour la grande instance. le modèle n'a pas convergé pour l'instance complète mais on a réussi à avoir des résultats pour des instances partielle. Plusieurs pistes ont été testé afin de surmonter ce problème ce qui a conduit à des solution non complètes ou la résolution partielle du problème où des modèles trop complexes. L'utilisation des méta-heuristiques est une solution alternative intéressante qui peut être envisagée dans l'avenir. Cela dit, il faut pouvoir la comparer avec des solutions exactes afin de mesurer la distance par rapport à l'optimal. Jusqu'à l'heure de la rédaction de ce manuscrit nous n'avons pas encore résolu ce problème qui va faire la suite immédiate de ce travail.

### 4.5.4 Perspectives

Dans ce qui précède nous avons bien détaillé toutes les contraintes du modèle et nous avons proposé de nouvelles contraintes afin de réduire le coût et améliorer la solution. Par contre au niveau de la dernière étape qui est le choix du lien filaire entre la fibre et le câble RJ45, nous avons rencontré des difficultés concernant la taille du problème qui nous a empêché d'obtenir des résultats optimaux pour cette contrainte. Les perspectives au niveau de cette partie sont d'améliorer le code afin de minimiser encore plus le nombre des variables et par la suite essayer d'optimiser le modèle avec les nouvelles contraintes à l'aide des algorithmes génétiques. Ce choix est fait en se basant sur le fait que le problème a énormément augmenté de taille et a atteint les limites de la capacité de la méthode exacte nécessitant ainsi le passage aux méthodes méta-heuristiques. Ce modèle peut trouver des applications ailleurs que dans le réseau informatique telles que le transport multimodal et le placement de hubs de transport aériens ou logistiques.
<figure><img src="image_58.png" /><figcaption>FIGURE 4.23 – Les noeuds activés pour la petite instance du modèle avec la contrainte du choix du lien.</figcaption></figure>

<table><caption>FIGURE 4.24 – Le coût et le temps de résolution pour la petite instance du modèle avec la contrainte du choix du lien.</caption><thead><tr><th>Node</th><th>BestSoln</th><th>BestBound</th><th>Sols</th><th>Active</th><th>Depth</th><th>Gap</th><th>GInf</th><th>Time</th></tr></thead><tbody><tr><td>108</td><td>138.313708</td><td>113.639589</td><td>8</td><td>27</td><td>11</td><td>17.84%</td><td>7</td><td>2</td></tr><tr><td>211</td><td>138.313708</td><td>116.490700</td><td>8</td><td>41</td><td>11</td><td>15.78%</td><td>69</td><td>3</td></tr><tr><td>313</td><td>138.313708</td><td>120.332053</td><td>8</td><td>11</td><td>10</td><td>13.00%</td><td>99</td><td>3</td></tr><tr><td colspan="9">*** Search completed *** Time: 3 Nodes: 379</td></tr><tr><td colspan="9">Number of integer feasible solutions found is 8</td></tr><tr><td colspan="9">Best integer solution found is 138.313708</td></tr><tr><td colspan="9">Best bound is 138.313624</td></tr><tr><td colspan="9">Uncrunching matrix</td></tr><tr><td colspan="9">Solution:138.314</td></tr><tr><td colspan="9">TotalCost:138.314</td></tr><tr><td colspan="9">Solution:</td></tr><tr><td>t9</td><td>-------</td><td>e7</td><td>-------</td><td>f13</td><td>-------</td><td>g19</td><td>-------</td><td>c21</td></tr><tr><td>t10</td><td>-------</td><td>e6</td><td>-------</td><td>f13</td><td>-------</td><td>g19</td><td>-------</td><td>c21</td></tr><tr><td>t15</td><td>-------</td><td>e1</td><td>-------</td><td>f13</td><td>-------</td><td>g19</td><td>-------</td><td>c21</td></tr><tr><td>t16</td><td>-------</td><td>e6</td><td>-------</td><td>f13</td><td>-------</td><td>g19</td><td>-------</td><td>c21</td></tr><tr><td>t26</td><td>-------</td><td>e12</td><td>-------</td><td>f13</td><td>-------</td><td>g19</td><td>-------</td><td>c21</td></tr><tr><td>t27</td><td>-------</td><td>e12</td><td>-------</td><td>f13</td><td>-------</td><td>g19</td><td>-------</td><td>c21</td></tr><tr><td>t28</td><td>-------</td><td>e1</td><td>-------</td><td>f13</td><td>-------</td><td>g19</td><td>-------</td><td>c21</td></tr></tbody></table>
## 4.6 Conclusion

Dans ce chapitre, un modèle d'optimisation de coût de déploiement de l'architecture Fog Manufacturing pour une application de logistique a été présenté. Le modèle a été expliqué à travers différentes contraintes de façon à analyser leurs intérêts. Ensuite nous avons présenté notre étude portant sur la linéarisation et l'introduction de deux nouvelles contraintes concernant la probabilité de demande du réseau et le type de lien choisi (Fibre ou RJ45). Les résultats de la résolution de ce modèle avec les différents scénarios ont été présentés et comparés. L'analyse des résultats a montré que les nouvelles contraintes ont amélioré notablement la solution optimale du modèle en terme de coût et de nombre de noeuds activés. Dans la suite de ce mémoire, nous allons nous attacher à présenter l'implémentation des résultats de ce modèle sur un cas réel pour évaluer ses performances globales vis-à-vis des critères comme la latence et l'efficacité de filtrage des données.
<figure><img src="image_59.png" /></figure>
# Chapitre 5

# Déploiement d'une plateforme Fog Computing pour le traitement en temps réel d'un CPS de production

## 5.1 Introduction

Le chapitre précédent a présenté un modèle d'optimisation du coût du déploiement du Fog Manufacturing pour une application de logistique dans le contexte de l'Industrie 4.0. Outre le coût optimisé nous avons obtenu comme résultat les coordonnées des noeuds à activer. Dans ce chapitre, nous évaluons expérimentalement les résultats du modèle d'optimisation du coût pour étudier la faisabilité du Fog Manufacturing dans un cas réel. Cette implémentation aidera à évaluer les performances du Fog Manufacturing en termes de collecte et de gestion des données distribuées dans un atelier industriel présentant des CPS.

Cette expérimentation a été appliquée sur le démonstrateur d'usine de futur du laboratoire LINEACT CESI. Dans un premier temps, le principe de la conteneurisation est étudié. Ce principe sera adopté pour la mise en place de l'architecture basée sur le Fog Manufacturing. Dans un second temps, une évaluation de l'approche est faite afin de stocker la localisation des CPS, choisir les équipements et identifier les différents types de connectivité. Pour finir, nous présentons des éléments afin de construire un environnement d'évaluation plus réaliste, en interconnectant les terminaux du démonstrateur (principalement des AGVs) aux ENs, par la suite les ENs aux FNs et enfin établir les liens avec le Cloud via les passerelles. L'objectif visé est de tester la faisabilité d'une solution basée sur le Fog Manufacturing et d'évaluer ses performances pour un simple traitement de données (Exemple : Filtrage de données).

## 5.2 Conteneurisation

Depuis quelques années, les conteneurs ont révolutionné divers domaines en informatique. L'utilisation de la technique de conteneurisation a vu une croissance massive dans le marché des applications informatiques. Ils ont changé la façon de concevoir des applications, tout en permettant aux développeurs de bénéficier de valeur ajoutée en termes de productivité et performance des applications.

### 5.2.1 Définition

Dans le contexte des applications informatiques, un conteneur est utilisé pour bénéficier d'un espace spécifique d'exécution dédié à une application logicielle. Il peut
se présenter sous la forme d'un type abstrait de données, d'une structure d'informa-
tions ou encore d'une classe. Les conteneurs permettent aussi le test d'applications
en cours de développement. L'usage d'un conteneur permet en effet de tester des
applications en cours de développement, ainsi que des logiciels. L'intérêt est de dis-
poser d'un environnement isolé pour réaliser tous les contrôles nécessaires avant le
déploiement d'une architecture (JDN., 2020). Il est donc plus facile de distinguer les
dysfonctionnements, les failles de sécurité et d'éventuels problèmes de stabilité.

Actuellement, les technologies du cloud computing transforment la technolo-
gie traditionnelle par de nouvelles pratiques plus efficaces (BERNSTEIN, 2014). Les
conteneurs en sont un exemple. Ils sont considérés comme l'avenir des machines vir-
tuelles (VM). La virtualisation basée sur les conteneurs est également connue sous le
nom de virtualisation du système d'exploitation, qui permet à la couche de virtuali-
sation de s'exécuter comme une application dans le système d'exploitation (SE/OS).
Les conteneurs sont apparus comme des micro machines virtuelles, plus légères et
plus efficaces car un seul système d'exploitation (OS) gère tous les appels matériels.

Le principe de la conteneurisation est généralement le suivant : les demandes sont emballées sous forme d'images qui contiennent une partie d'un système de fichiers avec les bibliothèques, les exécutables et les fichiers de configuration nécessaires, etc. Les images sont stockées dans des dépôts centralisés où elles sont accessibles à partir de n'importe quel serveur de calcul. Pour déployer un conteneur, il faut commencer par télécharger l'image du dépôt et l'installer localement, à moins que l'image ne soit déjà mise en cache dans le nœud de calcul. Le démarrage d'un conteneur à partir d'une image installée localement est considéré plus rapide que de lancer le processus qui constitue l'application du conteneur. Le temps de déploiement de chaque conteneur est donc déterminé par le temps nécessaire pour télécharger, décompresser, vérifier et localement installer l'image avant de démarrer le conteneur lui-même.

La technologie des conteneurs aide à atténuer le problème de l'exécution des applications logicielles dans divers environnements. Dans la conteneurisation, le SE est partagé par les différents conteneurs plutôt que cloné pour chaque VM. Les conteneurs se composent d'un environnement d'exécution qui comprend l'application logicielle, ses dépendances, les bibliothèques, les binaires et les fichiers de configuration. L'application logicielle s'exécute sur le conteneur et ne dépend pas de l'environnement hôte, à l'exception du système d'exploitation. Un conteneur peut avoir plusieurs applications et chaque application aura son propre environnement. Lorsque le conteneur est déployé dans un environnement différent, le système d'exploitation sera partagé entre les applications.

Actuellement, le modèle de conteneur n'est pas complètement représenté. Appa-
remment, la technologie des conteneurs semble sûre, comme elle contient toutes les
dépendances dans un seul emballage. Cependant, elle n'assure pas sa sécurité. Les
plateformes de conteneurs sont également vulnérables, tout comme les autres plate-
formes de cloud computing. Il existe un certain nombre de menaces qui proviennent
de l'intérieur et de l'extérieur (BUI, 2015).

5.2.2 Conteneurs vs. machines virtuelles

Les machines virtuelles et les conteneurs permettent de répartir le charge de tra-
vail (ou workload) du matériel, mais les deux approches possèdent d'importantes
différences. Le principe de la virtualisation est ainsi résumé : c'est la simulation
d'une ou de nombreuses machines ou systèmes physiques via un hyperviseur afin
de les exécuter sous forme d'une ou nombreuses machines virtuelles-(VM) sur un
serveur. Chaque machine virtuelle est munie d'un SE sur lequel les applications sont exécutées. Les technologies de virtualisation suivantes sont considérées parmi les plus connues :

- VMWare : il s'agit de la technologie la plus populaire, elle est caractérisée par un fort écosystème, la diversification des outils de configuration et d'administration, la possibilité de changer des VMs d'un serveur à un autre et la haute-disponibilité des services,

- Xen (détenue par Citrix),

- KVM (qui s'appuie sur OpenStack pour la partie Hyperviseur et bénéficie du support RedHat).

Concernant la conteneurisation, le conteneur exécute ses applications en faisant appel directement au SE à partir de sa machine physique. Il partage le noyau de la machine à partir duquel les applications sont implémentées. Dans de nombreux cas, il n'est pas obligatoire d'avoir l'assistance d'un hyperviseur pour effectuer la gestion de toutes les VMs qui s'exécuteront par les conteneurs utilisés. Parmi les nombreuses technologies de conteneurisation, le Docker et par la suite le CoreOs sont considérés respectivement les plus connus et utilisés. Le Docker apporte plus de rapidité de déploiement et une gestion fluide de la création des conteneurs et de l'installation des applications. L'avantage d'une telle approche est le faible poids des conteneurs sur lequel la migration des conteneurs d'une machine physique à l'autre est fluide. Ce qui rend la portabilité d'une application d'un Cloud à l'autre, la duplication d'une application sur deux Clouds différents ou l'équilibre du workload plus simple.

En résumant, la virtualisation est basée sur les conteneurs ce qui rend la couche de virtualisation s'exécutant comme étant une application dans le SE. Lorsqu'on compare des conteneurs avec des VMs, les conteneurs sont beaucoup plus légers. Pourtant, chaque VM comprend son propre SE ainsi que l'application. En ce qui concerne les conteneurs, chacun partage le noyau de l'''SE'' hôte avec d'autres conteneurs. Le tableau 5.1 et la figure 5.1 ci-dessous clarifient la différence entre les VMs et les conteneurs :

<figure><img src="image_60.png" /><figcaption>FIGURE 5.1 – Containers vs. VMs (KOSKINEN, 2016).</figcaption></figure>

### 5.2.3 Les plateformes de conteneurisation

Les plateformes de conteneurisation sont conçues pour faciliter le déploiement des conteneurs. Malgré l'existence d'autres plateformes comme Rocket et OpenVZ,
<table><caption>TABLE 5.1 – Conteneurs vs. VMs.</caption><thead><tr><td>Paramètres</td><td>VM</td><td>Conteneurs</td></tr></thead><tbody><tr><td>Système d'exploitation</td><td>Chaque VM s'exécute sur un matériel virtuel et le noyau est chargé dans sa propre région de la mémoire.</td><td>Tous les conteneurs partagent le même OS et le même noyau. L'image du noyau est chargée dans la mémoire physique.</td></tr><tr><td>Communication</td><td>A travers les câbles Ethernet.</td><td>A travers les mécanismes IPC standards comme les signaux et les sockets.</td></tr><tr><td>Sécurité</td><td>Dépend de l'implémentation de l'hyperviseur</td><td>Un contrôle d'accès est obligatoire</td></tr><tr><td>Performance</td><td>Les VMs souffrent d'une surcharge qui s'ajoute lors de la traduction des instructions de l'OS vers L'OS hôte.</td><td>Les conteneurs fournissent une performance très proche de celle de l'OS hôte</td></tr><tr><td>Isolation</td><td>Le partage des fichiers et des libraries entre les VMs invitées ou entre une VM et le système hôte n'est pas possible</td><td>Les sous-répertoires peuvent être partagés d'une manière transparente</td></tr><tr><td>Temps de démarrage</td><td>Les VMs prennent quelques minutes pour démarrer</td><td>Les conteneurs démarrent au bout de quelques secondes</td></tr><tr><td>Stockage</td><td>En Gigaoctets</td><td>En Megaoctets</td></tr></tbody></table>

les plateformes Linux et la plateforme Docker sont les plus populaires.

## Les plateformes Linux

Les conteneurs Linux constituent une solution afin de virtualiser les logiciels au niveau du SE au sein du noyau Linux et permettre à une machine physique hôte d'exécuter de nombreuses instances Linux isolées « conteneurs Linux », ou LXC (LINUX Containers).

- **LXC**: LXC se base sur les groupes de contrôle, ce qui ressemble bien aux conteneurs Docker ou CoreOS. Cette ressemblance est due au fait que le LXC était la technologie sous-jacente qui a fait le succès du Docker et CoreOS. LXC a été à l'origine de la révolution des conteneurs il y a plusieurs années, et les principes LXC et le code LXC restent au coeur du développement des conteneurs (containers),

- **LXD**: LXD est défini comme une extension de LXC. L'un des objectifs fondamentaux du développement de LXD fut de rendre la gestion des conteneurs LXC aussi pratique que celle des machines virtuelles. La manière la plus technique de le définir est de le décrire comme une API REST qui se connecte à libxlc, la bibliothèque logicielle LXC. LXD, qui est écrit dans Go, crée un système daemon auquel les applications peuvent accéder localement à l'aide d'un socket Unix ou via le réseau via HTTPS (containers). Il est à noter qu'un système hôte peut exécuter de nombreux conteneurs LXC en utilisant un seul système daemon, ce qui simplifie la gestion et réduit les frais généraux. LXD offre, également, des fonctionnalités avancées non disponibles auprès de LXC, notamment la migration des conteneurs en direct et la possibilité de prendre une capture d'un conteneur en cours d'exécution.

Les conteneurs Linux proposent également une isolation complète de leur espace de noms. Les fonctions telles que les systèmes de fichiers, les identifiants réseau et utilisateur, ainsi que tout autre élément généralement associé aux SEs, peuvent donc être considérés comme «uniques» pour chaque conteneur.
### La plate-forme Docker

Parmi les logiciels qui lancent des applications sur les conteneurs, on trouve le Docker qui construit, assemble et gère ces applications (AHMED et PIERRE, 2018). Actuellement, Docker est la plate-forme de conteneur la plus populaire. Bien que l'idée d'isoler des environnements remonte assez loin dans le temps, et qu'il y ait eu d'autres logiciels de conteneurs par le passé, Docker est apparu sur le marché au bon moment et était open source depuis le début, ce qui a probablement conduit à sa dominance actuelle.

Solomon Hykes, qui a lancé Docker en tant que projet interne open-source chez dotCloud et qui a immensément contribué au succès des conteneurs précise : "Vous allez tester en utilisant Python 2.7 et par la suite exécuter sur Python 3, et quelque chose de bizarre se produira. Ou peut-être vous comptez sur le comportement d'une certaine version d'une bibliothèque SSL et une autre sera installée. Vous allez exécuter vos tests sur Debian et la production est sur Red Hat et toutes sortes de choses bizarres arrivent" (BERNSTEIN, 2014). Par conséquent, le Docker a été conçu pour utiliser différentes interfaces pour accéder aux caractéristiques de virtualisation du noyau Linux. Au début, Docker bénéficiait de LXC comme étant son environnement d'exécution. Néanmoins, lors de la sortie de la version 0.9, Docker a lâché LXC et a introduit sa propre bibliothèque. Le langage de programmation Go a été adopté afin de concevoir la bibliothèque Docker libcontainer (YASRAB, 2018).

Docker est actuellement open source, ce qui apporte un moyen automatique de déploiement rapide des applications Linux dans les conteneurs. Les développeurs et les administrateurs système bénéficient, tous les deux, de Docker, qui fait partie de plusieurs chaînes d'outils DevOps (développeurs + opérations). Pour les développeurs, cela signifie qu'ils peuvent se concentrer sur l'écriture du code sans se soucier du système sur lequel il sera implémenté. Cela leur permet également de choisir parmi une multitude de programmes déjà conçus pour fonctionner dans un conteneur Docker. En ce qui concerne les opérations, Docker donne de la flexibilité et réduit potentiellement le nombre de systèmes nécessaires en raison de son faible encombrement et de son moindre coût (BACIS et al., 2015).

Par ailleurs, l'objectif des plate-formes de conteneurisation, comme Docker décrit dans cette partie, est d'appuyer l'intégration rapide des applications dans les conteneurs, ainsi que gérer la mise à jour ces conteneurs et non à leur création (cela reste le rôle du noyau Linux). La plate-forme Docker n'est pas apparue pour remplacer les conteneurs Linux mais ils utilisent plutôt LXC comme une base de conteneurisation et ajoute plus de performances en terme de capacité. Comme exemple de ce passage en capacité supérieure, la plate-forme Docker permet le passage des applications entre les machines qui exécutent Docker. Le LXC seul ne peut pas déplacer l'application sur une autre machine possédant plus de capacités.

### 5.2.4 Moteurs d'orchestration des conteneurs

Les plate-formes de conteneurisation sont actuellement employées pour créer des ensembles d'applications hautement évolutifs à la demande. Cette création est admissible pour un nombre limité de conteneurs mais imaginons que l'on en possède des centaines ou des milliers, alors la gestion des conteneurs avec leurs ensembles d'applications devient très difficile, surtout lorsque le nombre d'instances s'accroît dynamiquement suivant la demande des applications.

Afin de surmonter un tel problème de gestion du cycle de vie des conteneurs et des services, l'orchestration de conteneurs se présente comme une solution qui
automatise la planification, le déploiement, l'évolutivité, l'équilibre de charge d'exécution, la disponibilité et la préparations des conteneurs à la mise en réseau.

Les moteurs de conteneurisation sont considérés des outils de gestion de l'infrastructure DevOps. Les COE (Container Orchestration Engine) fournissent une couche d'abstraction entre les ressources et les conteneurs d'applications qui s'exécutent sur ces ressources-là. Ils fournissent des services de haut niveau qui permettent la planification des conteneurs, qui consistent à exécuter des fonctions telles que le démarrage et l'arrêt, la distribution des conteneurs sur les ressources mises en commun, la récupération des conteneurs défectueux et la mise à niveau des applications via des conteneurs.

### 5.2.5 Exemple de moteurs d'orchestration

La liste des moteurs d'orchestration des conteneurs est réellement longue, citons par exemple : Kubernetes, OpenShift, Nomade, Docker Swarm, Docker Compose, MiniKube, Marathon, Cloudify, Rancher, Mesos, etc..

Les moteurs d'orchestration les plus utilisés par les entreprises et avec la plate-forme Docker sont les suivants :

- **Kubernetes** : Kubernetes (également connu sous le nom "k8s") a été publié en Juin 2014, et est écrit en Go. Traduit du grec ancien, le mot Kubernetes signifie "Helmesman" ou "timonier, pilote" en français. Le projet est basé sur l'expérience de Google dans la gestion de conteneurs à grande échelle. Très largement utilisé, Kubernetes a derrière lui une grande communauté. C'est une plate-forme open source qui a été initialement conçue et utilisée par Google, pour son propre service Container as a Service (CaaS), appelé Google Container Engine (GKE). Actuellement elle est maintenue par la Cloud Native Computing Foundation.

Un certain nombre d'autres plates-formes prennent en charge Kubernetes, notamment Red Hat OpenShift et Microsoft Azure. Or, Docker est le moteur des conteneurs le plus présent, supporté par Kubernetes, comme il prend en charge à la fois la configuration déclarative et l'automatisation. Il peut aider à automatiser le déploiement, l'évolutivité, la gestion de la charge de travail et de nombreux services de conteneurisation. La distinction des Kubernetes de Swarm et Mesos est basée sur le concept de «pods», qui constituent des groupes de conteneurs programmés ensemble pour constituer un «service», dans la terminologie de Kubernetes (VOHRA, 2016). Comme le montre la fi-

<figure><img src="image_61.png" /><figcaption>FIGURE 5.2 – Le moteur d'orchestration Kubernetes (Kubernetes).</figcaption></figure>
Figure 5.2 Kubernetes aide à établir la communication entre les différents utilisateurs des applications, les composants du groupe des noeuds kebelet et les composants externes. Le plan de contrôle Kubernetes et les nœuds kebernetes s'exécutent sur un groupe de nœuds qui forment ensemble le cluster. La charge de travail de l'application se forme d'un ou de plusieurs pods qui s'exécutent sur des nœuds de travail. Le plan de contrôle gère les pods et les nœuds de travail.

- **Docker Swarm**: Docker Swarm est un moteur d'orchestration des conteneurs de Docker basé sur un modèle déclaratif. Initialement publié en Novembre 2015, il est également écrit dans Go. Swarmkit est la version recommandée de Docker pour ceux qui souhaitent utiliser Swarm. Swarm est étroitement intégré à l'API Docker, ce qui le rend parfaitement compatible avec Docker. Les mêmes primitives qui s'appliquent à un seul cluster de Docker sont utilisées avec Swarm. Cela peut simplifier la gestion de l'infrastructure des conteneurs, car il n'est pas nécessaire de configurer un moteur d'orchestration distinct ou de ré-apprendre les concepts Docker pour utiliser Swarm (ibid.). Le Docker Swarm comporte deux composants essentiels :

- **Manager**, qui est un leader élu en se basant sur l'algorithme Raft et qui se charge de la gestion d'attribution des tâches aux nœuds de travail. Le manager assure les décisions de gestion et d'orchestration des tâches.

- **Le nœud de travail**, qui reçoit les tâches à exécuter de la part du manager.

<figure><img src="image_62.png" /><figcaption>FIGURE 5.3 – Le moteur d'orchestration Docker Swarm (Swarm).</figcaption></figure>

- **Mesos**: Apache Mesos version 1.0 a été publié en Juillet 2016, mais ce moteur d'orchestration a des racines remontant à 2009, quand il a été initialement développé par des étudiants en doctorat à UC Berkeley. Contrairement à Swarm et Kubernetes, Mesos est écrit en C++. Parmi les fonctionnalités disponibles dans Mesos, on peut mentionner la prise en charge de plusieurs types de moteurs de conteneurs, y compris Docker, ainsi que l'existence d'une interface utilisateur Web et la possibilité de fonctionner sur plusieurs systèmes d'exploitation, y compris Linux, OS X, et même Windows. En raison de sa
complexité et de sa flexibilité, Mesos est plus contraignant en apprentissage que Docker Swarm. Mais cette flexibilité et cette complexité sont également des points forts qui permettent à des entreprises comme Twitter et Airbnb d'utiliser Mesos pour gérer leurs applications à grande échelle (SAHA et al., 2016).

## 5.3 Conception et spécifications des besoins fonctionnels

Notre projet propose une solution basée sur une architecture de Fog Computing, appliquée à un environnement d'Industrie 4.0.

Ce chapitre sera consacré à la présentation des diagrammes de conception (UML). Par la suite, on passera à la justification des différents choix techniques adoptés lors du développement de la solution. Enfin, on présente les différentes interconnections qui vont assurer l'implémentation de l'architecture réelle basée sur le Fog Manufacturing.

Le but de cette partie est de répondre aux besoins potentiels de l'Industrie 4.0 en implémentant une architecture Fog Manufacturing. Il nous faut donc les exprimer clairement avant d'imposer (ou d'orienter vers) une solution finale. Généralement ces besoins sont formulés sous forme d'exigences fonctionnelles, qui sont l'expression de ce que la solution délivrée devrait être. Après étude et identification des besoins fonctionnels, on a procédé à la définition des différents cas d'utilisation et des scénarios d'application.

### 5.3.1 Diagramme de cas d'utilisation

Le diagramme des cas d'utilisation représente un modèle simplifié, afin de décrire le comportement du fonctionnement d'une application ou d'un système tel qu'un utilisateur externe le voit. Le diagramme de cas d'utilisation exprime les besoins des utilisateurs en les traduisant en fonction des cas d'utilisations qu'utilisent les acteurs du service offert.

Les composants d'un diagramme d'utilisation sont généralement :

- Les acteurs, ils sont les utilisateurs qui communiquent avec une application ou un système. Ils peuvent être une personne, une autre application ou un système externe. Ils sont donc nécessairement des entités extérieures qui utilisent les données,

- Le système, c'est le scénario spécifique des actions et des échanges entre les acteurs et le système,

- Les objectifs, sont les résultats finaux des cas d'utilisation. La réussite d'un diagramme dépend de la description de ses activités.

#### Description des acteurs

Un acteur représente une abstraction d'un rôle joué par des entités externes au système qui interagissent directement avec lui. Dans cette application, nous identifions deux types d'acteurs, l'administrateur du système d'information et le robot :

**L'administrateur du système d'information** : Il s'agit d'un acteur principal qui gère les ressources Fog (Les noeuds constituant une architecture basée sur le Fog) et les serveurs Cloud. Ainsi, il assure la collecte et l'acheminement des données vers les bases du Cloud.
**Le robot** : Il s'agit d'un acteur secondaire qui intervient dans notre environnement en générant de l'information en temps réel. Les informations du robot contiennent sa tâche actuelle, son niveau de batterie, sa position, etc..

## Diagramme de cas d'utilisation globale

La figure 5.4 montre le diagramme de cas d'utilisation globale de l'application qui implique tous les acteurs de notre système.

<figure><img src="image_63.png" /><figcaption>FIGURE 5.4 – Diagramme de cas d'utilisation globale du système.</figcaption></figure>

Le diagramme de cas d'utilisation globale du système est développé davantage dans le tableau 5.2.

### 5.3.2 Diagramme de séquences

Les diagrammes de cas d'utilisation modélisent à quoi sert le système, en assurant un ordonnancement des interactions possibles. Le diagramme de séquences permet de décrire les différentes interactions ou messages entre les acteurs et le système d'information, appelés dans ce cas les lignes de vie, selon un ordre chronologique ayant une dimension verticale et s'écoule de haut en bas.

Un message traduit une communication bien spécifique entre des lignes de vie. Il existe différents types de messages, les plus utilisés sont les suivants :

- L'envoi d'un signal,

- L'invocation d'une opération,

- La création ou la destruction d'une instance.

La figure 5.5 représente le diagramme de séquences de notre environnement d'application.
<table><caption>TABLE 5.2 – Cas d'utilisation global du système.</caption><tr><td>Titre</td><td>Accéder aux systèmes d'information</td></tr><tr><td>Description</td><td>Ce cas d'utilisation permet aux utilisateurs ayant le compte administrateur d'accéder aux ressources Fog et Cloud.</td></tr><tr><td>Acteurs</td><td>Administrateurs, Robot</td></tr><tr><td>Pré-conditions</td><td>Les administrateurs doivent être authentifiés pour accéder à ces fonctionnalités.</td></tr><tr><td>Scénario nominal</td><td><ol><li>L'utilisateur s'authentifie.</li><li>L'administrateur affecte une mission au robot.</li><li>Le robot génère de l'information.</li><li>L'administrateur peut accéder aux ressources Fog.</li><li>L'administrateur peut consulter les données stockées au niveau du Cloud.</li></ol></td></tr></table>

<figure><img src="image_64.png" /><figcaption>FIGURE 5.5 – Diagramme de séquence de l'environnement d'application.</figcaption></figure>
## 5.4 Choix Technologiques

Il est important de sélectionner les outils technologiques qui aideront à développer la solution. Ce choix est principalement basé sur le fonctionnement optimal du système, l'impact de la future croissance technologique et le coût de la mise en place. Dans cette section, on présente les moyens technologiques utilisés afin de mettre en place notre solution.

### 5.4.1 Les FNs : Raspberry Pi

#### Le choix des FNs

Pour les équipements du Fog computing ou précisément les FNs, il était prévu que l'on choisisse les routeurs Cisco dédiés à l'exploitation industrielle de la solution Fog, en considérant leur capacité à gérer et analyser les données au niveau de bord du réseau, leur évolutivité, flexibilité, sécurité, capacité de supporter de nombreux protocoles de communication, ainsi que la capacité à filtrer les données provenant des objets connectés.

Néanmoins, on a rencontré au cours de la thèse des contraintes liées aux moyens d'investissement et aux délais (incluant les contraintes liées à la crise sanitaire). Par conséquent, on a choisi un outil beaucoup plus accessible que les routeurs Cisco, et plus simple à manipuler afin de montrer l'applicabilité du Fog Manufacturing sur un cas réel.

L'architecture basée sur le Fog computing doit nécessairement s'appuyer sur un très grand nombre de FNs répartis géographiquement qui ne sont pas des serveurs puissants, mais des machines beaucoup plus faibles. En fait, l'une des options envisagée consiste à utiliser à cette fin des ordinateurs monocarte tels que les Raspberry Pi. Cette technologie est parmi les plus utilisées dans le contexte de l'IoT et dans les applications basées sur le Fog computing.

Malgré leurs limites matérielles évidentes, les Raspberry Pi offrent d'excellents rapports performances/coûts/énergie et sont bien adaptés aux scénarios où la taille physique et la consommation d'énergie du dispositif sont des facteurs importants pour un déploiement réel. Cependant, une application basée sur des FNs Raspberry Pi reste un défi difficile à relever. En particulier, ces machines ont des performances d'entrée/sortie très limitées.

Dans ce travail, on se concentre donc sur le déploiement des conteneurs Docker dans des cartes Raspberry. On part du principe que les serveurs Fog ont une capacité de stockage limitée et que l'on ne peut pas s'attendre à ce qu'elles gardent en mémoire cache les images des conteneurs de nombreuses applications pouvant être utilisées simultanément dans une architecture Fog. Le déploiement des images des conteneurs peut être très lent, de l'ordre de plusieurs minutes selon la taille de l'image du conteneur et l'état du réseau. Toutefois, de tels retards sont inacceptables dans des scénarios où les applications sont sensibles aux latences, où les objets connectés sont mobiles et où les conteneurs doivent être créés dynamiquement lorsqu'un robot mobile change de zone de couverture. Par contre, les capacités limitées du matériel ont permis de mettre en évidence les inefficacités de ce processus, qui seraient plus difficiles à cerner en utilisant des machines serveurs plus rapides.

Ce choix est propre à l'expérimentation de petite taille qui vise à prouver l'apPLICabilité et l'efficacité du Fog Manufacturing. De plus les capacités limitées du matériel sont inadéquates au déploiement sur des problèmes de grande taille.
## Evolution des cartes Raspberry Pi

Le Raspberry Pi est un nano ordinateur, appelé aussi ordinateur à carte unique ou monocarte, créé par David Braben dans le cadre de son association caritative Raspberry Pi. Le premier modèle du Raspberry Pi était en 2011 avec des caractéristiques plus au moins médiocres (le processeur à 700 MHz et la mémoire RAM de 128Mo), arrivant de nos jours au Pi3 qui porte des spécifications satisfaisantes que nous allons citer par la suite (RASPBERRYPI., 2020).

## Fiche technique du Raspberry Pi3

Comme le montre la figure 5.6 (ibid.), la carte Raspberry Pi3 porte :

- Un processeur Cortex-A53 (ARMv8) 64-bit à 1.4GHz - BCM2837B0.

- Une mémoire vive de 1GB LPDDR2 SDRAM

- Un module Wifi 2.4GHz and 5GHz IEEE 802.11.b/g/n/ac

- Un module Bluetooth 4.2

- Un port Ethernet 10/100

- Quatre ports USB 2.0

- Un lecteur Micro SD

- 5V/2.5A DC power input

- Un connecteur HDMI

- Le système d'exploitation convenable pour la carte Raspberry Pi est le Raspbian qui est un OS libre basé sur Debian GNU/Linux optimisé. Pour faciliter diverses tâches, la fondation Raspberry Pi a conçu le système d'exploitation NOOBS.

<figure><img src="image_65.png" /><figcaption>FIGURE 5.6 – Carte Raspberry Pi3 (RASPBERRYPI., 2020).</figcaption></figure>

Comme détaillé auparavant, le Raspberry Pi a la taille d'une carte de crédit donc il est très léger (45g). L'unité de Raspberry posséde un coût très faible (aux alentours de 37 euros) et elle a des capacités puissantes, ce qui amène à un rapport qualité prix très raisonnable. Enfin, cette dernière comporte une diversité de ports tels que USB, HDMI, ethernet, etc. De plus, il est important de souligner que derrière cette
carte, il y a une grande communauté, très active, ce qui permet de trouver différents projets, forums, blogs qui travaillent sur son développement pour de nombreuses applications comprenant les applications basées sur le Fog computing.

## 5.4.2 Langage de programmation, Python

Python est un langage de programmation facile à apprendre, à comprendre, à lire et à écrire.

Python rend la compréhension de la structure du programme plus facile à apprendre que d'autres langages populaires, comme le montre la figure 5.7 (python). La couleur orange présente les langages de programmation les plus utilisés, par contre la grise présente celles les moins utilisés. La largeur des cercle sur la figure dépend du pourcentage d'utilisation du langage de programmation concerné.

Ce langage est polyvalent. Il exécute des sites Web et il est utilisé dans beaucoup d'applications populaires de bureau sur des PC et des Macs. Il peut aussi exister dans des applications mobiles et être incorporé dans beaucoup de dispositifs.

<figure><img src="image_66.png" /><figcaption>FIGURE 5.7 – Utilisation de Python par rapport aux autres langages.</figcaption></figure>

## 5.4.3 Logiciel libre de conteneurisation, Docker

Il est impératif de considérer le type de déploiement en question avant de faire le choix de la plateforme de conteneurisation. Mais si on a l'intention de virtualiser un OS entier, ou d'exécuter une application virtuelle persistante pendant une longue période, LXD sera probablement une meilleure solution. Dans le cas où il y aurait un lancement rapide d'un grand nombre de conteneurs sur la base d'images d'applications génériques, il vaut mieux utiliser Docker ou CoreOS. Le deuxième facteur à considérer est l'environnement hôte. LXD ne supporte que Linux et il n'est documenté que pour Ubuntu. Donc, il y aurait certainement un problème lors de l'exécution de LXD dans le cas où une version de Windows ou une autre version de
Linux est utilisée. En revanche, Docker est assez portable sur presque tous les OS basés sur Linux, et maintenant exécutable sous Windows et OSX.

### 5.4.4 Orchestrateur des conteneurs, Kubernetes

Kubernetes est aujourd'hui un concurrent supérieur et (le plus) fort sur le marché. De plus, Kubernetes est techniquement supérieur aux autres orcherstrateurs des conteneurs. De meilleures dispositions de vérification de l'état de santé au niveau du pod, une meilleure planification et mise à l'échelle des conteneurs, des espaces de noms avec des contrôles d'accès basés sur les rôles et des stratégies réseaux pour contrôler le trafic entrant et sortant entre les services lui confèrent un avantage conséquent. Même les fournisseurs de cloud choisissent de passer aux services gérés de Kubernetes.

## 5.5 Connectivité

Les deux paradigmes de Cloud Computing et de Fog Computing ne fonctionnent que dans un environnement peuplé, doté d'une connectivité riche et à haut débit. Toutefois, les dispositifs IoT doivent être déployés dans des zones accessibles qui ont une connectivité Internet avec le monde extérieur. Le manque de connectivité empêche effectivement ces dispositifs IoT isolés d'accéder au ENs, FNs ou les passerelles aux Cloud. Cela nécessite un choix de connectivité selon le niveau et la nature de l'environnement : la capacité à connecter, la capacité maximale de connectivité des noeuds de l'architecture, la connectivité des dispositifs mobiles à la demande et la quantité maximale de données à transmettre.

L'architecture basée sur le Fog Manufacturing comporte de nombreuses couches intégrant des noeuds de natures différentes, impliquant forcément que les liens entre deux couches consécutives seront différents afin d'assurer la continuité de la connectivité.

Dans cette section, nous expliquons les différentes parties qui entrent en jeu dans notre architecture. Ces équipements sont : CPS fixes (machines, imprimantes 3D, découpes laser ou postes manuels) ou mobiles (AGVs), ENs : Points d'accès Wi-Fi, FNs : Cartes Raspberry Pi3, Passerelles : Routeurs, Cloud : serveur Big Data.

La figure 5.8 représente l'interconnexion entre les composantes de notre solution.

Les prochaines sous sections décriront les différents types de connectivités que l'on a créées afin de mettre en place notre architecture.

- **Liaison AGV - PAs** : On a supposé que les CPS fixes et mobiles seront liés en Wi-Fi au PA (point d'accès) à proximité, les robots mobiles sont connectés Wi-Fi aux points d'accès déjà installés sur tout l'atelier. Les robots envoient instantanément les données générées par les capteurs vers les points d'accès qui sont bien distribués sur l'atelier dans le but de garantir une large couverture de l'espace de présence des CPS,

- **Liaison PAs - LAN** : La liaison entre les points d'accès et les routeurs du LAN s'est établie filaire en utilisant les câbles Ethernet. Les points d'accès vont acheminer le trafic de données vers les routeurs du LAN. Ce trafic s'oriente par la suite vers le cluster de Raspberry pour le filtrage,

- **Liaison LAN - Cartes Raspberry** : Les cartes Raspberry sont connectées au réseau local à travers les câbles Ethernet. Les cartes Raspberry contrôlent le
<figure><img src="image_67.png" /><figcaption>FIGURE 5.8 – Les liens entre les composants de l'architecture basée sur le Fog Manufacturing.</figcaption></figure>

flux des données en entrée et puis transforment le format de données de XML en JSON,

- **Liaison LAN - Data center** : Après filtrage des données au niveau des cartes Raspberry, les données vont être orientées vers le Data Centre pour les stocker. Les routeurs du LAN acheminent le trafic à travers le passage par le réseau Internet,

A travers cette section, on a pu présenter la conception du système d'information au sein de l'atelier de production flexible. Dans cette conception, on a introduit la couche Fog et on a spécifié les différents moyens de communications existants dans l'architecture.

## 5.6 Réalisation

Après avoir identifié l'architecture, les outils technologiques ainsi que les différents types de connectivité, on passe à la réalisation de l'architecture basée sur le Fog Manufacturing. Au cours de cette section, on citera les différentes étapes de l'implémentation, on expliquera la démarche technique suivie et puis on citera les différentes difficultés rencontrées et les perspectives de cette réalisation.

### 5.6.1 Déroulement

Cette étude s'est élaborée en deux phases :

- La première phase est l'implémentation initiale sans l'intégration des liens avec les AGVs. Durant cette phase, l'objectif est de simuler l'architecture basée sur le Fog en générant des données aléatoires, ce qui permet de détecter les carences avant de rendre l'application plus complexe. Durant cette étape on s'assure que les liens sont correctement établis et que tous les noeuds sont
interconnectés. On teste également la couverture sur l'ensemble de l'atelier de production.

— La deuxième phase est celle de l'implémentation réelle et finale de l'architecture en impliquant l'intégralité des noeuds, y compris les AGVs. Cette étape sert à tester l'effet de la solution Fog Manufacturing sur une fonctionnalité de données. Le test est fait par le stockage des données filtrées par les FNs dans le data center du Cloud.

## Première phase : sans intégration des robots

Dans un premier temps, on propose de tester le temps de transfert que mettent les données pour arriver des sources de données jusqu'aux noeuds Fog. C'est pour cela que nous simulons les robots par deux PCs qui génèrent des données aléatoires et les envoient périodiquement aux noeuds Fog. La figure 5.9 représente cette phase.

<figure><img src="image_68.png" /><figcaption>FIGURE 5.9 – Implémentation sans intégration des robots.</figcaption></figure>

A travers cette première phase, on a pu estimer le temps de transfert moyen que mettent 1000 lignes de données générées et envoyées par les PCs connectés en WiFi jusqu'à leurs réceptions au niveau du cluster du couche Fog. Le temps de transfert, représenté sur la figure 5.10, est inférieur à 100 ms. Ce résultat est satisfaisant pour plusieurs applications nécessitant des traitements en temps réel.

## Deuxième phase : avec intégration des robots

Concernant la deuxième phase, on intègre les robots et on commence la collecte des données réelles. Les robots envoient instantanément des balises XML, présentées par la figure 5.11. Elles sont décrites dans ce qui suit :

— "Status" : la tâche que le robot exécute.

— "Map" : la région dans laquelle le robot se trouve.

— "Current time" : la date de l'information sous le format universelle.

— "Battery" : le niveau de batterie.

— "Status number" : le label de la tâche exécutée.
## FIGURE 5.10 – Temps de Transfert des données.
— "Status time" : la durée dans laquelle le robot est dans cette tâche.

— "x,y" : la position (x,y) du robot.

— "Theta" : l'angle d'orientation que fait le robot.

<figure><img src="image_69.png" /><figcaption>FIGURE 5.11 – Données sous format XML.</figcaption></figure>

Par la suite et au niveau des noeuds Fog, nous avons installé un module de contrôle de données pour éviter les lignes qui contiennent des valeurs nulles ou bien des valeurs erronées. Après le contrôle et le filtrage, les données sont transformées sous format JSON (figure 5.12) pour être acheminées vers le serveur du Data Centre.

<figure><img src="image_70.png" /><figcaption>FIGURE 5.12 – Données sous format JSON.</figcaption></figure>

## 5.6.2 Test et résultats de l'implémentation technique

Les deux phases identifiées dans la section précédente vont être implémentées tout d'abord sur une machine virtuelle par la suite transférée sous la forme d'une image conteneur vers le cluster.
Développement & Test de l'application sur une Machine Virtuelle

En utilisant la programmation Socket, on a développé une application composée d'une partie serveur et d'une autre client. D'un côté, on genère des données aléatoires et on les envoie. De l'autre côté, on réceptionne ces données et on calcule le temps de transfert. La figure 5.13 montre l'application qui tourne en machine virtuelle.

Création du conteneur

Dans le but de faciliter le déploiement de l'application, on a conteneurisé la partie Fog de l'application afin de la mettre en marche sur le cluster des cartes RPi.

Tout d'abord, on a créé le Dockerfile, représenté sur la figure 5.14, dans lequel on a précisé :

— "FROM python:3.7-alpine" : il s'agit de l'image de base utilisée.

— "Application source code Directory" : création d'un répertoire pour le code source de l'application.

— "Home directory for containers" : Changement du repertoire courant.

— "Source code" : Copier le code source dans le conteneur.

— "Ports" : Exposer le port 5000.

— "Persistent data" : Partager un dossier de log.

— "CMD ["python", "server.py"]" : Faire tourner le code source sous python.

Ensuite, on a construit l'image Docker, sur la figure 5.15, image qui est ensuite exécutée pour la tester, puis chargée sur DockerHub.

Le Docker Hub est une plateforme similaire au GitHub mais elle est dédiée aux images Docker seulement. Cette plateforme, représentée en figure 5.16, permet d'uploadeur, télécharger et mettre à jour les images Docker utilisées dans la preuve de concept de ce chapitre.

Déploiement de l'image dans le cluster

La figure 5.17 présente le cluster, sachant que nous avons utilisé trois cartes Raspberry Pi3, les deux niveaux qui se trouvent en bas sont des "travailleurs" et la carte en haut est le manager du cluster.

On se connecte sur les cartes Raspberry en SSH, on initialise le Kubernetes cluster sur la carte Manager, puis on intègre les autres cartes en tant que Workers.

En initialisant le Kubernetes Cluter, le manager génère un Token, représenté dans la figure 5.18, qui permet aux travailleurs de rejoindre le cluster.
<figure><img src="image_71.png" /><figcaption>FIGURE 5.13 – Application sous machine virtuelle.</figcaption></figure>
<figure><img src="image_72.png" /><figcaption>FIGURE 5.14 – Docker File.</figcaption></figure>

La figure 5.19 montre le statut de chacune des instances du cluster. Après l'initialisation du cluster au niveau du Manager et l'intégration des deux autres cartes en tant que Worker, les instances du cluster demeurent maintenant prêtes et disponibles pour l'exécution.

Par conséquent, on a lancé le tableau de bord Kubernetes afin de pouvoir déployer l'image sur le cluster déjà prête. Comme le présente la figure 5.20, on réalise le déploiement en faisant appel à l'image du conteneur, en indiquant le nombre de pods et en choisissant la nature du service et le port désigné.

Une fois déployés (figure 5.21), les noeuds travailleurs commencent à exécuter l'image Docker.

### 5.6.3 Difficultés techniques rencontrées

On a rencontré de nombreuses difficultés tout au long de cette partie aussi bien du point de vue communication que de point du vue traitement de données.

#### Communication entre les noeuds de l'architecture

Au début de l'étude, la difficulté majeure rencontrée était de faire transmettre les données (à partir des robots) au cluster Kubernetes. La communication via les Sockets mises en place comporte deux parties; la première est celle du côté robot dans laquelle on a adressé la communication vers l'IP du noeud Manager et on a utilisé le port de communication 5000; la deuxième est celle du Fog qui écoute sur le port 5000. Cependant, la connexion n'était pas établie et une erreur de "Connection Refused" affichée. Cette erreur, selon la documentation, est généralement due au blocage du port ou à son utilisation par un autre programme. En examinant le fichier
```
pi@rpiManager:~/fogcontainer $ sh build.sh
Sending build context to Docker daemon 7.68kB
Step 1/8 : FROM python:3.7-alpine
 ---> 479a172d0d26
Step 2/8 : RUN mkdir -p /FogAPP/src
 ---> Using cache
 ---> f3a4d14ec2fc
Step 3/8 : WORKDIR /FogAPP/src
 ---> Using cache
 ---> a8745ae7961f
Step 4/8 : COPY fogserver.py /FogAPP/src
 ---> Using cache
 ---> 5dc00bf4d49d
Step 5/8 : ENV APP_ENV development
 ---> Using cache
 ---> 5d9a093fead8
Step 6/8 : EXPOSE 5000
 ---> Using cache
 ---> 204df4dcf954
Step 7/8 : VOLUME ["/app-data"]
 ---> Using cache
 ---> c3b8374654a5
Step 8/8 : CMD ["python", "fogserver.py"]
 ---> Using cache
 ---> e902f8152a5f
Successfully built e902f8152a5f
Successfully tagged fogapp:latest
pi@rpiManager:~/fogcontainer $ sh run.sh
..................Hi Omar! I am waiting for tasks..................
```

<caption>FIGURE 5.15 – Building de l'image Docker.</caption>
<figure><img src="image_73.png" /><figcaption>FIGURE 5.16 – Docker Hub.</figcaption></figure>

<figure><img src="image_74.png" /><figcaption>FIGURE 5.17 – Cluster de Raspberry.</figcaption></figure>
<figure><img src="image_75.png" /><figcaption>FIGURE 5.18 – Initialisation du Cluster.</figcaption></figure>

<figure><img src="image_76.png" /><figcaption>FIGURE 5.19 – Distribution des noeuds.</figcaption></figure>

<figure><img src="image_77.png" /><figcaption>FIGURE 5.20 – Déploiement de l'image Docker.</figcaption></figure>
<figure><img src="image_78.png" /><figcaption>FIGURE 5.21 – Kubernetes Dashboard.</figcaption></figure>

de configuration de Kubernetes, on a trouvé un autre port attribué dynamiquement par l'orchestrateur Kubernetes, représenté sur la figure 5.22, appelé nodePort.

En revenant à la documentation de Kubernetes, on a compris que l'orchestrateur Kubernetes alloue automatiquement un port dans l'intervalle [30000-32767], ce port expose les services à l'intérieur et à l'extérieur du cluster. Nous avons pallié ce problème en utilisant le nodePort alloué par l'orchestrateur Kubernetes au niveau du robot, c'est à dire que le robot envoie les données sur le port désigné par le cluster.

## Traitement temps réel

Nous avons rencontré un problème de communication simultanée puisque les deux robots envoient les données au cluster en même temps. Cependant, le cluster ne traite que les données venant du premier robot et il semble indisponible pour le deuxième robot. Ce problème était important parce qu'il ne satisfait pas nos objectifs. On a attendu d'avoir un cluster de haute disponibilité, capable de traiter un flux de données venant de différents robots simultanément.

On a résolu ce problème à l'aide de la programmation parallèle en utilisant les threads, appelée Multithreading, ce qui revient à exécuter plusieurs threads ensemble. En utilisant le Multithreading au niveau des noeuds du cluster, ce dernier demeure capable d'écouter plusieurs robots (qui envoient simultanément leurs données).

## 5.6.4 Perspectives

Nous sommes arrivés aujourd'hui à avoir une architecture basée sur le Fog Manufacturing qui couvre les CPS d'un atelier d'Industrie 4.0. Les FNs assurent le filtrage des données et leur stockage permanent au niveau de la couche des serveurs Cloud. On a atteint plus de 30000 lignes de données historiques stockées.
<figure><img src="image_79.png" /><figcaption>FIGURE 5.22 – Fichier de configuration Kubernetes.</figcaption></figure>
Comme perspectives, on peut profiter de ce grand volume de données pour mettre en place un modèle d'apprentissage automatique. Nous envisageons d'implémenter un système d'alerte pour les robots en fonction de leurs positions. C'est-à-dire que si le robot est dans une localisation erronée, le système l'avertit et il lui donne la position dans laquelle il devrait être.

Les données stockées dans le Cloud vont être subdivisées en trois parties :

- Training set : ceux sont les données d'entraînement sur lesquelles le modèle apprend.

- Validation set : les données de validation sont utilisées pour évaluer le modèle, mais ceci est pour une évaluation fréquente. Ces données servent à recréifier les hyperparamètres du modèle.

- Test set : Les données du test mesurent l'erreur du modèle final sur des données qu'il n'a jamais vues.

Le modèle s'entraîne afin de prédire la position $(\hat{X}, \hat{Y})$ du robot. Après le training, la validation et le test du modèle au niveau du Cloud, on met en place le modèle au niveau de la couche Fog. Ensuite, le modèle reçoit en temps réel les informations du robot et il retourne les valeurs prédites de $(\hat{X}, \hat{Y})$. A partir d'un seuil d'erreur entre $(\hat{X}, \hat{Y})$ et $(X, Y)$, la couche Fog avertit le robot et elle lui demande d'aller vers la position appropriée.

### 5.6.5 Conclusion

L'architecture basée sur le Fog Manufacturing a montré un grand potentiel en terme de mise en oeuvre de solutions distribuées pour le contrôle et la supervision d'un atelier de production flexible. En outre, sa mise en oeuvre réelle est actuellement possible, grâce à la disponibilité du matériel, des logiciels et de technologies comme la carte Raspberry, Docker et Kubernetes.

En outre, cette simulation a démontré par une mise en oeuvre réelle que l'utilisation du Fog Computing peut répondre à deux grands défis de l'industrie 4.0 qui sont l'interopérabilité de différents systèmes et la scalabilité du système d'informations. Grâce à l'intégration de la technologie Docker et à la haute performance de l'orchestrateur Kubernetes dans l'architecture Fog Computing, nous avons réalisé un prototype évolutif et interopérable. L'ajout de nouveaux noeuds Fog, des managers ou des robots utilisant différents systèmes d'exploitation devient plus facile à gérer. Par exemple, dans notre cas, nous avons ajouté un noeud Manager supplémentaire dans notre cluster afin d'assurer la redondance et la tolérance aux pannes.
<figure><img src="image_80.png" /></figure>
# Chapitre 6

## Conclusion générale

Cette thèse s'inscrit dans le cadre du traitement distribué en temps réel dans les systèmes cyber-physiques industriels et plus particulièrement le déploiement du Fog computing dans le contexte de l'Industrie 4.0 (Appelé Fog Manufacturing). Ces travaux de thèse proposent deux aboutissements, le premier, théorique, qui consiste en l'identification des défis limitant le déploiement du Fog dans le contexte de l'Industrie 4.0 et le second, plus pratique, propose un modèle d'optimisation du coût et son implémentation sur un cas réel. Le déploiement du Fog Manufacturing vise à distribuer la collecte puis le traitement des données des CPS dans l'industrie du futur pour des fins de logistique, de traçabilité, de surveillance, de maintenance, etc. Pour accomplir ces objectifs, les CPS sont équipés par des capteurs qui génèrent périodiquement les données qui seront envoyées par la suite aux noeuds de l'architecture basée sur le Fog Computing (ENs, FNs et passerelles), qui sont déployés uniformément dans l'usine. Ce déploiement va satisfaire de nombreux défis tout en optimisant le coût d'installation.

Via un état de l'art, le chapitre 2 retrace le concept de l'Industrie 4.0 comme étant la nouvelle révolution industrielle basée sur de nombreux composants (IoT, IoS, CPS, Cloud computing, Big Data, RA, etc.), ainsi que les premiers travaux relatifs à ce concept, à ses intégrations et exigences. Ensuite, une étude sur la solution du Fog computing est réalisée en étudiant ses caractéristiques, son architecture, les travaux intégrant le Fog computing et en réalisant une comparaison avec le Cloud computing. Ce chapitre introduit finalement notre problématique générale dans le contexte de l'Industrie 4.0, qui consiste en l'intégration du Fog computing afin d'améliorer les performances du Cloud computing, tout en traitant localement et d'un façon distribuée les données. Le Fog computing dans ce contexte ne va pas supprimer les services du Cloud computing, mais il vient étendre les services du Cloud au bord du réseau.

Dans la première partie du chapitre 3, nous avons étudié les différentes applications qui intègrent le Fog computing pour améliorer les performances de l'Industrie 4.0. Une telle vision du Fog est appelée le "Fog Manufacturing". Nous avons constaté que son déploiement dans les industries demeure modeste et qu'il n'existe pas une exploitation complète des caractéristiques du Fog computing. Cette emploi modéré est dû principalement à deux raisons majeures : d'une part l'apparition récente des deux paradigmes de l'Industrie 4.0 (2011) et du Fog computing (2015) et d'autre part la présence de nombreux défis qui limitent une telle intégration.

Notre première contribution a consisté à identifier les défis du déploiement du Fog computing dans le contexte de l'Industrie 4.0. Ainsi, dans la deuxième partie du chapitre 3, face à ces différents constats, nous avons donc spécifié les défis Input suivants :

- **Programmabilité** : Comment choisir les FNs programmables afin d'assurer une bonne performance en termes de calcul et de stockage local ?
— **Sécurité** : Comment assurer une communication sécurisée et confidentielle des données entre les FNs et les différents composants de l'architecture ?

— **Hétérogénéité** : Comment faire varier les différents SEs dans l'environnement de production sans affaiblir le fonctionnement du Fog Manufacturing ?

— **Intéropérabilité** : Comment assurer une communication entre les différents CPS lors d'un envoi des données des terminaux aux FNs ?

Les défis Outputs sont les suivants :

— **QoS** : Comment transmettre efficacement les données dans l'architecture du Fog Manufacturing ? Le terme efficacité se réfère à des contraintes de fiabilité, de délai, de taux d'erreur, etc.

— **Énergie** : Comment assurer une faible consommation d'énergie des différents composants de l'architecture basée sur le Fog Manufacturing ?

— **Coût** : Finalement, comment garder le coût du déploiement du Fog Manufacturing faible tout en surmontant tous les autres défis mentionnés ci-dessus.

Cette identification des différents défis est notre première contribution scientifique. Elle nous a conduit à l'étude des liens entre les différents défis, étude réalisée en se basant sur les indicateurs de performance. Il ressort de cette étude que le fait de surmonter un des défis Input permet de surmonter ses défis connexes et parmi eux les défis Output. Finalement, nous avons cité les applications industrielles qui possèdent des caractéristiques nécessitant l'intégration du Fog Manufacturing pour distribuer le traitement en temps réel des données massives provenant des CPS. Ce croisement des besoins et des caractéristiques nous a permis de justifier notre choix de l'application de logistique.

La problématique scientifique et technique pointue ensuite traitée, a porté sur l'optimisation du coût du déploiement du Fog Manufacturing afin de faciliter son implémentation sur un cas réel. Pour répondre à ces interrogations concernant le coût et la QoS, nous avons proposé dans le chapitre 4 un modèle d'optimisation du coût du déploiement du Fog Manufacturing dans une application de logistique interne à l'usine. La première partie a présenté un état de l'art sur le déploiement du Fog computing dans la logistique, et par la suite nous avons présenté une étude sur la problématique de déploiement du Fog Manufacturing dans ce contexte.

La deuxième contribution associée au chapitre 4 est la proposition d'un modèle d'optimisation du coût du déploiement du Fog manufacturing dans une application de logistique interne. Nous avons contribué à l'amélioration du modèle d'optimisation en assurant la linéarisation des contraintes dans un premier temps. Cette étape a amélioré le modèle en termes de convergence et de temps de résolution. Par la suite, nous avons proposé l'introduction de deux nouvelles contraintes qui sont :

— La probabilité de la présence des AGVs sur une trajectoire définie pour le déplacement. Cela entraîne la modification de la concentration en ENs aux alentours des trajectoires. La simulation du modèle en intégrant cette contrainte a optimisé le coût et le nombre des noeuds activés.

— Le choix du lien filaire entre les différents noeuds de l'architecture (RJ45 ou fibre) selon la capacité de demande des noeuds de la couche inférieure.

Le modèle fut résolu à l'aide de la méthode exacte et du solveur Fico xpress. Malgré la difficulté et la complexité du problème, nous avons obtenu des premiers résultats prometteurs mais cela reste une piste intéressante à améliorer et développer.

Nous avons évalué le résultat du modèle d'optimisation du coût par une simulation dans le chapitre 5. Nous avons déployé une véritable plate-forme de Fog Computing pour pré-traiter les données sur un CPS de production. Notre plate-forme est également basée sur la technologie Docker qui permet de traiter les données d'une
manière conteneurisée. Par cette étude, nous avons prouvé l'efficacité de notre plate-forme en termes de temps de communication (latence), de scalabilité et d'interopérabilité. Quant aux FNs, ils ont montré aussi de bonnes performances pour le filtrage des données.

L'objectif initial de cette thèse était de prouver l'applicabilité du Fog Manufacturing malgré les nombreux défis que cela met en jeu, ainsi qu'optimiser le déploiement du Fog Manufacturing dans la logistique, sans oublier le fait d'appliquer réellement le Fog Manufacturing, en se basant sur une architecture distribuée. Ces résultats théoriques ont été publiés dans quatre conférences internationales. Les résultats sur le modèle d'optimisation du coût sont actuellement soumis dans une revue internationale. La suite de nos travaux va donc consister à améliorer la phase d'ingénierie en utilisant des FNs performant afin de tester de nombreux types de traitement de données dans des situations applicatives réelles. Nous pensons que le Fog computing va continuer à grandir tout en répondant aux exigences des technologies émergentes. Parallèlement, le Cloud computing continuera à fournir des services et à répondre aux demandes d'accès au Cloud computing.

Les perspectives sont donc à court terme :

- Compléter le travail sur la contrainte du choix du lien filaire (fibre ou RJ45). Il faut par la suite passer à l'utilisation de méthodes méta-heuristiques, comme les algorithmes génétiques, afin de traiter le problème de multiplier à de nombreuses reprises le nombre d'instances, comme présenté dans le chapitre 4. Une comparaison entre la méthode exacte et les algorithmes génétiques peut se faire. Par la suite nous pensons à alléger le calcul, afin d'accélérer la convergence du modèle même avec une grande instance, en combinant les contraintes.

- Enrichir le modèle en considérant des terminaux hétérogènes présents dans l'atelier de production, et en diversifiant leurs paramètres fixés dans le cadre de ce travail. Cela permettrait de personnaliser le modèle selon les demandes de chaque type de CPS. Cette étape vise à améliorer les résultats d'optimisation.

À plus long terme, plusieurs perspectives s'offrent et constituent des perspectives très intéressantes :

- Faire évoluer la modélisation des défis. Les défis identifiés au niveau du chapitre 3 sont présentés en fonction de leurs PIs, mais il serait très intéressant d'introduire les équations séquentielles afin de modéliser ces défis limitant l'intégration du Fog Manufacturing,

- Examiner d'autre défis à surmonter au delà du coût et de la QoS. Nous pourrions par exemple travailler sur un modèle multi-objectif qui intègre comme deuxième objectif la consommation d'énergie des noeuds de l'architecture basée sur le Fog manufacturing. Cette optimisation peut améliorer le modèle et faciliter l'intégration du Fog.

- Envisager d'autres applications possibles pour appliquer le modèle. Les contraintes peuvent être adaptées aux composants de l'atelier de production. Par exemple, appliquer le Fog Manufacturing pour la supervision des robots collaboratifs dans un atelier de production.

- Améliorer l'efficacité de l'applicabilité de l'architecture basée sur le Fog Manufacturing en déployant des serveurs Fog (par exemple des routeurs industriel Cisco) et avec un grand nombre de noeuds (à grande échelle).

- Étendre le déploiement du Fog Manufacturing pour de nouvelles fonctionnalités (calcul des modèles légers, traitement selon la priorité, prise de décision
en temps réel). On pourrait par exemple imaginer d'utiliser le Fog Manufac-
turing pour assurer la prise des décisions urgentes selon les priorités de la
source.

— Introduire les concepts de l'Industrie 5.0. Ce terme industrie 5.0, centré sur l'humain, a été introduit récemment. Il est en lien avec l'articulation et les interactions entre humains, CPS, machines intelligentes, robots, tirant avancages de technologies avancées et innovantes comme l'intelligence artificielle, la science des données (incluant acquisitions et traitements efficients et rapides), les interfaces humains -machines avancées, ... et, potentiellement, le Fog Manufacturing qui pourrait induire une valeur ajoutée non négligeable!
Bibliographie

URL: http://www.rfidglobal.eu/userfiles/documents/CASAGRAS26022009.pdf.

AAZAM, Mohammad et Eui-Nam HUH (2014). « Fog computing and smart gateway based communication for cloud of things ». In : *Future Internet of Things and Cloud (FiCloud), 2014 International Conference on*. IEEE, p. 464-470.

— (2015). « Dynamic resource provisioning through Fog micro datacenter ». In : *Per-vasive Computing and Communication Workshops (PerCom Workshops), 2015 IEEE International Conference on*. IEEE, p. 105-110.

AHMED, Arif et Guillaume PIERRE (2018). « Docker container deployment in fog computing infrastructures ». In : *2018 IEEE International Conference on Edge Com-puting (EDGE)*. IEEE, p. 1-8.

AHMED, Ejaz et Mubashir Husain REHMANI (2017). *Mobile edge computing : opportu-nities, solutions, and challenges*.

AI, Yuan, Mugen PENG et Kecheng ZHANG (2018). « Edge computing technologies for Internet of Things : a primer ». In : *Digital Communications and Networks* 4.2, p. 77-86.

AL-FUQAHA, Ala et al. (2015). « Internet of things : A survey on enabling technolo-gies, protocols, and applications ». In : *IEEE Communications Surveys & Tutorials* 17.4, p. 2347-2376.

AL YAMI, Mohammed et Dirk SCHAEFER (2019). « Fog Computing as a Complementary Approach to Cloud Computing ». In : *2019 International Conference on Computer and Information Sciences (ICCIS)*. IEEE, p. 1-5.

ALHAZMI, Omar H et Khalid S ALOUFI (2019). « Fog-based internet of things : a security scheme ». In : *2019 2nd International Conference on Computer Applications & Information Security (ICCAIS)*. IEEE, p. 1-6.

ALMADA-LOBO, Francisco (2016). « The Industry 4.0 revolution and the future of manufacturing execution systems (MES) ». In : *Journal of Innovation Management* 3.4, p. 16-21.

ANDROCEC, Darko, Neven VRCEK et Jurica SEVA (2012). « Cloud computing ontolo-gies : A systematic review ». In : *Proceedings of the third international conference on models and ontology-based design of protocols, architectures and services*, p. 9-14.

ASHTON, Kevin (2011). « That ‘internet of things’ thing ». In : *RFiD Journal* 22.7.

ATZORI, Luigi, Antonio IERA et Giacomo MORABITO (2010). « The internet of things : A survey ». In : *Computer networks* 54.15, p. 2787-2805.

BACCARELLI, Enzo et al. (2017). « Fog of everything : Energy-efficient networked computing architectures, research challenges, and a case study ». In : *IEEE access* 5, p. 9882-9910.

BACIS, Enrico et al. (2015). « DockerPolicyModules : mandatory access control for docker containers ». In : *2015 IEEE Conference on Communications and Network Security (CNS)*. IEEE, p. 749-750.

BAHTOVSKI, Aleksandar et Marjan GUSEV (2014). « Cloudlet challenges ». In : *Procedia Engineering* 69, p. 704-711.
BANERJEE, Ayan et al. (2012). « Ensuring safety, security, and sustainability of mission-critical cyber-physical systems ». In : *Proceedings of the IEEE* 100.1, p. 283-299.

BAR-MAGEN NUMHAUSER, Jonathan et Jose Antonio Gutierrez de MESA (2013). « XMPP Distributed Topology as a Potential Solution for Fog Computing ». In : *MESH 2013 The Sixth International Conference on Advances in Mesh Networks*.

BELKADI, Farouk et al. (2017). « Collaboration management framework for OEM-suppliers relationships : a trust-based conceptual approach ». In : *Enterprise Information Systems* 11.7, p. 1018-1042.

BENATIA, Mohamed Amin et al. (2018). « QR-code enabled product traceability system : A big data perspective ». In : *Advances in transdisciplinary engineering*, p. 323-328.

BERNSTEIN, David (2014). « Containers and cloud : From lxc to docker to kubernetes ». In : *IEEE Cloud Computing* 1.3, p. 81-84.

BETTAYEB, B, SJ BASSETTO et M SAHNOUN (2014). « Quality control planning to prevent excessive scrap production ». In : *Journal of Manufacturing Systems* 33.3, p. 400-411.

BILL, Lydon (2016). « ORGIndustry 4.0 : Intelligent and flexible productionDigitization ». In :

BLANCO-NOVOA, Óscar et al. (2018). « A practical evaluation of commercial industrial augmented reality systems in an industry 4.0 shipyard ». In : *IEEE Access* 6, p. 8201-8218.

BONOMI, Flavio et al. (2012). « Fog computing and its role in the internet of things ». In : *Proceedings of the first edition of the MCC workshop on Mobile cloud computing*. ACM, p. 13-16.

BONOMI, Flavio et al. (2014). « Fog computing : A platform for internet of things and analytics ». In : *Big Data and Internet of Things : A Roadmap for Smart Environments*. Springer, p. 169-186.

BOUZARKOUNA, Imen et al. (2018). « Challenges facing the industrial implementation of Fog Computing ». In : *2018 IEEE 6th International Conference on Future Internet of Things and Cloud (FiCloud)*. IEEE, p. 341-348.

BOYES, Hugh et al. (2018). « The industrial internet of things (IIoT) : An analysis framework ». In : *Computers in Industry* 101, p. 1-12.

BRIK, Bouziane et al. (2019). « Towards Predicting System Disruption in Industry 4.0 : Machine Learning-Based Approach ». In : *Procedia Computer Science* 151, p. 667-674.

BRITO, Mathias Santos de et al. (2018). « Application of the fog computing paradigm to smart factories and cyber-physical systems ». In : *Transactions on Emerging Telecommunications Technologies* 29.4, e3184.

BROGI, Antonio et Stefano FORTI (2017). « QoS-aware deployment of IoT applications through the fog ». In : *IEEE Internet of Things Journal* 4.5, p. 1185-1192.

BRUNER, Jon (2013). *Industrial Internet*. " O'Reilly Media, Inc."

BUI, Thanh (2015). « Analysis of docker security ». In : *arXiv preprint arXiv:1501.02967*.

BUYUKKOC, Cagatay (2016). « Edge definition and how it fits with 5g era networks ». In : *IEEE Software Defined Networks, Newsletter.[Online]*. Available : http://sdn.ieee.org/newsletter/march-2016/edge-definition-and-how-it-fits-with-5g-era-networks.

BUYYA, Rajkumar, Rodrigo N CALHEIROS et Xiaorong LI (2012). « Autonomic cloud computing : Open challenges and architectural elements ». In : *Emerging Applications of Information Technology (EAIT), 2012 Third International Conference on*. IEEE, p. 3-10.
CHANG, Chii, Satish Narayana SRIRAMA et Rajkumar BUYYA (2017). « Indie Fog : An Efficient Fog-Computing Infrastructure for the Internet of Things ». In : *Computer* 50.9, p. 92-98.

CHEKIRED, Djabir Abdeldjalil, Lyes KHOUKHI et Hussein T MOUFTAH (2018). « Industrial IoT data scheduling based on hierarchical fog computing : a key for enabling smart factory ». In : *IEEE Transactions on Industrial Informatics* 14.10, p. 4590-4602.

CHEN, Min, Shiwen MAO et Yunhao LIU (2014). « Big data : A survey ». In : *Mobile Networks and Applications* 19.2, p. 171-209.

CHEN, Rui-Yang (2017). « An intelligent value stream-based approach to collaboration of food traceability cyber physical system by fog computing ». In : *Food Control* 71, p. 124-136.

CHEN, Siguang et al. (2019). « Delay guaranteed energy-efficient computation offloading for industrial IoT in fog computing ». In : *ICC 2019-2019 IEEE International Conference on Communications (ICC)*. IEEE, p. 1-6.

CHEN, Yan, Yu WANG et Daofu GONG (2019). « Fog computing support scheme based on fusion of location service and privacy preservation for QoS enhancement ». In : *Peer-to-Peer Networking and Applications* 12.6, p. 1480-1488.

CHIANG, Mung et Tao ZHANG (2016). « Fog and IoT : An overview of research opportunities ». In : *IEEE Internet of Things Journal* 3.6, p. 854-864.

CHIARELLO, Filippo et al. (2018). « Extracting and mapping industry 4.0 technologies using wikipedia ». In : *Computers in Industry* 100, p. 244-257.

ÇIFLIKLI, Cebrail et Esra KAHYA-ÖZYIRMIDOKUZ (2010). « Implementing a data mining solution for enhancing carpet manufacturing productivity ». In : *Knowledge-Based Systems* 23.8, p. 783-788.

COLOMBO, Armando W et al. (2017). « Industrial Cyberphysical Systems : A Backbone of the Fourth Industrial Revolution ». In : *IEEE Industrial Electronics Magazine* 11.1, p. 6-16.

COMPUTING, Fog (2016). *the Internet of Things : Extend the Cloud to Where the Things Are*.

DANTU, Karthik, Steven Y KO et Lukasz ZIAREK (2017). « RAINA : Reliability and Adaptability in Android for Fog Computing ». In : *IEEE Communications Magazine* 55.4, p. 41-45.

DASTJERDI, Amir Vahid et Rajkumar BUYYA (2016). « Fog computing : Helping the Internet of Things realize its potential ». In : *Computer* 49.8, p. 112-116.

DASTJERDI, Amir Vahid et al. (2016). « Fog computing : Principles, architectures, and applications ». In : *arXiv preprint arXiv:1601.02752*.

DE BRITO, Mathias Santos et al. (2016). « Towards programmable fog nodes in smart factories ». In : *2016 IEEE 1st International Workshops on Foundations and Applications of Self* Systems (FAS* W). IEEE, p. 236-241.

DIBAJI, Seyed Mehran et al. (2019). « A systems and control perspective of CPS security ». In : *Annual Reviews in Control*.

DOLUI, Koustabh et Soumya Kanti DATTA (2017). « Comparison of edge computing implementations : Fog computing, cloudlet and mobile edge computing ». In : *Global Internet of Things Summit (GIoTS)*, 2017. IEEE, p. 1-6.

DRATH, Rainer et Alexander HORCH (2014). « Industrie 4.0 : Hit or hype? [industry forum] ». In : *IEEE industrial electronics magazine* 8.2, p. 56-58.

DUBEY, Harishchandra et al. (2017). « Fog Computing in Medical Internet-of-Things : Architecture, Implementation, and Applications ». In : *Handbook of Large-Scale Distributed Computing in Smart Healthcare*. Springer, p. 281-321.
DUCQ, Yves et David CHEN (2008). « How to measure interoperability : Concept and Approach ». In : 2008 IEEE International Technology Management Conference (ICE). IEEE, p. 1-8.

ELGENDY, Ibrahim A et al. (2019). « Resource allocation and computation offloading with data security for mobile edge computing ». In : *Future Generation Computer Systems* 100, p. 531-541.

EVANS, Dave (2011). « The internet of things : How the next evolution of the internet is changing everything ». In : *CISCO white paper* 1.2011, p. 1-11.

FERREIRO, Susana et al. (2016). « Industry 4.0 : predictive intelligent maintenance for production equipment ». In : *European Conference of the Prognostics and Health Management Society, no*, p. 1-8.

FIRDHOUS, Mohamed, Osman GHAZALI et Suhaidi HASSAN (2014). « Fog computing : Will it be the future of cloud computing? » In : *The Third International Conference on Informatics & Applications (ICIA2014)*.

FRAGA-LAMAS, Paula et al. (2018). « A Review on Industrial Augmented Reality Systems for the Industry 4.0 Shipyard ». In : *IEEE Access* 6, p. 13358-13375.

FRAGA-LAMAS, Paula et al. (2019). « Design and Validation of a Bluetooth 5 Fog Computing Based Industrial CPS Architecture for Intelligent Industry 4.0 Shipyard Workshops ». In : *arXiv preprint arXiv:1903.00713*.

GAZIS, Vangelis et al. (2015). « Components of fog computing in an industrial internet of things context ». In : *Sensing, Communication, and Networking-Workshops (SECON Workshops), 2015 12th Annual IEEE International Conference on*. IEEE, p. 1-6.

GEORGAKOPOULOS, Dimitrios et al. (2016). « Internet of Things and edge cloud computing roadmap for manufacturing ». In : *IEEE Cloud Computing* 3.4, p. 66-73.

GRANGEL-GONZÁLEZ, Irlán et al. (2016). « Towards a semantic administrative shell for industry 4.0 components ». In : *Semantic Computing (ICSC), 2016 10th International Conference on*. IEEE, p. 230-237.

GRÖGER, Christoph, Florian NIEDERMANN et Bernhard MITSCHANG (2012). « Data mining-driven manufacturing process optimization ». In : *Proceedings of the world congress on engineering*. T. 3, p. 4-6.

GU, Lin et al. (2015). « Cost efficient resource management in fog computing supported medical cyber-physical system ». In : *IEEE Transactions on Emerging Topics in Computing* 5.1, p. 108-119.

GUAN, Yunguo et al. (2018). « Data security and privacy in fog computing ». In : *IEEE Network* 32.5, p. 106-111.

GUBBI, Jayavardhana et al. (2013). « Internet of Things (IoT) : A vision, architectural elements, and future directions ». In : *Future generation computer systems* 29.7, p. 1645-1660.

GUPTA, Harshit et al. (2016). « ifogsim : A toolkit for modeling and simulation of resource management techniques in internet of things, edge and fog computing environments ». In : *arXiv preprint arXiv:1606.02007*.

HASHIZUME, Keiko et al. (2013). « An analysis of security issues for cloud computing ». In : *Journal of Internet Services and Applications* 4.1, p. 5.

HENG, Stefan (2014). « Industry 4.0 : Upgrading of Germany's Industrial Capabilities on the Horizon ». In :

HERMANN, Mario, Tobias PENTEK et Boris OTTO (2016). « Design principles for industrie 4.0 scenarios ». In : *System Sciences (HICSS), 2016 49th Hawaii International Conference on*. IEEE, p. 3928-3937.

HOFMANN, Erik et Marco RÜSCH (2017). « Industry 4.0 and the current status as well as future prospects on logistics ». In : *Computers in Industry* 89, p. 23-34.
HONG, Kirak et al. (2013a). « Mobile fog : A programming model for large-scale applications on the internet of things ». In: *Proceedings of the second ACM SIGCOMM workshop on Mobile cloud computing*. ACM, p. 15-20.

— (2013b). « Opportunistic spatio-temporal event processing for mobile situation awareness ». In: *Proceedings of the 7th ACM international conference on Distributed event-based systems*. ACM, p. 195-206.

HU, Pengfei et al. (2017a). « Fog computing-based face identification and resolution scheme in internet of things ». In: *IEEE Transactions on Industrial Informatics*.

HU, Pengfei et al. (2017b). « Security and privacy preservation scheme of face identification and resolution framework using fog computing in internet of things ». In: *IEEE Internet of Things Journal* 4.5, p. 1143-1155.

IMKAMP, Dietrich et al. (2016). « Challenges and trends in manufacturing measurement technology–the “Industrie 4.0” concept ». In: *Journal of Sensors and Sensor Systems* 5.2, p. 325-335.

INTELLIGENCE, SRI Consulting Business (2008). « Disruptive civil technologies ». In: *Six technologies with potential impacts on US interests out to 2025*.

ISLAM, Mohammad Manzurul, Sarwar MORSHED et Parijat GOSWAMI (2013). « Cloud computing : A survey on its limitations and potential solutions ». In: *International Journal of Computer Science Issues (IJCSI)* 10.4, p. 159.

IVANOV, Dmitry, Alexander TSPOULANIDIS et Jörn SCHÖNBERGER (2019). « Digital Supply Chain, Smart Operations and Industry 4.0 ». In: *Global Supply Chain and Operations Management*. Springer, p. 481-526.

JALALI, Fatemeh et al. (2016). « Fog computing may help to save energy in cloud computing ». In: *IEEE Journal on Selected Areas in Communications* 34.5, p. 1728-1739.

JAZDI, Nasser (2014). « Cyber physical systems in the context of Industry 4.0 ». In: *Automation, Quality and Testing, Robotics, 2014 IEEE International Conference on*. IEEE, p. 1-4.

JDN. (2020). *Conteneur en informatique : définition précise et fonctionnement*. url = https://www.journaldunet.fr/web-tech/dictionnaire-du-webmastering/1445240-conteneur-en-informatique-definition-precise-et-fonctionnement/. Accessed: 2021-04-25.

KAGERMANN, Henning et al. (2013). *Recommendations for implementing the strategic initiative INDUSTRIE 4.0 : Securing the future of German manufacturing industry; final report of the Industrie 4.0 Working Group*. Forschungsunion.

KANG, Hyoung Seok et al. (2016). « Smart manufacturing : Past research, present findings, and future directions ». In: *International journal of precision engineering and manufacturing-green technology* 3.1, p. 111-128.

KANICKAM, S Hendry Leo, L JAYASIMMAN et A Nisha JEBASEELI (2017). « A Survey on Layer Wise Issues and Challenges in Cloud Security ». In: *Computing and Communication Technologies (WCCCT), 2017 World Congress on*. IEEE, p. 168-171.

KHAN, Saad, Simon PARKINSON et Yongrui QIN (2017). « Fog computing security : a review of current applications and security solutions ». In: *Journal of Cloud Computing* 6.1, p. 1-22.

KHAN, Waqas Ali et al. (2017). « Analysis of the requirements for offering industrie 4.0 applications as a cloud service ». In: *Industrial Electronics (ISIE), 2017 IEEE 26th International Symposium on*. IEEE, p. 1181-1188.

KHERBOUCHE, Lynda et Zohra OUBAHRI (2017). « Quelques méthodes de résolutions en optimisation combinatoire ». Thèse de doct. UMMTO.

KIANI, Abbas, Nirwan ANSARI et Abdallah KHREISHAH (2019). « Hierarchical capacity provisioning for fog computing ». In: *IEEE/ACM Transactions on Networking*.
KOPRAS, Bartosz, Filip IDZIKOWSKI et Paweł KRYSZKIEWICZ (2019). « Power Consumption and Delay in Wired Parts of Fog Computing Networks ». In : 2019 IEEE Sustainability through ICT Summit (StICT). IEEE, p. 1-8.

KOSKINEN, Miina (2016). « Microservices and containers : benefits and best practices ». In :

KRAEMER, Frank Alexander et al. (2017). « Fog Computing in Healthcare–A Review and Discussion ». In : *IEEE Access*.

KUBERNETSS. Kubernetes. https://www.https://kubernetes.io/.

LA, Quang Duy et al. (2019). « Enabling intelligence in fog computing to achieve energy and latency reduction ». In : *Digital Communications and Networks* 5.1, p. 3-9.

LEE, Edward A (2006). « Cyber-physical systems-are computing foundations adequate ». In : *Position Paper for NSF Workshop On Cyber-Physical Systems : Research Motivation, Techniques and Roadmap*. T. 2.

LEE, Gilsoo, Walid SAAD et Mehdi BENNIS (2018). « Online optimization for UAV-assisted distributed fog computing in smart factories of industry 4.0 ». In : 2018 IEEE Global Communications Conference (GLOBECOM). IEEE, p. 1-6.

LEE, Jay, Moslem AZAMFAR et Jaskaran SINGH (2019). « A blockchain enabled Cyber-Physical System architecture for Industry 4.0 manufacturing systems ». In : *Manufacturing Letters* 20, p. 34-39.

LEE, Jay, Behrad BAGHERI et Hung-An KAO (2015). « A cyber-physical systems architecture for industry 4.0-based manufacturing systems ». In : *Manufacturing Letters* 3, p. 18-23.

LEE, Jay, Hung-An KAO et Shanhu YANG (2014). « Service innovation and smart analytics for industry 4.0 and big data environment ». In : *Procedia CIRP* 16, p. 3-8.

LEE, Jay et al. (2015). « Industrial big data analytics and cyber-physical systems for future maintenance & service innovation ». In : *Procedia CIRP* 38, p. 3-7.

LENZINI, Gabriele, Sjouke MAUW et Samir OUCHANI (2016). « Analysing the Efficiency of Security Policies in Cyber-Physical Socio-Technical Systems ». In : *International Workshop on Security and Trust Management*. Springer, p. 170-178.

LIN, Chun-Cheng et Jhih-Wun YANG (2018). « Cost-efficient Deployment of Fog Computing Systems at Logistics Centers in Industry 4.0 ». In : *IEEE Transactions on Industrial Informatics*.

LIN, Shi-Wan et al. (2015). « Industrial internet reference architecture ». In : *Industrial Internet Consortium (IIC), Tech. Rep.*.

LIU, Yang, Jonathan E FIELDSEND et Geyong MIN (2017). « A Framework of Fog Computing : Architecture, Challenges and Optimization ». In : *IEEE Access*.

LOM, Michal, Ondrej PRIBYL et Miroslav SVITEK (2016). « Industry 4.0 as a part of smart cities ». In : *Smart Cities Symposium Prague (SCSP), 2016*. IEEE, p. 1-6.

LOPEZ (2014). « Building smarter Manufacturing With The Internet of Things (IoT) ». In : *The IoT Series*.

LUAN, Tom H et al. (2015). « Fog computing : Focusing on mobile users at the edge ». In : *arXiv preprint arXiv:1502.01815*.

LUONG, Nguyen Cong et al. (2016). « Data collection and wireless communication in internet of things (iot) using economic analysis and pricing models : a survey ». In : *IEEE Communications Surveys & Tutorials* 18.4, p. 2546-2590.

MAHMUD, Redowan et al. (2019a). « Context-aware placement of industry 4.0 applications in fog computing environments ». In : *IEEE Transactions on Industrial Informatics*.
MAHMUD, Redowan et al. (2019b). « Quality of Experience (QoE)-aware placement of applications in Fog computing environments ». In : *Journal of Parallel and Distributed Computing* 132, p. 190-203.

MANAVALAN, E et K JAYAKRISHNA (2019). « A review of Internet of Things (IoT) embedded sustainable supply chain for industry 4.0 requirements ». In : *Computers & Industrial Engineering* 127, p. 925-953.

MARKAKIS, Evangelos K et al. (2017). « EXEGESIS : Extreme Edge Resource Harvesting for a Virtualized Fog Environment ». In : *IEEE Communications Magazine* 55.7, p. 173-179.

MATT, Christian (2018). « Fog computing ». In : *Business & information systems engineering* 60.4, p. 351-355.

MATTERN, Friedemann et Christian FLOERKEMEIER (2010). « From the Internet of Computers to the Internet of Things ». In : *From active data management to event-based systems and more*, p. 242-259.

MEIDAN, Yair et al. (2011). « Cycle-time key factor identification and prediction in semiconductor manufacturing using machine learning and data mining ». In : *IEEE Transactions on Semiconductor Manufacturing* 24.2, p. 237-248.

MELL, Peter, Tim GRANCE et al. (2011). « The NIST definition of cloud computing ». In :

MIHALACHE, Alin Gabriel (2007). « Modélisation et évaluation de la fiabilité des systèmes mécatroniques : application sur système embarqué ». Thèse de doct.

MUKHERJEE, Mithun et al. (2017a). « A fog computing-based framework to reduce traffic overhead in large-scale industrial applications ». In : *Computer Communications Workshops (INFOCOM WKSHPS), 2017 IEEE Conference on*. IEEE, p. 1008-1009.

MUKHERJEE, Mithun et al. (2017b). « Security and Privacy in Fog Computing : Challenges ». In : *IEEE Access*.

MUTLAG, Ammar Awad et al. (2019). « Enabling technologies for fog computing in healthcare IoT systems ». In : *Future Generation Computer Systems* 90, p. 62-78.

NAIN, Grégory et al. (2010). « Integrating iot and ios with a component-based approach ». In : *Software Engineering and Advanced Applications (SEAA), 2010 36th EUROMICRO Conference on*. IEEE, p. 191-198.

NEGASH, Behailu, Tomi WESTERLUND et Hannu TENHUNEN (2019). « Towards an interoperable Internet of Things through a web of virtual things at the Fog layer ». In : *Future Generation Computer Systems* 91, p. 96-107.

NI, Jianbing et al. (2017). « Securing fog computing for internet of things applications : Challenges and solutions ». In : *IEEE Communications Surveys & Tutorials* 20.1, p. 601-628.

NING, Zhaolong, Jun HUANG et Xiaojie WANG (2019). « Vehicular fog computing : Enabling real-time traffic management for smart cities ». In : *IEEE Wireless Communications* 26.1, p. 87-93.

NIST. (2020). *Trustworthy Systems, Components, and Data for Smart Manufacturing Program*. https://www.nist.gov/programs-projects/trustworthy-systems-components-and-data-smart-manufacturing-program. Accessed : 2021-04-20.

O'DONOVAN, Peter et al. (2018). « A fog computing industrial cyber-physical system for embedded low-latency machine learning Industry 4.0 applications ». In : *Manufacturing Letters* 15, p. 139-142.

OPENFOG. Fogconsortium. https://www.openfogconsortium.org/.

OSANAIYE, Opeyemi et al. (2017). « From cloud to fog computing : A review and a conceptual live VM migration framework ». In : *IEEE Access*.
O'DONOVAN, Peter et al. (2019). « A comparison of fog and cloud computing cyber-physical interfaces for Industry 4.0 real-time embedded machine learning engineering applications ». In: *Computers in Industry* 110, p. 12-35.

PALLEWATTA, Samodha, Vassilis KOSTAKOS et Rajkumar BUYYA (2019). « Microservices-based IoT Application Placement within Heterogeneous and Resource Constrained Fog Computing Environments ». In: *Proceedings of the 12th IEEE/ACM International Conference on Utility and Cloud Computing*, p. 71-81.

PALLIS, George (2010). « Cloud computing : the new frontier of internet computing ». In : *IEEE internet computing* 14.5, p. 70-73.

PAN, Jianli et James MCELHANNON (2017). « Future edge cloud and edge computing for internet of things applications ». In : *IEEE Internet of Things Journal* 5.1, p. 439-449.

PERALTA, Goiuri et al. (2017). « Fog computing based efficient IoT scheme for the Industry 4.0 ». In : 2017 *IEEE International Workshop of Electronics, Control, Measurement, Signals and their Application to Mechatronics (ECMSM)*. IEEE, p. 1-6.

PERERA, Charith et al. (2014). « Context aware computing for the internet of things : A survey ». In : *IEEE Communications Surveys & Tutorials* 16.1, p. 414-454.

PERERA, Charith et al. (2017). « Fog computing for sustainable smart cities : a survey ». In : *arXiv preprint arXiv:1703.07079*.

PISCHING, Marcos A et al. (2015). « Service Composition in the Cloud-Based Manufacturing Focused on the Industry 4.0. » In : *DoCEIS*, p. 65-72.

PIZOŃ, Jakub et Jerzy LIPSKI (2016). « Perspectives for Fog Computing in Manufacturing ». In : *Applied Computer Science* 12.

PORTER, Michael E et James E HEPPELMANN (2015). « How smart, connected products are transforming companies ». In : *Harvard business review* 93.10, p. 96-114.

PUTHAL, Deepak et al. (2019). « Fog Computing Security Challenges and Future Directions [Energy and Security] ». In : *IEEE Consumer Electronics Magazine* 8.3, p. 92-96.

QI, Qinglin et Fei TAO (2019). « A Smart Manufacturing Service System Based on Edge Computing, Fog Computing, and Cloud Computing ». In : *IEEE Access* 7, p. 86769-86777.

QU, T et al. (2016). « IoT-based real-time production logistics synchronization system under smart cloud manufacturing ». In : *The International Journal of Advanced Manufacturing Technology* 84.1-4, p. 147-164.

RAHMAN, Hafizur et Md Iftekhar HUSSAIN (2019). « Fog-based semantic model for supporting interoperability in IoT ». In : *IET Communications* 13.11, p. 1651-1661.

RAHMANI, Amir M et al. (2018). « Exploiting smart e-health gateways at the edge of healthcare internet-of-things : a fog computing approach ». In : *Future Generation Computer Systems* 78, p. 641-658.

RAJKUMAR, Ragunathan Raj et al. (2010). « Cyber-physical systems : the next computing revolution ». In : *Proceedings of the 47th Design Automation Conference. ACM*, p. 731-736.

RAMALHO, Flávio de Sousa (2016). « SmartEdge : fog computing cloud extensions to support latency-sensitive IoT applications ». Mém. de mast. Brasil.

RASPBERRYPI. (2020). *Raspberry pi 3 mode*. url = https://www.raspberrypi.org/products/raspberry-pi-3-model-b-plus/. Accessed : 2021-04-22.

RAZVAN BEURAN, RB (2004). « Mesure de la qualité dans les réseaux informatiques ». Thèse de doct. Jean Monnet U.

REZABAKHSH, Behrang et al. (2006). « Consumer power : a comparison of the old economy and the Internet economy ». In : *Journal of Consumer Policy* 29.1, p. 3-36.