Giotto: A Time-Triggered Language

Tu Tran Ngoc

4300219

tran.tu@fu-berlin.de

July 6, 2013

Abstract

In dieser Arbeit geht es um die zeitgesteuerte Programmiersprache und gleich Com-

piler Giotto, deren Funktionalitäten und Entwicklungskonzepte anhand des vorgegebenen

Papiers ausgearbeitet werden sollen. Giotto wird bei strikt synchronen Systemen eingesetzt,

wobei streng geplante Zeitabläufe jeder einzelnen Funktionsaufgabe Zuverlässigkeit eines Sys-

tems verantwortlich sind. Eine reibungslose Zusammenarbeit zwischen dem Steuerungstech-

niker und dem Softwaretechniker ist eine wichtige Voraussetzung, dass ein Giotto Programm

fehlerfrei funktionieren kann. Die Funktionsweise von einem Giotto-Programm sowie Giotto-

Compiler wird anhand eines Hubschraubersystems veranschaulicht.

Contents

1 Einleitung 2

2 Informelle Notationen 3

3 Syntax 5

4 Operationelle Semantiken 6

5 Annotation 7

6 Praxis 8

6.1 Giotto in einem selbst gesteuerten Hubschraubersystem . . . . . . . . . . . . . . . 86.1.1 Autopilot-Softwarestruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . 96.1.2 Das Giotto-Model von dem Autopilotsoftware in Simulink . . . . . . . . . . 106.1.3 Giotto-Modelle in Simulink . . . . . . . . . . . . . . . . . . . . . . . . . . . 116.1.4 Giotto-Modelle in Giotto-Programme . . . . . . . . . . . . . . . . . . . . . 116.1.5 Das Giotto-Programm für die Autopilot-Software . . . . . . . . . . . . . . . 116.1.6 Der Giotto-Compiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

7 Zusammenfassung 15

References 15

1

1 EINLEITUNG 2

1 Einleitung

Heutzutage werden Systeme entwickelt, die unter strikt zeitlichen Bedingungen reibungslose Abläufeliefern sollen. Solche Systeme werden auch als reaktive Echtzeitsysteme genannt. Das Ziel dabeiist, möglichst keinen Fehler zu verursachen und groÿe Komplikationen bei der Programmentwick-lung zu vermeiden.Und genau wurde Giotto für solche Echtzeitsysteme entworfen, damit garantierte Reaktionen instrenger Zeitbeschränkungen gewährleistet werden können. Giotto dient als Programmierspracheund auch zugleich ein Compiler für eingebettetes Programmieren. Sie dient bei der abstraktenProgrammierung zur Verwaltung der Programmabläufe, bei denen es sich um Zeitperioden undverschiedene Verhalten der Programmzustände handelt. In eingebetteten Systemen wird dieserSoftwareentwurf eingesetzt um Fehler bei der Ausführung in Programmmodulen vermeiden zukönnen. Die Abläufe bei solchen Programmen sind zeitlich strikt eingeplant. Ein kleiner Fehleroder eine nicht in der Zeit zu spät zurückgegebenes Ergebnis kann zu einem Systemausfall oderfehlerhafter Kettenreaktion führen. Echtzeitsysteme dienen als Grundkonzept in Anwendungs-bereichen wie Automobil, Raumfahrt oder Fertigungskontrolle .

In Figure1.1 wird gezeigt, dass das eingebettete System zuerst von dem Steuerungstechnikermodelliert wird. Dabei werden Steuerungsregeln bearbeitet und optimiert. Die Funktionalitätund die Leistung des Models werden durch Simulation und Analyse überprüft. Dann einigen sichSteuerungs- und Softwaretechniker auf die Funktionalität und Zeitplanung des Systems. Dem-nächst überträgt der Giotto-Compiler das Giotto-Programm der vorgegebenen Hardwarekon�gu-ration ab. Die Giotto Runtime Library ist dafür zuständig, dass das Programm auf der vorgegebe-nen Plattform ausführbar sein kann.

Figure 1.1: [5] Eingebettete Systementwicklung mit Giotto

Durch diese klare Einteilung des Entwicklungsablaufs wird es deutlich, dass ein Giotto-Programmunabhängig von der Plattform ist, wo es eingesetzt werden soll. Typische Aktivitäten vomSteuerungstechniker sind:

2 INFORMELLE NOTATIONEN 3

• Modellierung der geplanten Verhalten, Störungen, Modi�zierungen und Optimierungen vonSteuerungsregeln, und Validierung von Funktionalität und Leistung des Models durch Anal-yse und Simulation

� Zerlegen der nötigen Ausführungsaktivitäten in zyklische/wiederholbare Aufgaben undBeauftragen dieser Aufgaben zu CPUs, und Setzen der Prioritäten für die verlangtestrenge Echtzeit-Beschränkungen.

• Verwaltung von einer zwischenliegenden Abstraktionslevel, welche dem Softwaretechnikere�ektivere Kommunikation zu dem Steuerungstechniker

� Giotto abstrahiert die Durchführung der Softwarearchitektur auf eine spezielle Plat-tform und befreie ihn von den Sorgen über Probleme wie Hardwareleistung und Ablaufmech-anismus während des Kommunizierens mit dem Steuerungstechniker

2 Informelle Notationen

Hier werden einzelne Komponenten von einem Giotto-Programm beschrieben. Es sind Ports,Task, Task-Invocations, Modes und Mode-Switches.

Ports

Ports empfangen und senden alle Daten. Ein Port ist eine globale Variable in einem gemein-samen Namensraum mit einem eindeutigen Ort. Jeder Port ist persistent von Zeit zu Zeit, biser aktualisiert wird. In einem Mode kann ein Task-Port nicht benutzt werden. Die in dem Modeverwendeten Ports werden Mode-Ports genannt. Jeder Mode-Port wird initialisiert, wenn dasMode eingetreten wird.

Figure 2.1: [4]Eine Task

Tasks

Eine Task enthält eine Menge Input und eine Menge Output Ports (Abb. 2.1). Alle Input Portsvon einer Task unterscheiden sich von allen Ports in einem Giotto-Programm. Die Output Portskönnen gemeinsam mit den anderen verwendet werden, solange sie nicht in demselben Modeaufgerufen werden. Im Allgemein kann eine Task beliebig viele Input und Output Ports haben.Eine Task beinhaltet einen Zustand, was als eine Menge von privaten Ports betrachtet werdenkann, und dessen Inhalt nicht von auÿen zugegri�en werden kann. Jede Task hat eine Funktion,die seine Input Werte und den aktuellen Zustand zu Output und nächsten Zustand berechnet.Die Funktion kann in einer beliebigen Programmiersprache geschrieben werden. Die Ausführungdieser Funktion hat keine Synchronisationspunkte und kann nicht frühzeitig terminiert werden. InGiotto ist die Synchronisation nur auÿerhalb von Tasks. Für Giotto Programm soll die worst-caseAusführungsdauer von der Funktion bei dem jenigen CPU.

2 INFORMELLE NOTATIONEN 4

Task-Invocations

Tasks in Giotto werden pünktlich periodisch aufgerufen. Wenn die Task t aufgerufen wird, dannsind die output ports von t die mode ports von m. der task Aufruf hat eine Häu�gkeit ωtask. DieEchtzeit-Häu�gkeit wird später bestimmt, wobei die Echt-Zeit-Periode von dem aktuellen Modus(von ωtask) geteilt wird.

Figure 2.2: [4] Task invocation

Der Task Aufruf spezi�ziert den Treiber (driver) d (Abb 2.2), welches die Werte für die Input-Ports beinhaltet. Im Allgemein ist ein Treiber eine Funktion, die die Werte von Sensor Ports undMode-Ports von dem aktuellen Modus zu Werten für die Input-Ports konvertiert oder Konstanteübergibt. Treiber können überwacht werden. Der Treiberwächter ist ein Prädikat an den Sensor-und Mode-Ports. Eine Task kann ausgeführt werden, wenn der Wächter true zurückgibt. DieGiotto Semantik schreibt vor, dass die Kommunikationsphase zwischen Ports keine Zeiteinheitkostet. Die synchrone Kommunikationsphase wird von der geplanten Kommunikationsphase ver-folgt.Nachdem die Funktion f in t ausgeführt ist, werden der Zustand und die output ports aktual-isiert. Es wird während der Ausführung der Task t nicht von Giotto beschrieben, wann, wo undwie f berechnet. Die Werte an output ports werden nach der angegeben Zeit bestimmt. SofortigeKommunikation, zeit- und wertdeterministische Berechnung sind drei wesentliche Bestanteile dervon Giotto logischen Beschreibungen.

Modes

Ein Giotto Programm enthält eine Menge von Modes. Ein Mode besteht aus eine Zeitperiode,mode ports, taks invocations, actuator updates und mode switches.Die Abb. 2.3 zeigt, dass ein Mode m Aufrufe von zwei Tasks t1 und t2 enthält. die Periode dauert10 ms. Es gibt den Sensorport s, einen Auslöserport a und ein Mode-Port o1, der nicht von jedertask aktualisiert wird. Der Aufruf von t1 hat den Treiber d1, der den Wert von o1 in i1 undo4kopiert. Der Aufruf von t2 hat eine Häu�gkeit ω2 = 2. Das bedeutet, dass t2 einmal jede 5 msaufgerufen wird, solange das Programm in dem Mode m ist. Der Treiber d2 verbindet o3 zu i3, szu i4 und o5 zu i5. Der Mode m hat ein Auslöser-Update, wobei der Treiber d3 den Wert von o2zu dem Auslöserport a kopiert.

3 SYNTAX 5

Figure 2.3: [4] Ein Mode

Modes-switches

Ein Mode kann Mode-Switches haben, die Übergänge zwischen modes beschreiben. Ein modeswitch kann tasks entfernen oder hinzufügen. Es bestimmt eine Wechselhäu�gkeit, ein Ziel-Modeund einen Treiber. Mode-Switches verursachen keine extra Zeit wie bei den Treibern.Die Abb. 2.4 zeigt einen Mode-Switch η von m zu m' mit der Wechselhäu�gkeit ωswitch = 2 unddem Treiber d5. Der Treiberwächter wird als Ausgangskondition genannt. Er legt fest, ob einMode-Wechsel erlaubt wird. Die Wechselhäu�gkeit von 2 bedeutet, dass die Ausgangskonditionvon d5 je 5ms evaluiert wird. Die Kondition ist ein Wahrheitswert an den Sensorports und Mode-Ports von m. Wie alle Treiber werden Mode-Switches logischerweise synchron durchgeführt.

Figure 2.4: [4] Ein Mode-Switch

3 Syntax

Ein Giotto-Programm besteht aus folgenden Komponenten:

4 OPERATIONELLE SEMANTIKEN 6

Port

Eine Port-Deklaration (p, Type, init) besteht aus einem Port-Namen p, einem Typ Type und einemInitial-Wert init. Es gibt 5 Arten von Ports SensePorts (Sensor-Ports), ActPorts (Actuator-Ports),InPorts (Task-Input-Ports), OutPorts (Task-Output-Ports) und PrivPorts (private Task-Ports).Einem Port p ∈ P in Type[p] wird eine Menge von Werten Vals[p] zugewiesen.

Task

Eine Task-Deklaration (t, In, Out, Priv, f) besteht aus dem Task-Namen t, einer Menge InputPorts In, einer Menge Output Ports Out, einer Menge von privaten Ports Priv und einer Funktionf : V als[In ∪ Priv]→ V als[Out ∪ Priv].

Driver

Eine Driver-Deklaration (d, Src, g, Dst, h) besteht aus einem Driver-Namen, einer Menge vonQuellen-Ports Src, einer Menge von Ziel-Ports Dst, einer Wächterfunktion g: V als[Src]→ B, diedas Zugri�srecht des Driver überprüft, und einer Funktion h:V als[Src] → V als[Dst], die Wertemit dem Erlaubnis des Wächters h transportiert.

Mode

Eine Mode-Deklaration (m,π,ModePorts,Invokes,Updates,Switches) besteht aus einem Namen m,einer Zeitperiode π, einer Menge von Mode-Ports ModePorts ⊆ OutPorts, einer Menge vonTask-Invocations Invokes. einer Menge von Actuator-Updates Updates und einer Menge vonMode-Switches Swiches. Es wird ein start mode ∈ Modes de�niert, was auch ein Bestandteileines Giotto-Programms ist.

4 Operationelle Semantiken

Die Kon�guration eines Programms C = (τ,m,u, v, σactive) besteht aus einem Zeitstempel τ , einemMode m, einem Einheitszähler u, einer Wertermittlung v für alle Ein- und Ausgänge und einerMenge von aktiven Aufgaben σactive. Eine Kon�guration C wird grundsätzlich wie folgt ausge-führt, zuerst werden einige tasks erledigt, danach werden die actuators aktualisiert, dann kannein mode switch durchgeführt werden und schlieÿlich können einige tasks zum Laufen gebrachtwerden. Die Csuccist dann die Folgekon�guration von C, nur wenn dann die folgenden Schrittevon einem Giotto Programm ausgeführt werden, solange es aufgerufen wird. Am Anfang werdendie Variablen τ = 0, u = 0und σactive initialisiert:

1. Task-Ausgänge und private Ports. Es gibt eine Menge σcompleted von den Aufgaben t, sodass ein Aufgabenaufruf von der Form (., t, .) ∈ Invokes[M ] bei der Kon�guration C mitp ∈ OutPorts∪PrivPorts vollendet wird. vtask(p) = f[t](C[In[t] ∪ Priv[t]])(p) wird de�niert,wenn p ∈ Out[t] ∪ Priv[t], andernfalls vtask(p) = v(p). Dadurch werden neue Werte für alleTask-Ouput und private Ports gegeben. vtaskstimmt mit Ctasküberein, wennOutPorts ∪ PrivPorts,sonst mit C.

2. Actuator-Ports. p ∈ ActPorts.Wenn p ∈ Dst[p] für einige Auslöser-Updates (.,d) ∈ Updates[m]sind, die bei Ctask verfügbar sind, dann wird vact(p) = h[d](Ctask[Src[d]])(p) de�niert, sonstvact(p) = v(p). Dadurch entstehen neue Daten von allen Auslöserports.vact soll dann aufActPorts mit Cact übereinstimmt werden, sonst bleibt es bei Ctask.

5 ANNOTATION 7

3. Sensor-Ports. Betrachtep ∈ SensePorts. vsense(p) ist irgendein Wert in Type[p], weil sichSensorports nichtfestlegend ändern. Csense stimmt mit vact auf SensePorts überein, sonstmitCsense.

4. Target-Mode. Wenn (.,mtarget, .) ∈ Switches[m] auf Csense verfügbar ist, dann wird m′=

mtarget de�niert, sonst m′= m. Es wird festgelegt, wenn da ein Mode-Switch ist. Ctarget

kann mit m′übereinstimmen, sonst mit Csense.

5. Mode-Ports. Betrachte p ∈ OutPorts. Wenn p ∈ Dst[p]für einige Mode-Switches (., .,d) ∈ Switches[m],die auf Csense verfügbar sind, dann wird vmode(p) = h[d](Ctarget[Src[d]])(p) de�niert, sonstvmode(p) = Ctarget[OutPorts](p). Es werden neue Daten von den Mode-Ports in dem Target-Mode gegeben. Wenn t beendet ist, werden alle Output-Ports wieder aktualisiert. vmode

kann mit Cmode auf den OutPorts-Daten übereinstimmen, sonst mit Ctarget.

6. Unit-Zähler. Wenn kein Mode-Switch in Switches[m] auf Csense verfügbar ist, dann wird u′ =(u+1) mod ωmax[m] de�niert, sonst wird es vorausgesetzt, dass ein Mode-Switch auf Csense

zu dem Target-Mode m′ existiert. De�niere σrunning = σactive \ σcompleted. Wennσrunning =φ, dann de�nere u′ = 1, sonst soll ucompleted die kleinste gemeinsame Vielfache von derMenge {ωmax[m]/ωtask|(ωtask.,t,.) ∈ Invokes[m] für t ∈ σrunning} sein. Sie ist auch die kle-inste Einheitsanzahl in m, wo alle ausführende Tasks gleichzeitig beenden. Sei uactualdas kleinste Vielfache von ucompleted, sodass uactual ≥ u. Sie ist die erste Einheitsan-zahl nach u. Sei δ = (π[m]/ωmax[m]).(uactual − u). δ ist die Dauer bis zum Ende. Seiutogo = (ωmax[m

′]/π[m′]).δ. utogo ist die Anzahl von Einheiten von dem Target-Mode m'bis zu dem nächsten gleichzeitigen Abschluss. De�niere u′ = (1− utogo)modωmax[m

′]. u'ist Einheitsanzahl in m' mit utogo − 1 Einheiten zu laufen bis zu dem letzten gleichzeitigenAbschluss in m'. Sei Cunit einig mit u', sonst mit Cmode.

7. Task-Input-Ports. Betrachte p ∈ InPorts. Wenn p ∈ Dst[d] für Task-Aufrufe (., .,d) ∈Invokes[m′],die auf Cunit verfügbar sind, dann de�niere vinput(p) =h[d](Cunit[Src[d]])(p), sonst vinput(p) =v(p). So werden die neuen Daten von allen Task-Input-Ports gegeben. Sei Cinput einig mitvinput auf den Daten von InPorts, sonst mit Cunit.

8. Aktive Tasks. Sei σenabled die Menge von Tasks (., t, .) ∈ Invokes(m′), die auf Cinput verfüg-bar sind. Die neue Menge von den aktiven Tasks ist σ′

active = (σactive \ σcompleted) ∪ σenabled

. Sei Cactive einig mit σ′active, sonst mitCinput.

9. Zeitstempel. Der Moment, wo das Giotto-Programm aufgerufen wird, ist τ ′ = τ + π[m′]/ωmax[m′].

Eine Menge von Zeit-Interrupt zu τ ′ kann beim Durchführen verwendet werden. Sei τ ′ einigmit Csucc, sonst mit Cactive.

Die Ausführung von einem Giotto-Programm ist eine unendliche Folge von Kon�gurationen C0,C1,C2, ....,sodass C0 = (0, start, 0, v, φ) mit v(p) = init[p] für p ∈ Ports und Ci+1 ist die Folgekon�gurationvon Ci für alle i ≥ 0.

5 Annotation

Die Giotto-Annotation ist eine Erweiterung von Giotto. Ein Giotto-Programm kann zu Engpässengeführt werden, wenn es auf einem Single-CPU läuft, obwohl ein normal starker Single-CPU theo-retisch dafür ausreichen wird. Die Gründe für solche technische Engpässe sind, dass die zeitlichenAnforderungen von einem Programm auf einem Single-CPU vielleicht archivierbar sein können.Dazu könnte eine besondere Anwendung seine Tasks auf speziellen Plätzen lokalisieren, z.B. in der

6 PRAXIS 8

Nähe von den physikalischen Prozessen, die die Tasks steuern, oder auf Prozessoren, die beson-ders geeignet für die Operationen von Tasks sind. Hier wird es deutlich, dass um Fehler möglichstzu vermeiden werden weitere getrennte CPUs benötigt, damit die Arbeit zwischen den CPUsverteilt wird. Dafür ist die Annotation mit Plattformeinschränkungen da, um die Übersetzungdes Programms zwischen den CPUs zu unterstützen. Die Giotto-Annotation besteht aus mehrerenAnnotationsstufen. Dadurch entstehen eine modulare Architektur für den Giotto-Compiler undErstellen von formalen Modellen auf allen Annotationsstufen. Diese Modelle können für die Kon-sistenz bei den höheren Annotationsstufen und bei der reinen Giotto-Semantik überprüft werden.Eine Hardware-Kon�guration besteht aus Hosts und Netzwerken. Ein Host ist ein CPU, derGiotto-Tasks ausführen kann. Ein Netzwerk verbindet Hosts und kann Werte transportieren.Annotation-Giotto besteht aus drei folgenden Annotationsstufen:

Giotto-H (H steht für �Hardware�) beschreibt eine Menge von Hosts, eine Menge von Netzwerkenund die Information über Ausführungszeit im schlechtesten Fall. Diese Information beinhaltet dieAusführungszeit für Tasks auf den Hosts und Transferzeit für Verbindungen auf den Netzwerken.

Giotto-HM (M steht für �map�) beschreibt eine Zuweisung der Task-Aufrufe zu Hosts und derVerbindungen zu Netzwerken. Ein Task-Aufruf in verschiedenen Modes kann zu verschiedenenHosts zugewiesen werden. Der physikalische Ort von den Task-Output-Ports wird bei dem Map-ping eines Task-Aufrufs festgelegt.

Giotto-HMS (S steht für �schedule�) beschreibt die Information über den Zeitplan für jeden Hostund Netzwerk.

Wenn alle Zuweisungen an den Annotationsstufen festgelegt werden, dann wird eine Annota-tion als vollständig bezeichnet, sonst unvollständig. Wenn ein Giotto-Programm keiner einzigenAusführung der Tasks erlaubt, obwohl sie mit den Annotationen übereinstimmt, dann ist diesesProgramm zu stark eingeschränkt. Ein Giotto-Programm darf nicht zu stark eingeschränkt seinund muss mit der Semantik des reinen Giotto-Programms übereinstimmen. Der Giotto-Compilerproduziert ein Giotto-Programm, solange es gültig ist, in einen ausführbaren Code. Ein Compilerkann fehlende HMS-Annotationen anhand der Planbarkeitsanalyse für verteiltes Echtzeitsystemherstellen.

6 Praxis

6.1 Giotto in einem selbst gesteuerten Hubschraubersystem

[1] Um die Funktionalität von Giotto im Praxis zu veranschaulichen, wird hier ein Giotto-basiertesHelikoptersystem vorgestellt, das von Schweizer Bundesinstitut von Technologie (ETH) in Zürichentwickelt wurde. Figure 6.1 zeigt ein Autopilot-Modelhubschrauber mit einem Steuerungssys-tem in dem darunter hängenden Aluminiumkasten. Figure 6.2 zeigt die Hardwarestruktur diesesSteuerungssystems. Die verwendeten Sensoren in dem Helikoptersystem sind ein GPS-Empfänger,ein Kompass, ein Revolutionssensor, ein Laserhöhenmesser, drei Beschleunigungsmesser, ein Gy-roskop und ein Temperatursensor.

6 PRAXIS 9

Figure 6.1: [1]Das Autopilot-Modelhubschrauber

Figure 6.2: [1] Hardwarestruktur des Steuerungssystems

6.1.1 Autopilot-Softwarestruktur

[1] Die Autopilot-Software hat sechs verschiedene Betriebsmodi, nämlich Init, Idle, Motor,TakeO�,ControlO� und ControlOn. In jedem Modus sind verschiedene Tasks aktiv. Die ersten drei Modiwerden gebraucht, um Startabläufe korrekt durchzuführen. Der Motor-Modus ist zuständig fürden Geschwindigkeitsübergang von dem Rotor von 0 rpm zu einer sicheren Geschwindigkeit von300 rpm. Bei einem Befehl von der Bodenstation kann der Übergang zu dem TakeO�-Modusversetzt werden. Wenn der Startablauf beendet ist, dann ist der Hubschrauber im ControlO�-Modus. In diesem Modus hat der Pilot die volle Kontrolle über die Rotor�ügel. da kann der Pilotzu jeder Zeit zu dem ControlOn-Modus umschalten, um Autopilot zu aktivieren. Die AdFilter-

6 PRAXIS 10

Figure 6.3: [1] Betriebmodi von der Hubschraubersteuerung

Figure 6.4: [1] Das Helikoptermodel in Simulink

Task entschlüsselt und bereitet Sensorwerte auf. Anhand der Daten von der Ad�lter-Task behältdie NavPilot-Task die Positionsspur und Geschwindigkeit von dem Hubschrauber und sendet demPilot Befehle zu den Servos.

6.1.2 Das Giotto-Model von dem Autopilotsoftware in Simulink

[1] Figure 6.4 zeigt die Simulink-Spezi�kation von einem Giotto-Model names Helicopter Con-troller, welches ständig in Verbidung mit dem Helicopter Dynamics ist. Der Dynamikblock en-thält nur normal zeitdurchgehende Simulink-Blöcke. der Kontrollerblock ist sogenannter Giotto-Model-Block. Die Abb. 6.5 zeigt die Inhalte von dem Helikopter-Block. Der AdFilter-blockist ein Giotto-Task-Block, der als eine einfache Giotto-Task dargestellt wird. Dieser Block ist fürEntschlüsseln und Aufbereiten von Sensordaten zuständig. Der andere Block in dem Giotto-Modelist ein Giotto-Case-Block, der mehrere Tasks enthalten kann. Als Beispiel entählt dieser Blockzwei Task-Blöcke NavPilot und NavControl. NavPilot berechnet die Hubschrauberposition unddie Geschwindigkeit und liest die Pilotbefehle ein. NavControl führt Autonom�ug aus. Sie erstelltdie Servodaten. Jedem Giotto-Case-Block wird eine bestimmte Häu�gkeit zugewiesen. In diesemBeispiel hat der Block eine Häu�gkeit von 1 und wird innerhalb von 25 ms aufgerufen. Abb. 8zeigt die Inhalte von dem Case-Block. Da ist ein Giotto-Switch-Block namens isControlO�/Onauÿer den beiden bekannten Blöcken. Ein Switch-Block kann zeitdiskrete Simulink-Blöcke enthal-ten, um eine von den Tasks auszuführen. Wenn keine Task gewählt ist, dann werden die vorherigenOutput-Daten genommen. der isControlO�/On-Block hat die Aufgabe Pilotbefehle einzulesen,um von manuellen in autonomen Modus und umgekehrt umzuschalten. Dementsprechend wirdzischen der NavPilot- und NavControl-Task gewählt. Der Switch-Block wird einmal bei jedemAufruf evalutiert. Der Block OutputPort ist zuständig für das Multiplexing von zwei Tasks zueinem Output.

6 PRAXIS 11

Figure 6.5: [1] Der Giotto-Helikoptersteuer in Simulink

Figure 6.6: [1] Giotto-Case-Block

6.1.3 Giotto-Modelle in Simulink

[1] Es wurde der S/G-Simulator für die Umsetzung der Giotto-Semantik entwickelt, um Giotto-Modelle in Simulink simulieren zu können. In der Praxis liest der S/G-Simulator eine Simulink-Spezi�kation von einem Giotto-Model ein und wandelt sie zeitdiskretes Simulink-Model, wobeidie Giotto-Semantik in Simulink erzeugt wird.

6.1.4 Giotto-Modelle in Giotto-Programme

[1] Der S/G-Umsetzer wandelt den Giotto-Model-Block in ein passendes Giotto-Programm um,das als Textform dargestellt wird. Dieses Programm wird dann von dem Giotto-Übersetzer fürdie Planbarkeitsanalyse und zum Erzeugen von Code für den zeitlichen Ablauf ausgeführt.

6.1.5 Das Giotto-Programm für die Autopilot-Software

Das folgende Beispiel (Abb. 6.7) wird das Giotto-ProgrammHelicopter-Controller veranschaulicht,das die Modi ControlO� und ControlOn von dem Steuerungssystem festlegt. Die Periode von

6 PRAXIS 12

den beiden Modi beträgt 25 ms. Die Ausführungshäu�gkeiten von den Task-Aufrufen, Actuator-Updates und Mode-Switches werden verhältnismäÿig zu dieser Periode durch die Variablen task-freq, actfreq und exitfreq festgelegt. Z.B. die ADFilter-Task wird fünft Mal je 25/5 ms ausgeführt.

Figure 6.7: [1] Zwei Modi: ControlO� und ControlOn

Die Abb. 6.8 zeigt die logische Ausführung von einer einmaligen Hyper-Periode in demControlOn-Modus. Die logische Ausführung erfüllt die FLET-Annahme: Die ADFilter-Taskwird genau fünf Mal je 5 ms ausgeführt, wobei die NavControl-Task genau einmal für 25 msparallel durchläuft. FLET (�xed logical execution time) ist die Schlüsseleigenschaft von derGiotto-Semantik-Annahme, welche bedeutet, dass die Ausführungszeiten in Verbindung mit allenBerechnungs- und Kommunikationsaktivitäten fest sind und von dem Modell, und nicht von derPlattform bestimmt werden.

6 PRAXIS 13

Figure 6.8: [1] Die logische Ausführung im ControlOn-Modus

In einem Giotto-Programm werden die Sensoren wie in der Abb. 6.9 global de�niert. Auÿereinem Typnamen wird ein Giotto-Gerättreiber für jeden Sensorport de�niert. Z.B. der Sensorportgps hat den Typ GPSPort und benutzt den Treiber GPSGet, um neue Sensordaten von demGPS-Gerät zu erhalten. In der Abb. 6.9 werden gleich am Anfang die letzten Sensordaten füralle Giotto-Sensor-Ports bei dem Aufrufen von Giotto-Gerät-Treibern eingelesen.

Figure 6.9: [1] Deklaration von Sensoren

Die Abb. 6.10 zeigt die Deklaration von dem Modustreiber SwitchO�. Dieser Treiber wirdunmittelbar nach der Ausführung von den Gerätstreibern für die Sensor-Ports aufgerufen. Erbestimmt, ob es in den ControlO�-Modus gewechselt oder nicht. Die Input-Variable stopswitchwurde von dessen Gerättreiber StopSwitchGet durch die Transaktion von der ferngesteuertenSteuerung übergeben.

6 PRAXIS 14

Figure 6.11: [1] deklaration: output, task, actuator und driver

Figure 6.10: [1] Deklaration von dem Modustreiber SwitchO�

In der Abb. 6.11 werden alle Task-Output-Ports global de�niert. Der Port �lter ist der einzigeOutput-Port von der Task ADFilter. Die Ports control und data sind von NavControl. Die TaskADFilter liest von den the accelerometers, gyroscopes, temperature und �lter Ports ein. Der Task-Output-Port �lter eine Zustandsvariable von der Task. Die Prozedur ADFilterImplementationimplementiert die Funktionalität von der Task ADFilter. Die Deklaration von NavControl ist ana-log zu ADFilter. Bei dem Stellantrieb-Port servos wird der Gerättreiber ServoPut benutzt, umneue Daten zu den Helikopter-Servos zu übertragen. Typen und Gerättreiber werden auÿerhalbvon Giotto implementiert. In der Abb. 6.8 in dem 25-ms-Moment werden servos und datapoolaktualisiert, wenn die Oberon ServoUpdateImplementation und DataPoolUpdateImplementationerstmals ausgeführt wird. Die Daten werden von control und data zu servos und datapool trans-portiert.

7 ZUSAMMENFASSUNG 15

6.1.6 Der Giotto-Compiler

Die Aufgabe von dem Giotto-Compiler ist, den Ablaufsplan-Code zu produzieren, der mit derFLET-Annahme übereinstimmt. Der Code muss zeitsicher auf der gewählten Plattform sein.Wenn er zeitsicher ist, dann entspricht das Ausführungsverhalten dem S/G-Simulationsverhaltenvon dem eigentlichen Giotto-Modell. Der Compiler überprüft die Zeitsicherheit von dem pro-duzierten Code durch eine Planbarkeitsanalyse bei gegebenen worst-case Ausführungszeiten. Umein Giotto-Steuerungssystem auf einer neuen Plattform auszuführen, sind folgende Schritte nötig:

1. Für Verknüpfung der neuen Hardware, Bereitstellen der C-Programme, die die Giotto-Gerät-Treiber realisieren.

2. Übersetze die C-Programme nochmal für die neue Plattform.

3. Neue Überprüfung für die Zeitsicherheit.

4. Durchführung der eingebetteten Maschine auf der neuen Plattform

7 Zusammenfassung

Giotto ist eine domain-spezi�sche und hochstu�ge Programmiersprache. Sie ist domain-spezi�sch,weil sie eingebettete Steuerungsanwendungen thematisiert. Sie ist hochstu�g, weil sie plattformab-hängige Implementationsdetails abstrahiert. Giotto erhöht die Transparenz von Steuerungssoft-ware und automatisiert Planung und Optimierung durch Zusammenstellungen. Giotto-basierteSteuerungssysteme pro�tieren von der doppelten Aufteilung von den Angelegenheiten, näm-lich Reaktivität gegenüber Planung und Timing gegenüber Funktionalität. Vor allem ist esgarantiert, dass das Zeitablaufverhalten von dem Steuerungssystem mit dem Simulationsverhal-ten des entsprechenden Simulink-Models übereinstimmt. Die Reaktion von einem Giotto-Systemist für jedes gegebene Verhalten in der physikalischen Umgebung eindeutig, deswegen ist sie über-schaubar.

References

[1] Marco A.A. Sanvido By Thomas A. Henzinger, Christoph M. Kirsch and Wolfgang Pree. Fromcontrol models to real-timer code using giotto. 2003.

[2] http://embedded.eecs.berkeley.edu/giotto/. Giotto.

[3] Christoph M. Kirsch University of Salzburg ck@cs.unisalzburg. at Marco A.A. SanvidoVMWare Inc. Thomas A. Henzinger EPFL and UC Berkeley tah@ep�.ch. A programmablemicrokernel for realtime systems. 2005.

[4] Benjamin Horowitz Thomas A. Henzinger and Christoph Meyer Kirsch. Giotto: A time-triggered language for embedded programming. 2001.

[5] Christoph Meyer Kirsch Thomas A. Henzinger, Benjamin Horowitz. Embedded control sys-tems development with giotto. page Emb2001, 2001.

[6] Rupak Majumdar Thomas A. Henzinger, Christoph M. Kirsch and Slobodan Matic. Time-safety checking for embedded programs. 2003.