Last typo rapport
This commit is contained in:
Leopold Clement
parent
513db00589
commit
fb9be95864
6 changed files with 88 additions and 194 deletions
|
|
@ -210,7 +210,7 @@
|
|||
|
||||
%------- Abréviations, langages et programme utiles
|
||||
|
||||
\newcommand{\ens}{École normale supérieur Paris-Saclay}
|
||||
\newcommand{\ens}{École normale supérieure Paris-Saclay}
|
||||
\newcommand{\matlab}{\textsc{Matlab}}
|
||||
\newcommand{\python}{\emph{python}}
|
||||
|
||||
|
|
|
|||
19
makefile
19
makefile
|
|
@ -1,6 +1,6 @@
|
|||
FIGURES_SVG=$(wildcard raw_img/*.svg)
|
||||
FIGURES_PDF=$(subst raw_img/,pdf_img/,$(FIGURES_SVG:.svg=.pdf_tex))
|
||||
FIGURES_PNG=$(subst raw_img/,png_svg_img/,$(FIGURES_SVG:.svg=.png))
|
||||
FIGURES_PDF=$(FIGURES_SVG:.svg=.pdf_tex)
|
||||
FIGURES_PNG=$(FIGURES_SVG:.svg=.png)
|
||||
|
||||
DOT_DOT=$(wildcard dot/*.dot)
|
||||
DOT_PNG=$(DOT_DOT:.dot=.png)
|
||||
|
|
@ -14,9 +14,9 @@ all : rapport.pdf poster.pdf
|
|||
|
||||
rapport.pdf : rapport.tex rapport.bib $(FIGURES_PNG) $(UML_PNG) png_img/gain_action.png $(DOT_PNG)
|
||||
lualatex -shell-escape rapport.tex
|
||||
bibtex rapport
|
||||
makeglossaries rapport
|
||||
lualatex -shell-escape rapport.tex
|
||||
bibtex rapport
|
||||
lualatex -shell-escape rapport.tex
|
||||
lualatex -shell-escape rapport.tex
|
||||
|
||||
|
|
@ -25,7 +25,6 @@ poster.pdf : poster.tex poster.bib $(FIGURES_PNG) $(UML_PNG) png_img/gain_action
|
|||
bibtex poster
|
||||
lualatex -shell-escape poster.tex
|
||||
lualatex -shell-escape poster.tex
|
||||
lualatex -shell-escape poster.tex
|
||||
|
||||
rapport.bib : biblio.bib
|
||||
cp biblio.bib rapport.bib
|
||||
|
|
@ -37,12 +36,14 @@ png_img/gain_action.png :
|
|||
python3 png_img/gen_fig_g.py
|
||||
|
||||
clean : clean-rapport clean-poster
|
||||
rm -f -r pdf_img/
|
||||
rm -f -r png_svg_img/
|
||||
rm -f -r svg_img/*.png
|
||||
rm -f -r svg_img/*.pdf
|
||||
rm -f -r svg_img/*.pdf_tex
|
||||
rm -f -r puml/*.svg
|
||||
rm -f -r puml/*.png
|
||||
rm -f -r dot/*.png
|
||||
rm -f rapport.pdf
|
||||
rm -f poster.pdf
|
||||
|
||||
clean-rapport :
|
||||
rm -f rapport.aux
|
||||
|
|
@ -78,13 +79,13 @@ clean-poster :
|
|||
rm -f poster.glo
|
||||
rm -f texput.log
|
||||
|
||||
pdf_img/%.pdf : raw_img/%.svg pdf_img/%.pdf_tex
|
||||
svg_img/%.pdf : svg_img/%.svg svg_img/%.pdf_tex
|
||||
inkscape -D -z --file=$< --export-pdf=$@ --export-latex
|
||||
|
||||
pdf_img/%.pdf_tex : raw_img/%.svg
|
||||
svg_img/%.pdf_tex : svg_img/%.svg
|
||||
inkscape -D -z --file=$< --export-pdf=$@ --export-latex
|
||||
|
||||
png_svg_img/%.png : raw_img/%.svg
|
||||
svg_img/%.png : svg_img/%.svg
|
||||
inkscape $< --export-type=png --export-filename=$@
|
||||
|
||||
puml/%.svg : puml/%.puml
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ hide footbox
|
|||
participant Capteur as capt
|
||||
database Cloud as cld
|
||||
|
||||
[-> capt ++: activation exterieur\ntimer, interuption...
|
||||
[-> capt ++: activation extérieure\ntimer, interruption...
|
||||
capt -> cld : CON[0x77]\nPUT/url?val
|
||||
cld --> capt !!: ACK[0x77]
|
||||
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ package "Notre ajout" as us {
|
|||
+float avg_RTT
|
||||
|
||||
+envoie_token()
|
||||
+receprion_token()
|
||||
+reception_token()
|
||||
+failed_request()
|
||||
+reset()
|
||||
}
|
||||
|
|
@ -61,14 +61,14 @@ package "tf_agent" as tf{
|
|||
}
|
||||
helper_client_coap "1" *-- "1" client_coap : > Simplifie l'usage
|
||||
|
||||
client_coap "1" *-- "1" superviseur_local : < Surveille et controle
|
||||
client_coap "1" *-- "1" superviseur_local : < Surveille et contrôle
|
||||
|
||||
superviseur_global "1" o-- "N" superviseur_local : > fait la synthèse
|
||||
|
||||
maquette "1" *-- "N" helper_client_coap
|
||||
maquette "1" *-- "1" superviseur_global : < envoie les données\nrécoltées
|
||||
maquette "1" *-- "N" requette : < permet le controle\nde la charge du réseau
|
||||
requette "1" --> "1" helper_client_coap : > envoie des requettes\navec une période précise
|
||||
maquette "1" *-- "N" requette : < permet le contrôle\nde la charge du réseau
|
||||
requette "1" --> "1" helper_client_coap : > envoie des requêtes\navec une période précise
|
||||
|
||||
tfenv <|-- maquette : < implémente
|
||||
@enduml
|
||||
135
rapport.tex
135
rapport.tex
|
|
@ -21,6 +21,12 @@
|
|||
\usepackage{lscape}
|
||||
\usepackage{wrapfig}
|
||||
|
||||
\usepackage[%
|
||||
all,
|
||||
defaultlines=3 % nombre minimum de lignes
|
||||
]{nowidow}
|
||||
|
||||
|
||||
\newcommand{\code}[1]{\mintinline[breaklines, breakafter=.]{python}{#1}}
|
||||
|
||||
\usepackage[toc]{glossaries}
|
||||
|
|
@ -61,7 +67,7 @@
|
|||
\newglossaryentry{cocoa}
|
||||
{
|
||||
name=Cocoa+,
|
||||
description={Evolution de \coap{}, protocole de la couche \osi{} 7, voir \cite{shelbyConstrainedApplicationProtocol2014}}
|
||||
description={Évolution de \coap{}, protocole de la couche \osi{} 7, voir \cite{shelbyConstrainedApplicationProtocol2014}}
|
||||
}
|
||||
|
||||
\newcommand{\cocoa}{\gls{cocoa}}
|
||||
|
|
@ -76,7 +82,7 @@
|
|||
|
||||
\newglossaryentry{keras}
|
||||
{
|
||||
name=keras,
|
||||
name=Keras,
|
||||
description={Module Python pour la manipulation de réseaux de neurones}
|
||||
}
|
||||
|
||||
|
|
@ -141,7 +147,7 @@
|
|||
\newglossaryentry{mac}
|
||||
{
|
||||
name=MAC,
|
||||
description={Media Access Control, Contrôle de l'accès à médium de communication}
|
||||
description={Media Access Control, Contrôle de l'accès au médium de communication}
|
||||
}
|
||||
|
||||
\newcommand{\mac}{\gls{mac}}
|
||||
|
|
@ -236,8 +242,9 @@
|
|||
\hspace{0pt}
|
||||
\vfill
|
||||
\begin{center}
|
||||
\section*{Remerciement}
|
||||
Je remercie Lynda Zitoune et Véronique Vèque de m'avoir permis de réalisé ce stage dans leur équipe.
|
||||
\section*{Remerciements}
|
||||
Je remercie Lynda Zitoune et Véronique Vèque\\
|
||||
de m'avoir permis de effectuer ce stage dans leur équipe.
|
||||
\end{center}
|
||||
\vfill
|
||||
\hspace{0pt}
|
||||
|
|
@ -276,7 +283,7 @@ Nos objectifs sont \begin{itemize}
|
|||
\item détermination des scénarios pertinents
|
||||
\item simulation ou test de ces scénarios
|
||||
\end {itemize}
|
||||
Le stage se déroule entièrement en distanciel, avec des réunions hébdomadaires avec mes encadrantes, soit en présentiel dans les locaux de CentralSupélec, soit sur Teams.
|
||||
Le stage se déroule entièrement en distanciel, avec des réunions hebdomadaires avec mes encadrantes, soit en présentiel dans les locaux de CentraleSupélec, soit sur Teams.
|
||||
|
||||
\subsection{Qu'est-ce qu'un réseau \iot{} ?}
|
||||
|
||||
|
|
@ -296,9 +303,9 @@ Ces connexions se font au moyen de normes et de protocoles organisés dans un mo
|
|||
\toprule
|
||||
Couche & Rôle & Protocole\\
|
||||
\midrule
|
||||
7 - Application & Utilisation finale & http, ssh...\\
|
||||
7 - Application & Utilisation finale & \http{}, ssh...\\
|
||||
4 - Transport & \CC{} \& multiplexage & \tcp{}, \udp{}\\
|
||||
3 - Réseau & Routage & IP\\
|
||||
3 - Réseau & Routage & \ip{}\\
|
||||
1 \& 2 - Physique & Support des communications & Ethernet, Wi-Fi...\\
|
||||
\bottomrule
|
||||
\end{tabular}
|
||||
|
|
@ -306,9 +313,9 @@ Ces connexions se font au moyen de normes et de protocoles organisés dans un mo
|
|||
|
||||
Les couches $1$ et $2$ permettent la communication entre deux machines directement reliées.
|
||||
C'est ici qu'intervient l'adresse \mac{}.
|
||||
La couches $3$ décrit le routage pour passer par des machines intermédiaires afin de voyager dans l'ensemble du réseau.
|
||||
La couche $3$ décrit le routage pour passer par des machines intermédiaires afin de voyager dans l'ensemble du réseau.
|
||||
C'est ici qu'intervient l'adresse \ip{}.
|
||||
La couches $4$ décrit les protocoles permettant d'établir une connexion entre deux applications sur les machines hôtes.
|
||||
La couche $4$ décrit les protocoles permettant d'établir une connexion entre deux applications sur les machines hôtes.
|
||||
Cela inclut donc le multiplexage des données (c'est le port sur la machine hôte), ainsi que la gestion de la congestion.
|
||||
Les couches $5$ et $6$ n'ont pas d'influence sur la suite, et sont donc négligées.
|
||||
Elles permettent par exemple d'encrypter la connexion avec le \emph{SSL}.
|
||||
|
|
@ -328,18 +335,19 @@ Suivant l'application, il faut favoriser l'un ou l'autre, ou trouver un compromi
|
|||
|
||||
\subsubsection{Qu'est-ce que la congestion ?}
|
||||
|
||||
Malheureusement, les réseaux étant hétérogènes, on ne contrôle pas tout les paramètres lorsqu'on les utilise.
|
||||
Malheureusement, les réseaux étant hétérogènes, on ne contrôle pas tous les paramètres lorsqu'on les utilise.
|
||||
En effet, pour envoyer un paquet à une autre machine, il faut (dans le cas général) passer par plusieurs intermédiaires, les routeurs.
|
||||
Lesdits routeurs ne doivent pas gérer qu'un seul flux, et tous les liens entre les routeurs n'ont pas la même capacité ; ainsi on se retrouve avec des accumulations de paquets dans certains routeurs.
|
||||
L'accumulation se produit au niveau des goulots d'étranglement.
|
||||
Les routeurs n'ont pas une mémoire infinie, ils ne peuvent donc pas laisser les queues d'envoi grandir indéfiniment.
|
||||
Elles ont une taille limite, et il faut donc parfois ne pas traiter certains paquets lorsque le réseau est trop chargé.
|
||||
Ce phénomène est appelé congestion.
|
||||
|
||||
On cherche à l'éviter, car un paquet non traité est un paquet perdu, et le message n'est pas complet pour le client.
|
||||
La gestion de la congestion sera expliquée plus en détail dans la partie \ref{part_cc}.
|
||||
La détection de la congestion se fait souvent à l'aide d'un accusé de réception : si l'accusé n'est pas reçu au bout d'un certain temps, on considère le message comme perdu.
|
||||
Lorsque des paquets sont perdus à cause de la congestion, il faut les réenvoyer, en faisant attention de ne pas recongestionner le réseau.
|
||||
Une grande partie des optimisations du \CC a lieu au niveau de ce temps d'attente, le \rto.
|
||||
Une grande partie des optimisations du \CC{} a lieu au niveau de ce temps d'attente, le \rto{}.
|
||||
|
||||
\subsubsection{Quelles sont les spécificités des réseaux \iot{} ?}
|
||||
|
||||
|
|
@ -350,7 +358,7 @@ Dans un réseau \iot, les contraintes et applications sont différentes : \begin
|
|||
\end{itemize}
|
||||
|
||||
Les technologies employées sont surtout des connexions sans fil à basse consommation, et à bas débit.
|
||||
On peut citer les technologies comme le BLE, le 802.15.4, 6LoWPAN. %manque référence
|
||||
On peut citer les technologies comme le BLE, le 802.15.4, 6LoWPAN \dots %manque référence
|
||||
|
||||
De plus, pour accéder aux ressources d'une autre machine, on ne peut pas utiliser l'\http{} comme sur un ordinateur de bureau ou un téléphone.
|
||||
En effet, \http{} s'appuie sur \tcp{}, et induit donc beaucoup de messages supplémentaires.
|
||||
|
|
@ -363,8 +371,8 @@ Un nouveau protocole a donc été développé pour proposer des fonctionnalités
|
|||
L'interface en question est une interface \emph{RestFull} :\begin{itemize}
|
||||
\item Les ressources sont identifiées par des url, par exemple \url{coap://exemple.com/ressource/en/ligne},
|
||||
\item On peut interagir avec les ressources au moyen de plusieurs méthodes: \begin{itemize}
|
||||
\item GET : On demande le contenu de la ressource distante,
|
||||
\item POST, PUT : On crée ou remplace le contenu de la ressource distante,
|
||||
\item GET : on demande le contenu de la ressource distante,
|
||||
\item POST, PUT : on crée ou remplace le contenu de la ressource distante,
|
||||
\item DELETE : on supprime la ressource.
|
||||
\end{itemize}
|
||||
\end{itemize}
|
||||
|
|
@ -425,7 +433,7 @@ Les deux paramètres sont : \begin{itemize}
|
|||
\end{itemize}
|
||||
La méthode pour déterminer l'action appropriée à chaque pas de temps est juste de prendre $argmax_{a \in \mathbb{A}} \mathbb{Q}\left(s_t, a \right) $.
|
||||
En réalité, on fait des actions aléatoires avec une probabilité faible pour explorer l'environnement.
|
||||
Deux des limites de cette solution sont la taille en mémoire d'un tel tableau quand les ensembles $mathbb{S}$ et $\mathbb{A}$ sont grands, et le temps qu'il faut pour que la convergence des valeurs du tableau ait lieu.
|
||||
Deux des limites de cette solution sont la taille en mémoire d'un tel tableau quand les ensembles $\mathbb{S}$ et $\mathbb{A}$ sont grands, et le temps qu'il faut pour que la convergence des valeurs du tableau ait lieu.
|
||||
Pour pallier à cela, on peut approximer la fonction par un réseau de neurones, c'est le principe du \dqlearn{}.
|
||||
|
||||
\section{État de l'art\label{part_cc}}
|
||||
|
|
@ -465,9 +473,9 @@ Mais interpréter ces variations de \rtt{} et prendre la décision adéquate est
|
|||
|
||||
\subsection{Comment gère-t-on la congestion avec l’implémentation classique de \coap{} ?}
|
||||
|
||||
Pour le \coap{}, la gestion de la congestion est différente, car on utilise une fenêtre unitaire ; c'est sur le \rto que se fait le travail.
|
||||
Pour le \coap{}, la gestion de la congestion est différente, car on utilise une fenêtre unitaire ; c'est sur le \rto{} que se fait le travail.
|
||||
Dans la version de base, le \rto{} de base est tiré aléatoirement entre $2 s$ et $3 s$, et est doublé à chaque retransmission.
|
||||
C'est un protocole simple mais peu performant, car si le délai de transmission est déjà de l'ordre du \rto, alors il risque d'y avoir des retransmissions systématiques.
|
||||
C'est un protocole simple mais peu performant, car si le délai de transmission est déjà de l'ordre du \rto{}, alors il risque d'y avoir des retransmissions systématiques.
|
||||
|
||||
Une des évolutions du \coap{} est \cocoa{}, qui ne change que le \CCA{}\cite{ancillottiRTTBasedCongestionControl2018}.
|
||||
C'est un algorithme inspiré de FAST-\tcp{} et Compound-\tcp{}.
|
||||
|
|
@ -488,8 +496,8 @@ Ensuite, on crée une fonction $T$ permettant de prendre une décision :
|
|||
\end{equation}
|
||||
On a donc $4$ cas pour prendre une décision : \begin{itemize}
|
||||
\item $RTT_S < T\left( -1 \right)$ : pas de congestion, on peut être beaucoup plus agressif,
|
||||
\item $T\left( -1 \right) \le RTT_S < T\left( +1 \right)$ : congestion faible, on se trouve à un point de fonctionement correct, on ne change rien, mais on peut aussi être un peu plus agressif si besoin,
|
||||
\item $T\left( +1 \right) \le RTT_S < T\left( +2 \right)$ : congestion normale, la congestion augmente, il faut être moins agressif pour ne pas congestioner le réseau,
|
||||
\item $T\left( -1 \right) \le RTT_S < T\left( +1 \right)$ : congestion faible, on se trouve à un point de fonctionnement correct, on ne change rien, mais on peut aussi être un peu plus agressif si besoin,
|
||||
\item $T\left( +1 \right) \le RTT_S < T\left( +2 \right)$ : congestion normale mais en augmentation, il faut être moins agressif pour ne pas congestionner le réseau,
|
||||
\item $T\left( +2 \right) \le RTT_S$ : congestion importante, le réseau est totalement congestionné, il faut être beaucoup moins agressif.
|
||||
\end{itemize}
|
||||
La seule contrainte est que $\alpha_S \gg \alpha_L$.
|
||||
|
|
@ -497,12 +505,12 @@ Le choix des autres valeurs, les seuils et les actions prises sont choisis empir
|
|||
|
||||
\subsection{Comment l'apprentissage machine prend-il place dans les \CCA{}?}
|
||||
Pour pallier ces problèmes, plusieurs \CCA{} utilisant de l'apprentissage machine sont apparus : Q-\tcp{}\cite{liQTCPAdaptiveCongestion2019}, \tcp{}-Drinc\cite{xiaoTCPDrincSmartCongestion2019}\dots
|
||||
L'idée derriere ces algorithmes est de déléguer la prise de decision à une IA qui serait capable de reconnaître les signes de congestion bien plus efficacement qu'un algorithme "fait-main" classique.
|
||||
L'idée derrière ces algorithmes est de déléguer la prise de décision à une IA qui serait capable de reconnaître les signes de congestion bien plus efficacement qu'un algorithme "fait-main" classique.
|
||||
Plusieurs problèmatiques se présentent : \begin{itemize}
|
||||
\item La modélisation de l'environement : \begin{itemize}
|
||||
\item La modélisation de l'environnement : \begin{itemize}
|
||||
\item quel est $\mathbb{S}$, c'est-à-dire comment représenter l'environnement pour l'acteur,
|
||||
\item quel est $\mathbb{A}$, c'est-à-dire qu'est-ce que l'acteur doit donner comme consigne,
|
||||
\item quel est $r_t$, c'est à dire qu'est-ce qu'une bonne action
|
||||
\item quel est $r_t$, c'est-à-dire qu'est-ce qu'une bonne action
|
||||
\end{itemize}
|
||||
\item mais aussi des problèmes de compétition multi-agents: \begin{itemize}
|
||||
\item comment être sûr que les ressources réseau sont équitablement réparties entre les agents,
|
||||
|
|
@ -514,35 +522,36 @@ L'intégration de l'IA dans le \CC{} n'est encore qu'à l'état de tests, de bal
|
|||
|
||||
\section{Modélisation choisie}
|
||||
La première étape est de modéliser le système.
|
||||
Notre modélisation s'appuie sur la modélisation de \cite{xiaoTCPDrincSmartCongestion2019}.
|
||||
Notre modélisation s'appuie sur celle de \cite{xiaoTCPDrincSmartCongestion2019}.
|
||||
|
||||
\subsection{Quel cas d'utilisation nous est le plus favorable ?}
|
||||
Pour notre travail, on se positionne dans une situation où un serveur central puissant voudrait récupérer des données sur un ensemble de capteurs.
|
||||
Les contraintes pour les codes s'exécutant sur le serveur central (un serveur cloud généralement) et sur les capteurs sont radicalement différentes.
|
||||
Le cloud peut exécuter le code qu'il veut avec beaucoup de puissance, alors que les capteurs doivent se limiter au maximum.
|
||||
Le could a accès aux données de toutes les connexions alors que les capteurs n'ont à priori que les données de leur connexion.
|
||||
On choisit de se placer dans le cas où on intéragit avec un nombre fixe de capteurs, $N$.
|
||||
On choisit de se placer dans le cas où on interagit avec un nombre fixe de capteurs, $N$.
|
||||
|
||||
\begin{figure}[htp]
|
||||
\centering
|
||||
\includegraphics[scale=1]{puml/cas_utilisation_coap_1.png}
|
||||
\includegraphics[scale=0.9]{puml/cas_utilisation_coap_1.png}
|
||||
\caption[Diagramme de séquence de transaction \coap{}, cas 1]{Diagramme de séquence entre le capteur et le serveur \coap{} avec déclenchement de la transaction par le capteur.}
|
||||
\label{fig:seq_coap:1}
|
||||
\end{figure}
|
||||
\begin{figure}[htp]
|
||||
\centering
|
||||
\includegraphics[scale=1]{puml/cas_utilisation_coap_2.png}
|
||||
\includegraphics[scale=0.9]{puml/cas_utilisation_coap_2.png}
|
||||
\caption[Diagramme de séquence de transaction \coap{}, cas 2]{Diagramme de séquence entre le capteur et le serveur \coap{} avec déclenchement de la transaction par le cloud et réponse dans l'acquittement.}
|
||||
\label{fig:seq_coap:2}
|
||||
\end{figure}
|
||||
\begin{figure}[htp]
|
||||
\centering
|
||||
\includegraphics[scale=1]{puml/cas_utilisation_coap_3.png}
|
||||
\includegraphics[scale=0.9]{puml/cas_utilisation_coap_3.png}
|
||||
\caption[Diagramme de séquence de transaction \coap{}, cas 3]{Diagramme de séquence entre le capteur et le serveur \coap{} avec déclenchement de la transaction par le cloud et réponse dans un message séparé.}
|
||||
\label{fig:seq_coap:3}
|
||||
\end{figure}
|
||||
|
||||
Lorsque l'on veut établir une connexion avec un capteur, il y a trois cas de figure, il faut donc choisir celui qui nous avantage le plus. Le cas 1 (figure \ref{fig:seq_coap:1}) permet de réagir à un événement, mais demande au capteur de prendre le rôle de gestionnaire du \CC{}, ce qui n'est pas le plus simple.
|
||||
Lorsque l'on veut établir une connexion avec un capteur, il y a trois cas de figure, il faut donc choisir le plus avantageux.
|
||||
Le cas 1 (figure \ref{fig:seq_coap:1}) permet de réagir à un événement, mais demande au capteur de prendre le rôle de gestionnaire du \CC{}, ce qui n'est pas le plus simple.
|
||||
Les cas 2 (figure \ref{fig:seq_coap:2}) et 3 (figure \ref{fig:seq_coap:3}) permettent tous deux au cloud de prendre en charge le \CC{}, mais le cas 3 demande l'échange de bien plus de messages et sature plus vite le réseau.
|
||||
On choisit donc de travailler dans le cas 2, qui permet d'avoir à la fois toutes les informations au niveau de l'acteur, et de la puissance de calcul.
|
||||
Pour ce qui est de la gestion des événements, on peut imaginer que le cloud envoie régulièrement au capteur des consignes simples pour le \CC{}, même si nous n'allons pas traiter cette problématique.
|
||||
|
|
@ -553,7 +562,7 @@ La grandeur la plus simple à se représenter est le \rtt{}.
|
|||
Chaque envoi de message permet de récupérer un échantillon de \rtt{}.
|
||||
Mais un problème se pose lorsque le \rto{} de base est plus faible que le \rtt{} à cause des retransmissions : on ne sait pas si l'acquittement vient de l'original ou de la retransmission, car ils ont le même token.
|
||||
Par exemple, dans la figure \ref{fig:temp_coap:valide}, on a sans ambiguïté un \rto{} de $25$, mais dans la figure \ref{fig:temp_coap:invalide}, le \rto{} semble être $5$ alors qu'il est de $30$.
|
||||
Ce problème peut être contourné en changeant le token dans les retransmissions, mais nous ne metterons pas en place cette solution pour l'instant.
|
||||
Ce problème peut être contourné en changeant le token dans les retransmissions, mais nous ne mett rons pas en place cette solution pour l'instant.
|
||||
|
||||
\begin{figure}[htp]
|
||||
\centering
|
||||
|
|
@ -577,7 +586,7 @@ Ces retransmissions peuvent être dues à la congestion mais aussi à des probl
|
|||
Une fois que l'on a mesuré une grandeur, il faut la transmettre à l'acteur.
|
||||
Le premier problème est que l'acteur voit un temps discontinu, alors que les nouvelles mesures arrivent à des instants irréguliers.
|
||||
On choisit donc de couper le temps en une série d'intervalles de longueur fixe.
|
||||
Dans ces intervalles, on supose que l'état du réseau est constant, et les valeurs utilisées par le \coap{} le sont aussi.
|
||||
Dans ces intervalles, on suppose que l'état du réseau est constant, et les valeurs utilisées par le \coap{} le sont aussi.
|
||||
Il faut prendre une durée de l'intervalle qui soit plus longue que le \rtt{}, car ainsi on ne se retrouve pas dans un cas limite où un message part pendant l'intervalle $t$, avec les consignes de l'instant $t$, mais arrive dans l'instant $t+1$ et influe $s_{t+1}$ au lieu de $s_t$.
|
||||
Il faut aussi que cette durée ne soit pas trop importante, car on ne change les consignes qu'à la fin de ces intervalles.
|
||||
On nomme cet intervalle "intervalle de contrôle".
|
||||
|
|
@ -585,7 +594,7 @@ On nomme cet intervalle "intervalle de contrôle".
|
|||
De plus, on travaille sur un réseau de capteurs qui renvoient leurs informations à un serveur cloud unique.
|
||||
Puisque le serveur cloud centralise toutes les connexions, on choisit d'avoir un seul agent, qui donne des consignes pour toutes les connexions.
|
||||
|
||||
Pour la suite, on appelle "serveur \coap{}" la partie de programme s'exécutant sur les capteurs, et "clients \coap{}" les programmes s'éxecutant sur le serveur cloud afin de récupérer les données des capteurs.
|
||||
Pour la suite, on appelle "serveur \coap{}" la partie de programme s'exécutant sur les capteurs, et "clients \coap{}" les programmes s'exécutant sur le serveur cloud afin de récupérer les données des capteurs.
|
||||
On remarque aussi qu'on ne fait pas la différence entre l'état du réseau et l'observation que l'on en fait.
|
||||
|
||||
\subsubsection{État d'un client seul.}
|
||||
|
|
@ -632,7 +641,7 @@ Une fois que chaque client a généré son vecteur, il suffit de les concaténer
|
|||
\label{eq:modele:mat}
|
||||
\end{equation}
|
||||
L'avantage d'une telle matrice est que l'on pourra utiliser une convolution dans le réseau de neurones.
|
||||
Une autre possibilité, qui est de concaténer les matrices de plusieurs échantillon de temps successifs pour créer un tenseur à trois dimensions, qui permettrait d'avoir plus d'informations sur l'évolution temporelle des valeurs, n'a pas pu être testée.
|
||||
Une autre possibilité, qui est de concaténer les matrices de plusieurs échantillon de temps successifs pour créer un tenseur à trois dimensions (ce qui permettrait d'avoir plus d'informations sur l'évolution temporelle des valeurs) n'a pas pu être testée.
|
||||
|
||||
\subsection{Comment l'acteur influence-t-il le client \coap{} ?}
|
||||
La principale valeur permettant de contrôler le comportement du client est le \rto{}.
|
||||
|
|
@ -659,11 +668,11 @@ D'autres choix sont possibles, par exemple $\mathbb{A} = \left\lbrace 0.1, 0.5,
|
|||
\subsection{Comment quantifier la réussite de l'agent ?}
|
||||
Une fois que l'on sait représenter l'état du réseau, il faut déterminer si cet état est favorable ou non.
|
||||
Pour cela, il faut se demander ce que l'on veut comme caractéristiques.
|
||||
Les critaires choisis sont : \begin{itemize}
|
||||
Les critères choisis sont : \begin{itemize}
|
||||
\item Le délai est le plus petit possible, pour avoir un système réactif,
|
||||
\item il y a peu de retransmissions, pour ne pas encombrer le réseau et abuser des ressources énergétiques des capteurs,
|
||||
\item il y a très peu d'échecs, c'est-à-dire de messages qui dépassent le nombre de retransmissions maximal,
|
||||
\item le nombre de message envoyés est équitablement réparti entre les clients.
|
||||
\item le nombre de messages envoyés est équitablement réparti entre les clients.
|
||||
\end{itemize}
|
||||
|
||||
L'équité est une grandeur permettant de mesurer si certains capteurs utilisent plus le réseau que d'autres.
|
||||
|
|
@ -703,12 +712,12 @@ Cela représente le fonctionnement normal du système.
|
|||
|
||||
Mais en plus de cela, il faut que l'on fasse s'optimiser la politique.
|
||||
Pour cela on va procéder en deux temps : \begin{enumerate}
|
||||
\item Le pré-entraînement,
|
||||
\item le pré-entraînement,
|
||||
\item l'entraînement en position.
|
||||
\end{enumerate}
|
||||
Le pré-entraînement se déroule avant le déploiment du réseau de capteurs.
|
||||
Il consiste à rendre la politique proche de ce qui est attendu pour qu'elle soit exploitable, même si elle n'est pas encore optimale.
|
||||
Pour cela, il faut généré de l'expérience (les transitions $\left( s_t, a_t, r_t, s_{t+1} \right)$ que on a vu plus haut), et l'utilisé pour optimisé la politique.
|
||||
Pour cela, il faut générer de l'expérience (les transitions $\left( s_t, a_t, r_t, s_{t+1} \right)$ que l'on a vues plus haut), et l'utiliser pour optimiser la politique.
|
||||
Cette génération peut se faire de plusieurs manières, que on évoquera plus tard.
|
||||
Une fois que la politique est correcte, on peut la déployer sur le réseau de capteurs réels.
|
||||
Mais elle n'est pas fixe, puisqu'on continue à l'optimiser avec de l'expérience récoltée sur le réseau réel.
|
||||
|
|
@ -736,24 +745,24 @@ Il faut donc trouver des solutions plus rapides que l'exploration simple si on v
|
|||
\subsubsection{Par exploration en simulateur}
|
||||
Une solution simple, en théorie, est d'utiliser un simulateur.
|
||||
Le plus utilisé est \ns{}.
|
||||
C'est un simulateur à événements discrets, destiné à la simulation de réseau informatique permettant de travaillier sur toutes les couches du modèle \osi{}.
|
||||
C'est un simulateur à événements discrets destiné à la simulation de réseaux informatiques permettant de travailler sur toutes les couches du modèle \osi{}.
|
||||
Ainsi on peut entraîner le simulateur avec la topologie du réseau que l'on veut, et la qualité des connexions sans fil que l'on veut.
|
||||
Malheureusment, c'est un simulateur complexe à utiliser : tous les scripts de simulation sont écrit en \cpp{}.
|
||||
Malheureusment, c'est un simulateur complexe à utiliser : tous les scripts de simulation sont écrits en \cpp{}.
|
||||
Par manque de temps et de compétence, les simulations sur \ns{} n'ont pas pu être réalisées, mais cela reste une piste à étudier pour le pré-entraînement.
|
||||
|
||||
\subsubsection{Par création artificielle de transitions\label{part:yaml}}
|
||||
|
||||
Une autre méthode possible est de créer des transitions artificiellement.
|
||||
Une autre méthode est de créer des transitions artificiellement.
|
||||
Pour cela, l'algorithme commence par fixer une charge sur le réseau $f$, c'est-à-dire la fréquence à laquelle chaque client interroge le capteur associé.
|
||||
Selon cette charge, le réseau est plus ou moins congestionné.
|
||||
Ensuite l'algorithme prend plusieurs consignes de \rto{} $c_n$, et pour chaque consigne, l'algorithme l'applique à l'agent et mesure le vecteur d'observation associé $s_n$ ainsi que $r_n$.
|
||||
Puis pour chaque couple $(s_n, s_m)$, l'algorithme calcule l'action $a_{n , m}$ pour passer de $c_n$ à $c_m$.
|
||||
L'algorithme peut ainsi construire une série de transitions $s_n, a_{n, m}, r_m, s_m$.
|
||||
On recommence avec un autre $f$
|
||||
On recommence avec un autre $f$.
|
||||
|
||||
Ces transitions sont uniquements des approximations car elles ne tiennent pas réellement compte des effets de $s_t$ sur $s_{t+1}$ liés au temps de propagation des messages dans le système.
|
||||
De plus elles supposent que la charge ne change pas sur le système.
|
||||
Malgré cela, elle permet d'aller plus vite dans la génération de transitions pour le pré-entraînement, car en $n$ intervalles de contrôle à $f$ fixe, on génère $n^2$ transitions.
|
||||
Cela permet malgres tout d'aller plus vite dans la génération de transitions pour le pré-entraînement, car en $n$ intervalles de contrôle à $f$ fixe, on génère $n^2$ transitions.
|
||||
|
||||
\section{Implémentation de l'algorithme}
|
||||
L'implémentation de l'algorithme est réalisée en Python.
|
||||
|
|
@ -767,7 +776,7 @@ De plus, pour la partie apprentissage, on utilise \TF{}, un module répandu pour
|
|||
\label{fig:imple:class}
|
||||
\end{figure}
|
||||
|
||||
\subsection{Modules uilisés}
|
||||
\subsection{Modules utilisés}
|
||||
Les modules que nous utilisons ont leur propre interface et fonctionnement Internet, auxquels nous devont nous adapter.
|
||||
|
||||
\paragraph{\coapthon{}}, pour sa partie client, utilise deux objets (voir figure \ref{fig:imple:class}) : \begin{itemize}
|
||||
|
|
@ -778,9 +787,9 @@ Les modules que nous utilisons ont leur propre interface et fonctionnement Inter
|
|||
Il y a aussi une partie serveur, mais nous ne la modifions pas du tout.
|
||||
C'est elle qui joue le rôle de serveur \coap{} sur les \rasp{}.
|
||||
|
||||
\paragraph{\TF{} et \keras{}} sont des modules \python{} fournissant les outils nécessaires à l'entraînement de modèles d'IA.
|
||||
\paragraph{\TF{} et \keras{}}sont des modules \python{} fournissant les outils nécessaires à l'entraînement de modèles d'IA.
|
||||
\TF{} s'occupe des fonctions hautes, avec les outils permettant de mettre en place la boucle d'apprentissage.
|
||||
Pour cela, il a besoin que l'on mette l'environement sous un format spécial : l'interface \gym{}.
|
||||
Pour cela, il a besoin que l'on mette l'environnement sous un format spécial : l'interface \gym{}.
|
||||
Cette interface permet la standardisation des interfaces des environnements.
|
||||
Pour cela, il faut définir une nouvelle classe, héritant de \code{tf_agents.environements.py_environement.PyEnvironement}, et surchargeant les attributs et méthodes suivantes :
|
||||
\begin{enumerate}
|
||||
|
|
@ -789,13 +798,13 @@ Pour cela, il faut définir une nouvelle classe, héritant de \code{tf_agents.en
|
|||
\item \code{._reset()}, qui doit renvoyer un objet \code{tf_agents.trajectories.time_step.transition},
|
||||
\item \code{._step(action)}, qui doit renvoyer un objet \code{tf_agents.trajectories.time_step.transition} ou \code{tf_agents.trajectories.time_step.termination}.
|
||||
\end{enumerate}
|
||||
Les deux premiers permettent de signaler à l'agent quelles valeurs sont autorisées.
|
||||
Les deux premiers membres permettent de signaler à l'agent quelles valeurs sont autorisées.
|
||||
Le troisième permet de remettre l'environnement dans un état initial.
|
||||
Le quatrième est le plus important, car il représente le passage d'un pas de temps.
|
||||
Les transitions sont les objets $\left( s_t, a_t, r_t, s_{t+1} \right)$.
|
||||
|
||||
\keras{} quant à lui, permet l'utilisation et la manipulation des réseaux de neurones.
|
||||
Puisqu'on n'utilise que des réseaux simples, les fonctionalités du module ne seront pas abordées.
|
||||
Puisqu'on n'utilise que des réseaux simples, les fonctionnalités du module ne seront pas abordées.
|
||||
|
||||
|
||||
\subsection{Structure du code}
|
||||
|
|
@ -822,7 +831,7 @@ On modifie aussi \code{client.CoAP.send_datagram._start_retransmission} pour que
|
|||
On modifie finalement \code{client.CoAP.receive_datagram} pour enregistrer les réceptions de messages en fonction de leurs tokens.
|
||||
|
||||
Je définis plusieurs types de \code{SuperviseurLocal} : \begin{itemize}
|
||||
\item \code{SuperviseurLocalPlaceHolder}, qui est utilisé par défaut et n'a aucune fonctionalité, et qui réutilise la génération de \rto{} de base dans \coapthon{},
|
||||
\item \code{SuperviseurLocalPlaceHolder}, qui est utilisé par défaut et n'a aucune fonctionn alité, et qui réutilise la génération de \rto{} de base dans \coapthon{},
|
||||
\item \code{SuperviseurLocal}, qui prend en charge l'enregistrement des \rto{}, la moyenne et le minimum, et qui est capable d'utiliser un \rto{} déterminé par l'IA,
|
||||
\item \code{SuperviseurLocalFiltre}, qui prend aussi en charge le filtrage exponentiel pour générer $RTT_L$ et $RTT_S$.
|
||||
\end{itemize}
|
||||
|
|
@ -832,7 +841,7 @@ Elle réalise aussi le calcul des récompenses.
|
|||
|
||||
\subsubsection{Boucle d'apprentissage}
|
||||
L'objet \code{Maquette} est celui qui intéragit avec l'agent IA.
|
||||
La méthode la plus importante est \code{step(action)}, qui prend l'action déterminée par l'IA comme entrée, l'applique
|
||||
La méthode la plus importante est \code{step(action)}, qui prend l'action déterminée par l'IA comme entrée, l'applique, attend la durée de l'intervalle de contrôle, puis renvoie l'état du système.
|
||||
C'est donc cette méthode qui joue un rôle prédominant dans l'algorithme de la partie \ref{part:description_boucle}.
|
||||
|
||||
\begin{listing}[htp]
|
||||
|
|
@ -880,7 +889,7 @@ while True:
|
|||
|
||||
|
||||
Le code \ref{lst:collecteur} implémente le collecteur d'expérience.
|
||||
Le collecteur est éxecuté dans un thread à part.
|
||||
Le collecteur est exécuté dans un thread à part.
|
||||
On lui donne comme paramètres une maquette sur laquelle travailler, et la politique \code{policy}.
|
||||
Cette politique est déterminée par un autre thread.
|
||||
Les transitions sont stockées dans le \code{replay_buffer}.
|
||||
|
|
@ -939,21 +948,21 @@ Si on tentait de réduire le \rto{}, ces messages seraient retransmis alors qu'i
|
|||
\begin{figure}[htp]
|
||||
\centering
|
||||
\includegraphics[width=0.7\textwidth]{png_img/n_client_saturation.png}
|
||||
\caption[Evolution des grandeurs mesurées en fonction du nombre de requêtes simultanées]{Evolution des grandeurs mesurées en fonction du nombre de requêtes simultanées traitées par le serveur \coap{} tournant sur un \rasp{}. Le \CCA{} de \coap{} de base est utilisé.}
|
||||
\caption[Évolution des grandeurs mesurées en fonction du nombre de requêtes simultanées]{Évolution des grandeurs mesurées en fonction du nombre de requêtes simultanées traitées par le serveur \coap{} tournant sur un \rasp{}. Le \CCA{} de \coap{} de base est utilisé.}
|
||||
\label{fig:res:evo_grandeur}
|
||||
\end{figure}
|
||||
|
||||
\begin{figure}[htp]
|
||||
\centering
|
||||
\includegraphics[width=0.7 \textwidth]{png_img/distri_rtt_distant.png}
|
||||
\caption[Distribution du \rtt{} et évolution de $RTT_L$ et $RTT_S$ avec un seul client.]{Distribution du \rtt{} et évolution de $RTT_L$ et $RTT_S$ pendant un envoi de message sans délai entre la réception d'un message et l'envoi du suivant, avec un seul client et un serveur sur le \rasp{}. Même si on ne les distingue pas sur l'histogramme, il y a quelque valeurs de \rtt{} très élevées.}
|
||||
\caption[Distribution du \rtt{} et évolution de $RTT_L$ et $RTT_S$ avec un seul client.]{Distribution du \rtt{} et évolution de $RTT_L$ et $RTT_S$ pendant un envoi de messages sans délai entre la réception d'un message et l'envoi du suivant, avec un seul client et un serveur sur le \rasp{}. Même si on ne les distingue pas sur l'histogramme, il y a quelque valeurs de \rtt{} très élevées.}
|
||||
\label{fig:res:rtt_distant}
|
||||
\end{figure}
|
||||
|
||||
\begin{figure}[htp]
|
||||
\centering
|
||||
\includegraphics[width=0.7 \textwidth]{png_img/varrtt_demo.png}
|
||||
\caption[Evolution de $VARRTT$ lors d'un changement de charge du réseau.]{Evolution de $VARRTT$ lors d'un changement de charge du réseau au moment du $500$-ième message.}
|
||||
\caption[Évolution de $VARRTT$ lors d'un changement de charge du réseau.]{Évolution de $VARRTT$ lors d'un changement de charge du réseau au moment du $500$-ième message.}
|
||||
\label{fig:res:varrtt}
|
||||
\end{figure}
|
||||
|
||||
|
|
@ -962,7 +971,7 @@ On place d'abord un unique client sur le réseau, et on regarde l'évolution de
|
|||
Au $500$-ieme message, on active $20$ autres clients qui vont eux aussi envoyer des requêtes au serveur.
|
||||
Dans la figure \ref{fig:res:varrtt}, on constate qu'il y a bien un pic au moment de l'augmentation de la charge du système, mais il y a aussi des pics dus au bruit dans la mesure du \rtt{}.
|
||||
|
||||
\subsection{Test d'apprentissage}
|
||||
\subsection{Tests d'apprentissage}
|
||||
|
||||
Les tests de pré-apprentissage ont été réalisés avec : \begin{itemize}
|
||||
\item des réseaux de $25$ capteurs, ce qui est un ordre de grandeur du nombre de capteurs dans le type de réseaux cibles,
|
||||
|
|
@ -994,8 +1003,8 @@ La modélisation que nous proposons est une transposition de méthodes existante
|
|||
L'apprentissage machine a déjà montré qu'il était capable de résoudre des problèmes liés aux réseaux et au \CC{}.
|
||||
Nous avons proposé ici une nouvelle modélisation pour intégrer ces nouveaux outils à des problématiques de l'\iot{}.
|
||||
On ne s'intéresse plus à une connexion seule mais à l'ensemble des connexions vers tout un réseau de capteurs.
|
||||
On ne mesure que les \rtt{} de chaque message, ainsi que le nombre de retransmissions.
|
||||
On construit ensuite une matrices qui représente l'état du réseau durant un intervalle de contrôle.
|
||||
On ne mesure que le \rtt{} de chaque message, ainsi que le nombre de retransmissions.
|
||||
On construit ensuite une matrice qui représente l'état du réseau durant un intervalle de contrôle.
|
||||
Cette matrice est utilisée par un agent IA pour déterminer l'action à prendre.
|
||||
Cette action est une liste de facteurs multiplicatifs à appliquer aux \rto{} de chaque capteur.
|
||||
La difficulté est que l'on ne peut pas récupérer assez d'expérience pour réaliser un pré-entraînement.
|
||||
|
|
@ -1005,7 +1014,7 @@ La solution de la partie \ref{part:yaml} n'a pas pu être testée.
|
|||
Par manque de temps et de capacité, ledit simulateur n'a pas pu être réalisé.
|
||||
Parmi les autres éléments à perfectionner, il y a les valeurs de pondération utilisées dans la fonction de récompense, qui sont pour l'instant arbitraires.
|
||||
De même, l'agent est pour l'instant assez basique, on pourrait utiliser une structure de réseau de neurones plus complexe pour prendre en compte les particularités de la matrice d'état.
|
||||
Le travail réalisé sera repris dans une thèse de \lss{}.
|
||||
Le travail réalisé sera repris dans une thèse du \lss{}.
|
||||
|
||||
\clearpage
|
||||
|
||||
|
|
@ -1078,12 +1087,12 @@ Le travail réalisé sera repris dans une thèse de \lss{}.
|
|||
\noindent\rule[2pt]{\textwidth}{0.5pt}\\
|
||||
{\textbf{Abstract :}}
|
||||
|
||||
Congestion control the bottleneck of network throughput.
|
||||
Since a few year, deep-learning is beeing used in congestion control algorithm.
|
||||
We aim to applied deep-learning to congestion control and \coap{}, an embbeded system protocol.
|
||||
The environement chosen is a whole network of sensor, this way the AI agent has access to every connection information.
|
||||
The only input used are the \rtt{} and number of retransmission of every transaction.
|
||||
Our protocol use a pre-traning phase in a \ns{}, then an inline traning to tune itself to the network.
|
||||
Congestion control is the bottleneck of network throughput.
|
||||
For a few years, deep-learning has beeing used in congestion control algorithms.
|
||||
We aim to apply deep-learning to congestion control and \coap{}, an embbeded system protocol.
|
||||
The environement chosen is a whole network of sensors, this way the AI agent has access to every connection information.
|
||||
The only inputs used are the \rtt{} and number of retransmission of every transaction.
|
||||
Our protocol uses a pre-training phase in a \ns{}, then an inline training to tune itself to the network.
|
||||
The protocol was implemented in \python{} as a patch to \coapthon{}.
|
||||
We tried to test the protocol on a physical system, a \rasp{}.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,116 +0,0 @@
|
|||
<?xml version="1.0" encoding="UTF-8" standalone="no"?><svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" contentScriptType="application/ecmascript" contentStyleType="text/css" height="1224px" preserveAspectRatio="none" style="width:1351px;height:1224px;background:#FFFFFF;" version="1.1" viewBox="0 0 1351 1224" width="1351px" zoomAndPan="magnify"><defs><filter height="300%" id="f16ihaszaea5jq" width="300%" x="-1" y="-1"><feGaussianBlur result="blurOut" stdDeviation="2.0"/><feColorMatrix in="blurOut" result="blurOut2" type="matrix" values="0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 .4 0"/><feOffset dx="4.0" dy="4.0" in="blurOut2" result="blurOut3"/><feBlend in="SourceGraphic" in2="blurOut3" mode="normal"/></filter></defs><g><!--MD5=[b9ab6c91daa042623ac722868ebc2597]
|
||||
cluster global--><polygon fill="#FFFFFF" filter="url(#f16ihaszaea5jq)" points="16,148.5,115,148.5,122,170.7969,1217,170.7969,1217,1101.5,16,1101.5,16,148.5" style="stroke:#000000;stroke-width:1.5;"/><line style="stroke:#000000;stroke-width:1.5;" x1="16" x2="122" y1="170.7969" y2="170.7969"/><text fill="#000000" font-family="sans-serif" font-size="14" font-weight="bold" lengthAdjust="spacing" textLength="93" x="20" y="163.4951">Client CoAP</text><!--MD5=[9d8156834bfc9526c23a84bd8a4eb9f5]
|
||||
cluster super--><rect fill="#FFFFFF" filter="url(#f16ihaszaea5jq)" height="538" style="stroke:#000000;stroke-width:1.5;" width="718" x="475" y="191.5"/><rect fill="#FFFFFF" height="10" style="stroke:#000000;stroke-width:1.5;" width="15" x="1173" y="196.5"/><rect fill="#FFFFFF" height="2" style="stroke:#000000;stroke-width:1.5;" width="4" x="1171" y="198.5"/><rect fill="#FFFFFF" height="2" style="stroke:#000000;stroke-width:1.5;" width="4" x="1171" y="202.5"/><text fill="#000000" font-family="sans-serif" font-size="14" font-style="italic" lengthAdjust="spacing" textLength="69" x="799.5" y="217.4951">«Thread»</text><text fill="#000000" font-family="sans-serif" font-size="14" font-weight="bold" lengthAdjust="spacing" textLength="95" x="786.5" y="233.792">Superviseur</text><!--MD5=[aa2f05b2676d7d34ffa7e771fb7634f3]
|
||||
cluster client--><rect fill="#FFFFFF" filter="url(#f16ihaszaea5jq)" height="502" style="stroke:#000000;stroke-width:1.5;" width="382" x="61" y="567.5"/><rect fill="#FFFFFF" height="10" style="stroke:#000000;stroke-width:1.5;" width="15" x="423" y="572.5"/><rect fill="#FFFFFF" height="2" style="stroke:#000000;stroke-width:1.5;" width="4" x="421" y="574.5"/><rect fill="#FFFFFF" height="2" style="stroke:#000000;stroke-width:1.5;" width="4" x="421" y="578.5"/><text fill="#000000" font-family="sans-serif" font-size="14" font-style="italic" lengthAdjust="spacing" textLength="76" x="214" y="593.4951">«Threads»</text><text fill="#000000" font-family="sans-serif" font-size="14" font-weight="bold" lengthAdjust="spacing" textLength="62" x="221" y="609.792">Session</text><path d="M69,444.5 L69,469.6328 L185,469.6328 L185,454.5 L175,444.5 L69,444.5 " fill="#FBFB77" filter="url(#f16ihaszaea5jq)" style="stroke:#A80036;stroke-width:1.0;"/><path d="M175,444.5 L175,454.5 L185,454.5 L175,444.5 " fill="#FBFB77" style="stroke:#A80036;stroke-width:1.0;"/><text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="95" x="75" y="461.5669">Un par capteur</text><!--MD5=[afa0aa9786e57ad2ec3dfc302e641c1c]
|
||||
entity h_coap--><ellipse cx="765" cy="309" fill="#FEFECE" filter="url(#f16ihaszaea5jq)" rx="8" ry="8" style="stroke:#A80036;stroke-width:1.5;"/><text fill="#000000" font-family="sans-serif" font-size="14" lengthAdjust="spacing" textLength="108" x="711" y="338.9951">Interface CoAP</text><!--MD5=[32a3dbe902e7e3707910d23f943dda71]
|
||||
entity h_stat--><ellipse cx="500" cy="309" fill="#FEFECE" filter="url(#f16ihaszaea5jq)" rx="8" ry="8" style="stroke:#A80036;stroke-width:1.5;"/><text fill="#000000" font-family="sans-serif" font-size="14" lengthAdjust="spacing" textLength="132" x="434" y="338.9951">Collecteur donnée</text><!--MD5=[0544887a6193e5bf5f374726bfa990c0]
|
||||
entity main_super--><rect fill="#FEFECE" filter="url(#f16ihaszaea5jq)" height="78.8906" style="stroke:#A80036;stroke-width:1.5;" width="123" x="544.5" y="417.5"/><rect fill="#FEFECE" height="10" style="stroke:#A80036;stroke-width:1.5;" width="15" x="647.5" y="422.5"/><rect fill="#FEFECE" height="2" style="stroke:#A80036;stroke-width:1.5;" width="4" x="645.5" y="424.5"/><rect fill="#FEFECE" height="2" style="stroke:#A80036;stroke-width:1.5;" width="4" x="645.5" y="428.5"/><text fill="#000000" font-family="sans-serif" font-size="14" font-style="italic" lengthAdjust="spacing" textLength="54" x="574" y="450.4951">«main»</text><text fill="#000000" font-family="sans-serif" font-size="14" lengthAdjust="spacing" textLength="83" x="559.5" y="466.792">Gestionaire</text><text fill="#000000" font-family="sans-serif" font-size="14" lengthAdjust="spacing" textLength="44" x="559.5" y="483.0889">global</text><!--MD5=[299d1c4a2ba6184a4b2319b3d939ce68]
|
||||
entity stat--><rect fill="#FEFECE" filter="url(#f16ihaszaea5jq)" height="46.2969" style="stroke:#A80036;stroke-width:1.5;" width="123" x="544.5" y="286"/><rect fill="#FEFECE" height="10" style="stroke:#A80036;stroke-width:1.5;" width="15" x="647.5" y="291"/><rect fill="#FEFECE" height="2" style="stroke:#A80036;stroke-width:1.5;" width="4" x="645.5" y="293"/><rect fill="#FEFECE" height="2" style="stroke:#A80036;stroke-width:1.5;" width="4" x="645.5" y="297"/><text fill="#000000" font-family="sans-serif" font-size="14" lengthAdjust="spacing" textLength="83" x="559.5" y="318.9951">Statisticien</text><!--MD5=[fade500c9f62cce835db878c83a60e51]
|
||||
entity buff--><rect fill="#FEFECE" height="52.5938" style="stroke:none;stroke-width:1.5;" width="114" x="1048" y="282.5"/><path d="M1033,282.5 L1048,282.5 L1048,335.0938 L1162,335.0938 L1162,282.5 L1177,282.5 " fill="none" filter="url(#f16ihaszaea5jq)" style="stroke:#A80036;stroke-width:1.5;"/><text fill="#000000" font-family="sans-serif" font-size="14" lengthAdjust="spacing" textLength="45" x="1058" y="305.4951">buffer</text><text fill="#000000" font-family="sans-serif" font-size="14" lengthAdjust="spacing" textLength="94" x="1058" y="321.792">d'experience</text><!--MD5=[1baef995baf605750a18e6de17020cf1]
|
||||
entity NN--><rect fill="#FEFECE" filter="url(#f16ihaszaea5jq)" height="46.2969" style="stroke:#A80036;stroke-width:1.5;" width="60" x="1074" y="667.5"/><rect fill="#FEFECE" height="10" style="stroke:#A80036;stroke-width:1.5;" width="15" x="1114" y="672.5"/><rect fill="#FEFECE" height="2" style="stroke:#A80036;stroke-width:1.5;" width="4" x="1112" y="674.5"/><rect fill="#FEFECE" height="2" style="stroke:#A80036;stroke-width:1.5;" width="4" x="1112" y="678.5"/><text fill="#000000" font-family="sans-serif" font-size="14" lengthAdjust="spacing" textLength="20" x="1089" y="700.4951">NN</text><!--MD5=[8e0cf92e53a407ca35d63255ba9bf9db]
|
||||
entity optimiseur--><rect fill="#FEFECE" filter="url(#f16ihaszaea5jq)" height="46.2969" style="stroke:#A80036;stroke-width:1.5;" width="118" x="1045" y="434"/><rect fill="#FEFECE" height="10" style="stroke:#A80036;stroke-width:1.5;" width="15" x="1143" y="439"/><rect fill="#FEFECE" height="2" style="stroke:#A80036;stroke-width:1.5;" width="4" x="1141" y="441"/><rect fill="#FEFECE" height="2" style="stroke:#A80036;stroke-width:1.5;" width="4" x="1141" y="445"/><text fill="#000000" font-family="sans-serif" font-size="14" lengthAdjust="spacing" textLength="78" x="1060" y="466.9951">optimiseur</text><!--MD5=[00ccade4d2e9d34be0442221a6cff66c]
|
||||
entity horloge--><rect fill="#FEFECE" filter="url(#f16ihaszaea5jq)" height="62.5938" style="stroke:#A80036;stroke-width:1.5;" width="136" x="862" y="277.5"/><rect fill="#FEFECE" height="10" style="stroke:#A80036;stroke-width:1.5;" width="15" x="978" y="282.5"/><rect fill="#FEFECE" height="2" style="stroke:#A80036;stroke-width:1.5;" width="4" x="976" y="284.5"/><rect fill="#FEFECE" height="2" style="stroke:#A80036;stroke-width:1.5;" width="4" x="976" y="288.5"/><text fill="#000000" font-family="sans-serif" font-size="14" font-style="italic" lengthAdjust="spacing" textLength="96" x="877" y="310.4951">«interuption»</text><text fill="#000000" font-family="sans-serif" font-size="14" lengthAdjust="spacing" textLength="55" x="897.5" y="326.792">horloge</text><!--MD5=[34b9dfdf6eee65fbbd1532cc0642e804]
|
||||
entity s_udp--><ellipse cx="133" cy="1014" fill="#FEFECE" filter="url(#f16ihaszaea5jq)" rx="8" ry="8" style="stroke:#A80036;stroke-width:1.5;"/><text fill="#000000" font-family="sans-serif" font-size="14" lengthAdjust="spacing" textLength="84" x="91" y="1043.9951">Socket UDP</text><!--MD5=[a1e3d70e5da20b3e5a11dc250470e676]
|
||||
entity h_session_message--><ellipse cx="358" cy="690.5" fill="#FEFECE" filter="url(#f16ihaszaea5jq)" rx="8" ry="8" style="stroke:#A80036;stroke-width:1.5;"/><text fill="#000000" font-family="sans-serif" font-size="14" lengthAdjust="spacing" textLength="106" x="305" y="720.4951">Session handle</text><!--MD5=[23de89f1cfa838dd70d864c6d1f1df45]
|
||||
entity h_session_rto--><ellipse cx="235" cy="690.5" fill="#FEFECE" filter="url(#f16ihaszaea5jq)" rx="8" ry="8" style="stroke:#A80036;stroke-width:1.5;"/><text fill="#000000" font-family="sans-serif" font-size="14" lengthAdjust="spacing" textLength="30" x="220" y="720.4951">RTO</text><!--MD5=[8d209b981869ba51a2440fe93c6b67e7]
|
||||
entity file_attente--><path d="M187.5,1001 L242.5,1001 C247.5,1001 247.5,1014.1484 247.5,1014.1484 C247.5,1014.1484 247.5,1027.2969 242.5,1027.2969 L187.5,1027.2969 C182.5,1027.2969 182.5,1014.1484 182.5,1014.1484 C182.5,1014.1484 182.5,1001 187.5,1001 " fill="#FEFECE" filter="url(#f16ihaszaea5jq)" style="stroke:#A80036;stroke-width:1.5;"/><path d="M242.5,1001 C237.5,1001 237.5,1014.1484 237.5,1014.1484 C237.5,1027.2969 242.5,1027.2969 242.5,1027.2969 " fill="none" style="stroke:#A80036;stroke-width:1.5;"/><text fill="#000000" font-family="sans-serif" font-size="14" lengthAdjust="spacing" textLength="45" x="187.5" y="1018.9951">Buffer</text><!--MD5=[a84a2f5a2d8e3077147b7b8a99f6a912]
|
||||
entity main_sess--><rect fill="#FEFECE" filter="url(#f16ihaszaea5jq)" height="78.8906" style="stroke:#A80036;stroke-width:1.5;" width="130" x="170" y="796.5"/><rect fill="#FEFECE" height="10" style="stroke:#A80036;stroke-width:1.5;" width="15" x="280" y="801.5"/><rect fill="#FEFECE" height="2" style="stroke:#A80036;stroke-width:1.5;" width="4" x="278" y="803.5"/><rect fill="#FEFECE" height="2" style="stroke:#A80036;stroke-width:1.5;" width="4" x="278" y="807.5"/><text fill="#000000" font-family="sans-serif" font-size="14" font-style="italic" lengthAdjust="spacing" textLength="54" x="203" y="829.4951">«main»</text><text fill="#000000" font-family="sans-serif" font-size="14" lengthAdjust="spacing" textLength="83" x="185" y="845.792">Gestionaire</text><text fill="#000000" font-family="sans-serif" font-size="14" lengthAdjust="spacing" textLength="90" x="185" y="862.0889">de la session</text><!--MD5=[13dff29a2267c98a2d820d96b9b744fb]
|
||||
entity timer--><rect fill="#FEFECE" filter="url(#f16ihaszaea5jq)" height="62.5938" style="stroke:#A80036;stroke-width:1.5;" width="136" x="283" y="982.5"/><rect fill="#FEFECE" height="10" style="stroke:#A80036;stroke-width:1.5;" width="15" x="399" y="987.5"/><rect fill="#FEFECE" height="2" style="stroke:#A80036;stroke-width:1.5;" width="4" x="397" y="989.5"/><rect fill="#FEFECE" height="2" style="stroke:#A80036;stroke-width:1.5;" width="4" x="397" y="993.5"/><text fill="#000000" font-family="sans-serif" font-size="14" font-style="italic" lengthAdjust="spacing" textLength="96" x="298" y="1015.4951">«interuption»</text><text fill="#000000" font-family="sans-serif" font-size="14" lengthAdjust="spacing" textLength="40" x="326" y="1031.792">timer</text><!--MD5=[778fdad4168e1c9e2d13c8a5e427c42e]
|
||||
entity usr--><ellipse cx="710" cy="14" fill="#FEFECE" filter="url(#f16ihaszaea5jq)" rx="8" ry="8" style="stroke:#A80036;stroke-width:1.5;"/><path d="M710,22 L710,49 M697,30 L723,30 M710,49 L697,64 M710,49 L723,64 " fill="none" filter="url(#f16ihaszaea5jq)" style="stroke:#A80036;stroke-width:1.5;"/><text fill="#000000" font-family="sans-serif" font-size="14" lengthAdjust="spacing" textLength="73" x="673.5" y="82.4951">Utilisateur</text><!--MD5=[7468467f3b6b392f1d176d828c753b77]
|
||||
entity db--><path d="M782,24 C782,14 820,14 820,14 C820,14 858,14 858,24 L858,65.5938 C858,75.5938 820,75.5938 820,75.5938 C820,75.5938 782,75.5938 782,65.5938 L782,24 " fill="#FEFECE" filter="url(#f16ihaszaea5jq)" style="stroke:#000000;stroke-width:1.5;"/><path d="M782,24 C782,34 820,34 820,34 C820,34 858,34 858,24 " fill="none" style="stroke:#000000;stroke-width:1.5;"/><text fill="#000000" font-family="sans-serif" font-size="14" lengthAdjust="spacing" textLength="56" x="792" y="50.9951">Base de</text><text fill="#000000" font-family="sans-serif" font-size="14" lengthAdjust="spacing" textLength="54" x="792" y="67.292">donnée</text><!--MD5=[c610bd6632b8a77f1f1b3723a00c362f]
|
||||
entity udp--><polygon fill="#FEFECE" filter="url(#f16ihaszaea5jq)" points="105.5,1164.5,105.5,1217.0938,160.5,1217.0938,160.5,1174.5,150.5,1164.5,105.5,1164.5" style="stroke:#000000;stroke-width:1.5;"/><path d="M150.5,1164.5 L150.5,1174.5 L160.5,1174.5 " fill="#FEFECE" style="stroke:#000000;stroke-width:1.5;"/><text fill="#000000" font-family="sans-serif" font-size="14" font-style="italic" lengthAdjust="spacing" textLength="35" x="115.5" y="1187.4951">«lib»</text><text fill="#000000" font-family="sans-serif" font-size="14" lengthAdjust="spacing" textLength="29" x="118.5" y="1203.792">UDP</text><!--MD5=[00f9e30d6ead67871b5f4dcdb52564e0]
|
||||
entity tf--><polygon fill="#FEFECE" filter="url(#f16ihaszaea5jq)" points="1233.5,664,1233.5,716.5938,1334.5,716.5938,1334.5,674,1324.5,664,1233.5,664" style="stroke:#000000;stroke-width:1.5;"/><path d="M1324.5,664 L1324.5,674 L1334.5,674 " fill="#FEFECE" style="stroke:#000000;stroke-width:1.5;"/><text fill="#000000" font-family="sans-serif" font-size="14" font-style="italic" lengthAdjust="spacing" textLength="35" x="1266.5" y="686.9951">«lib»</text><text fill="#000000" font-family="sans-serif" font-size="14" lengthAdjust="spacing" textLength="81" x="1243.5" y="703.292">TensorFlow</text><!--MD5=[1c8f5b81a31bcb335baf7fc7f30eecf0]
|
||||
entity keras--><polygon fill="#FEFECE" filter="url(#f16ihaszaea5jq)" points="1233,809.5,1233,862.0938,1293,862.0938,1293,819.5,1283,809.5,1233,809.5" style="stroke:#000000;stroke-width:1.5;"/><path d="M1283,809.5 L1283,819.5 L1293,819.5 " fill="#FEFECE" style="stroke:#000000;stroke-width:1.5;"/><text fill="#000000" font-family="sans-serif" font-size="14" font-style="italic" lengthAdjust="spacing" textLength="35" x="1245.5" y="832.4951">«lib»</text><text fill="#000000" font-family="sans-serif" font-size="14" lengthAdjust="spacing" textLength="40" x="1243" y="848.792">Keras</text><!--MD5=[44d1b863b7cf48b60c60df6e4197ceba]
|
||||
link h_coap to main_super--><path d="M755.996,318.268 C735.631,336.968 684.939,383.515 648.11,417.333 " fill="none" id="h_coap-main_super" style="stroke:#A80036;stroke-width:1.0;"/><!--MD5=[c3a97ac6bd5938361921b1a80d181d45]
|
||||
link buff to optimiseur--><path d="M1104.82,335.766 C1104.64,361.86 1104.37,402.064 1104.19,428.696 " fill="none" id="buff-to-optimiseur" style="stroke:#A80036;stroke-width:1.0;"/><polygon fill="#A80036" points="1104.15,433.833,1108.2116,424.8606,1104.1843,428.8331,1100.2118,424.8058,1104.15,433.833" style="stroke:#A80036;stroke-width:1.0;"/><text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="71" x="1105" y="383.5669">expérience</text><!--MD5=[8dc40196e7be32b7499da14a3a158fab]
|
||||
link optimiseur to NN--><path d="M1104,480.197 C1104,522.804 1104,615.924 1104,662.23 " fill="none" id="optimiseur-to-NN" style="stroke:#A80036;stroke-width:1.0;"/><polygon fill="#A80036" points="1104,667.37,1108,658.37,1104,662.37,1100,658.37,1104,667.37" style="stroke:#A80036;stroke-width:1.0;"/><text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="66" x="1105" y="539.5669">met à jour</text><!--MD5=[00e0e56bb8942f7d045b72b28410dcb8]
|
||||
link horloge to optimiseur--><path d="M966.476,340.606 C998.33,367.334 1044.01,405.666 1073.84,430.694 " fill="none" id="horloge-to-optimiseur" style="stroke:#A80036;stroke-width:1.0;"/><polygon fill="#A80036" points="1077.76,433.983,1073.4358,425.1342,1073.9295,430.7695,1068.2942,431.2631,1077.76,433.983" style="stroke:#A80036;stroke-width:1.0;"/><text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="65" x="1023" y="383.5669">déclanche</text><!--MD5=[0a9c8fbc5e6be315dc2579d6523c8be8]
|
||||
link h_stat to stat--><path d="M509.109,309 C520.842,309 532.575,309 544.308,309 " fill="none" id="h_stat-stat" style="stroke:#A80036;stroke-width:1.0;"/><!--MD5=[2a53bd9146470a4be8de7aed6b5e91cc]
|
||||
link stat to buff--><path d="M611.258,285.928 C620.128,253.062 641.521,193.93 685,168.5 C748.491,131.36 951.558,133.04 1016,168.5 C1057.95,191.59 1082.9,243.726 1095.27,277.587 " fill="none" id="stat-to-buff" style="stroke:#A80036;stroke-width:1.0;"/><polygon fill="#A80036" points="1097,282.445,1097.7441,272.6243,1095.3203,277.7356,1090.209,275.3118,1097,282.445" style="stroke:#A80036;stroke-width:1.0;"/><text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="47" x="741.5" y="128.5669">remplis</text><!--MD5=[6a54ee8702427f98472c00275752958b]
|
||||
link h_session_message to main_sess--><path d="M351.035,699.626 C335.382,717.888 296.571,763.167 268.129,796.35 " fill="none" id="h_session_message-main_sess" style="stroke:#A80036;stroke-width:1.0;"/><!--MD5=[2d05a6350c3effd7dbed848763bf8dc3]
|
||||
link h_session_rto to main_sess--><path d="M235,699.626 C235,717.888 235,763.167 235,796.35 " fill="none" id="h_session_rto-main_sess" style="stroke:#A80036;stroke-width:1.0;"/><!--MD5=[74528d00b0bff99990fc7889a8a0826b]
|
||||
link main_sess to s_udp--><path d="M169.78,863.04 C152.081,873.469 135.048,887.405 125,905.5 C108.164,935.817 119.892,978.566 127.654,999.867 " fill="none" id="main_sess-to-s_udp" style="stroke:#A80036;stroke-width:1.0;"/><polygon fill="#A80036" points="129.522,1004.8,130.074,994.9666,127.7506,1000.1243,122.5929,997.8009,129.522,1004.8" style="stroke:#A80036;stroke-width:1.0;"/><text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="43" x="126" y="926.0669">packet</text><text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="24" x="135.5" y="941.1997">udp</text><!--MD5=[4fe7736ffa86495e5c2d9f1f23a257e1]
|
||||
reverse link main_sess to s_udp--><path d="M213.626,880.167 C202.39,902.14 188.059,929.086 174,952.5 C162.374,971.863 147.093,993.548 138.861,1004.966 " fill="none" id="main_sess-backto-s_udp" style="stroke:#A80036;stroke-width:1.0;"/><polygon fill="#A80036" points="215.976,875.556,208.3264,881.7595,213.7063,880.0112,215.4546,885.391,215.976,875.556" style="stroke:#A80036;stroke-width:1.0;"/><text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="74" x="202" y="918.5669">aquitement</text><text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="10" x="234" y="933.6997">&</text><text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="52" x="213" y="948.8325">réponse</text><!--MD5=[4dc824d22c09885eb383f3198762067a]
|
||||
link main_sess to file_attente--><path d="M273.47,875.866 C280.246,884.915 286.305,894.997 290,905.5 C296.932,925.205 299.011,933.654 290,952.5 C284.341,964.336 257.464,984.378 237.492,998.129 " fill="none" id="main_sess-to-file_attente" style="stroke:#A80036;stroke-width:1.0;stroke-dasharray:7.0,7.0;"/><polygon fill="#A80036" points="233.345,1000.962,243.0322,999.1849,237.4727,998.1402,238.5174,992.5807,233.345,1000.962" style="stroke:#A80036;stroke-width:1.0;"/><text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="23" x="298" y="933.5669">use</text><!--MD5=[6e782e06c0d2e17c0f5dc02bf57560f0]
|
||||
link main_sess to timer--><path d="M300.421,873.953 C311.745,882.96 322.325,893.513 330,905.5 C343.574,926.701 348.725,954.723 350.535,976.842 " fill="none" id="main_sess-to-timer" style="stroke:#A80036;stroke-width:1.0;stroke-dasharray:7.0,7.0;"/><polygon fill="#A80036" points="350.908,982.041,354.2549,972.7783,350.5509,977.0538,346.2753,973.3497,350.908,982.041" style="stroke:#A80036;stroke-width:1.0;"/><text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="23" x="348" y="933.5669">use</text><!--MD5=[7ce8e2bcdca09a44590c89891d28fe3f]
|
||||
link main_super to h_session_message--><path d="M545.243,496.709 C522.263,512.522 496.489,531.731 475,551.5 C431.989,591.068 389.694,646.017 369.795,673.088 " fill="none" id="main_super-to-h_session_message" style="stroke:#A80036;stroke-width:1.0;"/><path d="M372.3756,683.9168 A9,9 0 0 0 358.6985 673.9651" style="stroke:#A80036;stroke-width:1.5;fill:none;"/><!--MD5=[ef2e0f79354206e0cc2b9607dccfbee3]
|
||||
link NN to h_session_rto--><path d="M1073.98,678.515 C945.413,627.995 441.44,438.471 302.333,514.833 C246.288,545.599 236.584,632.025 235.12,671.002 " fill="none" id="NN-to-h_session_rto" style="stroke:#A80036;stroke-width:1.0;"/><path d="M243.4117,678.5711 A9,9 0 0 0 226.5015 678.1941" style="stroke:#A80036;stroke-width:1.5;fill:none;"/><!--MD5=[e7d46baa1e450a057fba51bfb34eb936]
|
||||
link main_sess to h_stat--><path d="M169.629,817.568 C128.973,803.11 79.5398,778.179 53,737.5 C35.8582,711.226 11.1533,451.311 38,417.5 C94.8622,345.888 400.744,317.623 480.809,311.39 " fill="none" id="main_sess-to-h_stat" style="stroke:#A80036;stroke-width:1.0;"/><path d="M487.222,302.426 A9,9 0 0 0 488.493 319.2926" style="stroke:#A80036;stroke-width:1.5;fill:none;"/><!--MD5=[6d15f5afd906b4a05315f45878a919c1]
|
||||
link GMN1269701 to client--><path d="M118.575,469.68 C106.818,486.708 85.9312,519.783 77,551.5 C75.9755,555.1383 75.0467,558.8512 74.2059,562.6158 C73.9957,563.557 73.7909,564.5014 73.5916,565.4486 C73.4919,565.9223 73.3936,566.3966 73.2966,566.8716 " fill="none" id="GMN1269701-client" style="stroke:#A80036;stroke-width:1.0;stroke-dasharray:7.0,7.0;"/><!--MD5=[be411837912adfb435f6f18d03088f30]
|
||||
link usr to h_coap--><path d="M718.294,85.51 C730.389,143.12 752.385,247.905 761.198,289.89 " fill="none" id="usr-to-h_coap" style="stroke:#A80036;stroke-width:1.0;"/><path d="M770.9166,295.0192 A9,9 0 0 0 754.3628 298.4938" style="stroke:#A80036;stroke-width:1.5;fill:none;"/><!--MD5=[030ca119770c76539f4bb2f11fd02f62]
|
||||
link db to h_coap--><path d="M813.691,76.05 C802.166,130.95 778.042,245.872 768.755,290.111 " fill="none" id="db-to-h_coap" style="stroke:#A80036;stroke-width:1.0;"/><path d="M775.5952,298.696 A9,9 0 0 0 759.0416 295.221" style="stroke:#A80036;stroke-width:1.5;fill:none;"/><!--MD5=[98669b2e2b94e771ebe6a5424a2eb69f]
|
||||
link buff to tf--><path d="M1148.85,335.624 C1162.03,345.139 1175.49,356.961 1185,370.5 C1249.53,462.407 1273.08,597.81 1280.73,658.309 " fill="none" id="buff-to-tf" style="stroke:#A80036;stroke-width:1.0;stroke-dasharray:7.0,7.0;"/><polygon fill="#A80036" points="1281.38,663.579,1284.2482,654.157,1280.7679,658.6166,1276.3083,655.1364,1281.38,663.579" style="stroke:#A80036;stroke-width:1.0;"/><text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="23" x="1245" y="461.5669">use</text><!--MD5=[4d8c7b75c91428342e9b727caf112eb9]
|
||||
link optimiseur to tf--><path d="M1132.06,480.142 C1147.2,492.826 1165.65,509.555 1180,526.5 C1216.12,569.16 1249.26,625.291 1268,659.317 " fill="none" id="optimiseur-to-tf" style="stroke:#A80036;stroke-width:1.0;stroke-dasharray:7.0,7.0;"/><polygon fill="#A80036" points="1270.44,663.763,1269.6236,653.948,1268.0375,659.378,1262.6076,657.792,1270.44,663.763" style="stroke:#A80036;stroke-width:1.0;"/><text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="23" x="1194" y="539.5669">use</text><!--MD5=[414b4abe29706d3b1d235c982f330774]
|
||||
link NN to keras--><path d="M1128.5,713.607 C1155.92,738.362 1200.48,778.579 1230.73,805.878 " fill="none" id="NN-to-keras" style="stroke:#A80036;stroke-width:1.0;stroke-dasharray:7.0,7.0;"/><polygon fill="#A80036" points="1234.72,809.475,1230.7287,800.4711,1231.0119,806.1209,1225.3622,806.4041,1234.72,809.475" style="stroke:#A80036;stroke-width:1.0;"/><text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="23" x="1184" y="762.5669">use</text><!--MD5=[74d8804e3d4c7fb6dc3d2e83290e718e]
|
||||
link s_udp to udp--><path d="M133,1023.441 C133,1047.601 133,1117.9266 133,1159.0631 " fill="none" id="s_udp-to-udp" style="stroke:#A80036;stroke-width:1.0;stroke-dasharray:7.0,7.0;"/><polygon fill="#A80036" points="133,1164.1752,137,1155.1752,133,1159.1752,129,1155.1752,133,1164.1752" style="stroke:#A80036;stroke-width:1.0;"/><text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="23" x="134" y="1130.5669">use</text><!--MD5=[572256f3a60bec37f8387ca93c52b5ac]
|
||||
@startuml
|
||||
:Utilisateur: as usr
|
||||
database "Base de\ndonnée" as db
|
||||
file "UDP" <<lib>> as udp
|
||||
file "TensorFlow" <<lib>> as tf
|
||||
file "Keras" <<lib>> as keras
|
||||
|
||||
package "Client CoAP" as global {
|
||||
component "Superviseur" as super <<Thread>>{
|
||||
() "Interface CoAP" as h_coap
|
||||
() "Collecteur donnée" as h_stat
|
||||
|
||||
component "Gestionaire\nglobal" <<main>> as main_super
|
||||
component "Statisticien" as stat
|
||||
|
||||
stack "buffer\nd'experience" as buff
|
||||
[NN]
|
||||
[optimiseur]
|
||||
[horloge] <<interuption>>
|
||||
|
||||
h_coap - - main_super
|
||||
|
||||
buff - -> optimiseur : expérience
|
||||
optimiseur - -> NN : met à jour
|
||||
horloge - -> optimiseur : déclanche
|
||||
|
||||
h_stat - stat
|
||||
stat -> buff : remplis
|
||||
}
|
||||
component "Session" as client <<Threads>> {
|
||||
() "Socket UDP" as s_udp
|
||||
() "Session handle" as h_session_message
|
||||
() "RTO" as h_session_rto
|
||||
queue "Buffer" as file_attente
|
||||
[Gestionaire\nde la session] <<main>> as main_sess
|
||||
[timer] <<interuption>> as timer
|
||||
h_session_message - - main_sess
|
||||
h_session_rto - - main_sess
|
||||
main_sess - -> s_udp : packet\nudp
|
||||
main_sess ..> file_attente : use
|
||||
main_sess <- - s_udp : aquitement\n&\nréponse
|
||||
main_sess ..> timer : use
|
||||
}
|
||||
|
||||
main_super - -( h_session_message
|
||||
NN - -( h_session_rto
|
||||
main_sess - -( h_stat
|
||||
|
||||
note top of client
|
||||
Un par capteur
|
||||
end note
|
||||
}
|
||||
|
||||
usr - -( h_coap
|
||||
db - -( h_coap
|
||||
|
||||
|
||||
buff ..> tf : use
|
||||
optimiseur ..> tf : use
|
||||
NN ..> keras : use
|
||||
s_udp ..> udp : use
|
||||
@enduml
|
||||
|
||||
PlantUML version 1.2021.7(Sun May 23 12:40:07 UTC 2021)
|
||||
(GPL source distribution)
|
||||
Java Runtime: Java(TM) SE Runtime Environment
|
||||
JVM: Java HotSpot(TM) 64-Bit Server VM
|
||||
Default Encoding: UTF-8
|
||||
Language: en
|
||||
Country: US
|
||||
--></g></svg>
|
||||
|
Before Width: | Height: | Size: 26 KiB |
Loading…
Reference in a new issue