—

1. 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.
2. Attention à ne pas omettre la sécurité dans cet exemple, tout le monde ne doit pas avoir accès à toutes les informations.
3. Beaucoup trop de choses, il ne faut garder dans la réalisation que des choses qui aideront à résoudre les intégrations.
4. l'article 4 décrit plein de ces parametres pour une voiture électrique mais cela me semble un peu trop difficile et je ne suis pas sure que nos objectifs pédagogiques y gagnent.. sauf a introduire par la suite par exemple le critère de jour/nuit ou de la gravité… et voir comment il réagissent tant au niveau du cycle de vie que de l'architecture logicielle…
5. Pour la COO cela fait un petit exemple mais dans lequel on devrait il me semble avoir des classes abstraites utiles …

 Pas contente de celui-ci, il est bien trop flou...
 

• 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
• 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.

• 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…

Certains véhicules/automobilistes ¹⁾ 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.
• 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.

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.

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.

1. (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.
2. (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.
3. (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.
4. (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 ?
5. (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.
6. (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 ?
7. (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.

• 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/