Differences

This shows you the differences between two versions of the page.

--- 2014_2015:s3:etudedecas:notespedagogiques [2014/08/26 11:50] – created blay
+++ 2014_2015:s3:etudedecas:notespedagogiques [2014/08/27 14:56] (current) – [Consommation Variante] blay
@@ Line 18: / Line 18: @@
 ==== Consommation ====
+  - Attention besoin d'identifier les voitures pour le gestionnaire de flottes de voiture
+  - il faut caracteriser le type d'energie par voiture essence ou hybride
   - On ne sait pas vraiment comment gérer la consommation moyenne sur route, celle en fonction de la vitesse et celle en fonction d'une conduite écolo. On peut peutre calculer les 3 et donc affiner les US avec cela.
   - Attention à ne pas omettre la sécurité dans cet exemple, tout le monde ne doit pas avoir accès à toutes les informations.
@@ Line 26: / Line 28: @@
 ==== Consommation Variante ====
- Le système précédent vise à être vendu. Pour cela nous souhaitons développer un [[http://en.wikipedia.org/wiki/Software_ecosystem|écosystème]] qui permettent à des communautés d'usagers de saisir les informations nécessaires à son fonctionnement, tel que par exemple
+  *    Pas contente de celui-ci, il est bien trop flou...
-     * permettre à un constructeur automobile de saisir les données de consommation de ses véhicules,
-     * à un usager de s'enregistrer dans notre système pour obtenir des informations sur la consommation de ses voitures
-     *  à un usager d'obtenir des données statistiques sur la consommation de ses voiture,
-     * à un expert de confronter les données obtenues des usagers avec celles des constructeurs,
-     * aux usagers de consulter les statistiques sur les modèles de voitures,
-     * ...
-A terme, on peut imaginer que des producteurs de capteurs
 ==== Parcours ====
-Nos usagers doivent pouvoir calculer une route pour se rendre d'un point à un autre. Des responsables de l'urbanisme enregistre des points (Dept Info IUT Nice, Gare Saint Augustin, Dept Info Sophia) avec ses coordonnées GPS et des tronçons entre ces points. Ils caractérisent les tronçons en terme de "ville", "autoroute à péage", "montagne"... Des internautes peuvent associer différentes informations propres à chaque tronçon telles que "route étroite", "inondable", "attention aux coups de vents"...  Un usager peut alors obtenir les routes permettant de relier deux points avec des informations complémentaires comme la distance à parcourir, les natures de la route (autoroute+ montagne) et par tronçon les informations laissées par les internautes. Un usager doit pouvoir visualiser une route sur une carte.
-         * corrections:
              * Attention, il faut peut etre leur donner un algo de calcul de graphes (je vois avec Leo)
              * La visualisation est probablement pas dans le sujet sauf de regarder à se connecter à googlemap... si j'ai le temps.
-             * Pour l'instant je ne dis rien sur le fait que la "portion" de route est en ville ou de l'autoroute... a mon avis c'est indispensable mais je crois que c'est à eux de s'en rendre compte, en pensant à l'intégration. J'ai mis des infos mais ils doivent défricher pour rassembler les infos..
+             * Pour l'instant je ne dis rien sur le fait que la "portion" de route est en ville ou de l'autoroute... a mon avis c'est indispensable mais je crois que c'est à eux de s'en rendre compte, en pensant
-             * Il faut aussi prévoir de saisir des tronçons sinon on ne fait rien..Là c'est donc une US ou UC à définir.
-             * Pour COO on a là une jolie interface graphique. On le fera peut etre d'office pour tous les groupes
              * Je ne dis rien sur les unités des distances mais sans le préciser on ne pourra pas se connecter aux UC sur la consommation.
 ==== Trafic ====
-Il doit être possible à un automobiliste d'obtenir des informations sur le trafic routier et à un ensemble de capteurs de mémoriser les informations sur le trafic. Les informations qui nous intéressent sur un tronçon sont :
-    * le débit: (([[http://fr.wikipedia.org/wiki/Circulation_routi%C3%A8re|On mesure le débit de circulation en comptant le nombre de véhicules pendant une période de temps]]))
-    *  le temps de parcours (tp) qui correspond à une moyenne du temps passé par les véhicules pour franchir un tronçon.
-Ces informations peuvent être obtenues à partir de capteurs associés à la route, accessibles sur des sites distants comme googleMaps (http://www.memoclic.com/624-google-maps/15236-comment-fonctionne-trafic-google-maps.html) ou Escota, ou basé sur les données émises par les véhicules de notre système.
-Nous cherchons à avoir des informations :
-    *  courantes  : Un automobiliste qui demande le débit ou le temps de parcours courant d'un tronçon sera automatiquement dirigé vers le "bon" service qui lui donnera l'information;
-    * moyennées :  (nombre de vehicules/minutes qui passent journalièrement en un point).  Les données courantes sont automatiquement mémorisées. Les experts doivent pouvoir préciser la fréquence de questionnement des capteurs et la plage utilisée pour calculer la fréquentation.
-    * Il peut également être intéressant d'utiliser/enregistrer le débit et le temps de parcours en fonction de l'heure, des jours de la semaine et de la période de l'année. Un expert peut alors demander à visualiser sur un graphe l'évolution du débit pour un temps donné (aujourd'hui, le 25 décembre) ou en moyenne  à: une heure donnée (à 10h), une journée (aujourd'hui, ou les lundis), la semaine, sur plusieurs mois. L'objectif est de lui permettre d'identifier par exemple, l'autoroute est bien plus embouteillée le mardi matin.
-<html>
-<!--         * nombre de voies
-         * la direction
-         * la longueur (cf. article 3).
---!>
-</html>
-         * corrections:
              * Le vocabulaire est différent du précédent ce qui devrait poser des pbmes d'intégration... Je laisse
              * J'ai simplifié finalement viré le nombre de voies, les vitesses etc...
 ==== Communication ====
- Certains véhicules/automobilistes  ((dans cet exemple, les acteurs sont souvent les capteurs dans les véhicules que nous assimilons au véhicule lui-même)) doivent pouvoir recevoir et émettre des messages.  Voici quelques exemples basés sur ce principe et qui doivent être mis en oeuvre.
-  * Un véhicule en panne (à l'arrêt et problème détecté par le système central de la voiture) enverra automatiquement vers le serveur central un message  qui précisera : le lieu, la position sur la route (voie). Tous les véhicules abonnés au service et dans la zone de la panne seront automatiquement prévenus via des écrans dédiés dans la voiture. Si la panne a lieu sur une autoroute, le service de dépannage et de voiries sont également automatiquement prévenus.
-  * Tous les messages correspondant à un évènement localisé sont automatiquement "annulés" lorsque le véhicule sort de la zone correspondant au message.
+J'ai peur qu'il soit difficile...
-  * En cas d'accident (choc important détecté ou pression d'un bouton d'alerte), le véhicule signale l'accident. En réponse, les services de secours sont automatiquement prévenus et le système tente une prise de contact avec le véhicule accidenté si un numéro de téléphone lui est associé. Les véhicules à proximité sont également contactés en demandant des informations et en proposant une connexion téléphonique avec les services de secours dépêchés. L'automobiliste peut alors accepter de répondre à la demande. Dès que les informations sont considérées comme acquises par les services de secours, le message de demande d'information est "annulé". Un message est envoyé à toutes les voitures dans le secteur pour les notifier de l'accident. Ces notifications se font vers tous les véhicules qui rentrent dans la zone. Par la suite, les services idoines peuvent émettre de nouveaux messages comme : route fermée, circulation sur une voie, fin de l'accident.... Suite au signalement d'une fin d'accident, les voitures qui rentrent dans la zone ne sont plus notifiées.
-  * Un accident ou une panne peuvent ne pas être détectés (véhicule non équipé) et dans ce cas d'autres véhicules peuvent avertir le système central pour démarrer les scénarios.
-  * Enfin les automobilistes abonnés peuvent émettre et recevoir des messages tels que :  obstacle sur la route, verglas, ... Le contenu des messages est réglementé et ne peut pas excéder quelques mots appartenant à un vocabulaire attendu. A tout message est associé l'identité de l'automobiliste et la localisation du véhicule. Tous les automobilistes dans le secteur reçoivent ces messages. Il est possible de prévoir des filtres pour ne recevoir que certains types de messages. L'annulation d'un message est possible par tout automobiliste dans le secteur, par exemple un obstacle retiré de la voirie.
 ==== Stationnements ====
+pas assez détaillé
-Les automobilistes et les urbanistes désirent disposer d'un outil leur permettant de connaître les places libres (cf. http://www.nice.fr/Transport/Le-stationnement-intelligent). Il s'agit de connaître le taux d'occupation d'un stationnement à partir des capteurs présents sur les places quand les parkings en sont équipés ou d'utiliser la présence des véhicules connectés pour extrapoler l'occupation pour les parkings non équipés de capteurs. De plus, des responsables parkings pourront également ajouter des informations comme "fermeture" du parking, ou parking plein pour ceux qui sont non équipés, ... Les urbanistes pourront visualiser les taux d'occupation calculés dans le temps pour prévoir la politique de stationnement dans les villes.
 ===== Intégrations : Grands Cas d'utilisation =====
-Au début du projet, chaque groupe choisit deux cas d'utilisation d'intégration qu'il pense cibler.
-Des réunions hebdomadaires entre les chefs de groupes doivent permettre de maintenir la cohérence de l'ensemble.
-Si les groupes avancent bien ils peuvent s'intégrer davantage.
-Voici quelques exemples d'intégration, d'autres cas peuvent être proposés à votre enseignant.
-   - (CoS) //(difficulté niveau 1)// **Communication et stationnement**  : des automobilistes peuvent signaler eux-même qu'un parking est plein, pour cela ils émettent un message qui est automatiquement interprété par le système.
-   - (CoT) //(difficulté niveau 2)// **Communication et Trafic**  : Lorsque le temps de parcours d'un tronçon passe au delà de seuils donnés (les seuils sont déterminés en fonction de la voirie, de la vitesse autorisée, de la longueur du tronçon, ... nous les considérons comme donnés), un message est émis tels que "gêne notable"; "circulation dense", "risque de congestion" ou "blocage". Lorsque la situation passe en dessous ou au dessus du seuil courant, le message précédent est annulé et un nouveau message est éventuellement émis.
-   - (CC) //(difficulté niveau 1)// **Consommation et Consommation Variante**  : le système central interroge "régulièrement" les véhicules qu'il surveille pour connaître leur consommation courante.
-   - (CP) //(difficulté niveau 2)//  **Consommation et Parcours** : Ai-je assez d'énergie pour faire cette route? Quelle énergie me faut-il pour faire cette route ?
-   - (CCP) //(difficulté niveau 4)// **Consommation et Consommation Variante et Parcours**  : le système central interroge "régulièrement" les véhicules qu'il surveille pour connaître leur consommation courante et leur position, il détermine alors le tronçon sur lequel se trouve le véhicule et établit une concordance entre la nature du tronçon(montagne ou autoroute par exemple) et la consommation courante du véhicule et la mémorise.
-   - (TP)//(difficulté niveau 2)//  **Trafic et Parcours** : Connaissant la vitesse maximale autorisée sur un tronçon et le temps de parcours moyen des différents tronçons, combien de temps me faut-il pour faire cette route ?
-   - (CPT)//(difficulté niveau 4)// **Consommation Variante, Parcours et Trafic** : à partir des données de consommation constatées sur certains tronçons et du trafic, il s'agit de mieux caractériser les tronçons en leur associant des taux de consommation plus juste qui pourront ainsi tenir compte du contexte.
 ===== Références =====
-    * 1.	http://www.rtflash.fr/voiture-futur-sera-propre-communicante-automatique-et-partagee/article
-    * 2.	Hao Wu; Fujimoto, R.M.; Riley, G.F.; Hunter, M., "Spatial Propagation of Information in Vehicular Networks," Vehicular Technology, IEEE Transactions on , vol.58, no.1, pp.420,431, Jan. 2009 URL: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=4490168&isnumber=4749378
-    * 3.	Gaugel, T.; Mittag, J.; Hartenstein, H., "Characterization and modeling of dissemination delays in inter-vehicle communication networks," Vehicular Networking Conference (VNC), 2012 IEEE , vol., no., pp.203,210, 14-16 Nov. 2012 URL: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6407433&isnumber=6407366
-    * 4.	Borjan Tchakaloff, Sébastien Saudrais, Jean-Philippe Babau ORQA: Modeling Energy and Quality of Service within AUTOSAR Models. Quality of Software Architectures (QoSA) Conference, Vancouver : Canada (2013) http://hal.univ-brest.fr/hal-00852862
-    * http://mpt2013.fr/le-trafic-routier-en-equations/