bachelorarbeit im studiengang technische informatik der ... · die formula student1 ist ein projekt...

Fakultät Technik und Informatik Faculty of Engineering and Computer ScienceDepartment Informatik Department of Computer Science

Sebastian Haase

Telemetrie im Formula Student Rennwagen aufBasis von CAN Bus, Datenspeicherung und

Wireless LAN Technologien

Bachelorarbeit

Abgegeben am 23. September 2007

Betreuender Prüfer : Prof. Dr. Franz KorfZweitgutachter : Prof. Dr. rer. nat. Stephan Pareigis

Bachelorarbeit eingereicht im Rahmen der Bachelorprüfungim Studiengang Technische Informatikam Department Informatikder Fakultät Technik und Informatikder Hochschule für Angewandte Wissenschaften Hamburg

Sebastian Haase

Telemetrie im Formula Student Rennwagen aufBasis von CAN Bus, Datenspeicherung und

Wireless LAN Technologien

Sebastian Haase

Thema der BachelorarbeitTelemetrie im Formula Student Rennwagen auf Basis von CAN Bus, Datenspei-cherung und Wireless LAN Technologien

StichworteFormula Student, Telemetrie, eingebettete Systeme, Echtzeit-Systeme, Mikro-controller, CAN, TTCAN, TCP/IP, WLAN, WiPort, SD Speicherkarte

KurzzusammenfassungGegenstand dieser Arbeit ist die Entwicklung und Implementierung eines Tele-metriesystems für einen Formula Student Rennwagen. Dazu wurde eine modula-re Systemarchitektur entworfen, die das System als vernetzte Struktur beschreibtund die Schnittstellen definiert. Die Kommunikation zwischen den verteilten Kom-ponenten wird mit einem CAN-Bus realisiert. Des weiteren wurden zwei Kompo-nenten für das Telemetriesystem erstellt. Eine Komponente integriert eine draht-lose Kommunikation für eine live Auswertung der Telemetriedaten und die zweiteKomponente speichert alle Daten vom CAN-Bus auf eine SD Memory Card.

Sebastian Haase

Title of the paperTelemetry in the Formula Student racing car on the basis of CAN bus, data stor-age and wireless LAN technologies

KeywordsFormula Student, telemetry, embedded system, real-time system, microcon-troller, CAN, TTCAN, TCP/IP, WLAN, SD memory card

AbstractThe object of this assignment is the development and implementation of atelemetry system for a Formula Student racing car. A modular system architec-ture has been developed for this purpose which specifies the system as networkstructure and defines the interfaces. Communication takes place between thedistributed components with a CAN bus. Furthermore, two components wereconstructed for the telemetry system. One component integrates wireless com-munication for a live evaluation of the telemetry data and the second componentsaves all data from the CAN bus onto an SD memory card.

Inhaltsverzeichnis

Tabellenverzeichnis 7

Abbildungsverzeichnis 8

1. Einleitung 101.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.1.1. Formula Student . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.1.2. HAWKS Racing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.2. Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.3. Telemetrie im Rennwagen - Stand der Technik . . . . . . . . . . . . . . . . 13

2. Analyse 162.1. Systemumgebung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.2. Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.2.1. Funktionale Anforderungen . . . . . . . . . . . . . . . . . . . . . . . 162.2.2. Nicht-Funktionale Anforderungen . . . . . . . . . . . . . . . . . . . . 18

2.3. Randbedingungen dieser Arbeit . . . . . . . . . . . . . . . . . . . . . . . . 20

3. Grundlagen 223.1. CAN Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.1.1. Nachrichtenstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.1.2. Baudrate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.1.3. TTCAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.2. SPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.2.1. Eigenschaften . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.2.2. Master-Slave-Prinzip . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.3. FAT-Dateisystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.4. Serielle Datenübertragung . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.4.1. UART . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.4.2. RS232 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.4.3. Baudrate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.5. Rechnernetze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.5.1. Referenzmodelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Inhaltsverzeichnis 5

3.5.2. TCP/IP-Referenzmodell . . . . . . . . . . . . . . . . . . . . . . . . 333.5.3. Kommunikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.5.4. Wireless LAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4. Design und Realisierung 394.1. Systemarchitektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.1.1. Design der Komponentenanordnung . . . . . . . . . . . . . . . . . . 394.1.2. Datenformat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.1.3. Auswahl der Hardware . . . . . . . . . . . . . . . . . . . . . . . . . 434.1.4. Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.1.5. Realisierung der Architektur . . . . . . . . . . . . . . . . . . . . . . 46

4.2. CAN Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.2.1. Grundkonfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.2.2. Transport-Protokoll . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.2.3. Anwendungs-Protokoll . . . . . . . . . . . . . . . . . . . . . . . . . 524.2.4. TTCAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524.2.5. Lastanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564.2.6. Realisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

4.3. Communicator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574.3.1. Hardwaredesign vom Communicator . . . . . . . . . . . . . . . . . . 584.3.2. Bedingungen für die Übertragung vom Leitstand . . . . . . . . . . . . 614.3.3. WiPort Communication Module . . . . . . . . . . . . . . . . . . . . . 624.3.4. CAN Communication Module . . . . . . . . . . . . . . . . . . . . . . 654.3.5. Synchronisation der Module . . . . . . . . . . . . . . . . . . . . . . 68

4.4. Leitstand-Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 704.4.1. Bedingungen für die Kommunikation zum Communicator . . . . . . . 704.4.2. Synchronisierung der Nachrichten vom Communicator . . . . . . . . 704.4.3. Steuerung und Konfiguration von Komponenten . . . . . . . . . . . . 71

4.5. Datalogger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724.5.1. Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724.5.2. Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 744.5.3. Auslesen der Daten . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

5. Qualitätssicherung 805.1. Fehlermanagement im Telemetriesystem . . . . . . . . . . . . . . . . . . . 80

5.1.1. Realisierung der Fehlerkontrolle . . . . . . . . . . . . . . . . . . . . 815.2. Testorganisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

5.2.1. Testvorgehen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 835.2.2. Testwerkzeuge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 835.2.3. Gewünschte Testergebnisse . . . . . . . . . . . . . . . . . . . . . . 85

5.3. Testdurchführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

Inhaltsverzeichnis 6

5.3.1. Modultests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 865.3.2. Integrationstests . . . . . . . . . . . . . . . . . . . . . . . . . . . . 915.3.3. Systemtests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

6. Zusammenfassung und Ausblick 946.1. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

6.1.1. Ausgangssituation . . . . . . . . . . . . . . . . . . . . . . . . . . . 946.1.2. Durchführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 946.1.3. Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

6.2. Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 956.2.1. Einsatz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 956.2.2. Veränderungen und Weiterentwicklung . . . . . . . . . . . . . . . . . 96

Literaturverzeichnis 98

A. Automaten der Datalogger-Software 100

B. CAN-Bus Daten 103

C. Schaltpläne 106

D. Komponenten-Anschlussbelegung 108

Glossar 110

Tabellenverzeichnis

1.1. Übersicht der Ziele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.1. Sollfrequenzen der Sensoren und Steuergeräte . . . . . . . . . . . . . . . . 19

3.1. Anzahl der Bits eines CAN-Frames . . . . . . . . . . . . . . . . . . . . . . 243.2. Zeiten für die Übertragung eines CAN-Frames . . . . . . . . . . . . . . . . 253.3. Übliche Baudraten für die serielle Datenübertragung . . . . . . . . . . . . . 313.4. Übersicht des 802.11-PHY-Layer . . . . . . . . . . . . . . . . . . . . . . . . 363.5. 802.11-Arbeitsgruppen und Standarderweiterungen . . . . . . . . . . . . . . 363.6. Richtwerte für erzielbare Reichweiten . . . . . . . . . . . . . . . . . . . . . 383.7. Dämpfungseigenschaften verschiedener Materialien . . . . . . . . . . . . . 38

4.1. Auszug der Zeitmessungen am Scheduler . . . . . . . . . . . . . . . . . . . 454.2. Vergleich zwischen ereignisgesteuertem und zeitgesteuertem CAN-Bus . . . 534.3. Anpassung der Sollfrequenzen . . . . . . . . . . . . . . . . . . . . . . . . . 544.4. Zeitbedarf von CAN-Bibliotheksfunktionen . . . . . . . . . . . . . . . . . . . 574.5. UART Baudrate Fehler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594.6. CAN Baudrate Fehler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 604.7. Interrupteigenschaften . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

5.1. Ergebnis vom Lasttest beim Communicator . . . . . . . . . . . . . . . . . . 875.2. Spannungstest beim Communicator . . . . . . . . . . . . . . . . . . . . . . 905.3. Spannungstest beim Datalogger . . . . . . . . . . . . . . . . . . . . . . . . 90

Abbildungsverzeichnis

1.1. Kommunikation zwischen Rennwagen und Leitstand . . . . . . . . . . . . . 121.2. Leitstand von Ferrari für zwei Rennwagen . . . . . . . . . . . . . . . . . . . 131.3. MyChron 3 XG LOG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.1. CAN Standard Frames nach der CAN 2.0A Spezifikation . . . . . . . . . . . 233.2. CAN Extended Frames nach der CAN 2.0B Spezifikation . . . . . . . . . . . 233.3. Aufbau eines TTCAN Matrixzyklus aus Basiszyklen, die mehrere Zeitfenster

enthalten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.4. Aufbau eines TTCAN Matrixzyklus (Systemmatrix) . . . . . . . . . . . . . . 273.5. Master-Slave Verbindung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.6. Serieller Datenstrom der UART . . . . . . . . . . . . . . . . . . . . . . . . 303.7. OSI und TCP/IP Referenzmodell . . . . . . . . . . . . . . . . . . . . . . . . 333.8. Virtuelle Kommunikation zwischen einzelnen Schichten . . . . . . . . . . . . 353.9. Kommunikationswege innerhalb des Referenzmodells . . . . . . . . . . . . 353.10.WLAN-Frame nach 802.11 . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.1. Zentrale Telemetriesystem-Architektur . . . . . . . . . . . . . . . . . . . . . 394.2. Modulare Telemetriesystem-Architektur . . . . . . . . . . . . . . . . . . . . 404.3. Beispiel für ein Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.4. Datenformat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.5. Evaluation Board für AT90CAN128 Mikrocontroller . . . . . . . . . . . . . . 434.6. Leitstand mit Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.7. Beispiel einer Taskeinteilung . . . . . . . . . . . . . . . . . . . . . . . . . . 454.8. Realisierung der Telemetriesystem-Architektur im HAWK07 . . . . . . . . . . 464.9. 11 Bit Identifizierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.10.Byte 0 der 8 Byte Daten . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.11.Belegung der 8 Byte Daten für den Data Single Nachrichtentyp . . . . . . . . 494.12.Belegung der 8 Byte Daten für die Nachrichtentypen Control und Error . . . . 504.13.Kommunikationsverlauf für Nachrichten vom Typ Data Single . . . . . . . . . 514.14.CAN-Adressen einer Komponente . . . . . . . . . . . . . . . . . . . . . . . 514.15.TTCAN Zyklusaufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554.16.Oszilloskopaufnahme der Referenznachrichten . . . . . . . . . . . . . . . . 554.17.Communicator-Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Abbildungsverzeichnis 9

4.18.WiPort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584.19.Communicator Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614.20.Verändertes Datenformat . . . . . . . . . . . . . . . . . . . . . . . . . . . . 624.21.Wiport Communication Module . . . . . . . . . . . . . . . . . . . . . . . . . 634.22.Erforderliche Interrupteigenschaften vom Wiport Communication Module . . . 654.23.CAN Communication Module . . . . . . . . . . . . . . . . . . . . . . . . . 664.24.Taskeinteilung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674.25.Synchronisations-Verbindung der beiden Module . . . . . . . . . . . . . . . 684.26.Beispiel einer Startsynchronisation . . . . . . . . . . . . . . . . . . . . . . 694.27.Leitstand-Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 704.28.Synchronisation vom Indexzeiger . . . . . . . . . . . . . . . . . . . . . . . 714.29.Datalogger-Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 734.30.Datalogger Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 744.31.Verzeichnisstruktur auf einer SD Memory Card . . . . . . . . . . . . . . . . 764.32.RS232 Verbindung zwischen Communicator und Datenlogger . . . . . . . . 774.33.Protokoll für den Empfang der Verzeichnisstruktur . . . . . . . . . . . . . . . 784.34.Protokoll für den Empfang des Inhalts einer Datei . . . . . . . . . . . . . . . 784.35.Identifizierungsnummer einer Datei . . . . . . . . . . . . . . . . . . . . . . 784.36.Zuordnung der Identifizierungsnummern . . . . . . . . . . . . . . . . . . . . 79

5.1. System Checker im Systemdesign . . . . . . . . . . . . . . . . . . . . . . . 805.2. Fehlerkontrolle im TTCAN Zyklusaufbau . . . . . . . . . . . . . . . . . . . . 805.3. Fehlerkontrolle bei Komponenten ohne TTCAN-Funktionalität . . . . . . . . 815.4. Statusnachrichten von Komponenten . . . . . . . . . . . . . . . . . . . . . 825.5. Vorgehen beim Testen der Komponenten . . . . . . . . . . . . . . . . . . . 835.6. Werkzeuge zum Testen der Komponenten . . . . . . . . . . . . . . . . . . . 845.7. Communicator und Datalogger auf dem Hydropulser . . . . . . . . . . . . . 885.8. Diagramm der ermittelten Beschleunigungswerte vom Communicator . . . . 895.9. Diagramm der ermittelten Beschleunigungswerte vom Datalogger . . . . . . 895.10.Oszilloskopaufnahme vom CAN-Bus . . . . . . . . . . . . . . . . . . . . . . 925.11.Spannungsschwankungen vom Bordnetz des Rennwagens . . . . . . . . . . 93

A.1. Hauptautomat der Datalogger-Software . . . . . . . . . . . . . . . . . . . . 100A.2. Subautomat zum Auslesen einer Datei . . . . . . . . . . . . . . . . . . . . . 101A.3. Subautomat zum Auslesen der Ordner-Struktur . . . . . . . . . . . . . . . . 101A.4. Subautomat zum Aufzeichnen von CAN-Bus-Daten . . . . . . . . . . . . . . 102

B.1. Inhalt der CAN Daten-Nachrichten . . . . . . . . . . . . . . . . . . . . . . . 103B.2. Inhalt der CAN Control-Nachrichten . . . . . . . . . . . . . . . . . . . . . . 104B.3. Inhalt der CAN Error-Nachrichten . . . . . . . . . . . . . . . . . . . . . . . 104B.4. Adressen und Sollfrequenzen der CAN-Bus Komponenten . . . . . . . . . . 105

1. Einleitung

1.1. Motivation

Die im Automobilsport vorhandene Konkurrenz stellt hohe Anforderungen an einen Rennwa-gen. Wenn ein Team mit einem Rennwagen in Wettbewerben erfolgreich sein möchte, ist esnötig ihn kontinuierlich zu verbessern. Um den Prozess des Verbesserns zu beschleunigen,müssen viele Informationen über den Rennwagen erfasst und ausgewertet werden.

Die Telemetrie, welche sich mit der Übertragung von Messwerten eines am Messort befind-lichen Sensors zu einer räumlich getrennten Stelle beschäftigt, spielt bei der Erfassung vonDaten eine große Rolle. Sie erfordert den Einsatz verschiedenster Technologien wie z.B.Speichermedien, die es ermöglichen Daten für eine spätere Auswertung im Rennwagenaufzuzeichnen und Datenübertragungsmöglichkeiten, die kabelgebunden und kabellos ein-gesetzt werden damit, Daten zwischen den einzelnen Komponenten im System transferiertwerden können.

1.1.1. Formula Student

Die Formula Student1 ist ein Projekt für Studenten der Ingenieurswissenschaften mit demZiel einen einsitzigen Rennwagen (Monoposto) zu entwerfen und zu bauen, um damit beieinem Wettbewerb gegen Teams aus der ganzen Welt anzutreten. Bei diesem Wettbewerbgewinnt aber nicht das schnellste Auto, sondern das Team mit dem besten Gesamtpaket ausKonstruktion und Rennperformance, Finanzplanung und Verkaufsargumenten.

Der Anspruch der Formula Student ist das Sammeln intensiver Erfahrungen ergänzend zumStudium. Ein Team soll annehmen, es hätte von einer Produktionsfirma einen Auftrag fürdie Erstellung eines Prototypen erhalten. Dazu muss der Rennwagen beispielsweise sehrgute Fahreigenschaften hinsichtlich Beschleunigung, Bremskraft und Handling aufweisen.Der Monoposto soll wenig kosten, zuverlässig und einfach zu betreiben sein.

Beim Wettbewerb bewertet eine Jury aus Experten der Motorsport-, Automobil- und Zuliefer-industrie jede Konstruktion, jeden Kostenplan und jede Verkaufspräsentation im Vergleich zu

1http://www.formulastudent.de/

http://www.formulastudent.de/

1. Einleitung 11

den konkurrierenden Teams. Zum Anderen beweisen die Studenten auf der Rennstrecke inverschiedenen Disziplinen, wie sich ihre selbst gebauten Boliden in der Praxis bewähren.

1.1.2. HAWKS Racing

HAWKS Racing2 ist ein Team aus Studenten der HAW Hamburg, das einen Rennwagen fürWettbewerbe der Formula Student entwirft und baut. Dieses Team hat mittlerweile 2 Boliden(HAWK69, HAWK06) entworfen. Im Februar 2007 hat sich das Team an das DepartmentInformatik gewendet um beim Bau des aktuellen HAWK07 zu helfen. Das Team bestehtzum aktuellen Zeitpunkt aus ungefähr 40 Studenten die aus verschiedenen Fachbereichenkommen.

1.2. Zielsetzung

Diese Bachelorarbeit beschäftigt sich mit der Entwicklung eines Telemetriesystems für denRennwagen des HAWKS Racing Teams. Das Ziel ist es, mit den gegebenen Anforderungeneine Systemarchitektur zu entwerfen, Kommunikation zwischen den Komponenten zu er-möglichen, ein Datenübertragungsmodul und ein Datenspeicherungsmodul zu entwickeln.

Die Architektur soll den Aufbau des Telemetriesystems beschreiben und wird auf einer hohenAbstraktionsebene zusammen mit der Arbeit von Schuckert (2007) erstellt. Darauf basierendwerden in beiden Arbeiten Teile des Systems entwickelt, so dass es ein komplettes Teleme-triesystem mit Grundfunktionalitäten ergibt.

Die Kommunikation zwischen den einzelnen Komponenten im Rennwagen ermöglicht dasEinsetzen eines CAN-Busses (Controller Area Network) (Etschberger, 2002). In diesem Sys-tem soll die Kommunikation softwarebasierend zeitgesteuert ablaufen, da nur so genaueAussagen über Latenzzeiten und maximale Datenlasten gemacht werden können. Für die-ses spezielle Bussystem, welches auch Time-Triggered-CAN (TTCAN) genannt wird, ist esnotwendig ein Protokoll zu designen, welches das Nachrichtenformat, den Inhalt, die Bedeu-tung und die Reihenfolge gesendeter Nachrichten festlegt. Eine Software-Bibliothek, die dasSenden und Empfangen mit der benutzten Hardware vereinfacht, ist ebenfalls zu program-mieren, weil Studenten mit weniger Erfahrung dieses System weiterentwickeln sollen.

Das Datenübertragungsmodul, welches in dieser Arbeit Communicator genannt wird, reali-siert die kabellose Kommunikation zwischen dem Telemetriesystem im Rennwagen und demLeitstand wie in der Abbildung 1.1 dargestellt. Der Communicator wird in das Telemetriesys-tem integriert und benutzt für die kabellose Verbindung zum Leitstand den von der Firma

2http://www.hawksracing.de/

http://www.hawksracing.de/

1. Einleitung 12

LeitstandRennwagen

Wireless LAN

Abbildung 1.1.: Kommunikation zwischen Rennwagen und Leitstand

Lantronix3 entwickelten WiPort. Der WiPort ist für eingebettete Systeme (Scholz, 2005) undbietet eine Wireless LAN (Rech, 2006) Übertragungstechnologie. Diese Übertragungsmög-lichkeit besitzt die Funktionalität Daten während der Fahrt live auszuwerten.

Eine Software, die am Leitstand eingesetzt wird, soll mit dem im Rennwagen befindlichenCommunicator kommunizieren. Telemetriedaten werden von der Software aufgenommenund für die weitere Verarbeitung bzw. Darstellung aufbereitet. Auch die Konfiguration undSteuerung einzelner Module, wie z.B. das Einstellen der Systemuhrzeit oder das Steuernder Aufzeichnung beim Datenspeicherungsmodul, soll über diese Software möglich sein.Die aufbereiteten Daten werden von der Software live über das Netzwerk an andere Anwen-dungen wie z.B. LabVIEW4 gesendet.

Die Datenspeicherung wird durch den Datalogger ermöglicht und soll dazu dienen alle vonden Sensoren ermittelten Daten innerhalb des Rennwagens zu speichern. Speicherkartenwie die SD (Secure Digital) Memory Cards sind optimal für das Telemetriesystem, weil sieerschütterungsunempfindlich sind, ausreichende Kapazität bieten und von einem Mikrocon-troller angesteuert werden können. Diese Komponente ist notwendig, da die Reichweite vonWLAN eingeschränkt ist und es zu Verbindungsstörungen kommen kann und so der Da-tenverlust durch direkten Anschluss an das System im Rennwagen ausgeschlossen wird.Die aufgezeichneten Daten können später mit einer Anwendungssoftware ausgewertet wer-den.

In der Tabelle 1.1 ist noch einmal eine Übersicht über die in diesem Kapitel besprochenenZiele dargestellt.

3Firma die sich auf Netzwerkprodukte spezialisiert hat.http://www.lantronix.com/

4Graphisches Programmiersystem von National Instruments welches sich mit der Mess- und Automatisie-rungstechnik befasst.http://www.ni.com/labview/

http://www.lantronix.com/

http://www.ni.com/labview/

1. Einleitung 13

Bereiche ZieleTelemetriesystem SystemarchitekturCAN-Bus Protokoll

Software-BibliothekCommunicator Hardware

ModulsoftwareLeitstandsoftware

Datalogger HardwareModulsoftware

Tabelle 1.1.: Übersicht der Ziele

1.3. Telemetrie im Rennwagen - Stand der Technik

Die Überwachung und Kommunikation mit einem Rennwagen (Telemetrie) ist in den letztenJahren zur wichtigsten Technologie während des Rennens geworden. Sensoren im Rennwa-gen senden zu Überwachungs- und Analysezwecken ständig Daten an den Leitstand. “OhneTelemetrie würden wir erst gar nicht am Rennen teilnehmen”, beteuerte Gundel (TechnischerDirektor des Ferrari F1 Teams) in einem Bericht für Tom’s Hardware5.

Abbildung 1.2.: Leitstand von Ferrari für zwei Rennwagen[Tom’s Hardware, http://www.tomshardware.com/]

Der Aufwand für die Telemetrie ist in der Formel 1 enorm. Zum Beispiel hat das SauberTeam 2005 für seine zwei Boliden jeweils 17 Sensoren, 5 Ingenieure und 20 Computer fürdie Überwachung und Analyse der Rennwagendaten eingesetzt. Ferrari kann auf 150 Sen-soren, 10 bis 15 Ingenieure und 30 Telemetrie-Computer (Abb. 1.2) für zwei Rennwagenzurückgreifen.

5http://www.tomshardware.com/

http://www.tomshardware.com/

http://www.tomshardware.com/

1. Einleitung 14

Die Vielzahl der Sensoren und deren Einsatzgebiete sind groß. So können z.B. Sensoren,die an der Innenseite der Reifen befestigt werden, nicht nur Reifentemperatur und Luftdruckermitteln, sondern zusätzlich noch die Stärke des Reifenprofils und die Asphalttemperatur.Aber es gibt auch Sensoren die nach einem Unfall melden können, welche Teile beschädigtsind und eventuell beim nächsten Boxenstop gewechselt werden müssen.

Genaue Daten über die Telemetriesysteme in der Formel 1 sind nicht zu bekommen, weil dieeinzelnen Teams diese Informationen geheim halten. Es ist aber deutlich zu erkennen, dassdie Formel 1 ohne die Telemetrie nicht so ausgereifte Rennwagen auf die Strecke bringenwürde.

Abbildung 1.3.: MyChron 3 XG LOG[memotec, http://www.me-mo-tec.de/]

Für die Datenspeicherung und Visualisierung von Daten gibt es bereits bestehende Produktedie leicht einzusetzen und zu beschaffen sind. So setzt z.B. das HAWKS Racing Team fürden HAWK07, parallel zu der Entwicklung dieses Telemetriesystems, das MyChron 3 XGLOG6 (Abb. 1.3) ein. Es soll dem Fahrer die wichtigsten Daten anzeigen und kann gleichzeitignoch Daten von der Motorsteuerung oder den analogen Eingängen, die für verschiedeneSensoren genutzt werden können, aufzeichnen.

Jetzt kommt vielleicht die Frage auf, warum denn ein Telemetriesystem entwickeln wenn esfertige Produkte gibt. Diese Frage lässt sich leicht mit den Nachteilen von vielen kommerzi-ellen Produkten beantworten.

• Erweiterbarkeit:Viele Produkte wie das MyChron 3 XG LOG bieten ein begrenzte Anzahl von Eingän-gen um Sensoren anzuschließen.

6http://www.me-mo-tec.de/

http://www.me-mo-tec.de/

http://www.me-mo-tec.de/

1. Einleitung 15

• Angewiesen auf Hersteller:Wenn sich Protokolle z.B. einer Motorsteuerung ändern und es nicht von dem Produktunterstützt wird, ist es nötig, dass der Hersteller dieses implementiert und mit einerneuen Softwareversion ausliefert, da sonst das Produkt eingeschränkt oder nicht mehrnutzbar ist.

• Datennutzung:Bei vielen dieser Produkte ist es nicht mehr möglich, an die Daten für z.B. selbstentwickelte Software zu gelangen. Die Hersteller liefern mit ihrem Produkt oft eineeigene Software mit, die die Daten auswertet und geben kein offenes Datenformatfrei. Auch wenn Sensoren bereits integriert sind ist es meist nicht möglich diese Datenfür eigene Komponenten zu verwenden.

• Nutzung von Bussystemen:Sensoren können oft nur direkt an eine Box angeschlossen werden, was den Aufwandder Verkabelung deutlich erhöht und durch ein Bussystem einfacher zu realisierenwäre.

Diese Nachteile sind die Gründe für das HAWKS Racing Team ein eigenes Telemetriesystemeinzusetzen, welches die speziellen Anforderungen erfüllt.

2. Analyse

In diesem Kapitel wird die Umgebung beschrieben in der das Telemetriesystem eingesetztwird, welche Anforderungen an das System gestellt werden und einige Randbedingungen,die in der Entwicklung beachtet werden müssen. Hier werden nur die Anforderungen be-schrieben, die zur Umsetzung der Ziele aus Kapitel 1.2 notwendig sind. Die Anforderungen,die das ganze Telemetriesystem umfassen, sind dem Lastenheft von Haase und Schuckert(2007) zu entnehmen.

2.1. Systemumgebung

Das Telemetriesystem wird in einem Rennwagen eingesetzt und muss daher auch die spezi-ellen Anforderungen einhalten. Das betrifft z.B. die große Anzahl der Erschütterungen, even-tuelle Chemikalien oder Spritzwasser sowie wechselnde Temperaturbelastungen, denen dasSystem ausgesetzt ist.

Die Hardware des HAWKS Racing Teams für z.B. die Datenauswertung ist sehr heterogen.Deshalb muss bei der Programmierung von Software darauf geachtet werden, wo die Soft-ware eingesetzt wird.

2.2. Anforderungen

Das zu erstellende Telemetriesystem soll funktionale und nicht-funktionale Anforderungenerfüllen. Diese Anforderungen sind von dem HAWKS Racing Team gestellt worden.

2.2.1. Funktionale Anforderungen

Datenübertragung

• Einsatz eines Feldbusses innerhalb des Rennwagens.

2. Analyse 17

• Vom Rennwagen soll eine Funkverbindung die Daten zum Leitstand übertragen.

Datenspeicherung

• Alle Daten von den Sensoren sollen für eine spätere Auswertung gespeichert werden.

Sensoren und Steuergeräte

Die Anzahl der Sensoren und Steuergeräte die das Telemetriesystem unterstützen soll, ver-deutlicht die folgende Aufzählung.

Sensoren:

• 4x Raddrehzahl

• Lenkwinkel

• 4x Federweg

• 3 Achsen Beschleunigung

• 3 Achsen Drehraten

• Pedalwinkel Kupplung, Bremse u. Gas

• 4x Reifendruck

• 4x Reifentemperatur

• Bremsdruck

• Benzindruck

• Gangposition

• Dehnungsmessstreifen

• Laptrigger

Steuergeräte:

• Motorsteuerung

• Gangschaltung

• Lüftersteuerung

• Benzinpumpe

2. Analyse 18

Nicht alle Sensoren und Steuergeräte werden in dem HAWK07 verbaut, aber das Systemsoll die große Anzahl an Daten verarbeiten können, um es in den Nachfolgern des HAWK07weiterhin einsetzen zu können.

Frequenzen der Datenerfassung von Sensoren und Steuergeräten

Damit das System designed werden kann, mussten einzelne Baugruppenleiter des HAWKSRacing Teams angeben, wie oft sie ihre Daten von den Sensoren oder Steuergeräten erhal-ten möchten.

Die Tabelle 2.1 zeigt die verschiedenen Sollfrequenzen, die erfüllt werden sollen. Es konntennicht alle Sollfrequenzen angegeben werden, weil diese Erfahrungen im Team nicht für alleSensoren und Geräte vorhanden sind. Werte der Motorsteuerung, die mit einer Frequenzvon 0 angegeben wurden, sind hier entfernt worden, da sie für die Baugruppe Motor nichtrelevant sind.

2.2.2. Nicht-Funktionale Anforderungen

Performance

Die Hard- und Software einer technischen Lösung ist so auszulegen, dass die Daten pro-blemlos bearbeitet werden können, ohne dass inakzeptable Verhaltensweisen entstehen.

• Das Bussystem muss so schnell sein, dass alle Daten zuverlässig beim Empfängerempfangen werden.

• Das entstehende Datenvolumen muss ohne Verlust gespeichert werden.

• Die Visualisierung von Sensorwerten muss das entstehende Datenvolumen verarbei-ten können.

Eigenschaften des Telemetriesystems

• Die Bedienung sollte möglichst einfach und übersichtlich gehalten werden. AndereStudenten des Teams, die bei der Entwicklung nicht beteiligt waren, sollen für sichrelevante Information abrufen und auswerten können.

• Studenten der Technischen Informatik, die sich mindestens im 3. Semester befinden,sollte es möglich sein dieses Telemetriesystem weiterentwickeln zu können um z.B.neue Sensordaten zu erfassen.

2. Analyse 19

Typ Sensor / Wert Sollfrequenz (Werte/s)Motorsteuerung EngineRoundCounter 5

MAP 5Phase1 5TAir 5TPS 25RPM 25Klambda1 25Inj1, Inj2, Inj3, Inj4 25Spark1, Spark2, Spark3, Spark4 25Lambda 25VBatt 5DFarf 25TEngine 5LambdaTarget 5Speed 2Gear 2Active Block 1

Sensoren 4 x Raddrehzahl 25Lenkwinkel 254 x Federweg 1003 Achsen Beschleunigung 253 Achsen Drehraten 25Pedalwinkel Kupplung, Bremse u. Gas 254 x Reifendruck 54 x Reifentemperatur 5Bremsdruck 25Benzindruck 25

Tabelle 2.1.: Sollfrequenzen der Sensoren und Steuergeräte

Eigenschaften von Komponenten

• Komponenten, die konstruiert und gebaut werden, um anschließend im Rennwageneingesetzt zu werden, sollten möglichst klein und leicht sein.

• Sie müssen wasser-, schmutz und erschütterungsunempfindlich sein.

2. Analyse 20

2.3. Randbedingungen dieser Arbeit

Diese Arbeit wird unter den folgenden Randbedingungen durchgeführt.

MitwirkendeBei der Entwicklung und Realisierung des Telemetriesystems sind mehrere Studenten derTechnischen Informatik und des HAWKS Racing Teams beteiligt.

Damit das Telemetriesystem seine Grundfunktionen erhält, werden in der Arbeit von Schu-ckert (2007) parallel zu dieser Arbeit die restlichen Komponenten erstellt. Auch Sensoren(Lenkwinkel und Raddrehzahlen) werden durch seine Arbeit in das System integriert.

Studenten der Technischen Informatik ab dem 4. Semester helfen bei der Entwicklung ver-schiedener Sensoren und Steuergeräte, verwalten das Versions- und Wissensmanagementund erfüllen auch kleine Aufgaben wie z.B. das Schreiben von Konvertern, damit Daten inverschiedene Formate umgewandelt werden können.

Beteiligte des HAWKS Racing Teams haben eine beratende und helfende Funktion. Sie stel-len die Anforderungen und haben Fachwissen über den Aufbau des Rennwagens sowie denmomentanen technologischen Zustand. Es muss eine Kommunikation zwischen den ver-schiedenen Leitern des Teams entstehen, damit das Telemetriesystem im HAWK07 realisiertwerden kann.

LebenszyklusDie Formula Student fordert, dass jedes Jahr ein neuer Rennwagen gebaut wird odermehrere signifikante Veränderungen am bestehenden Rennwagen umgesetzt werden. DasHAWKS Racing Team hat für den Wettbewerb immer einen neuen Boliden entworfen undgebaut, da die Anzahl der Verbesserungen sonst nicht zu realisieren war. Unter diesen Vor-aussetzungen ist davon auszugehen, dass jedes Jahr ein neuer Rennwagen entsteht.

Abhängigkeit des Telemetriesystems für den RennwagenFehler, die im Telemetriesystem entstehen dürfen den HAWK07 nicht am Fahren hindern.Wenn das System zuverlässig funktioniert und ausreichende Tests erfolgt sind, ist es mög-lich, dass in den nachfolgenden Rennwagen erste Steuerungsaufgaben von den Sensorda-ten des Systems mit übernommen werden.

TestumgebungWeil der HAWK07 parallel zum Telemetriesystem entwickelt wird, ist es erst kurz vor demWettbewerb möglich, das System im Rennwagen zu testen. Erste Tests können an demVorjahreswagen, der HAWK06, durchgeführt werden, was aber aufgrund der nicht vorhandenSensoren schwer umzusetzen ist.

2. Analyse 21

Beim Testen ist zu beachten, dass das Fahrzeug in den räumlichen Gegebenheiten der HAWHamburg nicht fahren kann und daher mit Kostenaufwand zu einem Platz transportiert wer-den muss, der ausreichend groß und sicher ist. Tests, die ein Fahren des Wagens nichtvoraussetzen, sind nach Absprache mit der Werkstatt im Fachbereich Fahrzeugtechnik mög-lich.

EntwicklungszeitDie Entwicklungszeit des HAWK07 begann im Oktober 2006 und endet mit dem ersten Wett-bewerb, der im August 2007 stattfindet. Innerhalb dieser Zeit muss der Rennwagen entwor-fen, gebaut und getestet werden. Da sich das HAWKS Racing Team erst im Februar 2007an das Department Informatik gewendet hat um ein Telemetriesystem zu entwerfen, ist dieEntwicklungszeit für dieses System auf 6 Monate festgelegt.

3. Grundlagen

Dieses Kapitel enthält einige Grundlagen zum besseren Verständnis der benutzten Techno-logien in dieser Arbeit. Diese Grundlagen beziehen sich teilweise auf die verwendete Hard-ware und können von Hardware zu Hardware variieren. Ist dieses Grundlagenwissen bereitsvorhanden, kann man zum Kapitel Design und Realisierung übergehen.

3.1. CAN Bus

Der CAN-Bus (Controller Area Network) gehört zu den Feldbussen und wurde von Bosch inden 80er Jahren entwickelt. Derzeit ist es das am häufigsten eingesetzte Kfz-Bussystem fürLow-Speed- und High-Speed-Anwendungen.

3.1.1. Nachrichtenstruktur

Die CAN-Spezifikation beschreibt vier verschiedene CAN-Frames mit unterschiedlichenFunktionen:

• Data-Frames (Transport von Daten bis zu 8 Byte)

• Remote-Frames (Anforderung eines Data-Frames von einem anderen Teilnehmer)

• Error-Frames (signalisiert allen Teilnehmern einen Fehler in der Übertragung)

• Overload-Frames (Zwangspause zwischen Data- und Remote-Frames)

Data- und Remote-Frames bestehen aus einer seriell auf den Bus geschalteten Folge vonBits, denen sieben Felder1 bei Data-Frames und sechs Felder bei Remote-Frames zugeord-net werden. Die Abbildungen 3.1 und 3.2 zeigen jeweils die Frames mit dem Unterschied,dass sie einmal eine 11 Bit Identifizierungsnummer2 (CAN 2.0A) und 29 Bit Identifizierungs-nummer + 2 Bit (CAN 2.0B) haben.

1engl.: fields2engl.: identifier

3. Grundlagen 23

Abbildung 3.1.: CAN Standard Frames nach der CAN 2.0A Spezifikation[Atmel (2006), S.233]

Abbildung 3.2.: CAN Extended Frames nach der CAN 2.0B Spezifikation[Atmel (2006), S.234]

• SOF (Start of Frame)SOF besteht aus einem einzelnen Bit, das den Beginn eines Frames signalisiert undder Synchronisation der Steuergeräte über die fallende Flanke dient.

• Arbitration FieldEs besteht aus der Identifizierungsnummer und einem zusätzlichen Kontroll-Bit (RTRbei Standard-Frames bzw. SRR bei Extended-Frames). Neben der logischen Adres-sierung des Inhalts dient die Identifizierungsnummer der bitweisen Arbitrierung nachCSMA/CA3.

Das RTR-Bit (Remote Transmission Request) legt fest, ob es sich um einen Data-Frame oder einen Remote-Frame handelt. Im Extended-Format (CAN 2.0B) wird dieBezeichnung RTR-Bit durch SRR-Bit (Substitute Remote Request Bit) ersetzt.

• Control FieldDas Control Field ist 6 Bit lang. Das erste Bit ist das IDE-Bit (Identifier Extension Bit).Es legt fest, ob es sich um einen Standard Frame (CAN 2.0A) oder einem ExtendedFrame (CAN 2.0B) handelt. Das Bit r0 ist für zukünftige Erweiterungen reserviert.

3Collision Detection with non-destructive Bit Arbitration

3. Grundlagen 24

• Data FieldDas Data Field beinhaltet die Nutzdaten der Botschaft und kann 0 bis 8 Byte lang sein.Nur bei Data-Frames ist dieses Feld enthalten.

• CRC FieldDas CRC Field (Cyclic Redundancy Field) ist 16 Byte lang und wird beim CAN-Buszur Fehlererkennung verwendet.

• ACK FieldDas 2 Bit lange ACK Field (Acknowledge Field) dient zum Bestätigen der Nachrichtvon einem Teilnehmer des CAN-Busses.

• End of FrameEnd of Frame sind 7 aufeinanderfolgende Bits die das Ende der Botschaft markieren.

Interframe Space gehört nicht zum CAN-Frame. Er ist 3 Bit lang und trennt einzelne CAN-Nachrichten voneinander.

(vgl. [Marscholik und Subke (2007)], S.44f)

Länge eines Frames

Neben der harten Synchronisation über das Start-Bit muss sich jeder CAN-Knoten für dieDauer einer CAN-Nachricht resynchronisieren. Diese Resynchronisierung erfolgt durch Si-gnalwechsel von high auf low oder umgedreht. Erfolgt dieser Signalwechsel nicht innerhalbvon 5 Bits wird ein zusätzliches Bit (Stuff-Bit) eingefügt. Dadurch ist die Anzahl der Bits, diemit einer Botschaft übertragen werden muss, je nach Inhalt unterschiedlich. Die Tabelle 3.1zeigt die minimale und maximale Anzahl der Bits, die übertragen werden müssen.

Art des Frames Anzahl der BitsStandard Frame Extended Frame

minimal maximal minimal maximalData-Frames (8 Byte Daten) 111 130 131 154Remote-Frames 47 53 67 77

Tabelle 3.1.: Anzahl der Bits eines CAN-Frames

3. Grundlagen 25

3.1.2. Baudrate

Die Baudrate ist eine physikalische Größe, welche die Taktgeschwindigkeit einer Datenüber-tragung als Datenrate beschreibt. Im Automobilbereich werden High-Speed-CAN-Busse mitBitraten von 250kbit/s und 500kbit/s eingesetzt. Low-Speed-CAN wird in europäischen Kfzin der Regel mit 125kbit/s eingesetzt. (vgl. [Zimmermann und Schmidgall (2006)], S.34)

Datenübertragungszeiten

Frame-Typ Baudrate Übertragungszeit eines FramesStandard Frame Extended Frame

minimal maximal minimal maximalData-Frame (8 Byte Daten) 125kbit/s 888µs 1040µs 1048µs 1232µs

250kbit/s 444µs 520µs 524µs 616µs500kbit/s 222µs 260µs 262µs 308µs

Remote-Frame 125kbit/s 376µs 424µs 536µs 616µs250kbit/s 188µs 212µs 268µs 308µs500kbit/s 94µs 106µs 134µs 154µs

Tabelle 3.2.: Zeiten für die Übertragung eines CAN-Frames

Die Tabelle 3.2 zeigt Zeiten für die Übertragung eines Frames. Diese berechnet sich aus derAnzahl der Bits eines Frames (siehe Tab. 3.1) und der Baudrate.

3.1.3. TTCAN

Da in CAN-Netzwerken Nachrichten normalerweise ereignisgesteuert übertragen werden,können Belastungsspitzen auf dem Bus auftreten, wenn mehrere Nachrichten gleichzeitigübertragen werden sollen. Aufgrund des CSMA/CA-Verfahrens kann nur für die Botschaftmit der höchsten Priorität und unter bestimmten weiteren Voraussetzungen, z.B. bekanntenmaximalen Wiederholraten für diese Botschaft, die maximale Latenzzeit garantiert werden,innerhalb der die Botschaft auch im ungünstigen Fall noch sicher übertragen werden kann.

Um ein streng deterministisches Übertragungsverhalten zu garantieren, muss ein synchroni-sierter Buszugriff erfolgen, bei dem vorgegeben ist, welcher Teilnehmer in welchem Zeitfens-ter auf den Bus zugreifen darf (Time Division Multiple Access TDMA). Hier ist die Erweite-rung des CAN-Protokolls um ein übergeordnetes zeitgesteuertes Protokoll (“Time-TriggeredCAN”, TTCAN) spezifiziert.

3. Grundlagen 26

Zeitfenster, Basis- und Matrixzyklus

“Referenz-Nachrichten”, die vom sog. “Time Master” gesendet werden sorgen für die zeit-gesteuerte, zyklische Kommunikation des TTCAN. Jeder Zyklus, der mit einer Referenz-Nachricht beginnt ist ein Basiszyklus und ist in mehrere Zeitfenster unterteilt. Der Startpunkteines Zeitfensters ist durch eine Zeitmarkierung festgelegt. Es werden drei Arten von Zeit-fenstern unterschieden:

• Exklusive ZeitfensterIn Exklusiven Zeitfenstern werden Nachrichten übertragen, die ohne Konkurrenz aufdem CAN-Bus sind.

• Arbitrierende ZeitfensterArbitrierende Zeitfenstern werden ereignisgesteuerten Nachrichten zugewiesen. Meh-rere Teilnehmer können sich ein solches Zeitfenster teilen, wobei in diesen ZeitfensternBuskonflikte durch Priorisierung gelöst werden. Konnte ein Teilnehmer durch einenKonflikt nicht senden darf er es in diesem Zeitfenster nicht erneut versuchen.

• Freies ZeitfensterDie freien Zeitfenster sind für nachträgliche Erweiterungen reserviert.

R R R........ ........................ ........

Referenz-nachricht ........

Zeitfenster 1 Zeitfenster 2 Zeitfenster 3

Basiszyklus

Matrixzyklus

Basiszyklus 1 ................... Basiszyklus N

Abbildung 3.3.: Aufbau eines TTCAN Matrixzyklus aus Basiszyklen, die mehrere Zeitfensterenthalten

Die Abbildung 3.3 zeigt den grundsätzlichen Aufbau eines Basiszyklus. Da ein Basiszyklusnicht genügend Flexibilität bietet werden mehrere Basiszyklen zu einem Matrixzyklus zusam-mengefasst.

Jeder Basiszyklus des Matrixzyklus besteht aus der selben Folge von Zeitfenstern und be-ginnt jeweils mit der Referenz-Nachricht, was in der Abbildung 3.4 dargestellt ist.

(vgl. [Etschberger (2002)], S.443f)

3. Grundlagen 27

Referenz-nachricht

NachrichtA

NachrichtB ArbitrierungBasiszyklus 1

Basiszyklus 2

Basiszyklus N

Referenz-nachricht

Referenz-nachricht

NachrichtA

NachrichtA

NachrichtR

NachrichtU Arbitrierung

NachrichtM

Frei

NachrichtS

Frei

Abbildung 3.4.: Aufbau eines TTCAN Matrixzyklus (Systemmatrix)

3.2. SPI

SPI (Serial Peripheral Interface) ist ein von Motorola entwickeltes Bus-System mit einem sehrlockeren Standard für einen synchronen seriellen Datenbus, mit dem digitale Schaltkreisenach dem Master-Slave-Prinzip miteinander verbunden werden können.

3.2.1. Eigenschaften

• 3 gemeinsame Leitungen an denen jeder Teilnehmer angeschlossen ist:

MOSI (Master out Slave in)MISO (Master in Slave out)SCK (Serial Clock)

• 1 separate SS (Slave Select) Leitung für jeden Slave. Bei manchen Anwendungenteilen sich mehrere Slaves eine SS Leitung

• Full duplex

• keine Adressierung (erfolgt über Slave Select Leitung)

• Taktfrequenzen bis in den MHz-Bereich zulässig

3.2.2. Master-Slave-Prinzip

In der Abbildung 3.5 ist eine Verbindung zwischen dem Master und einem Slave dargestellt.Der Master gibt über die SCK Leitung (beim Master intern) den Takt für die Register vor.Da der Takt für alle Beteiligten aus einer Quelle kommt, ist der Datentransfer synchron zurTaktflanke. Dabei ist der maximal zulässige Takt zu beachten, weil dieser von Hardware zu

3. Grundlagen 28

8 BIT SHIFT REGISTER

SPI CLOCK GENERATOR

SHIFT ENABLE PORTS

MASTER

8 BIT SHIFT REGISTER

SLAVE

MISO

MOSI

SCK

SS

MSB MSBLSB LSB

Abbildung 3.5.: Master-Slave Verbindung

Hardware unterschiedlich sein kann. Mit der SS Leitung signalisiert der Master dem Slave-Register, dass es die Datenbits schieben soll.

3.3. FAT-Dateisystem

FAT ist abgekürzt und heißt File Allocation Table, was auf Deutsch so viel wie Dateizuord-nungstabelle bedeutet. Diese Tabelle befindet sich in den ersten Sektoren einer Harddisk(hinter dem sogenannten Boot-Loader) und enthält Informationen zum Auffinden der Datei-en. Aus Gründen der Sicherheit ist die FAT noch ein zweites Mal auf der Festplatte abgelegt.So kann sie im Falle einer Beschädigung wiederhergestellt werden. Bis heute existierenmehrere Versionen dieser Tabelle, wovon im Folgenden drei vorgestellt werden.

• FAT12FAT12 wird nur auf Datenträgern bzw. Partitionen bis zu einer Größe von 16MB einge-setzt und es ist bis heute auf fast allen FAT-formatierten 3,5”-Disketten im Einsatz.

Merkmale:

– Es werden nur Dateinamen im Schema 8.3 (acht Zeichen für den Dateinamenund drei Zeichen für die Dateinamenserweiterung) unterstützt.

– Es können 212 = 4096 Cluster angesprochen werden

– Die Clustergröße beträgt 512 Byte bis 4096 Byte.

– Unterstützt die Dateiattribute “Schreibgeschützt”, “Versteckt”, “System” und “Ar-chiv”

– Es werden keine Berechtigungen für Dateien oder Ordner unterstützt.

– Maximal 224 Einträge im Hauptverzeichnis (Root-Directory).

3. Grundlagen 29

• FAT16Durch die zunehmende Größe der eingesetzten Festplatten wurde eine Erweiterungdes Adressraumes notwendig. Mit FAT16 können Partitionen bis zu einer Größe von 4GB eingesetzt werden.

Merkmale:

– 8.3-Dateinamenformat.

– Es können 216 − 12 = 65.524 Cluster angesprochen werden (12 Cluster reser-viert FAT16, deshalb nicht 65.536).

– 65.536 Einträge sind möglich, allerdings nur 512 im Rootverzeichnis.

– Dateien dürfen bis 2 GB groß werden.

– Die Cluster sind je nach Partitionsgröße zwischen 512 Byte und maximal 64 KBgroß.

• FAT32Das FAT32 Dateisystem kann durch seine 32 Bit Adressierung Partitionen bis zu einerGröße von 2 Terabyte zu unterstützen.

Merkmale:

– Lange Dateinamen werden durch die Unterstützung von VFAT möglich.

– Es können 232−4 = 268.435.456 Cluster angesprochen werden (−4 weil 4 Bitreserviert sind).

– Rootverzeichnis ist nicht eingeschränkt.

– Dateien dürfen max. bis zu 4 GB - 1 Byte (= 4.294.967.295 Bytes) groß werden.

– Ein Cluster entspricht je nach Partitionsgröße zwischen 512 Byte und 32KB.

(vgl. [Wikipedia (2007)])

3.4. Serielle Datenübertragung

Bei der seriellen Datenübertragung werden Bits hintereinander über ein bestimmtes Mediumübertragen.

3. Grundlagen 30

3.4.1. UART

Die Funktion einer UART (Asynchronous Receiver Transmitter) ist, einen seriellen digitalenDatenstrom mit einem fixen Rahmen aufzubauen, welcher aus einem Start-Bit, fünf bis maxi-mal neun Datenbits, einem optionalen Parity-Bit zur Erkennung von Übertragungsfehlern undeinem oder zwei Stopp-Bits besteht. Mit der UART können Daten gesendet und empfangenwerden.

Serial Frame

Abbildung 3.6.: Serieller Datenstrom der UART[Atmel (2006), S.180]

• IDLE (High Pegel): keine Daten auf dem Bus

• St (Startbit, Low Pegel): Beginn eines Datenstroms

• 0 bis 8 (Datenbits): Bits die Daten beinhalten, Bit 5 bis 8 ist optional

• P (Parity-Bit): Optionales Bit für die Erkennung von Übertragungsfehlern

• Sp1 (Erstes Stopbit, High Pegel): Kennzeichnet das Ende eines Frames

• Sp2 (Zweites Stopbit, High Pegel): Optionales Bit, welches zusätzlich das Ende kenn-zeichnet

3.4.2. RS232

RS232 benutzt für die Datenübertragung ein einfaches asynchrones serielles Verfahren. Indieser Arbeit nutzt die RS232 dafür den Datenstrom der UART eines Mikrocontrollers.

Seriell bedeutet, dass die einzelnen Bits des zu übertragenden Bytes nacheinander über ei-ne einzige Datenleitung geschoben werden. Asynchron heißt, dass es keine Taktleitung gibt,die dem Datenempfänger genau sagt, wann das nächste Bit auf der Datenleitung liegt. Soein Verfahren kann nur funktionieren, wenn Sender und Empfänger mit genau dem gleicheninternen Takt arbeiten, und wenn der Empfänger gesagt bekommt, wann genau das erste Bitanfängt (Synchronisation).

3. Grundlagen 31

Alle RS232-Leitungen (mit Ausnahme der Masseleitung) arbeiten mit den Spannungspegeln+12V (für eine logische ’0’) und -12V (für eine logische ’1’). Erlaubt sind Pegel im Bereichvon +5V bis +15V bzw. -5V bis -15V. Der Datenempfänger erwartet eine Spannung von über+3V für eine 0 und von unter -3V für eine 1. Für die Steuerleitungen (Handshake-Leitungen)bedeutet ON ein hoher Pegel von +5V bis +15V und OFF ein negativer Pegel von -5V bis-15V.

Um Daten minimalistisch von einer Datenquelle zu einem Datenempfänger zu übertragen,werden eigentlich nur 2 Drähte benötigt - eine Masseleitung und eine Datenleitung. Für einebidirektionale Verbindung reichen also 3 Leitungen.

Um zu vermeiden, dass der Sender Daten sendet, obwohl der Empfänger noch nicht bereitist, werden 2 bis 4 zusätzliche Handshakeleitungen benötigt, die hier nicht weiter beschrie-ben werden.

3.4.3. Baudrate

Die Baudrate ist eine physikalische Größe, welche die Taktgeschwindigkeit einer Datenüber-tragung als Datenrate beschreibt.

übliche BaudratenBaud Bitlänge

2400 417 µs4800 208 µs9600 104 µs

19200 52 µs38400 26 µs57600 17 µs

115200 8,68 µs230400 4,34 µs460800 2,17 µs921600 1,09 µs

Tabelle 3.3.: Übliche Baudraten für die serielle Datenübertragung

In der Tabelle 3.3 sind die üblichen Baudraten aufgelistet die z.B. von Mikrocontrollern un-terstützt werden.

3. Grundlagen 32

Berechnung der Baudrate

UBRRdesired value =fCLKio

16 · BAUDdesired value− 1 (3.1)

UBRRactual value = round(UBRRdesired value) (3.2)

BAUDactual value =fCLKio

16 · (UBRRactual value + 1)(3.3)

Die Baudrate lässt sich, wie die Gleichung 3.3 zeigt, aus dem Systemtakt (fCLKio) und demPrescaler (UBRRactual value) berechnen. Dabei ist zu beachten, dass der Prescaler keineFließkommazahl sein kann, weil es ein Registerwert ist und somit gerundet werden muss.

Fehlerberechnung

Error [%] = (1−Baudratedesired valueBaudrateactual value

) · 100 (3.4)

Durch die Rundung mit dem Wert vom Prescaler entsteht ein Fehler der sich mit der Glei-chung 3.4 berechnen lässt. Dieser Fehler darf einen bestimmten Wert nicht überschreiten.Bei dem Atmel4 AT90CAN128 Mikrocontroller liegt der maximale Fehler bei 2%.

(vgl. [Atmel (2006)], S.177f)

3.5. Rechnernetze

Rechnernetze ermöglichen die Kommunikation zwischen verschiedener technischer, primärselbständiger elektronischer Systeme. Dazu zählen hauptsächlich Computer aber auch Sen-soren, Aktoren und funktechnologische Komponenten. Die Kommunikation erfolgt über ver-schiedene Protokolle, die mittels des ISO/OSI-Modells strukturiert werden können.

4http://www.atmel.com/

http://www.atmel.com/

3. Grundlagen 33

3.5.1. Referenzmodelle

Die Kommunikation innerhalb eines Netzwerkes wird anhand eines Netzwerkmodells be-schrieben, wobei man sich das so genannte Open Systems Interconnection Referenzmodell(OSI Reference Model) zugrunde legt. Es ist in 7 Schichten unterteilt, die auch als Layerbezeichnet werden. Die Abbildung 3.7 zeigt das OSI-Referenzmodell und das direkt auf

7

6

Anwendung

Darstellung

5

4

3

2

1

Kommunikations-steuerung

Transport

Vermittlung

Sicherung

Bitübertragung

OSI-Schichten

Anwendung

Transport

Internet

Netzzugang

TCP/IP-Schichten

Abbildung 3.7.: OSI und TCP/IP Referenzmodell

die Internet-Protokolle zugeschnittene TCP/IP-Referenzmodell. Schichten stellen jeweils ih-re Dienste der darüber liegenden Schicht zur Verfügung und nutzen ihrerseits die Diensteder darunter liegenden Schicht. Die Kommunikation zwischen den Schichten erfolgt überdefinierte Schnittstellen. Mit jeder darüber liegenden Schicht werden die Funktionen bzw.Dienste der darunterliegenden Schicht erweitert.

3.5.2. TCP/IP-Referenzmodell

Wie schon beschrieben ist das TCP/IP-Referenzmodell auf die Internet-Protokolle zuge-schnitten. Es ermöglicht den Datenaustausch über Grenzen lokaler Netzwerke hinaus. Spe-zielle Protokolle sind dafür zuständig diese Kommunikation herzustellen.

Im Folgenden werden die 4 Schichten des Referenzmodells kurz beschrieben.

Netzzugangsschicht

Die Netzzugangsschicht beschreibt, wie die physikalische Datenübertragung erfolgt. Damitdie Kommunikation zwischen zwei Netzwerkknoten möglich ist, wird auf dieser untersten

3. Grundlagen 34

Schicht die Bitübertragung und die Transportsicherung zuverlässig zur Verfügung gestellt.Protokolle, die in dieser Schicht liegen, wären z.B. Ethernet oder WLAN.

Internetschicht

Sie sorgt für den eigentlichen Datentransfer zwischen den Computern, indem sie die Wegfin-dung (Routing) zwischen den Computern übernimmt. Die Internetschicht ermöglicht es überdie Grenzen zwei direkt verbundener Computer mit einem weiteren Computer zu kommuni-zieren. Dazu werden die Daten mit entsprechenden Ziel- und Quelladressen versehen, überdie das zielgerichtete Routing durchgeführt werden kann. IPv4 und IPv6 sind Protokolle, diein dieser Schicht liegen.

Transportschicht

Im Grunde tauschen zwei Programme untereinander Daten aus, wenn zwei Computer mit-einander kommunizieren. Die Transportschicht sorgt dafür, dass die Daten der Internet-schicht an die richtigen Programme auf dem Computer ausgeliefert werden. Die Transport-schicht stellt damit für die übergeordneten Instanzen einen transparenten Datenkanal zurVerfügung. Hier spielen die Protokolle TCP (verbindungorientierter, sicherer Transportdienst)und UDP (verbindungsloser Transportdienst) eine wichtige Rolle.

Anwendungsschicht

In der Anwendungsschicht sind alle Protokolle definiert, auf die alle Programme und Anwen-dungen direkt zugreifen.

(vgl. [Kersken (2004)], Kapitel 12.2)

3.5.3. Kommunikation

Die Kommunikation zwischen zwei Computern findet immer nur zwischen den Schichtender gleichen Ebene statt, was in der Abbildung 3.8 dargestellt ist. Dieses ist die virtuelleKommunikation und kann nur stattfinden wenn bei beiden Computern das gleiche Protokollgenutzt wird.

Tatsächlich verläuft die Kommunikation wie in der Abbildung 3.9 gezeigt. Die Daten bewe-gen sich dabei von dem einem Computer vertikal nach unten bis zur untersten Schicht, derNetzzugangsschicht. Auf der Netzzugangsschicht bewegen sich die Daten von einem zum

3. Grundlagen 35

Anwendung

Transport

Internet

Netzzugang

Sender

Anwendung

Transport

Internet

Netzzugang

Empfänger

Anwendungs-protokolle

TCP, UDP

IP (IPv4, IPv6)

WLAN

Abbildung 3.8.: Virtuelle Kommunikation zwischen einzelnen Schichten

Anwendung

Transport

Internet

Netzzugang

Sender

Anwendung

Transport

Internet

Netzzugang

Empfänger

phys. Medium

Abbildung 3.9.: Kommunikationswege innerhalb des Referenzmodells

anderen Computer über ein physikalisches Medium (Kabel, Funk). Auf dem empfangendenComputer laufen die Daten dann wieder vertikal nach oben in die einzelnen Schichten. Soerreichen die Daten einer Schicht die gleiche Schicht auf dem gegenüberliegenden Compu-ter.

(vgl. [Rech (2006)], S.35f)

3.5.4. Wireless LAN

Wireless Local Area Network bezeichnet ein “drahtloses", lokales Funknetz, wobei meistensein Standard der IEEE 802.11-Familie gemeint ist.

3. Grundlagen 36

IEEE 802.11

(Teil-)Standard Datenrate FrequenzbandIEEE 802.11 1 und 2 MBit/s InfrarotIEEE 802.11 1 und 2 MBit/s 2,4 GHzIEEE 802.11 1 und 2 MBit/s 2,4 GHzIEEE 802.11a 6, 9, 12, 18, 24, 36 und 54 MBit/s 5 GHzIEEE 802.11b 5,5 und 11 MBit/s 2,4 GHzIEEE 802.11g 6, 9, 12, 18, 24, 36 und 54 MBit/s 2,4 GHz

Tabelle 3.4.: Übersicht des 802.11-PHY-Layer

Die Tabelle 3.4 zeigt die technische Gegenüberstellung der auf der Schicht 1 des OSI-Referenzmodells bezogenen Implementierungen des Grundstandards und der Erweiterun-gen.

Standard BeschreibungIEEE 802.11d Länderspezifischer Informationsaustausch für internationales RoamingIEEE 802.11e MAC-Erweiterung für Quality of Service und PerformanceverbesserungIEEE 802.11f Definition des Inter Access Point Protocols (IAPP)IEEE 802.11i MAC-Erweiterung zur Verbesserung der DatensicherheitIEEE 802.11n Neuer MAC- und PHY-Layer für Datenraten von 108 bis 600 MBit/sIEEE 802.11p Optimierung für Datenaustausch auf FahrzeugenIEEE 802.11r Optimierung des Roaming (Fast Roaming)IEEE 802.11s Definition eines drahtlosen Mesh-Netzwerks

Tabelle 3.5.: 802.11-Arbeitsgruppen und Standarderweiterungen

Die Tabelle 3.5 zeigt die wichtigsten 802.11-Arbeitsgruppen und Standarderweiterungen.

(vgl. [Rech (2006)], S.5f)

Nachrichtenstruktur

Eine WLAN Nachricht nach dem IEEE802.11 Standard setzt sich wie in der Abbildung 3.10dargestellt zusammen. Hierbei ist zu beachten, dass der Ethernet Frame nicht wie im 802.3Standard eine maximale Größe von 1518 Byte haben kann sondern maximal 2304 Byte.Die Präambel benötigt 20µs und dient zum Synchronisieren des Empfängers. Es folgt der

3. Grundlagen 37

Prüfsumme

4 Byte

EthernetFrame

maximal 2304 Byte

SNAPIV802.11 HeaderPräambel

24 bis 32 Byte20µs 4 oder 8 Byte 8 Byte

Abbildung 3.10.: WLAN-Frame nach 802.11

802.11-Header mit bis zu 32 Byte. Der Sequenzzähler (IV) wird bei verschlüsselten Paketenbenötigt und beträgt 4 oder 8 Byte. Der SNAP-Header ist 8 Byte lang und wird benötigt umEthernet-Pakete über Nicht-Ethernet-Medien zu transportieren. Dann folgt der eigentlicheEthernet-Frame mit maximal 2304 Byte und die Prüfsumme der physikalischen Schicht mit4 Byte.

Betriebsarten

WLAN Netze können wahlweise in einem Ad-hoc Modus oder einem Infrastruktur Modusbetrieben werden.

• Ad-hoc-NetzwerkIm Ad-hoc-Modus kommunizieren die Stationen direkt miteinander. Vergleichen kannman diese Art der Verbindung mit einer Punkt-zu-Punkt-Verbindung, wobei aber einKnoten mehrere Verbindungen unterhalten kann. Es ist auch möglich, dass zwei Com-puter, die aufgrund der Reichweite nicht direkt miteinander kommunizieren können,diese Verbindung über einen dritten Knoten aufnehmen.

• Infrastruktur-NetzwerkIm Infrastructure Mode hingegen vermittelt eine spezielle Basisstation, Access Pointgenannt, zwischen den Clients. Dieser Access Point kann leicht zwischen drahtlo-sen (IEEE 802.11) und drahtgebundenen (802.3) Netzen vermitteln, weil WLAN inder Schicht 2 des OSI-Referenzmodell dasselbe Protokoll wie Ethernet verwendet. Miteinem Access Point kann die Reichweite zwischen zwei WLAN Endknoten verdoppeltwerden wenn er zentral zwischen den beiden aufgebaut wird.

Reichweite

Bei der Reichweitenbetrachtung hat die Umgebung den größten Einfluss und darauf folgenddie Datenrate. In der Tabelle 3.6 sind erzielbare Reichweiten im Verhältnis von Datenratezur Umgebung dargestellt. Die Umgebung wird hierbei in 3 Klassen eingeteilt. Befindet sichkein Hindernis zwischen dem Sender und dem Empfänger, so liegt eine flache und offeneUmgebung vor. Befinden sich hingegen Materialien mit geringer oder mittlerer Dämpfung

3. Grundlagen 38

Datenrate Reichweiten in Abhängigkeit von der UmgebungFlach und offen Halb offen Geschlossen

11MBit/s 160m 50m 25m5,5MBit/s 270m 70m 35m2MBit/s 400m 90m 40m1MBit/s 550m 115m 50m

Tabelle 3.6.: Richtwerte für erzielbare Reichweiten

zwischen Sender und Empfänger, wobei eine indirekte Ausbreitung des Signals über Refle-xionen gegeben ist, so spricht man von einer halb offenen Umgebung. Sind Materialien miteiner hohen Dämpfung zwischen Sender und Empfänger, liegt eine geschlossene Umge-bung vor. Die Tabelle 3.7 zeigt einige Dämpfungseigenschaften von Materialien.

Material DämpfungGips GeringHolz GeringGlas Gering

Mauersteine MittelWasser MittelBeton HochMetall Sehr hoch

Tabelle 3.7.: Dämpfungseigenschaften verschiedener Materialien

(vgl. [Rech (2006)], S.345f)

4. Design und Realisierung

4.1. Systemarchitektur

In diesem Kapitel wird zuerst beschrieben wie die Komponenten zueinander angeordnetsind. Zur Vereinheitlichung bei der Datenverarbeitung wird ein Datenformat festgelegt, wel-ches in dem Telemetriesystem verwendet wird. Des weiteren wird Hard- und Software vorge-stellt und welche Komponenten letztendlich in dieses Telemetriesystem integriert werden.

4.1.1. Design der Komponentenanordnung

Für den Aufbau des Telemetriesystems gibt es zwei verschiedene Ansätze, die im Folgendenverglichen werden.

Zentral

Sensormodul „x“

CAN-Bus

(optional)Steuerungsmodul „x“

Zentrale Hauptkomponente

Integrierte Funktionen:● Communicator● Datalogger● Time Master● Gateway● System Checker

Abbildung 4.1.: Zentrale Telemetriesystem-Architektur

4. Design und Realisierung 40

Ein Ansatz ist, eine zentrale Hauptkomponente in das System zu integrieren (Abb. 4.1),welches über ein Feldbus alle relevanten Informationen von einzelnen Sensormodulen emp-fängt, eine Wireless LAN Verbindung zum Leitstand bereitstellt (Communicator), Daten füreine spätere Auswertung speichert (Datalogger), Steuernachrichten versendet z.B. für denTTCAN (Time Master), eine Vermittlungsfunktion zu anderen Netzwerken mit unterschiedli-chen Protokollen ermöglicht (Gateway) und das System überprüfen kann, z.B. durch Emp-fang und Auswertung von Fehlernachrichten bzw. Statusnachrichten der einzelnen Module(System Checker). Diese Komponente würde mit einem eingebetteten Betriebssystem wiez.B. T2-Linux1 oder QNX2 ausgestattet werden, welche schon eine große Funktionalität mitsich bringen. Ein Vorteil wäre die Platzersparnis im Rennwagen, weil diese Komponenteviele Aufgaben des Systems übernehmen würde. Bei einer zentralen Komponente, wie siehier beschrieben ist, muss man beachten, dass das ganze System von dieser Komponen-te abhängt und bei einem Totalausfall das ganze Telemetriesystem ausfällt (Single Point ofFailure). Die Ausfallsicherheit könnte ein Replikat der Komponente verbessern, was aberaufgrund des höheren Platzbedarfs, der Gewichtserhöhung und der zu großen Kosten nichtmehr tragbar ist.

Modular

Sensormodul „x“

CAN-Bus

Gateway „x“(optional)Steuerungsmodul „x“ System Checker

TimeMaster „x“ Communicator Datalogger

Abbildung 4.2.: Modulare Telemetriesystem-Architektur

Der modulare Ansatz aus Abbildung 4.2 basiert ausschließlich auf Mikrocontroller. In diesemAnsatz wird die zentrale Komponente aus dem ersten Ansatz in einzelne Module aufgeteilt.Durch diesen Ansatz ist es möglich, die Module komplett unabhängig voneinander zu entwi-ckeln und auch Verbesserungen von einzelnen Modulen wie Hardware- oder Technologieän-

1http://www.t2-project.org/2http://www.qnx.com/products/neutrino_rtos/

http://www.t2-project.org/

http://www.qnx.com/products/neutrino_rtos/


derung sind einfacher zu realisieren. Es wäre z.B. denkbar, dass die Funkübertragung vonWLAN auf GPRS geändert werden soll. Wenn diese neue Technologie nicht von der Hard-ware unterstützt wird, ist es notwendig, die komplette zentrale Komponente durch andereHardware zu ersetzen und somit müssen auch Funktionalitäten, die diese Hardware bein-haltet, ersetzt und eventuell neu entwickelt werden. Bei einem modularen Ansatz ist diesdurch einfaches Austauschen des Moduls erreichbar.

Entscheidung der Systemarchitektur

Vorteile der zentralen Architektur:

• Großer Funktionsumfang durch das Betriebssystem

• Hohe Abstraktionsebene der Softwareentwicklung durch das Betriebssystem alsSchnittstelle zwischen Anwendung und Hardware

• Platzeinsparung

Vorteile der modularen Architektur:

• Module voneinander unabhängig entwickelbar

• Hardwareänderungen einfacher realisierbar

• Sicherheit vor Datenverlust durch Redundanz möglich und dadurch kein Single Pointof Failure im System

Die Entscheidung für das Telemetriesystem fiel auf den modularen Ansatz, da er bessereEntwicklungsmöglichkeiten bietet und die Sicherheit vor Datenverlust einfacher zu realisierenist, weil kein Single Point of Failure existiert.

Das System, so wie es in der Abbildung 4.2 dargestellt ist, besteht aus folgenden Modulen:

• CAN-Bus für die Datenübertragung zwischen den einzelnen Modulen im Rennwagen.

• Time Master sind für die zeitlichen Abhängigkeiten auf dem CAN-Bus verantwortlich.Durch redundante Time Master wird sichergestellt, dass bei Ausfall eines Time Mas-ters der TTCAN weiter funktioniert.

• Datalogger, der alle relevanten Daten aufzeichnet, damit sie später ausgewertet wer-den können.

• Communicator als Bindeglied zwischen dem System im Rennwagen und dem Leit-stand. Er ist ein besonderer Gateway, weil er die Kommunikation zwischen den CAN-Bus und Wireless LAN ermöglicht und somit Daten von den einzelnen Komponentenmit dem Leitstand ausgetauscht werden.


• Gateways die es ermöglichen verschiedene Netzwerke mit ihren Protokollen, mitein-ander kommunizieren zu lassen. Ein Beispiel für ein Gateway zeigt die Abbildung

CAN-Bus

Gateway „ECU“ Engine Control UnitRS232

Abbildung 4.3.: Beispiel für ein Gateway

4.3. Hier werden die Daten der Engine Control Unit (dt. Motorsteuerung), die nur dasRS232 Protokoll unterstützt, durch ein Gateway auf den CAN-Bus übertragen.

• System Checker, der den CAN-Bus mit seinen Module auf ihre Funktionsfähigkeitüberprüft und den Status visualisieren kann.

• Sensormodule, die einzelne Sensoren auswerten und die Daten aufbereitet über denCAN-Bus senden.

• Steuerungsmodule bieten die Möglichkeit aus verschiedenen Sensordaten Steuerauf-gaben, wie zum Beispiel eine Lüftersteuerung oder Traktionskontrolle, zu integrieren.

4.1.2. Datenformat

16 Byte Nachricht

identifier ide | length application data timestamprtr

Abbildung 4.4.: Datenformat

Die Transparenz zwischen den Komponenten wird erreicht, indem alle Komponenten dieCAN-Nachrichten in einem fest definierten Format über andere Netzwerke und Schnittstel-len senden und speichern, damit diese Nachrichten für die weitere Verarbeitung im ganzenSystem kompatibel zu den CAN-Nachrichten bleiben. Die Abbildung 4.4 zeigt die Struktureiner Nachricht wie sie für dieses System definiert ist. Entstanden ist sie im Wesentlichenaus der CAN-Bus Spezifikation, damit das Versenden über den Bus möglich wird.


Eine Nachricht ist 16 Bytes lang und besteht aus:

• 4 Byte Identifizierungsnummer

• 4 Bit für die Markierung einer erweiterten Identifizierungsnummer

• 4 Bit Längenangabe der Anwendungsdaten

• 8 Byte Anwendungsdaten

• 1 Byte das eine remote transfer message kennzeichnet

• 2 Byte Zeitstempel für den Empfang einer Nachricht

4.1.3. Auswahl der Hardware

Die folgende Hardware wird für das Telemetriesystem verwendet.

Mikrocontroller und Board

Für die Komponenten des Telemetriesystems im Rennwagen wird der AT90CAN128 Mikro-controller von Atmel verwendet. Die Ausstattung des Mikrocontrollers mit CAN-Bus, UARTund SPI Interface, vier Timer für zeitliche Abhängigkeiten sowie verschiedene Interruptbe-handlungen sind für das zu erstellende Telemetriesystem ausreichend. Dabei spielte dasschon durch das Studium erreichte Wissen über den AT90CAN128 eine große Rolle, weildie Leistung gut eingeschätzt werden kann und Erfahrung mit der Programmierung vorhan-den ist, was sich positiv auf die Entwicklungszeit auswirkt.

Abbildung 4.5.: Evaluation Board für AT90CAN128 Mikrocontroller


Damit der AT90CAN128 Mikrocontroller für die Entwicklung des Telemetriesystems einge-setzt werden kann, wird das Evaluation Board aus der Abbildung 4.5 eingesetzt. DiesesBoard ist an der Hochschule entwickelt und in verschiedenen Arbeiten und Praktika ausrei-chend getestet worden. Ein Schaltplan zu diesem Board befindet sich im Anhang C.

Router

Leitstand mit Router

WLAN

Abbildung 4.6.: Leitstand mit Router

Da integrierte Antennen in Notebooks nicht optimal für die Überbrückung weiter Streckensind, wird für den Leitstand zusätzlich ein Router von der Firma Linksys3 (WRT54GL) ver-wendet, was in der Abbildung 4.6 dargestellt ist. Dieser Router wurde gewählt, weil er güns-tig in der Anschaffung ist und mit einer alternativen Firmware (DD-WRT4) betrieben werdenkann. Mit der Firmware ist es möglich, die Leistung des Routers selbst zu konfigurieren, wassich positiv auf die Empfangsqualität auswirkt.

4.1.4. Software

Als Basissoftware für die Mikrocontroller kommt ein Echtzeitscheduler (Pont, 2001) zum Ein-satz. Dieser Scheduler wird in einer Bachelorarbeit von Schuckert (2007) parallel zu dieserArbeit für das Telemetriesystem entwickelt und ausführlich beschrieben.

Dieser Scheduler kann mehrere Tasks zu verschiedenen Zeiten ausführen und besitzt dieMöglichkeit eine Reguläre Task (RegTask) zu verwenden. Die RegTask kann eine normaleTask zu vorgegeben Zeiten in ihrer Ausführung unterbrechen, damit sie selbst ausgeführt

3http://www.linksys.com/4http://www.dd-wrt.com/

http://www.linksys.com/

http://www.dd-wrt.com/


Task1 Task2 Task3 Task1 Task2 Task3

0 10 20 30 40

Zeiteinheiten

normale Tasks

Abbildung 4.7.: Beispiel einer Taskeinteilung

wird. Die Abbildung 4.7 zeigt ein Beispiel in dem 3 normale Tasks ohne eine RegTask ver-wendet werden. Damit eine Task in dem Scheduler eingebunden werden kann müssen 3zeitliche Angaben erfolgen. Zum Beispiel Task 1 in der Abbildung 4.7, sie startet bei derZeiteinheit 1, dauert 3 Zeiteinheiten und wird alle 30 Zeiteinheiten wiederholt.

Bearbeitungszeit des Scheduler

Wichtig für das weitere Design ist die Bearbeitungszeit, die der Scheduler für die Verwaltungder einzelnen Tasks benötigt.

Anzahl der Task Kompiler-Optimierungsstufe Regtask max. Scheduler-Zeitdauer15 o0 nein 96µs

15 o1 nein 35µs

15 o2 nein 30µs

Tabelle 4.1.: Auszug der Zeitmessungen am Scheduler

Die Tabelle 4.1 zeigt den maximalen Zeitbedarf, die der Scheduler für seine Bearbeitung in-nerhalb einer Zeiteinheit braucht. Zusätzlich zum Zeitbedarf des Scheduler kommt die Zeit-dauer, die der Dispatcher benötigt, wenn eine Task beendet und eine neue gestartet wird.Der Zeitbedarf des Dispatcher ist rund 30µs . Alle hier genannten Zeiten sind durch Messun-gen entstanden.

TScheduler = NTaskzeiteinheiten · TSchedulerZeitdauer + TDispatcherZeitdauer (4.1)

Sind jetzt die Zeiteinheiten bekannt, die benötigt werden um eine Task auszuführen, kannmit der Gleichung 4.1 der gesamte Zeitbedarf des Scheduler bestimmt werden. Bei dieserRechnung muss beachtet werden, dass keine RegTask verwendet wird, da diese zusätzlichZeit beansprucht.


Eigenschaften des Echtzeitschedulers

• Keine oder eine RegTask

• Bearbeitungszeit des Scheduler und des Dispatcher muss berücksichtigt werden

• Eine Zeiteinheit ist 200µs

• Minimale Periodenzeit für eine RegTask ist 200µs

• Latenzzeit für externe Ereignisse ist maximal 200µs

4.1.5. Realisierung der Architektur

Sensor„Lenkwinkel“

CAN-Bus

Gateway „ECU“Sensoren„Raddrehzahl hinten“

Sensoren„Raddrehzahl vorne“

Time Master

System CheckerCommunicator Datalogger

Abbildung 4.8.: Realisierung der Telemetriesystem-Architektur im HAWK07

Wie die Abbildung 4.8 zeigt, sind 7 Komponenten bis zum ersten Wettbewerb im August2007 für den HAWK07 entstanden.

Somit besteht das Telemetriesystem aus:

• CAN-Bus für die Kommunikation zwischen den Komponenten

• Communicator für die kabellose Datenübertragung zum Leitstand

• Datalogger, um die Daten direkt vom CAN-Bus zu speichern

• Time Master für den TTCAN mit System Checker für die Überwachung der einzelnenKomponenten

• Lenkwinkelsensor, damit der Winkel des Lenkrades ermittelt wird

• Raddrehzahl vorne erfasst die Drehzahl der beiden Räder vorne


• Raddrehzahl hinten erfasst die Drehzahl der beiden Räder hinten

• ECU Gateway holt die Daten von der Motorsteuerung per RS232 und versendet dieseüber den CAN-Bus

Der Time Master mit System Checker, Lenkwinkelsensor und die beiden Raddrehzahlsen-soren sind auch in der Bachelorarbeit von Schuckert (2007) entwickelt worden. Der ECUGateway ist die erste Komponente, die erfolgreich von einem Student aus dem 4. Semesterentwickelt wurde und in das System integriert ist. Der CAN-Bus, Communicator und Data-logger werden in dieser Arbeit entwickelt und in den folgenden Kapiteln beschrieben.

4.2. CAN Bus

Für die Kommunikation zwischen den einzelnen Komponenten wird ein CAN-Bus eingesetzt.Der CAN-Bus ist für das Telemetriesystem, wie es gefordert wird, optimal weil:

• Verdrahtung weniger komplex

• Zusätzliche Komponenten integrierbar

• Ausreichende Geschwindigkeit für den Datentransfer

• Wissen durch das Studium vorhanden

4.2.1. Grundkonfiguration

Die CAN-Bus Grundkonfiguration sieht wie folgt aus:

• Geschwindigkeit: 500kbit/s

• Nachrichten-Identifizierung: 11-Bit-Identifier (CAN 2.0A)

Der CAN-Bus wird mit einer Geschwindigkeit von 500kbit/s betrieben, weil es für denAutomotiv-Sektor empfohlen wird. Das liegt an der Abhängigkeit von der Länge einer Stich-leitung vom Bus zum CAN-Teilnehmer und der Datenrate. Bei 500kbit/s sollte die Stichleitung30 cm nicht übersteigen (vgl. [Marscholik und Subke (2007)], S. 42). Für das erforderlicheDatenaufkommen im Telemetriesystem ist die Datenrate ausreichend. Die 11 Bit für die Iden-tifizierung einer Nachricht wird verwendet, weil diese eine ausreichende Anzahl an Adressenzur Verfügung stellt, um Nachrichten eindeutig zu identifizieren und eine Nachricht durch dieEinsparung von mindestens 20 Bit je Nachricht (siehe Kap. 3.1.1), die bei einem 29-Bit-Identifier hinzukommen würden, schneller über den Bus versendet werden kann.


4.2.2. Transport-Protokoll

Damit die einzelnen Komponenten miteinander Daten austauschen können ist es erfor-derlich ein Transport-Protokoll zu designen. Das Protokoll beinhaltet Regeln und Formate,die das Kommunikationsverhalten der einzelnen kommunizierenden Instanzen bestimmen.Wenn dieses Protokoll in das ISO-OSI-Schichtenmodell eingegliedert wird, dann ist es in derSchicht 4 - Transportschicht einzuordnen.

Hier wird nur das für diese Arbeit Notwendigste aus dem Protokoll beschrieben. Eine detail-lierte Beschreibung befindet sich in dem Dokument von Haase (2007).

11 Bit Identifizierung

10 9 8 7 6 5 4 3 2 1 0

Priorität Quelladresse

11bit Identifizierung

Abbildung 4.9.: 11 Bit Identifizierung

Die 11 Bit für die Identifizierung einer CAN-Nachricht bestehen, wie die Abbildung 4.9 zeigt,aus 3 Bit für die Priorität und 8 Bit für die Quelladresse.

Die 3 Bit für die Priorität ermöglichen es 8 verschiedene Prioritäten zu definieren. 0 ist diehöchste Priorität und 7 die niedrigste.

• 0 - Time Service: Nur für die Nachrichten vom Time Master.

• 1 - Service: Alle Steuernachrichten zum Konfigurieren der Komponenten.

• 2 - Device Error: Nachrichten, die einen Fehler für ein Gerät beschreiben.

• 3 - Program Error: Nachrichten, die einen Programmfehler beschreiben.

• 4 - Data 1: Nachrichten für Sensordaten.





256 verschiedene Quelladressen werden durch die 8 Bit in der 11 Bit Identifizierung möglich,wobei die Adressen 0x00 und 0xFF nicht als Quelladressen vergeben werden dürfen. DieAdresse 0xFF (dezimal 255) ist die Broadcast-Adresse und die Adresse 0x00 darf nicht alsQuelladresse verwendet werden, weil es sonst möglich wäre eine 11 Bit Identifizierung zuerstellen die dezimal 0 ergibt, was ausgeschlossen werden soll.

8 Byte Daten

0 1 2 3 4 5 6 7

8 Byte Daten

Byte 0

7 6 5 4 3 2 1 0

Protokoll-Version Nachrichten-Typ

Abbildung 4.10.: Byte 0 der 8 Byte Daten

Das erste Byte der Daten definiert den weiteren Aufbau der Nachricht. Es beinhaltet, wie dieAbbildung 4.10 zeigt, 4 Bit für die Protokollversion, welches hier die Version 1 ist und 4 Bitfür den Nachrichtentyp. Es sind 7 verschiedene Nachrichtentypen definiert, wovon nur dreifür diese Arbeit relevant sind:

• Data Single

• Control

• Error

Byte 0

8 Byte Daten

Byte 1 – Byte 7 Nutzerdaten

Abbildung 4.11.: Belegung der 8 Byte Daten für den Data Single Nachrichtentyp


Byte 0 Byte 1

8 Byte Daten

Zieladresse

Byte 2 – Byte 7 Nutzerdaten

Abbildung 4.12.: Belegung der 8 Byte Daten für die Nachrichtentypen Control und Error

Data Single ist der einfachste und meist eingesetzte Nachrichtentyp, weil er am meistenNutzdaten transportieren kann (Abb. 4.11). Bei diesem Typ bestehen die 8 Byte Daten ausdem fest definierten Byte 0 und 7 Bytes für Nutzdaten wie z.B. Sensorwerte.

Die Nachrichtentypen Control und Error besitzen zusätzlich im Byte 1 eine Zieladresse (Abb.4.12) um Nachrichten gezielt an eine Komponente zu senden. Nachrichten vom Typ Controlbeinhalten Konfigurationsdaten für einzelne Komponenten wie z.B. das Einstellen der Uhr-zeit für den Realtime-Baustein im Time Master. Fehlermitteilungen werden mit dem Nach-richtentyp Error versendet.

Die anderen Nachrichtentypen können in dem oben genannten Dokument nachgelesen wer-den. Diese ermöglichen es, Nachrichten zu versenden, die mehr als 7 Byte Nutzdaten bein-halten.

Kommunikationsverlauf

Die folgende Aufzählung beschreibt die Reihenfolge wie Nachrichten von den Typen DataSingle, Control und Error zwischen Sender und Empfänger ausgetauscht werden.

1. Sender erstellt die Nachricht.

2. Sender versendet die erstellte Nachricht über den Bus.

3. Empfänger empfängt diese Nachricht und gibt keine Empfangsbestätigung.

Das Sequenzdiagramm in der Abbildung 4.13 zeigt einen Beispiel für den Kommunikations-verlauf von 3 aufeinanderfolgenden Nachrichten vom Typ Data Single.

Adressen zur Identifikation

Eine genaue Zuordnung von Nachrichten ist mit Hilfe von Quelladressen und bei einigenNachrichtentypen auch durch Zieladressen möglich. Für jede Komponente im System gibt


Abbildung 4.13.: Kommunikationsverlauf für Nachrichten vom Typ Data Single

es zwei verschiedene Arten von Adressen. Die Komponentenadresse ist für die Nachrich-tentypen Control und Error und bietet die Möglichkeit einzelne Komponenten über CAN-Nachrichten zu konfigurieren und ihren Fehlerstatus mitzuteilen. Nachrichtenadressen iden-tifizieren Daten die z.B. durch Auswerten von Sensoren entstanden sind und deren Nachrichtdem Nachrichtentyp Data Single entsprechen.

Komponente „xyz“Adresse: 0x12

Nachricht 1Adresse: 0x33

Daten-Nachrichten

CAN-Bus

Control & ErrorNachrichten

Data Single Nachricht

Nachricht nAdresse: 0x44

Data Single Nachricht

Abbildung 4.14.: CAN-Adressen einer Komponente

Abbildung 4.14 zeigt ein Beispiel für eine Komponente mit einer Komponentenadresse undzwei Nachrichtenadressen. Dieses Beispiel ist üblich für Komponenten, die Sensoren aus-


werten und deren Daten über den CAN-Bus senden oder Gateways, die Daten von einerSchnittstelle wie RS232 auf den CAN-Bus übertragen.

Im Anhang B befindet sich eine komplette Auflistung der vergebenen Adressen für das Tele-metriesystem.

4.2.3. Anwendungs-Protokoll

CAN-Nachrichten mit denen Daten verschickt werden, müssen das zuvor beschriebeneTransport-Protokoll einhalten. Zusätzlich muss die Position und Interpretation der Anwen-dungsdaten festgelegt werden. Diese Definition übernimmt das Anwendungs-Protokoll, wel-ches sich im Anhang B befindet. In diesem Protokoll werden die Nutzerdaten belegt undbestimmt wie diese von anderen Komponenten zu interpretieren sind. Zum Beispiel der Wertdes Lenkwinkels, dieser wird von der Komponente Sensor “Lenkwinkel” mittels einer DataSingle Nachricht versendet. Nun wird festgelegt, dass sich der Winkel im Byte 1 und 2 der8 Byte Daten einer Nachricht befindet und als vorzeichenbehafteter 16 Bit Wert mit einemIntervall von -180◦ bis +180◦ zu interpretieren ist. Für alle Werte ist zu beachten, dass sie inder Little-Endian Byte-Reihenfolge vorliegen.

4.2.4. TTCAN

Der CAN-Bus ist ein ereignisgesteuerter Bus, was bedeutet, dass Nachrichten auf dem Buserscheinen, wenn ein neuer Wert von z.B. einem Sensor ermittelt wurde. Der ereignisgesteu-erte Bus ist für das Telemetriesystem unvorteilhaft, weil die Sollfrequenzen der Sensorwerteaus Kapitel 2.2.1 eingehalten werden müssen und die Datenlast auf dem Bus schwer zubestimmen ist. Ein weiterer Nachteil ist Starvation (Verhungern) was durch die Priorisierungder Nachrichten entsteht. Hierbei kann es vorkommen, dass Nachrichten mit einer niedrigenPriorität nicht über den Bus versendet werden können, weil Nachrichten mit höherer Prio-rität es nicht zulassen. Diese Nachteile können durch einen zeitgesteuerten Bus beseitigtwerden, was aber einen größeren Entwicklungsaufwand der Software mit sich bringt.

Aufgrund der Vor- und Nachteile, die in der Tabelle 4.2 zusammengefasst dargestellt sind,wird der CAN-Bus softwareseitig zeitgesteuert entwickelt. Die Entwicklung der Software wirdin der Arbeit von Schuckert (2007) durchgeführt, weil sie in Verbindung mit dem Echtzeit-Scheduler aus Kapitel 4.1.4 implementiert werden muss.


Eigenschaft CAN-Busereignisgesteuert zeitgesteuert

Echtzeitfähig nein jaStarvation (Verhungern von Nachrichten) ja neinDatenlastbestimmung schwer einfachSoftware-Entwicklungsaufwand niedrig hoch

Tabelle 4.2.: Vergleich zwischen ereignisgesteuertem und zeitgesteuertem CAN-Bus

Zyklusaufbau

Damit die Werte zeitlich auf dem CAN-Bus verteilt werden können, ist es notwendig Zyklenfestzulegen um die Sollfrequenzen einzuhalten. Die Sollfrequenzen aus Kapitel 2.2.1 habenein großes Intervall von 1Hz bis 100Hz. Um dieses Intervall zu minimieren und dadurch dieKomplexität der Zykleneinteilung zu verringern werden alle Frequenzen die kleiner 25Hz sindauf 25Hz angehoben, was in der Tabelle 4.3 dargestellt ist.

Mit dem jetzt vorhandenen Intervall von 25Hz - 100Hz werden die Zyklen für den TTCANerstellt. Die untere Grenze des Intervalls von 25Hz gibt die Länge des Matrixzyklus an, der40ms beträgt. Die obere Grenze von 100Hz gibt die Länge der Basiszyklen an, die in einemMatrixzyklus vorhanden sind und 10ms betragen. Somit hat ein Matrixzyklus 4 Basiszyklen,was 3 verschiedene Frequenzen für den Datenversand ermöglicht:

• 25Hz: Daten einmal pro Matrixzyklus senden

• 50Hz: Daten jeden zweiten Basiszyklus senden

• 100Hz: Daten in jedem Basiszyklus senden

Die 10ms eines Basiszyklus werden in Zeitfenster unterteilt, die 400µs bzw. 600µs großsind. Innerhalb eines Zeitfensters muss eine Komponente ihre Daten vollständig übertragenhaben.

Die Abbildung 4.15 zeigt den vollständigen Zyklusaufbau für das Telemetriesystem. In dieserAbbildung ist ein Matrixzyklus mit 4 Basiszyklen dargestellt. Basiszyklus 0 und 3 haben bisauf die ersten 7 Zeitfenster eine spezielle Verwendung für Steuernachrichten, um Kompo-nenten zu konfigurieren und zur Fehlerkontrolle, wo einzelne Komponenten ihren Fehlersta-tus senden können. In den Zyklen 1 und 2 werden die von den Sensoren ermittelten Werteversendet. Die Schedulerzeit ist eine wichtige Angabe für den verwendeten Scheduler undhilft bei der zeitlichen Einteilung der Tasks.


Typ Sensor / Wert Frequenz in Werte/sMotorsteuerung EngineRoundCounter 25 (vorher 5)

MAP 25 (vorher 5)Phase1 25 (vorher 5)TAir 25 (vorher 5)TPS 25RPM 25Klambda1 25Inj1, Inj2, Inj3, Inj4 25Spark1, Spark2, Spark3, Spark4 25Lambda 25VBatt 25 (vorher 5)DFarf 25TEngine 25 (vorher 5)LambdaTarget 25 (vorher 5)Speed 25 (vorher 2)Gear 25 (vorher 2)Active Block 25 (vorher 1)

Sensoren 4 x Raddrehzahl 25Lenkwinkel 254 x Federweg 1003 Achsen Beschleunigung 253 Achsen Drehraten 25Pedalwinkel Kupplung, Bremse u. Gas 254 x Reifendruck 25 (vorher 5)4 x Reifentemperatur 25 (vorher 5)Bremsdruck 25Benzindruck 25

Tabelle 4.3.: Anpassung der Sollfrequenzen

Referenznachrichten

Die Referenznachrichten sind CAN-Nachrichten, die im ersten Zeitfenster von jedem Basis-zyklus (Abb. 4.15) versendet werden. Durch diese Nachrichten können sich alle am TTCANangeschlossenen Komponenten synchronisieren, um z.B. das Zeitfenster zu ermitteln, indem gesendet werden darf. Für das Senden der Referenznachrichten ist der Time Masterzuständig, der in der Arbeit von Schuckert (2007) erstellt wird.

In den Nutzdaten der Referenznachrichten sind einige Informationen vorhanden die wichtig


TTCAN Matrixzyklus (40ms)Basiszyklus 0 (10ms) Steuerung

198 0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44 46Zeit für Fenster 400µs 2,4ms 400µs 400µs 400µs 400µs 400µs 400µs 400µs 400µs 400µs 400µs 400µs 400µs 400µs 400µs 400µs 400µs 400µs 400µsIdentifizierung 0x01 – 0x07 Reserviert für 50Hz und 100Hz Daten 0x09 0x09

Basiszyklus 1 (10ms) Daten 148 50 52 54 56 58 60 62 64 66 68 70 72 74 76 78 80 82 84 86 88 90 92 94 96

Zeit für Fenster 400µs 2,4ms 2ms 400µs 400µs 400µs 400µs 400µs 400µs 400µs 400µs 400µs 400µs 400µs 400µs 400µsIdentifizierung 0x01 – 0x07 Reserviert für 50Hz und 100Hz Daten 0x35 – 0x3A (6 Nachrichten) 0x3B 0x33 0x34


Zeit für Fenster 400µs 2,4ms 400µs 400µs 400µs 400µs 400µs 400µs 400µs 400µs 400µs 400µs 400µs 400µs 400µs 400µs 400µs 400µs 400µs 400µsIdentifizierung 0x01 – 0x07 Reserviert für 50Hz und 100Hz Daten

Basiszyklus 3 (10ms) Fehlerkontrolle148 150 152 154 156 158 160 162 164 166 168 170 172 174 176 178 180 182 184 186 188 190 192 195

Zeit für Fenster 400µs 2,4ms 400µs 400µs 400µs 400µs 400µs 400µs 400µs 400µs 400µs 400µs 400µs 400µs 400µs 400µs 400µs 600µs 600µsIdentifizierung 0x01 – 0x07 Reserviert für 50Hz und 100Hz Daten 0x09 0x0D 0x0E 0x0C 0x0A

Scheduler- Zeit

Scheduler- Zeit

Scheduler- Zeit

Scheduler- Zeit

Abbildung 4.15.: TTCAN Zyklusaufbau

für andere Komponenten sind. Zum Beispiel werden das Datum und die Uhrzeit mit den 4verschiedenen Referenznachrichten übertragen und vom Datalogger verwendet, um seineDateien anzulegen.

Abbildung 4.16.: Oszilloskopaufnahme der Referenznachrichten

In der Abbildung 4.16 sind die Referenznachrichten mit einer Oszilloskopaufnahme durchdie roten Pegel dargestellt. Die blauen Pegel liegen in jedem zweiten Zeitfenster des Basis-zyklus 0 und dienen der Erkennung des Matrixzyklus. Anhand der Zeitachse kann erkanntwerden, dass die Referenznachrichten einen Abstand von 10ms haben, was der Länge ei-nes Basiszyklus entspricht. Die blauen Pegel kennzeichnen die Länge eines Matrixzyklusvon 40ms.


4.2.5. Lastanalyse

100Nachr ichten

Matr ixzyklus (40ms)· 25 = 2500

Nachr ichten

s(4.2)

Durch die Einteilung der Zeitfenster innerhalb der Zyklen lässt sich die maximale Anzahl derNachrichten je Sekunde mit der Gleichung 4.2 genau bestimmen.

2500Nachr ichten

s· 16

Byte

Nachr icht= 40000

Byte

s(4.3)

Aus der Anzahl der maximalen Nachrichten und dem Datenformat aus Kapitel 4.1.2 kanndas maximale Datenaufkommen je Sekunde berechnet werden, was in der Gleichung 4.3durchgeführt wurde. Dieses Datenaufkommen ist für Komponenten relevant, die entwederalle Daten weiter übertragen möchten, was z.B. die Aufgabe des Communicator ist oderdiese Daten speichern möchten, wie der Datalogger.

4.2.6. Realisierung

Software-Bibliothek

Für die einfache Benutzung der CAN-Hardware vom AT90CAN128 Mikrocontroller ist eineSoftware-Bibliothek erstellt worden. Die von Atmel zur Verfügung gestellte Bibliothek konntenicht genutzt werden, weil diese keine Mobs5 festlegen kann, die dauerhaft zum Empfangenvon Nachrichten verwendet werden, keinen zusätzlichen Nachrichtenpuffer zur Verfügungstellt, nicht für das Empfangen von Nachrichten per Interrupts geeignet ist und den TTCANMode des Mikrocontrollers nicht unterstützt.

Die Software-Bibliothek setzt die von Atmel erstellten Treiber voraus und besteht aus einerHeader-Datei (can_lib.h) und der zugehörigen Source-Datei (can_lib.c). Sie bietet Funktio-nen zum Initialisieren, Zurücksetzen, Senden und Empfangen an und definiert zusätzlicheinige Datentypen wie z.B. can_msg_t, welches das Datenformat aus Kapitel 4.1.2 imple-mentiert. Die Bibliothek ist mit speziellen Kommentaren versehen, die es ermöglichen, mitdem Software-Dokumentationswerkzeug Doxygen6 eine übersichtliche Dokumentation zu er-stellen. In dieser Dokumentation, die auf der beigelegten CD zu Verfügung steht, sind alleFunktionen, Strukturen und Typen ausreichend beschrieben und werden hier nicht weitererläutert.

5Message Objects vom Mikrocontroller6http://www.stack.nl/~dimitri/doxygen/index.html

http://www.stack.nl/~dimitri/doxygen/index.html


Funktion Kompileroptimierung Zeitbedarf Bemerkungcan_rx_mobs_flush ohne Optimierung 631, 7µs 14 Mobs mit

o1 328, 3µs Nachrichten belegto2 303, 8µs

o2 24, 57µs Interrupts aktiviertcan_get_next_msg ohne Optimierung 48, 6µs Keine Bemerkung

o1 10, 1µs

o2 10, 1µs

can_send_msg ohne Optimierung 41, 8µs Nachricht nach Ablaufo1 18, 7µs der Zeit auf dem Buso2 15, 9µs

Tabelle 4.4.: Zeitbedarf von CAN-Bibliotheksfunktionen

Für die weitere Arbeit an dem Telemetriesystem ist es notwendig den Zeitbedarf einigerFunktionen zu bestimmten. Diese Bestimmung wurde durch eine Messung mit einem Oszil-loskop durchgeführt und ergab die in der Tabelle 4.4 dargestellten Zeiten.

Transport-Protokoll

Eine Header-Datei (can_protocol_v1.h) ist erstellt worden, um das Transport-Protokoll ausKapitel 4.2.2 in der Programmiersprache C zu implementieren und so für die Software derMikrocontroller verwendet werden kann. Diese Header-Datei besitzt Definitionen für die ein-zelnen Prioritäten und Nachrichtentypen sowie Makros zum Erstellen und Auslesen vonCAN-Nachrichten. Zusätzlich zur Protokolldokumentation existiert auch eine Doxygen Doku-mentation, die in digitaler Form auf der beigelegten CD vorhanden ist und beim Verwendender Header-Datei behilflich sein kann.

4.3. Communicator

Als Schnittstelle zwischen dem Telemetriesystem im Rennwagen und dem Leitstand dientder Communicator. Durch diese Schnittstelle hat der Leitstand die Möglichkeit von demSystem Nachrichten zu empfangen und zu senden. Die mit dem Communicator entstande-ne bidirektionale Kommunikation zum Leitstand wird genutzt, um alle Nachrichten währendder Fahrt beim Leitstand live auszuwerten und um verschiedenste Konfigurationen einzelnerKomponenten im System vom Leitstand aus durchzuführen.


4.3.1. Hardwaredesign vom Communicator

AT90CAN128CAN Communication

Module

16MHz

AT90CAN128WiPort Communication

Module

14.7456MHz

CAN-Bus

SPIWiPort

RS232

Communicator

LeitstandWLAN

RS232

Abbildung 4.17.: Communicator-Architektur

Die drahtlose Kommunikation zwischen dem System und dem Leitstand übernimmt eineWireless LAN Verbindung. Wie in der Abbildung 4.17 zu sehen ist, wird hier der WiPorteingesetzt, der die Wireless LAN Unterstützung bereitstellt. Er ist mit einem Mikrocontrollerüber eine RS232 Schnittstelle verbunden und kann auf diese Weise die Daten empfangenund senden. Der WiPort besitzt noch eine weitere RS232 Schnittstelle, die in diesem Systemvon dem Datalogger genutzt wird, was im Kapitel 4.5.3 noch beschrieben wird.

WiPort

Abbildung 4.18.: WiPort

Der WiPort (Abb. 4.18) ist für die kabellose Verbindung zwischen dem Rennwagen und demLeitstand zuständig. Ausgewählt wurde der WiPort, weil er speziell für eingebettete Syste-me entwickelt wurde und eine Wireless LAN (WLAN) Kommunikation bietet. Die Reichweitevon WLAN ist nicht sehr groß, aber für eine Live-Übertragung auf der Teststrecke mit einermaximalen Entfernung von ungefähr 150 Meter zwischen Rennwagen und Leistand ausrei-chend. Die Vorteile von WLAN wie günstige Hardware und der integrierten Unterstützungin Betriebssystemen waren bei der Auswahl sehr wichtig. Der WiPort hat die Eigenschaf-ten eines Gateways und ist für den Mikrocontroller im Rennwagen und dem Leitstand ein


transparentes Modul. Der Mikrocontroller im Rennwagen nutzt eine der beiden verfügbarenRS232 Schnittstellen um mit dem Leitstand zu kommunizieren und der Leitstand nutzt dieWLAN Verbindung für die Kommunikation mit dem Rennwagen.

Designentstehung

Die Abbildung 4.17 zeigt, dass der Communicator für die Anbindung an den WiPort zwei Mo-dule besitzt. Im Folgenden wird beschrieben wie dieses Hardwaredesign entstanden ist.

40000Byte

s· 10

Bit

Byte= 400kbps (4.4)

Da die maximale Datenrate, wie im Kapitel 4.2.5 beschrieben, mit 40000Bytes

sehr großist, ist es wie die Gleichung 4.4 zeigt notwendig, die Baudrate der RS232 Schnittstelle ≥400kbps zu wählen, damit keine Daten verloren gehen.

Baudrate UART Fehler bei14.7456MHz 16.0000MHz

9.6kbps 0,00% 0,16%38.4kbps 0,00% 0,16%57.6kbps 0,00% 2,12%

115.2kbps 0,00% 3,55%230.4kbps 0,00% 8,51%460.8kbps 0,00% 8,51%921.6kbps 0,00% 8,51%

Tabelle 4.5.: UART Baudrate Fehler

Die vom WiPort zur Verfügung stehenden Baudraten 460.8kbps und 921.6kbps erfordertenden Mikrocontroller mit einem anderen Quarz zu betreiben, weil die Prescaler-Einstellungenmit dem für dieses Telemetriesystem standardmäßig verwendeten 16MHz Quarz nicht mög-lich ist. Die Tabelle 4.5 zeigt, dass der Fehler mit einem 16MHz Quarz und einer Baudratevon mehr als 38.4kbps größer als die von Atmel spezifizierten 2% maximaler Fehler der se-riellen Schnittstelle wird. Das Aktivieren des Double Speed Modus, was die Abtastrate proBit von 16 auf 8 halbiert, würde nur einen akzeptablen Fehler bis zu einer Baudrate von57.6kbps haben. Auch ein Betreiben des externen Takteinganges für die UART Schnittstelleist aufgrund der Hardwarespezifikation vom Mikrocontroller fXCKn <

fCLKio4

nicht möglich,weil dieser Eingang mit mindestens 7.3728MHz betrieben werden muss, um eine Baudratevon 460.8kbps zu erreichen aber der externe Takteingang für die UART Schnittstelle mit derEinschränkung nur maximal 4MHz bei einem 16MHz Systemtakt haben darf.


Um dieses Problem zu beheben ist der Mikrocontroller, der mit dem WiPort kommuniziert, inder Abbildung 4.17 WiPort Communication Module genannt, mit einem 14.7456MHz Quarzbestückt, da dieser Quarz, wie die Tabelle 4.5 zeigt einen Fehler von 0% bei allen Baudratenhat.

Baudrate CAN Fehler bei14.7456MHz 16.0000MHz

100kbps 1,70% 0,00%125kbps 1,70% 0,00%250kbps 1,70% 0,00%500kbps 1,70% 0,00%

1000kbps 5,33% 0,00%

Tabelle 4.6.: CAN Baudrate Fehler

Der Einsatz des 14.7456MHz Quarzes hat aber auch den Nachteil, dass der Fehler jetztbei der CAN Baudrate entsteht, was in der Tabelle 4.6 dargestellt ist. Somit kann derAT90CAN128 Mikrocontroller nicht beide Kommunikationsarten gleichzeitig nutzen. Weil dieEntwicklungszeit der Komponenten aufgrund des Events der Formula Student eingeschränktist, kam ein zweiter zusätzlicher Mikrocontroller (CAN Communication Module) der gleichenBaureihe mit einem 16MHz Quarz zum Einsatz. Eine andere Lösung wäre der LPC2129Mikrocontroller von NXP7, weil sich hier Quarze einsetzen lassen bei denen die Fehler derKommunikationsschnittstellen akzeptabel sind. Die zwei Mikrocontroller nutzen zum Daten-austausch SPI, weil es wegen des Master Slave Verfahrens, wie es im Kapitel 3.2 erklärtwurde, nicht direkt von der Taktrate abhängt und somit das Problem mit der Baudrate löst.

Hardware-Realisierung

Für die beiden Communication Module wird das Evaluation Board, was im Kapitel 4.1.3 vor-gestellt ist, verwendet. Ein Bausatz8 inklusive WiPort wird für die Integration in dem Commu-nicator genutzt. Für die Einbindung in das Telemetriesystem sind zwei CAN-Bus Anschlüsse,Antennenanschluss, Anschluss für die Spannungsversorgung, ein RS232 Anschluss für denzweiten Kanal des WiPort und 3 Leuchtdioden für die Statusanzeige aus der Box (Abb. 4.19)raus geführt worden. Eine detaillierte Beschreibung der Anschlüsse befindet sich im AnhangD.

7http://www.nxp.com/8http://www.segor.de/L1Bausaetze/ComLanC.shtml

http://www.nxp.com/

http://www.segor.de/L1Bausaetze/ComLanC.shtml


Abbildung 4.19.: Communicator Box

4.3.2. Bedingungen für die Übertragung vom Leitstand

Es werden zwei Bedingungen für den Leitstand definiert, damit Nachrichten erfolgreich anden Communicator versendet werden können.

Nachrichtengeschwindigkeit

Durch den TTCAN Zyklusaufbau aus Kapitel 4.2.4 hat sich ergeben, dass der Communicatormaximal zwei Nachrichten in einem Matrixzyklus (40ms) über den CAN-Bus versenden kann.Daraus ergibt sich die Bedingung, dass der Leitstand nur zwei Nachrichten in 40ms an denCommunicator senden darf, da es sonst zu Datenverlust kommt, wenn die Puffer nicht mehrausreichen.

Abweichung des Datenformates

Weil die Nachrichten über WLAN an den Communicator gesendet werden und diese Über-tragung fehlerbehaftet sein kann, was z.B. bei Verbindungsabbruch der Fall ist, wird dasDatenformat aus Kapitel 4.1.2 dahingehend angepasst, dass eine Überprüfung der Nach-richt vom Communicator erfolgen kann.

Die Abbildung 4.20 zeigt das veränderte Datenformat. Hier sind die 2 Bytes des an dieserStelle noch nicht benötigten Timestamp entfernt und dafür eine 1 Byte große Prüfsumme


16 byte message

identifier ide | length application data 0x00rtr checksum

Abbildung 4.20.: Verändertes Datenformat

an das Ende der Nachricht eingefügt worden. Weil die Prüfsumme aus 1 Byte besteht und2 Byte frei sind, ist das Byte vor der Prüfsumme ohne Bedeutung. Der Timestamp konnteentfernt werden, weil er nur von der CAN-Bus-Hardware verändert wird, welche erst vomCommunicator benutzt wird und nicht vom Leitstand. Die anderen Daten haben sich nichtverändert, so dass es den folgenden Aufbau einer 16 Byte Nachricht ergibt.

• 4 Byte Identifizierungsnummer

• 4 Bit für die Markierung einer erweiterten Identifizierungsnummer

• 4 Bit Längenangabe der Anwendungsdaten

• 8 Byte Anwendungsdaten

• 1 Byte das eine remote transfer message kennzeichnet

• 1 Byte nicht belegt

• 1 Byte Prüfsumme

Die Prüfsumme wird durch aufsummieren der Bytes 0 bis 13 erstellt. Zu beachten ist, dassdie Prüfsumme nur aus einem Byte besteht und es somit zu einem Überlauf des Wertebe-reichs kommen kann.

Über die Prüfsumme ist jetzt die Möglichkeit gegeben diese Nachrichten zu überprüfen. Istdie Überprüfung einer Nachricht abgeschlossen und akzeptiert, muss der Communicatordiese Nachricht, bevor der sie über den CAN-Bus versendet in das normale Datenformat,wie es in Kapitel 4.1.2 beschrieben ist, konvertieren.

4.3.3. WiPort Communication Module

Dieses Modul hat erstens den SPI Slave Modus, damit es Nachrichten von dem CAN Com-munication Modul empfangen und bereitstellen kann und zweitens eine RS232 Schnittstelle,um Daten mit dem WiPort auszutauschen. Damit die Kommunikation zwischen den verschie-denen Schnittstellen ermöglicht werden konnte, war eine Software Architektur auf Basisvon Interrupts von Vorteil, weil dieses Modul schnell auf eintreffende Nachrichten reagie-ren muss. Die Echtzeitsoftware aus Kapitel 4.1.4 kann hier nicht eingesetzt werden, da die


Bufferin

SPI handleinterrupt

Bufferout

RS232

WiPort Communication Module

SPI

RS232 send

RS232 readinterrupt

Sync Buffer

Sync Buffer

messagecheck & convert

Abbildung 4.21.: Wiport Communication Module

SPI und RS232 Schnittstelle eine so hohe Baudrate haben, dass Nachrichten durch ein zugroßes Intervall beim Abfragen der Register verloren gehen würden. Die Abbildung 4.21 zeigtdie einzelnen Funktionen der Software damit die Daten ausgetauscht werden können. DiePuffer sind die Schnittstellen für zwischen den ISR9s und den Funktionen, die in der SuperLoop ausgeführt werden.

SPI→ RS232

Die ISR SPI handle interrupt die auf ein SPI Serial Transfer Complete reagiert, liest dasübertragene Byte aus dem Register aus und schreibt es in einen Puffer für ausgehendeNachrichten. Die Funktion RS232 send der Super Loop prüft ständig diesen Puffer und ver-schickt bei einer vollständigen 16 Byte Nachricht die enthaltenen Bytes über die RS232 anden WiPort.

RS232→ SPI

Eine RS232 ISR wird aktiviert wenn das USART0, Rx Complete Flag gesetzt wurde undschreibt das empfangene Byte in einen der beiden Synchronisationspuffer, die zum Über-prüfen der Nachrichten sind. Es sind zwei Puffer zur Synchronisation eingesetzt worden umder Super Loop mehr Zeit für die Bearbeitung der anderen Funktionen zu geben. Eine Nach-richt im Synchronisationspuffer ist gültig, wenn sie das Datenformat aus Kapitel 4.3.2 einhält.Die Super Loop überprüft laufend diese Synchronisationspuffer und schreibt bei einer positivvalidierten Nachricht die Daten nach der Konvertierung in das normale Datenformat, wie esim Kapitel 4.1.2 definiert ist, in den Puffer für eingehende Nachrichten. Die ISR SPI handleinterrupt prüft bei jedem empfangenen Byte vom CAN Communication Module ob Daten imeingehenden Puffer sind und schreibt diese in das SPI Data Register damit sich das CAN

9Interruptserviceroutine


Communication Module das Byte beim nächsten Transfer holen kann. Durch den TTCAN istgewährleistet, dass Nachrichten mindestens alle 10ms vom SPI Slave durch den SPI Mas-ter abgeholt werden. Das liegt an der Referenznachricht vom Time Master, die alle 10msgeschickt wird und somit eine Kommunikation zwischen den beiden SPI Modulen erfolgenmuss.

Interrupteigenschaften

ISR Zeitbedarf minimale PeriodenzeitRS232 5µs 10, 85µs

SPI 6.5µs 4µs

Tabelle 4.7.: Interrupteigenschaften

TPer iode =1

Baudrate· NBits pro Byte (4.5)

Um Datenverlust durch zu lange ISRs zu vermeiden wurde der Zeitbedarf der ISRs gemes-sen und hat die in der Tabelle 4.7 notierten Werte ergeben. Die Periodenzeit ist durch dieGleichung 4.5 ermittelt worden. Sie errechnet sich aus der Baudrate der Schnittstellen undder Anzahl der Bits, die übertragen werden müssen, um ein Byte zu erhalten. Zeitverzöge-rungen, die durch die Hardware entsteht können sind bei dieser Gleichung nicht berücksich-tigt worden.

Voraussetzungen für den Datentransfer

Es gibt drei Voraussetzungen für einen korrekten Datentransfer zwischen der SPI und RS232Schnittstelle.

1. Der SPI handle interrupt muss beendet sein bevor der SPI Master neue Daten trans-feriert.

2. Das Datenregister der RS232 muss von dem RS232 read interrupt gelesen werdenbevor neue Daten empfangen werden.

3. Die ISRs dürfen sich untereinander nicht beeinflussen.


Berechnung der erforderlichen SPI Periodenzeit

TSP I Kommunikation = min. P er iodenzeitSP I + ISR Zeitbedar f SP I (4.6)

TISRs =∑

ISR Zeitbedarf

(4.7)

TSP IPer iode ≥ max(TKommunikation, TISRs) (4.8)

Die Tabelle 4.7 zeigt, dass es bei SPI zu Datenverlust kommt, wenn die Periodenzeit so vomSPI Master betrieben wird, weil die Voraussetzungen 1. und 3. für den Datentransfer nichteingehalten werden. Die erforderliche Periodenzeit ist mit Hilfe der Gleichungen 4.6 - 4.8errechnet. Die Gleichungen beinhalten die 1. (Glg. 4.6) und 3. (Glg. 4.7) Voraussetzung fürden korrekten Datentransfer. Das Maximum der Ergebnisse aus Gleichung 4.6 und 4.7 ergibtdie mindestens erforderliche SPI Periodenzeit von 11.5µs , die das CAN CommunicationModule einhalten muss.

SPI handleinterrupt

Zeitbedarf: 6,5µs

RS232

WiPort Communication Module

SPIRS232 read

interrupt

Zeitbedarf: 5µsminimalePeriodenzeit: 11,5µs

minimalePeriodenzeit: 10,85µs...

Abbildung 4.22.: Erforderliche Interrupteigenschaften vom Wiport Communication Module

Die Abbildung 4.22 gibt eine Übersicht über die erforderlichen Eigenschaften der Interrupt-bearbeitung für das WiPort Communication Module.

4.3.4. CAN Communication Module

Das CAN Communication Module hat die Aufgabe die Kommunikation mit dem CAN Busdurchzuführen und als SPI Master die Daten mit dem WiPort Communication Module aus-zutauschen. Um die Kommunikation mit dem TTCAN zu ermöglichen, ist für dieses Moduldie Echtzeit-Software aus Kapitel 4.1.4 eingesetzt worden. Der Ablauf der Datenübertragungwird in den folgenden 2 Absätzen beschrieben und der Absatz Zeitliche Anordnung der Tasksbeschreibt wie die Software strukturiert ist.


CAN Library BufferCAN flush

SPI handle

SPI BufferCAN buildmessageCAN send

CAN Bus

SPI

CAN Communication Module

Abbildung 4.23.: CAN Communication Module

CAN→ SPI

Eine Task, in der Abbildung 4.23 CAN flush genannt, prüft in festgelegten Zeitabständenob neue Nachrichten in den Mobs der CAN Hardware vorhanden sind und schreibt diesein den CAN Library Buffer. Hierfür wird die Funktionalität der CAN Bibliothek verwendet.Eine andere Task SPI handle liest den CAN Puffer aus und sendet Nachrichten, wenn diesevorhanden sind, über SPI an das WiPort Communication Module.

SPI→ CAN

Die Task SPI handle die Nachrichten sendet, empfängt gleichzeitig Daten und prüft ob esneue Nachrichten sind. Die Überprüfung muss stattfinden, weil bei einem SPI-Transfer immerneue Daten vom WiPort Communication Module empfangen werden. Um Nachrichten mitInhalt von anderen zu unterscheiden haben alle Nachrichten ohne Inhalt in jedem der 16Byte eine 0x00. Wenn eine Nachricht empfangen wird, die eine Identifizierungsnummer inden ersten 4 Byte beinhaltet, wird diese Nachricht als neu interpretiert und in den SPI Buffergeschrieben. CAN build message ist eine Task die aus den Daten im SPI Buffer eine CANNachricht erstellt, die dann von der zeitlich darauf folgenden Task und mit Hilfe der CANBibliothek über den CAN Bus versendet wird.

Zeitliche Anordnung der Tasks

Die Softwarearchitektur beinhaltet einen Scheduler für den verschiedene Tasks geschriebenwerden mussten, die zeitgesteuert ihre Aufgaben erledigen. In der Abbildung 4.24 ist dieAnordnung der Tasks anhand des TTCAN Zyklusaufbaus dargestellt. Die zwei Tasks CANflush und SPI send waren die ausschlaggebenden Größen dieser Anordnung, weil sie vielezeitliche Abhängigkeiten haben.


10ms1* 2* 3* 4* 5* 6* 7* 8* 9* 10* 11* 12* 13* 14* 15* 16* 17* 18* 19* 20* 21* 22* 23* 24* 25*

Basiszyklus 1

Basiszyklus 2

Basiszyklus 3

Basiszyklus 4

* 400µs Zeitfenster

freie Zeitfenster

CAN flushSPI sendTimeMasterMsg receiveTimeMaster synchronizeCAN sendCAN build messageModul synchronize

Abbildung 4.24.: Taskeinteilung

TCANsendTask = TCANsend + TScheduler (4.9)

Eine wichtige Größe für das CAN flush vom TTCAN aus Kapitel 4.2.4 war die Anzahl derNachrichten die innerhalb eines Basiszyklus empfangen werden müssen. Da im Basiszyklus2 die maximale Anzahl der Nachrichten 26 ist und für den Empfang von Nachrichten nur 12Mobs des Mikrocontroller zu Verfügung stehen, war es notwendig 3 mal pro Basiszyklus dieMobs mit dem CAN flush zu leeren. Die Dauer dieser Task ist mit der Gleichung 4.9 errechnetworden, die die Messung der CAN Bibliothek für das CAN send aus Kapitel 4.2.6 beinhaltetund die Zeit, die der Scheduler für seine Berechnungen braucht, was durch die Gleichung4.1 im Kapitel 4.1.4 berechnet wurde.

TSP IsendTask = NNachr ichten · (16 · TPer iode + TPuf f eroperationen) + TScheduler (4.10)

Bei den SPI send Tasks mussten mehrere Daten berücksichtigt werden, die in der Glei-chung 4.10 einbezogen sind. Durch die Position der CAN flush Task konnte die Anzahl derNachricht bestimmt werden, die bei jedem Ausführen der Task übertragen werden. DieseNachrichten enthalten jeweils 16 Bytes, wobei zwischen den einzelnen Bytes die erforder-liche Periodenzeit des WiPort Communication Module eingehalten werden muss, damit esnicht zu Datenverlust kommt. Um das zu gewährleisten wurden zwischen dem Senden dereinzelnen Bytes NOP10s eingefügt, die eine Periodenzeit von 13.5µs11 ermöglichen. Nach

10No Operations11gemessener Wert


dem Übertragen einer Nachricht muss noch die empfangene Nachricht überprüft werden, obsie eine Identifizierungsnummer enthält und wenn dies der Fall ist, wird sie in den SPI Buffergeschrieben. Um die gesamte Dauer der Task zu erhalten, ist es noch notwendig die Zeit miteinzubeziehen die der Scheduler für seine Arbeit braucht. Das Ergebnis ist in der Abbildung4.24 zu sehen.

4.3.5. Synchronisation der Module

Die Synchronisationstechniken, die im Folgenden beschrieben werden sind für den Com-municator wichtig, weil in ihm 3 asynchron laufende Module vorhanden sind. Zwischen denverschiedenen Modulen müssen die Zeiger der Puffer synchron sein, damit z.B. eine 16 ByteNachricht vom WiPort korrekt auf dem CAN-Bus gesendet werden kann.

Startsynchronisation der beiden Communication Module

Weil die zwei Module CAN Communication Module und WiPort Communication Module un-abhängig voneinander auf verschiedenen Mikrocontrollern betrieben werden und unterein-ander Nachrichten austauschen, ist es nötig eine Startsynchronisation zu erstellen. DieseSynchronisation soll beim Übertragen einer 16 Byte Nachricht vermeiden, dass der Pufferin-dex in beiden Modulen asynchron zueinander sind. Dazu werden von jedem Modul zweiPorts des Mikrocontrollers verwendet, die über eine 2-Drahtleitung miteinander verbundensind.

CAN Communication Module WiPort Communication Module

MASTER_SYNC

SLAVE_SYNC

PO

RT BP

OR

T B

BIT 5

BIT 6

BIT 5

BIT 6

Abbildung 4.25.: Synchronisations-Verbindung der beiden Module

Die Abbildung 4.25 zeigt wie beide Module miteinander verbunden werden. Jede dieser Lei-tungen kennt zwei Zustände high (5 Volt) und low (0 Volt). Im deaktivierten Zustand derModule ist diese Leitung low, was bedeutet, dass keine Spannung vorhanden ist. Wenn einModul bereit ist sich zu synchronisieren setzt er seine Leitung auf high und wartet bis dasandere Modul seine Leitung ebenfalls auf high setzt.


Abbildung 4.26.: Beispiel einer Startsynchronisation

Ein beispielhafter Ablauf der Startsynchronisation ist in der Abbildung 4.26 durch ein Se-quenzdiagramm dargestellt. Das CAN Communication Module setzt seine Leitung (MAS-TER_SYNC) als erstes auf high und wartet bis das WiPort Communication Module seineLeitung (SLAVE_SYNC) auf high setzt. Nachdem beide Leitungen auf high sind, können siemit dem Nachrichtenaustausch per SPI beginnen. Die Module überprüfen periodisch die Lei-tung des anderen Moduls. Wird die Leitung eines Moduls durch z.B. einem Reset auf lowgesetzt, synchronisieren sich beide Module erneut.

Puffersynchronisation zwischen WiPort Communication Module und WiPort

Zwischen den WiPort Communication Module und WiPort ist eine Synchronisation auf Ba-sis von zwei Leitungen nicht möglich, weil der WiPort keinen Eingriff in Hard- und Softwarezulässt. Damit der Pufferindex für eingehende Nachrichten beim WiPort Communication Mo-dule synchron ist, wird ein Timer eingesetzt durch den Verbindungsunterbrechungen erkanntwerden. Der Timer gibt dem WiPort 25ms zum Übertragen einer 16 Byte Nachricht. Sollte esbeim Übertragen einer Nachricht zu einer Unterbrechung kommen, läuft der Timer ab undaktiviert eine ISR, die den zum Teil gefühlten Puffer löscht, so dass er wieder bereit ist ei-ne vollständige Nachricht zu empfangen. Fehlerhafte Nachrichten vom WiPort werden durchdas in Kapitel 4.3.2 beschriebene Prüfsummenverfahren erkannt.


Abbildung 4.27.: Leitstand-Software

4.4. Leitstand-Software

Eine Java-Software (Abb. 4.27), die am Leitstand eingesetzt wird, kommuniziert mit demCommunicator im Rennwagen. Diese Software übernimmt die Funktionen Nachrichten vomCommunicator zu empfangen, die anschließend per UDP Server für Visuallisierungssoftwarewie z.B. LabVIEW bereitgestellt werden und dient der Konfiguration der Komponenten imTelemetriesystem.

4.4.1. Bedingungen für die Kommunikation zum Communicator

Damit der Communicator die Nachrichten von der Leitstand-Software akzeptiert, muss dieseNachrichten in dem Datenformat aus Kapitel 4.3.2 mit der Prüfsumme senden.

Die Anzahl der Nachrichten ist durch den TTCAN Zyklusaufbau aus Kapitel 4.2.4 einge-schränkt. Die Abbildung 4.15 zeigt, dass der Communicator zwei Nachrichten im Basiszyklus0 senden kann und somit maximal zwei Nachrichten innerhalb von 40ms von der Leitstand-Software versendet werden dürfen.

4.4.2. Synchronisierung der Nachrichten vom Communicator

Der Communicator versendet jedes Byte einer 16 Byte Nachricht einzeln per WLAN an denLeitstand. Da bei Verbindungsaufbau nie gewährleistet werden kann, dass das Byte 0 einer


Nachricht empfangen wird, ist es nötig eine Synchronisation zu erstellen. Dazu wird die durchden TTCAN periodisch vorkommende Referenznachricht genommen, weil sie immer auf demBus vorhanden ist.

Referenznachricht Datennachricht

Indexzeiger0 0 0 0 0 0 0 01 2 3 4

... ...

Abbildung 4.28.: Synchronisation vom Indexzeiger

Der Indexzeiger auf dem Array für eingehende Nachrichten bleibt auf 0 bis eine validierteReferenznachricht empfangen wird (Abb. 4.28). Das Validieren der Referenznachricht erfolgtdurch die bekannte Zusammensetzung der Nachricht. Referenznachrichten haben als ein-zige eine Priorität von 0 und einen Adressbereich von 0 bis 7. So ist es mit den ersten 6Byte, in denen noch Protokollversion, Nachrichtentyp und Nachrichtenlänge vorhanden sind,möglich eine Referenznachricht eindeutig zu identifizieren.

Ein Timer, der auf 1500ms eingestellt ist, dient zur Erkennung von Verbindungsunterbre-chungen. Der Timer läuft ab wenn die Referenznachricht vom TTCAN nicht mehr empfangenwird. Läuft dieser Timer ab wird die Synchronisation bei dem Empfang des nächsten Byteswiederholt ausgeführt.

4.4.3. Steuerung und Konfiguration von Komponenten

Die Leitstandsoftware bietet die Möglichkeit Nachrichten über den CAN-Bus im Rennwagenzu senden. Dadurch können Komponenten im Telemetriesystem vom Leitstand konfiguriert,gesteuert und getestet werden.

Konfiguration

• Telemetriesystem-Zeit:Durch Senden von zwei Nachrichten werden dem Time Master die Systemzeit und dasDatum vom Leitstand übermittelt, um diese in die Referenznachrichten einzufügen.

• Radumfang und Einheit:Den Komponenten Sensoren “Raddrehzahl vorne” und Sensoren “Raddrehzahl hin-ten” wird für die Auswertung der Sensordaten der Radumfang angegeben und in wel-cher Einheit sie den Wert auf den CAN-Bus senden sollen.


Steuerung

• Reset:Alle am CAN-Bus befindlichen Komponenten führen nach Empfang dieser Nachrichtein Reset durch.

• Bus Mode:Hiermit ist es möglich alle Nachrichten bis auf die Referenznachricht vom CAN-Bus zunehmen und die Aufzeichnung vom Datalogger zu deaktivieren.

• Datalogger:Mit dieser Funktion können Daten vom Datalogger ausgelesen werden.

Test

• Custom Message:Frei definierbare Nachrichten ermöglichen es Komponenten im Telemetriesystem zuTesten.

4.5. Datalogger

Der Datalogger ist eine Komponente zum Aufzeichnen von Daten. Er zeichnet alle Daten dieüber den CAN-Bus versendet werden auf und bietet dadurch die Möglichkeit die Daten zueinem späteren Zeitpunkt auszuwerten. Hierbei hat er den Vorteil direkt an den CAN-Busangeschlossen zu sein. Somit kann er nicht wie der Leitstand Nachrichten durch Verbin-dungsstörungen verlieren.

4.5.1. Hardware

Der Datalogger besteht, wie in der Abbildung 4.29 dargestellt, aus einem Mikrocontroller(AT90CAN128 aus Kapitel 4.1.3) der direkt mit dem CAN-Bus verbunden ist und über SPIeine SD Memory Card ansteuert. Über eine extra RS232 Schnittstelle können Daten, diesich auf der SD Memory Card befinden, an den Communicator gesendet werden.


AT90CAN128Datalogger SD Memory Card

CAN-Bus

SPI

RS232

Datalogger

Abbildung 4.29.: Datalogger-Architektur

SD Memory Card

Für die Speicherung der Daten im Rennwagen wird für den Datalogger eine SD MemoryCard verwendet, weil sie klein, leicht, schnell, robust gegen Erschütterungen und über SPIleicht anzusteuern ist. Ein Nachteil der SD Card ist die 3,3V Betriebsspannung, was weitereHardware erfordert, da der Mikrocontroller mit 5V betrieben wird. Eine Alternative zur SDCard wäre die Compact Flash Card. Sie hat den Vorteil, dass sie mit 5V betrieben wird, aberden großen Nachteil 15 Pins (8 Daten, 4 Adresse, 3 Steuerung) des Mikrocontrollers für dieAnsteuerung zu verwenden, weshalb die SD Memory Card eingesetzt wird.

3,3V Problembehebung

Das Problem, dass die SD Memory Card eine 3,3V Betriebsspannung und der Mikrocontrol-ler eine 5V Betriebsspannung hat, wird durch eine spezielle Schaltung behoben. Die Haupt-aufgabe dieser Schaltung, die sich im Anhang C befindet, ist die 5V Ausgangsspannung anden SPI Datenausgängen des Mikrocontrollers auf 3,3V zu senken, den Datenausgang derSD Memory Card von 3,3V auf 5V anzuheben und die Spannung von 5V auf 3,3V für denBetrieb der Karte zu wandeln. Diese Schaltung besitzt zusätzlich 3 Leuchtdioden für eineStatusanzeige. Diese Leuchtdioden teilen mit, ob die Karte eine Spannungsversorgung hat,sie detektiert wurde und ob auf sie zugegriffen wird.

Hardware-Realisierung

Für die Umsetzung des Schaltplans aus der Abbildung C diente eine Rasterplatine. DiesePlatine wurde so mit den Bauteilen bestückt, dass sie über eine Steckverbindung mit demEvaluation Board verbunden werden kann. Das Resultat ist in der Abbildung 4.30 zu sehen.Auch hier wurden wie beim Communicator zwei CAN-Bus Anschlüsse (D-SUB-Stecker mitte


Abbildung 4.30.: Datalogger Box

und D-SUB-Buchse rechts) nach außen geführt. Ein 9 poliger D-SUB-Stecker wurde zusätz-lich heraus geführt. Dieser Stecker bietet eine RS232 Schnittstelle, um direkt Daten mit demWiPort auszutauschen, was im Kapitel 4.5.3 beschrieben wird und einen Schalteranschlussfür die Deaktivierung der Aufzeichnung. 3 Leuchtdioden, die mit dem Mikrocontroller verbun-den sind, zeigen den Status von der Software an und 3 weitere Leuchtdioden, die auf derPlatine des SD Memory Card Adapters verbaut sind, zeigen den Status der SD Memory Cardan. Eine detaillierte Beschreibung der Anschlussbelegung befindet sich im Anhang D.

4.5.2. Software

FAT Bibliothek

Ein FAT (File Allocation Table) Software-Bibliothek12 bietet eine komfortable Lösung zumSchreiben und Lesen von Daten auf einer SD Memory Card mit einem Mikrocontroller. DieseBibliothek unterstützt das FAT12, FAT16 und FAT32 Dateisystem, was es ermöglicht Datenvon der SD Memory Card mit allen gängigen Betriebssystemen (Windows, Linux usw.) zulesen. Des weiteren ist das SPI Protokoll für die Kommunikation zwischen einem Mikrocon-troller und einer SD Memory Card bereits in der Bibliothek implementiert, was sich positivauf die Entwicklungszeit auswirkt.

Für den Datalogger wird das Dateisystem in der FAT16 Version verwendet, weil es mit einenmaximalen Adressraum für 4GB Daten ausreicht. Des weiteren ist die Verarbeitung von 16

12http://www.holger-klabunde.de/avr/avrboard.htm#FullFAT

http://www.holger-klabunde.de/avr/avrboard.htm#FullFAT


Bit-Werten für den Mikrocontroller schneller als die 32 Bit-Werte eines FAT32 Dateisystems.Zudem ist der Speicherverbrauch beim einem Mikrocontroller für ein FAT32 Dateisystemsgrößer, was sich negativ auf die Größe anderer Puffer auswirkt.

Software-Architektur

SD Memory Cards haben unterschiedliche Lese- und Schreibgeschwindigkeiten, so dasskeine Angabe über die maximale Zeit einer Operation gemacht werden kann. Aus diesemGrund ist es nicht möglich den Echtzeitscheduler aus Kapitel 4.1.4 einzusetzen, weil die Ein-teilung bzw. die Länge einer Task zum Schreiben oder Lesen nicht angegeben werden kann.Da der Datalogger nur Daten vom CAN-Bus empfängt und selber keine sendet, ist die Ver-wendung des Echtzeitschedulers nicht nötig und die Entwicklung einer eigenen Architekturbeginnt.

Der Datalogger hat drei größere Funktionen zu erfüllen.

1. Daten vom CAN-Bus aufzeichnen:Der Datalogger empfängt Daten über die CAN-Bus Schnittstelle und schreibt diese indem Datenformat aus Kapitel 4.1.2 auf eine SD Memory Card.

2. Verzeichnisstruktur der SD Memory Card übertragen:Die auf der SD Memory Card vorhandene Verzeichnisstruktur soll über die RS232Schnittstelle übertragen werden.

3. Datei übertragen:Den Inhalt einer Datei über die RS232 Schnittstelle übertragen.

Keine der Funktionen kann parallel zu einer anderen ausgeführt werden, was die Entwick-lung einer Architektur auf Basis eines Automaten möglich macht. Diese Architektur wurdegewählt, weil die Realisierung der Software aus dem Design des Automaten einfach undschnell umzusetzen ist.

Die Software besteht somit aus einem Hauptautomaten der drei Subautomaten beinhaltet.In den Subautomaten sind die drei Funktionen eingefügt. Im Anhang A befinden sich die vierAutomaten als UML-Diagramm.

Datenempfang

Interrupts übernehmen den Empfang der Nachrichten von der CAN-Hardware. Dieses istnötig, weil 11 Mobs für den Empfang von CAN-Nachrichten nur einen Puffer für maximal4ms bieten, was durch den Zyklusaufbau (Abb. 4.15) vorgegeben ist, aber das Schreiben


von Daten auf einer SD Memory Card mit FAT Dateisystem im schlimmsten Fall durch dieVerwaltung des Dateisystems länger dauert.

Verzeichnisstruktur

Für den Aufbau der Verzeichnisstruktur sind drei Anforderungen zu beachten.

1. Daten sollen eindeutig identifizierbar sein.

2. Die Struktur muss übersichtlich sein.

3. Das Rootverzeichnis eines FAT16 Dateisystems darf nicht mehr als 512 Einträge ent-halten.

Abbildung 4.31.: Verzeichnisstruktur auf einer SD Memory Card

Für die Erstellung der Verzeichnisse und Dateien dienen die Referenznachrichten vom TimeMaster, weil sie periodisch über den CAN-Bus gesendet werden und eine Zeit enthalten. DieVerzeichnisstruktur besteht somit aus Verzeichnissen die nach dem Datum (YY_MM_DD)benannt sind und darin befindliche Dateien die als Namen die Uhrzeit (hh_mm_ss.DAT) ent-halten. Ein Beispiel der Verzeichnisstruktur ist in der Abbildung 4.31 zu sehen.

4.5.3. Auslesen der Daten

Für das Auslesen der Nachrichten gibt es zwei Möglichkeiten.


Communicator Datalogger

CAN-Bus

RS232

Abbildung 4.32.: RS232 Verbindung zwischen Communicator und Datenlogger

Auslesen über Wireless LAN

Der WiPort im Communicator bietet zwei separate RS232 Schnittstellen, wovon eine internfür die Live-Übertragung verwendet wird und die zweite über eine direkte Verbindung vomDatalogger, was in der Abbildung 4.32 dargestellt ist. Die Übertragung der Daten über denCAN Bus zum Communicator wird nicht genutzt, weil die zur Verfügung stehenden Zeitfens-ter (siehe Abbildung 4.15) keine große Datenrate ermöglichen könnten. Für den CAN-Busmüsste ein neuer Bus-Modus entwickelt werden der z.B. nur eine Kommunikation zwischenden beiden Komponenten erlaubt. Da das für ein sicherheitskritisches Steuerungssystem fa-tal wäre, wenn es keine Sensordaten mehr bekommt und dadurch ein zu komplexes Anforde-rungsprofil für den Bus-Modus entstehen würde, wird diese Variante der Datenübertragungnicht berücksichtigt.

Die Kommunikation zwischen dem Datalogger und dem Communicator ist Unidirektional inRichtung des Communicators. Die Befehle für den Datalogger werden über den CAN-Busübertragen und sind in der Header-Datei vom Datalogger zu entnehmen.

Zum Auslesen des Inhaltes einer SD Memory Card bietet der Datalogger zwei Funktionenan, für die zwei Protokolle für die Kommunikation erstellt werden.

1. Auslesen der Verzeichnisstruktur:Die Funktion ermöglicht es, die Verzeichnisstruktur einer SD Memory Card mit demDatalogger zu lesen und über Wireless LAN von der Leitstandsoftware zu empfangen.Damit die Leitstandsoftware die eintreffenden Daten interpretieren kann, ist das in derAbbildung 4.33 als Zustandsdiagramm dargestellte Protokoll designed worden. DerDatalogger unterstützt hierbei eine Verzeichnistiefe von maximal 5 Ebenen.

2. Dateninhalt auslesen:Damit der Leitstand den Empfang einer Datei interpretieren kann, muss er das Proto-koll aus der Abbildung 4.34 implementieren.

Für den Befehl zum Auslesen einer Datei muss für diese eine Identifizierungsnummer in derCAN-Nachricht angegeben werden. Die Abbildung 4.35 zeigt wie diese Identifizierungsnum-


Abbildung 4.33.: Protokoll für den Empfang der Verzeichnisstruktur

Abbildung 4.34.: Protokoll für den Empfang des Inhalts einer Datei

Abbildung 4.35.: Identifizierungsnummer einer Datei

mer erstellt wird. Ein Beispiel für die Zuordnung der Identifizierungsnummern nach Ablaufdes Algorithmus ist in der Abbildung 4.36 dargestellt.

Das Problem mit den Baudraten und deren Fehler, was bei dem Communicator zu dem De-sign mit zwei Mikrocontroller führte (Kap. 4.3.1), ist durch die direkte Verbindung zum WiPortauch bei dieser Komponente vorhanden. Eine Lösung die das Problem beheben könnte wä-re z.B. wie bei dem Communicator einen zweiten Mikrocontroller einzusetzen, wobei aberbeachtet werden muss, dass bei dem Datalogger zwei SPI Slaves vorhanden wären, dieüber entsprechende Ports vom SPI Master gesteuert werden müssten. Durch den Einsatzeines externen Oszillators mit 3,6864MHz für die UART Schnittstelle des AVR Mikrocon-trollers könnte die Übertragungsrate auf 230.4kbps angehoben werden. Ein Oszillator miteiner höheren Frequenz lässt sich nicht einsetzen, weil die Spezifikation des AT90CAN128maximal 1

4des Systemtakts für einen externen Taktgeber spezifiziert. Aufgrund der kurz-


Abbildung 4.36.: Zuordnung der Identifizierungsnummern

en Entwicklungszeit ist keiner der Lösungsansätze umgesetzt worden. Für die Übertragungwurde die größtmögliche Bautrate von 57.6kbps im “Double Speed Mode” eingestellt, wasfür das Auslesen großer Datenmengen unbrauchbar ist.

Auslesen durch Entnehmen der SD Memory Card

Eine andere Möglichkeit zum Auslesen der aufgezeichneten Daten, ist das Entnehmen derSD Memory Card aus dem Datalogger. Diese Variante wird durch das FAT Dateisystem be-günstigt, weil dadurch mit allen gängigen Betriebssystem die Daten gelesen werden könnenund keine Software zum Lesen der Daten entwickelt werden muss.

5. Qualitätssicherung

5.1. Fehlermanagement im Telemetriesystem

Sensormodul „x“

CAN-Bus

Gateway „x“(optional)Steuerungsmodul „x“ System Checker

Time Master „x“ Communicator Datalogger

Abbildung 5.1.: System Checker im Systemdesign

Für ein Fehlermanagement innerhalb des Systems ist die Komponente System Checker indas Systemdesign integriert (Abb. 5.1). Der System Checker ist direkt mit dem CAN-Busverbunden und kann somit die Fehler auf dem Bus erkennen, analysieren bzw. anzeigenund beheben, wenn es möglich ist.

FehlererkennungDamit der System Checker nicht nur die Nachrichten auf dem CAN-Bus analysieren kann, ist

TTCAN Matrixzyklus (40ms)Basiszyklus 0 (10ms) Steuerung

198 0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44 46Zeit für Fenster 400µs 2,4ms 400µs 400µs 400µs 400µs 400µs 400µs 400µs 400µs 400µs 400µs 400µs 400µs 400µs 400µs 400µs 400µs 400µs 400µsIdentifizierung 0x01 – 0x07 Reserviert für 50Hz und 100Hz Daten 0x09 0x09


Zeit für Fenster 400µs 2,4ms 2ms 400µs 400µs 400µs 400µs 400µs 400µs 400µs 400µs 400µs 400µs 400µs 400µs 400µsIdentifizierung 0x01 – 0x07 Reserviert für 50Hz und 100Hz Daten 0x35 – 0x3A (6 Nachrichten) 0x3B 0x33 0x34


Zeit für Fenster 400µs 2,4ms 400µs 400µs 400µs 400µs 400µs 400µs 400µs 400µs 400µs 400µs 400µs 400µs 400µs 400µs 400µs 400µs 400µs 400µsIdentifizierung 0x01 – 0x07 Reserviert für 50Hz und 100Hz Daten

Basiszyklus 3 (10ms) Fehlerkontrolle148 150 152 154 156 158 160 162 164 166 168 170 172 174 176 178 180 182 184 186 188 190 192 195

Zeit für Fenster 400µs 2,4ms 400µs 400µs 400µs 400µs 400µs 400µs 400µs 400µs 400µs 400µs 400µs 400µs 400µs 400µs 400µs 600µs 600µsIdentifizierung 0x01 – 0x07 Reserviert für 50Hz und 100Hz Daten 0x09 0x0D 0x0E 0x0C 0x0A

Scheduler- Zeit

Scheduler- Zeit

Scheduler- Zeit

Scheduler- Zeit

Abbildung 5.2.: Fehlerkontrolle im TTCAN Zyklusaufbau

5. Qualitätssicherung 81

ein extra Basiszyklus für das Fehlermanagement designed worden, welches die Abbildung5.2 zeigt. In diesem Zeitfenster (rot markiert) können einzelne Komponenten eine Status-nachricht zum System Checker senden. Durch diese Art der Fehlererkennung ist es möglichSensor- oder Softwarefehler von einzelnen Komponenten zu ermitteln. Auch Komponenten,wie der Datalogger, die keinen Echtzeitscheduler für die Steuerung des TTCAN haben, kön-nen diese Funktionalität nutzen. Dafür gibt es die 600µs Zeitfenster, die am Ende des Basis-zyklus 3 sind. Innerhalb dieser Zeitfenster kann der System Checker, wie in der Abbildung 5.3

Abbildung 5.3.: Fehlerkontrolle bei Komponenten ohne TTCAN-Funktionalität

dargestellt, eine spezielle CAN-Nachricht1 an die Komponente ohne TTCAN-Funktionalitätsenden und diese Komponente sendet automatisch durch die “Automatic Reply” Konfigura-tion des Mobs die Statusnachricht zeitgesteuert auf den CAN-Bus.

Fehleranalyse und FehleranzeigeEine Komponente besitzt eine Header-Datei, in der der Inhalt einer Statusnachricht definiertist. Der System Checker kann mittels dieser Datei die Nachricht analysieren. Durch z.B. eineFehlercodetabelle und einem Display kann dieser Status für einen Anwender oder Entwicklerdes Telemetriesystems visualisiert werden, um entsprechend darauf zu reagieren.

FehlerbehebungWenn der System Checker einen Fehler bei einem Modul erkennt und dieser sich durch z.B.ein Reset der Komponente beheben lässt, kann der System Checker diesen Reset über eineCAN-Nachricht veranlassen. Möglich wären auch spezielle Schaltungen oder Steuerungen,die von dem System-Checker gesteuert werden, um das System in einen sicheren Zustandzu versetzen.

5.1.1. Realisierung der Fehlerkontrolle

Die Hardware wird in der Arbeit von Schuckert (2007) erstellt. Eine softwareseitige Im-plementierung ist nur teilweise erfolgt. Einige Komponenten im Telemetriesystem senden

1Remote Message


Basiszyklus 0 Basiszyklus 1 Basiszyklus 2 Basiszyklus 3

Abbildung 5.4.: Statusnachrichten von Komponenten

Statusnachrichten, wie in der Abbildung 5.4 anhand einer Oszilloskopaufnahme im grünenBereich zu sehen ist. Diese Statusnachrichten sind in jeweils einer Header-Datei für eineKomponente definiert. In dem folgenden Listing 5.1 ist ein Auszug der Header-Datei vomDatalogger zu sehen.

1 #define CANapp_ERR_DATALOGGER_OK (0x00)2 #define CANapp_ERR_DATALOGGER_CARD_NOT_FOUND (0x01)3 #define CANapp_ERR_DATALOGGER_CARD_NOT_WRITEABLE (0x02)4 #define CANapp_ERR_DATALOGGER_FILE_NOT_OPEN (0x03)5 #define CANapp_ERR_DATALOGGER_FOLDER_NOT_OPEN (0x04)6 #define CANapp_ERR_DATALOGGER_BUS_MODE_OFF (0x05)7 #define CANapp_ERR_DATALOGGER_SWITCH_OFF (0x06)8 #define CANapp_ERR_DATALOGGER_CARD_FULL (0x07)

Listing 5.1: Auszug der Header-Datei vom Datalogger

In diesem Listing sind alle Statusmeldungen vom Datalogger aufgelistet. Der Communicatorsendet mit seiner Statusnachricht den Status des Schedulers. Dieser ist in der zugehörigenBibliothek definiert. Eine komplexe Überprüfung des Communicators auf der Softwareebeneist nicht realisiert.


5.2. Testorganisation

Die Möglichkeit zum Testen ist durch die parallele Entwicklung des HAWK07 eingeschränkt,weil der Rennwagen während der Konstruktion nicht zum Testen zur Verfügung steht. Durchdiese Umstände ist das folgende Testvorgehen entstanden.

5.2.1. Testvorgehen

ModultestimLabor

Integrationstestim

Labor

SystemtestimLabor

Systemtestim

Rennwagen

Testvorgehen

Abbildung 5.5.: Vorgehen beim Testen der Komponenten

Die Abbildung 5.5 zeigt in welcher Reihenfolge die Tests durchgeführt werden. Bis auf einenSystemtest werden alle anderen Tests im Labor durchgeführt, wobei einige Schnittstellenzu einem Sensor z.B. durch einen Frequenzgenerator simuliert werden. Bei dem Modultestwerden vorwiegend White-Box Tests2 durchgeführt. Diese Testmethode hat den Vorteil dasz.B. bei dem Datalogger die Eingaben so gewählt werden, dass jeder Zustand durchlaufenund getestet wird. Die Black-Box-Tests3 werden in den darauf folgenden Tests angewendet.Hier werden z.B. Äquivalenzklassen für korrekte und falsche Eingaben definiert. Ein Beispieldafür wäre die Äquivalenzklassendefinition für einen Steuerbefehl wie der Reset. Von diesemSteuerbefehl werden gültige und ungültige Eingaben für eine Komponente definiert und dieAusgabe ausgewertet. Diese Tests werden teilweise von zwei Personen durchgeführt undausgewertet, damit die Qualität der Tests steigt und so mehr Fehler entdeckt werden.

5.2.2. Testwerkzeuge

In der Abbildung 5.6 ist ein Überblick über die wichtigsten Werkzeuge zum Testen dargestellt.In der folgenden Aufzählung werden die Werkzeuge kurz beschrieben.

2Tests unter Berücksichtigung der Programmlogik3Eingaben werden aus der Spezifikation abgeleitet


Oszilloskop

CAN-Sniffer LabVIEWOberflächeMultimeter

CAN-Fluter

Daten-analyse-software

Testwerkzeuge

Leitstand-software

Abbildung 5.6.: Werkzeuge zum Testen der Komponenten

• Multimeter 4:Das Multimeter wird für Hardwaretests eingesetzt um Spannungen, Ströme und Leit-fähigkeit zu messen. Hiermit kann zum Teil die hardwareseitige Funktionsfähigkeit ge-testet werden.

• Oszilloskop5:Ein sehr vielseitiges Werkzeug zum Testen von Hard- und Software ist das Oszilloskop.Zu den Hardwaretests gehören z.B. das Testen von Pegelwandlern die im Dataloggereingesetzt werden und ein hochfrequentes Signal von 5V auf 3.3V wandeln. Software-tests erfolgen z.B. über das visualisieren von Nachrichten auf dem CAN-Bus, um diezeitlichen Abhängigkeiten zu testen.

• CAN-Sniffer:Nachrichten, die über den CAN-Bus versendet werden, können mit dem CAN-Snifferempfangen und dargestellt werden. Dazu wurde eine Software für den AT90CAN128Mikrocontroller entwickelt, der direkt mit dem CAN-Bus verbunden wird. Dieses Werk-zeug wurde selber erstellt, weil keine anderen Werkzeuge für eine Analyse des CAN-Busses zu Verfügung standen. Der CAN-Sniffer kommuniziert mit einem Terminal-Programm auf einem PC über die RS232 Schnittstelle, um die empfangenen Datenzu Visualisieren. Mit dem CAN-Sniffer kann getestet werden, ob eine KomponenteCAN-Nachrichten senden kann. Es ist möglich den Inhalt einer CAN-Nachricht zu va-lidieren, wenn Nachrichten empfangen werden.

• CAN-Fluter:Der CAN-Fluter besteht, wie der CAN-Sniffer, aus einem AT90CAN128 Mikrocontrol-ler und einer speziellen Software. Er kann Datenlasten auf dem zeitgesteuerten CAN-

4DIGITAL MULTIMETER EX-530http://www.extech.com/instrument/products/alpha/ex530.html

5PicoScope 3000 serieshttp://www.picotech.com/picoscope-3000.html

http://www.extech.com/instrument/products/alpha/ex530.html

http://www.picotech.com/picoscope-3000.html


Bus erzeugen um z.B. Schnittstellen von Komponenten zu testen. Die Nachrichten,die der CAN-Fluter auf den Bus sendet, sind so definiert, dass sie anschließend vali-diert werden können. Diese Funktionalität ermöglicht das Testen von Datenverlust beiKomponenten, die als Gateway dienen oder Komponenten, die die Daten aufzeichnen.

• Datenanalyse-Software:Diese Software ist in Java programmiert und kann die von CAN-Fluter gesendetenNachrichten validieren. Sie kann Anzeigen, wieviele Nachrichten aufgezeichnet oderempfangen wurden und wieviele Nachrichten davon verloren gegangen sind.

• Leitstand-Software6:Die Leitstandsoftware dient der Kommunikation zwischen dem Leitstand und demCommunicator. Sie bietet die Funktion Black-Box-Tests an einzelnen Modulen bis zumganzen System durchzuführen. Das ist möglich durch die Erstellung beliebiger Nach-richten, wodurch gültige, ungültige oder Nachrichten die Werte im Grenzbereich bein-halten, versendet werden können.

• LabVIEW Oberfläche:Diese grafische Benutzerschnittstelle ist parallel zu dieser Arbeit in einer Studienarbeitentstanden (Schlaack, 2007). Sie zeigt die Werte aller Komponenten an, die für das Te-lemetriesystem wichtig sind. Damit kann das System auf teilweise korrekte Funktions-weise getestet werden. Zeitliche Abhängigkeiten des TTCAN kann dieses Programmnicht erkennen.

5.2.3. Gewünschte Testergebnisse

Damit die Ausgaben beim Testen auch validiert werden können, müssen die korrekten Aus-gaben vorher ermittelt werden. Diese korrekten Ausgaben werden durch das Anforderungs-profil aus dem Kapitel 2.2 und dem kompletten Design erstellt. Die wichtigsten funktionalenund korrekten Ausgaben für diese Arbeit zeigt die folgende Auflistung auf einer hohen Ab-straktionsebene.

• Nachrichten dürfen bei der live Übertragung nicht verloren gehen.

• Alle Nachrichten sollen auf die SD Memory Card gespeichert werden.

• Der Inhalt einer Nachricht darf nicht verändert werden.

6siehe Kapitel 4.4


5.3. Testdurchführung

Die Testdurchführung beschreibt welche Tests durchgeführt worden sind, um die Qualitätdes Systems sicher zu stellen.

5.3.1. Modultests

Bei den Modultests werden die Komponenten CAN-Bibliothek, Communicator, Leitstandsoft-ware und Datalogger einzeln getestet.

CAN-Bibliothek

Die CAN-Bus Bibliothek wurde durch das White-Box-Verfahren getestet. Hier wurden syste-matisch alle Funktionen der Bibliothek aufgerufen und die Ausgaben kontrolliert. Die Ausga-ben sind teilweise durch die RS232 Schnittstelle und einer Textausgabe in einem Terminal-Programm erfolgt. Der CAN-Sniffer wurde verwendet, um die Nachrichten zu testen, diemittels der Bibliothek versendet wurden.

Communicator

Beim Communicator fiel die hohe Temperatur des WiPort Moduls auf und es wurde ein Dau-ertest unter Volllast durchgeführt. Dazu wurde der CAN-Fluter so konfiguriert, dass der CAN-Bus voll ausgelastet ist und der WiPort diese Nachrichten über Wireless LAN versendet. Die-se Konfiguration erzeugt beim WiPort den höchsten Stromverbrauch und dadurch eine hoheWärmeentwicklung.

Testeigenschaften:

• Volle Busauslastung

• 24◦C Raumtemperatur

• 4 Stunden Betrieb

• geschlossenes Gehäuse


Testergebnis:Nach Ablauf der 4 Stunden hatte die Oberfläche des WiPort eine Temperatur von 52,9◦C,was bei einer Betriebstemperatur von maximal 70◦C keine Störungen verursachte.

Die Software wurde durch ein Black-Box-Verfahren getestet, indem der CAN-Fluter den CAN-Bus mit Nachrichten voll auslastet. Diese Nachrichten werden durch die Wireless LAN Ver-bindung beim Leitstand aufgezeichnet und anschließend mit der Datenanalysesoftware ge-testet. In der Tabelle 5.1 ist das Ergebnis vom Lasttest dokumentiert. Zu sehen ist, dass es

Baudrate Nachrichten pro Matrixzyklus Nachrichtenverlust460.8kbps 96 0,70%

84 0,46%80 0,00%

< 80 0,00%921.6kbps 96 0,00%

100 0,00%

Tabelle 5.1.: Ergebnis vom Lasttest beim Communicator

bei der RS232 Baudrate von 460.8kbps zwischen dem WiPort Communicator Module7 unddem WiPort zu Nachrichtenverlust kommt wenn der Bus voll ausgelastet ist.

Leitstandsoftware

Durch den CAN-Sniffer wurden bei dieser Software die Ausgaben der Event-Buttons, die sichauf der grafischen Oberfläche befinden, getestet. Die Synchronisation eingehender Nach-richt wurde durch die LabVIEW Oberfläche getestet. Weiter wurde die Leitstandsoftwarekeinen aufwendigen Tests unterzogen.

Datalogger

Die Funktionsweise der Hardware bzw. des SD Memory Card Adapters wurde mit dem Oszil-loskop und dem Multimeter getestet, damit vor Einlegen der SD Memory Card sichergestelltist, dass die Umwandlung von 5V auf 3.3V korrekt ist.

Weil die Softwarearchitektur des Dataloggers auf einem Automaten basiert, wurden die Ein-gaben für die Tests so gewählt, dass jeder Zustand des Automaten durchlaufen wird. Die

7siehe Kapitel 4.3


Ausgabe erfolgte über Leuchtdioden und Textausgabe in einem Terminal-Programm. Mit Hil-fe des CAN-Fluters wurde anschließend getestet, ob kein Datenverlust bei der Aufzeichnungentsteht.

Hardwaretest auf einem Hydropulser

Alle Komponenten des Systems wurden einem Beschleunigungstest unterzogen. Dieser Testsoll die Beschleunigung in dem Rennwagen simulieren, damit die Hardware vor dem Einbaugetestet wird.

Testeigenschaften:

• Testdauer pro Modul: 55s

• Amplitude: 10mm

• Frequenz: 5-10 Hz (linearer Anstieg über Testdauer)

• Getestete Achse: y-Achse

• Beschleunigungsmessung mit Beschleunigungsaufnehmer

• Messauswertung: Beschleunigungsaufnehmer⇒Messverstärker Spider 8⇒ Softwa-re Diadem (NI)

Testdurchführung:Die Module wurden einzeln auf dem Hydraulikzylinder mit Kabelbindern befestigt, was in der

Abbildung 5.7.: Communicator und Datalogger auf dem Hydropulser


Abbildung 5.7 dargestellt ist. Je Modul gab es einen Testdurchlauf entsprechend den obengenannten Testeigenschaften.

Testergebnis:Die beiden Diagramme in den Abbildungen 5.8 und 5.9 zeigen die vom Beschleunigungs-

0 5 10 15 20 25 30 35 40 45 50 55-80-70-60-50-40-30-20-10

010203040506070

Beschleunigungstest vom Communicator

Zeit in s

Bes

chle

unig

ung

in m

/s²

Abbildung 5.8.: Diagramm der ermittelten Beschleunigungswerte vom Communicator

0 5 10 15 20 25 30 35 40 45 50 55-80-70-60-50-40-30-20-10

010203040506070

Beschleunigungstest vom Datalogger

Zeit in s

Bes

chle

unig

ung

in m

/s²

Abbildung 5.9.: Diagramm der ermittelten Beschleunigungswerte vom Datalogger

aufnehmer aufgezeichneten Werte. Die größte gemessene Beschleunigung beim Communi-cator ist 70, 92m/s2 und beim Datalogger 72, 76m/s2.


Bei der anschließenden Sichtprüfung wurden keine mechanischen Veränderungen, außerein leicht angescheuerter Schrumpfschlauch im Communicator, festgestellt. Bei einem Funk-tionstest konnten keinerlei Probleme festgestellt werden.

Spannungsvario-Test

Bei diesem Test wurden bei dem Communicator und dem Datalogger verschiedene Span-nungen angelegt und die Funktionsfähigkeit der Komponenten getestet. Getestet wurdenhier ausschließlich der untere Grenzbereich, weil der obere Grenzbereich durch die Spezi-fikation der Spannungswandler gegeben ist und zu einem Defekt bei Überspannung führenkann.

CommunicatorSpannung - Netzteil Spannung - Evaluation Board Boottest (>1000) Lasttest9,26V 4,96V bestanden bestanden5,60V 4,20V bestanden bestanden

Tabelle 5.2.: Spannungstest beim Communicator

DataloggerSpannung - Netzteil Spannung - Evaluation Board Boottest (>1000) Lasttest9,26V 5,05V bestanden bestanden6,77V 4,49V bestanden bestanden

Tabelle 5.3.: Spannungstest beim Datalogger

In den beiden Tabellen 5.2 und 5.3 sind die Ergebnisse des Tests dokumentiert. Dierot markierten Spannungen sind für den Mikrocontroller außerhalb der Spezifikation. DerAT90CAN128 Mikrocontroller hat eine sichere Betriebsspannung von 4, 5V ≤ U ≤ 5, 5Vbei 16MHz Systemtakt.

Die Mikrocontroller der beiden Komponenten schalten bei den folgenden Spannungen ab.

• Communicator: 5,63V Spannung-Netzteil oder 4,16V Spannung-Board durch Brow-nout8 Erkennung vom Mikrocontroller

• Datalogger: 6,43V Spannung-Netzteil oder 4,21V Spannung-Board durch eingebautenUnterspannungssensor

8Spannungsabfall


5.3.2. Integrationstests

Die Integrationstests sind vorwiegend zum Testen einiger weniger Module eingesetzt wor-den. Diese Tests sind durch die modulare Architektur und deren Entwicklungsfortschritt er-zwungen, weil das Gesamtsystem erst in einer späten Phase der Entwicklung komplett rea-lisiert wurde.

Subsysteme, die in ihrer Funktionalität getestet wurden sind im Folgenden aufgelistet.

• Time Master / Communicator / Leitstandsoftware:Mit diesem Subsystem kann getestet werden, ob die bidirektionale Kommunikationzwischen dem Communicator und dem Leitstand funktioniert, die Synchronisation inder Leitstandsoftware die Daten richtig analysiert und das Senden von Steuernach-richten die an den Time Master adressiert sind, auch vom Time Master empfangenwerden.

• Time Master / Sensormodul “x” / Datalogger:Diese Kombination der Komponenten dient zum Testen des zeitgesteuerten Bussesund der Datenaufzeichnung. Für diesen Test wurde kein bestimmtes Sensormodulgewählt, weil es in diesem Fall nur wichtig war, dass Daten über den CAN-Bus trans-portiert werden. Anhand der aufgezeichneten Daten kann überprüft werden, ob sievollständig und korrekt sind.

5.3.3. Systemtests

Die Systemtests beinhalten Tests, die das gesamte Telemetriesystem einschließen. Hierfürwurden ausschließlich Black-Box-Tests verwendet unter den Aspekten der Leistung und Zu-verlässigkeit. Dazu wurde die Anforderungsbeschreibung aus dem Kapitel 2.2 mit den Leis-tungen des Systems verglichen. Diese Tests fanden im Labor und im Rennwagen statt.

Tests im Labor

Alle Komponenten einschließlich der Sensoren des Telemetriesystems sind im Labor mitein-ander verbunden worden, um die Leistung und Zuverlässigkeit zu testen. Dazu wurde dasSystem mehrere Stunden betrieben und nach Auffälligkeiten in den Ausgaben untersucht.

Da die LabVIEW Oberfläche alle Sensordaten visualisiert, ist es möglich damit die Funkti-onsfähigkeit des Systems von den Sensormodulen, Gateways, CAN-Bus, Live-Übertragungund Leitstandsoftware zu testen.


Basiszyklus 0 Basiszyklus 1 Basiszyklus 2 Basiszyklus 3

Abbildung 5.10.: Oszilloskopaufnahme vom CAN-Bus

Mit dem PicoScope wurde zusätzlich getestet, dass die Nachrichten über dem CAN-Busübertragen werden und in dem richtigen Zeitfenster sind. Eine Aufnahme in der Abbildung5.10 zeigt das Ergebnis, indem alle Nachrichten korrekt auf dem CAN-Bus vorhanden sind.

Tests im Rennwagen

Nachdem die Tests im Labor durchgeführt wurden ging es an den Einbau des Telemetrie-systems in den HAWK07 Rennwagen. Nachdem das System eingebaut war, mussten einigespezielle Tests durchgeführt werden, die im Labor nur schwer zu testen sind.

• Test bei laufendem Motor:Dieser Test musste durchgeführt werden, weil bei laufendem Motor viele elektrischeStörungen verursacht werden, die den Betrieb der Mikrocontroller einschränken kön-nen. Mit dem Oszilloskop wurden die Störungen im Bordnetz beobachtet und kon-trolliert ob dadurch Komponenten beeinflusst werden. Die Abbildung 5.11 zeigt ei-ne Oszilloskopaufnahme, in der die Spannungsschwankungen dargestellt sind. Fürdie tatsächlichen Werte der Spannung muss die Y-Achse mit 10 multipliziert werden,wodurch deutlich wird, dass die Spannung zwischen ca. 6V und 18V schwankt. Mitder LabVIEW Oberfläche wurde erkannt, dass diese Störungen keine Komponente imTelemetriesystem beeinträchtigten. Dieses Ergebnis bestätigte zusätzlich der spätereEinsatz des Systems.

• Entfernungstest:Bei der live Übertragung der Daten mit einer drahtlosen Verbindung zwischen dem


Abbildung 5.11.: Spannungsschwankungen vom Bordnetz des Rennwagens

Rennwagen und dem Leitstand ist die maximale Entfernung für die Leistung dieserFunktion entscheidend. Für die Bestimmung der Entfernung hat sich der Rennwagenmit laufenden Motor von dem Leitstand entfernt. Dabei wurde beobachtet, dass abeiner Entfernung von ca. 150 Meter Daten verloren gehen, wenn die Kopfstütze ausCarbon9 die Sichtverbindung zwischen der Antenne am Router und der am Rennwa-gen unterbricht. Bei Sichtverbindung wurde eine maximale Entfernung von ca. 640Meter gemessen, was aber auch stark wetterabhängig ist, weil bei hoher Luftfeuchtig-keit die Signalqualität sinkt. Für den Einsatz auf der Teststrecke und bei Wettbewerbenist die Entfernung für einen fehlerfreien Betrieb ausreichend.

• Test in einer Umgebung mit viel Wireless LAN Verkehr:Dieser Test ist bei dem Formula Student Wettbewerb in Hockenheim durchgeführt wor-den, weil dort eine hohe Anzahl an Access-Points10 und Wireless LAN Teilnehmernvorhanden war. Dazu wurde bei jedem dynamischen Ereignis11 das Telemetriesystemmittels der LabVIEW Oberfläche beobachtet. Das Ergebnis dieses Tests ist, dass denganzen Wettbewerb über keine negativen Beeinträchtigungen an der live Übertagungfestgestellt wurden.

9Kohlenstofffaserverstärkter Kunststoff der eine abschirmende Eigenschaft besitzt.10drahtloser Zugangsknoten11Beschleunigungsrennen, Kreisfahrt, Ausdauerrennen

6. Zusammenfassung und Ausblick

Dieses letzte Kapitel gibt einen Überblick wie diese Arbeit verlaufen ist, welche weiterenEinsatzmöglichkeiten es gibt und was für Veränderungen bzw. Weiterentwicklungen in derZukunft erfolgen könnten.

6.1. Zusammenfassung

6.1.1. Ausgangssituation

Das HAWKS Racing Team baut Rennwagen für die Formula Student Wettbewerbe inDeutschland und Italien. Dieses Team hat in der Vergangenheit zwei Boliden gebaut undmöchte bei der Entwicklung nachfolgender Rennwagen die Vorteile eines Telemetriesystemsnutzen, um weiter oben in der Rangliste zu erscheinen.

Da noch kein Telemetriesystem im HAWKS Racing Team vorhanden war, war es nötig einneues System zu designen und zu realisieren. Diese Arbeit stand vor den Aufgaben eine,Systemarchitektur zu erstellen und darauf aufbauend die Datenübertragung und Datenspei-cherung zu ermöglichen.

6.1.2. Durchführung

Nachdem eine modulare Systemarchitektur erstellt wurde, ist die Datenübertagung per CAN-Bus realisiert worden. Bei der Entwicklung des CAN-Busses wurde viel Wert auf die Echt-zeitfähigkeit gelegt, wodurch ein zeitgesteuerter CAN-Bus entstanden ist. Anschließend sindzwei Komponenten des Telemetriesystem Communicators und Dataloggers entstanden, diees ermöglichen Daten per Wireless LAN zu übertragen und Daten auf einer SD MemoryCard zu speichern. Innerhalb dieser Arbeit ist eine Reihe an Software entstanden, die z.B.Daten am Leitstand von dem Communicator empfangen oder die CAN-Bibliothek, die dasEmpfangen und Senden von Nachrichten über den CAN-Bus vereinfacht. Weitere Softwareist für die beiden Komponenten entstanden und natürlich auch für verschiedenste Tests.

6. Zusammenfassung und Ausblick 95

6.1.3. Fazit

Entstanden ist ein Telemetriesystem mit ersten sinnvollen Funktionalitäten wie z.B. die li-ve Datenauswertung und -speicherung von der Motorsteuerung, dem Lenkwinkel und dervier Raddrehzahlsensoren. Für weitere Entwicklungen besitzt dieses Telemetriesystem vielPotenzial, weil es durch die modulare Architektur um viele Komponenten erweitert werdenkann.

Auch wenn andere Teammitglieder die Daten des Dataloggers nicht auswerten können, weildafür keine Software existiert, ist der Datalogger für das Gesamtsystem eine große Berei-cherung. Ein Vorteil bei dieser Komponente ist, dass die Daten auch noch ein halbes Jahrspäter, wenn es eine Software zur Visualisierung der Daten gibt, wichtige Ergebnisse lie-fern kann. Während der Entwicklung war es schon möglich Tests durch die aufgezeichnetenDaten durchzuführen.

Der Communicator ist beim HAWK07 während der Tests und dem Wettbewerb in Hocken-heim voll zum Einsatz gekommen und liefert wichtige Telemetriedaten. Überrascht hat dieseKomponente mit der großen Entfernung bei der Datenübertragung, was auch durch den be-nutzen Router entstanden ist.

Bei der Realisierung der Hardware sind zum Teil die harten Anforderungen der verschie-denen Umgebungsbedingungen vernachlässigt worden, wodurch Gehäuse entstanden sind,die nicht ausreichend vor Wasser geschützt waren und zusätzlich versiegelt werden muss-ten. Auch die Auswirkung der hohen Vibrationen im Rennwagen muss durch Langzeittestserst noch ermittelt werden.

Für das HAWKS Racing Team ist der Anfang einer wertvollen Entwicklung entstanden, wo-mit das Ziel, dass andere Mitglieder erste relevante Daten über den Rennwagen erhalten,erfolgreich realisiert wurde.

6.2. Ausblick

6.2.1. Einsatz

Diese Arbeit bietet außer dem Einsatz im Rennwagen weitere Möglichkeiten die im Folgen-den vorgestellt werden.


Datenspeicherung

Die Datenspeicherung könnte z.B. auch im Bereich der Versicherungen interessant sein.Hier ist es vorstellbar, dass jedes Serienauto einen solchen Datalogger mit einigen rele-vanten Sensoren besitzt, damit nach einem Unfall der Verlauf und eventuell die Ursachebestimmt werden kann.

Kabellose Datenübertragung per WLAN

Diese Komponente lässt sich in Systemen einsetzen wo eine drahtlose Kommunikation reali-siert werden soll und keine Echtzeitanforderung an die Datenübertragung gestellt wird. ZumBeispiel könnte es als Schnittstelle in Service-Werkstätten genutzt werden, um Daten miteinem System auszutauschen.

TTCAN

Durch das Design des TTCAN lassen sich die Latenzzeiten der Datenübertragung genaubestimmen. Das ermöglicht den Einsatz in beliebigen verteilten Systemen, wo harte Echt-zeitanforderungen gestellt werden.

6.2.2. Veränderungen und Weiterentwicklung

Komponenten-Hardware

Wichtig bei einem Rennwagen ist immer ein niedriges Gewicht zu erreichen. Da die in dieserArbeit erstellten Komponenten Prototypen sind, können sie im Bereich der Hardware starkverbessert werden.

Bei dem Communicator ist es möglich ein Platinenlayout zu erstellen, indem die drei Moduleauf einer Platine platziert werden und nur die nötigsten Verbindungen enthält. Das WiPortCommunication Modul des Communicator kann durch einen anderen Mikrocontroller z.B.dem ATmega32 mit 16MHz ersetzt werden, ohne viel an der Software ändern zu müssen.Es kann auch ein anderer Mikrocontroller, wie der LPC2129 von NXP benutzt werden, umdie beiden Module CAN Communication Modul und WiPort Communication Module zu ver-einen.

Der Datalogger mit dem SD Memory Card Adapter kann ebenfalls durch ein neues Platinen-layout verbessert werden. Zusätzlich sollte bei diesem Modul das Auslesen der Daten mit


einer hohen Datenrate ermöglicht werden, was momentan durch die Fehler beim konfigurie-ren der Baudraten eingeschränkt ist.

Nachdem serienreife Platinen entstanden sind, ist es sinnvoll Gehäuse, die direkt auf dieKomponenten abgestimmt sind, zu erstellen. Diese Gehäuse müssen dann die SchutzartIP167 einhalten. Das hat den entscheidenden Vorteil, dass die Hardware höchsten Gradesvor Fremdkörpern und zeitweilig vor Wasser geschützt ist. Ein sicheren Schutz vor hohenVibrationen kann durch den Einsatz von speziellen Harz erreicht werden, mit dem das Ge-häuse ausgegossen wird.

Leitstandsoftware

Die Leitstandsoftware besitzt eine grafische Oberfläche die funktional aber nicht benutzer-freundlich ist. Diese Software könnte unter den Betrachtungen der Usability eine neue grafi-sche Oberfläche bekommen, die mehr Information über den Systemstatus liefert und durchzusätzliche Funktionen wie z.B. auto-reconnect2 ergänzt wird.

CAN-Bus

Der CAN-Bus mit der zeitgesteuerten Erweiterung ist für dieses System mit aufwändigerSoftware realisiert worden, die nur einen Teil des eng spezifizierten TTCAN umsetzt. Daes auf der Softwareebene sehr schwer ist, die vollständige Spezifikation zu implementie-ren wäre es sinnvoll, den TTCAN mittels neuer CAN-Controller3 zu realisieren, die TTCANhardwareseitig unterstützen.

1International Protection2Automatisches Verbinden nach einem Verbindungsabbruch3Hardware Support von Boschhttp://www.semiconductors.bosch.de/en/20/ttcan/index.asp

http://www.semiconductors.bosch.de/en/20/ttcan/index.asp

Literaturverzeichnis

[Atmel 2006] ATMEL: AT90CAN128. 4250H-CAN, 05 2006

[Society of Automotiv Engineers 2006] AUTOMOTIV ENGINEERS, Inc Society of: 2007 For-mula SAE Rules, 2006. – URL http://students.sae.org/competitions/formulaseries/rules/2007rules.pdf

[Beckmann und Danisch 2006] BECKMANN, Kirsten ; DANISCH, Ruben: Formula StudentGermany. In: Sonderausgabe ATZ/MTZ FORMULA STUDENT GERMANY (2006)

[CadSoft 2003] CADSOFT: Eagle - Referenz Handbuch, 2003. – URL http://www-emc.ee.tu-berlin.de/software/eagle_manual-ger.pdf

[Etschberger 2002] ETSCHBERGER, Konrad: Controller Area Network. Carl Hanser Verlag,2002. – ISBN 3-446-21776-2

[Haase 2007] HAASE, Sebastian: Hawks Racing CAN Transport-Protokoll / HawksRacing. URL http://users.informatik.haw-hamburg.de/projects/hawks/, 2007. – Protokolldokumentation

[Haase und Schuckert 2007] HAASE, Sebastian ; SCHUCKERT, Simon: Telemetrie am H03,Anforderungen (Lastenheft) / Hawks Racing. URL http://users.informatik.haw-hamburg.de/projects/hawks/, 2007. – Anforderungsspezifikation

[Jacobsen u. a. 2003] JACOBSEN, Andreas ; AHRENS, Peter ; HAUSNER, Wilhelm: TCP/IPBasics. J. Schlembach Fachverlag, 2003. – ISBN 3-935340-26-5

[Kernighan und Ritchie 1990] KERNIGHAN, Brian W. ; RITCHIE, Dennis M.: Programmierenin C. Carl Hanser Verlag, 1990. – ISBN 3-446-15497-3

[Kersken 2004] KERSKEN, Sascha: Kompendium der Informationstechnik. Galileo PressGmbH, 2004. – ISBN 3-89842-355-7

[Lantronix 2004] LANTRONIX: WiPort - User Guide. 900-332, 2004. – URL http://www.lantronix.cn/support/docs/pdf/WiPort_UG_900-332.pdf

[Lawrenz 2000] LAWRENZ, Wolfhard: CAN Controller Area Network. Hüthig Verlag Hei-delberg, 2000. – ISBN 3-7785-2780-0

http://students.sae.org/competitions/formulaseries/rules/2007rules.pdf

http://students.sae.org/competitions/formulaseries/rules/2007rules.pdf

http://www-emc.ee.tu-berlin.de/software/eagle_manual-ger.pdf

http://www-emc.ee.tu-berlin.de/software/eagle_manual-ger.pdf

http://users.informatik.haw-hamburg.de/projects/hawks/




http://www.lantronix.cn/support/docs/pdf/WiPort_UG_900-332.pdf

http://www.lantronix.cn/support/docs/pdf/WiPort_UG_900-332.pdf

Literaturverzeichnis 99

[Marscholik und Subke 2007] MARSCHOLIK, Christoph ; SUBKE, Peter: Datenkommunika-tion im Automobil. Hüthig Verlag Heidelberg, 2007. – ISBN 978-3-7785-2969-0

[Pont 2001] PONT, Michael J.: Patterns for Time-Triggered Embedded Systems. ACMPress, 2001. – ISBN 0-201-33138-1

[Rech 2006] RECH, Jörg: Wireless LANs. Heise Zeitschriften Verlag, 2006. – ISBN 3-936931-29-1

[Schlaack 2007] SCHLAACK, Patrick: Visuelle Aufbereitung von Telemetriedaten, Hoch-schule für Angewandte Wissenschaften Hamburg, Studienarbeit, 2007

[Scholz 2005] SCHOLZ, Peter: Softwareentwicklung eingebetteter Systeme. Springer-Verlag, 2005. – ISBN 3-540-23405-5

[Schuckert 2007] SCHUCKERT, Simon: Mikrocontrollerbasierte Telemetrie und Echtzeit-auswertung von Sensordaten im Formula Student Rennwagen, Hochschule für Ange-wandte Wissenschaften Hamburg, Bachelorarbeit, 2007

[Spillner und Linz 2005] SPILLNER, Andreas ; LINZ, Tilo: Basiswissen Softwaretest.dpunkt.verlag Gmbh, 2005. – ISBN 13 978-3-89864-358-0

[Wikipedia 2007] WIKIPEDIA: File Allocation Table. 2007. – URL http://de.wikipedia.org/wiki/File_Allocation_Table

[Zimmermann und Schmidgall 2006] ZIMMERMANN, Werner ; SCHMIDGALL, Ralf: Bussys-tem in der Fahrzeugtechnik. Friedr. Vieweg & Sohn Verlag, 2006. – ISBN 978-3-8348-0166-1

http://de.wikipedia.org/wiki/File_Allocation_Table

http://de.wikipedia.org/wiki/File_Allocation_Table

A. Automaten der Datalogger-Software

Abbildung A.1.: Hauptautomat der Datalogger-Software


Abbildung A.2.: Subautomat zum Auslesen einer Datei

Abbildung A.3.: Subautomat zum Auslesen der Ordner-Struktur


Abbildung A.4.: Subautomat zum Aufzeichnen von CAN-Bus-Daten

B. CAN-Bus Daten

Komponenten / Werte B 0 B 1 B 2 B 3 B 4 B 5 B 6 B 7 Einheit Bereich

Time Master 0x01

x 0x 1x 2x 3

Raddrehzahl vorne links0x33

km/h oder RPM bei km/h -> 0 bis 400Raddrehzahl vorne rechts km/h oder RPM bei km/h -> 0 bis 400

1=KMH, 2=RPMRaddrehzahl hinten links

0x34km/h oder RPM bei km/h -> 0 bis 400

Raddrehzahl hinten rechts km/h oder RPM bei km/h -> 0 bis 4001=KMH, 2=RPM

Lenkwinkel 0x3B Grad -180 bis +180

0x35MAPPhase1

TPS

0x36RPMKlambda1Inj1Inj2

0x37Inj3Inj4

Spark3

0x38Spark4Spark2

Spark1

0x39

Lambda

0x3A

BAP

Nachrichten vom Typ Data Single (Byte-Reihenfolge: Little-Endian)Quell-Adr.

Wird für Protokolldaten verwendet

u char u char u char Datum: dd.mm.yy x = 0 -> BusMode: offu char u char u char Uhrzeit: hh.mm.ss x = 1 -> BusMode: recordu char u char u char Datum: dd.mm.yyu char u char u char Uhrzeit: hh.mm.ss

u shortu short

SpeedMode u charu short

u shortSpeedMode u char

s shortEngineRoundCounter u short

siehe K-Line Protokoll

u shortu short

TAir u charu char

u shortu short

u shortu short

u shortu short

ValvPosition u chars short

s shorts short

Sidestand u chars short

u charVBatt u charDFarf u charTEngine u charLambdaTarget u charSpeed u shortTipover u charGear u charActive Block u char

u short

Abbildung B.1.: Inhalt der CAN Daten-Nachrichten


Steuernachricht B 0 B 1 B 2 B 3 B 4 B 5 B 6 B 7

0x22 = Set Time

Nachrichten vom Typ Control (Byte-Reihenfolge: Little-Endian)

Generel Command Protokolldaten

Zieladresse

0x01 = Reset0x05 = BusModeOff0x06 = BusModeOn

Datalogger Read File 0x11 = Read File FileID (uint32)

Datalogger Command0x12 = Read File Folder Structure0x13 = Record Data0x15 = Cancel

TimeMaster Time hour (uint8) minute (uint8) second (uint8)TimeMaster Date 0x33 = Set Date dayOfTheWeek (uint8) day (uint8) month (uint8) year (uint8)

Whellspeed Tire Size 0x55 = Tire Size 1 = km/h2 = rpm tire size in mm (uint16)

Abbildung B.2.: Inhalt der CAN Control-Nachrichten

Komponenten B 0 B 1 B 2 B 3 B 4 B 5 B 6 B 70x09

0x0A

Lenkwinkel 0x0CRaddrehzahl vorne 0x0DRaddrehzahl hinten 0x0E

Nachrichten vom Typ Error (Byte-Reihenfolge: Little-Endian)Quell-Adr.

CommunicatorProtokolldaten

Zieladresse

Scheduler Status (siehe Scheduler Definition)

Datalogger

0x00 = OK0x01 = CardNotFound0x02 = CardNotWriteable0x03 = FileNotOpen0x04 = FolderNotOpen0x05 = BusModeOff0x06 = SwitchOff0x07 = CardFull

Scheduler Status (siehe Scheduler Definition)Scheduler Status (siehe Scheduler Definition)Scheduler Status (siehe Scheduler Definition)

Abbildung B.3.: Inhalt der CAN Error-Nachrichten


Adressen & Soll-Frequenzen

Typ Sensor / Komponente Priorität

ECU 5 (25)

0x35 6MAP 5 (25)Phase1 5 (25)

5 (25)TPS 25

0x36 6RPM 25Klambda1 25Inj1 25Inj2 25

0x37 6Inj3 25Inj4 25

0 (25)Spark3 25

0x38 6Spark4 25Spark2 25

0 (25)Spark1 25

0x39 6

Lambda 255 (25)

255 (25)5 (25)2 (25)

0x3A 60 (25)2 (25)1 (25)

BAP 5 (25)Sensoren Raddrehzahl vorne links 25 0x33 6Raddrehzahl vorne rechts 25

Raddrehzahl hinten links 25 0x34 6Raddrehzahl hinten rechts 25Lenkwinkelsensor 25 0x3B 6

Komponenten Time Master 1 100 0x01 0Time Master 2 100 0x02 0Time Master 3 100 0x03 0Time Master Broadcast 0xFE 1

25 0x08 125 0x09 125 0x0A 1

ECU 25 0x0B 1Lenkwinkel 25 0x0C 1Raddrehzahl vorne 25 0x0D 1Raddrehzahl hinten 25 0x0E 1Broadcast Adresse 0xFFReservierte Adresse 0x00

Soll Frequenz (Werte/s) Quelladresse

EngineRoundCounter

TAir

ValvPosition

Sidestand

VBattDFarfTEngineLambdaTargetSpeedTipoverGearActive Block

System CheckerCommunicatorDatalogger

Abbildung B.4.: Adressen und Sollfrequenzen der CAN-Bus Komponenten

C. Schaltpläne

C. Schaltpläne 107

11

22

33

44

DD

CC

BB

AA

Title

Num

ber

Rev

isio

nSi

ze A4

Dat

e:01

.12.

2006

Shee

t o

fFi

le:

C:\C

ar\..

\AT9

0CA

N12

8-B

oard

-rev

2.Sc

hDocD

raw

n B

y:

TXD

1

GN

D2

VC

C3

RX

D4

Vre

f5

CA

NL

6

CA

NH

7

Rs

8U

3

PCA

82C

250

R1

10KV

CC

VC

CV

CC

VC

C

VC

CV

CC

12

Y2

VC

C

Vin

Vou

t GN

D

VR

1V

olt R

eg

C1

100u

F

C2

100u

F

C3

100n

F

C4

100n

F

C11 22

pFC

1222

pF

1 2 3 4 5 6 7 8

PA

1 2 3 4 5 6 7 8

PB

1 2 3 4 5 6 7 8

PC

1 2 3 4 5 6 7 8

PD

1 2 3 4 5 6 7 8

PE

12345678

PF

1 2 3 4 5 6 7 8

GN

D1

1 2 3 4 5 6 7 8

VC

C1

1 2 3 4 5 6 7 8

GN

D4

1 2 3 4 5 6 7 8

VC

C4

1 2 3 4 5 6 7 8

GN

D2

1 2 3 4 5 6 7 8

VC

C2

1 2 3 4 5 6 7 8

GN

D5

1 2 3 4 5 6 7 8

VC

C5

1 2 3 4 5 6 7 8

GN

D6

1 2 3 4 5 6 7 8

VC

C6

12345678 GN

D3

12345678 VC

C3

GN

DG

ND

GN

DG

ND

GN

D

GN

DG

ND

GN

DG

ND

Vba

t

TOSC

1TO

SC2

TOSC

1TO

SC2

C7

100n

FC

810

0nF

C9

100n

FC

1010

0nF

GN

D

L110

uH

GN

DG

ND

GN

D

VC

C

1 2 3

RS2

32-01 2 3

RS2

32-1 123

CA

N

GN

D

GN

D

GN

D

GN

D

VC

C

VC

C

GN

D

B.C

arst

ense

n

AT9

0CA

N12

8-B

oard

2.0

11

4

12

19

3 20

5 18

V+

8

C2-

11

GN

D6

C1+

13

VC

C7

R1T1 T2

R2

C2-

16

C2+

12

C1-

14

GN

D9

C2+

15

V-

10

V-

17

U2

MA

X23

3AEW

P

1 2

Pow

er

7,5-

12V

DC

GN

D

12

Y1

16M

Hz

C5

22pF

C6 22pF

GN

DG

ND

12

34

56

78

910

JTA

G

GN

D

VC

CV

CC

RES

ET

TCK

TMS

TDO

TDI

TCK

TDO

TMS

TDI

1 2 3 45678

SW-D

IP4

AV

CC

AR

EFA

VC

CA

REF

RES

ET1

23

45

67

89

10

ISP

MO

SI

MO

SI

RES

ETSC

K

SCK

MIS

O

MIS

O

VC

C

GN

D

GN

D

Reset GN

D

VC

C

R2

10K G

ND

GN

DG

ND

Opt

ion

1 2 3

PG

1 2 3

GN

D7

RxD

RxD

TxD

TxD

PEN

1

PE0

(RX

D0/

PDI)

2

PE1

(TX

D0/

PDO

)3

PE2

(XC

K0/

AIN

0)4

PE3

(OC

3A/A

IN1)

5

PE4

(OC

3B/IN

T4)

6

PE5

(OC

3C/IN

T5)

7

PE6

(T3/

INT6

)8

PE7

(IC

3/IN

T7)

9

PB0

(SS)

10

PB1

(SC

K)

11

PB2

(MO

SI)

12

PB3

(MIS

O)

13

PB4

(OC

0)14

PB5

(OC

1A)

15

PB6

(OC

1B)

16

PB7

(OC

2/O

C1C

)17

TOSC

2/PG

318

TOSC

1/1P

G4

19

RES

ET20

VC

C21

GN

D22

XTA

L223

XTA

L124

PD0

(SC

L/IN

T0)

25

PD1

(SD

A/IN

T1)

26

PD2

(RX

D1/

INT2

)27

PD3

(TX

D1/

INT3

)28

PD4

(IC

1)29

PD5

(TX

CA

N/X

CK

1)30

PD6

(RX

CA

N/T

1)31

PD7

(T0)

32

PG0

(WR

)33

PG1

(RD

)34

PC0

(A8)

35

PC1

(A9)

36

PC2

(A10

)37

PC3

(A11

)38

PC4

(A12

)39

PC5

(A13

)40

PC6

(A14

)41

PC7

(A15

)42

PG2

(ALE

)43

PA7

(AD

7)44

PA6

(AD

6)45

PA5

(AD

5)46

PA4

(AD

4)47

PA3

(AD

3)48

PA2

(AD

2)49

PA1

(AD

1)50

PA0

(AD

0)51

VC

C52

GN

D53

PF7

(AD

C7/

TDI)

54

PF6

(AD

C6/

TDO

)55

PF5

(AD

C5/

TMS)

56

PF4

(AD

C4/

TCK

)57

PF3

(AD

C3)

58

PF2

(AD

C2)

59

PF1

(AD

C1)

60

PF0

(AD

C0)

61

AR

EF62

GN

D63

AV

CC

64

U1

AT9

0CA

N12

8-A

I

P0C101 P0C102

P0C201 P0C202

P0C301 P0C302

P0C401 P0C402

P0C501 P0C502

P0C601 P0C602

P0C701 P0C702

P0C801 P0C802

P0C901 P0C902

P0C1001 P0C1002

P0C1101 P0C1102

P0C1201 P0C1202

P0CAN01

P0CAN02

P0CAN03

P0GND101

P0GND102

P0GND103

P0GND104

P0GND105

P0GND106

P0GND107

P0GND108

P0GND201

P0GND202

P0GND203

P0GND204

P0GND205

P0GND206

P0GND207

P0GND208

P0GND301

P0GND302

P0GND303

P0GND304

P0GND305

P0GND306

P0GND307

P0GND308

P0GND401

P0GND402

P0GND403

P0GND404

P0GND405

P0GND406

P0GND407

P0GND408

P0GND501

P0GND502

P0GND503

P0GND504

P0GND505

P0GND506

P0GND507

P0GND508

P0GND601

P0GND602

P0GND603

P0GND604

P0GND605

P0GND606

P0GND607

P0GND608

P0GND701

P0GND702

P0GND703

P0ISP01

P0ISP02

P0ISP03

P0ISP04

P0ISP05

P0ISP06

P0ISP07

P0ISP08

P0ISP09

P0ISP010

P0JTAG01

P0JTAG02

P0JTAG03

P0JTAG04

P0JTAG05

P0JTAG06

P0JTAG07

P0JTAG08

P0JTAG09

P0JTAG010

P0L101

P0L102

P0PA01

P0PA02

P0PA03

P0PA04

P0PA05

P0PA06

P0PA07

P0PA08

P0PB01

P0PB02

P0PB03

P0PB04

P0PB05

P0PB06

P0PB07

P0PB08

P0PC01

P0PC02

P0PC03

P0PC04

P0PC05

P0PC06

P0PC07

P0PC08

P0PD01

P0PD02

P0PD03

P0PD04

P0PD05

P0PD06

P0PD07

P0PD08

P0PE01

P0PE02

P0PE03

P0PE04

P0PE05

P0PE06

P0PE07

P0PE08

P0PF01

P0PF02

P0PF03

P0PF04

P0PF05

P0PF06

P0PF07

P0PF08

P0PG01

P0PG02

P0PG03

P0Power01

P0Power02

P0R101 P0R102

P0R201 P0R202

P0Reset01 P0Reset02

P0RS2320001

P0RS2320002

P0RS2320003

P0RS2320101

P0RS2320102

P0RS2320103

P0SW0DIP401

P0SW0DIP402

P0SW0DIP403

P0SW0DIP404

P0SW0DIP405

P0SW0DIP406

P0SW0DIP407

P0SW0DIP408

P0U101

P0U102

P0U103

P0U104

P0U105

P0U106

P0U107

P0U108

P0U109

P0U1010

P0U1011

P0U1012

P0U1013

P0U1014

P0U1015

P0U1016

P0U1017

P0U1018

P0U1019

P0U1020

P0U1021

P0U1022

P0U1023

P0U1024 P0U1025

P0U1026

P0U1027

P0U1028

P0U1029

P0U1030

P0U1031

P0U1032

P0U1033

P0U1034

P0U1035

P0U1036

P0U1037

P0U1038

P0U1039

P0U1040

P0U1041

P0U1042

P0U1043

P0U1044

P0U1045

P0U1046

P0U1047

P0U1048

P0U1049

P0U1050

P0U1051

P0U1052

P0U1053

P0U1054

P0U1055

P0U1056

P0U1057

P0U1058

P0U1059

P0U1060

P0U1061

P0U1062

P0U1063

P0U1064

P0U201

P0U202

P0U203

P0U204

P0U205

P0U206

P0U207

P0U208

P0U209

P0U2010

P0U2011

P0U2012

P0U2013

P0U2014

P0U2015

P0U2016

P0U2017

P0U2018

P0U2019

P0U2020

P0U301

P0U302

P0U303

P0U304

P0U305

P0U306

P0U307

P0U308

P0VCC01 P0VCC02

P0VCC101

P0VCC102

P0VCC103

P0VCC104

P0VCC105

P0VCC106

P0VCC107

P0VCC108

P0VCC201

P0VCC202

P0VCC203

P0VCC204

P0VCC205

P0VCC206

P0VCC207

P0VCC208

P0VCC301

P0VCC302

P0VCC303

P0VCC304

P0VCC305

P0VCC306

P0VCC307

P0VCC308

P0VCC401

P0VCC402

P0VCC403

P0VCC404

P0VCC405

P0VCC406

P0VCC407

P0VCC408

P0VCC501

P0VCC502

P0VCC503

P0VCC504

P0VCC505

P0VCC506

P0VCC507

P0VCC508

P0VCC601

P0VCC602

P0VCC603

P0VCC604

P0VCC605

P0VCC606

P0VCC607

P0VCC608

P0VR101

P0VR102

P0VR103

P0Y101

P0Y102

P0Y201

P0Y202

P0C902

P0U1062

N0AREF

N0AREF

P0C1002 P0L101

P0U1064

N0AVCC

N0AVCC

P0C102

P0C202

P0C301

P0C401

P0C502

P0C602

P0C701

P0C801

P0C901

P0C1001

P0C1102

P0C1202

P0CAN02

P0GND101

P0GND102

P0GND103

P0GND104

P0GND105

P0GND106

P0GND107

P0GND108

P0GND201

P0GND202

P0GND203

P0GND204

P0GND205

P0GND206

P0GND207

P0GND208

P0GND301

P0GND302

P0GND303

P0GND304

P0GND305

P0GND306

P0GND307

P0GND308

P0GND401

P0GND402

P0GND403

P0GND404

P0GND405

P0GND406

P0GND407

P0GND408

P0GND501

P0GND502

P0GND503

P0GND504

P0GND505

P0GND506

P0GND507

P0GND508

P0GND601

P0GND602

P0GND603

P0GND604

P0GND605

P0GND606

P0GND607

P0GND608

P0GND701

P0GND702

P0GND703

P0ISP04

P0ISP06

P0ISP08

P0ISP010

P0JTAG02

P0JTAG010

P0Power02

P0Reset01

P0RS2320002

P0RS2320102

P0U1022

P0U1053

P0U1063

P0U206

P0U209

P0U302

P0U308

P0VCC02

P0VR102

P0ISP09

P0PB04

P0U1013

N0MISO

N0MISO

P0ISP01

P0PB03

P0U1012

N0MOSI

N0MOSI

P0C501

P0U1023

P0Y102

P0C601

P0U1024

P0Y101

P0CAN01

P0U306

P0CAN03

P0U307

P0ISP03

P0JTAG08

P0PA01

P0U1051

P0PA02

P0U1050

P0PA03

P0U1049

P0PA04

P0U1048

P0PA05

P0U1047

P0PA06

P0U1046

P0PA07

P0U1045

P0PA08

P0U1044

P0PB01

P0U1010

P0PB05

P0U1014

P0PB06

P0U1015

P0PB07

P0U1016

P0PB08

P0U1017

P0PC01

P0U1035

P0PC02

P0U1036

P0PC03

P0U1037

P0PC04

P0U1038

P0PC05

P0U1039

P0PC06

P0U1040

P0PC07

P0U1041

P0PC08

P0U1042

P0PD01

P0U1025

P0PD02

P0U1026

P0PD03

P0U1027

P0U203

P0PD04

P0U1028

P0U202

P0PD05

P0U1029

P0PD06

P0U1030

P0U301

P0PD07

P0U1031

P0U304

P0PD08

P0U1032

P0PE01

P0U102

P0U2020

P0PE02

P0U103

P0U201

P0PE03

P0U104

P0PE04

P0U105

P0PE05

P0U106

P0PE06

P0U107

P0PE07

P0U108

P0PE08

P0U109

P0PF01

P0U1061

P0PF02

P0U1060

P0PF03

P0U1059

P0PF04

P0U1058

P0PF05

P0SW0DIP405 P0PF06

P0SW0DIP406 P0PF07

P0SW0DIP407 P0PF08

P0SW0DIP408

P0PG01

P0U1033

P0PG02

P0U1034

P0PG03

P0U1043

P0R201 P0VCC01

P0RS2320001

P0U2018

P0RS2320003

P0U2019

P0RS2320101

P0U205

P0RS2320103

P0U204

P0U101

P0U208

P0U2010

P0U2017

P0U2011

P0U2016

P0U2012

P0U2015

P0U2013

P0U2014

P0ISP05

P0JTAG06

P0R101 P0Reset02

P0U1020

N0RESET

N0RESET

N0RESET

P0ISP07

P0PB02

P0U1011

N0SCK

N0SCK

P0JTAG01

P0SW0DIP404

P0U1057

N0TCK

N0TCK

P0JTAG09

P0SW0DIP401

P0U1054

N0TDI

N0TDI

P0JTAG03

P0SW0DIP402

P0U1055

N0TDO

N0TDO

P0JTAG05

P0SW0DIP403

P0U1056

N0TMS

N0TMS

P0C1101 P0U1019

P0Y202

N0TOSC1

N0TOSC1

P0C1201

P0U1018

P0Y201

N0TOSC2

N0TOSC2

P0C101

P0C402

P0Power01

P0VR101

P0C201

P0C302

P0C702

P0C802

P0ISP02

P0JTAG04

P0JTAG07

P0L102

P0R102

P0R202

P0U1021

P0U1052

P0U207

P0U303

P0U305

P0VCC101

P0VCC102

P0VCC103

P0VCC104

P0VCC105

P0VCC106

P0VCC107

P0VCC108

P0VCC201

P0VCC202

P0VCC203

P0VCC204

P0VCC205

P0VCC206

P0VCC207

P0VCC208

P0VCC301

P0VCC302

P0VCC303

P0VCC304

P0VCC305

P0VCC306

P0VCC307

P0VCC308

P0VCC401

P0VCC402

P0VCC403

P0VCC404

P0VCC405

P0VCC406

P0VCC407

P0VCC408

P0VCC501

P0VCC502

P0VCC503

P0VCC504

P0VCC505

P0VCC506

P0VCC507

P0VCC508

P0VCC601

P0VCC602

P0VCC603

P0VCC604

P0VCC605

P0VCC606

P0VCC607

P0VCC608

P0VR103

N0AREF

P0C902

P0U1062

N0AVCC

P0C1002 P0L101

P0U1064

P0C102

P0C202

P0C301

P0C401

P0C502

P0C602

P0C701

P0C801

P0C901

P0C1001

P0C1102

P0C1202

P0CAN02

P0GND101

P0GND102

P0GND103

P0GND104

P0GND105

P0GND106

P0GND107

P0GND108

P0GND201

P0GND202

P0GND203

P0GND204

P0GND205

P0GND206

P0GND207

P0GND208

P0GND301

P0GND302

P0GND303

P0GND304

P0GND305

P0GND306

P0GND307

P0GND308

P0GND401

P0GND402

P0GND403

P0GND404

P0GND405

P0GND406

P0GND407

P0GND408

P0GND501

P0GND502

P0GND503

P0GND504

P0GND505

P0GND506

P0GND507

P0GND508

P0GND601

P0GND602

P0GND603

P0GND604

P0GND605

P0GND606

P0GND607

P0GND608

P0GND701

P0GND702

P0GND703

P0ISP04

P0ISP06

P0ISP08

P0ISP010

P0JTAG02

P0JTAG010

P0Power02

P0Reset01

P0RS2320002

P0RS2320102

P0U1022

P0U1053

P0U1063

P0U206

P0U209

P0U302

P0U308

P0VCC02

P0VR102

N0MISO

P0ISP09

P0PB04

P0U1013

N0MOSI

P0ISP01

P0PB03

P0U1012

P0C501

P0U1023

P0Y102

P0C601

P0U1024

P0Y101

P0CAN01

P0U306

P0CAN03

P0U307

P0ISP03

P0JTAG08

P0PA01

P0U1051

P0PA02

P0U1050

P0PA03

P0U1049

P0PA04

P0U1048

P0PA05

P0U1047

P0PA06

P0U1046

P0PA07

P0U1045

P0PA08

P0U1044

P0PB01

P0U1010

P0PB05

P0U1014

P0PB06

P0U1015

P0PB07

P0U1016

P0PB08

P0U1017

P0PC01

P0U1035

P0PC02

P0U1036

P0PC03

P0U1037

P0PC04

P0U1038

P0PC05

P0U1039

P0PC06

P0U1040

P0PC07

P0U1041

P0PC08

P0U1042

P0PD01

P0U1025

P0PD02

P0U1026

P0PD03

P0U1027

P0U203

P0PD04

P0U1028

P0U202

P0PD05

P0U1029

P0PD06

P0U1030

P0U301

P0PD07

P0U1031

P0U304

P0PD08

P0U1032

P0PE01

P0U102

P0U2020

P0PE02

P0U103

P0U201

P0PE03

P0U104

P0PE04

P0U105

P0PE05

P0U106

P0PE06

P0U107

P0PE07

P0U108

P0PE08

P0U109

P0PF01

P0U1061

P0PF02

P0U1060

P0PF03

P0U1059

P0PF04

P0U1058

P0PF05

P0SW0DIP405 P0PF06

P0SW0DIP406 P0PF07

P0SW0DIP407 P0PF08

P0SW0DIP408

P0PG01

P0U1033

P0PG02

P0U1034

P0PG03

P0U1043

P0R201 P0VCC01

P0RS2320001

P0U2018

P0RS2320003

P0U2019

P0RS2320101

P0U205

P0RS2320103

P0U204

P0U101

P0U208

P0U2010

P0U2017

P0U2011

P0U2016

P0U2012

P0U2015

P0U2013

P0U2014

N0RESET

P0ISP05

P0JTAG06

P0R101 P0Reset02

P0U1020

N0SCK

P0ISP07

P0PB02

P0U1011

N0TCK

P0JTAG01

P0SW0DIP404

P0U1057

N0TDI

P0JTAG09

P0SW0DIP401

P0U1054

N0TDO

P0JTAG03

P0SW0DIP402

P0U1055

N0TMS

P0JTAG05

P0SW0DIP403

P0U1056

N0TOSC1

P0C1101 P0U1019

P0Y202

N0TOSC2

P0C1201

P0U1018

P0Y201

P0C101

P0C402

P0Power01

P0VR101

P0C201

P0C302

P0C702

P0C802

P0ISP02

P0JTAG04

P0JTAG07

P0L102

P0R102

P0R202

P0U1021

P0U1052

P0U207

P0U303

P0U305

P0VCC101

P0VCC102

P0VCC103

P0VCC104

P0VCC105

P0VCC106

P0VCC107

P0VCC108

P0VCC201

P0VCC202

P0VCC203

P0VCC204

P0VCC205

P0VCC206

P0VCC207

P0VCC208

P0VCC301

P0VCC302

P0VCC303

P0VCC304

P0VCC305

P0VCC306

P0VCC307

P0VCC308

P0VCC401

P0VCC402

P0VCC403

P0VCC404

P0VCC405

P0VCC406

P0VCC407

P0VCC408

P0VCC501

P0VCC502

P0VCC503

P0VCC504

P0VCC505

P0VCC506

P0VCC507

P0VCC508

P0VCC601

P0VCC602

P0VCC603

P0VCC604

P0VCC605

P0VCC606

P0VCC607

P0VCC608

P0VR103

D. Komponenten-Anschlussbelegung

Anschlussbelegung vom Communicator

CAN-Stecker CAN-Buchse

D-SUB-Stecker

LED1 LED2 LED3

Spannungs-versorgung

Antennenstecker

An Aus

LED1 Kein Fehler

LED2 Kein Fehler

LED3 Software nicht gestartet

WiPort Communication Module Fehler*SPI Übertragungsfehler o. Pufferüberlauf*RS232 Übertragungfehler o. Pufferüberlauf*Synchronisationsfehler mit CAN Communication ModuleCAN Communication Module Fehler*SPI Pufferüberlauf*CAN Empfang- u. Sende-Pufferüberlauf*CAN Sendefehler*Synchronisationsfehler mit WiPort Communication ModuleTime Master Nachricht fehlt (durchgehend an)Software gestartet (blinkend)

D-SUB-SteckerPin Beschreibung1 NC2 RS232_TX3 RS232_RX4 NC5 GND6 NC7 NC8 NC9 NC

CAN-SteckerPin Beschreibung1 NC2 CAN_L3 NC4 NC5 NC6 GND7 CAN_H8 NC9 +9V

CAN-BuchsePin Beschreibung1 NC2 CAN_L3 NC4 NC5 NC6 GND7 CAN_H8 NC9 +9V

SpannungsversorgungPin Beschreibung1 GND2 +9V3 NC4 NC


Anschlussbelegung vom Datalogger

CAN-Stecker CAN-BuchseD-SUB-Stecker

SD Memory Card

LED1 LED2 LED3

Spannungs-versorgung

LED4LED5

LED6

An AusLED1 CAN Pufferüberlauf o. Karte nicht gefunden Kein FehlerLED2 Datei ist offen (zum lesen oder schreiben) keine Datei offenLED3 Software gestartet Software nicht gestartetLED4 Auf Karte wird zugegriffen Kein KartenzugriffLED5 Karte erkannt Karte nicht erkanntLED6 Spannungsversorgung für Karte aktiv Keine Spannung für Karte vorhanden

D-SUB-SteckerPin Beschreibung1 NC2 RS232_RX3 RS232_TX4 NC5 GND6 NC7 NC8 NC9 Logging Switch (GND)

CAN-SteckerPin Beschreibung1 NC2 CAN_L3 NC4 NC5 NC6 GND7 CAN_H8 NC9 +9V

CAN-BuchsePin Beschreibung1 NC2 CAN_L3 NC4 NC5 NC6 GND7 CAN_H8 NC9 +9V

SpannungsversorgungPin Beschreibung1 GND2 +9V3 NC4 NC

Glossar

Automobilsport umfasst alle Disziplinen und Wettbewerbe, die das Ziel haben motorge-triebene vierrädrige Fahrzeuge schnell und geschickt zu bewegen.

Evaluation Board ist eine Musterplatine zum Austesten eines neuen Bauteiles. BeiProzessoren enthalten sie meist einen kompletten Rechner (CPU, Speicher, Ein-/Ausgabe).

Feldbus ist ein industrielles Kommunikationssystem, das eine Vielzahl von Feldgeräten,wie Messfühler (Sensoren), Stellglieder und Antriebe (Aktoren), miteinander verbin-det.

Gateways ermöglichen eine Kommunikation mit Netzwerken die auf unterschiedlichenProtokollen basieren.

Latenzzeit ist ein Zeitintervall vom Ende eines Ereignisses bis zum Beginn der Reaktion.

Leitstand ist eine technische Einrichtung, die Daten speichern und auswerten kann.

Lenkwinkelsensoren messen den Winkel des Lenkradeinschlages.

Master hat als einziger das Recht unaufgefordert auf die gemeinsame Ressource zuzu-greifen.

Prescaler ist ein elektronischer Baustein, der die Frequenz um einen vorgegeben Faktorreduziert.

Prototyp ist ein Vorab-Exemplar einer späteren Serienfertigung das zur Erprobung vonEigenschaften dient.

Raddrehzahlsensoren messen die Drehzahl der Räder bzw. einen pro Zeiteinheit zurück-gelegten Weg oder Winkel.

Replikat ist eine Kopie eines Gegenstandes.


Slave kann von sich aus nicht auf die gemeinsame Ressource zugreifen. Er muss warten,bis er vom Master gefragt wird.

Task ist ein einzelner Pfad durch die Ausführung eines Programms in der eine Aufgabeerledigt wird.

Telemetrie (Fernmessung) bezeichnet die Übertragung von Messwerten eines am Mes-sort befindlichen Sensors zu einer räumlich getrennten Stelle.

Versicherung über Selbstständigkeit

Hiermit versichere ich, dass ich die vorliegende Arbeit im Sinne der Prüfungsordnung nach§24(5) ohne fremde Hilfe selbstständig verfasst und nur die angegebenen Hilfsmittel benutzthabe.

Hamburg, 23. September 2007Ort, Datum Unterschrift

bachelorarbeit im studiengang technische informatik der ... · die formula student1 ist ein projekt...

Documents