Microprocessor Execution Time and Memory Use for Battery State of Charge Estimation Algorithms
Notice bibliographique
Résumé
<div class="section abstract"><div class="htmlview paragraph">Accurate battery state of charge (SOC) estimation is essential for safe and reliable performance of electric vehicles (EVs). Lithium-ion batteries, commonly used for EV applications, have strong time-varying and non-linear behaviour, making SOC estimation challenging. In this paper, a processor in the loop (PIL) platform is used to assess the execution time and memory use of different SOC estimation algorithms. Four different SOC estimation algorithms are presented and benchmarked, including an extended Kalman filter (EKF), EKF with recursive least squares filter (EKF-RLS) feedforward neural network (FNN), and a recurrent neural network with long short-term memory (LSTM). The algorithms are deployed to two different NXP S32Kx microprocessors and executed in real-time to assess the algorithms' computational load. The algorithms are benchmarked in terms of accuracy, execution time, flash memory, and random access memory (RAM) use. In order to ensure the validity of running these models for multiple cells in the pack, the impact of increasing the number of instances to run each algorithm simultaneously is investigated as well. The results show that the four algorithms present a reasonable accuracy, with less than 5% maximum error. For the more power microprocessor tested, the execution time was found to be 0.24 ms, 0.25 ms, 0.14 ms, and 0.71 ms for the EKF, EKF-RLS, FNN, and LSTM respectively. The neural network SOC estimation algorithms were also demonstrated to have lower RAM use than the EKFs, with less than 1 kB RAM required to run one instance of the estimators. Moreover, the FNN SOC estimation algorithm is found to be a promising option with both low execution time and memory use.</div></div>
Récupéré en direct depuis OpenAlex et désinversé. Les résumés ne sont pas conservés dans cette base de données : les index inversés représentent 8,6 Go des 9,3 Go de texte de la base, et le serveur dispose de 13 Go libres.
Comment cette classification a été obtenuedéplier
Prédiction distillée sur la base complète
Imitation des enseignantsNi prévalence calibrée, ni vérité terrain. Validation humaine à venir. Apprise à partir de 10 348 étiquettes directes de Codex et de 10 348 étiquettes directes de Gemma. Le mode candidate est l'union des têtes enseignantes seuillées; le consensus est leur intersection. Ces sorties portent le statut machine_predicted_unvalidated et ne sont ni des étiquettes humaines ni des étiquettes directes de modèles de pointe.
Scores Codex et Gemma par catégorie
| Catégorie | Codex | Gemma |
|---|---|---|
| Métarecherche | 0,001 | 0,001 |
| Méta-épidémiologie (sens strict) | 0,001 | 0,001 |
| Méta-épidémiologie (sens large) | 0,001 | 0,000 |
| Bibliométrie | 0,000 | 0,001 |
| Études des sciences et des technologies | 0,000 | 0,001 |
| Communication savante | 0,000 | 0,001 |
| Science ouverte | 0,001 | 0,001 |
| Intégrité de la recherche | 0,000 | 0,001 |
| Charge utile insuffisante (le modèle a refusé de juger) | 0,000 | 0,000 |
Scores machine (provisoires)
Les deux têtes enseignantes du modèle étudiant, lues sur ce travail. Un score ordonne la base pour la relecture; il n'affirme jamais une catégorie, et le statut de validation accompagne chaque rangée tel quel.
Scores de référence d'un modèle non mature (critères de maturité non atteints, 7 itérations). Un score ordonne; il n'affirme jamais une catégorie.
score_only:v0-immature-baseline · tel quel depuis la passe de notation : score_only signifie que le nombre peut ordonner les travaux, et qu'aucune étiquette de catégorie n'en découleClassification
machine, non validéePrédiction automatique; un appel candidat d’une seule tête enseignante, pas un consensus.
Le détail, modèle par modèle et score par score, se trouve en fin de page sous « Comment cette classification a été obtenue ».