Werkzeugeinsatz bei CANopen

Transkript

1 Insert picture and click Align Title Graphic. Werkzeugeinsatz bei CANopen Systemeigenschaften und Testbarkeit CANopen Techdays 26./ , München/Hamburg Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector. V

2 Agenda > Einführung Eigenschaften von CANopen Konformitätstest des CiA e.v. Was muss man hier noch tun? Slide 2

3 Einführung Motivation CANopen wird heute in vielen verschiedenen Anwendungen (Maschinensteuerungen, Fahrzeugaufbauten, Sensorsysteme) eingesetzt. Die Nutzung in stark unterschiedlichen Anwendungs-Szenarien ist nur möglich, wenn ein CANopen-Gerät auch an den jeweiligen Anwendungsfall angepasst werden kann. Diese Anpassbarkeit stellt hohe Anforderungen an das Detailwissen der Entwickler, Integratoren und Anwender. Der Einsatz von Softwarewerkzeugen kann hier unterstützen. Slide 3

4 Einführung Was definiert CANopen? Device Profile A Device Profile B Device Profile C Funktionalität von Geräteklassen ISO/OSI Layer 7 Application - CANopen Communication Profile ISO/OSI Layer 2 Data Link Verwendung von Nachrichten Konfigurationsschnittstelle Netzwerkmanagement Fehlerbehandlung ISO/OSI Layer 1 Physical elektrisches Interface, Baudraten, Steckverbinder CAN Slide 4

5 Einführung Und wer legt das alles fest? 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

6 Agenda Einführung > Eigenschaften von CANopen Konformitätstest des CiA e.v. Was muss man hier noch tun? Slide 6

7 Struktur eines CANopen-Netzwerks CANopen device In einem Netzwerk sind bis zu 127 Geräte an einen Bus angeschlossen. Jedem Gerät wird eine eindeutig Knoten-ID [1..127] zugewiesen. CANopen device 2 CAN high CAN low Die Übertragung erfolgt gemäß ISO (CAN Highspeed medium access unit). Der Bus wird an den Enden jeweils mit 120 Ohm abgeschlossen. CANopen device Die maximale Ausdehnung des Busses wird durch die verwendete Baudrate bestimmt. Slide 7

8 Werkzeuge/Testbarkeit Grundsätzlich nutzt CANopen die von CAN auf Frame-Ebene verfügbaren Kommunikationsmechanismen. 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 Busanalyse 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

9

10 Objektverzeichnis Sammlung von Parametern für Kommunikation und Applikation Standardisierter Aufbau der Struktur des Objektverzeichnisses Zugriffsmöglichkeit auf strukturierte Parameter (Arrays, Records) Referenz auf Datentypen Index (hex) F FFF FFF FFF FFF A000-AFFF Object not used Data Types Reserved for further use Communication Profile Area Manufacturer Specific Profile Area Standardized Device Profile Area Reserved for further use Slide 10

11 Objektadressierung im Objektverzeichnis Main Index 6092 Sub Index Object meaning Number of Entries Baud Rate Number of Data Bits Number of Stop Bits Parity Data Type Unsigned8 Unsigned16 Unsigned8 Unsigned8 Unsigned8 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 typedef struct { unsigned char Number_of_Entries; unsigned short BaudRate; unsigned char Number_of_DataBits; unsigned char Number_of_StopBits; unsigned char Parity; } RS232; Beispiel Abbildung der Parameter einer seriellen Schnittstelle RS232 rs232; Slide 11

12 Elektronische Beschreibung des Objektverzeichnisses Gerätebeschreibung standardisierte Gerätebeschreibung herstellerunabhängiges Format Standard-Tools einsetzbar beschreibt Kommunikationsfähigkeiten listet zugreifbare Objekte mit ihren Attributen Electronic Data Sheet (DS306) XML Device Description (DSP311) Slide 12

13 Werkzeuge/Testbarkeit 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. Selbst bei ausschließlichem Lesezugriff ist eine strukturierte Darstellung einer Rohdarstellung (Interpretation z.b. von Einzelbits innerhalb eines Parameters) vorzuziehen. Weiterhin sollte es möglich sein, Dateien zwischen den unterschiedlichen Formaten (DS306 DSP311) konvertieren zu können. Getestet werden kann hier insbesondere, ob eine CANopen- Implementierung der elektronischen Beschreibung entspricht (Konformitätstest). Slide 13

14 Zugriff auf das Objektverzeichnis CAN-Id 0x600 + Node-Id SDO client CAN-Id 0x580 + Node-Id Über Service-Daten-Objekte (SDO) erfolgt der Zugriff auf das Objektverzeichnis eines CANopen-Gerätes. Jedes CANopen-Gerät muss über mindestens ein SDO (Standard SDO) verfügen. Pre-defined connection set SDO server object dictionary Communication object NMT SYNC RPDO4 SDO (Server->Client) SDO (Client->Server) Error control / boot up CAN identifier 0x0 0x80 0x501 0x57F 0x581 0x5FF 0x601 0x67F 0x701 0x77F Slide 14

15 SDO-Protokolle Client Server (Node-ID) Client Server (Node-ID) Initiate Upload Initiate Block Upload 1st Block Upload Client Server (Node-ID) Next Block Upload Initiate Upload Upload Segment Upload Segment End Block Upload Slide 15

16 Werkzeuge/Testbarkeit Ü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. Das SDO-Protokoll (Protokollvarianten) ist ein sehr wichtiger Bestandteil eines CANopen-Gerätes und muss dementsprechend auch getestet werden. Getestet werden muss u.a. Korrekter Ablauf Zeitverhalten (Antwortzeit, Time-Out) Erreichbarkeit von Objekten im Objektverzeichnis Auswirkung auf Applikation (Test ist nicht immer möglich) Slide 16

17 Interne Struktur eines CANopen-Gerätes Pflicht oder Kür? Index Object Type Description Category 1000 VAR device type M 1001 VAR error register M 1002 VAR manufacturer status register O 1003 ARRAY pre-defined error field O VAR COB-ID SYNC-message, communication cycle period, synchronous window length C / O A VAR device name, hardware version, software version O 100C, 100D VAR guard time, life time factor C ARRAY store/restore parameters O VAR COB-ID TIME, high resolution time stamp, COB-ID EMCY, Inhibit time EMCY C / O 1016 ARRAY consumer heartbeat time O 1017 VAR producer heartbeat time C 1018 RECORD Identity object M F RECORD Server SDO parameter C / O FF RECORD Client SDO parameter C FF RECORD Receive PDO Communication and Mapping Parameter for 512 RPDOs (M) BFF RECORD Transmit PDO Communication and Mapping Parameter for 512 TPDOs (M) Slide 17

18 Interne Struktur eines CANopen-Gerätes Testbarkeit Viele Eigenschaften, die in den CANopen-Spezifikationen beschrieben sind, müssen nicht verpflichtend implementiert werden. Das betrifft sowohl Objekte im Objektverzeichnis, als auch die damit verbundene Funktionalität. Obwohl viel aus dem Objektverzeichnis (auch aus der elektr. Beschreibung) ausgelesen werden kann, sind hier Grenzen gesetzt. z.b. Übertragungsvarianten für PDO Unterstützte Protokolle bei SDO Zusammenhänge zwischen Applikationsobjekten Slide 18

19 Austausch von Prozessdaten object dictionary Input Austausch von Prozeßdaten zwischen CANopen-Geräten Beschreibung/Konfiguration jeweils lokal im Gerät PDO producer (TPDO) CAN-Nachricht ID + Daten Pre-defined connection set Communication object CAN identifier PDO consumer (RPDO) TPDO1 RPDO1 TPDO2 0x181 0x1FF 0x201 0x27F 0x281 0x2FF RPDO2 0x301 0x37F TPDO3 0x381 0x3FF Output object dictionary RPDO3 TPDO4 RPDO4 0x401 0x47F 0x481 0x4FF 0x501 0x57F Slide 19

20 Konfiguration von PDO Sub-Index Description 0 Number of entries 1 COB-ID CAN-Identifier 2 Transmission Type Index Description 3 Inhibit Time 1400/ /1801 RPDO/TPDO 1 Communication Parameter RPDO/TPDO 2 Communication Parameter Reserved Event Timer SYNC start value 15FF/19FF 1600/1A /1A01 17FF/1BFF RPDO/TPDO 512 Communication Parameter RPDO/TPDO 1 Mapping Parameter RPDO/TPDO 2 Mapping Parameter RPDO/TPDO 512 Mapping Parameter Sub-Index Description Number of entries 1th mapped object 2th mapped object Beschreibung der CAN-Daten 64 64th mapped object CAN-Nachricht ID Data Slide 20

21 Verbindung von PDOs (Kommunikation) Gerät 1 PDO producer Gerät 2 PDO consumer COB-ID 0x transmission type SYNC start value Object dictionary 1800 (TPDO1) Object dictionary 1400 (RPDO1) COB-ID 0x transmission type 6 SYNC start value PDO CAN-ID data Slide 21

22 Verbindung von PDOs (Mapping) Gerät 1 PDO producer Gerät 2 PDO consumer Object dictionary Object dictionary x x A00 (TPDO1) (RPDO1) x x PDO Slide 22

23 Werkzeuge Um PDO zwischen CANopen-Geräten auszutauschen, müssen diese PDO korrekt konfiguriert werden (Entwickler, Integrator). Der (gemeinsam zu nutzende) CAN-Identifier muss für jede PDO-Verbindung festgelegt werden. Die Mapping-Tabellen (Interpretationsvorschrift für CAN- Nachrichten) müssen für jedes PDO gefüllt/abgeglichen werden. 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

24 Testbarkeit 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. Folgende Eigenschaften lassen sich gut testen PDO-Konfiguration (über SDO und Gerätebeschreibung) 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

25 Netzwerkmanagement/Statusmaschine Power on or Hardware Reset Jedes Gerät verfügt über eine Statusmaschine, die das Verhalten der CANopen-Funktionalität kontrolliert. Initialisation Interne Initialisierung der Kommunikation Betriebsbereit - (LED RUN LED oder STATUS LED blinkt grün) Pre- Operational Stopped Der NMT-Master steuert die Statusmaschine über eine CAN- Nachricht. Operational Slide 25

26 Fehlererkennung - Heartbeat CANopen device A 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 [Guarding] Request + Warten auf Response CANopen device B CANopen device D [Heartbeat] Warten auf zyklische Nachricht CANopen device C Slide 26

27 Testbarkeit 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. Für den Integrator und den Anwender sind hier auch quantitative Aussagen von großer Bedeutung Wie lange dauert der Start eines Gerätes? 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

28 Agenda Einführung Eigenschaften von CANopen > Konformitätstest des CiA e.v. Was muss man hier noch tun? Slide 28

29 Konformitätstest des CiA e.v. Prinzipien Die Konformität einer bestehenden Applikation bezüglich des DS- 301 kann mit einem Konformitätstest (EN , DS 301 V4.02) nachgewiesen werden Der Test soll die Interoperabilität zwischen CANopen Geräten sicherstellen Das Tool sowie das Zertifikat wird vom CiA e.v. angeboten (http// 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

30 Konformitätstest des CiA e.v. Ablauf Der Konformitätstest umfasst EDS Datei die Überprüfung der EDS Datei Konsistenz, Wertebereiche, vorgeschriebene Einträge, interne Referenzen die Überprüfung des Gerätes SDO Protokoll, PDO (nur TPDO), EMCY, SYNC Verhalten Vergleich des Objektverzeichnisses gegen die Einträge in der EDS Datei Überprüfung der internen Statusmaschine in Kombination mit den Fehlererkennungsmechanismen CiA e.v. Conformance Test CANopen Gerät Slide 30

31 Konformitätstest des CiA e.v. Was wird vom Konformitätstest nicht abgedeckt? Generell werden keine Zeitvorgaben überprüft die individuelle Leistungsfähigkeit eines Gerätes wird nicht berücksichtigt (z.b. die Boot-Up Zeit, SDO Antwortzeiten, kritische Frequenz der Prozessdaten). Es wird kein Last-Test durchgeführt der Konformitätstest wird ohne vordefinierte Hintergrund- Buslast ausgeführt Das physikalische Interface wird nicht überprüft Das elektrische Interface wird nicht getestet. Somit kann das Verhalten in einem realen Netzwerk vom erwarteten Verhalten abweichen. Slide 31

32 Agenda Einführung Eigenschaften von CANopen Konformitätstest des CiA e.v. > Was muss man hier noch tun? Slide 32

33 Was muss man hier noch tun? Weitere Testumfänge 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. Prüfung dynamischer Größen (z.b. Umschaltzeiten sind je nach Prozessorplattform unterschiedlich) Negativ-Tests (bewusste Protokollverletzungen, um die Stabilität des CANopen-Gerätes zu beeinflussen) Applikative Tests (Prüfung der ausgetauschten Applikationsdaten ist natürlich nur mit Anwender Know-How möglich) Slide 33

34 Vielen Dank für Ihre Aufmerksamkeit. Weitere Infos unter Autor Mirko Tischer Vector Informatik GmbH Ingersheimer Str Stuttgart Slide 34