FR3072814A1

FR3072814A1 - Procede et dispositif de detection d'entree, de presence ou de sortie de vehicule dans une zone surveillee

Info

Publication number: FR3072814A1
Application number: FR1759958A
Authority: FR
Original assignee: Nauticspot
Current assignee: JEREMY LADOUX, FR
Priority date: 2017-10-23
Filing date: 2017-10-23
Publication date: 2019-04-26
Also published as: EP3701501A1; WO2019081843A1; US20220198342A1; FR3072813A1

Abstract

Le dispositif de détection d'entrée, de présence ou de sortie d'un véhicule d'une zone surveillée, comporte : a) des moyens de : - détection de passage dans le chenal (coordonnées géolocalisées), - détection d'absence d'un ensemble de cellules Lora couvrant l'ensemble du port surveillé et/ou - détection d'absence d'un ensemble de cellules couvrant chaque emplacement de la zone surveillée ; b) des moyens de remontée des informations centralisées et c) des moyens d'interrogation d'un utilisateur du véhicule détecté.

Description

DOMAINE TECHNIQUE DE L’INVENTION

La présente invention concerne un procédé et un dispositif de détection d’entrée, de présence ou de sortie de véhicules dans une zone surveillée. Elle s’applique au domaine du nautisme, notamment plaisancier.

ÉTAT DE LA TECHNIQUE

Dans les ports de Plaisance, ni la capitainerie, ni les plaisanciers n’ont de visibilité en temps réel sur les emplacements disponibles. On procède, généralement, à une relève manuelle quotidienne ou hebdomadaire. Ce qui présente plusieurs inconvénients. D’une part, cela implique pour la capitainerie une perte financière due à la non-optimisation des places. D’autre part, les plaisanciers résidents au port ne sont pas récompensés pour déclarer leur absence et libérer leur emplacement, si bien qu’environ 10 % d’entre eux le font. Enfin, les résidents en escale se trouvent face à une pénurie apparente de place disponible due à une gestion manuelle et la procédure de demande d’escale est archaïque et chronophage.

Aujourd’hui les ports de plaisance sont confrontés à un double défi : d’une part inciter les propriétaires des bateaux à naviguer ou à faire naviguer leurs bateaux, d’autre part optimiser les places de ports afin de limiter les bateaux ventouses et permettre d’accueillir des bateaux en escale sur des anneaux disponibles.

Pourtant ni les places disponibles, ni les taux de sortie (ou d’absence) des bateaux ne sont connus précisément par les capitaineries. Il est donc très difficile voire impossible de faire une gestion en temps réel des mouvements (entrée/sortie) des bateaux et donc des disponibilités en anneaux, notamment durant la haute saison. Ceci entraîne un manque à gagner notable pour les ports. De la même façon, les plaisanciers ne sont pas incités à naviguer et à libérer leur place par les capitaineries et souvent il n’y a aucune différence de tarification annuelle entre un bateau ventouse et un plaisancier actif qui sort fréquemment et qui libère souvent son anneau.

OBJET DE L’INVENTION

La présente invention vise à remédier à tout ou partie de ces inconvénients.

À cet effet, selon un premier aspect, la présente invention vise un dispositif de détection d’entrée, de présence ou de sortie d’un véhicule d’une zone surveillée, qui comporte :

a) des moyens de :

- détection de passage dans le chenal (coordonnées géolocalisées),

- détection d’absence d’un ensemble de cellules Lora couvrant l’ensemble du port surveillé et/ou

- détection d’absence d’un ensemble de cellules couvrant chaque emplacement de la zone surveillée ;

b) des moyens de remontée des informations centralisées et

c) des moyens d’interrogation d’un utilisateur du véhicule détecté.

Dans des modes de réalisation, la détection de passage du bateau est effectué par détection de l’absence du bateau d’un ensemble de cellules RFID, LORA ou GSM.

Selon un deuxième aspect, la présente invention vise un procédé de détection d’entrée, de présence ou de sortie d’un véhicule d’une zone surveillée, qui comporte :

a) une étape de :

- détection de passage dans le chenal (coordonnées géolocalisées),

b) une étape de remontée des informations centralisées et

c) une étape d’interrogation d’un utilisateur du véhicule détecté.

Les avantages, buts et caractéristiques de ce procédé étant similaires à ceux du dispositif objet de l’invention, ils ne sont pas rappelés ici.

BRÈVE DESCRIPTION DES FIGURES

D’autres avantages, buts et caractéristiques de la présente invention ressortiront de la description qui va suivre, faite dans un but explicatif et nullement limitatif en regard du dessin annexé, dans lequel :

- les figures 1 et 2 illustrent des écrans affichés lors d’étapes de déclaration d’absence, avec cette application,

- la figure 3 représente un écran affiché pour changer de date ou d’heure de retour,

- la figure 4 illustre différents modes de réalisation de la solution,

- la figure 5 représente des balises déployées pour couvrir l’intégralité d’un plan d’eau portuaire,

- la figure 6 représente une détection en sortie du port,

- la figure 7 représente une détection en entrée dans un port d’escale,

- la figure 8 représente une détection en sortie du port d’escale,

- la figure 9 représente une détection d’un navire au large du port et

- la figure 10 représente une détection en retour au port d’attache.

DESCRIPTION D’EXEMPLES DE RÉALISATION DE L’INVENTION

La présente description est donnée à titre non limitatif, chaque caractéristique d’un mode de réalisation pouvant être combinée à toute autre caractéristique de tout autre mode de réalisation de manière avantageuse.

On note, dès à présente, que les figures ne sont pas à l’échelle.

L’invention vise à fournir une solution portuaire qui aide les capitaineries à identifier les entrées et sorties en temps réel au sein du port afin de communiquer plus facilement avec ses plaisanciers, d’optimiser le remplissage du port, dynamiser le tourisme et améliorez la rentabilité du port par l’optimisation de l’occupation des places.

Pour le plaisancier, c’est un outil simple et rapide pour s’informer avant une sortie, naviguer en toute sécurité, déclarer son absence tout en faisant des économies lorsque sa place est réutilisée pour l’escale.

En d’autres termes, il s’agit de fournir aux ports de plaisance des solutions permettant de répondre à leur besoin d’identification des mouvements des bateaux afin d’optimiser les places de ports libérées, pour augmenter leur capacité en escale, pour optimiser les places disponibles ou pour mieux gérer la facturation des places auprès des propriétaires, selon les mouvements des bateaux concernés

La présente invention utilise différentes solutions techniques, depuis l’installation de balises dans les bateaux et de bornes de passage à l’entrée du port, jusqu’à des applications mobiles qui ne nécessitent aucune installation à bord des bateaux. Dans tous les cas le système est intégré dans un logiciel de la capitainerie, afin que celle-ci puisse connaître en temps réel les places de ports disponibles ou vides et la durée prévue de disponibilité.

Le premier mode de réalisation de l’invention ne nécessite aucune installation supplémentaire dans les ports. Seul un logiciel spécifique doit être installé dans le système informatique de la capitainerie via une interface de la toile (web). Ce logiciel est interfacé avec le système de gestion existant. Connecté à une application mobile pour le plaisancier, le système est basé sur la détection de la position GPS des bateaux lorsqu’ils sortent ou rentrent dans le chenal d’accès au port et uniquement à cet endroit. Il n’y a donc pas de suivi permanent (« tracking ») du plaisancier.

Afin d’améliorer la précision de la localisation du bateau du matériel peut être ajouté sous forme de :

- capteurs embarqués

- embarqués avec puce GPS

- capteurs au niveau de l’emplacement (anneaux intelligents)

Une déclaration d’absence réalisée par un plaisancier est automatisée, réalise la mise à jour des places disponibilités et permet l’anticipation des départs. Aux escales, l’application affiche les places d’escale disponibles et les places de résidents, c’est-à-dire affectées à un navire, disponibles.

Avec le logiciel de la capitainerie, l’équipe du port peut:

- Visualiser en temps en réel la disponibilité (aujourd’hui sous forme de calendrier),

- Recevoir les déclarations d’absence automatisées afin d’anticiper les départs,

- Consulter les places disponibles pour une demande d’escale et

- Accéder aux statistiques.

L’application mobile à télécharger sur un terminal mobile communiquant (téléphone mobile, montre connectée ou tablette, par exemple) améliore les services aux plaisanciers, en leur fournissant des informations, la météo, des images de webcam et des actualités.

Les figures 1 et 2 illustrent des écrans affichés lors d’étapes de déclaration d’absence, avec cette application. La figure 3 représente un écran affiché pour changer de date ou d’heure de retour.

Avant de sortir le plaisancier peut consulter la météo et visualiser les webcams de la ville en temps réel. Il peut anticiper sa déclaration d’absence en 2 clics ou la déclarer à sa sortie. En escale, le plaisancier est aujourd’hui redirigé sur l’office de tourisme de la destination. Il peut prévenir d’un retour anticipé afin que sa capitainerie s’organise si la place a été relouée et qu’il trouve son emplacement libre à son arrivée.

Dans le cas où le mode de réalisation du dispositif selon l’invention comporte au moins un capteur, l’application mobile reste préférentielle car une interrogation du plaisancier en direct lors du départ permet d'anticiper la durée d'absence et donc la disponibilité de la place.

La figure 4 illustre différents modes de réalisation de la solution.

Les avantages de la mise en oeuvre de l’invention comportent, au niveau de la capitainerie, en termes opérationnels :

Visibilité en temps réel sur les emplacements disponibles Meilleure gestion des emplacements et du remplissage Automatisation des déclarations d’absence Anticipation des périodes d’absences

Amélioration de la communication avec les plaisanciers Sécurité.

Et, en termes financiers, l’augmentation du chiffre d’affaires par : Augmentation du volume d’escale

Optimisation de la grille tarifaire (Yield Management)

Statistiques:

Connaissance des taux de sorties et d’absences

Ratios précis de places disponibles par catégorie, par période

En terme de gestion des ressources humaines :

Affectation du personnel à des taches à forte valeur ajoutée

Réduction du nombre de saisonniers nécessaire

Les avantages de la mise en œuvre de l’invention comportent, au niveau des plaisanciers, en termes opérationnels :

Amélioration des services

Information avant une sortie

Escale: information destination

Déclaration d’absence simplifiée Sécurité: réception d’alertes (vol, zones dangereuses) Plaisance Responsable

Et en termes financiers :

Economie en libérant sa place

L’avantage d’anticipation des périodes d’absences permet de proposer des places de port en plus grand nombre, à n’importe quel moment, que ce soit ponctuellement pour les bateaux en escale ou pour des durées plus longues sur les places des bateaux qui partent plus longtemps.

Par exemple : si un bateau résident part de février à juillet et un second bateau résident de juin à octobre, le port dispose d’une place supplémentaire 9 mois sur 12, le reste du temps le bateau visiteur pouvant être mis à sec.

La capacité totale du port peut donc ainsi être augmentée, sans recourir à des extensions de la capacité du port, financièrement lourdes et de plus en plus aléatoires.

L’insertion de la Block Chain permet de motiver les plaisanciers à interagir de manière responsable en convertissant les sorties en points utilisables chez les partenaires dynamisant l’économie locale.

Concernant la détection de sortie de port d’un bateau, dans des modes de réalisation, on met en œuvre la technologie LoRa (acronyme de « long range »). Ses principaux avantages sont:

Longue portée

Basse consommation

Bas débit des réseaux

Aucun câblage

Géolocalisation sans GPS

Bidirectionnelle

Standard LoRa Wan

LoRa est un protocole radio utilisant aussi la bande 868 MHz. LoRaWAN est un standard, les objets Lorawan sont compatibles entre eux et avec les villes qui s’équipent en Lora (Bordeaux, Marseille, Nice, Montpellier, Paris). Une seule antenne pour gérer tous les besoins en objets connectés. Le protocole LoRa est bidirectionnel, c’est à dire que les objets peuvent être réveillés à la demande ce qui permet d’être moins gourmand en énergie. La géolocalisation sans GPS est très précise sur LoRa.

Concernant le capteur LoRa embarqué, il est compatible avec la norme IP66 pour un environnement maritime et protégé contre les UV. Il possède une autonomie de 3 ans. Une balise autonome permet la localisation et l’identification de passage. Elle possède une couverture allant jusqu’à 200 mètres.

Une antenne passerelle (« Gateway ») permet la remontée de l’information via un réseau de téléphonie mobile 3G multi-opérateurs vers le logiciel de la capitainerie. Cette antenne est autonome grâce au panneau solaire. Les données transmises sont sécurisées via un tunnel VPN-APN.

La figure 5 représente les balises LoRa déployées pour couvrir l’intégralité d’un plan d’eau portuaire. Quatre balises intérieures réalisent l’émission de signaux pour une localisation de zonage. Une balise de sortie réalise l’émission de signaux pour une détection de passage dans le chenal.

Chaque capteur réalise l’enregistrement du n° de la balise et l’heure. Il envoie l’information vers l’antenne. Les balise intérieure fonctionnent de manière périodique et la balise de sortie de manière spontanée.

En ce qui concerne le schéma de remontée de l’information :

- une balise (Zoner) émet des signaux (beacons) dans un rayon maximal de 200 mètres,

- un navire équipé d’un capteur (Tag) rentre dans la zone de la balise, reçoit le signal, renvoie une information contenant son N° Tag, N° balise de la zone entrée, N° balise de la dernière zone sortie, RTC (Date - Heure), Température vers l’antenne (Gateway),

- l’antenne (Gateway) remonte via un canal sécurisé APN-VPN de son modem 3G l’information sur les serveurs du prestataire de déploiement des balises, capteurs et gateways,

- l’information est automatiquement renvoyée sur les serveurs de l’exploitant de la solution via un Web service (API) entre les deux plateformes qui permet d’authentifier un N° de Tag à un plaisancier et d’afficher sa présence ou non dans le port à travers le logiciel capitainerie.

Périodiquement, une copie de l'historique de la semaine est envoyé par mail à la capitainerie.

Précision par l’association capteur - application mobile :

Un plaisancier équipé de l’application mobile qui sort du port avec son navire équipé d’un capteur reçoit alors un message (push) à sa sortie pour connaître sa date de retour. Un plaisancier qui est sur le bateau d’un autre plaisancier ne reçoit pas ce message push car il n’y a pas eu d’association App+tag pour valider la sortie du bon navire.

Concernant un évènement de traversée de zones (détection active), lorsqu’un navire change de zone (entrée ou sortie), la détection de changement de zone remonte automatiquement sous forme d’alarme.

Pour un évènement de validation de présence (détection passive), périodiquement les capteurs sont paramétrés pour confirmer leur présence dans la dernière zone connue.

En ce qui concerne les modes de réalisation avec solution embarquée avec Puce GPS, un schéma de remontée de l’information est le suivant :

- un navire équipé d’une balise GPS envoie périodique sa position GPS directement sur les serveurs de Synox,

- l’information est automatiquement renvoyée sur les serveurs de l’exploitant de la solution via un Web service (API) entre les deux plateformes qui permet d’authentifier un N° de balise GPS à un plaisancier et de traiter d’afficher la présence ou non du navire dans le port à travers le logiciel capitainerie,

- périodiquement chaque dimanche minuit une copie l'historique de la semaine est envoyé par mail à la capitainerie.

En ce qui concerne les modes de réalisation avec solution ponton ou anneau intelligent, le schéma de remontée de l’information est le suivant :

- un capteur est placé devant chaque emplacement au niveau du quai ou du ponton et sonde périodiquement la présence ou non d’un navire,

- l’information est envoyée à l’antenne (gateway) qui la renvoie automatiquement sur les serveurs de l’exploitant de la solution ce qui permet d’afficher la disponibilité ou l’absence d’un navire sur cet emplacement à travers le plan d’eau du logiciel capitainerie,

- périodiquement chaque dimanche minuit une copie l’historique de la semaine est envoyé par mail à la capitainerie.

Le capteur peut utiliser la technologie LoRa ou être un capteur à ultrasons étanche. On peut aussi créer un anneau intelligent sous forme de capteur de tension au niveau de l’anneau ou du taquet / bitte d’amarrage. Cette information est envoyée à l’antenne (gateway) qui la renvoie automatiquement sur les serveurs de l’exploitant de la solution, ce qui permet d’afficher la disponibilité ou l’absence d’un navire sur cet emplacement à travers le plan d’eau du logiciel capitainerie. Périodiquement chaque dimanche minuit une copie l’historique de la semaine est envoyé par mail à la capitainerie.

Concernant l’application plaisancier :

A/ En sortie du port (figure 6)

- 1^ère détection dans la zone de sortie, remontée dans le logiciel,

- 2^nde détection dans la zone de sortie, remontée dans le logiciel,

- calcul des deux points géographiques des détections indique la sortie.

Au niveau de la capitainerie cette détection déclenche

- l’affichage du plan d’eau avec plage de couleur orange sur emplacement. Cette couleur signifie une sortie en mer sans date de retour.

- un compte à rebours.

Une durée prédéterminée, par exemple 30 minutes, après avoir quitté le port, un message est envoyé à l’application du plaisancier associé, en mémoire, au capteur qui a été identifié comme quittant le port. Ce message prévient le propriétaire de la sortie du navire et lui demande la date de retour. La réponse simple du plaisancier se fait en deux clics.

Selon la réponse, le logiciel de la capitainerie réalise la libération automatique de la place pour l’escale du nombre de nuits d’absence déclaré. De plus, un crédit du nombre de nuits d’absence est déclaré dans le profil du plaisancier.

Côté Plaisancier:

Sélection de la période d’absence à modifier

Modification de la date retour de la période d’absence déclarée

Côté Capitainerie:

Affichage automatique de la nouvelle plage de disponibilité de l’emplacement pour escale

Mise à jour automatique du nombre de jours d’absence déclarés dans la fiche plaisancier

B/ En entrée dans un port d’escale (figure 7)

1) 1ère Détection dans la zone de sortie, remontée dans le logiciel

2) 2nde Détection dans la zone de sortie, remontée dans le logiciel

3) Calcul des deux points géographiques des détections = Entrée dans un port d’Escale

a) Envoi Push d’informations sur le port et la destination + « possibilité de réserver des services >>

b) SI le plaisancier a réservé une place d’escale et que la capitainerie l’a enregistré dans le logiciel ALORS :

i) Envoi du plan d’eau du port avec la place réservée ii) Après 5-10min Envoi Push d’informations sur le port et la destination + possibilité de réserver des services

C/ Sortie du port d’escale (figure 8)

1) 1ère Détection dans la zone de sortie, remontée dans le logiciel

2) 2nde Détection dans la zone de sortie, remontée dans le logiciel

3) Calcul des deux points géographiques des détections = Sortie du port d’Escale > Si dernier jour d’escale Alors Envoi Push pour notation générale de l’escale

4) Après réponse du plaisancier, réception de l’avis dans le logiciel capitainerie

D/ Détection d’un navire au large du port (figure 9)

Définition d’une zone au large perpendiculaire au port pour capter de nouveaux plaisanciers de passage

1) 1ère Détection dans la zone au large, remontée dans le logiciel

2) 2nde Détection dans la zone au large, remontée dans le logiciel

3) Calcul des deux points géographiques des détections = Passage au large à tribord du port de plaisance

a) Envoi Push d’informations sur le port et la destination + possibilité de réserver une place d’escale

E/ Retour au port d’attache (figure 10)

1) 1ère Détection dans la zone de sortie, remontée dans le logiciel

2) 2nde Détection dans la zone de sortie, remontée dans le logiciel

3) Calcul des deux points géographiques des détections: Entrée + Port d’attache = Retour Port d’attache

a) Affichage Plan d’eau : icône bateau sur l’emplacement = présence du navire dans le port

b) Push de retour ? « Bienvenue chez vous !>>...

Par ailleurs, l’application mobile plaisanciers propose de recevoir des alertes tirant d’eau dans les zones de bancs de sable ou d’entrées de port ou lorsque l’utilisateur entre dans une zone interdite au mouillage / sans réservoir à eaux noires.

Pour les modes de réalisation comportant des capteurs LoRa embarqués, il peut s’agir de TAG IP 66 pour environnements maritimes. Les Tag sont posés sur les bateaux à suivre. Plus le Tag est en vue (posé en évidence), plus il est souple de couvrir tous les cas, de tous les ports. La programmation de la fréquence de remontée des données se fait depuis une plateforme loT. Les Tags comportent une pile lithium qui peut potentiellement être remplacée (mais nécessite la dépose et l’ouverture complète du produit). Le niveau de pile remonte en pourcentage dans toutes les trames périodiques ; une alarme est émise en fin de vie.

Ils émettent périodiquement vers la/les Gateways, mais peuvent aussi émettre spontanément sous forme d’alarme sur évènement, comme le passage sous la couverture d’une balise configuré à cet effet.

Les balises autonomes permettent la localisation et/ou l’identification de passage. Balises autonomes émettant périodiquement des Beacons. La portée (« range >>) de couverture peut de régler de 2m à 200m environ. Au moins une balise est installée en en sortie de canal (sortie du port) et une en amont à l’intérieur pour déterminer le sens de passage.

Le Gateway est installé au niveau de la Capitainerie ou au niveau d’un ponton. Il comporte un boîter étanche, une batterie, un chargeur à panneau solaire et est configuré pour une pose sans intrusion. Les Gateways sont des points d’accès distant pouvant être utilisés pour atteindre les dispositifs (« devices ») et l’infrastructure en temps réel (reconfiguration, vérification, inventaire...).

Concernant la localisation et la remontée d’information périodique :

a. les Tags sont montés sur les bateaux

b. au moins une balise est installée en en sortie de canal (sortie du port) et une autre en amont à l’intérieur pour déterminer le sens de passage. L’installation peut être multipliée suivant la largeur du canal mais aussi les contraintes radios issues de l’intégration des Tags sur les bateaux. D’autres balises pourraient être installées dans le port lui-même pour proposer une macro localisation.

A chaque passage sous la zone d’une balise, le Tag enregistre l’identifiant de la balise et horodate cet évènement. Périodiquement, le Tag envoie les derniers évènements de Beacons périodiquement (typiquement toutes les 4H). Les Gateway peuvent être multiples (et itinérances possible). Si le bateau est loin en mer pendant cette phase d’émission, le Tag n’est pas acquitté et garde ces éléments non envoyés pour la prochaine émission.

Pour la remontée spontanée par alarme et périodique

c. Même infrastructure que ci-dessus 1, mais les balises de sortie de canal sont configurées pour que les Tags les détectant émettent une alarme spontanée à destination des Gateways. Comme ci-dessus, le positionnement d’une autre balise en amont du flux de sorti sera indiqué également dans cette alarme pour discriminer les bateaux entrant des bateaux sortants.

d. Dans ce cas, l’envoi périodique reste vrai, et permet potentiellement de confirmer les données reçues spontanément.

La plateforme de gestion de la connectivité et des objets fonctionne en mode SaaS (« software as a service ou logiciel en tant que service).

a. Plateformes de data management modulaires et évolutives, décloisonnement des flux entre les objets et les métiers.

b. Graphiques, diagrammes, cartographies... disposez de tableaux de bord dynamiques pour monitorer l’activité des bornes et compteurs de passages et visualiser les données qui sont remontées, réception d’alerte à atteinte de seuil.

c. Création de Widgets Spécifiques en fonction de la donnée que l’on souhaite voir apparaître et sous quelle forme

d. Stockage des données et accès à la plateforme loT en SaaS o Interfaçage des données de tracking des entrées et sorties des bateaux et flux de passage avec la plateforme de gestion o Stockage de toutes les données sans limite de temps o Accès sécurisé aux données

Pour le schéma de remontée de l’information

1. Une balise (Zoner) émet des signaux (beacons) dans un rayon maximal de 200 mètres.

2. Un navire équipé d’un capteur (Tag) rentre dans la zone de la balise, reçoit le signal, renvoie une information contenant son N° Tag, N° balise de la zone entrée, N° balise de la dernière zone sortie, RCT (Date - Heure), Température vers l’antenne (Gateway).

3. L’antenne (Gateway) remonte via un canal sécurisé APN-VPN de son modem 3G l’information sur les serveurs du prestataire de déploiement des balises, capteurs et gateways,

4. L’information est automatiquement renvoyée sur les serveurs de l’exploitant de la solution via un web service (API) entre les deux plateformes qui permet d’authentifier un N° de Tag à un plaisancier et d’afficher la présence ou non du navire dans le port à travers le logiciel capitainerie.

5. Périodiquement chaque dimanche minuit une copie l'historique de la semaine est envoyé par mail à la capitainerie.

6. Précision par l’association capteur - application mobile :

1. Un plaisancier équipé de l’application mobile qui sortirait du port avec son navire équipé d’un capteur recevrait alors un push à sa sortie pour connaître sa date de retour

2. Un plaisancier qui serait sur le bateau d’un autre plaisancier ne recevra pas ce push car il n’y aura pas eu d’association App+tag pour valider la sortie du bon navire.

Concernant la configuration, on aura uniquement le(s) zoneur(s) en entrée/sortie du port qui seront configurés en actif (mode alarme sur changement de zone), le reste des zoneurs seront en mode passif (on ne les verra que dans les trames de présence, s'il y a un changement de zone).

Evénement de Changement de zone (détection active)

Lorsqu’un navire sort d’une zone (ex : Zone n°0138743B) pour rentrer dans une autre zone (ex : Zone n°01387538) balisée alors il envoie une trame d’information automatiquement sous forme d’alarme suivante :

{ gateld: 0138A926, deviceld:013870C1, deviceType: TAG, frameType:ALARM, batteryLevel: 100, température : 25, rtc: 244198112, events:

[ {

rtc: 0, way: IN, zonerld: 01387538 }, {

rtc: 0, way: OUT, zonerld: 0138743B }

] }

Si le bateau vient du large et rentre au port et que le premier zoner est 0138743B, ce sera : events:

[ {

rtc: 0, way: IN, zonerld: 0138743B }

]

Evénement de Présence (détection passive)

Périodiquement les tags sont paramétrés pour envoyer leur position pour confirmer leur présence dans le port.

La trame PRESENCE_BIS est la seconde trame qui est envoyée immédiatement après la trame PRESENCE s'il y a trop de changements de zone dans celle-ci.

Voici un rappel de la structure de trame et les descriptifs :

Les champs « gateld », « deviceld >> et « zoneld >> sont les identifiants uniques des gateways, devices (en fonction du deviceType) et zoner.

« batteryLevel >> correspond au pourcentage restant de batterie du device (non présent dans la trame « PRESENCE_BIS >>, valeur = -1 ).

« température >> correspond à la température en °C relevée par le device (non présent dans les trames « PRESENCE >> et « PRESENCE_BIS >>, valeur = -1 ).

« rtc >> correspond au nombre de secondes depuis le 01/01/2010 à OOhOO, en fonction du type de trame :

« ALARM >> : moment où l’alerte est détectée « PRESENCE >> : moment du 1er évènement d’entrée ou sortie de zone « PRESENCE_BIS >> : Attention, le rtc n’est pas envoyé dans cette trame (valeur = -1 ), il faut se baser sur celui de la trame de présence « deviceType >> peut être :

« TAG >> pour un tag (fixé à un bateau) « ZONER >> pour un zoneur « UNKOWN >> si non identifié « frameType >> peut être :

« ALARM >> selon le « deviceType >> :

o « TAG >> pour une alerte d’entrée ou sortie de zone par un tag o « ZONER >> pour une alerte de dépassement de seuil de batterie (tous les 10%) « PRESENCE >> pour une trame récurrente de présence (« keep alive >> de 1h dans la configuration actuelle). Attention, cette trame peut contenir des entrées/sorties de zone déjà envoyées dans une alerte « PRESENCE_BIS >> pour la trame suivant la trame de présence, au cas où il y aurait plus de 26 zones traversées. Attention, le rtc n’est pas envoyé dans cette trame, il faut se baser sur celui de la trame de présence « UNKOWN >> si non identifié « events >> est un tableau listant les évènements d’entrée ou de sortie de zone par un tag (il n’y aura des évènements que si le deviceType est « TAG »).

« rtc >> dans un event correspond au nombre de secondes depuis le rtc de la trame.

« way >> dans un event correspond au sens, peut être :

« IN >> pour une entrée de zone « OUT >> pour une sortie de zone « UNKOWN >> si non identifié

Remarque : Si on a un event dont way=OUT et zonerld=00000000, cela signifie que le tag est sorti de la zone précédente où il était rentré.

Exemples de trames :

Trames de présence :

Trame de présence sans historique de changement de zone : {gateld:0138A926,deviceld:013870C8,deviceType:TAG,frameType:PRE SENCE,batteryLevel:100,temperature:-1 ,rtc:-1 ,events:[]}

Trame de présence avec une sortie de zone en historique :

{gateld:0138A926,deviceld:013870C1 ,deviceType:TAG,frameType:PRE SENCE,batteryLevel:99,temperature:1 ,rtc:245326087,events:[{rtc:0,way:OUT,zonerld:00000000}]}

Trame de présence avec une entrée de zone en historique :

{gateld:0138A926,deviceld:013870C1 ,deviceType:TAG,frameType:PRE SENCE,batteryLevel:99,temperature:1 ,rtc:245319370,events:[{rtc:0,way:IN,zonerld:01387538}]}

Trame de présence avec deux entrées de zone en historique :

{gateld:0138A926,deviceld:013870C1 ,deviceType:TAG,frameType:PRE SENCE,batteryLevel:99,temperature:1 ,rtc:244972642,events:[{rtc:0,way:IN,zonerld:0138743B},{rtc:488,way :IN,zonerld:01387538}]}

Trames d'alarme de TAG avec une sortie et une entrée de zones :

{gateld:0138A926,deviceld:013870C1,deviceType:TAG,frameType:ALA RM,batteryLevel:99,temperature:24,rtc:244973046,events:[{rtc:0,way:IN, zonerld:01387538},{rtc:0,way:OUT,zonerld:0138743B}]} {gateld:0138A926,deviceld:013870DD,deviceType:TAG,frameType:ALA RM,batteryLevel:100,temperature:28,rtc:244995328,events:[{rtc:0,way:IN ,zonerld:01387538}, {rtc:0,way:OUT,zonerld:0138743B}]}

Trame d'alarme de ZONER sur dépassement de seuil de batterie : {gateld:0138A926,deviceld:01387538, deviceType:ZONER,frameType:AL ARM,batteryLevel:90,temperature:-1,rtc:244995328,events:[]}

Trame de présence bis (suivant la trame de présence qui contient plus de 26 changements de zone) :

Grâce à la détection par zone(s) balisée(s), et éventuellement des capteurs embarqués à bord des navires, la présente invention résout efficacement les problèmes de détection de places libres et d’entrées et sorties des bateaux du port.

La détection d’une zone balisée effectuée sur un port se fait :

- Soit par détection de passage dans le chenal (coordonnées géolocalisées),

- Soit par détection d’absence d’un ensemble de cellules Lora couvrant l’ensemble du port surveillé,

- Soit par détection d’absence d’un ensemble de cellules RFID couvrant chaque emplacement du port surveillé

Puis, il y a une remontée des informations centralisées.

Il y a remontée de l’information puis interrogation du plaisancier par le biais du logiciel embarqué (application mobile) lorsqu’une sortie est enregistrée via un capteur ou l’application par géolocalisation dans la zone de sortie, afin de connaître la date retour du plaisancier.

Claims

REVENDICATIONS

1. Dispositif de détection d’entrée, de présence ou de sortie d’un véhicule d’une zone surveillée, comportant :

a) des moyens de :

- détection de passage dans le chenal (coordonnées géolocalisées),

- détection d’absence d’un ensemble de cellules Lora couvrant l’ensemble du port surveillé et/ou

- détection d’absence d’un ensemble de cellules couvrant chaque emplacement de la zone surveillée ;

b) des moyens de remontée des informations centralisées et

c) des moyens d’interrogation d’un utilisateur du véhicule détecté.
2. Dispositif selon la revendication 1, dans lequel la détection de passage du bateau est effectué par détection de l’absence du bateau d’un ensemble de cellules RFID, LORA ou GSM.
3. Procédé de détection d’entrée, de présence ou de sortie d’un véhicule d’une zone surveillée, comportant :

a) une étape de :

- détection de passage dans le chenal (coordonnées géolocalisées),

- détection d’absence d’un ensemble de cellules Lora couvrant l’ensemble du port surveillé et/ou

- détection d’absence d’un ensemble de cellules couvrant chaque emplacement de la zone surveillée ;

b) une étape de remontée des informations centralisées et

c) une étape d’interrogation d’un utilisateur du véhicule détecté.
4. Procédé selon la revendication 3, dans lequel la détection de passage du bateau est effectué par détection de l’absence du bateau d’un ensemble de cellules RFID, LORA ou GSM.