Device Net

1
Device Net
Les couches applicatives de CAN
Controller Area Network
CAN Open - CAL
SDS

• Présentation

Patrick MONASSIER Université Lyon 1 France
2
Device Net

• Présentation

3
DeviceNet - Présentation

• Normalise la Couche 7 ISO partie basse de la
  couche 1 ISO
• Sappuie sur CAN ISO 11898 - Commercialisation
  fin 1994
• Appartient à lorganisme ODVA (Open DeviceNet
  Vendor Association) qui est une association
  doffreur de services autour de DeviceNet - Le
  but de lODVA 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 [phone]
  Fax [phone]
• Allen Bradley Rockwell Ave de lEurope 78941
  Velizy Cedex France Tel [phone] Fax
  01 3465 3233

http//www.odva.org
4
DeviceNet et les couches ISO
Couche Application DeviceNet
Couche Application Couche liaison de
données Signal Physique Transmetteur/Récepteur
Support de transmission
ISO Couche 7
ISO Couche 2
Protocole CAN
ISO Couche 1
Couche physique DeviceNet
Médium
5
DeviceNet - Les couches ISO

• Couche Communication de données
• Messagerie et mode de connexion
• Modes dadressages
• Echange de donnes
• Fragmentation
• Profils de communication
• Couche Physique
• Medium de transmission et topologie du réseau
• Connexion au medium
• Possibilités dalimentation par les stations
  DeviceNet

6
Couche Communication de données

• DeviceNet sappuie 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 lidentifieur 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 lun des Communication
  Objects
• Cest 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
Station émettrice
Station réceptrice
I/O data I/O message
I /O data
Application Connection
Connection Application
I/O messages I/O Connection I/O
Connection I /O messages
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 2
Explicit messages
Question
Question
Connection Connection
Réponse
Réponse
Les connection Explicites sont à usage multiple.
Les messages qui sont construits dans la trame
CAN, sont constitués dun Connection ID et dune
information de protocole message. DeviceNet ne
fournit pas dindications sur le protocole. Il
définit un protocole de fragmentation permettant
des échanges de taille supérieure à 8 octets
(trame CAN).
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éfinir 3 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

• Message ID identifie un message particulier à
  lintérieur dun 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 lidentifieur.
• Destination MAC ID désigne la station
  destinatrice du message.

• Laccè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 dautres 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

13
Etablissement dune connexion

• Le but de la couche applicative DeviceNet est
  de fournir, pour des applications particulières,
  des informations pertinentes dEntré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 dadressage de DeviceNet
MAC ID 1
MAC ID 2
MAC ID 4 Object classe 5 Instance 2
Attribute 1
réseau
instance 1
object classe 5
object classe 7
Attribute 1
Attribute 2
instance 1
instance 2
instance 1
MAC ID 3
object classe 5
MAC ID 4
15
CAN Open
PRESENTATION de la 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.
• Lobjectif 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 dentré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 dobjets,
  sans mode demploi précis.
• Lun 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 demploi 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
CANopen Device Profile CiA
DS 401 à 406
Device profile A
Device profile B
Device profile C
Standard Device futur proof
ISO Couche 8
CANopen
CANopen Communication Profile CiA 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
19
CANopen spécifications

• Communication profile for Industrial System
• CiA DS 301 3.0 1996
• Framework for Programmable devices
• CiA 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.0 1997
• 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 nayant pas daspect 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
byte 0 bytes 1-3 bytes
4-7
Start of domain 3 bytes
profile 4 bytes profile end
of telegram command identification
data telegram frame
specification
frame
INITIATE COMMAND
16 bits 8 bits index
sub-index data type data type unsigned
16 unsigned 8
byte 0 bytes 1-7
Start of domain
7 bytes profile end
of telegram command
data
telegram frame specification

frame
SEGMENT COMMAND
22
CANopen transmission synchrone et asynchrone
Object SYNC Object
SYNC
fenêtre des objects SYNC
PDO synchrones
PDO asynchrones
Période du cycle de communication
Longueur de la fenêtre de synchronisation
Message SYNC Message SYNC
Messages actuels
Messages de commande
23
CAL CAN Application Layer

• PRESENTATION de
• la COUCHE APPLICATIVE

24
CAL CAN Application Layer

• Définition des spécifications dune 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

Contact CiA CAN in Automation Am Weichselgarten
26 D-91508 Erlangen Tel [phone] Fax
49 9131 601092 http//www.can-cia.org
25
CAL Les couches ISO
Couche Application CAL
Couche Application Couche liaison de
données Signal Physique Transmetteur/Récepteur
Support de transmission
ISO Couche 7
ISO Couche 2
Protocole CAN
ISO Couche 1
Couche physique CAL
Médium
26
CAL Présentation

• CAL fournit aux utilisateurs
• ladministration du réseau et des couches
• les fonctionnalités de maître et superviseur
  dun 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 dinterfacer le réseau
physique CAN (règles de codage). CMS décrit
aussi la description dobjets 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
NMT
Maitre
CMS Spécification des messages basés sur CAN
Variables
Administration du réseau
Esclave
Evènements
DBT
Maitre
Distributeur des identifications
Domaines
Esclave
LMT
Régles de codage
Maitre
Administartion des couches
Esclave
28
CAL Présentations DBT, NMT, LMT

• DBT (identifier DistriBuTor) est responsable de
  laffectation dynamique de la valeur des
  identifieurs.
• NMT (Network ManagemenT) est responsable de
  ladministration du réseau
• spécifie les services généraux et
  dadministration du réseau
• réalise linitialisation 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 didentificateurs individuels et des
  noeuds
• paramètres temporels CAN (Nominal Bit time...)
  ...etc.

29
CAL Primitives et types de services

• 4 types de services
• services locaux
• services initialisés par le fournisseur
• services non confirmés
• services confirmés

• 4 services de primitives
• requête demande de lapplication à la
  couche applicative
• indication fournie par la couche
  applicative pour rapporter un événement interne
• réponse fournie par lapplication vers la
  couche applicative pour répondre à une indication
  reçue
• confirmation fournie par la couche
  applicative à lapplication pour rapporter le
  résultat dune requête précédente.

Voir les figures page suivante
30
CAL Primitives et types de services
Application X
Application X
indication
requête
Service initialisé par un fournisseur
Service local
Application X Application Y
Application X Application Y
indication
requête
indication
confirmation
réponse
Service confirmé
Service non confirmé
31
CMS langage de modélisation pour applications
distribuées

• CMS est considéré comme le langage standard pour
  la spécification dune 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 dautres
  noeuds
• Les CMS Domains permettent le transfert de
  blocs de données de plus de 8 octets de longueur
  (fragmentation)

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 didentifieurs 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 dattributs des objets CMS

• Name - Nom identifiant lobjet (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
  lidentifieur)
• Inhibit Time - Temps dinhibition permettant de
  contrôler la charge de communication du réseau
  CAN (temps minimal entre 2 transferts consécutifs
  dun même message)
• Data Type - classes conventionneles de données
  (entier, booléen, flottant...)
• Error type - définit laction qui doit être
  prise par CAL sur certains types derreurs
• Access type - droit daccès à lobjet CMA du
  point de vue du client

34
NMT Network ManagemenT

• assure la gestion du réseau en dehors de
  lapplication 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 derreur
• 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
  nimporte 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. -


35
DBT identifier DistriBuTor

• 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 dadministrer les
  identifieurs et den 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é
  daccè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
  lallocation dynamique
• 8 groupes de priorités sont définis par le DBT

groupe COB ID
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
36
LMT Layer MagagemenT

• 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 à
  dautres modules (esclaves LMT) via le réseau
  CAN.
• Lapplication a un accès direct à toutes les
  couches CAL
• Sur le principe, ceci est en contradiction avec
  lidé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.

37
DBT Affectation globale des COB ID
CMS CAN Based Message Specification NMT Network
ManagemenT DBT identifier DistriBuTor LMT Layer
ManagemenT
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 CiA 2016-2019
Services LMT
2020-2021
NMT Identité des noeuds 2022
Services DBT
2023-2024
De nombreuse sociétés proposent des
packages logiciels daide à la conception
dapplications utilisant CAL (langage C) Compter
environ 4 à 30 Ko de ROM pour lintégration du
code binaire CAL.
Services NMT 2025-2026
Réservé par lautotest module 2027
Réservé par le CiA 2028-2031
38
CAL CAN Application Layer

• PRESENTATION de
• la COUCHE PHYSIQUE

39
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 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

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)
40
SDS Smart Distributed System

• PRESENTATION de
• la 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 [phone] Fax [phone]
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 SDS (APL)
Couche Application Couche liaison de
données Signal Physique Transmetteur/Récepteur
Support de transmission
ISO Couche 7
ISO Couche 2
Protocole CAN
ISO Couche 1
Couche physique SDS
Médium
44
SDS La couche applicative APL
APL Application Protocol Layer

• 4 classes génériques de services disponibles par
  lutilisateur
• 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 lAPL

• Services READ WRITE
• permet de lire les entrées et écrire les sorties
• permet laccès à toutes les données visibles
  nexcé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 ladministration du
  réseau

46
SDS les objets de lAPL
Composant Physique contient...
composant physique
126 adresses logiques maxi qui contiennent...
adresse logique
32 éléments objets maxi qui contiennent...
Objet
attributs
255 attributs 255 actions 255 events maxi, en 3
tableaux
actions
events
Liaison CAN
Bus CAN
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
changer ladresse 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 dun 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

• Read Lecture dun attribut
• Write Modification dun attribut
• Event Report Report dun événement
• Action Commande lexécution dune action
• COS ON Report sur changement détat ON
• COS OFF Report sur changement détat OFF
• Write ON state Ecriture dun ON sur un I/O
• Write OFF state Ecriture dun OFF sur un I/O

COS Change Of State
49
SDS les messages
Types de messageries utilisables avec SDS
gérées par lAPDU Application Protocol Data
Unit
Diffusion générale (broadcast) permettant la
diffusion simultanée de messages à lensemble
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 dinformation
rapide Messages longs messages de données (6
octets) Messages fragmentés message longs (256
octets maximum)
50
SDS APDU et trame CAN

• Lobjet CAN du SDS (APDU) sappuie 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 lidentifieur
• 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 dAPDU
Nom du champ
1 7
3
Nbre de bits par champ
0,1 0 .. 125
0..7
Gamme de valeur
0Adresse de destination, 1Adresse de la
source
52
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
Nom de champ
SOF DIR Adress APDU RTR DLC
CRC ACK EOF
1 1 7 3
3 4 16 2 7
Nbre bits par champ
1 0..1 0..125 0..7 0
0 - - -
Gamme de valeurs
Etats de lAPDU
000 COS to OFF 001 COS to ON 010
COS to OFFAck 011 COS to ON Ack 100 Write
OFF 101 Write ON 110 Write OFF Ack
111 Write ON Ack (COSChange Of State)
53
SDS Message de forme longue
HEADER
RTR -gt 0 DLC -gt gt0 APDU -gt 000...011
Reserved 100 Write 101 Read 110
Action 111 Event
DONNEES
2 bits 1 bit 5 bits
Data 0 CAN
RRED fragment0
Object / Group ID (0..31)
00 Request 01 Succesful Response 10 Error
Response (11 Direct Peer to Peer)
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
Data
Data
54
SDS Message de forme longue
HEADER
RTR -gt 0 DLC -gt gt0 APDU -gt 000...011
Reserved 100 Write 101 Read 110
Action 111 Event
DONNEES
2 bits 1 bit 5 bits
RRED fragment1
Object / Group ID (0..31)
Data 0 CAN
Data 1 CAN
PDU Modifier (Attribute,
Action, Event - 0..255)
Data 2 CAN

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

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

Variable ID (0..63)
Données SDS sur 4 octets
Data
Data
Data 3 à 7 CAN
Destination
Adress (0..255)
Data 8 CAN
57
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
dAUTOBAUD est fournie par le seul
administrateur de Bus
Phase de mapping réseau
Après lautobaud, phase détablissement de la
cartographie des éléments dont les adresses
appartiennent à leurs domaines spécifiés. Les
Duplications dadresses sont détectées, et des
réaffectations dadresses possibles...
Phase de fonctionnement normal
En plus de lactivité 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 dinsérer ou de retirer une
station à tout moment sans perturber le réseau
58
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 dhéritages
  sont applicables aux stations.

2.0
1.1
2.2
fonctions IEC1131
sortie binaire simple
hiérarchie des objets
0
SDS caractér. minimum
1.0
1.2
2.3
objets communs E/S
Entrées analogiq. simples
2.4
1.3
59
SDS Implémentation
Exemples dordres 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 ou bretelle
Tronc
T
Résistance de terminaison
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
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/sds
pec.html)
NORMALISATION
Comité des Standards CLC17B du CENELEC (European
Commitee for Electrotechnical Standardization)
63
Fin de présentation
Merci de votre attention
Patrick MONASSIER Université Lyon 1 France