Eigenschaften von CANopen

Transcription

Insert picture
and click “Align Title
Graphic”.
Werkzeugeinsatz bei CANopen
Systemeigenschaften und Testbarkeit
CANopen Techdays 26./28.01.09, München/Hamburg
© 2009. Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
V 1.00
2009-01-21
Agenda
> Einführung
Konformitätstest des CiA e.V.
Was muss man hier noch tun?
© 2009. Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector. V 1.00. 2009-01-21.
Slide: 2
Einführung
Motivation
T
CANopen wird heute in vielen verschiedenen Anwendungen
(Maschinensteuerungen, Fahrzeugaufbauten, Sensorsysteme)
eingesetzt.
T
Die Nutzung in stark unterschiedlichen Anwendungs-Szenarien ist
nur möglich, wenn ein CANopen-Gerät auch an den jeweiligen
Anwendungsfall angepasst werden kann.
T
Diese Anpassbarkeit stellt hohe Anforderungen an das
Detailwissen der Entwickler, Integratoren und Anwender.
T
Der Einsatz von Softwarewerkzeugen kann hier unterstützen.
Slide: 3
Einführung
Was definiert CANopen?
Device
Profile A
Device
Profile B
Device
Profile C
ISO/OSI Layer 7: Application - CANopen
Communication Profile
T
Funktionalität von
Geräteklassen
T
Verwendung von
Nachrichten
T
Konfigurationsschnittstelle
T
Netzwerkmanagement
T
Fehlerbehandlung
T
elektrisches Interface,
Baudraten, Steckverbinder
ISO/OSI Layer 2: Data Link
ISO/OSI Layer 1: Physical
CAN
Slide: 4
Einführung
Und wer legt das alles fest?
T
T
Die Spezifikationen im Umfeld von CANopen werden vom CiA e.V. (CAN in
Automation - Nürnberg) gepflegt und weiterentwickelt.
Definiert werden die Dokumente von den Mitgliedsfirmen (im Rahmen von
Special Interest Groups)
Slide: 5
Agenda
Einführung
> Eigenschaften von CANopen
Slide: 6
Struktur eines CANopen-Netzwerks
120
T
In einem Netzwerk sind bis zu
127 Geräte an einen Bus
angeschlossen. Jedem Gerät
wird eine eindeutig Knoten-ID
[1..127] zugewiesen.
T
Die Übertragung erfolgt gemäß
ISO 11898-2:2003 (CAN Highspeed medium access unit).
T
Der Bus wird an den Enden
jeweils mit 120 Ohm
abgeschlossen.
T
Die maximale Ausdehnung des
Busses wird durch die
verwendete Baudrate
bestimmt.
CANopen device 1
CAN low
CAN high
CANopen device 2
CANopen device
127
120
Slide: 7
Werkzeuge/Testbarkeit
T
Grundsätzlich nutzt CANopen die von CAN auf Frame-Ebene
verfügbaren Kommunikationsmechanismen.
T
Wenn im Rahmen der Entwicklung oder Integration Probleme
auftauchen, deren Ursache möglicherweise in einer fehlerhaften
CAN-Kommunikation liegt, wird i.d.R. ein Busmonitor benötigt:
T
Busanalyse
T
T
T
elektrische Ebene Æ Oszilloskop (Überprüfung d. Pegel,
Nachrichtenverkehr ja/nein)
logische Ebene Æ Welche Nachrichten werden auf dem Bus
transportiert (Hier ist auch Domäneninformation wichtig Æ
Protokollinterpretation)?
Logging Æ Aufzeichnung des Busverkehrs (Nachweis,
Dokumentation)
Slide: 8
Objektverzeichnis
T
Sammlung von Parametern für Kommunikation und Applikation
T
Standardisierter Aufbau der Struktur des Objektverzeichnisses
T
Zugriffsmöglichkeit auf strukturierte Parameter (Arrays, Records)
T
Referenz auf Datentypen
Index (hex)
Object
0000
not used
0001-025F
Data Types
0260-0FFF
Reserved for further use
1000-1FFF
Communication Profile Area
2000-5FFF
Manufacturer Specific Profile Area
6000-9FFF
Standardized Device Profile Area
A000-AFFF
Reserved for further use
Slide: 10
Objektadressierung im Objektverzeichnis
Main
Index
Sub
Index
Object meaning
Data Type
6092
0
Number of Entries
Unsigned8
1
Baud Rate
Unsigned16
2
Number of Data Bits
Unsigned8
3
Number of Stop Bits
Unsigned8
4
Parity
Unsigned8
T
T
T
typedef struct
{
unsigned char Number_of_Entries;
unsigned short BaudRate;
unsigned char Number_of_DataBits;
unsigned char Number_of_StopBits;
unsigned char Parity;
} RS232;
T
Jedes Objekt im Objektverzeichnis
wird über einen Index (16 Bit) und
einen Sub-Index (8 Bit)
angesprochen.
Der Sub-Index ist beim Zugriff auf
Einzelobjekte immer 0.
Nutzung des Sub-Index zur
Adressierung eines Feldes
Beispiel: Abbildung der Parameter
einer seriellen Schnittstelle
RS232 rs232;
Slide: 11
Elektronische Beschreibung des Objektverzeichnisses
T
Gerätebeschreibung

standardisierte
Gerätebeschreibung

herstellerunabhängiges Format

Standard-Tools einsetzbar

beschreibt
Kommunikationsfähigkeiten

listet zugreifbare Objekte mit
ihren Attributen
T
Electronic Data Sheet (DS306)

XML Device Description (DSP311)
Slide: 12
T
Für die Erstellung von elektronischen Gerätebeschreibungen ist
die Nutzung eines Werkzeugs wünschenswert. Damit ist
gewährleistet, dass die erzeugten Dateien konsistent sind und
dem spezifizierten Format entsprechen.
T
Selbst bei ausschließlichem Lesezugriff ist eine strukturierte
Darstellung einer Rohdarstellung (Interpretation z.B. von
Einzelbits innerhalb eines Parameters) vorzuziehen.
T
Weiterhin sollte es möglich sein, Dateien zwischen den
unterschiedlichen Formaten (DS306 ÅÆ DSP311) konvertieren zu
können.
T
Getestet werden kann hier insbesondere, ob eine CANopenImplementierung der elektronischen Beschreibung entspricht
(Konformitätstest).
Slide: 13
Zugriff auf das Objektverzeichnis
T
Über Service-Daten-Objekte
(SDO) erfolgt der Zugriff auf
das Objektverzeichnis eines
CANopen-Gerätes.
T
Jedes CANopen-Gerät muss
über mindestens ein SDO
(Standard SDO) verfügen.
SDO client
CAN-Id:
0x600 + Node-Id
CAN-Id:
0x580 + Node-Id
Pre-defined connection set
SDO server
object
dictionary
Communication object
CAN identifier
NMT
0x0
SYNC
0x80
:
:
RPDO4
0x501 – 0x57F
SDO (Server->Client)
0x581 – 0x5FF
SDO (Client->Server)
0x601 – 0x67F
Error control / boot up
0x701 – 0x77F
Slide: 14
SDO-Protokolle
Server
(Node-ID)
Client
Server
(Node-ID)
Client
Initiate Block Upload
Initiate Upload
1st Block Upload
:
Server
(Node-ID)
Client
Next Block Upload
Initiate Upload
:
Upload Segment
:
:
End Block Upload
Upload Segment
Slide: 15
T
Über das SDO ist der Zugriff auf das komplette Objektverzeichnis
eines Gerätes möglich. Mit einem entsprechenden Werkzeug
können die Objektverzeichniseinträge gelesen und geändert
werden.
T
Das SDO-Protokoll (Protokollvarianten) ist ein sehr wichtiger
Bestandteil eines CANopen-Gerätes und muss dementsprechend
auch getestet werden.
T
Getestet werden muss u.a.
T
Korrekter Ablauf
T
Zeitverhalten (Antwortzeit, Time-Out)
T
Erreichbarkeit von Objekten im Objektverzeichnis
T
Auswirkung auf Applikation (Test ist nicht immer möglich)
Slide: 16
Interne Struktur eines CANopen-Gerätes
Pflicht oder Kür?
Index
Object Type
Description
1000
VAR
device type
M
1001
VAR
error register
M
1002
VAR
manufacturer status register
O
1003
ARRAY
pre-defined error field
O
1005 - 1007
VAR
COB-ID SYNC-message, communication cycle period, synchronous window
length
1008 - 100A
VAR
device name, hardware version, software version
O
100C, 100D
VAR
guard time, life time factor
C
1010 - 1011
ARRAY
store/restore parameters
O
1012 - 1015
VAR
1016
ARRAY
consumer heartbeat time
O
1017
VAR
producer heartbeat time
C
1018
RECORD
Identity object
M
1200 - 127F
RECORD
Server SDO parameter
C/O
1280 - 12FF
RECORD
Client SDO parameter
C
1400 - 17FF
RECORD
Receive PDO Communication and Mapping Parameter for 512 RPDOs
(M)
1800 – 1BFF
RECORD
Transmit PDO Communication and Mapping Parameter for 512 TPDOs
(M)
COB-ID TIME, high resolution time stamp, COB-ID EMCY, Inhibit time EMCY
Slide: 17
Category
C/O
C/O
Interne Struktur eines CANopen-Gerätes
Testbarkeit
T
Viele Eigenschaften, die in den CANopen-Spezifikationen
beschrieben sind, müssen nicht verpflichtend implementiert
werden.
T
Das betrifft sowohl Objekte im Objektverzeichnis, als auch die
damit verbundene Funktionalität.
T
Obwohl viel aus dem Objektverzeichnis (auch aus der elektr.
Beschreibung) ausgelesen werden kann, sind hier Grenzen
gesetzt.
T
z.B.
T
Übertragungsvarianten für PDO
T
Unterstützte Protokolle bei SDO
T
Zusammenhänge zwischen Applikationsobjekten
Slide: 18
Austausch von Prozessdaten
T
object
dictionary
Input
T
PDO producer
(TPDO)
Austausch von Prozeßdaten
zwischen CANopen-Geräten
Beschreibung/Konfiguration jeweils
lokal im Gerät
CAN-Nachricht:
ID + Daten
PDO
consumer
(RPDO)
Output
object
dictionary
Pre-defined connection set
Communication object
CAN identifier
:
:
TPDO1
0x181 – 0x1FF
RPDO1
0x201 – 0x27F
TPDO2
0x281 – 0x2FF
RPDO2
0x301 – 0x37F
TPDO3
0x381 – 0x3FF
RPDO3
0x401 – 0x47F
TPDO4
0x481 – 0x4FF
RPDO4
0x501 – 0x57F
:
:
Slide: 19
Konfiguration von PDO
Index
Description
Sub-Index
Description
0
Number of entries
1
COB-ID
2
Transmission Type
3
Inhibit Time
1400/1800
RPDO/TPDO 1 Communication Parameter
4
Reserved
1401/1801
5
Event Timer
6
SYNC start value
Sub-Index
Description
0
Number of entries
1
1th mapped object
2
2th mapped object
:
:
64
64th mapped object
:
15FF/19FF
1600/1A00
RPDO/TPDO 1 Mapping Parameter
1601/1A01
:
17FF/1BFF
CAN-Nachricht
ID
Data
Slide: 20
CAN-Identifier
Beschreibung
der CAN-Daten
Verbindung von PDOs (Kommunikation)
0
1
2
:
6
Gerät 1
Gerät 2
PDO producer
PDO consumer
Object dictionary
6
:
0x00000181
COB-ID
transmission type
:
SYNC start value
Object dictionary
1400 (RPDO1)
:
:
COB-ID
0x00000181
2
transmission type
:
:
6
CAN-ID
data
6
1
1800 (TPDO1)
PDO
Slide: 21
0
:
SYNC start value
Verbindung von PDOs (Mapping)
Gerät 1
Gerät 2
PDO producer
PDO consumer
0
0
2
1
0x60000108
2
:
0x60000208
Object dictionary
Object dictionary
:
:
1A00 (TPDO1)
1600 (RPDO1)
:
:
6000
64
0
6200
0
1
1
2
2
:
:
PDO
Slide: 22
0
0
2
1
0x62000108
2
0x62000208
:
64
Werkzeuge
T
T
Um PDO zwischen CANopen-Geräten auszutauschen, müssen
diese PDO korrekt konfiguriert werden (Entwickler, Integrator).
T
Der (gemeinsam zu nutzende) CAN-Identifier muss für jede
PDO-Verbindung festgelegt werden.
T
Die Mapping-Tabellen (Interpretationsvorschrift für CANNachrichten) müssen für jedes PDO gefüllt/abgeglichen
werden.
T
Fehler bei dieser Konfiguration führen zu fatalen Auswirkungen.
Hier ist ein Werkzeug sinnvoll, dass eine konsistente Berechnung
des Mappings (abhängig von der elektronischen
Gerätebeschreibung) zulässt. Damit wird vor allem die
Konfiguration von kompletten Netzwerken vereinfacht.
Slide: 23
Testbarkeit
T
PDO lassen sich nur testen, wenn entsprechende Vorkehrungen
für die Auslösung und Interpretation getroffen wurden. Die
übertragenen Daten werden immerhin direkt in der Applikation
ausgewertet.
T
Folgende Eigenschaften lassen sich gut testen:
T
T
PDO-Konfiguration (über SDO und Gerätebeschreibung)
T
Auslösung über Timer und SYNC-Nachricht
Dynamische Anforderungen an die PDO-Kommunikation sind in
den CANopen-relevanten Dokumenten nur in Ausnahmefällen
festgelegt. Hier muss auf jeden Fall ein Testszenario festgelegt
werden.
Slide: 24
Netzwerkmanagement/Statusmaschine
Power on or
T
Hardware Reset
Initialisation
T
T
PreOperational
T
Stopped
Jedes Gerät verfügt über eine
Statusmaschine, die das Verhalten
der CANopen-Funktionalität
kontrolliert.
Interne Initialisierung der
Kommunikation
Betriebsbereit - (LED „RUN LED“
oder „STATUS LED“ blinkt grün)
Der NMT-Master steuert die
Statusmaschine über eine CANNachricht.
Operational
Slide: 25
Fehlererkennung - Heartbeat
T
CANopen
device A
T
Der Ausfall von Geräten im Netz
kann nicht direkt erkannt werden –
„D“ erkennt nicht, dass „A“ keine
Nachrichten mehr empfängt.
Die Ausfallerkennung kann nur
über Time-Out erfolgen:
T
CANopen
device B
CANopen
device D
T
[Guarding] Request + Warten
auf Response
[Heartbeat] Warten auf
zyklische Nachricht
CANopen
device C
Slide: 26
Testbarkeit
T
Die Statusmaschine lässt sich nur indirekt testen (Reaktion über
gesendete Nachrichten). Der Zustand des Gerätes wird
umgeschaltet und es wird über die Fehlerüberwachung oder die
PDO-Kommunikation geprüft, ob intern diese Umschaltung
vorgenommen wurde.
T
Für den Integrator und den Anwender sind hier auch quantitative
Aussagen von großer Bedeutung:

T
Wie lange dauert der Start eines Gerätes?
T
Wie lange dauert eine Statusumschaltung (z.B. nach
Operational)?
Zeitliche Anforderungen sind im Standard nicht berücksichtigt.
Hier muss der CANopen-Nutzer selbst Vorgaben machen, die für
sein System wichtig sind.
Slide: 27
Agenda
Einführung
> Konformitätstest des CiA e.V.
Slide: 28
Prinzipien
T
Die Konformität einer bestehenden Applikation bezüglich des DS301 kann mit einem Konformitätstest (EN 50325-4, DS 301
V4.02) nachgewiesen werden
T
T
Das Tool sowie das Zertifikat wird vom CiA e.V. angeboten
(http://www.can-cia.org)
T
T
Der Test soll die Interoperabilität zwischen CANopen Geräten
sicherstellen
Das Test-Labor befindet sich in den Büroräumen des CiA e.V. in
Nürnberg
Besteht ein Gerät den Test, wird die Bezeichnung „CANopen
certified“ erteilt (Liste zertifizierter Geräte ist im Internet
einsehbar)
Slide: 29
Ablauf
T
EDS Datei
Der Konformitätstest umfasst
T
die Überprüfung der EDS Datei
T
T
Konsistenz, Wertebereiche,
vorgeschriebene Einträge, interne
Referenzen
die Überprüfung des Gerätes
T
SDO Protokoll, PDO (nur TPDO),
EMCY, SYNC Verhalten
T
Vergleich des
Objektverzeichnisses gegen die
Einträge in der EDS Datei
T
Überprüfung der internen
Statusmaschine in Kombination
mit den Fehlererkennungsmechanismen
CiA e.V.
Conformance
Test
CANopen
Gerät
Slide: 30
Was wird vom Konformitätstest nicht abgedeckt?
T
Generell werden keine Zeitvorgaben überprüft
T
T
Es wird kein Last-Test durchgeführt
T
T
die individuelle Leistungsfähigkeit eines Gerätes wird nicht
berücksichtigt (z.B. die Boot-Up Zeit, SDO Antwortzeiten,
kritische Frequenz der Prozessdaten).
der Konformitätstest wird ohne vordefinierte HintergrundBuslast ausgeführt
Das physikalische Interface wird nicht überprüft
T
Das elektrische Interface wird nicht getestet. Somit kann das
Verhalten in einem realen Netzwerk vom erwarteten Verhalten
abweichen.
Slide: 31
Agenda
Einführung
> Was muss man hier noch tun?
Slide: 32
Weitere Testumfänge
T
Der Konformitätstest des CiA e.V. prüft einige grundlegende
CANopen-Eigenschaften. Um wirklich Interoperabilität in einem
System gewährleisten zu können, sind aber weitergehende Tests
erforderlich.
T
Prüfung dynamischer Größen (z.B. Umschaltzeiten sind je nach
Prozessorplattform unterschiedlich)
T
Negativ-Tests (bewusste Protokollverletzungen, um die
Stabilität des CANopen-Gerätes zu beeinflussen)
T
Applikative Tests (Prüfung der ausgetauschten
Applikationsdaten Æ ist natürlich nur mit Anwender Know-How
möglich)
Slide: 33
Vielen Dank für Ihre Aufmerksamkeit.
Weitere Infos unter:
www.vector.com
Autor: Mirko Tischer
Vector Informatik GmbH
Ingersheimer Str. 24
70499 Stuttgart
Slide: 34

Eigenschaften von CANopen

Transcription

Similar documents

Einführung in CANopen

PDF Geschichte der Maus

CANopen

Neuer Drehkolben- gaszähler RABO®

(Features, Software, Third Party Tools) - TinyCan - MHS

Produktinformation