HA, Analyse et exploitation des données brutes

priusfan

darwiniste
Prius Touring Club
Inscrit
22 Oct. 2005
messages
7,040
Score de réaction
10,250
Localisation
Challans
Véhicule
RZ450e
Il y a un expert en SQL appliqué à l'analyse de la base de données de HA...
C'est LAEVUS
Regardez ce qu'il arrive à faire par ici.


En se basant sur ses requêtes actuelles, il est très simple (en tous cas pour lui :-D ) d'extraire instantanément les épisodes où mg1 & mg2 participent à la propulsion...


le mode opératoire consisterait à remonter la BD (le fichier hybridassistant.db) sur un ordinateur, de l'ouvrir avec un outil adapté, par exemple celui-ci

et balancer une requête "à la Laevus" 8) .....
 
Dernière édition:
Il y a un expert en SQL appliqué à l'analyse de la base de données de HA...
C'est LAEVUS
Regardez ce qu'il arrive à faire par ici.

En se basant sur ses requêtes actuelles, il est très simple (en tous cas pour lui :-D ) d'extraire instantanément les épisodes où mg1 & mg2 participent à la propulsion...

le mode opératoire consisterait à remonter la BD (le fichier hybridassistant.db) sur un ordinateur, de l'ouvrir avec un outil adapté, par exemple celui-ci

et balancer une requête "à la Laevus" 8) .....
C'est qqchose que je saurais faire, mais il faut que je prenne le temps… Si personne ne le fait avant.
 
Suite aux remarques précédentes, j'ai revisité la DB de HA pour mon UX, à la recherche d'épisodes 3M...(un peu bizarre cet enchainement de lettres non?)



et bien j'en ai trouvé plusieurs!!! semble similaire à ce que je crois avoir vu avec pizzabad.

Pendant la phase de chauffe de ICE, les 2 MG pourraient contribuer à l'avancement de la watture.

Ceci est une piste à suivre pour les curieux, merci de continuer avec des contributions factuelles (typiquement des logs de HA, techstream ou autre application de bonne réputation).
 
Laevus :jap::jap::jap: a analysé la BD de francoisrcl (de HL).
C' est une petite base qui contient seulement 14H de conduite.


Pour cela, il faut installer cette base sur un ordi et utiliser un DB Browser.
La requète est la suivante:
Code:
SELECT
    round(f.MG1_RPM*f.MG1_TORQUE/9549.29658551372,1) as MG1_kW,
    round(f.MG2_RPM*f.MG2_TORQUE/9549.29658551372,1) as MG2_kW,
    round((f.MG1_RPM*f.MG1_TORQUE+f.MG2_RPM*f.MG2_TORQUE)/9549.29658551372,1) as MG_kW,
    f.HSI,
    f.SPEED_OBD
FROM fastlog f
WHERE
    f.ICE_RPM=0 AND
    round(f.MG1_RPM*f.MG1_TORQUE/9549.29658551372,1)>=1 AND
    round(f.MG2_RPM*f.MG2_TORQUE/9549.29658551372,1)>=1
ORDER BY
    MG1_kW desc,
    HSI desc,
    SPEED_OBD desc;
j'ai procédé à la mème opération (en utilisant sa requète).

des 52894 enregistrements, ont été extraits 434 enregistrements.
ils sont tous aux alentours de 110km/h.
Result: 434 enregistrements ramenés en 178ms


Si on enlève la condition f.ICE_RPM=0, on récupère également les enregistrements en mode 3 moteurs(804 enregistrements, dont 358 en mode 3 moteurs).
j'ai utilisé cette requete:
Code:
SELECT
    round(f.MG1_RPM*f.MG1_TORQUE/9549.29658551372,1) as MG1_kW,
    round(f.MG2_RPM*f.MG2_TORQUE/9549.29658551372,1) as MG2_kW,
    round((f.MG1_RPM*f.MG1_TORQUE+f.MG2_RPM*f.MG2_TORQUE)/9549.29658551372,1) as MG_kW,
    f.HSI,
    f.SPEED_OBD,
    f.ICE_RPM,
    round(f.ICE_PWR) as ICE_KW
FROM fastlog f
WHERE
    round(f.MG1_RPM*f.MG1_TORQUE/9549.29658551372,1)>=1 AND
    round(f.MG2_RPM*f.MG2_TORQUE/9549.29658551372,1)>=1
ORDER BY
    MG1_kW desc,
    HSI desc,
    SPEED_OBD desc;

Merci infiniment @Laevus pour le partage de sa recette...
 
Bonjour,

si j'ai bien compris on a capté 358 points de fonctionnement en mode 3 moteurs, sur 14 h de fonctionnement.

Parmi ces points, lesquels présentent 3 couples significatifs (afin d'exclure les transitions rapide, à-coups , ...) ?
Combien de temps de fonctionnement cela représente-il ?

Que représentent :
HSI,
SPEED_OBD (? vitesse véhicule )


Sur le plan du principe, un mode 3 moteurs me semble possible, à condition que le thermique produise un couple qui lui permette d'encaisser ceux de MG1 (soleil) et de la couronne (MG2 et roues). [le mode 2 moteurs étant un cas limite du mode 3 moteurs, ou le couple est encaissé par la roue libre, qu'il est facile de dimensionner mécaniquement pour encaisser du lourd ! ]

A+
 
Regarde la pièce jointe 1790speed_obd est la vitesse en km/h, HSI est l'indicateur de puissance au tdb (charge , eco, power).


j'ai procédé à une autre extraction contenant tous les épisodes ou MG1 & MG2 sont positifs, avec la requete suivante:
SELECT
strftime('%Y-%m-%d %H:%M:%S',datetime(f.TIMESTAMP/1000, 'unixepoch'))timestamp,
round(f.MG1_RPM*f.MG1_TORQUE/9549.29658551372,1) as MG1_kW,
round(f.MG2_RPM*f.MG2_TORQUE/9549.29658551372,1) as MG2_kW,
round((f.MG1_RPM*f.MG1_TORQUE+f.MG2_RPM*f.MG2_TORQUE)/9549.29658551372,1) as MG_kW,
f.SPEED_OBD,
f.ICE_RPM,
round(f.ICE_PWR) as ICE_KW
FROM fastlog f
WHERE
round(f.MG1_RPM*f.MG1_TORQUE/9549.29658551372,1)>=1 AND
round(f.MG2_RPM*f.MG2_TORQUE/9549.29658551372,1)>=1
ORDER BY
timestamp asc;
le résultat sous forme de .csv est attaché...




edit: attachement modifié suite à extraction sur mauvaise db...


 

Pièces jointes

  • export_prime.zip
    8.6 KB · Affichages: 3
Merci Priusfan,

hélas j'ai un peu de mal a comprendre cette extraction car beaucoup de lignes ont sauté lors des filtrages.

Quelqu'un peut il me passer une base non filtrée pour la torturer un peu (en tout bien tout honneur, hein ...). ?
Je n'ai pas trouvé la bases de Pizzabad :

Bonsoir,
[...]
Résultats :
J’ai mis les fichier dans le dossier Vidéo : 18h58 correspond au test 1) sur 2 km et 19h04 au test 2) sur 11 km.
[...]

Merci de votre aide !

A+
 
J'étais hors forum, quelques jours…
Il me semble que pour récupérer des lignes en 3 moteurs significatives il faudrait mettre plutôt:
f.ICE_RPM>500 AND

500 en tr/mn est même un peu faible car je pense que ICE n'est jamais en dessous de 1000
 
As tu une base complète à me passer ?
 
@genfutures, je t'ai envoyé un mp....
 
En complément, je vous suggère d'explorer le blog de Laevus (en utilisant le navigateur Chrome, la traduction est automatique).
il y a dedans des ressources immenses et des recettes SQL de très haute qualité :jap::jap::jap::jap:.
(pour le moment, ce sont des images, mais si vous n'avez pas envie de tout retaper, demandez lui poliment, je suis persuadé qu'il répondra)...


FX
 
Je remercie Priusfan :jap: pour le db de la Prius PHEV qu'il m'a envoyé. Enfin j'ai pu satisfaire une vieille curiosité.

DCL et CCL
Code:
Select 
    (Case when ICE_RPM=0 Then "EV" 
          when ICE_RPM>=1000 then "ICE_ON"
          else "Transitory" end) as "Driving status",
    Max(DCL) as DCL_max_kW,
    Min(CCL) as CCL_min_kW,
    count(*) as nCases
From Fastlog as f
Where
    round(f.ice_pwr+(f.MG1_RPM*f.MG1_TORQUE+f.MG2_RPM*f.MG2_TORQUE)/9549.29658551372,1)>=1
Group By
    (Case when ICE_RPM=0 Then "EV" 
          when ICE_RPM>=1000 then "ICE_ON"
          else "Transitory" end)
Driving status DCL_max_kW CCL_min_kW nCases
EV 68.4 -40 23508
ICE_ON 68.4 -40 14073
Transitory 68.4 -40 346


Malheureusement dans le Log il n'est pas possible de connaître l'état du système (HV, EV, ...). Pour la traction seule, la situation de l'ICE peut donner une idée approximative à ce sujet. Il semble donc que les valeurs DCL / CCL ne soient pas affectées par l'état.

En rappelant les puissances des MGs, 22 et 53 kW, c'est clair que la décharge maximale de 68 kW de la batterie peut être obtenue seulement en utilisant ensemble les deux motogénérateurs.


Priusfan a posé une autre question lorsqu'il a recherché la situation tri- moteurs (ICE, MG1 et MG2 à puissances positives). Le résultat m'a surpris, car je n'y vois aucune utilité pour le système. Cependant, il n’est pas exclusif de la Prime: il peut également fonctionner sur la HEV: c’est une variante de la modalité hérétique, dans laquelle MG2, au lieu de générateur, fonctionne comme moteur. Ensuite, j'ai fait une query similaire sur mon file Prius HEV avec ce résultat:

tmp01.jpg
 
Merci à Laevus, c'est super instructif.

On y voit que le 3 moteurs est présent, même sur une P4 normale. Autant je vois un intérêt au mode 3 moteurs sur une rechargeable autant je ne le soupçonnais pas si fréquent sur une normale.
Je suis surpris des faible régime ICE dans les lignes visibles sur la copie d'écran, qui semblent correspondre à des cas de transition.

Mais ce qui me surprend le plus, alors même que je supposait le mode 3 moteur, sont les lignes 16-18 ou la puissance MG1 est supérieure à la puissance ICE.

Je suppose depuis le début que les couple MG1 et ICE doivent s'équilibrer pour que le système soit stable. Le tableau montre des puissances, pas des couples, donc pas évident de statuer. Et il peut y avoir des différences assez notables en transition.

Super intéressant, et à suivre…
 
Il est difficile d'éviter les états transitoires, tout en utilisant certaines précautions, comme le contrôle du nombre de tours d'ICE.

Toutefois le données sélectionnées sont rares, quelques centaines de lignes sur 1.7 milions.

Si vous êtes intéressés à ces données, je vais le mettre en ligne.
 
Oui, quand j'aurai un peu plus de temps, je ferai volontiers des requêtes SQL sur la base de la Prime. Pour le moment je ne l'ai pas demandée à Priusfan ni cherché si elle est accessible sur HL car je suis encore en charrette sur un boulot.
 
Sur la PIII, un ICE à moins de 850 rpm correspond effectivement au démarrage ou à l'arrêt du moteur thermique, donc on ne devrait pas parler de mode 3 moteurs dans ce cas.
 
[OT]
Si vous étiez intéressé au traitement des fichiers Hybridassistant.db aussi pour d’autres modèles ou pour d’autres questions, on pourrait ouvrir une discussion générale à ce sujet.
[/OT]
 
Je regardais la consommation spécifique BSFC. C'est une valeur "délicate" car elle est obtenue en combinant plusieurs PID OBD atomiques qui semblent avoir des temps de réponse différents. Ceux relatives à la consommation, qui sont au numérateur de la fraction g/kWh, semblent répondre plus rapidement que ceux au dénominateur relatives à l'énergie.
Résultat: en cas d'augmentation de puissance, la consommation spécifique atteint des valeurs très élevées (les PID de consommation ont déjà été ajustés, ceux de l'énergie pas encore), puis elle se stabilise à une valeur appropriée. En cas de réduction, c'est l'inverse: initialement, le BSFC atteint initialement des valeurs très basses, puis il s'adapte.
Il serait alors souhaitable de n'utiliser que des valeurs stabilisées pour obtenir résultats crédibles.

Mais, en utilisant des moyennes calculées sur des échantillons nombreux, on pourrait obtenir une compensation statistique des deux effets opposés.
Ayant un DB d'une Prius4 assez peuplé, j'ai essayé de calculer une moyenne générale, en n'imposant qu'une limite à la puissance minimale du Thermique et à sa température.
Code:
SELECT
	round(avg(f.BSFC)) as avg_BSFC,
 	round(81.967/avg(f.BSFC),3)*100 as avg_Thr_Rend,
	count(*) nCases
	FROM Fastlog f
	WHERE
	f.ICE_PWR>=5 AND
	f.ICE_TEMP>70
avg_BSFC avg_Thr_Rend nCases
226.0 36.3 521404

Bon résultat, mais toujours possible.

J'ai ensuite introduit une restriction pour limiter le calcul aux valeurs "stabilisées". Pour faire cela, j'ai imposé que la valeur de la puissance ICE, arrondie au kW, était égale à la moyenne running des dernières 2.5 secondes.
Code:
SELECT
	round(avg(f.BSFC)) as avg_BSFC,
 	round(81.967/avg(f.BSFC),3)*100 as avg_Thr_Rend,
	count(*) nCases
	FROM Fastlog f
	WHERE
	f.ICE_PWR>=5 AND
	f.ICE_TEMP>70 and
	Round(f.ICE_PWR)=(Select round(avg(f1.ICE_PWR)) from fastlog f1 
					  Where f1.TIMESTAMP between (f.TIMESTAMP-2500) and (f.TIMESTAMP-1))

Mon attente c'était de maintenir les 226g/kWh ou, à la limite, une légère amélioration. Pas du tout.
avg_BSFC avg_Thr_Rend nCases
231.0 35.5 271239


J'ai essayé de rendre la contrainte plus restrictive. D'abord en étendant la profondeur de la moyenne running à 5 secondes.
avg_BSFC avg_Thr_Rend nCases
230.0 35.6 206553


Ensuite en réduisant l’arrondi à 500W
avg_BSFC avg_Thr_Rend nCases
230.0 35.6 137956


La moyenne est restée presque stable après la première restriction.

Il apparaît donc que la restriction initiale est suffisante pour stabiliser le résultat et que l’effet, comparé aux données non stabilisées, c'est une réduction, bien que limitée, du rendement. Je me demande pourquoi.
 
Je ne suis pas convaincu. Je décide d'eapprofondir.

Une prémisse: les données que j'utilise sont presque toujours acquises à haute fréquence. En moyenne 5Hz, contre 1Hz d’acquisition standard. Cela signifie que dans les 2,5 secondes de profondeur de la moyenne running, je trouve environ 12 échantillons. Avec l’acquisition standard 2. Le temps de 2,5 secondes a été choisi pour permettre quand même 2 échantillons.

Je calcule la différence entre la puissance ICE actuelle et sa moyenne running au cours des 2,5 secondes précédentes. Tous approximés au kW et, dans la moyenne, la valeur actuelle c'est exclue.

Je groupe sur ce delta et calcule les moyennes de puissance ICE, BSFC, Rendement, en excluant les cas avec moins de 100 résultats.

bsfc_transitory-1.gif


Delta 0 correspond aux moyennes stabilisées calculées précédemment.
Les deltas négatifs indiquent un régime transitoire avec une diminution de la puissance, variations à intensité croissante à mesure que le delta diminue.
Les deltas positif l'inverse.
Ces résultats sanctionnent sans aucun doute que mes impressions en observant l'arc-en-ciel des rendements sur le Dashboard de H.A. c'étaient complètement fausses. :oops:
Dans les transitoires décroissants, il y a une diminution progressive du rendement qui pourrait être raisonnable.
Dans les transitoires en croissance, au lieu de la diminution susmentionnée, il y a une augmentation des rendements qui atteint a des valeurs manifestement incohérentes (> 40%).

Le choix de limiter l'analyse de BSFC / Rendements au seul cas stabilisé semble toutefois fondé.

Ici la Query et la table de résultats.
 
Merci Laevus pour tes analyses...


Cela pourra, peut-etre, nous aider pour HA à mieux gérer les épisodes de transition.... (Alessandro est facile à convaincre lorsque les arguments sont clairs, mais attention: dans HA, il y a vraiment pas mal de modèles différents )...



as tu également récupéré des db depuis des utilisateurs sur le forum italien?
 
Aucune critique à HA. Plutôt le contraire: j'ai crié au miracle quand il fût possible évaluer une information complexe comme le BSFC avec les limitations de l'environnement OBD. En effet je crois que HA travail aux limites des possibilités de OBD, et parfois au delà :)

À propos du forum italien: je n'y ai pas participé beaucoup, juste de récent j'ai essayé de réintroduire des arguments plus complexes. Mais en réalité aujourd'hui il n'est pas très intéressant.

Non, je n'ai pas récupérer des autres Db.J'ai seulement un db où j'ai rassemblé les Log de 3 Prius4 et de 1 Prius3 qui ont fait un test de conduite comparatif de ~60km. Mais je ne l'ai jamais élaboré.
Toutefois je crois qu'il faudrait penser à quelque forme de Repository de Db anonymisées.
 
Après avoir discuté de la stabilisation des valeurs du BSFC, il est maintenant possible de procéder à des élaborations selon diverses dimensions.

Pour niveaux de puissance du Thermique
bsfc_kw.jpg


Pour zones du Powermeter
bfsc_hsi.jpg


Pour plages de température ambiante :D
bsfc_temp.jpg



Notes:
Ici les Query.
Si vous voulez jouer avec la stabilisation, augmentez la profondeur de 2.5 secondes (2500 millisecondes) de la moyenne running.
Il serait très intéressant de disposer de statistiques de rendement aussi pour d'autres modèles.
 
Toutefois je crois qu'il faudrait penser à quelque forme de Repository de Db anonymisées.
Oui, j'y pense depuis la question des 3 moteurs. S'il n'y en a pas déjà une sur HL ou ailleurs, je pense qu'il serait bien de mettre ça en place.

Perso, j'ai les compétences pour le faire sur le web avec un BdD MySQL. L'importation des texte de loi de HA ne pose pas de difficulté.
Ce forum tourne avec Mysql, donc si les admin sont pour, il serait possible de mettre cette base en place sur cet hébergement, sans frais supplémentaires.
Ensuite, la question se pose de qui aura l'accès à la base pour poser des requêtes etc. Ou alors simplement une procédure d'export/téléchargement d'un échantillon de la base pour traitement externe. La base en elle-même ne chargera pas l'hébergement mais des requêtes complexes comme celle de Laevus seraient trop lourdes pour le serveur du forum.
 
En 2016, à la sortie de HA, je posais la question à Alessandro en utilisant, comme suggestion, l'exemple d'un super-Spritmonitor de télémétries.
Mais à cette époque là, au debut de l'application, il n'était pas intéressé à un tel développement.
Je crois que aujourd'hui on peut commencer aussi en manière minimale, avec un partage de file géré à la manière la plus simple possible, à bénéfice de la communauté qui les a produits.
 

:p:horreur::idea::lecteur::pleure3::malade:...

...Ce n'est pas croyable ce que l'on peut se sentir Cromagnon......:rigolade:
 
Pages vues depuis le 20 Oct 2005: 308,087,883
Retour
Haut Bas