Bachelorarbeit im Studiengang Technische Informatik der ... · Als Hardwarebasis dient hier ein 8 Bit Mikrocontroller und der für den Automotiv Bereich prädestinierte CAN-Bus. Simon

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

Simon Martin Schuckert

Mikrocontrollerbasierte Telemetrie undEchtzeitauswertung von Sensordaten im

Formula Student Rennwagen

Bachelorarbeit

Abgegeben am 25. September 2007

Betreuender Prüfer : Prof. Dr. rer. nat. Stephan PareigisZweitgutachter : Prof. Dr. Franz Korf

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


Mikrocontrollerbasierte Telemetrie undEchtzeitauswertung von Sensordaten im Formula

Student Rennwagen


Thema der BachelorarbeitMikrocontrollerbasierte Telemetrie und Echtzeitauswertung von Sensordaten imFormula Student Rennwagen

StichworteTelemetrie, Automotive, Embedded, Mikrocontroller, Time-Triggered, CAN, Echt-zeitsystem

KurzzusammenfassungGegenstand dieser Bachelorarbeit ist der Entwurf und die Implementation von ei-nem System, dass Daten mit Sensoren in einem Formula Student Rennwagenerfasst, für Steuerungszwecke auswertet und die Aufgaben eines Telemetrie Sys-tems im Motorsport erfüllt. Das System soll dabei harten Echtzeitanforderungengenügen, um auch zeitkritische und sicherheitsrelevante Steuerungsaufgaben be-wältigen zu können. In dieser Arbeit werden die Anforderungen der Rennwagen-konstrukteure analysiert und entsprechende Realisierungsmöglichkeiten entwi-ckelt und umgesetzt. Dabei wird eine modulare Systemarchitektur geschaffen diees ermöglicht das System schnell und ohne großen Aufwand um weitere Funktio-nalitäten zu erweitern. Als Hardwarebasis dient hier ein 8 Bit Mikrocontroller undder für den Automotiv Bereich prädestinierte CAN-Bus.


Title of the paperMicrocontroller based telemetry and realtime analysis of sensor data in FormulaStudent racing cars.

KeywordsTelemetry, Automotive, embedded, microcontroller, time-triggered, CAN, real-timesystem

AbstractThis bachelor’s thesis is concerned with the development and implementation of asystem, which collects data via sensors mounted in Formula Student racing cars,then evaluates the data for control purposes, whilst fulfilling the functions of atelemetry system suitable for motor sport. The system should be capable of deal-ing with hard realtime requirements, in order to cope with time critical and safetyrelevant control duties. This thesis analyses the specifications of racing car con-struction and develops the relevant implementation contingencies. This includescreating a modular system architecture, which allows quick and effortless expan-sion of system functionality. The hardware basis for this is an 8 bit microcontrollerand a suitable automotive CAN bus.

Inhaltsverzeichnis

Tabellenverzeichnis vii

Abbildungsverzeichnis viii

1. Einleitung 11.1. Formula Student . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2. HAWKS Racing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.4. Zielsetzung und Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . 3

1.4.1. Anforderungen durch Technische Gegebenheiten . . . . . . . . . . . 41.4.2. Anwender . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.5. Randbedingungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.5.1. Ressourcen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2. Gesamtkonzept 72.1. Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.1. Die Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.1.2. CAN Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.2. Time-Triggered versus Event-Triggered . . . . . . . . . . . . . . . . . . . . 122.3. Time-Triggered-Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.3.1. Globale Systemzustände und Steuerfunktionen . . . . . . . . . . . . 152.4. Die Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.4.1. Der Atmel AVR AT90CAN128 . . . . . . . . . . . . . . . . . . . . . 162.4.2. Gehäuse, Stecker und Leitungen der Module . . . . . . . . . . . . . 17

3. Realisierung 203.1. Der Scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.1.1. Eine Software-Architektur für alle Module . . . . . . . . . . . . . . . 203.1.2. Aufbau und Implementation des Schedulers . . . . . . . . . . . . . . 263.1.3. Eigenschaften des Schedulers in einer Zusammenfassung . . . . . . 313.1.4. Fehlerbehandlung und Analyse . . . . . . . . . . . . . . . . . . . . . 313.1.5. Perfomance und Speicherbedarf Verbesserung . . . . . . . . . . . . 32

3.2. Das TTC-System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Inhaltsverzeichnis v

3.2.1. Aufgaben und Arbeitsweise des Time-Triggered-Systems . . . . . . . 353.2.2. TTC-Erweiterung für den Scheduler . . . . . . . . . . . . . . . . . . 373.2.3. Versenden einer CAN-Nachricht (Slave) . . . . . . . . . . . . . . . . 393.2.4. Fehlerbehandlung . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.3. Der Time-Master . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.3.1. Aufgaben des Time-Masters . . . . . . . . . . . . . . . . . . . . . . 403.3.2. Funktionsweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.3.3. Ausfall des Time-Masters . . . . . . . . . . . . . . . . . . . . . . . . 413.3.4. Die Realtimeclock . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423.3.5. Systemüberwachung . . . . . . . . . . . . . . . . . . . . . . . . . . 433.3.6. Moduleinstellungen und Statusanzeige . . . . . . . . . . . . . . . . . 43

3.4. Eigenschaften der Module . . . . . . . . . . . . . . . . . . . . . . . . . . . 443.5. Lenkwinkel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

3.5.1. Auswertung Sensor . . . . . . . . . . . . . . . . . . . . . . . . . . . 453.5.2. Moduleinstellungen und Statusanzeige . . . . . . . . . . . . . . . . . 48

3.6. Raddrehzahl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483.6.1. Funktionsweise und Anschluss des Sensorlagers . . . . . . . . . . . 493.6.2. Auswertung Sensor / Berechnungen . . . . . . . . . . . . . . . . . . 503.6.3. Moduleinstellungen und Statusanzeige . . . . . . . . . . . . . . . . . 54

4. Qualitätssicherung 554.1. Maßnahmen gegen EMV- Störungen . . . . . . . . . . . . . . . . . . . . . 554.2. Unterspannungstest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574.3. Rüttel-Test auf Hydropulsstand . . . . . . . . . . . . . . . . . . . . . . . . . 584.4. Individuelle Modultests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594.5. Integrationstest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 604.6. Integration im Fahrzeug . . . . . . . . . . . . . . . . . . . . . . . . . . . . 604.7. Hilfsmittel zur Fehleranalyse . . . . . . . . . . . . . . . . . . . . . . . . . . 61

4.7.1. CAN-Sniffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614.7.2. CAN-Bus-Fluter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

5. Fazit und Ausblick 645.1. Praktischer Einsatz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 645.2. Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 645.3. Veränderungen und Weiterentwicklung in der Zukunft . . . . . . . . . . . . . 65

Literaturverzeichnis 68

A. TTCAN-Timing und Nachrichtenformate 69

B. Qualitätsicherung CAN-Nachrichtenversandt 71

Inhaltsverzeichnis vi

C. Inhalt der CD 77

Glossar 78

Index 80

Tabellenverzeichnis

2.1. Einige wichtige Kenndaten des Atmel AVR AT90CAN128 . . . . . . . . . . . 19

3.1. Scheduler Vergleich . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

C.1. Inhalt der beiliegenden CD . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

Abbildungsverzeichnis

1.1. HAWK 07 auf der Rennstrecke . . . . . . . . . . . . . . . . . . . . . . . . . 1

2.1. Systementwurf mit Hauptrechner . . . . . . . . . . . . . . . . . . . . . . . 82.2. Systementwurf ohne Hauptrechner . . . . . . . . . . . . . . . . . . . . . . 92.3. Systementwurf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.4. Shared-Clock Scheduler via CAN-Bus . . . . . . . . . . . . . . . . . . . . . 142.5. Shared-Clock Scheduler via externen Interrupts (CAN-Bus nicht dargestellt) . 142.6. Synchronisation mehrerer Clocks via CAN-Bus . . . . . . . . . . . . . . . . 152.7. Evolution-Board des Labors für Technische-Informatik der HAW (Design von

B. Carstensen) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.8. Fertigung eines Moduls . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.1. Sequenzdiagramm des Schedulers . . . . . . . . . . . . . . . . . . . . . . 303.2. Diagramm Scheduler Compileroptimierung Zeitmessungen . . . . . . . . . . 333.3. Diagramm Scheduler Codeveränderungen Zeitmessungen . . . . . . . . . . 343.4. Ein Matrixzyklus mit den vier Basiszyklen . . . . . . . . . . . . . . . . . . . 363.5. Ermittlung der Zeitdifferenz zwischen Time-Master und Slave . . . . . . . . . 383.6. TM-Nachricht auf dem CAN-Bus . . . . . . . . . . . . . . . . . . . . . . . . 413.7. Signalform Drehwinkelsensor . . . . . . . . . . . . . . . . . . . . . . . . . 463.8. Funktionsweise des Sensorlagers (SKF (2003)) . . . . . . . . . . . . . . . . 493.9. Elektrischer Anschluss des Sensorlagers (SKF (2003)) . . . . . . . . . . . . 50

4.1. Time-Master-Modul auf dem Hydropulsstand . . . . . . . . . . . . . . . . . 584.2. CAN-Sniffer Menü . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 624.3. CAN-Sniffer Nachrichtenanzeige (mit ID 0x63B) . . . . . . . . . . . . . . . . 624.4. CAN-Bus-Fluter verursacht 80% CAN-Busauslastung (Bild auf Oszilloskop) . 63

5.1. Oberfläche für die Live-Ansicht der Daten . . . . . . . . . . . . . . . . . . . 655.2. Oberfläche Leitstandsoftware . . . . . . . . . . . . . . . . . . . . . . . . . 66

A.1. CAN-Protokoll Nachrichtenformate . . . . . . . . . . . . . . . . . . . . . . . 69A.2. TTCAN-Timing, Matrixzyklus mit vier Basiszyklen . . . . . . . . . . . . . . . 70

B.1. Zeitabstand zwischen zwei TM-Nachrichten . . . . . . . . . . . . . . . . . . 71

Abbildungsverzeichnis ix

B.2. Detailansicht einer TM-Nachricht . . . . . . . . . . . . . . . . . . . . . . . . 72B.3. Abstand zweier Nachrichten . . . . . . . . . . . . . . . . . . . . . . . . . . 73B.4. Sendezeitpunkt der Nachricht mit der ID 0x33 . . . . . . . . . . . . . . . . . 74B.5. Sendezeitpunkt der Nachricht mit der ID 0x34 . . . . . . . . . . . . . . . . . 75B.6. Nachrichten auf dem CAN-Bus beim setzen der Systemzeit . . . . . . . . . 76

1. Einleitung

In dieser Bachelorarbeit geht es um die Entwicklung eines Telemetrie-Systems für einenFormula Student Rennwagen des HAWKS Racing Teams der Hochschule für Angewand-te Wissenschaften Hamburg. Bevor die Motivation und die Zielsetzung genauer betrachtetwerden, sollen die nächsten beiden Abschnitte ersteinmal zeigen, was es mit der FormulaStudent und dem HAWKS Racing Team auf sich hat.

Abbildung 1.1.: HAWK 07 auf der Rennstrecke

1.1. Formula Student

Das folgende Zitat, von M. Schwarz (2006) auf der HAWKS Racing Webseite, erklärt worumes sich bei der Formula Student handelt.

Die Formula Student ist ein Projekt für Studenten der Ingenieurswissenschaften in dem esgilt einen einsitzigen Rennwagen (Monoposto) zu entwerfen und zu bauen. Das Projekt stellt

1. Einleitung 2

normalerweise einen Teil der akademischen Studien dar und gipfelt in einem Wettbewerb,bei dem Teams aus der ganzen Welt zusammenkommen um gegeneinander anzutreten. Beider Konstruktion müssen Regeln bezüglich der Rahmengestaltung (Sicherheit) und des Mo-tors eingehalten werden, um das Wissen, die Kreativität und das Vorstellungsvermögen derStudenten zu testen. Viertaktmotoren mit bis zu 610 cm2 können turbo- oder kompressorge-laden werden, um eine neue Herausforderung in der Motorenentwicklung hinzuzufügen.

• Die Fahrzeuge werden in drei Kategorien bewertet:

• STATISCH - Design- & Costreport, Marketingpräsentation

• DYNAMISCH I - Acceleration, Skid Pad

• DYNAMISCH II - Hot Lap, Endurance

Die Studenten sollen annehmen, dass ein Produktionsbetrieb ihnen den Auftrag erteilt hat,einen Rennwagen zu entwickeln und einen Prototypen zur Beurteilung zu bauen. Der ange-strebte Markt ist der der nichtprofessionellen Wochenendrennfahrer, Berg- und Sprintrenn-fahrer. Der Wagen muss daher hohe Beschleunigungs- und Bremsleistung sowie gute Hand-lingeigenschaften besitzen. Er muss günstig in der Anschaffung, bezahlbar im Unterhalt undvor allem zuverlässig sein. Des Weiteren wird der Marktwert des Fahrzeugs durch ein an-sprechendes Design, Komfort und die Verwendung von Bauteilen aus der Massenproduktiongesteigert. Der Hersteller plant 1.000 Fahrzeuge pro Jahr zu fertigen und sie zu einem Stück-preis unter 25.000 $ an den Kunden zu bringen. Die Herausforderung für ein Team besteht inder bestmöglichen Erfüllung all dieser Anforderungen. Innerhalb eines Jahres entwickeln dieTeams Prototypen, die dann auf den verschiedenen Wettbewerben (in den USA, Brasilien,Japan, England, Italien, Australien, Deutschland) miteinander verglichen werden. Weltweitgibt es inzwischen über 300 Teams, in Deutschland mit Beginn des Jahres 2006 über 30.

1.2. HAWKS Racing

Das Hawks Racing Team hat sich seit der Gründung im Jahre 2003 als studentisches Pro-jekt sämtlicher Fachrichtungen mit Schwerpunkt in den technischen Studiengängen an derHochschule für Angewandte Wissenschaften Hamburg etabliert. Am Beispiel eines Renn-wagens wird eine Firma simuliert, die innerhalb von zwei Semestern einen Prototypen biszur kleinserienreife entwickelt, und so die interdisziplinäre Ausbildung der Studenten fördert.Mit diesem Rennwagen nimmt das HAWKS Racing Team an internationalen Wettbewerbenteil, um dort Konstruktion, Kostenkalkulation, Vermarktung und Fahreigenschaften bewertenzu lassen. Die Wettbewerbe finden in unterschiedlichen Ländern wie z.B. in Italien, Englandund Deutschland statt. Das HAWKS Racing Team steht dabei in unmittelbarer Konkurrenzzu Hochschulen aus der ganzen Welt.

1. Einleitung 3

1.3. Motivation

Im Bereich des Motorsports gehören Telemetrie-Systeme schon seit vielen Jahren zu denganz wichtigen Hilfsmitteln. Hierzu ein Zitat von der BMW Motorsport Webseite:

Die Datenaufzeichnung trägt im modernen Motorsport nicht nur dazu bei, wich-tige Funktionen des Fahrzeugs nachvollziehen zu können. Sie liefert auch ent-scheidende Informationen über den Rennverlauf und die aktuelle Fahrsituation.Durch ihre vielfältigen Einsatzmöglichkeiten trägt die Datenerfassung heute ent-scheidend zum Erfolg auf der Strecke bei.

Auch in der Formula Student können die Informationen, die ein Telemetriesystem bereitstellt,nachhaltig zum Erfolg im Wettbewerb beitragen. Genau deshalb ist es so wichtig, dass mitHilfe der technischen Informatik ein Telemetriesystem, passend für die Anforderungen einesFormula Student Rennwagens, entwickelt wird. Da bei der Telemetrie viele Sensordaten an-fallen, ergeben sich interessante Möglichkeiten, auch Steuerungsaufgaben mit diesen Datenzu erledigen, die sonst nur manuell oder diskret gelöst werden konnten.

1.4. Zielsetzung und Anforderungen

Das Ziel ist es die Entwicklung und den erfolgreichen Betrieb im Wettbewerb des Rennwa-gens zu unterstützen. Um dieses Ziel zu erreichen soll ein System entwickelt werden, mitdem Telemetrie- und Steuerungsaufgaben in einem Formula Student Rennwagen bewältigtwerden können. Der Rennwagen soll dazu mit allen dazu benötigten Sensoren und Sys-temkomponenten ausgerüstet werden. Dabei ist es wichtig, dass das System individuell andie Bedürfnisse der Fahrzeugkonstrukteure angepasst werden kann. Insbesondere sollte ei-ne leichte Erweiterbarkeit gewährleistet sein, so dass zu jedem Zeitpunkt neue Funktionenintegriert werden können. Das System soll möglichst unabhängig vom Fahrzeug entwickeltwerden und dann über mehrere Fahrzeuggenerationen genutzt und ausgebaut werden. Eineeinfache Wartbarkeit und Bedienung des Systems soll für alle Personengruppen nach einerkurzen Einweisung gegeben sein. Diese und weitere Anforderungen sind in einem Lasten-heft, in Zusammenarbeit von Herrn S.Haase und mir erstellt, entsprechend den Wünschender Fahrzeugkonstrukteure, detailliert aufgeführt.

Folgende Funktionen soll das System nach Fertigstellung dieser Bachelorarbeit beherr-schen, wobei nur die entsprechend gekennzeichneten Bestandteil dieser Bachelorarbeitsind:

• Erfassen des Lenkwinkels.

• Erfassen der Raddrehzahlen aller vier Räder.

1. Einleitung 4

• Erfassen aller Daten die von der Motorsteuerung (ECU) zur Verfügung gestellt werden.

• Aufzeichnung aller anfallenden Daten.

• Liveübertragung aller Daten zum Kontrollstand (mit Visualisierung).

Die ersten drei Funktionen sind Bestandteil dieser Arbeit, alle anderen Funktionen sind Be-standteil der parallel laufenden Bachelorarbeit von Herrn Haase (2007), außer der Möglich-keit, die Daten der Motorsteuerung zu erfassen, das findet in einer parallel laufenden Arbeitstatt. Eine Erweiterung des Systems um Sensoren für Beschleunigung und Drehraten, mitder dazugehörigen Auswertung, wird im Anschluss dieser Arbeit stattfinden.

Da es sich um einen Rennwagen handelt, der auch möglichst gewichtssparend entwickeltwird, sollen auch alle elektronischen Komponenten so klein und leicht wie möglich gehaltenwerden.

1.4.1. Anforderungen durch Technische Gegebenheiten

Das System wird in einem offenen Rennwagen eingesetzt, es muss daher einige speziel-le Anforderungen erfüllen. Das System muss unempfindlich gegenüber Wasser, Schmutzund Erschütterungen sein. Es muss bei den in Europa typischen Außentemperaturbereichenohne Funktionsstörungen im Fahrzeug arbeiten. Dabei sind eventuelle höhere Temperatu-ren in einigen Fahrzeugbereichen zu berücksichtigen. Im Rennwagen steht nur begrenzterRaum für die Integration des Systems zur Verfügung. Die Stromversorgung ist durch einebestimmte Maximalleistung begrenzt.

1.4.2. Anwender

Es gibt zwei Hauptgruppen von Anwendern, die das System nach der Fertigstellung nutzenwerden.

• Fahrer: Der Fahrer bedient während der Fahrt Steuerfunktionen des Systems und be-kommt ggf. Rückmeldung über Anzeigen. Nach der Fahrt analysiert der Fahrer Fahr-fehler oder besondere Fahrsituationen anhand der aufgezeichneten Daten.

• Konstrukteure: Die Konstrukteure überwachen während der Fahrt Fahrzeug und Mo-torfunktionen am Kontrollstand und analysieren die Daten nach der Fahrt um aufge-tretene Fehlfunktionen oder andere Motor-Abstimmungen zu analysieren.

1. Einleitung 5

1.5. Randbedingungen

Im folgenden Abschnitt werden die Randbedingungen aufgezeigt, unter der die vorliegendeArbeit erstellt wurde.

Es wurde kurz vor Beginn dieser Arbeit eine Baugruppe Informatik im HAWKS Racing Teamgegründet. Die anderen Baugruppen hatten zu diesem Zeitpunkt bereits vor einem halbenJahr ihre Arbeit aufgenommen. Sie besteht aus einem halben Dutzend Informatik Studentendes dritten und vierten Semesters, sowie aus zwei Bacheloranten. Die technische Leitungder Baugruppe obliegt den beiden Bacheloranten.

Am Projekt HAWK07 sind folgende Baugruppen beteiligt, mit der sich die Informatik direktberaten muss:

• Motor und Antrieb

• Fahrwerk

• Exterieuer

• Interieur

• Elektrik

Die Anforderungen wurden ausgiebig mit der Baugruppe Motor und Antrieb, sowie der Bau-gruppe Fahrwerk ausgearbeitet. Für die spätere Integration im Fahrzeug war eine engeZusammenarbeit mit den restlichen oben aufgeführten Baugruppen, äußerst wichtig. Da-bei gab es neben den Gesprächen mit den einzelnen Teammitgliedern auch immer wiederDiskussions- und Informationstreffen mit dem gesamten Team.

1.5.1. Ressourcen

Da diese Arbeit parallel zu der Entwicklung und Montage des Fahrzeuges stattfand, konn-ten anfangs wichtige Detailinformationen vom Fahrzeug und der Informatik ausschließlichanhand von Plänen und technischen Zeichnungen ausgetauscht werden. Dafür ließen sicheinige benötigte Konstrukte, wie Halterungen oder elektrische Anforderungen, mit in die Pla-nung des Fahrzeuges einfließen. Dies betraf aber nur wenige kleine Details. In späteren,weiter fortgeschrittenen Phasen, konnte auch am Fahrzeug selbst getestet und geplant wer-den. Des weiteren stand das Vorjahres Fahrzeug der HAWK06 zu Besichtigungszwecken zurVerfügung. An ihm konnten die technischen Eigenschaften eines Formula Student Rennwa-gens begutachtet werden. Bei dem Fahrzeug handelt es sich um ein Prototyp, von dem keine

1. Einleitung 6

weiteren Modelle geplant sind. Es ist jedoch geplant, jedes Jahr ein neues Modell zu entwi-ckeln und zu bauen, das auf den positiven Erfahrungen des jeweiligen Vorgänger Modellsaufbauen soll.

2. Gesamtkonzept

2.1. Architektur

Es gibt verschiedene Möglichkeiten ein System aufzubauen, das Sensoren enthält, auswer-tet, die Daten speichert und per Funk an Dritte versendet, sowie die Daten nutzt um Aktorenanzusteuern. Dabei gibt es sowohl Unterschiede in der äußerlichen Gestalt, als auch von derinternen Realisierung. Systeme lassen sich als zentral oder verteilt (dezentral) aufbauen.

Eine zentrale Lösung könnte sein, einen Industrie PC mit Erweiterungskarten für die Aus-wertung von Sensoren, die Steuerung von Aktoren und Datenfunk in das Fahrzeug zu in-tegrieren. Die Hardware würde so aus Komponenten bestehen, die am Markt von verschie-denen Herstellern, inklusive Treiber und Zubehör, bezogen werden könnten. Treiber und einBetriebssystem müssten so nicht selbst entwickelt werden. Bei dem Rennwagen sind dieSensoren über das gesamte Fahrzeug verteilt. Eine zentrale Lösung hat hier den Nachteil,dass von den verschiedenen Sensoren lange Leitungen zu dem Auswerte- und Steuerge-rät durch das Fahrzeug gelegt werden müssen. Die oft analogen elektrischen Größen, diebei Sensoren anfallen, sind bei der Übertragung über längere Leitungswege stärker fremdenStöreinflüssen ausgesetzt als bei kurzen Leitungswegen. Außerdem bedeuten längere Lei-tungen auch ein höheres Gewicht, das es bei diesen Rennwagen jedoch einzusparen gilt.Zudem hat so ein Industrie PC mit diversen Zusatzkarten eine Größe, die in dem Rennwagensehr schwer unterzubringen ist.

Bei einem verteilten System werden die Einheiten, zum Auswerten der Sensordaten, naheden Sensoren platziert. Diese übernehmen die Auswertung eines oder auch mehrerer Sen-soren vor Ort. Sie sind weniger komplex, sowohl in der Hardware, als auch in der Software,als ein zentrales System, da sie nur eine Teilfunktion des gesamten Systems übernehmen.Über ein geeignetes Kommunikationssystem tauschen sie Daten mit den anderen Kompo-nenten aus.

Die einzelnen Komponenten können so deutlich kleiner und leichter gebaut werden. Die Lei-tungslängen zu den Sensoren fallen deutlich kleiner aus und sind somit Gewichtssparenderund weniger störempfindlich. Es werden längere Leitungen nur noch für die Kommunikationzwischen den Komponenten benötigt, die aber, wenn ein serielles Übertragungsverfahrengenutzt wird, in der Anzahl sehr klein sind (geringe Aderzahl in den Leitungen).

2. Gesamtkonzept 8

Bei einem verteilten System kann man die Steuerung des gesamten Systems einem Haupt-rechner oder auch den einzelnen Komponenten überlassen. Zwei Möglichkeiten sind hier inden Abbildungen 2.1 und 2.2 zu sehen.

ECU

HauptrechnerARM7, ARM9, x86, ...

Flash(SD-card)

Datalogging

Wi-PortW-Lan

CAN-Bus

RS-232

SPI

AVRSensoren- Auswertung

Verschiedene Sensoren


Verschiedene Aktoren


Verschiedene Aktoren und Sensoren

Abbildung 2.1.: Systementwurf mit Hauptrechner

Zu Abbildung 2.1: Als Hauptrechner könnte ein kleines x86 System, genauso gut wie einARM9 oder gar nur ein ARM7, zum Einsatz kommen. Der Hauptrechner übernimmt hier dieAufgaben der Datenspeicherung, der Übermittlung der Telemetriedaten über WLAN und dieKommunikation mit der Motorsteuerung (ECU). Außerdem sorgt er für den Datenaustauschmit den, über CAN-Bus, angebundenen Modulen. Die Idee bei diesem Lösungsansatz ist,dass ähnliche Aufgaben wie das Speichern und Versenden von Daten, von einem Geräterledigt werden, um z.B. die Softwareentwicklung zu vereinfachen.

Zu Abbildung 2.2 auf Seite 9: Anstelle des Hauptrechners werden hier mehrere Mikrocontrol-ler eingesetzt, die jeweils eine Aufgabe des Hauptrechners übernehmen. Ein Grund, auchähnliche Aufgaben von getrennten Modulen erledigen zu lassen, ist die erhöhte Ausfallsi-cherheit. Fällt ein Modul aus, kann das andere Modul noch weiter arbeiten. Beispiel: DasModul für den Datenversand via WLAN fällt aus, die Datenaufzeichnung arbeitet aber weiter.Nun können die Daten zwar nicht mehr live verfolgt werden, sie lassen sich aber hinterher

2. Gesamtkonzept 9

ECU

Flash(SD-card)

Wi-PortW-Lan

CAN-Bus

RS-232

RS-232 SPI

AVRGATEWAY

AVRWirelessCommunication

AVRDatalogging

CAN-Bus


Verschiedene Sensoren


Verschiedene Aktoren


Verschiedene Aktoren und Sensoren

Abbildung 2.2.: Systementwurf ohne Hauptrechner

2. Gesamtkonzept 10

noch auswerten. Bei einem System, wo beide Funktionen von einem Gerät übernommenwerden, hätte man überhaupt keine Daten mehr vorliegen.

Die Wahl fällt auf das System ohne Hauptrechner. Die erhöhte Ausfallsicherheit sowie Fle-xibilität, überzeugen in diesem Fall. Zudem besteht die Möglichkeit, alle Module nun mitdem gleichen Mikrocontroller auszustatten, was evtl. eine einheitliche Softwarearchitekturzu lässt. Die Entscheidung wurde in Absprache mit Herrn S. Haase getroffen, der in seinerBachelorarbeit die Entwicklung des WLAN-Komunikations- und des Datenaufzeichnungsmo-duls beschreibt.

AVR VorderachseGeschwindigkeit

AVR HinterachseGeschwindigkeit

ECU

Flash(SD-card)

Wi-PortW-Lan

CAN-Bus

RS-232

RS-232 SPI

2x Sensorlager 2x Sensorlager

AVRGATEWAY

AVRWirelessCommunication

AVRDatalogging

Lenkwinkelsensor

AVRLenkwinkel

AVRTimeMaster

AVRBeschleunigungDrehrate (Giro)

3 Achsen Drehratensensor

3 Achsen Beschleunigungs-sensor

Abbildung 2.3.: Systementwurf

In der Abbildung 2.3 ist jetzt die endgültige Systemarchitektur mit allen Modulen, die in derersten Phase in das System integriert werden sollen.

2.1.1. Die Module

Das System wird zunächst aus den folgenden sechs verschiedenen Modulen bestehen:

2. Gesamtkonzept 11

• Time-Master - Systemsteuerung

• Communicator* - WLAN-Datenübertragung

• Datenlogger* - Datenaufzeichnung

• Raddrehzahl - Ermittelt die aktuelle Fahrzeuggeschwindigkeit (für jedes Rad einzeln)

• Lenkwinkel - Ermittelt den aktuellen Lenkwinkel

• ECU-Modul - Ermittelt die akruellen Motordaten

Von dem Raddrehzehl-Modul wird es zwei Stück geben, eins für die vorderen Räder undeins für die hinteren Räder. Die mit * gekennzeichneten Module sind Bestandteil der Bache-lorarbeit von Herrn S. Haase (2007). Das ECU-Modul ist ebenfalls nicht Bestandteil dieserArbeit.

2.1.2. CAN Bus

Der CAN-Bus (Controller Area Network) gehört zu den Feldbussen. Es ist ein asynchrones,serielles Bussystem, dass für den Automotiv Bereich 1983 von der Firma Bosch entwickeltwurde. Es ist speziell für die Vernetzung von Steuergeräten in Fahrzeugen gedacht.

Um bei der asynchronen Datenübertragung Kollisionen zu vermeiden, bei denen beide Sen-der erneut senden müssten, wird das CSMA/CA Verfahren eingesetzt. Dabei wird der Bus-zugriff verlustfrei mit einer bitweisen Arbitrierung auf Basis der Identifier der zu sendendenNachricht aufgelöst. Die Übertragung erfolgt normalerweise nicht zeitgesteuert.

Bei der Übertragung arbeitet der CAN-Bus normalerweise mit Differenzsignalen. Die Diffe-renzsignale werden meistens mit 3 Leitungen ausgeführt: CAN-HIGH, CAN-LOW und CAN-GND (Masse). CAN-LOW enthält den komplementären Pegel von CAN-HIGH gegen Masse.Dadurch können Gleichtaktstörungen unterdrückt werden, da die Differenz gleich bleibt.

Zusätzlich werden noch weitere Methoden zur Störungsunterdrückung bei der Datenüber-tragung eingesetzt, auf die hier nicht weiter eingegangen wird.

Der CAN-Bus unterstützt, je nach Leitungslänge, unterschiedliche Übertragungsraten. Diemaximalen (theoretisch) möglichen Übertragungsraten sind z.B. bei 40 m 1 Mbit/s, bei 100m sind 500 kbit/s möglich und bei 500 m 125 kbit/s.

Dar CAN-Bus wird heute in fast jedem modernen Automobil eingesetzt.

2. Gesamtkonzept 12

2.2. Time-Triggered versus Event-Triggered

Es gibt verschiedene Möglichkeiten, wie man das Erfassen von Daten steuert. Die Ausgangs-situation: Es gibt eine endliche Anzahl von Modulen, die Daten von verschiedenen Sensorenerfassen. Drei mögliche Ansätze:

• Jedes Modul erfasst die Daten so schnell wie möglich, bzw. wenn Änderungen auftre-ten, und sendet sie dann auf den CAN-Bus. Das ganze System ist ereignisgesteuert(Event-Triggered-System).

• Jedes Modul erfasst die Daten nach einem eigenen Zeitplan und sendet sie, von derinternen Uhr gesteuert, auf den CAN-Bus. Nur die einzelnen Module sind zeitgesteuert(Time-Triggered-Module).

• Alle Module arbeiten nach einem globalen Zeitplan und arbeiten synchron zu einerglobalen Systemzeit. Das System ist komplett zeitgesteuert (Time-Triggered-System).

Wenn jedes Modul für sich arbeitet und seine ermittelten Daten irgendwann über den CAN-Bus verschickt (Event-Triggered-System), auch wenn es in regelmäßigen Abständen pas-siert (Time-Triggered-Module), kann keine genaue Aussage getroffen werden, welche Datenwann gesendet werden. Da die internen Uhren der Module zu einander nicht synchron ar-beiten, wird sich das Datenaufkommen auf dem CAN-Bus ständig verschieben. Zu einemZeitpunkt werden die Nachrichten gleichmäßig über ein Zeitintervall verteilt sein und zu ei-nem anderen Zeitpunkt senden alle Module fast gleichzeitig, was dann auch zu Kollisionenführt.

Damit die Daten später bestimmten Zeitpunkten zugeordnet werden können, ist es von Vor-teil, wenn man in einem definierten Zeitintervall garantiert alle erforderlichen Daten erhält.Beispiel: Der Motor hat zu bestimmten Momenten Aussetzer. Um das Problem genau analy-sieren zu können, werden die aufgezeichneten Daten eines bestimmten Zeitpunkts benötigt.Jetzt kommt es darauf an, dass die Daten aus einem besonders kleinen Zeitraum von ver-schiedenen Sensoren zur Verfügung stehen. Bei einem Time-Triggered-System ist nun ge-nau nachvollziehbar zu welchem Zeitpunkt die Daten angefallen sind. Zudem ist garantiert,dass in einem bestimmten Zeitintervall die erforderlichen Daten immer wieder vorhandensind. Es gibt keine zeitlichen Verschiebungen durch Kollisionen auf dem CAN-Bus.

Ein anderer Grund der für ein Time-Triggered-System spricht ist, dass das System auchfür Steuerungsaufgaben ausgelegt sein soll. Dann ist es besonders wichtig, dass Sensor-daten garantiert zu einem bestimmten Zeitpunkt aktualisiert vorliegen. Ein Beispiel: Es sollein ABS-Modul in das System integriert werden. Das ABS-Modul greift dabei direkt in dieBremssteuerung ein und verhindert ein Blockieren der Räder bei einer Vollbremsung. So einModul muss absolut zuverlässig arbeiten und in angemessen kurzer Zeit reagieren. Dazuist das Modul darauf angewiesen, dass die erforderlichen Sensordaten, wie z.B. von den

2. Gesamtkonzept 13

Raddrehzahlen, in einem bestimmten Zeitintervall aktualisiert vorliegen. Eine Verzögerungoder sogar ein Ausbleiben der Daten ist dann inakzeptabel. Das die Daten garantiert recht-zeitig vorliegen, kann nur mit einem Time-Triggered-System realisiert werden oder, in demdie Sensoren direkt mit dem Steuerungsmodul verbunden werden, was hier nicht der Fall ist.Bei einem Time-Triggered-System wird jede Nachricht zu einem ganz bestimmten Zeitpunktauf den CAN-Bus gesendet. So gibt es keine Kollisionen die die Nachrichtenübertragungverzögern könnten.

2.3. Time-Triggered-Architektur

Damit ein verteiltes System zeitgesteuert arbeitet und kommuniziert, müssen alle beteiligtenModule zeitlich Synchron arbeiten. Da die Quarze der verschiedenen Module zwar sehr ge-nau ihre Taktfrequenz einhalten, aber eben dies nicht zu einhundert Prozent schaffen, musseine Lösung gefunden werden, mit der man die zeitlichen Drift der verschiedenen Moduleausgleichen oder korrigieren kann. Es gibt verschiedene Ansätze mit denen sich so ein Pro-blem lösen lässt. Bei allen hier genannten Möglichkeiten wird, wenn die Rede von der Clockist, immer nur die Erzeugung des Taktes für den Scheduler gemeint und nicht die Clock diemit Hilfe des Quarzes für den Takt des Mikrocontrollers verantwortlich ist. Es wird für alleModule immer der, in 3.1.2 diskutierte, Scheduler verwendet. Es ändert sich bei den Slavesnur die Clock für den Scheduler.

Einige Möglichkeiten der Synchronisation:

• Shared-Clock Scheduler via CAN-Bus: Ein Master verfügt über eine Clock, auf de-ren Basis die Zeitsteuerung aller Module (Slaves) realisiert wird. Die Slaves nutzenkeinen eigenen Timer für das Scheduling. Der Master verschickt mit jedem Timertickeine so genannte Tick-Message an alle Slaves. Empfängt ein Slave eine solche Tick-Message, löst diese den, für den Scheduler erforderlichen, Interrupt aus. Ein Nachteildieser Lösung ist, dass bei kurzen Timerticks sehr viele Tick-Messages die Auslastungdes Busses in die Höhe treiben. Zudem ist die Regelung für den Nachrichtenversandder Slaves aufwendig, wobei der Aufwand mit steigender Anzahl von Slaves zunimmt.Daher ist diese Lösung nur für eine geringe Anzahl von Slaves und einem langenTimertick gut.

• Shared-Clock Scheduler via externen Interrupts: Die Slaves werden mit dem Masterüber extra Leitungen synchronisiert. Die Leitungen werden an Interrupt fähigen Ein-gängen der Slaves angeschlossen. Der Master verschickt dann zu jedem Timertickeine Pulse-Message. Der, dann am Slave ausgelöste, Interrupt wird als Clock für denScheduler genutzt. Ein Vorteil dieser Lösung ist die einfache Implementierbarkeit in

2. Gesamtkonzept 14

Time-Master

Slave 2 Slave nSlave 1

CAN-Bus

Abbildung 2.4.: Shared-Clock Scheduler via CAN-Bus

den Programmcode und, dass die Kommunikation über den CAN-Bus von dieser Lö-sung unberührt bleibt. Die Nachteile dieser Lösung sind, dass eine extra Leitung denMaster mit allen Slaves verbinden muss. Dies kann in einem Fahrzeug erheblichenMehraufwand bedeuten, außerdem wird ein, vielleicht dringend benötigter, Eingangdes Mikrocontrollers blockiert. Und sollten Störungen auf den Leitungen verursachtwerden, z.B. durch EMV, hätte dies fatale Auswirkungen. Das ganze System könnteasynchron weiter laufen, womit die Echtzeitanforderungen nicht mehr erfüllt werden.

Time-Master


ext. Int. ext. Int. ext. Int.

Abbildung 2.5.: Shared-Clock Scheduler via externen Interrupts (CAN-Bus nicht dargestellt)

• Synchronisation mehrerer Clocks via CAN-Bus: Jeder Slave hat seinen eigenen Timerfür die Clock. In festen Zeitabständen sendet der Master eine Time-Master-Nachricht(TM-Nachricht) an alle Slaves. Die Zeit zwischen zwei TM-Nachrichten ist dabei deut-lich länger, als die Zeit eines Timerticks. Die Slaves messen die Zeit zwischen zweiTM-Nachrichten und vergleichen sie mit einer Sollzeit. Die Differenz zwischen derSollzeit und der gemessenen Zeit stellt die Zeit dar, um die die interne Clock vor-,bzw. nachgestellt wird. In Abhängigkeit des Abstandes der TM-Nachrichten und derToleranz der Quarze ergibt sich die maximale Varianz zwischen den Clocks der ver-schiedenen Module. Ein Nachteil bei dieser Lösung ist, dass ein höherer Aufwandim Vergleich zu den anderen Lösungen bei der Implementierung besteht. Ein großer

2. Gesamtkonzept 15

Vorteil ist, dass durch das Versenden der TM-Nachricht keine hohe Auslastung desCAN-Busses entsteht. Außerdem bleibt der Nachrichtenversand genauso flexibel, wiebei der Lösung mit externen Interrupts, und erlaubt so auch den Betrieb mit vielenTeilnehmern.

Time-Master


CAN-Bus

Abbildung 2.6.: Synchronisation mehrerer Clocks via CAN-Bus

2.3.1. Globale Systemzustände und Steuerfunktionen

Steuerbefehle werden, vom Communicator ausgehend, über den CAN-Bus an die Moduleversandt. Es gibt zwei Arten von Steuerbefehlen, globale Steuerbefehle und Steuerbefehledie nur ein bestimmtes Modul betreffen. Globale Steuerbefehle betreffen alle Module glei-chermaßen. Alle Module müssen diese Befehle empfangen und entsprechend reagieren.Steuerbefehle die nur ein bestimmtes Modul betreffen, werden individuell für die Modulefestgelegt.

Über globale Steuerbefehle kann das System in verschiedene Zustände versetzt werden.Für das System werden zwei globale Systemzustände eingeführt:

• Busmode-On: In diesem Systemzustand arbeiten alle Module normal und dürfenNachrichten über den CAN-Bus senden.

• Busmode-Off: In diesem Zustand sind alle Module betriebsbereit, dürfen aber keineNachrichten über den CAN-Bus versenden. Der Time-Master versendet weiterhin dieTM-Nachricht und der Communicater darf Nachrichten mit Steuerbefehlen versenden.Es ist auch möglich, das ausgewählte Module nach expliziter Aufforderung durch Steu-erbefehle Nachrichten versenden dürfen. Dieser Systemzustand ermöglicht es, z.B.Daten aus einem Speicher mit hoher Datenrate über den CAN-Bus zu versenden.

Die Systemzustände werden mit jeder TM-Nachricht an alle Module mitgeteilt.

Des weiteren gibt es einen globalen Steuerbefehl der ein Reset aller Module bewirkt.

2. Gesamtkonzept 16

2.4. Die Hardware

2.4.1. Der Atmel AVR AT90CAN128

Der AT90CAN128 ist ein sehr vielseitiger Mikrocontroller der uns auch aus verschiedenenVeranstaltungen an der HAW Hamburg bekannt ist. Es handelt sich bei dem AT90CAN128um einen 8 Bit Mikrocontroller in RISC-Architektur der bei maximal 16 MHz bis zu 16 Mips1

erreichen kann. Er hat 128 kByte Programmspeicher und 4kByte Arbeitsspeicher und ist so-mit auch für aufwendigere Programme geeignet. Für analoge Messgrößen ist er mit einemAnalog-Komparator ausgestattet, der auch als Analog-Digital-Wandler mit acht Multiplex-Eingängen arbeiten kann. Er hat verschiedene serielle Schnittstellen, inklusive eine für dieseArbeit wichtige CAN-Bus Schnittstelle. Dabei handelt es sich um einen vollständigen CAN-Bus-Controller der die Standards 2.0A und 2.0B unterstützt und mit einem Puffer für 15CAN-Nachrichten ausgestattet ist. Es gibt ihn in einer industriellen und einer Automotiv Ver-sion.

Für die Softwareentwicklung stehen verschiedene Tools zur Verfügung, die Wichtigsten sind:das AVR-Studio von Atmel, WinAVR mit dem GCC-Compiler für Atmel AVRs und weiterenützliche Tools. Mit den WinAVR-Tools ist es auch möglich komfortabel mit Eclipse Pro-gramme zu schreiben und auch auf den Mikrocontroller zu laden. Eine komfortable Debug-Möglichkeit bietet das AVR-Studio in Verbindung mit der Jtag-Schnittstelle des AVRs.

Abbildung 2.7.: Evolution-Board des Labors für Technische-Informatik der HAW (Design vonB. Carstensen)

Zu dem gibt es an der HAW Hamburg eine passende Platine, die jegliche Ein- und Ausgänge,sowie alle Schnittstellen des Mikrocontrollers zur Verfügung stellt und entsprechende Treiber-

1Million instructions per second

2. Gesamtkonzept 17

bausteine, z.B. für den CAN-Bus und die RS232-Schnittstelle, bereit stellt. Sie hat außerdemeine eigene 5 Volt Spannungsstabilisierung und Sockelleisten für einfaches kontaktieren vonexterner Hardware an den Mikrocontroller Schnittstellen. Mit dieser Platine lassen sich ein-fach Versuchsaufbauten realisieren. Zudem können auch die endgültigen Module mit ihnenaufgebaut werden. Es werden bei der Bestückung der Platine einfach nur die benötigtenBauteile verwendet. Mit einem Preis, Platine mit Bauteilen inklusive Mikrocontroller, von un-ter 50 Euro ist es auch eine recht günstige Lösung. Daher habe ich mich für meine Module,genauso wie Herr S. Haase für seine Module, für diesen Mikrocontroller entschieden.

In Tabelle 2.1 auf Seite 19 sind wichtige Kenndaten mit Beschreibung zusammengefasst. Füralle Kenndaten des Atmel AVR AT90CAN128 siehe Datenblatt.

2.4.2. Gehäuse, Stecker und Leitungen der Module

Die Gehäuse für alle Module sind aus Aluminiumblech. Das Material lässt sich leicht bear-beiten und bietet eine gute elektrische Abschirmung (siehe hierzu auch EMV-Maßnahmen4.1). Kunststoffgehäuse bieten keine elektrische Abschirmung und lassen sich nicht so ein-fach bearbeiten wie Aluminiumbleche. Zum Beispiel lassen sich die Aussparungen für dieStecker einfach ausstanzen, was viel Arbeit und Zeit spart. Die Platinen mit den Mikrocon-trollern werden mit Abstandsbolzen mittig am Boden der Gehäuse angebracht. Der Span-nungsregler für die Stromversorgung wird an einer breiten Gehäuseseite, isoliert durch einGlimmerplättchen, angeschraubt. Das Gehäuse dient dabei als Kühlkörper für den Span-nungsregler. Auf der gegenüberliegenden Seite werden jeweils ein Stecker und eine Buchsefür den CAN-Bus angebracht, sowie ggf. ein weiterer Stecker oder eine weitere Buchse fürSensor oder Datenleitungen. Alle Stecker und Buchsen sind als neunpolige Sub-Ds ausge-führt. Alle Stecker und Buchsen werden mit Hilfe von Gummistreifen wasserdicht montiert.Auf der gleichen Seite werden, am unteren Rand, drei Leuchtdioden mit Reflektorgehäuseeingebaut. Die Leuchtdioden werden für verschiedene Statusanzeigen genutzt, die ,je nachModul, unterschiedliche Bedeutungen haben. Die Gehäuse werden vor dem Einbau in dasFahrzeug mit Moosgummistreifen in den Deckeln wasserdicht verschlossen.

Die Spannung wird in zwei Schritten von den 12-15 Volt des Fahrzeugbordnetzes auf die be-nötigten 5 Volt reduziert. Ein zentrales Netzgerät stellt zunächst eine stabilisierte Spannungvon 9 Volt, bei einem maximalen Strom von 6 Ampere zur Verfügung. Der maximale Stromreich derzeit aus, um das ganze System zu versorgen. Der zweite Schritt erfolgt im jeweili-gen Modul, mit dem Spannungsregler auf der Platine des Mikrocontrollers. Das Reduzierender Spannung in zwei Stufen hat den Vorteil, dass die Wärmeentwicklung im Modul nichtso groß wird, als wenn dort die ganze Spannungsreduzierung stattfinden würde. Außerdemergibt sich noch ein weiterer Vorteil, der in 4.1 beschrieben wird.

2. Gesamtkonzept 18

Abbildung 2.8.: Fertigung eines Moduls

2. Gesamtkonzept 19

Funktion / Eigenschaft Beschreibung / Erklärung

8 Bit RISC Architektur Fast alle Befehle werden in einem Takt ausge-führt

Bis zu 16 MHz Taktfrequenz Durch die Risc Architektur können bei 16 Mhzbis zu 16 Millionen Operationen pro Sekundeausgeführt werden.

128 kByte In-System reprogrammier-barer Flashspeicher (Programmspei-cher)

Großzügiger wiederbeschreibbarer Pro-grammspeicher für umfangreiche Software.

Internes 4 kByte EEPROM Für die Speicherung von Werten die zur Lauf-zeit anfallen wie z.B. Teach-in Werte und Log-daten.

Interner 4 kByte SRAM Großzügiger Arbeitsspeicher.Optionale Boot Code Sektion Mit einem Bootprogramm kann zum Pro-

grammstart Programmcode über verschiede-ne Schnittstellen geladen werden.

JTAG-Interface Zum Beschreiben von Programmspeicher undEEPROM, sowie zum Debuging im TargetSystem.

CAN-Controller mit Register für 15komplette Message-Objekte, Time-Stamping, TTC-Mode untestützung

Nachrichten können parallel zur Programm-ausführung empfangen und gesendet werden,die Sende- bzw. Empfangszeit wird automa-tisch zur jeweiligen Nachricht gespeichert. imTTC-Mode werden Nachrichten auch im Feh-lerfall nur einmal gesendet.

Zwei 8 Bit und zwei 16 Bit Timer mitverschiedenen PWM- und Compare-Modes und Zählfunktionen für exter-ne Ereignisse

Verschiedene Steuer- und Zählfunktionen las-sen sich mit den Timern realisieren.

8 Kanal (multiplex) 10 Bit Analog-Digital-Konverter

Ermöglicht eine direkte Anbindung von Ana-logsensoren.

Analog Komparator Für das Vergleichen von Analogen Größen,z.B. von analogen Sensoren.

Zwei serielle UARTS Für die Kommunikation mit anderen Geräten,Diagnose über Terminal usw..

SPI Schnittstelle Betrieb als Mas-ter/Slave

Für die Kommunikation mit anderer Hardware,wie z.B. Sensoren, Mikrocontrollern, SD-Cardusw..

TWI Schnittstelle Für die Kommunikation mit anderer Hardwarewie z.B. Sensoren, Auswerte ICs usw..

Integrierte Power-on Reset undBrown-out Detection

Keine externen Bausteine für Einschaltresetund Unterspannungserkennung nötig.

53 digitale Ein- Ausgänge Konfigurierbar, mit Pull-Up Funktion.Interner Watchdog Keine externe Hardware für die Laufzeitüber-

wachung notwendig.5 verschiedene Sleep-Modes Integrierte Stromsparfunktionen.

Tabelle 2.1.: Einige wichtige Kenndaten des Atmel AVR AT90CAN128

3. Realisierung

3.1. Der Scheduler

3.1.1. Eine Software-Architektur für alle Module

Anforderungen

Damit die einzelnen Module leicht programmierbar und wartbar sind, ist es sinnvoll eineeinheitliche Programmarchitektur zu verwenden.

Um verschiedene Aufgaben auf einem Mikrocontroller bearbeiten zu können, ohne dass derCode unübersichtlich wird, soll es die Möglichkeit geben verschiedene Tasks gleichzeitig aufdem Mikrocontroller laufen zu lassen. Eine Aufgabe wird dabei immer innerhalb einer Taskerledigt. Dabei kann es vorkommen, dass bestimmte Aufgaben zu einen ganz bestimmtenZeitpunkt erledigt werden müssen. Teilweise handelt es sich um periodisch wieder abzuar-beitende Aufgaben, teilweise um einmalige Aufgaben.

Beispiele für periodische Aufgaben:

• Die Geschwindigkeit des Fahrzeugs soll alle 40ms ermittelt werden.

• Eine Nachricht soll alle 10ms zu einer bestimmten Zeit über den CAN-Bus gesendetwerden.

• Das TX- und RX-Register für eine RS232-Schnittstelle soll entsprechend der einge-stellten Baudrate bedient werden.

• Rücksetzen eines Watchdogs.

• Die Tasten für die Eingabe von Befehlen müssen alle 40ms abgefragt werden.

Beispiele für einmalige Aufgaben:

• Initialisierung vom System, z.B. Nullpunkteinstellung (Motor drehen bis Nullpunkt er-reicht).

• Feststellen von Ausgangzuständen des Systems nach dem Einschalten.

3. Realisierung 21

Für das in dieser Bachelorarbeit beschriebene System müssen eine Reihe von Anforder-ungen von der Software-Architektur erfüllt werden. Folgende Anforderungen sind zwingenderforderliche Anforderungen und müssen somit erfüllt werden:

• Es soll harte Echtzeit garantiert werden.

• Tasks sollen periodisch oder nur einmalig ausgeführt werden können.

• Es soll die Möglichkeit bestehen, zeitlich kurze Aktionen in einem schnellen Intervallauszuführen.

• Die Tasks sollen eine unterschiedlich lange Ausführungzeit haben dürfen. Das gilt so-wohl für eine Task selber, das heißt, sie darf je nach Situation mal etwas länger maletwas kürzer in ihrer Ausführungszeit sein. Zum anderen gilt es für die Tasks unterein-ander, das heißt, dass nicht alle Tasks die gleiche Ausführungsdauer haben müssen.

• Der Zeitpunkt wann eine Task ausgeführt wird muss vorher festgelegt werden können.

• Die Software-Architektur soll Ressourcen schonend sein. Das heißt, es soll nur soviel Programm- und Arbeitsspeicher von der Architektur benutzt werden wie unbedingtnötig. Außerdem soll sie nicht viel CPU-Zeit in Anspruch nehmen.

• Sie soll einfach zu konfigurieren sein.

Folgende Anforderungen sind wünschenswerte Anforderungen und müssen somit nicht un-bedingt erfüllt werden:

• Tasks lassen sich zu einem beliebigen Zeitpunkt hinzufügen.

• Tasks lassen sich zu einem beliebigen Zeitpunkt entfernen.

• Funktionen die zum Auffinden von Fehlern helfen (Debug-Funktionen).

Es bietet sich dafür an, eine Art Betriebssystem zu entwickeln. Ein so umfangreiches Be-triebssystem, wie es auf einem Standart-PC läuft, kommt dabei nicht in Frage. Dieses Be-triebssystem braucht keine grafischen Schnittstellen um mit einem Anwender zu kommu-nizieren. Das System braucht auch keine Zugriffs-Funktionen für Drucker, Festplatten oderandere Peripherie zur Verfügung zu stellen. Das System braucht eine Funktion, die sichdarum kümmert, dass verschiedene Aufgaben bzw. Tasks abgearbeitet werden, einen sogenannten Scheduler.

3. Realisierung 22

Die Super Loop

Eine einfache Programmarchitektur für eine solche Aufgabe ist die so genannte Super Loop.Bei der Super Loop werden alle abzuarbeitenden Tasks hintereinander in einer großen Pro-grammschleife abgearbeitet. Um bestimmte Zeiten einzuhalten, können Zeitverzögerungen(delays) in die Schleife zwischen den Tasks eingefügt werden. Diese recht primitive Art desSchedulings ist zwar sehr Ressourcen sparend aber es gibt viele Einschränkungen die manberücksichtigen muss. Die zwei Wichtigsten sind:

1. Die Dauer der vorhandenen Tasks müssen genau bekannt sein.

2. Die Dauer der Tasks dürfen niemals variieren, sonst können die Zeitvorgaben nichteingehalten werden.

In einigen Fällen reicht diese Art des Schedulings vielleicht aus, für die oben genanntenAnforderung aber nicht.

Auf Harware-Timer basierendes Scheduling

Eine bessere Lösung ist es, ein auf Timer Interrupts und Interrupt Service Routinen (ISR)basierendes Scheduling zu verwenden. Dabei wird für jede Task eine eigene Interrupt Ser-vice Routine geschrieben, die dann bei Ablauf des jeweiligen Timers aufgerufen wird. Damitist es möglich die einzelnen Tasks zu einem exakt vorher bestimmten Zeitpunkt auszuführen.Dabei dürfen die Tasks jetzt auch eine unterschiedlich lange Ausführungszeit haben, ohnedas es sich auf den Startzeitpunkt der nächsten Task auswirkt, vorausgesetzt es werdeneinige wichtige Punkte beachtet. Die Tasks können periodisch, oder nur ein einziges malausgeführt werden, je nachdem, ob in der ISR der Timer deaktiviert wird oder nicht. Auchdiese Art des Schedulings hat einige Nachteile:

1. Jede Task braucht einen eigenen Timer. Daraus ergeben sich folgende Nachteile:

• Die Anzahl der Tasks ist durch die Anzahl der Timer begrenzt.

• Wenn alle Timer von der Software benutzt werden und zu einem späteren Zeit-punkt noch neue Funktionen in Form von Tasks hinzugefügt werden sollen, istdas nur mit einem Hardware Wechsel möglich.

• Großer Verbrauch von Hardware Timern.

2. Treten mehrere Interrupts gleichzeitig auf kann es zu großen Problemen kommen.

3. Ist eine Task noch nicht fertig und es tritt ein neuer Interrupt auf kann dies auch zuverschiedenen Problemen führen.

3. Realisierung 23

Scheduler mit nur einem Hardware-Timer

Ein vernünftig einsetzbarer Scheduler sollte mit nur einem einzigen Hardware-Timer aus-kommen. In der ISR des Schedulers werden dann zu bestimmten Zeitpunkten die entspre-chenden Tasks ausgeführt. Für den Scheduler macht es keinen Unterschied, ob nur eine,fünf oder einhundert Tasks periodisch oder einmalig ausgeführt werden sollen. Es mussdann nur noch ein einziger Hardware-Timer initialisiert werden. Bei den meisten Standart-PC Betriebssystemen arbeitet der Scheduler auch mit nur einer einzigen ISR bzw. einemHardware-Timer.

Kooperativer Scheduler

Ein kooperativer Scheduler stellt eine so genannte Single-Tasking System Architektur dar.Das heißt, dass nur eine Task zur Zeit und bis zum Ende ausgeführt wird. Die laufende Taskkann also nicht unterbrochen werden (non preemtive scheduling). Die nächste Task muss solange warten bis die CPU von der gerade laufenden Task wieder freigegeben wird. WeitereEigenschaften sind:

• Tasks können periodisch oder einmalig ausgeführt werden.

• Wenn eine Task bereit zur Ausführung ist wird sie auf eine Warteliste gesetzt.

• Wenn die CPU frei ist wird die nächste Task von der Warteliste ausgeführt.

• Wenn die Task zu Ende ausgeführt wurde wird die Kontrolle zurück an den Schedulergegeben.

In der Umsetzung eines kooperativen Schedulers ergeben sich folgende Punkte:

• Der Scheduler ist relativ einfach aufgebaut, so dass der Programm-Code überschau-bar klein bleibt.

• Der Scheduler braucht immer nur für eine Task zur Zeit Speicherplatz zu reservieren.

• Der Scheduler lässt sich problemlos in einer Hochsprache wie ’C’ programmieren.

• Der Scheduler stellt kein eigenständiges Programm dar, sondern ist teil des Entwick-lungs-Codes.

Beachten muss man bei einem kooperativen Scheduler, dass die Zeit bis zu einer Reaktionauf externe Ereignisse abhängig, von der Anzahl und Dauer der einzelnen Task ist und wieoft die für die Reaktion zuständige Task ausgeführt wird. Der kooperative Scheduler bieteteine einfach zu überschauende Scheduling-Technik, alle Aktionen die der Scheduler machtsind genau vorhersagbar. Zudem sind Zugriffe auf gemeinsam genutzte Ressourcen (z.B.gemeinsam genutzter Speicher) von verschiedenen Tasks sicher (thread-safe).

3. Realisierung 24

Preemtiver Scheduler

Ein preemtiver Scheduler stellt eine so genannte Multi-Tasking System Architektur dar. Beimpreemtive Scheduling ist die gerade laufende Task unterbrechbar. Anders als beim Koope-rativer Scheduler kann hier die gerade laufende Task durch eine andere bei der Ausführungunterbrochen werden. Weitere Eigenschaften sind:

• Tasks können periodisch oder einmalig ausgeführt werden.

• Wenn eine Task bereit zur Ausführung ist, wird sie auf eine Warteliste gesetzt.

• Eine Task aus der Warteliste wird für eine bestimmte Zeit ausgeführt und dann, wennsie noch nicht fertig ist, unterbrochen und wieder in die Warteliste getan.

In der Umsetzung eines preemtiven Schedulers ergeben sich folgende Punkte:

• Der Scheduler ist im Vergleich deutlich komplizierter, unter anderem müssen Funktio-nen wie Semaphoren implementiert werden, die ein sicheres Zugreifen auf gemeinsamgenutzte Resourcen erlaubt.

• Der Scheduler muss für alle unterbrochenden Tasks Speicherplatz reservieren undderen Zustände sichern.

• Der Scheduler lässt sich nicht problemlos in einer Hochsprache programmieren, son-dern muss zumindest teilweise in Assembler geschrieben werden.

• Der Scheduler wird generell als eigenständiges Programm geschrieben.

Gegenüber dem kooperativen Scheduler kann der preemtive Scheduler grundsätzlich eineschnelle Reaktion auf externe Ereignisse gewährleisten. Allgemein ist diese Art des Sche-dulings nicht so überschaubar und weniger vorhersagbar. Er ist auch nicht so sicher, wie derkooperative Scheduler beim Zugriff auf gemeinsam genutzte Ressourcen, hier muss immerder Programmierer darfür sorgen, dass es nicht zu Problemen kommt. Ansonsten kann eszu Datenverlust oder Inkonsistenz der Daten führen.

Hybrider Scheduler

Ein hybrider Scheduler ist ein kooperativer Scheduler, der in einem begrenzten Umfang auchpreemtives Scheduling erlaubt. Er besitzt zwei Hauptmerkmale:

• Der Scheduler arbeitet mit den gleichen Tasks zusammen wie beim kooperativenScheduler.

• Der Scheduler bietet die Möglichkeit, dass eine spezielle Task (preemtive Task) dieanderen kooperativen Tasks unterbrechen kann.

3. Realisierung 25

In der Umsetzung eines hybriden Schedulers ergeben sich folgende Punkte:

• Der Scheduler ist relativ einfach aufgebaut, so dass der Programm-Code überschau-bar klein bleibt.

• Der Scheduler braucht immer nur für zwei Tasks zur Zeit Speicherplatz zu reservieren.

• Der Scheduler lässt sich problemlos in einer Hochsprache wie ’C’ programmieren.

• Der Scheduler stellt kein eigenständiges Programm dar, sondern ist teil des Entwick-lungs-Codes.

Der Hybridscheduler hat so den Vorteil gegenüber dem kooperativen Scheduler, dass eineTask, die z.B. regelmäßig eine Hardwareschnittstelle bedienen muss, dies tun kann, unab-hängig davon, ob eine andere gerade laufende Task bereits ihre Ausführung fertig abge-schlossen hat. Es muss aber auch hier dann, wie bei einem preemtiven Scheduler daraufgeachtet werden, dass der Zugriff auf gemeinsam genutzte Ressourcen geregelt abläuft.Trotzdem bleibt es überschaubarer, da es nur eine preemtive Task gibt.

Funktion n Scheduler Typ kooperativer preemtiver hybriderperiodische und einmalige Ausführung ja ja ja

preemtive Tasks nein ja nur eineeinfach implementierbar ja nein ja

Ressourcensparend ja nein javorhersagbares Verhalten ja nein ja

(erfüllt harte Echtzeitanforderungen)grundsätzlich treahd-safe ja nein teilweise

Tabelle 3.1.: Scheduler Vergleich

Die Entscheidung für den Hybridscheduler

Wenn man sich nun die verschiedenen Möglichkeiten des Schedulings anschaut, zeigt sich,dass ein kooperativer oder hybrider Scheduler sich am besten für die gegebenen Anforder-ungen 3.1.1 eignet. Dies lässt sich durch folgende Punkte begründen:

• Die kooperativen Eigenschaften des Hybridschedulers erfüllen, durch das vorhersag-bare Scheduling, die harten Echtzeitanforderungen. Wichtig hierfür ist, dass das Pro-gramm keine weiteren Interrupts, bzw. interrupt Service Routinen, haben darf.

• Der Scheduler ist, wie gefordert, sparsam im Umgang mit den Ressourcen des Mikro-controllers.

3. Realisierung 26

• Mit der einen premmtiven Task können, unter bestimmten Vorraussetzungen, zeitlichkurze Aktionen in einem schnellen Intervall ausgeführt werden, wie es z.B. für dieNutzung der seriellen RS232-Schnittstelle erforderlich ist.

• Alle anderen Anforderungen lassen sich auch im Rahmen eines hybriden Schedulerserfüllen, wie der nächste Abschnitt zeigt.

3.1.2. Aufbau und Implementation des Schedulers

Der Scheduler wird für den Atmel AVR AT90CAN128 implementiert, er lässt sich aber auchauf anderen Mikrocontrollern einsetzen. Dafür müssen nur Anpassungen in den entspre-chenden Header-Dateien gemacht werden. Eine mit Doxygen erstellte Dokumentation zumScheduler befindet sich im Anhang dieser Arbeit. Der Quelltext des Schedulers besteht imwesentlichen aus drei Dateien, der scheduler.c und den beiden Header-Dateien scheduler.hund der Konfigurationsdatei config.h. In der config.h werden bestimmte Einstellungen für dasjeweilige Programm vorgenommen, wo der Scheduler dann eingesetzt wird.

Zu jeder Task muss man angeben, zu welchem Zeitpunkt die erste Ausführung stattfindensoll, wann und ob die Task wiederholt, also periodisch, ausgeführt werden soll, und wie vielZeit die Task für die Ausführung bekommt. Soll eine Task nur ein einziges mal ausgeführtwerden, wird für die Periode einfach eine Null angegeben. Welche die Zeitverzögerung fürdie Ausführung einer Task mit einem Abwärtszähler realisiert. Bei jedem Aufruf des Schedu-lers durch den Timer-Interrupt wird der Zähler decrementiert, bis der Zähler auf Null steht unddie Task ausgeführt wird. Nach der Ausführung wird der Zähler wieder mit dem Wert für dieLänge einer Periode neu geladen, wenn es sich um eine periodische Task handelt. Über eineKonfigurationsdatei können alle, für den Scheduler relevanten, Einstellungen vorgenommenwerden. Zum Beispiel lässt sich in der Konfigurationsdatei festlegen, ob der Mikrocontrollernach jeder Ausführung einer Task ,bis zum nächsten Timer-Interrupt, in den Sleepmoduswechseln soll. Damit der Scheduler nur so viel Speicher wie nötig für die Verwaltung derTasks reserviert, muss in der Konfigurationsdatei angegeben werden, wie viele Tasks maxi-mal gleichzeitig im Programm vom Scheduler verwaltet werden sollen.

Der Timer

Der Scheduler nutzt einen Hardware-Timer. Die dafür notwendigen Registereinstellungendes Mikrocontrollers werden in der Konfigurationsdatei vorgenommen. Die nötigen Einstel-lungen werden dem Scheduler über drei Makros bekannt gegeben, eins für das Vergleichsre-gister, eins für die Timerkonfiguration und eins für das Aktivieren des Interrupts. So kann derScheduler später Werte im Vergleichsregister anpassen und den Timer zu einem bestimmten

3. Realisierung 27

Zeitpunkt initialisieren. Außerdem gibt es noch ein Makro, mit dem die Dauer eines Timer-durchlaufs, also der Wert für das Vergleichsregister, festgelegt wird. Beim AT90CAN128 wirdder 8 Bit-Timer 0 verwendet und so konfiguriert, dass beim Erreichen eines eingestelltenVergleichswertes ein Interrupt generiert wird. Beim Erreichen des Vergleichswertes wird derTimer automatisch zurückgesetzt und beginnt wieder von vorne zu zählen. Dieser Betriebs-modus heißt Clear Timer on Compare Match Mode (CTC). Über die Makros lässt sich aucheine andere Hardware für den Scheduler konfigurieren. Ein kompletter Durchlauf des Timers,also die Zeit zwischen zwei Interrupts, nennt man Timertick. Man kann den Timertick beinahebeliebig lang oder kurz wählen. Es gilt jedoch zu beachten, dass, wenn man den Timertickbesonders kurz wählt, der Scheduler sehr oft aufgerufen wird und viel Rechenzeit für denScheduler benötigt wird. Längere Tasks werden dann während ihrer Ausführung sehr häu-fig vom Scheduler unterbrochen. Manchmal benötigt man aber einen kurzen Timertick fürdie schnelle periodische Ausführung der preemptiven Task. Wählt man dagegen einen sehrlangen Timertick, bedeutet das, dass kurze Tasks zwar schon fertig sind, aber noch Aus-führungszeit besitzen. Zu diesem Zeitpunkt wartet der Mikrocontroller nur darauf, dass derTimertick abläuft. Man sollte dahern individuell für jedes Programm, eine sinnvolle Größe fürden Timertick wählen.

Die RegTask

Die preemptive Task wird innerhalb der ISR, bei jedem zweiten Aufruf der ISR ausgeführt.Das bedeutet, dass die Task, jedesmal wenn ein Timertick abgelaufen ist, einmal ausgeführtwird. Durch das regelmäßige Ausführen der Task mit jedem Timertick, nenne ich die Taskfortan RegTask, wie Regelmäßige Task. Diese RegTask ermöglicht es, schnelle wiederkeh-rende Aufgaben zu erledigen. Wie oft die RegTask ausgeführt wird, hängt alleine von der Zeiteines Timerticks ab. Für die maximale Ausführungzeit der RegTask wird ein entsprechenderWert zur Entwicklungszeit in der Konfigurationsdatei festgelegt. Wird die ISR des Schedu-lers aufgerufen, wird zunächst der Timer des Schedulers auf den vorher festgelegeten Wert,für die maximale Ausführungszeit der RegTask eingestellt. Danach wird die RegTask ausge-führt. Ist der Timer dann abgelaufen und die ISR wird wieder aufgerufen, wird nun die Zeitfür den Timertick, minus dem Wert für die maximale Ausführungzeit der RegTask, in denTimer geladen. Nun kann wieder eine kooperative Task ausgeführt werden, dies kann aucheine zuvor durch die RegTask unterbrochene sein, die dann weiter ausgeführt wird. Siehehierzu auch das Sequenzdiagramm in Abbildung 3.1 auf Seite 30. Innerhalb eines eigent-lichen Timerticks wird die ISR also zweimal aufgerufen. Ein großer Vorteil gegenüber demhybriden Scheduler im Buch Patterns for Time-Triggered Embedded Systems von Michael J.Pont (2001) ist, dass durch die Zeitvorgabe für die RegTask, in Verbindung mit dem Timer,die RegTask immer die gleiche Zeit lang läuft. Ansonsten könnte man keine genaue Zeitaus-

3. Realisierung 28

sagen mehr über das Scheduling treffen, was für harte Echtzeitanforderungen inakzeptabelist.

Die Struktur

Zu jeder Task, die vom Scheduler gesteuert werden soll, müssen drei wichtige Informationengespeichert werden:

• Die Ausführungsdauer der Task (Duration) in Timerticks.

• Die Zeit bis zum ersten Start der Task (Delay) in Timerticks.

• Der zeitliche Abstand zwischen zwei Aufrufen der Task (Period) in Timerticks.

Dazu kommen noch für die Verwaltung des Schedulers wichtige Informationen, ein Funkti-onszeiger auf die Task und ein Flag mit dem der Scheduler dem Dispatcher anzeigt, dassdie Task ausgeführt werden soll (darauf wird später noch genauer eingegangen). Um die-se Informationen zu den einzelnen Task vernünftig zu speichern, wird eine entsprechendeStruktur angelegt. Jedes mal, wenn eine Task dem Scheduler übergeben wird, wird eine sol-che Struktur mit den entsprechenden Informationen gefüllt und in die Taskliste mit den zuschedulenden Tasks, einem Array, eingefügt.

Die Funktionen des Schedulers

Zunächst die öffentlichen Funktionen:

Die Funktion SchInit initialisiert den Scheduler, dass heißt alles wird zurückgesetzt. Es be-finden sich dann keine Tasks mehr in der Taskliste und auch alle Fehlercodes sind zurück-gesetzt. Mit der Funktion SchInit_T wird zusätzlich der Timer, entsprechend des Makros inder Konfigurationsdatei, initialisiert.

Um eine Task an den Scheduler zu übergeben, wird die Funktion SchAddTask benutzt. Dazuwird der Funktionszeiger der Task und die Zeiten Delay, Period und Duration als Parametermit übergeben. Die Task wird dann, in der oben genannten Struktur, in die Taskliste eingefügt.Als Rückgabewert erhält man die Positionnummer der Task in der Liste.

Mit der Positionsnummer und der Funktion SchDeleteTask kann man eine, vorher an denScheduler, übergebene Task wieder aus der Taskliste löschen. Die Task wird dann ab sofortnicht mehr ausgeführt.

Für die eine mögliche preemtive Task gibt es die Funktionen SchAddRegTask und SchDe-leteRegTask. Ab dem Zeitpunkt, wo die preemtive Task an den Scheduler übergeben wird,verändert sich das Scheduling- und Zeitverhalten des Schedulers wie in Abschnitt RegTask

3. Realisierung 29

3.1.2 beschrieben. Wird die preemtive Task entfernt, verhält sich der Scheduler ab sofortwieder normal.

Mit der Funktion SchReportStatus kann man sich den Fehlercode des zuletzt aufgetretenenFehlers zurückgeben lassen. Die Fehlercodes sind in der scheduler.h definiert und gebenüber den aktuellen Status des Schedulers Auskunft.

Die Funktion SchDispatchTask sorgt dafür, dass eine Task die zur Ausführung bereit ist aus-geführt wird. Dazu wird die Taskliste durchgegangen und auf das RunMe-Flag geachtet. Istdas RunMe-Flag gesetzt, wird die Duration in einer globalen Variablen (runRemain) gespei-chert und die Task ausgeführt. Nach der Ausführung wird anhand der Period überprüft, obdie Task nur einmal ausgeführt werden sollte, und dann gegebenen Falls aus der Tasklisteentfernt. Nun wird das RunMe-Flag zurückgesetzt und, wenn in der Konfigurationsdatei derSleepmode definiert ist, dieser aktiviert. Die Funktion SchDispatchTask wird in einer Whlie-True-Schleife im Hauptprogramm ständig ausgeführt.

Die Hauptfunktion des Schedulers ist SchSchedule, sie wird jedes mal, wenn der Timerinter-rupt kommt, in der Interrupt Service Routine (ISR) ausgeführt. In ihr wird zunächst überprüft,ob noch eine Task ausgeführt wird, und wenn ja, ob diese noch Ausführungszeit besitzt.Sollte eine Task noch ausgeführt werden, obwohl sie keine Ausführungszeit mehr besitzt,wird der entsprechende Fehlercode gesetzt. Im nächsten Schritt wird überprüft, ob nun einenormale Task oder die RegTask ausgeführt werden soll. Ist es Zeit für die RegTask, wirdder Vergleichswert für den Timer entsprechend gesetzt und die RegTask ausgeführt. Da-nach wird nur noch ein Flag gesetzt, das signalisiert, dass als nächstes wieder eine normaleTask dran ist. Ist es Zeit für eine normale Task, wird der Vergleichswert für den Timer mitder Zeit für eine normale Task geladen, sofern es überhaupt eine RegTask gibt. Ist in demaktuellen Programm gar keine RegTask vorhanden, ist der Vergleichswert ohnehin immerfür eine normale Task gesetzt. Nun wird die Taskliste durchsucht und bei jeder Task dasDelay decrementiert. Sollte bei einer Task das Delay bereits auf Null stehen, wird für dieseTask das RunMe-Flag gesetzt. Dabei wird wieder überprüft, ob noch eine andere Task Aus-führungszeit besitzt. Sollte das der Fall sein, wird der entsprechende Fehlercode gesetzt.Nach dieser Überprüfung wird der Period-Wert der nun auszuführenden Task in das Delaykopiert, wenn es sich nicht um eine einmalig auszuführende Task handelt. Dies geschieht,damit die nächste Ausführung der Task nach entsprechender Zeit wieder stattfinden kann.Zum Schluss wird noch die globale Variable runRemain decrementiert, sofern sie einen Wertgrößer Null besitzt.

Aufbau des Hauptpragramms für den Scheduler

In dem Programm wo der Scheduler eingesetzt werden soll, müssen einige GrundlegendeDinge beachtet und umgesetzt werden. Es darf und muss nur eine Interrupt Service Routine

3. Realisierung 30

Abbildung 3.1.: Sequenzdiagramm des Schedulers

geben. In dieser ISR wird die Funktion SchSchedule aufgerufen, sie wird ausgelöst, wennder Timer den Vergleichswert im Compare Register erreicht hat. Andere Interrupts sind nichtzulässig. Außerdem sollte kein weiterer Code in der ISR stehen.

In der main stehen am Anfang alle benötigten Initialisierungs Routinen/Funktionen, wo auchdie des Schedulers SchInit stehen muss. Darunter folgen die Taskübergaben an den Sche-duler mit der SchAddTask Funktion und maximal ein SchAddRegTask Aufruf. Tasks dürfenauch später noch innerhalb einer aktiven Task hinzugefügt werden, es muss dann aber be-achtet werden, dass die Ausführungszeitpunkte schwerer zu berechnen sind. Das Entfer-nen einer Task ist jederzeit mit SchDeleteTask oder bei der RegTask mit SchDeleteRegTaskmöglich. Im vorletzten Schritt wird das globale Interrupt-Enable-Flag mit dem Aufruf sei() ge-setzt. Dann folgt die Arbeitsschleife (While-True-Schleife), in der nur der Aufruf der FunktionSchDispatchTask steht.

Als Task kommt jede Funktion in Frage, die keinen Rückgabewert liefert. Außerdem solltendie Funktionen keine blockierenden Aufrufe machen, bzw. nicht blockierend auf Ressourcenzugreifen. Es kann sonst dazu führen, dass Funktionen nicht innerhalb der ihr zur Verfü-gung stehenden Ausführungszeit beendet werden, und somit das gesamte Zeitverhalten desSchedulers beeinträchtigen. Der Scheduler kann dann nicht mehr die harten Echtzeitanfor-derungen erfüllen.

Der Scheduler ist in den meisten Fällen Thread-Safe. Besondere Vorsicht gilt jedoch, wennman bei einer Task, die länger als ein Timertick dauert, auf die selben Ressourcen wie in derRegTask zugreift. Wird ausschließlich während des ersten Timerticks der Ausführungszeit

3. Realisierung 31

auf die gemeinsam genutzte Ressource zugegriffen, dann besteht auch hier keine Gefahrvon inkonsistenten Daten. Können die Zugriffe nicht so platziert werden, sollte geprüft wer-den, ob sich die Zugriffe auf die Ressourcen in einer extra Task auslagern lassen. Tasksdie nur einen Timertick andauern sind immer vollständig abgeschlossen in ihrer Ausführungwenn die RegTask aufgerufen wird. Daher besteht hier keine Gefahr beim Zugriff auf diegemeinsam genutzten Daten oder Ressourcen.

3.1.3. Eigenschaften des Schedulers in einer Zusammenfassung

• Tasks können zur Laufzeit der Scheduler-Liste hinzugefügt und entfernt werden.

• Für jede Task kann individuell die erste Ausführuns- Startzeit, der Ausführungs- Inter-vall und die Ausführungs- Dauer festgelegt werden.

• Fehlerüberwachung: Überwachung der Ausführungs- Dauer, der maximalen Anzahlan Tasks, Überlappen von Tasks und ob eine Task gelöscht werden konnte.

3.1.4. Fehlerbehandlung und Analyse

Mit den Fehlercodes, welche die Funktion SchReportStatus zurück gibt, lassen sich die meis-ten Fehler, die beim Scheduling auftreten können, feststellen. Die Fehlercodes sind und be-deuten:

• ERROR_SCH_TOO_MANY_TASKS : Es wurden mehr Tasks an den Scheduler über-geben als erlaubt.

• ERROR_SCH_CANNOT_DELETE_TASK : Eine Task konnte nicht gelöscht werden,da sie nicht in der Taskliste steht.

• ERROR_SCH_TASK_RUNNING : Eine Task wurde nicht beendet, bevor ihre Ausfüh-rungszeit abgelaufen war.

• ERROR_SCH_TASK_OVERLAPPING : Es wurde versucht eine Task auszuführen, ob-wohl noch eine andere Task Ausführungszeit besitzt.

3. Realisierung 32

Sinnvolle standard Tasks

Um eine schnelle grobe Fehlererkennung während der Laufzeit zu gewährleisten, hat es sich,zumindest für die Debugphase für sinnvoll erwiesen, einige besondere Tasks standardmäßigin die Programme aufzunehmen. Einige dieser Tasks können dann zur Veröffentlichung, nachder Qualitätssicherung, wieder entfernt werden.

• ErrorCode-Task: Eine Task die regelmäßig mir der Funktion SchReportStatus den Sta-tus des Schedulers abfragt. Die Task kann dann, z.B. auf einem Display oder mitLeuchtdioden den Fehlercode anzeigen.

• Heartbeat-Task: Eine Task, die, z.B. einmal pro Sekunde eine Leuchtdiode blinkenlässt, um zu signalisieren, dass das Programm (noch) arbeitet und, z.B. nicht in einerTask hängen geblieben ist.

• Watchdog-Task: Eine Task, die einen bei Programmstart initialisierten Watchdog re-gelmäßig zurücksetzt. Der Watchdog kann dann ein hängen gebliebenes Programmneu starten.

3.1.5. Perfomance und Speicherbedarf Verbesserung

Für bestimmte Anwendungen kann es sinnvoll sein, den Code besonders schnell in der Aus-führung oder besonders speicherschonend auszulegen. Auch bei dem Scheduler gibt es einpaar Möglichkeiten den Code dahingehend zu verändern. Dies sollte man besonders dannin Betracht ziehen, wenn man am oberen Leistungslimit der Hardware angelangt ist, undsich evtl. ein Umsteigen auf Leistungsfähigere und damit auch teurere Hardware vermeidenlässt. In diesem Abschnitt werden nun einige dieser Möglichkeiten diskutiert.

Compiler Optimierungstufen

Über bestimmte Compilerschalter lassen sich verschiedene Code-Optimierungen einstellen.In der Optimierungsstufe O0 wird keine Code-Optimierung vorgenommen. Diese Stufe istideal fürs Debugen, da der Code nicht verändert wird. Außerdem ist die Zeit für den Com-pilervorgang besonders kurz. In der Optimierungsstufe O1 wird der Code etwas auf Ge-schwindigkeit und Größe optimiert, das heißt auch, der Copiliervorgang dauert etwas länger.Bei der Optimierungsstufe O2 wird der Code noch stärker verändert, um ihn noch schnel-ler und kleiner zu bekommen. Dabei werden Verfahren, wie das Abrollen von Schleifen undFunction-Inlining, angewendet. Das heißt, dass Schleifen in hintereinander folgenden Codegewandelt werden, so als hätte man die immer wieder anfallenden Programmschritte nichtin einer Schleife sondern immer wieder hintereinander hingeschrieben. Genauso wird der

3. Realisierung 33

Codeblock aus einer Funktion beim Function-inlining immer wieder in das Hauptprogrammeingefügt und nicht als Funktion aufgerufen. Des Weiteren eignet sich der Code kaum nochzum Debugen, da er nicht mehr mit dem Quelltext nachvollzogen werden kann.

Zeitmessungen am Scheduler

Um einen Überblick zu bekommen, wie viel Zeit der Scheduler für das Scheduling bean-sprucht und wie sich verschiedene Compiler-Optimierungen bemerkbar machen, werdenZeitmessungen am Scheduler vorgenommen. Dafür wird ein beliebiges Programm mit einergewissen Anzahl von Tasks genommen, die vom Scheduler zu schedulen sind. Es wird dieZeit für nur einen Scheduler Aufruf in der ISR gemessen, die Zeit für den Dispatcher ist hiernoch nicht berücksichtigt.Die Messung wird mit Hilfe eines Oszilloskops vorgenommen. Dazu wird ein Port des Mikro-controllers vor dem Scheduleraufruf auf High und nach dem Aufruf wieder auf Low gesetzt.Die Zeit zwischen dem High- und Low-Signalen kann dann mit dem Oszilloskop gemessenwerden. Die zeitliche Verzögerung, die ein Port bei einem Signalwechsel mit sich bringt, wirktsich nicht auf die Messung aus, da sie sowohl am Anfang wie auch am Ende der Messungauftritt.Die erste Messreihe wird mit 15 Tasks in drei verschiedenen Optimierungsstufen des Com-pilers durchgeführt.

Zeitmessungen Programm (1) mit 15 Tasks und ohne RegTask:

0 10 20 30 40 50 60 70 80 90 100

96

35

30

Maximale Dauer in Mikrosekunden

O0

O1

O2

Abbildung 3.2.: Diagramm Scheduler Compileroptimierung Zeitmessungen

Aus den Messungen geht hervor, dass eine Optimierung des Codes einen deutlichen Per-formancegewinn mit sich bringt. Wobei alleine schon die erste Optimierungstufe einen Zeit-lichen Gewinn von über 60 Prozent bringt.

3. Realisierung 34

Eine zweite Messreihe soll nun zeigen, was kleine Veränderungen am Programmcode be-wirken. Das jetzt verwendetete Programm besitzt 14 Tasks, keine RegTask und wird jedesmal in der Optimierungsstufe 2 des Compilers compiliert. Die erste Messung wird am unver-änderten Programm vorgenommen. Bei der zweiten Messung wird dann die Funktionalitätder RegTask entfernt. Bei der dritten Messung werden zusätzlich zwei Variablen (Delay &Duration) im Schedulercode von 16 Bit auf 8 Bit verkleinert. In der letzten Messung wird dieFunktionalität der RegTask wieder eingebaut, die Variablen bleiben auf 8 Bit Größe.

0,0 5,0 10,0 15,0 20,0 25,0 30,0

28,0

27,3

21,4

22,1

Keine Veränderung

Keine RegTask Funktionalität, 8 Bit Variablen

Mit RegTask Funktionalität, 8 Bit Variablen

Keine RegTask Funktionalität

Maximale Dauer in Mikrosekunden

Abbildung 3.3.: Diagramm Scheduler Codeveränderungen Zeitmessungen

Ein so deutlicher Performancegewinn wie bei den Messungen mit den verschiedenen Op-timierungsstufen des Compilers ist nun nicht erkennbar. Es fällt besonders auf, dass dasWeglassen der RegTask Funktionalität sich mit nur 0,7 Mikrosekunden sehr gering bemerk-bar macht. Dafür ist der Performancegewinn beim Verkleinern der Variablen auf 8 Bit, mit 5,9bzw. 21 Prozent recht groß.

Für den gesamten Zeitbedarf des Schedulers ist die Zeit, die der Dispatcher benötigt, auchnoch zu berücksichtigen. Dazu wird die Zeit des Dispatchers bei dem gleichem Programmmit den 14 Tasks gemessen. Ein Durchlauf des Dispatchers dauert 27,8us. Der gesamteZeitbedarf GZ des Schedulers berechnet sich aus der Anzahl der Zeiteinheiten ZE die eineTask für ihre Ausführung benötigt, der Scheduler-Dauer SD und der Dispatcher-Dauer DDwie folgt:

GZ = ZE � SD +DD

BeispielEine normale Task bekommt 10 Zeiteinheiten:

10 � 22; 1�s + 27; 8�s = 248; 8�s

3. Realisierung 35

Der Scheduler benötigt für das Scheduling dieser Task eine Gesamtzeit von 248,8us. DieseZeit steht der Task während ihrer Ausführung also nicht zur Verfügung.

Fazit der Zeitmessungen

Bei einem Programm, wo der Mikrocontroller ein wenig zu langsam für dessen Bearbeitungist, kann eine Verkleinerung der Variablengröße entscheidene Performancegewinne bewir-ken, das Entfernen der RegTask wird dagegegen wohl meistens nicht ausreichen um einUmschwenken auf einen schnelleren Mikrocontroller zu verhindern.

Verringerung des Speicherbedarfs

Um den Speicherbedarf des Schedulers zu verringern, bietet es sich, genauso wie bei derPerfomancesteigerung an, die zwei Variablen Delay und Duration des Schedulers auf 8 Bitstatt 16 Bit zu setzen. Dies lässt sich einfach, für den Entwickler, der den Scheduler nutzenmöchte, über ein Define (#define SCHEDULER_LIGHT) umsetzen. Da diese beiden Varia-blen so oft vorkommen, wie der Wert für die maximale Anzahl an Tasks gesetzt ist, ergibtsich ein Speicherplatzgewinn SG aus der maximal möglichen Anzahl Tasks MT wie folgt:

SG = MT � 2Byte

Zum Beispiel lassen sich so bei 15 Tasks schon 30 Byte Arbeitsspeicher einsparen.

3.2. Das TTC-System

Das Time-Triggered-CAN-System bietet, passend zu dem in dieser Arbeit vorgestelltenScheduler, Funktionen, mit denen eine Zeit gesteuerte Kommunikation über den CAN-Buszwischen verschiedenen Teilnehmern möglich ist.

3.2.1. Aufgaben und Arbeitsweise des Time-Triggered-Systems

Die Aufgabe des TTC-Systems wird es sein, dafür zu sorgen, dass der Scheduler des lo-kalen Systems synchron zum Time-Master arbeitet. Wenn der Scheduler synchron arbeitet,können dann mit dessen Hilfe Nachrichten zu einem fest definierten Zeitpunkt über denCAN-Bus versendet werden, man hat dann einen Time-Triggered-CAN-Bus.

Für die Synchronisation und die Zeitpunkte für den Nachrichtenversand wird der CAN-Busin Zeitintervalle eingeteilt. Die Abbildung 3.4 zeigt die gewählte Einteilung des CAN-Busses

3. Realisierung 36

in Zeitintervalle mit Zeitfenstern für den Nachrichtenversand. Den Hauptintervall nennt manMatrixzyklus, dieser ist unterteilt in so genannte Basiszyklen. In diesem Fall gibt es vierBasiszyklen. Jeder Basiszyklus beginnt mit einer TM-Nachricht, welche die Nummer desBasiszyklus enthält. Die Basiszyklen sind wiederum in Zeitfenster für den Nachrichtenver-sand unterteilt. Der Abstand der Nachrichtenfenster ergibt sich dabei aus der maximalenÜbertragungszeit einer CAN-Nachricht und einem für den Scheduler günstigen Wert. DasTTC-System sorgt nun dafür, dass der Scheduler nach dem Erhalt einer TM-Nachricht desBasiszyklus 0 gestartet wird und so synchron zum Time-Master arbeitet.

Basiszyklus 0 (10ms)Zyklus-Zeit 0,4ms 9,6ms

198 0 2 4 6 ... 40 42 44 46Zeitfenster 400µs 400µs 400µs 400µs 400µs ... 400µs 400µs 400µs 400µs







TTCAN Matrixzyklus

Synchro-nisations-punkt

Scheduler-Zeit


Scheduler-Zeit


Scheduler-Zeit


Scheduler-Zeit

Abbildung 3.4.: Ein Matrixzyklus mit den vier Basiszyklen

Damit der Scheduler auch weiterhin synchron arbeitet, wird die Zeit zwischen zwei Basis-zyklen aus den Empfangszeiten der aktuellen und der zuletzt empfangenden TM-Nachrichtberechnet. Diese Zeit wird dann mit einem Sollwert verglichen, welcher der Zeit zwischenzwei TM-Nachrichten entspricht. Weichen die beiden Zeiten voneinander ab, muss der Ti-mer für den Scheduler entsprechend angepasst werden.

Der Vergleich der Zeiten funktioniert wie folgt:

3. Realisierung 37

Auf dem Time-Master und dem Slave vergeht die gleiche Zeit. Beide Timer müssten al-so nach der gleichen Zeit die gleichen Werte anzeigen. Der Time-Master verschickt seineNachricht immer wieder genau nach der gleichen Zeit. Diese Zeit ist bekannt und wird alsSollwert im Slave fest abgelegt. Wenn der Slave nun mit dem internen Timer die Zeit zwi-schen zwei TM-Nachrichten misst, und diese Zeit dann vom Sollwert abweicht, bedeutet das,dass der interne Timer nicht genauso schnell arbeitet wie der Timer des Time-Masters. DieDifferenz zwischen der gemessenen Zeit und dem Sollwert entspricht genau der Zeit um diedie interne Uhr des Slaves gegenüber dem Timer des Time-Masters abweicht. Damit beidewieder exakt synchron arbeiten, muss die interne Uhr um die Differenz vor, bzw. nach gestelltwerden.

Die folgende Abbildung 3.5 zeigt exemplarisch, wie zwei TM-Nachrichten zu bestimmtenZeitpunkten vom Time-Master versandt und von einem Slave empfangen werden. Der Ab-stand der beiden TM-Nachrichten entspricht dabei genau der Sollzeit, wenn von der Time-Master Uhr ausgegangen wird. Nach der Uhr des Slaves ist der zeitliche Abstand der beidenNachrichten etwas länger (3 Ticks), als von der Sollzeit angegeben. Da die Nachrichtenbei der Übertragung nicht verzögert1 werden, bedeutet das, dass die Uhr des Slaves etwasschneller läuft als die Uhr des Time-Masters. Die Uhr des Slaves muss entsprechend (um 3Ticks) korrigiert werden.

3.2.2. TTC-Erweiterung für den Scheduler

Zusätzliche Funktionen für den Scheduler

Um einen Zeit synchronen Ablauf mehrerer Kommunikationsteilnehmer gewährleisten zukönnen, muss der Scheduler ein wenig angepasst werden. Er bekommt hierfür zwei neueFunktionen. Bis auf diese beiden neuen Funktionen arbeitet er weiterhin wie im vorigen Ab-schnitt 3.1.2 beschrieben.

Der Timer für den Scheduler wird nun nicht mehr direkt bei der Initialisierung des Schedulersgestartet, sondern erst mit dem Aufruf der Funktion SchStart. Die Funktion ruft zunächst dasMakro TIMER_START, das jetzt in der Konfigurationsdatei vorhanden sein muss, auf. Damitwird der Timer gestartet, in dem der Prescaler des Timers von No-Clock auf den definiertenClock-Teiler Wert gesetzt wird. Als nächstes wird dann noch der Interrupt für den Timeraktiviert. Der Scheduler beginnt somit zu arbeiten.

Mit der Funktion SchSync lässt sich das Zeitverhalten des Schedulers verändern. DieseFunktion wird ausschließlich direkt vom TTC-System aufgerufen. Es wird der Funktion ein

1Die Verzögerung ist bei allen Nachrichten gleich groß, so dass sich der Abstand zwischen den Nachrichtennicht verändert.

3. Realisierung 38

Time-Master

versendet:

TM-MSG 1 um 2500 Uhr


Slave

empfängt:



Differenz = 2500entspricht der Sollzeit

Differenz = 2503weicht um 3 Ticks

von der Sollzeit ab

Abbildung 3.5.: Ermittlung der Zeitdifferenz zwischen Time-Master und Slave

Wert übergeben, mit dem der gerade laufende Timertick verkürzt oder verlängert wird. DerWert hat die Größe, um die der Wert im Vergleichsregister des Timers verändert wird. Dabeidarf der Wert eine vorher festgelegte Größe, sowohl im Negativen, als auch im Positiven,nicht überschreiten. Diese maximale Zeitdifferenz wird in der Headerdatei des Schedulersfestgelegt. Die Funktion überprüft auch, ob sich der daraus berechnete neue Vergleichswertfür den Timer, in einem für das 8 Bit Register gültigen Bereich befindet. Sollte sich der Wertaußerhalb des gültigen Bereichs befinden, wird der maximal bzw. minimal mögliche Wertgenommen.

Die Funktionen des TTC-Systems

Die Funktion ErrorCodeLEDS dient der Fehleranalyse. Sie zeigt die Fehlercodes des Sche-dulers auf den Status-Leuchtdioden an und lässt die Heartbeat-LED Blinken (Ausgabe-Portssind in der Konfigurationsdatei festzulegen). Die Funktion ist im Hauptprogramm als Task zuimplementieren.

Die Funktion TtcGetTmMsg dient lediglich dazu, einen Zeiger auf die TM-Nachricht zurückzu geben, damit auf den Inhalt der Nachricht zugegriffen werden kann.

3. Realisierung 39

Die Funktion TtcSynchronize ruft die Scheduler-Funktion SchSync auf und übergibt ihr alsParameter die berechnete Differenz zwischen der eigenen und der Time-Master-Clock. DieFunktion muss im Hauptprogramm als Task implementiert werden und genau einmal in je-dem Basiszyklus, mit einer Duration von eins, ausgeführt werden. Es wird dann, einmal nachjedem Empfang einer TM-Nachricht, die eigene Scheduler-Clock der Time-Master-Clock an-gepasst (synchronisiert). Der genaue Zeitpunkt der Ausführung spielt keine Rolle. Eine län-gere Duration als eins macht keinen Sinn, da nur einmal innerhalb eines Timerticks die Clockangepasst wird.

Mit TtcInit wird das TTC-System initialisiert. Der CAN-Controller wird für das Empfangen vonTM-Nachrichten bereit gemacht. Dazu wird ein MOB entsprechend initialisiert und der CAN-Controller auf den TTC-Modus gestellt. Mit der Funktion TtcTmRx werden die empfangenenTM-Nachrichten aus dem CAN-Controller abgeholt. Wurde eine Nachricht empfangen, wirdzunächst der Timestamp der Nachricht gesichert. Dann wird die Differenz zwischen der TM-Clock und der eigenen Clock aus dem aktuellen, dem letzten TM-Nachrichten-Timestampund dem TM-Cycle berechnet. Der TM-Cycle ist ein in der Konfigurationsdatei festgelegterWert, der die Dauer eines Basiszyklus, also die Zeit zwischen zwei TM-Nachrichten be-schreibt. Die verwendete Zeiteinheit entspricht der des Timers im CAN-Controller. Nun wirdder Watchdog zurückgesetzt, außer es wurde keine TM-Nachricht empfangen oder die Dif-ferenz zwischen eigener und der TM-Clock ist zu groß, dann wird der Watchdog nicht zu-rückgesetzt. Auch diese Funktion muss im Hauptprogramm als Task implementiert werden.Die Task muss in jedem Basiszyklus vor der synchronisations Task TtcSynchronize ausge-führt werden, damit immer die aktuelle Differenz für die Anpassung der Scheduler-Clock zurVerfügung steht.

Damit der Scheduler bereits zum Start synchron zum Time-Master läuft, gibt es die Funk-tion TtcFirstSync. Diese Funktion wird im Hauptprogramm aufgerufen, wenn der Schedulergestartet werden soll. Der Scheduler wird erst dann gestartet, wenn die erste TM-Nachrichtdes ersten Basiszyklus (Basiszyklus 0) empfangen wurde. Außerdem überprüft die Funktionob der Mikrocontroller zuvor durch den Watchdog resetet wurde, und gibt dies ggf., mit derentsprechenden Status-LED, bekannt.

3.2.3. Versenden einer CAN-Nachricht (Slave)

Die CAN-Nachrichten werden in einer Task vorbereitet und in einer weiteren Task versen-det. Es ist wichtig, dass der Versand einer Nachricht in einer gesonderten Task statt findet,sonst kann nicht gewährleistet werden, dass die Nachricht innerhalb ihres vorgegebenenZeitfenster auf dem CAN-Bus ist.

3. Realisierung 40

Die Beiden Task folgen in ihrer Ausführung direkt hintereinander. Der Zeitpunkt für die Aus-führung der Sende-Task richtet sich nach dem in der Tabelle des Matrixzyklus festgelegtenZeitpunkt.

3.2.4. Fehlerbehandlung

Bleibt eine TM aus, so wird das vom TTC-System erkannt und es kann dann eine entspre-chende Notfall-Funktion ausführen. Im einfachsten Fall ist dies ein Reset des Moduls, es sindaber auch andere Funktionen möglich. Denkbar ist auch eine Variante, bei der das Modulnoch eine gewisse Zeit weiterarbeitet und seine Nachrichten weiterhin versendet, bis z.B.ein neuer TimeMaster die Kontrolle übernimmt. Dabei sollte die Anzahl der Zyklen so geringwie möglich gehalten werden.

3.3. Der Time-Master

3.3.1. Aufgaben des Time-Masters

Der Time-Master dient der Synchronisation aller Module im System. Dazu muss er in einemfesten Zeitintervall so genannte Time-Master-Nachrichten auf den CAN-Bus senden. Überdie TM-Nachrichten werden zusätzlich die Uhrzeit, sowie das aktuelle Datum der im Time-Master integrierten Real Time Clock verbreitet. Dies dient nicht der Synchronisation, es ist le-diglich für Applikationen gedacht, die das aktuelle Datum und die aktuelle Uhrzeit benötigen.Diese Informationen werden von einigen Modulen benötigt, um zum Beispiel beim Datenauf-zeichnen fest zu halten, zu welcher Zeit diese Daten angefallen sind. Da der Time-Mastereine zentrale Rolle spielt, bietet es sich an, ihn auch für eine zentrale Fehlerüberwachungdes gesamten Systems einzusetzen. Zudem kann er den aktuellen Systemzustand allenModulen mitteilen. Der Time-Master zeigt den aktuellen Systemzustand und gegebenenfallsFehlermeldungen auf einem 2x16 Zeichen LC-Display an. Außerdem wird im Wechsel Uhr-zeit und Datum der internen Real Time Clock, sowie die Batteriespannung der RTC-Backup-Batterie angezeigt.

3.3.2. Funktionsweise

Der Time-Master versendet alle 10 Millisekunden eine TM-Nachricht. Die TM-Nachricht ent-hält folgende Daten:

• die Basiszyklusnummer

3. Realisierung 41

• den aktuellen Systemzustand

• abwechselnd die aktuelle Uhrzeit und das aktuelle Datum (In Basiszyklus 0 und 2 dieUhrzeit sonst das Datum)

Auf dem Time-Master wird der Scheduler ohne das TTC-System benutzt, da er seinen Timernicht an andere anpassen muss. Alle Module müssen sich nach seiner Zeit richten und sichentsprechen synchronisieren.

Abbildung 3.6.: TM-Nachricht auf dem CAN-Bus

In Abbildung 3.6 sind die vier TM-Nachrichten eines Matrixzyklus zu sehen. Die blauen Im-pulse werden zur triggerung auf die TM-Nachricht des ersten Basiszyklus vom Time-Masteran einem I/O-Ausgang erzeugt (nur während der Messungen implementiert).

3.3.3. Ausfall des Time-Masters

In diesen Abschnitt wird eine Möglichkeit genannt, mit der es möglich ist, dass bei einemAusfall des Time-Masters, das System weiterarbeiten kann.

Es gibt einen Haupt-Time-Master (Haupt-TM) und es gibt Ersatz-Time-Master (Ersatz-TM).Fällt der Haupt-TM aus, so übernimmt der nächste Ersatz-TM das Bus-Timing. Beim Startdes Systems befindet sich zunächst nur der Haupt-TM im Sende-Modus. Die Ersatz-TMswarten eine bestimmte Zeit ab. Sollte nach Ablauf dieser Zeit keine TM-Nachricht empfangenworden sein, beginnt der nächste Ersatz-TM zu senden. Die Zeit die ein Ersatz-TM abwartet,hängt dabei von einer vorher festgelegten Rangfolge ab, genauso wird auch die Priorität der

3. Realisierung 42

TM-Nachricht entsprechend der Rangfolge festgelegt. Der Haupt-TM steht dabei immer anhöchster Stelle. Sollte ein zunächst ausgefallener TM wieder anfangen zu senden, so setztsich dieser, dank der höheren Priorität gegenüber dem Ersatz-TM, durch. Der Ersatz-TMmerkt dann sofort, dass ein TM mit höherem Rang sendet und stellt selber das Sendender TM-Nachricht ein. Alle Ersatz-TMs müssen erkennen wann eine TM-Nachricht ausbleibt.Ist dies der Fall müssen sie ab dem nächsten Basiszyklus das Senden der TM-Nachrichtübernehmen. Dabei kommt es zwangsläufig zu einer Kollision, denn schließlich senden nunalle Ersatz-TMs gleichzeitig. Aber auch hier wird dann sich wieder der Ersatz-TM mit derhöchsten Priorität durchsetzen und die Anderen ziehen sich sofort zurück.

Ein Ersatz-TM muss nicht unbedingt ein, nur für diese Funktion, aufgebautes Modul sein,es kann auch ein Modul sein, das eigentlich eine ganz andere Aufgabe hat. Es muss nurnoch entsprechende Kapazität frei haben, um die Aufgabe eines Ersatz-TM übernehmenzu können. Da der Ersatz-TM nur im Notfall dafür sorgt, dass das System noch bei einerStörung des Haupt-TM weiterarbeitet, ist es nicht zwingend erforderlich, dass er auch alleAufgaben eines Haupt-TM übernimmt. Es reicht, wenn er nur eine Mindestanforderung derFehlerbehandlung im System übernimmt. Genauso muss er nicht unbedingt eine Real-Time-Clock besitzen, da die nicht für einen Betrieb des Systems zwingend erforderlich ist.

Bei diesem Lösungsansatz handelt es sich lediglich um eine Idee, die bislang noch nicht um-gesetzt wurde. Einige Details müssen bei diesem Lösungsansatz noch genauer untersuchtund ausgearbeitet werden. Zum Beispiel ist die Behandlung von Kollisionen nicht besonderstrivial in der Umsetzung.

3.3.4. Die Realtimeclock

Bei der verwendeten Real Time Clock (RTC) handelt es sich um einen externen Baustein derFirma Epson, den RTC-72421. Sie ist über einen 4 Bit Adress- und Datenbus, sowie übervier Steuerleitungen mit dem Mikrocontroller verbunden. Diese RTC im externen Bausteinhat gegenüber eines internen Timers des Mikrocontrollers den Vorteil, dass sie mit einerkleineren Betriebsspannung und einem sehr geringen Stromverbrauch im Standby-Modeauskommt. So reicht eine Knopfzelle für viele Jahre Betrieb im Standby-Mode.

Die RTC besitzt einen internen Oszillator und kann im 24 Stunden Modus betrieben werden.Die Uhrzeit kann Sekundengenau und das Datum mit zweistelliger Jahreszahl und Wochen-tag abgefragt und gesetzt werden.

Mit einer einfachen elektronischen Schaltung wird die Versorgungsspannung der RTC, beimAbschalten des Moduls, auf die Versorgung durch die Knopfzelle umgeschaltet und gleich-zeitig der Standby-Mode aktiviert. Im Standby-Mode arbeitet die Uhr intern weiter, es kannaber nicht auf die Register, zum setzen oder Abfragen der Uhrzeit, zugegriffen werden.

3. Realisierung 43

Bei der Uhrzeit- und Datumsanzeige im Display, erfolgt die Abfrage der RTC im Sekunden-takt. Außerdem wird beim Versand einer TM-Nachricht die Uhrzeit bzw. das Datum abgefragt.Über zwei Steuerbefehle kann die Uhrzeit und das Datum jederzeit gesetzt werden.

Der Time-Master arbeitet auch ohne RTC, das bedeutet auch, dass ein Ausfall der RTC keineAuswirkung auf das rechtzeitige Versenden einer TM-Nachricht hat.

3.3.5. Systemüberwachung

Damit Störungen oder Defekte frühzeitig erkannt und entsprechend behoben werden kön-nen, bietet es sich an, an einem zentralen Punkt im System eine Sytemüberwachung einzu-setzen. Der Time-Master stellt einen solchen zentralen Punkt im System dar, ohne ihn ist dasSystem nicht funktionstüchtig. Außerdem ist der Mikrocontroller mit der Aufgabe des Time-Master alleine noch nicht sehr ausgelastet. Es bietet sich daher an, das Time-Master-Modulauch zur Systemüberwachung (als System-Checker)einzusetzen.

Die Systemüberwachung könnte sich folgendermaßen gestalten:

Alle Module müssen regelmäßig eine Status-Nachricht an den System-Checker senden, derZeitpunkt wird an geeigneter Stelle im Matrixzyklus festgelegt. Die jeweils erste Nachrichteines Moduls dient als Anmeldung an dem System-Checker, dieser weiß fortan welche Mo-dule sich regelmäßig mit ihrem Status bei ihm melden müssen. Der System-Checker achtetnun darauf, dass sich alle Module regelmäßig bei ihm melden. Bleibt eine Meldung aus oderder Status des Moduls zeigt einen Fehler an, kann der System-Checker an entsprechenderStelle den Fehler melden oder evtl. geeignete Notfallmaßnahmen veranlassen.

Derzeit übermitteln die Module nur ihren Scheduler-Status (siehe hier zu auch 3.1.3) an denSystem-Checker, weitere Statusmeldungen sind aber denkbar. Es könnten z.B. Sensoraus-fälle mit über die Status-Nachricht gemeldet werden.

3.3.6. Moduleinstellungen und Statusanzeige

Es gibt drei Steuerbefehle mit denen folgende Einstellungen am Modul vorgenommen wer-den können:

• Setzen der Uhrzeit.

• Setzen des Datums mit Wochentag.

3. Realisierung 44

Die Einstellungen können über die Oberfläche der Leistandsoftware, die in Abbildung 5.2auf Seite 66 zu sehen ist, vorgenommen werden. Dabei wird die Systemzeit des Computersverwendet.

Die beiden Leuchtdioden an der Oberseite des Moduls dienen als Statusanzeige und habenfolgende Bedeutungen:

• Grün: Heartbeat-LED. Blinken = System arbeitet, Aus = keine Versorgungsspannungoder defekt.

• Rot: Fehler-LED. Dauerleuchten = Fehler aufgetreten, für details Fehlerbeschreibungim Display beachten. Aus = Kein Fehler.

Eine Übersicht mit den Nachrichten- und Datenformaten befindet sich im Anhang A auf Seite69.

3.4. Eigenschaften der Module

Alle Module die in das System integriert werden (außer Time-Master und Datenlogger) ha-ben unter anderem die folgenden Eigenschaften2:

• Es wird der synchronisierbare Scheduler mit dem TTC-System verwendet.

• Der CAN-Controller wird ausschließlich über die CAN-Library von Herrn S. Haase an-gesprochen und das entsprechende Nachrichten-Protokoll von Herrn S. Haase be-nutzt.

• Ein 8 Bit Port wird für die Status-LEDs konfiguriert.

• folgeden Tasks sind vorhanden:

– TtcTmRx mit Duration = 1Auswertung der TM-Nachricht (siehe auch 3.2.2)

– TtcSynchronize mit Duration = 1Synchronisation, Timeranpassung (siehe auch 3.2.2)

– CanReceive mit Duration = 1Auswertung der empfangenen CAN-Nachrichten z.B. Steuerbefehle

– PrepareCanMsg mit Duration = beliebigVorbereitung der CAN-Nachrichten

2Softwareeigenschaften

3. Realisierung 45

– CanSend mit Duration = 1Senden einer CAN-Nachricht

– StatusSend mit Duration = 1Der eigene Status wird an den System-Checker gesendet

– evtl. RegTask

Der versandt der CAN-Nachrichten gestaltet sich wie in 3.2.2 auf Seite 39 beschrieben.

3.5. Lenkwinkel

Das Modul dient der Ermittlung des Lenkwinkels mit Hilfe eines Sensors der am Lenkgetriebedirekt mit der Lenksäule verbunden ist. Der Lenkwinkel soll 25 mal pro Sekunde bestimmtund über den CAN-Bus versendet werden.

Der Lenkwinkel wird mit einem kontaktlosen Drehwinkelgeber über einen Bereich von 360Grad ohne mechanischen Anschlag erfasst. Der Sensor verfügt über zwei analoge Aus-gangssignale, die den Sinus und den Cosinus des Winkels repräsentieren (siehe Abbildung3.7). Für die Ausgangssignale gilt:

• Signal 1, von 0,5 V bis 4,5 V Sinus

• Signal 2, von 0,5 V bis 4,5 V Cosinus

Der Winkel für die Mittelstellung wird als Teach-Wert in dem EEPROM des Mikrocontrollersabgelegt. Die Mittelstellung kann jederzeit mittels Taster an der Modulvorderseite gesetztwerden. Nach dem Setzen der Mittelstellung führt das Modul selbstständig ein Reset aus,da das Schreiben in das EEPROM sehr lange dauert und so die Zeiten für das Schedulingnicht eingehalten werden. Nach dem Reset ist das Modul wieder betriebsbereit.

3.5.1. Auswertung Sensor

Die beiden Ausgänge des Drehwinkelgebers werden an zwei Eingängen des Analog-Digital-Wandlers des Mikrocontrollers angeschlossen. Als Vergleichsspannung für den AD-Wandlers wird die Versorgungsspannung des Mikrocontrollers (5 Volt) gewählt. Die Eingän-ge werden als acht unipolare Kanäle betrieben, wovon aber nur zwei benutzt werden. Diebeiden Kanäle können dann zur AD-Wandlung über den internen Analogmultiplexer ausge-wählt werden. Der AD-Wandler arbeitet mit einer Auflösung von 10 Bit und wird im Single-Conversion-Mode, mit einer Taktrate3 von 125 kHz betrieben. Im Single-Conversion-Mode

3I/O-Clock / Prescaler = 16 MHz / 128 = 125 kHz

3. Realisierung 46

0 90 180 270 3600,00

0,50

1,00

1,50

2,00

2,50

3,00

3,50

4,00

4,50

5,00

Spalte ESpalte H

Winkel in Grad

Span

nung

in V

olt

Signal 1Signal 2

Abbildung 3.7.: Signalform Drehwinkelsensor

muss im Gegensatz zum Free-Running-Mode jede Wandlung vom Programm neu angesto-ßen werden.

Oversampling

In praktischen Versuchen hat sich gezeigt, dass die Signale kleinen schnellen Schwankun-gen unterliegen. Um den Messwert etwas zu stabilisieren, werden die Spannungen der Si-gnale nun öfter gemessen als benötigt (Oversampling). Statt die Messung 25 mal pro Se-kunde durchzuführen wie gefordert, wird sie 100 mal pro Sekunde durchgeführt. Aus vierMessungen wird der Durchschnittswert berechnet und dieser dann für die Berechnung desWinkels verwendet.

Die Spannungsmessungen mit dem DA-Wandler werden in einer eigenen Task durchgeführt.Die Task wird viermal aufgerufen bevor im direkten Anschluss eine Task aufgerufen wird inder alle Berechnungen durchgeführt werden. Für das Vorbereiten und Absenden der CAN-Nachricht gibt es wie üblich zwei eigene Tasks, die nach den Berechnungen ausgeführtwerden. Danach wiederholt sich der Ablauf.

Berechnungen

Die Winkelbestimmung erfolgt auf Basis der atan2-Funktion. Dabei handelt es sich um einemodifizierte Arcus-Tangens-Funktion, welche den korrekten Quadranten des berechnetenWinkels bestimmt.

3. Realisierung 47

Der Sinus wird mit x und der Cosinus mit y bezeichnet.

Bei der Spannungsmessung mit dem AD-Wandler, wird das Messergebnis in Form eines 10Bit Wertes dargestellt. Der Wert Null steht für eine Spannung von 0 V und der Wert 1023 füreine Spannung von 5 V. Da sich der eigentliche Nullpunkt der beiden Signale nicht bei 0 Voltsondern bei 2,5 V befindet, muss dieser, für die weiteren Rechenschritte, zunächst korrigiertwerden. Eine Spannung von 2,5 Volt wird durch den Messwert 512 repräsentiert. Da es aberbei negativen x-Werten zu Ungenauigkeiten4 bei der Winkelberechnung kommt, gilt für diex-Werte folgendes:

Gegeben: Messwert xm Gesucht: korrigierter Messwert xm

xk = xm � 512 für xm > 512

xk = 512� xm für xm < 512

Die Berechnung des Winkels (in Radiant) sieht mit der atan2-Funktion dann so aus:

wr = atan2(xk ; y512))

Die Umrechnung von Radiant in Grad:

wg = wr �180�

�

Zum Schluss wird der durch die obige Veränderung der Berechnung bei negativen x-Werten,zu kleine Winkel wieder korrigiert:

wgk = wk für xm > 512

wgk = 360� � wk für xm < 512

Diese Berechnung des Winkels wird als Funktion in eine extra Libary ausgelagert, so kannsie auch für andere Anwendungen in Zukunft verwendet werden.

Im Programm des Moduls muss jetzt noch der Winkel in einen Bereich von -180 Grad bis+180 Grad umgerechnet werden. Außerdem wird noch die Mittelstellung berücksichtigt, da-zu wird der im EEPROM gespeicherte Winkel als Nullpunkt in der Umrechnung berücksich-tigt.

Winkel um Nullpunkt für Mittelstellung des Lenkrades korrigieren:

wgkn = wk � wnp für wgk > wnp

wgkn = wk + (360� � wnp) für wgk < wnp

Winkelbereich zu �180�::+ 180� korrigieren:

wgknb = wgknb � 360� für wgkn > 180�

4Die Ungenauigkeiten wurden bei praktischen Tests festgestellt.

3. Realisierung 48

Berechnungen versus statische Tabelle

Um den 8 Bit Mikrocontroller von der Berechnung von Gleitkommazahlen mit doppelter Ge-nauigkeit zu entlasten, könnte man versuchen die Berechnungen mit Hilfe von vorberechne-ten statischen Tabellen zu vereinfachen. Da die Berechnungen aber von zwei Messgrößenabhängen, die leichten Schwankungen unterliegen, ist es nicht auf einfachem Wege möglichden Winkel anhand statischer Tabellen zu ermitteln. Und da die Berechnungen zwar sehr lan-ge dauern, aber immer noch in zufriedenstellender Zeit erledigt werden, ist ein Ausweichenauf andere Methoden der Winkelbestimmung nicht erforderlich. Andere Methoden wären vorallem dann interessant, wenn die Berechnungen auf der gewählten Hardware so lange dau-ern würden, dass die gestellten Anforderungen nicht mehr erfüllt werden können.


Die einzige Einstellung die an diesem Modul vorgenommen werden kann, ist das Setzendes Nullpunkts (Lenkradmittelstellung). Über einen Taster an der Gehäusevorderseite kanndieser jederzeit gesetzt werden.

Die Leuchtdioden an der Vorderseite des Moduls dienen als Statusanzeige und haben fol-gende Bedeutungen:

• Grün: Heartbeat-LED. Dauerleuchten = warte auf Synchronisation durch TM-Nachricht. Blinken = System arbeitet, Aus = keine Versorgungsspannung oder defekt.

• Gelb1: CAN-Send-LED. Dauerleuchten mit Grün zusammen = Watchdog abgelaufen.Blinken = Nachrichten werden gesendet. Aus = Busmode-Off.

• Gelb2: Aktion-LED. Blinken = Lenkwinkelveränderung. Aus = keine Winkeländerung

Die unterstützten globalen Steuerungsbefehle werden in 2.3 auf Seite 15 beschrieben. EineÜbersicht mit den Nachrichten- und Datenformaten befindet sich im Anhang A auf Seite69.

3.6. Raddrehzahl

Das Modul dient der Ermittlung der Raddrehzahl, bzw. der Radumlaufgeschwindigkeit vonzwei gleichen Rädern. Die Geschwindigkeit soll 25 mal pro Sekunde festgestellt und überden CAN-Bus versendet werden. Die Ermittlung der Raddrehzahl erfolgt mit so genanntenSensorlagern, eins an jedem Rad. Die Sensorlager befinden sich an der Radaufhängung

3. Realisierung 49

und dienen als Lager für den Radbolzen, an dem die Bremsscheibe und die Radaufnahmemit dem Rad selber befestigt sind.

3.6.1. Funktionsweise und Anschluss des Sensorlagers

Die verwendeten Sensorlager arbeiten intern mit so genannten Hallsensoren. An dem in-neren Ring, in dem sich der Radbolzen befindet, befindet sich im Lager noch ein weitererRing. Dieser Ring hat ein gleichmäßig, über die Oberfläche verteiltes, wechselndes Magnet-feld. Die, wie in Abbildung 3.8, angeordneten Hallsensoren erzeugen dann bei Drehung desinneren Ringes jeweils ein Rechtecksignal. Die beiden Ausgangssignale sind dabei zu ein-ander um 90 Grad Phasen verschoben. Die Drehrichtung gibt dabei vor, welches der beidenSignale vor- bzw. nacheilt. Bei der Auswertung der Signale könnte man so die Drehrichtungbestimmen.

Abbildung 3.8.: Funktionsweise des Sensorlagers (SKF (2003))

Die Sensoren sind wie in Abbildung 3.9 abgebildet, als Open-Collector-Schaltung ausge-legt. An dem Modul für die Raddrehzahl wird das Sensorlager mit einer Versorgungsspan-nung von 5 Volt betrieben, dabei werden die Open-Collector-Ausgänge mit einem Pull-Up-Widerstand von 270 Ohm an die Versorgungsspannung gelegt.

3. Realisierung 50

Abbildung 3.9.: Elektrischer Anschluss des Sensorlagers (SKF (2003))

Die hier verwendeten Sensorlager erzeugen 48 Pulse pro Umdrehung. Das Modul nutzt nureinen der beiden Kanäle.

3.6.2. Auswertung Sensor / Berechnungen

Um zu ermitteln, wie schnell sich ein Rad dreht, gibt es zwei Möglichkeiten:

• Es wird in einem festgelegtem Zeitraum die Anzahl der Pulse gezählt. Dies hat denNachteil, dass wenn man den Zeitraum zu klein wählt, kann es bei niedrigen Ge-schwindigkeiten des Rades passieren, dass in dem einen Zeitraum ein Puls und indem nächsten Zeitraum kein Puls gezählt wird. Es würde eine ständig wechselndeAnzeige von der Geschwindigkeit geben und die Bestimmung der Raddrehzahl wäreungenau.

• Es wird der zeitliche Abstand zwischen den Pulsen gemessen. Auch hier gibt es Pro-bleme bei zu niedrigen Geschwindigkeiten, bei kurzen Abfrageintervallen sind die Zeit-messungen bei der Abfrage des Zählerstands oftmals noch nicht abgeschlossen, danoch kein neuer Puls aufgetreten ist. Bei höheren Geschwindigkeiten ist die Auflösungdes Timer entscheidend, ist sie zu gering, können feine Geschwindigkeitsunterschiedeim oberen Bereich nicht mehr unterschieden werden. Die Geschwindigkeit würde aufeiner Anzeige kleine Sprünge machen und nicht mehr linear abgebildet.

3. Realisierung 51

Um die Geschwindigkeit zu ermitteln, wird die zweite Möglichkeit angewandt. Dabei wird dieTimerauflösung möglichst hoch gewählt, was durch die Verwendung einer RegTask unter-stützt wird.

Jeweils ein Ausgang der Sensorlager wird auf die Input-Capture-Pins der beiden Timer 0 und3 des Mikrocontrollers gelegt. Die Timer werden als vorwärts zählende Zähler konfiguriert,die nach Erreichen des maximal Wertes wieder bei Null beginnen (Wraparound). Außerdemwird er so konfiguriert, dass bei einer positiven Flanke am Input-Capture-Pin, der aktuelleZählerstand in das Input-Capture-Register übernommen wird.

Als Clock-Source wird die interne I/O-Clock mit dem Teiler 8 vom Prescaler verwendet, dasheißt, der Timer wird mit einem Takt von 2 MHz betrieben.

Ausgangssituation:Es wird angenommen, dass der Radumfang niemals kleiner als 150 cm ist. Außerdem wirddie zu messende Geschwindigkeit nie höher als 400 km/h sein. Wahrscheinlich sogar kleinerals 250 km/h.

Das Input-Capture-Register muss so oft abgefragt werden, dass kein Wert verloren geht.Das bedeutet, dass das Abfrageintervall mindestens genauso klein, besser aber noch etwaskleiner ist, als das Intervall der Impulse. Bei der oben genannten Ausgangssituation ergibtsich folgende Rechnung für das Abfrageintervall:

Gegeben: Geschwindigkeit v = 400km=h, Radumfang UR = 1; 5m, Pulse pro UmdrehungPu = 48

Gesucht: Pulsintervall ip

ip =UR

v � Pu

=3; 6 � 1; 5m

400km=h � 48= 281�s

Mit einer normalen Task ist es somit nicht möglich die Abfrage zu realisieren. Als RegTaskist es mit einem Abfrageintervall von 200�s machbar.

Bei der Zählertaktrate von 2 MHz und dem Abfrageintervall von 200�s ergibt sich eine ma-ximale Zählerstandsdifferenz zwischen zwei Abfragen von 400. Der Zählerstand erhöht sich,bei einer Geschwindigkeit von 400 km/h, zwischen zwei Pulsen um 562.

Gegeben: Pulsintervall ip = 281�s , Zählerintervall iz =1

2MHz

Gesucht: Zählerstandsdifferenz dz

dz =iptz

=281�s

1

2MHz

= 281�s � 2MHz = 562

Da die Zählerstandsdifferenz größer als die Geschwindkeit in km/h ist, ist die ermittelte Ge-schwindigkeit bei 400 km/h auf unter 1 km/h genau.

3. Realisierung 52

Gegeben: Zählerstandsdifferenz dz = 562, Geschwindigkeit v = 400km=h

Gesucht: Genauigkeit g

v

dz=

400km=h

562= 0; 71km=h

Die Raddrehzahl, bzw. die Umlaufgeschwindigkeit des Rades, kann nun alle 200�s innerhalbder RegTask berechnet werden. Dabei kann es vorkommen, dass nicht jedes mal, wenn dasInput-Capture-Register abgefragt wird, ein neuer Wert vorhanden ist. Ob es sich bei dem,im Input-Capture-Register vorhandenen Wert, um einen Neuen handelt, wird durch ein Flag,das Input-Capture-Flag angezeigt. Nur wenn dieses Flag gesetzt ist, wird das zugehörigeRegister abgefragt. Da der Zähler nach einem Impuls am Imput-Capture-Pin nicht zurück-gesetzt wird, sondern einfach weiter läuft, bis es zu einem Wraparound kommt, muss diesbei der Berechnung der Zählerstandsdifferenz berücksichtigt werden. Ist der aktuelle Wertim Zähler kleiner als der letzte Wert, wird die Differenz wie folgt berechnet:

Gegeben: Zählerstand alt calt , Zählerstand neu cneuGesucht: Zählerstandsdifferenz dz

dz = (216 � calt) + cneu

Bei sehr niedrigen Geschwindigkeiten kann es vorkommen, dass der Zähler mehr als einenWraparound ausführt. Um dies zu erkennen, wird in einer Variable mitgezählt, wie oft dieRegTask ausgeführt wurde, ohne dass das Input-Capture-Flag gesetzt war. In der Konfigu-rationsdatei des Programms lässt sich die maximale Anzahl der Durchgänge, in denen dasInput-Capture-Flag nicht gesetzt sein darf, festlegen. Wird dieser Wert überschritten, wird fürdie Geschwindigkeit der Wert Null gesetzt. Die maximale Anzahl an Durchgängen, bis einWraparound auftritt, wird wie folgt berechnet:

Gegeben: Abfrageintervall ci = 200�s , Zählerintervall iz =1

2MHz, max. Zählerstand cm =

216

Gesucht: max. Durchgänge dm

dm = cm :izci

= dm = 216 :0; 5�s

200�s=

216

400� 163

Somit ergibt sich für die kleinste Geschwindigkeit, die mit diesem Modul ermittelt werdenkann:

Gegeben: Durchgänge dm = 163, Pulse pro Umdrehung Pu = 48, Abfrageintervall ci =200�s , Radumfang UR = 1; 5m, Umrechnungsfaktor m/s zu km/h = 3,6Gesucht: min. Geschwindigkeit vmin

vmin =UR � 3; 6

dm � ci � Pu

=1; 5m � 3; 6

163 � 200�s � 48

3. Realisierung 53

Man könnte auch die Anzahl der Wraparounds bei der Geschwindigkeitsberechnung be-rücksichtigen und so noch kleinere Geschwindigkeiten auswerten. Dies wird jedoch nichtals erforderlich angesehen, da so niedrige Geschwindigkeiten nicht für die Telemetrie undSteuerungsaufgaben wichtig sind.

Um die RegTask in ihrer Ausführungszeit möglichst kurz zu halten, wird nur die Zählerstands-differenz innerhalb der RegTask berechnet. Die Geschwindigkeit wird dann in der Task diedie CAN-Nachricht vorbereitet berechnet.

Die Berechnung der Geschwindigkeit gestaltet sich folgendermaßen:

Gegeben: Zählerstandsdifferenz dz , Zählertaktrate fz , Radumfang UR,Pulse pro Umdrehung Pu

Gesucht: Geschwindigkeit v in km/h

v =fz � UR � 3; 6

dz � Pu

Um Rechenzeit zu sparen wird ein Teil der Berechnungen schon vorher durchgeführt und alsKonstante im Programmcode abgelegt bzw. berechnet wenn der Radumfang eingestellt wirdund dann als Konstante im EEPROM abgelegt.

Dieser Teil wird nun vorher schon berechnet und im Programmcode abgelegt:

cf =fzPu

Dieser Teil wird beim einstellen des Radumfangs berechnet der in Zentimetern angegebenwird:

ctz = UR � 0; 0036

Und so sieht die Berechnung dann im Programm aus, wo die Raddrehzahl in Umdrehungenpro Minute berechnet wird :

vrpm =cfdz

� ctz

Neben der Raddrehzahl soll auch die Geschwindigkeit in km/h ausgegeben werden kön-nen:

v =cfdz

Die Raddrehzahl und die Geschwindigkeit in km/h werden noch auf ganze Einer gerundet,und dann als 16 Bit unsigned Integer versendet.

3. Realisierung 54


Es gibt drei Steuerbefehle mit denen folgende Einstellungen am Modul vorgenommen wer-den können:

• Setzen der Geschwindigkeitsausgabe auf Umdrehungen pro Minute.

• Setzen der Geschwindigkeitsausgabe auf Kilometer pro Stunde.

• Setzen und speichern des Radumfangs im EEPROM, Einheit in Zentimeter.

Wenn Einstellungen verändert werden, wird die neue Einstellung im EEPROM des Mikro-controllers gespeichert und das Modul führt selbständig einen Reset aus. Dieser Reset istnotwendig, da das Schreiben von Daten in das EEPROM zu lange dauert und so die Zeitenfür das Scheduling nicht eingehalten werden.

Die Einstellungen können über die Oberfläche der Leistandsoftware, die in Abbildung 5.2 aufSeite 66 zu sehen ist, vorgenommen werden.

Die Leuchtdioden an der Vorderseite des Moduls dienen als Statusanzeige und haben fol-gende Bedeutungen:

• Grün: Heartbeat-LED. Dauerleuchten = warte auf Synchronisation durch TM-Nachricht. Blinken = System arbeitet. Aus = keine Versorgungsspannung oder defekt.

• Gelb: CAN-Send-LED. Dauerleuchten mit Grün zusammen Watchdog abgelaufen.Blinken = Nachrichten werden gesendet. Aus = Busmode-Off.

• Rot: Fehler-LED. Dauerleuchten = Fehler im Scheduling. Aus = Kein Fehler.

Die unterstützten globalen Steuerungsbefehle werden in 2.3 auf Seite 15 beschrieben. EineÜbersicht mit den Nachrichten- und Datenformaten befindet sich im Anhang A auf Seite69.

4. Qualitätssicherung

4.1. Maßnahmen gegen EMV- Störungen

EMV Allgemein

EMV steht für Elektromagnetische Verträglichkeit und behandelt die technischen und recht-lichen Grundlagen der wechselseitigen Beeinflussung elektrischer Geräte, durch die von ih-nen hervorgerufenen elektromagnetischen Felder in der Elektrotechnik. Das Thema Elek-tromagnetische Verträglichkeit umfasst alles, was mit ungewollten als auch gewollten Funk-tionsstörungen von elektrischen Betriebsmitteln, durch z.B. elektrische, magnetische oderelektromagnetische Felder und Vorgänge zusammenhängt. Bei der Nutzung von elektrischerEnergie wird immer Energie elektromagnetischer Felder umgewandelt, z.B. in Strahlungs-energie (Glühlampe) oder mechanische Energie(Motor). Dabei bleiben die Felder nicht zwin-gend nur innerhalb der elektrischen Betriebsmittel, sondern können sich auch außerhalb desBetriebsmittels ausbreiten. Wenn die Felder sich frei ausbreiten, können sie in andere elektri-sche Betriebsmittel eindringen und Funktionen des Betriebsmittels beeinflussen. Besondersgroß ist die Gefahr bei Fahrzeugen, dass Störungen von der Zündung, Lichtmaschine oderdem Anlasser verursacht werden. Zum Beispiel entstehen bei dem Betätigen des Anlassers,Funken an den Kohlebürsten des Anlassers. Diese Funken können starke elektromagne-tische Felder verursachen. Durch bestimmte Maßnahmen lassen sich die elektronischenKomponenten im Fahrzeug ausreichend unempfindlich gegenüber diesen elektromagneti-schen Feldern machen.

EMV Maßnahmen

Damit das System bei auftretenden EMV Störungen nicht beeinträchtigt wird, werden eineReihe von Schutzmaßnahmen ergriffen. Die Gehäuse sind alle aus Aluminium, um eine guteAbschirmung zu gewährleisten. Alle Gehäuse sind mit der Masse über den Fahrzeugrahmenverbunden, eine direkte Verbindung zur Masse auf der Platine im Modul besteht nicht.

Die Aufteilung der Stromversorgung in zwei Stufen hat außer den in 2.4.1 schon beschrie-benen Vorteilen, auch noch den, dass leichte Störungen im 9 Volt-Netz, beim Herabsetzen

4. Qualitätssicherung 56

auf die 5 Volt, ausgefiltert werden können. Dafür wird eine Grundschaltung mit 5 Volt Span-nungsregler verwendet, wobei auch hier wieder ein 100nF Kondensator eine wichtige Rollespielt.

Alle Leitungen für den CAN-Bus haben zwei verdrillte Adernpaare. Ein Adernpaar wird fürdie Stromversorgung von 9 Volt benutzt das andere Adernpaar für die Signale CAN-High undCAN-Low. Außerdem sind die Leitungen mit einer Abschirmung ausgestattet, diese wird im-mer nur einseitig mit der Gehäusemasse eines Moduls verbunden. Dadurch werden eventu-elle Masseschleifen zwischen den einzelnen Modulen vermieden. Das CAN-Physical-Layernach ISO 11898-1 arbeitet nach sehr wirkungsvollen Verfahren, die eine Anfälligkeit desCAN-Busses gegenüber EMV-Störungen weiter verringern. Auf so genannte Stichleitungenwird vollständig verzichtet, der CAN-Bus wird von Modul zu Modul durchgeschliffen, wasProblemen, die in Zusammenhang mit zu langen Stichleitungen vorkommen, vorbeugt.

Auch alle Sensoren werden über abgeschirmte Leitungen angeschlossen. Zudem sind anallen Eingängen Kondensatoren (100nF) gegen Masse geschaltet. Diese schließen kurzeSpannungsimpulse wie sie durch EMV auftreten können, mit der Masse kurz, so dass siekeine Störungen verursachen können.

EMV Negativbeispiel

Eine elektronische Steuerung, für die im Fahrzeug verwendete elektropneumatische Gang-schaltung zeigt welche Störungen elektromagnetische Felder von einem Anlasser erzeu-gen können. Die Steuerung ist kein Bestandteil dieser Arbeit, zeigt aber sehr gut, wiesich EMV-Störungen auswirken können. Bei der elektronischen Steuerung sind keine EMV-Schutzmaßnahmen eingesetzt worden. Beim Starten des Motors, der Anlasser wurde be-tätigt, beginnt die Gangschaltung unkontrolliert schnell hin und her zu schalten. Währenddie Schaltung im Einzelbetrieb einwandfrei arbeitet. Bei der Gangschaltungssteuerung wirdkein geschirmtes Gehäuse und auch keine geschirmten Zuleitungen zu den Tasten verwen-det. Um die Steuerung unempfindlicher gegenüber EMV-Störungen zu machen, werden nunKondensatoren (100nF) an den Eingängen des Mikrocontrollers, wo die Taster angeschlos-sen sind, verwendet. Ein erneuter Test zeigt nun keine Funktionsstörungen beim Anlassendes Motors mehr. Mit einfachen Mitteln können also Probleme mit EMV vermieden werden.

EMV Test

Mit einem einfachen EMV Test wird festgestellt, wie sich eine kurze Entladung auf die Ge-häuse / Abschirmung auswirkt. Für den Test ist das gesamte System mit allen Modulen imLabor in Betrieb. Dazu wird ein statisch aufgeladener Gegenstand an die Gehäuse verschie-dener Module herangeführt. Bei der Entladung an den verschiedenen Modulen schaltet sich


immer wieder das Datenlogger Modul ab. Der Grund dafür ist, dass die Leitung, die einenInterrupt bei einem plötzlichen Spannungseinbruch am Datenlogger Modul verursachen soll,nicht genügend gegen EMV-Störungen geschützt ist. Mit einem 100nF Kondensator lässtsich dieses Problem lösen. Außer dieser Störung gibt es sowohl an diesem, als auch ananderen Modulen keine Störungen.

4.2. Unterspannungstest

Für diesen Test wird die Versorgungsspannung von den stabilisierten 9 Volt so lange redu-ziert, bis die Module in einen sicheren Reset-Zustand übergehen.In den Modulen sorgt ein 5V Spannungsstabilisator für die Betriebsspannung. Bei allen ver-bauten Mikrocontrollern ist die Unterspannungserkennung (Brown-out detection) auf 4,1 Volteingestellt. Wenn diese Spannungsschwelle unterschritten wird, soll der Mikrocontroller inden sicheren Reset-Zustand gehen.

Ergebnisse:

• Alle Module schalten bei einer internen Spannung von ca. <= 4,1 Volt sicher in denReset-Zustand. Die externe Spannungsschwelle liegt dann bei ca. 5,5 Volt.

• Kritisch ist eine Spannung Ub:

– extern: 5,5V < Ub < 5,75V und

– intern: 4,1V < Ub < 4,35 V

• Beim Time-Master ist eine Spannung Ub kritisch wenn,

– extern: 5,5V < Ub < 6,4V und

– intern: 4,1V < Ub < 4,9V

Aus den gewonnenen Werten kann man jetzt erkennen, dass es einen Spannungsbereichgibt, in dem die Module in fehlerhafte Zustände geraten, bzw. fehlerhaft arbeiten.Besonders kritisch ist dieser Bereich beim Time-Master, dieser beginnt mit 4,9 Volt bereitsknapp unter der normalen Betriebsspannung von 5 Volt. Um zu verhindern, dass die Mo-dule aufgrund einer zu niedrigen Betriebsspannung fehlerhaft arbeiten, muss eine externeElektronik die Betriebsspannung gegebenenfalls ganz abschalten. Diese Unterspannungs-erkennung könnte auch die Spannungsquelle für die Modul-Betriebsspannung auf eine Er-satzspannungsquelle umschalten (z.B. eine Batterie).


Ein Überspannungstest macht hier keinen Sinn, da die Hardware dann zerstört wird. GegenÜberspannungen müssen extern entsprechende Maßnahmen getroffen werden.

4.3. Rüttel-Test auf Hydropulsstand

Testbedingungen

Testdauer je Modul: 55sAmplitude: 10mmFrequenz: 5-10 Hz (linearer Anstieg über Testdauer)Getestete Achse: y-Achse

Beschleunigungsmessung mit BeschleunigungsaufnehmerMesswertauswertung:Beschleunigungsaufnehmer -> Messverstärker Spider 8 -> Software Diadem (NI)

Abbildung 4.1.: Time-Master-Modul auf dem Hydropulsstand

Zu testende Module

Es wurden die Module Communicator, Datalogger, Time-Master und zwei mal Raddrehzahlgetestet.Bei dem einen Raddrehzahl Modul waren die Signalleitungen intern auf das Board nur ge-steckt und nicht gelötet worden. Es sollte festgestellt werden, ob sich die gesteckten Signal-leitungen während des Tests lösen. Im Vergleich dazu stand das Raddrehzahl Modul mitangelöteten Signalleitungen.


Durchführung

Die Module wurden einzeln auf dem Hydraulikzylinder mit Kabelbindern befestigt. Je Modulgab es einen Testdurchlauf, entsprechend den oben genannten Testbedingungen. Währenddes Tests wurden Beschleunigungswerte von Maximal 67,44m=s2 gemessen. Während desTestdurchlaufs musste die Amplitude mit steigender Frequenz von Hand nach geregelt wer-den.

Testergebnis

Bei der anschließenden Sichtprüfung wurden keine mechanischen Veränderungen, außerein Andeuten von Scheuern an einem Stück Schrumpfschlauch im Communicator-Modulfestgestellt. Auch an dem Modul, das zum Test nur Steckverbindungen gehabt hat sind kei-ne losen Verbindungen entstanden. Beim anschließenden Funktionstest konnten keinerleiProbleme festgestellt werden.

Somit wurden alle Tests erfolgreich abgeschlossen.

4.4. Individuelle Modultests

Alle Module werden einzeln auf ihre Funktionalität überprüft. Neben den Tests, die für alleModule gleich sind, werden zusätzlich bei jedem Modul entsprechend für dessen FunktionenTestszenarien entwickelt.

Bei allen wird einzeln getestet ob sie ihre Arbeit aufnehmen, sich mit dem Time-Master syn-chronisieren und ob die Nachrichten im richtigen Zeitfenster über den CAN-Bus versendetwerden.

Beispiele für individuelle Testszenarien:

• Beim Modul für die Bestimmung der Raddrehzahlen, wird an Stelle eines Sensorlagersein Funktionsgenerator angeschlossen. Mit dem Funktionsgenerator lassen sich ver-schiedene Geschwindigkeiten simulieren. Die Geschwindigkeit, die das Modul ermit-telt, kann dann über Berechnungen, mit der am Funktionsgenerator eingestellten Fre-quenz, validiert werden. Für diesen Test wird ein Terminal an die RS232-Schnittstelledes Moduls angeschlossen, wo dann die ermittelte Geschwindigkeit ausgegeben wird.Wird die Geschwindigkeit immer richtig angezeigt, kann auch der Inhalt der CAN-Nachrichten mit Hilfe des CAN-Sniffers validiert werden.


• Das Testen des Lenkwinkel-Modul gestaltet sich mit einem einfach an das Modul an-geschlossenen Lenkwinkelsensor recht einfach. Auch hier werden dann die ermitteltenWinkel, ähnlich wie die Geschwindigkeit beim Raddrehzahl-Modul, überprüft.

4.5. Integrationstest

Beim Integrationstest werden alle Module, die später auch ins Fahrzeug kommen, im La-bor, angeschlossen. Dabei wird mit dem Oszilloskop und dem CAN-Sniffer 4.7 überprüftob alle Nachrichten zum richtigen Zeitpunkt, auf dem CAN-Bus vorhanden sind. Auch derDatenaustausch mit einem Laptop als Kommandostand wird überprüft, sowie alle Einstel-lungsmöglichkeiten ausprobiert. Es werden alle Daten mit dem Datenlogger und zusätzlichmit dem Laptop aufgezeichnet und später verglichen bzw. auf Fehler überprüft.

Es wird auch getestet wie sich das gesamte System verhält, wenn einzelne Module währenddes Betriebs am CAN-Bus an- und abgekoppelt, über die Versorgungsspannung ein- undausgeschaltet und resettet werden. Bei allen Tests darf das System nicht aus dem Taktkommen, es muss ohne Funktionsstörung weiterarbeiten. Besonders wichtig ist auch, dasskeine CAN-Nachrichten in falschen Zeitfenstern gesendet werden.

Ob die Nachrichten zum richtigen Zeitpunkt über den CAN-Bus gesendet werden, wird mitdem Oszilloskop überprüft. Hierzu befinden sich im Anhang B einige Abbildungen von dendurchgeführten Messungen.

Erst nach dem erfolgreichen Abschluss aller Tests, wird das System ins Fahrzeug inte-griert.

4.6. Integration im Fahrzeug

Das System wird beim Einschalten der Bordspannung über den Hauptschalter aktiviert. ZweiSchalter werden im Cockpit integriert, mit denen der Fahrer die Datenaufzeichnung und dieWLAN-Übertragung, getrennt voneinander, ein- und ausschalten kann. Die Module sind vonaußen unsichtbar im Fahrzeug untergebracht. Um auf das Statusdisplay des TimeMastersschauen zu können, muss nur die Nase des Fahrzeugs abgenommen werden. Dies ist dankSchnellverschlüssen ohne großen Aufwand zu erledigen. Der Datenlogger befindet sich aufder Rechten Seite unter dem Seitenkasten und ist auch hier dank Schnellverschlüssen inder Seitenverkleidung leicht zugänglich. Nach dem Einschalten der Zündung baut das ECU-Modul automatisch die Verbindung zur jetzt eingeschalteten ECU her. Alle anderen Modulesind bereits mit dem Einschalten der Bordspannung betriebsbereit und liefern ihre Daten.


Im stehendem Fahrzeug wird getestet ob nach dem Einschalten alle Komponenten einwand-frei arbeiten, dies wird mit Hilfe des Oszilloskop, des Kommandostands (Laptop) und anhandder Status-LEDs an den Modulen überprüft. Mit dem Oszilloskop wird außerdem die Span-nungsversorgung auf ihre Stabilität überprüft.

Wenn alles überprüft und in Ordnung ist, wird der Motor gestartet und alle Tests wiederholt.Besonders interessant ist, jetzt wo die Lichtmaschine Strom erzeugt, die Versorgungsspan-nung für die Module. In einem Test werden die von dem ECU-Modul an der Motorsteuerungabgegriffenen Daten mit denen von der Motorsteuerungssoftware angezeigten Daten vergli-chen.

Im letzten Test wird bei fahrendem Fahrzeug überwacht ob das System einwandfrei Datenzum Kommandostand sendet. Außerdem werden die Befestigungen der Module in regelmä-ßigen Abständen überprüft. Auch eine Fahrt bei schlechtem Wetter (starker Regen, nasseverschmutzte Fahrbahn) müssen alle Komponenten ohne Fehlfunktionen absolvieren. AlleModule und Stecker werden nach der Fahrt auf Wassereinbruch und Korrosion überprüft.

Alle Tests konnte das System letztendlich erfolgreich abschließen.

4.7. Hilfsmittel zur Fehleranalyse

4.7.1. CAN-Sniffer

Der CAN-Sniffer ist ein Modul, das ausschließlich der Qualitätssicherung und dem Debug-gen dient. Es bietet die Möglichkeit, alle oder nur bestimmte CAN-Nachrichten, die auf demCAN-Bus gesendet werden, anzuzeigen. Dazu muss es nur an dem CAN-Bus und an ei-nem Terminal (z.B. PC mit Hyperterminal), das für die Anzeige und Bedienung zuständig ist,angeschlossen werden. Die Abbildung 4.2 auf Seite 62 zeigt das Konfigurationsmenü desCAN-Sniffers.

Es werden, wie in der Abbildung 4.3 auf Seite 62 zu sehen ist, die acht Datenbytes, derIdentifier, die Länge, der Zeitstempel des Empfangszeitpunktes, sowie alle anderen dazugehörigen Informationen angezeigt. Die Nachrichten und deren Inhalt lassen sich so denModulen zuordnen und überprüfen.

4.7.2. CAN-Bus-Fluter

Dieses spezielle Modul dient nur zu Testzwecken. Das Modul kann eine beliebige Anzahl vonCAN-Nachrichten, zu bestimmten Zeitpunkten, auf den CAN-Bus senden. Auch hier lassen


Abbildung 4.2.: CAN-Sniffer Menü

Abbildung 4.3.: CAN-Sniffer Nachrichtenanzeige (mit ID 0x63B)


sich die Zeitpunkte für das Absenden einer Nachricht in 200us Schritten einstellen. Es istmit diesem Modul möglich für Tests den Bus von 0 bis 100 Prozent auszulasten (außer derTM-Nachricht). Es können so, auch Kollisionen mit Nachrichten anderer Module provoziertwerden. Die Abbildung 4.4 auf Seite 63 zeigt den CAN-Bus auf einem Oszilloskop, mit einervom CAN-Bus-Fluter erzeugten Auslastung von 80 Prozent.

Abbildung 4.4.: CAN-Bus-Fluter verursacht 80% CAN-Busauslastung (Bild auf Oszilloskop)

5. Fazit und Ausblick

5.1. Praktischer Einsatz

Mit dem Telemetrie-Funktionen des Systems, stehen den Konstrukteuren neue Möglichkei-ten zur Verfügung, die Testfahrten des Rennwagens zu überwachen. Vom Leitstand aus,kann jetzt jede Fehlfunktion oder Defekte am Motor, frühzeitig erkannt werden. Sollte z.B.die Kühlwassertemperatur zu hoch steigen, ohne das der Fahrer es bemerkt, kann dies vomLeitstand aus dem Fahrer per Funk oder über die Streckenposten, mitgeteilt werden.

Auch das Fahrverhalten der Fahrer, kann mit diesem System, vom Leitstand aus, oder beider späteren Datenauswertung, beobachtet werden. So können die Fahrer, auch nach Be-endigung der Fahrt, auf Fahrfehler hingewiesen werden.

Zum Beispiel können die Fahrer, auch durch eine andere Fahrweise die Motortemperaturniedriger halten, wenn sie entsprechend darauf hingewiesen werden. Damit aber überhaupterst erkannt werden kann, dass ein Fahrer eine ungünstige Fahrweise hat, z.B. durch ständi-ges Fahren in einem hohen Drehzahlbereich, wird ein solches Telemetrie-System benötigt.

In der Abbildung 5.1 auf Seite 65 ist die Oberfläche, für die Live-Ansicht der Leistandssoft-ware, mit den diversen Telemetrie-Daten zu sehen.

Einstellungen am System können von den Konstrukteuren und Fahrern, bequem vom Note-book aus, über die Leitstandssoftware (siehe hierzu Abbildung 5.2 auf Seite 66) vorgenom-men werden.

5.2. Fazit

Zusammenfassend lässt sich sagen, dass das entwickelte System alle für die erste Ausbau-stufe gestellten Anforderungen erfüllt hat. Das System lässt sich leicht um weitere Modulemit neuen Funktionen erweitern und ausbauen. Auch die Integration und Anpassung an dieGegebenheiten, in zukünftigen Rennwagen-Modellen sollte für die Konstrukteure keine Pro-bleme darstellen.

5. Fazit und Ausblick 65

Abbildung 5.1.: Oberfläche für die Live-Ansicht der Daten

Die Idee ein System zu entwickeln, welches nicht nur Telemetrie-, sondern auch Steuerungs-aufgaben übernehmen kann, konnte durch den Einsatz der Echtzeitfähigen Systemarchitek-tur erfolgreich umgesetzt werden.

Die Anwendung und Konfiguration, ist für die Fahrer und Konstrukteure, wie sich in der erstenAnwendung gezeigt hat, gleichermaßen leicht und verständlich gelungen. Dies ist auch denausgiebigen Tests, in Zusammenarbeit mit den Rennwagenkonstrukteuren und Fahrern, zuverdanken.

5.3. Veränderungen und Weiterentwicklung in derZukunft

In Zukunft werden, die bislang nur für Telemetrie genutzten Sensordaten auf dem CAN-Bus,auch für Steuerungsaufgaben benutzt. So lassen sich dann Aufgaben, wie in der folgendenListe, mit diesem System bewältigen.

• Temperaturabhängige Kühlwasserlüftersteuerung

• Anti-Blockier-System (ABS)

• Elektronische Fahrzeugs Stabilisierung bei extremen Fahrsituationen (ESP)


Abbildung 5.2.: Oberfläche Leitstandsoftware


• Teilweise automatisierte Gangschaltung

• Anti Schlupfsregelung (Anfahrhilfe)

Zum Beispiel lässt sich mit den durch die Radsensorlager und Lenkwinkelsensor gewonne-nen Daten, ein Reifendruck-Kontroll-System realisieren. So lässt sich ein, im Vergleich mitden anderen Rädern, stark in der Raddrehzahl abweichendes Rad unter Einbeziehung desLenkwinkels gegebenenfalls als defekt erkennen.

Ein weiteres Beispiel betrifft die Gangschaltung, die für die Disziplin Acceleration automa-tisiert werden kann. So lässt man die Gangschaltung bei einer bestimmten Drehzahl beimbeschleunigen automatisch in den nächst höheren Gang schalten. Zudem kann über dieGeschwindigkeit, gemessen an der angetriebenen Achse, und der Motordrehzahl berech-net werden, in welchem Gang sich die Gangschaltung befindet. Leider geben die meistenGetriebe, genauso wie das im aktuellen Auto verwendete, keine Rückmeldung darüber, inwelchem Gang man sich gerade befindet.

Literaturverzeichnis

[Atmel 2006] ATMEL: Atmel AVR AT90CAN128 Datasheet. 2006. – URL http://www.atmel.com/dyn/resources/prod_documents/doc7679.pdf

[Bosch-GmbH 2002] BOSCH-GMBH, Robert: Autoelektrik, Autoelektronik. Vieweg, 2002.– ISBN 3-528-13872-6

[Etschberger 2002] ETSCHBERGER, Konrad: Controller Area- Network - Grundlagen, Pro-tokolle, Bausteine, Anwendungen. Carl Hanser Verlag München Wien, 2002. – ISBN3-446-21776-2

[Haase 2007] HAASE, Sebastian: Telemetrie im Formula Student Rennwagen auf Basisvon CAN Bus, Datenspeicherung und Wireless LAN Technologien, Hochschule für Ange-wandte Wissenschaften Hamburg, Bachelorarbeit, 2007

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

[Schmitt 2006] SCHMITT, Günter: Mikrocomputertechnik mit Controllern der Atmel AVR-RISC-Familie. Oldenbourg Wissenschaftsverlag, 2006. – ISBN 3-486-58016-7

[Schwarz 2006] SCHWARZ, M.: Die Idee der Formula SAE / Student. 2006. – URLhttp://www.hawksracing.de/index.php?page=ueber_fsae

[SKF 2003] SKF: Sensor-Bearing Units concentrate intelligence in your motion control.2003. – URL http://www.skf.com

[Th.Führer 2000] TH.FÜHRER, W. Dieterle F. Hartwich R. Hugel M. W.: Time TriggeredCommunication on CAN. 2000. – URL http://www.semiconductors.bosch.de/pdf/CiA2000Paper_1.pdf

[Zimmerman und Schmidgall 2006] ZIMMERMAN, Werner ; SCHMIDGALL, Ralf: Bussys-teme in der Fahrzeugtechnik - Protokolle und Standards. Vieweg, 2006. – ISBN 978-3-8348-0166-1

http://www.atmel.com/dyn/resources/prod_documents/doc7679.pdf

http://www.atmel.com/dyn/resources/prod_documents/doc7679.pdf

http://www.hawksracing.de/index.php?page=ueber_fsae

http://www.skf.com

http://www.semiconductors.bosch.de/pdf/CiA2000Paper_1.pdf

http://www.semiconductors.bosch.de/pdf/CiA2000Paper_1.pdf

A. TTCAN-Timing undNachrichtenformate

Abbildung A.1.: CAN-Protokoll Nachrichtenformate

A. TTCAN-Timing und Nachrichtenformate 70

Abbildung A.2.: TTCAN-Timing, Matrixzyklus mit vier Basiszyklen

B. QualitätsicherungCAN-Nachrichtenversandt

Abbildung B.1.: Zeitabstand zwischen zwei TM-Nachrichten

In B.1 wird der zeitliche Abstand von zwei Time-Master-Nachrichten überprüft.

In B.3 wird der zeitliche Abstand von zwei aufeinander folgende Nachrichten überprüft.

In den Abbildungen B.4 und B.5 wird die Zeit von der TM-Nachricht des ersten Basiszyklusbis zu einer bestimmten Nachricht gemessen.

In Abbildung B.6 sind die zwei Nachrichten, die zum setzen der Systemzeit im Time-Masterführen, zu sehen.


Abbildung B.2.: Detailansicht einer TM-Nachricht


Abbildung B.3.: Abstand zweier Nachrichten


Abbildung B.4.: Sendezeitpunkt der Nachricht mit der ID 0x33


Abbildung B.5.: Sendezeitpunkt der Nachricht mit der ID 0x34


Abbildung B.6.: Nachrichten auf dem CAN-Bus beim setzen der Systemzeit

C. Inhalt der CD

Der Inhalt der beiliegenden CD wird in Tabelle C.1 beschrieben.

Verzeichnis Inhalt/Bachelorarbeit Enthält die Bachelorarbeit als PDF-Dokument./Quellcode Enthält den Quellcode aller Module./Literatur Enthält die PDF-Dokumente, die im Literaturverzeichnis angegeben sind.

Tabelle C.1.: Inhalt der beiliegenden CD

Glossar

Arbitration Im Allgemeinen versteht man unter der Arbitration oder Arbitrierung die mög-lichst gerechte Zuteilung von Ressourcen auf verschiedene Benutzer (Geräte).

Baudrate auch Symbolrate genannt ist eine physikalische Größe, welche die Schrittge-schwindigkeit einer Datenübertragung als Datenrate beschreibt. Ein Schritt (Takt)überträgt immer ein Symbol. Dieses Symbol kann ein oder mehrere Bits eines Da-tenstromes darstellen.

ECU Engine Control Unit - Motorsteuerung dient der Steuerung der Zündung und elektro-nischer Einspritzanlagen.

Hochsprache siehe höhere Programmiersprache.

höhere Programmiersprache ist eine Programmiersprache, die die Abfassung einesComputerprogramms in einer abstrakten Sprache ermöglicht (die so zwar für Men-schen, aber nicht unmittelbar für Computer verständlich ist).

Knopfzelle bezeichnung für kleine Batterien, die in Größe und Form Kleidungsknöpfenähneln.

Library ist eine Programmbibliothek.

Mips Millionen Instruktionen pro Sekunde(Million instructions per second) ist ein Maß fürdie Leistungsfähigkeit der zentralen Recheneinheit.

Prescaler Vorteiler, wird in elektronischen Schaltungen als Frequenzteiler verwendet.

Scheduler regelt die zeitliche Ausführung mehrerer Tasks in Betriebssystemen.

Stichleitungen sind Leitungen die als Arm von einer Hauptleitung abgehen.

Telemetrie heißt so viel wie Fernmessung und bezeichnet die Übertragung von Messwer-ten eines am Messort befindlichen Messfühlers (Sensor) zu einer räumlich getrenntenStelle.

C. Inhalt der CD 79

Timer auch Zeitgeber genannt, ist ein Steuerbaustein, der zur Realisierung der unter-schiedlichsten zeitbezogenen Funktionen, sowie als Zähler eingesetzt wird.

Wachtdog ist eine Komponente eines Systems, die die Funktion anderer Komponentenüberwacht.

Index

Übertragungsraten, 11

Abfrageintervall, 51Abschirmung, 17AD-Wandler, 45, 47Aktoren, 7Anforderungen, 3–5, 21AT90CAN128, 16Ausfallsicherheit, 10AVR-Studio, 16

Buchsen, 17

CAN, 11, 12, 16CAN-Nachrichten, 39Clock, 14, 51

Datenübertragung, 11Datenaufzeichnung, 3Display, 40, 43Drehwinkelgeber, 45

Echtzeitanforderungen, 14EEPROM, 45Einstellungen, 54Erweiterungskarten, 7

Formula Student, 1, 3

Gehäuse, 17Glimmerplättchen, 17

HAWKS, 5Hawks Racing, 2Hybridscheduler, 25

Interrupt, 22ISR, 23

Jtag-Schnittstelle, 16

Kollisionen, 11

Lenkwinkel, 45Leuchtdioden, 17, 54

Mikrocontroller, 16, 17, 20, 39, 45, 51Mittelstellung, 45

Oversampling, 46

Prototyp, 2, 5

Rennwagen, 1, 4RTC, 42

Scheduler, 21, 35Sensoren, 7Sensorlager, 49Softwareentwicklung, 16Spannungsmessungen, 46Stecker, 17Steuerbefehle, 15Steuerbefehlen, 15Steuerungsaufgaben, 12Super Loop, 22Synchronisation, 13, 40System-Checker, 43

Tasks, 20Telemetrie, 3Timer, 50

Index 81

TM-Nachrichten, 40

Varianz, 14Versorgungsspannung, 49

Wärmeentwicklung, 17

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, 25. September 2007Ort, Datum Unterschrift

Bachelorarbeit im Studiengang Technische Informatik der ... · Als Hardwarebasis dient hier ein 8 Bit Mikrocontroller und der für den Automotiv Bereich prädestinierte CAN-Bus. Simon

Documents