Communication tactique
Date: 06 janvier 2018 à 15:32:00 Sujet: Tactique et Pratique
Si la lutte contre les feux de locaux est facilitée par quelques connaissances sur les phénomènes et sur une bonne connaissance de l'usage des lances, il n'en reste pas moins que c'est le travail d'équipe qui permet de venir à bout de ce type d'incendie. Or qui dit travail d'équipe dit communication. En effet, le feu étant un phénomène évolutif, il est pratiquement impossible de définir une tactique et ensuite de la suivre aveuglement sans s'occuper de cette évolution. Il faut donc communiquer, afin que chaque observation puisse remonter rapidement au commandement, qui, en fonction des informations, va pouvoir modifier la tactique initiale et l'adapter aux circonstances.
Reste à savoir comment recevoir ces informations, comment les traiter et comment les transmettre aux intervenants.
La solution la plus simple, c'est évidement la radio. Mais les systèmes sont généralement assez coûteux et surtout ils ne permettent que la transmission audio.
Nous avons eu la chance de découvrir un autre système, particulièrement prometteur. A l'état de prototype fonctionnel, ce système a comme nom de code "Chappe", du nom de l'inventeur du sémaphore, connu comme ayant été le premier entrepreneur dans le domaine des télécommunications.
Important: bien que nous ayons vu le système fonctionner, transmettre, recevoir etc... il n'y aura aucune photo dans cet article. Cela vient du fait que dans l'état actuel le modules sont "ouverts" et la parte électronique est donc visible. Lors des prochains tests, des photos pourront sans doute être diffusées.
Le but cCest de permettre la communication au niveau tactique entre un chef et un ensemble de sapeurs-pompiers, avec usage de tablette Android associée à des modules avec caméra, micro, capteurs diverss, le tout pour un prix extrêmement bas. Compter en effet moins de 1.000 Euros pour équiper 6 binômes! L'équipe développant actuellement ce système est composée de développeurs informatiques et d'électroniciens, entourés de conseillers techniques. Tous sont sapeurs-pompiers professionnels ou volontaires ce qui fait qu'ils peuvent construire un système et le tester, en sachant ce qui est nécessaire.
Description Le système est composé de 3 parties; - Une application Android, utilisée par le Chef. Idéalement une tablette d'assez grande taille est nécessaire. L'essai auquel nous avons assisté était réalisé sur une Samsung Galaxy TAB E donc une tablette de 9,6 pouce ce qui semble être la taille idéal pour ce genre d'application. - Un module intermédiaire. C'est un petit boitier d'environ 4x5cm et de 2cm d'épaisseur que le chef porte sur lui. Il réalise le transfert entre la tablette et les modules des binômes. - Les modules des Sapeurs-Pompiers. Leur taille, leur poids et leurs possibilités sont variables, mais ces boitiers sont toujours très petits. Certains ne servent qu'à la communication de messages, d'autres à la transmission radio, d'autres peuvent transmettre des températures, des photos etc...
Concernant le boitier du chef, nous n'avons pas eu de détail, mais son usage semble venir du fait que la tablette ne comporte que 3 moyens de communications: GSM, Wifi et Bluetooth. Or le GSM n'est pas utilisé dans le cas présent et le Wifi et le Bluetooth ne possèdent pas de portée suffisante. On peut donc penser que les modules des sapeurs-pompiers communiquent à longue portée avec le boitier du chef et que celui-ci transcrive les données pour la tablette, en Bluetooth.
La portée Le système a été testé en milieu urbain. La portée est d'environ 100 à 200m dans les bâtiments, portes et fenêtres fermées. En extérieur la portée augmente mais elle ne dépasse pas 500m. Au delà, le débit de transmission faiblit et le système perd de son intérêt. C'est donc un système principalement fait pour les feux de locaux.
Comment ça marche? Au départ le chef active son boitier et sa tablette. Quand un sapeur-pompier active son module, celui-ci communique avec la tablette du chef et c'est cette tablette qui donne un identifiant au boitier. En fait les boitiers ne possèdent aucun identifiant propre. Le système est étonnant mais particulièrement malin: dans beaucoup de systèmes de communication, chaque "émetteur" possède un code figé en usine ou réglé par un bouton. Là, les boitiers ne possèdent aucun code: ils s'allument, envoient un message au boitier du chef et c'est le boitier du chef qui donne le code au module. Concrètement si un module tombe en panne, est cassé etc... on le remplace par une autre module, sans se soucier d'une quelconque numérotation. La maintenance est donc facilitée.
A chaque fois que l'application du chef reçoit une demande d'un module qui n'est pas encore identifié, elle ajoute ce module dans sa liste et lui envoi le code unique que ce module utilisera durant toute l'intervention. En retour de ce code, le module envoi au chef la liste de ses possibilités: réception radio, transmission radio, détection de mouvement, prise de photo etc... L'application du chef change donc son interface pour chaque module. Ainsi le chef pourra par exemple recevoir une photo d'un module mais pas d'un autre etc... Le système est complètement évolutif et le réseau peut donc être constitués de modules ayant des capacités différentes les uns des autres.
En ce qui concerne le nombre de modules, ce nombre est... illimité! Du moins en théorie. En fait rien dans la partie électronique ne bloque le nombre de modules. On pourrait donc imaginer 10.000 modules actifs en même temps sur la même opération. Une limite "logicielle" a été mise en place du fait qu'un chef ne peut évidement pas gérer un nombre infini de binômes. Cette limite est de 1 chef et 50 binômes pouvant appartenir à 10 groupes. Le chef peut communiquer de 3 façons: soit avec un module spécifique (il clique dessus dans sa liste), soit vers tous les modules en une fois (message d'évacuation par exemple), soit avec un groupe, auquel vont appartenir certains modules. C'est le chef qui, à partir de sa tablette, "inscrit" les modules dans les groupes et les en retire. Le système gère 10 groupes et chaque module peut appartenir à l'un ou l'autre de ces 10 groupes ou à plusieurs groupes en même temps. On peut ainsi imaginer un feu impliquant 2 habitations. Le chef va donc définir deux groupes ("maison 1" et "maison 2" par exemple) et y inscrire les sapeurs-pompiers correspondants. En même temps, il peut créer un groupe "étage maison 1" dans lequel il mettra les sapeurs-pompiers qui sont à l'étage de la maison 1. Par ce principe, les sapeurs-pompiers qui sont à l'étage de la maison 1 appartiendront à 2 groupes simultanément: celui de la maison 1 et celui de l'étage de la maison 1. Au niveau des sapeurs-pompiers, aucun interaction n'est nécessaire: c'est le chef qui crée les groupes et qui envoient les "invitations", le boitier du sapeur-pompier répondant tout seul aux demandes.
Les options actuellement disponibles Actuellement les développeurs disposent de 3 boitiers pour les sapeurs-pompiers, un boitier intermédiaire (pour le chef) et de l'application Android. Les boitiers possèdent un écran sur lequel s'affiche un cours texte envoyé par le chef. Ils disposent également d'un système de communication audio. La communication est géré par un protocole logiciel très évolutif. Il permet l'envoi de tout type de données. Dans l'état actuel les possibilités sont les suivantes: Du chef vers les modules - envoyer un message texte au module, message qui sera affiché sur l'écran. - envoyer un ordre d'évacuation. Cela affiche un message sur le module et déclenche une alarme sonore - envoyer une alarme relative au temps restant estimé en fonction de la consommation d'air. 3 niveaux de message, chacun avec un texte et une alarme. Niveau 1: il reste certainement assez d'air, mais il faut penser à revenir, niveau 2 il ne fait plus "penser" à revenir, il faut revenir! Niveau 3, il faut se dépêcher de revenir. - envoyer un message audio (donc comme avec une radio) - déclencher l'enregistrement audio. Le chef peut ouvrir le micro du module afin d'écouter ce qui se passe. Ceci est particulièrement utile dans le cas de la recherche d'un sapeur-pompier inconscient. L'équipe de recherche peut faire du bruit et le chef peut indiquer si ce bruit est proche ou non du sapeur-pompier recherché. - déclencher ou arrêter la balise sonore de détresse. Le chef peut déclencher la balise du sapeurs-pompiers mais il peut aussi l'arrêter. Ceci permet d'économiser les piles et ceci peut permettre également d'utiliser le micro du module. On peut en effet imaginer un sapeur-pompier pris de convulsion ce qui empêcherait le déclenchement de la balise de détection d'absence de mouvement. - déclencher l'appareil photo du module. Une fois la photo prise, celle-ci est transmise à la tablette.
Des sapeurs-pompiers vers le Chef - Prise de photo pour envoi au chef (sachant que le chef peut lui-même déclencher la photo) - Transmission audio (type radio) - Appel au secours "manuel" donc le sapeur-pompier fait un "mayday" - Appel au secours automatique suite à non détection de mouvement. Comme avec les "homme mort" d'ARI, une première alarme se déclenche et si aucun mouvement n'est détecté, l'alarme augmente puis le module prévient le chef.
Un détail: l'écran qui est sur les modules, n'est pas un écran "texte" mais un écran graphique. Le chef peut donc envoyer du texte, mais aussi des dessins.
Ce qui semble difficile, voir impossible... Les essais de diverses autres options se poursuivent mais certaines semblent difficiles à mettre en oeuvre. La transmission vidéo. Elle nécessité un débit très largement supérieur à ce que le réseau peut supporter. C'est pour cela que dans l'état actuel l'équipe se focalise sur les photos. Gestion simultanée de caméra "normale" et de caméra thermique. Là le problème c'est celui de l'emplacement. Actuellement la caméra est sur le torse de la personne et pas sur le casque. S'il faut mettre 2 caméras, cela risque de faire un gros boitier. Affichage "tête haute". Là encore, c'est un problème purement mécanique. Nous avons en effet assisté à une démonstration d'affichage des messages directement sur la "vitre" de l'ARI. Si techniquement "ça marche", les ingénieurs nous ont fait part de 2 problèmes: 1) la vitre de l'ARI est incurvée. Donc si on affiche les données comme sur un écran, tout l'affichage se trouve déformé par cette courbure. 2) le projecteur doit se trouver dans le masque de l'ARI sinon il sera détruit par la chaleur. Or l'espace disponible est très faible et en plus l'équipe ne veut pas être obligé de créer un masque spécifique.
L'équipe travail sur ces quelques problèmes mais même si elle n'arrive pas à les résoudre, le résultat est déjà assez fabuleux.
Le travail actuel L'équipe travaille en plusieurs sous-équipes sur les éléments suivants: Réaliser le circuit imprimé des modules afin de mettre ceux-ci dans de véritables boitiers et non plus avec des fils qui dépassent. Optimiser la compression des images afin de diminuer le temps de transmission mais surtout afin de pouvoir renvoyer des photos aux modules. L'idée c'est qu'un binôme peut progresser, passer devant un élément particulier, le prendre en photo puis envoyer la photo au chef. Celui-ci pourra alors renvoyer cette photo au second binôme engagé par exemple pour lui dire "Lorsque vous verrez ça, prenez la porte qui sera à droite".
D'autres éléments sont également prévus comme un système de gestion de pompe des engins, utilisant le même protocole de communication et donc envoyant en temps réel à la tablette du chef, les indications sur le débit, la quantité d'eau restante etc...
Conclusion Le développement n'est pas terminé, mais force est de constater qu'il est bien avancé. Nous ne sommes déjà plus dans des délires comme ceux que l'on voit passer sur internet avec des équipements de science-fiction.
|
|