Nous voulons créer une planche de surf connectée, proposant des services météorologiques et sécuritaire.

• TURCHINI Marie-Catherine (IAM) : turchini@polytech.unice.fr
• BOURGEOIS Benjamin (IAM) : bbourgeo@polytech.unice.fr
• MICHEL Alain (IFTS) : alainmichel08@gmail.com
• BOHL Gautier (IFTS) : gautier.bohl@orange.fr

Alors qu’il est en train de surfer, un phénomène météorologique dangereux approche. L’information est retransmise au surfeur à l’aide d’une LED et/ou d’un dispositif vibrant et/ou un signal sonore, incitant le surfeur à arrêter son activité.

Alors qu’il est en train de surfer, un phénomène naturel dangereux vient de se produire. L’alerte est transmise au surfeur qui est vivement incité à se retirer (cf Tsunami).

Alerte aux requins. L'alerte peut tout aussi bien provenir d'un service externe comme d'un surfeur. A cette fin, les surfeurs dispose d'un bouton qui leur permettra d'envoyer l'alerte.

Détection des conditions météorologiques et envoi d’alertes au surfeur chez lui :

• Conditions optimales
• Conditions changeantes
• Conditions défavorables

Après une chute sans remontée sur la planche est déclenché un système de secours à la personne :

1. Recherche des surfeurs aux alentours pour porter secours (disposant de l’objet)
2. Envoi d’une alerte au poste de secours
3. Envoi d’une alerte aux pompiers

Dégradation/Rétablissement de la qualité de l’eau, envoi d’une alerte.

Un surfeur détecte un bon spot ou une anomalie et peut transmettre l’information.

Nous faisons le choix de créer une planche de surf ou de bodyboard aux dimensions réduites, afin d'obtenir non seulement un objet réaliste mais également un élément pouvant venir se greffer à n'importe quel type de planche et demeurant toujours fonctionnel.

Pour l'aspect visuel de l'objet envisagé voici un ensemble d'images qui ont guidé nos collaborateurs de l'Université de Reims :

Une version planche de surf avait aussi été envisagée. Cependant la solution fut rejeté par nos collaborateurs pour des raisons évidentes de réalisation. 3 images illustrant cette proposition figurent aux adresses suivantes pour ne pas surcharger la présente page :

• http://goo.gl/u5lnZn
• http://goo.gl/Lh5mxh
• http://goo.gl/4aZxD1

Voici quelques images du travail réalisé par nos collaborateurs de l'Université de Reims sur la conception 3D de l'objet :

Le fichier de CAO est disponible à l'adresse suivante : http://c.sdbx.co/1z0XGwu

Un schéma étant bien souvent plus parlant que de simples mots, voici une description des différents emplacements et quel matériel ils viendront abriter :

A des fins de test nos collaborateurs ont effectué une première découpe de l'objet communiquant. L'image ci-dessous présente le résultat de ces premières étapes de conception.

- Phidget

- Ensemble de LED

- Bracelet possédant un vibreur

- Capteur de pression pour la planche

- Wi-Fi

Une extension possible serait l'ajout d'un bloc permettant l'insertion d'une carte SIM, afin de pouvoir utiliser le réseau GSM en mer. Notre preuve de concept

- LED : signaler une nouvelle notification au surfeur. Elles peuvent être soit d'informations comme la LED orange qui s'allumera en cas de temps peu favorable mais sans risques, soit d'alerte, elles sont alors rouges et signale au surfeur un danger immédiat.

(Note : affichage des informations avec les LED et un motif par transparence/finesse de la matière)

- Le surfeur possède également un vibreur afin de recevoir les notifications (les LED n'étant pas toujours visibles à contre-jour).

- Le capteur pression intégrer à la planche capte la présence du surfeur, si la pression devient nulle ou quasi-nulle cela signifie que le sportif est tombé à l'eau. Si la durée au cours de laquelle la pression est trop faible dépasse un certain seuil, alors un nouvelle alerte est créée.

https://docs.google.com/spreadsheet/ccc?key=0AuY9JyjKXRY0dHlzcjBSazM2WWZqUzNBa2cwSGV0LUE&usp=sharing#gid=0

Description de l'interface du périphérique

L'objet embarque le minimum de l'intelligence, à savoir le traitement d'une donnée basique pouvant potentiellement engendrer l'allumage d'une LED ou du vibreur. Ainsi, côté réception notre Phidget peut :

• Recevoir le résultat du web service météo :
  • 0 : rien à signaler, rien ne s'allume ;
  • 1 : le temps n'est pas optimal, le surfeur doit se méfier. La LED orange s'allume ;
  • 2 : une alerte météo est levée en raison de pluie, d'un vent trop fort ou d'une pression très basse. La LED rouge s'allume et le vibreur s'active ;
  • tsunami : le surfeur n'est pas en sécurité, comme pour une alerte météo de niveau 2, le vibreur s'active et la LED tsunami s'allume également.
• Recevoir le résultat du web service de chute d'un surfeur (boolean true/false) : la LED rouge d'aide à un surfeur s'allume et le vibreur s'active, indiquant la chute de celui-ci dans un périmètre très proche.
• Recevoir le résultat du web service d'alerte aux requins (boolean true/false) : la LED rouge d'alerte requin s'allume et le vibreur s'active, indiquant qu'un requin a été signalé dans un périmètre de quelques kilomètres maximum.

Mais il peut également :

• Émettre une alerte requin, suite à l'appui sur le bouton prévu à cet effet ;
• Émettre une alerte de chute, si le capteur détecte une absence trop longue du surfeur sur sa planche.

Intégration Bluetooth

Actuellement, la récupération de l'alerte chute d'un surfeur se fait en récupérant la position GPS du surfeur, et le web service a pour rôle de détecter s'il est suffisamment proche d'un autre surfeur en détresse pour pouvoir l'aider. Une extension possible aurait été d'intégrer les dongle Bluetooth à la planche, et de s'en servir afin de détecter la distance avec d'autres surfeurs, équivalent au principe des positions GPS. Cette fonctionnalité était à l'origine prévue d'être réalisée, mais pour des raisons de temps seule la solution par positions GPS n'a été réalisée.

• Embarqué dans l'objet
  • WeatherBeanPhidget.dll : contient les fonctions permettant d'émettre les évènements d'allumage ou extinction des LED météo en fonction du niveau d'alerte reçu du web services (0/1/2). Cela permet d'abonner les LED orange et rouges aux événements leur correspondant plutôt que d'effectuer un traitement de l'indice d'alerte par le biais de composants ;
  • PhidgetContainer.wcc : le fichier container embarqué la description des réceptions/émissions possibles faites dans les paragraphes précédents.

• Partie locale
  • ConnectedWaveBeans.dll
    • WeatherBean : contient les appels (GET) au web service de météo et d'alerte tsunami
    • SharkBean : contient les appels (GET et POST) au web service d'alerte requin
    • SurferFallBean : contient les appels (GET et POST) au web service d'alerte de chute d'un surfeur
  • LocalContainer.wcc

• Liens local/embarqué : ils s'effectuent en dehors de la Phidget, au sein de l'orchestrateur, contenu dans le fichier “LocalContainer.wcc”. Il s'agit là de faire le lien entre les connexions au web services mis en place et le containeur embarqué sur la carte, chargé du traitement de ces résultats (allumage/extinction des LED/vibreur).

Le schéma situé dans la partie suivante résume l'ensemble de l'architecture implémentée.

L'objet n'embarque que l'intelligence pure de traitement de l'information, engendrant ainsi les comportements nécessaires pour les composants électroniques, rien de plus. L'orchestrateur est quant à lui en charge du lien avec les web services, il fait dont le lien entre la partie matérielle et logicielle. C'est au sein de celui-ci que l'on retrouve les beans, contenant les URL au web services ainsi que les possibles conversions de format. Le but étant bien sûr d'envoyer la donnée la plus légère et simple possible, de telle sorte que la Phidget n'ait aucun autre traitement à faire que l'envoi au composant concerné.

Les web services sont une partie externe à SharpDevelop, tournant pour notre preuve de concept en local et décomposé en plusieurs sous-services :

• localhost:8080/weather/lat/lon
  • Fonction GET : récupération de la météo (indice 0/1/2) par le biais de l'API http://api.openweathermap.org/, et analyse de certains paramètres essentiels nous permettant de juger s'il s'agit d'un bon temps (alerte niveau 0), d'une météo moyennement favorable (alerte niveau 1) ou bien d'une météo dangereuse pour le surfer (alerte niveau 2) ;
  • /tsunami/lat/lon : fonction GET d'un boolean indiquant s'il y a une alerte tsunami, en fonction des coordonnées GPS passées en paramètre ;
• localhost:8080/shark/lat/lon
  • Fonction GET d'un boolean indiquant s'il y a une alerte requin, en fonction des coordonnées GPS passées en paramètre ;
  • Fonction POST : crée une nouvelle alerte pour les coordonnées passées en paramètre.
• localhost:8080/fall/lat/lon
  • Fonction GET d'un boolean indiquant s'il y a une alerte chute d'un surfeur, en fonction des coordonnées GPS passées en paramètre ;
  • Fonction POST : crée une nouvelle alerte pour les coordonnées passées en paramètre.

Les web services auraient pu être programmé en C# et contenu dans l'orchestrateur, cependant, en raison d'un choix initial différent de cette architecture, nous avions déjà crée les services de telles sortes, en Java et hébergés sur un serveur Tomee. Afin de ne pas perdre du temps à remettre en place des web services, cette partie n'a pas été refaite, mais aurait très bien pu l'être.

• Le projet ConnectedWaveWS : projet Maven contenant les web services ;
• Projet SharpDevelop local : projet contenant les Beans et le containeur local ;
• Projet SharpDevelop embarqué : contient la DLL de transformation des résultats des web services en alertes destinées au LED, ainsi que le fichier contenant le comportement embarqué de la Phidget.

L'ensemble des instructions pour le fonctionnement de la planche sont contenues dans la dernière catégorie de cette page.

Le schéma ci-dessous résume l'ensemble de l'architecture implémentée pour notre planche de surf connectée :

== Extension ajoutée au cours de l'examen

Dans le cadre de l'examen nous avons rajouté la possibilité de supprimer des alertes directement depuis l'orchestrateur. A cela s'ajoutent deux services de suppression des alertes : un pour la suppression des alertes requins et l'autre pour la suppression des alertes de chute d'un surfeur. Ces appels sont déclenchés grâce à des boutons dans l'orchestrateur.

Une possible évolution serait d'ajouter une application mobile qui contrôlerait ces appels aux services de suppression en interagissant avec l'orchestrateur.

Waiting for the object…

1. First, you have to launch the web services server, in the folder “/ConnectedWaveWS” (at the file pom.xml level), using the command :

mvn clean install tomee:run

1. Then, you have to turn on the Phidget. The container, in the folder “/root/SharpWCompContainerMonoLinux/”, is automatically launched during the boot, thanks to the command :

mono ContainerMonoLinux.exe -r Beans -l PhidgetContainer.wcc -n connectedwave

contained in /etc/rc.local file, so, you don't have to launch it ;

1. Finally, you have to launch the local part :
   1. Open Sharp Develop software ;
   2. Import the file “LocalContainer.wcc” in a new container file ;
   3. Create a new UPnP Wizard Proxy selecting “connectedwave_Functionnal” device in the list and add it into the container ;
   4. Make the mapping with the UPnP Proxy :
      1. Link from SharkBean to UPnP Proxy : AlertSharkBoolChanged to receiveSharkWSresultBool
      2. Link from SurferFallBean to UPnP Proxy : AlertFallBoolChanged to receiveSurferFallWSresultBool
      3. Link from WeatherBean to UPnP Proxy : AlertStringChanged to receiveWeatherWSresultString
      4. Link from WeatherBean to UPnP Proxy : AlertTsunamiBoolChanged to receiveTsunamiWSresultBool
      5. Link from UPnP Proxy to SharkBean : sharkButtonClickEvent to connectToSharkWSpost()
      6. Link from UPnP Proxy to SurferFallBean : fallSensorAlertEvent to connectToFallWSpost()
   5. Set the timer parameter “Started” to “True”

The final schema will look like the following:

Here are the source files : ocs_g1_connectedwave.zip