# Improving the Asynchronous Contact Tracing (ACT) platform

Egan Perais

<figure><img src="image_1.png" /></figure>

To cite this version:

Egan Perais. Improving the Asynchronous Contact Tracing (ACT) platform. Informatique [cs]. 2025. hal-05459022

HAL Id: hal-05459022

https://inria.hal.science/hal-05459022v1

Submitted on 15 Jan 2026

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_2.png" /></figure>

Distributed under a Creative Commons CC0 1.0 - Universal - International License
<figure><img src="image_3.png" /></figure>

Rapport de stage ingénieur

Institut National de Recherche en Informatique et en
Automatique (Inria)

Fonction : Assistant de Recherche

Tuteur de stage : Luigi Liquori, Directeur de Recherche INRIA
Table des matières

<table><tr><td>1.</td><td>Introduction : Contexte, sujet traité et finalité</td><td>3</td></tr><tr><td>1.1.</td><td>Contexte, sujet traité et finalité</td><td>3</td></tr><tr><td>2.</td><td>Travail effectué</td><td>3</td></tr><tr><td>2.1.</td><td>Asynchronous Contact Tracing</td><td>3</td></tr><tr><td>2.2.</td><td>Standard OneM2M</td><td>5</td></tr><tr><td>2.3.</td><td>Mes missions</td><td>6</td></tr><tr><td>2.4.</td><td>Étude de l' existant</td><td>7</td></tr><tr><td>2.5.</td><td>Réalisations concrètes</td><td>10</td></tr><tr><td>2.5.1.</td><td>Évolution du projet ACT</td><td>10</td></tr><tr><td>2.5.2.</td><td>Déploiement en ligne de la nouvelle version</td><td>16</td></tr><tr><td>3.</td><td>Bibliographie</td><td>17</td></tr><tr><td>4.</td><td>Glossaire</td><td>18</td></tr><tr><td>5.</td><td>Annexes</td><td>19</td></tr></table>
# 1. Introduction : Contexte, sujet traité et finalité

## 1.1. Contexte, sujet traité et finalité

Le projet de recherche sur lequel j'ai travaillé se nomme ACT pour Asynchronous Contact Tracing (Traçage asynchrones des cas contacts). Il s'agit d'une norme ETSI (TS 103757 [1]) créée par Luigi Liquori et d'autres experts de l'ETSI (Enrico Scarrone, Bob Flynn, Andreas Kraft...) en 2020 juste après la pandémie de Covid-19. La norme a été créée pour remplacer les applications téléphoniques pandémiques en Europe, en raison de leur échec signalé par des études universitaires et institutionnelles [2][3]. Ces applications avaient toutes un point commun : les utilisateurs devaient se déclarer comme cas contacts ou cas positifs, et deux clés cryptographiques étaient échangées selon le principe « 2 mètres - 15 minutes » (ce qui n'est pas une bonne idée sur le plan social, car cela revient à attraper le virus seulement après qu'il ait déjà pénétré votre corps...).

Comme il était assez tabou de se déclarer positif ou cas contact, les gens n'utilisaient pas les applications, qui étaient donc inutiles. C'est pourquoi l'idée d'ACT consiste à utiliser un système de détection automatique, asynchrone et anonyme du COVID pour alerter les gens si une zone est contaminée ou non.

À l'inverse d'un projet ingénieur avec des consignes et des objectifs bien définis, la finalité d'un projet de recherche n'est pas toujours connue dès le départ. Le but de ces recherches a été de savoir comment faire évoluer la méthode ACT afin de l'utiliser dans un scénario autre qu'une pandémie mondiale, tout en cherchant à appliquer le standard oneM2M de la meilleure façon possible.

# 2. Travail effectué

## 2.1. Asynchronous Contact Tracing

« Asynchronous Contact Tracing » signifie « Traçage asynchrone des contacts ». Le traçage des contacts est une méthode utilisée pour freiner la propagation d'une maladie, en coupant sa chaîne de transmission. À l'inverse d'un système synchrone classique, c'est un système
asynchrone qui a été choisi. Pour comprendre la différence entre ces deux termes voici une
explication :

Dans un système synchrone, toujours dans un cadre de pandémie, notre téléphone transmet nos données de traçage des contacts à un serveur central, ou à d'autres téléphones via Bluetooth. Il y a une interaction immédiate ou directe entre les utilisateurs, ou entre mon téléphone et un serveur. Celui-ci peut potentiellement savoir où nous sommes allés et qui on a croisé.

Dans un système asynchrone comme ACT, notre téléphone ne parle à personne, mais il capte simplement des informations publiques (la liste des capteurs à proximité). Ensuite, localement et sans envoi d'information, notre téléphone compare ces données avec notre historique. Il n'y a pas de communication bidirectionnelle avec des utilisateurs ou un serveur. C'est parce que cette méthode est locale et anonyme qu'elle a été choisie. Elle répond au problème survenu lors de la pandémie de 2020.

Pour faire suite à l'introduction du projet ACT, voici en quelques points comment cela fonctionne :

- Les techniques de détection permettent d'identifier le virus sur le plastique, le bois, dans l'air et dans l'eau au plus proche des gens.

- Les smartphones, toujours entre les mains des utilisateurs, enregistrent l'empreinte des déplacements de leur utilisateurs.

- De simples requêtes oneM2M dans le réseau IoT oneM2M nous permettent de vérifier si une zone donnée est infectée (oneM2M est à l'heure actuelle, le seul protocole de communication standardisé permettant la création d'un réseau de détection IoT)

- L'empreinte (qui est stockée dans le téléphone des utilisateurs et qui n'est jamais communiquée) est vérifiée par rapport à la requête oneM2M : c'est ce qui a donné le nom « asynchrone » dans ACT. Si l'intersection n'est pas vide, c'est-à-dire que si un utilisateur est allé dans endroit où une présence de virus a été détectée, il y a au moins un point en commun entre les deux listes, et la personne ferait mieux de se faire tester. L'alerte est locale et anonyme.
En appliquant ces étapes au schéma de fonctionnement d'ACT, lorsque qu'un capteur de virus (Detection Service) détecte la présence d'un virus, sa position est envoyée dans une base de données gouvernementale (Control Service ou National Control Service) par un serveur intermédiaire (Local Service). Quand un utilisateur de l'application mobile (Mobile App) se déplace, l'application récupère automatiquement les identifiants uniques des capteurs environnants, et regarde si la zone est contaminée. Si c'est le cas, l'utilisateur reçoit une notification. Il peut également retrouver les zones infectées via la carte du site web d'ACT (Display Application) [12].

<figure><img src="image_4.png" /><figcaption>Figure 3 : Schéma de l'architecture ACT dans le cadre de oneM2M</figcaption></figure>

## 2.2. Standard OneM2M

OneM2M est un partenariat entre huit organismes majeurs de normalisation (ARIB et TTC au Japon, ATIS et TIA aux États-Unis, CCSA en Chine, ETSI en Europe, TSDSI en Inde et TTA en Corée) établi en 2012 [13]. Ces organisations collaborent pour développer un standard technique commun permettant à tous les objets connectés et systèmes IoT de communiquer entre eux, peu importe leur fabricant ou leur technologie. L'objectif est simple : éviter que chaque constructeur crée son propre système fermé et incompatible avec les autres.

Le standard oneM2M évolue régulièrement : la première version sort en janvier 2015, la deuxième en mars 2016, et nous utilisons dans le projet ACT la troisième version publiée en
décembre 2018. Cette approche garantit une amélioration continue des fonctionnalités et de
la sécurité.

Aujourd'hui, ce standard n'est plus seulement théorique : il équipe déjà le réseau IoT national indien, et quelques entreprises européennes. Ces déploiements concrets montrent que oneM2M permet réellement de faire fonctionner ensemble des objets connectés de différentes marques et technologies.

Selon ce standard, l'architecture d'un réseau IoT s'organise en arbre hiérarchique dont la racine est un CSE (Common Service Entity). Cette racine agit comme une interface de communication entre tous les appareils du système. Plus précisément, c'est une API REST, ce qui signifie qu'elle permet aux appareils d'échanger des données en suivant un modèle simple basé sur des requêtes web standards (comme quand on navigue sur internet). Grâce à cette interface, les objets connectés peuvent s'enregistrer, demander ou envoyer des informations, et interagir entre eux de manière sécurisée et organisée (c'est ce qu'on appelle le modèle publish/subscribe ou pub/sub).

L'arbre de ressources oneM2M comprend plusieurs types de ressources fondamentaux. Les Application Entities (AE), représentent des applications connectées. Les Containers (CNT) sont basiquement des dossiers, dans lequel on range des Content Instances (CIN) qui sont des données. Ces dernières sont les données reçues par les AE. Elles peuvent être des positions géographiques, des mesures de qualité de l'air...

Cette architecture garantit que toute communication entre plusieurs objets du réseau transite par les CSE, assurant ainsi la sécurité et le contrôle du système. Le fait d'avoir choisi ce standard pour le projet ACT est une bonne idée. D'un côté, ETSI se situe à environ 1 kilomètre du centre Inria Sophia Antipolis, ce qui est plus simple pour une collaboration étroite, et d'un autre côté, cela favorise l'utilisation de ce standard qui se fait trop rare. L'implémentation utilisée est celle d'Andreas Kraft, ACME, qui est actuellement l'outil qui se rapproche le plus du standard [14].

## 2.3. Mes missions

Durant mon stage ingénieur, mon tuteur Luigi Liquori m'a confié plusieurs tâches. En tant qu'assistant de recherche, mon travail consistait à faire de la recherche et développement et
du déploiement Cloud, ainsi qu'un peu de management d'équipe au début de mon stage. J'ai
donc eu trois missions principales :

- Trouver des moyens de faire évoluer le projet ACT

- Déployer en ligne la nouvelle version du projet

Ma première mission a consisté à cogérer avec mon tuteur l'équipe des trois autres stagiaires. Dans le cadre de leurs études en master 2, un Programme Interdisciplinaire de Recherche (PIR) doit être réalisé. Il s'agit d'un stage de deux semaines, effectué dans le milieu de la recherche. Ils l'ont donc fait aux côtés de M. Liquori et de moi-même. Cela a été une période propice pour nous tous afin de mieux comprendre le sujet de recherche et de trouver des idées quant à l'évolution du projet ACT. Pierre-Adrien s'occupait de maintenir à jour les composants logiciels nécessaires au bon fonctionnement de l'application (les librairies), y compris les fichiers liés à l'environnement Docker. Eidem Essafi avait la charge de mettre à jour l'application mobile et Hamadi Daghar effectuait des recherches sur différents types de capteurs et autres technologies afin d'identifier de nouveaux cas d'utilisation pour ACT. Ensemble, nous cherchions également un moyen d'ajouter une certaine mobilité au projet dont je traiterai par la suite. Durant ces deux premières semaines, j'ai également commencé à m'intéresser à l'amélioration de l'implémentation du projet. En effet, plusieurs stagiaires m'ont précédé dont Thomas Gorisse, Grégory Jeannin, Ahmed Kamoun, Antoine Fadda Rodriguez et d'autres ont développé une preuve de concept du standard ACT.

2.4. Étude de l'existant

La prise en main du projet existant a été une tâche nécessaire et essentielle afin de voir
l'avancée du projet. Comme ACT est une norme, les précédents stagiaires ont mis en place
des technologies et outils pour l'implémenter. Inria héberge localement sur ses serveurs une
version de Gitlab, qui est une plateforme de gestion de projets et de code source, sur
laquelle le projet ACT est stocké. Voici à quoi ressemble l'outil :
<figure><img src="image_5.png" /><figcaption>Figure 4 : Organisation du projet dans GitLab</figcaption></figure>

Le projet est lui-même divisé en sous-groupes pour une meilleure organisation. On y retrouve les éléments mentionnés précédemment comme le Local Service, l'application mobile, la librairie, le National Control Service, le site web, mais aussi du code pour les microcontrôleurs ESP32 (utilisés pour tester réellement le système), ainsi que de la documentation. Voici le site web en ligne à disposition du public :

<figure><img src="image_6.png" /><figcaption>Figure 5 : Site web d'ACT permettant de rechercher des zones infectées</figcaption></figure>

Il permet de sélectionner des zones, afin de voir si les capteurs présents dans celles-ci détectent un virus. Thomas Gorisse, un ancien stagiaire, avait commencé la création d'un
outil de création de capteurs simulés (appelés Detection Services ou Application Entities).

Cela était la première étape pour simuler un réseau entier avant le déployer en ligne.

<figure><img src="image_7.png" /><figcaption>Figure 6 : Première version du panneau de contrôle pour créer des AE, par Thomas Gorisse</figcaption></figure>

<figure><img src="image_8.png" /><figcaption>Figure 7 : Première version du panneau de contrôle, avec la simulation des données envoyées par un AE, par Thomas Gorisse</figcaption></figure>
<figure><img src="image_9.png" /><figcaption>Figure 8 : Site web d'ACT fonctionnant avec le prototype de Thomas Gorisse</figcaption></figure>

## 2.5. Réalisations concrètes

À la suite de cette analyse de l' existant, j'ai pu identifier les axes d'amélioration prioritaires et me concentrer sur la réalisation concrète de mes missions.

### 2.5.1. Évolution du projet ACT

C'est cette partie qui a été ma principale mission. Comme énoncé plus tôt dans le rapport, oneM2M fonctionne en système hiérarchique, que mon tuteur et moi appelons « arbre ».

Cependant, dans la preuve de concept développé par les précédents stagiaires, on ne retrouvait pas exactement une structure d'arbre, mais une seule instance d'ACME principale (appelée IN pour Infrastructure Node), sur laquelle étaient branchés tous les capteurs (AE). Voici un schéma de ce qui a été mis en place :
<figure><img src="image_10.png" /><figcaption>Figure 9 : Première version de la hiérarchie oneM2M mise en place pour ACT</figcaption></figure>

Pour information un Node est un nœud, et représente une instance d'ACME qui permet
à des AE de s'enregistrer pour envoyer leurs données.

Il existe deux types de nœuds :

- IN (Infrastructure Node) : Il y en a un seul par arbre. Il s'agit du nœud principal, en haut de l'arbre. Des AE peuvent s'enregistrer, ainsi que des MN (Middle Node).

- MN (Middle Node) : Il s'agit d'un nœud intermédiaire. On peut y enregistrer des AE, ainsi que d'autres MN, pour créer un arbre plus fourni.

Il existe d'autres types de ressources oneM2M, mais je traiterai uniquement des INs, MNs et AEs.

Le modèle présenté ci-dessus fonctionne tel quel, mais ne peut pas représenter un
modèle réel. En effet, si l'IN représente la France, cela voudrait dire que tous les capteurs de
France sont branchés à une seule instance. La solution a été de segmenter le réseau pour
agrandir cet arbre. Pour cela, j'ai utilisé des MN, qui sont d'autres instances d'ACME. Après
plusieurs jours de recherche et de tests, je suis parvenu à créer une structure plus fournie, et
plus réelle, comme cela :
<figure><img src="image_11.png" /><figcaption>Figure 10 : Architecture en arbre</figcaption></figure>

Cette structure est beaucoup plus logique dans le fonctionnement du projet. Dans la réalité, ce sont les entreprises, les habitations et les autres bâtiments qui posent les capteurs. Cet arbre permet donc une meilleure gestion des capteurs et des instances en elles-mêmes, tout en laissant une certaine autonomie à chaque gestionnaire de capteurs.

Le problème avec cette structure, c'est qu'elle n'englobe que la France. Mon tuteur souhaitait un arbre comprenant les pays de l'Union Européenne. Pour cela, j'ai simplement dû revoir l'arbre global, en décidant avec mon tuteur de mettre la Belgique comme nœud principal (car Bruxelles est le siège du Conseil de l'UE, du Conseil européen et de la Commission européenne) :
<figure><img src="image_12.png" /><figcaption>**Figure 11 : Restructuration de la hiérarchie en arbre avec la Belgique en tant qu'IN principal**</figcaption></figure>

Cette première étape a été très intéressante car elle a combiné recherche et développement. J'ai dû en premier lieu comprendre si oneM2M permettait de connecter tous ces nœuds, puis dans un deuxième lieu, j'ai dû chercher le moyen de les connecter avec ACME. Andréas Kraft a implémenté cette fonctionnalité, ce qui m'a permis de créer ce type d'architecture avec son aide.

Une fois cette architecture réalisée avec succès, j'ai pu reproduire ou adapter facilement tout autre type de structure hiérarchique.

Afin de tester cette structure, je me suis intéressé au prototype de simulation d'AE présenté plus tôt et développé par Thomas Gorisse. J'ai donc commencé la création d'un panneau de contrôle basé sur le prototype afin de pouvoir créer et simuler plusieurs AE tout en choisissant à quel MN je souhaite les enregistrer. Cet outil permet également de simuler un réseau ACT entier, en testant les limites technologiques d'ACME, le tout sur notre propre ordinateur. Cependant, je me suis heurté à quelques problèmes :

- Le concept de MN n'était pas implémenté dans le prototype.

- Son utilisation était compliquée. Certaines fonctionnalités étaient inutiles.

- Certaines parties ne respectaient le standard ACT

J'ai donc repris la base du prototype en commençant par une refonte graphique entière (en HTML, CSS).
<figure><img src="image_13.png" /><figcaption>Figure 12 : Nouveau panneau de contrôle, avec la création des AE et la carte en temps réel</figcaption></figure>

Comme les structures hiérarchiques commençaient à être conséquentes, j'ai décidé d'ajouter la possibilité de lancer ou de stopper les différentes instances d'ACME, directement sur le panneau de contrôle en me basant sur le code existant en Python et en Javascript (ici 2 instances ACME sont ouvertes : celui de la Belgique, et celui de l'Autriche).

<figure><img src="image_14.png" /><figcaption>Figure 13 : Nouveau panneau de contrôle, gestion simplifiée des instances ACME et affichage automatique de la hiérarchie des CSE</figcaption></figure>

Je suis donc parvenu à créer et simuler des AE via le nouveau panneau de contrôle, tout en respectant le standard oneM2M en passant par ACME. J'ai également réussi à faciliter l'ouverture et fermeture des instances. Il est intéressant de noter que ce type d'application est nouveau pour ACME et oneM2M, ce qui nous a permis avec M. Kraft d'implémenter un
nouveau système de fermeture d'instance ACME via une requête Web (http) sur les systèmes Windows.

Mon tuteur et moi sommes donc passés à l'étape suivante : l'interconnexion de plusieurs IN que l'on a appelé la structure en « fleur ».

<figure><img src="image_15.png" /><figcaption>Figure 14 : Architecture en fleur</figcaption></figure>

Comme mentionné précédemment, il est possible de connecter un IN avec un ou plusieurs MN, mais pas plusieurs IN. Cette connexion est assez délicate à mettre en place car peu de documentation existe sur ce sujet, donc cela a été un vrai travail de recherche et développement. Avec l'aide de M. Kraft, je suis parvenu à réaliser cette connexion pour enfin respecter le standard ACT (connexion inter-domaine). Il y a cependant selon moi quelques points à améliorer dans cette mise en place. En effet, pour réaliser cette connexion, il est nécessaire que toutes les instances se connaissent au maximum une fois. C'est-à-dire que si l'instance de France connaît celle de la Belgique, alors, la Belgique n'a pas besoin de connaître la France. La configuration des instances devient de plus en plus compliquée dès lors que le nombre d'instances augmente, et en ajouter une se traduit par le fait modifier toutes les autres.

La réussite de cette mission a été un vrai succès car cela a permis de standardiser un pan d'ACT qui n'avait pas pu être mis en place.

En revanche, cela a posé un réel problème sur le reste du projet. L'implémentation précédente avait été créée pour une structure d'arbre simplissime avec un seul IN, et des AE
enregistrés directement dessus. Cela implique que tout le reste du projet, essentiellement le National Control Service et la librairie ont été développé pour cette structure précise. Adapter le code à la nouvelle structure en fleur signifie redévelopper presque entièrement ces éléments. Par manque de temps, je n'ai pas pu les redévelopper, mais j'ai mis à disposition une version fonctionnelle et locale du nouveau panneau de configuration avec la structure en arbre. La version en fleur fonctionne également, mais ne respecte pas le standard sur certains points.

### 2.5.2. Déploiement en ligne de la nouvelle version

Après la mise en place des deux nouvelles structures, je me suis attardé sur le déploiement de la nouvelle version du projet sur le Cloud d'Inria qui fonctionne en tant que serveur interne et externe. Je me suis heurté à deux principales difficultés durant cette mission. La première étant le fait qu'il ne me restait qu'une semaine pour déployer la nouvelle version. La seconde étant que tout fonctionne avec la technologie Docker, que je n'ai jamais utilisé. Docker est une plateforme open source qui permet de créer et d'exécuter des applications dans des conteneurs. Un conteneur est un environnement léger et isolé qui inclut tout ce dont une application a besoin pour fonctionner (code, configurations, dépendances...). Cela permet de garantir que l'application marche de la même façon partout, que ce soit sur un ordinateur personnel, un serveur de test, ou en production, sans conflits. Inria utilise donc une plateforme de gestion des conteneurs Docker, appelée Portainer. Elle permet d'utiliser, surveiller et déployer des conteneurs facilement. Je n'ai pas pu réaliser cette mission en une semaine, mais j'ai pu comprendre le fonctionnement de Docker, Portainer, et Docker Hub qui est une plateforme en ligne de stockage et de partage d'images de conteneurs Docker. De manière concise, les images sont les installateurs de conteneurs.
## 3. Bibliographie

[1] ETSI TS 103 757 V2.1.1 (2021-08), ETSI TS 103 757 V2.1.1 (2021-08), SmartM2M; Asynchronous Contact Tracing System; Fighting pandemic disease with Internet of Things (IoT) :
https://www.etsi.org/deliver/etsi_ts/103700_103799/103757/02.01.01_60/ts_103757v020101p.pdf

[2] Effectiveness evaluation of digital contact tracing for COVID-19 in New South Wales, Australia, Vogt, Florian et al. The Lancet Public Health, Volume 7, Issue 3, e250 - e258

[3] Jenniskens K, Bootsma MCJ, Damen JAAG, et al. Effectiveness of contact tracing apps for SARS-CoV-2: a rapid systematic review. *BMJ Open*. 2021;11(7):e050519. Published 2021 Jul 12. doi:10.1136/bmjopen-2021-050519

[4] Histoire d'Inria : https://www.inria.fr/fr/notre-histoire

[5] Site d'Inria Sophia Antipolis : https://www.inria.fr/fr/centre-inria-universite-cote-azur

[6] Contrat d'objectifs, de moyens & de performance pour la période 2024-2028 :
https://www.inria.fr/sites/default/files/2025-04/Contrat%20d%27objectifs%2C%20de%20moyens%20et%20de%20performance%20d%20Inria%202024-2028.pdf

[7] Article d'Inria sur le programme « 1 scientifique, 1 classe : chiche ! » :
https://inria.fr/fr/deploiement-application-programme-1-scientifique-1-classe-chiche

[8] Rapport annuel de 2024 d'Inria : https://www.inria.fr/sites/default/files/2025-07/Annual%20report%202024%20-%20Inria.pdf

[9] Article d'Inria concernant Terra Numerica : https://www.inria.fr/fr/ouverture-espace-terranumerica-sophia-mediation-scientifique

[10] Site Internet de Terra Numerica : https://terra-numerica.org/

[11] Site Internet de oneM2M : https://www.onem2m.org/

[12] Carte du projet : https://act.gitlabpages.inria.fr/website/

[13] Page Wikipédia de oneM2M : https://en.wikipedia.org/wiki/OneM2M

[14] Page Internet d'ACME : https://acmecse.net/
4. Glossaire

<table><thead><tr><td>Terme</td><td>Définition</td></tr></thead><tbody><tr><td>ACT</td><td>« Asynchronous Contact Tracing » ou « Traçage asynchrones des cas contacts » est une norme ETSI créée par Luigi Liquori et d'autres experts de l'ETSI.</td></tr><tr><td>ETSI</td><td>« European Telecommunications Standards Institute » ou en français « Institut des normes de télécommunications ». Il s'agit de l'organisme européen de normalisation qui élabore des normes pour les technologies de l'information et de la communication.</td></tr><tr><td>IoT</td><td>« Internet of Things » ou « Internet des Objets ». Réseau d'objets physiques connectés à Internet, capables de collecter, échanger et traiter des données de manière autonome.</td></tr><tr><td>MQTT</td><td>« Message Queuing Telemetry Transport ». Protocole de messagerie publication-abonnement (publish/subscribe) basé sur le protocole TCP/IP.</td></tr><tr><td>DD&RSE</td><td>Développement Durable et Responsabilité Sociétale et Environnementale</td></tr><tr><td>PEPR</td><td>Programmes et Équipements Prioritaires de Recherche</td></tr><tr><td>CSE</td><td>Common Service Entity. Nœud central dans oneM2M, fournissant les services de communication, de sécurité et de gestion des données.</td></tr><tr><td>Cloud</td><td>Ensemble de services informatiques (stockage, calcul, logiciels) accessibles à distance via Internet sans gestion directe de l'infrastructure par l'utilisateur.</td></tr><tr><td>PIR</td><td>Programme Interdisciplinaire de Recherche</td></tr><tr><td>API REST</td><td>Interface permettant à des systèmes de communiquer entre eux via des requêtes web standard, suivant des règles simples pour envoyer et recevoir des données de façon organisée et sécurisée. Plus simplement : c'est un moyen simple et standard pour deux applications de communiquer et d'échanger des données via internet.</td></tr><tr><td>Open Source</td><td>Ou « code source ouverte ». Logiciel dont le code source est accessible, modifiable et redistribuable librement.</td></tr></tbody></table>
# 5. Annexes

<figure><img src="image_16.png" /><figcaption>Annexe 1 : Trois instances ACME connectées en architecture de fleur (3 IN interconnectés) :</figcaption></figure>

<figure><img src="image_17.png" /></figure>

<figure><img src="image_18.png" /></figure>
<figure><img src="image_19.png" /><figcaption>Annexe 3 : Participation à l'évolution d'ACME :</figcaption></figure>
<figure><img src="image_20.png" /></figure>

Annexe 4 : Exemple de cas d'utilisation rédigé dans le cadre de l'implémentation de oneM2M dans une flotte de drones pour le projet du professeur Scagnetto en Italie.

<BATTERY>

Triggers

* Battery Level: The battery level of a drone becomes critical (<20%)

Pre-conditions

* All drones are pre-registered with the oneM2M platform and continuously transmit their telemetry data (GPS position, altitude, **battery status**, orientation, speed) to PAMAC. Flight zones are defined with appropriate geofences and charging stations are operational.

* The mission start with all drones having their battery charged

Normal flow : Battery Level

01. The N drones are registered with the oneM2M platform. PAMAC continuously sends/receives control messages to each drone for surveillance missions.

02. When the battery level of drone X becomes critical, PAMAC receives this information and sends a control message to the N-1 other drones indicating that drone X must return to the nearest charging station.

03. As the number of operational drones decreases, the remaining N-1 drones must adjust their surveillance coverage. PAMAC initiates a transaction mechanism and sends the new mission parameters to the N-1 drones.

04. The N-1 drones respond with success information, confirming acceptance of the new mission parameters.

05. PAMAC confirms the reconfiguration and drone X proceeds to automatically return to the charging station and N-1 drones continue to work on a new rescheduled basis....
## Alternative flow: Battery Level

01. All N drones are registered and PAMAC coordinates surveillance missions.

02. Drone X reports a critical battery level, requiring a return to the charging station.

03. PAMAC initiates the transaction mechanism and sends reconfiguration commands to the remaining N-1 drones.

04. Drones 1 to N/2 respond successfully, but drone Y reports a problem (mission overload, faulty sensor).

05. The oneM2M platform triggers the policy-based reprogramming mechanism, referencing the predefined transaction rules.

06. The drones are grouped into geographical areas: Group A (drones 1 to N/2, zone A) and Group B (drones N/2+1 to N, zone B).

07. If drone Y in Group A fails again, only the drones in Group A are affected by the cancellation, allowing Group B to continue its mission in the southern area.

## Post-conditions

None.

## High Level Illustration

<figure><img src="image_21.png" /><figcaption>Figure xx2: illustration diagram for battery use case</figcaption></figure>

<figure><img src="image_22.png" /><figcaption>Figure xx2: functional architecture diagram for battery use case</figcaption></figure>

## Potential requirements

1. The PAMAC shall support transaction management to multiple devices.