Un fournisseur de batteries ne peut pas concevoir une interface CAN fiable à partir d'une photo de connecteur et de quelques trames capturées. Ce guide explique le dossier technique précis qu'un équipementier doit fournir avant que l'intégration du BMS d'une batterie de chariot élévateur ne puisse commencer.
Cela échoue dès le début.
Lorsqu'un constructeur de chariots élévateurs se contente de fournir à son fournisseur de batteries la tension nominale, la capacité, des photos des connecteurs et une demande vague visant à “ faire fonctionner le protocole CAN ”, le projet passe déjà d'une phase d'ingénierie maîtrisée à une phase coûteuse de rétro-ingénierie, où chaque hypothèse manquante se traduit par un nouveau retard dans la fabrication du prototype, une nouvelle révision du micrologiciel ou un dysfonctionnement sur le terrain.
Pourquoi les fabricants d'équipements de pointe continuent-ils à considérer les données de communication comme facultatives ?
L'intégration du bus CAN dans une batterie de chariot élévateur ne se résume pas à un simple câblage. Il s'agit d'un contrat d'interface entre le système de gestion de la batterie, l'unité de contrôle du véhicule, le chargeur, le tableau de bord, l'onduleur de traction, l'unité télématique et, parfois, un calculateur passerelle.
Le fournisseur a besoin de plus que CAN-H et CAN-L.
Il doit savoir ce que signifie chaque message, quand il doit s'afficher, à qui il appartient, ce qui se passe lorsqu'il disparaît, et quel appareil est habilité à interrompre la recharge ou à désactiver la traction.
Mon point de vue, sans détours, est simple : Un équipementier qui ne communique pas la définition de l'interface ne peut raisonnablement tenir le fournisseur de batteries pour responsable des performances d'intégration.
Le Norme ISO 11898-1 relative au réseau CAN définit la couche de liaison de données CAN et les règles de codage physique. Il ne précise pas la signification de l'octet 3 sur un chariot élévateur donné, ni si l'état de charge utilise une échelle de 0,5%, ni si le message 0x351 doit arriver toutes les 100 millisecondes.
Cette différence a son importance.
Un fournisseur peut brancher un analyseur CAN et visualiser immédiatement le trafic. Les trames s'affichent. Les compteurs augmentent. Les données changent lorsque l'accélérateur est actionné ou que le chargeur est branché.
Mais le trafic n'est pas synonyme de sens.
Prenons l'exemple suivant :
ID CAN : 0x351
DLC : 8
Données : 64 0A 5E 10 00 03 7B 92
Cycle : 100 ms
En l'absence d'une définition de signal validée, le fournisseur ne sait pas si :
Les essais empiriques peuvent permettre d'obtenir un tableau de bord fonctionnel en laboratoire. Mais ils ne permettent pas d'obtenir une batterie sûre pour la production.
La différence entre une démonstration CAN et un produit intégré réside dans la documentation.
Le fournisseur a besoin d'un dossier technique complet. Pas de dix fils de discussion par e-mail. Pas de captures d'écran provenant d'un ancien outil de maintenance. Et certainement pas d'un fichier DBC dans lequel la moitié des signaux sont nommés Réservé.
Voici le dossier de transfert minimal que j'exigerais avant d'approuver l'intégration du système de gestion de batterie (BMS) d'un chariot élévateur.
| Livrable OEM | Contenu obligatoire | Pourquoi le fournisseur en a-t-il besoin ? | Erreur courante en cas d'absence |
|---|---|---|---|
| Architecture réseau | Tous les calculateurs, passerelles, points de terminaison, segments de bus, ports de diagnostic et appartenance au réseau connectés | Indique l'emplacement de la batterie et les contrôleurs qui utilisent ses données | La batterie fonctionne sur un banc d'essai, mais ne fonctionne pas une fois installée à l'arrière du véhicule. |
| Spécification de la couche physique | CAN Classic ou CAN FD, identifiants de 11 ou 29 bits, débit de 250/500 kbps ou autre, point d'échantillonnage, circuits de terminaison et de réveil | Permet une communication électrique stable | Événements de coupure du bus, réflexions, défauts de démarrage intermittents |
| DBC, EDS ou base de données équivalente | Identifiants de message, signaux, positions de bits, mise à l'échelle, décalages, unités, ordre des octets, valeurs valides et débits de transmission | Fournit le mappage des messages CAN de la batterie du chariot élévateur | SOC incorrect, courant inversé, fausses alarmes de température |
| Matrice de responsabilité des messages | Calculateur émetteur, calculateur récepteur, durée de cycle prévue, délai d'expiration et délai de démarrage pour chaque message | Empêche les doublons d'identifiants et les conflits de synchronisation | Deux appareils transmettent le même identifiant ou les délais de surveillance arrivent à expiration |
| Machine à états de fonctionnement | Transitions entre les modes veille, veille active, précharge, fonctionnement, charge, défaut, maintenance et arrêt | Définit un comportement conforme à la loi plutôt que des signaux isolés | Les contacteurs s'ouvrent pendant la course ou restent fermés en cas de défaut |
| Interface de recharge | Identifiants des chargeurs, demandes de tension/intensité, logique d'activation des chargeurs, déclassement, arrêt de la charge et comportement en cas de dépassement du délai | Coordonne le BMS, le chargeur et le camion | Le chargeur refuse de démarrer ou ne tient pas compte de la limite de courant de la batterie |
| Matrice de réaction aux défaillances | Gravité des défauts, niveau d'alerte, réponse en couple, réponse du contacteur, conditions de rétablissement et règles de verrouillage | Adapte le comportement du camion aux mesures de protection du système de gestion de batterie (BMS) | Les avertissements mineurs désactivent la traction, tandis que les défauts graves sont ignorés |
| Schéma d'interface électrique | Brochage, modèle de connecteur, entrée d'allumage, boucle de verrouillage, alimentation auxiliaire, blindage et mise à la terre | Empêche les problèmes de communication et les dommages matériels | Ligne de sillage inversée, décalage par rapport au sol, défaillance du dispositif de verrouillage |
| Spécifications de diagnostic | Identifiants de diagnostic, UDS ou services propriétaires, format DTC, droits d'accès et méthode de mise à jour du micrologiciel | Soutient les essais de production et l'intervention sur site | Les concessionnaires ne peuvent pas détecter les défauts ni mettre à jour les batteries de remplacement |
| Consulter les journaux CAN | Démarrage à froid, conduite normale, SOC faible, recharge, charge complète, traces de défaut et d'arrêt | Fournit au fournisseur des preuves concrètes de son bon comportement | Les erreurs de documentation restent invisibles jusqu'aux essais sur route |
| Matrice des tests d'acceptation | Conditions de réussite/échec, modèles concernés, limites environnementales et versions logicielles | Définit le moment où l'intégration est terminée | Des révisions sans fin parce que le terme “ fonctionnel ” n'a jamais été défini |
Le DBC, c'est important.
Cependant, une base de données DBC décrit généralement les messages et les signaux ; elle ne reprend que rarement l'intégralité de la machine à états de la batterie, la séquence des contacteurs, le modèle de cybersécurité, les autorisations de diagnostic ou la réaction du véhicule en cas de perte de communication. Le constructeur doit donc également fournir un document de contrôle d'interface et un plan de réception.
CoreSpark's Compétences en ingénierie des batteries OEM/ODM couvrent déjà la configuration personnalisée du BMS, les options de communication, la conception des connecteurs, l'adaptation des chargeurs, le développement d'échantillons et l'assistance aux essais. Ce processus ne peut être efficace que si l'équipementier fournit des données d'interface contrôlées dès le début, plutôt qu'après l'échec du premier prototype.
Un fichier DBC du bus CAN exploitable destiné aux fournisseurs de batteries doit définir chaque signal que la batterie transmet ou reçoit.
Chaque entrée de signal doit comporter au minimum :
La description de la somme de contrôle mérite une attention particulière. Il ne suffit pas d'indiquer “ CRC-8 ”.
Le fournisseur a besoin du polynôme, de la valeur initiale, de la valeur XOR finale, des règles de réflexion, de la plage d'octets protégée, des règles d'inclusion des identifiants, de la position du compteur d'activité et d'un exemple d'entrée-sortie vérifié. Les normes CRC-8/SAE-J1850 et CRC-8/AUTOSAR sont toutes deux des calculs sur huit bits, mais elles ne sont pas interchangeables.
Un seul paramètre manquant peut faire perdre plusieurs jours.
Et non, une trace CAN ne peut pas s'y substituer. Une trace permet certes de confirmer un comportement, mais elle révèle rarement toutes les valeurs réservées, les conditions de défaillance, les délais d'expiration, les règles de mise à l'échelle, les graines de somme de contrôle ou les variantes spécifiques au modèle.
Le fabricant d'équipement d'origine doit identifier le protocole de couche supérieure réel.
Un système CAN propriétaire nécessite généralement un fichier DBC ainsi qu'un document de contrôle d'interface. Une implémentation CANopen peut nécessiter un fichier EDS ou DCF, un dictionnaire d'objets, un mappage PDO, un comportement SDO, des états NMT, une synchronisation des signaux de pulsation, des règles d'identification des nœuds et des définitions de messages d'urgence.
Le Profil du périphérique CiA 418 a été spécialement conçu pour favoriser l'interopérabilité entre les modules de batterie CANopen et les chargeurs, y compris ceux mis en œuvre selon la norme CiA 419. Il s'agit là d'une indication utile, mais la mention “ compatible CANopen ” ne permet toujours pas à un fournisseur de savoir quels objets optionnels, mappages, identifiants de nœuds ou règles de synchronisation le chariot élévateur utilise réellement.
Un camion basé sur la norme J1939 nécessite un ensemble de paramètres spécifiques : PGN, SPN, adresses source, comportement en matière de revendication d'adresse, PGN propriétaires, taux de répétition, exigences relatives au protocole de transport et règles de gestion du réseau.
“ Utilise le CAN ” ne nous apprend pratiquement rien.
La plupart des problèmes d'intégration ne surviennent pas lorsque le camion roule normalement. Ils se produisent lors des transitions.
Mise en veille. Précharge. Connexion du chargeur. Temporisation après coup de clé. Arrêt d'urgence. Coupure en cas de basse tension. Rétablissement de la communication.
Le fabricant d'équipement d'origine doit documenter chaque transition sous forme de séquence, et non sous la forme d'une simple liste de signaux.
Voici à quoi pourrait ressembler une séquence de démarrage simplifiée :
Maintenant, posez les questions qui dérangent.
Que se passe-t-il si la demande du véhicule arrive avant que le BMS n’ait terminé son autotest ? Combien de temps la précharge peut-elle durer ? Le BMS doit-il recevoir trois trames valides avant de fermer les contacteurs ? Quel pourcentage de la boucle intermédiaire CC est considéré comme indiquant que la précharge est terminée : 85%, 90% ou 95% ? Que se passe-t-il si le signal de présence du véhicule disparaît pendant 500 millisecondes alors que le camion est en mouvement ?
Les réponses ne peuvent pas venir de l'imagination du fournisseur de batteries.
Pour chaque état de fonctionnement, le constructeur d'équipement d'origine doit définir :
La même rigueur s'applique au sommeil.
Certains camions coupent immédiatement l'alimentation du système d'allumage. D'autres laissent la batterie sous tension pendant 10, 30 ou 120 secondes afin que le véhicule puisse enregistrer des données de fonctionnement, transmettre des messages finaux ou terminer les transferts de données télématiques.
Une batterie qui se met en veille trop tôt peut sembler défectueuse, même si son système de protection fonctionne parfaitement.
De nombreuses équipes parlent du camion et de la batterie, tout en considérant le chargeur comme un simple accessoire.
C'est une erreur.
Dans un système intégré de chariots élévateurs au lithium, le chargeur peut être amené à recevoir :
La batterie peut également avoir besoin de connaître la tension de sortie du chargeur, le courant disponible, l'état du chargeur, les codes d'erreur et l'état du connecteur.
Le chariot peut alors se positionner au-dessus des deux dispositifs et déterminer si la recharge est autorisée en fonction de l'état du frein de stationnement, de la position de la clé, de l'état du dispositif de verrouillage, de la présence de l'opérateur, de la détection du connecteur ou des règles d'exploitation de l'entrepôt.
Qui est responsable ?
Le constructeur d'équipement d'origine doit y répondre par écrit.
CoreSpark's solutions de batteries pour chariots élévateurs la conception des zones de recharge, la recharge ponctuelle, le dimensionnement en fonction des équipes de travail, la sécurité et la planification de la conversion. Ces thèmes sont directement liés à l'intégration du réseau CAN, car un protocole adapté aux batteries au lithium des chariots élévateurs doit prendre en charge la stratégie de recharge effective, et non se contenter d'afficher l'état de charge (SOC) sur un écran.
Un chariot élévateur commercialisé sous l'appellation “ chariot élévateur 48 V ” peut être équipé d'un bloc-batterie au lithium de type LFP d'une tension nominale de 51,2 V. Une configuration LiFePO₄ classique en série de 16 cellules utilise des cellules d'une tension nominale d'environ 3,2 V, mais le contrôleur du chariot tient compte de la plage de fonctionnement complète, et non de la mention figurant sur l'étiquette commerciale.
Le constructeur d'équipement d'origine doit fournir :
Le fournisseur met ensuite ces limites en correspondance avec la composition chimique des cellules, le nombre de séries, les seuils de protection du BMS et les paramètres du chargeur.
Le simple fait de faire correspondre le terme “ 48 V ” ne relève pas de l'ingénierie.
Une matrice des défauts doit établir un lien entre chaque état de la batterie et une réaction précise du véhicule.
Par exemple :
| Incident lié à la batterie | Fonctionnement de la batterie | Circulation de camions prévue | Règle de récupération |
|---|---|---|---|
| Avertissement SOC | Transmettre l'état d'alerte | Afficher un message d'avertissement ; maintenir l'adhérence | Dépasse le seuil SOC d'origine |
| Seuil bas de SOC | Réduire la limite du courant de décharge | Réduire progressivement le couple | Se résout après la recharge |
| Surchauffe de la cellule | Courant de déclassement | Limiter la traction et la régénération | Se désactive une fois que les limites de température et d'hystérésis sont atteintes |
| Surchauffe grave | Ouvrez les contacteurs lorsque cela peut se faire en toute sécurité | Entrer un arrêt contrôlé | Entretien ou réinitialisation définie requise |
| Délai d'attente CAN en position de stationnement | Maintenir ou ouvrir les contacteurs selon la logique d'état | Affichage d'un défaut de communication | Récupération après une séquence de trames valides |
| Délai d'attente CAN pendant le déplacement | Appliquer la période de fonctionnement en cas de défaillance convenue | Réduire le couple ou s'arrêter en toute sécurité | Procédure de redémarrage définie par le fabricant d'équipement d'origine (OEM) |
| Défaut d'isolation | Bloquer la lecture ou la écriture | Afficher les codes d'erreur (DTC) de gravité élevée | Une inspection par un professionnel est requise |
| Détection des contacteurs soudés | Empêcher le redémarrage normal | Désactiver les messages d'erreur relatifs aux camions et aux journaux | Réinitialisation du service uniquement |
“ Envoyer un bit de défaut ” n'est pas une stratégie de gestion des défauts.
L'équipementier doit définir le comportement du véhicule après réception de celui-ci. Le fournisseur doit définir le comportement du BMS si le véhicule ne tient pas compte de ses instructions.
Ce deuxième cas est souvent évité lors des réunions, car il soulève des questions relatives à l'autorité. Il n'en reste pas moins qu'il faut y répondre.
Le rapport 2024 de l'OSHA sur les blessures graves a fait état de 5 186 accidents graves impliquant des chariots élévateurs entre 2015 et 2024, soit environ neuf blessures graves par semaine parmi les employeurs couverts par la base de données fédérale. Le rapport souligne également que cette base de données ne couvre qu'une partie de la population active américaine et qu'elle ne doit donc pas être considérée comme un recensement national exhaustif. Consultez le rapport 2024 de l'OSHA sur les blessures graves.
Ces blessures n'étaient pas toutes liées à des problèmes de batterie ou de communication. Ce n'est pas là le problème.
Le fait est que les chariots élévateurs évoluent au milieu des piétons, des rayonnages, des quais de chargement, des charges en hauteur et des allées étroites. Une interruption inexpliquée de la traction, un calcul erroné du niveau de charge (SOC), une limite de régénération désactivée ou l'ouverture d'un contacteur ne constituent pas seulement une mauvaise expérience utilisateur.
Cela peut compromettre la sécurité de fonctionnement.
Le libellé réglementaire est également sans ambiguïté. En vertu de OSHA 29 CFR 1910.178(a)(4), les modifications qui ont une incidence sur la capacité ou le fonctionnement en toute sécurité d'un chariot industriel motorisé nécessitent l'accord écrit préalable du fabricant, ainsi que la mise à jour correspondante des plaques, étiquettes ou autocollants.
C'est pourquoi tout programme de conversion au lithium devrait commencer par la liste de contrôle pour la conversion des chariots élévateurs du plomb-acide au lithium ainsi que la procédure d'autorisation écrite du constructeur d'équipement d'origine (OEM). L'intégration du réseau CAN ne dispense pas de tenir compte des aspects mécaniques liés au poids de la batterie, à son fixation, aux dimensions du compartiment, au lest, aux connecteurs et à la capacité nominale.
Le règles relatives au poids et au contrepoids des batteries de chariots élévateurs sont particulièrement pertinentes dans ce contexte. Une interface CAN techniquement parfaite ne peut pas corriger un pack de remplacement qui ne respecte pas la plage de poids de batterie homologuée pour le camion.
Les batteries connectées sont des calculateurs électroniques (ECU) pilotés par logiciel.
Traitez-les comme ça.
La batterie peut donner accès à des fonctions de diagnostic CAN, au Bluetooth, à l'interface RS485, à l'USB, aux logiciels de maintenance, aux données télématiques ou aux fonctions de mise à jour du micrologiciel. Chaque interface modifie le modèle de risque.
Le Recommandations de la NHTSA en matière de cybersécurité des véhicules recommande de communiquer des normes claires en matière de cybersécurité aux fournisseurs, de tenir à jour des registres des composants logiciels et de leurs versions, de tester les produits, de documenter les choix de conception, de protéger l'accès aux fonctions de diagnostic, d'authentifier les messages liés à la sécurité dans la mesure du possible, et de recourir à la segmentation ou au filtrage du réseau. Bien que ce document concerne les véhicules routiers, la logique technique qui y est exposée s'applique directement aux équipements industriels connectés via le réseau CAN.
Il existe un véritable précédent qui justifie de prendre cela au sérieux.
En juillet 2015, Fiat Chrysler a procédé au rappel d'environ 1,4 million de véhicules américains après que des chercheurs ont démontré qu'il était possible d'accéder à distance aux commandes d'un véhicule connecté via le système Uconnect. Selon Reuters, les chercheurs auraient pu envoyer des commandes agissant sur le moteur, la direction et les freins.
Une batterie de chariot élévateur n'est pas une Jeep Cherokee. Mais les réseaux CAN partagent une caractéristique préoccupante : dès qu'une interface non fiable accède à un bus de commande mal segmenté, une simple fonctionnalité de communication peut devenir une porte d'entrée vers des fonctions liées à la sécurité.
L'équipementier doit donc définir :
La sécurité fondée sur l'opacité des connecteurs n'est pas une véritable sécurité.
Il existe des cas légitimes où un équipementier historique ne peut pas fournir une documentation complète. Il se peut que le fournisseur d'origine du contrôleur n'existe plus. Le fichier DBC peut être incomplet. La plateforme du camion peut avoir accumulé quinze ans de modifications de micrologiciel non documentées.
La rétro-ingénierie peut s'avérer utile.
Mais il faut le considérer comme un projet d'ingénierie maîtrisé, soumis à certaines contraintes, et non comme une alternative bon marché à la coopération avec les équipementiers.
Un programme de rétro-ingénierie digne de ce nom peut nécessiter :
Même dans ce cas, certains événements peuvent ne jamais apparaître dans les données enregistrées. Un défaut d'isolation grave, le déclenchement d'un contacteur, la défaillance d'un capteur de température de cellule, la restauration du chargeur d'amorçage ou une erreur rare du chargeur peuvent ne pas se produire au cours d'une observation normale.
Le silence n'est pas une preuve.
La meilleure approche consiste à utiliser des traces CAN enregistrées pour vérifier le cahier des charges écrit. En cas de divergence entre la trace et le document, l'équipementier doit résoudre cette divergence et publier une définition révisée, soumise à un contrôle de version.
Tout programme sérieux d'intégration de batteries par un équipementier nécessite une matrice d'acceptation signée.
Les essais ne doivent pas se limiter au “ démarrage et à la conduite du camion ”.”
Vérifier :
Test :
Déconnecter ou simuler :
Vérifiez ensuite que la batterie, le chariot, le chargeur et l'écran réagissent tous conformément à la même matrice de dépannage.
On ne devrait pas demander à un fournisseur de découvrir les critères d'acceptation lors de l'essai final du véhicule. Cela revient à lui imposer des conditions à l'improviste.
CoreSpark's Études de cas et processus de validation relatifs au projet de batterie LiFePO₄ Mettre l'accent sur la vérification des échantillons avant la production en série, notamment en ce qui concerne la tension, la capacité, les dimensions du pack, la configuration du BMS, la méthode de charge et les exigences relatives aux connecteurs. Pour les projets de chariots élévateurs intégrant le protocole CAN, cette même étape doit inclure la vérification de la conformité au protocole et les tests de détection des défauts au niveau du véhicule avant la validation définitive du micrologiciel de production.
Les équipementiers hésitent souvent à publier une base de données CAN complète, car celle-ci contient des signaux propriétaires sans rapport avec la batterie.
Cette inquiétude est légitime. La réponse habituelle ne l'est pas.
L'équipementier n'est pas tenu de mettre à disposition tous les signaux relatifs à la direction, au système hydraulique, à la traction ou à la télématique. Il doit toutefois fournir suffisamment d'informations pour permettre au fournisseur de batteries de mettre en œuvre et de vérifier en toute sécurité l'interface qui lui a été attribuée.
Il existe trois modèles viables :
Le constructeur fournit une base de données filtrée contenant les messages relatifs à la batterie, au chargeur, à la passerelle et aux diagnostics requis. Les signaux non pertinents sont supprimés ou renommés.
Le constructeur d'équipement d'origine (OEM) fournit un document de référence qui définit uniquement les signaux, les séquences, les temporisations, les défauts et les services de diagnostic requis par la batterie.
Le constructeur automobile place le protocole dédié aux véhicules particuliers derrière une passerelle et fournit au fournisseur de batteries une interface stable et documentée. Cela permet souvent d'obtenir la séparation la plus claire à long terme, à condition que le délai d'expiration et le comportement en cas de défaillance de la passerelle soient clairement définis.
Un accord de confidentialité (NDA) permet de protéger les informations confidentielles.
Cela ne peut pas se substituer aux informations techniques.
Je suspendrais le projet d'ingénierie si un équipementier tenait l'une des déclarations suivantes :
Cette dernière affirmation est particulièrement dangereuse. Elle pourrait signifier que le fournisseur précédent disposait d'une documentation plus complète, avait mis en place une solution de contournement non documentée ou avait pris en charge un risque d'intégration qui n'a jamais fait l'objet d'une évaluation formelle.
Le silence passé ne prouve pas que l'interface soit performante.
L'intégration du bus CAN dans les batteries de chariots élévateurs désigne le processus d'ingénierie visant à permettre au système de gestion de la batterie, au contrôleur du chariot, au chargeur, à l'écran d'affichage et aux outils de diagnostic d'échanger des messages définis, de suivre le même état de fonctionnement et de réagir en toute sécurité aux limites, aux défauts, aux commandes de réveil, aux demandes de charge et aux coupures de communication.
Ces travaux portent sur la configuration de la couche physique, le mappage des signaux, la synchronisation des messages, la logique des contacteurs, la gestion de la charge, les diagnostics, la gestion logicielle et la validation au niveau du véhicule. Ils ne sont considérés comme achevés que lorsque le fonctionnement normal et le comportement en cas de défaillance répondent tous deux aux critères d'acceptation définis par écrit.
Un fichier DBC CAN bus est une base de données lisible par machine qui définit chaque trame et chaque signal CAN que le fournisseur doit mettre en œuvre, notamment les identifiants de message, les positions d'octets, les longueurs en bits, l'ordre des octets, la mise à l'échelle, les décalages, les unités, les débits de transmission, les règles de multiplexage, les plages valides et, parfois, des tables de valeurs ou des champs de somme de contrôle.
Le DBC ne constitue qu'une partie de l'interface. Une spécification distincte devrait définir les transitions d'état, la coordination avec le chargeur, les réactions en cas de défaillance, le comportement en cas de délai d'attente, les diagnostics, les contrôles de cybersécurité et les tests de réception.
L'équipementier doit fournir au fournisseur de batteries le cahier des charges complet de l'interface : brochage électrique, paramètres de la couche physique, DBC ou carte de signaux équivalente, propriété du réseau, synchronisation des messages, transitions d'état, protocole de charge, réactions en cas de défaut, accès au diagnostic, règles relatives aux versions logicielles, traces de test et critères d'acceptation écrits pour le modèle de chariot élévateur concerné.
L'équipementier doit également recenser tous les modèles concernés, ainsi que les versions des contrôleurs, des chargeurs et les variantes régionales. Un protocole validé sur un seul camion de 48 V ne doit pas être systématiquement étendu à l'ensemble d'une gamme de produits.
Une batterie de chariot élévateur ne peut fonctionner sans communication CAN que si le chariot et le chargeur ont été conçus pour accepter une batterie autonome dont le système de gestion de batterie (BMS) commande les contacteurs et les dispositifs de protection de manière indépendante ; sur de nombreux chariots élévateurs modernes, l'absence de messages CAN déclenchera des verrouillages, un mode de secours, un refus de charge, des codes d'avertissement ou une perte totale de traction.
Même une batterie autonome doit tout de même être compatible avec la plage de tension du véhicule, sa demande en courant, son connecteur, les exigences en matière de poids de la batterie, son système de charge et ses dispositifs de sécurité. La mention “ Pas besoin de CAN ” ne signifie pas “ compatible sans adaptation ”.”
La meilleure pratique en matière d'intégration CAN pour les batteries de chariots élévateurs consiste à définir une spécification d'interface unique soumise à un contrôle de version, à la valider à l'aide de traces CAN réelles et d'un système « hardware-in-the-loop » ou d'un banc d'essai pour chariots élévateurs, à simuler des délais d'expiration et des défaillances de capteurs, à vérifier le comportement du chargeur, puis à signer une matrice d'acceptation avant que le fournisseur ne lance la version de production du micrologiciel.
L'équipementier et le fournisseur doivent également assurer la traçabilité des versions des protocoles, examiner chaque modification du micrologiciel, contrôler l'accès aux diagnostics et conserver les résultats des essais pour chaque combinaison approuvée de chariot élévateur, de batterie et de chargeur.
La documentation relative à la norme ONU 38.3 ne constitue pas une exigence du protocole CAN ; il s'agit d'une preuve de conformité aux normes de transport attestant qu'une cellule ou une batterie au lithium a satisfait aux essais applicables prévus à la partie III, sous-section 38.3, du Manuel des essais et critères de l'ONU avant d'être mise en circulation.
Le Administration américaine chargée de la sécurité des pipelines et des matières dangereuses stipule que les fabricants et les distributeurs en aval doivent mettre à disposition les résumés des essais effectués sur les batteries au lithium, conformément à la réglementation en vigueur. La validation du protocole et les documents de transport doivent tous deux être inclus dans le dossier de lancement du projet, mais ils ont des objectifs différents.
Ne vous lancez pas dans un projet d'intégration du bus CAN d'une batterie de chariot élévateur en ne disposant que de la tension, de la capacité en ampères-heures et d'une photo du connecteur.
Préparez l'architecture réseau, le fichier DBC ou EDS, la matrice de propriété des messages, la machine à états d'exploitation, la procédure d'échange de données pour la recharge, le tableau des réponses aux défauts, le schéma de brochage, les traces CAN de référence, la liste des versions logicielles et les critères d'acceptation. Identifiez les modèles exacts de camions et de chargeurs concernés.
Envoyez ensuite le dossier pour examen technique.
Un fournisseur de batteries qualifié est en mesure de protéger les fichiers confidentiels dans le cadre d'un accord de confidentialité (NDA), de signaler les informations manquantes, de proposer un système de gestion de batterie (BMS) et une architecture de communication, de construire un prototype contrôlé et de valider le résultat sur le véhicule réel.
Mais le fournisseur ne peut pas créer des informations que le constructeur n'a jamais communiquées.
Communiquez à CoreSpark Battery le modèle de votre chariot élévateur, la tension et la capacité de la batterie, le protocole CAN, les détails du chargeur, le schéma du connecteur et la quantité visée afin de lancer une étude d'intégration OEM documentée — et non pas un énième pari hasardeux de rétro-ingénierie.
