Le Multiplexage - Partie2

56
CITROËN Chapitre 5
ARCHITECTURES BI VAN CAN
Les architectures ont beaucoup évolué dans le temps.
L’architecture bi VAN CAN est la première architecture électrique électronique

optimisée; avant elle, plusieurs architectures multiplexées comportant un seul
réseau VAN Confort ont été mises en série. Ces architectures comportaient
jusqu’à 7 calculateurs.
Puis, d’autres besoins fonctionnels et d’autres motivations économiques ont

poussé CITROËN à proposer des architectures plus poussées et plus optimisées.
I- RAPPEL : ARCHITECTURE TYPE
L’architecture bi VAN CAN type est en fait une architecture tri VAN CAN puisque
le véhicule comporte 2 réseaux Carrosserie (CAR1 et CAR2) et 1 réseau Confort
basés sur le protocole VAN et 1 réseau Intersystèmes basé sur le protocole CAN.
A - LE RESEAU CAN INTERSYSTEMES

1. COMPOSITION, STRATEGIES D’ECHANGES, SÛRETE DE FONCTIONNEMENT
Le réseau CAN Intersystèmes est un réseau CAN High Speed fonctionnant à un

débit brut de 250 kbits/s.
Les composants de ce réseau sont :
 Le calculateur Electronique Contrôle Moteur (ECM)
 Le calculateur Boîte de Vitesse Automatique (BVA)
 Le calculateur Anti Blocage de Roue (ABS/ESP)
 Le calculateur Angle Volant (CAV)
 Le calculateur Boîtier de Servitude Intelligent (BSI) jouant le rôle de

passerelle vers les autres réseaux du véhicule
La stragétie d’échanges des informations entre ces calculateurs est de type multi-
maîtres, car chaque calculateur peut communiquer à n’importe quel instant.
Chaque calculateur dispose d’un certain nombre de capteurs et d’actionneurs.
LE MULTIPLEXAGE
© AUTOMOBILES CITROËN Toute reproduction ou traduction même partielle sans l'autorisation écrite d'AUTOMOBILES CITROËN est interdite et constitue une contrefaçon
Date du formulaire : 26/06/2003

57
CITROËN Chapitre 5
Les informations sont transmises en utilisant le procédé de diffusion de données

en mode périodique, complété, si nécessaire du procédé événementiel (exemple :
demande de synchronisation entre le moteur et la boîte de vitesse).
Selon la criticité des informations à transmettre, les messages transmis porteront

différents noms :
 Trame dynamique pour les informations à criticité élevée. Exemples :

Angle papillon, régime moteur. Période 10 ms
 Trame données pour les informations à criticité faible. Exemple :

Température d’eau, demande de suspension sport. Période 100 à 200
ms
 Trame synchronisation à criticité élevée. Exemple : Demande de

réduction de couple. Pédiode 20 ms
 Trame version émise une seule fois à la mise sous tension du

calculateur
 Trame supervision informant de l’état du calculateur et des autres

calculateurs. Période 1000 ms
 Trame diagnostic donnant des informations Après-Vente
2. PHASES DE VIE
Les phases de vie du réseau CAN Intersystèmes sont principalement régies par la
présence et l’absence du contact clé (+APC). La figure 5.1 ci-dessous illustre les
mécanismes de veille-réveil du réseau CAN Intersystèmes :
Début de la
communication Arrêt de la
+ APC communication
10 volts
30 s max.
300 ms.
Figure 5.1 : Stratégie de veille – réveil CAN Intersystèmes
LE MULTIPLEXAGE

58
CITROËN Chapitre 5
Suite à la présence contact clé (+APC), tous les calculateurs ont 300 ms
maximum pour s’initialiser et communiquer sur le réseau CAN. La trame de
version doit être émise par chaque calculateur avant l’écoulement de ces 300 ms.
Le réseau CAN est alors réveillé.
Dès la disparition du contact clé, le système doit être placé en veille pour des
besoins d’économie d’énergie : tous les calculateurs doivent s’arrêter de
fonctionner et aller en mode veille, sauf les calculateurs étant en charge d’une
fonction (exemple : Refroidissement moteur par ventilation après l’arrêt du
véhicule). Ces calculateurs sont autorisés à fonctionner pendant 30 secondes et
peuvent même fonctionner pendant plusieurs minutes en auto-alimentation.
Le tableau ci-dessous indique les états de communication d’un calculateur CAN

Intersystèmes en fonction de l’état de la clé et du moteur (tournant ou non
tournant) :
ETAT GMP MNT MNT MNT DEM MT MNT
ETAT CLE Arrêt ACC +APC DEM +APC Arrêt
ETAT Aucune Aucune

Ok entre BSI OK OK Aucune sauf
COMMUNICATION et ECM pour ECU encore
valider le alimentés
démarrage
MNT : Moteur Non Tournant
MT : Moteur Tournant
DEM : Démarreur
+ACC : Plus Accessoires (supprimé pour les architectures Tout CAN)
+APC : Plus Après Contact
LE MULTIPLEXAGE

59
CITROËN Chapitre 5
3. MESSAGERIES FONCTIONNELLES
Les identificateurs des messages ont été créés afin de répondre à des besoins
fonctionnels et de diagnostic.
L’identificateur CAN (11 bits) a été redécoupé pour les besoins de CITROËN en
différentes parties :
ID10 ID9 ID8 ID7 ID6 ID5 ID4 ID3 ID2 ID1 ID0
S5 S4 S3 S2 S1 0 So2 So1 So0 M1 M0

Sujet Diff. Source
Figure 5.2 : Découpage du champ d’identification CAN Intersystèmes
Ces parties sont les suivantes :
 Partie SUJET : Le sujet définit le code du message (dynamique,

véhicule, demande de synchro, diagnostic, …)
 Partie DIFF : Le champ DIFF définit si le message est de type

périodique ou événementiel
 Partie SOURCE : Le champ source définit le calculateur émetteur du

message (Exemple : BVA = 9, Moteur =8, BSI=12, ….)
4. MESSAGERIES DE DIAGNOSTIC, NOTION DE DIAGNOSTIC DES DEFAUTS

(DETECTION, MEMORISATION, EFFACEMENT)
Chaque calculateur du réseau CAN Intersystèmes gère ses propres défauts situés
à sa périphérie directe (entrées capteurs / sorties diverses) et l’état des autres
calculateurs par le procédé de supervision. La supervision consiste à observer un
message émis périodiquement par un calculateur et d’analyser si ce message est
toujours correctement émis en respectant la bonne période d’émission. Si tel n’est
pas le cas (exemple : absence du message observé pendant 3 périodes
consécutives), le calculateur est déclaré absent et une stratégie de défaut (ou
mode dégradé fonctionnel) doit être mise en place.
En général, les durées nécessaires pour déclarer la présence d’un défaut pour
des besoins Après-Vente ou bien pour mettre en place un mode dégradé
fonctionnel ne sont pas les mêmes. En effet, pour mettre en place un mode
dégradé fonctionnel afin d’éviter une perte de fonction qui pourrait gêner le client,
LE MULTIPLEXAGE

60
CITROËN Chapitre 5
la durée pour détecter un défaut est de l’ordre de quelques centaines de

millisecondes (300 à 500 ms en général). Par contre, pour mémoriser un défaut
destiné à être lu et informer le réseau Après-Vente, cette durée sera de l’ordre de
quelques secondes afin de garantir que le défaut est présent pendant au moins
quelques secondes (procédé de filtrage du défaut). Le défaut est détecté et
mémorisé en E²PROM (mémoire non volatile ne perdant pas les informations
même à la coupure de la batterie). Le défaut est alors déclaré présent et
permanent. Par contre, si ce défaut disparaît, le défaut restera présent mais sera
déclaré comme fugitif : Il est fugitif car il est apparu au moins une fois.
Il existe 2 moyens d’effacer un défaut en E²PROM :
 Effacement par un service de diagnostic : Le défaut (qu’il soit fugitif

ou permanent) peut être effacé du calculateur par le réseau Après-
Vente au moyen d’un outil de dagnostic. Pour cela, il faut transmettre
au calculateur un message de diagnostic d’effacement des défauts (voir
chapitre Diag-On-CAN).
 Effacement au bout de 40 cycles de démarrage du véhicule : Le

défaut (qu’il soit fugitif ou permanent) est effacé du calculateur au bou
de 40 cycles de démarrage du véhicule sans aucune apparition du
défaut considéré. Si cette condition est satisfaite, le calculateur efface
de lui-même le défaut correspondant.
5. CODES CALCULATEURS
Chaque calculateur du réseau CAN Intersystèmes détient une adresse source qui
lui est propre et qui est différente de tous les autres calculateurs du réseau.
Cela aboutit à la définition de codes calculateurs appelés quelquefois ‘codes

target’. Ces codes calculateurs sont fournis en Annexe.
LE MULTIPLEXAGE

61
CITROËN Chapitre 5
B - LES RESEAUX VAN CARROSSERIE ET CONFORT

Les réseaux VAN Carrosserie 1 & 2 sont des réseaux VAN fonctionnant à un débit
brut de 62,5 kTS/s.
Les composants du réseau VAN CAR 1 sont :
 Les calculateurs Electronique de Portes Conducteur et Passager (EDP

cond et EDP pass)
 Le calculateur Toit Ouvrant (TO)
 Le calculateur Capteur de pluie (CDPL)
 Le boîtier de mémorisation (BDM)
 Etc…

Les composants du réseau VAN CAR 2 sont :
 Le calculateur Airbag (RBG)
 Le calculateur Haut de Colonne (COM2000)
 Le calculateur Boîtier de Servitude Moteur (BSM)

La stragétie d’échanges des informations entre ces calculateurs et le boîtier BSI

est de type maître-esclaves, car chaque calculateur ne peut communiquer seul sur
le réseau s’il n’a pas été préalablement sollicité par le BSI. Par exemple, si le
client actionne la manette de commandes pour allumer ses codes, le COM2000
n’envoie aucun message sur le réseau. Il attend que le BSI lui demande son état
et lorsque la question du BSI arrive enfin, le COM2000 lui répond. Ce n’est
qu’après avoir analysé la réponse du COM2000 que le BSI transmet un message
de commande d’allumage des codes vers le BSM.
Les informations sont transmises en utilisant le procédé de communication point à

point en mode périodique, complété, si nécessaire du procédé événementiel.
Selon la criticité des informations à transmettre, les messages transmis

nécessiteront des périodes plus courte.
LE MULTIPLEXAGE

62
CITROËN Chapitre 5
Le réseau VAN Confort est un réseau VAN fonctionnant à un débit brut de

125 kTS/s.
Les composants du réseau VAN CONFORT sont :
 Le combiné d’instrumentation (CMB)
 La Radio (RAD)
 L’écran multifonctions (EMF)
 La climatisation (CLIM, TDC)
 Le Chargeur CD

 Etc…

est de type multi-maitres, car chaque calculateur est apte à communiquer ses
états sur le réseau même s’il n’a pas été préalablement sollicité par le BSI. Par
exemple, si le client actionne la molette de volume sur la façade de la radio, celle-
ci envoie un message périodique sur le réseau à destination des calculateurs
ayant besoin de cette information. Cette information va pariculièrement intéresser
l’écran multifonctions qui va afficher une action du client et l’informera d’une
augmentation ou d’une diminution du volume et du niveau de volume en cours.
Les informations sont également transmises en utilisant le procédé de

communication point à point en mode périodique, complété, si nécessaire du
procédé événementiel.

LE MULTIPLEXAGE

63
CITROËN Chapitre 5
2. PHASES DE VIE
Les phases de vie des réseaux VAN Carrosserie et VAN Confort sont orchestrées
par le BSI qui est seul apte à placer les réseaux VAN en mode veille.
La figure 5.3 ci-dessous illustre les mécanismes de veille-réveil des réseaux VAN
Carrosserie et VAN Confort :
Coupure imminente du
Ordre BSI ou réveil par un
+VAN
calculateur
Début de la 5 secondes
communication
+ VAN
10 volts
REVEIL
VEILLE
300 ms. Arrêt de la

communicat
ion
Figure 5.3 : Stratégie de veille – réveil VAN Carrosserie et VAN Confort
Il existe 2 moyens de réveiller les réseaux VAN :
 Suite à un événement interne, le BSI peut décider le réveil des réseaux

VAN. Pour cela, il commute le signal +VAN à Vbat, signalant à tous les
calculateurs présents qu’ils sont autorisés à fonctionner normalement :
C’est la phase de réveil. Ceci peut arriver par exemple lorsque le client
est resté dans le véhicule à l’arrêt pendant plusieurs minutes sans
actionner aucune fonction. Puis, s’il ouvre une des portes du véhicule,
les contacts de portes étant gérés par le BSI, celui-ci provoque un réveil
des réseaux VAN. Lorsque les réseaux sont réveillés, tous les
calculateurs ont 300 ms maximum pour s’initialiser et communiquer sur
le réseau VAN.
 Suite à un événement local à un calculateur (exemple plip HF

communiquant avec le COM2000 pour la décondamnation du véhicule),
le calculateur consomme un courant sur la ligne DATAB. Ce courant est
détecté au niveau du BSI qui commute le signal +VAN à Vbat et réveille
les réseaux VAN. Le BSI questionne ensuite tous les calculteurs et
détecte le calculateur ayant provoqué le réveil du réseau.
LE MULTIPLEXAGE

64
CITROËN Chapitre 5
A l’inverse, il n’existe qu’un moyen de placer les réseaux VAN en mode veille :
 Dès la disparition du contact clé et de toute activité client, le BSI

détecte qu’il doit placer le système en veille pour des besoins
d’économie d’énergie. Avant cela, il va informer tous les calculateurs
que le signal +VAN va être coupé dans les 5 secondes afin que chaque
calculateur puisse sauvegarder des paramètres internes. Après ces 5
secondes, tous les calculateurs doivent s’arrêter de fonctionner et aller
en mode veille. Le BSI coupe le signal +VAN et le système est en veille.
Les identificateurs des messages ont été créés afin de répondre à des besoins
fonctionnels et de diagnostic.
L’identificateur VAN (12 bits) a été redécoupé pour les besoins de CITROËN en
différentes parties :
ID11 ID10 ID9 ID8 ID7 ID6 ID5 ID4 ID3 ID2 ID1 ID0
S5 S4 S3 S2 S1 0/1 St5 St4 St3 St2 St1 0/1
Sujet Diff. / PàP Station M/E
Figure 5.4 : Découpage du champ d’identification des réseaux VAN
Ces parties sont les suivantes :
 Partie SUJET : Le sujet définit les codes des messages émis par un
même calculateur (Exemple : Au sein de la radio, des messages relatifs
aux parties audio, tuner, K7, etc… peuvent être transmis). Deux sujets
sont également réservés pour chaque calculateur pour les besoins de
diagnostic (sujet 14 : requête diagnostic, sujet 15 : Réponse diagnostic)
 Partie DIFF / PàP : Le champ DIFF / PàP définit si le message est de

type diffusion (destiné à tout ou partie des calculateurs ou point à point
avec un calculateur particulier)
 Partie STATION : Le champ STATION définit le calculateur émetteur

du message lorsque le mode Diffusion est utilisé sinon il définit le
calculateur destinataire
 Partie M/E : Le champ M/E définit si le calculateur utilise un composant

de type maître (1) ou esclave (0)
LE MULTIPLEXAGE

65
CITROËN Chapitre 5

Chaque calculateur des réseaux VAN gère ses propres défauts situés à sa
périphérie directe (entrées capteurs / sorties diverses). Il n’y a pas de procédé de
supervision des autres calculateurs.
Les durées nécessaires pour déclarer la présence d’un défaut pour des besoins
Après-Vente ou bien pour mettre en place un mode dégradé fonctionnel sont
similaires à celles utilisées pour le réseau CAN Intersystèmes.
En effet, pour mettre en place un mode dégradé fonctionnel afin d’éviter une perte
de fonction qui pourrait gêner le client, la durée pour détecter un défaut est de
l’ordre de quelques centaines de millisecondes (300 à 500 ms en général). Par
exemple, si le calculateur BSM perd la commnication avec le BSI pendant plus de
400 ms, il enclenche un mode dégradé de fonctionnement consistant à allumer les
codes et à déclencher l’essuie-vitres en petite vitesse.
Par contre, avant de mémoriser un défaut destiné à être lu et informer le réseau

Après-Vente, cette durée sera de l’ordre de quelques secondes (2 secondes) afin
de garantir que le défaut est présent pendant au moins quelques secondes
(procédé de filtrage du défaut). Le défaut est détecté et mémorisé en E²PROM
(mémoire non volatile ne perdant pas les informations même à la coupure de la
batterie). Le défaut est alors déclaré présent et permanent. Par contre, si ce
défaut disparaît, le défaut restera présent mais sera déclaré comme fugitif : Il est
fugitif car il est apparu au moins une fois.
Il existe 2 moyens d’effacer un défaut en E²PROM :
 Effacement par un service de diagnostic : Le défaut (qu’il soit fugitif

ou permanent) peut être effacé du calculateur par le réseau Après-
Vente au moyen d’un outil de dagnostic. Pour cela, il faut transmettre
au calculateur un message de diagnostic d’effacement des défauts (voir
chapitre Diag-On-CAN).
 Effacement au bout de 40 cycles de démarrage du véhicule : Le

défaut (qu’il soit fugitif ou permanent) est effacé du calculateur au bou
de 40 cycles de démarrage du véhicule sans aucune apparition du
défaut considéré. Si cette condition est satisfaite, le calculateur efface
de lui-même le défaut correspondant.
Chaque calculateur des réseaux VAN Carrosserie 1 & 2 et VAN Confort détient
une adresse source qui lui est propre et qui est différente de tous les autres
calculateurs du réseau considéré.
Les codes calculateurs des réseaux VAN sont également fournis en Annexe.
LE MULTIPLEXAGE

66
CITROËN Chapitre 6
ARCHITECTURES FULL CAN
I- RAISONS DU PASSAGE AU FULL CAN : ABANDON DU VAN
Le protocole VAN a été créé par des sociétés françaises (PSA, RENAULT,
VALEO, SAGEM, …) afin de proposer une solution alternative au protocole CAN
créé et promu par la société Robert BOSCH GmbH.
Pour cela, une politique de spécifcation, conception, validation et industrialisation

de composants VAN a été mise en place par les 3 constructeurs automobiles
français (PEUGEOT, CITROËN, RENAULT). Cette politique a été massivement
suivie dès 1987 par nombre de partenaires de composants électroniques comme
SGS-THOMSON, PHILIPS, MATRA MHS, ALCATEL MIETEC, TEXAS
INSTRUMENTS…
Bien que le protocole VAN présentait bon nombre d’avantages techniques

reconnus (possibilité de bâtir des architectures électroniques maître – esclaves
peu chères, possibilité de répondre dans la trame, possibilité d’utiliser le procédé
de diffusion de données mais aussi le procédé point à point), RENAULT a décidé
d’abandonner ce protocole au profit du protocole CAN pour des raisons
industrielles en 1995 par crainte de ne pas pouvoir disposer des composants sur
le marché pour produire ses véhicules.
PSA et CITROËN notamment étant plus avancé que RENAULT sur le sujet, a
choisi de poursuivre les travaux sur le protocole VAN pour les réseaux concernant
l’habitacle et la carrosserie et dans le même temps, d’adopter le protocole CAN
pour les applications Intersystèmes. Ainsi, PSA se rapprochait des architectures
connues chez les autres constructeurs, à savoir :
 Un protocole propriétaire (le VAN) pour les applications confort et

carrosserie
 Un protocole standard (le CAN) pour les applications intersystèmes
Suite à l’abandon du protocole VAN par RENAULT, les partenaires fournisseurs

de composants VAN, TEXAS INSTRUMENTS, PHILIPS et SGS-THOMSON, ont
abandonné à leur tour, préférant les perspectives offertes par le protocole CAN.
D’autres partenaires ont rejoint PSA comme NEC et MITSUBISHI.
Enfin, en 2000, la direction de PSA a décidé d’abandonner à son tour le protocole

VAN, également pour des raisons industrielles et par crainte de rupture de la
production des composants VAN, dont la palette et le choix n’ont pas été jugés
suffisants.
LE MULTIPLEXAGE

67
CITROËN Chapitre 6
II - RAPPEL : ARCHITECTURE TYPE
L’architecture FULL CAN type est constituée classiquement de 4 réseaux CAN, 2

réseaux Carrosserie et Confort utilisant la couche physique CAN Low Speed Fault
Tolerant à 125 Kbits/s, 1 réseau Intersystèmes utilisant la couche physique CAN
High Speed à 500 Kbits/s et 1 réseau Diag utilisant également la couche physique
CAN High Speed à 500 Kbits/s (sauf pour quelques calculateurs ayant conservé
une liaison K pour des besoins de diagnostic constructeur ou pour le diagnostic
réglementaire lié au contrôle de la pollution).
A - LE RESEAU CAN INTERSYSTEMES
Lors du basculement des architectures bi VAN CAN vers les architectures FULL
CAN, le réseau CAN Intersystèmes utilisant la couche physique CAN High Speed
est passé d’un débit de 250 Kbits/s à un débit de 500 Kbits/s.
Les composants de ce réseau sont :
 Le calculateur Electronique Contrôle Moteur (ECM)
 Le calculateur Boîte de Vitesse Automatique (BVA)
 Le calculateur Anti Blocage de Roue (ABS/ESP)
 Le calculateur Angle Volant (CAV)
 Le calculateur Groupe ElectroPompe (GEP)
 Le calculateur Détection de Sous Gonflage (DSG)
 Le calculateur de Suspension (BHI)

La stragétie d’échanges des informations entre ces calculateurs est de type multi-
maîtres, car chaque calculateur peut communiquer à n’importe quel instant.
Chaque calculateur dispose d’un certain nombre de capteurs et d’actionneurs.
Les informations sont transmises en utilisant le procédé de diffusion de données

en mode périodique, complété, si nécessaire du procédé événementiel.
LE MULTIPLEXAGE

68
CITROËN Chapitre 6
2. PHASES DE VIE : FONCTIONNEMENT DU SIGNAL RCD
Les phases de vie du réseau CAN Intersystèmes sont principalement régies par la
présence et l’absence du contact clé (+APC). Cependant, un signal
supplémentaire a été créé lors de l’évolution vers les architectures FULL CAN, le
signal RCD (Réveil Commandé à Distance). Ce signal est destiné à réaliser un
réveil total (comme pour la mise sous contact du +APC) ou partiel du réseau CAN
pour anticiper la réalisation de certaines fonctions.
Concernant le réveil lié au signal +APC, ce réveil fonctionne de la même manière

que celui décrit dans le chapitre 5.A.2.
Suite à la présence contact clé (+APC), tous les calculateurs connectés au +APC
sont réveillés et passent en mode normal : il s’agit d’un réveil principal.
Le signal RCD a également le rôle de réveiller le réseau CAN Intersystèmes mais

il est accompagné d’un message de réveil contenant un mot d’état indiquant quel
calculateur est concerné par le réveil.
 Lorsque le mot d’état vaut ‘Réveil principal’, tous les calculateurs

connectés au signal RCD se réveillent et passent en mode normal.
 Lorsque le mot d’état est différent de ‘Réveil principal’, le réveil

correspondant est partiel. Tous les calculateurs connectés au signal
RCD se réveillent mais seuls concernés par ce réveil partiel passent en
mode normal, les autres se rendormant.
Les réveils partiels peuvent être demandés dans les conditions suivantes :
 BSI -> ECM : anticiper le démarrage (Anti Démarrage Codé)

 BSI -> ECM : contrôler le niveau de carburant (détection de fuite)
 BSI -> BVA AM6 : obtenir des infos boîte nécessaires au démarrage
 BSI -> BVMP : obtenir des infos boîte nécessaires au démarrage
 BSI -> BVMP : changer de rapport après coupure du contact
 BSI -> UC Frein : obtenir l’info vitesse véhicule
 BSI -> BHI : modifier la hauteur de caisse à l’arrêt du véhicule
 BSI -> EHB : éviter la sensation de pédale « molle » (projet)
 BSI -> AR2S : raccourcir le temps de démarrage (projet)
 EHB -> BSI : signaler un défaut de frein à l’arrêt du véhicule (projet)
 FSE -> BSI : signaler un défaut de frein de parking à l’arrêt du véhicule
(projet)
LE MULTIPLEXAGE

69
CITROËN Chapitre 6
 DSG -> BSI : assurer le déverrouillage des portes à l’arrêt (si PLIP
version Japon)
Le procédé de mise en veille est identique à celui décrit dans le paragraphe 5.A.2.
Les identificateurs des messages CAN Intersystèmes ont subi une légère
modification car seuls les champs SUJET et SOURCE ont été conservés pour
répondre aux besoins fonctionnels, systèmes et diagnostic.
S5 S4 S3 S2 S1 S0 S4 S3 S2 S1 S0
Sujet Source
Figure 6.1 : Découpage du champ d’identification

du réseau CAN Intersystèmes
Ces champs sont les suivants :
 Partie SUJET : Le sujet définit le code du message (dynamique,

véhicule, demande de synchro, diagnostic, …)
 Partie SOURCE : Le champ source définit le calculateur émetteur du

message (Exemple : BVA = 9, Moteur =8, BSI=12, ….)

Le principe des messages de diagnostic n’a pas évolué, chaque calculateur du

réseau CAN Intersystèmes gèrant ses propres défauts situés à sa périphérie
directe (entrées capteurs / sorties diverses) et l’état des autres calculateurs par le
procédé de supervision.
Le procédé de gestion des défauts, de leur filtrage, de leur mémorisation et de leur

effacement est identique.
Les codes des calculateurs n’ont pas changé, certains codes ayant été créés suite
à l’ajout de nouvelles fonctions comme le calculateur DSG (Détection de Sous
Gonflage, code 26).
LE MULTIPLEXAGE

70
CITROËN Chapitre 6
B - LES RESEAUX CAN CARROSSERIE ET CONFORT
Lors du basculement des architectures bi VAN CAN vers les architectures FULL
CAN, les réseaux VAN Carrosserie 1 et 2 ont été transformé en 1 seul et unique
réseau CAN Carrosserie. La principale modification de ce réseau est la
suppression des calculateurs Electroniques De Porte (EDP) pour des raisons de
sûreté de fonctionnement : les 2 calculateurs EDP ont été placés sur le réseau
CAN Confort. Le débit des réseaux VAN Carrosserie a également évolué de
62,5 KTS/s à 125 Kbits/s.
Le réseau VAN Confort a été transformé en CAN Confort mais exceptée l’arrivée
des calculateurs EDP, ce réseau n’a pas subi d’importantes modifications.
L’essentiel des calculateurs déjà existants ont été conservés et le débit a
également été conservé égal à 125 Kbits/s.
Une grande évolution est la couche physique CAN Low Speed Fault Tolerant, qui,
comme son nom l’indique, est tolérante aux pannes physiques pouvant survenir
sur les lignes de communication CAN-H ou CAN-L.
(MODES SECOURS, …)
a) Réseau CAN Carrosserie

Le réseau CAN Carrosserie fonctionne à un débit brut de 125 kbits/s.
Les composants du réseau CAN CAR sont :
 Le calculateur Toit Ouvrant (TO)
 Le calculateur Capteur de pluie (CDPL)
 Le boîtier de mémorisation (BDM)
 Le boîtier de mémorisation (BSM)
 Le calculateur Airbag (RBG)
 Le calculateur COM2000 (HDC)
 Etc…

LE MULTIPLEXAGE

71
CITROËN Chapitre 6
Une des évolutions majeures est également la stragétie d’échanges des

informations entre ces calculateurs et le boîtier BSI : celle-ci n’est plus de type
maître-esclaves, mais de type multi-maîtres car chaque calculateur peut
communiquer seul sur le réseau même s’il n’a pas été préalablement sollicité par
le BSI. Par exemple, si le client actionne la manette de commandes pour allumer
ses codes, le COM2000 envoie périodiquement un message sur le réseau
indiquant l’état des commandes. Le BSI analyse la réponse du COM2000 et
transmet un message de commande d’allumage des codes vers le BSM.
Les informations sont transmises en utilisant le procédé de communication

diffusion en mode périodique, complété, si nécessaire du procédé événementiel.
Ce type de communication est beaucoup plus adapté pour le protocole CAN.

b) Réseau CAN Confort

Le réseau CAN Confort fonctionne à un débit brut de 125 kbits/s.
Les composants du réseau CAN CONFORT sont :
 Le combiné d’instrumentation (CMB)
 La Radio (RAD)
 L’écran multifonctions (EMF)
 La climatisation (CLIM, TDC)
 Le Chargeur CD
 Les calculateurs Electronique de Porte (EDPcond et EDPpass)

 Etc…

est de type multi-maitres, car chaque calculateur est apte à communiquer ses
états sur le réseau même s’il n’a pas été préalablement sollicité par le BSI. Par
exemple, si le client actionne la molette de volume sur la façade de la radio, celle-
ci envoie un message périodique sur le réseau à destination des calculateurs
ayant besoin de cette information. Cette information va pariculièrement intéresser
l’écran multifonctions qui va afficher une action du client et l’informera d’une
augmentation ou d’une diminution du volume et du niveau de volume en cours.
LE MULTIPLEXAGE

72
CITROËN Chapitre 6
Les informations sont également transmises en utilisant le procédé de

communication diffusion en mode périodique, complété, si nécessaire du procédé
événementiel.

2. PHASES DE VIE
Les phases de vie sont les différentes phases que doivent respecter les
calculateurs en fonction de l’état du véhicule. En effet, si le moteur est arrêté et
qu’aucune fonction n’est utilisée depuis plus d’une minute, le système se met en
veille afin d’économiser l’énergie de la batterie.
Les différentes phases des calculateurs sont représentées dans la figure 6.2 ci-
dessous :
Alimentation +VBAT / VEILLE

 +CAN absent
 Aucune communication
Etat
Etat
VEILLE
VEILLE
 +CAN présent
 +CAN présent
 Aucune communication fonctionnelle,
 +CAN présent sauf besoinscommunication
 Aucune fonctionnels spécifiques
fonctionnelle,
Aucuneprésent
 +CAN communication fonctionnelle
 Trames
sauf defonctionnels
besoins REVEIL présentes
spécifiques
 Aucune communication fonctionnelle
 Trames de REVEIL présentes
Etat
15 s MISE-en-
Etat
Etat
REVEIL
50 ms
VEILLE Etat
15 s MISE-en- REVEIL
50 ms
VEILLE
Perte COM MODE
DEGRADE
Perte COM MODE
Retour COM DEGRADE
Retour COM
Etat Pour certains calculateurs
NORMAL  +CAN présent seulement: émission de
Etat  Communications fonctionnelles actives messages
Pour certainsfonctionnels
calculateurs
NORMAL seulement: émission de

 messages fonctionnels
 +CAN présent
 Communications fonctionnelles inactives
 Communications Diag / Télé
-chargement / Télé
-codage autorisées
Etat  +CAN présent
COM-OFF  Communications fonctionnelles inactives
 Communications Diag / Télé
-chargement / Télé
-codage autorisées
Etat
COM-OFF
Figure 6.2 : Phases de vie des réseaux CAN Carrosserie et Confort
Lorsqu’une action utilisateur est détectée soit par le BSI soit par un calculateur
apte à effectuer le réveil du système, le système passe de la phase VEILLE à la
phase REVEIL. Cet état est un état transitoire où les calculateurs demeurent
environ 50 ms. Puis, le BSI ordonne le passage en mode normal et tous les
calculateurs adoptent le mode NORMAL où toutes les fonctionnalités sont
assurées.
LE MULTIPLEXAGE

73
CITROËN Chapitre 6
Si un outil de diagnostic est connecté au véhicule pour des besoins de

téléchargement d’un calculateur CAN Carrosserie ou CAN Confort, le BSI
demande aux calculateurs d’adopter le mode COM-OFF où ils doivent couper leur
communication afin de laisser le réseau CAN libre pour le téléchargement
considéré. Après celui-ci, le BSI ordonne à tous les calculateurs de retourner en
mode NORMAL. Toute leurs fonctionnalités peuvent à nouveau être assurées.
Si pendant ce mode NORMAL, un des calculateurs perd la communication avec le

BSI, et selon s’il doit assurer ou non une fonction de secours (allumage des
codes, enclenchement des essuie-vitres), il adopte alors le mode DEGRADE de
fonctionnement. Le retour au mode NORMAL sera réalisé dès que le calculateur
aura retrouvé la communication avec le BSI.
Enfin, si le moteur du véhicule est coupé et si aucune fonction client n’est activée
pendant plus d’une minute, le BSI ordonne à tous les calculateurs de se placer en
mode MISE EN VEILLE. Cet état est un état transitoire où les calculateurs
demeurent 15 secondes avant de passer en mode VEILLE.
3. REGLES DE COMMUNICATION
a) Modes de transmission, sécurisation des échanges

Les modes de transmission utilisés sont une combinaison de plusieurs modes :
 Le mode périodique : Le mode de transmission périodique consiste à

émettre périodiquement un ou plusieurs messages vers d’autres
calculateurs ayant besoin du contenu de ces messages afin de réaliser
une fonction. Afin de réaliser cette fonction dans des conditions fiables,
la tolérance de la période d’émission doit être meilleure que +/-10%.
 Le mode événementiel : Le mode événementiel consiste à émettre un

message dès qu’une valeur interne a changé. Ce message n’est émis
qu’une seule fois. Un temps maximal de traitement sera assuré entre le
changement de la valeur interne et l’émission du message sur le
réseau.
 Le mode mixte : Le mode mixte, périodique complété du mode

événementiel, combine les 2 méthodes. Cela permet la fiabilité apporté
epar le mode périodique et la réactivité apportée par le mode
événementiel.
Les échanges sont sécurisés par la robustesse du protocole CAN lui-même

notamment par l’acquittement de protocole qui permet de vérifier si les messages
sont correctement transmis. Si ce n’est pas le cas, il n’y a pas d’acquittement
protocole et l’application s’en aperçoit car elle ne reçoit aucun compte-rendu de
transmission correcte. Si tel est le cas, elle doit stopper immédiatement l’émission
en cours afin de ne pas occuper sans cesse le réseau car le contrôleur de
protocole cherchera à émettre sans cesse en absence d’acquittement.
LE MULTIPLEXAGE

74
CITROËN Chapitre 6
b) Segmentation des données : Besoins et principes

Le protocole CAN permet des échanges de messages constitués de 8 octets de
données maximum.
Dès que des calculateurs souhaitent échanger des informations dépassant la taille
maximale autorisée par le protocole CAN, il est nécessaire de segmenter ces
informations. Cela revient à les couper en morceaux ou segments et les
transmettre selon un procédé normalisé.
Le procédé de segmentation est utilisé par certains calculateurs pour transmettre

leurs informations fonctionnelles (navigation, téléphone, …) mais cela reste assez
rare.
Par contre, la segmentation des données est toujours utilisée pour les besoins de
diagnostic (communication diagnostic avec les calculateurs et besoins de
téléchargement).
Le principe est illustré par la figure 6.3 ci-dessous :
Producteur Consommateur
Début
Stmin = 10 ms
Stmin = 10 ms
Fin
Figure 6.3 : Exemple d’échange segmenté
LE MULTIPLEXAGE

75
CITROËN Chapitre 6
Dans cet exemple, un calculateur producteur souhaite transmettre 24 octets de

données.
 Pour cela, il utilise le procédé de segmentation des données qui est

initié par l’envoi d’un message appelé ‘First Frame’ symbolisé en rouge.
Ce message a la particularité de toujours contenir un premier octet de
donnée commençant par 1. Cela symbolise la First Frame qui marque
l’ouverture de la session de segmentation. Ce premier octet est suivi du
nombre d’octets à échanger : ici 018 soit 24 octets (codage
hexadécimal)
 Suite à la réception de ce message ‘First Frame’, le consommateur des

données envoie un message ‘Flow Control’ afin de contrôler l’échange
avec le producteur. Ce message a la particularité de toujours contenir
un premier octet de donnée commençant par 3. Cela symbolise la Flow
Control Frame. Ce message contient ensuite 3 informations
importantes :
 Le Flow Status indiquant si le consommateur est prêt à recevoir ou si

le producteur doit attendre.
 Le Bloc Size indiquant le nombre maximal de messages que le

producteur est autorisé à envoyer par bloc.
 Le ST min indiquant le temps minimal que le producteur doit

respecter entre chaque trame. Ce temps est exprimé en
millisecondes.
 Tout ceci a pour rôle de réguler l’échange entre le producteur et le

consommateur
 Enfin, le producteur lorsqu’il reçoit le message Flow Control et s’il est

autorisé à transmettre, envoie les messages Consecutive Frames
(symbolisés en vert). Ces messages ont la particularité de toujours
contenir un premier octet de donnée commençant par 2, suivi du
numéro du message (21, 22, 23, …), et respectent les informations
transmises par le consommateur (Bloc Size et ST min) : les messages
doivent être transmis par paquets de N (Bloc Size différent de 0) ou
d’un seul coup (Bloc Size égal à 0), et seront séparés au minimum du
temps ST exprimé en millisecondes
Le procédé de segmentation est complètement normalisé et les

dysfonctionnement sont également traités : Pour cela, différentes contraintes de
temps sont à respecter par le producteur et le consommateur. Si ces contraintes
de temps ne sont pas respectées, une erreur de segmentation se produit et
chacun des calculateurs devra reprendre la session depuis le début.
LE MULTIPLEXAGE

76
CITROËN Chapitre 6
4. SUPERVISION
Le procédé de supervision vise à augmenter la fiabilité des réseaux CAN.
Le principe consiste pour chaque calculateur de superviser un ou plusieurs

calculateurs avec lesquels il est en relation fonctionnelle. De plus, la tâche de
supervision doit également gérer un certains nombre de compteurs de défauts liés
à un certain nombre de pannes redoutées.
Cette tâche de supervision propre à chaque calculateur peut être activée ou

désactivée en fonction de la phase de vie du véhicule. C’est le calculateur contrôle
moteur qui transmet un bit DIAG-MUX-ON qui indique si cette tâche est active ou
inactive. Le BSI relaye cette information sur les réseaux CAN Low Speed.
a) Types de défauts liés au multiplexage

Parmi les défauts liés au multiplexage, il est possible de citer :
 Défaut NERR : Erreur physique sur une des deux lignes CAN (réseaux
CAN Low Speed). Ce défaut apparaît dans le joournal des défauts.
 Calculateur absent : Un calculateur supervisé a été détecté absent.

Pour cela, un de ses messages périodiques a été détecté absent
pendant 3 périodes consécutives. Ce défaut apparaît dans le joournal
des défauts.
 Calculateur muet : Le calculateur ne parvient pas à émettre ses

messages périodiques. Ce défaut n’apparaît pas dans le joournal des
défauts, le calculateur étant muet.
 Calculateur en Bus Off : Un nombre d’erreurs important en transmission

s’est produit et a conduit le calculateur à se déconnecter du réseau
(Etat Bus Off)
b) Conditions de détection, filtrage, mémorisation,

effacement des défauts
Chaque calculateur gère les défauts situés à sa périphérie directe (entrées
capteurs / sorties diverses).
Les durées nécessaires pour déclarer la présence d’un défaut pour des besoins
Après-Vente ou bien pour mettre en place un mode dégradé fonctionnel sont
différentes.
LE MULTIPLEXAGE

77
CITROËN Chapitre 6
En effet, pour mettre en place un mode dégradé fonctionnel afin d’éviter une perte
de fonction qui pourrait gêner le client, la durée pour détecter un défaut est de
l’ordre de quelques centaines de millisecondes (300 à 500 ms en général). Par
exemple, si le calculateur BSM perd la commnication avec le BSI pendant plus de
400 ms, il enclenche un mode dégradé de fonctionnement consistant à allumer les
codes et à déclencher l’essuie-vitres en petite vitesse.
Par contre, avant de mémoriser un défaut destiné à être lu et informer le réseau

Après-Vente, cette durée sera de l’ordre de quelques secondes (2 secondes) afin
de garantir que le défaut est présent pendant au moins quelques secondes
(procédé de filtrage du défaut). Le défaut est détecté et mémorisé en E²PROM
(mémoire non volatile ne perdant pas les informations même à la coupure de la
batterie). Le défaut est alors déclaré présent et permanent. Par contre, si ce
défaut disparaît, le défaut restera présent mais sera déclaré comme fugitif : Il est
fugitif car il est apparu au moins une fois.
Messages périodiques émis / reçus Messages périodiques émis / reçus

Compteur C_xx
t
255
DETECTION
t
0
 2 secondes  2 secondes
Etat ECU Pas de défaut Mode dégradé Pas de défaut
Etat JDD Pas de défaut Permanent Fugitif
Figure 6.4 : Détection, filtrage, mémorisation des défauts
La figure 6.4 ci-dessus indique les critères de détection, les mécanismes de

filtrage et les conditions de mémorisation dans le calculateur et dans le journal des
défauts du BSI.
LE MULTIPLEXAGE

78
CITROËN Chapitre 6
c) Journal des défauts

Le journal des défauts du BSI est une mémoire des défauts stockés par le BSI
suite la réception de messages ‘EVENEMENT_DEFAUT’ transmis par les
calculateurs ayant détecté l’apparition ou la disparition d’un défaut.
Suite à la réception d’un message d’apparition ou de disparition de défaut, le BSI

stocke cette information dans ce journal avec les principales données liées au
contexte véhicule comme le kilométrage, la tension de la batterie, la température
extérieure, l’état du système (arrêt, démarrage, roulage), etc…
Ces données permettront plus tard à l’intervenant de situer le contexte dans lequel
est apparu ou a disparu un défaut et lui permettront peut être d’en comprendre la
cause et d’en rechercher l’origine.
Les messageries VAN ont été transformées en messageries CAN avec beaucoup
de bouleversements. Ceci a été principalement dû à la capacité maximale de 8
octets de données possible en CAN comparativement aux 28 octets de données
en VAN.
Les identificateurs des messages VAN ont été transformés en identificateurs CAN
en adoptant le découpage décrit par la figure 6.5 ci-dessous :
T1 T0 Su2 Su1 Su0 UCE5 UCE4 UCE3 UCE2 UCE1 UCE0

Type
Typ Sujet
Sujet Num UCE
NUM_UCE
e
Figure 6.5 : Découpage du champ d’identification

des réseaux CAN Carrosserie et CAN Confort
LE MULTIPLEXAGE

79
CITROËN Chapitre 6
Les champs constituants les identificateurs sont les suivants :
 Partie TYPE : Le TYPE définit le type de message véhiculé
 00 et 01 : Il s’agit de messages fonctionnels
 10 : Il s’agit de messages système
 11 : Il s’agit de messages de diagnostic
 Partie SUJET : Le champ SUJET dépend du type de message.
 Exemples de messages système :
 000 : Message de réveil
 100 : Message de supervision
 111 : Message version
 Exemples de messages de diagnostic :
 101 : Requête diagnostic CAN Low Speed
 001 : Réponse diagnostic CAN Low Speed
 0101 : Requête diagnostic CAN High Speed
 0101 : Réponse diagnostic CAN High Speed
 Partie NUM_UCE : Le champ NUM_UCE définit le calculateur émetteur

ou destinataire du message
 Les messages de diagnostic répondent tous au procédé de

segmentation. Toute requête et toute réponse de diagnostic répond à
ce procédé.
 La raison en est simple : Les informations liées au diagnostic

dépassent quasiment toutes 8 octets.
LE MULTIPLEXAGE

80
CITROËN Chapitre 6
 Exemples de messages de diagnostic :
 101 : Requête diagnostic CAN Low Speed
 001 : Réponse diagnostic CAN Low Speed
 0101 : Requête diagnostic CAN High Speed
 0101 : Réponse diagnostic CAN High Speed
 Exemples d’échange de diagnostic :
 Requête diagnostic d’identification vers la Climatisation
 La réponse de la Climatisation, contenant 24 octets

d’identification, va commencer par un message First Frame, suivi
d’un message de Flow Control envoyé par le BSI, suivi des
messages de Consecutive Frames transmis par la Climatisation
Les codes des calculateurs n’ont pas changé, certains codes ayant été créés suite
à l’ajout de nouvelles fonctions comme le calculateur AFIL ou BSR.
LE MULTIPLEXAGE

92
CITROËN Chapitre 8
LE PROTOCOLE LIN
III - HISTORIQUE DU PROTOCOLE LIN
Le protocole LIN a été créé en 1998, par un consortium d’entreprises regroupant

MOTOROLA, BMW, DAIMLER CHRYSLER, VOLKSWAGEN, VOLVO et
VOLCANO.
La création de ce protocole a suivi les étapes principales suivantes :
 Octobre 1998 : création d’un groupe de travail autour d’un protocole bas coût
/ bas débit
 Juillet 1999 : Apparition d’un premier document de spécification
 Mars 2000 : Création d’un consortium LIN par Audi, BMW, Daimler Chrysler,
Volvo, Volkswagen, Volcano et Motorola.
 Novembre 2000 : Diffusion de la spécification LIN 1.2
 Septembre 2003 : Diffusion de la spécification LIN 2.0
 2004 : 1ere application LIN en série chez CITROËN sur X3 (nouvelle C5) sur
les applications AFIL (Alerte Franchissement Involontaire de Ligne) et
Projecteurs Directionnels
IV - RAISONS DE L’UTILISATION D’UN SOUS RESEAU LIN (EN COMPLEMENT

DU CAN)
Les protocoles VAN et CAN ont tous deux des compétences et performances
similaires. Ce sont des protocoles de communication bien adaptés aux besoins de
contrôle / commande, dont le coût reste moyen et dont la robustesse est
nécessaire. Les débits maximum autorisés par ces protocoles sont de l’ordre de 1
Mbits/s (sur une distance maximale de 40 mètres).
Par contre, ils restent encore chers et trop complexes lorsque les fonctions à
multiplexer sont assez simples et ne présentent pas de possibilité d’économie
significative en terme de suppression de fils (pilotage d’un moteur de serrure, …).
Le protocole LIN est donc utilisé en complément des protocoles VAN et CAN et
non en remplacement de ceux-ci.
LE MULTIPLEXAGE

93
CITROËN Chapitre 8
De plus, l’adoption du protocole LIN permet d’éradiquer bon nombre de liaisons

séries en tout genre proposées par les équipementiers et dont les principales
caractéristiques suivantes ne sont pas maîtrisées :
 Compatibilité Electromagnétique (CEM) non maîtrisée
 Mécanisme de veille / réveil inexistant donc la consommation n’est pas

maîtrisable
 Absence de diagnostic
V- PRINCIPALES CARACTÉRISTIQUES DU PROTOCOLE LIN
Le protocole LIN est un protocole simple, bas débit et bas coût dont les principales
caractéristiques sont listées dans le tableau suivant :
L’amplitude des signaux sur la ligne LIN est comprise entre 0 et 12 volts.
LE MULTIPLEXAGE

94
CITROËN Chapitre 8
A - CONCEPT
Le protocole LIN a été inventé dans le but de mettre en relation des systèmes
communicants simples entre eux. Ce protocole est conçu afin de mettre en
relation des éléments simples et esclaves avec un maître qui assurera le
cadencement du réseau.
Seul le maître du réseau LIN est habilité à prendre la parole :
 Pour commander les esclaves
 Pour récupérer l’état des esclaves
La figure ci-dessous illustre le concept LIN :
A: B:
Maître Esclave
Commande
1
Entête + Donneés
A: B:
Maître Esclave
Requête Réponse
Requête
1
Entête Données
Figure 7.1 : Concept LIN
LE MULTIPLEXAGE

95
CITROËN Chapitre 8
B - ARCHITECTURES ACTUELLES
Les architectures actuelles faisant appel aux protocoles VAN et CAN ont permis
de réaliser un premier niveau de multiplexage ayant abouti à la suppression
d’un grand nombre de fils et d’interconnexions.
Cependant, comme l’indique la figure ci-dessous, même si les liaisons entre les
calculateurs VAN ou CAN sont aujourd’hui optimisées, les liaisons entre un
calculateur et ses capteurs et/ou actionneurs ne sont pas toujours
multiplexées. La raison principale avant l’adoption du protocole LIN, était
principalement le coût, le VAN et le CAN étant tous deux trop chers.
Abonné du réseau véhicule

Maître du réseau véhicule Capteurs / actionneurs
Liaisons filaires
ou séries propriétaires
Bruiteur
CAN LS véhicule Voyants
Calc. A Calc. B
Moteur 1
Capteur 1
Commande 1-
Sonde 1
Etc…
Calculateur avec faisceau secondaire
Figure 7.2 : Architectures actuelles sans LIN
LE MULTIPLEXAGE

96
CITROËN Chapitre 8
C - ARCHITECTURE AVEC L’APPORT DU PROTOCOLE LIN
Avec l’apport du protocole LIN, les liaisons entre certains calculateurs et leurs
capteurs et/ou actionneurs sont aujourd’hui multiplexées. Pour chaque
calculateur, une balance économique est calculée et l’électronique à rajouter
dans les capteurs / actionneurs est comparée aux fils supprimés
Dans le cas où la balance économique est favorable, le faisceau secondaire est

supprimé au profit d’un sous-réseau LIN reliant les capteurs / actionneurs au
calculateur, comme illustré dans la figure ci-dessous :
Maître du réseau véhicule Abonné du réseau véhicule Esclaves LIN
CAN LS véh. LIN Calc. C

Bruiteur
Calc. A Calc. B Commande 1
Voyants
Moteur 1 Calc. D
Maître du réseau secondaire LIN Capteur 1
Sonde 1 Calc. E
Figure 7.3 : Architecture actuelle avec LIN
D - PRINCIPALES CARACTERISTIQUES DU PROTOCOLE LIN
Le nombre maximum de nœuds LIN sur le même bus est 16 et la longueur

maximale autorisée entre les 2 calculateurs les plus éloignés du système, est
40 mètres.
1. Médium de transmission
Le médium de transmission c’est à dire le support matériel ou immatériel de

transmission des signaux LIN n’est pas imposé par la norme LIN. La norme
propose un médium de transmission de type filaire (cuivre) en fil simple.
LE MULTIPLEXAGE

97
CITROËN Chapitre 8
2. Structure d’un nœud
Un calculateur LIN dispose d’une interface standardisée (standard LIN) lui

permettant d’interopérer avec d’autres calculateurs LIN. Cette interface
électronique standardisée répond à des critères de coût très sévères qui
imposent d’utiliser des cellules standard dans les microcontrôleurs actuels :
La cellule de base est l’UART (Universal Asynchronous Receiver
Transmitter) comme dans le cas d’une liaison série RS-232 :
Médium de communication
LIN
UART intégré dans le composant Microcontrôleur
INTERFACE
Rx APPLICATION
DE
+
UART LIN
LIGNE
Tx
LIN
Nœud LIN
Figure 7.4 : Structure d’un nœud LIN
LE MULTIPLEXAGE

98
CITROËN Chapitre 8
Cette interface est constituée de 2 éléments majeurs :
Le contrôleur de protocole (CP LIN), qui est réalisé sur la base d’un UART
standard intégré dans un microcontrôleur qui a la charge de gérer le
protocole LIN par logiciel en réalisant les fonctions principales suivantes :
 Emission / réception des octets
 Constitution des trames de requêtes, réception des trames de réponse
 Séquencement des émissions
 Etc…
L’interface de ligne qui a la charge de traduire la ligne du bus LIN en signal

RX dépourvu de parasites vers le CP LIN et inversement, le signal TX issu
du CP LIN, en signal vers le bus LIN. Ce composant a donc 2 rôles majeurs,
de traduction et de protection.
3. Structure d’une trame
Une trame LIN est constituée d’une suite d’octets séparés de temps inter-
octets :
Figure 7.5 : Structure d’une trame LIN
 Le champ Synchro Break marque le début de la trame LIN. Il est émis

par le nœud maître du réseau LIN et permet à tous les nœuds LIN
présents sur le bus d’auto-adapter leur vitesse
 Le champ de synchronisation permet à tous les nœuds LIN présents

sur le bus de se synchroniser
LE MULTIPLEXAGE

99
CITROËN Chapitre 8
 Le champ d’identification IDEN permet d’identifier jusqu’à 64 nœuds

LIN. Il indique le destinataire des données ou l’adresse du nœud
questionné
 Le champ données, constitué de 1 à 8 octets, contient les informations

utiles de la commande ou de la réponse
 Le champ checksum constitué de 1 octet permet de garantr l’intégrité

du contenu de la trame LIN
4. Codage LIN
Le codage utilisé pour un bit LIN fait appel au codage NRZ (figure 7.6).
5V
0V
Bit 1 Bit 0
Figure 7.6 : Codage NRZ
5. Modes de transmission
Les modes de transmission utilisés par un calculateur LIN sont identiques

aux 3 modes de transmisions utilisés par les calculateurs VAN et CAN :
 Le mode de transmission périodique
 Le mode événementiel
 Le mode mixte, périodique et événementiel
LE MULTIPLEXAGE

100
CITROËN Chapitre 8
6. Accès au médium de transmission
Un calculateur LIN maître accède au médium de transmission de façon

aléatoire et asynchrone. Cela signifie simplement que cet accès peut se faire
à n’importe quel moment sur besoin et décision locale de l’application.
L’accès au réseau LIN sur décision locale n’est pas possible pour les nœuds
LIN esclaves. Pour pouvoir entrer en communication, il est nécessaire qu’ils
y soient préalablement invités par le nœud maître LIN, par l’intermédiaire
d’une question.
7. Services
Les calculateurs LIN disposent de 3 services de communication :
 L’écriture de données en mode diffusion (envoi de données d’un

producteur vers plusieurs consommateurs)
 La requête de données (requête de données d’un consommateur vers

un producteur)
 La réponse immédiate (réponse immédiate à une requête)
Ces services permettent de mettre au point la stratégie mono maître- multi-

esclaves (diffusion et requête / réponse)
8. Acquittement LIN
Il n’y pas d’acquittement prévu par la norme LIN même si rien n’empêche
d’envoyer une trame LIN de confirmation (acquittement logiciel).
E - NOTION DE DEBIT BRUT ET DEBIT NET
Le débit brut est celui qui est mesuré sur le réseau. Pour cela, il faut identifier
l’entité la plus petite dans une trame LIN (un bit)
Le débit brut vaut alors : 1/Tbit soit l’inverse de la durée d’un bit
 Exemple : Si le bit est identifié comme valant 50 µs, le débit LIN brut est :
20 Kbits/s
Le débit net est celui qui est calculé en tenant compte du nombre total de bits
utilisé dans une trame par rapport au nombre de bits d’informations utiles
réellement échangées.
Le débit net vaut alors : N bits de données / M bits total
 Exemple : Pour faire ce calcul, il faut identifier tous les bits transmis dans
une trame LIN, en reprenant tous les champs la constituant :
LE MULTIPLEXAGE

101
CITROËN Chapitre 8
 Champs break (13 bits), Synchro (10 bits), Iden (10 bits), Checksum
(10 bits) + Données (2 bits x N octets)
 Champ données : N octets (1 à 8 octets de données) x 8 bits
 Par conséquent :
Débit net pour 1 octet = 8/(45+8) * 20 Kbits/s = 3,02 Kbits/s
Débit net pour 8 octets : 64/ (59+64) * 20 Kbits/s = 10,4 Kbits/s
En résumé, même si le débit apparent (débit brut) semble suffisant, il est

nécessaire, au niveau de la conception d’un système multiplexé, de calculer le
débit réel utile pour transmettre les informations. Pour quelques cas, il peut
apparaître que le débit net ne dépasse pas 15,1% (3,01 kbits/s) du débit brut
annoncé (20 kbits/s).
F - CHARGE DE BUS
La charge de bus se calcule de façon identique à celle des protocoles VAN et

CAN.
Cette charge s’exprime également en %.
Comme la méthode d’échanges des informations est de type maître-esclaves, la

charge de bus maximale admissible pourra être plus élevée.
En effet, pour des échanges de type maître-esclaves, il n’y a pas de collision

possible sur le bus, car seul le maître est autorisé à générer des messages. Les
esclaves ne peuvent en aucun cas émettre de façon autonome mais uniquement
sur sollicitation préalable du maître. Dans un tel schéma d’échanges, la charge de
bus maximale admissible peut être très élevée, de l’ordre de 80 à 90%.
LE MULTIPLEXAGE

102
CITROËN Chapitre 8
G - TEMPS DE LATENCE
Le temps de latence est la durée séparant l’instant de demande d’émission d’un

message de l’instant d’émission réel de ce message sur le bus.
Dans le cas du protocole LIN, ce temps de latence peut être nul.
Par contre, si à l’instant de la demande d’émission d’un message par le

calculateur maître, le bus n’était pas libre (celui-ci étant occupé par un autre
message en cours de transmission), le calculateur maître est prié d’attendre la fin
du message en cours avant de tenter d’émettre son message.
H - TYPES D’ERREURS LIN
Le protocole LIN a normalisé un certain nombre d’erreurs pouvant survenir sur un

réseau. Ces erreurs sont signalées par le CP LIN à l’application qui doit alors
décider de la stratégie adéquate à mettre en place. Par exemple, une erreur en
transmission pourra se traduire par une reprise de l’émission et une erreur en
réception pourra se traduire par le rejet du message erroné reçu.
VI - APPLICATIONS DANS LE GROUPE PSA PEUGEOT CITROËN (AFIL,

PROJECTEURS DIRECTIONNELS, …)
Le protocole LIN a été utilisé dans plusieurs applications chez CITROËN

notamment au niveau des calculateurs AFIL et PROJECTEURS
DIRECTIONNELS.
Dans le premier cas, le calculateur est connecté à un certain nombre de capteurs

de suivi de ligne blanche au moyen du protocole LIN. Cela permet de réduire le
nombre de fils connectés au calculateur AFIL.
Dans le deuxième cas, le calculateur PROJECTEURS DIRECTIONNELS est

connecté à 2 moteurs :
 Un moteur ‘correction d’assiette’
 Un moteur ‘correction d’azimut’
Ces deux moteurs sont reliés au calculateur au moyen du protocole LIN.
LE MULTIPLEXAGE

103
CITROËN Chapitre 8
LE DIAG-ON-CAN
VII - ARCHITECTURE DIAGNOSTIC
Une architecture spécifique a été mise en place par CITROËN pour les besoins de
diagnostic. Cette architecture spécifique est due à une contrainte sécuritaire
essentielle pour le constructeur : Ne pas fournir un accès direct aux réseaux
internes du véhicule, autrement dit, ne pas communiquer directement avec les
équipements pour les besoins de diagnostic. En effet, pour communiquer avec un
équipement du véhicule, quelle que soit sa localisation, ceci sera possible par
l’intermédiaire d’une interface qui est le BSI. Le BSI est utilisé en tant que
passerelle de données entre les divers outils de diagnostic et les équipements
internes au véhicule, comme l’indique la figure 8.1 ci-dessous :
AAS CMB UCE n
COM2000 BSM UCE n
Réseau Confort (CAN LS)
UCE n
BSI Réseau Carrosserie (CAN Low Speed)
Réseau Inter Systèmes (CAN High Speed)
BHI ABS/ESP BVA ECM
Ligne K
Ligne K Prise
16 V
Réseau Inter Systèmes commuté
Réseau CAN DIAG (CAN High Speed 500 Kbit/s)
Figure 8.1 : Architecture propre au diagnostic
LE MULTIPLEXAGE

104
CITROËN Chapitre 8
Une seule exception existe à ce principe : le diagnostic réglementaire (connexion

d’un outil de la police par exemple) est réalisé directement avec certains
équipements du véhicule comme le contrôle moteur (ECM).
VIII - PRINCIPES : RÔLE DE LA BSI (RAPPEL). ACCÈS DIAGNOSTIC, ACCÈS

TÉLÉCHARGEMENT
Le diagnostic repose sur un protocole de communication international appelé

KWP2000-3F (KeyWord Protocol 2000).
Ce protocole présente un mécanisme de requêtes envoyées par un outil de

diagnostic et les réponses associées envoyées par l’équipement questionné.
Requête Requête
Réponse Réponse
BSI ECM,…
Figure 8.2 : Interface diagnostic
Comme l’indique la figure 8.2 ci-dessus, les requêtes sont en fait transmises par
l’outil vers le BSI qui les analyse et détermine si ces requêtes lui sont destinées ou
si elles sont adressées à un autre équipement.
 Si les requêtes lui sont destinées, le BSI les traite et renvoie la réponse
associée vers l’outil.
 Si les requêtes sont adressées à un autre équipement, le BSI joue le

rôle de passerelle de diagnostic et renvoie la requête vers le calculateur
correspondant sur le réseau associé (réseau CAN Intersystèmes,
réseau CAN Confort ou CAN Carrosserie). L’équipement après avoir
reçu et analysé cette requête, prépare et envoie la réponse associée
vers le BSI. Le BSI renvoie alors cette réponse vers l’outil de
diagnostic, jouant une fois encore son rôle de passerelle de diagnostic.
LE MULTIPLEXAGE

105
CITROËN Chapitre 8
Les accès diagnostic (lecture des défauts d’un calculateur, configuration de ses
paramètres, pilotage de ses sorties, effacement de ses défauts) ainsi que les
accès liés au téléchargement, répondent aussi à ce mécanisme de requêtes et
réponses en respectant le protocole KWP2000 et les services qui y sont définis.
IX - SERVICES DÉFINIS PAR LE PROTOCOLE KWP2000
Les services de diagnostic sont définis dans la norme KWP2000-3F (KeyWord

Protocol 2000) au niveau mondial. Ce protocole indique quels sont les services et
les mécanismes d’échanges normalisés pour le diagnostic d’un véhicule.
Les services définis sont le plus souvent suivis par un sous-service qui précise la
requête demandée et parfois par des paramètres qui précisent à leur tour le
service et le sous-service demandés.
Cette requête de diagnostic sera suivie d’une réponse du calculateur

diagnostiqué. Le tableau ci-dessous mentionne les codes de réponses positives et
négatives définis par le protocole KWP2000.
Nom du service Abréviation Implémentation Code Code Codes de réponses

requête réponse négatives autorisées
positive
11 12 21 22 33 35 87
StartCommunication STCOM Conditionnelle 81 C1
StopCommunication SPCOM Obligatoire 82 C2 X X
StartDiagnosticSession SDS Obligatoire 10 50 X X X X X
SecurityAccess SA Libre 27 67 X X X X X
TesterPresent TP Obligatoire 3E 7E X
ECUReset ER Libre 11 51 X X X X X
ReadDataByLocalIdentifier RDBLID Obligatoire 21 61 X X X X
ReadDataByLocalIdentifierRepeatedly RDBLID Libre 21 61 X X X X
ReadMemoryByAddress RMBA Libre 23 63 X X X X X
DynamicallyDefineLocalIdentifier DDLID Libre 2C 6C X X X X X
WriteDataByLocalIdentifier WDBLID Libre 3B 7B X X X X X X
WriteMemoryByAddress WMBA Libre 3D 7D X X X X X X
ReadStatusOfDTC RSDTC Libre 17 57 X X X X X
LE MULTIPLEXAGE

106
CITROËN Chapitre 8
ReadFreezeFrameData RFFD Libre 12 52 X X X X X
Nom du service Mnémonique Implémentation Code Code Codes de réponses

requête réponse négatives autorisées
positive
11 12 21 22 33 35 87
ClearDiagnosticInformation CDI Obligatoire 14 54 X X X X X
IOControlByLocalIdentifier IOCBLID Libre 30 70 X X X X X
StartRoutineByLocalIdentifier SRBLID Libre 31 71 X X X X X
StopRoutineByLocalIdentifier SRBLID Libre 32 72 X X X X
RequestDownload RD UCE Reprog. 34 74
RequestUpload RU UCE Reprog. 35 75
Les réponses négatives sont résumées dans le tableau suivant :
Code Description Signification

de la
réponse négative
11 Service non supporté Le service demandé n’est pas implémenté dans l’UCE
12 Sous fonction non supportée Le service demandé est bien supporté par l’UCE, mais la requête a été
Format invalide mal formulée par l’outil (mauvais paramétrage ou paramètres hors
limites)
21 Occupé – Répéter requête L’UCE a bien compris la requête, mais la requête précédente est encore
en cours d’exécution et son résultat pourrait influer sur la réponse au
service demandé. Exemple : Demande de lecture E²PROM alors que la
requête précédente qui est une écriture E²PROM n’est pas encore
achevée.
22 Conditions d’exécution non Les conditions de fonctionnement actuelles de l’UCE ne permettent pas
satisfaites ou erreur dans le (ou n’autorisent pas) l’exécution de la requête ou le service est protégé
séquencement des requêtes par un « StartDiagSession »
NB : Ce code de réponse négative est principalement utilisé lorsque la
fonction de protection du véhicule est active
33 Calculateur verrouillé Ce code de réponse négative est utilisé par les services pour lesquels
l’accès n’est autorisé qu’après avoir verrouillé l’UCE par le service
SecurityAccess
35 Clé invalide Ce code de réponse négative est utilisé pour le service
SecurityAccess en cas de réception par l’UCE d’une clé différente de
celle qu’elle a calculée en interne
78 Requête correctement reçue Ce code de réponse négative est utilisé pour le traitement des requêtes
Réponse en instance longues
87 Défaut lors de l’écriture Ce code de réponse négative est utilisé par les services
WriteDataByLocalIdentifier et WriteMemoryByAddress
88 Non réponse à la passerelle Ce code de réponse négative est utilisé par une passerelle pour indiquer
que l’équipement distant n’a pas répondu
LE MULTIPLEXAGE

107
CITROËN Chapitre 8
Par convention, un code de réponse positive est constitué de la manière suivante :
 Le premier octet consiste à ajouter 40 en hexadécimal au code du

service de la requête reçue. Par exemple, si le service
ReadDataByLocalIdentifier (Lecture) a été reçu, le premier octet sera
égal à 61 (21 + 40)
 Le deuxième octet consiste à recopier le code de sous-service. Par

exemple, si la lecture correspondait à une lecture d’identification, le
sous-service reçu valait 80. L’octet renvoyé est donc 80.
 Les octets suivants comporteront les octets de la réponse

d’identification elle-même.
De la même manière, une requête peut se solder par une réponse négative. Dans
un tel cas, un code de réponse négative est constitué de la façon suivante :
 Le premier octet vaut toujours 7F, signifiant que la réponse à la requête

préalablement reçue est négative.
 Les deuxième et troisième octets sont dépendants de la cause de cette

réponse négative.
 Exemple 1: 7F 31 11 signifie que le service

StartRoutineByLocalIdentifer (code service 31) n’est pas supporté
(code 11)
 Exemple 2 : 7F FD 12 signifie que le sous-service FD n’est pas

supporté
LE MULTIPLEXAGE

108
CITROËN Chapitre 8
X- MÉCANISMES DU PROTOCOLE DIAG-ON-CAN
Le diagnostic d’un équipement repose sur un mécanisme de sessions. Un

équipement peut être piloté vers différentes sessions dont deux d’entre-elles
donnent accès à des informations de diagnostic.
NOTIONS DE SESSIONS, DIAGRAMME
Tout équipement est pilotable vers des sessions comme illustré dans la figure 8.3
ci-dessous :
Session Standard
Services accessibles : SDS
SDS 81 ou
5 sec
SDS 81
SDS C0 SDS FA
ou
5 sec
Session Spéciale
Session de diagnostic actif
Services accessibles :
Définis par le constructeur
Services accessibles :
Définis dans la messagerie Diagnostic
Services obligatoires : TP, RDBLID, RDSDTC, CLTDTC, SDS
Figure 8.3 : Diagramme des sessions standard et diagnostic
PRINCIPE DES ÉCHANGES SEGMENTÉS
Les accès diagnostic (lecture des défauts d’un calculateur, configuration de ses
paramètres, pilotage de ses sorties, effacement de ses défauts) ainsi que les
accès liés au téléchargement, répondent à un mécanisme de requêtes et
réponses en respectant le protocole KWP2000 et les services qui y sont définis.
Comme ces échanges dépassent le plus souvent la capacité maximale du champ
de données d’un message CAN, tous les échanges de diagnotsic sont segmentés.
Ils obéissent donc au procédé de segmentation décrit dans le chapitre 6,
paragraphe 6.3.
LE MULTIPLEXAGE

109
CITROËN Chapitre 8
XI - EXEMPLES DE DIALOGUES DIAG-ON-CAN (SUR UN CALCULATEUR)
IDENTIFICATION
L’identification d’un calculateur s’obtient aisément avec un outil de diagnostic.
Pour ce faire, l’outil va générer un service RDBLID

(ReadDataByLocalIdentifier = 21 ) suivi d’un service d’identification (80).
De plus, si ce calculateur est le tableau de climatisation, l’identificateur CAN

utilisé sera 76D pour la requête.
Le message envoyé par l’outil est donc illustré par la figure 8.4 ci-dessous :
Données trame CAN

1 octet 1 octet 1 octet
Ident CAN NPCI RDBLID LID

76D 02 21 80
Figure 8.4 : Exemple d’échange de diagnotsic (requête d’identification

du tableau de climatisation)
LE MULTIPLEXAGE

110
CITROËN Chapitre 8
La réponse transmise par le tableau de climatisation vers l’outil est illustrée

par la figure 8.5 ci-dessous :
2 octets 1 octet 1 octet 4 octets
FIRST FRAME CLIM vers OUTIL
Ident NPCI RDBLI LID Identification : octets 1 à 4
66D 1018 61 80
1 octet 1 octet 1 octet
FLOW CONTROL OUTIL vers CLIM Ident FC + FS Block ST min
76D 30 0 0A
1 octet 7 octets
CONSECTIVE FRAME CLIM vers OUTIL
Ident NPCI Identification : octets 5 à 11
66D 21
1 octet 7 octets
66D 22
1 octet 4 octets
66D 23
Figure 8.5 : Exemple d’échange de diagnostic (réponse d’identification

du tableau de climatisation)
TÉLÉCHARGEMENT
Le téléchargement d’un calculateur est effectué au moyen d’un outil de

diagnostic. L’outil utilise le service de diagnostic RD (RequestDownload) .
Ce procédé de téléchargement répond également au mécanisme de

segmentation des données. La segmentation considérée sera un peu
particulière puisque le producteur est autorisé à transmettre toutes les
données liées au téléchargement (en général, en programme à télécharger
dans un calculateur) d’un seul bloc (information Block Size = 0) et aussi vite
que possible (information Stmin = 0 ms).
TÉLÉCODAGE
L’opération de télécodage permet de configurer un calculateur afin de

particulariser la fonction.
Par exemple, il est possible de configurer une table d’éclairage d’un Ecran
Multifonctions.
Le télécodage d’un calculateur est effectué au moyen d’un outil de diagnostic.

L’outil utilise le service de diagnostic WDBLID (WriteDataByLocalIdentifier).
LE MULTIPLEXAGE

111
CITROËN Chapitre 2
ANNEXE : TERMINOLOGIE
XII - TERMINOLOGIE DES RESEAUX
Les principaux éléments de la terminologie couramment utilisés dans le

domaine des réseaux de communication embarqués sont présentés ci-
dessous, associés à leur définition :
 Débit Vitesse de transmission des données exprimé en bits/s en

CAN et en TS/s en VAN (Time Slot par seconde)
 Diffusion Mise en relation de plusieurs calculateurs au cours d’un

même échange
 Echantillonnage Opération de capture de l’état du signal reçu
 ERL / Driver Emetteur / Récepteur de ligne : Composant chargé de former

les signaux sur les lignes de communication CAN-H et CAN-L
en CAN et DATA et DATA/ en VAN (Faisceau véhicule) et de
remettre en forme les signaux présents sur ces lignes, pour le
décodage des trames de communication. Autres
appellations : ‘ Interface de ligne’ , ‘Driver de ligne ’ ou
‘ Transceiver ’
 Medium Support matériel de la transmission. Dans le cas des

applications PSA, le medium est matérialisé par les faisceaux
dédiés aux signaux CAN-H et CAN-L en CAN et DATA et
DATA/ en VAN
 Noeud Organe / calculateur connecté au réseau
 Producteur / Consommateur Organe détenant les données à transmettre (Producteur) /

Organe exploitant les données circulant sur le réseau
(Consommateur)
 Topologie Disposition des calculateurs suivant l’arborescence des

faisceaux
 Trame Assemblage de données véhiculées sous forme d’un ‘paquet’

indissociable’, sur le réseau
 Erreur ACTIVE Etat d’un nœud CAN fonctionnant en mode nominal dans le
sens où il continue d’émettre et de recevoir. En cas d’erreur, il
émet un flag (Signalement) ‘ erreur active ’
LE MULTIPLEXAGE
© AUTOMOBILES CITROËN Toute reproduction ou traduction même partielle sans l'autorisation écrite d'AUTOMOBILES CITROËN est interdite et constitue une
contrefaçon

112
CITROËN Chapitre 2
 Erreur PASSIVE Etat d’un nœud CAN ayant détecté un nombre d’erreurs
moyen permettant de continuer à émettre et à recevoir. En
cas d’erreur, il émet un flag ‘ erreur passive ’
 BUS-OFF Etat d’un nœud CAN ayant détecté un nombre élevé

d ’erreurs entraînant sa déconnexion en émission et
réception
 Etat Récessif / Dominant Etat électrique correspondant à la transmission d’un bit 1

(Récessif) ou 0 (Dominant) sur le réseau. Un état dominant
est prioritaire par rapport à un état récessif
 NRZ Non Retour à Zéro : Méthode de codage électrique des bits,

basée sur la correspondance électrique d’une tension
constante durant toute la description du bit (ex. : V = 5v si bit
= 1 / V=0 si bit = 0). Cette tension reste constante durant la
totalité du bit, c’est à dire 2 µs dans le cas d’un débit réseau
de 500 Kbits/s et 8 µs dans le cas d’un débit réseau de 125
Kbits/s
 Maître / Esclave Privilège d’initiation de messages sur le réseau ou encore de

gestion des procédures de veille / réveil du réseau
 Manchester Méthode de codage électrique des bits, basée sur la

correspondance électrique d’une tension durant la moitié du
bit (ex. : V = 5v si bit = 1 / V=0 si bit = 0) et d’une tension
complémentaire durant la deuxième partie de ce bit.
 Phase de vie Etat des réseaux VAN et CAN et des équipements connectés
en fonction de l’état du véhicule
 Segmentation Procédé normalisé (OSEK-COM), utilisé pour véhiculer un

nombre d’informations supérieur à 7 octets au moyen de
plusieurs messages CAN successifs
 Supervision Procédé normalisé (OSEK-NM), utilisé pour assurer la fiabilité

de la communication des équipements sur le réseau, la
sécurité de fonctionnement (passage en mode dégradé par
détection d’un défaut de communication) et le diagnostic de
présence des calculateurs pour les besoins
Après-Vente
 TS Time Slot, unité temporelle consituant les bits VAN
LE MULTIPLEXAGE
contrefaçon

113
CITROËN Chapitre 2
XIII - TERMINOLOGIE DES CALCULATEURS
Les calculateurs constituants les architectures électriques électroniques du

Groupe PSA PEUGEOT CITROËN sont définis par des sigles ou abréviations
présentés ci-dessous associés à leur définition :
LE MULTIPLEXAGE
contrefaçon

114
CITROËN Chapitre 2
 Sigle  Nom calculateur  Code  Numéro  Réseau

calculateur calculateur schéma
AAS Aide Au Stationnement 1D 7500 CONF
ADDGO ADDitif Gas-Oil (ou Filtre à Particules) 35 1282 CAR
(FAP)
ALM Alarme 1C 8600 CAR
AVE Antivol Electrique 0F AE00 CAR
BDM Cond Boîtier de Mémorisation conducteur 2E 6338 CONF
BSI Boîtier de Servitude Intelligent 12 BSI1 TOUS
BSM Boîtier de Servitude Moteur 07 BSM CAR
BSR Boîtier de Servitude Remorque 2C BSR1 CAR
BVA Boîte de Vitesse Automatique 09 1630 IS
CAV Capteur d’Angle Volant 05 7803 IS
CDC Changeur De CD 31 8415 CONF
CDPL Capteur De Pluie et Luminosité 0A 5007 CAR
CMB Combiné 1F 0004 CONF
CMBD Combiné déporté 26 CONF
ECM Contrôle Moteur 08 1320 IS
COM2000 Commandes au volant (commutation 02 CV00 CAR
(HDC) d’essuyage et éclairage) ou Haut de
Colonne
Projecteurs Calculateur de Projecteurs Directionnels 1F 6606 IS
Directionnels
DSG Détection de Sous Gonflage 26 7600 IS
EDP Electronique De Porte (EDPc : 0B (cond) 9030 (cond) CONF(1)
conducteur, EDPp : Passager) OC (pass) 9050 (pass)
ABS/ESP Contrôle dynamique de stabilité 0D 7800 IS
EMF Ecran Multi-Fonctions 25 7215 CONF
GEP Groupe électropompe direction assistée 15 7122 IS
MAE Module Auto Ecole 1E 2003 CAR
PLC Porte Latérale Coulissante 15 6239 CONF(1)
RAD Radio 20 8410 CONF
RBG Airbag 04 6570 CAR
RT3 Boîtier télématique (Radio télématique 3) 24 8480 CONF
AFIL Alerte Franchissement Involontaire de 22 7550 CONF
Ligne
CLIM Fonction Climatisation
2D 8025 CONF
TO Toit Ouvrant 28, 29, 2A 6811 CONF
(1) : Modules connectés sur le réseau VAN Carrosserie dans les architectures bi VAN CAN et
sur le réseau CAN Confort dans les architectures Full CAN
XIV - GLOSSAIRE COMPLET
LE MULTIPLEXAGE
contrefaçon

115
CITROËN Chapitre 2
Le glossaire suivant regroupe les abréviations couramment utilisées dans les

documents ou litératures traitant du sujet du multiplexage et des architectures
électriques électroniques.
 ACK Acknowledgement ou acquittement en VAN et en CAN
 Bit Binary Digit
 CAN Controller Area Network
 CAN-H Ligne de comunication CAN HIGH
 CAN-L Ligne de comunication CAN LOW
 COM Champ de commande d’une trame CAN
 CRC Code à Redondance Cyclique (FCS en anglais)
 DAT Champ de données d’une trame CAN
 DLC Data Length Code : Champ indiquant la longueur du champ
de données
 EOD Champ délimiteur de CRC en CAN
 EOF Champ de fin de trame (End Of Frame) en CAN
 IDEN Identifier ou Identificateur : Champ d’identification d’une trame
CAN
 IDLE BUS Bus libre
 IFS Inter Frame Separation : Champ inter trame
 LIN Local Interconnection Network
 LSB Least Significant Bit
 MSB Most Significant Bit
 NRZ Non Return to Zero
 Octet Mot constitué de 8 bits
 OSEK Offene Systeme und deren Schnittstellen für die Electronik im
Kraftfahrzeug (Systèmes ouverts et interfaces
correspondantes pour l’électronique automobile)
 START-BIT Start bit : Symbole de début d’une trame CAN
 TS Time Slot
 VAN Vehicle Area Network
LE MULTIPLEXAGE
contrefaçon

Le Multiplexage - Partie2

Transféré par

Droits d'auteur :

Formats disponibles

Le Multiplexage - Partie2

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Le Multiplexage - Partie2

Transféré par

Droits d'auteur :

Formats disponibles

56

ARCHITECTURES BI VAN CAN

Les architectures ont beaucoup évolué dans le temps.

L’architecture bi VAN CAN est la première architecture électrique électronique

Puis, d’autres besoins fonctionnels et d’autres motivations économiques ont

I- RAPPEL : ARCHITECTURE TYPE

A - LE RESEAU CAN INTERSYSTEMES

Le réseau CAN Intersystèmes est un réseau CAN High Speed fonctionnant à un

Les composants de ce réseau sont :

 Le calculateur Electronique Contrôle Moteur (ECM)

 Le calculateur Boîte de Vitesse Automatique (BVA)

 Le calculateur Anti Blocage de Roue (ABS/ESP)

 Le calculateur Angle Volant (CAV)

 Le calculateur Boîtier de Servitude Intelligent (BSI) jouant le rôle de

Chaque calculateur dispose d’un certain nombre de capteurs et d’actionneurs.

Date du formulaire : 26/06/2003

Les informations sont transmises en utilisant le procédé de diffusion de données

Selon la criticité des informations à transmettre, les messages transmis porteront

 Trame dynamique pour les informations à criticité élevée. Exemples :

 Trame données pour les informations à criticité faible. Exemple :

 Trame synchronisation à criticité élevée. Exemple : Demande de

 Trame version émise une seule fois à la mise sous tension du

 Trame supervision informant de l’état du calculateur et des autres

 Trame diagnostic donnant des informations Après-Vente

Figure 5.1 : Stratégie de veille – réveil CAN Intersystèmes

Date du formulaire : 26/06/2003

Le tableau ci-dessous indique les états de communication d’un calculateur CAN

ETAT GMP MNT MNT MNT DEM MT MNT

ETAT CLE Arrêt ACC +APC DEM +APC Arrêt

ETAT Aucune Aucune

Date du formulaire : 26/06/2003

S5 S4 S3 S2 S1 0 So2 So1 So0 M1 M0

Figure 5.2 : Découpage du champ d’identification CAN Intersystèmes

Ces parties sont les suivantes :

 Partie SUJET : Le sujet définit le code du message (dynamique,

 Partie DIFF : Le champ DIFF définit si le message est de type

 Partie SOURCE : Le champ source définit le calculateur émetteur du

4. MESSAGERIES DE DIAGNOSTIC, NOTION DE DIAGNOSTIC DES DEFAUTS

Date du formulaire : 26/06/2003

la durée pour détecter un défaut est de l’ordre de quelques centaines de

Il existe 2 moyens d’effacer un défaut en E²PROM :

 Effacement par un service de diagnostic : Le défaut (qu’il soit fugitif

 Effacement au bout de 40 cycles de démarrage du véhicule : Le

Cela aboutit à la définition de codes calculateurs appelés quelquefois ‘codes

Date du formulaire : 26/06/2003

B - LES RESEAUX VAN CARROSSERIE ET CONFORT

Les composants du réseau VAN CAR 1 sont :

 Les calculateurs Electronique de Portes Conducteur et Passager (EDP

 Le calculateur Toit Ouvrant (TO)

 Le calculateur Capteur de pluie (CDPL)

 Le boîtier de mémorisation (BDM)

 Le calculateur Boîtier de Servitude Intelligent (BSI) jouant le rôle de

Les composants du réseau VAN CAR 2 sont :

 Le calculateur Airbag (RBG)

 Le calculateur Haut de Colonne (COM2000)

 Le calculateur Boîtier de Servitude Moteur (BSM)

 Le calculateur Boîtier de Servitude Intelligent (BSI) jouant le rôle de

La stragétie d’échanges des informations entre ces calculateurs et le boîtier BSI

Les informations sont transmises en utilisant le procédé de communication point à