kramann.info
© Guido Kramann

Login: Passwort:










COACH2
1 Planung
2 Architektur
3 Anzeige
4 EEPROM
5 I2C
..5.1 MasterSendByte
..5.2 MasterSend2Bytes
..5.3 MasterReceiveByte
..5.4 MasterReceive2Bytes
6 UART
7 DFT
8 FFT
9 Planung2
10 Klassen
..10.1 AnzeigeTaster
..10.2 RS232
..10.3 MotorServo
..10.4 Drehgeber
..10.5 Sensor
..10.6 Funk
11 Adaption
..11.1 Programmiertechnik
..11.2 Evoopt
12 Fuzzy
..12.1 Uebungsaufgabe
..12.2 Fuzzygroesse
..12.3 Fuzzyset
..12.4 Lookuptable
13 Skript
..13.1 Funkkorrektur
..13.2 Skriptsprachen
..13.3 Anforderungen
..13.4 Agentensysteme
..13.5 Implementierung
..13.6 Experimente
14 Gesamtkonzept
..14.1 Skripterweiterung
..14.2 Makroverhalten
67 Echtzeitsysteme
..67.1 Einfuehrung
....67.1.1 Echtzeit
....67.1.2 Korrektheit
....67.1.3 Hardware
....67.1.4 Ziele
....67.1.5 Synchronprogramm
..67.2 Threads
....67.2.1 Java
....67.2.2 Synchronisierung
..67.3 COACH
....67.3.1 Kaskadenregler
....67.3.2 Zeitebene1
....67.3.3 Zeitebene2
....67.3.4 Zeitebene3
....67.3.5 Puck
....67.3.6 Puckschwarm
..67.4 RTAIlab
....67.4.1 Slax
....67.4.1 USB_Stick
....67.4.2 Sinus
..67.5 Semaphor
....67.5.1 Laufkatze
....67.5.2 Java
....67.5.3 Semaphor
..67.6 Audio
....67.6.1 wav
....67.6.2 Linux
..67.7 Lookup
....67.7.1 Fuzzy
....67.7.2 PWM
..67.8 NeuronaleNetze
....67.8.1 Neuron
....67.8.2 Backpropagation
....67.8.3 Umsetzung
....67.8.4 Winkelerkennung
..67.9 Internetprogrammierung
....67.9.1 Codegenerierung
....67.9.2 PHP_Programmierung
....67.9.3 PHP_OOP
....67.9.4 Java
....67.9.5 UDP
..67.10 DFT
..67.11 FFT
..67.12 Zustandsmaschine
..67.13 Fuzzy
....67.13.1 Fuzzylogik
....67.13.2 FuzzyRegler
....67.13.3 Uebung9
....67.13.5 Softwareentwicklung
......67.13.5.1 AgileSoftwareentwicklung
......67.13.5.2 FuzzyRegler
......67.13.5.3 Uebung
....67.13.6 Umsetzung
......67.13.6.1 FuzzyRegler
......67.13.6.2 Simulation
......67.13.6.3 Optimierung
......67.13.6.4 Uebung
....67.13.7 Haengependel
......67.13.7.1 Haengependel
......67.13.7.2 Simulation
......67.13.7.3 FuzzyRegler
......67.13.7.4 Optimierer
......67.13.7.5 Genetisch
....67.13.8 Information
....67.13.9 Energie

67.1.2 Logische Korrektheit versus Zeitliche Korrektheit

  • Neben dem Problem der Auswahl einer geeigneten Hardware-Plattform, die grundsätzlich ermöglicht einen performanten Regler zu realisieren, treten programmiertechnische Probleme auf, die weniger mit der Geschwindigkeit der Programmabläufe, sondern mehr mit der rechtzeitigen Abarbeitung bestimmter Aufgaben (Tasks) zu tun haben.
  • Es reicht nicht mehr aus, wenn die Progrogramme das richtige Ergebnis liefern, sie müssen es auch rechtzeitig liefern.
  • Drastisch zutage tritt das am Beispiel einer Nothalt-Anforderung bei einer Maschine, oder übertragen auf das tägliche Leben beim Umgang mit einer roten Ampel im Straßenverkehr.
  • Ein solches Signal muß bei dem Fahrer, bzw. bei der autonomen Maschine mit höchster Priorität behandelt werden.
  • Es reicht nicht noch die spannenden Nachrichten im Radio zuende zu hören und dann auf das Signal zu reagieren, es muß sofort reagiert werden.
  • Überhaupt richtig zu reagieren reicht nicht, es muß jetzt reagiert werden.
  • Neben das Erfordernis der Logischen Korrektheit von Programmabläufen tritt nun noch das Erfordernis der Zeitlichen Korrektheit hinzu.
Zu spät gebremst: logisch korrekt, aber nicht zeitlich korrekt.

Bild 67.1.2-1: Zu spät gebremst: logisch korrekt, aber nicht zeitlich korrekt.

Zeitliche Korrektheit bei COACH (Autonomes Vehikel)

  • Bei folgenden Prozessen, die im Mikrocontroller ablaufen, ist zeitliche Korrektheit von Bedeutung:
  • Reaktion auf externe Signale, die vom Drehgeber ausgelöst werden, um die Drehzahl zu bestimmen (externe Interrupts).
  • Zeitliches Einhalten der Busprotokolle bei der Kommunikation mit dem PC und peripheren Elektronik-Komponenten.
  • Generierung der PWM-Signale zur Ansteuerung des Antriebsmotors und des Lenk-Servos.
  • Rechtzeitiges Auswerten der Daten vom Abstandssensor, um Hindernissen rechtzeitig ausweichen zu können.
  • Einhalten von Sendepausen im automatischen Funkverkehr, um den Datenaustausch zwischen einer Reihe von autonomen Fahrzeugen und einer Station zu ermöglichen.

Das Gewährleistungsintervall

  • Natürlich gibt es für die Reaktion auf äußere Ereignisse eine zeitliche Toleranz, innerhalb der eine Reaktion auf eine Anforderung noch tolerabel ist.
  • Umgekehrt läßt sich je nach Art und Weise, wie ein bestimmter Prozeß implementiert ist angeben, innerhalb welches Zeitintervalls der Prozeß mit Sicherheit beim Eintreten eines entsprechenden äußeren Ereignisses gestartet werden kann, bzw. eine bestimmte gewünschte Reaktion liefern kann.
  • Dieses letztere Zeitintervall wird mit gewährleistungsintervall bezeichnet.
  • Das Gewährleistungsintervall muß kleiner sein, als die tolerierte Reaktionszeit.