API Backend

Le rôle de cette API est de récupérer les données émises par les caméras, les traiter, les mettre en base de données, ainsi que de fournir aux caméras leur configuration.

Les étapes du fonctionnement du point de vue d'une caméra sont les suivantes :

• Lors du démarrage, la caméra va s'enregistrer auprès de l'API, et ainsi récupérer la configuration pour laquelle elle a été paramétré (c-à-d mode de fonctionnement, si il doit envoyer ses données, etc.)
• Si besoin, elle va passer par une étape de préparation (comme dans le mode d'affluence locale) où elle va de nouveau faire des appels à l'API pour envoyer ou récupérer des données
• Lorsque l'étape de préparation est terminée, la caméra passe en mode opération, et va donc récolter des données qu'elle transmet ensuite régulièrement à l'API. La fréquence à laquelle elle transmet ses informations dépend du mode de fonctionnement dans lequel elle se trouve

Cette API a été développée en Python, car cela rend plus simple le traitement des données de l'affluence locale, et notamment l'utilisation des algorithmes utilisés.

Affluence globale

L'affluence globale est calculée en faisant la somme des entrées et sorties comptées par toutes les caméras. Le fonctionnement est donc assez simple : les caméras peuvent envoyer leurs statistiques à l'API, qui garde un compte des entrées et sorties pour chaque endroit, et se charge de regrouper les données ensemble. Par exemple, elle calcule le nombre de personnes dans une zone en additionnant le nombre d'entrées et de sorties de toutes les caméras dans cette zone.

Affluence locale

Le suivi de l'affluence locale sur un évènement est plus complexe que celui de l'affluence globale : il ne s'agit pas simplement de compter des entrées et sorties, mais de regrouper les positions des personnes détectées par les caméras pour estimer la positions des personnes dans une zone, ainsi que d'identifier si plusieurs caméras détectent la même personne.

Pour cela, les caméras vont régulièrement envoyer les coordonnées dans leur référentiel des personnes qu'elles détectent, et l'API doit se charger de regrouper ces données et d'en déduire les statistiques souhaitées. En effet, une fois que l'API connaît la position des personnes dans une zone, elle peut en déduire les statistiques de personnes pour chaque stand dans la zone.

Ici, contrairement à la partie de l'affluence globale, il y a un traitement complexe à effectuer sur les données.

Regroupement des personnes par position

Les caméras vont donc transmettre à l'API les positions (dans leur référentiel) des personne qu'elles détectent, mais il est possible que plusieurs caméras détectent la même personne. Il faut donc trouver un moyen d'identifier quand c'est le cas.

Pour cela, à chaque fois qu'une caméra transmet ses données, comme pour le tracking positionnel effectué sur les caméras, on utilise un algorithme hongrois (voir tracking prédictif) pour déterminer quelles personnes étaient déjà présentes dans la zone et quelles personnes sont nouvelles dans les détections de la caméra, ainsi qu'actualiser les positions des personnes déjà présentes. Ici, pour construire notre graphe biparti pour l'algorithme, on prend la distance physique entre les positions comme poids pour les arêtes.

Afin d'effectuer de meilleurs regroupement, il est envisagé dans le futur de demander aux caméras d'envoyer au même moment leurs données, afin que toutes les données utilisées pour le calcul soient proches temporellement, ce qui élimine en partie les problèmes de regroupement liés aux déplacements des personnes.

Authentification et sécurité

Afin d'éviter que de fausses statistiques soient envoyées par une personne malveillante, il faut ajouter une sécurité à l'API afin d'authentifier les caméras. Pour cela, nous sommes parti sur l'utilisation de clés API.

Pour chaque caméra, un opérateur peut générer une clé API affichée une seule fois. Cette clé doit être placée dans un fichier dans la partition de boot de la Raspberry Pi accompagnant la caméra. La clé hashée est aussi stockée dans la base de données, associée à la caméra, ce qui permet de connaître quelle caméra effectue une requête en fonction de sa clé.

L'historique de toute les clés émises est conservé, et une clé peut être révoquée si besoin. De plus, il est aussi possible de bloquer une caméra, par exemple dans le cas où elle aurait été volée par une personne malveillante qui tenterait d'envoyer de mauvaises données.

Pas stateless

Cette API, du fait des traitements effectués, n'est pas stateless. En effet, elle a besoin de conserver des données sur un temps plutôt court (< 1 minute) pour regrouper les différentes informations.
Cependant, si l'API tombe et qu'une nouvelle est lancée, comme les données conservées par l'API ont une courte durée de vie, de nouvelles informations correctes peuvent être rapidement calculées.

Afin d'améliorer ce point là, il est envisagé que les données conservées en local soient aussi stockées dans une base de données annexe, afin qu'elles puissent être chargés rapidement si besoin.