Présentation 1

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

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

Chapitre 1 : Connaissances de base - Partie 1 : Historique 1980-1983 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) 1983-1987 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 : http://www.can-cia.de/ destiné à promouvoir les applications industrielles

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).

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

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

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 11898 + DS-102 + 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

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

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

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)

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

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

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

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

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

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

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 11898 + DS-102 + DRP-301-1

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 120 ohms à chaque extrémités Résistance du fil 70 milli-ohms / mètre nominal Temps de propagation 5 ns / mètre nominal Topologie Type bus dérivations les plus courtes possibles

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

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

Chapitre 2 : Couche physique - Partie 2 : Connectique recommandée Connectiques recommandées Le CiA préconise dans sa recommandation DR-303-1 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

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

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

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)

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

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

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

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

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

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

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)

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

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)

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).

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

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

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

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 11898-1 et 2 ISO 11898 + DS-102

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)

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…)

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

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

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=12-05-2000 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=0x0200005a 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: 1.0 Line4=Software version: 1.0 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

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

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=0x60400010 [1600sub2] ParameterName=2.mapped object DefaultValue=0x60420010

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

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

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 »

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

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

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

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

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

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

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é

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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.

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…)

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)

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

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"

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 ».