1
Device Net
Présentation
CAN Open - CALSDS
Les couches applicatives de CANController Area Network
Patrick MONASSIERUniversité Lyon 1 France
2
Device Net
Présentation
3
DeviceNet - 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 DeviceNet Vendor Association) qui est une association d’offreur de services autour de DeviceNet - Le but de l’ODVA est de promouvoir DeviceNet.• 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, FL33067 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
4
DeviceNet et les couches ISO
Couche Application
Couche liaison de données
Signal Physique
Transmetteur/Récepteur
Support de transmission
Couche ApplicationDeviceNet
ProtocoleCAN
Couche physiqueDeviceNet
ISO Couche 7
ISO Couche 2
ISO Couche 1
Médium
5
DeviceNet - 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 DeviceNet
6
Couche Communication de données
• DeviceNet s’appuie sur la trame CAN 2.0A (identifieur 11 bits)• Le protocole DeviceNet 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
7
Connexions et messages
• La communication DeviceNet 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...)
8
I/O connections & I/O messages
I/O messages I/O Connection I/O Connection I /O messages
Station émettrice Station réceptrice
I/O data I/O message I /O data
Application Connection Connection Application
Les IO data sont inclues dans le champs des données de la trame CAN (8 octets maxi). DeviceNet 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é).
9
Explicit Messaging Connections
Station 1 Station 2Explicit messages
Connection Connection
Les connection Explicites sont à usage multiple. Les messages qui sont construits dans la trame CAN, sont constitués d’un Connection IDet d’une information de protocole message. DeviceNet 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).
Question Question
Réponse Réponse
10
Identifieur CAN selon DeviceNet
10 9 8 7 6 5 4 3 2 1 0 Valeur Hex
0 Groupe 1 Source MAC ID 000-3FF Message groupe 1 Message ID
1 0 MAC ID Groupe 2 400-5FF Message groupe 2 Message ID
1 1 Groupe 3 Source MacID 600-7BF Message groupe 3 Message ID
1 1 1 1 1 Groupe 4 7C0-7EF Message groupe 4 Message ID
1 1 1 1 1 1 1 1 1 1 1 7F0-7FF ID non valides
11
Groupe de priorité
La construction des identifieurs selon DeviceNet permet de définir3 groupes distinct, fonction des bits de poids fort:
Bit 10 Bit 9 Groupe Priorité Application 0 x groupe 1 haute Entrées/sorties 1 0 groupe 2 moyenne Maître/Esclave 1 1 groupe 3 basse messages groupe 4 très faible non définie
12
Définitions
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
• 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.
13
Etablissement d’une connexion
• Le but de la couche applicative DeviceNet est de fournir, pour des applications particulières, des informations pertinentes d’Entrées/Sorties en temps réel.
• DeviceNet 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.
• DeviceNet pédéfinit un jeu de connexions Maître/Esclaves: le predefined Master/Slave Connection Set .
14
Modes d’adressage de DeviceNet
MAC ID #1 MAC ID #2
MAC ID #3 MAC ID #4
object classe #5
object classe #5
instance #1
instance #1
instance #2
instance #1
Attribute #1Attribute #2
object classe #7
réseau
MAC ID #4: Object classe #5Instance #2: Attribute #1
15
CAN Open
PRESENTATION dela COUCHE APPLICATIVE
16
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 CiA, 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.
17
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.
18
CANopen modèle ISO
Communication Profile
CAL (Can Application Layer)
CAN Protocol (Data Link Layer)
Physical Layer
Deviceprofile A
Deviceprofile B
Deviceprofile C
CANopen
CAL
CANISO 11898
ISOCouche 7
ISOCouche 2
ISOCouche 1
Bus CAN
Standard Device«futur proof»
ISOCouche 8
ISOCouche 7
CAL
CANopenCommunication Profile CiA DS 301
CANopen Device ProfileCiA DS 401 à 406
19
CANopen spécifications
Communication profile for Industrial SystemCiA DS 301 3.0 1996
Framework for Programmable devicesCiA DS 302 1.0 1997
Devices profiles– For I/O modules CiA DS 401 1.4 1996
– For drives and motion control CiA DS 402 1.01997
– For Human machine interface CiA DS 403
– For measure & close-loop devices CiA DS 404 1.0 1997
– For Encoders CiA DS 406 1.0 1997
20
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 CanOpen– SYNC objects
– Time Stamp Objects
– Emergency Objects
21
CANopen Service Data Object SDO
Start of domain 3 bytes profile 4 bytes profile end oftelegram command identification data telegramframe specification frame
Start of domain 7 bytes profile end oftelegram command data telegramframe specification frame
byte 0 bytes 1-3 bytes 4-7
byte 0 bytes 1-7
16 bits 8 bits
index sub-index
data type data type unsigned 16 unsigned 8
INITIATECOMMAND
SEGMENTCOMMAND
22
CANopen transmission synchrone et asynchrone
Object SYNC Object SYNC
fenêtre des objects SYNC
PDO synchronesPDO asynchrones
Message SYNC Message SYNC
Période du cycle de communication
Longueur de la fenêtre de synchronisation
Messages actuels Messages de commande
23
CAL CAN Application Layer
PRESENTATION de
la COUCHE APPLICATIVE
24
CAL CAN Application Layer
Contact: CiA CAN in AutomationAm Weichselgarten 26D-91508 ErlangenTel +49 9131 601091Fax +49 9131 601092
http://www.can-cia.org
• Définition des spécifications d’une couche applicative système ouvert, basée sur le protocole CAN.• En 1992, par le CiA (CAN In Automation), naissance des CAL (CAN Application layers).• Pas de droit de licence, ni de royalties.• Fonction détaillées dans documents CiA / DS 201 à 205
25
CAL Les couches ISO
Couche Application
Couche liaison de données
Signal Physique
Transmetteur/Récepteur
Support de transmission
Couche ApplicationCAL
Protocole CAN
Couche physiqueCAL
ISO Couche 7
ISO Couche 2
ISO Couche 1
Médium
26
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 DistriBuTor• LMT Layer ManagemenT
27
CAL Présentation CMS
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émentsdite «orientée communication»
CMSSpécificationdes messagesbasés sur CAN
Variables
Evènements
Domaines
Régles de codage
NMT
DBT
LMT
Administration du réseau
Distributeur desidentifications
Administartiondes couches
Maitre
Esclave
Maitre
Maitre
Esclave
Esclave
28
CAL Présentations DBT, NMT, LMT
• DBT (identifier DistriBuTor) est responsable de l’affectation
dynamique de la valeur des identifieurs.
• NMT (Network ManagemenT) 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 ManagemenT) 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.
29
CAL Primitives et types de services
Voir les figures page suivante
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
30
CAL Primitives et types de services
Application X Application X
Application X Application YApplication X Application Y
indication
indication
indicationrequête
requête
confirmation réponse
Service initialisé par un fournisseur
Service confirmé
Service local
Service non confirmé
31
CMS langage de modélisation pour applications distribuées
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)
• 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
32
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 des données d’événements spontanés ou asynchrones
• Transportent des données identifiant la cause de l’événement
33
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
34
NMT Network ManagemenT
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. - + + + +
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)
35
DBT identifier DistriBuTor
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
groupe COB ID groupe COB ID
• 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
36
LMT Layer MagagemenT
LME Layer Magagement Entity• LME permet à une application de commander les réglages des paramètres de la couche.
• 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.
37
DBT Affectation globale des COB ID
NMT service de Start/Stop 0
Réservé par le CiA 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 CiA 2028-2031
CMS priorités des objets 0 à 7 1 - 1760
NMT protocole Node Guarding 1761-2015
CMSCAN Based Message Specification
NMTNetwork ManagemenT
DBTidentifier DistriBuTor
LMTLayer ManagemenT
De nombreuse sociétés proposent des packageslogiciels d’aide à la conception d’applicationsutilisant CAL (langage C)
Compter environ 4 à 30 Ko de ROM pour l’intégration du code binaire CAL.
38
CAL CAN Application Layer
PRESENTATION de
la COUCHE PHYSIQUE
39
CAL Couche physique CAL et CANopen*(* voir présentation de CANopen)
débit longueur Nominal bit time Nbre time quanta long. time quanta position sample point
1Mb/s 25m 1us 8 125ns 6tq (125ns)
500Kb/s 100m 2us 16 125ns 14tq (1.75us)
125Kb/s 500m 8us 16 500ns 14tq (7us)
10Kb/s 5 Km 100us 16 6.25us 14tq (87.5us)
• 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 CiA / DS102 (connecteurs sub-D 9 broches et cylindrique mini 5 broches)• Le débit va au delà de la norme CAN High Speed (ISO11898), de 0 à 1Mb/s
40
SDS Smart Distributed
System
PRESENTATION dela COUCHE APPLICATIVE
41
SDS Smart Distributed System
Protocole proposé par la société HONEYWELL
Parc Technologique de Saint Aubin Bâtiment Mercury BP87 91193 Gif sur Yvette France Tel 01 6019 8182 Fax 01 6019 8173 honeywell.sensing.com
Spécifications SDS : GS052-103 à 108 (1994..)
http://www.honeywell/sensing/prodinfo/sds
42
SDS Smart Distributed System
• débit de 125Kb/s à 1 Mb/s
• longueur: 1.2Km à 125Kb/s, 30m à 1Mb/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
43
SDS Les couches ISO
Couche Application
Couche liaison de données
Signal Physique
Transmetteur/Récepteur
Support de transmission
Couche ApplicationSDS (APL)
Protocole CAN
Couche physiqueSDS
ISO Couche 7
ISO Couche 2
ISO Couche 1
Médium
44
SDS La couche applicative APL
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
45
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 par une station ou un élément
• Service ACTION – Permet de lancer des ordres de commandes– Principalement utilisé pour l’administration du réseau
46
SDS les objets de l’APL
Liaison CANBus CAN
Composant Physique contient...
126 adresses logiques maxi qui contiennent...
32 éléments objets maxi qui contiennent...
255 attributs255 actions255 events maxi, en 3 tableaux
attributs
actions
events
Objet
adresse logique
composant physique
47
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:
Le tableau Events indique les évènements qui peuvent se produiresur ce dispositif:
changer l’adresse logique de la station, effacer / corriger les erreurs...
Changement d’état d’un capteur, dépassement de limite.....
48
SDS Codage des Services
Les services sont codés par la valeur du champ APDU Application Protocol Data Unit
COS = Change Of State
• Read: Lecture d’un attribut
• Write Modification d’un attribut
• Event Report Report d’un événement
• Action Commande l’exécution d’une action
• COS ON Report sur changement d’état ON
• COS OFF Report sur changement d’état OFF
• Write ON state Ecriture d’un ON sur un I/O
• Write OFF state Ecriture d’un OFF sur un I/O
49
SDS les messages
Types de messageries utilisables avec SDS :
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.
gérées par l’APDU Application Protocol Data Unit
Les types de messages SDS:
Messages courts: messages d’information rapide
Messages longs: messages de données (6 octets)
Messages fragmentés: message longs (256 octets maximum)
50
SDS APDU et trame CAN
• L’objet CAN du SDS (APDU) s’appuie sur la trame CAN standard 2.0A
• 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.0A:
– 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.0A:
– 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
51
SDS APDU et identifieur CAN
Identifieur trame CAN 2.0A (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
52
SDS Message de forme courte
En-Tête SDS Fin SDS
En-Tête CAN Fin CAN
SOF DIR Adress APDU RTR DLC CRC ACK EOF
1 1 7 3 3 4 16 2 7
1 0..1 0..125 0..7 0 0 - - -
La trame SDS courte est composée de 44 bits (hors bit de bourrage)
Nom de champ
Nbre bits par champ
Gamme de valeurs
000 COS to OFF 001 COS to ON 010 COS to OFFAck 011 COS to ON Ack 100 Write OFF 101 Write ON110 Write OFF Ack 111 Write ON Ack (COS=Change Of State)
Etats de l’APDU
53
SDS Message de forme longue
RTR -> 0 DLC -> >0APDU -> 000...011 Reserved 100 Write 101 Read 110 Action 111 Event
HEADER
DONNEES
RRED fragment=0 Object / Group ID (0..31) Data 0 CAN
00 Request01 Succesful Response10 Error Response(11 Direct Peer to Peer)
2 bits 1 bit 5 bits
00000 Object Group ID 0....11111 Object Group ID 32
PDU Modifier (Attribute, Action, Event - 0..255) Data 1 CAN
8 bits
Données SDS sur 6 octetsData 3 à 8 CANData Data
54
SDS Message de forme longue
HEADER
DONNEES
RRED fragment=1 Object / Group ID (0..31) Data 0 CAN
2 bits 1 bit 5 bits
PDU Modifier (Attribute, Action, Event - 0..255) Data 1 CAN
Data 4 à 8 CAN
RTR -> 0 DLC -> >0APDU -> 000...011 Reserved 100 Write 101 Read 110 Action 111 Event
Fragment Number (0..63) Data 2 CAN
Total Fragment bytes (0..255) Data 3 CAN
Données SDS sur 4 octets
Data Data
55
SDS Message longs fragmentés
HEADER
DONNEES
RRED fragment=1 Object / Group ID (0..31) Data 0 CAN
2 bits 1 bit 5 bits
PDU Modifier (Attribute, Action, Event - 0..255) Data 1 CAN
Data 4 à 8 CAN
RTR -> 0 DLC -> >0APDU -> 000...011 Reserved 100 Write 101 Read 110 Action 111 Event
Fragment Number (0..63) Data 2 CAN
Total Fragment bytes (0..255) Data 3 CAN
Données SDS sur 4 octets
Data Data
Laps de temps de 10ms entre deux transmissions de fragments
56
SDS Message Direct Point à Point
HEADER
DONNEES
DPP =11 fragment=0 Object / Group ID (0..31) Data 0 CAN
2 bits 1 bit 5 bits
PDU Modifier (Attribute, Action, Event - 0..255) Data 1 CAN
Data 3 à 7 CAN
RTR -> 0 DLC -> >0APDU -> 000...011 Reserved 100 Write 101 Read 110 Action 111 Event
Variable ID (0..63) Data 2 CAN
Destination Adress (0..255) Data 8 CAN
Données SDS sur 4 octets
Laps de temps de 10ms entre deux transmissions de fragments
Data Data
57
SDS Administration du réseau SDS
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 détection de débit
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
58
SDS Les Device Models
0
2.0
1.0
1.1
1.2
2.2
2.3
1.3 2.4
SDScaractér.minimum
fonctionsIEC1131
objetscommunsE/S
sortiebinairesimple
Entréesanalogiq.simples
hiérarchie desobjets
• 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.
59
SDS Implémentation
Exemples d’ordres de tailles de code pour microcontrôleur standard
• Capteur Photoélectrique: 1,7Kb Entrées/Sorties - Fonctionnalités Event et Diagnostic incluses
• Elément multivalves: 8K - Elément à entrées/sorties multiples (64 I/O)
• Démarreur de moteur: 8K
• Interface Maître: 16K - Interface de commande avec toutes les fonctionnalités
60
SDS Smart Distributed System
PRESENTATION de
la COUCHE PHYSIQUE
61
SDS Smart Distributed System
Branche oubretelle
Tronc
«T»
débit L Tronc maxi L branche max Nb Opérations/s noeuds max
1Mb/s 22,8 m 0,30 m 800 32
500Kb/s 91.4 m 0,90 m 500 64
250Kb/s 182,8 m 1,80 m 300 64
125Kb/s 457,2 3,60 m 200 64
Résistance determinaison
62
SDS Smart Distributed System
2 paires torsadées différentielles (signal CAN + alimentation) + Shield
• Marron V+• Bleu Gnd• Noir CAN H• Blanc CAN L
Vérification de conformité effectué par UL (UnderWriters Labs.- USA)suivant spécification Honeywell GS 052 108 disponible sur Internet:http://www.sensing.honeywell.com/sds/sdspec.html)
NORMALISATION
Comité des Standards CLC17B du CENELEC(European Commitee for Electrotechnical Standardization)
63
Fin de présentation
Merci de votre attention
Patrick MONASSIERUniversité Lyon 1 France