6. Elemente eines RTOS

Transcrição

Vorlesung Real-Time Systems
3. Echtzeitbetriebssysteme
Friedhelm Stappert – Echtzeitbetriebssysteme – Real-Time Systems - SoSe 2009 – Hochschule Darmstadt
1
Übersicht
1.
2.
3.
4.
5.
6.
7.
8.
9.
Ziel dieses Kapitels
Definition
Anforderungen an ein Echtzeitbetriebssystem (RTOS)
Unterschiede RTOS – Standard-OS
Standards
Elemente eines RTOS
System Overhead
Zusammenfassung
Case Study
2
1. Ziel dieses Kapitels
Ein Echtzeitbetriebssystem (Real-Time Operating System – RTOS) hat
zunächst die gleichen Aufgaben wie ein Standard-Betriebssystem. Darüber
hinaus muss es aber spezielle Anforderungen erfüllen und spezielle Dienste
liefern, um die Echtzeitfähigkeit zu gewährleisten.
In diesem Kapitel werden die wesentlichen Unterschiede eines RTOS zu einem
Standard-OS beschrieben. Die charakteristischen Konzepte eines RTOS
werden vorgestellt.
"Sie müssen das System
neu starten, damit Ihre
Änderungen wirksam
werden"...
3
2. Definition
Definition RTOS:
Ein Echtzeitbetriebssystem oder auch RTOS (real-time operating system) ist
ein Betriebssystem mit zusätzlichen Echtzeit-Funktionen für die Einhaltung von
Zeitbedingungen und die Vorhersagbarkeit des Systemverhaltens.
Echtzeitbetriebsyssteme sind in der Regel deutlich kompakter als StandardBetriebssysteme und kommen häufig in eingebetteten Systemen zum Einsatz.
4
3. Anforderungen an ein RTOS
RTOS unterliegen anderen Anforderungen als Standardbetriebssysteme:
l
l
l
l
l
l
l
l
l
stabiler Betrieb rund um die Uhr
l u.U. jahrelang
definierte Reaktionszeiten
effizienter Prozesswechsel (geringer Prozesskontext)
Interruptbehandlung
echtzeitfähiges Scheduling
Prozesssynchronisation
l Semaphore, Mutex, etc.
echtzeitfähige Prozesskommunikation
Zeitdienste
l absolute, relative Uhren, Timeouts, Weckdienste, etc.
einfaches Speichermanagement
5
3. Anforderungen an ein RTOS
l
l
l
l
l
Unterstützung für Ein-/Ausgabe
l z.B. Zugriff auf Hardware-Register
Unterstützung für Buskommunikation
l z.B. zum Senden/Empfangen von CAN-Botschaften
Konfigurierbarkeit
l z.B. Allokierung von Speicherbereichen, Scheduling Algorithmus
Skalierbarkeit
l optionale Komponenten sollten nur bei Bedarf implementiert werden
minimaler Speicherbedarf
RTOS stehen oft in Form von Sourcecode zur Verfügung, der, abhängig von
der gegebenen Konfiguration, teilweise generiert / parametrisiert und dann
zusammen mit der Applikation übersetzt und gelinkt wird.
6
4. Unterschiede RTOS – Standard-OS
Warum kann ein Standard-OS in der Regel nicht für Echtzeitanwendungen
verwendet werden?
l Existenz von Monitor und Tastatur (Maus) werden vorausgesetzt
l bei eingebetteten Systemen meist nicht vorhanden
l Hintergrundspeicher wird vorausgesetzt
l bei eingebetteten Systemen meist nicht vorhanden
l Das System zeigt nichtdeterministisches Verhalten
l z.B. wegen Verwendung von Puffern, Fragmentierung von Dateien und
Speicher
l ungeeignete Scheduling-Strategien
l z.B. nur "Round Robin"
l „Timing“-Services ungeeignet
l zu geringe Auflösung, Schwankungen, ...
l viel zu hohe Hardware-Anforderungen (Prozessor, Speicher, ... )
l auch selten/nie benötigte Dienstprogramme und Bibliotheken immer
vorhanden
l viel zu hohe Lizenzkosten (für die hohen Stückzahlen eingebetteter Systeme)
7
4. Unterschiede RTOS – Standard-OS
Ziele eines Standard-OS:
l alle Prozesse werden (weitgehend) gleich (fair) behandelt
l der Gesamtdurchsatz des Systems wird optimiert
l weniger Prozesswechsel und lange kritische Bereiche
l blockweise Ein-/Ausgabe, Sammlung "gleicher Aufträge"
Ziele eines RTOS:
l einige Prozesse sind wichtiger als andere und haben höhere Priorität
l kritische Prozesse verdrängen weniger wichtige
l vorhersagbare Laufzeiten sind wichtiger als optimaler Gesamtdurchsatz
l kurze kritische Bereiche
l sofortige Bearbeitung anstehender Aufträge (Ein-/Ausgabe)
8
5. RTOS Standards
Es gibt kein "typisches" Echtzeitbetriebssystem, da die Anforderungen je nach
Einsatzbereich sehr unterschiedlich sind. Anders als bei PC-Betriebssystemen
haben sich bislang nicht ein oder zwei RTOS-Produkte durchgesetzt.
Es existieren einige Derivate, z.B.
l RT-Linux (http://www.rtlinux.org)
l RT-Java (kein RTOS im eigentlichen Sinne)
l Windows CE für eingebettete Systeme
Außerdem viele proprietäre Lösungen wie QNX, LynxOS, VxWorks, ...
Dazu gibt es die folgenden Standards:
l POSIX (ISO/IEC 9945-1:1996): an UNIX angelehnter Standard für
Betriebssystem-Schnittstellen mit Ergänzungen für Echtzeit.
l OSEK/VDX: „de facto“- Standard der Automobilindustrie. Zielt auf minimale
Betriebssystemkerne
l AUTOSAR: basierend auf OSEK, mit einigen Erweiterungen
9
5. RTOS Standards
POSIX = Portable Operating System Interface
wurde durch Arbeitsgruppen in der IEEE definiert und durch ANSI und ISO
standardisiert. POSIX hat seine Ursprünge in der UNIX-Welt und soll die
Portierung von (stark) betriebssystemabhängigen Programmen vereinfachen.
Der POSIX 1003.1 Standard = ISO/IEC 9945-1:1996 = ANSI/IEEE Std. 1003.1
besteht aus mehreren Teilen. Betriebssysteme unterstützen oft nur Teilmengen
des gesamten POSIX-Standards. Es besteht die Möglichkeit, ein
Betriebssystem zertifizieren zu lassen. (QNX und VxWorks sind z.B. POSIXkonform).
Bestandteile von POSIX:
asynchr./synchr. I/O, shared memory, RT signals, message queues, priority
scheduling, memory locking, semaphores, timers, ...
POSIX 1003.1 - 1990: Basisdienste eines Betriebssystems
l POSIX 1003.1b - 1993: Real-Time-Erweiterungen
l POSIX 1003.1c - 1995: Threads
l POSIX 1003.1d - 1999: weitere RT-Erweiterungen
l POSIX 1003.1j - 2000: weitere RT-Erweiterungen
l POSIX 1003.1q - 2000: Tracing, Ausführungszeitmessung, ...
l
10
5. RTOS Standards
Typisches C POSIX Interface:
typedef ... pthread_t; /* details not defined */
typedef ... pthread_attr_t;
int pthread_attr_init(pthread_attr_t *attr);
int pthread_attr_destroy(pthread_attr_t *attr);
int pthread_attr_setstacksize(..);
int pthread_attr_getstacksize(..);
int pthread_create(pthread_t *thread, const pthread_attr_t *attr,
void *(*start_routine)(void *), void *arg);
/* create thread and call the start_routine with the argument */
int pthread_join(pthread_t thread, void **value_ptr);
int pthread_exit(void *value_ptr);
/* terminate the calling thread and make the pointer value_ptr
available to any joining thread */
pthread_t pthread_self(void);
All functions return 0 if successful,
otherwise an error number
11
5. RTOS Standards
OSEK:
l "Offene Systeme und deren Schnittstellen für die Elektronik im Kraftfahrzeug"
l ist ein Gemeinschaftsprojekt der deutschen Automobilindustrie (u.a. BMW,
DaimlerChrysler, VW, Opel, Bosch, Siemens)
VDX:
l "Vehicle Distributed eXecutive"
l PSA, Renault
Der Standard ist auf Skalierbarkeit und Minimalität (8 Bit bis 32 Bit Mikroprozessen)
zugeschnitten; er besteht aus drei Teilen:
l OS: Operating System: Schnittstellen für Tasks, Scheduling, Alarme, Ereignisse,
Ressourcen, Interrupts, ...
l COM: Communication: Schnittstellen für Nachrichtenübertragung, Übertragungsmodi,
Monitoring, Message Queues, ... zwischen Prozessen und Prozessoren
l NM: Network Management standard: Verwaltung eines Netzwerkes, Modi für
Erkennung/Behandlung von Ausfällen, ...
Außerdem eine Konfigurationssprache:
l OIL = OSEK Implementation Language: für die Beschreibung der Betriebssystem- und
Prozesskonfigurationen; das Betriebssystem wird daraus generiert
12
5. RTOS Standards
Beispiel OIL File (Auszug):
CPU ExampleCPU {
OS MyOs {
...
};
TASK MyTask1 {
PRIORITY = 17;
...
};
TASK MyTask1 {
StackSize = 64;
...
};
ALARM MyAlarm1 {
ACTION = ACTIVATETASK {
TASK = MyTask1;
};
START = TRUE;
...
};
MESSAGE MyMsg1 {
ITEMTYPE = "SensorData";
...
};
ISR MyIsr1 {
RCV_MESSAGES = MyMsg1;
RCV_MESSAGES = MyMsg2;
...
};
}; // End CPU ExampleCPU
OIL Generator
(optional)
OIL Files
Application
C Code
System
Generator
OS Kernel
C Code
C Code
Compiler
Linker
OS Libraries
Object Code
Executable
13
5. RTOS Standards
Im OIL-File kann definiert werden, ob eine Task unterbrechbar ist oder nicht. OSEK
unterstützt nur statische Prioritäten.
OSEK unterscheidet 2 Klassen von Tasks:
l Basic Tasks: können sich nicht selbst blockieren
l Extended Tasks: können blockieren (mittels wait() Anweisung)
Der Standard definiert 4 Klassen von Betriebssystemen ("Basic / Extended
Conformance Classes") mit unterschiedlicher Komplexität:
l BCC1:
l nur Basic Tasks
l jede Task kann nur einmal aktiviert sein
l alle Tasks haben verschiedene Prioritäten
l BCC2: BCC1 plus:
l mehrfache Aktivierung derselben Task möglich
l gleiche Priorität für verschiedene Tasks möglich
l ECC1: BCC1 plus:
l extended Tasks, nicht mehrfach aktivierbar
l ECC2: BCC2 plus:
l extended Tasks
14
5. RTOS Standards
Der OSEK Standard ist frei verfügbar (www.osek-vdx.org), Implementierungen
sind aber kommerziell.
Es gibt auch einige Initiativen für eine freie Implementierung des Standards:
l www.openosek.org
l trampoline.rts-software.org
l opensek.sourceforge.net (FreeeOSEK)
Es existieren ebenso Ansätze für ein zeitgesteuertes Betriebssystem
(OSEK-Time), sowie eine fehlertolerante Kommunikationsschicht.
15
5. RTOS Standards
AUTOSAR = AUTomotive Open System ARchitecture ist eine Initiative von
inzwischen über 100 Firmen der Automobilindustrie zur Standardisierung der
Softwarearchitektur für Steuergeräte.
AUTOSAR definiert
– unter anderem – ein
Standard-API für ein
Betriebssystem:
AUTOSAR-OS.
16
5. RTOS Standards
AUTOSAR-OS basiert auf OSEK-OS. Applikationen, die für ein OSEK-OS
entwickelt wurden, laufen auch mit einem AUTOSAR-OS.
Darüberhinaus definiert AUTOSAR-OS einige Erweiterungen, wie z.B.:
l Schedule Tables: statisches Abarbeiten von Tasks
l OS-Applications: eine Menge von OS-Objekten (Tasks, Schedule Tables,
ISRs, ...), die eine zusammenhängende funktionale Einheit bilden, werden zu
einer OS-Application zusammengefasst. OS-Applications werden unterteilt in:
l trusted OS-Applications: uneingeschränkter Zugriff auf Speicher und
Betriebssystemdienste
l non-trusted OS-Applications: nur eingeschränkter Zugriff auf Speicher
und Betriebssystemdienste. Zeitverhalten wird überwacht.
l Memory Protection: Das OS überwacht den Zugriff auf Daten, Stack und
Code einer OS-Application. Versucht eine non-trusted OS-Application auf
Daten einer anderen OS-Application zuzugreifen, wird eine
Fehlerbehandlungsroutine ausgelöst (E_OS_PROTECTION_MEMORY).
17
5. RTOS Standards
l Timing Protection: Überwachung des Zeitverhaltens von non-trusted
Applications. Bei Verletzung einer der u.g. Zeitschranken wird eine
Fehlerbehandlungsroutine ausgelöst (E_OS_PROTECTION_TIME):
l execution time protection: stellt sicher, dass eine Task oder Kategorie 2
ISR ihre konfigurierte maximale Ausführungszeit ("Execution Budget")
nicht überschreitet.
l locking time protection: definiert die maximale Zeit ("Lock Budget"), für
die eine Task geblockt bzw. gesperrt werden darf (z.B. Warten auf Zugriff
auf Ressourcen). Unterbrechungen durch höher-priore Tasks, aufgrund
des "normalen" Scheduling, sind nicht im Lock Budget enthalten.
l inter-arrival time protection: überwacht die minimale Zeitspanne ("Time
Frame") zwischen 2 Aktivierungen einer Task. Das schützt u.A. vor sog.
"babbling idiots"; z.B. Sensoren, die aufgrund einer Fehlfunktion dauernd
Interrupts auslösen.
l Bemerkung: Mit den o.g. protection Mechanismen ist sichergestellt, dass
Deadline-Verletzungen bei Tasks erkannt werden. Eine "deadline
protection" ist somit nicht nötig.
18
5. RTOS Standards
Ähnlich wie bei OSEK-OS gibt es für AUTOSAR-OS vier verschiedene
Scalability Classes mit aufsteigender Komplexität. Protection-Mechanismen
sind z.B. nur in den höchsten Klassen verfügbar.
Die Sprache OIL wurde in AUTOSAR durch ein xml-Austauschformat abgelöst.
Der Nachfolger von OSEK-COM für die Kommunikation ist AUTOSAR-COM.
Der AUTOSAR Standard ist frei verfügbar (www.autosar.org). Wer ihn
kommerziell nutzen will, muss Mitglied im AUTOSAR Konsortium sein und
einen entsprechenden Beitrag zahlen.
Die ersten Serienfahrzeuge mit – teilweise – AUTOSAR Software gehen bereits
dieses Jahr in Produktion.
19
Einschub: Mikrocontroller
20
Timer
!
Events
Tasks
Message
Queues
Objekte
Semaphore
Interrupts
Scheduler
Mailboxes
Services
Time Management
l Interrupt Handling
l Speichermanagement
l Gerätemanagement
l ...
l
21
Der Scheduler ist verantwortlich für die Zuteilung von Rechenzeit an die
aktiven Tasks, gemäß eines Scheduling-Algorithmus.
POSIX unterstützt prioritätenbasiertes Scheduling, gemischt mit FIFO, RoundRobin, OTHER (d.h. selbst implementiert). Prioritäten können sich dynamisch
ändern.
OSEK und AUTOSAR unterstützen statische Prioritäten. AUTOSAR stellt
zusätzlich Schedule Tables zur Verfügung. Diese können mit etwas mehr
Aufwand aber auch in einem OSEK-OS implementiert werden.
22
Timer
Für ein Echtzeitsystem ist es naturgemäß essentiell, Zugriff auf die "echte" Zeit
zu haben, z.B. um:
l verstrichene Zeit zu messen,
l eine Task für einen bestimmten Zeitraum zu verzögern
l eine Task zu einem bestimmten Zeitpunkt zu aktivieren
l nach einem bestimmten Zeitraum zu reagieren, wenn ein erwartetes Ereignis
nicht eintritt
l in bestimmten Zeiträumen ein Lebenszeichen zu senden
Jedes RTOS stellt dazu Uhren und Timer Services mit unterschiedlicher
Genauigkeit und Komplexität zur Verfügung. Sie benutzen die Uhren, die i.d.R.
vom Prozessor zur Verfügung gestellt werden. Die Zeit wird dabei in Ticks, d.h.
Prozessortakte, gemessen und entsprechend der Taktfrequuenz umgerechnet.
Uhren unterscheiden sich in:
l globale Uhren für ein gesamtes Netzwerk; z.B. per GPS
l lokale Uhren. In einem Netzwerk entsteht hierbei das Problem der
Uhrensynchronisation
23
Beispiel: eine bestimmte Zeitspanne warten
start = clock();
//get current time
while (clock() - start < 31.4)
; // wait
Dieses "busy waiting" sollte allerdings vermieden werden. Meist stellt das
RTOS dazu eigene Services zur Verfügung. In POSIX z.B. sleep() und
nanosleep(). Dabei kann die entsprechende Task für den gegebenen
Zeitraum suspendiert werden.
Zusätzlich ist zu beachten, dass die tatsächlich verstrichene Zeit i.d.R. nicht
exakt gleich der für sleep() angegebenen ist, wie die folgende Graphik zeigt:
24
Time specified by
program
Granularity
difference
between
clock and
delay
Process
runnable here
but not
executable
Process
executing
Interrupts
disabled
Time
Diesen Overhead nennt man local drift. Es lässt sich zumindest vermeiden,
dass dieser Drift sich im Laufe der Zeit aufsummiert, indem man absolute
Delays verwendet:
25
Beispiel:
interval = 31.4;
next
= clock() + interval; //time of next activation
for(;;) //forever
do_something();
delay_until (next);
next = clock() + interval;
OSEK / AUTOSAR stellt hierfür z.B. Alarme zur Verfügung (SetAbsAlarm(),
SetRelAlarm(), ...).
26
Events
sind ein Mechanismus, mit dem Tasks über bestimmte Ereignisse informiert
werden können; z.B. wenn eine globale Variable aktualisiert wurde.
In OSEK gibt es dazu z.B. die folgenden APIs:
l DeclareEvent(): definiert ein Event
l WaitEvent(): warte auf ein oder mehrere Event(s); die aufrufende Task wird
suspendiert.
l SetEvent(): wecke die Task(s), die auf diese(s) Event(s) warten, wieder auf.
Events werden typischerweise in einem Event-Register verwaltet. Jedes Event
entspricht einem Bit in diesem Register. Dadurch können Events auch verknüpft
werden (durch logisches Und / Oder).
Damit eine Task nicht ewig auf ein Event wartet, sollte immer sicherheitshalber
zusätzlich ein Timeout definiert werden, z.B. mittels eines Alarms. Die Task
wartet dann bis entweder der Alarm auslöst oder das Event stattfindet. Im
ersten Fall wird eine entsprechende Fehlerbehandlung ausgeführt. Viele RTOS
Services stellen einen zusätzlichen timeout-Parameter zur Verfügung, so dass
nicht zusätzlich ein Alarm benutzt werden muss.
27
Ähnlich wie Timeouts sind Watchdog Timer eine Möglichkeit, die Inaktivität
einer Task zu bemerken. Ein Watchdog Timer muss durch eine Task immer
wieder "aufgezogen" werden. Wenn sie das nicht tut, wird eine
Fehlerbehandlung ausgelöst.
Beispiel (AUTOSAR):
/** Application: **/
for (;;)
do_something();
WdgM_UpdateAliveCounter(my_id);
/** Watchdog Manager: **/
void WdgM_MainFunction_AliveSupervision()
for each id
if AliveCounterExpired(id)
Error(id);
28
Ressourcen (Betriebsmittel)
Eine Ressource ist ein
l (angeschlossenes) Gerät oder
l gemeinsam genutzte Daten.
Unterbrechbare Ressourcen können einer Task ohne unerfreuliche
Nebenerscheinungen entzogen werden (z.B. CPU). Ununterbrechbare
Ressourcen können ihrem Besitzer nicht entzogen werden, ohne dass dessen
Ausführung fehlschlägt (z.B. CD-Brenner). Allerdings gibt es in manchen Fällen
recht einfache aber sehr spezielle Möglichkeiten den Zugriff zu regeln (z.B.
Drucker-Spooling).
In allen anderen Fällen tritt ein Problem auf, wenn mehrere Tasks auf
gemeinsam genutzte Ressourcen zugreifen, so dass es die Aufgabe des
Betriebssystems ist, dafür Schutzmechanismen zur Verfügung zu stellen.
Zur abstrakten Formulierung des Problems für den allgemeinen Fall, werden die
Teile eines Computer-Programms, in denen auf gemeinsam genutzte Daten
zugegriffen wird, kritischer Abschnitt (= Ressource) genannt.
29
Das Betriebssystem stellt primitive Operationen zur Verfügung, um
wechselseitigen Ausschluss zu erzielen. Diese sind vor dem Betreten und
nach dem Verlassen eines kritischen Abschnitts zu verwenden.
30
Semaphoren
Ein Mittel (neben anderen) zur Interprozess-Kommunikation (IPC) sind
Semaphoren [Dijkstra, 1965]. Ein (zählendes) Semaphor ist eine Integer-Variable,
die eine bestimmte Anzahl an Weckrufen (Kapazität) verwaltet, und
l deren Wert Null anzeigt, dass alle Weckrufe verbraucht sind,
l ein Wert größer Null bedeutet, dass noch Kapazität vorhanden ist.
Operationen auf Semaphoren sind:
l DOWN() (sem_wait() in POSIX) prüft, ob der Wert des
Semaphors größer als Null ist: dann wird der Wert vermindert.
Ist der Wert Null, blockiert die Task und kann später durch einen
anderen Thread per UP() wieder aktiviert werden.
l UP() (sem_post() in POSIX) inkrementiert das Semaphor und
weckt irgendeine wartende Task.
Beides sind atomare Operationen, d.h. es ist sichergestellt, dass während der
Ausführung keine andere Task auf das Semaphor zugreifen kann. Wir beschränken
uns auf eine maximale Kapazität von 1 (auch binären Semaphoren bzw. Mutexe).
31
Beispiel Semaphoren in POSIX für Konto-Buchungen:
#include <semaphore.h>
...
sem_t sem;
/* DEFINE semaphore */
int konten[100];
void buchen (int KNr, int betrag){
/* Down */
sem_wait(&sem);
int alt = konten[KNr];
int neu = alt + betrag;
konten[KNr] = neu;
/* Up */
sem_post(&sem);
}
...
main(...
sem_init(/* name */ &sem, /* shared flag */ 0, /* init value */ 1);
...
32
Interrupts
(Unterbrechungen) werden von einem Gerät ausgelöst und führen dazu, dass eine
entsprechende Interrupt-Routine (Behandlungsroutine) durch das Betriebssystem
ausgeführt wird:
l Dazu wird die CPU (falls möglich) in den Kern-Modus umgeschaltet und
während dieser Zeit werden keine weiteren Interrupts entgegen genommen.
l Die Zeit, die ein System braucht um Interrupts zu verarbeiten (d.h. die
Zeitspanne bis zum Aufruf der Behandlungsroutine), wird Interrupt Latency
genannt.
l Interrupt-Routinen haben üblicherweise eine höhere Priorität als andere
Tasks.
l In Interrupt-Routinen wird oft ein gemeinsam genutzter Puffer benutzt, um
Daten mit Tasks auszutauschen, welcher dadurch geschützt wird, dass
Ø
Ø
l
Interrupts unterbunden werden (disable), bevor auf die Daten zugegriffen wird und
Interrupts wieder erlaubt werden (enable), wenn man damit fertig ist.
Dies ist wiederum nicht anderes, als ein binäres Semaphor zu benutzen!
33
Bemerkung: In der Tat implementiert ein Betriebssystem ein Semaphor
dadurch, während der Semaphor-Operationen die Interrupts zu unterbinden.
Schlussfolgerungen:
l Interrupt-Routinen lassen sich als hoch priorisierte Task mit einer
bestimmten Periodenlänge modellieren und so in die Analyse einbringen
l Der Disable/Enable-Interupt-Mechanismus lässt sich in Blockiert-Zeiten
umsetzen.
34
In OSEK gibt es 2 Arten von Interrupt Service Routinen:
ISR Kategorie 1: Die Routine benutzt keine Betriebssystemdienste (kann also
insbesondere keine neuen Tasks aktivieren). Die unterbrochene Task wird im
Anschluss an die ISR fortgesetzt. Diese Kategorie wird für extrem hochpriore
Interrupts verwendet, die sehr schnell bearbeitet werden müssen.
l
ISR Kategorie 2: Aufrufe von Betriebssystemdiensten sind erlaubt. Im
Anschluss findet ein Rescheduling statt, d.h. der Scheduler wählt die nächste
auszuführende Task.
l
35
Synchronisation via messages
Messages ermöglichen sowohl Kommunikation als auch Synchronisation
zwischen Tasks. Kommunikation kann
l asynchron oder
l synchron
Process P1
Process P2
erfolgen.
receive message
send message
time
time
36
Asynchrone Kommunikation:
benutzt einen gemeinsamen Puffer: Mailbox oder Message Queue. Der Zugriff
auf diesen Puffer muss natürlich (z.B. durch ein Semaphor) geschützt sein.
Process P1
Process P2
send message
message
receive message
time
time
37
Synchrone Kommunikation:
oder auch Rendezvous; benötigt keinen Puffer.
Process P1
Process P2
send message
blocked
M
receive message
time
time
38
Remote Invocation:
oder auch Client/Server Kommunikation. Die Message M enthält die Parameter
des "Funktionsaufrufs". Die Antwort liefert den Rückgabewert der Funktion.
Process P1
Process P2
send message
M
receive message
blocked
reply
time
time
39
Message Queue:
Sender Tasks
Sender
...
Receiver Tasks
queue size
Sender
Receiver
...
Receiver
message size
Eine Message Queue ist charakterisiert durch:
l ihre Länge, d.h. die maximale Anzahl Nachrichten
l die maximale Größe (bzw. Datentyp) einer Nachricht
l das Verhalten, wenn die Queue voll bzw. leer ist
l voll: der Sender wird blockiert
l leer: der Receiver wird blockiert
l alternativ: bei voller Queue wird der letzte Wert überschrieben ("last-isbest Semantik"). Beim Versuch eine leere Queue zu lesen erhält der
Receiver nur einen Fehlerstatus, wird aber nicht blockiert.
40
Prinzipiell kann eine Message aus beliebigen Datentypen bestehen.
Wenn Sender und Receiver aber auf verschiedenen Prozessoren liegen, muss
der Datentyp ggf. angepasst werden.
Die Message wird vom Sender-Prozessor als Folge von Bytes verschickt (z.B.
in Form einer CAN-Message). Diese Bytefolge wird beim Empfänger wieder
entsprechend interpretiert und in den Datentyp des Empfänger-Prozessors
umgewandelt.
41
Message Queues in POSIX:
l POSIX unterstützt asynchrone message queues (mqd_t)
l Eine message queue kann mehrere sender und receiver haben
l Für Messages können Prioritäten definiert werden
l POSIX message queues haben verschiedene Attribute:
l maximale Größe (Anzahl Messages)
l Größe einer Message
l Anzahl Messages in der Queue
l verschiedene Flags, die das Verhalten steuern
l Zum Setzen und Lesen dieser Eigenschaften gibt es Attribut-Objekte (struct
mq_attr).
l Ähnlich wie Files oder Streams wird eine Queue durch mq_open, mq_close,
mq_unlink erzeugt bzw. gelöscht.
l Daten werden von/auf character buffer gelesen/geschrieben.
l Es ist nicht definiert, welcher der wartenden Sender/Receiver geweckt wird,
wenn eine Queue nicht mehr voll/leer ist.
l Ein Receiver kann sich durch ein Signal (vgl. OS Event) informieren lassen,
wenn in eine leere Queue geschrieben wurde.
42
/* Establish connection between a process and a message queue NAME and
return message queue descriptor or (mqd_t) -1 on error. */
extern mqd_t mq_open (const char *__name, int __oflag, ...);
/* Removes the association between message queue descriptor MQDES and its message
queue. */
extern int mq_close (mqd_t __mqdes);
/* Query status and attributes of message queue MQDES. */
extern int mq_getattr (mqd_t __mqdes, struct mq_attr *__mqstat);
/* Set attributes associated with message queue MQDES */
extern int mq_setattr (mqd_t __mqdes,
const struct mq_attr *__restrict __mqstat,
struct mq_attr *__restrict __omqstat);
/* Remove message queue named NAME. */
extern int mq_unlink (const char *__name);
/*Register notification issued upon message arrival to an empty message queue MQDES.*/
extern int mq_notify (mqd_t __mqdes, const struct sigevent *__notification);
/* Receive the oldest from highest priority messages in message queue MQDES.
extern ssize_t mq_receive (mqd_t __mqdes, char *__msg_ptr, size_t __msg_len,
unsigned int *__msg_prio);
*/
/* Add message pointed by MSG_PTR to message queue MQDES. */
extern int mq_send (mqd_t __mqdes, const char *__msg_ptr, size_t __msg_len,
unsigned int __msg_prio);
43
Send / Receive mit Timeouts:
/* Receive the oldest from highest priority messages in message queue
MQDES, stop waiting if ABS_TIMEOUT expires. */
extern ssize_t mq_timedreceive (mqd_t __mqdes, char *__restrict __msg_ptr,
size_t __msg_len,
unsigned int *__restrict __msg_prio,
const struct timespec *__restrict __abs_timeout);
/* Add message pointed by MSG_PTR to message queue MQDES, stop blocking
on full message queue if ABS_TIMEOUT expires. */
extern int mq_timedsend (mqd_t __mqdes, const char *__msg_ptr,
size_t __msg_len, unsigned int __msg_prio,
const struct timespec *__abs_timeout);
44
7. System Overhead
Das Betriebssystem benötigt Rechenzeit um alle Kernel-Aufgaben zu
behandeln:
l Queuing von Tasks
l Kontextwechsel
l Update interner Datenstrukturen
l Intertask Kommunikation: Senden und Empfangen von Nachrichten
l Bedienung von Interrupts
Normalerweise ist die Prozessorzeit für das OS gegenüber den anderen Tasks
vernachlässigbar.
In einigen Fällen jedoch, wenn Anwendungstasks kleine Ausführungszeiten
haben und enge Zeitbedingungen, kann die Kernel-Aktivität nicht mehr
vernachlässigt werden und signifikante Interferenzen erzeugen.
Vorhersagbarkeit kann dann nur noch durch Betrachtung des Systemoverheads
in der Schedulability Analyse erreicht werden.
45
7. System Overhead
Einer der wichtigsten Beiträge zum Systemoverhead ist die Context Switching
Zeit, z.B. für das Sichern/Wiederherstellen der Prozessor-Register, des Stacks,
etc.:
l ist intrinsische Grenze für den Kernel
l nicht abhängig vom Scheduling Algorithmus
l nicht abhängig von der Struktur der Tasks
l i.W. Hardware-abhängig
Ein weiterer wichtiger Beitrag ist die Prozessorzeit zur Behandlung der Timerund anderer Interrupts.
Diese Zeiten müssen bei der Schedulability Analyse zusätzlich berücksichtigt
werden (s. nächstes Kapitel).
46
8. Zusammenfassung
Wichtige Eigenschaften von RTOS
l Skalierbarkeit, minimaler Ressourcenverbrauch
l Vorhersagbarkeit
l Stabilität
RTOS Standards
l POSIX
l OSEK
l AUTOSAR
l proprietäre Lösungen
Elemente eines RTOS
l Tasks, Scheduler
l Timer
l Interrupts
l Events
l Message Queues
47
9. Case Study
Im Folgenden wird eine einfache Anwendung, die in C++ programmiert ist und
POSIX-Threads benutzt, vorgestellt:
l Dabei wird ein autonomes Fahrzeug simuliert, das einer Linie folgt.
l Das Fahrzeug verfügt über einen Sensor, mit dem festgestellt werden
kann, wie weit das Fahrzeug von der Linie entfernt ist.
l Der Lenkung wird dabei der Kurs (als Winkel in einem KoordinatenSystem) mitgeteilt: Ist das Fahrzeug zu weit rechts, wird der Winkel nach
links korrigiert und umgekehrt.
48
9. Case Study
Zur Erinnerung: So programmiert man in etwa einen Regelkreislauf:
void main (void){
int state1, state2,…, staten;
initializeClock();
while(1){
readSensors(…);
if (CalculateNewSetValues(…))
ActuateProcess(…);
else
Error();
WaitForNextCycle(…);
}
}
49
9. Case Study
Abstrakte Klasse Task:
class Task {
public:
Task(int);
protected:
int T; // period in ms
public:
friend void *timer_main( void * task);
friend void *execute_main( void * task);
virtual void execute() = 0;// abstract class
protected:
/* Function to block the Process until next tick */
void waitForNextCycle() {
sem_wait( &timersemaphore );
}
private:
/* Semaphore for timer */
sem_t timersemaphore;
};
50
9. Case Study
void *timer_main( void * task) {
cout << "Clock initialized!" <<endl;
while( true ) {
Task *t = (Task *) task;
usleep( t->T * 1000 );
sem_post( &(t->timersemaphore) );
}
return NULL;
}
void *execute_main( void * task) {
cout << "Start execution ...." <<endl;
Task *t = (Task *) task;
t->execute();
return NULL;
}
// Construktor starts threads:
Task::Task(int t=1000): T(t) {
sem_init( &timersemaphore, 0, 0 );
pthread_t timerthread;
pthread_t executethread;
pthread_create( &timerthread, NULL, &timer_main, (void *) this );
pthread_create( &executethread, NULL, &execute_main, (void *) this );
};
51
9. Case Study
Fahrzeug auf dem Bildschirm anzeigen:
class Display : public Task {
public:
Display(int T): Task(T) {};
void execute();
};
void Display::execute() {
cout << "... Display::execute T=" << T << endl;
sem_post(& mutex); // don't start without me!
while( true )
{
// critical region:
sem_wait(& mutex);
p.display("P= ");
cout << "Abstand =" << (int) Abstand(p, Ldir) << endl << endl;
sem_post(& mutex);
waitForNextCycle();
}
}
52
9. Case Study
Fahrzeug bewegen:
class Fahren : public Task {
public:
Fahren(int T, int v, int d): Task(T), V(v), D(d) {};
void execute();
private:
int V; // speed
int D; // direction
};
void Fahren::execute() {
while( true ) {
// simulate moving the vehicle:
sem_wait(& mutex); // enter critical region
// compute distance travelled during period
double realV = (T * V) / 1000.0;
p.move(realV, D);
sem_post(& mutex); // end critical region
// calculateNewSetValue() and actuateProcess():
int entf = Abstand(p, Ldir);
const int deltha = 1;
if (entf > 0)
D += deltha;
else if (entf < 0)
D -= deltha;
waitForNextCycle();
}
}
53
9. Case Study
Hauptprogramm:
int main( int argc, char *argv[] )
{
InitAll(45); // direction of line [0, 90]
sleep(1);
Display D(...);
cout << "Los geht's!!" << endl;
Fahren F(/* period in ms */ ,
/* speed in pixels per second */ ,
/* start direction [0, 90] */ 0 );
// sleep forever:
sem_t block;
sem_init( &block, 0, 0 );
sem_wait( &block );
return EXIT_SUCCESS;
}
54
9. Case Study
Aufgaben:
l Ermitteln Sie sinnvolle Werte für die Perioden der beiden Tasks
l Bestimmen Sie ein Task-Modell (Prioritäten, Blockierungen, etc.)
l Überlegen Sie sich sinnvolle Erweiterungsmöglichkeiten
55

6. Elemente eines RTOS

Transcrição

Documentos relacionados

Eröffnung Heinerfest 2015 Darmstadt

Ad-hoc-Betreuung an der Waldspirale in Darmstadt

Übersicht der 10 relevanten Realtime Betriebssysteme

3 66 88 99 Centralstation/Im Carree/Darmstadt

Das offizielle Voxamps Forum des deutschen Vertriebes

Eisenbahnmuseum Darmstadt Kranichstein Vernissage am

Anfahrt Darmstadt

das Original PDF - Orplid

DARMSTADT LEONHART OPEN

6. Design von Echtzeitsystemen