Simulation d’un conducteur

Cycle de conduite

Un cycle de conduite est une simulation de trajet parcouru. Il est composé de phases d’accélération, de freinage et de temps d’arrêt afin de simuler au mieux le comportement d’un utilisateur de la route. Ces tests s’effectuent sur des bancs à rouleaux et permettent d’évaluer la consommation du véhicule (en électricité ou en essence) ainsi que les émissions de polluants (moteur à essence). Actuellement, en Europe, les constructeurs automobiles utilisent le cycle « nouveau cycle européen de conduite – NEDC 3 » datant de 1973. Ce cycle n’est vraiment pas représentatif du comportement d’un conducteur et l’autonomie des véhicules correspond très rarement à la réalité. À partir du 1er septembre 2018, tous les véhicules seront obligatoirement homologués par un nouveau cycle nommé « procédure d’essai mondiale harmonisée pour les voitures particulières et véhicules utilitaires légers – WLTP 4 ».

Ce cycle est mis au point par des experts du monde entier et se base sur des données réelles de conduite, il prend également en compte la consommation d’équipements optionnels et l’aérodynamisme du véhicule. Cette nouvelle norme engendrera une augmentation de la consommation des véhicules, même ceux à essence, et se rapprochera de la réalité. Simulations À l’aide des profils d’accélération et de vitesse, le modèle Simulink calcule en tout temps la force de traction nécessaire au véhicule pour avancer. À partir de cette force, il est possible de déterminer le couple, la puissance, l’énergie puis la consommation et l’autonomie d’un véhicule. Les cycles de conduites sont générés à l’aide d’un bloc créer par un utilisateur Matlab (Daniel Auger, 2018)6. Le modèle de simulation dans sa version complète se situe à l’annexe 1. Conditions de simulation Afin de tester l’importance d’une déclivité sur un itinéraire et de comparer les cycles de conduite en vigueur, les caractéristiques de la route ainsi que celles du véhicule sont définies comme suit : Véhicule • Masse totale : m = 2250 [kg] • Surface frontale : s = 1 [m2] • Coefficient de trainée : cx = 0.5 [-] • Coefficient de force de frottement : crr = 0.015 [-] • Rayon de la roue : rr = 0.33 [m] • Rapport de réduction : r = 9.73 [-] • Rendement du réducteur : nr = 0.9 [-] • Rendement du moteur : nm = 0.89 [-] • Rendement du convertisseur : nc = 0.89 [-] • Capacité de la batterie : cb = 98 [kWh] • Densité de l’air : ρ = 1.225 [kg/m3] • Accélération gravitationnelle : g = 9.81 [m/s2] • Couple maximum : mlimit = 660 [Nm] NEDC vs NEDC avec pente Dans cette simulation, un test NEDC classique est comparé au même test NEDC, mais sur une route possédant une pente.

Dans ce test, l’autonomie du véhicule et sa consommation sont comparées. À la fin du cycle NEDC sans pente, il est constaté que le véhicule possède encore une autonomie de 569 kilomètres et il a une consommation de 17.2 kWh/100km. Le cycle NEDC avec pente a duré le même temps et a parcouru la même distance, la seule différence sur ce test c’est qu’une déclivité constante est ajoutée au parcours initial. Il est remarqué que le véhicule termine le cycle avec une autonomie de 522 kilomètres, soit environ 47 kilomètres de différence avec le test initial. En plus de cela, le véhicule consomme 18.8 kWh/100km, soit environ 1.6 kWh/100km de plus.

Importation de trajets routiers

Dans le but d’adapter l’algorithme à la topographie suisse, il est important de pouvoir accéder aux données géographiques de nos routes. Pour ce faire, une comparaison est effectuée entre le service Maps de Google et le service MapGeoAdmin de la Confédération suisse afin de déterminer la fiabilité des services et la facilité d’accès aux données. Comparaison des services Précision MapGeo étant un service de la Confédération suisse, il est considéré comme fiable, précis et fera office de référence dans la comparaison. L’erreur entre les deux services étant toujours plus petite que 1 %, les données de Google sont considérées comme correctes et recevables. Facilité d’accès aux données Les deux services possèdent des interfaces de programmation (API) ainsi qu’une documentation pour savoir comment les utiliser. Cependant, MapGeo ne possède pas d’API pour créer des itinéraires en voiture. Choix La solution choisie est d’utiliser l’interface de programmation de Google.

Une grande quantité d’exemples, une précision correcte et surtout une possibilité d’obtenir des itinéraires routiers ainsi que leur limitation de vitesse ont été les arguments de ce choix. Google Maps API Définition d’un API7 Les API se définissent comme un ensemble de fonctions informatiques par lesquelles deux logiciels vont interagir sans intermédiation humaine. L’API est donc une abstraction définie par la description d’une interface et le comportement de l’interface. Les API sont donc utilisées par des programmes informatiques permettant leurs interactions sous des conditions déterminées et documentées. Google Maps Directions API L’API Directions permet à partir d’un lieu de départ et d’un lieu d’arrivée ou de deux coordonnées GPS de déterminer l’itinéraire à prendre avec une voiture. L’API s’adapte aux mises à jour, c’est-à-dire, si une route est déviée par des travaux le parcours est modifié en conséquence.

Google Maps Elevation API L’API Elevation permet de connaitre l’altitude de n’importe quel endroit sur la Terre à partir d’une coordonnée GPS, même dans l’océan (valeur négative). Clé API Une clé d’interface de programmation d’application est un code utilisé par les programmes informatiques pour identifier le programme ainsi que son développeur ou son utilisateur. Elles contrôlent l’utilisation de l’API et permettent d’éviter des utilisations excessives. 8 Protocole d’importation des profils géographiques Fonction getItinerary Cette fonction permet de déterminer un itinéraire entre deux lieux. Elle prend comme argument un lieu de départ, un lieu d’arrivée, ainsi que la clé API fournie par Google.

Le rapport de stage ou le pfe est un document d’analyse, de synthèse et d’évaluation de votre apprentissage, c’est pour cela chatpfe.com propose le téléchargement des modèles complet de projet de fin d’étude, rapport de stage, mémoire, pfe, thèse, pour connaître la méthodologie à avoir et savoir comment construire les parties d’un projet de fin d’étude.

Table des matières

1. Introduction
1.1 Contexte
1.2 Objectifs
1.3 Cahier des charges
2. Modèle de calcul
3. Environnement et données constructeurs
3.1 Force de pesanteur
3.2 Forces aérodynamiques
3.3 Force de résistance au roulement
3.4 Force d’inertie
3.5 Force de traction
3.6 Couple
4. Voiture électrique
4.1 Bloc moteur
4.1.1 Différentiel
4.1.2 Transmission
4.1.3 Moteur électrique
4.2 Convertisseur DC/AC
4.3 Batteries
4.3.1 12 V
4.3.2 400 V
4.4 Recharge
4.4.1 Prise AC
4.4.2 Convertisseur AC/DC
5. Cycle de conduite
5.1 Comparaison des cycles de conduites
5.2 Simulations
5.2.1 Conditions de simulation
5.2.2 NEDC vs NEDC avec pente
5.2.3 WLTP vs WLTP avec pente
5.2.4 NEDC vs WLTP
6. Importation de trajets routiers
6.1 Comparaison des services
6.1.1 Précision
6.1.2 Facilité d’accès aux données
6.1.3 Choix
6.2.1 Définition d’un API
6.2.2 Google Maps Directions API
6.2.3 Google Maps Elevation API
6.2.4 Clé API
6.3 Protocole d’importation des profils géographiques
6.3.1 Fonction getItinerary
6.3.2 Fonction getElevations
Table des matières Moser Thomas
6.3.3 Fonction principale
7. Création du profil de vitesse
7.1 Méthode pour déterminer la vitesse maximum dans un contour
7.1.1 Position
7.1.2 Vitesse
7.1.3 Accélération
7.1.4 Produit scalaire
7.2 Simulations
7.2.1 Itinéraire 1
7.2.2 Itinéraire 2
7.1 Anticipation pour le changement de vitesse
7.1.1 Simulation 1
7.1.2 Simulation 2
7.1.3 Conclusion
8. Simulation d’un conducteur
9. Tests et résultats
9.1 Itinéraire 1
9.1.1 Profil de vitesse réel
9.2 Itinéraire 2
9.2.1 Profil de vitesse réel
10. Limites de l’algorithme
10.1 Limites du véhicule et de l’environnement
10.2 Limites de l’itinéraire
10.2.1 Exemple 1
10.2.2 Exemple 2
11. Conclusion
11.1 Date et signature
12. Bibliographie
13. Logiciels
14. Annexes
15. Liste des figures et tableaux
15.1 Figures
15.2 Tableaux