Refroidissement intelligent DENSO : traduire les signaux de commande en exigences HVAC claires

Mise à jour technique

Le 3 juin 2026, DENSO a publié une mise à jour sur le passage du refroidissement mécanique du moteur vers des systèmes thermiques à commande électronique. Il traite des pompes électriques à refroidissement, du contrôle des PWM et des thermostats gérés électroniquement, ainsi que de la nécessité d'un diagnostic au niveau du système. Il s'agit d'une mise à jour technique de l'industrie, et non d'une allégation selon laquelle chaque véhicule ou contrôleur HVAC supporte la même interface électrique ou de communication. [Source]

Le sujet est directement pertinent pour les demandes de CVCA d'OEM. Les clients se demandent souvent si un système a CAN, RS-232, RS-485 ou une autre interface avant d'expliquer l'information dont ils ont réellement besoin. Un fournisseur peut répondre à la question du nom d'interface et ne parvient toujours pas à résoudre le problème du client.

Cet article présente une méthode plus claire pour définir les exigences en matière de contrôle et de rétroaction. Il ne précise pas le câblage d'un produit particulier. Toute connexion, caractéristique électrique ou protocole doit être confirmé pour le contrôleur exact et l'arrangement du véhicule par l'intermédiaire des fournisseurs responsables.

Commencer par le résultat demandé

Demandez au client de décrire ce que le véhicule doit savoir ou faire. Est-ce qu'il faut savoir si le climatiseur fonctionne ? Doit-il activer ou désactiver l'unité? Faut-il changer un réglage de température, lire un défaut ou surveiller une valeur mesurée? Ce sont des fonctions séparées.

Un client qui ne demande qu'une indication d'activation ou d'arrêt peut ne pas avoir besoin d'un protocole de communication complet. À l'inverse, une demande de télécommande peut nécessiter plus qu'une sortie d'état. Le projet ne devrait pas ajouter de complexité simplement parce qu'un nom d'interface familier apparaît dans un courriel précoce.

Écrivez le résultat en une courte phrase et confirmez-le avec le client. Par exemple, le contrôleur du véhicule a besoin d'une indication que le système HVAC fonctionne, le sens exact du fonctionnement restant à convenir. Cette phrase révèle une question suivante importante au lieu de choisir prématurément un connecteur ou un bus.

Le fournisseur peut alors proposer un formulaire de signal approprié et expliquer ses limites. Cette séquence facilite la conversation technique des deux côtés et réduit la chance qu'un contrôleur soit commandé avec la mauvaise capacité.

Puissance, commande, rétroaction et diagnostic séparés

L'énergie fournit l'énergie dont un appareil a besoin. Une commande demande un comportement. La rétroaction rapporte un état ou une mesure. Les diagnostics fournissent des renseignements utiles pour identifier ou enquêter sur une affection. Un arrangement de connexion unique peut prendre en charge plusieurs fonctions, mais la spécification devrait les maintenir distinctes.

La confusion survient souvent lorsqu'un acheteur traite une commande comme preuve d'opération. Un contrôleur peut demander un refroidissement pendant que l'équipement attend une condition habilitante ou fonctionne dans une limite de protection. L'état requis et l'état atteint ne sont pas nécessairement identiques.

De même, un signal de puissance ne prouve pas qu'un compresseur ou un ventilateur fonctionne. Une indication sans défaut ne prouve pas nécessairement que l'espace occupé a atteint l'état désiré. La signification de chaque signal doit être précisée suffisamment précisément pour que le contrôleur récepteur puisse l'utiliser correctement.

Créez une liste de signaux avec une ligne par fonction. Décrivez la source, la destination, la signification et le comportement requis. Cela peut être fait avant de choisir la forme électrique. Il donne aux équipes matérielles et logicielles une base fonctionnelle partagée pour la conception de l'interface.

Définir ce qu'on signifie

Une demande d'état on/off sonne simple jusqu'à ce que l'équipe demande ce qu'on représente. Cela pourrait signifier que le panneau de commande est alimenté, qu'un utilisateur a activé le système, que le ventilateur fonctionne, que le compresseur est commandé ou qu'un état de refroidissement particulier est actif. Ces significations ne sont pas interchangeables.

Demandez au client quelle décision le système receveur prendra à partir du signal. S'il n'allume qu'un indicateur de situation, le sens requis peut différer d'un signal utilisé pour coordonner l'allocation de puissance ou d'une autre fonction du véhicule. La conséquence du signal détermine la précision avec laquelle il doit être défini.

Définir également les États de transition. Que devrait montrer la sortie pendant le démarrage, une pause temporaire ou un arrêt de protection? Un signal binaire peut être suffisant, mais son comportement doit toujours être documenté. Si une représentation binaire ne peut pas soutenir la décision du client, l'équipe peut avoir besoin d'une description de statut plus riche.

Le résultat devrait être un petit tableau d'état que les deux fournisseurs approuvent. Il est beaucoup plus utile qu'une affirmation sans réserve que l'unité a un signal d'on/off. Le tableau permet d'éviter des désaccords ultérieurs sur la question de savoir si une sortie techniquement opérationnelle signale l'état prévu par le client.

Choisissez la forme électrique après la signification

Une fois la fonction définie, le fournisseur du contrôleur peut identifier les formes électriques possibles. Le système de réception du véhicule doit confirmer ce qu'il peut accepter. Les deux parties devraient convenir des niveaux pertinents, de la référence, de l ' isolement, le cas échéant, et de l ' arrangement de raccordement pour la conception réelle.

Ne pas déduire ces détails d'une étiquette occasionnelle comme le contact sec, le signal de tension ou la sortie de communication. La mise en œuvre exacte est importante. Le fournisseur doit fournir les renseignements techniques requis par l'ingénieur du système récepteur et identifier les conditions ou limites éventuelles.

La spécification de l'interface devrait comprendre la définition du connecteur et de la broche, les conditions d'exploitation autorisées et les dispositions de protection ou d'isolement requises, telles que déterminées par les concepteurs responsables. Il devrait également indiquer quelle organisation fournit le harnais ou l'adaptateur et vérifier la connexion terminée.

Cet article ne prescrit pas de valeurs électriques parce qu'elles doivent provenir de l'équipement réel. L'obligation de passation des marchés est d'obtenir et de concilier ces valeurs avant l'installation. Deviner un niveau de signal d'une famille de produits familiers peut endommager l'équipement ou produire des comportements trompeurs.

Un nom de protocole n'est pas un accord complet

CAN, LIN, RS-232 et RS-485 décrivent différents aspects de la technologie de communication, mais un nom d'interface ne définit pas à lui seul les messages d'application ou le comportement attendu par le véhicule. Le protocole exact et la configuration doivent être confirmés.

Pour une interface de données, demandez quelles commandes et valeurs d'état sont prises en charge, comment elles sont représentées et combien de fois elles sont transmises ou demandées. Identifiez les versions requises et toute configuration nécessaire à l'une ou l'autre des extrémités. Le système récepteur doit interpréter les informations de la même manière que l'expéditeur.

Le projet devrait aussi définir comment les renseignements manquants, obsolètes ou non valides sont traités. Un contrôleur qui continue d'afficher la dernière valeur reçue sans indiquer la perte de communication peut créer une impression trompeuse de fonctionnement courant. Le comportement requis appartient à la spécification fonctionnelle.

Un fournisseur peut fournir un document de protocole ou un autre paquet d'interface technique convenu. L'acheteur devrait alors organiser un test de compatibilité pour les fonctions demandées. Des connecteurs similaires ou une technologie de bus partagé ne remplacent pas ce test.

Utiliser une table d'état pour exposer l'ambiguïté

Considérez un système HVAC hypothétique avec cinq états: propulsé mais désactivé, activé et en attente, refroidissement actif, temporairement limité et défectueux. Un client demande un seul signal marqué AC. L'équipe doit décider lequel de ces États produit une indication active.

Si le client veut seulement savoir si l'opérateur a activé le système, le signal peut rester actif pendant que l'unité attend. Si le client a besoin d'une confirmation de refroidissement actif, ce même comportement serait inapproprié. La demande originale utilisait les mêmes mots, mais les décisions envisagées sont différentes.

Le tableau d'état doit décrire la sortie requise dans chaque état et le moment associé aux transitions. Il devrait également identifier le comportement lorsque le contrôleur perd de la puissance ou que la connexion est interrompue. Les ingénieurs responsables déterminent la mise en œuvre et le retrait appropriés.

Cet exemple n'est pas une spécification pour aucun contrôleur VETHY. Il montre pourquoi la clarification fonctionnelle devrait précéder une promesse de compatibilité. Une table courte peut prévenir un problème d'intégration beaucoup plus important après l'achat et l'installation du matériel.

Le calendrier est important même pour un simple retour d'information

Le système de réception doit savoir à quelle vitesse un signal suit un changement et comment les conditions temporaires sont représentées. Un statut qui se met à jour lentement peut être acceptable pour un affichage mais inadapté à un autre but de contrôle. Le moment requis devrait suivre le cas d'utilisation réel.

Déterminer si une brève transition doit être signalée immédiatement ou traitée conformément à une règle de filtrage convenue. Le fournisseur devrait expliquer le comportement de son contrôleur réel. Évitez de supposer qu'une sortie change au même moment que le processus physique sous-jacent.

Pour les interfaces de données, distinguer le moment de la transmission de l'âge de la mesure sous-jacente. Un message transmis fréquemment peut toujours contenir une valeur qui n'a pas été rafraîchie comme prévu. L'interface devrait fournir les informations nécessaires pour interpréter sa monnaie là où cela compte.

Lors des essais, consigner les commandes, les états rapportés et les observations pertinentes selon un calendrier cohérent. Cela aide l'équipe à comprendre les retards et la séquence. Une capture d'écran d'une valeur peut confirmer qu'un message existe sans démontrer qu'il se comporte correctement pendant le cycle d'exploitation.

Plan de perte de puissance ou de communication

Chaque interface devrait avoir un comportement défini lorsque le chemin d'information normal n'est pas disponible. La réponse correcte dépend de la fonction du véhicule et doit être déterminée par les ingénieurs responsables. Il ne devrait pas être improvisé par un installateur au point de connexion.

Demandez ce que le système de réception voit lorsque le contrôleur HVAC est dévié, déconnecté ou redémarré. Distinguer ces conditions d'un état valide hors de l'état, le cas échéant. Un signal unique peut être ambigu sauf si le design explique comment les défauts et les états normaux sont représentés.

Le contrôleur du véhicule devrait également avoir une réponse définie aux informations non disponibles. Il peut être nécessaire d'indiquer l'incertitude, d'utiliser un système de repli approuvé ou de prendre une autre mesure spécifiée par la conception du véhicule. La clé est que le comportement est accepté et testé plutôt que supposé.

Enregistrez les limites de la portée technique orientée vers le client. Une sortie d'état de base peut intentionnellement fournir moins d'informations qu'une interface diagnostique. Cela peut être acceptable lorsqu'il correspond à l'exigence, mais le client ne devrait pas s'attendre à des détails de faute que l'arrangement choisi ne peut pas livrer.

Construire un test de compatibilité autour des fonctions réelles

Un test utile vérifie les commandes et les statuts que le client entend utiliser. Il devrait inclure le fonctionnement normal, les transitions pertinentes et les cas d'information non disponible définis. La méthode exacte doit être adaptée à l'équipement et approuvée par les équipes responsables.

Utiliser les versions et la configuration du contrôleur prévues lorsque cela est pratique. Si un simulateur ou une interface temporaire est utilisé, indiquer comment il représente le système final du véhicule et ce qui reste à vérifier ultérieurement. Un échange de banc réussi n'établit pas nécessairement le comportement installé complet.

Le dossier d'essai doit identifier le matériel, le logiciel, le câblage ou la disposition de connexion et le résultat escompté pour chaque cas. Enregistrer le résultat observé et toute déviation. Cela crée des preuves qui peuvent être examinées par les deux fournisseurs sans se fier à une déclaration verbale selon laquelle la communication a fonctionné.

Lorsqu'un problème est trouvé, mettez à jour le document d'interface ou la mise en œuvre par le biais du contrôle des changements. Tester les fonctions affectées et tout comportement associé identifié par les ingénieurs. La compatibilité devient un résultat contrôlé du projet plutôt qu'une démonstration ponctuelle difficile à reproduire.

Diagnostiquer le système plutôt que le composant le plus visible

Le contrôle thermique électronique peut produire des symptômes qui nécessitent une enquête à la fois physique et au niveau du signal. L'atelier doit comprendre la relation entre une demande, la réponse du contrôleur et le comportement réel de l'équipement. Le remplacement d'une composante sans ce contexte peut laisser la cause sans solution.

Un dossier utile de service comprend le mode demandé, l'état déclaré, les conditions d'approvisionnement pertinentes et les informations sur les défauts disponibles via l'interface approuvée. Il devrait identifier les versions installées du contrôleur et les changements récents. Les données collectées devraient répondre à une question diagnostique plutôt que de simplement accumuler des valeurs.

L'équipe de service devrait savoir quelles observations proviennent des capteurs et quels sont les états inférés ou commandés. Une demande affichée de pompe ou de compresseur ne peut pas être une mesure directe du fonctionnement physique. Les étiquettes claires permettent d'éviter une conclusion incorrecte.

Le fabricant ou le fournisseur de services qualifié devrait définir les contrôles appropriés pour le système. Le présent article ne remplace pas ces procédures. Son point pratique est que la spécification de l'interface et la documentation diagnostique doivent être élaborées ensemble, car les deux dépendent d'une compréhension partagée de l'État et de la responsabilité.

Garder la personnalisation du contrôleur dans un cadre défini

Si une interface demandée n'est pas actuellement prise en charge, le fournisseur peut proposer la personnalisation. L'acheteur devrait demander une portée de développement couvrant la fonction, les modifications matérielles ou logicielles, le processus d'échantillonnage et les responsabilités de validation. Une affirmation selon laquelle la personnalisation est possible n'est pas une conception terminée.

Indiquez qui est propriétaire du protocole ou du signal requis et qui peut approuver le résultat. Le fournisseur peut avoir besoin de détails du fabricant principal du contrôleur du client. Sans ces intrants, il ne peut pas garantir de manière fiable la compatibilité ou estimer le travail.

La citation devrait distinguer les capacités existantes des nouvelles. Indiquer les produits livrables et les critères d'acceptation pour le travail sur mesure. Cela protège les deux parties de traiter une discussion préliminaire comme un engagement inconditionnel en matière de production.

Après approbation, conservez la configuration personnalisée dans l'enregistrement du produit. Les remplacements de service doivent correspondre à la version pertinente ou suivre une voie de mise à jour approuvée. Une interface personnalisée perd de la valeur si le processus de remplacement ultérieur fournit un contrôleur standard qui ne fournit pas la fonction requise.

Un livre de fournisseur concis

La remise la plus utile commence par le résultat requis du client : quelles informations doivent être reçues ou quelles mesures doivent être prises. Il identifie ensuite le contrôleur récepteur, le formulaire de signal proposé, s'il est connu, et le contexte du véhicule.

Demandez au fabricant du contrôleur de confirmer si la conception actuelle supporte cette fonction. Dans ce cas, demander la définition électrique et fonctionnelle, l'information du connecteur et l'applicabilité de la version. Dans le cas contraire, demandez la portée et les éléments de preuve nécessaires à une éventuelle modification.

Inclure le moment, les états normaux et le comportement requis lorsque l'information est indisponible. Indiquer si la fonction est destinée à l'affichage, à la coordination ou à un autre but. Cela donne au fournisseur le contexte nécessaire pour juger si une simple sortie est suffisante ou si une interface plus détaillée est nécessaire.

La réponse doit être examinée avec l'ingénieur du système récepteur avant l'installation. Les deux parties doivent convenir de la même fonction et de la même mise en œuvre. Cette conciliation finale est ce qui transforme une liste de fonctions d'interface en une véritable intégration de véhicule.

Une table d'état fonctionnel avant un dessin électrique

Le tableau suivant est un outil de clarification hypothétique. Il ne décrit pas une sortie VETHY existante et ne précise pas de tension, de connecteur ou de circuit. Son but est d'aider un client à décider quelles informations il a réellement besoin avant de demander au fabricant du contrôleur de les mettre en œuvre.

L'ingénieur du système récepteur devrait expliquer la décision qui suit chaque réponse. Si le signal ne commande qu'un affichage, une définition simple peut être adéquate. S'il coordonne une autre fonction, l'information requise et le repli peuvent être différents. La mise en œuvre devrait suivre cet objectif.

Une fois la table fonctionnelle acceptée, le fournisseur du contrôleur peut proposer le formulaire électrique ou de communication. Le fournisseur côté véhicule vérifie ensuite la compatibilité. Le document final d'interface devrait connecter le sens fonctionnel à l'implémentation exacte de sorte qu'aucune des parties ne doit déduire la relation.

Cette commande est efficace parce qu'elle empêche l'équipe de débattre de CAN, de liens série ou de contacts avant de savoir si le client a besoin d'un ou plusieurs états. Il peut aussi révéler qu'une fonction supportée existante est suffisante, évitant une personnalisation inutile.

Pendant les essais, utiliser le tableau comme résultat attendu. Observez chaque état pertinent par une méthode approuvée et enregistrez ce que le système récepteur affiche ou fait. Un test qui ne montre que l'état actif laisse les états ambigus d'attente et non disponibles non résolus.

Gardez la table approuvée avec l'enregistrement de la version du contrôleur. Si le logiciel change, vérifiez si le sens ou le calendrier déclarés changent. Un remplacement physiquement identique ne devrait pas être supposé être identique sur le plan fonctionnel sans les informations de configuration pertinentes.

Pour une réponse orientée vers le client, le fournisseur peut ensuite indiquer la fonction confirmée dans un langage clair et joindre la définition technique. Cette réponse est plus utile que de dire seulement qu'une interface est prise en charge, parce qu'elle dit au client ce que le véhicule saura réellement.

Foire aux questions

Si un client n'a besoin que d'un signal d'allumage/arrêt, le système doit-il utiliser CAN?

Pas forcément. Le formulaire approprié dépend de la fonction et du contrôleur récepteur. Définir d'abord le sens et les exigences électriques, puis obtenir la confirmation des deux fournisseurs. Une interface plus simple peut suffire, mais elle doit toujours être spécifiée correctement.

Est-ce qu'une entrée habilite est la même que la rétroaction opérationnelle?

Non, je sais. Un permet les demandes d'entrée ou permet le fonctionnement. La rétroaction rapporte un état défini. L'équipement ne fonctionne peut-être pas exactement comme demandé, de sorte que les deux fonctions doivent rester séparées dans la spécification.

Une étiquette partagée RS-485 ou CAN peut-elle prouver sa compatibilité?

Non, je sais. Le protocole d'application, la configuration et le comportement doivent correspondre. Demander les informations techniques pertinentes et tester les fonctions requises par le véhicule plutôt que de se fier uniquement au nom de l'interface.

Que peut confirmer VETHY avant de faire une promesse d'interface?

VETHY devrait confirmer l'exigence avec le client et obtenir la capacité exacte du fournisseur du contrôleur. La réponse devrait identifier le modèle, la version, la définition du signal et tout travail de développement. Les fonctions non vérifiées CAN, série ou retour d'état ne doivent pas être annoncées comme des fonctions standard.

Rendre l'exigence compréhensible avant de la rendre technique

La spécification de l'interface la plus forte commence par une phrase opérationnelle claire et se termine par un accord électrique ou de communication testé. Cette séquence évite toute complexité inutile et expose tôt les informations manquantes.

La mise à jour de DENSO est un rappel utile que les systèmes thermiques dépendent de plus en plus des commandes ainsi que du matériel. Les acheteurs peuvent répondre en séparant les demandes, les états, les mesures et les diagnostics, puis demander aux fournisseurs de confirmer les fonctions exactes de leur véhicule.