Présentation 1.

Présentation au sujet: "Présentation 1."— Transcription de la présentation:

1 Présentation 1

2 CANopen Chapitre 1 : Connaissances de base
Chapitre 2 : Couche physique Chapitre 3 : Couche liaison Chapitre 4 : Couche application 2

3 Chapitre 1 : Connaissances de base
CANopen Chapitre 1 : Connaissances de base Partie 1 : Historique Partie 2 : Caractéristiques principales 2

4 Chapitre 1 : Connaissances de base - Partie 1 : Historique
Création de CAN à l ’initiative de l’équipementier allemand BOSCH pour répondre à un besoin de l’industrie automobile CAN ne définit qu’une partie des couches 1 et 2 du modèle ISO (ISO 11898) Attractivité en prix des drivers et micro-contrôleurs intégrant CAN, du fait des gros volumes consommés par l’industrie automobile 1991 Naissance du groupement d’utilisateurs CIA = CAN in Automation : destiné à promouvoir les applications industrielles

5 Chapitre 1 : Connaissances de base - Partie 1 : Historique
1993 Publication par le CiA des spécifications CAL = CAN Application Layer Celles-ci décrivent les mécanismes de transmission, mais sans préciser quand ni comment les utiliser 1995 Publication par le CiA du profil de communication DS-301 : CANopen 2001 Publication par le CIA de la DS-304 permettant d’intégrer des composants de sécurité de niveau 4 sur un bus CANopen standard (CANsafe).

6 Les spécifications de référence
Chapitre 1 : Connaissances de base - Partie 2 : Caractéristiques principales Les spécifications de référence CANopen a été bâti chronologiquement à partir de plusieurs spécifications : CAN 2.0 A et B (origine Robert BOSCH) Définit précisément la couche liaison et une partie de la couche physique CAL = CAN Application Layer (CiA) Fournit des outils permettant de développer une application utilisant CAN sans mode d’emploi + précisions sur la couche physique CANopen (CiA) Définit quels outils CAL utiliser et comment Garantit l’interopérabilité des produits par la description de profiles

7 Chapitre 1 : Connaissances de base - Partie 2 : Caractéristiques principales
Modèle OSI 7 APPLICATION 6 PRESENTATION 5 SESSION 4 TRANSPORT 3 RESEAU 2 LIAISON = LLC + MAC 1 PHYSIQUE

8 CANopen et le modèle OSI
Chapitre 1 : Connaissances de base - Partie 2 : Caractéristiques principales CANopen et le modèle OSI Device Profile CiA DS-401 I/O modules CiA DS-402 Drives CiA DS-404 Measuring devices CiA DS-4xx CiA DS-301 = Communication profile Non implémentée CAN 2.0 A et B + ISO 11898 ISO DS DRP-301-1 CAL= CAN Application Layer APPLICATION PRESENTATION SESSION TRANSPORT RESEAU LIAISON = LLC + MAC PHYSIQUE 7 6 5 4 3 2 1 Spécifications CAN

9 Les spécifications de référence
Chapitre 1 : Connaissances de base - Partie 2 : Caractéristiques principales Les spécifications de référence

10 Medium : Paire torsadée blindée 2 ou 4 fils (si alimentation)
Chapitre 1 : Connaissances de base - Partie 2 : Caractéristiques principales Couche physique Medium : Paire torsadée blindée 2 ou 4 fils (si alimentation) Topologie : Type bus Avec dérivations courtes et résistance fin de ligne Distance maximum 1000 m Débit 9 débits possibles de 1Mbits/s à 10 Kbit/s Fonction de la longueur du bus et de la nature du câble : 25 m à 1 Mbits/s, 1000 m à 10Kbits/s NB maxi équipements 128 1 maître et 127 esclaves

11 Méthode d ’accès au médium : CSMA/CR
Chapitre 1 : Connaissances de base - Partie 2 : Caractéristiques principales Couche liaison Méthode d ’accès au médium : CSMA/CR (Carrier Sense Multiple Access / Collision Recovery) Chaque équipement peut émettre dès que le bus est libre Lors d’une collision, un principe de bits récessifs/dominants permet un arbitrage bit à bit non destructif (si on "néglige" le temps de propagation d’un bit, si 2 abonnés parlent en même temps, celui qui a mis un ‘1’ sur le bus, alors que l’autre aura mis un ‘0’, verra que le bus est occupé, et il s’arrêtera d’émettre, sans détruire la trame de l’autre)

12 Couche liaison : Bits dominants et bits récessifs
Chapitre 1 : Connaissances de base - Partie 2 : Caractéristiques principales Couche liaison : Bits dominants et bits récessifs Identificateur SOF RTR Champ de commande 10 9 8 7 6 5 4 3 2 1 Station 1 perd l ’arbitrage et arrête d ’émettre R Station 1 D Station 2 perd l ’arbitrage et arrête d ’émettre Station 2 Station 3 continue d ’émettre, sa trame n ’est pas modifiée Station 3 S1 S2 S3

13 Méthode d ’accès au médium : CSMA/CR
Chapitre 1 : Connaissances de base - Partie 2 : Caractéristiques principales Couche liaison Méthode d ’accès au médium : CSMA/CR (Carrier Sense Multiple Access / Collision Recovery) La priorité d ’un message est donné par la valeur de l’identificateur appelé COB-ID (Communication Object IDentifier) situé en début de trame Le COB-ID est codé sur 11 bits : valeurs comprises entre 0 et 2047 Le COB-ID de valeur la plus faible est prioritaire

14 Modèle de communication : Producteur / Consommateur
Chapitre 1 : Connaissances de base - Partie 2 : Caractéristiques principales Couche liaison Modèle de communication : Producteur / Consommateur Chaque message possède un identificateur unique situé en début de trame La valeur de cet identificateur renseigne les récepteurs sur la nature des données contenues dans chaque message. Chaque récepteur en fonction de sa configuration, consomme ou non ces données Taille maxi des données utiles : 8 octets par trame Sécurité de transmission Parmi les meilleurs sur les réseaux locaux industriels De nombreux dispositifs de signalisation et de détections d’erreurs permettent de garantir une grande sécurité de transmission

15 comment sont transmises les données :
Chapitre 1 : Connaissances de base - Partie 2 : Caractéristiques principales Couche application CANopen définit : comment sont transmises les données : Profil communication DS-301 commun à tous les produits Définit entre autre l’allocation des identificateurs (COB-ID) pour chaque type de message quelles sont les données transmises Profils produits DS-4xx propres à chaque famille de produit (E/S TOR, E/S analogique, variateurs de vitesse, encodeurs…) La description de ces fonctionnalités s’effectue par l ’intermédiaire d’un dictionnaire d ’objet : Device Object Dictionnary (OD), matérialisé par un fichier EDS

16 4 types de services sont standardisés :
Chapitre 1 : Connaissances de base - Partie 2 : Caractéristiques principales Couche application 4 types de services sont standardisés : 1 . Administration du réseau : paramétrage, démarrage, surveillance (maître-esclaves) 2 . Transmission rapide des données de process (<= 8octets) : PDO = Process Data Object (modèle producteur-consommateur) 3 . - Transmission de données de paramétrage sans contrainte de temps (peuvent être > 8 octets par segmentation) : SDO = Service Data Object (modèle client-serveur) 4 . Messages prédéfinis pour gérer les synchronisation, références temporelles, erreurs fatales : SFO = Special Function Object

17 Chapitre 2 : Couche physique
CANopen Chapitre 2 : Couche physique Partie 1 : Caractéristiques du médium Partie 2 : Connectiques recommandées 2

18 Chapitre 2 : Couche physique - Partie 1 : Caractéristiques du médium
Couche physique de CANopen Device Profile CiA DS-401 I/O modules Device Profile CiA DS-402 Drives Device Profile CiA DS-404 Measuring devices Device Profile CiA DS-4xx 7 APPLICATION CiA DS-301 = Communication profile CAL= CAN Application Layer 6 PRESENTATION Non implémentée 5 SESSION Non implémentée 4 TRANSPORT Non implémentée 3 RESEAU Non implémentée 2 LIAISON = LLC + MAC CAN 2.0 A et B + ISO 11898 1 PHYSIQUE CAN 2.0 A et B + ISO 11898 ISO DS DRP-301-1

19 Chapitre 2 : Couche physique - Partie 1 : Caractéristiques du médium
Description du médium Paire différentielle torsadée 1 paire si CAN-H / CAN-L 2 paires si CAN-H / CAN-L + alim. Impédance caractéristique de ligne 120 ohms nominal Terminaisons de ligne ohms à chaque extrémités Résistance du fil milli-ohms / mètre nominal Temps de propagation 5 ns / mètre nominal Topologie Type bus dérivations les plus courtes possibles

20 Chapitre 2 : Couche physique - Partie 1 : Caractéristiques du médium
Débit - longueur du bus - section câble pour 32 stations maximum

21 Chapitre 2 : Couche physique - Partie 1 : Caractéristiques du médium
Débit - longueur du bus - section câble pour 100 stations maximum

22 Chapitre 2 : Couche physique - Partie 2 : Connectique recommandée
Connectiques recommandées Le CiA préconise dans sa recommandation DR une liste de connecteurs classée en 3 catégories : Usage général connecteur SUB-D 9 points, connecteur DIN 41652, connecteur multipôles (câble plat vers SUB-D 9 points), connecteur RJ10, et connecteur RJ45 Usage industriel connecteur Mini Style 5 points, connecteur Micro Style 5 points, connecteur Open Style Usage particulier Connecteur rond 7 points, connecteur rond 8 points, connecteur rond 9 points, connecteur rond 12 points, connecteur Hand Brid Harting

23 Chapitre 2 : Couche physique - Partie 2 : Connectique recommandée
Connecteur SUB D 9 points DIN 41652 Mâle coté produit Pin Signal Description : 1 : Reserved 2 : CAN_L = CAN_L bus line dominant low 3 : CAN_GND = CAN Ground 4 : Reserved 5 : (CAN_SHLD) Optional CAN Shield 6 : (GND) Optional Ground 7 : CAN_H = CAN_H bus line dominant high 8 : Reserved 9 : (CAN_V+) Optional CAN external positive supply

24 Chapitre 2 : Couche physique - Partie 2 : Connectique recommandée
Connecteur RJ45 Pin Signal Description 1: CAN_H = CAN_H bus line (dominant high) 2: CAN_L = CAN_L bus line (dominant low) 3: CAN_GND = Ground / 0 V / V- 4: Reserved 5: Reserved 6: (CAN_SHLD) = Optional CAN Shield 7: CAN_GND = Ground / 0 V / V- 8 (CAN_V+) = Optional CAN external positive supply

25 Chapitre 2 : Couche physique - Partie 2 : Connectique recommandée
Connecteur 5-pin Mini Style : 7/8 Mâle coté produit Pin Signal Description : 1 : (CAN_SHLD) = Optional CAN Shield 2 : (CAN_V+) = Optional CAN external positive supply 3 : CAN_GND = Ground / 0V / V- 4 : CAN_H = CAN_H bus line (dominant high) 5 : CAN_L = CAN_L bus line (dominant low)

26 Chapitre 2 : Couche physique - Partie 2 : Connectique recommandée
Connecteur Open Style Mâle coté produit Pin Signal Description : 1 : CAN_GND = Ground / 0 V / V- 2 : CAN_L = CAN_L bus line (dominant low) 3 : (CAN_SHLD) = Optional CAN Shield 4 : CAN_H = CAN_H bus line (dominant high) 5 : (CAN_V+) = Optional CAN external positive supply

27 Chapitre 2 : Couche physique - Partie 2 : Connectique recommandée
Fournisseurs recommandés Câbles U.I.LAPP GmbH Schultze-Delitsch-Str. 25 D Stuttgart Germany Connecteurs ERNI Elektroapparate GmbH Seestrasse 9 D Adelberg Germany ERNI Connectique S.a.r.l, France 27 bis, avenue des Sources / CP 638 F LYON Cedex 09,

28 Chapitre 3 : Couche liaison
CANopen Chapitre 3 : Couche liaison Partie 1 : Format des trames Partie 2 : La sécurisation des échanges 2

29 Chapitre 3 : Couche liaison - Partie 1 : Format des trames
CAN 2.0.A et CAN 2.0.B La spécification CAN V2.0 comprend 2 versions : CAN 2.0.A et CAN 2.0.B CAN 2.0.A correspond au format de trame standard avec un identificateur sur 11 bits utilisée par CANopen et la plupart des couches applicatives CAN 2.0.B correspond au format de trame étendue avec un identificateur sur 29 bits peu utilisée

30 Chapitre 3 : Couche liaison - Partie 1 : Format des trames
Structure de la trame CAN 2.0.A Champ d ’arbitrage Taille de la trame sans bit stuffing : 47 à 111 bits 1 11 1 6 0 à 64 15 1 1 1 7 Bit RTR Remote Transmission Request Champ de données Délimit. CRC Délimit. ACK Début de trame SOF Indentifieur Champ de commande : compatibilité et longueur Séquence de CRC Slot ACK Fin de trame EOF

31 Chapitre 3 : Couche liaison - Partie 1 : Format des trames
Les 4 types de trames CAN Data Frame trames transportant des données d’un producteur vers des consommateurs, sans garantie de traitement Remote Frame trames de requête en polling émises par un maître vers un ou des esclaves, pour demander le renvoi d ’une trame de données (utilisées pour le Node Guarding, ou pour l ’émission des PDOs si ceux-ci sont configurés en polling) Error Frame trames émises lorsqu’une station détecte une erreur de transmission sur le bus Overload Frame trames émises pour demander un laps de temps supplémentaire entre des trames (de données ou de requête) successives

32 Chapitre 3 : Couche liaison - Partie 1 : Format des trames
Data Frame CAN V2.0 A Trame de données SOF IDENT RTR CTR DATA CRC ACK EOF Intertrame 1D 11X 1D 6X 0 à 64X 5X+1R 1X+1R 7R 3R Remote Frame CAN V2.0 A Trame de requête SOF IDENT RTR CTR DATA CRC ACK EOF Intertrame 1D 11X 1R 6X 0 à 64X 5X+1R 1X+1R 7R 3R Une trame de Donnée (Data frame) est prioritaire sur une trame de Requête (Remote frame)

33 Chapitre 3 : Couche liaison - Partie 1 : Format des trames
Error Frame Erreur détectée Trame en cours de diffusion ERROR FLAG ERROR DELIMITER ACTIVE ERROR FLAG : 6D 8R PASSIVE ERROR FLAG : 6R Overload Frame EOF ou ERROR DELIMITER Trame précédente OVERLOAD FLAG OVERLOAD DELIMITER 6D 8R

34 Chapitre 3 : Couche liaison - Partie 2 : La sécurisation des échanges
Les mécanismes de sécurisation Au niveau du bit lors de l ’émission de 5 bits consécutifs identiques, est introduit volontairement un bit supplémentaire dit de "stuffing", de valeur opposée. Ce bit est testé et éliminé par le récepteur Au niveau de la structure des trames des délimiteurs sont intégrés pour permettre la vérification de la structure CRC Delimiter, ACK Delimiter, End of Frame, Error Delimiter, Overload Delimiter . Au niveau de la validité du contenu un CRC permet aux récepteurs de vérifier la cohérence des données reçues ACK slot cette fenêtre permet à l ’émetteur de savoir si son message a bien été reçu par au moins une station (bit dominant)

35 Chapitre 3 : Couche liaison - Partie 2 : La sécurisation des échanges
Compteurs d’erreurs Chaque noeud comporte obligatoirement deux compteurs TEC : Transmit Error Counter REC : Receive Error Counter Ces compteurs s ’incrémentent et se décrémentent en utilisant un mécanisme de pondération sophistiqué gravé dans le silicium Suivant la valeur de ces compteurs, le nœud se trouve dans un des 3 états suivant : Erreurs actives Erreurs passives Bus OFF (driver d ’émission déconnecté du bus).

36 Chapitre 3 : Couche liaison - Partie 2 : La sécurisation des échanges
Valeur des compteurs / état du noeud Reset et configuration Erreurs actives REC > 127 ou TEC > 127 REC < 128 et TEC < 128 Erreurs passives 128 occurrences de 11 bits récessifs consécutifs (fin de trames sans erreurs) TEC > 255 Bus OFF

37 Chapitre 3 : Couche liaison - Partie 2 : La sécurisation des échanges
Comportement en cas d’erreur de communication détecté Etat Erreurs actives dès la détection du défaut, le nœud émet une trame Error Frame, avec un champ ACTIVE ERROR FLAG les 6 bits dominants émis transgressent la loi de bit stuffing, et provoquent une réaction en chaîne des autres nœuds qui détruit la trame en cours Etat Erreurs passives Dès la détection du défaut, le nœud émet une trame Error Frame avec un champ PASSIVE ERROR FLAG Les bits récessifs émis n ’ont aucune influence sur la trame en cours d ’émission Etat Bus OFF : Le nœud est déconnecté et surveille le bus

38 Chapitre 4 : Couche application
CANopen Chapitre 4 : Couche application Partie 1 : Concepts de base de CANopen Partie 2 : Objets et services CANopen Hygjkjki dsfgdwgdswf sdvg<svgsvg sdvggdsbvs sdgvsfd 2

39 CANopen s’appuie sur CAL
Chapitre 4 : Couche application - Partie 1 : Concepts de base de CANopen CANopen s’appuie sur CAL Device Profile CiA DS-401 I/O modules Device Profile CiA DS-402 Drives Device Profile CiA DS-404 Measuring devices Device Profile CiA DS-4xx 7 APPLICATION CiA DS-301 = Communication profile CAL= CAN Application Layer 6 PRESENTATION Non implémentée 5 SESSION Non implémentée 4 TRANSPORT Non implémentée 3 RESEAU Non implémentée 2 LIAISON = LLC + MAC CAN 2.0 A et B + ISO 11898 1 PHYSIQUE CAN 2.0 A et B = ISO et 2 ISO DS-102

40 Couche application CANopen définit :
Chapitre 4 : Couche application - Partie 1 : Concepts de base de CANopen Couche application CANopen définit : comment sont transmises les données : Profil communication DS-301 commun à tous les produits Définit entre autre l’allocation des identificateurs COB-ID pour chaque type de message. quelles sont les données transmises : Profils produits DS-4xx propre à chaque famille de produit (E/S TOR, E/S analogique, variateurs de vitesse, encodeurs…) La description des ces fonctionnalités s’effectue par l’intermédiaire d ’un dictionnaire d ’objet Device Object Dictionnary (OD)

41 Dictionnaire d’Objets [Object Dictionary]
Chapitre 4 : Couche application - Partie 1 : Concepts de base de CANopen Dictionnaire d’Objets [Object Dictionary] Le Dictionnaire d’Objets (OD) est un groupement ordonné des objets accessibles sur un type de nœud donné, via : un index, sur 16 bits éventuellement un sous-index, sur 8 bits Le Dictionnaire d’Objets (OD) contient l’ensemble des paramètres décrivant un produit, ainsi que son comportement vis à-vis du réseau Cette description est matérialisée par un fichier EDS : Electronic Data Sheet de format ASCII, respectant une syntaxe stricte et exploitable par les logiciels de configuration du bus (Sycon etc…)

42 Structure du Dictionnaire d’Objets [Object Dictionary]
Chapitre 4 : Couche application - Partie 1 : Concepts de base de CANopen Structure du Dictionnaire d’Objets [Object Dictionary] :khgjhjhj

43 Profil de communication DS-301
Chapitre 4 : Couche application - Partie 1 : Concepts de base de CANopen Profils CANopen Profil de communication DS-301 Décrit la structure générale de l’Object Dictionary, et des objets se trouvant dans la zone "Communication profile area"  : index 1000 à 1FFF Applicable à tous les produits CANopen Profils équipements DS-4xx Décrivent pour les différents types de produit (modules E/S TOR, E/S analogiques, variateurs, appareil de mesures, … ) les différents objets associés Objets standardisés : Index 6000 à 9FFF Objets spécifiques : Index 2000 à 5FFF Certains objets sont obligatoires, d ’autres optionnels Ils sont accessibles soit en lecture, soit en lecture et écriture

44 Extrait du fichier EDS CANopen ATV58
Chapitre 4 : Couche application - Partie 1 : Concepts de base de CANopen Extrait du fichier EDS CANopen ATV58 [FileInfo] FileName=A58_F.eds FileVersion=1 FileRevision=2 Description=Carte Option ATV58 CreationTime=00:00AM CreationDate= CreatedBy=Marie-Annick Menanteau, Schneider Electric [DeviceInfo] VendorName=Schneider Electric ProductName=ATV58_F ProductVersion=1 ProductRevision=1 BaudRate_10=0 BaudRate_20=0 BaudRate_50=0 BaudRate_100=0 BaudRate_125=1 BaudRate_250=1 BaudRate_500=1 BaudRate_800=0 BaudRate_1000=1 Granularity=0x8 VendorNumber=0x a ProductNumber=0 SimpleBootUpMaster=0 ExtendedBootUpMaster=0 SimpleBootUpSlave=1 ExtendedBootupSlave=0…. [Comments] Lines=6 Line1=Used profile: 402 Line2=Manufacturer device name: VW3A58306 Line3=Hardware version: Line4=Software version: Line6= This is the EDS file for the CANopen Schneider Electric ATV58 drive module CAN Communication Adapter [MandatoryObjects] SupportedObjects=12 1=0x1000 2=0x1001 3=0x6040 4=0x6041 5=0x6042 6=0x6043 7=0x6044 8=0x6046 9=0x6048 10=0x6049 11=0x6060 12=0x6061 [1000] ParameterName=Device Type ObjectType=7 DataType=0x0007 AccessType=RO DefaultValue=0x10192 PDOMapping=0

45 Extrait du fichier EDS CANopen ATV58
Chapitre 4 : Couche application - Partie 1 : Concepts de base de CANopen Extrait du fichier EDS CANopen ATV58 [1400] SubNumber=0x03 ParameterName=receive PDO1 parameter ObjectType=6 [1400sub0] ParameterName=number of entries ObjectType=7 AccessType=CONST DataType=0x0005 PDOMapping=0 LowLimit=2 HighLimit=4 DefaultValue=0x2 [1400sub1] ParameterName=COB-ID ObjectType=7 AccessType=RW DataType=0x0007 PDOMapping=0 LowLimit= HighLimit= DefaultValue=$NODEID+0x200 [1400sub2] ParameterName=transmission type AccessType=CONST DataType=0x0005 DefaultValue=0xFF

46 Extrait du fichier EDS CANopen ATV58
Chapitre 4 : Couche application - Partie 1 : Concepts de base de CANopen Extrait du fichier EDS CANopen ATV58 [1600] SubNumber=0x03 ParameterName=receive PDO mapping ObjectType=6 [1600sub0] ParameterName=number of mapped objects ObjectType=7 AccessType=RW DataType=0x0007 PDOMapping=0 LowLimit=0 HighLimit=2 DefaultValue=0x2 [1600sub1] ParameterName=1.mapped object ObjectType=7 AccessType=RW DataType=0x0007 PDOMapping=0 LowLimit= HighLimit= DefaultValue=0x [1600sub2] ParameterName=2.mapped object DefaultValue=0x

47 Résumé des concepts de base
Chapitre 4 : Couche application - Partie 1 : Concepts de base de CANopen Résumé des concepts de base Chaque type de message CANopen possède un identificateur COB-ID unique, codé sur 11 bits : valeurs comprises entre 0 et 2047 Chaque nœud peut envoyer un message dès que le réseau est libre Les collisions sont résolues suivant la priorité de chaque message L ’identificateur de valeur la plus basse est prioritaire Un message CAN peut transporter au maximum 8 octets de données utiles

48 Profil de communication CANopen DS-301
Chapitre 4 : Couche application - Partie 2 : Objets et services CANopen Profil de communication CANopen DS-301 Le profil de communication CANopen définit 4 fonctions standardisés : 1 . Administration du réseau : démarrage du bus, affectation des identificateurs, paramétrage, et surveillance NMT = Network ManagemenT (modèle maître-esclave) 2 . Transmission rapide des Données de Process (<= 8 octets) : PDO = Process Data Object (modèle producteur-consommateur) 3 . Transmission de Données de Paramétrage sans contrainte de temps SDO = Service Data Object (modèle client-serveur) (peuvent être > 8 octets par segmentation) 4 . Messages prédéfinis pour gérer les synchronisation, références temporelles, erreurs fatales : SFO = Special Function Object

49 Démarrage du bus Administration du Réseau : NMT
Chapitre 4 : Couche application - Partie 2 : Objets et services CANopen Administration du Réseau : NMT Démarrage du bus Diagramme d ’état correspondant au « CANopen minimum boot-up » * (service obligatoire) Transitions effectuées Types d ’objet par le maître NMT de communication autorisés 1: Start_Remote_Node a. NMT 2: Stop_Remote_Node b. Node Guard 3: Enter_Pre-Operational_State c. SDO 4: Reset_Node d. EMCY 5: Reset_Communication e. PDO. 6: Initialisation du nœud terminée NOTA : Il existe un autre diagramme d ’état « Extended boot-up »

50 Allocation des Identificateurs
Chapitre 4 : Couche application - Partie 2 : Objets et services CANopen Allocation des Identificateurs L ’allocation des identificateurs peut s’effectuer par 3 méthodes : En utilisant l’allocation par défaut : CANopen Predefined Set existence de ce mode d ’allocation obligatoire disponible dans l’état Pre-Opérationnel permet de réduire la phase de configuration du réseau données de process échangées suivant un mode maître esclaves Par application, dans l’état Pre-Operationnel Ecriture dans les objets correspondant du dictionnaire via le service SDO En utilisant le service DBT (DistriBuTor) possible sur les produits qui supportent la fonction « Extended boot up  » affectation des identificateurs effectuée automatiquement par ajout d’étapes supplémentaires entre l’état Pre-Operationnel et Operationnel

51 Allocation par défaut des Identificateurs
Chapitre 4 : Couche application - Partie 2 : Objets et services CANopen Allocation par défaut des Identificateurs Pour réduire la phase de configuration du réseau a été défini un système obligatoire d’allocation des identificateurs par défaut Ce mode d’allocation est effectif dans l’état "Pré-Operationnel", juste après la phase d ’initialisation Elle est basée sur un partage de l’identificateur COB-ID en 2 parties : Code Fonction : permet le codage de 4 PDOs en réception, 4 PDOs en émission, 1 SDO (occupant 2 Identificateurs), 1 EMCY object, 1 Node Guardind Identifier, 1 SYNC object, 1 Time Stamp object Node ID : correspond à l’adresse du nœud, codée par exemple par DIP switches 10 9 8 7 6 5 4 3 2 1 Code Fonction Node ID

52 Allocation par défaut des Identificateurs
Chapitre 4 : Couche application - Partie 2 : Objets et services CANopen Allocation par défaut des Identificateurs

53 défaut n’est utilisable
Chapitre 4 : Couche application - Partie 2 : Objets et services CANopen L ’allocation des identificateurs par défaut n’est utilisable que pour les nœuds n ’utilisant que les 4 premiers PDO (Le cinquième PDO recouvre la zone réservée aux SDO) Allocation par défaut des Identificateurs 1024 identificateurs maximum résersvés pour les PDOs

54 Allocation par défaut des Identificateurs
Chapitre 4 : Couche application - Partie 2 : Objets et services CANopen Allocation par défaut des Identificateurs Esclave 1 TxPDO_1_SL1 Master TxPDO_2_SL1 RxPDO_1_SL1 RxPDO_2_SL1 RxPDO_1_SL2 RxPDO_2_SL2 RxPDO_1_SL3 RxPDO_2_SL3 TxPDO_1_SL1 TxPDO_2_SL1 TxPDO_1_SL2 TxPDO_2_SL2 TxPDO_1_SL3 TxPDO_2_SL3 RxPDO_1_SL1 Entrées RxPDO_2_SL1 Esclave 2 Tous les nœuds (esclaves) communiquent avec une station centale (maître) TxPDO_1_SL2 TxPDO_2_SL2 RxPDO_1_SL2 RxPDO_2_SL2 Sorties Esclave 3 TxPDO_1_SL3 TxPDO_2_SL3 RxPDO_1_SL3 RxPDO_2_SL3

55 Modification de l’allocation par défaut
Chapitre 4 : Couche application - Partie 2 : Objets et services CANopen Modification de l’allocation par défaut Permet d ’échanger des données directement sans passer par le maître (PDO linking) Utilisation du concept producteur-consommateur Exemple : Commande d’axes Produit X Produit Z Produit Y

56 Process Data Objects = PDOs
Chapitre 4 : Couche application - Partie 2 : Objets et services CANopen Process Data Objects = PDOs Services utilisés pour l ’émission en temps réel de données de process de faible taille (<= 8 octets) Ils permettent à un équipement producteur de mettre à disposition d’un ou plusieurs consommateurs une variable de taille maximum de 64 bits sans overhead Ce service est est un service non confirmé

57 COB-ID utilisé par le PDO mode de transmission/réception utilisé
Chapitre 4 : Couche application - Partie 2 : Objets et services CANopen Description des PDOs Chaque PDO en émission ou réception est décrit par 2 objets dans le Dictionnaire d’Objets : le PDO Communication Parameter, qui indique comment est transmis ou reçu un PDO : COB-ID utilisé par le PDO mode de transmission/réception utilisé durée minimale entre 2 messages (inhibit time) pour les PDOs en émission le PDO Mapping Parameter indique quelles sont les données transportées : liste des objets du dictionnaire d’objet (OD) mappés dans le PDO taille de chaque objet en bits

58 Objets TxPDO Communication parameter
Chapitre 4 : Couche application - Partie 2 : Objets et services CANopen Objets TxPDO Communication parameter PDO en émission : Index 0x1800 à 0x19FF Exemple : TxPDO1 = 0x1800, TxPDO2 = 0x1801, TxPDO3 = 0x1802, TxPDO4 = 0x1803

59 Objets TxPDO Mapping parameter
Chapitre 4 : Couche application - Partie 2 : Objets et services CANopen Objets TxPDO Mapping parameter PDO en émission : Index 0x1A00 à 0x1BFF

60 Objets RxPDO Communication parameter
Chapitre 4 : Couche application - Partie 2 : Objets et services CANopen Objets RxPDO Communication parameter PDO en réception : Index 0x1400 à 0x15FF

61 Objets RxPDO Mapping parameter
Chapitre 4 : Couche application - Partie 2 : Objets et services CANopen Objets RxPDO Mapping parameter PDO en réception : Index 0x1600 à 0x17FF

62 Modes d’émission des PDOs
Chapitre 4 : Couche application - Partie 2 : Objets et services CANopen Modes d’émission des PDOs Synchrone : sur réception d’un message SYNC Acyclique : émission pré-déclenchée par l’occurrence d’un événement sur le nœud (événement spécifié dans le profil du nœud) émission pré-déclenchée sur réception d’une trame "Remote Request" (polling) émise depuis un autre nœud Cyclique émission déclenchée périodiquement, après réception de 1, 2, ... jusqu’à 240 messages SYNC Asynchrone transmission déclenchée par l’occurrence d ’un événement sur l’équipement (événement spécifié dans le profil du nœud ) transmission déclenchée sur réception d’une trame "Remote Request" émise depuis un autre nœud

63 Emission synchrone acyclique des PDOs
Chapitre 4 : Couche application - Partie 2 : Objets et services CANopen Emission synchrone acyclique des PDOs Sur événement - Transmission Type = 0 SYNC SYNC SYNC SYNC SYNC TxPDO Evénement sur Nœud X Sur réception d ’une Remote Request (polling) - Transmission Type = 252 SYNC Remote request vers Nœud X SYNC SYNC SYNC Remote request vers Nœud X SYNC TxPDO TxPDO

64 Emission synchrone cyclique des PDOs
Chapitre 4 : Couche application - Partie 2 : Objets et services CANopen Emission synchrone cyclique des PDOs Cyclique sur n signaux de synchro - Transmission Type = 1 à 240 (nombre de messages SYNC) SYNC SYNC SYNC SYNC SYNC SYNC SYNC SYNC SYNC TxPDO TxPDO TxPDO Exemple si n = 3 Exemple si n = 3

65 Emission asynchrone des PDOs
Chapitre 4 : Couche application - Partie 2 : Objets et services CANopen Emission asynchrone des PDOs Sur événement - Transmission Type : 254 = événement spécifique; 255 = événement défini dans profil SYNC SYNC SYNC SYNC SYNC Evénement sur Nœud X TxPDO Sur réception d’une Remote Request (polling) - Transmission type = 253 SYNC SYNC SYNC SYNC Remote request vers Nœud X SYNC Remote request vers Nœud X TxPDO TxPDO

66 Emission des PDOs : Inhibit time
Chapitre 4 : Couche application - Partie 2 : Objets et services CANopen Emission des PDOs : Inhibit time Pour garantir que des objets ayant un niveau faible de priorité puisse être transmis, il est possible d’affecter un temps minimum entre 2 émissions d’un même PDO. Cette valeur est renseignée dans le paramètre «Inhibit time» des objets TxPDO, communication parameters index 0x1800 à 0x180F.

67 Réception synchrone acyclique des PDOs
Chapitre 4 : Couche application - Partie 2 : Objets et services CANopen Réception synchrone acyclique des PDOs Sur événement - Transmission Type = 0 SYNC SYNC SYNC SYNC SYNC Rx_PDO Tx_PDO Prise en compte du PDO reçu

68 Réception synchrone cyclique des PDOs
Chapitre 4 : Couche application - Partie 2 : Objets et services CANopen Réception synchrone cyclique des PDOs Cyclique sur n signaux de synchro - Transmission Type = 1 à 240 SYNC SYNC SYNC SYNC SYNC SYNC SYNC SYNC SYNC RxPDO T_PDO RxPDO T_PDO Exemple si n = 3 Exemple si n = 3 Prise en compte du PDO reçu Prise en compte du PDO reçu

69 Réception asynchrone des PDOs
Chapitre 4 : Couche application - Partie 2 : Objets et services CANopen Réception asynchrone des PDOs Sur événement - Transmission type=254 SYNC SYNC SYNC SYNC SYNC RxPDO T_PDO Prise en compte du PDO reçu

70 Service Data Objects = SDO
Chapitre 4 : Couche application - Partie 2 : Objets et services CANopen Service Data Objects = SDO Ces services sont utilisés pour la transmission en point à point de données de paramétrage n’ayant pas de contraintes de temps. Ils permettent à un équipement client (gestionnaire du bus) d’accéder en écriture ou en lecture au dictionnaire d’objets d’un équipement serveur (stations 1 à 127), en l’adressant par son Index et Sub-index La taille des données peut dépasser 8 octets : dans ce cas un système de segmentation des données est activé Le résultat d ’une écriture ou d ’une lecture est confirmé par une réponse Un échange SDO requiert 2 COB-IDs : un pour la requête, l ’autre pour la réponse

71 Special Function Objects = SFO
Chapitre 4 : Couche application - Partie 2 : Objets et services CANopen Special Function Objects = SFO SYNC = Synchronization Object : Objets utilisés pour synchroniser l’acquisition de données d’entrées, ou la mise à jour de de données en sorties (commande d ’axes par exemple). Le Gestionnaire du bus émet le message SYNC selon la période de communication (cycle period) définie lors de la configuration

72 Special Function Objects = SFO
Chapitre 4 : Couche application - Partie 2 : Objets et services CANopen Special Function Objects = SFO Time Stamp Object : L ’objet Time-Stamp fournit une référence de temps commune à tous les stations. Ce temps est codé sur 6 octets et représente un temps absolu en ms à partir du 1er janvier 1984 Il permet de synchroniser l ’horloge locale de toutes les stations.

73 Special Function Objects = SFO
Chapitre 4 : Couche application - Partie 2 : Objets et services CANopen Special Function Objects = SFO EMCY Object : Les objets EMCY (Emergency) sont utilisés pour transmettre des défauts applicatifs associés à chaque station (courant, tension, température, etc…)

74 Special Function Objects = SFO
Chapitre 4 : Couche application - Partie 2 : Objets et services CANopen Special Function Objects = SFO 2 mécanismes permettent de surveiller l’état des stations présentes sur le bus Node guarding Fonctionne suivant un concept maître esclave (polling) permet au manager du bus de demander (Remote request) l ’état de chaque station, selon une période définie en configuration Heartbeat Fonctionne suivant un concept producteur consommateur. L’état de la station est produit cycliquement sur le réseau, à une période définie en configuration Ce mécanisme, nouvellement spécifié, remplace le node guarding sur les nouveaux produits (meilleurs utilisation de la bande passante)

75 Special Function Objects = SFO
Chapitre 4 : Couche application - Partie 2 : Objets et services CANopen Special Function Objects = SFO Node guard Object : Le maitre NMT surveille l’état des esclaves connectés sur le bus en émettant périodiquement (Guard time) une trame ‘ remote frame ’ demandant son Node guard object à chaque esclave Dès réception, l’esclave répond au maître Les esclaves peuvent éventuellement surveiller le maître NMT : il s ’agit alors du Life guarding : Life Time = Guard Time x Life Time Factor Si pendant un temps égal au Life Time un esclave ne reçoit pas de polling, il génère un événement "Life guarding", passe en défaut communication et envoie un objet EMCY

76 Special Function Objects = SFO
Chapitre 4 : Couche application - Partie 2 : Objets et services CANopen Special Function Objects = SFO Node guard Object : Le maitre NMT scrute régulièrement l’état de chacun des esclaves par une Remote Frame et les compare aux valeurs précédentes enregistrées dans une table. Si une différence est détectée, l’information est remontée à l’application par l ’événement "Network Event"

77 Special Function Objects = SFO
Chapitre 4 : Couche application - Partie 2 : Objets et services CANopen Special Function Objects = SFO Heartbeat : La fonction Heartbeat nouvellement spécifiée permet d ’économiser la bande passante par rapport au Node Guarding Le producteur de Heartbeat transmet le message Heartbeat suivant une période définie dans l ’objet « Heartbeat Producer Time » Le consommateur de Heartbeat vérifie qu ’il reçoit le message Heartbeat dans la fenêtre de temps défini dans l ’objet « Heartbeat Consumer Time ».