Bus de données CAN

Le bus de données CAN (Controller Area Network) est un bus système série très répandu dans beaucoup d'industries, notamment l'automobile^[1]^,^[2]^,^[3]^,^[4]^,^[5]^,^[6].

Si ce bandeau n'est plus pertinent, retirez-le. Cliquez ici pour en savoir plus.

Cet article ne cite pas suffisamment ses sources (décembre 2015).

Si vous disposez d'ouvrages ou d'articles de référence ou si vous connaissez des sites web de qualité traitant du thème abordé ici, merci de compléter l'article en donnant les références utiles à sa vérifiabilité et en les liant à la section « Notes et références ».

En pratique : Quelles sources sont attendues ? Comment ajouter mes sources ?

Il a été normalisé avec la norme ISO 11898^[7].

Il met en application une approche connue sous le nom de multiplexage, et qui consiste à raccorder à un même câble (un bus) un grand nombre de calculateurs qui communiqueront donc à tour de rôle. Cette technique élimine le besoin de câbler des lignes dédiées pour chaque information à faire transiter (connexion point-à-point). Dès qu'un système (voiture, avion, bateau, réseau téléphonique, etc.) atteint un certain niveau de complexité, l'approche point-à-point devient impossible du fait de l'immense quantité de câblage à installer et de son coût (en masse, matériaux, main d'œuvre, maintenance).

L'introduction des bus multiplexés (principalement le CAN) dans l'automobile avait pour objectif de réduire la quantité de câbles dans les véhicules (il y avait alors jusqu'à 2 km de câbles par voiture), mais elle a surtout permis l'explosion du nombre de calculateurs et capteurs distribués dans tout le véhicule, et des prestations correspondantes (baisse de consommation, dépollution, sécurité active/passive, confort, détection des pannes, etc.), tout en diminuant les longueurs câblées.

Historique modifier

Le bus de données CAN est le fruit de la collaboration entre l'université de Karlsruhe et Bosch.

Il fut d'abord utilisé dans le secteur de l'automobile, mais est actuellement utilisé dans la plupart des industries comme l'aéronautique via des protocoles standardisés basés sur le CAN.

Il fut présenté avec Intel en 1985, mais ne fut standardisé par l'ISO qu'au début des années 1991.

En 1992, plusieurs entreprises se sont réunies pour créer le CAN in Automation, une association qui a pour but de promouvoir le CAN.

Une première évolution appelée CAN FD (en) pour « Flexible Data-Rate » est sortie^[8].

Une deuxième évolution portée par Bosch et Vector Informatik, appelée « XL », est en cours de développement.

Couche physique modifier

Il existe deux normes pour la couche physique :

ISO 11898-2 (2016) : CAN « high-speed » (jusqu'à 1 Mbit/s) ;
ISO 11898-3 (2006) : CAN « low-speed, fault tolerant » (jusqu'à 125 kbit/s).

Topologie modifier

CAN est un bus de données série bidirectionnel half-duplex dans le domaine automobile, mais est utilisé en unidirectionnel — simplex — dans l'aéronautique, pour obtenir un comportement déterministe.

Chaque équipement connecté, appelé « nœud », peut communiquer avec tous les autres.

Architecture CAN avec plusieurs nœuds

Le nombre maximal de nœuds sur un bus CAN est limité par la capacité de pilotage d'un émetteur-récepteur CAN.

Support modifier

Chaque nœud est connecté au bus par l'intermédiaire d'une paire torsadée (blindée ou non).

Les deux extrémités du bus doivent être rebouclées par des résistances de 120 Ω ±10 % (tolérance entre 108 Ω et 132 Ω).

Surpport d'un bus CAN

L'accès au bus de données CAN suit la technique CSMA/CR (écoute de chaque station avant de parler mais pas de tour de parole, résolution des collisions par priorité).

La longueur maximale du bus est déterminée par la vitesse utilisée :

Vitesse (kbit/s)	Longueur (m)
1 000	30
800	50
500	100
250	250
125	500
62,5	1 000
20	2 500
10	5 000

Encodage des bits modifier

L'encodage utilisé est de type NRZ (non retour à 0) :

Encodage d'un bit CAN

États logiques et Niveaux électriques modifier

Les nœuds sont câblés sur le bus par le principe du « OU câblé » du point de vue électrique (« ET câblé » du point de vue logique), ce qui veut dire qu'en cas d'émission simultanée de deux nœuds, la valeur 0 écrase la valeur 1.

On dit donc :

que l'état logique « 0 » est l'état « dominant » ;
que l'état logique « 1 » est l'état « récessif ».

Les états logiques et les niveaux électriques utilisés entre les deux lignes de la paire différentielle pour le CAN low-speed sont les suivants :

État logique	V_CANH-GND	V_CANL-GND	V_CANH-CANL
Récessif ou « 1 »	1,75 V	3,25 V	−1,5 V
Dominant ou « 0 »	4 V	1 V	3 V

Les états logiques et les niveaux électriques utilisés entre les deux lignes de la paire différentielle pour le CAN high-speed sont les suivants :

État logique	V_CANH-GND	V_CANL-GND	V_CANH-CANL
Récessif ou « 1 »	2,5 V	2,5 V	de 0 à 0,5 V
Dominant ou « 0 »	3,5 V	1,5 V	de 0,9 à 2 V

Temps et vitesse modifier

La durée d'un bit est appelée « Nominal Bit Time ».

Chaque bit est constitué de plusieurs segments cadencés par l'horloge interne de chaque nœud :

segment de synchronisation ;
segment de propagation ;
segment de phase buffer n^o 1 ;
segment de phase buffer n^o 2.

Time Quantum modifier

Le « Time Quantum » est l'unité de temps construite à partir de la période de l'oscillateur interne de chaque nœud.

La fréquence du bus étant au maximum de 1 MHz et celles des oscillateurs de plusieurs MHz, le « Time Quantum » vaut généralement plusieurs périodes d'horloge (entre 1 et 32 fois).

La durée de chaque segment est la suivante :

Segment	Durée en « Time Quantum »
Synchronisation	1
Propagation	de 1 à 8
Phase buffer n^o 1	de 1 à 8
Phase buffer n^o 2	de 2 à 8

Ainsi la durée d'un bit peut varier de 5 à 25 « Time Quantum ».

Plus la fréquence de l'horloge interne du nœud est importante, plus la durée du « Time Quantum » pourra être faible, plus les trois derniers segments compteront de « Time Quantum » et meilleure sera la précision de la synchronisation.

Segment de synchronisation modifier

Le segment de synchronisation est utilisé pour synchroniser les différents nœuds.

La transition de 0 à 1 ou de 1 à 0, effectuée pour le nœud émetteur, doit s'effectuer dans ce segment. Si pour un nœud récepteur cette transition n'a pas lieu dans ce même segment, c'est qu'il est désynchronisé. Il s'agit d'une erreur de phase.

Grâce au bit de transparence, cette vérification peut être faite au moins tous les 5 bits (pour les premiers champs de la trame dans lequel il est utilisé).

Segment de propagation modifier

Le segment de propagation est utilisé pour compenser les phénomènes de propagation sur le bus.

Segments de phase modifier

Les segments de phase sont utilisés pour compenser les erreurs de phase détectées lors des transitions.

La durée de ces segments peut varier en cas de resynchronisation.

Point d'échantillonnage modifier

Le point d'échantillonnage ou « Sample point » est l'instant où on lit la valeur du bit sur le bus. Celui-ci intervient entre les deux segments de phase.

Synchronisation modifier

Il existe deux types de synchronisation :

la hard-synchronisation qui consiste à se resynchroniser brutalement dès qu'une transition est détectée dans le segment de synchronisation, notamment lors du SOF (Start Of Frame) d'une nouvelle trame ;
la resynchronisation qui consiste à allonger le segment de phase buffer n^o 1 ou à diminuer le segment de buffer phase n^o 2, ce qui a deux effets :
- déplacer le point d'échantillonnage,
- diminuer ou augmenter la durée du bit et ainsi améliorer la synchronisation du bit suivant.

Connecteur modifier

Le brochage sur le bus de données CAN est normalisé et utilise un connecteur DE-9 :

Connecteur CAN

Broche	Description
1	(Réservé)
2	CANL
3	Masse
4	(Réservé)
5	Blindage (optionnel)
6	Masse
7	CANH
8	(Réservé)
9	Alimentation externe (optionnel)

Couche liaison de données modifier

Il existe également deux standards pour la couche de liaison de données :

ISO 11898 part A → CAN 2.0A « standard frame format » (identification sur 11 bits) ;
ISO 11898 part B → CAN 2.0B « extended frame format » (identification sur 29 bits).

Il existe plusieurs types de trame :

trame de données ;
trame de requête ;
trame d'erreur ;
trame de surcharge.

Entre deux trames, les émetteurs doivent respecter une pause (période d’inter-trame) équivalente à la durée de trois bits pendant laquelle le bus est maintenu à l'état récessif.

Trame de données modifier

La trame de données sert à envoyer des informations aux autres nœuds.

Une trame de données se compose de sept champs différents :

le début de trame ou SOF (Start Of Frame) matérialisé par 1 bit dominant ;
le champ d'arbitrage (identificateur) composé de 12 ou 32 bits ;
le champ de commande (ou de contrôle) composé de 6 bits ;
le champ de données composé de 0 à 64 bits (de 0 à 8 octets) ;
le champ de CRC composé de 16 bits ;
le champ d'acquittement composé de 2 bits ;
la fin de trame ou EOF (End of Frame) matérialisée par 7 bits récessifs.

Trame de données sur bus CAN

Ordre de transmission des bits modifier

Les champs sont transmis dans l'ordre du SOF à l'EOF.

Dans chaque champ de la trame, les bits sont transmis du plus fort au plus faible.

Champ d'arbitrage modifier

Le champ d'arbitrage est composé de 11 bits d'identification pour CAN 2.0A et 29 bits pour CAN 2.0B suivis par le bit RTR (Remote Transmission Request) qui est dominant. Ce champ sert d'identifiant pour la donnée transportée dans le champ de données.

Les 11 bits de CAN 2.0A autorisent 2¹¹ = 2 048 combinaisons.

Les 29 bits de CAN 2.0B autorisent 2²⁹ = 536 870 912 combinaisons.

Champ de commande modifier

Le champ de commande est composé de six bits.

Le bit de poids fort est utilisé pour différencier le type de trame :

dans le cas d'une trame standard (sur 11 bits), le bit de poids fort est dominant ;
dans le cas d'une trame étendue (sur 29 bits), le bit de poids fort est récessif.

Le bit suivant n'est pas utilisé.

Les quatre bits de poids faibles appelés DLC (Data Length Code) représentent le nombre d'octets du champ de données (PAYLOAD) embarqué.

Ce nombre d'octets peut varier de 0 à 8, soit neuf valeurs stockées avec les quatre bits du champ DLC. Les valeurs DLC supérieures à 9 ne seraient donc pas utilisées (de 9 à 15).

Champ de données modifier

Le champ de données peut varier de 0 à 8 octets.

Dans le cas d'une trame de requête le champ de données est vide.

Champ de CRC modifier

Le champ est composé de quinze bits de CRC (Cyclic Redundancy Check) et d'un bit dit délimiteur (« CRC delimiter ») toujours récessif.

Le CRC est calculé à partir de l'ensemble des champs transmis jusque-là (c'est-à-dire le SOF, le champ d'arbitrage, le champ de commande et le champ de données ; les bits de transparence ne sont pas pris en compte). L'ensemble constitue le polynôme f(x).

L'algorithme consiste dans un premier temps à multiplier f(x) par 2¹⁵.

Ensuite le polynôme f(x) est divisé (modulo 2) par le polynôme g(x) = x¹⁵ + x¹⁴ + x¹⁰ + x⁸ + x⁷ + x⁴ + x³ + x⁰.

Une fois les divisions successives effectuées, le reste constitue la séquence de CRC.

La distance de Hamming de l’algorithme utilisé est de 6, ce qui signifie que cinq erreurs au maximum sont détectables.

Grâce à ce système de détection, le taux d’erreur enregistré est très faible (inférieur à 4,6 × 10⁻¹¹). De plus, le réseau est capable de différencier les erreurs ponctuelles des erreurs redondantes. Ainsi, tout périphérique défaillant peut être déconnecté du réseau afin de limiter les perturbations. Le réseau entre alors en mode « dégradé ».

Champ d'acquittement ACK modifier

Le champ est composé d'un bit d'acquittement ACK (ACKnowledge) et d'un bit dit délimiteur (« ACKnowledge delimiter ») toujours récessif.

Tous les récepteurs qui ont bien reçu le message doivent l'acquitter en émettant un bit dominant pendant la durée du bit ACK, ce qui permet au nœud émetteur de savoir qu'au moins un des nœuds récepteurs a reçu le message.

Si un nœud récepteur n'a pas ou mal reçu le message, il ne peut pas se servir de ce mécanisme pour signaler l'erreur, puisqu'il suffit qu'une station réceptrice envoie un bit dominant pour masquer tous les bits récessifs. Pour signaler le dysfonctionnement, il doit émettre une trame d'erreur.

Trame de requête modifier

La trame de requête sert à demander une donnée à un autre nœud. Elle est similaire à la trame de données hormis :

le champ de données est vide ;
le bit RTR du champ d'arbitrage est récessif ;
les quatre bits DLC du champ de commande correspondent au nombre d'octets attendus dans la réponse.

À noter que le fait que le bit RTR soit récessif dans le cas d'une trame de requête fait que si une trame de données est émise simultanément avec le même champ d'arbitrage, c'est la trame de données qui est prioritaire.

Bit de transparence modifier

Afin de sécuriser la transmission des messages, la méthode du « bit-stuffing » est utilisée.

Elle consiste, dans le cas où l’on a émis cinq bits de même polarité d'affilée, d'ajouter à la suite un bit de polarité contraire, pour casser des chaînes trop importantes de bits identiques. Cette méthode n'est appliquée que sur les champs SOF, d'arbitrage, de commande, de data et de CRC (délimiteur exclu).

Par exemple, « 1111 1110 » deviendra « 1111 1011 0 ».

Priorité de transmission modifier

Que se passe-t-il si plusieurs nœuds tentent de transmettre simultanément?

Il existe une procédure d'accès au bus à laquelle chaque nœud doit se soumettre :

lorsqu'il transmet un bit, le nœud doit rester à l'écoute du bus. Dit autrement, après avoir envoyé un bit, il lit le bus et vérifie que le bit lu correspond à celui transmis ;
s'il y une différence (forcément sur un bit récessif), c'est qu'un autre nœud l'a écrasé par un bit dominant ;
le nœud doit alors interrompre sa transmission, monitorer le bus pour attendre la fin de la transmission, puis tenter à nouveau d'envoyer son message.

Ainsi une priorité est réalisée grâce au champ d'arbitrage.

Plus celui-ci est petit, plus il contient des bits de poids forts à 0 (dominant), plus il sera prioritaire.

Cette phase de priorisation ou d'arbitrage prend fin au bit RTR.

Trame d'erreur modifier

Dès la détection d'une erreur, le nœud n'attend pas la fin de la trame incriminée, il envoie immédiatement une trame d'erreur pour signaler un problème dans la transmission.

Une trame d'erreur se compose de deux champs différents :

le drapeau d'erreur composé de six bits ;
le délimiteur composé de huit bits récessifs.

La trame d'erreur peut être :

« active » si le drapeau d'erreur est composé de six bits dominants ;
« passive » si le drapeau d'erreur est composé de six bits récessifs.

Erreurs modifier

Un certain nombre d'erreurs sont détectables par les nœuds.

Bit error modifier

Chaque fois qu'un nœud émet un bit sur le bus, il relit le bus et doit retrouver le bit qu'il a écrit. Si sur l'envoi d'un bit récessif, il relit un bit dominant, celui-ci a été altéré.

Ce mécanisme est identique à celui permettant la priorisation, c'est pourquoi il ne faut pas en tenir compte dans le champ d'arbitrage.

Idem pour le champ d'acquittement, si le bit récessif envoyé par le nœud émetteur devient dominant, c'est simplement qu'un ou plusieurs nœuds récepteur ont confirmé la bonne réception de la trame, ce n'est donc pas une erreur.

Stuff error modifier

Si sur le bus on lit six bits de même polarité consécutifs, le mécanisme du bit de transparence n'a pas été respecté ou qu'un bit a été altéré.

CRC error modifier

Si la valeur de CRC calculée par le nœud récepteur est différente du CRC codé dans la trame par le nœud émetteur, la trame a été altérée.

CRC delimiter modifier

Si le bit « CRC delimiter » lu par les nœuds récepteurs n'est pas récessif, le bit a été altéré.

ACKnowledge error modifier

Si le bit ACK récessif envoyé par le nœud émetteur n'a pas été écrasé par un bit dominant, c'est qu'aucun nœud récepteur ne l'a reçu.

ACKnowledge delimiter modifier

Si le bit « ACKnowledge delimiter » lu par les nœuds récepteurs n'est pas récessif, le bit a été altéré.

Recouvrement des erreurs modifier

Par construction, la trame d'erreur brise la règle du bit-stuffing puisque, quoi qu'il arrive, les six bits du drapeau d'erreur sont identiques.

Lorsqu'un nœud émet une trame d'erreur, tous les autres nœuds détectent une erreur de type « Stuff error » et se mettent à envoyer également une trame d'erreur.

Dans le cas de trames d'erreurs actives, le nombre de bits dominants d'affilée ne doit pas dépasser douze bits. Au-delà, les nœuds n'ayant pas émis leur trame d'erreur ne doivent pas le faire.

Le dernier nœud à émettre fournit le délimiteur (huit bits récessifs) et met fin à la cacophonie.

Le nœud ayant émis la trame incriminée retente alors sa chance.

Et ainsi de suite, jusqu'à ce que la trame passe ou qu'un de ses compteurs d'erreur fasse changer de mode d'erreur au nœud.

Compteurs d'erreur modifier

Chaque nœud possède deux compteurs d'erreur :

un compteur d'erreur de transmission ou « Transmit Error Counter » (TEC) ;
un compteur d'erreur de réception ou « Receive Error Counter » (REC).

TEC modifier

Le compteur d'erreur de transmission d'un nœud en mode émetteur est :

incrémenté de 8 :
- si le nœud envoie un drapeau d'erreur sauf :
  - en cas de « ACKnowledge error » et qu'il est en mode d'erreur passive,
  - en cas de « Stuff error » durant la période d'arbitrage,
- si le nœud reçoit sept bits dominants consécutifs après un drapeau d'erreur ou un drapeau de surcharge ;
décrémenté de 1 si la transmission du nœud se déroule sans erreur.

REC modifier

Le compteur d'erreur de réception d'un nœud en mode récepteur est :

incrémenté de 1 si le nœud détecte une erreur de réception, sauf en cas de « Bit error » pendant un drapeau d'erreur ou un drapeau de surcharge ;
incrémenté de 8 :
- si le nœud reçoit un bit dominant juste après un drapeau d'erreur,
- si le nœud détecte un « Bit error » pendant un drapeau d'erreur ou un drapeau de surcharge,
- si le nœud reçoit 7 bits dominants consécutifs après un drapeau d'erreur ou un drapeau de surcharge ;
décrémenté de 1 s'il est inférieur à 127 et que le nœud reçoit une trame sans erreur ;
ramené entre 119 et 127, s'il était supérieur à 127 et que le nœud reçoit une trame sans erreur.

Modes d'erreur modifier

En fonction des compteurs d'erreur, le nœud change de mode d'erreur. Il en existe trois :

mode d'erreur active : dans le cas où TEC et REC sont inférieurs à 127. Le nœud émet alors des trames d'erreur active ;
mode d'erreur passive : dans le cas où TEC ou REC est supérieur/égal à 128 et inférieur à 255. Le nœud émet alors des trames d'erreur passive ;
mode « Bus Off » : dans le cas où TEC ou REC est supérieur à 255. Le nœud se déconnecte du bus. Pour sortir de ce mode, le nœud doit recevoir 128 trames de 11 bits récessifs.

Trame de surcharge modifier

La trame de surcharge peut être utilisée dans deux cas :

lorsque le nœud demande un délai avec la réception d'une nouvelle trame ;
lorsque le nœud détecte un bit dominant pendant une période d’inter-trame (trois bits récessifs entre les trames).

Une trame de surcharge se compose de deux champs différents :

le drapeau de surcharge composé de six bits dominants ;
le délimiteur composé de huit bits récessifs.

La trame de surcharge est similaire à une trame d'erreur active.

Lorsqu'un nœud émet une trame de surcharge pour demander un délai (condition n^o 1), il écrase les trois bits récessifs de la période d’inter-trame, les autres nœuds détectent la surcharge, et elles émettent elles-mêmes des trames de surcharge (condition n^o 2).

Tout comme pour les trames d'erreurs actives, le nombre de bits dominants d'affilée ne doit pas dépasser douze bits. Au-delà, les nœuds n'ayant pas émis leur trame de surcharge ne doivent pas le faire.

Le dernier nœud à émettre fournit le délimiteur (huit bits récessifs) et met fin à la cacophonie.

Couche application modifier

Plusieurs couches applications ont été définies sur la norme CAN :

CANopen ;
DeviceNet ;
SAE J1939 ;
ISO11783 (ISOBUS) ;
NMEA2000 ;
CANaerospace ;
MilCAN ;
SocketCAN ;
FlexCAN ;
CAL ;
SDS^[9] ;
CAN Kingdom^[10] ;
UAVCAN, DroneCAN.

Bibliographie modifier

Dominique Paret, Le bus Can : Description, de la théorie à la pratique, Dunod, 2009, 277 p. (ISBN 978-2-10-004764-2)

(en) Wolfhard Lawrenz, Can System Engineering : From Theory to Practical Applications, Springer, 2007, 468 p. (ISBN 978-0-387-94939-0)
Livre en anglais écrit par le chef de projet du réseau CAN chez Bosch lors de la création du protocole.

Notes et références modifier

↑ http://ww1.microchip.com/downloads/en/AppNotes/00754.pdf
↑ https://www.can-cia.org/fileadmin/resources/documents/proceedings/2003_fellmeth.pdf
↑ (de) « Applications », sur can-newsletter.org (consulté le 7 avril 2023).
↑ (en) « CAN in Automation (CiA) : History of the CAN technology », sur can-cia.org (consulté le 7 avril 2023).
↑ « Bus CAN », sur enib.fr (consulté le 7 avril 2023).
↑ « Le bus CAN », sur igm.univ-mlv.fr (consulté le 24 octobre 2018)
↑ ISO 11898-2:2003, sur iso.org, 30 juillet 2014 (consulté le 28 décembre 2015)
↑ R. de Andrade, K. N. Hodel, J. F. Justo, A. M. Laganá, M. M. Santos et Z. Gu, « Analytical and Experimental Performance Evaluations of CAN-FD Bus », IEEE Access, vol. 6,‎ 2018, p. 21287 - 21295 (DOI 10.1109/ACCESS.2018.2826522)
↑ (en) « Understanding SDS, DeviceNet Protocol and Can Kingdom », sur Kvaser (consulté le 7 avril 2023).
↑ (en) « On the Difference Between CAN Open and CAN Kingdom », sur Kvaser (consulté le 7 avril 2023).

Voir aussi modifier

Articles connexes modifier

Liens externes modifier

Site web du CAN in Automation
P. Kadionik, Cours sur le CANbus de l'ENSEIRB [PDF]
(en) Plate-forme indépendante de discussion CANLIST
(en) Différentes interfaces CAN
(en) 1^re étude sur le déterminisme du bus CAN
(en) 2^e étude sur le déterminisme du bus CAN
Le bus CAN dans l'automobile
CAN Tutoriel Protocole

[1] ttp://ww1.microchip.com/downloads/en/AppNotes/00754.pdf

[2] ttps://www.can-cia.org/fileadmin/resources/documents/proceedings/2003_fellmeth.pdf

[3] (de) « Applications », sur can-newsletter.org (consulté le 7 avril 2023).

[4] (en) « CAN in Automation (CiA) : History of the CAN technology », sur can-cia.org (consulté le 7 avril 2023).

[5] « Bus CAN », sur enib.fr (consulté le 7 avril 2023).

[6] « Le bus CAN », sur igm.univ-mlv.fr (consulté le 24 octobre 2018)

[7] ISO 11898-2:2003, sur iso.org, 30 juillet 2014 (consulté le 28 décembre 2015)

[8] R. de Andrade, K. N. Hodel, J. F. Justo, A. M. Laganá, M. M. Santos et Z. Gu, « Analytical and Experimental Performance Evaluations of CAN-FD Bus », IEEE Access, vol. 6,‎ 2018, p. 21287 - 21295 (DOI 10.1109/ACCESS.2018.2826522)

[9] (en) « Understanding SDS, DeviceNet Protocol and Can Kingdom », sur Kvaser (consulté le 7 avril 2023).

[10] (en) « On the Difference Between CAN Open and CAN Kingdom », sur Kvaser (consulté le 7 avril 2023).

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]