Les couches applicatives de CAN Controller Area Network

Les couches applicatives de CAN Controller Area Network Device Net CAN Open - CAL SDS Présentation Patrick MONASSIER Université Lyon 1 France 1

Device Net Présentation 2

Device. Net - Présentation • Normalise la Couche 7 ISO + partie basse de la couche 1 ISO • S’appuie sur CAN ISO 11898 - Commercialisation fin 1994 • Appartient à l’organisme ODVA (Open Device. Net Vendor Association) qui est une association d’offreur de services autour de Device. Net - Le but de l’ODVA est de promouvoir Device. Net. • En 1997 environ 200 sociétés - Plus de 100 produits différents : Rockwell Automation, OMRON, Hitachi, AEG, Schneider, Hohner, Yaskawa, Mitsubichi, Crouzet, Softing, Leroy Automatique, NSI, Vector, Lumberg. . . • Spécifications disponibles, pas de licence, le système est ouvert. • ODVA 8222 Wiles Road , suite 287, Coral Springs, FL 33067 USA Tel (1) 954 340 5412 Fax (1) 954 340 5413 • Allen Bradley Rockwell Ave de l’Europe 78941 Velizy Cedex France Tel 01 3067 7200 Fax 01 3465 3233 http: //www. odva. org 3

Device. Net et les couches ISO Couche 7 Couche Application ISO Couche 2 Couche liaison de données Signal Physique Couche Application Device. Net Protocole CAN ISO Couche 1 Transmetteur/Récepteur Médium Couche physique Device. Net Support de transmission 4

Device. Net - Les couches ISO Couche Communication de données • Messagerie et mode de connexion • Modes d’adressages • Echange de donnes • Fragmentation • Profils de communication Couche Physique • Medium de transmission et topologie du réseau • Connexion au medium • Possibilités d’alimentation par les stations Device. Net 5

Couche Communication de données • Device. Net s’appuie sur la trame CAN 2. 0 A (identifieur 11 bits) • Le protocole Device. Net est complètement intégré dans la trame • 2 modes de messagerie – Implicite ou haute priorité pour Entrées/Sorties (temps réel) – Explicite ou basse priorité pour diagnostics, configuration. . . • 2 modèles de communication – Modèle Producteur/Consommateur (Broadcast) en implicite – Modèle Client/Serveur (point à point) souvent en explicite • Les 2 modes de messageries et les 2 modèles de communication sont définis dans l’identifieur de la trame CAN 6

Connexions et messages • • • La communication Device. Net est établie sur le mode «objets» Avant d’échanger des données, il faut établir une connexion Une connexion est établie entre deux ou plusieurs points finaux Le Connection Object est l’un des Communication Objects C’est le container des caractéristiques de la communication 2 types principaux de connexions – I/O connections (Implicite, pour les Entrées/Sorties) – Explicit Messaging Connections (diagnostics, configurations. . . ) 7

I/O connections & I/O messages Station émettrice I/O data Application I/O messages Station réceptrice I/O message Connection I/O Connection I /O data Connection I/O Connection Application I /O messages Les IO data sont inclues dans le champs des données de la trame CAN (8 octets maxi). Device. Net ne définit aucune information quant au protocole régissant les données. La signification des données est implicite selon le I/O connection (connection ID associé). 8

Explicit Messaging Connections Station 1 Explicit messages Question Réponse Station 2 Question Connection Réponse Les connection Explicites sont à usage multiple. Les messages qui sont construits dans la trame CAN, sont constitués d’un Connection ID et d’une information de protocole message. Device. Net ne fournit pas d’indications sur le protocole. Il définit un protocole de fragmentation permettant des échanges de taille supérieure à 8 octets (trame CAN). 9

Identifieur CAN selon Device. Net 10 9 0 8 7 6 Groupe 1 5 4 3 2 1 0 Valeur Hex Source MAC ID 000 -3 FF Message groupe 1 400 -5 FF Message groupe 2 600 -7 BF Message groupe 3 Message ID 1 0 MAC ID Groupe 2 Message ID 1 1 Groupe 3 Source Mac. ID Message ID 1 1 1 Groupe 4 7 C 0 -7 EF Message groupe 4 Message ID 1 1 1 7 F 0 -7 FF ID non valides 10

Groupe de priorité La construction des identifieurs selon Device. Net permet de définir 3 groupes distinct, fonction des bits de poids fort: Bit 10 Bit 9 Groupe Priorité Application 0 1 1 x 0 1 groupe 2 groupe 3 groupe 4 haute moyenne basse très faible Entrées/sorties Maître/Esclave messages non définie 11

Définitions • Message ID identifie un message particulier à l’intérieur d’un groupe de messages spécifiques. • Source MAC ID désigne la station assurant la transmission. Les groupes 1 et 3 imposent sa présence dans l’identifieur. • Destination MAC ID désigne la station destinatrice du message. L’accès au bus est défini par la valeur message ID pour les groupes 1 et 3, et par la valeur du MAC ID pour le groupe 2. Bien que d’autres configurations soient possibles, par définition, les groupes sont utilisés pour les connexion: • Entrées/Sorties pour le groupe 1 • Entrées/Sorties et messages explicites pour le groupe 2 • Messages explicites pour le groupe 3 12

Etablissement d’une connexion • Le but de la couche applicative Device. Net est de fournir, pour des applications particulières, des informations pertinentes d’Entrées/Sorties en temps réel. • Device. Net définit, construit la configuration complète, dynamique, des I/O connections entre stations. • Une grande partie des Connection Information peut être configurée à la mise sous-tension de la station. • Device. Net pédéfinit un jeu de connexions Maître/Esclaves: le predefined Master/Slave Connection Set. 13

Modes d’adressage de Device. Net MAC ID #1 MAC ID #2 MAC ID #4: Object classe #5 Instance #2: Attribute #1 réseau instance #1 object classe #5 Attribute #1 Attribute #2 instance #1 object classe #7 instance #2 instance #1 MAC ID #3 object classe #5 MAC ID #4 14

CAN Open PRESENTATION de la COUCHE APPLICATIVE 15

CANopen principes • La couche applicative CANopen décrit un concept de réseau basé sur la couche applicative CAL et sur le protocole CAN. • Le CANopen Communication profile a été defini en 1995 par le Ci. A, et débouchait sur le premier I/O Device Profile en 1996. • Les deux profils (Communication et I/O Device) de CANopen utilisent des services de la couche applicative CAL. • L’objectif de la couche applicative CANopen est de faciliter, permettre et autoriser la création économique de: – systèmes de commandes décentralisées. – systèmes d’entrées/sorties distribuées. – systèmes capteurs actionneurs mis en réseau. 16

CANopen relations entre CAL et CANopen • La spécification CAL, définie en premier, représente un ensemble de services et d’objets, sans mode d’emploi précis. • L’un des buts de CANopen est de définir quels services et quels objets doivent être utilisés, avec quels paramètres et comment interpréter ces paramètres. • CANopen peut être vu comme un mode d’emploi de CAL. • CANopen permet de construire une couche applicative sur le concept de Device Profiles (profiling) • Cette construction présente des avantages: – Les caractéristiques obligatoires font que la fonctionnalité minimale du réseau est atteinte – Les possibilités de performances optionnelles donnent une grande souplesse aux extensions possibles. – Les Hooks (crochets) ouvrent la possibilité de concevoir des éléments spécifiques standards multiconstructeurs. 17

CANopen modèle ISO Couche 8 Device profile A Device profile B Device profile C Standard Device «futur proof» CANopen Device Profile Ci. A DS 401 à 406 CANopen Communication Profile Ci. A DS 301 ISO Couche 7 Communication Profile ISO Couche 7 CAL (Can Application Layer) CAL ISO Couche 2 CAN Protocol (Data Link Layer) CAN ISO 11898 ISO Couche 1 Physical Layer CAL Bus CAN 18

CANopen spécifications Communication profile for Industrial System Ci. A DS 301 3. 0 1996 Framework for Programmable devices Ci. A DS 302 1. 0 1997 Devices profiles – For I/O modules Ci. A DS 401 1. 4 1996 – For drives and motion control Ci. A DS 402 1. 0 1997 – For Human machine interface Ci. A DS 403 – For measure & close-loop devices Ci. A DS 404 1. 0 1997 – For Encoders Ci. A DS 406 1. 0 1997 19

CANopen modèle de communication • Services et Process Data Object - SDO et PDO – SDO: utilisée pour transmettre des paramètres et/ou données n’ayant pas d’aspect temps réel (configuration, chargement de programmes. . . ) – PDO: utilisée pour transmettre les données applicatives temps réel • Modes de transmission des PDO –Synchrone –Asynchrone • Modes de déclenchement des PDO –événement –requêtes asynchrones • Objets de communication prédéfinis de Can. Open – SYNC objects – Time Stamp Objects – Emergency Objects 20

CANopen Service Data Object SDO byte 0 Start of telegram frame bytes 1 -3 domain command specification 3 bytes profile identification 16 bits index data type unsigned 16 byte 0 Start of telegram frame domain command specification bytes 4 -7 4 bytes profile data end of telegram frame INITIATE COMMAND 8 bits sub-index data type unsigned 8 bytes 1 -7 7 bytes profile data end of telegram frame SEGMENT COMMAND 21

CANopen transmission synchrone et asynchrone Object SYNC fenêtre des objects SYNC PDO asynchrones PDO synchrones Période du cycle de communication Longueur de la fenêtre de synchronisation Message SYNC Messages actuels Message SYNC Messages de commande 22

CAL CAN Application Layer PRESENTATION de la COUCHE APPLICATIVE 23

CAL CAN Application Layer • Définition des spécifications d’une couche applicative système ouvert, basée sur le protocole CAN. • En 1992, par le Ci. A (CAN In Automation), naissance des CAL (CAN Application layers). • Pas de droit de licence, ni de royalties. • Fonction détaillées dans documents Ci. A / DS 201 à 205 Contact: Ci. A CAN in Automation Am Weichselgarten 26 D-91508 Erlangen Tel +49 9131 601091 Fax +49 9131 601092 http: //www. can-cia. org 24

CAL Les couches ISO Couche 7 Couche Application ISO Couche 2 Couche liaison de données Signal Physique Couche Application CAL Protocole CAN ISO Couche 1 Transmetteur/Récepteur Médium Support de transmission Couche physique CAL 25

CAL Présentation CAL fournit aux utilisateurs: • • l’administration du réseau et des couches les fonctionnalités de maître et superviseur d’un système les objets et services de communication standard la distribution des identificateurs CAL est constitué de 4 entités principales: • • CMS CAN based Message Spécification NMT Network Management DBT identifier Distri. Bu. Tor LMT Layer Managemen. T 26

CAL Présentation CMS décrit le façon d’interfacer le réseau physique CAN (règles de codage). CMS décrit aussi la description d’objets de communication (variables, event. . . ) Les objets CMS de base permettent une communication «orientée message» Les objets CMS évolués permettent de réaliser des connexions entre éléments dite «orientée communication» CMS Spécification des messages basés sur CAN Variables Evènements Domaines Régles de codage NMT Maitre Administration du réseau Esclave DBT Maitre Distributeur des identifications Esclave LMT Maitre Administartion des couches Esclave 27

CAL Présentations DBT, NMT, LMT • DBT (identifier Distri. Bu. Tor) est responsable de l’affectation dynamique de la valeur des identifieurs. • NMT (Network Managemen. T) est responsable de l’administration du réseau –spécifie les services généraux et d’administration du réseau –réalise l’initialisation globale du réseau –initialise, si nécessaire, la distribution dynamique des identifieurs –assure la supervision du réseau en fonctionnement (fonction guarding) –basé sur une relation maître/esclave (1 maître NMT/ 255 esclaves NMT maxi) (fonction guarding: détection des stations connectées, opérationnelles en temps réel) • LMT (Layer Managemen. T) définit des services permettant une configu- ration large du réseau et de certains paramètres des couches CAL: –numéros d’identificateurs individuels et des noeuds –paramètres temporels CAN (Nominal Bit time. . . ). . . etc. 28

CAL Primitives et types de services 4 services de primitives • requête : demande de l’application à la couche applicative • indication : fournie par la couche applicative pour rapporter un événement interne • réponse : fournie par l’application vers la couche applicative pour répondre à une indication reçue • confirmation : fournie par la couche applicative à l’application pour rapporter le résultat d’une requête précédente. 4 types de services • services locaux • services initialisés par le fournisseur • services non confirmés • services confirmés Voir les figures page suivante 29

CAL Primitives et types de services Application X requête indication Service local Application X Service initialisé par un fournisseur Application Y Application X Application Y requête indication confirmation Service non confirmé réponse Service confirmé 30

CMS langage de modélisation pour applications distribuées • CMS est considéré comme le langage standard pour la spécification d’une interface de communication entre éléments CAN • Définit les services de communication entre les différentes entités CAL • Définit les règles de codage (encoding rules) • Offre des services de communication basés sur des objets CMS Les objets CMS • Les CMS variables permettent de lire et écrire des données via le réseau • Les CMS Events permettent de signaler des évènements se produisant dans d’autres noeuds • Les CMS Domains permettent le transfert de blocs de données de plus de 8 octets de longueur (fragmentation) 31

CAL Les objets CMS Les CMS variables • Les CMS Basic variables : Message CAN habituel (8 octets maxi) • Les CMS Multiplexed variables : réduit le nombre nécessaires d’identifieurs en définissant un jeu (set) assigné à un seul identifieur (codé dans le premier octet de données) - soit 7 octets de données utiles. Les CMS Domains • Permet le tranfert de données dont la longueur est supérieure à 8 octets • Technique de fragmentation (packaging) et transmission temporelle séquentielle des données sur le réseau. Les CMS Events (événements) • Représentes données d’événements spontanés ou asynchrones • Transportent des données identifiant la cause de l’événement 32

CAL Le jeu d’attributs des objets CMS • Name - Nom identifiant l’objet (voir Application Layer Naming Convention) • User Type - Client (consommé par un noeud) ou Serveur (fourni par un noeud) • Prority - 8 classes de priorités (codage de l’identifieur) • Inhibit Time - Temps d’inhibition permettant de contrôler la charge de communication du réseau CAN (temps minimal entre 2 transferts consécutifs d’un même message) • Data Type - classes conventionneles de données (entier, booléen, flottant. . . ) • Error type - définit l’action qui doit être prise par CAL sur certains types d’erreurs • Access type - droit d’accès à l’objet CMA du point de vue du client 33

NMT Network Managemen. T assure la gestion du réseau en dehors de l’application courante. . . administration du réseau, initialisation, présence des noeuds, guarding. . . • Relation Maître / Esclave - Il y a 1 maître NMT et jusqu’à 255 esclaves NMT • 2 identifieurs CAN sont spécifiquement réservés pour les services NMT • Les services NMT sont subdivisés en 3 groupes: – Module Control Services - Services de commande et contrôle de module – Error Control Services - Services de commande et contrôle d’erreur – Configuration Services - Services de commande et contrôle de configuration • Les Objets NMT sont de 3 types – objet réseau - jeu des modules physiques sur le réseau (255 maxi) – objet noeud déporté - module incluant un partie de la configuration réseau en commun avec le maître – objet noeud - Un objet noeud peut exister dans n’importe quel module • Les Classes de réseau CAL indiquent les possibilités du réseau (issu de la configuartion NMT) Classe de réseau Classe 0 Classe 1 Classe 2 Classe 3 Classe 4 Administration réseau - + + Erreur réseau - - + Configuration réseau - - - + + Contrôle de noeud - + + Distri. Dyn. des identif. - + + 34

DBT identifier Distri. Bu. Tor • Dans un système ouvert multi-constructeur, il doit être nécessaire de pouvoir réaffecter les identifieurs pour éviter tout conflit éventuel. • DBT a pour mission d’administrer les identifieurs et d’en assurer la distribution dynamique si nécessaire. • Le protocole CAN offre 2032 valeurs COB ID (CAN OBject distributor) • La valeur binaire du COB ID définit la priorité d’accès au medium. • Le processus de distribution est organisé en maître DBT et esclaves DBT • Tous les modules du réseau ne supportent pas l’allocation dynamique • 8 groupes de priorités sont définis par le DBT groupe COB ID CMS priorité des objets 0 1 - 220 CMS priorité des objets 4 881 - 1100 CMS priorité des objets 1 221 - 440 CMS priorité des objets 5 1101 - 1320 CMS priorité des objets 2 441 - 660 CMS priorité des objets 6 1321 - 1540 CMS priorité des objets 3 661 - 880 CMS priorité des objets 7 1541 - 1760 35

LMT Layer Magagemen. T • LMT est basée sur une relation Maître/Esclave avec un maître LMT optionnel. • Sert à configurer les paramètres de chaque couche CAL dans le modèle de référence de CAN, via le réseau CAN. • Permet à un module (le maître LMT) de commander le réglage de certains paramètres des couches à d’autres modules (esclaves LMT) via le réseau CAN. • L’application a un accès direct à toutes les couches CAL • Sur le principe, ceci est en contradiction avec l’idée de conception structurées en couches selon le modèle ISO/OSI. LME Layer Magagement Entity • LME permet à une application de commander les réglages des paramètres de la couche. 36

DBT Affectation globale des COB ID NMT service de Start/Stop 0 CMS priorités des objets 0 à 7 1 - 1760 NMT protocole Node Guarding 1761 -2015 Réservé par le Ci. A 2016 -2019 Services LMT 2020 -2021 NMT Identité des noeuds 2022 Services DBT 2023 -2024 Services NMT 2025 -2026 Réservé par l’autotest module 2027 Réservé par le Ci. A 2028 -2031 CMS CAN Based Message Specification NMT Network Managemen. T DBT identifier Distri. Bu. Tor LMT Layer Managemen. T De nombreuse sociétés proposent des packages logiciels d’aide à la conception d’applications utilisant CAL (langage C) Compter environ 4 à 30 Ko de ROM pour l’intégration du code binaire CAL. 37

CAL CAN Application Layer PRESENTATION de la COUCHE PHYSIQUE 38

CAL Couche physique CAL et CANopen* (* voir présentation de CANopen) • La couche physique repose entièrement sur les spécifications CAN ISO 11898 (paire torsadée, niveaux électriques. . . ) • Les connecteurs sont définis par la recommandation Ci. A / DS 102 (connecteurs sub-D 9 broches et cylindrique mini 5 broches) • Le débit va au delà de la norme CAN High Speed (ISO 11898), de 0 à 1 Mb/s débit longueur Nominal bit time 1 Mb/s 25 m 1 us 8 125 ns 6 tq (125 ns) 500 Kb/s 100 m 2 us 16 125 ns 14 tq (1. 75 us) 125 Kb/s 500 m 8 us 16 500 ns 14 tq (7 us) 10 Kb/s 5 Km 100 us 16 6. 25 us 14 tq (87. 5 us) Nbre time quanta long. time quanta position sample point 39

SDS Smart Distributed System PRESENTATION de la COUCHE APPLICATIVE 40

SDS Smart Distributed System Protocole proposé par la société HONEYWELL Parc Technologique de Saint Aubin Bâtiment Mercury BP 87 91193 Gif sur Yvette France Tel 01 6019 8182 Fax 01 6019 8173 honeywell. sensing. com Spécifications SDS : GS 052 -103 à 108 (1994. . ) http: //www. honeywell/sensing/prodinfo/sds 41

SDS Smart Distributed System • débit de 125 Kb/s à 1 Mb/s • longueur: 1. 2 Km à 125 Kb/s, 30 m à 1 Mb/s • 64 stations maxi sur le réseau (126 avec répéteur) • 4032 point maxi, analogiques ou digitaux • Modes de communication: – Evènementiel – Requête / réponse – Cyclique 42

SDS Les couches ISO Couche 7 Couche Application ISO Couche 2 Couche liaison de données Signal Physique Couche Application SDS (APL) Protocole CAN ISO Couche 1 Transmetteur/Récepteur Médium Support de transmission Couche physique SDS 43

SDS APL La couche applicative APL Application Protocol Layer • 4 classes génériques de services disponibles par l’utilisateur – READ, WRITE, EVENT, ACTION • 2 à 126 éléments physiques sur un réseau • 126 adresses logiques maxi par élément physique • 32 éléments/objets indépendants par adresse logique • 255 attibuts, 255 actions, 255 events maxi par élément/objet 44

SDS les Services de l’APL • Services READ & WRITE – permet de lire les entrées et écrire les sorties – permet l’accès à toutes les données visibles n’excédant pas 6 octets – supporte la gestion en Maître/esclave • Service EVENT – Permet la gestion d’évènements asynchrones ou spontanés générés par une station ou un élément • Service ACTION – Permet de lancer des ordres de commandes – Principalement utilisé pour l’administration du réseau 45

SDS composant physique adresse logique Objet attributs actions events Liaison CAN les objets de l’APL Composant Physique contient. . . 126 adresses logiques maxi qui contiennent. . . 32 éléments objets maxi qui contiennent. . . 255 attributs 255 actions 255 events maxi, en 3 tableaux Bus CAN 46

SDS les paramètres des objets Le tableau Attributs contient les informations générales telles que: vitesse de communication, adresse logique de la station (1à 126), Numéro de série, référence du produit. . . Le tableau Actions indique les actions possibles sur le dispositif: changer l’adresse logique de la station, effacer / corriger les erreurs. . . Le tableau Events indique les évènements qui peuvent se produire sur ce dispositif: Changement d’état d’un capteur, dépassement de limite. . . 47

SDS Codage des Services Les services sont codés par la valeur du champ APDU Application Protocol Data Unit • • Read: Write Event Report Action COS ON COS OFF Write ON state Write OFF state Lecture d’un attribut Modification d’un attribut Report d’un événement Commande l’exécution d’une action Report sur changement d’état ON Report sur changement d’état OFF Ecriture d’un ON sur un I/O Ecriture d’un OFF sur un I/O COS = Change Of State 48

SDS les messages Types de messageries utilisables avec SDS : gérées par l’APDU Application Protocol Data Unit Diffusion générale (broadcast) permettant la diffusion simultanée de messages à l’ensemble des stations. Point à Point direct (DPP Direct Peer to Peer) met en relation temporaire deux stations identifiées. Les types de messages SDS: Messages courts: Messages longs: Messages fragmentés: messages d’information rapide messages de données (6 octets) message longs (256 octets maximum) 49

SDS APDU et trame CAN • L’objet CAN du SDS (APDU) s’appuie sur la trame CAN standard 2. 0 A • Il se compose de deux parties: le CAN Header et le Champ de données • Le CAN Header (entête) utilise les champs suivants de la trame CAN 2. 0 A: – Les 11 bits de l’identifieur – Le bit RTR – Les 4 bits DLC – Les 2 ou 3 premiers octets des données (messages longs et fragmentatés, point à point) • Le Champ de données utilise les octets de données de la trame CAN 2. 0 A: – 0 octets (vide) pour le message court – 6 octets pour le message long – 4 octets pour le message fragmenté – 5 octets en messagerie point à point 50

SDS APDU et identifieur CAN Identifieur trame CAN 2. 0 A (11 bits) DIR Adresse de l’élément type d’APDU 1 7 3 0, 1 0. . 125 0. . 7 Nom du champ Nbre de bits par champ Gamme de valeur 0=Adresse de destination, 1=Adresse de la source 51

SDS Message de forme courte La trame SDS courte est composée de 44 bits (hors bit de bourrage) En-Tête SDS Fin SDS En-Tête CAN Fin CAN SOF DIR Adress APDU 1 1 7 1 0. . 125 CRC ACK EOF Nom de champ 4 16 2 7 Nbre bits par champ 0 - - - Gamme de valeurs RTR DLC 3 3 0. . 7 0 Etats de l’APDU 000 COS to OFF 011 COS to ON Ack 110 Write OFF Ack 001 COS to ON 010 COS to OFFAck 100 Write OFF 101 Write ON 111 Write ON Ack (COS=Change Of State) 52

SDS Message de forme longue HEADER RTR APDU -> 0 DLC -> >0 -> 000. . . 011 Reserved 100 Write 101 Read 110 Action 111 Event DONNEES 2 bits 1 bit RRED fragment=0 00 Request 01 Succesful Response 10 Error Response (11 Direct Peer to Peer) 5 bits Object / Group ID (0. . 31) Data 0 CAN 00000 Object Group ID 0. . 11111 Object Group ID 32 8 bits PDU Modifier (Attribute, Action, Event - 0. . 255) Data 1 CAN Données SDS sur 6 octets Data 3 à 8 CAN 53

SDS Message de forme longue HEADER RTR APDU -> 0 DLC -> >0 -> 000. . . 011 Reserved 100 Write 101 Read 110 Action 111 Event DONNEES 2 bits 1 bit 5 bits RRED fragment=1 Object / Group ID (0. . 31) Data 0 CAN PDU Modifier (Attribute, Action, Event - 0. . 255) Data 1 CAN Fragment Number (0. . 63) Data 2 CAN Total Fragment bytes (0. . 255) Data 3 CAN Données SDS sur 4 octets Data 4 à 8 CAN 54

SDS Message longs fragmentés Laps de temps de 10 ms entre deux transmissions de fragments HEADER RTR APDU -> 0 DLC -> >0 -> 000. . . 011 Reserved 100 Write 101 Read 110 Action 111 Event DONNEES 2 bits 1 bit 5 bits RRED fragment=1 Object / Group ID (0. . 31) Data 0 CAN PDU Modifier (Attribute, Action, Event - 0. . 255) Data 1 CAN Fragment Number (0. . 63) Data 2 CAN Total Fragment bytes (0. . 255) Data 3 CAN Données SDS sur 4 octets Data 4 à 8 CAN 55

SDS Message Direct Point à Point Laps de temps de 10 ms entre deux transmissions de fragments HEADER RTR APDU -> 0 DLC -> >0 -> 000. . . 011 Reserved 100 Write 101 Read 110 Action 111 Event DONNEES 2 bits 1 bit 5 bits DPP =11 fragment=0 Object / Group ID (0. . 31) PDU Modifier (Attribute, Action, Event - 0. . 255) Variable ID Data 0 CAN Data 1 CAN Data 2 CAN (0. . 63) Données SDS sur 4 octets Data Destination Adress (0. . 255) Data 3 à 7 CAN Data 8 CAN 56

SDS Administration du réseau SDS Phase de détection de débit A la première mise sous tension, la station entre en «détection de débit du bus» La séquence d’AUTOBAUD est fournie par le seul «administrateur de Bus» Phase de mapping réseau Après l’autobaud, phase d’établissement de la cartographie des éléments dont les adresses appartiennent à leurs domaines spécifiés. Les Duplications d’adresses sont détectées, et des réaffectations d’adresses possibles. . . Phase de fonctionnement normal En plus de l’activité normale entre stations, les interfaces des contrôleurs possèdent des fonctions Chiens de Garde qui permettent de détecter des éléments défectueux ou inactifs, en les scrutant périodiquement. Il est possible d’insérer ou de retirer une station à tout moment sans perturber le réseau 57

SDS Les Device Models • La couche SDS est conçue pour être utilisée avec une méthodologie orientée objets. • Les notions de hiérarchisations et d’héritages sont applicables aux stations. 2. 0 0 SDS caractér. minimum fonctions IEC 1131 1. 0 objets communs E/S 1. 1 sortie binaire simple 1. 2 2. 2 hiérarchie des objets 2. 3 Entrées analogiq. simples 1. 3 2. 4 58

SDS Implémentation Exemples d’ordres de tailles de code pour microcontrôleur standard • Capteur Photoélectrique: 1, 7 Kb Entrées/Sorties - Fonctionnalités Event et Diagnostic incluses • Elément multivalves: 8 K - Elément à entrées/sorties multiples (64 I/O) • Démarreur de moteur: 8 K • Interface Maître: 16 K - Interface de commande avec toutes les fonctionnalités 59

SDS Smart Distributed System PRESENTATION de la COUCHE PHYSIQUE 60

SDS Smart Distributed System Branche ou bretelle Tronc «T» Résistance de terminaison débit L Tronc maxi L branche max Nb Opérations/s noeuds max 1 Mb/s 22, 8 m 0, 30 m 800 32 500 Kb/s 91. 4 m 0, 90 m 500 64 250 Kb/s 182, 8 m 1, 80 m 300 64 125 Kb/s 457, 2 3, 60 m 200 64 61

SDS Smart Distributed System 2 paires torsadées différentielles (signal CAN + alimentation) + Shield • Marron • Bleu • Noir • Blanc V+ Gnd CAN H CAN L Vérification de conformité effectué par UL (Under. Writers Labs. - USA) suivant spécification Honeywell GS 052 108 disponible sur Internet: http: //www. sensing. honeywell. com/sdspec. html) NORMALISATION Comité des Standards CLC 17 B du CENELEC (European Commitee for Electrotechnical Standardization) 62

Fin de présentation Merci de votre attention Patrick MONASSIER Université Lyon 1 France 63