FR3140690A1

FR3140690A1 - boîtier CAN BUS pour véhicules professionnels

Info

Publication number: FR3140690A1
Application number: FR2210301A
Authority: FR
Inventors: Sylvain Denis
Original assignee: FBI (Fabrication de Batiments Industriels) SA
Current assignee: FBI (Fabrication de Batiments Industriels) SA
Priority date: 2022-10-07
Filing date: 2022-10-07
Publication date: 2024-04-12

Abstract

L’invention concerne un boîtier d’interface (10) pour véhicule professionnel tel qu’un camion, exécutant un programme d’ordinateur programmé pour :- échanger des données d’entrée et/ou des données de sortie avec un réseau « BUS CAN » du véhicule ;- coordonner des échanges d’informations et des routines de sécurité entre le châssis du véhicule et des éléments carrossés rajoutés sur le châssis ;le boîtier (10) comprenant une interface homme machine « IHM ». Selon l’invention, l’IHM est configurée pour afficher une interface graphique de programmation pour créer des fonctions combinatoires de données d’entrée et/ou de données de sorties. Figure pour l’abrégé : Fig. 1

Description

boîtier CAN BUS pour véhicules professionnels

L’invention se rapporte au domaine technique des véhicules professionnels, tels que des camions-bennes.

Art antérieur

Il est connu de l’art antérieur des boîtiers CAN BUS destinés à coordonner des échanges d’informations et des routines de sécurité entre un châssis d’un véhicule et des éléments carrossés rajoutés sur ce châssis.

Ce type de boîtier est utilisé par des carrossiers, qui achètent des châssis à des constructeurs de véhicules, et qui installent ensuite sur ces châssis des équipements optionnels, en fonction des besoins de leurs clients. Il peut par exemple s’agir d’une benne hydraulique, d’une grue, ou encore d’une combinaison de différents éléments.

Des boîtiers d’interfaces sont généralement utilisés afin de regrouper en une seule interface des moyens de pilotage des éléments carrossés.

De plus, différentes réglementations régissent les règles de sécurité à mettre en œuvre pour que les véhicules carrossés ne présentent pas de danger lors de leur utilisation. Des boîtiers d’interfaces sont alors utilisés afin de collecter des données issues de capteurs du châssis, ainsi que de capteurs disposés sur les éléments carrossés, de manière que le boîtier exécute un programme d’ordinateur programmé pour analyser dans quelle situation évolue le véhicule, et vérifier que les conditions de sécurité sont respectées.

Par exemple, il faut éviter qu’un véhicule équipé d’une benne à ridelles puisse circuler avec une ridelle ouverte : la ridelle dépasse alors du gabarit normal du véhicule, et le risque d’accident en cas de croisement est très élevé.

Les boîtiers CAN BUS sont donc programmés à l’aide de fonctions combinatoires combinant différents opérandes tels que la vitesse du véhicule, l’état activé ou non d’une prise de force hydraulique, la position ouverte ou non d’une ridelle. Ces fonctions combinatoires permettent de vérifier le bon respect des conditions de sécurités. Dans le cas contraire, une alerte peut être émise à l’attention du conducteur, ou encore la vitesse du véhicule peut être bridée à un seuil prédéfini (15km/h par exemple).

Les boîtiers utilisant le réseau de communication CAN BUS du véhicule, les différents opérandes issus du châssis sont identifiés au moyen d’un code hexadécimal, qui identifie l’opérande cherché au sein de toutes les données d’entrées qui circulent sur le réseau CAN BUS.

Le code hexadécimal d’un opérande est propre à chaque marque de châssis de véhicule, voir à chaque modèle de véhicule au sein d’une marque. De plus, programmation est bien entendu à adapter en fonction des éléments qui sont carrossés sur le châssis.

Les carrossiers rencontrent donc des difficultés pour programmer les boîtiers d’interface qu’ils installent.

Il est connu de l’art antérieur le document CN101913343 qui décrit le paramétrage de boîtiers d’interfaces. Néanmoins ce paramétrage doit être effectué au moyen de fichiers de paramétrage préparés à l’avance par un bureau d’études compétents. Le carrossier n’est donc pas autonome dans la programmation du boîtier.

Il est connu du document DE102009047974 des moyens de reprogrammation d’un contrôleur d’un véhicule. Néanmoins cette reprogrammation est effectuée au moyen d’une connexion à distance. Là encore, le carrossier n’est pas autonome dans la programmation du boîtier.

L’un des buts de l’invention est de faciliter la programmation d’un boîtier CAN BUS installé sur un véhicule.

Enfin l’un des buts de l’invention est de permettre aux carrossiers de travailler avec différents modèles de véhicules au sein d’une marque, ou des véhicules de différentes marques constructeurs, sans difficulté supplémentaire.

À cet effet il a été mis au point un boîtier d’interface pour véhicule professionnel tel qu’un camion, exécutant un programme d’ordinateur programmé pour :
- échanger des données d’entrée et/ou des données de sortie avec un réseau « BUS CAN » du véhicule ;
- coordonner des échanges d’informations et des routines de sécurité entre le châssis du véhicule et des éléments carrossés rajoutés sur le châssis ;
le boîtier comprenant une interface homme machine « IHM » .

Selon l’invention l’interface homme-machine est configurée pour afficher l’interface graphique programmation pour créer des fonctions combinatoires de données d’entrée et/ou des données de sortie.

De cette manière, le boîtier est fonctionnel et préprogrammé pour la surveillance de fonctions, et il ne reste plus qu’à indiquer quelles doivent être les fonctions à surveiller. Le carrossier est apte à programmer les fonctions combinatoires nécessaires, en adéquation avec les éléments carrossés du véhicule concerné, et de manière autonome. Il n’est plus nécessaire d’utiliser du matériel spécifique et exclusif d’une marques, tel qu’une valise constructeur, et il n’est pas non plus nécessaire de faire intervenir un bureau d’étude dédié pour préparer des fichiers de programmation.

La programmation des fonctions combinatoires est facilitée, et rendue accessible à des carrossiers ne disposant pas de bureaux d’études d’automatismes.

De manière à pouvoir être compatible avec tout type de modèle ou de marque constructeurs de châssis, l’interface graphique de programmation comprend un champ d’opérande qui est configuré pour une saisie, par l’utilisateur, de paramètres hexadécimaux d’une donnée d’entrée, tels qu’un identifiant de trame, un bit de démarrage, ou une longueur de codage. En effet le carrossier peut utiliser les documentations relatives aux réseaux CAN BUS fournies par les constructeurs, y trouver les paramètres hexadécimaux de la donnée cherchée, et les saisir dans le champ d’opérande.

De manière à faciliter la création ou la programmation de nouvelles fonctions combinatoires, l’interface graphique de programmation comprend un champ de fonction qui est configuré pour une saisie, par l’utilisateur, de fonctions combinatoires d’au moins un opérande. Le carrossier est ainsi libre de créer les nouvelles fonctions dont il a besoin. De plus s’il y a une modification des éléments carrossés installés sur le véhicule, alors ces nouveaux éléments pourront être surveillés et/ou commandés au moyen de nouvelles fonctions programmées par le carrossier au moyen du champ de fonctions.

Afin de faciliter la saisie des fonctions dans le champ de fonctions, en évitant de recopier manuellement les paramètres hexadécimaux des opérandes nécessaires, le champ de fonction est configuré pour afficher une liste d’opérandes comprenant :
- des opérandes pré-saisis par le fabricant du boîtier ; et
- des opérandes saisis par l’utilisateur ;
et le champ de fonction est configuré pour que la sélection d’un opérande soit effectuée parmi la liste affichée.

Pour faciliter la programmation de fonctions complexes, utilisant de nombreux opérandes, la liste d’opérandes comprend également des combinaisons d’opérandes, définis par des fonctions combinatoires d’au moins un opérande.

Afin de réduire les opérations de câblage nécessaires, qui seraient imposées par l’utilisation de boutons physiques externes, le boîtier d’interface comprend des boutons, physiques ou virtuels, et l’interface graphique de programmation comprend une interface graphique d’affectation de bouton qui est configurée pour une saisie, par l’utilisateur, de l’affectation d’une fonction à un bouton. Au surplus, cela permet d’avoir des boîtiers d’interface interchangeable, qui peuvent être adaptés à différents types de véhicules, quels que soient les éléments carrossés.

De préférence, le champ d’affectation de bouton est configuré pour programmer un comportement monostable ou bistable d’un bouton. De cette manière les boutons programmés du boîtier reproduisent parfaitement le comportement de boutons matériels auxquels il se substitue.

Pour que l’interface graphique affichée par l’interface homme-machine soit la plus explicite possible pour l’utilisateur du véhicule, le champ d’affectation de bouton est configuré pour programmer l’affichage d’une étiquette de bouton sur l’IHM, selon un résultat d’un calcul d’une fonction. Le carrossier peut ainsi prévoir des messages d’alertes ou d’informations dédiées à chaque fonction programmée et associée à un bouton.

Dans un mode de réalisation particulier, la fonction est une fonction de sécurité susceptible d’identifier une défaillance de sécurité du véhicule. Le boîtier d’interface peut alors permettre la vérification de la conformité de l’utilisation du véhicule. En particulier, il est possible d’effectuer les mises à niveau de sécurité nécessaires lorsque d’anciens véhicules préexistants doivent être mis en conformité avec les évolutions réglementaires ultérieures.

Dans un mode de réalisation particulier, une mémoire de stockage du boîtier comprend une base de données d’opérandes comprenant des paramètres hexadécimaux des opérandes, des marques de véhicules et des modèles de véhicules. De cette manière le travail du carrossier est encore facilité, car il n’a pas à saisir manuellement les paramètres hexadécimaux des opérandes nécessaires, il n’a qu’à les sélectionner au sein de la base de données via une fonction dédiée de l’interface graphique.

L’invention concerne également un véhicule équipé d’un boîtier selon les caractéristiques précitées.

est une illustration d’un boîtier selon l’invention, avant sa programmation.

est une illustration d’un tel boîtier, en cours de programmation.

est une illustration d’un tel boîtier, une fois sa programmation achevée.

est une illustration de conventions de paramètres hexadécimaux d’un réseau CAN BUS.

est un extrait d’une documentation CAN BUS d’un constructeur.

Description détaillée de l’invention

L’invention se rapporte essentiellement à un boîtier d’interface (10) pour véhicules professionnels, destiné à être relié au réseau CAN BUS de ces véhicules, qui comprend une interface homme-machine « IHM », et qui permet à un installateur du boîtier (10), typiquement un carrossier, de programmer les fonctions que doit exécuter ledit boîtier (10).

Ce nouveau type de boîtier (10) permet donc au carrossier d’être indépendant dans l’installation et la programmation de ce boîtier (10), quel que soit le modèle du châssis, sa marque, et quels que soient les éléments carrossés installés sur le véhicule. Ce boîtier (10) confère donc carrossier une autonomie qui n’était pas disponible jusqu’alors.

La difficulté qui résidait dans la programmation des boîtiers de contrôle tenait à ce que les différents constructeurs de châssis mettent à disposition des informations des paramètre hexadécimal utilisé sur leur réseau CAN BUS, mais chaque constructeur utilise sa propre terminologie.

Par exemple pour une première marque de châssis, l’état de la prise de force est codé sur la trame CAN BUS avec un identifiant 0CFE6269, alors que chez un autre constructeur ce même opérande d’état activé ou non de la prise de force est codée CFDA455, chez un troisième constructeur de châssis il s’agira encore d’un autre identifiant, 0X10FF7F7F.

Bien que chaque constructeur de châssis mette à disposition l’information cherchée, à savoir dans cet exemple l’état activé ou non de la prise de force, un carrossier ne dispose pas du matériel nécessaire ni des automaticiens suffisamment compétents pour aller programmer lui-même, avec les moyens conventionnels, un boîtier (10) d’interface.

Le boîtier d’interface (10) selon l’invention, configuré pour afficher une interface graphique de programmation, permet donc à un carrossier de pallier les inconvénients de l’art antérieur.

Le boîtier d’interface (10) est configuré pour être installé sur un véhicule, et est destiné à être relié, par exemple par réseau filaire, à des capteurs d’éléments carrossés ainsi qu’à un réseau CAN BUS du véhicule.

Le boîtier (10) comprend une unité de contrôle dotée d’une mémoire inscriptible, et exécute un programme d’ordinateur configuré pour exécuter des fonctions de surveillance, ainsi qu’une interface graphique affichée sur interface homme machine « IHM », de préférence tactile.

Dans le mode de réalisation préférée, l’interface graphique de programmation comprend un champ d’opérande permettant à l’utilisateur de saisir les paramètres hexadécimaux d’une donnée d’entrée. Ces paramètres sont ceux qui sont fournis par les constructeurs de châssis. L’utilisateur peut donc, quel que soit le modèle du châssis destiné à recevoir le boîtier (10), saisir les bons paramètres hexadécimaux permettant d’identifier la donnée d’entrée désirée, et de l’affecter à un opérande. Selon l’exemple précédent, il peut s’agir de l’état activé ou non de la prise de force.

Cette donnée d’entrée sera utilisée en tant qu’opérande dans une fonction exécutée par le boîtier (10) d’interface.

Ensuite l’interface graphique de programmation comprend un champ de fonctions permettant au carrossier de créer de nouvelles fonctions combinatoires avec les différents opérandes.

Les opérandes peuvent correspondre à des données d’entrée issues de capteurs ou de contrôleurs installés par le carrossier, ou encore de données d’entrée issues d’informations circulant sur le réseau CAN BUS du châssis.

Dans un cas particulier, les opérandes sont des résultats de fonctions combinatoires préprogrammées par le carrossier : pour simplifier des fonctions complexes, le carrossier peut regrouper certains termes de cette fonction sous le nom de nouveaux opérandes, dits « combinaisons d’opérandes ». Les fonctions affichées sur l’interface graphique de programmation sont plus courtes et plus intelligibles.

Afin de faciliter la saisie des fonctions combinatoires, le champ de fonctions est configuré pour afficher une liste d’opérandes comprenant à la fois :
- des opérandes pré-saisis par le fabricant du boîtier (10) et correspondant à des entrées câblées du boîtier (10) sur lequel le carrossier est susceptible de raccorder des capteurs qui l’intéressent a priori ;
- des opérandes saisis par l’utilisateur, c’est-à-dire correspondant à des données d’entrée issues du réseau CAN BUS, pour lesquelles l’utilisateur a dû saisir les paramètres hexadécimaux afin que le boîtier (10) interface puisse les détecter au sein des informations circulant sur le réseau CAN BUS ;
- et le cas échéant les combinaisons d’opérandes définies par l’utilisateur ;
de sorte que la saisie des fonctions est facilitée car il n’y a pas à ressaisir manuellement les paramètres hexadécimaux.

Le résultat d’une fonction combinatoire peut être utilisé en local, par le boîtier (10) d’interface. Par exemple, il peut s’agir de contrôler le boîtier (10) dans le cas de l’émission d’une alerte (tel qu’au moyen d’un buzzer). Une combinaison d’opérandes correspond également à une utilisation locale.

Le résultat d’une fonction combinatoire peut être utilisé de manière externe, en tant que donnée de sortie du boîtier (10) : dans ce cas, le résultat est injecté par le boîtier d’interface (10) sur le réseau CAN BUS, en respectant les paramètres hexadécimaux indiqués par le constructeur du châssis. Dans ce cas, il est possible de piloter des éléments du châssis, tel que le bridage de vitesse par exemple.

De manière qu’il ne soit pas nécessaire de rajouter des boutons (12) sur le tableau de bord du véhicule pour piloter les éléments carrossés, le boîtier d’interface (10) comprend des boutons (12), matériels ou virtuels (c’est-à-dire affichés sur l’interface graphique). Le comportement des boutons (12) virtuels est programmable afin qu’ils reproduisent le comportement des boutons (12) matériels auxquels ils se substituent. Le comportement des boutons (12) peut donc être monostable par exemple.

En référence aux figures 1 à 3, qui représentent un boîtier (10) selon l’invention, le carrossier peut affecter de nouvelles fonctions à des boutons (12), ici l’allumage de feux de travail, et programmer l’affichage d’étiquettes (13) associées à ces boutons (12).

En référence à la , le boîtier (10) neuf n’exécute aucune fonction de surveillance, et seul l’accès (11) à l’interface de programmation du boîtier (10) est accessible.

En référence à la , le carrossier a programmé des boutons (12) de pilotage (12) de phares de travail :
- une info bulle (13) rappelle l’état allumé ou éteint des phares de travail ;
- les boutons (12) sont bistables ;
- le carrossier a néanmoins programmé une fonction d’extinction automatique des phares de travail, dans le cas où la vitesse du véhicule dépasse un seuil prédéterminé, par exemple 15 km/h.

Pour cela, le carrossier :
- a identifié au sein de la documentation constructeur les paramètres hexadécimaux de la donnée d’entrée correspondant à la vitesse du véhicule ;
- créé un nouvel opérande « vitesse », et affecté à cet opérande les paramètres hexadécimaux correspondants, au moyen de l’interface de saisie d’opérande ;
- créé une fonction de surveillance de la vitesse et d’extinction des phares de travail au moyen de l’interface de programmation, pour que l’éclairage soit automatiquement coupé si le véhicule dépasse la vitesse seuil (qui est synonyme de reprise de la circulation sur route, où les phares de travail doivent être éteints) ;
- associé cette fonction au pilotage des boutons (12) bistables ;
- créé des étiquettes (13) de type infobulle rappelant sur l’interface graphique l’état allumé ou non des phares de travail.

La illustre un boîtier d’interface (10) pour lequel la programmation est achevée, et dont l’interface graphique présente :
- plusieurs zones (14) illustrant l’état de certaines fonctions (et qui ne sont pas rattachées à des boutons) ;
- l’affectation de deux boutons (12) au pilotage de phares de travail.

La est un tableau illustrant la structure d’une trame échangée sur le réseau CAN BUS. On y voit qu’en fonction des conventions adoptées par les différents constructeurs de châssis :
- le premier octet peut être référencé 1 (numérotation des octets de 1 à 8) ;
- le premier octet peut être référencé 0 (numérotation des octets de 0 à 7) ;
- de même pour le premier bit de chaque octet (numérotation de 0 à 7 ou de 1 à 8, et de 0 à 63 ou de 1 à 64).

Ce tableau illustre la nécessité de pouvoir s’adapter à tous les châssis du marché, quelle que soit la convention utilisée, et donc le besoin de pouvoir modifier directement sur le boîtier (10) les paramètres hexadécimaux des opérandes.

La est un extrait d’une documentation constructeur permettant de retrouver la donnée d’entrée désirée au sein des informations circulant sur le réseau CAN BUS du châssis, en vue de l’affecter à un opérande. Pour sélectionner la donnée d’entrée, il faut saisir les paramètres hexadécimaux suivant : identifiant de la trame, octet parmi la trame, le bit de démarrage et la longueur de la donnée au sein de l’octet. La valeur de bit indiquée dans la cinquième colonne permet de savoir quelle est la valeur de la donnée d’entrée sélectionnée.

Le tableau 1 est une illustration récapitulative de la fonction combinatoire destinée à brider la vitesse du véhicule lorsque qu’un élément mobile du véhicule, tel qu’une ridelle, n’a pas été replacé dans sa position de sécurité avant la reprise de la circulation.

Info PTO	Info Vitesse >15km/h	Eléments tous conformes	Bridage vitesse
0	1	0	1
0	1	1	0
0	0	0	1
0	0	1	1
1	1	0	1
1	1	1	1
1	0	0	1
1	0	1	1

Dans le cas illustré, l’info PTO est l’état activé ou non de la prise de force, qui indique :
- si la prise de force est active, l’intention du conducteur du véhicule de rester en situation d’intervention ; ou bien,
- si la prise de force est inactive, son intention de reprendre la route.

L’information vitesse est la surveillance de la vitesse de circulation du véhicule par rapport à un seuil de vitesse, ici 15km/h.

La conformité des éléments est la surveillance du rangement en position de sécurité de l’intégralité des éléments mobiles carrossés sur le châssis.

Si la prise de force est inactive, que le véhicule circule à une allure trop importante, au-delà d’un seuil prédéterminé ici de 15 km/h, et si des éléments ne sont pas dans leur position de sécurité, alors le bridage de vitesse du véhicule sera actif. Le véhicule, dans le cas d’espèce en camion, ne pourra donc pas circuler au-delà du seuil de vitesse préétablie.

Le carrossier peut créer autant de fonctions qu’il le souhaite, à l’instar de cette fonction de bridage de vitesse.

Si de nouveaux éléments mobiles sont rajoutés sur le véhicule, l’utilisation d’une première fonction permettant de vérifier si tous les éléments carrossés sont dans leur position conforme est facile à compléter. Utiliser le résultat de la fonction « les éléments sont tous conformes » sous la forme d’une combinaison d’opérandes permet dans ce cas de rajouter des éléments carrossés sur le véhicule et de ne modifier que la fonction « les éléments sont tous conformes », sans avoir à mettre à jour la fonction de bridage de la vitesse du véhicule.

Il est rappelé que le boîtier (10) selon l’invention est configuré pour que sa programmation soit modifiée : il s’agit bien de rajouter ou de modifier les fonctions combinatoires qui seront ensuite exécutées par le boîtier (10). Il ne s’agit pas d’un simple paramétrage du boîtier (10), au sens commun dans le domaine technique du type réglage de l’heure, ou sélection d’une langue de l’IHM au sein d’une liste.

Par ailleurs, le boîtier (10) peut être conformé différemment des exemples donnés sans sortir du cadre de l’invention, qui est défini par les revendications.

En outre, les caractéristiques techniques des différents modes de réalisation et variantes mentionnés ci-dessus peuvent être, en totalité ou pour certaines d’entre elles, combinées entre elles. Ainsi, le boîtier (10) peut être adapté en termes de coût, de fonctionnalités et de performance.

Claims

Boîtier d’interface (10) pour véhicule professionnel tel qu’un camion, exécutant un programme d’ordinateur programmé pour :
- échanger des données d’entrée et/ou des données de sortie avec un réseau « BUS CAN » du véhicule ;
- coordonner des échanges d’informations et des routines de sécurité entre le châssis du véhicule et des éléments carrossés rajoutés sur le châssis ;
le boîtier (10) comprenant une interface homme machine « IHM » ;
caractérisé en ce que l’IHM est configurée pour afficher une interface graphique de programmation pour créer des fonctions combinatoires de données d’entrée et/ou de données de sorties.
Boîtier d’interface (10) selon la revendication 1, caractérisé en ce que l’interface graphique de programmation comprend un champ d’opérande qui est configuré pour une saisie, par l’utilisateur, de paramètres hexadécimaux d’une donnée d’entrée, tels qu’un identifiant de trame, un bit de démarrage, ou une longueur de codage.
Boîtier d’interface (10) selon l’une des revendications précédentes, caractérisé en ce que l’interface graphique de programmation comprend un champ de fonction qui est configuré pour une saisie, par l’utilisateur, de fonctions combinatoires d’au moins un opérande.
Boîtier d’interface (10) selon la revendication 3, caractérisé en ce que le champ de fonction est configuré pour afficher une liste d’opérandes comprenant :
- des opérandes pré-saisis par le fabricant du boîtier (10) ; et
- des opérandes saisis par l’utilisateur ;
et le champ de fonction est configuré pour que la sélection d’un opérande soit effectuée parmi la liste affichée.
Boîtier d’interface (10) selon la revendication 4, caractérisé en ce que la liste d’opérandes comprend également des combinaisons d’opérandes, définis par des fonctions combinatoires d’au moins un opérande.
Boîtier d’interface (10) selon l’une des revendications précédentes, caractérisé en ce qu’il comprend des boutons (12) et l’interface graphique de programmation comprend une interface graphique d’affectation de bouton (12) qui est configurée pour une saisie, par l’utilisateur, de l’affectation d’une fonction à un bouton (12).
Boîtier d’interface (10) selon la revendication 6, caractérisé en ce qu’un champ d’affectation de bouton (12) est configuré pour programmer un comportement monostable ou bistable d’un bouton (12).
Boîtier d’interface (10) selon l’une des revendications 6 ou 7, caractérisé en ce qu’un champ d’affectation de bouton (12) est configuré pour programmer l’affichage d’une étiquette (13) de bouton (12) sur l’IHM, selon un résultat d’un calcul d’une fonction.
Boîtier d’interface (10) selon l’une des revendications 3 à 8, caractérisé en ce qu’une fonction est une fonction de sécurité susceptible d’identifier une défaillance de sécurité du véhicule.
Boîtier d’interface (10) selon l’une des revendications précédentes, caractérisé en ce qu’une mémoire de stockage du boîtier (10) comprend une base de données d’opérandes, de paramètres hexadécimaux des opérandes, de marque de véhicules et de modèles de véhicules.
Véhicule professionnel tel qu’un camion, comprenant un bus CAN équipé d’un boîtier (10) selon l’une des revendications précédentes.